Re: [pmtud] Improvement for the current PMTUD mechanism

[John Heffner <[e-mail]>]

Fernando,

I've read over the PMTUD-related section of your draft.  Here are a few
comments.

One thing to consider is the case where one flow is traversing multiple paths
concurrently.  In the algorithm you describe, in this case it's likely a host
will ignore the ICMP PTB messages since it can still make progress, but
ignoring them is clearly the wrong thing to do and will drastically hurt
performance.  You may consider incorrect operation in this case worth the
trade-off, but it should at least be explicitly documented.

It might be a good idea to add some text about layering issues. Classic PMTUD
occurs at both the IP and TCP layers.  In implementations with which I'm
familiar, the ICMP message is processed by the IP layer, updating the pmtu in
the route cache, then the message is demuxed and passed down to TCP, which
updates is MSS and retransmits the packet.  To implement these the algorithm you
describe, you'll need the ability for TCP to be able to "override" the IP
layer's idea of the pmtu.  We have similar constraints for MTU probing, and
we're addressing this issue more directly in the next revision of
draft-ietf-pmtud-method.

One small suggestion is that it might be natural to use "R1" from RFC 1122
instead of specifying the new variable MAXSEGRTO.  This variable indicates
how long to wait before deciding the connection is making no progress.  This
may be what you're looking for, or possibly not.  But reusing an existing
variable does make implementation easier. :)

Thanks,
  -John


On Monday 05 September 2005 12:24 pm, Fernando Gont wrote:
> Folks,
>
> Since August 2004 I have been woeking on an internet-draft on ICMP attacks
> against TCP. One of the attacks the draft addresses is a "blind
> performance-degrading attack" in which the traditional PMTUD is exploited
> to reduce the size of the packets used for a given connection.
>
> We (me, and the community, including "traditional" vendors, open source
> ones, etc.) have been able to work out an improvement to the current PMTUD,
> to mitigate its security implications.
>
> The fix just tries to address that. By no means is it an alternative to
> PLPMTUD. For instance, it does not address ICMP blackholes.
>
> I'd like to get feedback from this WG on the PMTUD fix. I think the
> proposed mechanism could be used in some broader PMTUD such as PLPMTUD, so
> that ICMP can be used without the security implications of the traditional
> PMTUD, and thus the same convergnece time than the tradtional PMTUD could
> be achieved.
>
> The draft will soon be available from the internet-drafts public
> repository. In the mean time, you can access it through my web site:
> http://www.gont.com.ar/drafts/draft-gont-tcpm-icmp-attacks-04.txt
> (http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html)
>
> Kindest regards,
>
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
>
>
>
>
>
>
> _______________________________________________
> pmtud mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pmtud

_______________________________________________
pmtud mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pmtud