idnits 2.17.1 draft-ietf-opsec-ip-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 date (January 29, 2009) is 5538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CERT2001' is defined on line 2975, but no explicit reference was found in the text == Unused Reference: 'I-D.stjohns-sipso' is defined on line 3072, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-mtuassurance' is defined on line 3077, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 3210, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 3217, 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) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-04 == Outdated reference: A later version (-11) exists of draft-stjohns-sipso-06 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) 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 F. Gont 3 for IP Network Infrastructure UK CPNI 4 (opsec) January 29, 2009 5 Internet-Draft 6 Intended status: Informational 7 Expires: August 2, 2009 9 Security Assessment of the Internet Protocol version 4 10 draft-ietf-opsec-ip-security-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 2, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document contains a security assessment of the IETF 50 specifications of the Internet Protocol version 4, and of a number of 51 mechanisms and policies in use by popular IPv4 implementations. It 52 is based on the results of a project carried out by the UK's Centre 53 for the Protection of National Infrastructure (CPNI). 55 Table of Contents 57 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 60 1.3. Organization of this document . . . . . . . . . . . . . . 6 61 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6 62 3. Internet Protocol header fields . . . . . . . . . . . . . . . 7 63 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8 65 3.3. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 11 68 3.5.1. Some workarounds implemented by the industry . . . . . 11 69 3.5.2. Possible security improvements . . . . . . . . . . . . 12 70 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 15 72 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 16 73 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 22 75 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 22 76 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 23 77 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 3.13.1. General issues with IP options . . . . . . . . . . . . 24 79 3.13.1.1. Processing requirements . . . . . . . . . . . . . 24 80 3.13.1.2. Processing of the options by the upper layer 81 protocol . . . . . . . . . . . . . . . . . . . . 25 82 3.13.1.3. General sanity checks on IP options . . . . . . . 25 83 3.13.2. Issues with specific options . . . . . . . . . . . . . 27 84 3.13.2.1. End of Option List (Type = 0) . . . . . . . . . . 27 85 3.13.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 27 86 3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 27 87 3.13.2.4. Strict Source and Record Route (SSRR) (Type = 88 137) . . . . . . . . . . . . . . . . . . . . . . 30 89 3.13.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 33 90 3.13.2.6. Stream Identifier (Type = 136) . . . . . . . . . 34 91 3.13.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 35 92 3.13.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 38 93 3.13.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 38 94 3.13.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 38 95 3.13.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 39 96 3.13.2.12. DoD Basic Security Option (Type = 130) . . . . . 39 97 3.13.2.13. DoD Extended Security Option (Type = 133) . . . . 40 98 3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 99 134) . . . . . . . . . . . . . . . . . . . . . . 40 100 3.13.2.15. Sender Directed Multi-Destination Delivery 101 (Type = 149) . . . . . . . . . . . . . . . . . . 41 102 3.14. Differentiated Services field . . . . . . . . . . . . . . 41 103 3.15. Explicit Congestion Notification (ECN) . . . . . . . . 42 104 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 44 105 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 44 106 4.1.1. Problems related with memory allocation . . . . . . . 45 107 4.1.2. Problems that arise from the length of the IP 108 Identification field . . . . . . . . . . . . . . . . . 46 109 4.1.3. Problems that arise from the complexity of the 110 reassembly algorithm . . . . . . . . . . . . . . . . . 47 111 4.1.4. Problems that arise from the ambiguity of the 112 reassembly process . . . . . . . . . . . . . . . . . . 48 113 4.1.5. Problems that arise from the size of the IP 114 fragments . . . . . . . . . . . . . . . . . . . . . . 49 115 4.1.6. Possible security improvements . . . . . . . . . . . . 49 116 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 54 117 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 54 118 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 55 119 4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 56 120 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 57 121 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 57 122 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 57 123 4.3.2. Private address space . . . . . . . . . . . . . . . . 57 124 4.3.3. Class D addresses (224/4 address block) . . . . . . . 58 125 4.3.4. Class E addresses (240/4 address block) . . . . . . . 58 126 4.3.5. Broadcast and multicast addresses, and 127 connection-oriented protocols . . . . . . . . . . . . 58 128 4.3.6. Broadcast and network addresses . . . . . . . . . . . 58 129 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 59 130 5. Security Considerations . . . . . . . . . . . . . . . . . . . 60 131 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 132 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 133 7.1. Normative References . . . . . . . . . . . . . . . . . . . 61 134 7.2. Informative References . . . . . . . . . . . . . . . . . . 62 135 Appendix A. Advice and guidance to vendors . . . . . . . . . . . 70 136 Appendix B. Changes from previous versions of the draft (to 137 be removed by the RFC Editor before publishing 138 this document as an RFC) . . . . . . . . . . . . . . 71 139 B.1. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 71 140 B.2. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 71 141 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71 143 1. Preface 145 1.1. Introduction 147 The TCP/IP protocols were conceived in an environment that was quite 148 different from the hostile environment they currently operate in. 149 However, the effectiveness of the protocols led to their early 150 adoption in production environments, to the point that, to some 151 extent, the current world's economy depends on them. 153 While many textbooks and articles have created the myth that the 154 Internet protocols were designed for warfare environments, the top 155 level goal for the DARPA Internet Program was the sharing of large 156 service machines on the ARPANET [Clark1988]. As a result, many 157 protocol specifications focus only on the operational aspects of the 158 protocols they specify, and overlook their security implications. 160 While the Internet technology evolved since it inception, the 161 Internet's building blocks are basically the same core protocols 162 adopted by the ARPANET more than two decades ago. During the last 163 twenty years, many vulnerabilities have been identified in the TCP/IP 164 stacks of a number of systems. Some of them were based in flaws in 165 some protocol implementations, affecting only a reduced number of 166 systems, while others were based in flaws in the protocols 167 themselves, affecting virtually every existing implementation 168 [Bellovin1989]. Even in the last couple of years, researchers were 169 still working on security problems in the core protocols 170 [I-D.ietf-tcpm-icmp-attacks] [Watson2004] [NISCC2004] [NISCC2005]. 172 The discovery of vulnerabilities in the TCP/IP protocols led to 173 reports being published by a number of CSIRTs (Computer Security 174 Incident Response Teams) and vendors, which helped to raise awareness 175 about the threats and the best mitigations known at the time the 176 reports were published. Unfortunately, this also led to the 177 documentation of the discovered protocol vulnerabilities being spread 178 among a large number of documents, which are sometimes difficult to 179 identify. 181 For some reason, much of the effort of the security community on the 182 Internet protocols did not result in official documents (RFCs) being 183 issued by the IETF (Internet Engineering Task Force). This basically 184 led to a situation in which "known" security problems have not always 185 been addressed by all vendors. In addition, in many cases vendors 186 have implemented quick "fixes" to protocol flaws without a careful 187 analysis of their effectiveness and their impact on interoperability 188 [Silbersack2005]. 190 The lack of adoption of these fixes by the IETF means that any system 191 built in the future according to the official TCP/IP specifications 192 will reincarnate security flaws that have already hit our 193 communication systems in the past. 195 Producing a secure TCP/IP implementation nowadays is a very difficult 196 task, in part because of the lack of a single document that serves as 197 a security roadmap for the protocols. Implementers are faced with 198 the hard task of identifying relevant documentation and differentiate 199 between that which provides correct advisory, and that which provides 200 misleading advisory based on inaccurate or wrong assumptions. 202 There is a clear need for a companion document to the IETF 203 specifications that discusses the security aspects and implications 204 of the protocols, identifies the possible threats, discusses the 205 possible counter-measures, and analyzes their respective 206 effectiveness. 208 This document is the result of an assessment the IETF specifications 209 of the Internet Protocol (IP), from a security point of view. 210 Possible threats were identified and, where possible, counter- 211 measures were proposed. Additionally, many implementation flaws that 212 have led to security vulnerabilities have been referenced in the hope 213 that future implementations will not incur the same problems. 214 Furthermore, this document does not limit itself to performing a 215 security assessment of the relevant IETF specifications, but also 216 provides an assessment of common implementation strategies found in 217 the real world. 219 This document does not aim to be the final word on the security of 220 the Internet Protocol (IP). On the contrary, it aims to raise 221 awareness about many security threats based on the IP protocol that 222 have been faced in the past, those that we are currently facing, and 223 those we may still have to deal with in the future. It provides 224 advice for the secure implementation of the Internet Protocol (IP), 225 but also provides insights about the security aspects of the Internet 226 Protocol that may be of help to the Internet operations community. 228 Feedback from the community is more than encouraged to help this 229 document be as accurate as possible and to keep it updated as new 230 threats are discovered. 232 This document is heavily based on the "Security Assessment of the 233 Internet Protocol" [CPNI2008] released by the UK Centre for the 234 Protection of National Infrastructure (CPNI), available at: 235 http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx . 237 1.2. Scope of this document 239 While there are a number of protocols that affect the way in which IP 240 systems operate, this document focuses only on the specifications of 241 the Internet Protocol (IP). For example, routing and bootstrapping 242 protocols are considered out of the scope of this project. 244 The following IETF RFCs were selected for assessment as part of this 245 work: 247 o RFC 791, "Internet Protocol. DARPA Internet Program. Protocol 248 Specification" (51 pages). 250 o RFC 815, "IP datagram reassembly algorithms" (9 pages). 252 o RFC 1122, "Requirements for Internet Hosts -- Communication 253 Layers" (116 pages). 255 o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages). 257 o RFC 2474, "Definition of the Differentiated Services Field (DS 258 Field) in the IPv4 and IPv6 Headers" (20 pages). 260 o RFC 2475, "An Architecture for Differentiated Services" (36 261 pages). 263 o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) 264 to IP" (63 pages). 266 1.3. Organization of this document 268 This document is basically organized in two parts: "Internet Protocol 269 header fields" and "Internet Protocol mechanisms". The former 270 contains an analysis of each of the fields of the Internet Protocol 271 header, identifies their security implications, and discusses the 272 possible counter-measures. The latter contains an analysis of the 273 security implications of the mechanisms implemented by the Internet 274 Protocol. 276 2. The Internet Protocol 278 The Internet Protocol (IP) provides a basic data transfer function, 279 in the form of data blocks called "datagrams", from a source host to 280 a destination host, across the possible intervening networks. 281 Additionally, it provides some functions that are useful for the 282 interconnection of heterogeneous networks, such as fragmentation and 283 reassembly. 285 The "datagram" has a number of characteristics that makes it 286 convenient for interconnecting systems [Clark1988]: 288 o It eliminates the need of connection state within the network, 289 which improves the survivability characteristics of the network. 291 o It provides a basic service of data transport that can be used as 292 a building block for other transport services (reliable data 293 transport services, etc.). 295 o It represents the minimum network service assumption, which 296 enables IP to be run over virtually any network technology. 298 3. Internet Protocol header fields 300 The IETF specifications of the Internet Protocol define the syntax of 301 the protocol header, along with the semantics of each of its fields. 302 Figure 1 shows the format of an IP datagram. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |Version| IHL |Type of Service| Total Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Identification |Flags| Fragment Offset | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Time to Live | Protocol | Header Checksum | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Source Address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Destination Address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Options | Padding | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 1: Internet Protocol header format 322 Even when the minimum IP header size is 20 bytes, an IP module might 323 be handed an (illegitimate) "datagram" of less than 20 bytes. 324 Therefore, before doing any processing of the IP header fields, the 325 following check should be performed by the IP module on the packets 326 handed by the link layer: 328 LinkLayer.PayloadSize >= 20 330 If the packet does not pass this check, it should be dropped. 332 The following subsections contain further sanity checks that should 333 be performed on IP packets. 335 3.1. Version 337 This is a 4-bit field that indicates the version of the Internet 338 Protocol (IP), and thus the syntax of the packet. For IPv4, this 339 field must be 4. 341 When a Link-Layer protocol de-multiplexes a packet to an internet 342 module, it does so based on a "Protocol Type" field in the data-link 343 packet header. 345 In theory, different versions of IP could coexist on a network by 346 using the same "Protocol Type" at the Link-layer, but a different 347 value in the Version field of the IP header. Thus, a single IP 348 module could handle all versions of the Internet Protocol, 349 differentiating them by means of this field. 351 However, in practice different versions of IP are identified by a 352 different "Protocol Type" number in the link-layer protocol header. 353 For example, IPv4 datagrams are encapsulated in Ethernet frames using 354 a "Protocol Type" field of 0x0800, while IPv6 datagrams are 355 encapsulated in Ethernet frames using a "Protocol Type" field of 356 0x86DD [IANA2006a]. 358 Therefore, if an IPv4 module receives a packet, the Version field 359 must be checked to be 4. If this check fails, the packet should be 360 silently dropped. 362 3.2. IHL (Internet Header Length) 364 The IHL (Internet Header Length) indicates the length of the internet 365 header in 32-bit words (4 bytes). As the minimum datagram size is 20 366 bytes, the minimum legal value for this field is 5. Therefore, the 367 following check should be enforced: 369 IHL >= 5 371 For obvious reasons, the Internet header cannot be larger than the 372 whole Internet datagram it is part of. Therefore, the following 373 check should be enforced: 375 IHL * 4 <= Total Length 377 The above check allows for Internet datagrams with no data bytes in 378 the payload that, while nonsensical for virtually every protocol that 379 runs over IP, it is still legal. 381 3.3. TOS 383 Figure 2 shows the syntax of the Type of Service field, defined by 384 RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. 386 0 1 2 3 4 5 6 7 387 +-----+-----+-----+-----+-----+-----+-----+-----+ 388 | PRECEDENCE | D | T | R | C | 0 | 389 +-----+-----+-----+-----+-----+-----+-----+-----+ 391 Figure 2: Type of Service field 393 +----------+----------------------------------------------+ 394 | Bits 0-2 | Precedence | 395 +----------+----------------------------------------------+ 396 | Bit 3 | 0 = Normal Delay, 1 = Low Delay | 397 +----------+----------------------------------------------+ 398 | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | 399 +----------+----------------------------------------------+ 400 | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | 401 +----------+----------------------------------------------+ 402 | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | 403 +----------+----------------------------------------------+ 404 | Bits 7 | Reserved for Future Use (must be zero) | 405 +----------+----------------------------------------------+ 407 Table 1: TOS bits 409 +-----+-----------------+ 410 | 111 | Network Control | 411 +-----+-----------------+ 412 | 110 | Internetwork | 413 +-----+-----------------+ 414 | 101 | CRITIC/ECP | 415 +-----+-----------------+ 416 | 100 | Flash Override | 417 +-----+-----------------+ 418 | 011 | Flash | 419 +-----+-----------------+ 420 | 010 | Immediate | 421 +-----+-----------------+ 422 | 001 | Priority | 423 +-----+-----------------+ 424 | 000 | Routine | 425 +-----+-----------------+ 427 Table 2: Precedence field 429 The Type of Service field can be used to affect the way in which the 430 packet is treated by the systems of a network that process it. 431 Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 432 ("Weak TOS") of this document describe the security implications of 433 the Type of Service field in the forwarding of packets. 435 3.4. Total Length 437 The Total Length field is the length of the datagram, measured in 438 bytes, including both the IP header and the IP payload. Being a 16- 439 bit field, it allows for datagrams of up to 65535 bytes. RFC 791 440 [RFC0791] states that all hosts should be prepared to receive 441 datagrams of up to 576 bytes (whether they arrive as a whole, or in 442 fragments). However, most modern implementations can reassemble 443 datagrams of at least 9 Kbytes. 445 Usually, a host will not send to a remote peer an IP datagram larger 446 than 576 bytes, unless it is explicitly signaled that the remote peer 447 is able to receive such "large" datagrams (for example, by means of 448 TCP's MSS option). However, systems should assume that they may be 449 sent datagrams larger than 576 bytes, regardless of whether they 450 signal their remote peers to do so or not. In fact, it is common for 451 NFS [RFC3530]implementations to send datagrams larger than 576 bytes, 452 even without explicit signaling that the destination system can 453 receive such "large" datagram. 455 Additionally, see the discussion in Section 4.1 "Fragment reassembly" 456 regarding the possible packet sizes resulting from fragment 457 reassembly. 459 Implementations should be aware that the IP module could be handed a 460 packet larger than the value actually contained in the Total Length 461 field. Such a difference usually has to do with legitimate padding 462 bytes at the link-layer protocol, but it could also be the result of 463 malicious activity by an attacker. Furthermore, even when the 464 maximum length of an IP datagram is 65535 bytes, if the link-layer 465 technology in use allows for payloads larger than 65535 bytes, an 466 attacker could forge such a large link-layer packet, meaning it for 467 the IP module. If the IP module of the receiving system were not 468 prepared to handle such an oversized link-layer payload, an 469 unexpected failure might occur. Therefore, the memory buffer used by 470 the IP module to store the link-layer payload should be allocated 471 according to the payload size reported by the link-layer, rather than 472 according to the Total Length field of the IP packet it contains. 474 The IP module could also be handled a packet that is smaller than the 475 actual IP packet size claimed by the Total Length field. This could 476 be used, for example, to produce an information leakage. Therefore, 477 the following check should be performed: 479 LinkLayer.PayloadSize >= Total Length 481 If this check fails, the IP packet should be dropped. As the 482 previous expression implies, the number of bytes passed by the link- 483 layer to the IP module should contain at least as many bytes as 484 claimed by the Total Length field of the IP header. 486 [US-CERT2002] is an example of the exploitation of a forged IP Total 487 Length field to produce an information leakage attack. 489 3.5. Identification (ID) 491 The Identification field is set by the sending host to aid in the 492 reassembly of fragmented datagrams. At any time, it needs to be 493 unique for each set of {Source Address, Destination Address, 494 Protocol}. 496 In many systems, the value used for this field is determined at the 497 IP layer, on a protocol-independent basis. Many of those systems 498 also simply increment the IP Identification field for each packet 499 they send. 501 This implementation strategy is inappropriate for a number of 502 reasons. First, if the Identification field is set on a protocol- 503 independent basis, it will wrap more often than necessary, and thus 504 the implementation will be more prone to the problems discussed in 505 [Kent1987] and [RFC4963]. 507 Additionally, this implementation strategy opens the door to an 508 information leakage that can be exploited to in a number of ways. 509 [Sanfilippo1998a] originally pointed out how this field could be 510 examined to determine the packet rate at which a given system is 511 transmitting information. Later, [Sanfilippo1998b] described how a 512 system with such an implementation can be used to perform a stealth 513 port scan to a third (victim) host. [Sanfilippo1999] explained how 514 to exploit this implementation strategy to uncover the rules of a 515 number of firewalls. [Bellovin2002] explains how the IP 516 Identification field can be exploited to count the number of systems 517 behind a NAT. [Fyodor2004] is an entire paper on most (if not all) 518 the ways to exploit the information provided by the Identification 519 field of the IP header. 521 3.5.1. Some workarounds implemented by the industry 523 As the IP Identification field is only used for the reassembly of 524 datagrams, some operating systems (such as Linux) decided to set this 525 field to 0 in all packets that have the DF bit set. This would, in 526 principle, avoid any type of information leakage. However, it was 527 detected that some non-RFC-compliant middle-boxes fragmented packets 528 even if they had the DF bit set. In such a scenario, all datagrams 529 originally sent with the DF bit set would all result in fragments 530 that would have an Identification field of 0, which would lead to 531 problems ("collision" of the Identification number) in the reassembly 532 process. 534 Linux (and Solaris) later set the IP Identification field on a per- 535 IP-address basis. This avoids some of the security implications of 536 the IP Identification field, but not all. For example, systems 537 behind a load balancer can still be counted. 539 3.5.2. Possible security improvements 541 Contrary to common wisdom, the IP Identification field does not need 542 to be system-wide unique for each packet, but has to be unique for 543 each {Source Address, Destination Address, Protocol} tuple. 545 For instance, the TCP specification defines a generic send() function 546 which takes the IP ID as one of its arguments. 548 We provide an analysis of the possible security improvements that 549 could be implemented, based on whether the protocol using the 550 services of IP is connection-oriented or connection-less. 552 Connection-oriented protocols 554 To avoid the security implications of the information leakage 555 described above, a pseudo-random number generator (PRNG) could be 556 used to set the IP Identification field on a {Source Address, 557 Destination Address} basis (for each connection-oriented transport 558 protocol). 560 [Klein2007] is a security advisory that describes a weakness in the 561 pseudo random number generator (PRNG) in use for the generation of 562 the IP Identification by a number of operating systems. 564 While in theory a pseudo-random number generator could lead to 565 scenarios in which a given Identification number is used more than 566 once in the same time-span for datagrams that end up getting 567 fragmented (with the corresponding potential reassembly problems), in 568 practice this is unlikely to cause trouble. 570 By default, most implementations of connection-oriented protocols, 571 such as TCP, implement some mechanism for avoiding fragmentation 572 (such as the Path-MTU Discovery mechanism described in [RFC1191]). 574 Thus, fragmentation will only take place sporadically, when a non- 575 RFC-compliant middle-box is placed somewhere along the path that the 576 packets travel to get to the destination host. Once the sending 577 system is signaled by the middle-box that it should reduce the size 578 of the packets it sends, fragmentation would be avoided. Also, for 579 reassembly problems to arise, the same Identification field should be 580 reused very frequently, and either strong packet reordering or packet 581 loss should take place. 583 Nevertheless, regardless of what policy is used for selecting the 584 Identification field, with the current link speeds fragmentation is 585 already bad enough to rely on it. A mechanism for avoiding 586 fragmentation should be implemented, instead. 588 Connectionless protocols 590 Connectionless protocols usually have these characteristics: 592 o lack of flow-control mechanisms, 594 o lack of packet sequencing mechanisms, and, 596 o lack of reliability mechanisms (such as "timeout and retransmit"). 598 This basically means that the scenarios and/or applications for which 599 connection-less transport protocols are used assume that: 601 o Applications will be used in environments in which packet 602 reordering is very unlikely (such as Local Area Networks), as the 603 transport protocol itself does not provide data sequencing. 605 o The data transfer rates will be low enough that flow control will 606 be unnecessary. 608 o Packet loss is not important and probably also unlikely. 610 With these assumptions in mind, the Identification field could still 611 be set according to a pseudo-random number generator (PRNG). In the 612 event a given Identification number was reused while the first 613 instance of the same number is still on the network, the first IP 614 datagram would be reassembled before the fragments of the second IP 615 datagram get to their destination. 617 In the event this was not the case, the reassembly of fragments would 618 result in a corrupt datagram. While some existing work 619 [Silbersack2005] assumes that this error would be caught by some 620 upper-layer error detection code, the error detection code in 621 question (such as UDP's checksum) might be intended to detect single 622 bit errors, rather than data corruption arising from the replacement 623 of a complete data block (as is the case in corruption arising from 624 collision of IP Identification numbers). 626 In the case of UDP, unfortunately some systems have been known to not 627 enable the UDP checksum by default. For most applications, packets 628 containing errors should be dropped. Probably the only application 629 that may benefit from disabling the checksum is streaming media, to 630 avoid dropping a complete sample for a single-bit error. 632 In general, if IP Identification number collisions become an issue 633 for the application using the connection-less protocol, then use of a 634 different transport protocol (which hopefully avoids fragmentation) 635 should be considered. 637 It must be noted that an attacker could intentionally exploit 638 collisions of IP Identification numbers to perform a Denial of 639 Service attack, by sending forged fragments that would cause the 640 reassembly process to result in a corrupt datagram that would either 641 be dropped by the transport protocol, or would incorrectly be handed 642 to the corresponding application. This issue is discussed in detail 643 in section 4.1 ("Fragment Reassembly"). 645 3.6. Flags 647 The IP header contains 3 control bits, two of which are currently 648 used for the fragmentation and reassembly function. 650 As described by RFC 791, their meaning is: 652 Bit 0: reserved, must be zero 654 Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment 656 Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments 658 The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) 659 mechanism described in [RFC1191]. However, it can also be exploited 660 by an attacker to evade Network Intrusion Detection Systems. An 661 attacker could send a packet with the DF bit set to a system 662 monitored by a NIDS, and depending on the Path-MTU to the intended 663 recipient, the packet might be dropped by some intervening router 664 (because of being too big to be forwarded without fragmentation), 665 without the NIDS being aware of it. 667 (still to be added) 668 (See Figure 3 in Page 13 of the CPNI document) 670 Figure 3: NIDS evasion by means of the Internet Protocol DF bit 672 In Figure 3, an attacker sends a 17914-byte datagram meant to the 673 victim host in the same figure. The attacker's packet probably 674 contains an overlapping IP fragment or an overlapping TCP segment, 675 aiming at "confusing" the NIDS, as described in [Ptacek1998]. The 676 packet is screened by the NIDS sensor at the network perimeter, which 677 probably reassembles IP fragments and TCP segments for the purpose of 678 assessing the data transferred to and from the monitored systems. 679 However, as the attacker's packet should transit a link with an MTU 680 smaller than 17914 bytes (1500 bytes in this example), the router 681 that encounters that this packet cannot be forwarded without 682 fragmentation (Router B) discards the packet, and sends an ICMP 683 "fragmentation needed and DF bit set" error message to the source 684 host. In this scenario, the NIDS may remain unaware that the 685 screened packet never reached the intended destination, and thus get 686 an incorrect picture of the data being transferred to the monitored 687 systems. 689 [Shankar2003] introduces a technique named "Active Mapping" that 690 prevents evasion of a NIDS by acquiring sufficient knowledge about 691 the network being monitored, to assess which packets will arrive at 692 the intended recipient, and how they will be interpreted by it. 694 Some firewalls are known to drop packets that have both the MF (More 695 Fragments) and the DF (Don't fragment) bits set. While in principle 696 such a packet might seem nonsensical, there are a number of reasons 697 for which non-malicious packets with these two bits set can be found 698 in a network. First, they may exist as the result of some middle-box 699 processing a packet that was too large to be forwarded without 700 fragmentation. Instead of simply dropping the corresponding packet 701 and sending an ICMP error message to the source host, some middle- 702 boxes fragment the packet (copying the DF bit to each fragment), and 703 also send an ICMP error message to the originating system. Second, 704 some systems (notably Linux) set both the MF and the DF bits to 705 implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should 706 be taken into account when configuring firewalls and/or tuning 707 Network Intrusion Detection Systems (NIDS). 709 3.7. Fragment Offset 711 The Fragment Offset is used for the fragmentation and reassembly of 712 IP datagrams. It indicates where in the original datagram the 713 fragment belongs, and is measured in units of eight bytes. As a 714 consequence, all fragments (except the last one), have to be aligned 715 on an 8-byte boundary. Therefore, if a packet has the MF flag set, 716 the following check should be enforced: 718 (Total Length - IHL * 4) % 8 == 0 720 If the packet does not pass this check, it should be dropped. 722 Given that Fragment Offset is a 13-bit field, it can hold a value of 723 up to 8191, which would correspond to an offset 65528 bytes within 724 the original (non-fragmented) datagram. As such, it is possible for 725 a fragment to implicitly claim to belong to a datagram larger than 726 65535 bytes (the maximum size for a legitimate IP datagram). Even 727 when the fragmentation mechanism would seem to allow fragments that 728 could reassemble into such large datagrams, the intent of the 729 specification is to allow for the transmission of datagrams of up to 730 65535 bytes. Therefore, if a given fragment would reassemble into a 731 datagram of more than 65535 bytes, the resulting datagram should be 732 dropped. To detect such a case, the following check should be 733 enforced on all packets for which the Fragment Offset contains a non- 734 zero value: 736 Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535 738 In the worst-case scenario, the reassembled datagram could have a 739 size of up to 131043 bytes. 741 Such a datagram would result when the first fragment has a Fragment 742 Offset of 0 and a Total Length of 65532, and the second (and last) 743 fragment has a Fragment Offset of 8189 (65512 bytes), and a Total 744 Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 745 bytes), the reassembled datagram would be 65532 + (65535 - 20) = 746 131047 bytes. 748 Additionally, the IP module should implement all the necessary 749 measures to be able to handle such illegitimate reassembled 750 datagrams, so as to avoid them from overflowing the buffer(s) used 751 for the reassembly function. 753 [CERT1996c] and [Kenney1996] describe the exploitation of this issue 754 to perform a Denial of Service (DoS) attack. 756 3.8. Time to Live (TTL) 758 The Time to Live (TTL) field has two functions: to bind the lifetime 759 of the upper-layer packets (e.g., TCP segments) and to prevent 760 packets from looping indefinitely in the network. 762 Originally, this field was meant to indicate maximum time a datagram 763 was allowed to remain in the internet system, in units of seconds. 764 As every internet module that processes a datagram must decrement the 765 TTL by at least one, the original definition of the TTL field became 766 obsolete, and it must now be interpreted as a hop count. 768 Most systems allow the administrator to configure the TTL to be used 769 for the packets sent, with the default value usually being a power of 770 2. The recommended value for the TTL field, as specified by the IANA 771 is 64 [IANA2006b]. This value reflects the assumed "diameter" of the 772 Internet, plus a margin to accommodate its growth. 774 The TTL field has a number of properties that are interesting from a 775 security point of view. Given that the default value used for the 776 TTL is usually a power of eight, chances are that, unless the 777 originating system has been explicitly tuned to use a non-default 778 value, if a packet arrives with a TTL of 60, the packet was 779 originally sent with a TTL of 64. In the same way, if a packet is 780 received with a TTL of 120, chances are that the original packet had 781 a TTL of 128. 783 This discussion assumes there was no protocol scrubber, transparent 784 proxy, or some other middle-box that overwrites the TTL field in a 785 non-standard way, between the originating system and the point of the 786 network in which the packet was received. 788 Asserting the TTL with which a packet was originally sent by the 789 source system can help to obtain valuable information. Among other 790 things, it may help in: 792 o Fingerprinting the operating system being used by the source host. 794 o Fingerprinting the physical device from which the packets 795 originate. 797 o Locating the source host in the network topology. 799 Additionally, it can be used to perform functions such as: 801 o Evading Network Intrusion Detection Systems. 803 o Improving the security of applications that make use of the 804 Internet Protocol (IP). 806 Fingerprinting the operating system in use by the source host 808 Different operating systems use a different default TTL for the 809 packets they send. Thus, asserting the TTL with which a packet was 810 originally sent will help to reduce the number of possible operating 811 systems in use by the source host. 813 Fingerprinting the physical device from which the packets originate 815 When several systems are behind a middle-box such as a NAT or a load 816 balancer, the TTL may help to count the number of systems behind the 817 middle-box. If each of the systems behind the middle-box use a 818 different default TTL for the packets they send, or they are located 819 in a different place of the network topology, an attacker could 820 stimulate responses from the devices being fingerprinted, and each 821 response that arrives with a different TTL could be assumed to come 822 from a different device. 824 Of course, there are many other and much more precise techniques to 825 fingerprint physical devices. Among drawbacks of this method, while 826 many systems differ in the default TTL they use for the packets they 827 send, there are also many implementations which use the same default 828 TTL. Additionally, packets sent by a given device may take different 829 routes (e.g., due to load sharing or route changes), and thus a given 830 packet may incorrectly be presumed to come from a different device, 831 when in fact it just traveled a different route. 833 Locating the source host in the network topology 835 The TTL field may also be used to locate the source system in the 836 network topology [Northcutt2000]. 838 +---+ +---+ +---+ +---+ +---+ 839 | A |-----| R |------| R |----| R |-----| R | 840 +---+ +---+ +---+ +---+ +---+ 841 / | / \ 842 / | / \ 843 / | / +---+ 844 / +---+ +---+ +---+ | E | 845 / | R |----| R |------| R |-- +---+ 846 / +---+ +---+\ +---+ \ 847 / / / \ \ \ 848 / ---- / +---+ \ \+---+ 849 / / / | F | \ | D | 850 +---+ +---+ +---+ \ +---| 851 | R |----------| R |-- \ 852 +---+ +---+ \ \ 853 | \ / \ +---+| +---+ 854 | \ / ----| R |------| R | 855 | \ / +---+ +---+ 856 +---+ \ +---+ +---+ 857 | B | \| R |----| C | 858 +---+ +---+ +---+ 860 Figure 4: Tracking a host by means of the TTL field 862 Consider network topology of Figure 4. Assuming that an attacker 863 ("F" in the figure) is performing some type of attack that requires 864 forging the Source Address (such as a TCP-based DoS reflection 865 attack), and some of the involved hosts are willing to cooperate to 866 locate the attacking system. 868 Assuming that: 870 o All the packets A gets have a TTL of 61. 872 o All the packets B gets have a TTL of 61. 874 o All the packets C gets have a TTL of 61. 876 o All the packets D gets have a TTL of 62. 878 Based on this information, and assuming that the system's default 879 value was not overridden, it would be fair to assume that the 880 original TTL of the packets was 64. With this information, the 881 number of hops between the attacker and each of the aforementioned 882 hosts can be calculated. 884 The attacker is: 886 o Three hops away from A. 888 o Three hops away from B. 890 o Three hops away from C. 892 o Two hops away from D. 894 In the network setup of Figure 3, the only system that satisfies all 895 these conditions is the one marked as the "F". 897 The scenario described above is for illustration purposes only. In 898 practice, there are a number of factors that may prevent this 899 technique from being successfully applied: 901 o Unless there is a "large" number of cooperating systems, and the 902 attacker is assumed to be no more than a few hops away from these 903 a systems, the number of "candidate" hosts will usually be too 904 large for the information to be useful. 906 o The attacker may be using a non-default TTL value, or, what is 907 worse, using a pseudo-random value for the TTL of the packets it 908 sends. 910 o The packets sent by the attacker may take different routes, as a 911 result of a change in network topology, load sharing, etc., and 912 thus may lead to an incorrect analysis. 914 Evading Network Intrusion Detection Systems 916 The TTL field can be used to evade Network Intrusion Detection 917 Systems. Depending on the position of a sensor relative to the 918 destination host of the examined packet, the NIDS may get a different 919 picture from that got by the intended destination system. As an 920 example, a sensor may process a packet that will expire before 921 getting to the destination host. A general counter-measure for this 922 type of attack is to normalize the traffic that gets to an 923 organizational network. Examples of such traffic normalization can 924 be found in [Paxson2001]. 926 Improving the security of applications that make use of the Internet 927 Protocol (IP) 929 In some scenarios, the TTL field can be also used to improve the 930 security of an application, by restricting the hosts that can 931 communicate with the given application. For example, there are 932 applications for which the communicating systems are typically in the 933 same network segment (i.e., there are no intervening routers). Such 934 an application is the BGP (Border Gateway Protocol) between utilized 935 by two peer routers. 937 If both systems use a TTL of 255 for all the packets they send to 938 each other, then a check could be enforced to require all packets 939 meant for the application in question to have a TTL of 255. 941 As all packets sent by systems that are not in the same network 942 segment will have a TTL smaller than 255, those packets will not pass 943 the check enforced by these two cooperating peers. This check 944 reduces the set of systems that may perform attacks against the 945 protected application (BGP in this case), thus mitigating the attack 946 vectors described in [NISCC2004] and [Watson2004]. 948 This same check is enforced for related ICMP error messages, with the 949 intent of mitigating the attack vectors described in [NISCC2005] and 950 [I-D.ietf-tcpm-icmp-attacks]. 952 The TTL field can be used in a similar way in scenarios in which the 953 cooperating systems either do not use a default TTL of 255, or are 954 not in the same network segment (i.e., multi-hop peering). In that 955 case, the following check could be enforced: 957 TTL >= 255 - DeltaHops 959 This means that the set of hosts from which packets will be accepted 960 for the protected application will be reduced to those that are no 961 more than DeltaHops away. While for obvious reasons the level of 962 protection will be smaller than in the case of directly-connected 963 peers, the use of the TTL field for protecting multi-hop peering 964 still reduces the set of hosts that could potentially perform a 965 number of attacks against the protected application. 967 This use of the TTL field has been officially documented by the IETF 968 under the name "Generalized TTL Security Mechanism" (GTSM) in 969 [RFC5082]. 971 Some protocol scrubbers enforce a minimum value for the TTL field of 972 the packets they forward. It must be understood that depending on 973 the minimum TTL being enforced, and depending on the particular 974 network setup, the protocol scrubber may actually help attackers to 975 fool the GTSM, by "raising" the TTL of the attacking packets. 977 3.9. Protocol 979 The Protocol field indicates the protocol encapsulated in the 980 internet datagram. The Protocol field may not only contain a value 981 corresponding to an implemented protocol within the system, but also 982 a value corresponding to a protocol not implemented, or even a value 983 not yet assigned by the IANA [IANA2006c]. 985 While in theory there should not be security implications from the 986 use of any value in the protocol field, there have been security 987 issues in the past with systems that had problems when handling 988 packets with some specific protocol numbers [Cisco2003] [CERT2003]. 990 3.10. Header Checksum 992 The Header Checksum field is an error detection mechanism meant to 993 detect errors in the IP header. While in principle there should not 994 be security implications arising from this field, it should be noted 995 that due to non-RFC-compliant implementations, the Header Checksum 996 might be exploited to detect firewalls and/or evade network intrusion 997 detection systems (NIDS). 999 [Ed3f2002] describes the exploitation of the TCP checksum for 1000 performing such actions. As there are internet routers known to not 1001 check the IP Header Checksum, and there might also be middle-boxes 1002 (NATs, firewalls, etc.) not checking the IP checksum allegedly due to 1003 performance reasons, similar malicious activity to the one described 1004 in [Ed3f2002] might be performed with the IP checksum. 1006 3.11. Source Address 1008 The Source Address of an IP datagram identifies the node from which 1009 the packet originated. 1011 Strictly speaking, the Source Address of an IP datagram identifies 1012 the interface of the sending system from which the packet was sent, 1013 (rather than the originating "system"), as in the Internet 1014 Architecture there's no concept of "node". 1016 Unfortunately, it is trivial to forge the Source Address of an 1017 Internet datagram. This has been exploited in the past for 1018 performing a variety of DoS (Denial of Service) attacks [NISCC2004] 1019 [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate as 1020 other systems in scenarios in which authentication was based on the 1021 Source Address of the sending system [daemon91996]. 1023 The extent to which these attacks can be successfully performed in 1024 the Internet can be reduced through deployment of ingress/egress 1025 filtering in the internet routers. [NISCC2006] is a detailed guide 1026 on ingress and egress filtering. [RFC3704] and [RFC2827] discuss 1027 ingress filtering. [GIAC2000] discusses egress filtering. 1029 Even when the obvious field on which to perform checks for ingress/ 1030 egress filtering is the Source Address and Destination Address fields 1031 of the IP header, there are other occurrences of IP addresses on 1032 which the same type of checks should be performed. One example is 1033 the IP addresses contained in the payload of ICMP error messages, as 1034 discussed in [I-D.ietf-tcpm-icmp-attacks] and [Gont2006]. 1036 There are a number of sanity checks that should be performed on the 1037 Source Address of an IP datagram. Details can be found in Section 1038 4.2 ("Addressing"). 1040 Additionally, there exist freely available tools that allow 1041 administrators to monitor which IP addresses are used with which MAC 1042 addresses [LBNL2006]. This functionality is also included in many 1043 Network Intrusion Detection Systems (NIDS). 1045 It is also very important to understand that authentication should 1046 never rely on the Source Address of the communicating systems. 1048 3.12. Destination Address 1050 The Destination Address of an IP datagram identifies the destination 1051 host to which the packet is meant to be delivered. 1053 Strictly speaking, the Destination Address of an IP datagram 1054 identifies the interface of the destination network interface, rather 1055 than the destination "system", as in the Internet Architecture 1056 there's no concept of "node". 1058 There are a number of sanity checks that should be performed on the 1059 Destination Address of an IP datagram. Details can be found in 1060 Section 4.2 ("Addressing"). 1062 3.13. Options 1064 According to RFC 791, IP options must be implemented by all IP 1065 modules, both in hosts and gateways (i.e., end-systems and 1066 intermediate-systems). 1068 There are two cases for the format of an option: 1070 o Case 1: A single byte of option-type. 1072 o Case 2: An option-type byte, an option-length byte, and the actual 1073 option-data bytes. 1075 In the Case 2, the option-length byte counts the option-type byte and 1076 the option-length byte, as well as the actual option-data bytes. 1078 All options except "End of Option List" (Type = 0) and "No Operation" 1079 (Type = 1), are of Class 2. 1081 The option-type has three fields: 1083 o 1 bit: copied flag. 1085 o 2 bits: option class. 1087 o 5 bits: option number. 1089 The copied flag indicates whether this option should be copied to all 1090 fragments in the event the packet carrying it needs to be fragmented: 1092 o 0 = not copied. 1094 o 1 = copied. 1096 The values for the option class are: 1098 o 0 = control. 1100 o 1 = reserved for future use. 1102 o 2 = debugging and measurement. 1104 o 3 = reserved for future use. 1106 This format allows for the creation of new options for the extension 1107 of the Internet Protocol (IP). 1109 Finally, the option number identifies the syntax of the rest of the 1110 option. 1112 3.13.1. General issues with IP options 1114 The following subsections discuss security issues that apply to all 1115 IP options. The proposed checks should be performed in addition to 1116 any option-specific checks proposed in the next sections. 1118 3.13.1.1. Processing requirements 1120 Router manufacturers tend to do IP option processing on the main 1121 processor, rather than on line cards. Unless special care is taken, 1122 this may be a security risk, as there is potential for overwhelming 1123 the router with option processing. 1125 To reduce the impact of these packets on the system performance, a 1126 few counter-measures could be implemented: 1128 o Rate-limit the number of packets with IP options that are 1129 processed by the system. 1131 o Enforce a limit on the maximum number of options to be accepted on 1132 a given internet datagram. 1134 The first check avoids a flow of packets with IP options to overwhelm 1135 the system in question. The second check avoids packets with 1136 multiple IP options to affect the performance of the system. 1138 3.13.1.2. Processing of the options by the upper layer protocol 1140 Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options 1141 received in IP datagrams must be passed to the transport layer (or to 1142 ICMP processing when the datagram is an ICMP message). Therefore, 1143 care in option processing must be taken not only at the internet 1144 layer, but also in every protocol module that may end up processing 1145 the options included in an IP datagram. 1147 3.13.1.3. General sanity checks on IP options 1149 There are a number of sanity checks that should be performed on IP 1150 options before further option processing is done. They help prevent 1151 a number of potential security problems, including buffer overflows. 1152 When these checks fail, the packet carrying the option should be 1153 dropped. 1155 RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" 1156 message to the originating system when a packet is dropped because of 1157 a invalid value in a field, such as the cases discussed in the 1158 following subsections. Sending such a message might help in 1159 debugging some network problems. However, it would also alert 1160 attackers about the system that is dropping packets because of the 1161 invalid values in the protocol fields. 1163 We advice that systems default to sending an ICMP "Parameter Problem" 1164 error message when a packet is dropped because of an invalid value in 1165 a protocol field (e.g., as a result of dropping a packet due to the 1166 sanity checks described in this section). However, we recommend that 1167 systems provide a system-wide toggle that allows an administrator to 1168 override the default behavior so that packets can be silently dropped 1169 due when an invalid value in a protocol field is encountered. 1171 Option length 1173 Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must 1174 not crash as the result of an option length that is outside the 1175 possible range, and mentions that erroneous option lengths have been 1176 observed to put some IP implementations into infinite loops. 1178 For options that belong to the "Case 2" described in the previous 1179 section, the following check should be performed: 1181 option-length >= 2 1183 The value "2" accounts for the option-type byte, and the option- 1184 length byte. 1186 This check prevents, among other things, loops in option processing 1187 that may arise from incorrect option lengths. 1189 Additionally, while the option-length byte of IP options of "Case 2" 1190 allows for an option length of up to 255 bytes, there is a limit on 1191 legitimate option length imposed by the syntax of the IP header. 1193 For all options of "Case 2", the following check should be enforced: 1195 option-offset + option-length <= IHL * 4 1197 Where option-offset is the offset of the first byte of the option 1198 within the IP header, with the first byte of the IP header being 1199 assigned an offset of 0. 1201 If a packet does not pass these checks, the corresponding packet 1202 should be dropped. 1204 The aforementioned check is meant to detect forged option-length 1205 values that might make an option overlap with the IP payload. This 1206 would be particularly dangerous for those IP options which request 1207 the processing systems to write information into the option-data area 1208 (such as the Record Route option), as it would allow the generation 1209 of overflows. 1211 Data types 1213 Many IP options use pointer and length fields. Care must be taken as 1214 to the data type used for these fields in the implementation. For 1215 example, if an 8-bit signed data type were used to hold an 8-bit 1216 pointer, then, pointer values larger than 128 might mistakenly be 1217 interpreted as negative numbers, and thus might lead to unpredictable 1218 results. 1220 3.13.2. Issues with specific options 1222 3.13.2.1. End of Option List (Type = 0) 1224 This option is used to indicate the "end of options" in those cases 1225 in which the end of options would not coincide with the end of the 1226 Internet Protocol Header. 1228 IP systems are required to ignore those options they do not 1229 implement. Therefore, even in those cases in which this option is 1230 required, but is missing, IP systems should be able to process the 1231 remaining bytes of the IP header without any problems. 1233 3.13.2.2. No Operation (Type = 1) 1235 The no-operation option is basically meant to allow the sending 1236 system to align subsequent options in, for example, 32-bit 1237 boundaries. 1239 This option does not have security implications. 1241 3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) 1243 This option lets the originating system specify a number of 1244 intermediate systems a packet must pass through to get to the 1245 destination host. Additionally, the route followed by the packet is 1246 recorded in the option. The receiving host (end-system) must use the 1247 reverse of the path contained in the received LSRR option. 1249 The LSSR option can be of help in debugging some network problems. 1250 Some ISP (Internet Service Provider) peering agreements require 1251 support for this option in the routers within the peer of the ISP. 1253 The LSRR option has well-known security implications. Among other 1254 things, the option can be used to: 1256 o Bypass firewall rules 1258 o Reach otherwise unreachable internet systems 1260 o Establish TCP connections in a stealthy way 1262 o Learn about the topology of a network 1264 o Perform bandwidth-exhaustion attacks 1266 Of these attack vectors, the one that has probably received least 1267 attention is the use of the LSRR option to perform bandwidth 1268 exhaustion attacks. The LSRR option can be used as an amplification 1269 method for performing bandwidth-exhaustion attacks, as an attacker 1270 could make a packet bounce multiple times between a number of systems 1271 by carefully crafting an LSRR option. 1273 This is the IPv4-version of the IPv6 amplification attack that was 1274 widely publicized in 2007 [Biondi2007]. The only difference is that 1275 the maximum length of the IPv4 header (and hence the LSRR option) 1276 limits the amplification factor when compared to the IPv6 counter- 1277 part. 1279 While the LSSR option may be of help in debugging some network 1280 problems, its security implications outweigh any legitimate use. 1282 All systems should, by default, drop IP packets that contain an LSRR 1283 option. However, they should provide a system-wide toggle to enable 1284 support for this option for those scenarios in which this option is 1285 required. Such system-wide toggle should default to "off" (or 1286 "disable"). 1288 [OpenBSD1998] is a security advisory about an improper implementation 1289 of such a system-wide in 4.4BSD kernels. 1291 Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to 1292 act as an intermediate hop in a source route, forwarding a source- 1293 routed datagram to the next specified hop. We strongly discourage 1294 host software from forwarding source-routed datagrams. 1296 If processing of source-routed datagrams is explicitly enabled in a 1297 system, the following sanity checks should be performed. 1299 RFC 791 states that this option should appear, at most, once in a 1300 given packet. Thus, if a packet is found to have more than one LSRR 1301 option, it should be dropped. Therefore, hosts and routers should 1302 discard packets that contain more than one LSRR option. 1303 Additionally, if a packet were found to have both LSRR and SSRR 1304 options, it should be dropped. 1306 As many other IP options, the LSSR contains a Length field that 1307 indicates the length of the option. Given the format of the option, 1308 the Length field should be checked to be at least 3 (three): 1310 LSRR.Length >= 3 1312 If the packet does not pass this check, it should be dropped. 1314 Additionally, the following check should be performed on the Length 1315 field: 1317 LSRR.Offset + LSRR.Length < IHL *4 1319 This check assures that the option does not overlap with the IP 1320 payload (i.e., it does not go past the IP header). If the packet 1321 does not pass this check, it should be dropped. 1323 The Pointer is relative to this option. Thus, the minimum legal 1324 value is 4. Therefore, the following check should be performed. 1326 LSRR.Pointer >= 4 1328 If the packet does not pass this check, it should be dropped. 1329 Additionally, the Pointer field should be a multiple of 4. 1330 Consequently, the following check should be performed: 1332 LSRR.Pointer % 4 == 0 1334 If a packet does not pass this check, it should be dropped. 1336 When a system receives an IP packet with the LSRR route option, it 1337 should check whether the source route is empty or not. The option is 1338 empty if: 1340 LSRR.Pointer > LSRR.Length 1342 In that case, routing should be based on the Destination Address 1343 field, and no further processing should be done on the LSRR option. 1345 [Microsoft1999] is a security advisory about a vulnerability arising 1346 from improper validation of the LSRR.Pointer field. 1348 If the address in the Destination Address field has been reached, and 1349 the option is not empty, the next address in the source route 1350 replaces the address in the Destination Address field. 1352 The IP address of the interface that will be used to forward this 1353 datagram should be recorded into the LSRR. However, before writing 1354 in the route data area, the following check should be performed: 1356 LSRR.Length - LSRR.Pointer >= 3 1358 This assures that there will be at least 4 bytes of space in which to 1359 record the IP address. If the packet does not pass this check, it 1360 should be dropped. 1362 An offset of "1" corresponds to the option type, that's why the 1363 performed check is LSRR.Length - LSRR.Pointer >=3, and not 1364 LSRR.Length - LSRR.Pointer >=4. 1366 The LSRR must be copied on fragmentation. This means that if a 1367 packet that carries the LSRR is fragmented, each of the fragments 1368 will have to go through the list of systems specified in the LSRR 1369 option. 1371 3.13.2.4. Strict Source and Record Route (SSRR) (Type = 137) 1373 This option allows the originating system to specify a number of 1374 intermediate systems a packet must pass through to get to the 1375 destination host. Additionally, the route followed by the packet is 1376 recorded in the option, and the destination host (end-system) must 1377 use the reverse of the path contained in the received SSRR option. 1379 This option is similar to the Loose Source and Record Route (LSRR) 1380 option, with the only difference that in the case of SSRR, the route 1381 specified in the option is the exact route the packet must take 1382 (i.e., no other intervening routers are allowed to be in the route). 1384 The SSSR option can be of help in debugging some network problems. 1385 Some ISP (Internet Service Provider) peering agreements require 1386 support for this option in the routers within the peer of the ISP. 1388 The SSRR option has well-known security implications. Among other 1389 things, the option can be used to: 1391 o Bypass firewall rules 1393 o Reach otherwise unreachable internet systems 1395 o Establish TCP connections in a stealthy way 1397 o Learn about the topology of a network 1399 o Perform bandwidth-exhaustion attacks 1401 Of these attack vectors, the one that has probably received least 1402 attention is the use of the SSRR option to perform bandwidth 1403 exhaustion attacks. The SSRR option can be used as an amplification 1404 method for performing bandwidth-exhaustion attacks, as an attacker 1405 could make a packet bounce multiple times between a number of systems 1406 by carefully crafting an LSRR option. 1408 This is the IPv4-version of the IPv6 amplification attack that was 1409 widely publicized in 2007 [Biondi2007]. The only difference is that 1410 the maximum length for the IPv4 header (and hence the SSRR option) 1411 limits the amplification factor when compared to the IPv6 counter- 1412 part. 1414 While the SSSR option may be of help in debugging some network 1415 problems, its security implications outweigh any legitimate use of 1416 it. 1418 All systems should, by default, drop IP packets that contain an LSRR 1419 option. However, they should provide a system-wide toggle to enable 1420 support for this option for those scenarios in which this option is 1421 required. Such system-wide toggle should default to "off" (or 1422 "disable"). 1424 [OpenBSD1998] is a security advisory about an improper implementation 1425 of such a system-wide in 4.4BSD kernels. 1427 In the event processing of the SSRR option were explicitly enabled, 1428 there are some sanity checks that should be performed. 1430 RFC 791 states that this option should appear, at most, once in a 1431 given packet. Thus, if a packet is found to have more than one SSRR 1432 option, it should be dropped. Also, if a packet contains a 1433 combination of SSRR and LSRR options, it should be dropped. 1435 As the SSRR option is meant to specify the route a packet should 1436 follow from source to destination, use of more than one SSRR option 1437 in a single packet would be nonsensical. Therefore, hosts and 1438 routers should check the IP header and discard the packet if it 1439 contains more than one SSRR option, or a combination of LSRR and SSRR 1440 options. 1442 As with many other IP options, the SSRR option contains a Length 1443 field that indicates the length of the option. Given the format of 1444 the option, the length field should be checked to be at least 3: 1446 SSRR.Length >= 3 1448 If the packet does not pass this check, it should be dropped. 1450 Additionally, the following check should be performed on the length 1451 field: 1453 SSRR.Offset + SSRR.Length < IHL *4 1455 This check assures that the option does not overlap with the IP 1456 payload (i.e., it does not go past the IP header). If the packet 1457 does not pass this check, it should be dropped. 1459 The Pointer field is relative to this option, with the minimum legal 1460 value being 4. Therefore, the following check should be performed: 1462 SSRR.Pointer >= 4 1464 If the packet does not pass this check, it should be dropped. 1466 Additionally, the Pointer field should be a multiple of 4. 1467 Consequently, the following check should be performed: 1469 SSRR.Pointer % 4 == 0 1471 If a packet does not pass this check, it should be dropped. 1473 If the packet passes the above checks, the receiving system should 1474 determine whether the Destination Address of the packet corresponds 1475 to one of its IP addresses. If does not, it should be dropped. 1477 Contrary to the IP Loose Source and Record Route (LSRR) option, the 1478 SSRR option does not allow in the route other routers than those 1479 contained in the option. If the system implements the weak end- 1480 system model, it is allowed for the system to receive a packet 1481 destined to any of its IP addresses, on any of its interfaces. If 1482 the system implements the strong end-system model, a packet destined 1483 to it can be received only on the interface that corresponds to the 1484 IP address contained in the Destination Address field [RFC1122]. 1486 If the packet passes this check, the receiving system should 1487 determine whether the source route is empty or not. The option is 1488 empty if: 1490 SSRR.Pointer > SSRR.Length 1492 In that case, if the address in the destination field has not been 1493 reached, the packet should be dropped. 1495 [Microsoft1999] is a security advisory about a vulnerability arising 1496 from improper validation of the SSRR.Pointer field. 1498 If the option is not empty, and the address in the Destination 1499 Address field has been reached, the next address in the source route 1500 replaces the address in the Destination Address field. This IP 1501 address must be reachable without the use of any intervening router 1502 (i.e., the address must belong to any of the networks to which the 1503 system is directly attached). If that is not the case, the packet 1504 should be dropped. 1506 The IP address of the interface that will be used to forward this 1507 datagram should be recorded into the SSRR. However, before doing 1508 that, the following check should be performed: 1510 SSRR.Length - SSRR.Pointer >=3 1512 An offset of "1" corresponds to the option type, that's why the 1513 performed check is SSRR.Length - SSRR.Pointer >=3, and not 1514 SSRR.Length - SSRR.Pointer >=4. 1516 This assures that there will be at least 4 bytes of space on which to 1517 record the IP address. If the packet does not pass this check, it 1518 should be dropped. 1520 The SSRR option must be copied on fragmentation. This means that if 1521 a packet that carries the SSRR is fragmented, each of the fragments 1522 will have to go through the list of systems specified in the SSRR 1523 option. 1525 3.13.2.5. Record Route (Type = 7) 1527 This option provides a means to record the route that a given packet 1528 follows. 1530 The option begins with an 8-bit option code, which must be equal to 1531 7. The second byte is the option length, which includes the option- 1532 type byte, the option-length byte, the pointer byte, and the actual 1533 option-data. The third byte is a pointer into the route data, 1534 indicating the first byte of the area in which to store the next 1535 route data. The pointer is relative to the option start. 1537 RFC 791 states that this option should appear, at most, once in a 1538 given packet. Therefore, if a packet has more than one instance of 1539 this option, it should be dropped. 1541 Given the format of the option, the Length field should be checked to 1542 be at least 3: 1544 RR.Length >= 3 1546 If the packet does not pass this check, it should be dropped. 1548 Additionally, the following check should be performed on the Length 1549 field: 1551 RR.Offset + RR_Length < IHL *4 1553 This check assures that the option does not overlap with the IP 1554 payload (i.e., it does not go past the IP header). If the packet 1555 does not pass this check, it should be dropped. 1557 The pointer field is relative to this option, with the minimum legal 1558 value being 4. Therefore, the following check should be performed: 1560 RR.Pointer >= 3 1562 If the packet does not pass this check, it should be silently 1563 dropped. 1565 Additionally, the Pointer field should be a multiple of 4. 1566 Consequently, the following check should be performed: 1568 RR.Pointer % 4 == 0 1570 When a system receives an IP packet with the Record Route option, it 1571 should check whether there is space in the option to store route 1572 information. The option is full if: 1574 RR.Pointer > RR.Length 1576 If the option is full, the datagram should be forwarded without 1577 further processing of this option. If not, the following check 1578 should be performed before writing any route data into the option: 1580 RR.Pointer - RR.Length >= 3 1582 If the packet does not pass this check, the packet should be 1583 considered in error, and therefore should be silently dropped. 1585 If the option is not full (i.e., RR.Pointer <= RR.Length), but 1586 RR.Pointer - RR.Length < 4, it means that while there's space in the 1587 option, there is not not enough space to store an IP address. It is 1588 fair to assume that such an scenario will only occur when the packet 1589 has been crafted. 1591 If the packet passes this check, the IP address of the interface that 1592 will be used to forward this datagram should be recorded into the 1593 area pointed by the RR.Pointer, and RR.Pointer should then be 1594 incremented by 4. 1596 This option is not copied on fragmentation, and thus appears in the 1597 first fragment only. If a fragment other than the one with offset 0 1598 contains the Record Route option, it should be dropped. 1600 3.13.2.6. Stream Identifier (Type = 136) 1602 The Stream Identifier option originally provided a means for the 16- 1603 bit SATNET stream Identifier to be carried through networks that did 1604 not support the stream concept. 1606 However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this 1607 option is obsolete. Therefore, it should be ignored by the 1608 processing systems. 1610 In the case of legacy systems still using this option, the length 1611 field of the option should be checked to be 4. If the option does 1612 not pass this check, it should be dropped. 1614 RFC 791 states that this option appears at most once in a given 1615 datagram. Therefore, if a packet contains more than one instance of 1616 this option, it should be dropped. 1618 3.13.2.7. Internet Timestamp (Type = 68) 1620 This option provides a means for recording the time at which each 1621 system processed this datagram. The timestamp option has a number of 1622 security implications. Among them are: 1624 o It allows an attacker to obtain the current time of the systems 1625 that process the packet, which the attacker may find useful in a 1626 number of scenarios. 1628 o It may be used to map the network topology, in a similar way to 1629 the IP Record Route option. 1631 o It may be used to fingerprint the operating system in use by a 1632 system processing the datagram. 1634 o It may be used to fingerprint physical devices, by analyzing the 1635 clock skew. 1637 Therefore, by default, the timestamp option should be ignored. 1639 For those systems that have been explicitly configured to honor this 1640 option, the rest of this subsection describes some sanity checks that 1641 should be enforced on the option before further processing. 1643 The option begins with an option-type byte, which must be equal to 1644 68. The second byte is the option-length, which includes the option- 1645 type byte, the option-length byte, the pointer, and the overflow/flag 1646 byte. The minimum legal value for the option-length byte is 4, which 1647 corresponds to an Internet Timestamp option that is empty (no space 1648 to store timestamps). Therefore, upon receipt of a packet that 1649 contains an Internet Timestamp option, the following check should be 1650 performed: 1652 IT.Length >= 4 1653 If the packet does not pass this check, it should be dropped. 1655 Additionally, the following check should be performed on the option 1656 length field: 1658 IT.Offset + IT.Length < IHL *4 1660 This check assures that the option does not overlap with the IP 1661 payload (i.e., it does not go past the IP header). If the packet 1662 does not pass this check, it should be dropped. 1664 The pointer byte points to the first byte of the area in which the 1665 next timestamp data should be stored. As its value is relative to 1666 the beginning of the option, its minimum legal value is 5. 1667 Consequently, the following check should be performed on a packet 1668 that contains the Internet Timestamp option: 1670 IT.Pointer >= 5 1672 If the packet does not pass this check, it should be dropped. 1674 The flag field has three possible legal values: 1676 o 0: Record time stamps only, stored in consecutive 32-bit words. 1678 o 1: Record each timestamp preceded with the internet address of the 1679 registering entity. 1681 o 3: The internet address fields of the option are pre-specified. 1682 An IP module only registers its timestamp if it matches its own 1683 address with the next specified internet address. 1685 Therefore the following check should be performed: 1687 IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 1689 If the packet does not pass this check, it should be dropped. 1691 The timestamp field is a right-justified 32-bit timestamp in 1692 milliseconds since UT. If the time is not available in milliseconds, 1693 or cannot be provided with respect to UT, then any time may be 1694 inserted as a timestamp, provided the high order bit of the timestamp 1695 is set, to indicate this non-standard value. 1697 According to RFC 791, the initial contents of the timestamp area must 1698 be initialized to zero, or internet address/zero pairs. However, 1699 internet systems should be able to handle non-zero values, possibly 1700 discarding the offending datagram. 1702 When an internet system receives a packet with an Internet Timestamp 1703 option, it decides whether it should record its timestamp in the 1704 option. If it determines that it should, it should then determine 1705 whether the timestamp data area is full, by means of the following 1706 check: 1708 IT.Pointer > IT.Length 1710 If this condition is true, the timestamp data area is full. If not, 1711 there is room in the timestamp data area. 1713 If the timestamp data area is full, the overflow byte should be 1714 incremented, and the packet should be forwarded without inserting the 1715 timestamp. If the overflow byte itself overflows, the packet should 1716 be dropped. 1718 If timestamp data area is not full, then further checks should be 1719 performed before actually inserting any data. 1721 If the IT.Flag byte is 0, the following check should be performed: 1723 IT.Length - IT.Pointer >= 3 1725 If the packet does not pass this check, it should be dropped. If the 1726 packet passes this check, there is room for at least one 32-bit 1727 timestamp. The system's 32-bit timestamp should be inserted at the 1728 area pointed by the pointer byte, and the pointer byte should be 1729 incremented by four. 1731 If the IT.Flag byte is 1, then the following check should be 1732 performed: 1734 IT.Length - IT.Pointer >= 7 1736 If the packet does not pass this check, it should be dropped. If the 1737 packet does pass this check, it means there is space in the timestamp 1738 data area to store at least one IP address plus the corresponding 32- 1739 bit timestamp. The IP address of the system should be stored at the 1740 area pointed to by the pointer byte, followed by the 32-bit system 1741 timestamp. The pointer byte should then be incremented by 8. 1743 If the flag byte is 3, then the following check should be performed: 1745 IT.Length - IT.Pointer >= 7 1747 If the packet does not pass this check, it should be dropped. If it 1748 does, it means there is space in the timestamp data area to store an 1749 IP address and store the corresponding 32-bit timestamp. The 1750 system's timestamp should be stored at the area pointed by IT.Pointer 1751 + 4. Then, the pointer byte should be incremented by 8. 1753 [Kohno2005] describes a technique for fingerprinting devices by 1754 measuring the clock skew. It exploits, among other things, the 1755 timestamps that can be obtained by means of the ICMP timestamp 1756 request messages [RFC0791]. However, the same fingerprinting method 1757 could be implemented with the aid of the Internet Timestamp option. 1759 3.13.2.8. Router Alert (Type = 148) 1761 The Router Alert option is defined in RFC 2113 [RFC2113]. It has the 1762 semantic "routers should examine this packet more closely". A packet 1763 that contains a Router Alert option will not go through the router's 1764 fast-path and will be processed in the router more slowly than if the 1765 option were not set. Therefore, this option may impact the 1766 performance of the systems that handle the packet carrying it. 1768 According to the syntax of the option as defined in RFC 2113, the 1769 following check should be enforced: 1771 RA.Length == 4 1773 If the packet does not pass this check, it should be dropped. 1774 Furthermore, the following check should be performed on the Value 1775 field: 1777 RA.Value == 0 1779 If the packet does not pass this check, it should be dropped. 1781 As explained in RFC 2113, hosts should ignore this option. 1783 3.13.2.9. Probe MTU (Type =11) 1785 This option is defined in RFC 1063 [RFC1063], and originally provided 1786 a mechanism to discover the Path-MTU. 1788 This option is obsolete, and therefore any packet that is received 1789 containing this option should be dropped. 1791 3.13.2.10. Reply MTU (Type = 12) 1793 This option is defined in RFC 1063 [RFC1063], and originally provided 1794 a mechanism to discover the Path-MTU. 1796 This option is obsolete, and therefore any packet that is received 1797 containing this option should be dropped. 1799 3.13.2.11. Traceroute (Type = 82) 1801 This option is defined in RFC 1393 [RFC1393], and originally provided 1802 a mechanism to trace the path to a host. 1804 This option is obsolete, and therefore any packet that is received 1805 containing this option should be dropped. 1807 3.13.2.12. DoD Basic Security Option (Type = 130) 1809 This option is used by end-systems and intermediate systems of an 1810 internet to [RFC1108]: 1812 o Transmit from source to destination in a network standard 1813 representation the common security labels required by computer 1814 security models, 1816 o Validate the datagram as appropriate for transmission from the 1817 source and delivery to the destination, and, 1819 o Ensure that the route taken by the datagram is protected to the 1820 level required by all protection authorities indicated on the 1821 datagram. 1823 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 1824 [RFC1038]). 1826 RFC 791 [RFC0791] defined the "Security Option" (Type = 130), which 1827 used the same option type as the DoD Basic Security option discussed 1828 in this section. The "Security Option" specified in RFC 791 is 1829 considered obsolete by Section 4.2.2.1 of RFC 1812, and therefore the 1830 discussion in this section is focused on the DoD Basic Security 1831 option specified by RFC 1108 [RFC1108]. 1833 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 1834 this option". 1836 The DoD Basic Security Option is currently implemented in a number of 1837 operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], 1838 and [Cisco2008]), and deployed in a number of high-security networks. 1840 RFC 1108 states that the option should appear at most once in a 1841 datagram. Therefore, if more than one DoD Basic Security option 1842 (BSO) appears in a given datagram, the corresponding datagram should 1843 be dropped. 1845 RFC 1108 states that the option Length is variable, with a minimum 1846 option Length of 3 bytes. Therefore, the following check should be 1847 performed: 1849 BSO.Length >= 3 1851 If the packet does not pass this check, it should be dropped. 1853 Systems that belong to networks in which this option is in use should 1854 process the DoD Basic Security option contained in each packet as 1855 specified in [RFC1108]. 1857 Current deployments of the DoD Security Options have motivated the 1858 proposal of a "Common Architecture Label IPv6 Security Option 1859 (CALIPSO)" for the IPv6 protocol. [RFC1038]. 1861 3.13.2.13. DoD Extended Security Option (Type = 133) 1863 This option permits additional security labeling information, beyond 1864 that present in the Basic Security Option (Section 3.13.2.12), to be 1865 supplied in an IP datagram to meet the needs of registered 1866 authorities. It is specified by RFC 1108 [RFC1108]. 1868 This option may be present only in conjunction with the DoD Basic 1869 Security option. Therefore, if a packet contains a DoD Extended 1870 Security option (ESO), but does not contain a DoD Basic Security 1871 option, it should be dropped. It should be noted that, unlike the 1872 DoD Basic Security option, this option may appear multiple times in a 1873 single IP header. 1875 RFC 1108 states that the option Length is variable, with a minimum 1876 option Length of 3 bytes. Therefore, the following check should be 1877 performed: 1879 ESO.Length >= 3 1881 If the packet does not pass this check, it should be dropped. 1883 Systems that belong to networks in which this option is in use, 1884 should process the DoD Extended Security option contained in each 1885 packet as specified in RFC 1108 [RFC1108]. 1887 3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 134) 1889 This option was proposed by the Trusted Systems Interoperability 1890 Group (TSIG), with the intent of meeting trusted networking 1891 requirements for the commercial trusted systems market place. It is 1892 specified in [CIPSO1992] and [FIPS1994]. 1894 The TSIG proposal was taken to the Commercial Internet Security 1895 Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an 1896 Internet-Draft was produced [CIPSO1992]. The Internet-Draft was 1897 never published as an RFC, and the proposal was later standardized by 1898 the U.S. National Institute of Standards and Technology (NIST) as 1899 "Federal Information Processing Standard Publication 188" [FIPS1994]. 1901 It is currently implemented in a number of operating systems (e.g., 1902 IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris 1903 [Solaris2008]), and deployed in a number of high-security networks. 1905 [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux 1906 implementation. 1908 According to the option syntax specified in [CIPSO1992] the following 1909 validation check should be performed: 1911 CIPSO.Length >= 6 1913 If a packet does not pass this check, it should be dropped. 1915 Systems that belong to networks in which this option is in use should 1916 process the CIPSO option contained in each packet as specified in 1917 [CIPSO1992]. 1919 3.13.2.15. Sender Directed Multi-Destination Delivery (Type = 149) 1921 This option is defined in RFC 1770 [RFC1770], and originally provided 1922 unreliable UDP delivery to a set of addresses included in the option. 1924 This option is obsolete. If a received packet contains this option, 1925 it should be dropped. 1927 3.14. Differentiated Services field 1929 The Differentiated Services Architecture is intended to enable 1930 scalable service discrimination in the Internet without the need for 1931 per-flow state and signaling at every hop [RFC2475]. RFC 2474 1932 [RFC2474] defines a Differentiated Services Field (DS Field), which 1933 is intended to supersede the original Type of Service field. Figure 1934 5 shows the format of the field. 1936 0 1 2 3 4 5 6 7 1937 +---+---+---+---+---+---+---+---+ 1938 | DSCP | CU | 1939 +---+---+---+---+---+---+---+---+ 1941 Figure 5: Structure of the DS Field 1943 The DSCP ("Differentiated Services CodePoint").is used to select the 1944 treatment the packet is to receive within the Differentiated Services 1945 Domain. The CU ("Currently Unused") field was, at the time the 1946 specification was issued, reserved for future use. The DSCP field is 1947 used to select a PHB, by matching against the entire 6-bit field. 1949 Considering that the DSCP field determines how a packet is treated 1950 within a DS domain, an attacker send packets with a forged DSCP field 1951 to perform a theft of service or even a Denial of Service attack. In 1952 particular, an attacker could forge packets with a codepoint of the 1953 type '11x000' which, according to Section 4.2.2.2 of RFC 2474 1954 [RFC2474], would give the packets preferential forwarding treatment 1955 when compared with the PHB selected by the codepoint '000000'. If 1956 strict priority queuing were utilized, a continuous stream of such 1957 pockets could perform a Denial of Service to other flows which have a 1958 DSCP of lower relative order. 1960 As the DS field is incompatible with the original Type of Service 1961 field, both DS domains and networks using the original Type of 1962 Service field should protect themselves by remarking the 1963 corresponding field where appropriate, probably deploying remarking 1964 boundary nodes. Nevertheless, care must be taken so that packets 1965 received with an unrecognized DSCP do not cause the handling system 1966 to malfunction. 1968 3.15. Explicit Congestion Notification (ECN) 1970 RFC 3168 [RFC3168] specifies a mechanism for routers to signal 1971 congestion to hosts sending IP packets, by marking the offending 1972 packets, rather than discarding them. RFC 3168 defines the ECN 1973 field, which utilizes the CU unused field of the DSCP field described 1974 in Section 3.14 of this document. Figure 6 shows the syntax of the 1975 ECN field, together with the DSCP field used for Differentiated 1976 Services. 1978 0 1 2 3 4 5 6 7 1979 +-----+-----+-----+-----+-----+-----+-----+-----+ 1980 | DS FIELD, DSCP | ECN FIELD | 1981 +-----+-----+-----+-----+-----+-----+-----+-----+ 1983 Figure 6: The Differentiated Services and ECN fields in IP 1985 As such, the ECN field defines four codepoints: 1987 +-----------+-----------+ 1988 | ECN field | Codepoint | 1989 +-----------+-----------+ 1990 | 00 | Not-ECT | 1991 +-----------+-----------+ 1992 | 01 | ECT(1) | 1993 +-----------+-----------+ 1994 | 10 | ECT(0) | 1995 +-----------+-----------+ 1996 | 11 | CE | 1997 +-----------+-----------+ 1999 Table 3: ECN codepoints 2001 The security implications of ECN are discussed in detail in a number 2002 of Sections of RFC 3168. Of the possible threats discussed in the 2003 ECN specification, we believe that one that can be easily exploited 2004 is that of host falsely indicating ECN-Capability. 2006 An attacker could set the ECT codepoint in the packets it sends, to 2007 signal the network that the endpoints of the transport protocol are 2008 ECN-capable. Consequently, when experiencing moderate congestion, 2009 routers using active queue management based on RED would mark the 2010 packets (with the CE codepoint) rather than discard them. In the 2011 same scenario, packets of competing flows that do not have the ECT 2012 codepoint set would be dropped. Therefore, an attacker would get 2013 better network service than the competing flows. 2015 However, if this moderate congestion turned into heavy congestion, 2016 routers should switch to drop packets, regardless of whether the 2017 packets have the ECT codepoint set or not. 2019 A number of other threats could arise if an attacker was a man in the 2020 middle (i.e., was in the middle of the path the packets travel to get 2021 to the destination host). For a detailed discussion of those cases, 2022 we urge the reader to consult Section 16 of RFC 3168. 2024 4. Internet Protocol Mechanisms 2026 4.1. Fragment reassembly 2028 To accommodate networks with different Maximum Transmission Units 2029 (MTUs), the Internet Protocol provides a mechanism for the 2030 fragmentation of IP packets by end-systems (hosts) and/or 2031 intermediate systems (routers). Reassembly of fragments is performed 2032 only by the end-systems. 2034 [Cerf1974] provides the rationale for which packet reassembly is not 2035 performed by intermediate systems. 2037 During the last few decades, IP fragmentation and reassembly has been 2038 exploited in a number of ways, to perform actions such as evading 2039 Network Intrusion Detection Systems (NIDS), bypassing firewall rules, 2040 and performing Denial of Service (DoS) attacks. 2042 [Bendi1998] and [Humble1998] are examples of the exploitation of 2043 these issues for performing Denial of Service (DoS) attacks. 2044 [CERT1997] and [CERT1998b] document these issues. [Anderson2001] is 2045 a survey of fragmentation attacks. [US-CERT2001] is an example of 2046 the exploitation of IP fragmentation to bypass firewall rules. 2047 [CERT1999] describes the implementation of fragmentation attacks in 2048 Distributed Denial of Service (DDoS) attack tools. 2050 The problem with IP fragment reassembly basically has to do with the 2051 complexity of the function, in a number of aspects: 2053 o Fragment reassembly is a stateful operation for a stateless 2054 protocol (IP). The IP module at the host performing the 2055 reassembly function must allocate memory buffers both for 2056 temporarily storing the received fragments, and to perform the 2057 reassembly function. Attackers can exploit this fact to exhaust 2058 memory buffers at the system performing the fragment reassembly. 2060 o The fragmentation and reassembly mechanisms were designed at a 2061 time in which the available bandwidths were very different from 2062 the bandwidths available nowadays. With the current available 2063 bandwidths, a number of interoperability problems may arise. And 2064 these issues may be intentionally exploited by attackers to 2065 perform Denial of Service (DoS) attacks. 2067 o Fragment reassembly must usually be performed without any 2068 knowledge of the properties of the path the fragments follow. 2069 Without this information, hosts cannot make any educated guess on 2070 how long they should wait for missing fragments to arrive. 2072 o The fragment reassembly algorithm, as described by the IETF 2073 specifications, is ambiguous, and allows for a number of 2074 interpretations, each of which has found place in different TCP/IP 2075 stack implementations. 2077 o The reassembly process is somewhat complex. Fragments may arrive 2078 out of order, duplicated, overlapping each other, etc. This 2079 complexity has lead to numerous bugs in different implementations 2080 of the IP protocol. 2082 4.1.1. Problems related with memory allocation 2084 When an IP datagram is received by an end-system, it will be 2085 temporarily stored in system memory, until the IP module processes it 2086 and hands it to the protocol machine that corresponds to the 2087 encapsulated protocol. 2089 In the case of fragmented IP packets, while the IP module may perform 2090 preliminary processing of the IP header (such as checking the header 2091 for errors and processing IP options), fragments must be kept in 2092 system buffers until all fragments are received and are reassembled 2093 into a complete internet datagram. 2095 As mentioned above, the fact that the internet layer will not usually 2096 have information about the characteristics of the path between the 2097 system and the remote host, no educated guess can be made on the 2098 amount of time that should be waited for the other fragments to 2099 arrive. Therefore, the specifications recommend to wait for a period 2100 of time that will be acceptable for virtually all the possible 2101 network scenarios in which the protocols might operate. 2102 Specifically, RFC 1122 [RFC1122] states that the reassembly timeout 2103 should be a fixed value between 60 and 120 seconds. If after waiting 2104 for that period of time the remaining fragments have not yet arrived, 2105 all the received fragments for the corresponding packet are 2106 discarded. 2108 The original IP Specification, RFC 791 [RFC0791], states that systems 2109 should wait for at least 15 seconds for the missing fragments to 2110 arrive. Systems that follow the "Example Reassembly Procedure" 2111 described in Section 3.2 of RFC 791 may end up using a reassembly 2112 timer of up to 4.25 minutes, with minimum of 15 seconds. Section 2113 3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that 2114 the reassembly timeout should be a fixed value between 60 and 120 2115 seconds. 2117 However, the longer the system waits for the missing fragments to 2118 arrive, the longer the corresponding system resources must be tied to 2119 the corresponding packet. The amount of system memory is finite, and 2120 even with today's systems, it can still be considered a scarce 2121 resource. 2123 An attacker could take advantage of the uncomfortable situation the 2124 system performing fragment reassembly is in, by sending forged 2125 fragments that will never reassemble into a complete datagram. That 2126 is, an attacker would send many different fragments, with different 2127 IP IDs, without ever sending all the necessary fragments that would 2128 be needed to reassemble them into a full IP datagram. For each of 2129 the fragments, the IP module would allocate resources and tie them to 2130 the corresponding fragment, until any the reassembly timer for the 2131 corresponding packet expires. 2133 There are some implementation strategies which could increase the 2134 impact of this attack. For example, upon receipt of a fragment, some 2135 systems allocate a memory buffer that will be large enough to 2136 reassemble the whole datagram. While this might be beneficial in 2137 legitimate cases, this just amplifies the impact of the possible 2138 attacks, as a single small fragment could tie up memory buffers for 2139 the size of an extremely large (and unlikely) datagram. The 2140 implementation strategy suggested in RFC 815 [RFC0815] leads to such 2141 an implementation. 2143 The impact of the aforementioned attack may vary depending on some 2144 specific implementation details: 2146 o If the system does not enforce limits on the amount of memory that 2147 can be allocated by the IP module, then an attacker could tie all 2148 system memory to fragments, at which point the system would become 2149 unusable, probably crashing. 2151 o If the system enforces limits on the amount of memory that can be 2152 allocated by the IP module as a whole, then, when this limit is 2153 reached, all further IP packets that arrive would be discarded, 2154 until some fragments time out and free memory is available again. 2156 o If the system enforces limits on the amount memory that can be 2157 allocated for the reassembly of fragments (in addition to 2158 enforcing a limit for the IP module as a whole), then, when this 2159 limit is reached, all further fragments that arrive would be 2160 discarded, until some fragment(s) time out and free memory is 2161 available again. 2163 4.1.2. Problems that arise from the length of the IP Identification 2164 field 2166 The Internet Protocols are currently being used in environments that 2167 are quite different from the ones in which they were conceived. For 2168 instance, the availability of bandwidth at the time the Internet 2169 Protocol was designed was completely different from the availability 2170 of bandwidth in today's networks. 2172 The Identification field is a 16-bit field that is used for the 2173 fragmentation and reassembly function. In the event a datagram gets 2174 fragmented, all the corresponding fragments will share the same 2175 Identification number. Thus, the system receiving the fragments will 2176 be able to uniquely identify them as fragments that correspond to the 2177 same IP datagram. At a given point in time, there must be at most 2178 only one packet in the network with a given Identification number. 2179 If not, an Identification number "collision" might occur, and the 2180 receiving system might end up "mixing" fragments that correspond to 2181 different IP datagrams which simply reused the same Identification 2182 number. 2184 For each group of fragments whose Identification numbers "collide", 2185 the fragment reassembly will lead to corrupted packets. The IP 2186 payload of the reassembled datagram will be handed to the 2187 corresponding upper layer protocol, where the error will (hopefully) 2188 be detected by some error detecting code (such as the TCP checksum) 2189 and the packet will be discarded. 2191 An attacker could exploit this fact to intentionally cause a system 2192 to discard all or part of the fragmented traffic it gets, thus 2193 performing a Denial of Service attack. Such an attacker would simply 2194 establish a flow of fragments with different IP Identification 2195 numbers, to trash all or part of the IP Identification space. As a 2196 result, the receiving system would use the attacker's fragments for 2197 the reassembly of legitimate datagrams, leading to corrupted packets 2198 which would later (and hopefully) get dropped. 2200 In most cases, use of a long fragment timeout will benefit the 2201 attacker, as forged fragments will keep the IP Identification space 2202 trashed for a longer period of time. 2204 4.1.3. Problems that arise from the complexity of the reassembly 2205 algorithm 2207 As IP packets can be duplicated by the network, and each packet may 2208 take a different path to get to the destination host, fragments may 2209 arrive not only out of order and/or duplicated, but also overlapping. 2210 This means that the reassembly process can be somewhat complex, with 2211 the corresponding implementation being not specifically trivial. 2213 [Shannon2001] analyzes the causes and attributes of fragment traffic 2214 measured in several types of WANs. 2216 During the years, a number of attacks have exploited bugs in the 2217 reassembly function of a number of operating systems, producing 2218 buffer overflows that have led, in most cases, to a crash of the 2219 attacked system. 2221 4.1.4. Problems that arise from the ambiguity of the reassembly process 2223 Network Intrusion Detection Systems (NIDSs) typically monitor the 2224 traffic on a given network with the intent of identifying traffic 2225 patterns that might indicate network intrusions. 2227 In the presence of IP fragments, in order to detect illegitimate 2228 activity at the transport or application layers (i.e., any protocol 2229 layer above the network layer), a NIDS must perform IP fragment 2230 reassembly. 2232 In order to correctly assess the traffic, the result of the 2233 reassembly function performed by the NIDS should be the same as that 2234 of the reassembly function performed by the intended recipient of the 2235 packets. 2237 However, a number of factors make the result of the reassembly 2238 process ambiguous: 2240 o The IETF specifications are ambiguous as to what should be done in 2241 the event overlapping fragments were received. Thus, in the 2242 presence of overlapping data, the system performing the reassembly 2243 function is free to either honor the first set of data received, 2244 the latest copy received, or any other copy received in between. 2246 o As the specifications do not enforce any specific fragment timeout 2247 value, different systems may choose different values for the 2248 fragment timeout. This means that given a set of fragments 2249 received at some specified time intervals, some systems will 2250 reassemble the fragments into a full datagram, while others may 2251 timeout the fragments and therefore drop them. 2253 o As mentioned before, as the fragment buffers get full, a Denial of 2254 Service (DoS) condition will occur unless some action is taken. 2255 Many systems flush part of the fragment buffers when some 2256 threshold is reached. Thus, depending on fragment load, timing 2257 issues, and flushing policy, a NIDS may get incorrect assumptions 2258 about how (and if) fragments are being reassembled by their 2259 intended recipient. 2261 As originally discussed by [Ptacek1998], these issues can be 2262 exploited by attackers to evade intrusion detection systems. 2264 There exist freely available tools to forcefully fragment IP 2265 datagrams so as to help evade Intrusion Detection Systems. Frag 2266 router [Song1999] is an example of such a tool; it allows an attacker 2267 to perform all the evasion techniques described in [Ptacek1998]. 2268 Ftester [Barisani2006] is a tool that helps to audit systems 2269 regarding fragmentation issues. 2271 4.1.5. Problems that arise from the size of the IP fragments 2273 One approach to fragment filtering involves keeping track of the 2274 results of applying filter rules to the first fragment (i.e., the 2275 fragment with a Fragment Offset of 0), and applying them to 2276 subsequent fragments of the same packet. The filtering module would 2277 maintain a list of packets indexed by the Source Address, Destination 2278 Address, Protocol, and Identification number. When the initial 2279 fragment is seen, if the MF bit is set, a list item would be 2280 allocated to hold the result of filter access checks. When packets 2281 with a non-zero Fragment Offset come in, look up the list element 2282 with a matching Source Address/Destination Address/Protocol/ 2283 Identification and apply the stored result (pass or block). When a 2284 fragment with a zero MF bit is seen, free the list element. 2285 Unfortunately, the rules of this type of packet filter can usually be 2286 bypassed. [RFC1858] describes the details of the involved technique. 2288 4.1.6. Possible security improvements 2290 Memory allocation for fragment reassembly 2292 A design choice usually has to be made as to how to allocate memory 2293 to reassemble the fragments of a given packet. There are basically 2294 two options: 2296 o Upon receipt of the first fragment, allocate a buffer that will be 2297 large enough to concatenate the payload of each fragment. 2299 o Upon receipt of the first fragment, create the first node of a 2300 linked list to which each of the following fragments will be 2301 linked. When all fragments have been received, copy the IP 2302 payload of each of the fragments (in the correct order) to a 2303 separate buffer that will be handed to the protocol being 2304 encapsulated in the IP payload. 2306 While the first of the choices might seem to be the most straight- 2307 forward, it implies that even when a single small fragment of a given 2308 packet is received, the amount of memory that will be allocated for 2309 that fragment will account for the size of the complete IP datagram, 2310 thus using more system resources than what is actually needed. 2312 Furthermore, the only situation in which the actual size of the whole 2313 datagram will be known is when the last fragment of the packet is 2314 received first, as that is the only packet from which the total size 2315 of the IP datagram can be asserted. Otherwise, memory should be 2316 allocated for largest possible packet size (65535 bytes). 2318 The IP module should also enforce a limit on the amount of memory 2319 that can be allocated for IP fragments, as well as a limit on the 2320 number of fragments that at any time will be allowed in the system. 2321 This will basically limit the resources spent on the reassembly 2322 process, and prevent an attacker from trashing the whole system 2323 memory. 2325 Furthermore, the IP module should keep a different buffer for IP 2326 fragments than for complete IP datagrams. This will basically 2327 separate the effects of fragment attacks on non-fragmented traffic. 2328 Most TCP/IP implementations, such as that in Linux and those in BSD- 2329 derived systems, already implement this. 2331 [Jones2002] contains an analysis about the amount of memory that may 2332 be needed for the fragment reassembly buffer depending on a number of 2333 network characteristics. 2335 Flushing the fragment buffer 2337 In the case of those attacks that aim to consume the memory buffers 2338 used for fragments, and those that aim to cause a collision of IP 2339 Identification numbers, there are a number of counter-measures that 2340 can be implemented. 2342 The IP module should enforce a limit on the amount of memory that can 2343 be allocated for IP fragments, as well as a limit on the number of 2344 fragments that at any time will be allowed in the system. This will 2345 basically limit the resources spent on the reassembly process, and 2346 prevent an attacker from trashing the whole system memory. 2348 Additionally, the IP module should keep a different buffer for IP 2349 fragments than for complete IP datagrams. This will basically 2350 separate the effects of fragment attacks on non-fragmented traffic. 2351 Most TCP/IP implementations, such as that in Linux and those in BSD- 2352 derived systems, already implement this. 2354 Even with these counter-measures in place, there is still the issue 2355 of what to do when the buffer used for IP fragments get full. 2356 Basically, if the fragment buffer is full, no instance of 2357 communication that relies on fragmentation will be able to progress. 2359 Unfortunately, there are not many options for reacting to this 2360 situation. If nothing is done, all the instances of communication 2361 that rely on fragmentation will experience a denial of service. 2362 Thus, the only thing that can be done is flush all or part of the 2363 fragment buffer, on the premise that legitimate traffic will be able 2364 to make use of the freed buffer space to allow communication flows to 2365 progress. 2367 There are a number of factors that should be taken into consideration 2368 when flushing the fragment buffer. First, if a fragment of a given 2369 packet (i.e., fragment with a given Identification number) is 2370 flushed, all the other fragments that correspond to the same datagram 2371 should be flushed. As in order for a packet to be reassembled all of 2372 its fragments must be received by the system performing the 2373 reassembly function, flushing only a subset of the fragments of a 2374 given packet would keep the corresponding buffers tied to fragments 2375 that would never reassemble into a complete datagram. Additionally, 2376 care must be taken so that, in the event that subsequent buffer 2377 flushes need to be performed, it is not always the same set of 2378 fragments that get dropped, as such a behavior would probably cause a 2379 selective Denial of Service (DoS) to the traffic flows to which that 2380 set of fragments belong. 2382 Many TCP/IP implementations define a threshold for the number of 2383 fragments that, when reached, triggers a fragment-buffer flush. Some 2384 systems flush 1/2 of the fragment buffer when the threshold is 2385 reached. As mentioned before, the idea of flushing the buffer is to 2386 create some free space in the fragment buffer, on the premise that 2387 this will allow for new and legitimate fragments to be processed by 2388 the IP module, thus letting communication survive the overwhelming 2389 situation. On the other hand, the idea of flushing a somewhat large 2390 portion of the buffer is to avoid flushing always the same set of 2391 packets. 2393 A more selective fragment buffer flushing strategy 2395 One of the difficulties in implementing counter-measures for the 2396 fragmentation attacks described in this document is that it is 2397 difficult to perform validation checks on the received fragments. 2398 For instance, the fragment on which validity checks could be 2399 performed, the first fragment, may be not the first fragment to 2400 arrive at the destination host. 2402 Fragments can not only arrive out of order because of packet 2403 reordering performed by the network, but also because the system (or 2404 systems) that fragmented the IP datagram may indeed transmit the 2405 fragments out of order. A notable example of this is the Linux 2406 TCP/IP stack, which transmits the fragments in reverse order. 2408 This means that we cannot enforce checks on the fragments for which 2409 we allocate reassembly resources, as the first fragment we receive 2410 for a given packet may be some other fragment than the first one (the 2411 one with an Fragment Offset of 0). 2413 However, at the point in which we decide to free some space in the 2414 fragment buffer, some refinements can be done to the flushing policy. 2415 The first thing we would like to do is to stop different types of 2416 traffic from interfering with each other. This means, in principle, 2417 that we do not want fragmented UDP traffic to interfere with 2418 fragmented TCP traffic. In order to implement this traffic 2419 separation for the different protocols, a different fragment buffer 2420 would be needed, in principle, for each of the 256 different 2421 protocols that can be encapsulated in an IP datagram. 2423 We believe a tradeoff is to implement two separate fragment buffers: 2424 one for IP datagrams that encapsulate IPsec packets, and another for 2425 the rest of the traffic. This basically means that traffic not 2426 protected by IPsec will not interfere with those flows of 2427 communication that are being protected by IPsec. 2429 The processing of each of these two different fragment buffers would 2430 be completely independent from each other. In the case of the IPsec 2431 fragment buffer, when the buffer needs to be flushed, the following 2432 refined policy could be applied: 2434 o First, for each packet for which the IPsec header has been 2435 received, check that the SPI field of the IPsec header corresponds 2436 to an existing IPsec Security Association (SA), and probably also 2437 check that the IPsec sequence number is valid. If the check 2438 fails, drop all the fragments that correspond to this packet. 2440 o Second, if the fragment buffer still needs to be flushed, drop all 2441 the fragments that correspond to packets for which the full IPsec 2442 header has not yet been received. The number of packets for which 2443 this flushing is performed depends on the amount of free space 2444 that needs to be created. 2446 o Third, if after flushing packets with invalid IPsec information 2447 (First step), and packets on which validation checks could not be 2448 performed (Second step), there is still not enough space in the 2449 fragment buffer, drop all the fragments that correspond to packets 2450 that passed the checks of the first step, until the necessary free 2451 space is created. 2453 The rationale behind this policy is that, at the point of flushing 2454 the fragment buffer, we prefer to keep those packets on which we 2455 could successfully perform a number of validation checks, over those 2456 packets on which those checks failed, or the checks could not even be 2457 performed. 2459 By checking both the IPsec SPI and the IPsec sequence number, it is 2460 virtually impossible for an attacker that is off-path to perform a 2461 Denial of Service attack to communication flows being protected by 2462 IPsec. 2464 Unfortunately, some TCP/IP stacks, when performing fragmentation, 2465 send the corresponding fragments in reverse order. In such cases, at 2466 the point of flushing the fragment buffer, legitimate fragments will 2467 receive the same treatment as the possible forged fragments. 2469 This refined flushing policy provides an increased level of 2470 protection against this type of resource exhaustion attack, while not 2471 making the situation of out-of-order IPsec-secured traffic worse than 2472 with the simplified flushing policy described in the previous 2473 section. 2475 Reducing the fragment timeout 2477 RFC 1122 [RFC1122] states that the reassembly timeout should be a 2478 fixed value between 60 and 120 seconds. The rationale behind these 2479 long timeout values is that they should accommodate any path 2480 characteristics, such as long-delay paths. However, it must be noted 2481 that this timer is really measuring inter-fragment delays, or, more 2482 specifically, fragment jitter. 2484 If all fragments take paths of similar characteristics, the inter- 2485 fragment delay will usually be, at most, a few seconds. 2486 Nevertheless, even if fragments take different paths of different 2487 characteristics, the recommended 60 to 120 seconds are, in practice, 2488 excessive. 2490 Some systems have already reduced the fragment timeout to 30 seconds 2491 [Linux2006]. The fragment timeout could probably be further reduced 2492 to approximately 15 seconds; although further research on this issue 2493 is necessary. 2495 It should be noted that in network scenarios of long-delay and high- 2496 bandwidth (usually referred to as "Long-Fat Networks"), using a long 2497 fragment timeout would likely increase the probability of collision 2498 of IP ID numbers. Therefore, in such scenarios it is mandatory to 2499 avoid the use of fragmentation with techniques such as PMTUD 2500 [RFC1191] or PLPMTUD [RFC4821]. 2502 Counter-measure for some IDS evasion techniques 2504 [Shankar2003] introduces a technique named "Active Mapping" that 2505 prevents evasion of a NIDS by acquiring sufficient knowledge about 2506 the network being monitored, to assess which packets will arrive at 2507 the intended recipient, and how they will be interpreted by it. 2508 [Novak2005] describes some techniques that are applied by the Snort 2509 NIDS to avoid evasion. 2511 Counter-measure for firewall-rules bypassing 2513 One of the classical techniques to bypass firewall rules involves 2514 sending packets in which the header of the encapsulated protocol is 2515 fragmented. Even when it would be legal (as far as the IETF 2516 specifications are concerned) to receive such a packets, the MTUs of 2517 the network technologies used in practice are not that small to 2518 require the header of the encapsulated protocol to be fragmented. 2519 Therefore, the system performing reassembly should drop all packets 2520 which fragment the upper-layer protocol header. The necessary 2521 information to perform this check could be stored by the IP module 2522 together with the rest of the upper-layer protocol information. 2524 Additionally, given that many middle-boxes such as firewalls create 2525 state according to the contents of the first fragment of a given 2526 packet, it is best that, in the event an end-system receives 2527 overlapping fragments, it honors the information contained in the 2528 fragment that was received first. 2530 RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass 2531 firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. 2533 4.2. Forwarding 2535 4.2.1. Precedence-ordered queue service 2537 Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should 2538 implement precedence-ordered queue service. This means that when a 2539 packet is selected for output on a (logical) link, the packet of 2540 highest precedence that has been queued for that link is sent. 2541 Section 5.3.3.2 of RFC 1812 advices routers to default to maintaining 2542 strict precedence-ordered service. 2544 Unfortunately, given that it is trivial to forge the IP precedence 2545 field of the IP header, an attacker could simply forge a high 2546 precedence number in the packets it sends, to illegitimately get 2547 better network service. If precedence-ordered queued service is not 2548 required in a particular network infrastructure, it should be 2549 disabled, and thus all packets would receive the same type of 2550 service, despite the values in their Type of Service or 2551 Differentiated Services fields. 2553 When Precedence-ordered queue service is required in the network 2554 infrastructure, in order to mitigate the attack vector discussed in 2555 the previous paragraph, edge routers or switches should be configured 2556 to police and remark the Type of Service or Differentiated Services 2557 values, according to the type of service at which each end-system has 2558 been allowed to send packets. 2560 Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT 2561 change precedence settings on packets it did not originate". 2562 However, given the security implications of the Precedence field, it 2563 is fair for routers, switches or other middle-boxes, particularly 2564 those in the network edge, to overwrite the Type of Service (or 2565 Differentiated Services) field of the packets they are forwarding, 2566 according to a configured network policy. 2568 Section 5.3.3.1 and Section 5.3.6 of RFC 1812 states that if 2569 precedence-ordered queue service is implemented and enabled, the 2570 router "MUST NOT discard a packet whose precedence is higher than 2571 that of a packet that is not discarded". While this recommendation 2572 makes sense given the semantics of the Precedence field, it is 2573 important to note that it would be simple for an attacker to send 2574 packets with forged high Precedence value to congest some internet 2575 router(s), and cause all (or most) traffic with a lower Precedence 2576 value to be discarded. 2578 4.2.2. Weak Type of Service 2580 Section 5.2.4.3 of RFC 1812 describes the algorithm for determining 2581 the next-hop address (i.e., the forwarding algorithm). Bullet 3, 2582 "Weak TOS", addresses the case in which routes contain a "type of 2583 service" attribute. It states that in case a packet contains a non- 2584 default TOS (i.e., 0000), only routes with the same TOS or with the 2585 default TOS should be considered for forwarding that packet. 2586 However, this means that among the longest match routes for a given 2587 in packet are routes with some TOS other than the one contained in 2588 the received packet, and no routes with the default TOS, the 2589 corresponding packet would be dropped. This may or may not be a 2590 desired behavior. 2592 An alternative to this would be to, in the case among the "longest 2593 match" routes there are only routes with non-default type of services 2594 which do not match the TOS contained in the received packet, to use a 2595 route with any other TOS. While this route would most likely not be 2596 able to address the type of service requested by packet, it would, at 2597 least, provide a "best effort" service. 2599 It must be noted that Section 5.3.2 of RFC 1812 allows for routers 2600 for not honoring the TOS field. Therefore, the proposed alternative 2601 behavior is still compliant with the IETF specifications. 2603 While officially specified in the RFC series, TOS-based routing is 2604 not widely deployed in the Internet. 2606 4.2.3. Address Resolution 2608 In the case of broadcast link-layer technologies, in order for a 2609 system to transfer an IP datagram it must usually first map an IP 2610 address to the corresponding link-layer address (for example, by 2611 means of the ARP protocol [RFC0826]) . This means that while this 2612 operation is being performed, the packets that would require such a 2613 mapping would need to be kept in memory. This may happen both in the 2614 case of hosts and in the case of routers. 2616 This situation might be exploited by an attacker, which could send a 2617 large amount of packets to a non-existent host which would supposedly 2618 be directly connected to the attacked router. While trying to map 2619 the corresponding IP address into a link-layer address, the attacked 2620 router would keep in memory all the packets that would need to make 2621 use of that link-layer address. At the point in which the mapping 2622 function times out, depending on the policy implemented by the 2623 attacked router, only the packet that triggered the call to the 2624 mapping function might be dropped. In that case, the same operation 2625 would be repeated for every packet destined to the non-existent host. 2626 Depending on the timeout value for the mapping function, this 2627 situation might lead to the router buffers to run out of free space, 2628 with the consequence that incoming legitimate packets would have to 2629 be dropped, or that legitimate packets already stored in the router's 2630 buffers might get dropped. Both of these situations would lead 2631 either to a complete Denial of Service, or to a degradation of the 2632 network service. 2634 One counter-measure to this problem would be to drop, at the point 2635 the mapping function times out all the packets destined to the 2636 address that timed out. In addition, a "negative cache entry" might 2637 be kept in the module performing the matching function, so that for 2638 some amount of time, the mapping function would return an error when 2639 the IP module requests to perform a mapping for some address for 2640 which the mapping has recently timed out. 2642 A common implementation strategy for routers is that when a packet is 2643 received that requires an ARP request to be performed before the 2644 packet can be forwarded, the packet is dropped and the router is then 2645 engaged in the ARP procedure. 2647 4.2.4. Dropping packets 2649 In some scenarios, it may be necessary for a host or router to drop 2650 packets from the output queue. In the event one of such packets 2651 happens to be an IP fragment, and there were other fragments of the 2652 same packet in the queue, those other fragments should also be 2653 dropped. The rationale for this policy is that it is nonsensical to 2654 spend system resources on those other fragments, because, as long as 2655 one fragment is missing, it will be impossible for the receiving 2656 system to reassemble them into a complete IP datagram. 2658 Some systems have been known to drop just a subset of fragments of a 2659 given datagram, leading to a denial of service condition, as only a 2660 subset of all the fragments of the packets were actually transferred 2661 to the next hop. 2663 4.3. Addressing 2665 4.3.1. Unreachable addresses 2667 It is important to understand that while there are some addresses 2668 that are supposed to be unreachable from the public Internet (such as 2669 those described in RFC 1918 [RFC1918], or the "loopback" address), 2670 there are a number of tricks an attacker can perform to reach those 2671 IP addresses that would otherwise be unreachable (e.g., exploit the 2672 LSRR or SSRR IP options). Therefore, when applicable, packet 2673 filtering should be performed at organizational network boundary to 2674 assure that those addresses will be unreachable. 2676 4.3.2. Private address space 2678 The Internet Assigned Numbers Authority (IANA) has reserved the 2679 following three blocks of the IP address space for private internets: 2681 o 10.0.0.0 - 10.255.255.255 (10/8 prefix) 2683 o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 2685 o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 2687 Use of these address blocks is described in RFC 1918 [RFC1918]. 2689 Where applicable, packet filtering should be performed at the 2690 organizational perimeter to assure that these addresses are not 2691 reachable from outside the enterprise network. 2693 4.3.3. Class D addresses (224/4 address block) 2695 The Class D addresses correspond to the 224/4 address block, and are 2696 used for Internet multicast. Therefore, if a packet is received with 2697 a Class D address as the Source Address, it should be dropped. 2698 Additionally, if an IP packet with a multicast Destination Address is 2699 received for a connection-oriented protocol (e.g., TCP), the packet 2700 should be dropped. 2702 4.3.4. Class E addresses (240/4 address block) 2704 The Class E addresses correspond to the 240/4 address block, and are 2705 currently reserved for experimental use. As a result, a number of 2706 implementations discard packets that contain a Class E address as the 2707 Source Address or Destination Address. 2709 However, there exists ongoing work to reclassify the Class E (240/4) 2710 address block as usable unicast address spaces [Fuller2008a] 2711 [I-D.fuller-240space] [I-D.wilson-class-e]. Therefore, we recommend 2712 implementations to accept addresses in the 240/4 block as valid 2713 addresses for the Source Address and Destination Address. 2715 It should be noted that the broadcast address 255.255.255.255 still 2716 must be treated as indicated in Section 4.3.7 of this document. 2718 4.3.5. Broadcast and multicast addresses, and connection-oriented 2719 protocols 2721 For connection-oriented protocols, such as TCP, shared state is 2722 maintained between only two endpoints at a time. Therefore, if an IP 2723 packet with a multicast (or broadcast) Destination Address is 2724 received for a connection-oriented protocol (e.g., TCP), the packet 2725 should be dropped. 2727 4.3.6. Broadcast and network addresses 2729 Originally, the IETF specifications did not permit IP addresses to 2730 have the value 0 or -1 for any of the Host number, network number, or 2731 subnet number fields, except for the cases indicated in Section 2732 4.3.7. However, this changed fundamentally with the deployment of 2733 Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a 2734 system cannot know a priori what the subnet mask is for a particular 2735 IP address. 2737 Many systems now allow administrators to use the values 0 or -1 for 2738 those fields. Despite that according to the IETF specifications 2739 these addresses are illegal, modern IP implementations should 2740 consider these addresses to be valid. 2742 4.3.7. Special Internet addresses 2744 RFC 1812 [RFC1812] discusses the use of some special internet 2745 addresses, which is of interest to perform some sanity checks on the 2746 Source Address and Destination Address fields of an IP packet. It 2747 uses the following notation for an IP address: 2749 { , } 2751 RFC 1122 [RFC1122] contained a similar discussion of special internet 2752 addresses, including some of the form { , , }. However, as explained in Section 4.2.2.11 2754 of RFC 1812, in a CIDR world, the subnet number is clearly an 2755 extension of the network prefix and cannot be interpreted without the 2756 remainder of the prefix. 2758 {0, 0} 2760 This address means "this host on this network". It is meant to be 2761 used only during the initialization procedure, by which the host 2762 learns its own IP address. 2764 If a packet is received with 0.0.0.0 as the Source Address for any 2765 purpose other than bootstrapping, the corresponding packet should be 2766 silently dropped. If a packet is received with 0.0.0.0 as the 2767 Destination Address, it should be silently dropped. 2769 {0, Host number} 2771 This address means "the specified host, in this network". As in the 2772 previous case, it is meant to be used only during the initialization 2773 procedure by which the host learns its own IP address. If a packet 2774 is received with such an address as the Source Address for any 2775 purpose other than bootstrapping, it should be dropped. If a packet 2776 is received with such an address as the Destination Address, it 2777 should be dropped. 2779 {-1, -1} 2781 This address is the local broadcast address. It should not be used 2782 as a source IP address. If a packet is received with 255.255.255.255 2783 as the Source Address, it should be dropped. 2785 Some systems, when receiving an ICMP echo request, for example, will 2786 use the Destination Address in the ICMP echo request packet as the 2787 Source Address of the response they send (in this case, an ICMP echo 2788 reply). Thus, when such systems receive a request sent to a 2789 broadcast address, the Source Address of the response will contain a 2790 broadcast address. This should be considered a bug, rather than a 2791 malicious use of the limited broadcast address. 2793 {Network number, -1} 2795 This is the directed broadcast to the specified network. As 2796 recommended by RFC 2644 [RFC2644], routers should not forward 2797 network-directed broadcasts. This avoids the corresponding network 2798 from being utilized as, for example, a "smurf amplifier" [CERT1998a]. 2800 As noted in Section 4.3.6 of this document, many systems now allow 2801 administrators to configure these addresses as unicast addresses for 2802 network interfaces. In such scenarios, routers should forward these 2803 addresses as if they were traditional unicast addresses. 2805 In some scenarios a host may have knowledge about a particular IP 2806 address being a network-directed broadcast address, rather than a 2807 unicast address (e.g., that IP address is configured on the local 2808 system as a "broadcast address"). In such scenarios, if a system can 2809 infer the Source Address of a received packet is a network-directed 2810 broadcast address, the packet should be dropped. 2812 As noted in Section 4.3.6 of this document, with the deployment of 2813 CIDR [RFC4632], it may be difficult for a system to infer whether a 2814 particular IP address is a broadcast address. 2816 {127, any} 2818 This is the internal host loopback address. Any packet that arrives 2819 on any physical interface containing this address as the Source 2820 Address, the Destination Address, or as part of a source route 2821 (either LSRR or SSRR), should be dropped. 2823 For example, packets with a Destination Address in the 127.0.0.0/8 2824 address block that are received on an interface other than loopback 2825 should be silently dropped. Packets received on any interface other 2826 than loopback with a Source Address corresponding to the system 2827 receiving the packet should also be dropped. 2829 5. Security Considerations 2831 This document discusses the security implications of the Internet 2832 Protocol (IP), and discusses a number of implementation strategies 2833 that help to mitigate a number of vulnerabilities found in the 2834 protocol during the last 25 years or so. 2836 6. Acknowledgements 2838 This document was written by Fernando Gont on behalf of the UK CPNI 2839 (United Kingdom's Centre for the Protection of National 2840 Infrastructure). It is heavily based on the "Security Assessment of 2841 the Internet Protocol" [CPNI2008] released by the UK Centre for the 2842 Protection of National Infrastructure (CPNI), available at: 2843 http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx . 2845 The author would like to thank Randall Atkinson, John Day, Juan 2846 Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka 2847 Savola, and Christos Zoulas for providing valuable comments on 2848 earlier versions of [CPNI2008], on which this document is based. 2850 The author would like to thank Randall Atkinson and Roque Gagliano, 2851 who generously answered a number of questions. 2853 Finally, the author would like to thank UK CPNI (formerly NISCC) for 2854 their continued support. 2856 7. References 2858 7.1. Normative References 2860 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2861 September 1981. 2863 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2864 converting network protocol addresses to 48.bit Ethernet 2865 address for transmission on Ethernet hardware", STD 37, 2866 RFC 826, November 1982. 2868 [RFC1038] St. Johns, M., "Draft revised IP security option", 2869 RFC 1038, January 1988. 2871 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 2872 MTU discovery options", RFC 1063, July 1988. 2874 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 2876 [RFC1122] Braden, R., "Requirements for Internet Hosts - 2877 Communication Layers", STD 3, RFC 1122, October 1989. 2879 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2880 November 1990. 2882 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 2883 Suite", RFC 1349, July 1992. 2885 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 2886 January 1993. 2888 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 2889 Destination Delivery", RFC 1770, March 1995. 2891 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 2892 RFC 1812, June 1995. 2894 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 2895 February 1997. 2897 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2898 "Definition of the Differentiated Services Field (DS 2899 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2900 December 1998. 2902 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2903 and W. Weiss, "An Architecture for Differentiated 2904 Services", RFC 2475, December 1998. 2906 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 2907 in Routers", BCP 34, RFC 2644, August 1999. 2909 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2910 Discovery", RFC 4821, March 2007. 2912 7.2. Informative References 2914 [Anderson2001] 2915 Anderson, J., "An Analysis of Fragmentation Attacks", 2916 Available at: http://www.ouah.org/fragma.html , 2001. 2918 [Barisani2006] 2919 Barisani, A., "FTester - Firewall and IDS testing tool", 2920 Available at: http://dev.inversepath.com/trac/ftester , 2921 2001. 2923 [Bellovin1989] 2924 Bellovin, S., "Security Problems in the TCP/IP Protocol 2925 Suite", Computer Communication Review Vol. 19, No. 2, pp. 2926 32-48, 1989. 2928 [Bellovin2002] 2929 Bellovin, S., "A Technique for Counting NATted Hosts", 2930 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 2932 [Bendi1998] 2933 Bendi, "Boink exploit", http://www.insecure.org/sploits/ 2934 95.NT.fragmentation.bonk.html , 1998. 2936 [Biondi2007] 2937 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 2938 CanSecWest 2007 Security Conference http://www.secdev.org/ 2939 conf/IPv6_RH_security-csw07.pdf, 2007. 2941 [CERT1996a] 2942 CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- 2943 Service Attack", 2944 http://www.cert.org/advisories/CA-1996-01.html, 1996. 2946 [CERT1996b] 2947 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 2948 Spoofing Attacks", 2949 http://www.cert.org/advisories/CA-1996-21.html, 1996. 2951 [CERT1996c] 2952 CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack 2953 via ping", 2954 http://www.cert.org/advisories/CA-1996-26.html, 1996. 2956 [CERT1997] 2957 CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service 2958 Attacks", http://www.cert.org/advisories/CA-1997-28.html, 2959 1997. 2961 [CERT1998a] 2962 CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- 2963 Service Attacks", 2964 http://www.cert.org/advisories/CA-1998-01.html, 1998. 2966 [CERT1998b] 2967 CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain 2968 TCP/IP Implementations", 2969 http://www.cert.org/advisories/CA-1998-13.html, 1998. 2971 [CERT1999] 2972 CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 2973 http://www.cert.org/advisories/CA-1999-17.html, 1999. 2975 [CERT2001] 2976 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 2977 TCP/IP Initial Sequence Numbers", 2978 http://www.cert.org/advisories/CA-2001-09.html, 2001. 2980 [CERT2003] 2981 CERT, "CERT Advisory CA-2003-15 Cisco IOS Interface 2982 Blocked by IPv4 Packet", 2983 http://www.cert.org/advisories/CA-2003-15.html, 2003. 2985 [CIPSO1992] 2986 CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF 2987 Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work 2988 in progress , 1992. 2990 [CIPSOWG1994] 2991 CIPSOWG, "Commercial Internet Protocol Security Option 2992 (CIPSO) Working Group", http://www.ietf.org/proceedings/ 2993 94jul/charters/cipso-charter.html, 1994. 2995 [CPNI2008] 2996 Gont, F., "Security Assessment of the Internet Protocol", 2997 http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. 2999 [Cerf1974] 3000 Cerf, V. and R. Kahn, "A Protocol for Packet Network 3001 Intercommunication", IEEE Transactions on 3002 Communications Vol. 22, No. 5, May 1974, pp. 637-648, 3003 1974. 3005 [Cisco2003] 3006 Cisco, "Cisco Security Advisory: Cisco IOS Interface 3007 Blocked by IPv4 packet", http://www.cisco.com/en/US/ 3008 products/products_security_advisory09186a00801a34c2.shtml, 3009 2003. 3011 [Cisco2008] 3012 Cisco, "Cisco IOS Security Configuration Guide, Release 3013 12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/ 3014 configuration/guide/scfipso.html, 2003. 3016 [Clark1988] 3017 Clark, D., "The Design Philosophy of the DARPA Internet 3018 Protocols", Computer Communication Review Vol. 18, No. 4, 3019 1988. 3021 [Ed3f2002] 3022 Ed3f, "Firewall spotting and networks analisys with a 3023 broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, 3024 Phile #0x0c of 3025 0x10 http://www.phrack.org/phrack/60/p60-0x0c.txt, 2002. 3027 [FIPS1994] 3028 FIPS, "Standard Security Label for Information Transfer", 3029 Federal Information Processing Standards Publication. FIP 3030 PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ 3031 fips188.pdf, 1994. 3033 [Fuller2008a] 3034 Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The 3035 Future Begins Now", Routing SIG Meeting, 25th APNIC Open 3036 Policy Meeting, February 25 - 29 2008, Taipei, Taiwan http 3037 ://www.apnic.net/meetings/25/program/routing/ 3038 fuller-240-future.pdf, 2008. 3040 [Fyodor2004] 3041 Fyodor, "Idle scanning and related IP ID games", 3042 http://www.insecure.org/nmap/idlescan.html, 2004. 3044 [GIAC2000] 3045 GIAC, "Egress Filtering v 0.2", 3046 http://www.sans.org/y2k/egress.htm, 2000. 3048 [Gont2006] 3049 Gont, F., "Advanced ICMP packet filtering", 3050 http://www.gont.com.ar/papers/icmp-filtering.html, 2006. 3052 [Haddad2004] 3053 Haddad, I. and M. Zakrzewski, "Security Distribution for 3054 Linux Clusters", Linux 3055 Journal http://www.linuxjournal.com/article/6943, 2004. 3057 [Humble1998] 3058 Gont, F., "Nestea exploit", 3059 http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 3060 1998. 3062 [I-D.fuller-240space] 3063 Fuller, V., "Reclassifying 240/4 as usable unicast address 3064 space", draft-fuller-240space-02 (work in progress), 3065 March 2008. 3067 [I-D.ietf-tcpm-icmp-attacks] 3068 Gont, F., "ICMP attacks against TCP", 3069 draft-ietf-tcpm-icmp-attacks-04 (work in progress), 3070 October 2008. 3072 [I-D.stjohns-sipso] 3073 StJohns, M., "Common Architecture Label IPv6 Security 3074 Option (CALIPSO)", draft-stjohns-sipso-06 (work in 3075 progress), December 2008. 3077 [I-D.templin-mtuassurance] 3078 Templin, F., "Requirements for IP-in-IP Tunnel MTU 3079 Assurance", draft-templin-mtuassurance-02 (work in 3080 progress), October 2006. 3082 [I-D.wilson-class-e] 3083 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 3084 of 240/4 from "Future Use" to "Private Use"", 3085 draft-wilson-class-e-02 (work in progress), 3086 September 2008. 3088 [IANA2006a] 3089 Ether Types, 3090 "http://www.iana.org/assignments/ethernet-numbers". 3092 [IANA2006b] 3093 IP Parameters, 3094 "http://www.iana.org/assignments/ip-parameters". 3096 [IANA2006c] 3097 Protocol Numbers, 3098 "http://www.iana.org/assignments/protocol-numbers". 3100 [IRIX2008] 3101 IRIX, "IRIX 6.5 trusted_networking(7) manual page", http: 3102 //techpubs.sgi.com/library/tpl/cgi-bin/ 3103 getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ 3104 cat7/trusted_networking.z, 2008. 3106 [Jones2002] 3107 Jones, R., "A Method Of Selecting Values For the 3108 Parameters Controlling IP Fragment Reassembly", ftp:// 3109 ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt, 3110 2002. 3112 [Kenney1996] 3113 Kenney, M., "The Ping of Death Page", 3114 http://www.insecure.org/sploits/ping-o-death.html, 1996. 3116 [Kent1987] 3117 Kent, C. and J. Mogul, "Fragmentation considered harmful", 3118 Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987. 3120 [Klein2007] 3121 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 3122 Predictable IP ID Vulnerability", http:// 3123 www.trusteer.com/files/ 3124 OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP 3125 _ID_Vulnerability.pdf, 2007. 3127 [Kohno2005] 3128 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 3129 Device Fingerprinting", IEEE Transactions on Dependable 3130 and Secure Computing Vol. 2, No. 2, 2005. 3132 [LBNL2006] 3133 LBNL/NRG, "arpwatch tool", http://ee.lbl.gov/, 2006. 3135 [Linux2006] 3136 The Linux Project, "http://www.kernel.org". 3138 [Microsoft1999] 3139 Microsoft, "Microsoft Security Program: Microsoft Security 3140 Bulletin (MS99-038). Patch Available for "Spoofed Route 3141 Pointer" Vulnerability", http://www.microsoft.com/ 3142 technet/security/bulletin/ms99-038.mspx, 1999. 3144 [NISCC2004] 3145 NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability 3146 Issues in TCP", 3147 http://www.uniras.gov.uk/niscc/docs/ 3148 re-20040420-00391.pdf, 2004. 3150 [NISCC2005] 3151 NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 3152 Vulnerability Issues in ICMP packets with TCP payloads", 3153 http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf, 3154 2005. 3156 [NISCC2006] 3157 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 3158 Filtering", http://www.niscc.gov.uk/niscc/docs/ 3159 re-20060420-00294.pdf?lang=en, 2006. 3161 [Northcutt2000] 3162 Northcut, S. and Novak, "Network Intrusion Detection - An 3163 Analyst's Handbook", Second Edition New Riders Publishing, 3164 2000. 3166 [Novak2005] 3167 Novak, "Target-Based Fragmentation Reassembly", 3168 http://www.snort.org/reg/docs/target_based_frag.pdf, 3169 2005. 3171 [OpenBSD1998] 3172 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 3173 Problem", 3174 http://www.openbsd.org/advisories/sourceroute.txt, 1998. 3176 [Paxson2001] 3177 Paxson, V., Handley, M., and C. Kreibich, "Network 3178 Intrusion Detection: Evasion, Traffic Normalization, and 3179 End-to-End Protocol Semantics", USENIX Conference, 2001, 3180 2001. 3182 [Ptacek1998] 3183 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 3184 of Service: Eluding Network Intrusion Detection", 3185 http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps, 3186 1998. 3188 [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, 3189 July 1982. 3191 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 3192 Considerations for IP Fragment Filtering", RFC 1858, 3193 October 1995. 3195 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3196 E. Lear, "Address Allocation for Private Internets", 3197 BCP 5, RFC 1918, February 1996. 3199 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3200 Defeating Denial of Service Attacks which employ IP Source 3201 Address Spoofing", BCP 38, RFC 2827, May 2000. 3203 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 3204 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 3206 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3207 of Explicit Congestion Notification (ECN) to IP", 3208 RFC 3168, September 2001. 3210 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 3211 Beame, C., Eisler, M., and D. Noveck, "Network File System 3212 (NFS) version 4 Protocol", RFC 3530, April 2003. 3214 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3215 Networks", BCP 84, RFC 3704, March 2004. 3217 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 3218 Network Tunneling", RFC 4459, April 2006. 3220 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3221 (CIDR): The Internet Address Assignment and Aggregation 3222 Plan", BCP 122, RFC 4632, August 2006. 3224 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3225 Errors at High Data Rates", RFC 4963, July 2007. 3227 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3228 Mitigations", RFC 4987, August 2007. 3230 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 3231 Pignataro, "The Generalized TTL Security Mechanism 3232 (GTSM)", RFC 5082, October 2007. 3234 [SELinux2008] 3235 Security Enhanced Linux, "http://www.nsa.gov/selinux/". 3237 [Sanfilippo1998a] 3238 Sanfilippo, S., "about the ip header id", Post to Bugtraq 3239 mailing-list, Mon Dec 14 3240 1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998. 3242 [Sanfilippo1998b] 3243 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing- 3244 list http://www.kyuzz.org/antirez/papers/dumbscan.html, 3245 1998. 3247 [Sanfilippo1999] 3248 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 3249 list http://www.kyuzz.org/antirez/papers/moreipid.html, 3250 1999. 3252 [Shankar2003] 3253 Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS 3254 EvasionWithout Altering Traffic", 3255 http://www.icir.org/vern/papers/activemap-oak03.pdf, 3256 2003. 3258 [Shannon2001] 3259 Shannon, C., Moore, D., and K. Claffy, "Characteristics of 3260 Fragmented IP Traffic on Internet Links", 2001. 3262 [Silbersack2005] 3263 Silbersack, M., "Improving TCP/IP security through 3264 randomization without sacrificing interoperability", 3265 EuroBSDCon 2005 Conference http://www.silby.com/ 3266 eurobsdcon05/eurobsdcon_slides.pdf, 2005. 3268 [Solaris2008] 3269 Solaris Trusted Extensions - Labeled Security for Absolute 3270 Protection, "http://www.sun.com/software/solaris/ds/ 3271 trusted_extensions.jsp#3", 2008. 3273 [Song1999] 3274 Song, D., "Frag router tool", 3275 http://www.anzen.com/research/nidsbench/. 3277 [US-CERT2001] 3278 US-CERT, "US-CERT Vulnerability Note VU#446689: Check 3279 Point FireWall-1 allows fragmented packets through 3280 firewall if Fast Mode is enabled", 3281 http://www.kb.cert.org/vuls/id/446689, 2001. 3283 [US-CERT2002] 3284 US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS 3285 discloses fragments of previous packets when Express 3286 Forwarding is enabled", 3287 http://www.kb.cert.org/vuls/id/310387, 2002. 3289 [Watson2004] 3290 Watson, P., "Slipping in the Window: TCP Reset Attacks", 3291 2004 CanSecWest Conference , 2004. 3293 [Zakrzewski2002] 3294 Zakrzewski, M. and I. Haddad, "Linux Distributed Security 3295 Module", http://www.linuxjournal.com/article/6215, 2002. 3297 [daemon91996] 3298 daemon9, route, and infinity, "IP-spoofing Demystified 3299 (Trust-Relationship Exploitation)", Phrack Magazine, 3300 Volume Seven, Issue Forty-Eight, File 14 of 3301 18 http://www.phrack.org/phrack/48/P48-14 , 1988. 3303 Appendix A. Advice and guidance to vendors 3305 Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they 3306 think they may be affected by the issues described in this document. 3307 As the lead coordination center for these issues, CPNI is well placed 3308 to give advice and guidance as required. 3310 CPNI works extensively with government departments and agencies, 3311 commercial organizations and the academic community to research 3312 vulnerabilities and potential threats to IT systems especially where 3313 they may have an impact on Critical National Infrastructure's (CNI). 3315 Other ways to contact CPNI, plus CPNI's PGP public key, are available 3316 at http://www.cpni.gov.uk . 3318 Appendix B. Changes from previous versions of the draft (to be removed 3319 by the RFC Editor before publishing this document as an 3320 RFC) 3322 B.1. Changes from draft-gont-opsec-ip-security-01 3324 o Draft resubmitted as draft-ietf, as a result of wg consensus on 3325 adopting the document as an opsec wg item. 3327 B.2. Changes from draft-gont-opsec-ip-security-00 3329 o Fixed author's affiliation. 3331 o Added Figure 4. 3333 o Fixed a few typos. 3335 o (no technical changes) 3337 Author's Address 3339 Fernando Gont 3340 UK Centre for the Protection of National Infrastructure 3342 Email: fernando@gont.com.ar 3343 URI: http://www.cpni.gov.uk