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

On Fri, Sep 23, 2005 at 12:57:40PM -0300, Fernando Gont wrote:
> At 11:32 a.m. 23/09/2005, Joe Touch wrote:
> 
> >> Issue 1 is: When a so-called ICMP "hard error" is received for a
> >> connection in any of the synchronized states (ESTABLISHED and so on),
> >> treat the error message as a soft error (i.e., do NOT abort the
> >> corresponding connection).
> >
> >WHY? Such an error could occur due to a reboot. It is legitimate operation.
> 
> In that case you should receive an RST, not an ICMP message.

Joe's not laying out his case completely.  Let me try to fill in the
blanks and he can tell me where I've misinterpreted what he's
suggesting.

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.
You can work your imagination for other reasons that TCP might fail to
come up - a firewall (mis-?)configured to send the ICMP for application
protocols that have been outlawed, an embedded TCP stack with an
initialization/configuration error, TCP in an LKM with the wrong kernel
version...  There are a few whack-O cases out there that are unlikely
but well within the range of the possible.  None of those behaviors
(with the possible exception of the firewall) breaks a spec that I
can think of.

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.

Of course, if no ICMP is generated or gets through, the ESTABLISHED TCP
will eventually have a UTO and abort the connection.

Yes, this is a pretty bizarre case, but it is a valid hard error in an
ESTABLISHED state, and one where aborting the connection is the most
sensible thing to do.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG