RFC 6274
Security Assessment of the Internet Protocol Version 4
Internet Engineering Task Force (IETF) F. Gont Request for Comments: 6274 UK CPNI Category: Informational July 2011 ISSN: 2070-1721 Security Assessment of the Internet Protocol Version 4Abstract
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 This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6274. Copyright Notice 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 .........................................................4 1.1. Introduction ...............................................4 1.2. Scope of This Document .....................................6 1.3. Organization of This Document ..............................7 2. The Internet Protocol ...........................................7 3. Internet Protocol Header Fields .................................8 3.1. Version ....................................................9 3.2. IHL (Internet Header Length) ..............................10 3.3. Type of Service (TOS) .....................................10 3.3.1. Original Interpretation ............................10 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 3.5. Identification (ID) .......................................15 3.5.1. Some Workarounds Implemented by the Industry .......16 3.5.2. Possible Security Improvements .....................17 3.5.2.1. Connection-Oriented Transport Protocols ...17 3.5.2.2. Connectionless Transport Protocols ........18 3.6. Flags .....................................................19 3.7. Fragment Offset ...........................................21 3.8. Time to Live (TTL) ........................................22 3.8.1. Fingerprinting the Operating System in Use by the Source Host .................................24 3.8.2. Fingerprinting the Physical Device from which the Packets Originate ........................24 3.8.3. Mapping the Network Topology .......................24 3.8.4. Locating the Source Host in the Network Topology ...25 3.8.5. Evading Network Intrusion Detection Systems ........26 3.8.6. Improving the Security of Applications That Make Use of the Internet Protocol (IP) .............27 3.8.7. Limiting Spread ....................................28 3.9. Protocol ..................................................28 3.10. Header Checksum ..........................................28 3.11. Source Address ...........................................29 3.12. Destination Address ......................................30 3.13. Options ..................................................30 3.13.1. General Issues with IP Options ....................31 3.13.1.1. Processing Requirements ..................31 3.13.1.2. Processing of the Options by the Upper-Layer Protocol .....................32 3.13.1.3. General Sanity Checks on IP Options ......32 3.13.2. Issues with Specific Options ......................34 3.13.2.1. End of Option List (Type=0) ..............34 3.13.2.2. No Operation (Type=1) ....................34
3.13.2.3. Loose Source and Record Route
(LSRR) (Type=131) ........................34
3.13.2.4. Strict Source and Record Route
(SSRR) (Type=137) ........................37
3.13.2.5. Record Route (Type=7) ....................39
3.13.2.6. Stream Identifier (Type=136) .............40
3.13.2.7. Internet Timestamp (Type=68) .............40
3.13.2.8. Router Alert (Type=148) ..................43
3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
3.13.2.11. Traceroute (Type=82) ....................44
3.13.2.12. Department of Defense (DoD)
Basic Security Option (Type=130) ........45
3.13.2.13. DoD Extended Security Option
(Type=133) ..............................46
3.13.2.14. Commercial IP Security Option
(CIPSO) (Type=134) ......................47
3.13.2.15. Sender Directed
Multi-Destination Delivery (Type=149) ...47
4. Internet Protocol Mechanisms ...................................48
4.1. Fragment Reassembly .......................................48
4.1.1. Security Implications of Fragment Reassembly .......49
4.1.1.1. Problems Related to Memory Allocation .....49
4.1.1.2. Problems That Arise from the
Length of the IP Identification Field .....51
4.1.1.3. Problems That Arise from the
Complexity of the Reassembly Algorithm ....52
4.1.1.4. Problems That Arise from the
Ambiguity of the Reassembly Process .......52
4.1.1.5. Problems That Arise from the Size
of the IP Fragments .......................53
4.1.2. Possible Security Improvements .....................53
4.1.2.1. Memory Allocation for Fragment
Reassembly ................................53
4.1.2.2. Flushing the Fragment Buffer ..............54
4.1.2.3. A More Selective Fragment Buffer
Flushing Strategy .........................55
4.1.2.4. Reducing the Fragment Timeout .............57
4.1.2.5. Countermeasure for Some NIDS
Evasion Techniques ........................58
4.1.2.6. Countermeasure for Firewall-Rules
Bypassing .................................58
4.2. Forwarding ................................................58
4.2.1. Precedence-Ordered Queue Service ...................58
4.2.2. Weak Type of Service ...............................59
4.2.3. Impact of Address Resolution on Buffer Management ..60
4.2.4. Dropping Packets ...................................61
4.3. Addressing ................................................61
4.3.1. Unreachable Addresses ..............................61
4.3.2. Private Address Space ..............................61
4.3.3. Former Class D Addresses (224/4 Address Block) .....62
4.3.4. Former Class E Addresses (240/4 Address Block) .....62
4.3.5. Broadcast/Multicast Addresses and
Connection-Oriented Protocols ......................62
4.3.6. Broadcast and Network Addresses ....................63
4.3.7. Special Internet Addresses .........................63
5. Security Considerations ........................................65
6. Acknowledgements ...............................................65
7. References .....................................................66
7.1. Normative References ......................................66
7.2. Informative References ....................................68
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
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 Defense Advanced Research Projects Agency (DARPA)
Internet Program was the sharing of large service machines on the
ARPANET [Clark1988]. 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 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 [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. 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 protocol flaws without a careful analysis of their effectiveness and their impact on interoperability [Silbersack2005]. The lack of adoption of these fixes by the IETF means that any system built in the future according to the official TCP/IP specifications will reincarnate security flaws that have already hit our communication systems in the past. Nowadays, producing a secure TCP/IP implementation 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 advisory and that which provides misleading advisory based on inaccurate or wrong assumptions. There is a clear need for a companion document to the IETF specifications; one that discusses the security aspects and implications of the protocols, identifies the possible threats, discusses the possible countermeasures, and analyzes their respective effectiveness. This document is the result of an assessment of the IETF 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 found to be vulnerable to one of these attacks, administrators must resort to mitigating them by packet filtering. Additionally, this document analyzes the security implications from changes in the operational environment since the Internet Protocol was designed. For example, it analyzes how the Internet Protocol could be exploited to evade Network Intrusion Detection Systems (NIDSs) or to circumvent firewalls. 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 document be as accurate as possible and to keep it updated as new threats are discovered. This document is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] released by the UK Centre for the Protection of National Infrastructure (CPNI), available at http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].1.2. Scope of This Document
While there are a number of protocols that affect the way in which IP systems operate, this document focuses only on the specifications of the Internet Protocol (IP). For example, routing and bootstrapping protocols are considered out of the scope of this project. The following IETF RFCs were selected as the primary sources for the assessment as part of this work:
o RFC 791, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" (45 pages). o RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages). o RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages). o RFC 950, "Internet Standard Subnetting Procedure" (18 pages) o RFC 1112, "Host Extensions for IP Multicasting" (17 pages) o RFC 1122, "Requirements for Internet Hosts -- Communication Layers" (116 pages). o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages). o RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" (20 pages). o RFC 2475, "An Architecture for Differentiated Services" (36 pages). o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP" (63 pages). o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan" (27 pages).1.3. Organization of This Document
This document is basically organized in two parts: "Internet Protocol header fields" and "Internet Protocol mechanisms". The former contains an analysis of each of the fields of the Internet Protocol header, identifies their security implications, and discusses possible countermeasures for the identified threats. The latter contains an analysis of the security implications of the mechanisms implemented by the Internet Protocol.2. The Internet Protocol
The Internet Protocol (IP) provides a basic data transfer function for passing data blocks called "datagrams" from a source host to a destination host, across the possible intervening networks. Additionally, it provides some functions that are useful for the interconnection of heterogeneous networks, such as fragmentation and reassembly.
The "datagram" has a number of characteristics that makes it convenient for interconnecting systems [Clark1988]: o It eliminates the need of connection state within the network, which improves the survivability characteristics of the network. o It provides a basic service of data transport that can be used as a building block for other transport services (reliable data transport services, etc.). o It represents the minimum network service assumption, which enables IP to be run over virtually any network technology.
(page 8 continued on part 2)
