At 09:13 p.m. 14/07/2005, Kevin Lahey wrote:

> > 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.
>
>Doh, in my hurry to get out of town, I obviously didn't read either
>the code or the draft closely enough.  Sorry.  Clearly, with the special
>case checking the size of acked segments, the PMTUD-delay stuff should work
>as quickly as the current code.

That's is the entire point of the two-phase separation. You only get a 
"penalty" (if you want to call it that) for Path-MTU changes, which are not 
that frequent in practice. And even then, the better security would be 
worth that penalty.



>Does the added complexity of the PMTUD-delay scheme result in significant
>advantages over the simple sequence number checking?

Yes, definitely. You can forget about facing the same problem again in the 
future.
And, by the way, the fix is pretty trivial. Not much additional code is needed.



>The sequence number and source quench fixes are obviously important to
>implement right away.  I don't think that *I* would add the PMTUD-delay
>fix to NetBSD, but I certainly won't object if someone else does.

You may not need it today. But at some point you'll start using even larger 
TCP windows than nowadays, and you'll need it. I wonder why anyone would 
want to be hit by a problem in the future, rather than fixing it now, once 
and for all.



> > 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.
>
>As you point out publicly elsewhere, the PLPMTUD stuff is totally
>orthogonal to your proposal.  The goal of PLPMTUD is to be able to
>work around PMTUD black holes, situations in which there are no
>ICMP messages at all.

My comment had to do with some statements made by Matt Mathis (one of the 
authors of the PLPMTUD document) at the last TCPM WG meeting. He seems to 
think my work interferes with that of the PMTUD WG.



>My concerns were with the elegance of the solution,

I don't think it's fair to make this statement without stating why you 
think so.



>and with
>implementing an obviously expired draft that doesn't show up
>on the IETF working group web site with which it was claimed
>it was associated.

As an author of the PLPMTUD draft, you must now that after a draft has 
expired, you can still submit updates. A draft being expired just means you 
didn't update it during the last six months, and not that the draft is not 
worth anymore, or that you have not got feedback on it, or anything.

Actually, I have not being able to submit an update because I have spent 
most of my time this year providing support to vendors to help them 
understand the problem, and implement the fixes, and also presenting this 
work at a number of conferences (including CanSecWest 2005 and BSDCan 
2005), to raise awareness.

Being that we are discussing this issue on a NetBSD mailing list, I think 
you should be more concerned about fixing the problem rather than worried 
about the status of the draft at the IETF (whether it's expired or not, and 
whether it's an RFC or not).



>After spending almost an entire day reading the TCPM archives,
>I can understand both why it wasn't there, and why you seem to
>be so touchy about the whole thing.  I'm sorry you had such a
>rough time trying to get through a worthwhile proposal.

Some people at the TCPM WG even wondered if we should do something about 
these vulnerabilities, so no wonder about why it has been hard to move the 
draft forward.

Anyway, this weekend I will submit an update of the draft. So next week 
you'll find draft-gont-tcpm-icmp-attacks-04.txt on the IETF repositories.

Kindest regards,

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