Subject: Re: icmp patches
To: Kevin Lahey <email@example.com>
From: Fernando Gont <firstname.lastname@example.org>
Date: 07/09/2005 21:01:13
At 07:49 p.m. 09/07/2005, Kevin Lahey wrote:
> > The idea is simple: If you receive an ICMP error message, the
> > 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
>That does seem like a clever idea, but why wouldn't the attacker just send
>a RST instead? I guess I'm concerned that this is delaying ICMP processing
>when there is an easier way for an attacker to accomplish the same thing.
That of "delaying the ICMP processing" is the attack-specific
counter-measure for the blind performance-degrading (PMTUD) atack.
i.e., there are three attacks, and three counter-measures. Namely:
* Blind connection-reset attack: The solution is to treat hard errors as
soft errors. With this counter-measure, you become immune to them.
* Blind throughput-reduction attack (ICMP Source Quench): The solution is
to ignore ICMP Source Quench messages that are meant for TCP connections.
With this counter-measure, you become immune to them.
* Blind performance-degrading attack (PMTUD): The counter-measure to this
attack is the one we have been discussed. As explained, with this
counter-measure you keep the same convergence time as for the current
Path-MTU Discovery mechanism, while avoiding the security problems of the
e-mail: email@example.com || firstname.lastname@example.org