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

Fernando Gont 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).

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

Joe

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

Attachment: signature.asc