At 01:29 p.m. 09/07/2005, Kevin Lahey wrote:

>I was a little unclear on the utility of putting off processing an MTU
>update via the PMTUD_PENDING, in any case.  What exactly is going on
>there?

The idea is simple: If you receive an ICMP error message, the corresponding 
segment should have ben dropped. So when you receive a message, you save 
it, and wait for a RTO. If in the mean time the corresponding segment is 
acknowledged, you clear the pending error (i.e., the ICMP error message 
connot be legitimate). If t isn't acknowledged, when the corresponding 
segment times out, you honor the ICMP error message.

This means that in order to succeed, an attacker would have to be able to 
either:
a) Drop the data segments you are sending to the remote endpoint
b) Drop the ACKs the other endpoint is sending you

If an attacker is able to do this (i.e., he's either a man-in-the-middle or 
can completely flood your communications link), he won't bother about 
performing this attack, because he has already DoS'ed you.



>The draft's suggestions about waiting until you'd seen a
>certain number of PMTUD messages to act seemed a little questionable.
>After all, if I can generate one bogus ICMP message, why not generate
>several?

To increase protection, you can increase the number of *RTOs* you wait. 
This means that even if an attacker is able to hit you in the window and 
cause *some* packets to be dropped, you will still be immune.
That of requiring the attacker to send more than one ICMP error messages 
means he should be able to hit in a moving window (if the window is closed, 
he has no chance at all) more than once. This requires more work on the 
attacker.

If the number of required RTOs is larger than the number of required ICMP 
error messages, you're sort of implicitly acnowledging that ICMP error 
messages are unreliable (i.e., can get lost), and that they may be subject 
of rate-limiting.

Last, but not least, the introduction of two "phases" ("Initial Path-MTU 
Discovery" and "Path-MTU Update") is to allow for quick convergence just 
after connection-establishment. The convergence time would be smaller than 
that for PLPMTUD (the proposal of the PMTUD WG), but still unacceptable.

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org