MTU path discovery and IPSec

Tony Rall trall at
Thu Dec 4 21:24:01 UTC 2003

On Wednesday, 2003-12-03 at 09:38 PST, David Sinn <dsinn at> 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.

> Frag.
> 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).)

Tony Rall

More information about the NANOG mailing list