Subject: Fwd: Security Assessment of the Transmission Control Protocol (TCP)

From: Marshall Eubanks <[email-masked]>
Date: Fri, 13 Feb 2009 17:25:45 -0500

If I am reading this correctly the UK Centre for the Protection of  
National Infrastructure
wants the IETF (or some other body) to produce a "companion document  
to the IETF specifications that discusses the security aspects and  
implications of the protocols, identifies the existing  
vulnerabilities, discusses the possible countermeasures, and analyses  
their respective effectiveness."

Regards
Marshall

Begin forwarded message:

> From: Fernando Gont <[email-masked]>
> Date: February 12, 2009 5:38:35 PM EST
> To: [email-masked], [email-masked]
> Subject: Security Assessment of the Transmission Control Protocol  
> (TCP)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello, folks,
>
> The United Kingdom's Centre for the Protection of National
> Infrastructure has just released the document "Security Assessment of
> the Transmission Control Protocol (TCP)", on which I have had the
> pleasure to work during the last few years.
>
> The motivation to produce this document is explained in the Preface of
> the document as follows:
>
> - ---- cut here ----
> The TCP/IP protocol suite was conceived in an environment that was  
> quite
> different from the hostile environment they currently operate in.
> However, the effectiveness of the protocols led to their early  
> adoption
> in production environments, to the point that to some extent, the
> current world?s economy depends on them.
>
> While many textbooks and articles have created the myth that the
> Internet protocols were designed for warfare environments, the top  
> level
> goal for the DARPA Internet Program was the sharing of large service
> machines on the ARPANET. As a result, many protocol specifications  
> focus
> only on the operational aspects of the protocols they specify, and
> overlook their security implications.
>
> While the Internet technology evolved since it early inception, the
> Internet?s building blocks are basically the same core protocols  
> adopted
> by the ARPANET more than two decades ago.
>
> During the last twenty years, many vulnerabilities have been  
> identified
> in the TCP/IP stacks of a number of systems. Some of them were based  
> on
> flaws in some protocol implementations, affecting only a reduced  
> number
> of systems, while others were based in flaws in the protocols
> themselves, affecting virtually every existing implementation. Even in
> the last couple of years, researchers were still working on security
> problems in the core protocols.
>
> The discovery of vulnerabilities in the TCP/IP protocol suite usually
> led to reports being published by a number of CSIRTs (Computer  
> Security
> Incident Response Teams) and vendors, which helped to raise awareness
> about the threats and the best mitigations known at the time the  
> reports
> were published. Unfortunately, this also led to the documentation of  
> the
> discovered protocol vulnerabilities being spread among a large  
> number of
> documents, which are sometimes difficult to identify.
>
> For some reason, much of the effort of the security community on the
> Internet protocols did not result in official documents (RFCs) being
> issued by the IETF (Internet Engineering Task Force). This basically  
> led
> to a situation in which ?known? security problems have not always
> been addressed by all vendors. In addition, in many cases vendors have
> implemented quick ?fixes? to the identified vulnerabilities without a
> careful analysis of their effectiveness and their impact on
> interoperability.
>
> Producing a secure TCP/IP implementation nowadays is a very difficult
> task, in part because of the lack of a single document that serves  
> as a
> security roadmap for the protocols. Implementers are faced with the  
> hard
> task of identifying relevant documentation and differentiating between
> that which provides correct advice, and that which provides misleading
> advice based on inaccurate or wrong assumptions.
>
>
> There is a clear need for a companion document to the IETF
> specifications that discusses the security aspects and implications of
> the protocols, identifies the existing vulnerabilities, discusses the
> possible countermeasures, and analyses their respective effectiveness.
>
> This document is the result of a security assessment of the IETF
> specifications of the Transmission Control Protocol (TCP), from a
> security point of view. Possible threats are identified and, where
> possible, countermeasures are proposed. Additionally, many
> implementation flaws that have led to security vulnerabilities have  
> been
> referenced in the hope that future implementations will not incur the
> same problems.
>
> This document does not aim to be the final word on the security  
> aspects
> of TCP. On the contrary, it aims to raise awareness about a number of
> TCP vulnerabilities that have been faced in the past, those that are
> currently being faced, and some of those that we may still
> have to deal with in the future.
>
> Feedback from the community is more than encouraged to help this
> document be as accurate as possible and to keep it updated as new
> vulnerabilities are discovered.
> - ---- cut here ----
>
> The document is available at CPNI's web site:
> http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-TCP.aspx
>
> Additionally, I have posted a copy of the document on my personal web
> site: http://www.gont.com.ar
>
> Any comments will be more than welcome.
>
> Kind regards,
> - --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBCAAGBQJJlKTFAAoJEJbuqe/Qdv/xbBgH/0CRAO7VttW8IlSs6ocKl8Xi
> pQkuUZOKAZrkok0T4GOkRPBmIv+5K8ZQT8hBBdTL6TOdZ+LOIHvmwpOMRqosijbm
> +KXTuHYws/zVbReCZXdYFhHfxRUn75G9s0mafNRpkiQV07hoHpD38UcGJYUnQXNy
> 7uuV3HXJDENgE0L8pAK8HhgNKlX3clcV3sBJEzHMsvVVT1Jh1XsS+krAD7JguN95
> nhjOTcTp1Ggq+F6wqucm9Kf193O78REEz/FGeaoPGSDfzD0EBGg4IG1qu6Bo3e++
> ALLEOhARQJ0l12dC+84N0/mrGBSe45pUbMddT6xZzDXa6INcmTE6dc1VSQL8EAo=
> =IVlY
> -----END PGP SIGNATURE-----

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Feb 2009 20:18:19 -0500

