At 10:39 p.m. 09/07/2005, Kevin Lahey wrote:

> > >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:
>
>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 whether we want to
>implement the rest of the stuff, even surrounded by ifdef's, before this
>draft becomes an RFC.

If your concern is that the draft has not yet become a STD, that may take 
*years*, and I don't think NetBSD users want to wait that long for this 
problem to get fixed. Also, I can find no reason for which you'd want to 
implement the TCP SEQ number checking (which is *not* proposed in an RFC, 
either), and not the PMTUD fix.

Ironically, the NetBSD community has contributed to the PMTUD-specific fix. 
That's why you'll find Miles Nordin acknowledged in the draft.

BTW, you should also be concerned that NetBSD has (fortunately) been 
treating hard errors as soft errors even when the RFCs state that you 
SHOULD abort the corresponding connection upon receipt of one of them.



>I haven't kept up with the work of TCPM, and perhaps someone who has
>should comment on the whole thing. Based on a brief look at the TCPM
>web site, it looks like there are a number of mitigation proposals on
>the table, and it might be useful to wait until there is more consensus.

No. Mine is the only proposal to solve these ICMP vulnerabilities.

I hope NetBSD moves this forward, and does the right thing, rather than 
applying the big vendor policy of denying the problem and wait for years 
before they fix in years what they should fix in terms of weeks.

I have had the pleasure to meet a number of NetBSD guys this year at 
BSDCan, and I'm sure they will not want to apply that big-vendor policy to 
NetBSD.

Kindest regards,

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