--- 1/draft-ietf-opsec-ip-security-05.txt 2011-01-27 08:28:48.000000000 +0100 +++ 2/draft-ietf-opsec-ip-security-06.txt 2011-01-27 08:28:49.000000000 +0100 @@ -1,20 +1,20 @@ Operational Security Capabilities F. Gont for IP Network Infrastructure UK CPNI -(opsec) December 16, 2010 +(opsec) January 27, 2011 Internet-Draft Intended status: Informational -Expires: June 19, 2011 +Expires: July 31, 2011 Security Assessment of the Internet Protocol version 4 - draft-ietf-opsec-ip-security-05.txt + draft-ietf-opsec-ip-security-06.txt Abstract This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). Status of this Memo @@ -25,43 +25,43 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 19, 2011. + This Internet-Draft will expire on July 31, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 - 1.3. Organization of this document . . . . . . . . . . . . . . 7 + 1.3. Organization of this document . . . . . . . . . . . . . . 8 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8 3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 8 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10 3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11 3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12 3.3.2.1. Differentiated Services field . . . . . . . . . . 12 3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 14 @@ -147,27 +147,28 @@ 4.3.5. Broadcast/Multicast addresses, and Connection-Oriented Protocols . . . . . . . . . . . . 62 4.3.6. Broadcast and network addresses . . . . . . . . . . . 62 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 67 Appendix A. Changes from previous versions of the draft . . . . . 75 - A.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 - A.2. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 - A.3. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 - A.4. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 - A.5. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76 - A.6. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76 - A.7. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76 + A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 75 + A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 76 + A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 + A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 + A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 + A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76 + A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76 + A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 1. Preface 1.1. Introduction The TCP/IP protocols were conceived in an environment that was quite different from the hostile environment in which they currently operate. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some @@ -182,22 +183,22 @@ While the Internet technology evolved since its 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 on flaws in the protocols themselves, affecting virtually every existing implementation [Bellovin1989]. Even in the last couple of years, researchers were - still working on security problems in the core protocols - [I-D.ietf-tcpm-icmp-attacks] [Watson2004] [NISCC2004] [NISCC2005]. + still working on security problems in the core protocols [RFC5927] + [Watson2004] [NISCC2004] [NISCC2005]. The discovery of vulnerabilities in the TCP/IP protocols 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. @@ -232,20 +233,33 @@ specifications of the Internet Protocol version 4 (IPv4), from a security point of view. Possible threats were identified and, where possible, countermeasures were 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. Furthermore, this document does not limit itself to performing a security assessment of the relevant IETF specifications, but also provides an assessment of common implementation strategies found in the real world. + Many IP implementations have also been subject of the so-called + "packet-of-death" vulnerabilities, in which a single specially- + crafted packet causes the IP implementation to crash or otherwise + misbehave. In most cases, the attack packet is simply malformed; in + other cases, the attack packet is well-formed, but exercises a little + used path through the IP stack. Well-designed IP implementations + should protect against these attacks, and therefore this document + describes a number of sanity checks that are expected to prevent most + of the aforementioned "packet-of-death" attack vectors. We note that + if an IP implementation is is found vulnerable to one of these + attacks, administrators must resort to mitigating them by packet + filtering. + This document does not aim to be the final word on the security of the Internet Protocol (IP). On the contrary, it aims to raise awareness about many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the Internet Protocol (IP), but also provides insights about the security aspects of the Internet Protocol that may be of help to the Internet operations community. Feedback from the community is more than encouraged to help this @@ -1209,21 +1223,21 @@ As all packets sent by systems that are not in the same network segment will have a TTL smaller than 255, those packets will not pass the check enforced by these two cooperating peers. This check reduces the set of systems that may perform attacks against the protected application (BGP in this case), thus mitigating the attack vectors described in [NISCC2004] and [Watson2004]. This same check is enforced for related ICMP error messages, with the intent of mitigating the attack vectors described in - [NISCC2005] and [I-D.ietf-tcpm-icmp-attacks]. + [NISCC2005] and [RFC5927]. The TTL field can be used in a similar way in scenarios in which the cooperating systems are not in the same network segment (i.e., multi- hop peering). In that case, the following check could be enforced: TTL >= 255 - DeltaHops This means that the set of hosts from which packets will be accepted for the protected application will be reduced to those that are no more than DeltaHops away. While for obvious reasons the level of @@ -1308,22 +1322,21 @@ on ingress and egress filtering. [RFC2827] and [RFC3704] discuss ingress filtering. [GIAC2000] discusses egress filtering. [SpooferProject] measures the Internet's susceptibility to forged Source Address IP packets. Even when the obvious field on which to perform checks for ingress/egress filtering is the Source Address and Destination Address fields of the IP header, there are other occurrences of IP addresses on which the same type of checks should be performed. One example is the IP addresses contained in the payload of ICMP - error messages, as discussed in [I-D.ietf-tcpm-icmp-attacks] and - [Gont2006]. + error messages, as discussed in [RFC5927] and [Gont2006]. There are a number of sanity checks that should be performed on the Source Address of an IP datagram. Details can be found in Section 4.2 ("Addressing"). Additionally, there exist freely available tools that allow administrators to monitor which IP addresses are used with which MAC addresses [LBNL2006]. This functionality is also included in many Network Intrusion Detection Systems (NIDS). @@ -3011,24 +3024,24 @@ Protocol (IP) and a number of implementation strategies that help to mitigate a number of vulnerabilities found in the protocol during the last 25 years or so. 6. Acknowledgements The author wishes to thank Alfred Hoenes for providing very thorough reviews of earlier versions of this document, thus leading to numerous improvements. - The author would like to thank Jari Arkko, Stewart Bryant, Adrian - Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and Andrew - Yourtchenko for providing valuable comments on earlier versions of - this document. + The author would like to thank Jari Arkko, Ron Bonica, Stewart + Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and + Andrew Yourtchenko for providing valuable comments on earlier + versions of this document. This document was written by Fernando Gont on behalf of the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure), and is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008. The author would like to thank Randall Atkinson, John Day, Juan Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka Savola, and Christos Zoulas for providing valuable comments on earlier versions of [CPNI2008], on which this document is based. @@ -3225,21 +3238,21 @@ Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work in progress , 1992. [CIPSOWG1994] CIPSOWG, "Commercial Internet Protocol Security Option (CIPSO) Working Group", http://www.ietf.org/proceedings/ 94jul/charters/cipso-charter.html, 1994. [CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", - http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. + 2008, . [Cerf1974] Cerf, V. and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications Vol. 22, No. 5, May 1974, pp. 637-648, 1974. [Cisco2003] Cisco, "Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 packet", http://www.cisco.com/en/US/ @@ -3288,25 +3301,20 @@ [Humble1998] Humble, "Nestea exploit", http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 1998. [I-D.ietf-intarea-router-alert-considerations] Faucheur, F., "IP Router Alert Considerations and Usage", draft-ietf-intarea-router-alert-considerations-02 (work in progress), October 2010. - [I-D.ietf-tcpm-icmp-attacks] - Gont, F., "ICMP attacks against TCP", - draft-ietf-tcpm-icmp-attacks-12 (work in progress), - March 2010. - [I-D.templin-mtuassurance] Templin, F., "Requirements for IP-in-IP Tunnel MTU Assurance", draft-templin-mtuassurance-02 (work in progress), October 2006. [IANA2006a] Ether Types, "http://www.iana.org/assignments/ethernet-numbers". [IANA2006b] @@ -3445,20 +3453,22 @@ Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009. [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- Nodes", RFC 5670, November 2009. [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009. + [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. + [SELinux2008] Security Enhanced Linux, "http://www.nsa.gov/selinux/". [Sanfilippo1998a] Sanfilippo, S., "about the ip header id", Post to Bugtraq mailing-list, Mon Dec 14 1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998. [Sanfilippo1998b] Sanfilippo, S., "Idle scan", Post to Bugtraq mailing- @@ -3523,61 +3533,64 @@ daemon9, route, and infinity, "IP-spoofing Demystified (Trust-Relationship Exploitation)", Phrack Magazine, Volume Seven, Issue Forty-Eight, File 14 of 18 http:// www.phrack.org/issues.html?issue=48&id=14&mode=txt, 1988. Appendix A. Changes from previous versions of the draft This whole appendix should be removed by the RFC Editor before publishing this document as an RFC. -A.1. Changes from draft-ietf-opsec-ip-security-03 +A.1. Changes from draft-ietf-opsec-ip-security-05 + o Addresses IESG review comments by Tim Polk (?). + +A.2. Changes from draft-ietf-opsec-ip-security-04 o Addresses IESG review comments by Jari Arkko, Stewart Bryant, Adrian Farrel, Peter Saint-Andre, and Sean Turner. -A.2. Changes from draft-ietf-opsec-ip-security-03 +A.3. Changes from draft-ietf-opsec-ip-security-03 o Addresses feedback received off-list by Warren Kumari. -A.3. Changes from draft-ietf-opsec-ip-security-02 +A.4. Changes from draft-ietf-opsec-ip-security-02 o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Miscellaneous edits (centers expressions, fills missing graphics with ASCII-art, etc.) -A.4. Changes from draft-ietf-opsec-ip-security-01 +A.5. Changes from draft-ietf-opsec-ip-security-01 o Addresses rest of the feedback received from Andrew Yourtchenko (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Addresses feedback submitted by Joel Jaeggli (off-list) o Addresses feedback submitted (off-list) by Bruno Rohee. o Miscellaneous edits (centers expressions, fills missing graphics with ASCII-art, etc.) -A.5. Changes from draft-ietf-opsec-ip-security-00 +A.6. Changes from draft-ietf-opsec-ip-security-00 o Addresses part of the feedback received from Andrew Yourtchenko (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) -A.6. Changes from draft-gont-opsec-ip-security-01 +A.7. Changes from draft-gont-opsec-ip-security-01 o Draft resubmitted as draft-ietf, as a result of wg consensus on adopting the document as an opsec wg item. -A.7. Changes from draft-gont-opsec-ip-security-00 +A.8. Changes from draft-gont-opsec-ip-security-00 o Fixed author's affiliation. o Added Figure 6. o Fixed a few typos. o (no technical changes) Author's Address