--pgp-sign-Multipart_Tue_Dec_14_10:20:43_2004-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "fg" == Fernando Gont <fernando@gont.com.ar> writes:

    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.

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.

    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''.  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.

    fg> your refinement means we'd discover the *initial* PMTU a bit
    fg> quicker. I cannot think of any other point in the connection
    fg> at which your "refinement" would kick in.

Exactly.  Unless a connection is rerouted, I thought PMTUD typically
happened to connections shortly after they open, in the common case.

I may have suggested partially disabling your workaround for fresh
connections because I don't fully understand the performance cost of
your draft, 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.  ``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.  That would help me
understand how it works, and the cost.  Then, ``To tamper with PMTU on
a system running the workaround, the attacker would have to
__________.''  That would help me understand to what extent choosing
constants controls the effectiveness of the DoS-resistance.

--pgp-sign-Multipart_Tue_Dec_14_10:20:43_2004-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)

iQCVAwUAQb8E14nCBbTaW/4dAQKq7gQAl1Za4DZMkdbcuccGasqBMtJkAZtnN8ZQ
QzfuHJRxgQ9tCd07tLE4zyUeO7ZFDtYimQT0allvYH40YQI0gmXrGrMSw1kf7bIA
sZzXmExGpzACmQM4MuqmddXlc/RXmF2TclaRm6f1tYOzaIf+1WVD0sJLHBxtphfe
SxirFgs6nsc=
=mAxJ
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Dec_14_10:20:43_2004-1--