diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6274.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6274.txt')
| -rw-r--r-- | doc/rfc/rfc6274.txt | 4203 |
1 files changed, 4203 insertions, 0 deletions
diff --git a/doc/rfc/rfc6274.txt b/doc/rfc/rfc6274.txt new file mode 100644 index 0000000..fac11bf --- /dev/null +++ b/doc/rfc/rfc6274.txt @@ -0,0 +1,4203 @@ + + + + + + +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 4 + +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 + + 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. + + + + + +Gont Informational [Page 1] + +RFC 6274 IPv4 Security Assessment July 2011 + + +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 + + + + +Gont Informational [Page 2] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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 + + + +Gont Informational [Page 3] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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 + + + +Gont Informational [Page 4] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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 + + + +Gont Informational [Page 5] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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: + + + + + +Gont Informational [Page 6] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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. + + + + + +Gont Informational [Page 7] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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. + +3. Internet Protocol Header Fields + + The IETF specifications of the Internet Protocol define the syntax of + the protocol header, along with the semantics of each of its fields. + Figure 1 shows the format of an IP datagram, as specified in + [RFC0791]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Version| IHL |Type of Service| Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification |Flags| Fragment Offset | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time to Live | Protocol | Header Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | [ Options ] | [ Padding ] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Internet Protocol Header Format + + Even though the minimum IP header size is 20 bytes, an IP module + might be handed an (illegitimate) "datagram" of less than 20 bytes. + Therefore, before doing any processing of the IP header fields, the + following check should be performed by the IP module on the packets + handed by the link layer: + + LinkLayer.PayloadSize >= 20 + + where LinkLayer.PayloadSize is the length (in octets) of the datagram + passed from the link layer to the IP layer. + + + +Gont Informational [Page 8] + +RFC 6274 IPv4 Security Assessment July 2011 + + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented + reflecting the packet drop). + + The following subsections contain further sanity checks that should + be performed on IP packets. + +3.1. Version + + This is a 4-bit field that indicates the version of the Internet + Protocol (IP), and thus the syntax of the packet. For IPv4, this + field must be 4. + + When a link-layer protocol de-multiplexes a packet to an Internet + module, it does so based on a Protocol Type field in the data-link + packet header. + + In theory, different versions of IP could coexist on a network by + using the same Protocol Type at the link layer, but a different value + in the Version field of the IP header. Thus, a single IP module + could handle all versions of the Internet Protocol, differentiating + them by means of this field. + + However, in practice different versions of IP are identified by a + different Protocol Type (e.g., EtherType in the case of Ethernet) + number in the link-layer protocol header. For example, IPv4 + datagrams are encapsulated in Ethernet frames using an EtherType of + 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames + using an EtherType of 0x86DD [IANA_ET]. + + Therefore, if an IPv4 module receives a packet, the Version field + must be checked to be 4. If this check fails, the packet should be + silently dropped, and this event should be logged (e.g., a counter + could be incremented reflecting the packet drop). If an + implementation does not perform this check, an attacker could use a + different value for the Version field, possibly evading NIDSs that + decide which pattern-matching rules to apply based on the Version + field. + + If the link-layer protocol employs a specific "Protocol Type" value + for encapsulating IPv4 packets (e.g., as is the case of Ethernet), a + node should check that IPv4 packets are de-multiplexed to the IPv4 + module when such value was used for the Protocol Type field of the + link-layer protocol. If a packet does not pass this check, it should + be silently dropped. + + + + + + +Gont Informational [Page 9] + +RFC 6274 IPv4 Security Assessment July 2011 + + + An attacker could encapsulate IPv4 packets using other link-layer + "Protocol Type" values to try to subvert link-layer Access Control + Lists (ACLs) and/or for tampering with NIDSs. + +3.2. IHL (Internet Header Length) + + The IHL (Internet Header Length) field indicates the length of the + Internet header in 32-bit words (4 bytes). The following paragraphs + describe a number of sanity checks to be performed on the IHL field, + such that possible packet-of-death vulnerabilities are avoided. + + As the minimum datagram size is 20 bytes, the minimum legal value for + this field is 5. Therefore, the following check should be enforced: + + IHL >= 5 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented + reflecting the packet drop). + + For obvious reasons, the Internet header cannot be larger than the + whole Internet datagram of which it is part. Therefore, the + following check should be enforced: + + IHL * 4 <= Total Length + + This needs to refer to the size of the datagram as specified by + the sender in the Total Length field, since link layers might have + added some padding (see Section 3.4). + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented + reflecting the packet drop). + + The above check allows for Internet datagrams with no data bytes in + the payload that, while nonsensical for virtually every protocol that + runs over IP, are still legal. + +3.3. Type of Service (TOS) + +3.3.1. Original Interpretation + + Figure 2 shows the original syntax of the Type of Service field, as + defined by RFC 791 [RFC0791] and updated by RFC 1349 [RFC1349]. This + definition has been superseded long ago (see Sections 3.3.2.1 and + 3.3.2.2), but it is still assumed by some deployed implementations. + + + + + +Gont Informational [Page 10] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | PRECEDENCE | D | T | R | C | 0 | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + Figure 2: Type of Service Field (Original Interpretation) + + +----------+----------------------------------------------+ + | Bits 0-2 | Precedence | + +----------+----------------------------------------------+ + | Bit 3 | 0 = Normal Delay, 1 = Low Delay | + +----------+----------------------------------------------+ + | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | + +----------+----------------------------------------------+ + | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | + +----------+----------------------------------------------+ + | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | + +----------+----------------------------------------------+ + | Bits 7 | Reserved for Future Use (must be zero) | + +----------+----------------------------------------------+ + + Table 1: Semantics of the TOS Bits + + +-----+-----------------+ + | 111 | Network Control | + +-----+-----------------+ + | 110 | Internetwork | + +-----+-----------------+ + | 101 | CRITIC/ECP | + +-----+-----------------+ + | 100 | Flash Override | + +-----+-----------------+ + | 011 | Flash | + +-----+-----------------+ + | 010 | Immediate | + +-----+-----------------+ + | 001 | Priority | + +-----+-----------------+ + | 000 | Routine | + +-----+-----------------+ + + Table 2: Semantics of the Possible Precedence Field Values + + The Type of Service field can be used to affect the way in which the + packet is treated by the systems of a network that process it. + Section 4.2.1 ("Precedence-Ordered Queue Service") and Section 4.2.2 + + + + + +Gont Informational [Page 11] + +RFC 6274 IPv4 Security Assessment July 2011 + + + ("Weak Type of Service") of this document describe the security + implications of the Type of Service field in the forwarding of + packets. + +3.3.2. Standard Interpretation + +3.3.2.1. Differentiated Services Field + + The Differentiated Services Architecture is intended to enable + scalable service discrimination in the Internet without the need for + per-flow state and signaling at every hop [RFC2475]. RFC 2474 + [RFC2474] redefined the IP "Type of Service" octet, introducing a + Differentiated Services Field (DS Field). Figure 3 shows the format + of the field. + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + | DSCP | CU | + +---+---+---+---+---+---+---+---+ + + Figure 3: Revised Structure of the Type of Service Field (RFC 2474) + + The DSCP ("Differentiated Services CodePoint") is used to select the + treatment the packet is to receive within the Differentiated Services + Domain. The CU ("Currently Unused") field was, at the time the + specification was issued, reserved for future use. The DSCP field is + used to select a PHB (Per-Hop Behavior), by matching against the + entire 6-bit field. + + Considering that the DSCP field determines how a packet is treated + within a Differentiated Services (DS) domain, an attacker could send + packets with a forged DSCP field to perform a theft of service or + even a Denial-of-Service (DoS) attack. In particular, an attacker + could forge packets with a codepoint of the type '11x000' which, + according to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the + packets preferential forwarding treatment when compared with the PHB + selected by the codepoint '000000'. If strict priority queuing were + utilized, a continuous stream of such packets could cause a DoS to + other flows that have a DSCP of lower relative order. + + As the DS field is incompatible with the original Type of Service + field, both DS domains and networks using the original Type of + Service field should protect themselves by remarking the + corresponding field where appropriate, probably deploying remarking + boundary nodes. Nevertheless, care must be taken so that packets + received with an unrecognized DSCP do not cause the handling system + to malfunction. + + + + +Gont Informational [Page 12] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.3.2.2. Explicit Congestion Notification (ECN) + + RFC 3168 [RFC3168] specifies a mechanism for routers to signal + congestion to hosts exchanging IP packets, by marking the offending + packets rather than discarding them. RFC 3168 defines the ECN field, + which utilizes the CU field defined in RFC 2474 [RFC2474]. Figure 4 + shows the current syntax of the IP Type of Service field, with the + DSCP field used for Differentiated Services and the ECN field. + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | DS FIELD, DSCP | ECN FIELD | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + Figure 4: The Differentiated Services and ECN Fields in IP + + As such, the ECN field defines four codepoints: + + +-----------+-----------+ + | ECN field | Codepoint | + +-----------+-----------+ + | 00 | Not-ECT | + +-----------+-----------+ + | 01 | ECT(1) | + +-----------+-----------+ + | 10 | ECT(0) | + +-----------+-----------+ + | 11 | CE | + +-----------+-----------+ + + Table 3: ECN Codepoints + + ECN is an end-to-end transport protocol mechanism based on + notifications by routers through which a packet flow passes. To + allow this interaction to happen on the fast path of routers, the ECN + field is located at a fixed location in the IP header. However, its + use must be negotiated at the transport layer, and the accumulated + congestion notifications must be communicated back to the sending + node using transport protocol means. Thus, ECN support must be + specified per transport protocol. + + [RFC6040] specifies how the Explicit Congestion Notification (ECN) + field of the IP header should be constructed on entry to and exit + from any IP-in-IP tunnel. + + + + + + + +Gont Informational [Page 13] + +RFC 6274 IPv4 Security Assessment July 2011 + + + The security implications of ECN are discussed in detail in a number + of Sections of RFC 3168. Of the possible threats discussed in the + ECN specification, we believe that one that can be easily exploited + is that of a host falsely indicating ECN-Capability. + + An attacker could set the ECT codepoint in the packets it sends, to + signal the network that the endpoints of the transport protocol are + ECN-capable. Consequently, when experiencing moderate congestion, + routers using active queue management based on Random Early Detection + (RED) would mark the packets (with the CE codepoint) rather than + discard them. In this same scenario, packets of competing flows that + do not have the ECT codepoint set would be dropped. Therefore, an + attacker would get better network service than the competing flows. + + However, if this moderate congestion turned into heavy congestion, + routers should switch to drop packets, regardless of whether or not + the packets have the ECT codepoint set. + + A number of other threats could arise if an attacker was a man in the + middle (i.e., was in the middle of the path the packets travel to get + to the destination host). For a detailed discussion of those cases, + we urge the reader to consult Section 16 of RFC 3168. + + There is also ongoing work in the research community and the IETF to + define alternate semantics for the CU/ECN field of IP TOS octet (see + [RFC5559], [RFC5670], and [RFC5696]). The application of these + methods must be confined to tightly administered domains, and on exit + from such domains, all packets need to be (re-)marked with ECN + semantics. + +3.4. Total Length + + The Total Length field is the length of the datagram, measured in + bytes, including both the IP header and the IP payload. Being a + 16-bit field, it allows for datagrams of up to 65535 bytes. RFC 791 + [RFC0791] states that all hosts should be prepared to receive + datagrams of up to 576 bytes (whether they arrive as a whole, or in + fragments). However, most modern implementations can reassemble + datagrams of at least 9 Kbytes. + + Usually, a host will not send to a remote peer an IP datagram larger + than 576 bytes, unless it is explicitly signaled that the remote peer + is able to receive such "large" datagrams (for example, by means of + TCP's Maximum Segment Size (MSS) option). However, systems should + assume that they may receive datagrams larger than 576 bytes, + regardless of whether or not they signal their remote peers to do so. + In fact, it is common for Network File System (NFS) [RFC3530] + + + + +Gont Informational [Page 14] + +RFC 6274 IPv4 Security Assessment July 2011 + + + implementations to send datagrams larger than 576 bytes, even without + explicit signaling that the destination system can receive such + "large" datagram. + + Additionally, see the discussion in Section 4.1 ("Fragment + Reassembly") regarding the possible packet sizes resulting from + fragment reassembly. + + Implementations should be aware that the IP module could be handed a + packet larger than the value actually contained in the Total Length + field. Such a difference usually has to do with legitimate padding + bytes at the link-layer protocol, but it could also be the result of + malicious activity by an attacker. Furthermore, even when the + maximum length of an IP datagram is 65535 bytes, if the link-layer + technology in use allows for payloads larger than 65535 bytes, an + attacker could forge such a large link-layer packet, meaning it for + the IP module. If the IP module of the receiving system were not + prepared to handle such an oversized link-layer payload, an + unexpected failure might occur. Therefore, the memory buffer used by + the IP module to store the link-layer payload should be allocated + according to the payload size reported by the link layer, rather than + according to the Total Length field of the IP packet it contains. + + The IP module could also be handed a packet that is smaller than the + actual IP packet size claimed by the Total Length field. This could + be used, for example, to produce an information leakage. Therefore, + the following check should be performed: + + LinkLayer.PayloadSize >= Total Length + + If this check fails, the IP packet should be dropped, and this event + should be logged (e.g., a counter could be incremented reflecting the + packet drop). As the previous expression implies, the number of + bytes passed by the link layer to the IP module should contain at + least as many bytes as claimed by the Total Length field of the IP + header. + + [US-CERT2002] is an example of the exploitation of a forged IP + Total Length field to produce an information leakage attack. + +3.5. Identification (ID) + + The Identification field is set by the sending host to aid in the + reassembly of fragmented datagrams. At any time, it needs to be + unique for each set of {Source Address, Destination Address, + Protocol}. + + + + + +Gont Informational [Page 15] + +RFC 6274 IPv4 Security Assessment July 2011 + + + In many systems, the value used for this field is determined at the + IP layer, on a protocol-independent basis. Many of those systems + also simply increment the IP Identification field for each packet + they send. + + This implementation strategy is inappropriate for a number of + reasons. Firstly, if the Identification field is set on a protocol- + independent basis, it will wrap more often than necessary, and thus + the implementation will be more prone to the problems discussed in + [Kent1987] and [RFC4963]. Secondly, this implementation strategy + opens the door to an information leakage that can be exploited in a + number of ways. + + [Sanfilippo1998a] describes how the Identification field can be + leveraged to determine the packet rate at which a given system is + transmitting information. Later, [Sanfilippo1998b] described how a + system with such an implementation can be used to perform a stealth + port scan to a third (victim) host. [Sanfilippo1999] explained how + to exploit this implementation strategy to uncover the rules of a + number of firewalls. [Bellovin2002] explains how the IP + Identification field can be exploited to count the number of systems + behind a NAT. [Fyodor2004] is an entire paper on most (if not all) + of the ways to exploit the information provided by the Identification + field of the IP header. + + Section 4.1 contains a discussion of the security implications of + the IP fragment reassembly mechanism, which is the primary + "consumer" of this field. + +3.5.1. Some Workarounds Implemented by the Industry + + As the IP Identification field is only used for the reassembly of + datagrams, some operating systems (such as Linux) decided to set this + field to 0 in all packets that have the DF bit set. This would, in + principle, avoid any type of information leakage. However, it was + detected that some non-RFC-compliant middle-boxes fragmented packets + even if they had the DF bit set. In such a scenario, all datagrams + originally sent with the DF bit set would all result in fragments + with an Identification field of 0, which would lead to problems + ("collision" of the Identification number) in the reassembly process. + + Linux (and Solaris) later set the IP Identification field on a per- + IP-address basis. This avoids some of the security implications of + the IP Identification field, but not all. For example, systems + behind a load balancer can still be counted. + + + + + + +Gont Informational [Page 16] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.5.2. Possible Security Improvements + + Contrary to common wisdom, the IP Identification field does not need + to be system-wide unique for each packet, but has to be unique for + each {Source Address, Destination Address, Protocol} tuple. + + For instance, the TCP specification defines a generic send() + function that takes the IP ID as one of its arguments. + + We provide an analysis of the possible security improvements that + could be implemented, based on whether the protocol using the + services of IP is connection-oriented or connection-less. + +3.5.2.1. Connection-Oriented Transport Protocols + + To avoid the security implications of the information leakage + described above, a pseudo-random number generator (PRNG) could be + used to set the IP Identification field on a {Source Address, + Destination Address} basis (for each connection-oriented transport + protocol). + + [RFC4086] provides advice on the generation of pseudo-random + numbers. + + [Klein2007] is a security advisory that describes a weakness in + the pseudo-random number generator (PRNG) employed for the + generation of the IP Identification by a number of operating + systems. + + While in theory a pseudo-random number generator could lead to + scenarios in which a given Identification number is used more than + once in the same time span for datagrams that end up getting + fragmented (with the corresponding potential reassembly problems), in + practice, this is unlikely to cause trouble. + + By default, most implementations of connection-oriented protocols, + such as TCP, implement some mechanism for avoiding fragmentation + (such as the Path-MTU Discovery mechanism described in [RFC1191]). + Thus, fragmentation will only take place if a non-RFC-compliant + middle-box that still fragments packets even when the DF bit is set + is placed somewhere along the path that the packets travel to get to + the destination host. Once the sending system is signaled by the + middle-box (by means of an ICMP "fragmentation needed and DF bit set" + error message) that it should reduce the size of the packets it + sends, fragmentation would be avoided. Also, for reassembly problems + to arise, the same Identification value would need to be reused very + frequently, and either strong packet reordering or packet loss would + need to take place. + + + +Gont Informational [Page 17] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Nevertheless, regardless of what policy is used for selecting the + Identification field, with the current link speeds fragmentation is + already bad enough (i.e., very likely to lead to fragment reassembly + errors) to rely on it. A mechanism for avoiding fragmentation (such + as [RFC1191] or [RFC4821] should be implemented, instead. + +3.5.2.2. Connectionless Transport Protocols + + Connectionless transport protocols often have these characteristics: + + o lack of flow-control mechanisms, + + o lack of packet sequencing mechanisms, and/or, + + o lack of reliability mechanisms (such as "timeout and retransmit"). + + This basically means that the scenarios and/or applications for which + connection-less transport protocols are used assume that: + + o Applications will be used in environments in which packet + reordering is very unlikely (such as Local Area Networks), as the + transport protocol itself does not provide data sequencing. + + o The data transfer rates will be low enough that flow control will + be unnecessary. + + o Packet loss is can be tolerated and/or is unlikely. + + With these assumptions in mind, the Identification field could still + be set according to a pseudo-random number generator (PRNG). + + [RFC4086] provides advice on the generation of pseudo-random + numbers. + + In the event a given Identification number was reused while the first + instance of the same number is still on the network, the first IP + datagram would be reassembled before the fragments of the second IP + datagram get to their destination. + + In the event this was not the case, the reassembly of fragments would + result in a corrupt datagram. While some existing work + [Silbersack2005] assumes that this error would be caught by some + upper-layer error detection code, the error detection code in + question (such as UDP's checksum) might not be able to reliably + detect data corruption arising from the replacement of a complete + data block (as is the case in corruption arising from collision of IP + Identification numbers). + + + + +Gont Informational [Page 18] + +RFC 6274 IPv4 Security Assessment July 2011 + + + In the case of UDP, unfortunately some systems have been known to + not enable the UDP checksum by default. For most applications, + packets containing errors should be dropped by the transport layer + and not delivered to the application. A small number of + applications may benefit from disabling the checksum; for example, + streaming media where it is desired to avoid dropping a complete + sample for a single-bit error, and UDP tunneling applications + where the payload (i.e., the inner packet) is protected by its own + transport checksum or other error detection mechanism. + + In general, if IP Identification number collisions become an issue + for the application using the connection-less protocol, the + application designers should consider using a different transport + protocol (which hopefully avoids fragmentation). + + It must be noted that an attacker could intentionally exploit + collisions of IP Identification numbers to perform a DoS attack, by + sending forged fragments that would cause the reassembly process to + result in a corrupt datagram that either would be dropped by the + transport protocol or would incorrectly be handed to the + corresponding application. This issue is discussed in detail in + Section 4.1 ("Fragment Reassembly"). + +3.6. Flags + + The IP header contains 3 control bits, two of which are currently + used for the fragmentation and reassembly function. + + As described by RFC 791, their meaning is: + + o Bit 0: reserved, must be zero (i.e., reserved for future + standardization) + + o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment + + o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments + + The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) + mechanism described in [RFC1191]. However, it can also be exploited + by an attacker to evade Network Intrusion Detection Systems. An + attacker could send a packet with the DF bit set to a system + monitored by a NIDS, and depending on the Path-MTU to the intended + recipient, the packet might be dropped by some intervening router + (because of being too big to be forwarded without fragmentation), + without the NIDS being aware of it. + + + + + + +Gont Informational [Page 19] + +RFC 6274 IPv4 Security Assessment July 2011 + + + +---+ + | H | + +---+ Victim host + | + Router A | MTU=1500 + | + +---+ +---+ +---+ + | R |-----| R |---------| R | + +---+ +---+ +---+ + | MTU=17914 Router B + +---+ | + | S |-----+ + +---+ | + | + NIDS Sensor | + | + _ ___/---\______ Attacker + / \_/ \_ +---+ + / Internet |---------| H | + \_ __/ +---+ + \__ __ ___/ <------ + \___/ \__/ 17914-byte packet + DF bit set + + Figure 5: NIDS Evasion by Means of the Internet Protocol DF Bit + + In Figure 3, an attacker sends a 17914-byte datagram meant for the + victim host in the same figure. The attacker's packet probably + contains an overlapping IP fragment or an overlapping TCP segment, + aiming at "confusing" the NIDS, as described in [Ptacek1998]. The + packet is screened by the NIDS sensor at the network perimeter, which + probably reassembles IP fragments and TCP segments for the purpose of + assessing the data transferred to and from the monitored systems. + However, as the attacker's packet should transit a link with an MTU + smaller than 17914 bytes (1500 bytes in this example), the router + that encounters that this packet cannot be forwarded without + fragmentation (Router B) discards the packet, and sends an ICMP + "fragmentation needed and DF bit set" error message to the source + host. In this scenario, the NIDS may remain unaware that the + screened packet never reached the intended destination, and thus get + an incorrect picture of the data being transferred to the monitored + systems. + + [Shankar2003] introduces a technique named "Active Mapping" that + prevents evasion of a NIDS by acquiring sufficient knowledge about + the network being monitored, to assess which packets will arrive + at the intended recipient, and how they will be interpreted by it. + + + + +Gont Informational [Page 20] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Some firewalls are known to drop packets that have both the MF (More + Fragments) and the DF (Don't Fragment) bits set. While in principle + such a packet might seem nonsensical, there are a number of reasons + for which non-malicious packets with these two bits set can be found + in a network. First, they may exist as the result of some middle-box + processing a packet that was too large to be forwarded without + fragmentation. Instead of simply dropping the corresponding packet + and sending an ICMP error message to the source host, some middle- + boxes fragment the packet (copying the DF bit to each fragment), and + also send an ICMP error message to the originating system. Second, + some systems (notably Linux) set both the MF and the DF bits to + implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should + be taken into account when configuring firewalls and/or tuning NIDSs. + + Section 4.1 contains a discussion of the security implications of the + IP fragment reassembly mechanism. + +3.7. Fragment Offset + + The Fragment Offset is used for the fragmentation and reassembly of + IP datagrams. It indicates where in the original datagram payload + the payload of the fragment belongs, and is measured in units of + eight bytes. As a consequence, all fragments (except the last one), + have to be aligned on an 8-byte boundary. Therefore, if a packet has + the MF flag set, the following check should be enforced: + + (Total Length - IHL * 4) % 8 == 0 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented + reflecting the packet drop). + + Given that Fragment Offset is a 13-bit field, it can hold a value of + up to 8191, which would correspond to an offset 65528 bytes within + the original (non-fragmented) datagram. As such, it is possible for + a fragment to implicitly claim to belong to a datagram larger than + 65535 bytes (the maximum size for a legitimate IP datagram). Even + when the fragmentation mechanism would seem to allow fragments that + could reassemble into such large datagrams, the intent of the + specification is to allow for the transmission of datagrams of up to + 65535 bytes. Therefore, if a given fragment would reassemble into a + datagram of more than 65535 bytes, the resulting datagram should be + dropped, and this event should be logged (e.g., a counter could be + incremented reflecting the packet drop). To detect such a case, the + following check should be enforced on all packets for which the + Fragment Offset contains a non-zero value: + + + + + +Gont Informational [Page 21] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535 + + where IHL_FF is the IHL field of the first fragment (the one with a + Fragment Offset of 0). + + If a fragment does not pass this check, it should be dropped. + + If IHL_FF is not yet available because the first fragment has not yet + arrived, for a preliminary, less rigid test, IHL_FF == IHL should be + assumed, and the test is simplified to: + + Fragment Offset * 8 + Total Length <= 65535 + + Once the first fragment is received, the full sanity check described + earlier should be applied, if that fragment contains "don't copy" + options. + + In the worst-case scenario, an attacker could craft IP fragments such + that the reassembled datagram reassembled into a datagram of 131043 + bytes. + + Such a datagram would result when the first fragment has a + Fragment Offset of 0 and a Total Length of 65532, and the second + (and last) fragment has a Fragment Offset of 8189 (65512 bytes), + and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header + length of 20 bytes), the reassembled datagram would be 65532 + + (65535 - 20) = 131047 bytes. + + Additionally, the IP module should implement all the necessary + measures to be able to handle such illegitimate reassembled + datagrams, so as to avoid them from overflowing the buffer(s) used + for the reassembly function. + + [CERT1996c] and [Kenney1996] describe the exploitation of this + issue to perform a DoS attack. + + Section 4.1 contains a discussion of the security implications of the + IP fragment reassembly mechanism. + +3.8. Time to Live (TTL) + + The Time to Live (TTL) field has two functions: to bound the lifetime + of the upper-layer packets (e.g., TCP segments) and to prevent + packets from looping indefinitely in the network. + + Originally, this field was meant to indicate the maximum time a + datagram was allowed to remain in the Internet system, in units of + seconds. As every Internet module that processes a datagram must + + + +Gont Informational [Page 22] + +RFC 6274 IPv4 Security Assessment July 2011 + + + decrement the TTL by at least one, the original definition of the TTL + field became obsolete, and in practice it is interpreted as a hop + count (see Section 5.3.1 of [RFC1812]). + + Most systems allow the administrator to configure the TTL to be used + for the packets they originate, with the default value usually being + a power of 2, or 255 (e.g., see [Arkin2000]). The recommended value + for the TTL field, as specified by the IANA is 64 [IANA_IP_PARAM]. + This value reflects the assumed "diameter" of the Internet, plus a + margin to accommodate its growth. + + The TTL field has a number of properties that are interesting from a + security point of view. Given that the default value used for the + TTL is usually either a power of two, or 255, chances are that unless + the originating system has been explicitly tuned to use a non-default + value, if a packet arrives with a TTL of 60, the packet was + originally sent with a TTL of 64. In the same way, if a packet is + received with a TTL of 120, chances are that the original packet had + a TTL of 128. + + This discussion assumes there was no protocol scrubber, + transparent proxy, or some other middle-box that overwrites the + TTL field in a non-standard way, between the originating system + and the point of the network in which the packet was received. + + Determining the TTL with which a packet was originally sent by the + source system can help to obtain valuable information. Among other + things, it may help in: + + o Fingerprinting the originating operating system. + + o Fingerprinting the originating physical device. + + o Mapping the network topology. + + o Locating the source host in the network topology. + + o Evading Network Intrusion Detection Systems. + + However, it can also be used to perform important functions such as: + + o Improving the security of applications that make use of the + Internet Protocol (IP). + + o Limiting spread of packets. + + + + + + +Gont Informational [Page 23] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.8.1. Fingerprinting the Operating System in Use by the Source Host + + Different operating systems use a different default TTL for the + packets they send. Thus, asserting the TTL with which a packet was + originally sent will help heuristics to reduce the number of possible + operating systems in use by the source host. It should be noted that + since most systems use only a handful of different default values, + the granularity of OS fingerprinting that this technique provides is + negligible. Additionally, these defaults may be configurable + (system-wide or per protocol), and managed systems may employ such + opportunities for operational purposes and to defeat the capability + of fingerprinting heuristics. + +3.8.2. Fingerprinting the Physical Device from which the Packets + Originate + + When several systems are behind a middle-box such as a NAT or a load + balancer, the TTL may help to count the number of systems behind the + middle-box. If each of the systems behind the middle-box uses a + different default TTL value for the packets it sends, or each system + is located at different distances in the network topology, an + attacker could stimulate responses from the devices being + fingerprinted, and responses that arrive with different TTL values + could be assumed to come from a different devices. + + Of course, there are many other (and much more precise) techniques + to fingerprint physical devices. One weakness of this method is + that, while many systems differ in the default TTL value that they + use, there are also many implementations which use the same + default TTL value. Additionally, packets sent by a given device + may take different routes (e.g., due to load sharing or route + changes), and thus a given packet may incorrectly be presumed to + come from a different device, when in fact it just traveled a + different route. + + However, these defaults may be configurable (system-wide or per + protocol) and managed systems may employ such opportunities for + operational purposes and to defeat the capability of fingerprinting + heuristics. + +3.8.3. Mapping the Network Topology + + An originating host may set the TTL field of the packets it sends to + progressively increasing values in order to elicit an ICMP error + message from the routers that decrement the TTL of each packet to + zero, and thereby determine the IP addresses of the routers on the + path to the packet's destination. This procedure has been + traditionally employed by the traceroute tool. + + + +Gont Informational [Page 24] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.8.4. Locating the Source Host in the Network Topology + + The TTL field may also be used to locate the source system in the + network topology [Northcutt2000]. + + +---+ +---+ +---+ +---+ +---+ + | A |-----| R |------| R |----| R |-----| R | + +---+ +---+ +---+ +---+ +---+ + / | / \ + / | / \ + / | / +---+ + / +---+ +---+ +---+ | E | + / | R |----| R |------| R |-- +---+ + / +---+ +---+\ +---+ \ + / / / \ \ \ + / ---- / +---+ \ \+---+ + / / / | F | \ | D | + +---+ +---+ +---+ \ +---| + | R |----------| R |-- \ + +---+ +---+ \ \ + | \ / \ +---+| +---+ + | \ / ----| R |------| R | + | \ / +---+ +---+ + +---+ \ +---+ +---+ + | B | \| R |----| C | + +---+ +---+ +---+ + + Figure 6: Tracking a Host by Means of the TTL Field + + Consider network topology of Figure 6. Assuming that an attacker + ("F" in the figure) is performing some type of attack that requires + forging the Source Address (such as for a TCP-based DoS reflection + attack), and some of the involved hosts are willing to cooperate to + locate the attacking system. + + Assuming that: + + o All the packets A gets have a TTL of 61. + + o All the packets B gets have a TTL of 61. + + o All the packets C gets have a TTL of 61. + + o All the packets D gets have a TTL of 62. + + + + + + + +Gont Informational [Page 25] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Based on this information, and assuming that the system's default + value was not overridden, it would be fair to assume that the + original TTL of the packets was 64. With this information, the + number of hops between the attacker and each of the aforementioned + hosts can be calculated. + + The attacker is: + + o Four hops away from A. + + o Four hops away from B. + + o Four hops away from C. + + o Four hops away from D. + + In the network setup of Figure 3, the only system that satisfies all + these conditions is the one marked as the "F". + + The scenario described above is for illustration purposes only. In + practice, there are a number of factors that may prevent this + technique from being successfully applied: + + o Unless there is a "large" number of cooperating systems, and the + attacker is assumed to be no more than a few hops away from these + systems, the number of "candidate" hosts will usually be too large + for the information to be useful. + + o The attacker may be using a non-default TTL value, or, what is + worse, using a pseudo-random value for the TTL of the packets it + sends. + + o The packets sent by the attacker may take different routes, as a + result of a change in network topology, load sharing, etc., and + thus may lead to an incorrect analysis. + +3.8.5. Evading Network Intrusion Detection Systems + + The TTL field can be used to evade Network Intrusion Detection + Systems. Depending on the position of a sensor relative to the + destination host of the examined packet, the NIDS may get a different + picture from that of the intended destination system. As an example, + a sensor may process a packet that will expire before getting to the + destination host. A general countermeasure for this type of attack + is to normalize the traffic that gets to an organizational network. + Examples of such traffic normalization can be found in [Paxson2001]. + OpenBSD Packet Filter is an example of a packet filter that includes + TTL-normalization functionality [OpenBSD-PF] + + + +Gont Informational [Page 26] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.8.6. Improving the Security of Applications That Make Use of the + Internet Protocol (IP) + + In some scenarios, the TTL field can be also used to improve the + security of an application, by restricting the hosts that can + communicate with the given application [RFC5082]. For example, there + are applications for which the communicating systems are typically in + the same network segment (i.e., there are no intervening routers). + Such an application is the BGP (Border Gateway Protocol) utilized by + two peer routers (usually on a shared link medium). + + If both systems use a TTL of 255 for all the packets they send to + each other, then a check could be enforced to require all packets + meant for the application in question to have a TTL of 255. + + 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 [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 + protection will be smaller than in the case of directly connected + peers, the use of the TTL field for protecting multi-hop peering + still reduces the set of hosts that could potentially perform a + number of attacks against the protected application. + + This use of the TTL field has been officially documented by the IETF + under the name "Generalized TTL Security Mechanism" (GTSM) in + [RFC5082]. + + + + + + + + +Gont Informational [Page 27] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Some protocol scrubbers enforce a minimum value for the TTL field of + the packets they forward. It must be understood that depending on + the minimum TTL being enforced, and depending on the particular + network setup, the protocol scrubber may actually help attackers to + fool the GTSM, by "raising" the TTL of the attacking packets. + +3.8.7. Limiting Spread + + The originating host sets the TTL field to a small value (frequently + 1, for link-scope services) in order to artificially limit the + (topological) distance the packet is allowed to travel. This is + suggested in Section 4.2.2.9 of RFC 1812 [RFC1812]. Further + discussion of this technique can be found in RFC 1112 [RFC1112]. + +3.9. Protocol + + The Protocol field indicates the protocol encapsulated in the + Internet datagram. The Protocol field may not only contain a value + corresponding to a protocol implemented by the system processing the + packet, but also a value corresponding to a protocol not implemented, + or even a value not yet assigned by the IANA [IANA_PROT_NUM]. + + While in theory there should not be security implications from the + use of any value in the protocol field, there have been security + issues in the past with systems that had problems when handling + packets with some specific protocol numbers [Cisco2003] [CERT2003]. + + A host (i.e., end-system) that receives an IP packet encapsulating a + Protocol it does not support should drop the corresponding packet, + log the event, and possibly send an ICMP Protocol Unreachable (type + 3, code 2) error message. + +3.10. Header Checksum + + The Header Checksum field is an error-detection mechanism meant to + detect errors in the IP header. While in principle there should not + be security implications arising from this field, it should be noted + that due to non-RFC-compliant implementations, the Header Checksum + might be exploited to detect firewalls and/or evade NIDSs. + + [Ed3f2002] describes the exploitation of the TCP checksum for + performing such actions. As there are Internet routers known to not + check the IP Header Checksum, and there might also be middle-boxes + (NATs, firewalls, etc.) not checking the IP checksum allegedly due to + performance reasons, similar malicious activity to the one described + in [Ed3f2002] might be performed with the IP checksum. + + + + + +Gont Informational [Page 28] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.11. Source Address + + The Source Address of an IP datagram identifies the node from which + the packet originated. + + Strictly speaking, the Source Address of an IP datagram identifies + the interface of the sending system from which the packet was + sent, (rather than the originating "system"), as in the Internet + Architecture there's no concept of "node address". + + Unfortunately, it is trivial to forge the Source Address of an + Internet datagram because of the apparent lack of consistent "egress + filtering" near the edge of the network. This has been exploited in + the past for performing a variety of DoS attacks [NISCC2004] + [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a] and for impersonating + other systems in scenarios in which authentication was based on the + Source Address of the sending system [daemon91996]. + + The extent to which these attacks can be successfully performed in + the Internet can be reduced through deployment of ingress/egress + filtering in the Internet routers. [NISCC2006] is a detailed guide + 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 [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.3 ("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 + NIDSs. + + It is also very important to understand that authentication should + never rely solely on the Source Address used by the communicating + systems. + + + + + + +Gont Informational [Page 29] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.12. Destination Address + + The Destination Address of an IP datagram identifies the destination + host to which the packet is meant to be delivered. + + Strictly speaking, the Destination Address of an IP datagram + identifies the interface of the destination network interface, + rather than the destination "system", as in the Internet + Architecture there's no concept of "node address". + + There are a number of sanity checks that should be performed on the + Destination Address of an IP datagram. Details can be found in + Section 4.3 ("Addressing"). + +3.13. Options + + According to RFC 791, IP options must be implemented by all IP + modules, both in hosts and gateways (i.e., end-systems and + intermediate-systems). This means that the general rules for + assembling, parsing, and processing of IP options must be + implemented. RFC 791 defines a set of options that "must be + understood", but this set has been updated by RFC 1122 [RFC1122], RFC + 1812 [RFC1812], and other documents. Section 3.13.2 of this document + describes for each option type the current understanding of the + implementation requirements. IP systems are required to ignore + options they do not implement. + + It should be noted that while a number of IP options have been + specified, they are generally only used for troubleshooting + purposes (except for the Router Alert option and the different + Security options). + + There are two cases for the format of an option: + + o Case 1: A single byte of option-type. + + o Case 2: An option-type byte, an option-length byte, and the actual + option-data bytes. + + In Case 2, the option-length byte counts the option-type byte and the + option-length byte, as well as the actual option-data bytes. + + All current and future options except End of Option List (Type = 0) + and No Operation (Type = 1), are of Class 2. + + The option-type has three fields: + + o 1 bit: copied flag. + + + +Gont Informational [Page 30] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o 2 bits: option class. + + o 5 bits: option number. + + This format allows for the creation of new options for the extension + of the Internet Protocol (IP) and their transparent treatment on + intermediate-systems that do not "understand" them, under direction + of the first three functional parts. + + The copied flag indicates whether this option should be copied to all + fragments in the event the packet carrying it needs to be fragmented: + + o 0 = not copied. + + o 1 = copied. + + The values for the option class are: + + o 0 = control. + + o 1 = reserved for future use. + + o 2 = debugging and measurement. + + o 3 = reserved for future use. + + Finally, the option number identifies the syntax of the rest of the + option. + + [IANA_IP_PARAM] contains the list of the currently assigned IP option + numbers. It should be noted that IP systems are required to ignore + those options they do not implement. + +3.13.1. General Issues with IP Options + + The following subsections discuss security issues that apply to all + IP options. The proposed checks should be performed in addition to + any option-specific checks proposed in the next sections. + +3.13.1.1. Processing Requirements + + Router manufacturers tend to do IP option processing on the main + processor, rather than on line cards. Unless special care is taken, + this represents DoS risk, as there is potential for overwhelming the + router with option processing. + + To reduce the impact of these packets on the system performance, a + few countermeasures could be implemented: + + + +Gont Informational [Page 31] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o Rate-limit the number of packets with IP options that are + processed by the system. + + o Enforce a limit on the maximum number of options to be accepted on + a given Internet datagram. + + The first check avoids a flow of packets with IP options to overwhelm + the system in question. The second check avoids packets with many IP + options to affect the performance of the system. + +3.13.1.2. Processing of the Options by the Upper-Layer Protocol + + Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options + received in IP datagrams must be passed to the transport layer (or to + ICMP processing when the datagram is an ICMP message). Therefore, + care in option processing must be taken not only at the Internet + layer but also in every protocol module that may end up processing + the options included in an IP datagram. + +3.13.1.3. General Sanity Checks on IP Options + + There are a number of sanity checks that should be performed on IP + options before further option processing is done. They help prevent + a number of potential security problems, including buffer overflows. + When these checks fail, the packet carrying the option should be + dropped, and this event should be logged (e.g., a counter could be + incremented to reflect the packet drop). + + RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" + message to the originating system when a packet is dropped because of + an invalid value in a field, such as the cases discussed in the + following subsections. Sending such a message might help in + debugging some network problems. However, it would also alert + attackers about the system that is dropping packets because of the + invalid values in the protocol fields. + + We advice that systems default to sending an ICMP "Parameter Problem" + error message when a packet is dropped because of an invalid value in + a protocol field (e.g., as a result of dropping a packet due to the + sanity checks described in this section). However, we recommend that + systems provide a system-wide toggle that allows an administrator to + override the default behavior so that packets can be silently dropped + when an invalid value in a protocol field is encountered. + + + + + + + + +Gont Informational [Page 32] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Option length + + Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer + must not crash as the result of an option length that is outside + the possible range, and mentions that erroneous option lengths + have been observed to put some IP implementations into infinite + loops. + + For options that belong to the "Case 2" described in the previous + section, the following check should be performed: + + option-length >= 2 + + The value "2" accounts for the option-type byte and the option- + length byte. + + This check prevents, among other things, loops in option + processing that may arise from incorrect option lengths. + + Additionally, while the option-length byte of IP options of + "Case 2" allows for an option length of up to 255 bytes, there is + a limit on legitimate option length imposed by the space available + for options in the IP header. + + For all options of "Case 2", the following check should be + enforced: + + option-offset + option-length <= IHL * 4 + + Where option-offset is the offset of the first byte of the option + within the IP header, with the first byte of the IP header being + assigned an offset of 0. + + This check assures that the option does not claim to extend beyond + the IP header. If the packet does not pass this check, it should + be dropped, and this event should be logged (e.g., a counter could + be incremented to reflect the packet drop). + + The aforementioned check is meant to detect forged option-length + values that might make an option overlap with the IP payload. + This would be particularly dangerous for those IP options that + request the processing systems to write information into the + option-data area (such as the Record Route option), as it would + allow the generation of overflows. + + + + + + + +Gont Informational [Page 33] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Data types + + Many IP options use pointer and length fields. Care must be taken + as to the data type used for these fields in the implementation. + For example, if an 8-bit signed data type were used to hold an + 8-bit pointer, then, pointer values larger than 128 might + mistakenly be interpreted as negative numbers, and thus might lead + to unpredictable results. + +3.13.2. Issues with Specific Options + +3.13.2.1. End of Option List (Type=0) + + This option is used to indicate the "end of options" in those cases + in which the end of options would not coincide with the end of the + Internet Protocol header. Octets in the IP header following the "End + of Option List" are to be regarded as padding (they should set to 0 + by the originator and must to be ignored by receiving nodes). + + However, an originating node could alternatively fill the remaining + space in the Internet header with No Operation options (see + Section 3.13.2.2). The End of Option List option allows slightly + more efficient parsing on receiving nodes and should be preferred by + packet originators. All IP systems are required to understand both + encodings. + +3.13.2.2. No Operation (Type=1) + + The No Operation option is basically meant to allow the sending + system to align subsequent options in, for example, 32-bit + boundaries, but it can also be used at the end of the options (see + Section 3.13.2.1). + + With a single exception (see Section 3.13.2.13), this option is the + only IP option defined so far that can occur in multiple instances in + a single IP packet. + + This option does not have security implications. + +3.13.2.3. Loose Source and Record Route (LSRR) (Type=131) + + This option lets the originating system specify a number of + intermediate-systems a packet must pass through to get to the + destination host. Additionally, the route followed by the packet is + recorded in the option. The receiving host (end-system) must use the + reverse of the path contained in the received LSRR option. + + + + + +Gont Informational [Page 34] + +RFC 6274 IPv4 Security Assessment July 2011 + + + The LSSR option can be of help in debugging some network problems. + Some ISP (Internet Service Provider) peering agreements require + support for this option in the routers within the peer of the ISP. + + The LSRR option has well-known security implications. Among other + things, the option can be used to: + + o Bypass firewall rules + + o Reach otherwise unreachable Internet systems + + o Establish TCP connections in a stealthy way + + o Learn about the topology of a network + + o Perform bandwidth-exhaustion attacks + + Of these attack vectors, the one that has probably received the least + attention is the use of the LSRR option to perform bandwidth + exhaustion attacks. The LSRR option can be used as an amplification + method for performing bandwidth-exhaustion attacks, as an attacker + could make a packet bounce multiple times between a number of systems + by carefully crafting an LSRR option. + + This is the IPv4-version of the IPv6 amplification attack that was + widely publicized in 2007 [Biondi2007]. The only difference is + that the maximum length of the IPv4 header (and hence the LSRR + option) limits the amplification factor when compared to the IPv6 + counterpart. + + While the LSSR option may be of help in debugging some network + problems, its security implications outweigh any legitimate use. + + All systems should, by default, drop IP packets that contain an LSRR + option, and should log this event (e.g., a counter could be + incremented to reflect the packet drop). However, they should + provide a system-wide toggle to enable support for this option for + those scenarios in which this option is required. Such system-wide + toggle should default to "off" (or "disable"). + + [OpenBSD1998] is a security advisory about an improper + implementation of such a system-wide toggle in 4.4BSD kernels. + + Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to + act as an intermediate hop in a source route, forwarding a source- + routed datagram to the next specified hop. We strongly discourage + host software from forwarding source-routed datagrams. + + + + +Gont Informational [Page 35] + +RFC 6274 IPv4 Security Assessment July 2011 + + + If processing of source-routed datagrams is explicitly enabled in a + system, the following sanity checks should be performed. + + RFC 791 states that this option should appear, at most, once in a + given packet. Thus, if a packet contains more than one LSRR option, + it should be dropped, and this event should be logged (e.g., a + counter could be incremented to reflect the packet drop). + Additionally, packets containing a combination of LSRR and SSRR + options should be dropped, and this event should be logged (e.g., a + counter could be incremented to reflect the packet drop). + + As all other IP options of "Case 2", the LSSR contains a Length field + that indicates the length of the option. Given the format of the + option, the Length field should be checked to have a minimum value of + three and be 3 (3 + n*4): + + LSRR.Length % 4 == 3 && LSRR.Length != 0 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + The Pointer is relative to this option. Thus, the minimum legal + value is 4. Therefore, the following check should be performed. + + LSRR.Pointer >= 4 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). Additionally, the Pointer field should be + a multiple of 4. Consequently, the following check should be + performed: + + LSRR.Pointer % 4 == 0 + + If a packet does not pass this check, it should be dropped, and this + event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + When a system receives an IP packet with the LSRR option passing the + above checks, it should check whether or not the source route is + empty. The option is empty if: + + LSRR.Pointer > LSRR.Length + + In that case, routing should be based on the Destination Address + field, and no further processing should be done on the LSRR option. + + + + +Gont Informational [Page 36] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [Microsoft1999] is a security advisory about a vulnerability + arising from improper validation of the LSRR.Pointer field. + + If the address in the Destination Address field has been reached, and + the option is not empty, the next address in the source route + replaces the address in the Destination Address field, and the IP + address of the interface that will be used to forward this datagram + is recorded in its place in the LSRR.Data field. Then, the + LSRR.Pointer. is incremented by 4. + + Note that the sanity checks for the LSRR.Length and the + LSRR.Pointer fields described above ensure that if the option is + not empty, there will be (4*n) octets in the option. That is, + there will be at least one IP address to read and enough room to + record the IP address of the interface that will be used to + forward this datagram. + + The LSRR must be copied on fragmentation. This means that if a + packet that carries the LSRR is fragmented, each of the fragments + will have to go through the list of systems specified in the LSRR + option. + +3.13.2.4. Strict Source and Record Route (SSRR) (Type=137) + + This option allows the originating system to specify a number of + intermediate-systems a packet must pass through to get to the + destination host. Additionally, the route followed by the packet is + recorded in the option, and the destination host (end-system) must + use the reverse of the path contained in the received SSRR option. + + This option is similar to the Loose Source and Record Route (LSRR) + option, with the only difference that in the case of SSRR, the route + specified in the option is the exact route the packet must take + (i.e., no other intervening routers are allowed to be in the route). + + The SSSR option can be of help in debugging some network problems. + Some ISP (Internet Service Provider) peering agreements require + support for this option in the routers within the peer of the ISP. + + The SSRR option has the same security implications as the LSRR + option. Please refer to Section 3.13.2.3 for a discussion of such + security implications. + + As with the LSRR, while the SSSR option may be of help in debugging + some network problems, its security implications outweigh any + legitimate use of it. + + + + + +Gont Informational [Page 37] + +RFC 6274 IPv4 Security Assessment July 2011 + + + All systems should, by default, drop IP packets that contain an SSRR + option, and should log this event (e.g., a counter could be + incremented to reflect the packet drop). However, they should + provide a system-wide toggle to enable support for this option for + those scenarios in which this option is required. Such system-wide + toggle should default to "off" (or "disable"). + + [OpenBSD1998] is a security advisory about an improper + implementation of such a system-wide toggle in 4.4BSD kernels. + + In the event processing of the SSRR option were explicitly enabled, + the same sanity checks described for the LSRR option in + Section 3.13.2.3 should be performed on the SSRR option. Namely, + sanity checks should be performed on the option length (SSRR.Length) + and the pointer field (SSRR.Pointer). + + If the packet passes the aforementioned sanity checks, the receiving + system should determine whether the Destination Address of the packet + corresponds to one of its IP addresses. If does not, it should be + dropped, and this event should be logged (e.g., a counter could be + incremented to reflect the packet drop). + + Contrary to the IP Loose Source and Record Route (LSRR) option, + the SSRR option does not allow in the route other routers than + those contained in the option. If the system implements the weak + end-system model, it is allowed for the system to receive a packet + destined to any of its IP addresses, on any of its interfaces. If + the system implements the strong end-system model, a packet + destined to it can be received only on the interface that + corresponds to the IP address contained in the Destination Address + field [RFC1122]. + + If the packet passes this check, the receiving system should + determine whether the source route is empty or not. The option is + empty if: + + SSRR.Pointer > SSRR.Length + + In that case, if the address in the destination field has not been + reached, the packet should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet + drop). + + [Microsoft1999] is a security advisory about a vulnerability + arising from improper validation of the SSRR.Pointer field. + + + + + + +Gont Informational [Page 38] + +RFC 6274 IPv4 Security Assessment July 2011 + + + If the option is not empty, and the address in the Destination + Address field has been reached, the next address in the source route + replaces the address in the Destination Address field, and the IP + address of the interface that will be used to forward this datagram + is recorded in its place in the source route (SSRR.Data field). + Then, the SSRR.Pointer is incremented by 4. + + Note that the sanity checks for the SSRR.Length and the + SSRR.Pointer fields described above ensure that if the option is + not empty, there will be (4*n) octets in the option. That is, + there will be at least one IP address to read, and enough room to + record the IP address of the interface that will be used to + forward this datagram. + + The SSRR option must be copied on fragmentation. This means that if + a packet that carries the SSRR is fragmented, each of the fragments + will have to go through the list of systems specified in the SSRR + option. + +3.13.2.5. Record Route (Type=7) + + This option provides a means to record the route that a given packet + follows. + + The option begins with an 8-bit option code, which is equal to 7. + The second byte is the option length, which includes the option-type + byte, the option-length byte, the pointer byte, and the actual + option-data. The third byte is a pointer into the route data, + indicating the first byte of the area in which to store the next + route data. The pointer is relative to the option start. + + RFC 791 states that this option should appear, at most, once in a + given packet. Therefore, if a packet has more than one instance of + this option, it should be dropped, and this event should be logged + (e.g., a counter could be incremented to reflect the packet drop). + + The same sanity checks performed for the Length field and the Pointer + field of the LSRR and the SSRR options should be performed on the + Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR + option. As with the LSRR and SSRR options, if the packet does not + pass these checks it should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet + drop). + + When a system receives an IP packet with the Record Route option that + passes the above checks, it should check whether there is space in + the option to store route information. The option is full if: + + + + +Gont Informational [Page 39] + +RFC 6274 IPv4 Security Assessment July 2011 + + + RR.Pointer > RR.Length + + If the option is full, the datagram should be forwarded without + further processing of this option. + + If the option is not full (i.e., RR.Pointer <= RR.Length), the IP + address of the interface that will be used to forward this datagram + should be recorded into the area pointed to by the RR.Pointer, and + RR.Pointer should then incremented by 4. + + This option is not copied on fragmentation, and thus appears in the + first fragment only. If a fragment other than the one with offset 0 + contains the Record Route option, it should be dropped, and this + event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + The Record Route option can be exploited to learn about the topology + of a network. However, the limited space in the IP header limits the + usefulness of this option for that purpose if the target network is + several hops away. + +3.13.2.6. Stream Identifier (Type=136) + + The Stream Identifier option originally provided a means for the + 16-bit SATNET stream Identifier to be carried through networks that + did not support the stream concept. + + However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this + option is obsolete. Therefore, it must be ignored by the processing + systems. + + In the case of legacy systems still using this option, the length + field of the option should be checked to be 4. If the option does + not pass this check, it should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet + drop). + + RFC 791 states that this option appears at most once in a given + datagram. Therefore, if a packet contains more than one instance of + this option, it should be dropped, and this event should be logged + (e.g., a counter could be incremented to reflect the packet drop). + +3.13.2.7. Internet Timestamp (Type=68) + + This option provides a means for recording the time at which each + system processed this datagram. The timestamp option has a number of + security implications. Among them are the following: + + + + +Gont Informational [Page 40] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o It allows an attacker to obtain the current time of the systems + that process the packet, which the attacker may find useful in a + number of scenarios. + + o It may be used to map the network topology, in a similar way to + the IP Record Route option. + + o It may be used to fingerprint the operating system in use by a + system processing the datagram. + + o It may be used to fingerprint physical devices by analyzing the + clock skew. + + Therefore, by default, the timestamp option should be ignored. + + For those systems that have been explicitly configured to honor this + option, the rest of this subsection describes some sanity checks that + should be enforced on the option before further processing. + + The option begins with an option-type byte, which must be equal to + 68. The second byte is the option-length, which includes the option- + type byte, the option-length byte, the pointer, and the overflow/flag + byte. The minimum legal value for the option-length byte is 4, which + corresponds to an Internet Timestamp option that is empty (no space + to store timestamps). Therefore, upon receipt of a packet that + contains an Internet Timestamp option, the following check should be + performed: + + IT.Length >= 4 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + The Pointer is an index within this option, counting the option type + octet as octet #1. It points to the first byte of the area in which + the next timestamp data should be stored and thus, the minimum legal + value is 5. Since the only change of the Pointer allowed by RFC 791 + is incrementing it by 4 or 8, the following checks should be + performed on the Internet Timestamp option, depending on the Flag + value (see below). + + If IT.Flag is equal to 0, the following check should be performed: + + IT.Pointer %4 == 1 && IT.Pointer != 1 + + + + + + +Gont Informational [Page 41] + +RFC 6274 IPv4 Security Assessment July 2011 + + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + Otherwise, the following sanity check should be performed on the + option: + + IT.Pointer % 8 == 5 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + The flag field has three possible legal values: + + o 0: Record time stamps only, stored in consecutive 32-bit words. + + o 1: Record each timestamp preceded with the Internet address of the + registering entity. + + o 3: The internet address fields of the option are pre-specified. + An IP module only registers its timestamp if it matches its own + address with the next specified Internet address. + + Therefore the following check should be performed: + + IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + The timestamp field is a right-justified 32-bit timestamp in + milliseconds since UTC. If the time is not available in + milliseconds, or cannot be provided with respect to UTC, then any + time may be inserted as a timestamp, provided the high-order bit of + the timestamp is set, to indicate this non-standard value. + + According to RFC 791, the initial contents of the timestamp area must + be initialized to zero, or Internet address/zero pairs. However, + Internet systems should be able to handle non-zero values, possibly + discarding the offending datagram. + + When an Internet system receives a packet with an Internet Timestamp + option, it decides whether it should record its timestamp in the + option. If it determines that it should, it should then determine + whether the timestamp data area is full, by means of the following + check: + + + +Gont Informational [Page 42] + +RFC 6274 IPv4 Security Assessment July 2011 + + + IT.Pointer > IT.Length + + If this condition is true, the timestamp data area is full. If not, + there is room in the timestamp data area. + + If the timestamp data area is full, the overflow byte should be + incremented, and the packet should be forwarded without inserting the + timestamp. If the overflow byte itself overflows, the packet should + be dropped, and this event should be logged (e.g., a counter could be + incremented to reflect the packet drop). + + If the timestamp data area is not full, then processing continues as + follows (note that the above checks on IT.Pointer ensure that there + is room for another entry in the option): + + o If IT.Flag is 0, then the system's 32-bit timestamp is stored into + the area pointed to by the pointer byte and the pointer byte is + incremented by 4. + + o If IT.Flag is 1, then the IP address of the system is stored into + the area pointed to by the pointer byte, followed by the 32-bit + system timestamp, and the pointer byte is incremented by 8. + + o Otherwise (IT.Flag is 3), if the IP address in the first 4 bytes + pointed to by IT.Pointer matches one of the IP addresses assigned + to an interface of the system, then the system's timestamp is + stored into the area pointed to by IT.Pointer + 4, and the pointer + byte is incremented by 8. + + [Kohno2005] describes a technique for fingerprinting devices by + measuring the clock skew. It exploits, among other things, the + timestamps that can be obtained by means of the ICMP timestamp + request messages [RFC0791]. However, the same fingerprinting method + could be implemented with the aid of the Internet Timestamp option. + +3.13.2.8. Router Alert (Type=148) + + The Router Alert option is defined in RFC 2113 [RFC2113] and later + updates to it have been clarified by RFC 5350 [RFC5350]. It contains + a 16-bit Value governed by an IANA registry (see [RFC5350]). The + Router Alert option has the semantic "routers should examine this + packet more closely, if they participate in the functionality denoted + by the Value of the option". + + According to the syntax of the option as defined in RFC 2113, the + following check should be enforced, if the router supports this + option: + + + + +Gont Informational [Page 43] + +RFC 6274 IPv4 Security Assessment July 2011 + + + RA.Length == 4 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + A packet that contains a Router Alert option with an option value + corresponding to functionality supported by an active module in the + router will not go through the router's fast-path but will be + processed in the slow path of the router, handing it over for closer + inspection to the modules that has registered the matching option + value. Therefore, this option may impact the performance of the + systems that handle the packet carrying it. + + [ROUTER-ALERT] analyzes the security implications of the Router + Alert option, and identifies controlled environments in which the + Router Alert option can be used safely. + + As explained in RFC 2113 [RFC2113], hosts should ignore this option. + +3.13.2.9. Probe MTU (Type=11) (Obsolete) + + This option was defined in RFC 1063 [RFC1063] and originally provided + a mechanism to discover the Path-MTU. + + This option is obsolete, and therefore any packet that is received + containing this option should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet + drop). + +3.13.2.10. Reply MTU (Type=12) (Obsolete) + + This option is defined in RFC 1063 [RFC1063], and originally provided + a mechanism to discover the Path-MTU. + + This option is obsolete, and therefore any packet that is received + containing this option should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet + drop). + +3.13.2.11. Traceroute (Type=82) + + This option is defined in RFC 1393 [RFC1393], and originally provided + a mechanism to trace the path to a host. + + + + + + + +Gont Informational [Page 44] + +RFC 6274 IPv4 Security Assessment July 2011 + + + The Traceroute option was specified as "experimental", and it was + never deployed on the public Internet. Therefore, any packet that is + received containing this option should be dropped, and this event + should be logged (e.g., a counter could be incremented to reflect the + packet drop). + +3.13.2.12. Department of Defense (DoD) Basic Security Option (Type=130) + + This option is used by Multi-Level-Secure (MLS) end-systems and + intermediate-systems in specific environments to [RFC1108]: + + o Transmit from source to destination in a network standard + representation the common security labels required by computer + security models, + + o Validate the datagram as appropriate for transmission from the + source and delivery to the destination, and + + o Ensure that the route taken by the datagram is protected to the + level required by all protection authorities indicated on the + datagram. + + It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 + [RFC1038]). + + RFC 791 [RFC0791] defined the "Security Option" (Type=130), which + used the same option type as the DoD Basic Security option + discussed in this section. The "Security Option" specified in RFC + 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and + therefore the discussion in this section is focused on the DoD + Basic Security option specified by RFC 1108 [RFC1108]. + + Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement + this option". + + The DoD Basic Security option is currently implemented in a number of + operating systems (e.g., [IRIX2008], [SELinux2009], [Solaris2007], + and [Cisco2008]), and deployed in a number of high-security networks. + + Systems that belong to networks in which this option is in use should + process the DoD Basic Security option contained in each packet as + specified in [RFC1108]. + + RFC 1108 states that the option should appear at most once in a + datagram. Therefore, if more than one DoD Basic Security option + (BSO) appears in a given datagram, the corresponding datagram should + be dropped, and this event should be logged (e.g., a counter could be + incremented to reflect the packet drop). + + + +Gont Informational [Page 45] + +RFC 6274 IPv4 Security Assessment July 2011 + + + RFC 1108 states that the option Length is variable, with a minimum + option Length of 3 bytes. Therefore, the following check should be + performed: + + BSO.Length >= 3 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + Current deployments of the security options described in this + section and the two subsequent sections have motivated the + specification of a "Common Architecture Label IPv6 Security Option + (CALIPSO)" for the IPv6 protocol [RFC5570]. + +3.13.2.13. DoD Extended Security Option (Type=133) + + This option permits additional security labeling information, beyond + that present in the Basic Security option (Section 3.13.2.13), to be + supplied in an IP datagram to meet the needs of registered + authorities. It is specified by RFC 1108 [RFC1108]. + + This option may be present only in conjunction with the DoD Basic + Security option. Therefore, if a packet contains a DoD Extended + Security option (ESO), but does not contain a DoD Basic Security + option, it should be dropped, and this event should be logged (e.g., + a counter could be incremented to reflect the packet drop). It + should be noted that, unlike the DoD Basic Security option, this + option may appear multiple times in a single IP header. + + Systems that belong to networks in which this option is in use, + should process the DoD Extended Security option contained in each + packet as specified in RFC 1108 [RFC1108]. + + RFC 1108 states that the option Length is variable, with a minimum + option Length of 3 bytes. Therefore, the following check should be + performed: + + ESO.Length >= 3 + + If the packet does not pass this check, it should be dropped, and + this event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + + + + + + + +Gont Informational [Page 46] + +RFC 6274 IPv4 Security Assessment July 2011 + + +3.13.2.14. Commercial IP Security Option (CIPSO) (Type=134) + + This option was proposed by the Trusted Systems Interoperability + Group (TSIG), with the intent of meeting trusted networking + requirements for the commercial trusted systems market place. It is + specified in [CIPSO1992] and [FIPS1994]. + + The TSIG proposal was taken to the Commercial Internet Security + Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an + Internet-Draft was produced [CIPSO1992]. The Internet-Draft was + never published as an RFC, but the proposal was later standardized + by the U.S. National Institute of Standards and Technology (NIST) + as "Federal Information Processing Standard Publication 188" + [FIPS1994]. + + It is currently implemented in a number of operating systems (e.g., + IRIX [IRIX2008], Security-Enhanced Linux [SELinux2009], and Solaris + [Solaris2007]), and deployed in a number of high-security networks. + + [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux + implementation. + + Systems that belong to networks in which this option is in use should + process the CIPSO option contained in each packet as specified in + [CIPSO1992]. + + According to the option syntax specified in [CIPSO1992], the + following validation check should be performed: + + CIPSO.Length >= 6 + + If a packet does not pass this check, it should be dropped, and this + event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + +3.13.2.15. Sender Directed Multi-Destination Delivery (Type=149) + + This option is defined in RFC 1770 [RFC1770] and originally provided + unreliable UDP delivery to a set of addresses included in the option. + + This option is obsolete. If a received packet contains this option, + it should be dropped, and this event should be logged (e.g., a + counter could be incremented to reflect the packet drop). + + + + + + + + +Gont Informational [Page 47] + +RFC 6274 IPv4 Security Assessment July 2011 + + +4. Internet Protocol Mechanisms + +4.1. Fragment Reassembly + + To accommodate networks with different Maximum Transmission Units + (MTUs), the Internet Protocol provides a mechanism for the + fragmentation of IP packets by end-systems (hosts) and/or + intermediate-systems (routers). Reassembly of fragments is performed + only by the end-systems. + + [Cerf1974] provides the rationale for why packet reassembly is not + performed by intermediate-systems. + + During the last few decades, IP fragmentation and reassembly has been + exploited in a number of ways, to perform actions such as evading + NIDSs, bypassing firewall rules, and performing DoS attacks. + + [Bendi1998] and [Humble1998] are examples of the exploitation of + these issues for performing DoS attacks. [CERT1997] and + [CERT1998b] document these issues. [Anderson2001] is a survey of + fragmentation attacks. [US-CERT2001] is an example of the + exploitation of IP fragmentation to bypass firewall rules. + [CERT1999] describes the implementation of fragmentation attacks + in Distributed Denial-of-Service (DDoS) attack tools. + + The problem with IP fragment reassembly basically has to do with the + complexity of the function, in a number of aspects: + + o Fragment reassembly is a stateful operation for a stateless + protocol (IP). The IP module at the host performing the + reassembly function must allocate memory buffers both for + temporarily storing the received fragments and to perform the + reassembly function. Attackers can exploit this fact to exhaust + memory buffers at the system performing the fragment reassembly. + + o The fragmentation and reassembly mechanisms were designed at a + time in which the available bandwidths were very different from + the bandwidths available nowadays. With the current available + bandwidths, a number of interoperability problems may arise, and + these issues may be intentionally exploited by attackers to + perform DoS attacks. + + o Fragment reassembly must usually be performed without any + knowledge of the properties of the path the fragments follow. + Without this information, hosts cannot make any educated guess on + how long they should wait for missing fragments to arrive. + + + + + +Gont Informational [Page 48] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o The fragment reassembly algorithm, as described by the IETF + specifications, is ambiguous, and allows for a number of + interpretations, each of which has found place in different TCP/IP + stack implementations. + + o The reassembly process is somewhat complex. Fragments may arrive + out of order, duplicated, overlapping each other, etc. This + complexity has lead to numerous bugs in different implementations + of the IP protocol. + +4.1.1. Security Implications of Fragment Reassembly + +4.1.1.1. Problems Related to Memory Allocation + + When an IP datagram is received by an end-system, it will be + temporarily stored in system memory, until the IP module processes it + and hands it to the protocol machine that corresponds to the + encapsulated protocol. + + In the case of fragmented IP packets, while the IP module may perform + preliminary processing of the IP header (such as checking the header + for errors and processing IP options), fragments must be kept in + system buffers until all fragments are received and are reassembled + into a complete Internet datagram. + + As mentioned above, because the Internet layer will not usually have + information about the characteristics of the path between the system + and the remote host, no educated guess can be made on the amount of + time that should be waited for the other fragments to arrive. + Therefore, the specifications recommend to wait for a period of time + that is acceptable for virtually all the possible network scenarios + in which the protocols might operate. After that time has elapsed, + all the received fragments for the corresponding incomplete packet + are discarded. + + The original IP Specification, RFC 791 [RFC0791], states that + systems should wait for at least 15 seconds for the missing + fragments to arrive. Systems that follow the "Example Reassembly + Procedure" described in Section 3.2 of RFC 791 may end up using a + reassembly timer of up to 4.25 minutes, with a minimum of 15 + seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this + advice, stating that the reassembly timeout should be a fixed + value between 60 and 120 seconds. + + + + + + + + +Gont Informational [Page 49] + +RFC 6274 IPv4 Security Assessment July 2011 + + + However, the longer the system waits for the missing fragments to + arrive, the longer the corresponding system resources must be tied to + the corresponding packet. The amount of system memory is finite, and + even with today's systems, it can still be considered a scarce + resource. + + An attacker could take advantage of the uncomfortable situation the + system performing fragment reassembly is in, by sending forged + fragments that will never reassemble into a complete datagram. That + is, an attacker would send many different fragments, with different + IP IDs, without ever sending all the necessary fragments that would + be needed to reassemble them into a full IP datagram. For each of + the fragments, the IP module would allocate resources and tie them to + the corresponding fragment, until the reassembly timer for the + corresponding packet expires. + + There are some implementation strategies which could increase the + impact of this attack. For example, upon receipt of a fragment, some + systems allocate a memory buffer that will be large enough to + reassemble the whole datagram. While this might be beneficial in + legitimate cases, this just amplifies the impact of the possible + attacks, as a single small fragment could tie up memory buffers for + the size of an extremely large (and unlikely) datagram. The + implementation strategy suggested in RFC 815 [RFC0815] leads to such + an implementation. + + The impact of the aforementioned attack may vary depending on some + specific implementation details: + + o If the system does not enforce limits on the amount of memory that + can be allocated by the IP module, then an attacker could tie all + system memory to fragments, at which point the system would become + unusable, perhaps crashing. + + o If the system enforces limits on the amount of memory that can be + allocated by the IP module as a whole, then, when this limit is + reached, all further IP packets that arrive would be discarded, + until some fragments time out and free memory is available again. + + o If the system enforces limits on the amount memory that can be + allocated for the reassembly of fragments, then, when this limit + is reached, all further fragments that arrive would be discarded, + until some fragment(s) time out and free memory is available + again. + + + + + + + +Gont Informational [Page 50] + +RFC 6274 IPv4 Security Assessment July 2011 + + +4.1.1.2. Problems That Arise from the Length of the IP Identification + Field + + The Internet Protocols are currently being used in environments that + are quite different from the ones in which they were conceived. For + instance, the availability of bandwidth at the time the Internet + Protocol was designed was completely different from the availability + of bandwidth in today's networks. + + The Identification field is a 16-bit field that is used for the + fragmentation and reassembly function. In the event a datagram gets + fragmented, all the corresponding fragments will share the same + {Source Address, Destination Address, Protocol, Identification + number} four-tuple. Thus, the system receiving the fragments will be + able to uniquely identify them as fragments that correspond to the + same IP datagram. At a given point in time, there must be at most + only one packet in the network with a given four-tuple. If not, an + Identification number "collision" might occur, and the receiving + system might end up "mixing" fragments that correspond to different + IP datagrams which simply reused the same Identification number. + + For example, sending over a 1 Gbit/s path a continuous stream of + (UDP) packets of roughly 1 kb size that all get fragmented into + two equally sized fragments of 576 octets each (minimum reassembly + buffer size) would repeat the IP Identification values within less + than 0.65 seconds (assuming roughly 10% link layer overhead); with + shorter packets that still get fragmented, this figure could + easily drop below 0.4 seconds. With a single IP packet dropped in + this short time frame, packets would start to be reassembled + wrongly and continuously once in such interval until an error + detection and recovery algorithm at an upper layer lets the + application back out. + + For each group of fragments whose Identification numbers "collide", + the fragment reassembly will lead to corrupted packets. The IP + payload of the reassembled datagram will be handed to the + corresponding upper-layer protocol, where the error will (hopefully) + be detected by some error detecting code (such as the TCP checksum) + and the packet will be discarded. + + An attacker could exploit this fact to intentionally cause a system + to discard all or part of the fragmented traffic it gets, thus + performing a DoS attack. Such an attacker would simply establish a + flow of fragments with different IP Identification numbers, to trash + all or part of the IP Identification space. As a result, the + receiving system would use the attacker's fragments for the + reassembly of legitimate datagrams, leading to corrupted packets + which would later (and hopefully) get dropped. + + + +Gont Informational [Page 51] + +RFC 6274 IPv4 Security Assessment July 2011 + + + In most cases, use of a long fragment timeout will benefit the + attacker, as forged fragments will keep the IP Identification space + trashed for a longer period of time. + +4.1.1.3. Problems That Arise from the Complexity of the Reassembly + Algorithm + + As IP packets can be duplicated by the network, and each packet may + take a different path to get to the destination host, fragments may + arrive not only out of order and/or duplicated but also overlapping. + This means that the reassembly process can be somewhat complex, with + the corresponding implementation being not specifically trivial. + + [Shannon2001] analyzes the causes and attributes of fragment traffic + measured in several types of WANs. + + During the years, a number of attacks have exploited bugs in the + reassembly function of several operating systems, producing buffer + overflows that have led, in most cases, to a crash of the attacked + system. + +4.1.1.4. Problems That Arise from the Ambiguity of the Reassembly + Process + + Network Intrusion Detection Systems (NIDSs) typically monitor the + traffic on a given network with the intent of identifying traffic + patterns that might indicate network intrusions. + + In the presence of IP fragments, in order to detect illegitimate + activity at the transport or application layers (i.e., any protocol + layer above the network layer), a NIDS must perform IP fragment + reassembly. + + In order to correctly assess the traffic, the result of the + reassembly function performed by the NIDS should be the same as that + of the reassembly function performed by the intended recipient of the + packets. + + However, a number of factors make the result of the reassembly + process ambiguous: + + o The IETF specifications are ambiguous as to what should be done in + the event overlapping fragments were received. Thus, in the + presence of overlapping data, the system performing the reassembly + function is free to honor either the first set of data received, + the latest copy received, or any other copy received in between. + + + + + +Gont Informational [Page 52] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o As the specifications do not enforce any specific fragment timeout + value, different systems may choose different values for the + fragment timeout. This means that given a set of fragments + received at some specified time intervals, some systems will + reassemble the fragments into a full datagram, while others may + timeout the fragments and therefore drop them. + + o As mentioned before, as the fragment buffers get full, a DoS + condition will occur unless some action is taken. Many systems + flush part of the fragment buffers when some threshold is reached. + Thus, depending on fragment load, timing issues, and flushing + policy, a NIDS may get incorrect assumptions about how (and if) + fragments are being reassembled by their intended recipient. + + As originally discussed by [Ptacek1998], these issues can be + exploited by attackers to evade intrusion detection systems. + + There exist freely available tools to forcefully fragment IP + datagrams so as to help evade Intrusion Detection Systems. Frag + router [Song1999] is an example of such a tool; it allows an attacker + to perform all the evasion techniques described in [Ptacek1998]. + Ftester [Barisani2006] is a tool that helps to audit systems + regarding fragmentation issues. + +4.1.1.5. Problems That Arise from the Size of the IP Fragments + + One approach to fragment filtering involves keeping track of the + results of applying filter rules to the first fragment (i.e., the + fragment with a Fragment Offset of 0), and applying them to + subsequent fragments of the same packet. The filtering module would + maintain a list of packets indexed by the Source Address, Destination + Address, Protocol, and Identification number. When the initial + fragment is seen, if the MF bit is set, a list item would be + allocated to hold the result of filter access checks. When packets + with a non-zero Fragment Offset come in, look up the list element + with a matching Source Address/Destination Address/Protocol/ + Identification and apply the stored result (pass or block). When a + fragment with a zero MF bit is seen, free the list element. + Unfortunately, the rules of this type of packet filter can usually be + bypassed. [RFC1858] describes the details of the involved technique. + +4.1.2. Possible Security Improvements + +4.1.2.1. Memory Allocation for Fragment Reassembly + + A design choice usually has to be made as to how to allocate memory + to reassemble the fragments of a given packet. There are basically + two options: + + + +Gont Informational [Page 53] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o Upon receipt of the first fragment, allocate a buffer that will be + large enough to concatenate the payload of each fragment. + + o Upon receipt of the first fragment, create the first node of a + linked list to which each of the following fragments will be + linked. When all fragments have been received, copy the IP + payload of each of the fragments (in the correct order) to a + separate buffer that will be handed to the protocol being + encapsulated in the IP payload. + + While the first of the choices might seem to be the most + straightforward, it implies that even when a single small fragment of + a given packet is received, the amount of memory that will be + allocated for that fragment will account for the size of the complete + IP datagram, thus using more system resources than what is actually + needed. + + Furthermore, the only situation in which the actual size of the whole + datagram will be known is when the last fragment of the packet is + received first, as that is the only packet from which the total size + of the IP datagram can be asserted. Otherwise, memory should be + allocated for the largest possible packet size (65535 bytes). + + The IP module should also enforce a limit on the amount of memory + that can be allocated for IP fragments, as well as a limit on the + number of fragments that at any time will be allowed in the system. + This will basically limit the resources spent on the reassembly + process, and prevent an attacker from trashing the whole system + memory. + + Furthermore, the IP module should keep a different buffer for IP + fragments than for complete IP datagrams. This will basically + separate the effects of fragment attacks on non-fragmented traffic. + Most TCP/IP implementations, such as that in Linux and those in BSD- + derived systems, already implement this. + + [Jones2002] analyzes the amount of memory that may be needed for the + fragment reassembly buffer depending on a number of network + characteristics. + +4.1.2.2. Flushing the Fragment Buffer + + In the case of those attacks that aim to consume the memory buffers + used for fragments, and those that aim to cause a collision of IP + Identification numbers, there are a number of countermeasures that + can be implemented. + + + + + +Gont Informational [Page 54] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Even with these countermeasures in place, there is still the issue of + what to do when the buffer pool used for IP fragments gets full. + Basically, if the fragment buffer is full, no instance of + communication that relies on fragmentation will be able to progress. + + Unfortunately, there are not many options for reacting to this + situation. If nothing is done, all the instances of communication + that rely on fragmentation will experience a denial of service. + Thus, the only thing that can be done is flush all or part of the + fragment buffer, on the premise that legitimate traffic will be able + to make use of the freed buffer space to allow communication flows to + progress. + + There are a number of factors that should be taken into consideration + when flushing the fragment buffers. First, if a fragment of a given + packet (i.e., fragment with a given Identification number) is + flushed, all the other fragments that correspond to the same datagram + should be flushed. As in order for a packet to be reassembled all of + its fragments must be received by the system performing the + reassembly function, flushing only a subset of the fragments of a + given packet would keep the corresponding buffers tied to fragments + that would never reassemble into a complete datagram. Additionally, + care must be taken so that, in the event that subsequent buffer + flushes need to be performed, it is not always the same set of + fragments that get dropped, as such a behavior would probably cause a + selective DoS to the traffic flows to which that set of fragments + belongs. + + Many TCP/IP implementations define a threshold for the number of + fragments that, when reached, triggers a fragment-buffer flush. Some + systems flush 1/2 of the fragment buffer when the threshold is + reached. As mentioned before, the idea of flushing the buffer is to + create some free space in the fragment buffer, on the premise that + this will allow for new and legitimate fragments to be processed by + the IP module, thus letting communication survive the overwhelming + situation. On the other hand, the idea of flushing a somewhat large + portion of the buffer is to avoid flushing always the same set of + packets. + +4.1.2.3. A More Selective Fragment Buffer Flushing Strategy + + One of the difficulties in implementing countermeasures for the + fragmentation attacks described throughout Section 4.1 is that it is + difficult to perform validation checks on the received fragments. + For instance, the fragment on which validity checks could be + performed, the first fragment, may be not the first fragment to + arrive at the destination host. + + + + +Gont Informational [Page 55] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Fragments cannot only arrive out of order because of packet + reordering performed by the network, but also because the system (or + systems) that fragmented the IP datagram may indeed transmit the + fragments out of order. A notable example of this is the Linux + TCP/IP stack, which transmits the fragments in reverse order. + + This means that we cannot enforce checks on the fragments for which + we allocate reassembly resources, as the first fragment we receive + for a given packet may be some other fragment than the first one (the + one with an Fragment Offset of 0). + + However, at the point in which we decide to free some space in the + fragment buffer, some refinements can be done to the flushing policy. + The first thing we would like to do is to stop different types of + traffic from interfering with each other. This means, in principle, + that we do not want fragmented UDP traffic to interfere with + fragmented TCP traffic. In order to implement this traffic + separation for the different protocols, a different fragment buffer + pool would be needed, in principle, for each of the 256 different + protocols that can be encapsulated in an IP datagram. + + We believe a trade-off is to implement two separate fragment buffers: + one for IP datagrams that encapsulate IPsec packets and another for + the rest of the traffic. This basically means that traffic not + protected by IPsec will not interfere with those flows of + communication that are being protected by IPsec. + + The processing of each of these two different fragment buffer pools + would be completely independent from each other. In the case of the + IPsec fragment buffer pool, when the buffers needs to be flushed, the + following refined policy could be applied: + + o First, for each packet for which the IPsec header has been + received, check that the Security Parameters Index (SPI) field of + the IPsec header corresponds to an existing IPsec Security + Association (SA), and probably also check that the IPsec sequence + number is valid. If the check fails, drop all the fragments that + correspond to this packet. + + o Second, if still more fragment buffers need to be flushed, drop + all the fragments that correspond to packets for which the full + IPsec header has not yet been received. The number of packets for + which this flushing is performed depends on the amount of free + space that needs to be created. + + o Third, if after flushing packets with invalid IPsec information + (First step), and packets on which validation checks could not be + performed (Second step), there is still not enough space in the + + + +Gont Informational [Page 56] + +RFC 6274 IPv4 Security Assessment July 2011 + + + fragment buffer, drop all the fragments that correspond to packets + that passed the checks of the first step, until the necessary free + space is created. + + The rationale behind this policy is that, at the point of flushing + fragment buffers, we prefer to keep those packets on which we could + successfully perform a number of validation checks, over those + packets on which those checks failed, or the checks could not even be + performed. + + By checking both the IPsec SPI and the IPsec sequence number, it is + virtually impossible for an attacker that is off-path to perform a + DoS attack to communication flows being protected by IPsec. + + Unfortunately, some IP implementations (such as that in Linux + [Linux]), when performing fragmentation, send the corresponding + fragments in reverse order. In such cases, at the point of flushing + the fragment buffer, legitimate fragments will receive the same + treatment as the possible forged fragments. + + This refined flushing policy provides an increased level of + protection against this type of resource exhaustion attack, while not + making the situation of out-of-order IPsec-secured traffic worse than + with the simplified flushing policy described in the previous + section. + +4.1.2.4. Reducing the Fragment Timeout + + RFC 1122 [RFC1122] states that the reassembly timeout should be a + fixed value between 60 and 120 seconds. The rationale behind these + long timeout values is that they should accommodate any path + characteristics, such as long-delay paths. However, it must be noted + that this timer is really measuring inter-fragment delays, or, more + specifically, fragment jitter. + + If all fragments take paths of similar characteristics, the inter- + fragment delay will usually be, at most, a few seconds. + Nevertheless, even if fragments take different paths of different + characteristics, the recommended 60 to 120 seconds are, in practice, + excessive. + + Some systems have already reduced the fragment timeout to 30 seconds + [Linux]. The fragment timeout could probably be further reduced to + approximately 15 seconds; although further research on this issue is + necessary. + + + + + + +Gont Informational [Page 57] + +RFC 6274 IPv4 Security Assessment July 2011 + + + It should be noted that in network scenarios of long-delay and high- + bandwidth (usually referred to as "Long-Fat Networks"), using a long + fragment timeout would likely increase the probability of collision + of IP ID numbers. Therefore, in such scenarios it is highly + desirable to avoid the use of fragmentation with techniques such as + PMTUD [RFC1191] or PLPMTUD [RFC4821]. + +4.1.2.5. Countermeasure for Some NIDS Evasion Techniques + + [Shankar2003] introduces a technique named "Active Mapping" that + prevents evasion of a NIDS by acquiring sufficient knowledge about + the network being monitored, to assess which packets will arrive at + the intended recipient, and how they will be interpreted by it. + [Novak2005] describes some techniques that are applied by the Snort + [Snort] NIDS to avoid evasion. + +4.1.2.6. Countermeasure for Firewall-Rules Bypassing + + One of the classical techniques to bypass firewall rules involves + sending packets in which the header of the encapsulated protocol is + fragmented. Even when it would be legal (as far as the IETF + specifications are concerned) to receive such a packets, the MTUs of + the network technologies used in practice are not that small to + require the header of the encapsulated protocol to be fragmented + (e.g., see [RFC2544]). Therefore, the system performing reassembly + should drop all packets which fragment the upper-layer protocol + header, and this event should be logged (e.g., a counter could be + incremented to reflect the packet drop). + + Additionally, given that many middle-boxes such as firewalls create + state according to the contents of the first fragment of a given + packet, it is best that, in the event an end-system receives + overlapping fragments, it honors the information contained in the + fragment that was received first. + + RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass + firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. + +4.2. Forwarding + +4.2.1. Precedence-Ordered Queue Service + + Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should + implement precedence-ordered queue service. This means that when a + packet is selected for output on a (logical) link, the packet of + highest precedence that has been queued for that link is sent. + Section 5.3.3.2 of RFC 1812 advises routers to default to maintaining + strict precedence-ordered service. + + + +Gont Informational [Page 58] + +RFC 6274 IPv4 Security Assessment July 2011 + + + Unfortunately, given that it is trivial to forge the IP precedence + field of the IP header, an attacker could simply forge a high + precedence number in the packets it sends to illegitimately get + better network service. If precedence-ordered queued service is not + required in a particular network infrastructure, it should be + disabled, and thus all packets would receive the same type of + service, despite the values in their Type of Service or + Differentiated Services fields. + + When precedence-ordered queue service is required in the network + infrastructure, in order to mitigate the attack vector discussed in + the previous paragraph, edge routers or switches should be configured + to police and remark the Type of Service or Differentiated Services + values, according to the type of service at which each end-system has + been allowed to send packets. + + Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT + change precedence settings on packets it did not originate". + However, given the security implications of the Precedence field, it + is fair for routers, switches, or other middle-boxes, particularly + those in the network edge, to overwrite the Type of Service (or + Differentiated Services) field of the packets they are forwarding, + according to a configured network policy (this is the specified + behavior for DS domains [RFC2475]). + + Sections 5.3.3.1 and 5.3.6 of RFC 1812 state that if precedence- + ordered queue service is implemented and enabled, the router "MUST + NOT discard a packet whose precedence is higher than that of a packet + that is not discarded". While this recommendation makes sense given + the semantics of the Precedence field, it is important to note that + it would be simple for an attacker to send packets with forged high + Precedence value to congest some internet router(s), and cause all + (or most) traffic with a lower Precedence value to be discarded. + +4.2.2. Weak Type of Service + + Section 5.2.4.3 of RFC 1812 describes the algorithm for determining + the next-hop address (i.e., the forwarding algorithm). Bullet 3, + "Weak TOS", addresses the case in which routes contain a "type of + service" attribute. It states that in case a packet contains a non- + default TOS (i.e., 0000), only routes with the same TOS or with the + default TOS should be considered for forwarding that packet. + However, this means that if among the longest match routes for a + given packet are routes with some TOS other than the one contained in + the received packet, and no routes with the default TOS, the + corresponding packet would be dropped. This may or may not be a + desired behavior. + + + + +Gont Informational [Page 59] + +RFC 6274 IPv4 Security Assessment July 2011 + + + An alternative for the case in which among the "longest match" routes + there are only routes with non-default type of service that do not + match the TOS contained in the received packet, would be to use a + route with any other TOS. While this route would most likely not be + able to address the type of service requested by packet, it would, at + least, provide a "best effort" service. + + It must be noted that Section 5.3.2 of RFC 1812 allows routers to not + honor the TOS field. Therefore, the proposed alternative behavior is + still compliant with the IETF specifications. + + While officially specified in the RFC series, TOS-based routing is + not widely deployed in the Internet. + +4.2.3. Impact of Address Resolution on Buffer Management + + In the case of broadcast link-layer technologies, in order for a + system to transfer an IP datagram it must usually first map an IP + address to the corresponding link-layer address (for example, by + means of the Address Resolution Protocol (ARP) [RFC0826]) . This + means that while this operation is being performed, the packets that + would require such a mapping would need to be kept in memory. This + may happen both in the case of hosts and in the case of routers. + + This situation might be exploited by an attacker, which could send a + large amount of packets to a non-existent host that would supposedly + be directly connected to the attacked router. While trying to map + the corresponding IP address into a link-layer address, the attacked + router would keep in memory all the packets that would need to make + use of that link-layer address. At the point in which the mapping + function times out, depending on the policy implemented by the + attacked router, only the packet that triggered the call to the + mapping function might be dropped. In that case, the same operation + would be repeated for every packet destined to the non-existent host. + Depending on the timeout value for the mapping function, this + situation might lead the router to run out of free buffer space, with + the consequence that incoming legitimate packets would have to be + dropped, or that legitimate packets already stored in the router's + buffers might get dropped. Both of these situations would lead + either to a complete DoS or to a degradation of the network service. + + One countermeasure to this problem would be to drop, at the point the + mapping function times out, all the packets destined to the address + that timed out. In addition, a "negative cache entry" might be kept + in the module performing the matching function, so that for some + amount of time, the mapping function would return an error when the + IP module requests to perform a mapping for some address for which + the mapping has recently timed out. + + + +Gont Informational [Page 60] + +RFC 6274 IPv4 Security Assessment July 2011 + + + A common implementation strategy for routers is that when a packet + is received that requires an ARP resolution to be performed before + the packet can be forwarded, the packet is dropped and the router + is then engaged in the ARP procedure. + +4.2.4. Dropping Packets + + In some scenarios, it may be necessary for a host or router to drop + packets from the output queue. In the event that one of such packets + happens to be an IP fragment, and there were other fragments of the + same packet in the queue, those other fragments should also be + dropped. The rationale for this policy is that it is nonsensical to + spend system resources on those other fragments, because, as long as + one fragment is missing, it will be impossible for the receiving + system to reassemble them into a complete IP datagram. + + Some systems have been known to drop just a subset of fragments of a + given datagram, leading to a denial-of-service condition, as only a + subset of all the fragments of the packets were actually transferred + to the next hop. + +4.3. Addressing + +4.3.1. Unreachable Addresses + + It is important to understand that while there are some addresses + that are supposed to be unreachable from the public Internet (such as + the private IP addresses described in RFC 1918 [RFC1918], or the + "loopback" address), there are a number of tricks an attacker can + perform to reach those IP addresses that would otherwise be + unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore, + when applicable, packet filtering should be performed at the private + network boundary to assure that those addresses will be unreachable. + + Similarly, link-local unicast addresses [RFC3927] and multicast + addresses with limited scope (link- and site-local addresses) should + not be accessible from outside the proper network boundaries and not + be passed across these boundaries. + + [RFC5735] provides a summary of special use IPv4 addresses. + +4.3.2. Private Address Space + + The Internet Assigned Numbers Authority (IANA) has reserved the + following three blocks of the IP address space for private internets: + + o 10.0.0.0 - 10.255.255.255 (10/8 prefix) + + + + +Gont Informational [Page 61] + +RFC 6274 IPv4 Security Assessment July 2011 + + + o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) + + o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) + + Use of these address blocks is described in RFC 1918 [RFC1918]. + + Where applicable, packet filtering should be performed at the + organizational perimeter to assure that these addresses are not + reachable from outside the private network where such addresses are + employed. + +4.3.3. Former Class D Addresses (224/4 Address Block) + + The former Class D addresses correspond to the 224/4 address block + and are used for Internet multicast. Therefore, if a packet is + received with a "Class D" address as the Source Address, it should be + dropped, and this event should be logged (e.g., a counter could be + incremented to reflect the packet drop). Additionally, if an IP + packet with a multicast Destination Address is received for a + connection-oriented protocol (e.g., TCP), the packet should be + dropped (see Section 4.3.5), and this event should be logged (e.g., a + counter could be incremented to reflect the packet drop). + +4.3.4. Former Class E Addresses (240/4 Address Block) + + The former Class E addresses correspond to the 240/4 address block, + and are currently reserved for experimental use. As a result, a most + routers discard packets that contain a "Class" E address as the + Source Address or Destination Address. If a packet is received with + a 240/4 address as the Source Address and/or the Destination Address, + the packet should be dropped and this event should be logged (e.g., a + counter could be incremented to reflect the packet drop). + + It should be noted that the broadcast address 255.255.255.255 still + must be treated as indicated in Section 4.3.7 of this document. + +4.3.5. Broadcast/Multicast Addresses and Connection-Oriented Protocols + + For connection-oriented protocols, such as TCP, shared state is + maintained between only two endpoints at a time. Therefore, if an IP + packet with a multicast (or broadcast) Destination Address is + received for a connection-oriented protocol (e.g., TCP), the packet + should be dropped, and this event should be logged (e.g., a counter + could be incremented to reflect the packet drop). + + + + + + + +Gont Informational [Page 62] + +RFC 6274 IPv4 Security Assessment July 2011 + + +4.3.6. Broadcast and Network Addresses + + Originally, the IETF specifications did not permit IP addresses to + have the value 0 or -1 (shorthand for all bits set to 1) for any of + the Host number, network number, or subnet number fields, except for + the cases indicated in Section 4.3.7. However, this changed + fundamentally with the deployment of Classless Inter-Domain Routing + (CIDR) [RFC4632], as with CIDR a system cannot know a priori what the + subnet mask is for a particular IP address. + + Many systems now allow administrators to use the values 0 or -1 for + those fields. Despite that according to the original IETF + specifications these addresses are illegal, modern IP implementations + should consider these addresses to be valid. + +4.3.7. Special Internet Addresses + + RFC 1812 [RFC1812] discusses the use of some special Internet + addresses, which is of interest to perform some sanity checks on the + Source Address and Destination Address fields of an IP packet. It + uses the following notation for an IP address: + + { <Network-prefix>, <Host-number> } + + where the length of the network prefix is generally implied by the + network mask assigned to the IP interface under consideration. + + RFC 1122 [RFC1122] contained a similar discussion of special + Internet addresses, including some of the form { <Network-prefix>, + <Subnet-number>, <Host-number> }. However, as explained in + Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number + is clearly an extension of the network prefix and cannot be + distinguished from the remainder of the prefix. + + {0, 0} + + This address means "this host on this network". It is meant to be + used only during the initialization procedure, by which the host + learns its own IP address. + + If a packet is received with 0.0.0.0 as the Source Address for any + purpose other than bootstrapping, the corresponding packet should be + silently dropped, and this event should be logged (e.g., a counter + could be incremented to reflect the packet drop). If a packet is + received with 0.0.0.0 as the Destination Address, it should be + silently dropped, and this event should be logged (e.g., a counter + could be incremented to reflect the packet drop). + + + + +Gont Informational [Page 63] + +RFC 6274 IPv4 Security Assessment July 2011 + + + {0, Host number} + + This address means "the specified host, in this network". As in the + previous case, it is meant to be used only during the initialization + procedure by which the host learns its own IP address. If a packet + is received with such an address as the Source Address for any + purpose other than bootstrapping, it should be dropped, and this + event should be logged (e.g., a counter could be incremented to + reflect the packet drop). If a packet is received with such an + address as the Destination Address, it should be dropped, and this + event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + {-1, -1} + + This address is the local broadcast address. It should not be used + as a source IP address. If a packet is received with 255.255.255.255 + as the Source Address, it should be dropped, and this event should be + logged (e.g., a counter could be incremented to reflect the packet + drop). + + Some systems, when receiving an ICMP echo request, for example, + will use the Destination Address in the ICMP echo request packet + as the Source Address of the response they send (in this case, an + ICMP echo reply). Thus, when such systems receive a request sent + to a broadcast address, the Source Address of the response will + contain a broadcast address. This should be considered a bug, + rather than a malicious use of the limited broadcast address. + + {Network number, -1} + + This is the directed broadcast to the specified network. As + recommended by RFC 2644 [RFC2644], routers should not forward + network-directed broadcasts. This avoids the corresponding network + from being utilized as, for example, a "smurf amplifier" [CERT1998a]. + + As noted in Section 4.3.6 of this document, many systems now allow + administrators to configure these addresses as unicast addresses for + network interfaces. In such scenarios, routers should forward these + addresses as if they were traditional unicast addresses. + + In some scenarios, a host may have knowledge about a particular IP + address being a network-directed broadcast address, rather than a + unicast address (e.g., that IP address is configured on the local + system as a "broadcast address"). In such scenarios, if a system can + infer that the Source Address of a received packet is a network- + + + + + +Gont Informational [Page 64] + +RFC 6274 IPv4 Security Assessment July 2011 + + + directed broadcast address, the packet should be dropped, and this + event should be logged (e.g., a counter could be incremented to + reflect the packet drop). + + As noted in Section 4.3.6 of this document, with the deployment of + CIDR [RFC4632], it may be difficult for a system to infer whether a + particular IP address that does not belong to a directly attached + subnet is a broadcast address. + + {127.0.0.0/8, any} + + This is the internal host loopback address. Any packet that arrives + on any physical interface containing this address as the Source + Address, the Destination Address, or as part of a source route + (either LSRR or SSRR), should be dropped. + + For example, packets with a Destination Address in the 127.0.0.0/8 + address block that are received on an interface other than loopback + should be silently dropped. Packets received on any interface other + than loopback with a Source Address corresponding to the system + receiving the packet should also be dropped. + + In all the above cases, when a packet is dropped, this event should + be logged (e.g., a counter could be incremented to reflect the packet + drop). + +5. Security Considerations + + This document discusses the security implications of the Internet + 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, 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. + + + +Gont Informational [Page 65] + +RFC 6274 IPv4 Security Assessment July 2011 + + + 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. + + The author would like to thank Randall Atkinson and Roque Gagliano, + who generously answered a number of questions. + + Finally, the author would like to thank UK CPNI (formerly NISCC) for + their continued support. + +7. References + +7.1. Normative References + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or + converting network protocol addresses to 48.bit Ethernet + address for transmission on Ethernet hardware", STD 37, + RFC 826, November 1982. + + [RFC1038] St. Johns, M., "Draft revised IP security option", + RFC 1038, January 1988. + + [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP + MTU discovery options", RFC 1063, July 1988. + + [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, August 1989. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + November 1990. + + [RFC1349] Almquist, P., "Type of Service in the Internet Protocol + Suite", RFC 1349, July 1992. + + [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, + January 1993. + + [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- + Destination Delivery", RFC 1770, March 1995. + + + +Gont Informational [Page 66] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, December 1998. + + [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts + in Routers", BCP 34, RFC 2644, August 1999. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, September 2001. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + May 2005. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing + (CIDR): The Internet Address Assignment and Aggregation + Plan", BCP 122, RFC 4632, August 2006. + + + + + +Gont Informational [Page 67] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, March 2007. + + [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. + Pignataro, "The Generalized TTL Security Mechanism + (GTSM)", RFC 5082, October 2007. + + [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the + IPv4 and IPv6 Router Alert Options", RFC 5350, + September 2008. + + [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", + BCP 153, RFC 5735, January 2010. + + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, November 2010. + +7.2. Informative References + + [Anderson2001] + Anderson, J., "An Analysis of Fragmentation Attacks", + 2001, <http://www.ouah.org/fragma.html>. + + [Arkin2000] + Arkin, "IP TTL Field Value with ICMP (Oops - Identifying + Windows 2000 again and more)", 2000, + <http://ofirarkin.files.wordpress.com/2008/11/ + ofirarkin2000-06.pdf>. + + [Barisani2006] + Barisani, A., "FTester - Firewall and IDS testing tool", + 2001, <http://dev.inversepath.com/trac/ftester>. + + [Bellovin1989] + Bellovin, S., "Security Problems in the TCP/IP Protocol + Suite", Computer Communication Review Vol. 19, No. 2, pp. + 32-48, 1989. + + [Bellovin2002] + Bellovin, S., "A Technique for Counting NATted Hosts", + IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. + + [Bendi1998] + Bendi, "Bonk exploit", 1998, + <http://www.insecure.org/sploits/ + 95.NT.fragmentation.bonk.html>. + + + + + +Gont Informational [Page 68] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [Biondi2007] + Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", + CanSecWest 2007 Security Conference, 2007, + <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>. + + [CERT1996a] + CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- + Service Attack", 1996, + <http://www.cert.org/advisories/CA-1996-01.html>. + + [CERT1996b] + CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP + Spoofing Attacks", 1996, + <http://www.cert.org/advisories/CA-1996-21.html>. + + [CERT1996c] + CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack + via ping", 1996, + <http://www.cert.org/advisories/CA-1996-26.html>. + + [CERT1997] CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service + Attacks", 1997, + <http://www.cert.org/advisories/CA-1997-28.html>. + + [CERT1998a] + CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- + Service Attacks", 1998, + <http://www.cert.org/advisories/CA-1998-01.html>. + + [CERT1998b] + CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain + TCP/IP Implementations", 1998, + <http://www.cert.org/advisories/CA-1998-13.html>. + + [CERT1999] CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", + 1999, <http://www.cert.org/advisories/CA-1999-17.html>. + + [CERT2003] CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface + Blocked by IPv4 Packet", 2003, + <http://www.cert.org/advisories/CA-2003-15.html>. + + [CIPSO1992] + CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work + in Progress, 1992. + + + + + + + +Gont Informational [Page 69] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [CIPSOWG1994] + CIPSOWG, "Commercial Internet Protocol Security Option + (CIPSO) Working Group", 1994, <http://www.ietf.org/ + proceedings/94jul/charters/cipso-charter.html>. + + [CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", + 2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>. + + [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", 2003, <http://www.cisco.com/en/ + US/products/ + products_security_advisory09186a00801a34c2.shtml>. + + [Cisco2008] + Cisco, "Cisco IOS Security Configuration Guide, Release + 12.2", 2003, <http://www.cisco.com/en/US/docs/ios/12_2/ + security/configuration/guide/scfipso.html>. + + [Clark1988] + Clark, D., "The Design Philosophy of the DARPA Internet + Protocols", Computer Communication Review Vol. 18, No. 4, + 1988. + + [Ed3f2002] Ed3f, "Firewall spotting and networks analysis with a + broken CRC", Phrack Magazine, Volume 0x0b, Issue + 0x3c, Phile #0x0c of 0x10, 2002, <http://www.phrack.org/ + issues.html?issue=60&id=12&mode=txt>. + + [FIPS1994] FIPS, "Standard Security Label for Information Transfer", + Federal Information Processing Standards Publication. FIP + PUBS 188, 1994, <http://csrc.nist.gov/publications/fips/ + fips188/fips188.pdf>. + + [Fyodor2004] + Fyodor, "Idle scanning and related IP ID games", 2004, + <http://www.insecure.org/nmap/idlescan.html>. + + [GIAC2000] GIAC, "Egress Filtering v 0.2", 2000, + <http://www.sans.org/y2k/egress.htm>. + + [Gont2006] Gont, F., "Advanced ICMP packet filtering", 2006, + <http://www.gont.com.ar/papers/icmp-filtering.html>. + + + +Gont Informational [Page 70] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [Haddad2004] + Haddad, I. and M. Zakrzewski, "Security Distribution for + Linux Clusters", Linux Journal, 2004, + <http://www.linuxjournal.com/article/6943>. + + [Humble1998] + Humble, "Nestea exploit", 1998, + <http://www.insecure.org/sploits/ + linux.PalmOS.nestea.html>. + + [IANA_ET] IANA, "Ether Types", + <http://www.iana.org/assignments/ethernet-numbers>. + + [IANA_IP_PARAM] + IANA, "IP Parameters", + <http://www.iana.org/assignments/ip-parameters>. + + [IANA_PROT_NUM] + IANA, "Protocol Numbers", + <http://www.iana.org/assignments/protocol-numbers>. + + [IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008, + <http://techpubs.sgi.com/library/tpl/cgi-bin/ + getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ + cat7/trusted_networking.z>. + + [Jones2002] + Jones, R., "A Method Of Selecting Values For the + Parameters Controlling IP Fragment Reassembly", 2002, + <ftp://ftp.cup.hp.com/dist/networking/briefs/ + ip_reass_tuning.txt>. + + [Kenney1996] + Kenney, M., "The Ping of Death Page", 1996, + <http://www.insecure.org/sploits/ping-o-death.html>. + + [Kent1987] Kent, C. and J. Mogul, "Fragmentation considered harmful", + Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987. + + [Klein2007] + Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S + Predictable IP ID Vulnerability", 2007, + <http://www.trusteer.com/files/ + OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP + _ID_Vulnerability.pdf>. + + + + + + +Gont Informational [Page 71] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [Kohno2005] + Kohno, T., Broido, A., and kc. Claffy, "Remote Physical + Device Fingerprinting", IEEE Transactions on Dependable + and Secure Computing Vol. 2, No. 2, 2005. + + [LBNL2006] LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>. + + [Linux] Linux Kernel Organization, "The Linux Kernel Archives", + <http://www.kernel.org>. + + [Microsoft1999] + Microsoft, "Microsoft Security Program: Microsoft Security + Bulletin (MS99-038). Patch Available for "Spoofed Route + Pointer" Vulnerability", 1999, <http://www.microsoft.com/ + technet/security/bulletin/ms99-038.mspx>. + + [NISCC2004] + NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability + Issues in TCP", 2004, <http://www.cpni.gov.uk>. + + [NISCC2005] + NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: + Vulnerability Issues in ICMP packets with TCP payloads", + 2005, <http://www.gont.com.ar/advisories/index.html>. + + [NISCC2006] + NISCC, "NISCC Technical Note 01/2006: Egress and Ingress + Filtering", 2006, <http://www.cpni.gov.uk>. + + [Northcutt2000] + Northcut, S. and Novak, "Network Intrusion Detection - An + Analyst's Handbook", Second Edition New Riders Publishing, + 2000. + + [Novak2005] + Novak, "Target-Based Fragmentation Reassembly", 2005, + <http://www.snort.org/assets/165/target_based_frag.pdf>. + + [OpenBSD-PF] + Sanfilippo, S., "PF: Scrub (Packet Normalization)", 2010, + <ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>. + + [OpenBSD1998] + OpenBSD, "OpenBSD Security Advisory: IP Source Routing + Problem", 1998, + <http://www.openbsd.org/advisories/sourceroute.txt>. + + + + + +Gont Informational [Page 72] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [Paxson2001] + Paxson, V., Handley, M., and C. Kreibich, "Network + Intrusion Detection: Evasion, Traffic Normalization, and + End-to-End Protocol Semantics", USENIX Conference, 2001. + + [Ptacek1998] + Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial + of Service: Eluding Network Intrusion Detection", 1998, + <http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>. + + [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, + July 1982. + + [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security + Considerations for IP Fragment Filtering", RFC 1858, + October 1995. + + [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, March 1999. + + [RFC3128] Miller, I., "Protection Against a Variant of the Tiny + Fragment Attack (RFC 1858)", RFC 3128, June 2001. + + [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., + Beame, C., Eisler, M., and D. Noveck, "Network File System + (NFS) version 4 Protocol", RFC 3530, April 2003. + + [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly + Errors at High Data Rates", RFC 4963, July 2007. + + [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common + Mitigations", RFC 4987, August 2007. + + [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) + Architecture", RFC 5559, June 2009. + + [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common + 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. + + + +Gont Informational [Page 73] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [ROUTER-ALERT] + Le Faucheur, F., Ed., "IP Router Alert Considerations and + Usage", Work in Progress, June 2011. + + [SELinux2009] + NSA, "Security-Enhanced Linux", + <http://www.nsa.gov/research/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>. + + [Sanfilippo1998b] + Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, + 1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>. + + [Sanfilippo1999] + Sanfilippo, S., "more ip id", Post to Bugtraq mailing- + list, 1999, + <http://www.kyuzz.org/antirez/papers/moreipid.html>. + + [Shankar2003] + Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS + Evasion Without Altering Traffic", 2003, + <http://www.icir.org/vern/papers/activemap-oak03.pdf>. + + [Shannon2001] + Shannon, C., Moore, D., and K. Claffy, "Characteristics of + Fragmented IP Traffic on Internet Links", 2001. + + [Silbersack2005] + Silbersack, M., "Improving TCP/IP security through + randomization without sacrificing interoperability", + EuroBSDCon 2005 Conference, 2005, + <http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>. + + [Snort] Sourcefire, Inc., "Snort", <http://www.snort.org>. + + [Solaris2007] + Oracle, "ORACLE SOLARIS WITH TRUSTED EXTENSIONS", 2007, <h + ttp://www.oracle.com/us/products/servers-storage/solaris/ + solaris-trusted-ext-ds-075583.pdf>. + + [Song1999] Song, D., "Frag router tool", + <http://www.monkey.org/~dugsong/fragroute/>. + + + + + +Gont Informational [Page 74] + +RFC 6274 IPv4 Security Assessment July 2011 + + + [SpooferProject] + MIT ANA, "Spoofer Project", 2010, + <http://spoofer.csail.mit.edu/index.php>. + + [US-CERT2001] + US-CERT, "US-CERT Vulnerability Note VU#446689: Check + Point FireWall-1 allows fragmented packets through + firewall if Fast Mode is enabled", 2001, + <http://www.kb.cert.org/vuls/id/446689>. + + [US-CERT2002] + US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS + discloses fragments of previous packets when Express + Forwarding is enabled", 2002. + + [Watson2004] + Watson, P., "Slipping in the Window: TCP Reset Attacks", + CanSecWest Conference, 2004. + + [Zakrzewski2002] + Zakrzewski, M. and I. Haddad, "Linux Distributed Security + Module", 2002, <http://www.linuxjournal.com/article/6215>. + + [daemon91996] + daemon9, route, and infinity, "IP-spoofing Demystified + (Trust-Relationship Exploitation)", Phrack Magazine, + Volume Seven, Issue Forty-Eight, File 14 of 18, 1988, <htt + p://www.phrack.org/issues.html?issue=48&id=14&mode=txt>. + +Author's Address + + Fernando Gont + UK Centre for the Protection of National Infrastructure + + EMail: fernando@gont.com.ar + URI: http://www.cpni.gov.uk + + + + + + + + + + + + + + + +Gont Informational [Page 75] + |