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

At 03:36 p.m. 30/09/2005, Joe Touch wrote:

> >> 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.
> >
> > I mean that even when you treat the hard error as soft error, you still
> > notify it to the application. The application can, upon this
> > notification, cause the connection to be aborted.
>
>FWIW, the application can't do much with ICMPs it didn't expect to be
>notified about. So this change requires not only a change to TCP, but a
>change to every application that might be affected. That's worth noting
>(if not reconsidering the implications of).

Strictly speaking, here should be a way to notify applications of the 
received ICMP messages (as per RFC1122). Yes, in practice this would mean 
that applications should be modified. What I mean is that, in the event you 
still want to abort a connection upon receipt of an ICMP message, you can 
do so at the application layer, when you are notified (if you have decided 
to) of the received ICMP messages.

> >> 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."
> >
> > My argument is: Why would an attacker bother to guess a TCP sequence
> > number, when it can reset a conenction much more trivially by means of
> > ICMP?
> >
> > "The strength of  a chain is that of the weakest link", I mean.
>
>But TCP-antispoof explains that the chain is already sufficiently weak
>in many cases even if you try to fix ICMP.

It's weak. But we are making it weaker unnecessarily.

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

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