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-TC... 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) iQEcBAEBCAAGBQJJlLWeAAoJEJbuqe/Qdv/xRBMIANfq3pfTFauzFacTyjzzdu7+ g0XP76J6qThEjUZzzjEtSAS0hi9u+rODEp5Cujk0y/QK0Wnyoc6ZHOn91q0cuOtA UC+YqfTrW72bJL0+JEHxYSRkASEwtfULyfnyzx3ZMoiN/gMTG/PAQ4WDvNu5ORhf nmbTiRkpdc3S6FmsMnxzwbNJrklAwGuJKIIOmGTGwrI4D1G9lOc0A6xqArIvkwma L6a2YIGOZBePpI8yj4baKk1qvXH9gk+oH5bjJDXyXZNWOIFeM5lDeJaiEQHWCbF+ k+P/plO5TImzQtmKqGGVNoRJa4scw9ZLxYz2zLkJ6dZtUzGriyi0RwvPj1ZKQR4= =sV1Y -----END PGP SIGNATURE-----
From: Fernando Gont <fernando@gont.com.ar>
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.
This in itself has become an oft-repeated canard. It is true that an important early rationalization for funding DARPA network research was to allow researchers at different institutions to use expensive (tens of millions of dollars) supercomputers from afar and, thus, not have to buy every worthy researcher their own O($100M) supercomputer center. However, an advantage in choosing a packet protocol (eventually IP) rather than a virtual circuit protocol as was popular around the time of its inception (e.g., IBM's SNA) was that packets could be re-routed around damage, transparently to virtual circuits built on top of the underlying packet protocol (e.g., TCP.) Routing of packets could be done dynamically on a per-packet basis if needed. And it was observed that routing around damage could at least in theory have utility in a situation where circuit facilities were being damaged in warfare so long as some route between two points remained. So these two goals are not mutually exclusive by any means. Merly providing remote access to super-computer facilities could have been accomplished with existing communication (e.g., phones and modems) and networks (e.g., SNA.) There was no need to fund the R&D of a new suite of protocols. Further:
As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications.
This is a non-sequitar and not a result at all. Neither goal implied security, only integrity. This was not an oversight, security was, and to a great extent still is, thought to be a higher-level function than packetizing and packet routing, with a few exceptions where a potential security flaw truly lies in the protocol (e.g., poor choice of packet sequence numbers.)
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.
Two decades is twenty years which takes me back to 1988. Three decades would be more accurate, e.g., the great NCP changeover which I think was 1978. I suppose arguably three decades is "more than two decades".
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).
(for some reason?) To the best of my knowledge the reason is quite simple: That is not what RFCs are used for tho occasionally some summary of the state of the art appears in an RFC. The rest seems reasonably stated. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Barry Shein wrote:
And it was observed that routing around damage could at least in theory have utility in a situation where circuit facilities were being damaged in warfare so long as some route between two points remained.
So these two goals are not mutually exclusive by any means.
The point of the text was to point out that "operating in warfare environments" was not the top level goal. The recent John Day¿s "Patterns in Network Architecture" provides more insights in this aspec.
As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications.
This is a non-sequitar and not a result at all. Neither goal implied security, only integrity.
This was not an oversight, security was, and to a great extent still is, thought to be a higher-level function than packetizing and packet routing, with a few exceptions where a potential security flaw truly lies in the protocol (e.g., poor choice of packet sequence numbers.)
I don't really understand what you mean. Attacks such as syn-floods and others are clearly issues that lie in the protocol design. And while it is understood that security was not a goal two or three decades ago, one would expect that it should be a goal nowadays, and that the specs should have been updated accordingly.
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).
(for some reason?)
To the best of my knowledge the reason is quite simple: That is not what RFCs are used for tho occasionally some summary of the state of the art appears in an RFC.
Not sure what you mean. Only *few* years ago there was some work published within the IETF about well-known issues such as, e.g., syn-floods. Think about any TCP/IP-based security issue, and most likely you will not be able to find any information about it within the RFC series. Talk with anybody that works day-to-day implementing the TCP/IP protocols, and most likely the comment you'll get about the current situation is a PITA. A few years ago I published an I-D on ICMP attacks against TCP (draft-ietf-tcpm-icmp-attacks, which is close to be published as an RFC, I believe). Known issues... but the counter-measures were not clear. The reult? Vulnerability advisories from many vendors, including Cisco, Microsoft, and the security-concious OpenBSD. I don't think it should be that hard to implement the protocols in a security-conscious way from the IETF specs. And that is the area in which this CPNI document (and the preivous "Security Assessment of the Internet Protocol") tries to help. 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
participants (2)
-
Barry Shein -
Fernando Gont