Re: [tcpm] poll for adopting draft-gont-tcp-security

[Fernando Gont <[e-mail]>]

Joe Touch wrote:

> If this document contained only information of decided WG issues, 
> including WG consensus on those issues, you would be correct.

A very large part of draft-gont-tcp-security is about stuff that has
never been discussed by this wg, but that you dismiss with arguments
such as "who TCP needs not be implemented in a secure way", etc.

Also, draft-gont-tcp-security is based on the idea of giving advice for
implementing TCP as good resiliency as possible. And one might argue
that this is a different context as that of draft-ietf-icmp-attacks,
which I guess that was meant for the general case ("general case"
probably being that case in which we are happy to be vulnerable to
obvious  and trivial attacks, I guess).


> I have pointed out several cases where that is not the case - and
> that has been (and remains) my concern.

The only case for which you raised this is for the ICMP attacks stuff. 
Will you support draft-gont-tcp-security if, say, I were to remove the 
entire ICMP section, or replace it with a summary of what's in
draft-ietf-icmp-attacks?


<sidetrack>
As for the ICMP stuff itself: there have been arguments against checking
  ICMPs to be "in window". However, I don't seem to recall people arguing
against the idea of "hard errors should be processes as soft errors when
received for connections in any of the synchronized states" (*this* is
what has been implemented in virtually all stacks for more than 20 years
as the main counter-measure for icmp-based reset attacks). Has anybody
argued against ignoring ICMP source quenches meant for TCP connections?
(this is the main countermeasure for source quench attacks, and what has
been implemented in most stacks). The "in-window" check is useful as a
mitigation technique for the PMTU counter-measure -- however, the one
described in the I-D is mainly based on the idea of "check for progress
on the connection", which I believe parallels the idea in PLPMTUD. --
and I don't recall people arguing against that idea, either.
Also, see the reviewers in the Acks of the I-D.. that's people from most
of the major TCP implementations. And the ideas in the I-D are the
running code we have and we use. However, we are so full of ourselves
that we tell implementers that the code they have implemented, which has
been running the Internet for the last 20 years or so, is "buggy",
backed on how we think the code should be (despite it doesn't run in
that way, and in some cases has not done it that way for ages (if it 
ever did)).

Want to now what the industry did in response? -- The have ignored our
consensus.
</sidetrack>

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