idnits 2.17.1 draft-ietf-opsec-ip-security-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 8, 2011) is 4759 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CERT2001' is defined on line 3253, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-mtuassurance' is defined on line 3338, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 3454, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3457, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 3467, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1038 (Obsoleted by RFC 1108) ** Obsolete normative reference: RFC 1063 (Obsoleted by RFC 1191) ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 1770 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-10) exists of draft-ietf-intarea-router-alert-considerations-03 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 5696 (Obsoleted by RFC 6660) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) UK CPNI 4 Internet-Draft April 8, 2011 5 Intended status: Informational 6 Expires: October 10, 2011 8 Security Assessment of the Internet Protocol version 4 9 draft-ietf-opsec-ip-security-07.txt 11 Abstract 13 This document contains a security assessment of the IETF 14 specifications of the Internet Protocol version 4, and of a number of 15 mechanisms and policies in use by popular IPv4 implementations. It 16 is based on the results of a project carried out by the UK's Centre 17 for the Protection of National Infrastructure (CPNI). 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 10, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 56 1.3. Organization of this document . . . . . . . . . . . . . . 8 57 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8 58 3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 9 59 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10 61 3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11 62 3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11 63 3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12 64 3.3.2.1. Differentiated Services field . . . . . . . . . . 12 65 3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13 66 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 15 67 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16 68 3.5.1. Some Workarounds Implemented by the Industry . . . . . 17 69 3.5.2. Possible security improvements . . . . . . . . . . . . 17 70 3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17 71 3.5.2.2. Connectionless Transport Protocols . . . . . . . 18 72 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 22 74 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 23 75 3.8.1. Fingerprinting the operating system in use by the 76 source host . . . . . . . . . . . . . . . . . . . . . 25 77 3.8.2. Fingerprinting the physical device from which the 78 packets originate . . . . . . . . . . . . . . . . . . 25 79 3.8.3. Mapping the Network Topology . . . . . . . . . . . . . 25 80 3.8.4. Locating the source host in the network topology . . . 26 81 3.8.5. Evading Network Intrusion Detection Systems . . . . . 27 82 3.8.6. Improving the security of applications that make 83 use of the Internet Protocol (IP) . . . . . . . . . . 28 84 3.8.7. Limiting spread . . . . . . . . . . . . . . . . . . . 29 85 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 29 87 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 29 88 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 30 89 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 3.13.1. General issues with IP options . . . . . . . . . . . . 32 91 3.13.1.1. Processing requirements . . . . . . . . . . . . . 32 92 3.13.1.2. Processing of the options by the upper layer 93 protocol . . . . . . . . . . . . . . . . . . . . 33 94 3.13.1.3. General sanity checks on IP options . . . . . . . 33 95 3.13.2. Issues with specific options . . . . . . . . . . . . . 35 96 3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 35 97 3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 35 98 3.13.2.3. Loose Source and Record Route (LSRR) 99 (Type=131) . . . . . . . . . . . . . . . . . . . 35 100 3.13.2.4. Strict Source and Record Route (SSRR) 101 (Type=137) . . . . . . . . . . . . . . . . . . . 38 102 3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 40 103 3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 41 104 3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 41 105 3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 44 106 3.13.2.9. Probe MTU (Type=11) (obsolete) . . . . . . . . . 45 107 3.13.2.10. Reply MTU (Type=12) (obsolete) . . . . . . . . . 45 108 3.13.2.11. Traceroute (Type=82) . . . . . . . . . . . . . . 45 109 3.13.2.12. DoD Basic Security Option (Type=130) . . . . . . 45 110 3.13.2.13. DoD Extended Security Option (Type=133) . . . . . 47 111 3.13.2.14. Commercial IP Security Option (CIPSO) 112 (Type=134) . . . . . . . . . . . . . . . . . . . 47 113 3.13.2.15. Sender Directed Multi-Destination Delivery 114 (Type=149) . . . . . . . . . . . . . . . . . . . 48 115 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 48 116 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 48 117 4.1.1. Security Implications of Fragment Reassembly . . . . . 49 118 4.1.1.1. Problems related with memory allocation . . . . . 49 119 4.1.1.2. Problems that arise from the length of the IP 120 Identification field . . . . . . . . . . . . . . 51 121 4.1.1.3. Problems that arise from the complexity of 122 the reassembly algorithm . . . . . . . . . . . . 52 123 4.1.1.4. Problems that arise from the ambiguity of the 124 reassembly process . . . . . . . . . . . . . . . 52 125 4.1.1.5. Problems that arise from the size of the IP 126 fragments . . . . . . . . . . . . . . . . . . . . 54 127 4.1.2. Possible security improvements . . . . . . . . . . . . 54 128 4.1.2.1. Memory allocation for fragment reassembly . . . . 54 129 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 55 130 4.1.2.3. A more selective fragment buffer flushing 131 strategy . . . . . . . . . . . . . . . . . . . . 56 132 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 58 133 4.1.2.5. Countermeasure for some IDS evasion techniques . 58 134 4.1.2.6. Countermeasure for firewall-rules bypassing . . . 58 135 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 59 136 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 59 137 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 60 138 4.2.3. Impact of Address Resolution on Buffer Management . . 60 139 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 61 140 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 61 141 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 62 142 4.3.2. Private address space . . . . . . . . . . . . . . . . 62 143 4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 62 144 4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 63 145 4.3.5. Broadcast/Multicast addresses, and 146 Connection-Oriented Protocols . . . . . . . . . . . . 63 147 4.3.6. Broadcast and network addresses . . . . . . . . . . . 63 148 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 63 149 5. Security Considerations . . . . . . . . . . . . . . . . . . . 66 150 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 151 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 152 7.1. Normative References . . . . . . . . . . . . . . . . . . . 66 153 7.2. Informative References . . . . . . . . . . . . . . . . . . 68 154 Appendix A. Changes from previous versions of the draft . . . . . 76 155 A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 76 156 A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 77 157 A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 77 158 A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 77 159 A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 77 160 A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77 161 A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77 162 A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77 163 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 78 165 1. Preface 167 1.1. Introduction 169 The TCP/IP protocols were conceived in an environment that was quite 170 different from the hostile environment in which they currently 171 operate. However, the effectiveness of the protocols led to their 172 early adoption in production environments, to the point that, to some 173 extent, the current world's economy depends on them. 175 While many textbooks and articles have created the myth that the 176 Internet protocols were designed for warfare environments, the top 177 level goal for the DARPA Internet Program was the sharing of large 178 service machines on the ARPANET [Clark1988]. As a result, many 179 protocol specifications focus only on the operational aspects of the 180 protocols they specify, and overlook their security implications. 182 While the Internet technology evolved since its inception, the 183 Internet's building blocks are basically the same core protocols 184 adopted by the ARPANET more than two decades ago. During the last 185 twenty years, many vulnerabilities have been identified in the TCP/IP 186 stacks of a number of systems. Some of them were based on flaws in 187 some protocol implementations, affecting only a reduced number of 188 systems, while others were based on flaws in the protocols 189 themselves, affecting virtually every existing implementation 190 [Bellovin1989]. Even in the last couple of years, researchers were 191 still working on security problems in the core protocols [RFC5927] 192 [Watson2004] [NISCC2004] [NISCC2005]. 194 The discovery of vulnerabilities in the TCP/IP protocols led to 195 reports being published by a number of CSIRTs (Computer Security 196 Incident Response Teams) and vendors, which helped to raise awareness 197 about the threats and the best mitigations known at the time the 198 reports were published. Unfortunately, this also led to the 199 documentation of the discovered protocol vulnerabilities being spread 200 among a large number of documents, which are sometimes difficult to 201 identify. 203 For some reason, much of the effort of the security community on the 204 Internet protocols did not result in official documents (RFCs) being 205 issued by the IETF (Internet Engineering Task Force). This basically 206 led to a situation in which "known" security problems have not always 207 been addressed by all vendors. In addition, in many cases vendors 208 have implemented quick "fixes" to protocol flaws without a careful 209 analysis of their effectiveness and their impact on interoperability 210 [Silbersack2005]. 212 The lack of adoption of these fixes by the IETF means that any system 213 built in the future according to the official TCP/IP specifications 214 will reincarnate security flaws that have already hit our 215 communication systems in the past. 217 Producing a secure TCP/IP implementation nowadays is a very difficult 218 task, in part because of the lack of a single document that serves as 219 a security roadmap for the protocols. Implementers are faced with 220 the hard task of identifying relevant documentation and differentiate 221 between that which provides correct advisory, and that which provides 222 misleading advisory based on inaccurate or wrong assumptions. 224 There is a clear need for a companion document to the IETF 225 specifications that discusses the security aspects and implications 226 of the protocols, identifies the possible threats, discusses the 227 possible countermeasures, and analyzes their respective 228 effectiveness. 230 This document is the result of an assessment of the IETF 231 specifications of the Internet Protocol version 4 (IPv4), from a 232 security point of view. Possible threats were identified and, where 233 possible, countermeasures were proposed. Additionally, many 234 implementation flaws that have led to security vulnerabilities have 235 been referenced in the hope that future implementations will not 236 incur the same problems. Furthermore, this document does not limit 237 itself to performing a security assessment of the relevant IETF 238 specifications, but also provides an assessment of common 239 implementation strategies found in the real world. 241 Many IP implementations have also been subject of the so-called 242 "packet-of-death" vulnerabilities, in which a single specially- 243 crafted packet causes the IP implementation to crash or otherwise 244 misbehave. In most cases, the attack packet is simply malformed; in 245 other cases, the attack packet is well-formed, but exercises a little 246 used path through the IP stack. Well-designed IP implementations 247 should protect against these attacks, and therefore this document 248 describes a number of sanity checks that are expected to prevent most 249 of the aforementioned "packet-of-death" attack vectors. We note that 250 if an IP implementation is is found vulnerable to one of these 251 attacks, administrators must resort to mitigating them by packet 252 filtering. 254 Additionally, this document analyzes the security implications from 255 changes in the operational environment since the Internet Protocol 256 was desgined. For example, it analyzes how the Internet Protocol 257 could be exploited to evade Network Intrusion Detection Systems 258 (NIDS) or to circumvent firewalls. 260 This document does not aim to be the final word on the security of 261 the Internet Protocol (IP). On the contrary, it aims to raise 262 awareness about many security threats based on the IP protocol that 263 have been faced in the past, those that we are currently facing, and 264 those we may still have to deal with in the future. It provides 265 advice for the secure implementation of the Internet Protocol (IP), 266 but also provides insights about the security aspects of the Internet 267 Protocol that may be of help to the Internet operations community. 269 Feedback from the community is more than encouraged to help this 270 document be as accurate as possible and to keep it updated as new 271 threats are discovered. 273 This document is heavily based on the "Security Assessment of the 274 Internet Protocol" [CPNI2008] released by the UK Centre for the 275 Protection of National Infrastructure (CPNI), available at: 276 http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx . 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 280 document are to be interpreted as described in RFC 2119 [RFC2119]. 282 1.2. Scope of this document 284 While there are a number of protocols that affect the way in which IP 285 systems operate, this document focuses only on the specifications of 286 the Internet Protocol (IP). For example, routing and bootstrapping 287 protocols are considered out of the scope of this project. 289 The following IETF RFCs were selected as the primary sources for the 290 assessment as part of this work: 292 o RFC 791, "Internet Protocol. DARPA Internet Program. Protocol 293 Specification" (51 pages). 295 o RFC 815, "IP datagram reassembly algorithms" (9 pages). 297 o RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages). 299 o RFC 950, "Internet Standard Subnetting Procedure" (18 pages) 301 o RFC 1112, "Host Extensions for IP Multicasting" (17 pages) 303 o RFC 1122, "Requirements for Internet Hosts -- Communication 304 Layers" (116 pages). 306 o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages). 308 o RFC 2474, "Definition of the Differentiated Services Field (DS 309 Field) in the IPv4 and IPv6 Headers" (20 pages). 311 o RFC 2475, "An Architecture for Differentiated Services" (36 312 pages). 314 o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) 315 to IP" (63 pages). 317 o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet 318 Address Assignment and Aggregation Plan" (27 pages). 320 1.3. Organization of this document 322 This document is basically organized in two parts: "Internet Protocol 323 header fields" and "Internet Protocol mechanisms". The former 324 contains an analysis of each of the fields of the Internet Protocol 325 header, identifies their security implications, and discusses 326 possible countermeasures for the identified threats. The latter 327 contains an analysis of the security implications of the mechanisms 328 implemented by the Internet Protocol. 330 2. The Internet Protocol 332 The Internet Protocol (IP) provides a basic data transfer function 333 for passing data blocks called "datagrams" from a source host to a 334 destination host, across the possible intervening networks. 335 Additionally, it provides some functions that are useful for the 336 interconnection of heterogeneous networks, such as fragmentation and 337 reassembly. 339 The "datagram" has a number of characteristics that makes it 340 convenient for interconnecting systems [Clark1988]: 342 o It eliminates the need of connection state within the network, 343 which improves the survivability characteristics of the network. 345 o It provides a basic service of data transport that can be used as 346 a building block for other transport services (reliable data 347 transport services, etc.). 349 o It represents the minimum network service assumption, which 350 enables IP to be run over virtually any network technology. 352 3. Internet Protocol Header Fields 354 The IETF specifications of the Internet Protocol define the syntax of 355 the protocol header, along with the semantics of each of its fields. 356 Figure 1 shows the format of an IP datagram, as specified in 357 [RFC0791]. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |Version| IHL |Type of Service| Total Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Identification |Flags| Fragment Offset | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Time to Live | Protocol | Header Checksum | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Source Address | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Destination Address | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | [ Options ] | [ Padding ] | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 1: Internet Protocol header format 377 Even though the minimum IP header size is 20 bytes, an IP module 378 might be handed an (illegitimate) "datagram" of less than 20 bytes. 379 Therefore, before doing any processing of the IP header fields, the 380 following check should be performed by the IP module on the packets 381 handed by the link layer: 383 LinkLayer.PayloadSize >= 20 385 where LinkLayer.PayloadSize is the length (in octets) of the datagram 386 passed from the link layer to the IP layer. 388 If the packet does not pass this check, it should be dropped, and 389 this event should be logged (e.g., a counter could be incremented 390 reflecting the packet drop). 392 The following subsections contain further sanity checks that should 393 be performed on IP packets. 395 3.1. Version 397 This is a 4-bit field that indicates the version of the Internet 398 Protocol (IP), and thus the syntax of the packet. For IPv4, this 399 field must be 4. 401 When a Link-Layer protocol de-multiplexes a packet to an internet 402 module, it does so based on a "Protocol Type" field in the data-link 403 packet header. 405 In theory, different versions of IP could coexist on a network by 406 using the same "Protocol Type" at the Link-layer, but a different 407 value in the Version field of the IP header. Thus, a single IP 408 module could handle all versions of the Internet Protocol, 409 differentiating them by means of this field. 411 However, in practice different versions of IP are identified by a 412 different "Protocol Type" (e.g., "EtherType" in the case of Ethernet) 413 number in the link-layer protocol header. For example, IPv4 414 datagrams are encapsulated in Ethernet frames using an EtherType of 415 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames 416 using an EtherType of 0x86DD [IANA2006a]. 418 Therefore, if an IPv4 module receives a packet, the Version field 419 must be checked to be 4. If this check fails, the packet should be 420 silently dropped, and this event should be logged (e.g., a counter 421 could be incremented reflecting the packet drop). If an 422 implementation does not performs this check, an attacker could use a 423 different value for the Version field, possibly evading Network 424 Intrusion Detection Systems (NIDS) that decide which pattern-matching 425 rules to apply based on the Version field. 427 If the link-layer protocol employs a specific "Protocol Type" value 428 for encapsulating IPv4 packets (as is the case of e.g. Ethernet), a 429 node should check that IPv4 packets are de-multiplexed to the IPv4 430 module when such value was used for the "Protocol Type" field of the 431 link-layer protocol. If a packet does not pass this check, it should 432 be silently dropped. 434 An attacker could encapsulate IPv4 packets using other link-layer 435 "Protocol Type" values to try to subvert link-layer Access Control 436 Lists (ACLs), and/or for tampering with Network Intrusion 437 Detection Systems (NIDS). 439 3.2. IHL (Internet Header Length) 441 The IHL (Internet Header Length) field indicates the length of the 442 internet header in 32-bit words (4 bytes). The following paragraphs 443 decribe a number of sanity checks to be performed on the IHL field, 444 such that possible packet-of-death vulnerabilities are avoided. 446 As the minimum datagram size is 20 bytes, the minimum legal value for 447 this field is 5. Therefore, the following check should be enforced: 449 IHL >= 5 451 If the packet does not pass this check, it should be dropped, and 452 this event should be logged (e.g., a counter could be incremented 453 reflecting the packet drop). 455 For obvious reasons, the Internet header cannot be larger than the 456 whole Internet datagram it is part of. Therefore, the following 457 check should be enforced: 459 IHL * 4 <= Total Length 461 This needs to refer to the size of the datagram as specified by 462 the sender in the Total Length field, since link layers might have 463 added some padding (see Section 3.4). 465 If the packet does not pass this check, it should be dropped, and 466 this event should be logged (e.g., a counter could be incremented 467 reflecting the packet drop). 469 The above check allows for Internet datagrams with no data bytes in 470 the payload that, while nonsensical for virtually every protocol that 471 runs over IP, are is still legal. 473 3.3. Type of Service 475 3.3.1. Original Interpretation 477 Figure 2 shows the original syntax of the Type of Service field, as 478 defined by RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. 479 This definition has been superseded long ago (see Section 3.3.2.1 and 480 Section 3.3.2.2), but it is still assumed by some deployed 481 implementations. 483 0 1 2 3 4 5 6 7 484 +-----+-----+-----+-----+-----+-----+-----+-----+ 485 | PRECEDENCE | D | T | R | C | 0 | 486 +-----+-----+-----+-----+-----+-----+-----+-----+ 488 Figure 2: Type of Service Field (Original Interpretation) 490 +----------+----------------------------------------------+ 491 | Bits 0-2 | Precedence | 492 +----------+----------------------------------------------+ 493 | Bit 3 | 0 = Normal Delay, 1 = Low Delay | 494 +----------+----------------------------------------------+ 495 | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | 496 +----------+----------------------------------------------+ 497 | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | 498 +----------+----------------------------------------------+ 499 | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | 500 +----------+----------------------------------------------+ 501 | Bits 7 | Reserved for Future Use (must be zero) | 502 +----------+----------------------------------------------+ 504 Table 1: TOS-bits Semantics 506 +-----+-----------------+ 507 | 111 | Network Control | 508 +-----+-----------------+ 509 | 110 | Internetwork | 510 +-----+-----------------+ 511 | 101 | CRITIC/ECP | 512 +-----+-----------------+ 513 | 100 | Flash Override | 514 +-----+-----------------+ 515 | 011 | Flash | 516 +-----+-----------------+ 517 | 010 | Immediate | 518 +-----+-----------------+ 519 | 001 | Priority | 520 +-----+-----------------+ 521 | 000 | Routine | 522 +-----+-----------------+ 524 Table 2: Precedence Field Values 526 The Type of Service field can be used to affect the way in which the 527 packet is treated by the systems of a network that process it. 528 Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 529 ("Weak TOS") of this document describe the security implications of 530 the Type of Service field in the forwarding of packets. 532 3.3.2. Standard Interpretation 534 3.3.2.1. Differentiated Services field 536 The Differentiated Services Architecture is intended to enable 537 scalable service discrimination in the Internet without the need for 538 per-flow state and signaling at every hop [RFC2475]. RFC 2474 539 [RFC2474] redefined the IP "Type of Service" octet, introducing a 540 Differentiated Services Field (DS Field). Figure 3 shows the format 541 of the field. 543 0 1 2 3 4 5 6 7 544 +---+---+---+---+---+---+---+---+ 545 | DSCP | CU | 546 +---+---+---+---+---+---+---+---+ 548 Figure 3: Revised Structure of the Type of Service Field (RFC 2474) 550 The DSCP ("Differentiated Services CodePoint") is used to select the 551 treatment the packet is to receive within the Differentiated Services 552 Domain. The CU ("Currently Unused") field was, at the time the 553 specification was issued, reserved for future use. The DSCP field is 554 used to select a PHB (Per-Hop Behavior), by matching against the 555 entire 6-bit field. 557 Considering that the DSCP field determines how a packet is treated 558 within a Differentiated Services (DS) domain, an attacker could send 559 packets with a forged DSCP field to perform a theft of service or 560 even a Denial-of-Service attack. In particular, an attacker could 561 forge packets with a codepoint of the type '11x000' which, according 562 to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the packets 563 preferential forwarding treatment when compared with the PHB selected 564 by the codepoint '000000'. If strict priority queuing were utilized, 565 a continuous stream of such packets could cause a Denial of Service 566 to other flows which have a DSCP of lower relative order. 568 As the DS field is incompatible with the original Type of Service 569 field, both DS domains and networks using the original Type of 570 Service field should protect themselves by remarking the 571 corresponding field where appropriate, probably deploying remarking 572 boundary nodes. Nevertheless, care must be taken so that packets 573 received with an unrecognized DSCP do not cause the handling system 574 to malfunction. 576 3.3.2.2. Explicit Congestion Notification (ECN) 578 RFC 3168 [RFC3168] specifies a mechanism for routers to signal 579 congestion to hosts exchanging IP packets, by marking the offending 580 packets, rather than discarding them. RFC 3168 defines the ECN 581 field, which utilizes the CU field defined in RFC 2474 [RFC2474]. 582 Figure 4 shows the current syntax of the IP Type of Service field, 583 with the DSCP field used for Differentiated Services and the ECN 584 field. 586 0 1 2 3 4 5 6 7 587 +-----+-----+-----+-----+-----+-----+-----+-----+ 588 | DS FIELD, DSCP | ECN FIELD | 589 +-----+-----+-----+-----+-----+-----+-----+-----+ 591 Figure 4: The Differentiated Services and ECN fields in IP 593 As such, the ECN field defines four codepoints: 595 +-----------+-----------+ 596 | ECN field | Codepoint | 597 +-----------+-----------+ 598 | 00 | Not-ECT | 599 +-----------+-----------+ 600 | 01 | ECT(1) | 601 +-----------+-----------+ 602 | 10 | ECT(0) | 603 +-----------+-----------+ 604 | 11 | CE | 605 +-----------+-----------+ 607 Table 3: ECN codepoints 609 ECN is an end-to-end transport protocol mechanism based on 610 notifications by routers through which a packet flow passes. To 611 allow this interaction to happen on the fast path of routers, the ECN 612 field is located at a fixed location in the IP header. However, its 613 use must be negotiated at the transport layer, and the accumulated 614 congestion notifications must be communicated back to the sending 615 node using transport protocol means. Thus, ECN support must be 616 specified per transport protocol. 618 [RFC6040] specifies how the explicit congestion notification (ECN) 619 field of the IP header should be constructed on entry to and exit 620 from any IP-in-IP tunnel. 622 The security implications of ECN are discussed in detail in a number 623 of Sections of RFC 3168. Of the possible threats discussed in the 624 ECN specification, we believe that one that can be easily exploited 625 is that of a host falsely indicating ECN-Capability. 627 An attacker could set the ECT codepoint in the packets it sends, to 628 signal the network that the endpoints of the transport protocol are 629 ECN-capable. Consequently, when experiencing moderate congestion, 630 routers using active queue management based on RED would mark the 631 packets (with the CE codepoint) rather than discard them. In this 632 same scenario, packets of competing flows that do not have the ECT 633 codepoint set would be dropped. Therefore, an attacker would get 634 better network service than the competing flows. 636 However, if this moderate congestion turned into heavy congestion, 637 routers should switch to drop packets, regardless of whether the 638 packets have the ECT codepoint set or not. 640 A number of other threats could arise if an attacker was a man in the 641 middle (i.e., was in the middle of the path the packets travel to get 642 to the destination host). For a detailed discussion of those cases, 643 we urge the reader to consult Section 16 of RFC 3168. 645 There also is ongoing work in the research community and the IETF to 646 define alternate semantics for the CU / ECN field of IP TOS octet 647 (see [RFC5559], [RFC5670], and [RFC5696]). The application of these 648 methods must be confined to tightly administered domains, and on exit 649 from such domains, all packets need to be (re-)marked with ECN 650 semantics. 652 3.4. Total Length 654 The Total Length field is the length of the datagram, measured in 655 bytes, including both the IP header and the IP payload. Being a 16- 656 bit field, it allows for datagrams of up to 65535 bytes. RFC 791 657 [RFC0791] states that all hosts should be prepared to receive 658 datagrams of up to 576 bytes (whether they arrive as a whole, or in 659 fragments). However, most modern implementations can reassemble 660 datagrams of at least 9 Kbytes. 662 Usually, a host will not send to a remote peer an IP datagram larger 663 than 576 bytes, unless it is explicitly signaled that the remote peer 664 is able to receive such "large" datagrams (for example, by means of 665 TCP's MSS option). However, systems should assume that they may 666 receive datagrams larger than 576 bytes, regardless of whether they 667 signal their remote peers to do so or not. In fact, it is common for 668 NFS [RFC3530] implementations to send datagrams larger than 576 669 bytes, even without explicit signaling that the destination system 670 can receive such "large" datagram. 672 Additionally, see the discussion in Section 4.1 ("Fragment 673 reassembly") regarding the possible packet sizes resulting from 674 fragment reassembly. 676 Implementations should be aware that the IP module could be handed a 677 packet larger than the value actually contained in the Total Length 678 field. Such a difference usually has to do with legitimate padding 679 bytes at the link-layer protocol, but it could also be the result of 680 malicious activity by an attacker. Furthermore, even when the 681 maximum length of an IP datagram is 65535 bytes, if the link-layer 682 technology in use allows for payloads larger than 65535 bytes, an 683 attacker could forge such a large link-layer packet, meaning it for 684 the IP module. If the IP module of the receiving system were not 685 prepared to handle such an oversized link-layer payload, an 686 unexpected failure might occur. Therefore, the memory buffer used by 687 the IP module to store the link-layer payload should be allocated 688 according to the payload size reported by the link-layer, rather than 689 according to the Total Length field of the IP packet it contains. 691 The IP module could also be handed a packet that is smaller than the 692 actual IP packet size claimed by the Total Length field. This could 693 be used, for example, to produce an information leakage. Therefore, 694 the following check should be performed: 696 LinkLayer.PayloadSize >= Total Length 698 If this check fails, the IP packet should be dropped, and this event 699 should be logged (e.g., a counter could be incremented reflecting the 700 packet drop). As the previous expression implies, the number of 701 bytes passed by the link-layer to the IP module should contain at 702 least as many bytes as claimed by the Total Length field of the IP 703 header. 705 [US-CERT2002] is an example of the exploitation of a forged IP 706 Total Length field to produce an information leakage attack. 708 3.5. Identification (ID) 710 The Identification field is set by the sending host to aid in the 711 reassembly of fragmented datagrams. At any time, it needs to be 712 unique for each set of {Source Address, Destination Address, 713 Protocol}. 715 In many systems, the value used for this field is determined at the 716 IP layer, on a protocol-independent basis. Many of those systems 717 also simply increment the IP Identification field for each packet 718 they send. 720 This implementation strategy is inappropriate for a number of 721 reasons. Firstly, if the Identification field is set on a protocol- 722 independent basis, it will wrap more often than necessary, and thus 723 the implementation will be more prone to the problems discussed in 724 [Kent1987] and [RFC4963]. Secondly, this implementation strategy 725 opens the door to an information leakage that can be exploited in a 726 number of ways. 728 [Sanfilippo1998a] examined to determine the packet rate at which a 729 given system is transmitting information. Later, [Sanfilippo1998b] 730 described how a system with such an implementation can be used to 731 perform a stealth port scan to a third (victim) host. 732 [Sanfilippo1999] explained how to exploit this implementation 733 strategy to uncover the rules of a number of firewalls. 734 [Bellovin2002] explains how the IP Identification field can be 735 exploited to count the number of systems behind a NAT. [Fyodor2004] 736 is an entire paper on most (if not all) the ways to exploit the 737 information provided by the Identification field of the IP header. 739 Section 4.1 contains a discussion of the security implications of 740 the IP fragment reassembly mechanism, which is the primary 741 "consumer" of this field. 743 3.5.1. Some Workarounds Implemented by the Industry 745 As the IP Identification field is only used for the reassembly of 746 datagrams, some operating systems (such as Linux) decided to set this 747 field to 0 in all packets that have the DF bit set. This would, in 748 principle, avoid any type of information leakage. However, it was 749 detected that some non-RFC-compliant middle-boxes fragmented packets 750 even if they had the DF bit set. In such a scenario, all datagrams 751 originally sent with the DF bit set would all result in fragments 752 with an Identification field of 0, which would lead to problems 753 ("collision" of the Identification number) in the reassembly process. 755 Linux (and Solaris) later set the IP Identification field on a per- 756 IP-address basis. This avoids some of the security implications of 757 the IP Identification field, but not all. For example, systems 758 behind a load balancer can still be counted. 760 3.5.2. Possible security improvements 762 Contrary to common wisdom, the IP Identification field does not need 763 to be system-wide unique for each packet, but has to be unique for 764 each {Source Address, Destination Address, Protocol} tuple. 766 For instance, the TCP specification defines a generic send() 767 function which takes the IP ID as one of its arguments. 769 We provide an analysis of the possible security improvements that 770 could be implemented, based on whether the protocol using the 771 services of IP is connection-oriented or connection-less. 773 3.5.2.1. Connection-Oriented Transport Protocols 775 To avoid the security implications of the information leakage 776 described above, a pseudo-random number generator (PRNG) could be 777 used to set the IP Identification field on a {Source Address, 778 Destination Address} basis (for each connection-oriented transport 779 protocol). 781 [RFC4086] provides advice on the generation of pseudo-random 782 numbers. 784 [Klein2007] is a security advisory that describes a weakness in 785 the pseudo random number generator (PRNG) in use for the 786 generation of the IP Identification by a number of operating 787 systems. 789 While in theory a pseudo-random number generator could lead to 790 scenarios in which a given Identification number is used more than 791 once in the same time-span for datagrams that end up getting 792 fragmented (with the corresponding potential reassembly problems), in 793 practice this is unlikely to cause trouble. 795 By default, most implementations of connection-oriented protocols, 796 such as TCP, implement some mechanism for avoiding fragmentation 797 (such as the Path-MTU Discovery mechanism described in [RFC1191]). 798 Thus, fragmentation will only take place if a non-RFC-compliant 799 middle-box that still fragments packets even when the DF bit is set 800 is placed somewhere along the path that the packets travel to get to 801 the destination host. Once the sending system is signaled by the 802 middle-box (by means of an ICMP "fragmentation needed and DF bit set" 803 error message) that it should reduce the size of the packets it 804 sends, fragmentation would be avoided. Also, for reassembly problems 805 to arise, the same Identification value would need to be reused very 806 frequently, and either strong packet reordering or packet loss would 807 need to take place. 809 Nevertheless, regardless of what policy is used for selecting the 810 Identification field, with the current link speeds fragmentation is 811 already bad enough (i.e., very likely to lead to fragment reassembly 812 errors) to rely on it. A mechanism for avoiding fragmentation (such 813 as [RFC1191] or [RFC4821] should be implemented, instead. 815 3.5.2.2. Connectionless Transport Protocols 817 Connectionless transport protocols often have these characteristics: 819 o lack of flow-control mechanisms, 821 o lack of packet sequencing mechanisms, and/or, 823 o lack of reliability mechanisms (such as "timeout and retransmit"). 825 This basically means that the scenarios and/or applications for which 826 connection-less transport protocols are used assume that: 828 o Applications will be used in environments in which packet 829 reordering is very unlikely (such as Local Area Networks), as the 830 transport protocol itself does not provide data sequencing. 832 o The data transfer rates will be low enough that flow control will 833 be unnecessary. 835 o Packet loss is can be tolerated and/or is unlikely. 837 With these assumptions in mind, the Identification field could still 838 be set according to a pseudo-random number generator (PRNG). 840 [RFC4086] provides advice on the generation of pseudo-random 841 numbers. 843 In the event a given Identification number was reused while the first 844 instance of the same number is still on the network, the first IP 845 datagram would be reassembled before the fragments of the second IP 846 datagram get to their destination. 848 In the event this was not the case, the reassembly of fragments would 849 result in a corrupt datagram. While some existing work 850 [Silbersack2005] assumes that this error would be caught by some 851 upper-layer error detection code, the error detection code in 852 question (such as UDP's checksum) might not be able to reliably 853 detect data corruption arising from the replacement of a complete 854 data block (as is the case in corruption arising from collision of IP 855 Identification numbers). 857 In the case of UDP, unfortunately some systems have been known to 858 not enable the UDP checksum by default. For most applications, 859 packets containing errors should be dropped by the transport layer 860 and not delivered to the application. A small number of 861 applications may benefit from disabling the checksum; for example, 862 streaming media where it is desired to avoid dropping a complete 863 sample for a single-bit error, and UDP tunneling applications 864 where the payload (i.e. the inner packet) is protected by its own 865 transport checksum or other error detection mechanism. 867 In general, if IP Identification number collisions become an issue 868 for the application using the connection-less protocol, the 869 application designers should consider using a different transport 870 protocol (which hopefully avoids fragmentation). 872 It must be noted that an attacker could intentionally exploit 873 collisions of IP Identification numbers to perform a Denial-of- 874 Service attack, by sending forged fragments that would cause the 875 reassembly process to result in a corrupt datagram that would either 876 be dropped by the transport protocol, or would incorrectly be handed 877 to the corresponding application. This issue is discussed in detail 878 in section 4.1 ("Fragment Reassembly"). 880 3.6. Flags 882 The IP header contains 3 control bits, two of which are currently 883 used for the fragmentation and reassembly function. 885 As described by RFC 791, their meaning is: 887 o Bit 0: reserved, must be zero (i.e., reserved for future 888 standardization) 890 o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment 892 o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments 894 The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) 895 mechanism described in [RFC1191]. However, it can also be exploited 896 by an attacker to evade Network Intrusion Detection Systems. An 897 attacker could send a packet with the DF bit set to a system 898 monitored by a Network Intrusion Detection System (NIDS), and 899 depending on the Path-MTU to the intended recipient, the packet might 900 be dropped by some intervening router (because of being too big to be 901 forwarded without fragmentation), without the NIDS being aware of it. 903 +---+ 904 | H | 905 +---+ Victim host 906 | 907 Router A | MTU=1500 908 | 909 +---+ +---+ +---+ 910 | R |-----| R |---------| R | 911 +---+ +---+ +---+ 912 | MTU=17914 Router B 913 +---+ | 914 | S |-----+ 915 +---+ | 916 | 917 NIDS Sensor | 918 | 919 _ ___/---\______ Attacker 920 / \_/ \_ +---+ 921 / Internet |---------| H | 922 \_ __/ +---+ 923 \__ __ ___/ <------ 924 \___/ \__/ 17914-byte packet 925 DF bit set 927 Figure 5: NIDS evasion by means of the Internet Protocol DF bit 929 In Figure 3, an attacker sends a 17914-byte datagram meant for the 930 victim host in the same figure. The attacker's packet probably 931 contains an overlapping IP fragment or an overlapping TCP segment, 932 aiming at "confusing" the NIDS, as described in [Ptacek1998]. The 933 packet is screened by the NIDS sensor at the network perimeter, which 934 probably reassembles IP fragments and TCP segments for the purpose of 935 assessing the data transferred to and from the monitored systems. 936 However, as the attacker's packet should transit a link with an MTU 937 smaller than 17914 bytes (1500 bytes in this example), the router 938 that encounters that this packet cannot be forwarded without 939 fragmentation (Router B) discards the packet, and sends an ICMP 940 "fragmentation needed and DF bit set" error message to the source 941 host. In this scenario, the NIDS may remain unaware that the 942 screened packet never reached the intended destination, and thus get 943 an incorrect picture of the data being transferred to the monitored 944 systems. 946 [Shankar2003] introduces a technique named "Active Mapping" that 947 prevents evasion of a NIDS by acquiring sufficient knowledge about 948 the network being monitored, to assess which packets will arrive 949 at the intended recipient, and how they will be interpreted by it. 951 Some firewalls are known to drop packets that have both the MF (More 952 Fragments) and the DF (Don't fragment) bits set. While in principle 953 such a packet might seem nonsensical, there are a number of reasons 954 for which non-malicious packets with these two bits set can be found 955 in a network. First, they may exist as the result of some middle-box 956 processing a packet that was too large to be forwarded without 957 fragmentation. Instead of simply dropping the corresponding packet 958 and sending an ICMP error message to the source host, some middle- 959 boxes fragment the packet (copying the DF bit to each fragment), and 960 also send an ICMP error message to the originating system. Second, 961 some systems (notably Linux) set both the MF and the DF bits to 962 implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should 963 be taken into account when configuring firewalls and/or tuning 964 Network Intrusion Detection Systems (NIDS). 966 Section 4.1 contains a discussion of the security implications of the 967 IP fragment reassembly mechanism. 969 3.7. Fragment Offset 971 The Fragment Offset is used for the fragmentation and reassembly of 972 IP datagrams. It indicates where in the original datagram payload 973 the payload of the fragment belongs, and is measured in units of 974 eight bytes. As a consequence, all fragments (except the last one), 975 have to be aligned on an 8-byte boundary. Therefore, if a packet has 976 the MF flag set, the following check should be enforced: 978 (Total Length - IHL * 4) % 8 == 0 980 If the packet does not pass this check, it should be dropped, and 981 this event should be logged (e.g., a counter could be incremented 982 reflecting the packet drop). 984 Given that Fragment Offset is a 13-bit field, it can hold a value of 985 up to 8191, which would correspond to an offset 65528 bytes within 986 the original (non-fragmented) datagram. As such, it is possible for 987 a fragment to implicitly claim to belong to a datagram larger than 988 65535 bytes (the maximum size for a legitimate IP datagram). Even 989 when the fragmentation mechanism would seem to allow fragments that 990 could reassemble into such large datagrams, the intent of the 991 specification is to allow for the transmission of datagrams of up to 992 65535 bytes. Therefore, if a given fragment would reassemble into a 993 datagram of more than 65535 bytes, the resulting datagram should be 994 dropped, and this event should be logged (e.g., a counter could be 995 incremented reflecting the packet drop). To detect such a case, the 996 following check should be enforced on all packets for which the 997 Fragment Offset contains a non-zero value: 999 Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535 1001 where IHL_FF is the IHL field of the first fragment (the one with a 1002 Fragment Offset of 0). 1004 If a fragment does not pass this check, it should be dropped. 1006 If IHL_FF is not yet available because the first fragment has not yet 1007 arrived, for a preliminary, less rigid test, IHL_FF == IHL should be 1008 assumed, and the test is simplified to: 1010 Fragment Offset * 8 + Total Length <= 65535 1012 Once the first fragment is received, the full sanity check described 1013 earlier should be applied, if that fragment contains "don't copy" 1014 options. 1016 In the worst-case scenario, an attacker could craft IP fragments such 1017 that the reassembled datagram reassembled into a datagram of 131043 1018 bytes. 1020 Such a datagram would result when the first fragment has a 1021 Fragment Offset of 0 and a Total Length of 65532, and the second 1022 (and last) fragment has a Fragment Offset of 8189 (65512 bytes), 1023 and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header 1024 length of 20 bytes), the reassembled datagram would be 65532 + 1025 (65535 - 20) = 131047 bytes. 1027 Additionally, the IP module should implement all the necessary 1028 measures to be able to handle such illegitimate reassembled 1029 datagrams, so as to avoid them from overflowing the buffer(s) used 1030 for the reassembly function. 1032 [CERT1996c] and [Kenney1996] describe the exploitation of this 1033 issue to perform a Denial-of-Service (DoS) attack. 1035 Section 4.1 contains a discussion of the security implications of the 1036 IP fragment reassembly mechanism. 1038 3.8. Time to Live (TTL) 1040 The Time to Live (TTL) field has two functions: to bound the lifetime 1041 of the upper-layer packets (e.g., TCP segments) and to prevent 1042 packets from looping indefinitely in the network. 1044 Originally, this field was meant to indicate the maximum time a 1045 datagram was allowed to remain in the internet system, in units of 1046 seconds. As every internet module that processes a datagram must 1047 decrement the TTL by at least one, the original definition of the TTL 1048 field became obsolete, and in practice it is interpreted as a hop 1049 count (see Section 5.3.1 of [RFC1812]). 1051 Most systems allow the administrator to configure the TTL to be used 1052 for the packets they originate, with the default value usually being 1053 a power of 2, or 255 (see e.g. [Arkin2000]). The recommended value 1054 for the TTL field, as specified by the IANA is 64 [IANA2006b]. This 1055 value reflects the assumed "diameter" of the Internet, plus a margin 1056 to accommodate its growth. 1058 The TTL field has a number of properties that are interesting from a 1059 security point of view. Given that the default value used for the 1060 TTL is usually either a power of two, or 255, chances are that unless 1061 the originating system has been explicitly tuned to use a non-default 1062 value, if a packet arrives with a TTL of 60, the packet was 1063 originally sent with a TTL of 64. In the same way, if a packet is 1064 received with a TTL of 120, chances are that the original packet had 1065 a TTL of 128. 1067 This discussion assumes there was no protocol scrubber, 1068 transparent proxy, or some other middle-box that overwrites the 1069 TTL field in a non-standard way, between the originating system 1070 and the point of the network in which the packet was received. 1072 Determining the TTL with which a packet was originally sent by the 1073 source system can help to obtain valuable information. Among other 1074 things, it may help in: 1076 o Fingerprinting the originating operating system. 1078 o Fingerprinting the originating physical device. 1080 o Mapping the network topology. 1082 o Locating the source host in the network topology. 1084 o Evading Network Intrusion Detection Systems. 1086 However, it can also be used to perform important functions such as: 1088 o Improving the security of applications that make use of the 1089 Internet Protocol (IP). 1091 o Limiting spread of packets. 1093 3.8.1. Fingerprinting the operating system in use by the source host 1095 Different operating systems use a different default TTL for the 1096 packets they send. Thus, asserting the TTL with which a packet was 1097 originally sent will help heuristics to reduce the number of possible 1098 operating systems in use by the source host. It should be noted that 1099 since most systems use only a handful of different default values, 1100 the granularity of OS fingerprinting that this technique provides is 1101 negligible. Additionally, these defaults may be configurable 1102 (system-wide or per protocol), and managed systems may employ such 1103 opportunities for operational purposes and to defeat the capability 1104 of fingerprinting heuristics. 1106 3.8.2. Fingerprinting the physical device from which the packets 1107 originate 1109 When several systems are behind a middle-box such as a NAT or a load 1110 balancer, the TTL may help to count the number of systems behind the 1111 middle-box. If each of the systems behind the middle-box uses a 1112 different default TTL value for the packets it sends, or each system 1113 is located at different distances in the network topology, an 1114 attacker could stimulate responses from the devices being 1115 fingerprinted, and responses that arrive with different TTL values 1116 could be assumed to come from a different devices. 1118 Of course, there are many other (and much more precise) techniques 1119 to fingerprint physical devices. One weakness of this method is 1120 that, while many systems differ in the default TTL value that they 1121 use, there are also many implementations which use the same 1122 default TTL value. Additionally, packets sent by a given device 1123 may take different routes (e.g., due to load sharing or route 1124 changes), and thus a given packet may incorrectly be presumed to 1125 come from a different device, when in fact it just traveled a 1126 different route. 1128 However, these defaults may be configurable (system-wide or per 1129 protocol) and managed systems may employ such opportunities for 1130 operational purposes and to defeat the capability of fingerprinting 1131 heuristics. 1133 3.8.3. Mapping the Network Topology 1135 An originating host may set the TTL field of the packets it sends to 1136 progressively increasing values in order to elicit an ICMP error 1137 message from the routers that decrement the TTL of each packet to 1138 zero, and thereby determine the IP addresses of the routers on the 1139 path to the packet's destination. This procedure has been 1140 traditionally employed by the traceroute tool. 1142 3.8.4. Locating the source host in the network topology 1144 The TTL field may also be used to locate the source system in the 1145 network topology [Northcutt2000]. 1147 +---+ +---+ +---+ +---+ +---+ 1148 | A |-----| R |------| R |----| R |-----| R | 1149 +---+ +---+ +---+ +---+ +---+ 1150 / | / \ 1151 / | / \ 1152 / | / +---+ 1153 / +---+ +---+ +---+ | E | 1154 / | R |----| R |------| R |-- +---+ 1155 / +---+ +---+\ +---+ \ 1156 / / / \ \ \ 1157 / ---- / +---+ \ \+---+ 1158 / / / | F | \ | D | 1159 +---+ +---+ +---+ \ +---| 1160 | R |----------| R |-- \ 1161 +---+ +---+ \ \ 1162 | \ / \ +---+| +---+ 1163 | \ / ----| R |------| R | 1164 | \ / +---+ +---+ 1165 +---+ \ +---+ +---+ 1166 | B | \| R |----| C | 1167 +---+ +---+ +---+ 1169 Figure 6: Tracking a host by means of the TTL field 1171 Consider network topology of Figure 6. Assuming that an attacker 1172 ("F" in the figure) is performing some type of attack that requires 1173 forging the Source Address (such as for a TCP-based DoS reflection 1174 attack), and some of the involved hosts are willing to cooperate to 1175 locate the attacking system. 1177 Assuming that: 1179 o All the packets A gets have a TTL of 61. 1181 o All the packets B gets have a TTL of 61. 1183 o All the packets C gets have a TTL of 61. 1185 o All the packets D gets have a TTL of 62. 1187 Based on this information, and assuming that the system's default 1188 value was not overridden, it would be fair to assume that the 1189 original TTL of the packets was 64. With this information, the 1190 number of hops between the attacker and each of the aforementioned 1191 hosts can be calculated. 1193 The attacker is: 1195 o Four hops away from A. 1197 o Four hops away from B. 1199 o Four hops away from C. 1201 o Four hops away from D. 1203 In the network setup of Figure 3, the only system that satisfies all 1204 these conditions is the one marked as the "F". 1206 The scenario described above is for illustration purposes only. In 1207 practice, there are a number of factors that may prevent this 1208 technique from being successfully applied: 1210 o Unless there is a "large" number of cooperating systems, and the 1211 attacker is assumed to be no more than a few hops away from these 1212 systems, the number of "candidate" hosts will usually be too large 1213 for the information to be useful. 1215 o The attacker may be using a non-default TTL value, or, what is 1216 worse, using a pseudo-random value for the TTL of the packets it 1217 sends. 1219 o The packets sent by the attacker may take different routes, as a 1220 result of a change in network topology, load sharing, etc., and 1221 thus may lead to an incorrect analysis. 1223 3.8.5. Evading Network Intrusion Detection Systems 1225 The TTL field can be used to evade Network Intrusion Detection 1226 Systems. Depending on the position of a sensor relative to the 1227 destination host of the examined packet, the NIDS may get a different 1228 picture from that of the intended destination system. As an example, 1229 a sensor may process a packet that will expire before getting to the 1230 destination host. A general countermeasure for this type of attack 1231 is to normalize the traffic that gets to an organizational network. 1232 Examples of such traffic normalization can be found in [Paxson2001]. 1233 OpenBSD Packet Filter is an example of a packet filter that includes 1234 TTL-normalization functionality [OpenBSD-PF] 1236 3.8.6. Improving the security of applications that make use of the 1237 Internet Protocol (IP) 1239 In some scenarios, the TTL field can be also used to improve the 1240 security of an application, by restricting the hosts that can 1241 communicate with the given application [RFC5082]. For example, there 1242 are applications for which the communicating systems are typically in 1243 the same network segment (i.e., there are no intervening routers). 1244 Such an application is the BGP (Border Gateway Protocol) utilized by 1245 two peer routers (usually on a shared link medium). 1247 If both systems use a TTL of 255 for all the packets they send to 1248 each other, then a check could be enforced to require all packets 1249 meant for the application in question to have a TTL of 255. 1251 As all packets sent by systems that are not in the same network 1252 segment will have a TTL smaller than 255, those packets will not pass 1253 the check enforced by these two cooperating peers. This check 1254 reduces the set of systems that may perform attacks against the 1255 protected application (BGP in this case), thus mitigating the attack 1256 vectors described in [NISCC2004] and [Watson2004]. 1258 This same check is enforced for related ICMP error messages, with 1259 the intent of mitigating the attack vectors described in 1260 [NISCC2005] and [RFC5927]. 1262 The TTL field can be used in a similar way in scenarios in which the 1263 cooperating systems are not in the same network segment (i.e., multi- 1264 hop peering). In that case, the following check could be enforced: 1266 TTL >= 255 - DeltaHops 1268 This means that the set of hosts from which packets will be accepted 1269 for the protected application will be reduced to those that are no 1270 more than DeltaHops away. While for obvious reasons the level of 1271 protection will be smaller than in the case of directly-connected 1272 peers, the use of the TTL field for protecting multi-hop peering 1273 still reduces the set of hosts that could potentially perform a 1274 number of attacks against the protected application. 1276 This use of the TTL field has been officially documented by the IETF 1277 under the name "Generalized TTL Security Mechanism" (GTSM) in 1278 [RFC5082]. 1280 Some protocol scrubbers enforce a minimum value for the TTL field of 1281 the packets they forward. It must be understood that depending on 1282 the minimum TTL being enforced, and depending on the particular 1283 network setup, the protocol scrubber may actually help attackers to 1284 fool the GTSM, by "raising" the TTL of the attacking packets. 1286 3.8.7. Limiting spread 1288 The originating host sets the TTL field to a small value (frequently 1289 1, for link-scope services) in order to artifically limit the 1290 (topological) distance the packet is allowed to travel. This is 1291 suggested in Section 4.2.2.9 of RFC 1812 [RFC1812]. Further 1292 discussion of this technique can be found in in RFC 1112 [RFC1112]. 1294 3.9. Protocol 1296 The Protocol field indicates the protocol encapsulated in the 1297 internet datagram. The Protocol field may not only contain a value 1298 corresponding to a protocol implemented by the system processing the 1299 packet, but also a value corresponding to a protocol not implemented, 1300 or even a value not yet assigned by the IANA [IANA2006c]. 1302 While in theory there should not be security implications from the 1303 use of any value in the protocol field, there have been security 1304 issues in the past with systems that had problems when handling 1305 packets with some specific protocol numbers [Cisco2003] [CERT2003]. 1307 A host (i.e., end-system) that receives an IP packet encapsulating a 1308 Protocol it does not support should drop the corresponding packet, 1309 log the event, and possibly send an ICMP Protocol Unreachable (type 1310 3, code 2) error message. 1312 3.10. Header Checksum 1314 The Header Checksum field is an error detection mechanism meant to 1315 detect errors in the IP header. While in principle there should not 1316 be security implications arising from this field, it should be noted 1317 that due to non-RFC-compliant implementations, the Header Checksum 1318 might be exploited to detect firewalls and/or evade network intrusion 1319 detection systems (NIDS). 1321 [Ed3f2002] describes the exploitation of the TCP checksum for 1322 performing such actions. As there are internet routers known to not 1323 check the IP Header Checksum, and there might also be middle-boxes 1324 (NATs, firewalls, etc.) not checking the IP checksum allegedly due to 1325 performance reasons, similar malicious activity to the one described 1326 in [Ed3f2002] might be performed with the IP checksum. 1328 3.11. Source Address 1330 The Source Address of an IP datagram identifies the node from which 1331 the packet originated. 1333 Strictly speaking, the Source Address of an IP datagram identifies 1334 the interface of the sending system from which the packet was 1335 sent, (rather than the originating "system"), as in the Internet 1336 Architecture there's no concept of "node address". 1338 Unfortunately, it is trivial to forge the Source Address of an 1339 Internet datagram because of the apparent lack of consistent "egress 1340 filtering" near the edge of the network. This has been exploited in 1341 the past for performing a variety of DoS (Denial of Service) attacks 1342 [NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to 1343 impersonate as other systems in scenarios in which authentication was 1344 based on the Source Address of the sending system [daemon91996]. 1346 The extent to which these attacks can be successfully performed in 1347 the Internet can be reduced through deployment of ingress/egress 1348 filtering in the internet routers. [NISCC2006] is a detailed guide 1349 on ingress and egress filtering. [RFC2827] and [RFC3704] discuss 1350 ingress filtering. [GIAC2000] discusses egress filtering. 1351 [SpooferProject] measures the Internet's susceptibility to forged 1352 Source Address IP packets. 1354 Even when the obvious field on which to perform checks for 1355 ingress/egress filtering is the Source Address and Destination 1356 Address fields of the IP header, there are other occurrences of IP 1357 addresses on which the same type of checks should be performed. 1358 One example is the IP addresses contained in the payload of ICMP 1359 error messages, as discussed in [RFC5927] and [Gont2006]. 1361 There are a number of sanity checks that should be performed on the 1362 Source Address of an IP datagram. Details can be found in Section 1363 4.2 ("Addressing"). 1365 Additionally, there exist freely available tools that allow 1366 administrators to monitor which IP addresses are used with which MAC 1367 addresses [LBNL2006]. This functionality is also included in many 1368 Network Intrusion Detection Systems (NIDS). 1370 It is also very important to understand that authentication should 1371 never rely solely on the Source Address used by the communicating 1372 systems. 1374 3.12. Destination Address 1376 The Destination Address of an IP datagram identifies the destination 1377 host to which the packet is meant to be delivered. 1379 Strictly speaking, the Destination Address of an IP datagram 1380 identifies the interface of the destination network interface, 1381 rather than the destination "system", as in the Internet 1382 Architecture there's no concept of "node address". 1384 There are a number of sanity checks that should be performed on the 1385 Destination Address of an IP datagram. Details can be found in 1386 Section 4.2 ("Addressing"). 1388 3.13. Options 1390 According to RFC 791, IP options must be implemented by all IP 1391 modules, both in hosts and gateways (i.e., end-systems and 1392 intermediate-systems). This means that the general rules for 1393 assembling, parsing, and processing of IP options must be 1394 implemented. RFC 791 defines a set of options that "must be 1395 understood", but this set has been updated by RFC 1122 [RFC1122], RFC 1396 1812 [RFC1812], and other documents. Section 3.13.2 of this document 1397 describes for each option type the current understanding of the 1398 implementation requirements. IP systems are required to ignore 1399 options they do not implement. 1401 It should be noted that while a number of IP options have been 1402 specified, they are generally only used for troubleshooting 1403 purposes (except for the Router Alert option and the different 1404 Security options). 1406 There are two cases for the format of an option: 1408 o Case 1: A single byte of option-type. 1410 o Case 2: An option-type byte, an option-length byte, and the actual 1411 option-data bytes. 1413 In Case 2, the option-length byte counts the option-type byte and the 1414 option-length byte, as well as the actual option-data bytes. 1416 All current and future options except "End of Option List" (Type = 0) 1417 and "No Operation" (Type = 1), are of Class 2. 1419 The option-type has three fields: 1421 o 1 bit: copied flag. 1423 o 2 bits: option class. 1425 o 5 bits: option number. 1427 This format allows for the creation of new options for the extension 1428 of the Internet Protocol (IP) and their transparent treatment on 1429 intermediate systems that do not "understand" them, under direction 1430 of the first three functional parts. 1432 The copied flag indicates whether this option should be copied to all 1433 fragments in the event the packet carrying it needs to be fragmented: 1435 o 0 = not copied. 1437 o 1 = copied. 1439 The values for the option class are: 1441 o 0 = control. 1443 o 1 = reserved for future use. 1445 o 2 = debugging and measurement. 1447 o 3 = reserved for future use. 1449 Finally, the option number identifies the syntax of the rest of the 1450 option. 1452 [IANA2006b] contains the list of the currently assigned IP option 1453 numbers. It should be noted that IP systems are required to ignore 1454 those options they do not implement. 1456 3.13.1. General issues with IP options 1458 The following subsections discuss security issues that apply to all 1459 IP options. The proposed checks should be performed in addition to 1460 any option-specific checks proposed in the next sections. 1462 3.13.1.1. Processing requirements 1464 Router manufacturers tend to do IP option processing on the main 1465 processor, rather than on line cards. Unless special care is taken, 1466 this represents Denial of Service (DoS) risk, as there is potential 1467 for overwhelming the router with option processing. 1469 To reduce the impact of these packets on the system performance, a 1470 few countermeasures could be implemented: 1472 o Rate-limit the number of packets with IP options that are 1473 processed by the system. 1475 o Enforce a limit on the maximum number of options to be accepted on 1476 a given internet datagram. 1478 The first check avoids a flow of packets with IP options to overwhelm 1479 the system in question. The second check avoids packets with many IP 1480 options to affect the performance of the system. 1482 3.13.1.2. Processing of the options by the upper layer protocol 1484 Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options 1485 received in IP datagrams must be passed to the transport layer (or to 1486 ICMP processing when the datagram is an ICMP message). Therefore, 1487 care in option processing must be taken not only at the internet 1488 layer, but also in every protocol module that may end up processing 1489 the options included in an IP datagram. 1491 3.13.1.3. General sanity checks on IP options 1493 There are a number of sanity checks that should be performed on IP 1494 options before further option processing is done. They help prevent 1495 a number of potential security problems, including buffer overflows. 1496 When these checks fail, the packet carrying the option should be 1497 dropped, and this event should be logged (e.g., a counter could be 1498 incremented to reflect the packet drop). 1500 RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" 1501 message to the originating system when a packet is dropped because of 1502 an invalid value in a field, such as the cases discussed in the 1503 following subsections. Sending such a message might help in 1504 debugging some network problems. However, it would also alert 1505 attackers about the system that is dropping packets because of the 1506 invalid values in the protocol fields. 1508 We advice that systems default to sending an ICMP "Parameter Problem" 1509 error message when a packet is dropped because of an invalid value in 1510 a protocol field (e.g., as a result of dropping a packet due to the 1511 sanity checks described in this section). However, we recommend that 1512 systems provide a system-wide toggle that allows an administrator to 1513 override the default behavior so that packets can be silently dropped 1514 when an invalid value in a protocol field is encountered. 1516 Option length 1518 Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer 1519 must not crash as the result of an option length that is outside 1520 the possible range, and mentions that erroneous option lengths 1521 have been observed to put some IP implementations into infinite 1522 loops. 1524 For options that belong to the "Case 2" described in the previous 1525 section, the following check should be performed: 1527 option-length >= 2 1529 The value "2" accounts for the option-type byte, and the 1530 option-length byte. 1532 This check prevents, among other things, loops in option 1533 processing that may arise from incorrect option lengths. 1535 Additionally, while the option-length byte of IP options of 1536 "Case 2" allows for an option length of up to 255 bytes, there is 1537 a limit on legitimate option length imposed by the space available 1538 for options in the IP header. 1540 For all options of "Case 2", the following check should be 1541 enforced: 1543 option-offset + option-length <= IHL * 4 1545 Where option-offset is the offset of the first byte of the option 1546 within the IP header, with the first byte of the IP header being 1547 assigned an offset of 0. 1549 This check assures that the option does not claim to extend beyond 1550 the IP header. If the packet does not pass this check, it should 1551 be dropped, and this event should be logged (e.g., a counter could 1552 be incremented to reflect the packet drop). 1554 The aforementioned check is meant to detect forged option-length 1555 values that might make an option overlap with the IP payload. 1556 This would be particularly dangerous for those IP options which 1557 request the processing systems to write information into the 1558 option-data area (such as the Record Route option), as it would 1559 allow the generation of overflows. 1561 Data types 1563 Many IP options use pointer and length fields. Care must be taken 1564 as to the data type used for these fields in the implementation. 1565 For example, if an 8-bit signed data type were used to hold an 1566 8-bit pointer, then, pointer values larger than 128 might 1567 mistakenly be interpreted as negative numbers, and thus might lead 1568 to unpredictable results. 1570 3.13.2. Issues with specific options 1572 3.13.2.1. End of Option List (Type=0) 1574 This option is used to indicate the "end of options" in those cases 1575 in which the end of options would not coincide with the end of the 1576 Internet Protocol Header. Octets in the IP header following the "End 1577 of Option List" are to be regarded as padding (they should set to 0 1578 by the originator and must to be ignored by receiving nodes). 1580 However, an originating node could alternatively fill the remaining 1581 space in the Internet header with No Operation options (see 1582 Section 3.13.2.2). The End of Option List option allows slightly 1583 more efficient parsing on receiving nodes and should be preferred by 1584 packet originators. All IP systems are required to understand both 1585 encodings. 1587 3.13.2.2. No Operation (Type=1) 1589 The no-operation option is basically meant to allow the sending 1590 system to align subsequent options in, for example, 32-bit 1591 boundaries, but it can also be used at the end of the options (se 1592 Section Section 3.13.2.1). 1594 With a single exception (see Section 3.13.2.13 below), this option is 1595 the only IP option defined so far that can occur in multiple 1596 instances in a single IP packet. 1598 This option does not have security implications. 1600 3.13.2.3. Loose Source and Record Route (LSRR) (Type=131) 1602 This option lets the originating system specify a number of 1603 intermediate systems a packet must pass through to get to the 1604 destination host. Additionally, the route followed by the packet is 1605 recorded in the option. The receiving host (end-system) must use the 1606 reverse of the path contained in the received LSRR option. 1608 The LSSR option can be of help in debugging some network problems. 1609 Some ISP (Internet Service Provider) peering agreements require 1610 support for this option in the routers within the peer of the ISP. 1612 The LSRR option has well-known security implications. Among other 1613 things, the option can be used to: 1615 o Bypass firewall rules 1616 o Reach otherwise unreachable internet systems 1618 o Establish TCP connections in a stealthy way 1620 o Learn about the topology of a network 1622 o Perform bandwidth-exhaustion attacks 1624 Of these attack vectors, the one that has probably received least 1625 attention is the use of the LSRR option to perform bandwidth 1626 exhaustion attacks. The LSRR option can be used as an amplification 1627 method for performing bandwidth-exhaustion attacks, as an attacker 1628 could make a packet bounce multiple times between a number of systems 1629 by carefully crafting an LSRR option. 1631 This is the IPv4-version of the IPv6 amplification attack that was 1632 widely publicized in 2007 [Biondi2007]. The only difference is 1633 that the maximum length of the IPv4 header (and hence the LSRR 1634 option) limits the amplification factor when compared to the IPv6 1635 counter-part. 1637 While the LSSR option may be of help in debugging some network 1638 problems, its security implications outweigh any legitimate use. 1640 All systems should, by default, drop IP packets that contain an LSRR 1641 option, and should log this event (e.g., a counter could be 1642 incremented to reflect the packet drop). However, they should 1643 provide a system-wide toggle to enable support for this option for 1644 those scenarios in which this option is required. Such system-wide 1645 toggle should default to "off" (or "disable"). 1647 [OpenBSD1998] is a security advisory about an improper 1648 implementation of such a system-wide toggle in 4.4BSD kernels. 1650 Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to 1651 act as an intermediate hop in a source route, forwarding a source- 1652 routed datagram to the next specified hop. We strongly discourage 1653 host software from forwarding source-routed datagrams. 1655 If processing of source-routed datagrams is explicitly enabled in a 1656 system, the following sanity checks should be performed. 1658 RFC 791 states that this option should appear, at most, once in a 1659 given packet. Thus, if a packet contains more than one LSRR option, 1660 it should be dropped, and this event should be logged (e.g., a 1661 counter could be incremented to reflect the packet drop). 1662 Additionally, packets containing a combination of LSRR and SSRR 1663 options should be dropped, and this event should be logged (e.g., a 1664 counter could be incremented to reflect the packet drop). 1666 As all other IP options of "Case 2", the LSSR contains a Length field 1667 that indicates the length of the option. Given the format of the 1668 option, the Length field should be checked to have a minimum value of 1669 three and be 3 (3 + n*4): 1671 LSRR.Length % 4 == 3 && LSRR.Length != 0 1673 If the packet does not pass this check, it should be dropped, and 1674 this event should be logged (e.g., a counter could be incremented to 1675 reflect the packet drop). 1677 The Pointer is relative to this option. Thus, the minimum legal 1678 value is 4. Therefore, the following check should be performed. 1680 LSRR.Pointer >= 4 1682 If the packet does not pass this check, it should be dropped, and 1683 this event should be logged (e.g., a counter could be incremented to 1684 reflect the packet drop). Additionally, the Pointer field should be 1685 a multiple of 4. Consequently, the following check should be 1686 performed: 1688 LSRR.Pointer % 4 == 0 1690 If a packet does not pass this check, it should be dropped, and this 1691 event should be logged (e.g., a counter could be incremented to 1692 reflect the packet drop). 1694 When a system receives an IP packet with the LSRR option passing the 1695 above checks, it should check whether the source route is empty or 1696 not. The option is empty if: 1698 LSRR.Pointer > LSRR.Length 1700 In that case, routing should be based on the Destination Address 1701 field, and no further processing should be done on the LSRR option. 1703 [Microsoft1999] is a security advisory about a vulnerability 1704 arising from improper validation of the LSRR.Pointer field. 1706 If the address in the Destination Address field has been reached, and 1707 the option is not empty, the next address in the source route 1708 replaces the address in the Destination Address field, and the IP 1709 address of the interface that will be used to forward this datagram 1710 is recorded in its place in the LSRR.Data field. Then, the 1711 LSRR.Pointer. is incremented by 4. 1713 Note that the sanity checks for the LSRR.Length and the 1714 LSRR.Pointer fields described above ensure that if the option is 1715 not empty, there will be (4*n) octets in the option. That is, 1716 there will be at least one IP address to read, and enough room to 1717 record the IP address of the interface that will be used to 1718 forward this datagram. 1720 The LSRR must be copied on fragmentation. This means that if a 1721 packet that carries the LSRR is fragmented, each of the fragments 1722 will have to go through the list of systems specified in the LSRR 1723 option. 1725 3.13.2.4. Strict Source and Record Route (SSRR) (Type=137) 1727 This option allows the originating system to specify a number of 1728 intermediate systems a packet must pass through to get to the 1729 destination host. Additionally, the route followed by the packet is 1730 recorded in the option, and the destination host (end-system) must 1731 use the reverse of the path contained in the received SSRR option. 1733 This option is similar to the Loose Source and Record Route (LSRR) 1734 option, with the only difference that in the case of SSRR, the route 1735 specified in the option is the exact route the packet must take 1736 (i.e., no other intervening routers are allowed to be in the route). 1738 The SSSR option can be of help in debugging some network problems. 1739 Some ISP (Internet Service Provider) peering agreements require 1740 support for this option in the routers within the peer of the ISP. 1742 The SSRR option has the same security implications as the LSRR 1743 option. Please refer to Section 3.13.2.3 for a discussion of such 1744 security implications. 1746 As with the LSRR, while the SSSR option may be of help in debugging 1747 some network problems, its security implications outweigh any 1748 legitimate use of it. 1750 All systems should, by default, drop IP packets that contain an SSRR 1751 option, and should log this event (e.g., a counter could be 1752 incremented to reflect the packet drop). However, they should 1753 provide a system-wide toggle to enable support for this option for 1754 those scenarios in which this option is required. Such system-wide 1755 toggle should default to "off" (or "disable"). 1757 [OpenBSD1998] is a security advisory about an improper 1758 implementation of such a system-wide toggle in 4.4BSD kernels. 1760 In the event processing of the SSRR option were explicitly enabled, 1761 the same sanity checks described for the LSRR option in 1762 Section 3.13.2.3 should be performed on the SSRR option. Namely, 1763 sanity checks should be performed on the option length (SSRR.Length) 1764 and the pointer field (SSRR.Pointer). 1766 If the packet passes the aforementioned sanity checks, the receiving 1767 system should determine whether the Destination Address of the packet 1768 corresponds to one of its IP addresses. If does not, it should be 1769 dropped, and this event should be logged (e.g., a counter could be 1770 incremented to reflect the packet drop). 1772 Contrary to the IP Loose Source and Record Route (LSRR) option, 1773 the SSRR option does not allow in the route other routers than 1774 those contained in the option. If the system implements the weak 1775 end-system model, it is allowed for the system to receive a packet 1776 destined to any of its IP addresses, on any of its interfaces. If 1777 the system implements the strong end-system model, a packet 1778 destined to it can be received only on the interface that 1779 corresponds to the IP address contained in the Destination Address 1780 field [RFC1122]. 1782 If the packet passes this check, the receiving system should 1783 determine whether the source route is empty or not. The option is 1784 empty if: 1786 SSRR.Pointer > SSRR.Length 1788 In that case, if the address in the destination field has not been 1789 reached, the packet should be dropped, and this event should be 1790 logged (e.g., a counter could be incremented to reflect the packet 1791 drop). 1793 [Microsoft1999] is a security advisory about a vulnerability 1794 arising from improper validation of the SSRR.Pointer field. 1796 If the option is not empty, and the address in the Destination 1797 Address field has been reached, the next address in the source route 1798 replaces the address in the Destination Address field, and the IP 1799 address of the interface that will be used to forward this datagram 1800 is recorded in its place in the source route (SSRR.Data field). 1801 Then, the SSRR.Pointer is incremented by 4. 1803 Note that the sanity checks for the SSRR.Length and the 1804 SSRR.Pointer fields described above ensure that if the option is 1805 not empty, there will be (4*n) octets in the option. That is, 1806 there will be at least one IP address to read, and enough room to 1807 record the IP address of the interface that will be used to 1808 forward this datagram. 1810 The SSRR option must be copied on fragmentation. This means that if 1811 a packet that carries the SSRR is fragmented, each of the fragments 1812 will have to go through the list of systems specified in the SSRR 1813 option. 1815 3.13.2.5. Record Route (Type=7) 1817 This option provides a means to record the route that a given packet 1818 follows. 1820 The option begins with an 8-bit option code, which is equal to 7. 1821 The second byte is the option length, which includes the option-type 1822 byte, the option-length byte, the pointer byte, and the actual 1823 option-data. The third byte is a pointer into the route data, 1824 indicating the first byte of the area in which to store the next 1825 route data. The pointer is relative to the option start. 1827 RFC 791 states that this option should appear, at most, once in a 1828 given packet. Therefore, if a packet has more than one instance of 1829 this option, it should be dropped, and this event should be logged 1830 (e.g., a counter could be incremented to reflect the packet drop). 1832 The same sanity checks performed for the Length field and the Pointer 1833 field of the LSRR and the SSRR options should be performed on the 1834 Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR 1835 option. As with the LSRR and SSRR options, if the packet does not 1836 pass these checks it should be dropped, and this event should be 1837 logged (e.g., a counter could be incremented to reflect the packet 1838 drop). 1840 When a system receives an IP packet with the Record Route option that 1841 passes the above checks, it should check whether there is space in 1842 the option to store route information. The option is full if: 1844 RR.Pointer > RR.Length 1846 If the option is full, the datagram should be forwarded without 1847 further processing of this option. 1849 If the option is not full (i.e., RR.Pointer <= RR.Length), the IP 1850 address of the interface that will be used to forward this datagram 1851 should be recorded into the area pointed to by the RR.Pointer, and 1852 RR.Pointer should then incremented by 4. 1854 This option is not copied on fragmentation, and thus appears in the 1855 first fragment only. If a fragment other than the one with offset 0 1856 contains the Record Route option, it should be dropped, and this 1857 event should be logged (e.g., a counter could be incremented to 1858 reflect the packet drop). 1860 The Record Route option can be exploited to learn about the topology 1861 of a network. However, the limited space in the IP header limits the 1862 usefulness of this option for that purpose if the target network is 1863 several hops away. 1865 3.13.2.6. Stream Identifier (Type=136) 1867 The Stream Identifier option originally provided a means for the 16- 1868 bit SATNET stream Identifier to be carried through networks that did 1869 not support the stream concept. 1871 However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this 1872 option is obsolete. Therefore, it must be ignored by the processing 1873 systems. 1875 In the case of legacy systems still using this option, the length 1876 field of the option should be checked to be 4. If the option does 1877 not pass this check, it should be dropped, and this event should be 1878 logged (e.g., a counter could be incremented to reflect the packet 1879 drop). 1881 RFC 791 states that this option appears at most once in a given 1882 datagram. Therefore, if a packet contains more than one instance of 1883 this option, it should be dropped, and this event should be logged 1884 (e.g., a counter could be incremented to reflect the packet drop). 1886 3.13.2.7. Internet Timestamp (Type=68) 1888 This option provides a means for recording the time at which each 1889 system processed this datagram. The timestamp option has a number of 1890 security implications. Among them are: 1892 o It allows an attacker to obtain the current time of the systems 1893 that process the packet, which the attacker may find useful in a 1894 number of scenarios. 1896 o It may be used to map the network topology, in a similar way to 1897 the IP Record Route option. 1899 o It may be used to fingerprint the operating system in use by a 1900 system processing the datagram. 1902 o It may be used to fingerprint physical devices, by analyzing the 1903 clock skew. 1905 Therefore, by default, the timestamp option should be ignored. 1907 For those systems that have been explicitly configured to honor this 1908 option, the rest of this subsection describes some sanity checks that 1909 should be enforced on the option before further processing. 1911 The option begins with an option-type byte, which must be equal to 1912 68. The second byte is the option-length, which includes the option- 1913 type byte, the option-length byte, the pointer, and the overflow/flag 1914 byte. The minimum legal value for the option-length byte is 4, which 1915 corresponds to an Internet Timestamp option that is empty (no space 1916 to store timestamps). Therefore, upon receipt of a packet that 1917 contains an Internet Timestamp option, the following check should be 1918 performed: 1920 IT.Length >= 4 1922 If the packet does not pass this check, it should be dropped, and 1923 this event should be logged (e.g., a counter could be incremented to 1924 reflect the packet drop). 1926 The Pointer is an index within this option, counting the option type 1927 octet as octet #1. It points to the first byte of the area in which 1928 the next timestamp data should be stored and thus, the minimum legal 1929 value is 5. Since the only change of the Pointer allowed by RFC 791 1930 is incrementing it by 4 or 8, the following checks should be 1931 performed on the Internet Timestamp option, depending on the Flag 1932 value (see below). 1934 If IT.Flag is equal to 0, the following check should be performed: 1936 IT.Pointer %4 == 1 && IT.Pointer != 1 1938 If the packet does not pass this check, it should be dropped, and 1939 this event should be logged (e.g., a counter could be incremented to 1940 reflect the packet drop). 1942 Otherwise, the following sanity check should be performed on the 1943 option: 1945 IT.Pointer % 8 == 5 1947 If the packet does not pass this check, it should be dropped, and 1948 this event should be logged (e.g., a counter could be incremented to 1949 reflect the packet drop). 1951 The flag field has three possible legal values: 1953 o 0: Record time stamps only, stored in consecutive 32-bit words. 1955 o 1: Record each timestamp preceded with the internet address of the 1956 registering entity. 1958 o 3: The internet address fields of the option are pre-specified. 1959 An IP module only registers its timestamp if it matches its own 1960 address with the next specified internet address. 1962 Therefore the following check should be performed: 1964 IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 1966 If the packet does not pass this check, it should be dropped, and 1967 this event should be logged (e.g., a counter could be incremented to 1968 reflect the packet drop). 1970 The timestamp field is a right-justified 32-bit timestamp in 1971 milliseconds since UTC. If the time is not available in 1972 milliseconds, or cannot be provided with respect to UTC, then any 1973 time may be inserted as a timestamp, provided the high order bit of 1974 the timestamp is set, to indicate this non-standard value. 1976 According to RFC 791, the initial contents of the timestamp area must 1977 be initialized to zero, or internet address/zero pairs. However, 1978 internet systems should be able to handle non-zero values, possibly 1979 discarding the offending datagram. 1981 When an internet system receives a packet with an Internet Timestamp 1982 option, it decides whether it should record its timestamp in the 1983 option. If it determines that it should, it should then determine 1984 whether the timestamp data area is full, by means of the following 1985 check: 1987 IT.Pointer > IT.Length 1989 If this condition is true, the timestamp data area is full. If not, 1990 there is room in the timestamp data area. 1992 If the timestamp data area is full, the overflow byte should be 1993 incremented, and the packet should be forwarded without inserting the 1994 timestamp. If the overflow byte itself overflows, the packet should 1995 be dropped, and this event should be logged (e.g., a counter could be 1996 incremented to reflect the packet drop). 1998 If the timestamp data area is not full, then processing continues as 1999 follows (note that the above checks on IT.Pointer ensure that there 2000 is room for another entry in the option): 2002 o If IT.Flag is 0, then the system's 32-bit timestamp is stored into 2003 the area pointed to by the pointer byte and the pointer byte is 2004 incremented by 4. 2006 o If IT.Flag is 1, then the IP address of the system is stored into 2007 the area pointed to by the pointer byte, followed by the 32-bit 2008 system timestamp, and the pointer byte is incremented by 8. 2010 o Otherwise (IT.Flag is 3), if the IP address in the first 4 bytes 2011 pointed to by IT.Pointer matches one of the IP addresses assigned 2012 to an interface of the system, then the system's timestamp is 2013 stored into the area pointed to by IT.Pointer + 4, and the pointer 2014 byte is incremented by 8. 2016 [Kohno2005] describes a technique for fingerprinting devices by 2017 measuring the clock skew. It exploits, among other things, the 2018 timestamps that can be obtained by means of the ICMP timestamp 2019 request messages [RFC0791]. However, the same fingerprinting method 2020 could be implemented with the aid of the Internet Timestamp option. 2022 3.13.2.8. Router Alert (Type=148) 2024 The Router Alert option is defined in RFC 2113 [RFC2113] and later 2025 updates to it have been clarified by RFC 5350 [RFC5350]. It contains 2026 a 16-bit Value governed by an IANA registry (see [RFC5350]). The 2027 Router Alert option has the semantic "routers should examine this 2028 packet more closely, if they participate in the functionality denoted 2029 by the Value of the option". 2031 According to the syntax of the option as defined in RFC 2113, the 2032 following check should be enforced, if the router supports this 2033 option: 2035 RA.Length == 4 2037 If the packet does not pass this check, it should be dropped, and 2038 this event should be logged (e.g., a counter could be incremented to 2039 reflect the packet drop). 2041 A packet that contains a Router Alert option with an option value 2042 corresponding to functionality supported by an active module in the 2043 router will not go through the router's fast-path but will be 2044 processed in the slow path of the router, handing it over for closer 2045 inspection to the modules that has registered the matching option 2046 value. Therefore, this option may impact the performance of the 2047 systems that handle the packet carrying it. 2049 [I-D.ietf-intarea-router-alert-considerations] analyzes the 2050 security implications of the Router Alert option, and identifies 2051 controlled environments in which the Router Alert option can be 2052 used safely. 2054 As explained in RFC 2113 [RFC2113], hosts should ignore this option. 2056 3.13.2.9. Probe MTU (Type=11) (obsolete) 2058 This option was defined in RFC 1063 [RFC1063], and originally 2059 provided a mechanism to discover the Path-MTU. 2061 This option is obsolete, and therefore any packet that is received 2062 containing this option should be dropped, and this event should be 2063 logged (e.g., a counter could be incremented to reflect the packet 2064 drop). 2066 3.13.2.10. Reply MTU (Type=12) (obsolete) 2068 This option is defined in RFC 1063 [RFC1063], and originally provided 2069 a mechanism to discover the Path-MTU. 2071 This option is obsolete, and therefore any packet that is received 2072 containing this option should be dropped, and this event should be 2073 logged (e.g., a counter could be incremented to reflect the packet 2074 drop). 2076 3.13.2.11. Traceroute (Type=82) 2078 This option is defined in RFC 1393 [RFC1393], and originally provided 2079 a mechanism to trace the path to a host. 2081 This option is obsolete, and therefore any packet that is received 2082 containing this option should be dropped, and this event should be 2083 logged (e.g., a counter could be incremented to reflect the packet 2084 drop). 2086 3.13.2.12. DoD Basic Security Option (Type=130) 2088 This option is used by Multi-Level-Secure (MLS) end-systems and 2089 intermediate systems in specific environments to [RFC1108]: 2091 o Transmit from source to destination in a network standard 2092 representation the common security labels required by computer 2093 security models, 2095 o Validate the datagram as appropriate for transmission from the 2096 source and delivery to the destination, and, 2098 o Ensure that the route taken by the datagram is protected to the 2099 level required by all protection authorities indicated on the 2100 datagram. 2102 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 2103 [RFC1038]). 2105 RFC 791 [RFC0791] defined the "Security Option" (Type=130), which 2106 used the same option type as the DoD Basic Security option 2107 discussed in this section. The "Security Option" specified in RFC 2108 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and 2109 therefore the discussion in this section is focused on the DoD 2110 Basic Security option specified by RFC 1108 [RFC1108]. 2112 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 2113 this option". 2115 The DoD Basic Security Option is currently implemented in a number of 2116 operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], 2117 and [Cisco2008]), and deployed in a number of high-security networks. 2119 Systems that belong to networks in which this option is in use should 2120 process the DoD Basic Security option contained in each packet as 2121 specified in [RFC1108]. 2123 RFC 1108 states that the option should appear at most once in a 2124 datagram. Therefore, if more than one DoD Basic Security option 2125 (BSO) appears in a given datagram, the corresponding datagram should 2126 be dropped, and this event should be logged (e.g., a counter could be 2127 incremented to reflect the packet drop). 2129 RFC 1108 states that the option Length is variable, with a minimum 2130 option Length of 3 bytes. Therefore, the following check should be 2131 performed: 2133 BSO.Length >= 3 2135 If the packet does not pass this check, it should be dropped, and 2136 this event should be logged (e.g., a counter could be incremented to 2137 reflect the packet drop). 2139 Current deployments of the security options described in this 2140 section and the two subsequent sections have motivated the 2141 proposal of a "Common Architecture Label IPv6 Security Option 2142 (CALIPSO)" for the IPv6 protocol. [RFC5570]. 2144 3.13.2.13. DoD Extended Security Option (Type=133) 2146 This option permits additional security labeling information, beyond 2147 that present in the Basic Security Option (Section 3.13.2.12), to be 2148 supplied in an IP datagram to meet the needs of registered 2149 authorities. It is specified by RFC 1108 [RFC1108]. 2151 This option may be present only in conjunction with the DoD Basic 2152 Security option. Therefore, if a packet contains a DoD Extended 2153 Security option (ESO), but does not contain a DoD Basic Security 2154 option, it should be dropped, and this event should be logged (e.g., 2155 a counter could be incremented to reflect the packet drop). It 2156 should be noted that, unlike the DoD Basic Security option, this 2157 option may appear multiple times in a single IP header. 2159 Systems that belong to networks in which this option is in use, 2160 should process the DoD Extended Security option contained in each 2161 packet as specified in RFC 1108 [RFC1108]. 2163 RFC 1108 states that the option Length is variable, with a minimum 2164 option Length of 3 bytes. Therefore, the following check should be 2165 performed: 2167 ESO.Length >= 3 2169 If the packet does not pass this check, it should be dropped, and 2170 this event should be logged (e.g., a counter could be incremented to 2171 reflect the packet drop). 2173 3.13.2.14. Commercial IP Security Option (CIPSO) (Type=134) 2175 This option was proposed by the Trusted Systems Interoperability 2176 Group (TSIG), with the intent of meeting trusted networking 2177 requirements for the commercial trusted systems market place. It is 2178 specified in [CIPSO1992] and [FIPS1994]. 2180 The TSIG proposal was taken to the Commercial Internet Security 2181 Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an 2182 Internet-Draft was produced [CIPSO1992]. The Internet-Draft was 2183 never published as an RFC, but the proposal was later standardized 2184 by the U.S. National Institute of Standards and Technology (NIST) 2185 as "Federal Information Processing Standard Publication 188" 2186 [FIPS1994]. 2188 It is currently implemented in a number of operating systems (e.g., 2189 IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris 2190 [Solaris2008]), and deployed in a number of high-security networks. 2192 [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux 2193 implementation. 2195 Systems that belong to networks in which this option is in use should 2196 process the CIPSO option contained in each packet as specified in 2197 [CIPSO1992]. 2199 According to the option syntax specified in [CIPSO1992] the following 2200 validation check should be performed: 2202 CIPSO.Length >= 6 2204 If a packet does not pass this check, it should be dropped, and this 2205 event should be logged (e.g., a counter could be incremented to 2206 reflect the packet drop). 2208 3.13.2.15. Sender Directed Multi-Destination Delivery (Type=149) 2210 This option is defined in RFC 1770 [RFC1770], and originally provided 2211 unreliable UDP delivery to a set of addresses included in the option. 2213 This option is obsolete. If a received packet contains this option, 2214 it should be dropped, and this event should be logged (e.g., a 2215 counter could be incremented to reflect the packet drop). 2217 4. Internet Protocol Mechanisms 2219 4.1. Fragment reassembly 2221 To accommodate networks with different Maximum Transmission Units 2222 (MTUs), the Internet Protocol provides a mechanism for the 2223 fragmentation of IP packets by end-systems (hosts) and/or 2224 intermediate systems (routers). Reassembly of fragments is performed 2225 only by the end-systems. 2227 [Cerf1974] provides the rationale for why packet reassembly is not 2228 performed by intermediate systems. 2230 During the last few decades, IP fragmentation and reassembly has been 2231 exploited in a number of ways, to perform actions such as evading 2232 Network Intrusion Detection Systems (NIDS), bypassing firewall rules, 2233 and performing Denial of Service (DoS) attacks. 2235 [Bendi1998] and [Humble1998] are examples of the exploitation of 2236 these issues for performing Denial of Service (DoS) attacks. 2237 [CERT1997] and [CERT1998b] document these issues. [Anderson2001] 2238 is a survey of fragmentation attacks. [US-CERT2001] is an example 2239 of the exploitation of IP fragmentation to bypass firewall rules. 2240 [CERT1999] describes the implementation of fragmentation attacks 2241 in Distributed Denial of Service (DDoS) attack tools. 2243 The problem with IP fragment reassembly basically has to do with the 2244 complexity of the function, in a number of aspects: 2246 o Fragment reassembly is a stateful operation for a stateless 2247 protocol (IP). The IP module at the host performing the 2248 reassembly function must allocate memory buffers both for 2249 temporarily storing the received fragments, and to perform the 2250 reassembly function. Attackers can exploit this fact to exhaust 2251 memory buffers at the system performing the fragment reassembly. 2253 o The fragmentation and reassembly mechanisms were designed at a 2254 time in which the available bandwidths were very different from 2255 the bandwidths available nowadays. With the current available 2256 bandwidths, a number of interoperability problems may arise, and 2257 these issues may be intentionally exploited by attackers to 2258 perform Denial of Service (DoS) attacks. 2260 o Fragment reassembly must usually be performed without any 2261 knowledge of the properties of the path the fragments follow. 2262 Without this information, hosts cannot make any educated guess on 2263 how long they should wait for missing fragments to arrive. 2265 o The fragment reassembly algorithm, as described by the IETF 2266 specifications, is ambiguous, and allows for a number of 2267 interpretations, each of which has found place in different TCP/IP 2268 stack implementations. 2270 o The reassembly process is somewhat complex. Fragments may arrive 2271 out of order, duplicated, overlapping each other, etc. This 2272 complexity has lead to numerous bugs in different implementations 2273 of the IP protocol. 2275 4.1.1. Security Implications of Fragment Reassembly 2277 4.1.1.1. Problems related with memory allocation 2279 When an IP datagram is received by an end-system, it will be 2280 temporarily stored in system memory, until the IP module processes it 2281 and hands it to the protocol machine that corresponds to the 2282 encapsulated protocol. 2284 In the case of fragmented IP packets, while the IP module may perform 2285 preliminary processing of the IP header (such as checking the header 2286 for errors and processing IP options), fragments must be kept in 2287 system buffers until all fragments are received and are reassembled 2288 into a complete internet datagram. 2290 As mentioned above, because the internet layer will not usually have 2291 information about the characteristics of the path between the system 2292 and the remote host, no educated guess can be made on the amount of 2293 time that should be waited for the other fragments to arrive. 2294 Therefore, the specifications recommend to wait for a period of time 2295 that is acceptable for virtually all the possible network scenarios 2296 in which the protocols might operate. After that time has elapsed, 2297 all the received fragments for the corresponding incomplete packet 2298 are discarded. 2300 The original IP Specification, RFC 791 [RFC0791], states that 2301 systems should wait for at least 15 seconds for the missing 2302 fragments to arrive. Systems that follow the "Example Reassembly 2303 Procedure" described in Section 3.2 of RFC 791 may end up using a 2304 reassembly timer of up to 4.25 minutes, with a minimum of 15 2305 seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this 2306 advice, stating that the reassembly timeout should be a fixed 2307 value between 60 and 120 seconds. 2309 However, the longer the system waits for the missing fragments to 2310 arrive, the longer the corresponding system resources must be tied to 2311 the corresponding packet. The amount of system memory is finite, and 2312 even with today's systems, it can still be considered a scarce 2313 resource. 2315 An attacker could take advantage of the uncomfortable situation the 2316 system performing fragment reassembly is in, by sending forged 2317 fragments that will never reassemble into a complete datagram. That 2318 is, an attacker would send many different fragments, with different 2319 IP IDs, without ever sending all the necessary fragments that would 2320 be needed to reassemble them into a full IP datagram. For each of 2321 the fragments, the IP module would allocate resources and tie them to 2322 the corresponding fragment, until the reassembly timer for the 2323 corresponding packet expires. 2325 There are some implementation strategies which could increase the 2326 impact of this attack. For example, upon receipt of a fragment, some 2327 systems allocate a memory buffer that will be large enough to 2328 reassemble the whole datagram. While this might be beneficial in 2329 legitimate cases, this just amplifies the impact of the possible 2330 attacks, as a single small fragment could tie up memory buffers for 2331 the size of an extremely large (and unlikely) datagram. The 2332 implementation strategy suggested in RFC 815 [RFC0815] leads to such 2333 an implementation. 2335 The impact of the aforementioned attack may vary depending on some 2336 specific implementation details: 2338 o If the system does not enforce limits on the amount of memory that 2339 can be allocated by the IP module, then an attacker could tie all 2340 system memory to fragments, at which point the system would become 2341 unusable, perhaps crashing. 2343 o If the system enforces limits on the amount of memory that can be 2344 allocated by the IP module as a whole, then, when this limit is 2345 reached, all further IP packets that arrive would be discarded, 2346 until some fragments time out and free memory is available again. 2348 o If the system enforces limits on the amount memory that can be 2349 allocated for the reassembly of fragments, then, when this limit 2350 is reached, all further fragments that arrive would be discarded, 2351 until some fragment(s) time out and free memory is available 2352 again. 2354 4.1.1.2. Problems that arise from the length of the IP Identification 2355 field 2357 The Internet Protocols are currently being used in environments that 2358 are quite different from the ones in which they were conceived. For 2359 instance, the availability of bandwidth at the time the Internet 2360 Protocol was designed was completely different from the availability 2361 of bandwidth in today's networks. 2363 The Identification field is a 16-bit field that is used for the 2364 fragmentation and reassembly function. In the event a datagram gets 2365 fragmented, all the corresponding fragments will share the same 2366 {Source Address, Destination Address, Protocol, Identification 2367 number} four-tuple. Thus, the system receiving the fragments will be 2368 able to uniquely identify them as fragments that correspond to the 2369 same IP datagram. At a given point in time, there must be at most 2370 only one packet in the network with a given four-tuple. If not, an 2371 Identification number "collision" might occur, and the receiving 2372 system might end up "mixing" fragments that correspond to different 2373 IP datagrams which simply reused the same Identification number. 2375 For example, sending over a 1 Gbit/s path a continuous stream of 2376 (UDP) packets of roughly 1 kb size that all get fragmented into 2377 two equally sized fragments of 576 octets each (minimum reasesmbly 2378 buffer size) would repeat the IP Identification values within less 2379 than 0.65 seconds (assuming roughly 10% link layer overhead); with 2380 shorter packets that still get fragmented, this figure could 2381 easily drop below 0.4 seconds. With a single IP packet dropped in 2382 this short timeframe, packets would start to be reassembled 2383 wrongly and continuously once in such interval until an error 2384 detection and recovery algorithm at an upper layer lets the 2385 application back out. 2387 For each group of fragments whose Identification numbers "collide", 2388 the fragment reassembly will lead to corrupted packets. The IP 2389 payload of the reassembled datagram will be handed to the 2390 corresponding upper layer protocol, where the error will (hopefully) 2391 be detected by some error detecting code (such as the TCP checksum) 2392 and the packet will be discarded. 2394 An attacker could exploit this fact to intentionally cause a system 2395 to discard all or part of the fragmented traffic it gets, thus 2396 performing a Denial-of-Service attack. Such an attacker would simply 2397 establish a flow of fragments with different IP Identification 2398 numbers, to trash all or part of the IP Identification space. As a 2399 result, the receiving system would use the attacker's fragments for 2400 the reassembly of legitimate datagrams, leading to corrupted packets 2401 which would later (and hopefully) get dropped. 2403 In most cases, use of a long fragment timeout will benefit the 2404 attacker, as forged fragments will keep the IP Identification space 2405 trashed for a longer period of time. 2407 4.1.1.3. Problems that arise from the complexity of the reassembly 2408 algorithm 2410 As IP packets can be duplicated by the network, and each packet may 2411 take a different path to get to the destination host, fragments may 2412 arrive not only out of order and/or duplicated, but also overlapping. 2413 This means that the reassembly process can be somewhat complex, with 2414 the corresponding implementation being not specifically trivial. 2416 [Shannon2001] analyzes the causes and attributes of fragment traffic 2417 measured in several types of WANs. 2419 During the years, a number of attacks have exploited bugs in the 2420 reassembly function of several operating systems, producing buffer 2421 overflows that have led, in most cases, to a crash of the attacked 2422 system. 2424 4.1.1.4. Problems that arise from the ambiguity of the reassembly 2425 process 2427 Network Intrusion Detection Systems (NIDSs) typically monitor the 2428 traffic on a given network with the intent of identifying traffic 2429 patterns that might indicate network intrusions. 2431 In the presence of IP fragments, in order to detect illegitimate 2432 activity at the transport or application layers (i.e., any protocol 2433 layer above the network layer), a NIDS must perform IP fragment 2434 reassembly. 2436 In order to correctly assess the traffic, the result of the 2437 reassembly function performed by the NIDS should be the same as that 2438 of the reassembly function performed by the intended recipient of the 2439 packets. 2441 However, a number of factors make the result of the reassembly 2442 process ambiguous: 2444 o The IETF specifications are ambiguous as to what should be done in 2445 the event overlapping fragments were received. Thus, in the 2446 presence of overlapping data, the system performing the reassembly 2447 function is free to either honor the first set of data received, 2448 the latest copy received, or any other copy received in between. 2450 o As the specifications do not enforce any specific fragment timeout 2451 value, different systems may choose different values for the 2452 fragment timeout. This means that given a set of fragments 2453 received at some specified time intervals, some systems will 2454 reassemble the fragments into a full datagram, while others may 2455 timeout the fragments and therefore drop them. 2457 o As mentioned before, as the fragment buffers get full, a Denial of 2458 Service (DoS) condition will occur unless some action is taken. 2459 Many systems flush part of the fragment buffers when some 2460 threshold is reached. Thus, depending on fragment load, timing 2461 issues, and flushing policy, a NIDS may get incorrect assumptions 2462 about how (and if) fragments are being reassembled by their 2463 intended recipient. 2465 As originally discussed by [Ptacek1998], these issues can be 2466 exploited by attackers to evade intrusion detection systems. 2468 There exist freely available tools to forcefully fragment IP 2469 datagrams so as to help evade Intrusion Detection Systems. Frag 2470 router [Song1999] is an example of such a tool; it allows an attacker 2471 to perform all the evasion techniques described in [Ptacek1998]. 2472 Ftester [Barisani2006] is a tool that helps to audit systems 2473 regarding fragmentation issues. 2475 4.1.1.5. Problems that arise from the size of the IP fragments 2477 One approach to fragment filtering involves keeping track of the 2478 results of applying filter rules to the first fragment (i.e., the 2479 fragment with a Fragment Offset of 0), and applying them to 2480 subsequent fragments of the same packet. The filtering module would 2481 maintain a list of packets indexed by the Source Address, Destination 2482 Address, Protocol, and Identification number. When the initial 2483 fragment is seen, if the MF bit is set, a list item would be 2484 allocated to hold the result of filter access checks. When packets 2485 with a non-zero Fragment Offset come in, look up the list element 2486 with a matching Source Address/Destination Address/Protocol/ 2487 Identification and apply the stored result (pass or block). When a 2488 fragment with a zero MF bit is seen, free the list element. 2489 Unfortunately, the rules of this type of packet filter can usually be 2490 bypassed. [RFC1858] describes the details of the involved technique. 2492 4.1.2. Possible security improvements 2494 4.1.2.1. Memory allocation for fragment reassembly 2496 A design choice usually has to be made as to how to allocate memory 2497 to reassemble the fragments of a given packet. There are basically 2498 two options: 2500 o Upon receipt of the first fragment, allocate a buffer that will be 2501 large enough to concatenate the payload of each fragment. 2503 o Upon receipt of the first fragment, create the first node of a 2504 linked list to which each of the following fragments will be 2505 linked. When all fragments have been received, copy the IP 2506 payload of each of the fragments (in the correct order) to a 2507 separate buffer that will be handed to the protocol being 2508 encapsulated in the IP payload. 2510 While the first of the choices might seem to be the most straight- 2511 forward, it implies that even when a single small fragment of a given 2512 packet is received, the amount of memory that will be allocated for 2513 that fragment will account for the size of the complete IP datagram, 2514 thus using more system resources than what is actually needed. 2516 Furthermore, the only situation in which the actual size of the whole 2517 datagram will be known is when the last fragment of the packet is 2518 received first, as that is the only packet from which the total size 2519 of the IP datagram can be asserted. Otherwise, memory should be 2520 allocated for the largest possible packet size (65535 bytes). 2522 The IP module should also enforce a limit on the amount of memory 2523 that can be allocated for IP fragments, as well as a limit on the 2524 number of fragments that at any time will be allowed in the system. 2525 This will basically limit the resources spent on the reassembly 2526 process, and prevent an attacker from trashing the whole system 2527 memory. 2529 Furthermore, the IP module should keep a different buffer for IP 2530 fragments than for complete IP datagrams. This will basically 2531 separate the effects of fragment attacks on non-fragmented traffic. 2532 Most TCP/IP implementations, such as that in Linux and those in BSD- 2533 derived systems, already implement this. 2535 [Jones2002] analyzes the amount of memory that may be needed for the 2536 fragment reassembly buffer depending on a number of network 2537 characteristics. 2539 4.1.2.2. Flushing the fragment buffer 2541 In the case of those attacks that aim to consume the memory buffers 2542 used for fragments, and those that aim to cause a collision of IP 2543 Identification numbers, there are a number of countermeasures that 2544 can be implemented. 2546 Even with these countermeasures in place, there is still the issue of 2547 what to do when the buffer pool used for IP fragments gets full. 2548 Basically, if the fragment buffer is full, no instance of 2549 communication that relies on fragmentation will be able to progress. 2551 Unfortunately, there are not many options for reacting to this 2552 situation. If nothing is done, all the instances of communication 2553 that rely on fragmentation will experience a denial of service. 2554 Thus, the only thing that can be done is flush all or part of the 2555 fragment buffer, on the premise that legitimate traffic will be able 2556 to make use of the freed buffer space to allow communication flows to 2557 progress. 2559 There are a number of factors that should be taken into consideration 2560 when flushing the fragment buffers. First, if a fragment of a given 2561 packet (i.e., fragment with a given Identification number) is 2562 flushed, all the other fragments that correspond to the same datagram 2563 should be flushed. As in order for a packet to be reassembled all of 2564 its fragments must be received by the system performing the 2565 reassembly function, flushing only a subset of the fragments of a 2566 given packet would keep the corresponding buffers tied to fragments 2567 that would never reassemble into a complete datagram. Additionally, 2568 care must be taken so that, in the event that subsequent buffer 2569 flushes need to be performed, it is not always the same set of 2570 fragments that get dropped, as such a behavior would probably cause a 2571 selective Denial of Service (DoS) to the traffic flows to which that 2572 set of fragments belongs. 2574 Many TCP/IP implementations define a threshold for the number of 2575 fragments that, when reached, triggers a fragment-buffer flush. Some 2576 systems flush 1/2 of the fragment buffer when the threshold is 2577 reached. As mentioned before, the idea of flushing the buffer is to 2578 create some free space in the fragment buffer, on the premise that 2579 this will allow for new and legitimate fragments to be processed by 2580 the IP module, thus letting communication survive the overwhelming 2581 situation. On the other hand, the idea of flushing a somewhat large 2582 portion of the buffer is to avoid flushing always the same set of 2583 packets. 2585 4.1.2.3. A more selective fragment buffer flushing strategy 2587 One of the difficulties in implementing countermeasures for the 2588 fragmentation attacks described throughout Section 4.1 is that it is 2589 difficult to perform validation checks on the received fragments. 2590 For instance, the fragment on which validity checks could be 2591 performed, the first fragment, may be not the first fragment to 2592 arrive at the destination host. 2594 Fragments can not only arrive out of order because of packet 2595 reordering performed by the network, but also because the system (or 2596 systems) that fragmented the IP datagram may indeed transmit the 2597 fragments out of order. A notable example of this is the Linux 2598 TCP/IP stack, which transmits the fragments in reverse order. 2600 This means that we cannot enforce checks on the fragments for which 2601 we allocate reassembly resources, as the first fragment we receive 2602 for a given packet may be some other fragment than the first one (the 2603 one with an Fragment Offset of 0). 2605 However, at the point in which we decide to free some space in the 2606 fragment buffer, some refinements can be done to the flushing policy. 2607 The first thing we would like to do is to stop different types of 2608 traffic from interfering with each other. This means, in principle, 2609 that we do not want fragmented UDP traffic to interfere with 2610 fragmented TCP traffic. In order to implement this traffic 2611 separation for the different protocols, a different fragment buffer 2612 pool would be needed, in principle, for each of the 256 different 2613 protocols that can be encapsulated in an IP datagram. 2615 We believe a tradeoff is to implement two separate fragment buffers: 2616 one for IP datagrams that encapsulate IPsec packets, and another for 2617 the rest of the traffic. This basically means that traffic not 2618 protected by IPsec will not interfere with those flows of 2619 communication that are being protected by IPsec. 2621 The processing of each of these two different fragment buffer pools 2622 would be completely independent from each other. In the case of the 2623 IPsec fragment buffer pool, when the buffers needs to be flushed, the 2624 following refined policy could be applied: 2626 o First, for each packet for which the IPsec header has been 2627 received, check that the SPI field of the IPsec header corresponds 2628 to an existing IPsec Security Association (SA), and probably also 2629 check that the IPsec sequence number is valid. If the check 2630 fails, drop all the fragments that correspond to this packet. 2632 o Second, if still more fragment buffers need to be flushed, drop 2633 all the fragments that correspond to packets for which the full 2634 IPsec header has not yet been received. The number of packets for 2635 which this flushing is performed depends on the amount of free 2636 space that needs to be created. 2638 o Third, if after flushing packets with invalid IPsec information 2639 (First step), and packets on which validation checks could not be 2640 performed (Second step), there is still not enough space in the 2641 fragment buffer, drop all the fragments that correspond to packets 2642 that passed the checks of the first step, until the necessary free 2643 space is created. 2645 The rationale behind this policy is that, at the point of flushing 2646 fragment buffers, we prefer to keep those packets on which we could 2647 successfully perform a number of validation checks, over those 2648 packets on which those checks failed, or the checks could not even be 2649 performed. 2651 By checking both the IPsec SPI and the IPsec sequence number, it is 2652 virtually impossible for an attacker that is off-path to perform a 2653 Denial-of-Service attack to communication flows being protected by 2654 IPsec. 2656 Unfortunately, some IP implementations (such as that in Linux 2657 [Linux2006]), when performing fragmentation, send the corresponding 2658 fragments in reverse order. In such cases, at the point of flushing 2659 the fragment buffer, legitimate fragments will receive the same 2660 treatment as the possible forged fragments. 2662 This refined flushing policy provides an increased level of 2663 protection against this type of resource exhaustion attack, while not 2664 making the situation of out-of-order IPsec-secured traffic worse than 2665 with the simplified flushing policy described in the previous 2666 section. 2668 4.1.2.4. Reducing the fragment timeout 2670 RFC 1122 [RFC1122] states that the reassembly timeout should be a 2671 fixed value between 60 and 120 seconds. The rationale behind these 2672 long timeout values is that they should accommodate any path 2673 characteristics, such as long-delay paths. However, it must be noted 2674 that this timer is really measuring inter-fragment delays, or, more 2675 specifically, fragment jitter. 2677 If all fragments take paths of similar characteristics, the inter- 2678 fragment delay will usually be, at most, a few seconds. 2679 Nevertheless, even if fragments take different paths of different 2680 characteristics, the recommended 60 to 120 seconds are, in practice, 2681 excessive. 2683 Some systems have already reduced the fragment timeout to 30 seconds 2684 [Linux2006]. The fragment timeout could probably be further reduced 2685 to approximately 15 seconds; although further research on this issue 2686 is necessary. 2688 It should be noted that in network scenarios of long-delay and high- 2689 bandwidth (usually referred to as "Long-Fat Networks"), using a long 2690 fragment timeout would likely increase the probability of collision 2691 of IP ID numbers. Therefore, in such scenarios it is highly 2692 desirable to avoid the use of fragmentation with techniques such as 2693 PMTUD [RFC1191] or PLPMTUD [RFC4821]. 2695 4.1.2.5. Countermeasure for some IDS evasion techniques 2697 [Shankar2003] introduces a technique named "Active Mapping" that 2698 prevents evasion of a NIDS by acquiring sufficient knowledge about 2699 the network being monitored, to assess which packets will arrive at 2700 the intended recipient, and how they will be interpreted by it. 2701 [Novak2005] describes some techniques that are applied by the Snort 2702 NIDS to avoid evasion. 2704 4.1.2.6. Countermeasure for firewall-rules bypassing 2706 One of the classical techniques to bypass firewall rules involves 2707 sending packets in which the header of the encapsulated protocol is 2708 fragmented. Even when it would be legal (as far as the IETF 2709 specifications are concerned) to receive such a packets, the MTUs of 2710 the network technologies used in practice are not that small to 2711 require the header of the encapsulated protocol to be fragmented. 2712 Therefore, the system performing reassembly should drop all packets 2713 which fragment the upper-layer protocol header, and this event should 2714 be logged (e.g., a counter could be incremented to reflect the packet 2715 drop). 2717 Additionally, given that many middle-boxes such as firewalls create 2718 state according to the contents of the first fragment of a given 2719 packet, it is best that, in the event an end-system receives 2720 overlapping fragments, it honors the information contained in the 2721 fragment that was received first. 2723 RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass 2724 firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. 2726 4.2. Forwarding 2728 4.2.1. Precedence-ordered queue service 2730 Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should 2731 implement precedence-ordered queue service. This means that when a 2732 packet is selected for output on a (logical) link, the packet of 2733 highest precedence that has been queued for that link is sent. 2734 Section 5.3.3.2 of RFC 1812 advices routers to default to maintaining 2735 strict precedence-ordered service. 2737 Unfortunately, given that it is trivial to forge the IP precedence 2738 field of the IP header, an attacker could simply forge a high 2739 precedence number in the packets it sends, to illegitimately get 2740 better network service. If precedence-ordered queued service is not 2741 required in a particular network infrastructure, it should be 2742 disabled, and thus all packets would receive the same type of 2743 service, despite the values in their Type of Service or 2744 Differentiated Services fields. 2746 When Precedence-ordered queue service is required in the network 2747 infrastructure, in order to mitigate the attack vector discussed in 2748 the previous paragraph, edge routers or switches should be configured 2749 to police and remark the Type of Service or Differentiated Services 2750 values, according to the type of service at which each end-system has 2751 been allowed to send packets. 2753 Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT 2754 change precedence settings on packets it did not originate". 2755 However, given the security implications of the Precedence field, it 2756 is fair for routers, switches or other middle-boxes, particularly 2757 those in the network edge, to overwrite the Type of Service (or 2758 Differentiated Services) field of the packets they are forwarding, 2759 according to a configured network policy (this is the specified 2760 behavior for DS domains [RFC2475]). 2762 Section 5.3.3.1 and Section 5.3.6 of RFC 1812 states that if 2763 precedence-ordered queue service is implemented and enabled, the 2764 router "MUST NOT discard a packet whose precedence is higher than 2765 that of a packet that is not discarded". While this recommendation 2766 makes sense given the semantics of the Precedence field, it is 2767 important to note that it would be simple for an attacker to send 2768 packets with forged high Precedence value to congest some internet 2769 router(s), and cause all (or most) traffic with a lower Precedence 2770 value to be discarded. 2772 4.2.2. Weak Type of Service 2774 Section 5.2.4.3 of RFC 1812 describes the algorithm for determining 2775 the next-hop address (i.e., the forwarding algorithm). Bullet 3, 2776 "Weak TOS", addresses the case in which routes contain a "type of 2777 service" attribute. It states that in case a packet contains a non- 2778 default TOS (i.e., 0000), only routes with the same TOS or with the 2779 default TOS should be considered for forwarding that packet. 2780 However, this means that if among the longest match routes for a 2781 given packet are routes with some TOS other than the one contained in 2782 the received packet, and no routes with the default TOS, the 2783 corresponding packet would be dropped. This may or may not be a 2784 desired behavior. 2786 An alternative for the case in which among the "longest match" routes 2787 there are only routes with non-default type of service which do not 2788 match the TOS contained in the received packet, would be to use a 2789 route with any other TOS. While this route would most likely not be 2790 able to address the type of service requested by packet, it would, at 2791 least, provide a "best effort" service. 2793 It must be noted that Section 5.3.2 of RFC 1812 allows routers to not 2794 honor the TOS field. Therefore, the proposed alternative behavior is 2795 still compliant with the IETF specifications. 2797 While officially specified in the RFC series, TOS-based routing is 2798 not widely deployed in the Internet. 2800 4.2.3. Impact of Address Resolution on Buffer Management 2802 In the case of broadcast link-layer technologies, in order for a 2803 system to transfer an IP datagram it must usually first map an IP 2804 address to the corresponding link-layer address (for example, by 2805 means of the ARP protocol [RFC0826]) . This means that while this 2806 operation is being performed, the packets that would require such a 2807 mapping would need to be kept in memory. This may happen both in the 2808 case of hosts and in the case of routers. 2810 This situation might be exploited by an attacker, which could send a 2811 large amount of packets to a non-existent host which would supposedly 2812 be directly connected to the attacked router. While trying to map 2813 the corresponding IP address into a link-layer address, the attacked 2814 router would keep in memory all the packets that would need to make 2815 use of that link-layer address. At the point in which the mapping 2816 function times out, depending on the policy implemented by the 2817 attacked router, only the packet that triggered the call to the 2818 mapping function might be dropped. In that case, the same operation 2819 would be repeated for every packet destined to the non-existent host. 2820 Depending on the timeout value for the mapping function, this 2821 situation might lead the router to run out of free buffer space, with 2822 the consequence that incoming legitimate packets would have to be 2823 dropped, or that legitimate packets already stored in the router's 2824 buffers might get dropped. Both of these situations would lead 2825 either to a complete Denial of Service, or to a degradation of the 2826 network service. 2828 One countermeasure to this problem would be to drop, at the point the 2829 mapping function times out, all the packets destined to the address 2830 that timed out. In addition, a "negative cache entry" might be kept 2831 in the module performing the matching function, so that for some 2832 amount of time, the mapping function would return an error when the 2833 IP module requests to perform a mapping for some address for which 2834 the mapping has recently timed out. 2836 A common implementation strategy for routers is that when a packet 2837 is received that requires an ARP resolution to be performed before 2838 the packet can be forwarded, the packet is dropped and the router 2839 is then engaged in the ARP procedure. 2841 4.2.4. Dropping packets 2843 In some scenarios, it may be necessary for a host or router to drop 2844 packets from the output queue. In the event one of such packets 2845 happens to be an IP fragment, and there were other fragments of the 2846 same packet in the queue, those other fragments should also be 2847 dropped. The rationale for this policy is that it is nonsensical to 2848 spend system resources on those other fragments, because, as long as 2849 one fragment is missing, it will be impossible for the receiving 2850 system to reassemble them into a complete IP datagram. 2852 Some systems have been known to drop just a subset of fragments of a 2853 given datagram, leading to a denial of service condition, as only a 2854 subset of all the fragments of the packets were actually transferred 2855 to the next hop. 2857 4.3. Addressing 2858 4.3.1. Unreachable addresses 2860 It is important to understand that while there are some addresses 2861 that are supposed to be unreachable from the public Internet (such as 2862 the private IP addresses described in RFC 1918 [RFC1918], or the 2863 "loopback" address), there are a number of tricks an attacker can 2864 perform to reach those IP addresses that would otherwise be 2865 unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore, 2866 when applicable, packet filtering should be performed at private 2867 network boundary to assure that those addresses will be unreachable. 2869 Similarly, link-local unicast addresses [RFC3927] and multicast 2870 addresses with limited scope (link- and site-local addresses) should 2871 not be accessible from outside the proper network boundaries and not 2872 be passed across these boundaries. 2874 [RFC5735] provides a summary of special use IPv4 addresses. 2876 4.3.2. Private address space 2878 The Internet Assigned Numbers Authority (IANA) has reserved the 2879 following three blocks of the IP address space for private internets: 2881 o 10.0.0.0 - 10.255.255.255 (10/8 prefix) 2883 o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 2885 o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 2887 Use of these address blocks is described in RFC 1918 [RFC1918]. 2889 Where applicable, packet filtering should be performed at the 2890 organizational perimeter to assure that these addresses are not 2891 reachable from outside the private network where such addresses are 2892 employed. 2894 4.3.3. Former Class D Addresses (224/4 Address Block) 2896 The former Class D addresses correspond to the 224/4 address block, 2897 and are used for Internet multicast. Therefore, if a packet is 2898 received with a "Class D" address as the Source Address, it should be 2899 dropped, and this event should be logged (e.g., a counter could be 2900 incremented to reflect the packet drop). Additionally, if an IP 2901 packet with a multicast Destination Address is received for a 2902 connection-oriented protocol (e.g., TCP), the packet should be 2903 dropped (see Section 4.3.5), and this event should be logged (e.g., a 2904 counter could be incremented to reflect the packet drop). 2906 4.3.4. Former Class E Addresses (240/4 Address Block) 2908 The former Class E addresses correspond to the 240/4 address block, 2909 and are currently reserved for experimental use. As a result, a most 2910 routers discard packets that contain a "Class" E address as the 2911 Source Address or Destination Address. If a packet is received with 2912 a 240/4 address as the Source Address and/or the Destination Address, 2913 the packet should be dropped and this event should be logged (e.g., a 2914 counter could be incremented to reflect the packet drop). 2916 It should be noted that the broadcast address 255.255.255.255 still 2917 must be treated as indicated in Section 4.3.7 of this document. 2919 4.3.5. Broadcast/Multicast addresses, and Connection-Oriented Protocols 2921 For connection-oriented protocols, such as TCP, shared state is 2922 maintained between only two endpoints at a time. Therefore, if an IP 2923 packet with a multicast (or broadcast) Destination Address is 2924 received for a connection-oriented protocol (e.g., TCP), the packet 2925 should be dropped, and this event should be logged (e.g., a counter 2926 could be incremented to reflect the packet drop). 2928 4.3.6. Broadcast and network addresses 2930 Originally, the IETF specifications did not permit IP addresses to 2931 have the value 0 or -1 (shorthand for all bits set to 1) for any of 2932 the Host number, network number, or subnet number fields, except for 2933 the cases indicated in Section 4.3.7. However, this changed 2934 fundamentally with the deployment of Classless Inter-Domain Routing 2935 (CIDR) [RFC4632], as with CIDR a system cannot know a priori what the 2936 subnet mask is for a particular IP address. 2938 Many systems now allow administrators to use the values 0 or -1 for 2939 those fields. Despite that according to the original IETF 2940 specifications these addresses are illegal, modern IP implementations 2941 should consider these addresses to be valid. 2943 4.3.7. Special Internet addresses 2945 RFC 1812 [RFC1812] discusses the use of some special internet 2946 addresses, which is of interest to perform some sanity checks on the 2947 Source Address and Destination Address fields of an IP packet. It 2948 uses the following notation for an IP address: 2950 { , } 2952 where the length of the network prefix is generally implied by the 2953 network mask assigned to the IP interface under consideration. 2955 RFC 1122 [RFC1122] contained a similar discussion of special 2956 internet addresses, including some of the form { , 2957 , }. However, as explained in 2958 Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number 2959 is clearly an extension of the network prefix and cannot be 2960 distinguished from the remainder of the prefix. 2962 {0, 0} 2964 This address means "this host on this network". It is meant to be 2965 used only during the initialization procedure, by which the host 2966 learns its own IP address. 2968 If a packet is received with 0.0.0.0 as the Source Address for any 2969 purpose other than bootstrapping, the corresponding packet should be 2970 silently dropped, and this event should be logged (e.g., a counter 2971 could be incremented to reflect the packet drop). If a packet is 2972 received with 0.0.0.0 as the Destination Address, it should be 2973 silently dropped, and this event should be logged (e.g., a counter 2974 could be incremented to reflect the packet drop). 2976 {0, Host number} 2978 This address means "the specified host, in this network". As in the 2979 previous case, it is meant to be used only during the initialization 2980 procedure by which the host learns its own IP address. If a packet 2981 is received with such an address as the Source Address for any 2982 purpose other than bootstrapping, it should be dropped, and this 2983 event should be logged (e.g., a counter could be incremented to 2984 reflect the packet drop). If a packet is received with such an 2985 address as the Destination Address, it should be dropped, and this 2986 event should be logged (e.g., a counter could be incremented to 2987 reflect the packet drop). 2989 {-1, -1} 2991 This address is the local broadcast address. It should not be used 2992 as a source IP address. If a packet is received with 255.255.255.255 2993 as the Source Address, it should be dropped, and this event should be 2994 logged (e.g., a counter could be incremented to reflect the packet 2995 drop). 2997 Some systems, when receiving an ICMP echo request, for example, 2998 will use the Destination Address in the ICMP echo request packet 2999 as the Source Address of the response they send (in this case, an 3000 ICMP echo reply). Thus, when such systems receive a request sent 3001 to a broadcast address, the Source Address of the response will 3002 contain a broadcast address. This should be considered a bug, 3003 rather than a malicious use of the limited broadcast address. 3005 {Network number, -1} 3007 This is the directed broadcast to the specified network. As 3008 recommended by RFC 2644 [RFC2644], routers should not forward 3009 network-directed broadcasts. This avoids the corresponding network 3010 from being utilized as, for example, a "smurf amplifier" [CERT1998a]. 3012 As noted in Section 4.3.6 of this document, many systems now allow 3013 administrators to configure these addresses as unicast addresses for 3014 network interfaces. In such scenarios, routers should forward these 3015 addresses as if they were traditional unicast addresses. 3017 In some scenarios a host may have knowledge about a particular IP 3018 address being a network-directed broadcast address, rather than a 3019 unicast address (e.g., that IP address is configured on the local 3020 system as a "broadcast address"). In such scenarios, if a system can 3021 infer that the Source Address of a received packet is a network- 3022 directed broadcast address, the packet should be dropped, and this 3023 event should be logged (e.g., a counter could be incremented to 3024 reflect the packet drop). 3026 As noted in Section 4.3.6 of this document, with the deployment of 3027 CIDR [RFC4632], it may be difficult for a system to infer whether a 3028 particular IP address that does not belong to a directly attached 3029 subnet is a broadcast address. 3031 {127.0.0.0/8, any} 3033 This is the internal host loopback address. Any packet that arrives 3034 on any physical interface containing this address as the Source 3035 Address, the Destination Address, or as part of a source route 3036 (either LSRR or SSRR), should be dropped. 3038 For example, packets with a Destination Address in the 127.0.0.0/8 3039 address block that are received on an interface other than loopback 3040 should be silently dropped. Packets received on any interface other 3041 than loopback with a Source Address corresponding to the system 3042 receiving the packet should also be dropped. 3044 In all the above cases, when a packet is dropped, this event should 3045 be logged (e.g., a counter could be incremented to reflect the packet 3046 drop). 3048 5. Security Considerations 3050 This document discusses the security implications of the Internet 3051 Protocol (IP) and a number of implementation strategies that help to 3052 mitigate a number of vulnerabilities found in the protocol during the 3053 last 25 years or so. 3055 6. Acknowledgements 3057 The author wishes to thank Alfred Hoenes for providing very thorough 3058 reviews of earlier versions of this document, thus leading to 3059 numerous improvements. 3061 The author would like to thank Jari Arkko, Ron Bonica, Stewart 3062 Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and 3063 Andrew Yourtchenko for providing valuable comments on earlier 3064 versions of this document. 3066 This document was written by Fernando Gont on behalf of the UK CPNI 3067 (United Kingdom's Centre for the Protection of National 3068 Infrastructure), and is heavily based on the "Security Assessment of 3069 the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008. 3071 The author would like to thank Randall Atkinson, John Day, Juan 3072 Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka 3073 Savola, and Christos Zoulas for providing valuable comments on 3074 earlier versions of [CPNI2008], on which this document is based. 3076 The author would like to thank Randall Atkinson and Roque Gagliano, 3077 who generously answered a number of questions. 3079 Finally, the author would like to thank UK CPNI (formerly NISCC) for 3080 their continued support. 3082 7. References 3084 7.1. Normative References 3086 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3087 September 1981. 3089 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 3090 converting network protocol addresses to 48.bit Ethernet 3091 address for transmission on Ethernet hardware", STD 37, 3092 RFC 826, November 1982. 3094 [RFC1038] St. Johns, M., "Draft revised IP security option", 3095 RFC 1038, January 1988. 3097 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 3098 MTU discovery options", RFC 1063, July 1988. 3100 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 3102 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 3103 RFC 1112, August 1989. 3105 [RFC1122] Braden, R., "Requirements for Internet Hosts - 3106 Communication Layers", STD 3, RFC 1122, October 1989. 3108 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3109 November 1990. 3111 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 3112 Suite", RFC 1349, July 1992. 3114 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 3115 January 1993. 3117 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 3118 Destination Delivery", RFC 1770, March 1995. 3120 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 3121 RFC 1812, June 1995. 3123 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3124 E. Lear, "Address Allocation for Private Internets", 3125 BCP 5, RFC 1918, February 1996. 3127 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 3128 February 1997. 3130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3131 Requirement Levels", BCP 14, RFC 2119, March 1997. 3133 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3134 "Definition of the Differentiated Services Field (DS 3135 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3136 December 1998. 3138 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3139 and W. Weiss, "An Architecture for Differentiated 3140 Services", RFC 2475, December 1998. 3142 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 3143 in Routers", BCP 34, RFC 2644, August 1999. 3145 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3146 Defeating Denial of Service Attacks which employ IP Source 3147 Address Spoofing", BCP 38, RFC 2827, May 2000. 3149 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3150 of Explicit Congestion Notification (ECN) to IP", 3151 RFC 3168, September 2001. 3153 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3154 Networks", BCP 84, RFC 3704, March 2004. 3156 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 3157 Configuration of IPv4 Link-Local Addresses", RFC 3927, 3158 May 2005. 3160 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3161 Requirements for Security", BCP 106, RFC 4086, June 2005. 3163 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3164 (CIDR): The Internet Address Assignment and Aggregation 3165 Plan", BCP 122, RFC 4632, August 2006. 3167 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3168 Discovery", RFC 4821, March 2007. 3170 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 3171 Pignataro, "The Generalized TTL Security Mechanism 3172 (GTSM)", RFC 5082, October 2007. 3174 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 3175 IPv4 and IPv6 Router Alert Options", RFC 5350, 3176 September 2008. 3178 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 3179 BCP 153, RFC 5735, January 2010. 3181 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 3182 Notification", RFC 6040, November 2010. 3184 7.2. Informative References 3186 [Anderson2001] 3187 Anderson, J., "An Analysis of Fragmentation Attacks", 3188 Available at: http://www.ouah.org/fragma.html , 2001. 3190 [Arkin2000] 3191 Arkin, "IP TTL Field Value with ICMP (Oops - Identifying 3192 Windows 2000 again and more)", http:// 3193 ofirarkin.files.wordpress.com/2008/11/ 3194 ofirarkin2000-06.pdf, 2000. 3196 [Barisani2006] 3197 Barisani, A., "FTester - Firewall and IDS testing tool", 3198 Available at: http://dev.inversepath.com/trac/ftester , 3199 2001. 3201 [Bellovin1989] 3202 Bellovin, S., "Security Problems in the TCP/IP Protocol 3203 Suite", Computer Communication Review Vol. 19, No. 2, pp. 3204 32-48, 1989. 3206 [Bellovin2002] 3207 Bellovin, S., "A Technique for Counting NATted Hosts", 3208 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 3210 [Bendi1998] 3211 Bendi, "Bonk exploit", http://www.insecure.org/sploits/ 3212 95.NT.fragmentation.bonk.html , 1998. 3214 [Biondi2007] 3215 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 3216 CanSecWest 2007 Security Conference http://www.secdev.org/ 3217 conf/IPv6_RH_security-csw07.pdf, 2007. 3219 [CERT1996a] 3220 CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- 3221 Service Attack", 3222 http://www.cert.org/advisories/CA-1996-01.html, 1996. 3224 [CERT1996b] 3225 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 3226 Spoofing Attacks", 3227 http://www.cert.org/advisories/CA-1996-21.html, 1996. 3229 [CERT1996c] 3230 CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack 3231 via ping", 3232 http://www.cert.org/advisories/CA-1996-26.html, 1996. 3234 [CERT1997] 3235 CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service 3236 Attacks", http://www.cert.org/advisories/CA-1997-28.html, 3237 1997. 3239 [CERT1998a] 3240 CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- 3241 Service Attacks", 3242 http://www.cert.org/advisories/CA-1998-01.html, 1998. 3244 [CERT1998b] 3245 CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain 3246 TCP/IP Implementations", 3247 http://www.cert.org/advisories/CA-1998-13.html, 1998. 3249 [CERT1999] 3250 CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 3251 http://www.cert.org/advisories/CA-1999-17.html, 1999. 3253 [CERT2001] 3254 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 3255 TCP/IP Initial Sequence Numbers", 3256 http://www.cert.org/advisories/CA-2001-09.html, 2001. 3258 [CERT2003] 3259 CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface 3260 Blocked by IPv4 Packet", 3261 http://www.cert.org/advisories/CA-2003-15.html, 2003. 3263 [CIPSO1992] 3264 CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF 3265 Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work 3266 in progress , 1992. 3268 [CIPSOWG1994] 3269 CIPSOWG, "Commercial Internet Protocol Security Option 3270 (CIPSO) Working Group", http://www.ietf.org/proceedings/ 3271 94jul/charters/cipso-charter.html, 1994. 3273 [CPNI2008] 3274 Gont, F., "Security Assessment of the Internet Protocol", 3275 2008, . 3277 [Cerf1974] 3278 Cerf, V. and R. Kahn, "A Protocol for Packet Network 3279 Intercommunication", IEEE Transactions on 3280 Communications Vol. 22, No. 5, May 1974, pp. 637-648, 3281 1974. 3283 [Cisco2003] 3284 Cisco, "Cisco Security Advisory: Cisco IOS Interface 3285 Blocked by IPv4 packet", http://www.cisco.com/en/US/ 3286 products/products_security_advisory09186a00801a34c2.shtml, 3287 2003. 3289 [Cisco2008] 3290 Cisco, "Cisco IOS Security Configuration Guide, Release 3291 12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/ 3292 configuration/guide/scfipso.html, 2003. 3294 [Clark1988] 3295 Clark, D., "The Design Philosophy of the DARPA Internet 3296 Protocols", Computer Communication Review Vol. 18, No. 4, 3297 1988. 3299 [Ed3f2002] 3300 Ed3f, "Firewall spotting and networks analisys with a 3301 broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, 3302 Phile #0x0c of 0x10 http://www.phrack.org/ 3303 issues.html?issue=60&id=12&mode=txt, 2002. 3305 [FIPS1994] 3306 FIPS, "Standard Security Label for Information Transfer", 3307 Federal Information Processing Standards Publication. FIP 3308 PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ 3309 fips188.pdf, 1994. 3311 [Fyodor2004] 3312 Fyodor, "Idle scanning and related IP ID games", 3313 http://www.insecure.org/nmap/idlescan.html, 2004. 3315 [GIAC2000] 3316 GIAC, "Egress Filtering v 0.2", 3317 http://www.sans.org/y2k/egress.htm, 2000. 3319 [Gont2006] 3320 Gont, F., "Advanced ICMP packet filtering", 3321 http://www.gont.com.ar/papers/icmp-filtering.html, 2006. 3323 [Haddad2004] 3324 Haddad, I. and M. Zakrzewski, "Security Distribution for 3325 Linux Clusters", Linux 3326 Journal http://www.linuxjournal.com/article/6943, 2004. 3328 [Humble1998] 3329 Humble, "Nestea exploit", 3330 http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 3331 1998. 3333 [I-D.ietf-intarea-router-alert-considerations] 3334 Faucheur, F., "IP Router Alert Considerations and Usage", 3335 draft-ietf-intarea-router-alert-considerations-03 (work in 3336 progress), March 2011. 3338 [I-D.templin-mtuassurance] 3339 Templin, F., "Requirements for IP-in-IP Tunnel MTU 3340 Assurance", draft-templin-mtuassurance-02 (work in 3341 progress), October 2006. 3343 [IANA2006a] 3344 Ether Types, 3345 "http://www.iana.org/assignments/ethernet-numbers". 3347 [IANA2006b] 3348 IP Parameters, 3349 "http://www.iana.org/assignments/ip-parameters". 3351 [IANA2006c] 3352 Protocol Numbers, 3353 "http://www.iana.org/assignments/protocol-numbers". 3355 [IRIX2008] 3356 IRIX, "IRIX 6.5 trusted_networking(7) manual page", http: 3357 //techpubs.sgi.com/library/tpl/cgi-bin/ 3358 getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ 3359 cat7/trusted_networking.z, 2008. 3361 [Jones2002] 3362 Jones, R., "A Method Of Selecting Values For the 3363 Parameters Controlling IP Fragment Reassembly", ftp:// 3364 ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt, 3365 2002. 3367 [Kenney1996] 3368 Kenney, M., "The Ping of Death Page", 3369 http://www.insecure.org/sploits/ping-o-death.html, 1996. 3371 [Kent1987] 3372 Kent, C. and J. Mogul, "Fragmentation considered harmful", 3373 Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987. 3375 [Klein2007] 3376 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 3377 Predictable IP ID Vulnerability", http:// 3378 www.trusteer.com/files/ 3379 OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP 3380 _ID_Vulnerability.pdf, 2007. 3382 [Kohno2005] 3383 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 3384 Device Fingerprinting", IEEE Transactions on Dependable 3385 and Secure Computing Vol. 2, No. 2, 2005. 3387 [LBNL2006] 3388 LBNL/NRG, "arpwatch tool", http://ee.lbl.gov/, 2006. 3390 [Linux2006] 3391 The Linux Project, "http://www.kernel.org". 3393 [Microsoft1999] 3394 Microsoft, "Microsoft Security Program: Microsoft Security 3395 Bulletin (MS99-038). Patch Available for "Spoofed Route 3396 Pointer" Vulnerability", http://www.microsoft.com/ 3397 technet/security/bulletin/ms99-038.mspx, 1999. 3399 [NISCC2004] 3400 NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability 3401 Issues in TCP", 3402 http://www.uniras.gov.uk/niscc/docs/ 3403 re-20040420-00391.pdf, 2004. 3405 [NISCC2005] 3406 NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 3407 Vulnerability Issues in ICMP packets with TCP payloads", 3408 http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf, 3409 2005. 3411 [NISCC2006] 3412 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 3413 Filtering", http://www.niscc.gov.uk/niscc/docs/ 3414 re-20060420-00294.pdf?lang=en, 2006. 3416 [Northcutt2000] 3417 Northcut, S. and Novak, "Network Intrusion Detection - An 3418 Analyst's Handbook", Second Edition New Riders Publishing, 3419 2000. 3421 [Novak2005] 3422 Novak, "Target-Based Fragmentation Reassembly", 3423 http://www.snort.org/reg/docs/target_based_frag.pdf, 3424 2005. 3426 [OpenBSD-PF] 3427 Sanfilippo, S., "PF: Scrub (Packet Normalization)", 3428 http://www.openbsd.org/faq/pf/scrub.html, 2010. 3430 [OpenBSD1998] 3431 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 3432 Problem", 3433 http://www.openbsd.org/advisories/sourceroute.txt, 1998. 3435 [Paxson2001] 3436 Paxson, V., Handley, M., and C. Kreibich, "Network 3437 Intrusion Detection: Evasion, Traffic Normalization, and 3438 End-to-End Protocol Semantics", USENIX Conference, 2001, 3439 2001. 3441 [Ptacek1998] 3442 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 3443 of Service: Eluding Network Intrusion Detection", 3444 http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps, 3445 1998. 3447 [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, 3448 July 1982. 3450 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 3451 Considerations for IP Fragment Filtering", RFC 1858, 3452 October 1995. 3454 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 3455 Network Interconnect Devices", RFC 2544, March 1999. 3457 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3458 via IPv4 Clouds", RFC 3056, February 2001. 3460 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 3461 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 3463 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 3464 Beame, C., Eisler, M., and D. Noveck, "Network File System 3465 (NFS) version 4 Protocol", RFC 3530, April 2003. 3467 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 3468 Network Tunneling", RFC 4459, April 2006. 3470 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3471 Errors at High Data Rates", RFC 4963, July 2007. 3473 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3474 Mitigations", RFC 4987, August 2007. 3476 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 3477 Architecture", RFC 5559, June 2009. 3479 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 3480 Architecture Label IPv6 Security Option (CALIPSO)", 3481 RFC 5570, July 2009. 3483 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 3484 Nodes", RFC 5670, November 2009. 3486 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 3487 Encoding and Transport of Pre-Congestion Information", 3488 RFC 5696, November 2009. 3490 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 3492 [SELinux2008] 3493 Security Enhanced Linux, "http://www.nsa.gov/selinux/". 3495 [Sanfilippo1998a] 3496 Sanfilippo, S., "about the ip header id", Post to Bugtraq 3497 mailing-list, Mon Dec 14 3498 1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998. 3500 [Sanfilippo1998b] 3501 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing- 3502 list http://www.kyuzz.org/antirez/papers/dumbscan.html, 3503 1998. 3505 [Sanfilippo1999] 3506 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 3507 list http://www.kyuzz.org/antirez/papers/moreipid.html, 3508 1999. 3510 [Shankar2003] 3511 Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS 3512 Evasion Without Altering Traffic", 3513 http://www.icir.org/vern/papers/activemap-oak03.pdf, 3514 2003. 3516 [Shannon2001] 3517 Shannon, C., Moore, D., and K. Claffy, "Characteristics of 3518 Fragmented IP Traffic on Internet Links", 2001. 3520 [Silbersack2005] 3521 Silbersack, M., "Improving TCP/IP security through 3522 randomization without sacrificing interoperability", 3523 EuroBSDCon 2005 Conference http://www.silby.com/ 3524 eurobsdcon05/eurobsdcon_slides.pdf, 2005. 3526 [Solaris2008] 3527 Solaris Trusted Extensions - Labeled Security for Absolute 3528 Protection, "http://www.sun.com/software/solaris/ds/ 3529 trusted_extensions.jsp#3", 2008. 3531 [Song1999] 3532 Song, D., "Frag router tool", 3533 http://www.anzen.com/research/nidsbench/. 3535 [SpooferProject] 3536 MIT ANA, "The MIT ANA Spoofer project", 3537 http://spoofer.csail.mit.edu/index.php, 2010. 3539 [US-CERT2001] 3540 US-CERT, "US-CERT Vulnerability Note VU#446689: Check 3541 Point FireWall-1 allows fragmented packets through 3542 firewall if Fast Mode is enabled", 3543 http://www.kb.cert.org/vuls/id/446689, 2001. 3545 [US-CERT2002] 3546 US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS 3547 discloses fragments of previous packets when Express 3548 Forwarding is enabled", 3549 http://www.kb.cert.org/vuls/id/310387, 2002. 3551 [Watson2004] 3552 Watson, P., "Slipping in the Window: TCP Reset Attacks", 3553 CanSecWest Conference , 2004. 3555 [Zakrzewski2002] 3556 Zakrzewski, M. and I. Haddad, "Linux Distributed Security 3557 Module", http://www.linuxjournal.com/article/6215, 2002. 3559 [daemon91996] 3560 daemon9, route, and infinity, "IP-spoofing Demystified 3561 (Trust-Relationship Exploitation)", Phrack Magazine, 3562 Volume Seven, Issue Forty-Eight, File 14 of 18 http:// 3563 www.phrack.org/issues.html?issue=48&id=14&mode=txt, 1988. 3565 Appendix A. Changes from previous versions of the draft 3567 This whole appendix should be removed by the RFC Editor before 3568 publishing this document as an RFC. 3570 A.1. Changes from draft-ietf-opsec-ip-security-05 3571 o Addresses IESG review comments by Tim Polk (?). 3573 A.2. Changes from draft-ietf-opsec-ip-security-04 3575 o Addresses IESG review comments by Jari Arkko, Stewart Bryant, 3576 Adrian Farrel, Peter Saint-Andre, and Sean Turner. 3578 A.3. Changes from draft-ietf-opsec-ip-security-03 3580 o Addresses feedback received off-list by Warren Kumari. 3582 A.4. Changes from draft-ietf-opsec-ip-security-02 3584 o Addresses a very thorough review by Alfred Hoenes (sent off-list) 3586 o Miscellaneous edits (centers expressions, fills missing graphics 3587 with ASCII-art, etc.) 3589 A.5. Changes from draft-ietf-opsec-ip-security-01 3591 o Addresses rest of the feedback received from Andrew Yourtchenko 3592 (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) 3594 o Addresses a very thorough review by Alfred Hoenes (sent off-list) 3596 o Addresses feedback submitted by Joel Jaeggli (off-list) 3598 o Addresses feedback submitted (off-list) by Bruno Rohee. 3600 o Miscellaneous edits (centers expressions, fills missing graphics 3601 with ASCII-art, etc.) 3603 A.6. Changes from draft-ietf-opsec-ip-security-00 3605 o Addresses part of the feedback received from Andrew Yourtchenko 3606 (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) 3608 A.7. Changes from draft-gont-opsec-ip-security-01 3610 o Draft resubmitted as draft-ietf, as a result of wg consensus on 3611 adopting the document as an opsec wg item. 3613 A.8. Changes from draft-gont-opsec-ip-security-00 3615 o Fixed author's affiliation. 3617 o Added Figure 6. 3619 o Fixed a few typos. 3621 o (no technical changes) 3623 Author's Address 3625 Fernando Gont 3626 UK Centre for the Protection of National Infrastructure 3628 Email: fernando@gont.com.ar 3629 URI: http://www.cpni.gov.uk