Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)

At 01:50 p.m. 23/09/2005, you wrote:

>Imagine a host that speaks IPv4 and TCP.  You connect to it.  The host
>goes down and reboots (fairly quickly), but it's flag day, and the host
>now no longer supports IPv4 at all, or no longer supports TCP at all.
[....]
>The point is that for whatever reason, all the host can do is send a
>Protocol Not Supported ICMP, because the TCP stack will not be reached
>(the postulate is that the host has stopped speaking either TCP or
>IPv4).  Because the packet can't get to the TCP stack (which may not be
>running at all), the host can't generate an RST.

Imagine that your connection is operating over a long fat pipe (large 
bandwidth delay product), and assume you are implementing RFC1323 for PAWS.

The ICMP message may contain just the first 64 bits of the original IP 
datagram that elicited the error (i.e., no timestamps).

You might end-up aborting a connection in response to an error message 
caused by an old segment.

Just another scenario in which the same mechanism/feature protects you both 
from incidental (stale error message, in this case) and intentional (as in 
the ICMP-based reset attack).

So my take is that aborting the connection could probably be not the most 
sensible thing to do in this case, either.

Kindest regards,

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm