Subject: Re: ICMP attacks against TCP
To: None <tech-net@netbsd.org>
From: Miles Nordin <carton@Ivy.NET>
List: tech-net
Date: 12/10/2004 03:40:03
--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--