Subject: Re: icmp patches
To: Kevin Lahey (by way of Kevin Lahey <firstname.lastname@example.org>
From: Fernando Gont <email@example.com>
Date: 07/09/2005 18:18:51
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
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
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
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
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
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.
e-mail: firstname.lastname@example.org || email@example.com