--pgp-sign-Multipart_Fri_Dec_10_03:39:35_2004-1
Content-Type: text/plain; charset=US-ASCII

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

    fg> Hope to get your constructive comments, now. :-)

in 7.2.2 you suggest ignoring PMTUD messages until you get a bunch of
them.  This seems clumsy, and could really slow down PMTU convergence.
With gre-in-IPsec tunnels already it can take >10 round trips to
discover PMTU.

Maybe you should instead suggest keeping state for ``maximum MTU
pushed through the link so far'' value that starts at 0 for fresh
connections, and tracks the largest segment ever acknowleged.  This
metric along with the existing PMTU measurement would capture the
MTU-uncertainty of a fresh connection.  For a connection that sends
short spurts of data and never has inclination to transmit a large
segment, these two values might never converge.  But a bulk file
transfer should quickly bring the two values to be equal.  You can
suggest your wait-for-multiple-retransmits workaround only when the
ICMP toobig message asks for an MTU smaller than the ``maximum MTU
ACKed so far''.  When your algorithm sees enough unsuccessful
retransmissions, it can knock the ``maximum MTU ACKed so far'' back to
0 and allow PMTUD to restart.  That way, fresh connections can
converge on the PMTU quickly, while established connections have
whatever DoS-resistance you're trying to achieve, but are still able
to reconverge on a new MTU if routing changes.


I've long found it annoying when hosts will reset an ESTABLISHED
connection upon getting an ICMP unreachable.  I appreciate your
revisiting this nuissance under the ``security'' banner and agree with
the general idea: they should abort a SYN_SENT connection upon getting
an unreachable, but an established connection should wait for routing
protocols to reconverge, for the ordinary TCP timeout.  It looks like
black-letter RFC to me:

rfc1122 3.2.2.1
            A Destination Unreachable message that is received with code
            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
            routing transient and MUST therefore be interpreted as only
            a hint, not proof, that the specified destination is
            unreachable [IP:11].

and 4.2.3.9
            o    Destination Unreachable -- codes 0, 1, 5
                 (net, host unreachable)

                 Since these Unreachable messages indicate soft error
                 conditions, TCP MUST NOT abort the connection, ...

            o    Destination Unreachable -- codes 2-4
                 (proto, port unreachable)

                 These are hard error conditions, so TCP SHOULD abort
                 the connection.

I see your RFC suggests the second case, the hard errors, revert to
soft for established connections, with some reasonable defense.
Sounds good.  But on Windows ExPee, if I unplug the network cable my
Putty session is instantly killed.  Isn't that a violation of 4.2.3.9?
Have you done any testing if the ``soft'' unreachables can also be
wrongly used to reset established connections on certain TCP stacks?

--
The auditing that is conducted on slot machine software in the U.S. is
significantly more meticulous than what is done to voting software.
		-- Bruce Schneier

--pgp-sign-Multipart_Fri_Dec_10_03:39:35_2004-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iQCVAwUAQblg44nCBbTaW/4dAQKNFQP/cOIxQtKZjFlOeaE2eBrSyDNGz/cExM2j
xh1kudvSOELLuQYGBYuGc30xMYeA2WASlN+23wDpaIO0dCbd1PjghyCRDtUEjY4m
PITcmnzMIFQmOweyZJfmGUHSB7l9SoPGJ5jy4koe1RrttEm2x1s8mCKRv/xyKvLl
3EHGzcexF3U=
=8egj
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Dec_10_03:39:35_2004-1--