At 10:05 p.m. 13/07/2005, Kevin Lahey wrote:

> > 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.

Please go and read the draft at 
http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html
This question, together with the previous ones on the fixes mean that you 
either didn't read the draft, or that you need to read it again.



>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[*].

Your assumption is completely wrong. The two-phase separation of the PMTUD 
fix you mean you'll achieve for new connections the same convergence time 
as the current PMTUD. Which is, by far, much smaller than the convergence 
time that the proposal of the PMTUD WG 
(http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt), of 
which you are one of the authors.



>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?

Two answers for this question:

a) You already have counter-measures for those attacks: Use the TCP MD5 
option, or use IPsec. You even have the TCP-secure draft, which proposes to 
modifiy the TCP state machine as a counter-measure.
c) Pro-active security



>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.

TCP acknowledgements are cumulative. If you have several segments in 
flight, any of the ACKs will do.
If you don't, it will be much harder for you to hit the window.

Also, if you are planning to send a huge number of ICMP packets (to be able 
to hit the window, and congest the link to intentionally congest the path), 
the RTT will tipically increase, and therefore the RTO will be increased. 
Just delaying the ACKs by means of congestion will not do, as TCP will wait 
for a longer time.

Even then (read the draft!), the draft states that you can choose to 
require more than one ICMP and RTO, if you are concerned with the minimum 
requirement of one ICMP error message and one RTO.



>I wonder if a better fix might be to notice large
>numbers of bogus ICMP messages and turn off PMTUD altogether.

Don't wonder about that: It wouldn't. I'd throw you lots of ICMP messages, 
make you fall back to fragmentation, and then make a fragmentation attack.



>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.

All these issues are in the draft itself.

We tested the counter-measure extensively at the OpenBSD Hackathon, and 
found that it is pretty effective even if you don't check the TCP SEQ 
number. Of course, OpenBSD is doing both.

Kindest regards,

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