MTU path discovery and IPSec
trall at almaden.ibm.com
Thu Dec 4 21:24:01 UTC 2003
On Wednesday, 2003-12-03 at 09:38 PST, David Sinn <dsinn at dsinn.com> wrote:
> Given the nastiness of ICMP DDoS attacks of late, it might be better to
> 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.
> is in the fast path of just about every current version of brand C code,
> giving the tunneling folks the OK to frag the packet might be preferred
> 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).)
More information about the NANOG