Subject: Re: icmp patches
To: Fernando Gont <firstname.lastname@example.org>
From: Kevin Lahey <email@example.com>
Date: 07/13/2005 18:05:57
On Sat, 09 Jul 2005 23:40:40 -0300
Fernando Gont <firstname.lastname@example.org> wrote:
> At 10:39 p.m. 09/07/2005, Kevin Lahey wrote:
> >It seems obvious that we should incorporate the ICMP sequence number
> >checking stuff. That's important.
> Checking only the TCP SEQ number puts you in the same position as for the
> "Slipping in the window" attacks.
> I'm glad NetBSD has chosen to fix this problem once and for all.
I'm curious about what attack you're trying to prevent. The cure may
be worse than the disease.
By waiting at least an RTO before acting on packet too big
notifications, we're slowing down PMTUD in every case. This could
have a big impact on people behind a small-MTU connection[*].
If the attacker is able to guess sequence numbers, why wouldn't she
send a TCP RST or insert data, or otherwise molest the connection?
Until we can defend against those attacks, why should we pay the
startup penalty to cure a less painful (PMTUD) attack?
I'm also concerned that this fix mitigates but does not prevent PMTUD
attack. If an ACK is lost in the network, we'd still accept the bogus
ICMP message. I wonder if a better fix might be to notice large
numbers of bogus ICMP messages and turn off PMTUD altogether.
If this has already been discussed exhaustively elsewhere, I'd be
grateful for a link to that discussion, and I can STFU, or at least
not re-hash the same arguments.
[*] I don't know anybody with this sort of connection, but it
seems perfectly possible.