Fwd: Security Assessment of the Transmission Control Protocol (TCP)
Marshall Eubanks <tme@multicasttech.com> Fri, 13 February 2009 22:25 UTC
Return-Path: <tme@multicasttech.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DD328C144 for <ietf@core3.amsl.com>; Fri, 13 Feb 2009 14:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.199
X-Spam-Level:
X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpAYDSNihJPk for <ietf@core3.amsl.com>; Fri, 13 Feb 2009 14:25:39 -0800 (PST)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 3F51E28C116 for <ietf@ietf.org>; Fri, 13 Feb 2009 14:25:39 -0800 (PST)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14635998 for ietf@ietf.org; Fri, 13 Feb 2009 17:24:29 -0500
Message-Id: <0B030ADA-F621-4FDF-9CAF-23A27C16E26B@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: IETF discussion list <ietf@ietf.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Fwd: Security Assessment of the Transmission Control Protocol (TCP)
Date: Fri, 13 Feb 2009 17:25:45 -0500
References: <4994A4EB.5030607@gmail.com>
X-Mailer: Apple Mail (2.930.3)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 22:25:40 -0000
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 <fernando.gont@gmail.com> > Date: February 12, 2009 5:38:35 PM EST > To: bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk > 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: fernando@gont.com.ar || fgont@acm.org > 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-----
- Fwd: Security Assessment of the Transmission Cont… Marshall Eubanks
- Re: Fwd: Security Assessment of the Transmission … Keith Moore
- Re: Fwd: Security Assessment of the Transmission … Joel Jaeggli
- Re: Fwd: Security Assessment of the Transmission … Keith Moore
- Re: Security Assessment of the Transmission Contr… Lars Eggert
- Re: Fwd: Security Assessment of the Transmission … Jari Arkko
- Re: Fwd: Security Assessment of the Transmission … TSG
- Re: Security Assessment of the Transmission Contr… Fernando Gont
- Security Assessment of the Transmission Control P… Fernando Gont