[ovs-dev] MPLS and VLAN QinQ patch

Ben Pfaff blp at nicira.com
Fri May 25 16:13:35 UTC 2012


On Fri, May 25, 2012 at 05:49:30PM +0200, Ravi.Kerur at telekom.com wrote:
> I would like to revisit this topic...
> 
> > ofproto-dpif.c
> > --------------
> > 
> > I think that say, two, dec_mpls_ttl actions in a single flow,
> > starting from a TTL of, say, 2, will fail to detect reaching TTL
> > 0.  Also, the existing implementation of dec ttl for IP stop
> > translating actions after reaching TTL 0.  Presumably the MPLS
> > implementation should do the same.
> 
> <rk> In traditional network for invalid TTLs(0 and 1) ICMP error msg
> has to be sent and a TTL expiry handling attack can be easily
> envisioned with this. Routers usually mitigate this attack via
> access-list to drop packets with TTL 0/1 (assumption is that network
> applications usually send with larger TTL value and it's highly
> unlikely that a packet will ever arrive with TTL 0/1) or rate-limit
> sending ICMP error message and can be evidenced via traceroute. In
> OVS, I see every invalid TTL(both IP and MPLS) packet is sent to the
> controller and I assume controller does rate control on sending ICMP
> error message or drop the packet or do additional processing?  It's
> quite unclear to me what's the rationale to send every invalid TTL
> packet to controller with knowing what it does, can you please
> clarify?

I don't see how your comment is related to mine.  Mine is about
properly handling double-decrement to zero.  Yours is about handling
decrement to zero in general.

The main rationale is that OpenFlow says to do that.  I wasn't behind
that decision.  You could ask the people who were, if you join the
Open Network Foundation "extensibility" mailing list.

There are other dubious OpenFlow choices regarding MPLS, also.

Open vSwitch can limit the rate at which "packet-in"s are sent to the
controller.  This can mitigate the amount of work the controller has
to do.



More information about the dev mailing list