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

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?
(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! :-) )

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

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