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

["Eddy, Wesley M. (GRC-MS00)[Verizon]" <[e-mail]>]

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Joe Touch
>Sent: Tuesday, June 30, 2009 11:09 AM
>
> ...
>
>This is a key flaw in the approach taken in this document. A proper scan
>of all aspects of TCP for security vulnerabilities would be useful, but
>the doc focuses on implementations as if they provide unique or correct
>insight into the issue. The state of implementations may provide a
>reason to look at this issue, but do not necessarily provide the right
>basis for determining how to proceed.
>
>TCP is not secure; it was not intended to be. We cannot make it secure
>simply by dropping vulnerable components. We cannot make it secure by
>focusing on poor implementation choices.
>
>If the WG is to proceed on this, there are two viable choices:
>
>	1) a from-scratch analysis of every aspect of TCP
>	for security, not just the ones implementers have
>	either tripped over or misdesigned
>
>	2) a from-scratch design of a new secure transport
>	protocol (in TSVWG)


Since 2 is out of our scope in TCPM, we'd have to move that to discussion
on TSVWG.

Just my personal thoughts here ... not co-chairing yet ...

As for from-scratch analysis, my personal thought is that Fernando's list
of issues identified is a strong starting point, even if we don't agree
about some of the mitigations suggested.  I 100% agree with Matt and Joe's
warnings that we need to come at the mitigations from the standpoint of
reducing risks without closing off our potential to continue innovating,
extending, and keeping TCP working as a key part of the Internet.  To me,
this task resembles some of the BEHAVE working group's work, where we know
that people are doing bad things in implementation, so we have need to
write guidelines documents to tell the implementers what they should be
doing.

I think much of Fernando's analysis is quite good, at least in terms of
identifying potential areas that can be exploited.  However, I do think
it could benefit from taking another step back in order to organize and
make sure the set of issues and recommendations is complete.

As a systems engineer, my first thought is always for requirements, so
when I looked at Fernando's document, my question was if we're intending
to do a "TCP implementation profile" for security, then what are the
actual requirements to build to ... something like:

- TCP MUST be able to be implemented in a way free of exploitable
  conditions leading to:
  - unbounded memory utilization
  - unbounded CPU utilization
  - data injection by off-path third-parties
  - connection breakage by off-path third-parties
  - packet amplification by off-path third parties
  - ...

- Recommended mitigations to security issues identified in legacy TCP
  specifications MUST NOT further limit TCP properties of:
  - interoperability
  - scalability (data rates, loss rates, RTT, etc.)
  - extensibility (new options, congestion control, use of reserved
    bits, etc.)
  - ...

If we can clearly state the goals like this, then we can both organize
the issues found more logically, and we can evaluate the potential harm
of the proposed implementation techniques very systematically.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------