From an old bugtraq posting I made:
The problem I'm exposing is quite obvious, but unfortunatelly
can be used in a very simple way by script kiddies.
It's possible to slowdown (a lot) connections between two
arbirary hosts (but at least one with the PMTU discovery enabled)
using some spoofed TCP/IP packet. Maybe you can do more
against some TCP/IP stack.
I tried it a bit against some site, seems that at least Linux
and some BSD are vulnerable. Anyway it is quite probable
that almost all the TCP/IP stacks with the PMTU discovery
enabled are vulnerable.
There isn't a clear solution.
DETAILS (When I talk about "the stack" I'm refering to Linux 2.4 TCP/IP stack)
The path MTU discovery is used to optimize TCP/IP performances.
Sorry if you don't know how it works, no flood for readers.
Anyway the stack takes an hash table with the MTU of other ends. When
an ICMP frag-req but DF set reaches the stack it perform a look-up
in the hash table, searching for the old MTU, than look at the
size of the quoted packet in the ICMP packet, and compute the new MTU
(strong semplification). The look-up is done using even the TOS
field, since different TOS may have different routing (I guess is for this).
A - some host that talks or will talk with the host B
B - some host that talks or will talk with the host A
C - the attacker, able to spoof IP packets
C: sends an ICMP echo request, with some data, the source
address set to A and the dest address set to B.
B: creates a new entry in the hash table, if there isn't an old.
C: sends an ICMP fragmentation needed but DF set, with the source
address set to A and the dest address set to B,
quoting the ICMP echo-reply response that we can guess (set the
right TOS (usually 0x40) if you want that this works).
B: set the new MTU in relation to the quoted packet total len.
You may want to send this packets once every second, just to
avoid expires. Also This may be useful if the MSS TCP option override
the MTU (it shouldn't, but some implementations may do this),
otherwise you can send even less spoofed packets.
Note that shouldn't be useful to quote a packet that was really
sent in this scenario.
Please, write the exploit just to confirm this, don't ship
it to lame people. I want not to release my proof-of-concepts
That's all, can someone confirm this?