Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> Joe Touch wrote:
> 
>> Much of this "rush to react" has led to a perspective that any incoming
>> packet that isn't expected is an indication of *attack*. That could
>> easily lead to changes to TCP that make it inappropriately complex and
>> fragile, at the expense of protecting every home computer from attacks
>> that are typically waged only at routers or other core network components.
> 
> Joe, your statement (At least wrt icmp attacks) has no correlation with
> reality.
> 
> ICMP reset attacks have been pretty usual since the 90's as IRC nuke
> attacks. i.e., they have been performed mostly against end users, rather
> than "core network components". Google for "irc nuke", or the like, and
> I'm sure you'll find 10+ years old icmp exploits.

Useful to include in your doc. Not cited, I note.

Yours is not the only document you have accused me of impeding. It would
be useful to reconsider my post in the context of the totality of work
it addresses (including the comment about being involved in deployment).

>> I agree with Wes that the role of ICMP in the Internet needs to be
>> re-examined, and some changes made. However, I also believe that many of
>> the current TCPM "rush to react" changes (including tcpsecure, some of
>> the ICMP checks, some parts of the TCP cookie transactions proposal) are
>> a poor substitute for the use of true security (IPsec, TCP-AO), 
> 
> They are not a substitute. And the recent support by Ran Atkinson
> (co-author of previous versions of the IPsec std) should be a good hint.
> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html

Note that he supports this as offered - Informational.

>> which
>> may also need to include more widely-deployable variants with different
>> levels of protection (e.g., BTNS).
> 
> Side note: I wonder what would be the result if you submitted BTNS to
> the same level of "correctness evaluation" as you have submitted this I-D...
> (Maybe the "BTNS" acronym is an implicit acknowledgement of that?)

BTNS doesn't redefine the core, *non-secure* TCP service for everyone.

Joe