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

[Fernando Gont <[e-mail]>]

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

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

These considerations were made when writing the document. As stated by
other tcpm'ers, no document is meant to be perfect. If anybody catches
any recommendation that is deemed to go against this principle, we can
fix the document, and that's it.

Simply knocking down an entire effort of many people during many years
simply because some people do not agree with some of the proposed
mitigations seems simply ridiculous.



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

Bringing the document to the IETF, and having the tcpm wg adopt this I-D
is taking that step back. Is assessing the entire document, and applying
changes where deemed necessary.



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

While not explicitly mentioned, this was the standpoint from which this
document was produced. Yes, there may be things to fix.... every
document can be improved. And by bringing this to the IETF it's implicit
that the resulting RFC would differ from the version of the document
originally published by the UK CPNI.

Thanks!

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