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

[Fernando Gont <[e-mail]>]

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.

That said, I would call 5+ years a rush... :-))



> 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

I don't really think anybody could call himself a "good engineer" if he
enabled IPsec just to mitigate the off-path attacks we have been
discussing in the last few years, when there are general and lightweight
mitigations for them.



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



> Yes, I have been the most vocal proponent of this view on TCPM, and
> perhaps in TSV. I do not believe I represent only myself, however - if
> that's the "rough consensus", there are mechanisms to override me
> anyway. It's also useful to note that some of the most vocal proponents
> of "it's deployed, so let's change the standard" were involved in their
> deployment.

Joe, I was involved in the deployment of "ignore source quenches" and
the PMTUD fix, only

The TCP SEQ check had already been incorporated in Linux years ago, and
was incorporated in lots of other stacks as a result of my I-D, rather
than my "code".

And if you want to "blame" somebody for the hard errors -> soft errors,
you should probably "blame" Mike Karels -- me, I'm thankful for his
work. FWIW, this behavior has been deployed for more than fifteen years.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1