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

On Tue, Sep 27, 2005 at 02:09:48AM -0300, Fernando Gont wrote:
> At 01:50 p.m. 23/09/2005, Ted Faber wrote:
> 
> >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.
> 
> So we would keep connections vulnerable to reset attacks for that 1 in 
> 1000000th chance in which this scenario might take place?

That's a decision for the community, of course.  But my opinion is that
you need to address the issue in the draft, not implicitly assume that
tradeoff is obvious.  Even if the community adopts it, it's wise to
indicate that we thought about it. 

> (And, btw, in the event that happened, why would ignoring the ICMP message 
> hurt you? For instance, the proposed policy does not prevent the 
> application layer from being notified of the received ICMP error message! 
> So this means you still let the application shoot itself, if it wants to! 
> :-) )

Hey, I generally believe that ignoring ICMP doesn't hurt you.  What's at
issue is whether responding to this ICMP can help you.  I believe that
the document asserts that once the connection is ESTABLISHED, this ICMP
is never a valid reason to terminate the connection.  Joe's described a
situation (that consists of many different possible causes) where
listening to that ICMP is perfectly reasonable.  An application's always
welcome to shoot itself from TCP's perspective.

> 
> Also, if there's consensus on the side of "not doing anything about this", 
> then my next question/comment would be "Does it make sense to modify TCP's 
> state transition diagram (as we currently are) to address TCP-based reset 
> attacks, then? An attacker will use ICMP-based ones, because they are much 
> easier to perform!"

If you've got questions about the motivations for and support of
tcpsecure, there's no need to be coy - no need to make such comments
conditionally.  :-) 

Right now, it sounds like the answer to your question is "yes, the WG
supports the tcp secure changes, independently of the changes proposed
here." 

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