At 10:20 14/12/2004 -0500, Miles Nordin wrote:

>     fg> Could you provide more information about why you say for this
>     fg> specific case it might take more than 10 RTT?
>
>http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml#t9
>
>The thing about the chart above is, it's not really about rtt.
>Because intermediate tunneling layers catch the ICMP toobig messages
>rather than the original sender, there's no way to force an immediate
>retransmit.  so, we're talking about several TCP retransmit timeouts,
>not several rtt's.

That's a problem that doesn't have to do with the proposed fix, but with 
PMTUD and tunnels themselves. You cannot use PMTUD in those scenarios.

That's why there's a proposal of an alternative PMTUD mechanism which does 
not (necessarily) need ICMP "don't fragment and DF bit set" packets. (It's 
referenced in my draft)

Also, IIRC, many tunelling mechanisms, such as those that are meant as 
transition mechanisms to IPv6 state that the tunnel must process the ICMP 
DF packets so that the endpoints can use the PMTUD mechanism.


>If you will _ignore_ ICMP toobig messages, you add this retransmit
>timeout problem to the common case, not just the pathological
>tunneling case above.  That's a pretty high cost to pay in the common
>case.

For the typical case, the PMTUD mechanism won't take longer than a few RTTs 
to succeed. And that's only just after the connection establishment phase.

Also, the applications that are more concerned about the PMTUD attacks are 
those that depend ond long-lived TCP connections. For them, the initial 
cost of a few RTTs at the begining of a connection which may last for 
*days* is not an issue, IMHO.


>    fg> In those cases, even the first ICMP DF would be claiming a
>     fg> Next-Hop MTU larger than the "maximum MTU ACKed so far", and
>     fg> thus the resulting behavior would be that described in the
>     fg> draft.
>
>no.  what I said was, you will disable your workaround and simply
>respond as usual whenver the ICMP toobig message asks for an MTU
>larger than the ``maximum MTU ACKed so far''.

You meant "smaller"?


>Since the latter value
>starts at zero, toobig messages are always honored on fresh
>connections, and never stochastically ignored by your workaround
>unless the PMTU goes down during the life of a connection.

As I said, this may make sense. I will think about it a bit more, and will 
most likely discuss this as a refinement of the proposed fix.
However, as I said before (and as you pointed out) maybe this requires some 
further analysis to see if the benefits are worth the additional complexity.


>I may have suggested partially disabling your workaround for fresh
>connections because I don't fully understand the performance cost of
>your draft,

In the worst case, it's a performance cost of a few RTTs at the beginning 
of the connection.


>or fully understand the performance of ordinary PMTUD.
>What might help me is a careful analysis of the constants you leave
>unspecified.  Instead of handwaving about why and when they
>should/could be bigger or smaller, do a quantitative analysis of the
>cost.

You must understand that vendors are right now figuring out how to patch 
their systems. Router vendors are the most concerned with the PMTUD 
vulnerability.
That's why my draft did not include an extensive discussion of the possible 
values for the constants, and their possible effects. This revision of the 
draft just tried to sketch how the PMTUD vulnerability could be fixed, so 
as to provide vendors a "hint" on a possible path to go. The next revision 
of the draft will probably contain an extensive discussion of the possible 
values for the constants, etc.

Being a security thing, *timing* is an issue for this draft.


>``With constants set at ______, PMTUD on this network takes ___
>RTTs and ___ TCP timeouts, as you can see below.''  then a diagram
>like in the link i posted.  ``Under the current common algorithm,
>PMTUD on the same connection requires ___ RTTs and no tcp timeouts.''
>Then, you might want to repeat the comparison of your workaround's
>performance with the commonly-deployed PMTUD for a really hard case
>like the multiple tunnels link I posted.

For tunnels, either PMTUD works as expected, or it doesn't.

Thanks (again) for your feedback!


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