Sorry for the confusion, I was not questioning your comments they are valid and I have addressed them. While making changes it occurred to me how invalid_ttl is handled in the controller, will it suffer from similar ttl expiry attack and should rate-limit sending invalid_ttl to controller? Since OVS can rate-limit and invalid_ttl for ip doesn't rate-limit, will leave the code for mpls as it is.
-----Original Message----- From: Ben Pfaff [mailto:b...@nicira.com] Sent: Friday, May 25, 2012 9:14 AM To: Kerur, Ravi Cc: dev@openvswitch.org Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch On Fri, May 25, 2012 at 05:49:30PM +0200, ravi.ke...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