Marshall Eubanks wrote:
> wants the IETF (or some other body) to produce a "companion document to
> the IETF specifications that discusses the security aspects and
> implications of the protocols, identifies the existing vulnerabilities,
> discusses the possible countermeasures, and analyses their respective
> effectiveness."

It's difficult to imagine that these things could be adequately captured
in a static document, for TCP or any other protocol, because new threats
and countermeasures continue to be identified decades after the base
protocol is well-settled.  Maybe something like an expanded version of
the RFC Editor's errata pages would be more appropriate?

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 13 Feb 2009 19:27:16 -0800

> the RFC Editor's errata pages would be more appropriate?

One might imagine an informational document which was routinely
obsoleted by future iterations. Keeping it tractable is a product of
necessarily limiting the scope.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Feb 2009 03:12:41 -0500

> necessarily limiting the scope.

I fear that our RFC approval and publication process has become so
onerous that it imposes a significant barrier for dissemination of such
information.

Keith

---

From: Lars Eggert <[email-masked]>
Date: Sat, 14 Feb 2009 12:01:19 +0200

Hi,

> their respective effectiveness."

during the discussions around the TCP implementation deficiencies  
publicized by the Outpost24 last fall, we discussed with CERT-FI and  
others in that community that the IETF would offer to be the venue for  
publishing such a document. The goal would be to document techniques  
that stack vendors are employing to harden their stacks. They asked us  
to wait until vendors had a chance to deploy patches to the latest  
round of vulnerabilities, and we haven't heard back from them since  
late last year. (Which reminds me to shoot them an email.)

I believe such a document would be fully in scope for TCPM, but  
obviously the involvement of the stack vendors is critical to ensure  
this is a document that has practical relevance.

Lars

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Feb 2009 13:23:08 +0200

Keith, Joel,

>> necessarily limiting the scope.
I am in favor of publishing things like these in informational RFCs. And 
no, we should not shoot for completeness, for obvious reasons.

Jari

---

From: TSG <[email-masked]>
Date: Sat, 14 Feb 2009 07:26:59 -0800

Joel Jaeggli wrote:
> obsoleted by future iterations. 

