Subject: Re: icmp patches
To: Kevin Lahey <email@example.com>
From: Fernando Gont <firstname.lastname@example.org>
Date: 07/15/2005 19:08:38
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
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
>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
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.
e-mail: email@example.com || firstname.lastname@example.org