|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MTU path discovery and IPSec
On Wednesday, 2003-12-03 at 09:38 PST, David Sinn <[email protected]> wrote: > Given the nastiness of ICMP DDoS attacks of late, it might be better to hit > the server and client admin's with the clue bat about not using PMTU > discovery (which also extends to the writers of the App's and OS's). This idea that some protocol has been used for some form of attack means that we should for now and evermore block that protocol leads clearly to a network with all protocols blocked. No, I don't buy the argument that icmp (at least most forms of it) should be blocked. > Frag. > is in the fast path of just about every current version of brand C code, so > giving the tunneling folks the OK to frag the packet might be preferred to > forcing them to mess about with alternate options. Fragmentation should be an ok eventuality for some traffic, but there are a couple of points that make it more painful than it might seem: 1. Encapsulated traffic (such as most vpns - GRE, IPSEC, etc.) often results in packets that subsequently need to be fragmented. That typically yields lots of 1500 byte packets followed by 80 byte packets. 2. I really don't know how NAPT routers deal with fragments. These guys depend on the port information in a packet to reliably determine the target of inbound traffic. But there is no port information in anything other than fragment 1. When they receive a frag other than 1 they don't definitely know who to deliver it to. They have to either guess or drop the packet. Ugh, in both cases. (And note that frag 1 often is not the first fragment to arrive at downstream nodes. In my example in (1), frequently frag 2 will reach places before frag 1 does (if any router along the path reorders its transmit queue based on packet size).) Tony Rall
|