Unfortunately this isnt new information - the liabilities of IP have 
been well identified and understood for years like the BGP4 flap as well.

What the IETF still seems to fail to grasp is that it is responsible for 
its actions so its not taking security and the ability to produce 
reliable evidence of anything over a network transport are key factors 
and need to be built into any IETF endorsement that is issued in the 
form of a standard or standards-track effort.

I also would suggest that the IETF be willing to support other protocols 
besides IP based - hell XNS was way more secure than IP is by its very 
design.

Its not that TCP/IP is bad - its just that it wasnt designed as an 
evidentiary-grade data transport and that is nowadays a real issue.

> Keeping it tractable is a product of
I dont think so.  Building an analysis scope which is defined to meet 
the evidence needs today would address this requirement and only need to 
be updated periodically to meet those changing evidence models.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 21 Feb 2009 22:00:38 -0300

2009/2/14 Lars Eggert [email-masked]

> publicized by the Outpost24 last fall, we discussed with CERT-FI and others
> in that community that the IETF would offer to be the venue for publishing
> such a document.
>

It has always been in our mind to bring the results of our project
("Security Assessment of the Transmission Control Protocol (TCP)" to the
IETF.

We have already done this for another document ("Security Assessment of the
Internet Protocol") that was part of the same project. In July 2008, the UK
CPNI  released that document, and the next week after the release we publish
an IETF I-D version of the same document.

We have done the same thing with this new TCP document. I have already
submitted an IETF I-D version of the document, in the hope that the IETF
will work on this stuff. The document is entitled "Security Assessment of
the Transmission Control Protocol (TCP)", and the filename is
draft-gont-tcp-security-00.txt.

> The goal would be to document techniques that stack vendors are employing
> to harden their stacks.
>

This is sort of what we have done. However, not only have we documented
techniques that stack vendors have implemented to harden their stack, but
have also performed an assessment of the IETF specs themselves, and have
also proposed mitigation techniques for known issues (on which there had
never been advise on how to deal with them). We had a preliminar version of
our paper sometime in 2006, but then it went through a throrough review
process. That's why it ended up being published this
month.

> They asked us to wait until vendors had a chance to deploy patches to the
> latest round of vulnerabilities, and we haven't heard back from them since

I have been in the loop (for some time, at least), and have also been in
very close contact with a number of vendors. For instance, an excerpt of our
large TCP document (that discussed the specific issues that had been
publicized by Outpost24) was made available to vendors in the hope of
providing vendors with advice on how to deal with those issues.
I don't really know how the "patching" work is going on... but at least a
few months ago, I would say that many (most?) vendors were not really
working in patches. And to some extent it might make sense, as some of the
issues have more to do with having the applications controlling the amount
of resources that they are using, than with TCP trying to limit the amount
of resources per app at the TCP level.

> I believe such a document would be fully in scope for TCPM,
>

I believe both tcpm and opsec could be possible candidates for this
document.

> but obviously the involvement of the stack vendors is critical to ensure

To the extent that was possible, vendors *have* been involved in the review
process of our TCP security document. However, at times it gets hard to get
vendors involved in the IETF process. For the most part, they feel they are
not heard, and that participating in the IETF has a low ROI (Return Of
Investment).

We have had some experience in this arena with the document "ICMP attacks
against TCP" that we are still pursuing within tcpm. I was able to get
involved from the following "vendors":

* NetBSD
* OpenBSD
* FreeBSD
* Linux
* Cisco
* Sun
* HP
* ExtremeNetworks (IIRC)
* ... and others

but we nitpicked on the document for ages. Virtually everybody in the vendor
community couldn't believe that we were having such discussions about that
stuff. So at some point most people argued that "they had already voiced
their opinion, but they felt that it didn't made a difference". After all,
they had already implemented the stuff discussed in the document (and so had
others), so they really didn't have much of a reason to get involved in the
process.

I'd be glad to discuss a plan to pursue this work within the IETF.

Thanks!

Kind regards,
--
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1