idnits 2.17.1 draft-gont-opsec-ip-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.2b on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3335. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2008) is 5722 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CERT2001' is defined on line 2943, but no explicit reference was found in the text == Unused Reference: 'I-D.stjohns-sipso' is defined on line 3040, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-mtuassurance' is defined on line 3045, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 3177, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 3184, 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-03 == Outdated reference: A later version (-11) exists of draft-stjohns-sipso-04 == Outdated reference: A later version (-02) exists of draft-wilson-class-e-01 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 10 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 Consultant 4 (opsec) August 25, 2008 5 Internet-Draft 6 Intended status: Informational 7 Expires: February 26, 2009 9 Security Assessment of the Internet Protocol version 4 10 draft-gont-opsec-ip-security-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 This document may not be modified, and derivative works of it may not 19 be created. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 26, 2009. 39 Abstract 41 This document contains a security assessment of the IETF 42 specifications of the Internet Protocol version 4, and of a number of 43 mechanisms and policies in use by popular IPv4 implementations. It 44 is based on the results of a project carried out by the UK's Centre 45 for the Protection of National Infrastructure (CPNI). 47 Table of Contents 49 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 52 1.3. Organization of this document . . . . . . . . . . . . . . 6 53 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6 54 3. Internet Protocol header fields . . . . . . . . . . . . . . . 7 55 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8 57 3.3. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 11 60 3.5.1. Some workarounds implemented by the industry . . . . . 11 61 3.5.2. Possible security improvements . . . . . . . . . . . . 12 62 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 15 64 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 16 65 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 66 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 21 67 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 21 68 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 22 69 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 3.13.1. General issues with IP options . . . . . . . . . . . . 23 71 3.13.1.1. Processing requirements . . . . . . . . . . . . . 24 72 3.13.1.2. Processing of the options by the upper layer 73 protocol . . . . . . . . . . . . . . . . . . . . 24 74 3.13.1.3. General sanity checks on IP options . . . . . . . 24 75 3.13.2. Issues with specific options . . . . . . . . . . . . . 26 76 3.13.2.1. End of Option List (Type = 0) . . . . . . . . . . 26 77 3.13.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 26 78 3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 26 79 3.13.2.4. Strict Source and Record Route (SSRR) (Type = 80 137) . . . . . . . . . . . . . . . . . . . . . . 29 81 3.13.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 32 82 3.13.2.6. Stream Identifier (Type = 136) . . . . . . . . . 34 83 3.13.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 34 84 3.13.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 37 85 3.13.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 37 86 3.13.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 38 87 3.13.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 38 88 3.13.2.12. DoD Basic Security Option (Type = 130) . . . . . 38 89 3.13.2.13. DoD Extended Security Option (Type = 133) . . . . 39 90 3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 91 134) . . . . . . . . . . . . . . . . . . . . . . 40 92 3.13.2.15. Sender Directed Multi-Destination Delivery 93 (Type = 149) . . . . . . . . . . . . . . . . . . 40 94 3.14. Differentiated Services field . . . . . . . . . . . . . . 40 95 3.15. Explicit Congestion Notification (ECN) . . . . . . . . 41 96 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 43 97 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 43 98 4.1.1. Problems related with memory allocation . . . . . . . 44 99 4.1.2. Problems that arise from the length of the IP 100 Identification field . . . . . . . . . . . . . . . . . 45 101 4.1.3. Problems that arise from the complexity of the 102 reassembly algorithm . . . . . . . . . . . . . . . . . 46 103 4.1.4. Problems that arise from the ambiguity of the 104 reassembly process . . . . . . . . . . . . . . . . . . 47 105 4.1.5. Problems that arise from the size of the IP 106 fragments . . . . . . . . . . . . . . . . . . . . . . 48 107 4.1.6. Possible security improvements . . . . . . . . . . . . 48 108 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 53 109 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 53 110 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 54 111 4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 55 112 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 56 113 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 56 114 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 56 115 4.3.2. Private address space . . . . . . . . . . . . . . . . 56 116 4.3.3. Class D addresses (224/4 address block) . . . . . . . 57 117 4.3.4. Class E addresses (240/4 address block) . . . . . . . 57 118 4.3.5. Broadcast and multicast addresses, and 119 connection-oriented protocols . . . . . . . . . . . . 57 120 4.3.6. Broadcast and network addresses . . . . . . . . . . . 57 121 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 58 122 5. Security Considerations . . . . . . . . . . . . . . . . . . . 59 123 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60 124 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 125 7.1. Normative References . . . . . . . . . . . . . . . . . . . 60 126 7.2. Informative References . . . . . . . . . . . . . . . . . . 61 127 Appendix A. Advice and guidance to vendors . . . . . . . . . . . 69 128 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70 129 Intellectual Property and Copyright Statements . . . . . . . . . . 71 131 1. Preface 133 1.1. Introduction 135 The TCP/IP protocols were conceived in an environment that was quite 136 different from the hostile environment they currently operate in. 137 However, the effectiveness of the protocols led to their early 138 adoption in production environments, to the point that, to some 139 extent, the current world's economy depends on them. 141 While many textbooks and articles have created the myth that the 142 Internet protocols were designed for warfare environments, the top 143 level goal for the DARPA Internet Program was the sharing of large 144 service machines on the ARPANET [Clark1988]. As a result, many 145 protocol specifications focus only on the operational aspects of the 146 protocols they specify, and overlook their security implications. 148 While the Internet technology evolved since it inception, the 149 Internet's building blocks are basically the same core protocols 150 adopted by the ARPANET more than two decades ago. During the last 151 twenty years, many vulnerabilities have been identified in the TCP/IP 152 stacks of a number of systems. Some of them were based in flaws in 153 some protocol implementations, affecting only a reduced number of 154 systems, while others were based in flaws in the protocols 155 themselves, affecting virtually every existing implementation 156 [Bellovin1989]. Even in the last couple of years, researchers were 157 still working on security problems in the core protocols 158 [I-D.ietf-tcpm-icmp-attacks] [Watson2004] [NISCC2004] [NISCC2005]. 160 The discovery of vulnerabilities in the TCP/IP protocols led to 161 reports being published by a number of CSIRTs (Computer Security 162 Incident Response Teams) and vendors, which helped to raise awareness 163 about the threats and the best mitigations known at the time the 164 reports were published. Unfortunately, this also led to the 165 documentation of the discovered protocol vulnerabilities being spread 166 among a large number of documents, which are sometimes difficult to 167 identify. 169 For some reason, much of the effort of the security community on the 170 Internet protocols did not result in official documents (RFCs) being 171 issued by the IETF (Internet Engineering Task Force). This basically 172 led to a situation in which "known" security problems have not always 173 been addressed by all vendors. In addition, in many cases vendors 174 have implemented quick "fixes" to protocol flaws without a careful 175 analysis of their effectiveness and their impact on interoperability 176 [Silbersack2005]. 178 The lack of adoption of these fixes by the IETF means that any system 179 built in the future according to the official TCP/IP specifications 180 will reincarnate security flaws that have already hit our 181 communication systems in the past. 183 Producing a secure TCP/IP implementation nowadays is a very difficult 184 task, in part because of the lack of a single document that serves as 185 a security roadmap for the protocols. Implementers are faced with 186 the hard task of identifying relevant documentation and differentiate 187 between that which provides correct advisory, and that which provides 188 misleading advisory based on inaccurate or wrong assumptions. 190 There is a clear need for a companion document to the IETF 191 specifications that discusses the security aspects and implications 192 of the protocols, identifies the possible threats, discusses the 193 possible counter-measures, and analyzes their respective 194 effectiveness. 196 This document is the result of an assessment the IETF specifications 197 of the Internet Protocol (IP), from a security point of view. 198 Possible threats were identified and, where possible, counter- 199 measures were proposed. Additionally, many implementation flaws that 200 have led to security vulnerabilities have been referenced in the hope 201 that future implementations will not incur the same problems. 202 Furthermore, this document does not limit itself to performing a 203 security assessment of the relevant IETF specifications, but also 204 provides an assessment of common implementation strategies found in 205 the real world. 207 This document does not aim to be the final word on the security of 208 the Internet Protocol (IP). On the contrary, it aims to raise 209 awareness about many security threats based on the IP protocol that 210 have been faced in the past, those that we are currently facing, and 211 those we may still have to deal with in the future. It provides 212 advice for the secure implementation of the Internet Protocol (IP), 213 but also provides insights about the security aspects of the Internet 214 Protocol that may be of help to the Internet operations community. 216 Feedback from the community is more than encouraged to help this 217 document be as accurate as possible and to keep it updated as new 218 threats are discovered. 220 This document is heavily based on the "Security Assessment of the 221 Internet Protocol" [CPNI2008] released by the UK Centre for the 222 Protection of National Infrastructure (CPNI), available at: 223 http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx . 225 1.2. Scope of this document 227 While there are a number of protocols that affect the way in which IP 228 systems operate, this document focuses only on the specifications of 229 the Internet Protocol (IP). For example, routing and bootstrapping 230 protocols are considered out of the scope of this project. 232 The following IETF RFCs were selected for assessment as part of this 233 work: 235 o RFC 791, "Internet Protocol. DARPA Internet Program. Protocol 236 Specification" (51 pages). 238 o RFC 815, "IP datagram reassembly algorithms" (9 pages). 240 o RFC 1122, "Requirements for Internet Hosts -- Communication 241 Layers" (116 pages). 243 o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages). 245 o RFC 2474, "Definition of the Differentiated Services Field (DS 246 Field) in the IPv4 and IPv6 Headers" (20 pages). 248 o RFC 2475, "An Architecture for Differentiated Services" (36 249 pages). 251 o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) 252 to IP" (63 pages). 254 1.3. Organization of this document 256 This document is basically organized in two parts: "Internet Protocol 257 header fields" and "Internet Protocol mechanisms". The former 258 contains an analysis of each of the fields of the Internet Protocol 259 header, identifies their security implications, and discusses the 260 possible counter-measures. The latter contains an analysis of the 261 security implications of the mechanisms implemented by the Internet 262 Protocol. 264 2. The Internet Protocol 266 The Internet Protocol (IP) provides a basic data transfer function, 267 in the form of data blocks called "datagrams", from a source host to 268 a destination host, across the possible intervening networks. 269 Additionally, it provides some functions that are useful for the 270 interconnection of heterogeneous networks, such as fragmentation and 271 reassembly. 273 The "datagram" has a number of characteristics that makes it 274 convenient for interconnecting systems [Clark1988]: 276 o It eliminates the need of connection state within the network, 277 which improves the survivability characteristics of the network. 279 o It provides a basic service of data transport that can be used as 280 a building block for other transport services (reliable data 281 transport services, etc.). 283 o It represents the minimum network service assumption, which 284 enables IP to be run over virtually any network technology. 286 3. Internet Protocol header fields 288 The IETF specifications of the Internet Protocol define the syntax of 289 the protocol header, along with the semantics of each of its fields. 290 Figure 1 shows the format of an IP datagram. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |Version| IHL |Type of Service| Total Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Identification |Flags| Fragment Offset | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Time to Live | Protocol | Header Checksum | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Source Address | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Destination Address | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Options | Padding | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 1: Internet Protocol header format 310 Even when the minimum IP header size is 20 bytes, an IP module might 311 be handed an (illegitimate) "datagram" of less than 20 bytes. 312 Therefore, before doing any processing of the IP header fields, the 313 following check should be performed by the IP module on the packets 314 handed by the link layer: 316 LinkLayer.PayloadSize >= 20 318 If the packet does not pass this check, it should be dropped. 320 The following subsections contain further sanity checks that should 321 be performed on IP packets. 323 3.1. Version 325 This is a 4-bit field that indicates the version of the Internet 326 Protocol (IP), and thus the syntax of the packet. For IPv4, this 327 field must be 4. 329 When a Link-Layer protocol de-multiplexes a packet to an internet 330 module, it does so based on a "Protocol Type" field in the data-link 331 packet header. 333 In theory, different versions of IP could coexist on a network by 334 using the same "Protocol Type" at the Link-layer, but a different 335 value in the Version field of the IP header. Thus, a single IP 336 module could handle all versions of the Internet Protocol, 337 differentiating them by means of this field. 339 However, in practice different versions of IP are identified by a 340 different "Protocol Type" number in the link-layer protocol header. 341 For example, IPv4 datagrams are encapsulated in Ethernet frames using 342 a "Protocol Type" field of 0x0800, while IPv6 datagrams are 343 encapsulated in Ethernet frames using a "Protocol Type" field of 344 0x86DD [IANA2006a]. 346 Therefore, if an IPv4 module receives a packet, the Version field 347 must be checked to be 4. If this check fails, the packet should be 348 silently dropped. 350 3.2. IHL (Internet Header Length) 352 The IHL (Internet Header Length) indicates the length of the internet 353 header in 32-bit words (4 bytes). As the minimum datagram size is 20 354 bytes, the minimum legal value for this field is 5. Therefore, the 355 following check should be enforced: 357 IHL >= 5 359 For obvious reasons, the Internet header cannot be larger than the 360 whole Internet datagram it is part of. Therefore, the following 361 check should be enforced: 363 IHL * 4 <= Total Length 365 The above check allows for Internet datagrams with no data bytes in 366 the payload that, while nonsensical for virtually every protocol that 367 runs over IP, it is still legal. 369 3.3. TOS 371 Figure 2 shows the syntax of the Type of Service field, defined by 372 RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. 374 0 1 2 3 4 5 6 7 375 +-----+-----+-----+-----+-----+-----+-----+-----+ 376 | PRECEDENCE | D | T | R | C | 0 | 377 +-----+-----+-----+-----+-----+-----+-----+-----+ 379 Figure 2: Type of Service field 381 +----------+----------------------------------------------+ 382 | Bits 0-2 | Precedence | 383 +----------+----------------------------------------------+ 384 | Bit 3 | 0 = Normal Delay, 1 = Low Delay | 385 +----------+----------------------------------------------+ 386 | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | 387 +----------+----------------------------------------------+ 388 | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | 389 +----------+----------------------------------------------+ 390 | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | 391 +----------+----------------------------------------------+ 392 | Bits 7 | Reserved for Future Use (must be zero) | 393 +----------+----------------------------------------------+ 395 Table 1: TOS bits 397 +-----+-----------------+ 398 | 111 | Network Control | 399 +-----+-----------------+ 400 | 110 | Internetwork | 401 +-----+-----------------+ 402 | 101 | CRITIC/ECP | 403 +-----+-----------------+ 404 | 100 | Flash Override | 405 +-----+-----------------+ 406 | 011 | Flash | 407 +-----+-----------------+ 408 | 010 | Immediate | 409 +-----+-----------------+ 410 | 001 | Priority | 411 +-----+-----------------+ 412 | 000 | Routine | 413 +-----+-----------------+ 415 Table 2: Precedence field 417 The Type of Service field can be used to affect the way in which the 418 packet is treated by the systems of a network that process it. 419 Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 420 ("Weak TOS") of this document describe the security implications of 421 the Type of Service field in the forwarding of packets. 423 3.4. Total Length 425 The Total Length field is the length of the datagram, measured in 426 bytes, including both the IP header and the IP payload. Being a 16- 427 bit field, it allows for datagrams of up to 65535 bytes. RFC 791 428 [RFC0791] states that all hosts should be prepared to receive 429 datagrams of up to 576 bytes (whether they arrive as a whole, or in 430 fragments). However, most modern implementations can reassemble 431 datagrams of at least 9 Kbytes. 433 Usually, a host will not send to a remote peer an IP datagram larger 434 than 576 bytes, unless it is explicitly signaled that the remote peer 435 is able to receive such "large" datagrams (for example, by means of 436 TCP's MSS option). However, systems should assume that they may be 437 sent datagrams larger than 576 bytes, regardless of whether they 438 signal their remote peers to do so or not. In fact, it is common for 439 NFS [RFC3530]implementations to send datagrams larger than 576 bytes, 440 even without explicit signaling that the destination system can 441 receive such "large" datagram. 443 Additionally, see the discussion in Section 4.1 "Fragment reassembly" 444 regarding the possible packet sizes resulting from fragment 445 reassembly. 447 Implementations should be aware that the IP module could be handed a 448 packet larger than the value actually contained in the Total Length 449 field. Such a difference usually has to do with legitimate padding 450 bytes at the link-layer protocol, but it could also be the result of 451 malicious activity by an attacker. Furthermore, even when the 452 maximum length of an IP datagram is 65535 bytes, if the link-layer 453 technology in use allows for payloads larger than 65535 bytes, an 454 attacker could forge such a large link-layer packet, meaning it for 455 the IP module. If the IP module of the receiving system were not 456 prepared to handle such an oversized link-layer payload, an 457 unexpected failure might occur. Therefore, the memory buffer used by 458 the IP module to store the link-layer payload should be allocated 459 according to the payload size reported by the link-layer, rather than 460 according to the Total Length field of the IP packet it contains. 462 The IP module could also be handled a packet that is smaller than the 463 actual IP packet size claimed by the Total Length field. This could 464 be used, for example, to produce an information leakage. Therefore, 465 the following check should be performed: 467 LinkLayer.PayloadSize >= Total Length 469 If this check fails, the IP packet should be dropped. As the 470 previous expression implies, the number of bytes passed by the link- 471 layer to the IP module should contain at least as many bytes as 472 claimed by the Total Length field of the IP header. 474 [US-CERT2002] is an example of the exploitation of a forged IP Total 475 Length field to produce an information leakage attack. 477 3.5. Identification (ID) 479 The Identification field is set by the sending host to aid in the 480 reassembly of fragmented datagrams. At any time, it needs to be 481 unique for each set of {Source Address, Destination Address, 482 Protocol}. 484 In many systems, the value used for this field is determined at the 485 IP layer, on a protocol-independent basis. Many of those systems 486 also simply increment the IP Identification field for each packet 487 they send. 489 This implementation strategy is inappropriate for a number of 490 reasons. First, if the Identification field is set on a protocol- 491 independent basis, it will wrap more often than necessary, and thus 492 the implementation will be more prone to the problems discussed in 493 [Kent1987] and [RFC4963]. 495 Additionally, this implementation strategy opens the door to an 496 information leakage that can be exploited to in a number of ways. 497 [Sanfilippo1998a] originally pointed out how this field could be 498 examined to determine the packet rate at which a given system is 499 transmitting information. Later, [Sanfilippo1998b] described how a 500 system with such an implementation can be used to perform a stealth 501 port scan to a third (victim) host. [Sanfilippo1999] explained how 502 to exploit this implementation strategy to uncover the rules of a 503 number of firewalls. [Bellovin2002] explains how the IP 504 Identification field can be exploited to count the number of systems 505 behind a NAT. [Fyodor2004] is an entire paper on most (if not all) 506 the ways to exploit the information provided by the Identification 507 field of the IP header. 509 3.5.1. Some workarounds implemented by the industry 511 As the IP Identification field is only used for the reassembly of 512 datagrams, some operating systems (such as Linux) decided to set this 513 field to 0 in all packets that have the DF bit set. This would, in 514 principle, avoid any type of information leakage. However, it was 515 detected that some non-RFC-compliant middle-boxes fragmented packets 516 even if they had the DF bit set. In such a scenario, all datagrams 517 originally sent with the DF bit set would all result in fragments 518 that would have an Identification field of 0, which would lead to 519 problems ("collision" of the Identification number) in the reassembly 520 process. 522 Linux (and Solaris) later set the IP Identification field on a per- 523 IP-address basis. This avoids some of the security implications of 524 the IP Identification field, but not all. For example, systems 525 behind a load balancer can still be counted. 527 3.5.2. Possible security improvements 529 Contrary to common wisdom, the IP Identification field does not need 530 to be system-wide unique for each packet, but has to be unique for 531 each {Source Address, Destination Address, Protocol} tuple. 533 For instance, the TCP specification defines a generic send() function 534 which takes the IP ID as one of its arguments. 536 We provide an analysis of the possible security improvements that 537 could be implemented, based on whether the protocol using the 538 services of IP is connection-oriented or connection-less. 540 Connection-oriented protocols 542 To avoid the security implications of the information leakage 543 described above, a pseudo-random number generator (PRNG) could be 544 used to set the IP Identification field on a {Source Address, 545 Destination Address} basis (for each connection-oriented transport 546 protocol). 548 [Klein2007] is a security advisory that describes a weakness in the 549 pseudo random number generator (PRNG) in use for the generation of 550 the IP Identification by a number of operating systems. 552 While in theory a pseudo-random number generator could lead to 553 scenarios in which a given Identification number is used more than 554 once in the same time-span for datagrams that end up getting 555 fragmented (with the corresponding potential reassembly problems), in 556 practice this is unlikely to cause trouble. 558 By default, most implementations of connection-oriented protocols, 559 such as TCP, implement some mechanism for avoiding fragmentation 560 (such as the Path-MTU Discovery mechanism described in [RFC1191]). 562 Thus, fragmentation will only take place sporadically, when a non- 563 RFC-compliant middle-box is placed somewhere along the path that the 564 packets travel to get to the destination host. Once the sending 565 system is signaled by the middle-box that it should reduce the size 566 of the packets it sends, fragmentation would be avoided. Also, for 567 reassembly problems to arise, the same Identification field should be 568 reused very frequently, and either strong packet reordering or packet 569 loss should take place. 571 Nevertheless, regardless of what policy is used for selecting the 572 Identification field, with the current link speeds fragmentation is 573 already bad enough to rely on it. A mechanism for avoiding 574 fragmentation should be implemented, instead. 576 Connectionless protocols 578 Connectionless protocols usually have these characteristics: 580 o lack of flow-control mechanisms, 582 o lack of packet sequencing mechanisms, and, 584 o lack of reliability mechanisms (such as "timeout and retransmit"). 586 This basically means that the scenarios and/or applications for which 587 connection-less transport protocols are used assume that: 589 o Applications will be used in environments in which packet 590 reordering is very unlikely (such as Local Area Networks), as the 591 transport protocol itself does not provide data sequencing. 593 o The data transfer rates will be low enough that flow control will 594 be unnecessary. 596 o Packet loss is not important and probably also unlikely. 598 With these assumptions in mind, the Identification field could still 599 be set according to a pseudo-random number generator (PRNG). In the 600 event a given Identification number was reused while the first 601 instance of the same number is still on the network, the first IP 602 datagram would be reassembled before the fragments of the second IP 603 datagram get to their destination. 605 In the event this was not the case, the reassembly of fragments would 606 result in a corrupt datagram. While some existing work 607 [Silbersack2005] assumes that this error would be caught by some 608 upper-layer error detection code, the error detection code in 609 question (such as UDP's checksum) might be intended to detect single 610 bit errors, rather than data corruption arising from the replacement 611 of a complete data block (as is the case in corruption arising from 612 collision of IP Identification numbers). 614 In the case of UDP, unfortunately some systems have been known to not 615 enable the UDP checksum by default. For most applications, packets 616 containing errors should be dropped. Probably the only application 617 that may benefit from disabling the checksum is streaming media, to 618 avoid dropping a complete sample for a single-bit error. 620 In general, if IP Identification number collisions become an issue 621 for the application using the connection-less protocol, then use of a 622 different transport protocol (which hopefully avoids fragmentation) 623 should be considered. 625 It must be noted that an attacker could intentionally exploit 626 collisions of IP Identification numbers to perform a Denial of 627 Service attack, by sending forged fragments that would cause the 628 reassembly process to result in a corrupt datagram that would either 629 be dropped by the transport protocol, or would incorrectly be handed 630 to the corresponding application. This issue is discussed in detail 631 in section 4.1 ("Fragment Reassembly"). 633 3.6. Flags 635 The IP header contains 3 control bits, two of which are currently 636 used for the fragmentation and reassembly function. 638 As described by RFC 791, their meaning is: 640 Bit 0: reserved, must be zero 642 Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment 644 Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments 646 The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) 647 mechanism described in [RFC1191]. However, it can also be exploited 648 by an attacker to evade Network Intrusion Detection Systems. An 649 attacker could send a packet with the DF bit set to a system 650 monitored by a NIDS, and depending on the Path-MTU to the intended 651 recipient, the packet might be dropped by some intervening router 652 (because of being too big to be forwarded without fragmentation), 653 without the NIDS being aware of it. 655 (still to be added) 656 (See Figure 3 in Page 13 of the CPNI document) 658 Figure 3: NIDS evasion by means of the Internet Protocol DF bit 660 In Figure 3, an attacker sends a 17914-byte datagram meant to the 661 victim host in the same figure. The attacker's packet probably 662 contains an overlapping IP fragment or an overlapping TCP segment, 663 aiming at "confusing" the NIDS, as described in [Ptacek1998]. The 664 packet is screened by the NIDS sensor at the network perimeter, which 665 probably reassembles IP fragments and TCP segments for the purpose of 666 assessing the data transferred to and from the monitored systems. 667 However, as the attacker's packet should transit a link with an MTU 668 smaller than 17914 bytes (1500 bytes in this example), the router 669 that encounters that this packet cannot be forwarded without 670 fragmentation (Router B) discards the packet, and sends an ICMP 671 "fragmentation needed and DF bit set" error message to the source 672 host. In this scenario, the NIDS may remain unaware that the 673 screened packet never reached the intended destination, and thus get 674 an incorrect picture of the data being transferred to the monitored 675 systems. 677 [Shankar2003] introduces a technique named "Active Mapping" that 678 prevents evasion of a NIDS by acquiring sufficient knowledge about 679 the network being monitored, to assess which packets will arrive at 680 the intended recipient, and how they will be interpreted by it. 682 Some firewalls are known to drop packets that have both the MF (More 683 Fragments) and the DF (Don't fragment) bits set. While in principle 684 such a packet might seem nonsensical, there are a number of reasons 685 for which non-malicious packets with these two bits set can be found 686 in a network. First, they may exist as the result of some middle-box 687 processing a packet that was too large to be forwarded without 688 fragmentation. Instead of simply dropping the corresponding packet 689 and sending an ICMP error message to the source host, some middle- 690 boxes fragment the packet (copying the DF bit to each fragment), and 691 also send an ICMP error message to the originating system. Second, 692 some systems (notably Linux) set both the MF and the DF bits to 693 implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should 694 be taken into account when configuring firewalls and/or tuning 695 Network Intrusion Detection Systems (NIDS). 697 3.7. Fragment Offset 699 The Fragment Offset is used for the fragmentation and reassembly of 700 IP datagrams. It indicates where in the original datagram the 701 fragment belongs, and is measured in units of eight bytes. As a 702 consequence, all fragments (except the last one), have to be aligned 703 on an 8-byte boundary. Therefore, if a packet has the MF flag set, 704 the following check should be enforced: 706 (Total Length - IHL * 4) % 8 == 0 708 If the packet does not pass this check, it should be dropped. 710 Given that Fragment Offset is a 13-bit field, it can hold a value of 711 up to 8191, which would correspond to an offset 65528 bytes within 712 the original (non-fragmented) datagram. As such, it is possible for 713 a fragment to implicitly claim to belong to a datagram larger than 714 65535 bytes (the maximum size for a legitimate IP datagram). Even 715 when the fragmentation mechanism would seem to allow fragments that 716 could reassemble into such large datagrams, the intent of the 717 specification is to allow for the transmission of datagrams of up to 718 65535 bytes. Therefore, if a given fragment would reassemble into a 719 datagram of more than 65535 bytes, the resulting datagram should be 720 dropped. To detect such a case, the following check should be 721 enforced on all packets for which the Fragment Offset contains a non- 722 zero value: 724 Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535 726 In the worst-case scenario, the reassembled datagram could have a 727 size of up to 131043 bytes. 729 Such a datagram would result when the first fragment has a Fragment 730 Offset of 0 and a Total Length of 65532, and the second (and last) 731 fragment has a Fragment Offset of 8189 (65512 bytes), and a Total 732 Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 733 bytes), the reassembled datagram would be 65532 + (65535 - 20) = 734 131047 bytes. 736 Additionally, the IP module should implement all the necessary 737 measures to be able to handle such illegitimate reassembled 738 datagrams, so as to avoid them from overflowing the buffer(s) used 739 for the reassembly function. 741 [CERT1996c] and [Kenney1996] describe the exploitation of this issue 742 to perform a Denial of Service (DoS) attack. 744 3.8. Time to Live (TTL) 746 The Time to Live (TTL) field has two functions: to bind the lifetime 747 of the upper-layer packets (e.g., TCP segments) and to prevent 748 packets from looping indefinitely in the network. 750 Originally, this field was meant to indicate maximum time a datagram 751 was allowed to remain in the internet system, in units of seconds. 752 As every internet module that processes a datagram must decrement the 753 TTL by at least one, the original definition of the TTL field became 754 obsolete, and it must now be interpreted as a hop count. 756 Most systems allow the administrator to configure the TTL to be used 757 for the packets sent, with the default value usually being a power of 758 2. The recommended value for the TTL field, as specified by the IANA 759 is 64 [IANA2006b]. This value reflects the assumed "diameter" of the 760 Internet, plus a margin to accommodate its growth. 762 The TTL field has a number of properties that are interesting from a 763 security point of view. Given that the default value used for the 764 TTL is usually a power of eight, chances are that, unless the 765 originating system has been explicitly tuned to use a non-default 766 value, if a packet arrives with a TTL of 60, the packet was 767 originally sent with a TTL of 64. In the same way, if a packet is 768 received with a TTL of 120, chances are that the original packet had 769 a TTL of 128. 771 This discussion assumes there was no protocol scrubber, transparent 772 proxy, or some other middle-box that overwrites the TTL field in a 773 non-standard way, between the originating system and the point of the 774 network in which the packet was received. 776 Asserting the TTL with which a packet was originally sent by the 777 source system can help to obtain valuable information. Among other 778 things, it may help in: 780 o Fingerprinting the operating system being used by the source host. 782 o Fingerprinting the physical device from which the packets 783 originate. 785 o Locating the source host in the network topology. 787 Additionally, it can be used to perform functions such as: 789 o Evading Network Intrusion Detection Systems. 791 o Improving the security of applications that make use of the 792 Internet Protocol (IP). 794 Fingerprinting the operating system in use by the source host 796 Different operating systems use a different default TTL for the 797 packets they send. Thus, asserting the TTL with which a packet was 798 originally sent will help to reduce the number of possible operating 799 systems in use by the source host. 801 Fingerprinting the physical device from which the packets originate 803 When several systems are behind a middle-box such as a NAT or a load 804 balancer, the TTL may help to count the number of systems behind the 805 middle-box. If each of the systems behind the middle-box use a 806 different default TTL for the packets they send, or they are located 807 in a different place of the network topology, an attacker could 808 stimulate responses from the devices being fingerprinted, and each 809 response that arrives with a different TTL could be assumed to come 810 from a different device. 812 Of course, there are many other and much more precise techniques to 813 fingerprint physical devices. Among drawbacks of this method, while 814 many systems differ in the default TTL they use for the packets they 815 send, there are also many implementations which use the same default 816 TTL. Additionally, packets sent by a given device may take different 817 routes (e.g., due to load sharing or route changes), and thus a given 818 packet may incorrectly be presumed to come from a different device, 819 when in fact it just traveled a different route. 821 Locating the source host in the network topology 823 The TTL field may also be used to locate the source system in the 824 network topology [Northcutt2000]. 826 (still to be added) 827 (See Figure 4 on page 17 of the CPNI document.) 829 Figure 4: Tracking a host by means of the TTL field 831 Consider network topology of Figure 4. Assuming that an attacker 832 ("F" in the figure) is performing some type of attack that requires 833 forging the Source Address (such as a TCP-based DoS reflection 834 attack), and some of the involved hosts are willing to cooperate to 835 locate the attacking system. 837 Assuming that: 839 o All the packets A gets have a TTL of 61. 841 o All the packets B gets have a TTL of 61. 843 o All the packets C gets have a TTL of 61. 845 o All the packets D gets have a TTL of 62. 847 Based on this information, and assuming that the system's default 848 value was not overridden, it would be fair to assume that the 849 original TTL of the packets was 64. With this information, the 850 number of hops between the attacker and each of the aforementioned 851 hosts can be calculated. 853 The attacker is: 855 o Three hops away from A. 857 o Three hops away from B. 859 o Three hops away from C. 861 o Two hops away from D. 863 In the network setup of Figure 3, the only system that satisfies all 864 these conditions is the one marked as the "F". 866 The scenario described above is for illustration purposes only. In 867 practice, there are a number of factors that may prevent this 868 technique from being successfully applied: 870 o Unless there is a "large" number of cooperating systems, and the 871 attacker is assumed to be no more than a few hops away from these 872 a systems, the number of "candidate" hosts will usually be too 873 large for the information to be useful. 875 o The attacker may be using a non-default TTL value, or, what is 876 worse, using a pseudo-random value for the TTL of the packets it 877 sends. 879 o The packets sent by the attacker may take different routes, as a 880 result of a change in network topology, load sharing, etc., and 881 thus may lead to an incorrect analysis. 883 Evading Network Intrusion Detection Systems 885 The TTL field can be used to evade Network Intrusion Detection 886 Systems. Depending on the position of a sensor relative to the 887 destination host of the examined packet, the NIDS may get a different 888 picture from that got by the intended destination system. As an 889 example, a sensor may process a packet that will expire before 890 getting to the destination host. A general counter-measure for this 891 type of attack is to normalize the traffic that gets to an 892 organizational network. Examples of such traffic normalization can 893 be found in [Paxson2001]. 895 Improving the security of applications that make use of the Internet 896 Protocol (IP) 898 In some scenarios, the TTL field can be also used to improve the 899 security of an application, by restricting the hosts that can 900 communicate with the given application. For example, there are 901 applications for which the communicating systems are typically in the 902 same network segment (i.e., there are no intervening routers). Such 903 an application is the BGP (Border Gateway Protocol) between utilized 904 by two peer routers. 906 If both systems use a TTL of 255 for all the packets they send to 907 each other, then a check could be enforced to require all packets 908 meant for the application in question to have a TTL of 255. 910 As all packets sent by systems that are not in the same network 911 segment will have a TTL smaller than 255, those packets will not pass 912 the check enforced by these two cooperating peers. This check 913 reduces the set of systems that may perform attacks against the 914 protected application (BGP in this case), thus mitigating the attack 915 vectors described in [NISCC2004] and [Watson2004]. 917 This same check is enforced for related ICMP error messages, with the 918 intent of mitigating the attack vectors described in [NISCC2005] and 919 [I-D.ietf-tcpm-icmp-attacks]. 921 The TTL field can be used in a similar way in scenarios in which the 922 cooperating systems either do not use a default TTL of 255, or are 923 not in the same network segment (i.e., multi-hop peering). In that 924 case, the following check could be enforced: 926 TTL >= 255 - DeltaHops 928 This means that the set of hosts from which packets will be accepted 929 for the protected application will be reduced to those that are no 930 more than DeltaHops away. While for obvious reasons the level of 931 protection will be smaller than in the case of directly-connected 932 peers, the use of the TTL field for protecting multi-hop peering 933 still reduces the set of hosts that could potentially perform a 934 number of attacks against the protected application. 936 This use of the TTL field has been officially documented by the IETF 937 under the name "Generalized TTL Security Mechanism" (GTSM) in 938 [RFC5082]. 940 Some protocol scrubbers enforce a minimum value for the TTL field of 941 the packets they forward. It must be understood that depending on 942 the minimum TTL being enforced, and depending on the particular 943 network setup, the protocol scrubber may actually help attackers to 944 fool the GTSM, by "raising" the TTL of the attacking packets. 946 3.9. Protocol 948 The Protocol field indicates the protocol encapsulated in the 949 internet datagram. The Protocol field may not only contain a value 950 corresponding to an implemented protocol within the system, but also 951 a value corresponding to a protocol not implemented, or even a value 952 not yet assigned by the IANA [IANA2006c]. 954 While in theory there should not be security implications from the 955 use of any value in the protocol field, there have been security 956 issues in the past with systems that had problems when handling 957 packets with some specific protocol numbers [Cisco2003] [CERT2003]. 959 3.10. Header Checksum 961 The Header Checksum field is an error detection mechanism meant to 962 detect errors in the IP header. While in principle there should not 963 be security implications arising from this field, it should be noted 964 that due to non-RFC-compliant implementations, the Header Checksum 965 might be exploited to detect firewalls and/or evade network intrusion 966 detection systems (NIDS). 968 [Ed3f2002] describes the exploitation of the TCP checksum for 969 performing such actions. As there are internet routers known to not 970 check the IP Header Checksum, and there might also be middle-boxes 971 (NATs, firewalls, etc.) not checking the IP checksum allegedly due to 972 performance reasons, similar malicious activity to the one described 973 in [Ed3f2002] might be performed with the IP checksum. 975 3.11. Source Address 977 The Source Address of an IP datagram identifies the node from which 978 the packet originated. 980 Strictly speaking, the Source Address of an IP datagram identifies 981 the interface of the sending system from which the packet was sent, 982 (rather than the originating "system"), as in the Internet 983 Architecture there's no concept of "node". 985 Unfortunately, it is trivial to forge the Source Address of an 986 Internet datagram. This has been exploited in the past for 987 performing a variety of DoS (Denial of Service) attacks [NISCC2004] 989 [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate as 990 other systems in scenarios in which authentication was based on the 991 Source Address of the sending system [daemon91996]. 993 The extent to which these attacks can be successfully performed in 994 the Internet can be reduced through deployment of ingress/egress 995 filtering in the internet routers. [NISCC2006] is a detailed guide 996 on ingress and egress filtering. [RFC3704] and [RFC2827] discuss 997 ingress filtering. [GIAC2000] discusses egress filtering. 999 Even when the obvious field on which to perform checks for ingress/ 1000 egress filtering is the Source Address and Destination Address fields 1001 of the IP header, there are other occurrences of IP addresses on 1002 which the same type of checks should be performed. One example is 1003 the IP addresses contained in the payload of ICMP error messages, as 1004 discussed in [I-D.ietf-tcpm-icmp-attacks] and [Gont2006]. 1006 There are a number of sanity checks that should be performed on the 1007 Source Address of an IP datagram. Details can be found in Section 1008 4.2 ("Addressing"). 1010 Additionally, there exist freely available tools that allow 1011 administrators to monitor which IP addresses are used with which MAC 1012 addresses [LBNL2006]. This functionality is also included in many 1013 Network Intrusion Detection Systems (NIDS). 1015 It is also very important to understand that authentication should 1016 never rely on the Source Address of the communicating systems. 1018 3.12. Destination Address 1020 The Destination Address of an IP datagram identifies the destination 1021 host to which the packet is meant to be delivered. 1023 Strictly speaking, the Destination Address of an IP datagram 1024 identifies the interface of the destination network interface, rather 1025 than the destination "system", as in the Internet Architecture 1026 there's no concept of "node". 1028 There are a number of sanity checks that should be performed on the 1029 Destination Address of an IP datagram. Details can be found in 1030 Section 4.2 ("Addressing"). 1032 3.13. Options 1034 According to RFC 791, IP options must be implemented by all IP 1035 modules, both in hosts and gateways (i.e., end-systems and 1036 intermediate-systems). 1038 There are two cases for the format of an option: 1040 o Case 1: A single byte of option-type. 1042 o Case 2: An option-type byte, an option-length byte, and the actual 1043 option-data bytes. 1045 In the Case 2, the option-length byte counts the option-type byte and 1046 the option-length byte, as well as the actual option-data bytes. 1048 All options except "End of Option List" (Type = 0) and "No Operation" 1049 (Type = 1), are of Class 2. 1051 The option-type has three fields: 1053 o 1 bit: copied flag. 1055 o 2 bits: option class. 1057 o 5 bits: option number. 1059 The copied flag indicates whether this option should be copied to all 1060 fragments in the event the packet carrying it needs to be fragmented: 1062 o 0 = not copied. 1064 o 1 = copied. 1066 The values for the option class are: 1068 o 0 = control. 1070 o 1 = reserved for future use. 1072 o 2 = debugging and measurement. 1074 o 3 = reserved for future use. 1076 This format allows for the creation of new options for the extension 1077 of the Internet Protocol (IP). 1079 Finally, the option number identifies the syntax of the rest of the 1080 option. 1082 3.13.1. General issues with IP options 1084 The following subsections discuss security issues that apply to all 1085 IP options. The proposed checks should be performed in addition to 1086 any option-specific checks proposed in the next sections. 1088 3.13.1.1. Processing requirements 1090 Router manufacturers tend to do IP option processing on the main 1091 processor, rather than on line cards. Unless special care is taken, 1092 this may be a security risk, as there is potential for overwhelming 1093 the router with option processing. 1095 To reduce the impact of these packets on the system performance, a 1096 few counter-measures could be implemented: 1098 o Rate-limit the number of packets with IP options that are 1099 processed by the system. 1101 o Enforce a limit on the maximum number of options to be accepted on 1102 a given internet datagram. 1104 The first check avoids a flow of packets with IP options to overwhelm 1105 the system in question. The second check avoids packets with 1106 multiple IP options to affect the performance of the system. 1108 3.13.1.2. Processing of the options by the upper layer protocol 1110 Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options 1111 received in IP datagrams must be passed to the transport layer (or to 1112 ICMP processing when the datagram is an ICMP message). Therefore, 1113 care in option processing must be taken not only at the internet 1114 layer, but also in every protocol module that may end up processing 1115 the options included in an IP datagram. 1117 3.13.1.3. General sanity checks on IP options 1119 There are a number of sanity checks that should be performed on IP 1120 options before further option processing is done. They help prevent 1121 a number of potential security problems, including buffer overflows. 1122 When these checks fail, the packet carrying the option should be 1123 dropped. 1125 RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" 1126 message to the originating system when a packet is dropped because of 1127 a invalid value in a field, such as the cases discussed in the 1128 following subsections. Sending such a message might help in 1129 debugging some network problems. However, it would also alert 1130 attackers about the system that is dropping packets because of the 1131 invalid values in the protocol fields. 1133 We advice that systems default to sending an ICMP "Parameter Problem" 1134 error message when a packet is dropped because of an invalid value in 1135 a protocol field (e.g., as a result of dropping a packet due to the 1136 sanity checks described in this section). However, we recommend that 1137 systems provide a system-wide toggle that allows an administrator to 1138 override the default behavior so that packets can be silently dropped 1139 due when an invalid value in a protocol field is encountered. 1141 Option length 1143 Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must 1144 not crash as the result of an option length that is outside the 1145 possible range, and mentions that erroneous option lengths have been 1146 observed to put some IP implementations into infinite loops. 1148 For options that belong to the "Case 2" described in the previous 1149 section, the following check should be performed: 1151 option-length >= 2 1153 The value "2" accounts for the option-type byte, and the option- 1154 length byte. 1156 This check prevents, among other things, loops in option processing 1157 that may arise from incorrect option lengths. 1159 Additionally, while the option-length byte of IP options of "Case 2" 1160 allows for an option length of up to 255 bytes, there is a limit on 1161 legitimate option length imposed by the syntax of the IP header. 1163 For all options of "Case 2", the following check should be enforced: 1165 option-offset + option-length <= IHL * 4 1167 Where option-offset is the offset of the first byte of the option 1168 within the IP header, with the first byte of the IP header being 1169 assigned an offset of 0. 1171 If a packet does not pass these checks, the corresponding packet 1172 should be dropped. 1174 The aforementioned check is meant to detect forged option-length 1175 values that might make an option overlap with the IP payload. This 1176 would be particularly dangerous for those IP options which request 1177 the processing systems to write information into the option-data area 1178 (such as the Record Route option), as it would allow the generation 1179 of overflows. 1181 Data types 1182 Many IP options use pointer and length fields. Care must be taken as 1183 to the data type used for these fields in the implementation. For 1184 example, if an 8-bit signed data type were used to hold an 8-bit 1185 pointer, then, pointer values larger than 128 might mistakenly be 1186 interpreted as negative numbers, and thus might lead to unpredictable 1187 results. 1189 3.13.2. Issues with specific options 1191 3.13.2.1. End of Option List (Type = 0) 1193 This option is used to indicate the "end of options" in those cases 1194 in which the end of options would not coincide with the end of the 1195 Internet Protocol Header. 1197 IP systems are required to ignore those options they do not 1198 implement. Therefore, even in those cases in which this option is 1199 required, but is missing, IP systems should be able to process the 1200 remaining bytes of the IP header without any problems. 1202 3.13.2.2. No Operation (Type = 1) 1204 The no-operation option is basically meant to allow the sending 1205 system to align subsequent options in, for example, 32-bit 1206 boundaries. 1208 This option does not have security implications. 1210 3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) 1212 This option lets the originating system specify a number of 1213 intermediate systems a packet must pass through to get to the 1214 destination host. Additionally, the route followed by the packet is 1215 recorded in the option. The receiving host (end-system) must use the 1216 reverse of the path contained in the received LSRR option. 1218 The LSSR option can be of help in debugging some network problems. 1219 Some ISP Internet Service Provider) peering agreements require 1220 support for this option in the routers within the peer of the ISP. 1222 The LSRR option has well-known security implications. Among other 1223 things, the option can be used to: 1225 o Bypass firewall rules 1227 o Reach otherwise unreachable internet systems 1228 o Establish TCP connections in a stealthy way 1230 o Learn about the topology of a network 1232 o Perform bandwidth-exhaustion attacks 1234 Of these attack vectors, the one that has probably received least 1235 attention is the use of the LSRR option to perform bandwidth 1236 exhaustion attacks. The LSRR option can be used as an amplification 1237 method for performing bandwidth-exhaustion attacks, as an attacker 1238 could make a packet bounce multiple times between a number of systems 1239 by carefully crafting an LSRR option. 1241 This is the IPv4-version of the IPv6 amplification attack that was 1242 widely publicized in 2007 [Biondi2007]. The only difference is that 1243 the maximum length of the IPv4 header (and hence the LSRR option) 1244 limits the amplification factor when compared to the IPv6 counter- 1245 part. 1247 While the LSSR option may be of help in debugging some network 1248 problems, its security implications outweigh any legitimate use. 1250 All systems should, by default, drop IP packets that contain an LSRR 1251 option. However, they should provide a system-wide toggle to enable 1252 support for this option for those scenarios in which this option is 1253 required. Such system-wide toggle should default to "off" (or 1254 "disable"). 1256 [OpenBSD1998] is a security advisory about an improper implementation 1257 of such a system-wide in 4.4BSD kernels. 1259 Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to 1260 act as an intermediate hop in a source route, forwarding a source- 1261 routed datagram to the next specified hop. We strongly discourage 1262 host software from forwarding source-routed datagrams. 1264 If processing of source-routed datagrams is explicitly enabled in a 1265 system, the following sanity checks should be performed. 1267 RFC 791 states that this option should appear, at most, once in a 1268 given packet. Thus, if a packet is found to have more than one LSRR 1269 option, it should be dropped. Therefore, hosts and routers should 1270 discard packets that contain more than one LSRR option. 1271 Additionally, if a packet were found to have both LSRR and SSRR 1272 options, it should be dropped. 1274 As many other IP options, the LSSR contains a Length field that 1275 indicates the length of the option. Given the format of the option, 1276 the Length field should be checked to be at least 3 (three): 1278 LSRR.Length >= 3 1280 If the packet does not pass this check, it should be dropped. 1282 Additionally, the following check should be performed on the Length 1283 field: 1285 LSRR.Offset + LSRR.Length < IHL *4 1287 This check assures that the option does not overlap with the IP 1288 payload (i.e., it does not go past the IP header). If the packet 1289 does not pass this check, it should be dropped. 1291 The Pointer is relative to this option. Thus, the minimum legal 1292 value is 4. Therefore, the following check should be performed. 1294 LSRR.Pointer >= 4 1296 If the packet does not pass this check, it should be dropped. 1297 Additionally, the Pointer field should be a multiple of 4. 1298 Consequently, the following check should be performed: 1300 LSRR.Pointer % 4 == 0 1302 If a packet does not pass this check, it should be dropped. 1304 When a system receives an IP packet with the LSRR route option, it 1305 should check whether the source route is empty or not. The option is 1306 empty if: 1308 LSRR.Pointer > LSRR.Length 1310 In that case, routing should be based on the Destination Address 1311 field, and no further processing should be done on the LSRR option. 1313 [Microsoft1999] is a security advisory about a vulnerability arising 1314 from improper validation of the LSRR.Pointer field. 1316 If the address in the Destination Address field has been reached, and 1317 the option is not empty, the next address in the source route 1318 replaces the address in the Destination Address field. 1320 The IP address of the interface that will be used to forward this 1321 datagram should be recorded into the LSRR. However, before writing 1322 in the route data area, the following check should be performed: 1324 LSRR.Length - LSRR.Pointer >= 3 1326 This assures that there will be at least 4 bytes of space in which to 1327 record the IP address. If the packet does not pass this check, it 1328 should be dropped. 1330 An offset of "1" corresponds to the option type, that's why the 1331 performed check is LSRR.Length - LSRR.Pointer >=3, and not 1332 LSRR.Length - LSRR.Pointer >=4. 1334 The LSRR must be copied on fragmentation. This means that if a 1335 packet that carries the LSRR is fragmented, each of the fragments 1336 will have to go through the list of systems specified in the LSRR 1337 option. 1339 3.13.2.4. Strict Source and Record Route (SSRR) (Type = 137) 1341 This option allows the originating system to specify a number of 1342 intermediate systems a packet must pass through to get to the 1343 destination host. Additionally, the route followed by the packet is 1344 recorded in the option, and the destination host (end-system) must 1345 use the reverse of the path contained in the received SSRR option. 1347 This option is similar to the Loose Source and Record Route (LSRR) 1348 option, with the only difference that in the case of SSRR, the route 1349 specified in the option is the exact route the packet must take 1350 (i.e., no other intervening routers are allowed to be in the route). 1352 The SSSR option can be of help in debugging some network problems. 1353 Some ISP Internet Service Provider) peering agreements require 1354 support for this option in the routers within the peer of the ISP. 1356 The SSRR option has well-known security implications. Among other 1357 things, the option can be used to: 1359 o Bypass firewall rules 1361 o Reach otherwise unreachable internet systems 1363 o Establish TCP connections in a stealthy way 1365 o Learn about the topology of a network 1367 o Perform bandwidth-exhaustion attacks 1369 Of these attack vectors, the one that has probably received least 1370 attention is the use of the SSRR option to perform bandwidth 1371 exhaustion attacks. The SSRR option can be used as an amplification 1372 method for performing bandwidth-exhaustion attacks, as an attacker 1373 could make a packet bounce multiple times between a number of systems 1374 by carefully crafting an LSRR option. 1376 This is the IPv4-version of the IPv6 amplification attack that was 1377 widely publicized in 2007 [Biondi2007]. The only difference is that 1378 the maximum length for the IPv4 header (and hence the SSRR option) 1379 limits the amplification factor when compared to the IPv6 counter- 1380 part. 1382 While the SSSR option may be of help in debugging some network 1383 problems, its security implications outweigh any legitimate use of 1384 it. 1386 All systems should, by default, drop IP packets that contain an LSRR 1387 option. However, they should provide a system-wide toggle to enable 1388 support for this option for those scenarios in which this option is 1389 required. Such system-wide toggle should default to "off" (or 1390 "disable"). 1392 [OpenBSD1998] is a security advisory about an improper implementation 1393 of such a system-wide in 4.4BSD kernels. 1395 In the event processing of the SSRR option were explicitly enabled, 1396 there are some sanity checks that should be performed. 1398 RFC 791 states that this option should appear, at most, once in a 1399 given packet. Thus, if a packet is found to have more than one SSRR 1400 option, it should be dropped. Also, if a packet contains a 1401 combination of SSRR and LSRR options, it should be dropped. 1403 As the SSRR option is meant to specify the route a packet should 1404 follow from source to destination, use of more than one SSRR option 1405 in a single packet would be nonsensical. Therefore, hosts and 1406 routers should check the IP header and discard the packet if it 1407 contains more than one SSRR option, or a combination of LSRR and SSRR 1408 options. 1410 As with many other IP options, the SSRR option contains a Length 1411 field that indicates the length of the option. Given the format of 1412 the option, the length field should be checked to be at least 3: 1414 SSRR.Length >= 3 1416 If the packet does not pass this check, it should be dropped. 1418 Additionally, the following check should be performed on the length 1419 field: 1421 SSRR.Offset + SSRR.Length < IHL *4 1423 This check assures that the option does not overlap with the IP 1424 payload (i.e., it does not go past the IP header). If the packet 1425 does not pass this check, it should be dropped. 1427 The Pointer field is relative to this option, with the minimum legal 1428 value being 4. Therefore, the following check should be performed: 1430 SSRR.Pointer >= 4 1432 If the packet does not pass this check, it should be dropped. 1434 Additionally, the Pointer field should be a multiple of 4. 1435 Consequently, the following check should be performed: 1437 SSRR.Pointer % 4 == 0 1439 If a packet does not pass this check, it should be dropped. 1441 If the packet passes the above checks, the receiving system should 1442 determine whether the Destination Address of the packet corresponds 1443 to one of its IP addresses. If does not, it should be dropped. 1445 Contrary to the IP Loose Source and Record Route (LSRR) option, the 1446 SSRR option does not allow in the route other routers than those 1447 contained in the option. If the system implements the weak end- 1448 system model, it is allowed for the system to receive a packet 1449 destined to any of its IP addresses, on any of its interfaces. If 1450 the system implements the strong end-system model, a packet destined 1451 to it can be received only on the interface that corresponds to the 1452 IP address contained in the Destination Address field [RFC1122]. 1454 If the packet passes this check, the receiving system should 1455 determine whether the source route is empty or not. The option is 1456 empty if: 1458 SSRR.Pointer > SSRR.Length 1460 In that case, if the address in the destination field has not been 1461 reached, the packet should be dropped. 1463 [Microsoft1999] is a security advisory about a vulnerability arising 1464 from improper validation of the SSRR.Pointer field. 1466 If the option is not empty, and the address in the Destination 1467 Address field has been reached, the next address in the source route 1468 replaces the address in the Destination Address field. This IP 1469 address must be reachable without the use of any intervening router 1470 (i.e., the address must belong to any of the networks to which the 1471 system is directly attached). If that is not the case, the packet 1472 should be dropped. 1474 The IP address of the interface that will be used to forward this 1475 datagram should be recorded into the SSRR. However, before doing 1476 that, the following check should be performed: 1478 SSRR.Length - SSRR.Pointer >=3 1480 An offset of "1" corresponds to the option type, that's why the 1481 performed check is SSRR.Length - SSRR.Pointer >=3, and not 1482 SSRR.Length - SSRR.Pointer >=4. 1484 This assures that there will be at least 4 bytes of space on which to 1485 record the IP address. If the packet does not pass this check, it 1486 should be dropped. 1488 The SSRR option must be copied on fragmentation. This means that if 1489 a packet that carries the SSRR is fragmented, each of the fragments 1490 will have to go through the list of systems specified in the SSRR 1491 option. 1493 3.13.2.5. Record Route (Type = 7) 1495 This option provides a means to record the route that a given packet 1496 follows. 1498 The option begins with an 8-bit option code, which must be equal to 1499 7. The second byte is the option length, which includes the option- 1500 type byte, the option-length byte, the pointer byte, and the actual 1501 option-data. The third byte is a pointer into the route data, 1502 indicating the first byte of the area in which to store the next 1503 route data. The pointer is relative to the option start. 1505 RFC 791 states that this option should appear, at most, once in a 1506 given packet. Therefore, if a packet has more than one instance of 1507 this option, it should be dropped. 1509 Given the format of the option, the Length field should be checked to 1510 be at least 3: 1512 RR.Length >= 3 1514 If the packet does not pass this check, it should be dropped. 1516 Additionally, the following check should be performed on the Length 1517 field: 1519 RR.Offset + RR_Length < IHL *4 1521 This check assures that the option does not overlap with the IP 1522 payload (i.e., it does not go past the IP header). If the packet 1523 does not pass this check, it should be dropped. 1525 The pointer field is relative to this option, with the minimum legal 1526 value being 4. Therefore, the following check should be performed: 1528 RR.Pointer >= 3 1530 If the packet does not pass this check, it should be silently 1531 dropped. 1533 Additionally, the Pointer field should be a multiple of 4. 1534 Consequently, the following check should be performed: 1536 RR.Pointer % 4 == 0 1538 When a system receives an IP packet with the Record Route option, it 1539 should check whether there is space in the option to store route 1540 information. The option is full if: 1542 RR.Pointer > RR.Length 1544 If the option is full, the datagram should be forwarded without 1545 further processing of this option. If not, the following check 1546 should be performed before writing any route data into the option: 1548 RR.Pointer - RR.Length >= 3 1550 If the packet does not pass this check, the packet should be 1551 considered in error, and therefore should be silently dropped. 1553 If the option is not full (i.e., RR.Pointer <= RR.Length), but 1554 RR.Pointer - RR.Length < 4, it means that while there's space in the 1555 option, there is not not enough space to store an IP address. It is 1556 fair to assume that such an scenario will only occur when the packet 1557 has been crafted. 1559 If the packet passes this check, the IP address of the interface that 1560 will be used to forward this datagram should be recorded into the 1561 area pointed by the RR.Pointer, and RR.Pointer should then be 1562 incremented by 4. 1564 This option is not copied on fragmentation, and thus appears in the 1565 first fragment only. If a fragment other than the one with offset 0 1566 contains the Record Route option, it should be dropped. 1568 3.13.2.6. Stream Identifier (Type = 136) 1570 The Stream Identifier option originally provided a means for the 16- 1571 bit SATNET stream Identifier to be carried through networks that did 1572 not support the stream concept. 1574 However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this 1575 option is obsolete. Therefore, it should be ignored by the 1576 processing systems. 1578 In the case of legacy systems still using this option, the length 1579 field of the option should be checked to be 4. If the option does 1580 not pass this check, it should be dropped. 1582 RFC 791 states that this option appears at most once in a given 1583 datagram. Therefore, if a packet contains more than one instance of 1584 this option, it should be dropped. 1586 3.13.2.7. Internet Timestamp (Type = 68) 1588 This option provides a means for recording the time at which each 1589 system processed this datagram. The timestamp option has a number of 1590 security implications. Among them are: 1592 o It allows an attacker to obtain the current time of the systems 1593 that process the packet, which the attacker may find useful in a 1594 number of scenarios. 1596 o It may be used to map the network topology, in a similar way to 1597 the IP Record Route option. 1599 o It may be used to fingerprint the operating system in use by a 1600 system processing the datagram. 1602 o It may be used to fingerprint physical devices, by analyzing the 1603 clock skew. 1605 Therefore, by default, the timestamp option should be ignored. 1607 For those systems that have been explicitly configured to honor this 1608 option, the rest of this subsection describes some sanity checks that 1609 should be enforced on the option before further processing. 1611 The option begins with an option-type byte, which must be equal to 1612 68. The second byte is the option-length, which includes the option- 1613 type byte, the option-length byte, the pointer, and the overflow/flag 1614 byte. The minimum legal value for the option-length byte is 4, which 1615 corresponds to an Internet Timestamp option that is empty (no space 1616 to store timestamps). Therefore, upon receipt of a packet that 1617 contains an Internet Timestamp option, the following check should be 1618 performed: 1620 IT.Length >= 4 1622 If the packet does not pass this check, it should be dropped. 1624 Additionally, the following check should be performed on the option 1625 length field: 1627 IT.Offset + IT.Length < IHL *4 1629 This check assures that the option does not overlap with the IP 1630 payload (i.e., it does not go past the IP header). If the packet 1631 does not pass this check, it should be dropped. 1633 The pointer byte points to the first byte of the area in which the 1634 next timestamp data should be stored. As its value is relative to 1635 the beginning of the option, its minimum legal value is 5. 1636 Consequently, the following check should be performed on a packet 1637 that contains the Internet Timestamp option: 1639 IT.Pointer >= 5 1641 If the packet does not pass this check, it should be dropped. 1643 The flag field has three possible legal values: 1645 o 0: Record time stamps only, stored in consecutive 32-bit words. 1647 o 1: Record each timestamp preceded with the internet address of the 1648 registering entity. 1650 o 3: The internet address fields of the option are pre-specified. 1651 An IP module only registers its timestamp if it matches its own 1652 address with the next specified internet address. 1654 Therefore the following check should be performed: 1656 IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 1658 If the packet does not pass this check, it should be dropped. 1660 The timestamp field is a right-justified 32-bit timestamp in 1661 milliseconds since UT. If the time is not available in milliseconds, 1662 or cannot be provided with respect to UT, then any time may be 1663 inserted as a timestamp, provided the high order bit of the timestamp 1664 is set, to indicate this non-standard value. 1666 According to RFC 791, the initial contents of the timestamp area must 1667 be initialized to zero, or internet address/zero pairs. However, 1668 internet systems should be able to handle non-zero values, possibly 1669 discarding the offending datagram. 1671 When an internet system receives a packet with an Internet Timestamp 1672 option, it decides whether it should record its timestamp in the 1673 option. If it determines that it should, it should then determine 1674 whether the timestamp data area is full, by means of the following 1675 check: 1677 IT.Pointer > IT.Length 1679 If this condition is true, the timestamp data area is full. If not, 1680 there is room in the timestamp data area. 1682 If the timestamp data area is full, the overflow byte should be 1683 incremented, and the packet should be forwarded without inserting the 1684 timestamp. If the overflow byte itself overflows, the packet should 1685 be dropped. 1687 If timestamp data area is not full, then further checks should be 1688 performed before actually inserting any data. 1690 If the IT.Flag byte is 0, the following check should be performed: 1692 IT.Length - IT.Pointer >= 3 1694 If the packet does not pass this check, it should be dropped. If the 1695 packet passes this check, there is room for at least one 32-bit 1696 timestamp. The system's 32-bit timestamp should be inserted at the 1697 area pointed by the pointer byte, and the pointer byte should be 1698 incremented by four. 1700 If the IT.Flag byte is 1, then the following check should be 1701 performed: 1703 IT.Length - IT.Pointer >= 7 1705 If the packet does not pass this check, it should be dropped. If the 1706 packet does pass this check, it means there is space in the timestamp 1707 data area to store at least one IP address plus the corresponding 32- 1708 bit timestamp. The IP address of the system should be stored at the 1709 area pointed to by the pointer byte, followed by the 32-bit system 1710 timestamp. The pointer byte should then be incremented by 8. 1712 If the flag byte is 3, then the following check should be performed: 1714 IT.Length - IT.Pointer >= 7 1716 If the packet does not pass this check, it should be dropped. If it 1717 does, it means there is space in the timestamp data area to store an 1718 IP address and store the corresponding 32-bit timestamp. The 1719 system's timestamp should be stored at the area pointed by IT.Pointer 1720 + 4. Then, the pointer byte should be incremented by 8. 1722 [Kohno2005] describes a technique for fingerprinting devices by 1723 measuring the clock skew. It exploits, among other things, the 1724 timestamps that can be obtained by means of the ICMP timestamp 1725 request messages [RFC0791]. However, the same fingerprinting method 1726 could be implemented with the aid of the Internet Timestamp option. 1728 3.13.2.8. Router Alert (Type = 148) 1730 The Router Alert option is defined in RFC 2113 [RFC2113]. It has the 1731 semantic "routers should examine this packet more closely". A packet 1732 that contains a Router Alert option will not go through the router's 1733 fast-path and will be processed in the router more slowly than if the 1734 option were not set. Therefore, this option may impact the 1735 performance of the systems that handle the packet carrying it. 1737 According to the syntax of the option as defined in RFC 2113, the 1738 following check should be enforced: 1740 RA.Length == 4 1742 If the packet does not pass this check, it should be dropped. 1743 Furthermore, the following check should be performed on the Value 1744 field: 1746 RA.Value == 0 1748 If the packet does not pass this check, it should be dropped. 1750 As explained in RFC 2113, hosts should ignore this option. 1752 3.13.2.9. Probe MTU (Type =11) 1754 This option is defined in RFC 1063 [RFC1063], and originally provided 1755 a mechanism to discover the Path-MTU. 1757 This option is obsolete, and therefore any packet that is received 1758 containing this option should be dropped. 1760 3.13.2.10. Reply MTU (Type = 12) 1762 This option is defined in RFC 1063 [RFC1063], and originally provided 1763 a mechanism to discover the Path-MTU. 1765 This option is obsolete, and therefore any packet that is received 1766 containing this option should be dropped. 1768 3.13.2.11. Traceroute (Type = 82) 1770 This option is defined in RFC 1393 [RFC1393], and originally provided 1771 a mechanism to trace the path to a host. 1773 This option is obsolete, and therefore any packet that is received 1774 containing this option should be dropped. 1776 3.13.2.12. DoD Basic Security Option (Type = 130) 1778 This option is used by end-systems and intermediate systems of an 1779 internet to [RFC1108]: 1781 o Transmit from source to destination in a network standard 1782 representation the common security labels required by computer 1783 security models, 1785 o Validate the datagram as appropriate for transmission from the 1786 source and delivery to the destination, and, 1788 o Ensure that the route taken by the datagram is protected to the 1789 level required by all protection authorities indicated on the 1790 datagram. 1792 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 1793 [RFC1038]). 1795 RFC 791 [RFC0791] defined the "Security Option" (Type = 130), which 1796 used the same option type as the DoD Basic Security option discussed 1797 in this section. The "Security Option" specified in RFC 791 is 1798 considered obsolete by Section 4.2.2.1 of RFC 1812, and therefore the 1799 discussion in this section is focused on the DoD Basic Security 1800 option specified by RFC 1108 [RFC1108]. 1802 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 1803 this option". 1805 The DoD Basic Security Option is currently implemented in a number of 1806 operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], 1807 and [Cisco2008]), and deployed in a number of high-security networks. 1809 RFC 1108 states that the option should appear at most once in a 1810 datagram. Therefore, if more than one DoD Basic Security option 1811 (BSO) appears in a given datagram, the corresponding datagram should 1812 be dropped. 1814 RFC 1108 states that the option Length is variable, with a minimum 1815 option Length of 3 bytes. Therefore, the following check should be 1816 performed: 1818 BSO.Length >= 3 1820 If the packet does not pass this check, it should be dropped. 1822 Systems that belong to networks in which this option is in use should 1823 process the DoD Basic Security option contained in each packet as 1824 specified in [RFC1108]. 1826 Current deployments of the DoD Security Options have motivated the 1827 proposal of a "Common Architecture Label IPv6 Security Option 1828 (CALIPSO)" for the IPv6 protocol. [RFC1038]. 1830 3.13.2.13. DoD Extended Security Option (Type = 133) 1832 This option permits additional security labeling information, beyond 1833 that present in the Basic Security Option (Section 3.13.2.12), to be 1834 supplied in an IP datagram to meet the needs of registered 1835 authorities. It is specified by RFC 1108 [RFC1108]. 1837 This option may be present only in conjunction with the DoD Basic 1838 Security option. Therefore, if a packet contains a DoD Extended 1839 Security option (ESO), but does not contain a DoD Basic Security 1840 option, it should be dropped. It should be noted that, unlike the 1841 DoD Basic Security option, this option may appear multiple times in a 1842 single IP header. 1844 RFC 1108 states that the option Length is variable, with a minimum 1845 option Length of 3 bytes. Therefore, the following check should be 1846 performed: 1848 ESO.Length >= 3 1850 If the packet does not pass this check, it should be dropped. 1852 Systems that belong to networks in which this option is in use, 1853 should process the DoD Extended Security option contained in each 1854 packet as specified in RFC 1108 [RFC1108]. 1856 3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 134) 1858 This option was proposed by the Trusted Systems Interoperability 1859 Group (TSIG), with the intent of meeting trusted networking 1860 requirements for the commercial trusted systems market place. It is 1861 specified in [CIPSO1992] and [FIPS1994]. 1863 The TSIG proposal was taken to the Commercial Internet Security 1864 Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an 1865 Internet-Draft was produced [CIPSO1992]. The Internet-Draft was 1866 never published as an RFC, and the proposal was later standardized by 1867 the U.S. National Institute of Standards and Technology (NIST) as 1868 "Federal Information Processing Standard Publication 188" [FIPS1994]. 1870 It is currently implemented in a number of operating systems (e.g., 1871 IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris 1872 [Solaris2008]), and deployed in a number of high-security networks. 1874 [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux 1875 implementation. 1877 According to the option syntax specified in [CIPSO1992] the following 1878 validation check should be performed: 1880 CIPSO.Length >= 6 1882 If a packet does not pass this check, it should be dropped. 1884 Systems that belong to networks in which this option is in use should 1885 process the CIPSO option contained in each packet as specified in 1886 [CIPSO1992]. 1888 3.13.2.15. Sender Directed Multi-Destination Delivery (Type = 149) 1890 This option is defined in RFC 1770 [RFC1770], and originally provided 1891 unreliable UDP delivery to a set of addresses included in the option. 1893 This option is obsolete. If a received packet contains this option, 1894 it should be dropped. 1896 3.14. Differentiated Services field 1898 The Differentiated Services Architecture is intended to enable 1899 scalable service discrimination in the Internet without the need for 1900 per-flow state and signaling at every hop [RFC2475]. RFC 2474 1902 [RFC2474] defines a Differentiated Services Field (DS Field), which 1903 is intended to supersede the original Type of Service field. Figure 1904 5 shows the format of the field. 1906 0 1 2 3 4 5 6 7 1907 +---+---+---+---+---+---+---+---+ 1908 | DSCP | CU | 1909 +---+---+---+---+---+---+---+---+ 1911 Figure 5: Structure of the DS Field 1913 The DSCP ("Differentiated Services CodePoint").is used to select the 1914 treatment the packet is to receive within the Differentiated Services 1915 Domain. The CU ("Currently Unused") field was, at the time the 1916 specification was issued, reserved for future use. The DSCP field is 1917 used to select a PHB, by matching against the entire 6-bit field. 1919 Considering that the DSCP field determines how a packet is treated 1920 within a DS domain, an attacker send packets with a forged DSCP field 1921 to perform a theft of service or even a Denial of Service attack. In 1922 particular, an attacker could forge packets with a codepoint of the 1923 type '11x000' which, according to Section 4.2.2.2 of RFC 2474 1924 [RFC2474], would give the packets preferential forwarding treatment 1925 when compared with the PHB selected by the codepoint '000000'. If 1926 strict priority queuing were utilized, a continuous stream of such 1927 pockets could perform a Denial of Service to other flows which have a 1928 DSCP of lower relative order. 1930 As the DS field is incompatible with the original Type of Service 1931 field, both DS domains and networks using the original Type of 1932 Service field should protect themselves by remarking the 1933 corresponding field where appropriate, probably deploying remarking 1934 boundary nodes. Nevertheless, care must be taken so that packets 1935 received with an unrecognized DSCP do not cause the handling system 1936 to malfunction. 1938 3.15. Explicit Congestion Notification (ECN) 1940 RFC 3168 [RFC3168] specifies a mechanism for routers to signal 1941 congestion to hosts sending IP packets, by marking the offending 1942 packets, rather than discarding them. RFC 3168 defines the ECN 1943 field, which utilizes the CU unused field of the DSCP field described 1944 in Section 3.14 of this document. Figure 6 shows the syntax of the 1945 ECN field, together with the DSCP field used for Differentiated 1946 Services. 1948 0 1 2 3 4 5 6 7 1949 +-----+-----+-----+-----+-----+-----+-----+-----+ 1950 | DS FIELD, DSCP | ECN FIELD | 1951 +-----+-----+-----+-----+-----+-----+-----+-----+ 1953 Figure 6: The Differentiated Services and ECN fields in IP 1955 As such, the ECN field defines four codepoints: 1957 +-----------+-----------+ 1958 | ECN field | Codepoint | 1959 +-----------+-----------+ 1960 | 00 | Not-ECT | 1961 +-----------+-----------+ 1962 | 01 | ECT(1) | 1963 +-----------+-----------+ 1964 | 10 | ECT(0) | 1965 +-----------+-----------+ 1966 | 11 | CE | 1967 +-----------+-----------+ 1969 Table 3: ECN codepoints 1971 The security implications of ECN are discussed in detail in a number 1972 of Sections of RFC 3168. Of the possible threats discussed in the 1973 ECN specification, we believe that one that can be easily exploited 1974 is that of host falsely indicating ECN-Capability. 1976 An attacker could set the ECT codepoint in the packets it sends, to 1977 signal the network that the endpoints of the transport protocol are 1978 ECN-capable. Consequently, when experiencing moderate congestion, 1979 routers using active queue management based on RED would mark the 1980 packets (with the CE codepoint) rather than discard them. In the 1981 same scenario, packets of competing flows that do not have the ECT 1982 codepoint set would be dropped. Therefore, an attacker would get 1983 better network service than the competing flows. 1985 However, if this moderate congestion turned into heavy congestion, 1986 routers should switch to drop packets, regardless of whether the 1987 packets have the ECT codepoint set or not. 1989 A number of other threats could arise if an attacker was a man in the 1990 middle (i.e., was in the middle of the path the packets travel to get 1991 to the destination host). For a detailed discussion of those cases, 1992 we urge the reader to consult Section 16 of RFC 3168. 1994 4. Internet Protocol Mechanisms 1996 4.1. Fragment reassembly 1998 To accommodate networks with different Maximum Transmission Units 1999 (MTUs), the Internet Protocol provides a mechanism for the 2000 fragmentation of IP packets by end-systems (hosts) and/or 2001 intermediate systems (routers). Reassembly of fragments is performed 2002 only by the end-systems. 2004 [Cerf1974] provides the rationale for which packet reassembly is not 2005 performed by intermediate systems. 2007 During the last few decades, IP fragmentation and reassembly has been 2008 exploited in a number of ways, to perform actions such as evading 2009 Network Intrusion Detection Systems (NIDS), bypassing firewall rules, 2010 and performing Denial of Service (DoS) attacks. 2012 [Bendi1998] and [Humble1998] are examples of the exploitation of 2013 these issues for performing Denial of Service (DoS) attacks. 2014 [CERT1997] and [CERT1998b] document these issues. [Anderson2001] is 2015 a survey of fragmentation attacks. [US-CERT2001] is an example of 2016 the exploitation of IP fragmentation to bypass firewall rules. 2017 [CERT1999] describes the implementation of fragmentation attacks in 2018 Distributed Denial of Service (DDoS) attack tools. 2020 The problem with IP fragment reassembly basically has to do with the 2021 complexity of the function, in a number of aspects: 2023 o Fragment reassembly is a stateful operation for a stateless 2024 protocol (IP). The IP module at the host performing the 2025 reassembly function must allocate memory buffers both for 2026 temporarily storing the received fragments, and to perform the 2027 reassembly function. Attackers can exploit this fact to exhaust 2028 memory buffers at the system performing the fragment reassembly. 2030 o The fragmentation and reassembly mechanisms were designed at a 2031 time in which the available bandwidths were very different from 2032 the bandwidths available nowadays. With the current available 2033 bandwidths, a number of interoperability problems may arise. And 2034 these issues may be intentionally exploited by attackers to 2035 perform Denial of Service (DoS) attacks. 2037 o Fragment reassembly must usually be performed without any 2038 knowledge of the properties of the path the fragments follow. 2039 Without this information, hosts cannot make any educated guess on 2040 how long they should wait for missing fragments to arrive. 2042 o The fragment reassembly algorithm, as described by the IETF 2043 specifications, is ambiguous, and allows for a number of 2044 interpretations, each of which has found place in different TCP/IP 2045 stack implementations. 2047 o The reassembly process is somewhat complex. Fragments may arrive 2048 out of order, duplicated, overlapping each other, etc. This 2049 complexity has lead to numerous bugs in different implementations 2050 of the IP protocol. 2052 4.1.1. Problems related with memory allocation 2054 When an IP datagram is received by an end-system, it will be 2055 temporarily stored in system memory, until the IP module processes it 2056 and hands it to the protocol machine that corresponds to the 2057 encapsulated protocol. 2059 In the case of fragmented IP packets, while the IP module may perform 2060 preliminary processing of the IP header (such as checking the header 2061 for errors and processing IP options), fragments must be kept in 2062 system buffers until all fragments are received and are reassembled 2063 into a complete internet datagram. 2065 As mentioned above, the fact that the internet layer will not usually 2066 have information about the characteristics of the path between the 2067 system and the remote host, no educated guess can be made on the 2068 amount of time that should be waited for the other fragments to 2069 arrive. Therefore, the specifications recommend to wait for a period 2070 of time that will be acceptable for virtually all the possible 2071 network scenarios in which the protocols might operate. 2072 Specifically, RFC 1122 [RFC1122] states that the reassembly timeout 2073 should be a fixed value between 60 and 120 seconds. If after waiting 2074 for that period of time the remaining fragments have not yet arrived, 2075 all the received fragments for the corresponding packet are 2076 discarded. 2078 The original IP Specification, RFC 791 [RFC0791], states that systems 2079 should wait for at least 15 seconds for the missing fragments to 2080 arrive. Systems that follow the "Example Reassembly Procedure" 2081 described in Section 3.2 of RFC 791 may end up using a reassembly 2082 timer of up to 4.25 minutes, with minimum of 15 seconds. Section 2083 3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that 2084 the reassembly timeout should be a fixed value between 60 and 120 2085 seconds. 2087 However, the longer the system waits for the missing fragments to 2088 arrive, the longer the corresponding system resources must be tied to 2089 the corresponding packet. The amount of system memory is finite, and 2090 even with today's systems, it can still be considered a scarce 2091 resource. 2093 An attacker could take advantage of the uncomfortable situation the 2094 system performing fragment reassembly is in, by sending forged 2095 fragments that will never reassemble into a complete datagram. That 2096 is, an attacker would send many different fragments, with different 2097 IP IDs, without ever sending all the necessary fragments that would 2098 be needed to reassemble them into a full IP datagram. For each of 2099 the fragments, the IP module would allocate resources and tie them to 2100 the corresponding fragment, until any the reassembly timer for the 2101 corresponding packet expires. 2103 There are some implementation strategies which could increase the 2104 impact of this attack. For example, upon receipt of a fragment, some 2105 systems allocate a memory buffer that will be large enough to 2106 reassemble the whole datagram. While this might be beneficial in 2107 legitimate cases, this just amplifies the impact of the possible 2108 attacks, as a single small fragment could tie up memory buffers for 2109 the size of an extremely large (and unlikely) datagram. The 2110 implementation strategy suggested in RFC 815 [RFC0815] leads to such 2111 an implementation. 2113 The impact of the aforementioned attack may vary depending on some 2114 specific implementation details: 2116 o If the system does not enforce limits on the amount of memory that 2117 can be allocated by the IP module, then an attacker could tie all 2118 system memory to fragments, at which point the system would become 2119 unusable, probably crashing. 2121 o If the system enforces limits on the amount of memory that can be 2122 allocated by the IP module as a whole, then, when this limit is 2123 reached, all further IP packets that arrive would be discarded, 2124 until some fragments time out and free memory is available again. 2126 o If the system enforces limits on the amount memory that can be 2127 allocated for the reassembly of fragments (in addition to 2128 enforcing a limit for the IP module as a whole), then, when this 2129 limit is reached, all further fragments that arrive would be 2130 discarded, until some fragment(s) time out and free memory is 2131 available again. 2133 4.1.2. Problems that arise from the length of the IP Identification 2134 field 2136 The Internet Protocols are currently being used in environments that 2137 are quite different from the ones in which they were conceived. For 2138 instance, the availability of bandwidth at the time the Internet 2139 Protocol was designed was completely different from the availability 2140 of bandwidth in today's networks. 2142 The Identification field is a 16-bit field that is used for the 2143 fragmentation and reassembly function. In the event a datagram gets 2144 fragmented, all the corresponding fragments will share the same 2145 Identification number. Thus, the system receiving the fragments will 2146 be able to uniquely identify them as fragments that correspond to the 2147 same IP datagram. At a given point in time, there must be at most 2148 only one packet in the network with a given Identification number. 2149 If not, an Identification number "collision" might occur, and the 2150 receiving system might end up "mixing" fragments that correspond to 2151 different IP datagrams which simply reused the same Identification 2152 number. 2154 For each group of fragments whose Identification numbers "collide", 2155 the fragment reassembly will lead to corrupted packets. The IP 2156 payload of the reassembled datagram will be handed to the 2157 corresponding upper layer protocol, where the error will (hopefully) 2158 be detected by some error detecting code (such as the TCP checksum) 2159 and the packet will be discarded. 2161 An attacker could exploit this fact to intentionally cause a system 2162 to discard all or part of the fragmented traffic it gets, thus 2163 performing a Denial of Service attack. Such an attacker would simply 2164 establish a flow of fragments with different IP Identification 2165 numbers, to trash all or part of the IP Identification space. As a 2166 result, the receiving system would use the attacker's fragments for 2167 the reassembly of legitimate datagrams, leading to corrupted packets 2168 which would later (and hopefully) get dropped. 2170 In most cases, use of a long fragment timeout will benefit the 2171 attacker, as forged fragments will keep the IP Identification space 2172 trashed for a longer period of time. 2174 4.1.3. Problems that arise from the complexity of the reassembly 2175 algorithm 2177 As IP packets can be duplicated by the network, and each packet may 2178 take a different path to get to the destination host, fragments may 2179 arrive not only out of order and/or duplicated, but also overlapping. 2180 This means that the reassembly process can be somewhat complex, with 2181 the corresponding implementation being not specifically trivial. 2183 [Shannon2001] analyzes the causes and attributes of fragment traffic 2184 measured in several types of WANs. 2186 During the years, a number of attacks have exploited bugs in the 2187 reassembly function of a number of operating systems, producing 2188 buffer overflows that have led, in most cases, to a crash of the 2189 attacked system. 2191 4.1.4. Problems that arise from the ambiguity of the reassembly process 2193 Network Intrusion Detection Systems (NIDSs) typically monitor the 2194 traffic on a given network with the intent of identifying traffic 2195 patterns that might indicate network intrusions. 2197 In the presence of IP fragments, in order to detect illegitimate 2198 activity at the transport or application layers (i.e., any protocol 2199 layer above the network layer), a NIDS must perform IP fragment 2200 reassembly. 2202 In order to correctly assess the traffic, the result of the 2203 reassembly function performed by the NIDS should be the same as that 2204 of the reassembly function performed by the intended recipient of the 2205 packets. 2207 However, a number of factors make the result of the reassembly 2208 process ambiguous: 2210 o The IETF specifications are ambiguous as to what should be done in 2211 the event overlapping fragments were received. Thus, in the 2212 presence of overlapping data, the system performing the reassembly 2213 function is free to either honor the first set of data received, 2214 the latest copy received, or any other copy received in between. 2216 o As the specifications do not enforce any specific fragment timeout 2217 value, different systems may choose different values for the 2218 fragment timeout. This means that given a set of fragments 2219 received at some specified time intervals, some systems will 2220 reassemble the fragments into a full datagram, while others may 2221 timeout the fragments and therefore drop them. 2223 o As mentioned before, as the fragment buffers get full, a Denial of 2224 Service (DoS) condition will occur unless some action is taken. 2225 Many systems flush part of the fragment buffers when some 2226 threshold is reached. Thus, depending on fragment load, timing 2227 issues, and flushing policy, a NIDS may get incorrect assumptions 2228 about how (and if) fragments are being reassembled by their 2229 intended recipient. 2231 As originally discussed by [Ptacek1998], these issues can be 2232 exploited by attackers to evade intrusion detection systems. 2234 There exist freely available tools to forcefully fragment IP 2235 datagrams so as to help evade Intrusion Detection Systems. Frag 2236 router [Song1999] is an example of such a tool; it allows an attacker 2237 to perform all the evasion techniques described in [Ptacek1998]. 2238 Ftester [Barisani2006] is a tool that helps to audit systems 2239 regarding fragmentation issues. 2241 4.1.5. Problems that arise from the size of the IP fragments 2243 One approach to fragment filtering involves keeping track of the 2244 results of applying filter rules to the first fragment (i.e., the 2245 fragment with a Fragment Offset of 0), and applying them to 2246 subsequent fragments of the same packet. The filtering module would 2247 maintain a list of packets indexed by the Source Address, Destination 2248 Address, Protocol, and Identification number. When the initial 2249 fragment is seen, if the MF bit is set, a list item would be 2250 allocated to hold the result of filter access checks. When packets 2251 with a non-zero Fragment Offset come in, look up the list element 2252 with a matching Source Address/Destination Address/Protocol/ 2253 Identification and apply the stored result (pass or block). When a 2254 fragment with a zero MF bit is seen, free the list element. 2255 Unfortunately, the rules of this type of packet filter can usually be 2256 bypassed. [RFC1858] describes the details of the involved technique. 2258 4.1.6. Possible security improvements 2260 Memory allocation for fragment reassembly 2262 A design choice usually has to be made as to how to allocate memory 2263 to reassemble the fragments of a given packet. There are basically 2264 two options: 2266 o Upon receipt of the first fragment, allocate a buffer that will be 2267 large enough to concatenate the payload of each fragment. 2269 o Upon receipt of the first fragment, create the first node of a 2270 linked list to which each of the following fragments will be 2271 linked. When all fragments have been received, copy the IP 2272 payload of each of the fragments (in the correct order) to a 2273 separate buffer that will be handed to the protocol being 2274 encapsulated in the IP payload. 2276 While the first of the choices might seem to be the most straight- 2277 forward, it implies that even when a single small fragment of a given 2278 packet is received, the amount of memory that will be allocated for 2279 that fragment will account for the size of the complete IP datagram, 2280 thus using more system resources than what is actually needed. 2282 Furthermore, the only situation in which the actual size of the whole 2283 datagram will be known is when the last fragment of the packet is 2284 received first, as that is the only packet from which the total size 2285 of the IP datagram can be asserted. Otherwise, memory should be 2286 allocated for largest possible packet size (65535 bytes). 2288 The IP module should also enforce a limit on the amount of memory 2289 that can be allocated for IP fragments, as well as a limit on the 2290 number of fragments that at any time will be allowed in the system. 2291 This will basically limit the resources spent on the reassembly 2292 process, and prevent an attacker from trashing the whole system 2293 memory. 2295 Furthermore, the IP module should keep a different buffer for IP 2296 fragments than for complete IP datagrams. This will basically 2297 separate the effects of fragment attacks on non-fragmented traffic. 2298 Most TCP/IP implementations, such as that in Linux and those in BSD- 2299 derived systems, already implement this. 2301 [Jones2002] contains an analysis about the amount of memory that may 2302 be needed for the fragment reassembly buffer depending on a number of 2303 network characteristics. 2305 Flushing the fragment buffer 2307 In the case of those attacks that aim to consume the memory buffers 2308 used for fragments, and those that aim to cause a collision of IP 2309 Identification numbers, there are a number of counter-measures that 2310 can be implemented. 2312 The IP module should enforce a limit on the amount of memory that can 2313 be allocated for IP fragments, as well as a limit on the number of 2314 fragments that at any time will be allowed in the system. This will 2315 basically limit the resources spent on the reassembly process, and 2316 prevent an attacker from trashing the whole system memory. 2318 Additionally, the IP module should keep a different buffer for IP 2319 fragments than for complete IP datagrams. This will basically 2320 separate the effects of fragment attacks on non-fragmented traffic. 2321 Most TCP/IP implementations, such as that in Linux and those in BSD- 2322 derived systems, already implement this. 2324 Even with these counter-measures in place, there is still the issue 2325 of what to do when the buffer used for IP fragments get full. 2326 Basically, if the fragment buffer is full, no instance of 2327 communication that relies on fragmentation will be able to progress. 2329 Unfortunately, there are not many options for reacting to this 2330 situation. If nothing is done, all the instances of communication 2331 that rely on fragmentation will experience a denial of service. 2332 Thus, the only thing that can be done is flush all or part of the 2333 fragment buffer, on the premise that legitimate traffic will be able 2334 to make use of the freed buffer space to allow communication flows to 2335 progress. 2337 There are a number of factors that should be taken into consideration 2338 when flushing the fragment buffer. First, if a fragment of a given 2339 packet (i.e., fragment with a given Identification number) is 2340 flushed, all the other fragments that correspond to the same datagram 2341 should be flushed. As in order for a packet to be reassembled all of 2342 its fragments must be received by the system performing the 2343 reassembly function, flushing only a subset of the fragments of a 2344 given packet would keep the corresponding buffers tied to fragments 2345 that would never reassemble into a complete datagram. Additionally, 2346 care must be taken so that, in the event that subsequent buffer 2347 flushes need to be performed, it is not always the same set of 2348 fragments that get dropped, as such a behavior would probably cause a 2349 selective Denial of Service (DoS) to the traffic flows to which that 2350 set of fragments belong. 2352 Many TCP/IP implementations define a threshold for the number of 2353 fragments that, when reached, triggers a fragment-buffer flush. Some 2354 systems flush 1/2 of the fragment buffer when the threshold is 2355 reached. As mentioned before, the idea of flushing the buffer is to 2356 create some free space in the fragment buffer, on the premise that 2357 this will allow for new and legitimate fragments to be processed by 2358 the IP module, thus letting communication survive the overwhelming 2359 situation. On the other hand, the idea of flushing a somewhat large 2360 portion of the buffer is to avoid flushing always the same set of 2361 packets. 2363 A more selective fragment buffer flushing strategy 2365 One of the difficulties in implementing counter-measures for the 2366 fragmentation attacks described in this document is that it is 2367 difficult to perform validation checks on the received fragments. 2368 For instance, the fragment on which validity checks could be 2369 performed, the first fragment, may be not the first fragment to 2370 arrive at the destination host. 2372 Fragments can not only arrive out of order because of packet 2373 reordering performed by the network, but also because the system (or 2374 systems) that fragmented the IP datagram may indeed transmit the 2375 fragments out of order. A notable example of this is the Linux 2376 TCP/IP stack, which transmits the fragments in reverse order. 2378 This means that we cannot enforce checks on the fragments for which 2379 we allocate reassembly resources, as the first fragment we receive 2380 for a given packet may be some other fragment than the first one (the 2381 one with an Fragment Offset of 0). 2383 However, at the point in which we decide to free some space in the 2384 fragment buffer, some refinements can be done to the flushing policy. 2385 The first thing we would like to do is to stop different types of 2386 traffic from interfering with each other. This means, in principle, 2387 that we do not want fragmented UDP traffic to interfere with 2388 fragmented TCP traffic. In order to implement this traffic 2389 separation for the different protocols, a different fragment buffer 2390 would be needed, in principle, for each of the 256 different 2391 protocols that can be encapsulated in an IP datagram. 2393 We believe a tradeoff is to implement two separate fragment buffers: 2394 one for IP datagrams that encapsulate IPsec packets, and another for 2395 the rest of the traffic. This basically means that traffic not 2396 protected by IPsec will not interfere with those flows of 2397 communication that are being protected by IPsec. 2399 The processing of each of these two different fragment buffers would 2400 be completely independent from each other. In the case of the IPsec 2401 fragment buffer, when the buffer needs to be flushed, the following 2402 refined policy could be applied: 2404 o First, for each packet for which the IPsec header has been 2405 received, check that the SPI field of the IPsec header corresponds 2406 to an existing IPsec Security Association (SA), and probably also 2407 check that the IPsec sequence number is valid. If the check 2408 fails, drop all the fragments that correspond to this packet. 2410 o Second, if the fragment buffer still needs to be flushed, drop all 2411 the fragments that correspond to packets for which the full IPsec 2412 header has not yet been received. The number of packets for which 2413 this flushing is performed depends on the amount of free space 2414 that needs to be created. 2416 o Third, if after flushing packets with invalid IPsec information 2417 (First step), and packets on which validation checks could not be 2418 performed (Second step), there is still not enough space in the 2419 fragment buffer, drop all the fragments that correspond to packets 2420 that passed the checks of the first step, until the necessary free 2421 space is created. 2423 The rationale behind this policy is that, at the point of flushing 2424 the fragment buffer, we prefer to keep those packets on which we 2425 could successfully perform a number of validation checks, over those 2426 packets on which those checks failed, or the checks could not even be 2427 performed. 2429 By checking both the IPsec SPI and the IPsec sequence number, it is 2430 virtually impossible for an attacker that is off-path to perform a 2431 Denial of Service attack to communication flows being protected by 2432 IPsec. 2434 Unfortunately, some TCP/IP stacks, when performing fragmentation, 2435 send the corresponding fragments in reverse order. In such cases, at 2436 the point of flushing the fragment buffer, legitimate fragments will 2437 receive the same treatment as the possible forged fragments. 2439 This refined flushing policy provides an increased level of 2440 protection against this type of resource exhaustion attack, while not 2441 making the situation of out-of-order IPsec-secured traffic worse than 2442 with the simplified flushing policy described in the previous 2443 section. 2445 Reducing the fragment timeout 2447 RFC 1122 [RFC1122] states that the reassembly timeout should be a 2448 fixed value between 60 and 120 seconds. The rationale behind these 2449 long timeout values is that they should accommodate any path 2450 characteristics, such as long-delay paths. However, it must be noted 2451 that this timer is really measuring inter-fragment delays, or, more 2452 specifically, fragment jitter. 2454 If all fragments take paths of similar characteristics, the inter- 2455 fragment delay will usually be, at most, a few seconds. 2456 Nevertheless, even if fragments take different paths of different 2457 characteristics, the recommended 60 to 120 seconds are, in practice, 2458 excessive. 2460 Some systems have already reduced the fragment timeout to 30 seconds 2461 [Linux2006]. The fragment timeout could probably be further reduced 2462 to approximately 15 seconds; although further research on this issue 2463 is necessary. 2465 It should be noted that in network scenarios of long-delay and high- 2466 bandwidth (usually referred to as "Long-Fat Networks"), using a long 2467 fragment timeout would likely increase the probability of collision 2468 of IP ID numbers. Therefore, in such scenarios it is mandatory to 2469 avoid the use of fragmentation with techniques such as PMTUD 2470 [RFC1191] or PLPMTUD [RFC4821]. 2472 Counter-measure for some IDS evasion techniques 2474 [Shankar2003] introduces a technique named "Active Mapping" that 2475 prevents evasion of a NIDS by acquiring sufficient knowledge about 2476 the network being monitored, to assess which packets will arrive at 2477 the intended recipient, and how they will be interpreted by it. 2478 [Novak2005] describes some techniques that are applied by the Snort 2479 NIDS to avoid evasion. 2481 Counter-measure for firewall-rules bypassing 2483 One of the classical techniques to bypass firewall rules involves 2484 sending packets in which the header of the encapsulated protocol is 2485 fragmented. Even when it would be legal (as far as the IETF 2486 specifications are concerned) to receive such a packets, the MTUs of 2487 the network technologies used in practice are not that small to 2488 require the header of the encapsulated protocol to be fragmented. 2489 Therefore, the system performing reassembly should drop all packets 2490 which fragment the upper-layer protocol header. The necessary 2491 information to perform this check could be stored by the IP module 2492 together with the rest of the upper-layer protocol information. 2494 Additionally, given that many middle-boxes such as firewalls create 2495 state according to the contents of the first fragment of a given 2496 packet, it is best that, in the event an end-system receives 2497 overlapping fragments, it honors the information contained in the 2498 fragment that was received first. 2500 RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass 2501 firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. 2503 4.2. Forwarding 2505 4.2.1. Precedence-ordered queue service 2507 Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should 2508 implement precedence-ordered queue service. This means that when a 2509 packet is selected for output on a (logical) link, the packet of 2510 highest precedence that as been queued for that link is sent. 2511 Section 5.3.3.2 of RFC 1812 advices routers to default to maintaining 2512 strict precedence-ordered service. 2514 Unfortunately, given that it is trivial to forge the IP precedence 2515 field of the IP header, an attacker could simply forge a high 2516 precedence number in the packets it sends, to illegitimately get 2517 better network service. If precedence-ordered queued service is not 2518 required in a particular network infrastructure, it should be 2519 disabled, and thus all packets would receive the same type of 2520 service, despite the values in their Type of Service or 2521 Differentiated Services fields. 2523 When Precedence-ordered queue service is required in the network 2524 infrastructure, in order to mitigate the attack vector discussed in 2525 the previous paragraph, edge routers or switches should be configured 2526 to police and remark the Type of Service or Differentiated Services 2527 values, according to the type of service at which each end-system has 2528 been allowed to send packets. 2530 Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT 2531 change precedence settings on packets it did not originate". 2532 However, given the security implications of the Precedence field, it 2533 is fair for routers, switches or other middle-boxes, particularly 2534 those in the network edge, to overwrite the Type of Service (or 2535 Differentiated Services) field of the packets they are forwarding, 2536 according to a configured network policy. 2538 Section 5.3.3.1 and Section 5.3.6 of RFC 1812 states that if 2539 precedence-ordered queue service is implemented and enabled, the 2540 router "MUST NOT discard a packet whose precedence is higher than 2541 that of a packet that is not discarded". While this recommendation 2542 makes sense given the semantics of the Precedence field, it is 2543 important to note that it would be simple for an attacker to send 2544 packets with forged high Precedence value to congest some internet 2545 router(s), and cause all (or most) traffic with a lower Precedence 2546 value to be discarded. 2548 4.2.2. Weak Type of Service 2550 Section 5.2.4.3 of RFC 1812 describes the algorithm for determining 2551 the next-hop address (i.e., the forwarding algorithm). Bullet 3, 2552 "Weak TOS", addresses the case in which routes contain a "type of 2553 service" attribute. It states that in case a packet contains a non- 2554 default TOS (i.e., 0000), only routes with the same TOS or with the 2555 default TOS should be considered for forwarding that packet. 2556 However, this means that among the longest match routes for a given 2557 in packet are routes with some TOS other than the one contained in 2558 the received packet, and no routes with the default TOS, the 2559 corresponding packet would be dropped. This may or may not be a 2560 desired behavior. 2562 An alternative to this would be to, in the case among the "longest 2563 match" routes there are only routes with non-default type of services 2564 which do not match the TOS contained in the received packet, to use a 2565 route with any other TOS. While this route would most likely not be 2566 able to address the type of service requested by packet, it would, at 2567 least, provide a "best effort" service. 2569 It must be noted that Section 5.3.2 of RFC 1812 allows for routers 2570 for not honoring the TOS field. Therefore, the proposed alternative 2571 behavior is still compliant with the IETF specifications. 2573 While officially specified in the RFC series, TOS-based routing is 2574 not widely deployed in the Internet. 2576 4.2.3. Address Resolution 2578 In the case of broadcast link-layer technologies, in order for a 2579 system to transfer an IP datagram it must usually first map an IP 2580 address to the corresponding link-layer address (for example, by 2581 means of the ARP protocol [RFC0826]) . This means that while this 2582 operation is being performed, the packets that would require such a 2583 mapping would need to be kept in memory. This may happen both in the 2584 case of hosts and in the case of routers. 2586 This situation might be exploited by an attacker, which could send a 2587 large amount of packets to a non-existent host which would supposedly 2588 be directly connected to the attacked router. While trying to map 2589 the corresponding IP address into a link-layer address, the attacked 2590 router would keep in memory all the packets that would need to make 2591 use of that link-layer address. At the point in which the mapping 2592 function times out, depending on the policy implemented by the 2593 attacked router, only the packet that triggered the call to the 2594 mapping function might be dropped. In that case, the same operation 2595 would be repeated for every packet destined to the non-existent host. 2596 Depending on the timeout value for the mapping function, this 2597 situation might lead to the router buffers to run out of free space, 2598 with the consequence that incoming legitimate packets would have to 2599 be dropped, or that legitimate packets already stored in the router's 2600 buffers might get dropped. Both of these situations would lead 2601 either to a complete Denial of Service, or to a degradation of the 2602 network service. 2604 One counter-measure to this problem would be to drop, at the point 2605 the mapping function times out all the packets destined to the 2606 address that timed out. In addition, a "negative cache entry" might 2607 be kept in the module performing the matching function, so that for 2608 some amount of time, the mapping function would return an error when 2609 the IP module requests to perform a mapping for some address for 2610 which the mapping has recently timed out. 2612 A common implementation strategy for routers is that when a packet is 2613 received that requires an ARP request to be performed before the 2614 packet can be forwarded, the packet is dropped and the router is then 2615 engaged in the ARP procedure. 2617 4.2.4. Dropping packets 2619 In some scenarios, it may be necessary for a host or router to drop 2620 packets from the output queue. In the event one of such packets 2621 happens to be an IP fragment, and there were other fragments of the 2622 same packet in the queue, those other fragments should also be 2623 dropped. The rationale for this policy is that it is nonsensical to 2624 spend system resources on those other fragments, because, as long as 2625 one fragment is missing, it will be impossible for the receiving 2626 system to reassemble them into a complete IP datagram. 2628 Some systems have been known to drop just a subset of fragments of a 2629 given datagram, leading to a denial of service condition, as only a 2630 subset of all the fragments of the packets were actually transferred 2631 to the next hop. 2633 4.3. Addressing 2635 4.3.1. Unreachable addresses 2637 It is important to understand that while there are some addresses 2638 that are supposed to be unreachable from the public Internet (such as 2639 those described in RFC 1918 [RFC1918], or the "loopback" address), 2640 there are a number of tricks an attacker can perform to reach those 2641 IP addresses that would otherwise be unreachable (e.g., exploit the 2642 LSRR or SSRR IP options). Therefore, when applicable, packet 2643 filtering should be performed at organizational network boundary to 2644 assure that those addresses will be unreachable. 2646 4.3.2. Private address space 2648 The Internet Assigned Numbers Authority (IANA) has reserved the 2649 following three blocks of the IP address space for private internets: 2651 o 10.0.0.0 - 10.255.255.255 (10/8 prefix) 2653 o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 2655 o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 2657 Use of these address blocks is described in RFC 1918 [RFC1918]. 2659 Where applicable, packet filtering should be performed at the 2660 organizational perimeter to assure that these addresses are not 2661 reachable from outside the enterprise network. 2663 4.3.3. Class D addresses (224/4 address block) 2665 The Class D addresses correspond to the 224/4 address block, and are 2666 used for Internet multicast. Therefore, if a packet is received with 2667 a Class D address as the Source Address, it should be dropped. 2668 Additionally, if an IP packet with a multicast Destination Address is 2669 received for a connection-oriented protocol (e.g., TCP), the packet 2670 should be dropped. 2672 4.3.4. Class E addresses (240/4 address block) 2674 The Class E addresses correspond to the 240/4 address block, and are 2675 currently reserved for experimental use. As a result, a number of 2676 implementations discard packets that contain a Class E address as the 2677 Source Address or Destination Address. 2679 However, there exists ongoing work to reclassify the Class E (240/4) 2680 address block as usable unicast address spaces [Fuller2008a] 2681 [I-D.fuller-240space] [I-D.wilson-class-e]. Therefore, we recommend 2682 implementations to accept addresses in the 240/4 block as valid 2683 addresses for the Source Address and Destination Address. 2685 It should be noted that the broadcast address 255.255.255.255 still 2686 must be treated as indicated in Section 4.3.7 of this document. 2688 4.3.5. Broadcast and multicast addresses, and connection-oriented 2689 protocols 2691 For connection-oriented protocols, such as TCP, shared state is 2692 maintained between only two endpoints at a time. Therefore, if an IP 2693 packet with a multicast (or broadcast) Destination Address is 2694 received for a connection-oriented protocol (e.g., TCP), the packet 2695 should be dropped. 2697 4.3.6. Broadcast and network addresses 2699 Originally, the IETF specifications did not permit IP addresses to 2700 have the value 0 or -1 for any of the Host number, network number, or 2701 subnet number fields, except for the cases indicated in Section 2702 4.3.7. However, this changed fundamentally with the deployment of 2703 Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a 2704 system cannot know a priori what the subnet mask is for a particular 2705 IP address. 2707 Many systems now allow administrators to use the values 0 or -1 for 2708 those fields. Despite that according to the IETF specifications 2709 these addresses are illegal, modern IP implementations should 2710 consider these addresses to be valid. 2712 4.3.7. Special Internet addresses 2714 RFC 1812 [RFC1812] discusses the use of some special internet 2715 addresses, which is of interest to perform some sanity checks on the 2716 Source Address and Destination Address fields of an IP packet. It 2717 uses the following notation for an IP address: 2719 { , } 2721 RFC 1122 [RFC1122] contained a similar discussion of special internet 2722 addresses, including some of the form { , , }. However, as explained in Section 4.2.2.11 2724 of RFC 1812, in a CIDR world, the subnet number is clearly an 2725 extension of the network prefix and cannot be interpreted without the 2726 remainder of the prefix. 2728 {0, 0} 2730 This address means "this host on this network". It is meant to be 2731 used only during the initialization procedure, by which the host 2732 learns its own IP address. 2734 If a packet is received with 0.0.0.0 as the Source Address for any 2735 purpose other than bootstrapping, the corresponding packet should be 2736 silently dropped. If a packet is received with 0.0.0.0 as the 2737 Destination Address, it should be silently dropped. 2739 {0, Host number} 2741 This address means "the specified host, in this network". As in the 2742 previous case, it is meant to be used only during the initialization 2743 procedure by which the host learns its own IP address. If a packet 2744 is received with such an address as the Source Address for any 2745 purpose other than bootstrapping, it should be dropped. If a packet 2746 is received with such an address as the Destination Address, it 2747 should be dropped. 2749 {-1, -1} 2751 This address is the local broadcast address. It should not be used 2752 as a source IP address. If a packet is received with 255.255.255.255 2753 as the Source Address, it should be dropped. 2755 Some systems, when receiving an ICMP echo request, for example, will 2756 use the Destination Address in the ICMP echo request packet as the 2757 Source Address of the response they send (in this case, an ICMP echo 2758 reply). Thus, when such systems receive a request sent to a 2759 broadcast address, the Source Address of the response will contain a 2760 broadcast address. This should be considered a bug, rather than a 2761 malicious use of the limited broadcast address. 2763 {Network number, -1} 2765 This is the directed broadcast to the specified network. As 2766 recommended by RFC 2644 [RFC2644], routers should not forward 2767 network-directed broadcasts. This avoids the corresponding network 2768 from being utilized as, for example, a "smurf amplifier" [CERT1998a]. 2770 As noted in Section 4.3.6 of this document, many systems now allow 2771 administrators to configure these addresses as unicast addresses for 2772 network interfaces. In such scenarios, routers should forward these 2773 addresses as if they were traditional unicast addresses. 2775 In some scenarios a host may have knowledge about a particular IP 2776 address being a network-directed broadcast address, rather than a 2777 unicast address (e.g., that IP address is configured on the local 2778 system as a "broadcast address"). In such scenarios, if a system can 2779 infer the Source Address of a received packet is a network-directed 2780 broadcast address, the packet should be dropped. 2782 As noted in Section 4.3.6 of this document, with the deployment of 2783 CIDR [RFC4632], it may be difficult for a system to infer whether a 2784 particular IP address is a broadcast address. 2786 {127, any} 2788 This is the internal host loopback address. Any packet that arrives 2789 on any physical interface containing this address as the Source 2790 Address, the Destination Address, or as part of a source route 2791 (either LSRR or SSRR), should be dropped. 2793 For example, packets with a Destination Address in the 127.0.0.0/8 2794 address block that are received on an interface other than loopback 2795 should be silently dropped. Packets received on any interface other 2796 than loopback with a Source Address corresponding to the system 2797 receiving the packet should also be dropped. 2799 5. Security Considerations 2801 This document discusses the security implications of the Internet 2802 Protocol (IP), and discusses a number of implementation strategies 2803 that help to mitigate a number of vulnerabilities found in the 2804 protocol during the last 25 years or so. 2806 6. Acknowledgements 2808 The author would like to thank Randall Atkinson, John Day, Juan 2809 Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka 2810 Savola, and Christos Zoulas for providing valuable comments on 2811 earlier versions of this document. 2813 The author would like to thank Randall Atkinson and Roque Gagliano, 2814 who generously answered a number of questions. 2816 Finally, the author would like to thank CPNI (formerly NISCC) for 2817 their continued support. 2819 This document is heavily based on the "Security Assessment of the 2820 Internet Protocol" [CPNI2008] released by the UK Centre for the 2821 Protection of National Infrastructure (CPNI), available at: 2822 http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx . 2824 7. References 2826 7.1. Normative References 2828 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2829 September 1981. 2831 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2832 converting network protocol addresses to 48.bit Ethernet 2833 address for transmission on Ethernet hardware", STD 37, 2834 RFC 826, November 1982. 2836 [RFC1038] St. Johns, M., "Draft revised IP security option", 2837 RFC 1038, January 1988. 2839 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 2840 MTU discovery options", RFC 1063, July 1988. 2842 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 2844 [RFC1122] Braden, R., "Requirements for Internet Hosts - 2845 Communication Layers", STD 3, RFC 1122, October 1989. 2847 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2848 November 1990. 2850 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 2851 Suite", RFC 1349, July 1992. 2853 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 2854 January 1993. 2856 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 2857 Destination Delivery", RFC 1770, March 1995. 2859 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 2860 RFC 1812, June 1995. 2862 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 2863 February 1997. 2865 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2866 "Definition of the Differentiated Services Field (DS 2867 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2868 December 1998. 2870 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2871 and W. Weiss, "An Architecture for Differentiated 2872 Services", RFC 2475, December 1998. 2874 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 2875 in Routers", BCP 34, RFC 2644, August 1999. 2877 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2878 Discovery", RFC 4821, March 2007. 2880 7.2. Informative References 2882 [Anderson2001] 2883 Anderson, J., "An Analysis of Fragmentation Attacks", 2884 Available at: http://www.ouah.org/fragma.html , 2001. 2886 [Barisani2006] 2887 Barisani, A., "FTester - Firewall and IDS testing tool", 2888 Available at: http://dev.inversepath.com/trac/ftester , 2889 2001. 2891 [Bellovin1989] 2892 Bellovin, S., "Security Problems in the TCP/IP Protocol 2893 Suite", Computer Communication Review Vol. 19, No. 2, pp. 2894 32-48, 1989. 2896 [Bellovin2002] 2897 Bellovin, S., "A Technique for Counting NATted Hosts", 2898 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 2900 [Bendi1998] 2901 Bendi, "Boink exploit", http://www.insecure.org/sploits/ 2902 95.NT.fragmentation.bonk.html , 1998. 2904 [Biondi2007] 2905 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 2906 CanSecWest 2007 Security Conference http://www.secdev.org/ 2907 conf/IPv6_RH_security-csw07.pdf, 2007. 2909 [CERT1996a] 2910 CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- 2911 Service Attack", 2912 http://www.cert.org/advisories/CA-1996-01.html, 1996. 2914 [CERT1996b] 2915 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 2916 Spoofing Attacks", 2917 http://www.cert.org/advisories/CA-1996-21.html, 1996. 2919 [CERT1996c] 2920 CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack 2921 via ping", 2922 http://www.cert.org/advisories/CA-1996-26.html, 1996. 2924 [CERT1997] 2925 CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service 2926 Attacks", http://www.cert.org/advisories/CA-1997-28.html, 2927 1997. 2929 [CERT1998a] 2930 CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- 2931 Service Attacks", 2932 http://www.cert.org/advisories/CA-1998-01.html, 1998. 2934 [CERT1998b] 2935 CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain 2936 TCP/IP Implementations", 2937 http://www.cert.org/advisories/CA-1998-13.html, 1998. 2939 [CERT1999] 2940 CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 2941 http://www.cert.org/advisories/CA-1999-17.html, 1999. 2943 [CERT2001] 2944 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 2945 TCP/IP Initial Sequence Numbers", 2946 http://www.cert.org/advisories/CA-2001-09.html, 2001. 2948 [CERT2003] 2949 CERT, "CERT Advisory CA-2003-15 Cisco IOS Interface 2950 Blocked by IPv4 Packet", 2951 http://www.cert.org/advisories/CA-2003-15.html, 2003. 2953 [CIPSO1992] 2954 CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF 2955 Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work 2956 in progress , 1992. 2958 [CIPSOWG1994] 2959 CIPSOWG, "Commercial Internet Protocol Security Option 2960 (CIPSO) Working Group", http://www.ietf.org/proceedings/ 2961 94jul/charters/cipso-charter.html, 1994. 2963 [CPNI2008] 2964 Gont, F., "Security Assessment of the Internet Protocol", 2965 http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. 2967 [Cerf1974] 2968 Cerf, V. and R. Kahn, "A Protocol for Packet Network 2969 Intercommunication", IEEE Transactions on 2970 Communications Vol. 22, No. 5, May 1974, pp. 637-648, 2971 1974. 2973 [Cisco2003] 2974 Cisco, "Cisco Security Advisory: Cisco IOS Interface 2975 Blocked by IPv4 packet", http://www.cisco.com/en/US/ 2976 products/products_security_advisory09186a00801a34c2.shtml, 2977 2003. 2979 [Cisco2008] 2980 Cisco, "Cisco IOS Security Configuration Guide, Release 2981 12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/ 2982 configuration/guide/scfipso.html, 2003. 2984 [Clark1988] 2985 Clark, D., "The Design Philosophy of the DARPA Internet 2986 Protocols", Computer Communication Review Vol. 18, No. 4, 2987 1988. 2989 [Ed3f2002] 2990 Ed3f, "Firewall spotting and networks analisys with a 2991 broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, 2992 Phile #0x0c of 2993 0x10 http://www.phrack.org/phrack/60/p60-0x0c.txt, 2002. 2995 [FIPS1994] 2996 FIPS, "Standard Security Label for Information Transfer", 2997 Federal Information Processing Standards Publication. FIP 2998 PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ 2999 fips188.pdf, 1994. 3001 [Fuller2008a] 3002 Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The 3003 Future Begins Now", Routing SIG Meeting, 25th APNIC Open 3004 Policy Meeting, February 25 - 29 2008, Taipei, Taiwan http 3005 ://www.apnic.net/meetings/25/program/routing/ 3006 fuller-240-future.pdf, 2008. 3008 [Fyodor2004] 3009 Fyodor, "Idle scanning and related IP ID games", 3010 http://www.insecure.org/nmap/idlescan.html, 2004. 3012 [GIAC2000] 3013 GIAC, "Egress Filtering v 0.2", 3014 http://www.sans.org/y2k/egress.htm, 2000. 3016 [Gont2006] 3017 Gont, F., "Advanced ICMP packet filtering", 3018 http://www.gont.com.ar/papers/icmp-filtering.html, 2006. 3020 [Haddad2004] 3021 Haddad, I. and M. Zakrzewski, "Security Distribution for 3022 Linux Clusters", Linux 3023 Journal http://www.linuxjournal.com/article/6943, 2004. 3025 [Humble1998] 3026 Gont, F., "Nestea exploit", 3027 http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 3028 1998. 3030 [I-D.fuller-240space] 3031 Fuller, V., "Reclassifying 240/4 as usable unicast address 3032 space", draft-fuller-240space-02 (work in progress), 3033 March 2008. 3035 [I-D.ietf-tcpm-icmp-attacks] 3036 Gont, F., "ICMP attacks against TCP", 3037 draft-ietf-tcpm-icmp-attacks-03 (work in progress), 3038 March 2008. 3040 [I-D.stjohns-sipso] 3041 StJohns, M., "Common Architecture Label IPv6 Security 3042 Option (CALIPSO)", draft-stjohns-sipso-04 (work in 3043 progress), July 2008. 3045 [I-D.templin-mtuassurance] 3046 Templin, F., "Requirements for IP-in-IP Tunnel MTU 3047 Assurance", draft-templin-mtuassurance-02 (work in 3048 progress), October 2006. 3050 [I-D.wilson-class-e] 3051 Wilson, P., "Redesignation of 240/4 from "Future Use" to 3052 "Limited Use for Large Private Internets"", 3053 draft-wilson-class-e-01 (work in progress), August 2007. 3055 [IANA2006a] 3056 Ether Types, 3057 "http://www.iana.org/assignments/ethernet-numbers". 3059 [IANA2006b] 3060 IP Parameters, 3061 "http://www.iana.org/assignments/ip-parameters". 3063 [IANA2006c] 3064 Protocol Numbers, 3065 "http://www.iana.org/assignments/protocol-numbers". 3067 [IRIX2008] 3068 IRIX, "IRIX 6.5 trusted_networking(7) manual page", http: 3069 //techpubs.sgi.com/library/tpl/cgi-bin/ 3070 getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ 3071 cat7/trusted_networking.z, 2008. 3073 [Jones2002] 3074 Jones, R., "A Method Of Selecting Values For the 3075 Parameters Controlling IP Fragment Reassembly", ftp:// 3076 ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt, 3077 2002. 3079 [Kenney1996] 3080 Kenney, M., "The Ping of Death Page", 3081 http://www.insecure.org/sploits/ping-o-death.html, 1996. 3083 [Kent1987] 3084 Kent, C. and J. Mogul, "Fragmentation considered harmful", 3085 Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987. 3087 [Klein2007] 3088 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 3089 Predictable IP ID Vulnerability", http:// 3090 www.trusteer.com/files/ 3091 OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP 3092 _ID_Vulnerability.pdf, 2007. 3094 [Kohno2005] 3095 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 3096 Device Fingerprinting", IEEE Transactions on Dependable 3097 and Secure Computing Vol. 2, No. 2, 2005. 3099 [LBNL2006] 3100 LBNL/NRG, "arpwatch tool", http://ee.lbl.gov/, 2006. 3102 [Linux2006] 3103 The Linux Project, "http://www.kernel.org". 3105 [Microsoft1999] 3106 Microsoft, "Microsoft Security Program: Microsoft Security 3107 Bulletin (MS99-038). Patch Available for "Spoofed Route 3108 Pointer" Vulnerability", http://www.microsoft.com/ 3109 technet/security/bulletin/ms99-038.mspx, 1999. 3111 [NISCC2004] 3112 NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability 3113 Issues in TCP", 3114 http://www.uniras.gov.uk/niscc/docs/ 3115 re-20040420-00391.pdf, 2004. 3117 [NISCC2005] 3118 NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 3119 Vulnerability Issues in ICMP packets with TCP payloads", 3120 http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf, 3121 2005. 3123 [NISCC2006] 3124 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 3125 Filtering", http://www.niscc.gov.uk/niscc/docs/ 3126 re-20060420-00294.pdf?lang=en, 2006. 3128 [Northcutt2000] 3129 Northcut, S. and Novak, "Network Intrusion Detection - An 3130 Analyst's Handbook", Second Edition New Riders Publishing, 3131 2000. 3133 [Novak2005] 3134 Novak, "Target-Based Fragmentation Reassembly", 3135 http://www.snort.org/reg/docs/target_based_frag.pdf, 3136 2005. 3138 [OpenBSD1998] 3139 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 3140 Problem", 3141 http://www.openbsd.org/advisories/sourceroute.txt, 1998. 3143 [Paxson2001] 3144 Paxson, V., Handley, M., and C. Kreibich, "Network 3145 Intrusion Detection: Evasion, Traffic Normalization, and 3146 End-to-End Protocol Semantics", USENIX Conference, 2001, 3147 2001. 3149 [Ptacek1998] 3150 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 3151 of Service: Eluding Network Intrusion Detection", 3152 http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps, 3153 1998. 3155 [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, 3156 July 1982. 3158 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 3159 Considerations for IP Fragment Filtering", RFC 1858, 3160 October 1995. 3162 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3163 E. Lear, "Address Allocation for Private Internets", 3164 BCP 5, RFC 1918, February 1996. 3166 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3167 Defeating Denial of Service Attacks which employ IP Source 3168 Address Spoofing", BCP 38, RFC 2827, May 2000. 3170 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 3171 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 3173 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3174 of Explicit Congestion Notification (ECN) to IP", 3175 RFC 3168, September 2001. 3177 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 3178 Beame, C., Eisler, M., and D. Noveck, "Network File System 3179 (NFS) version 4 Protocol", RFC 3530, April 2003. 3181 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3182 Networks", BCP 84, RFC 3704, March 2004. 3184 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 3185 Network Tunneling", RFC 4459, April 2006. 3187 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3188 (CIDR): The Internet Address Assignment and Aggregation 3189 Plan", BCP 122, RFC 4632, August 2006. 3191 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3192 Errors at High Data Rates", RFC 4963, July 2007. 3194 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3195 Mitigations", RFC 4987, August 2007. 3197 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 3198 Pignataro, "The Generalized TTL Security Mechanism 3199 (GTSM)", RFC 5082, October 2007. 3201 [SELinux2008] 3202 Security Enhanced Linux, "http://www.nsa.gov/selinux/". 3204 [Sanfilippo1998a] 3205 Sanfilippo, S., "about the ip header id", Post to Bugtraq 3206 mailing-list, Mon Dec 14 3207 1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998. 3209 [Sanfilippo1998b] 3210 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing- 3211 list http://www.kyuzz.org/antirez/papers/dumbscan.html, 3212 1998. 3214 [Sanfilippo1999] 3215 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 3216 list http://www.kyuzz.org/antirez/papers/moreipid.html, 3217 1999. 3219 [Shankar2003] 3220 Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS 3221 EvasionWithout Altering Traffic", 3222 http://www.icir.org/vern/papers/activemap-oak03.pdf, 3223 2003. 3225 [Shannon2001] 3226 Shannon, C., Moore, D., and K. Claffy, "Characteristics of 3227 Fragmented IP Traffic on Internet Links", 2001. 3229 [Silbersack2005] 3230 Silbersack, M., "Improving TCP/IP security through 3231 randomization without sacrificing interoperability", 3232 EuroBSDCon 2005 Conference http://www.silby.com/ 3233 eurobsdcon05/eurobsdcon_slides.pdf, 2005. 3235 [Solaris2008] 3236 Solaris Trusted Extensions - Labeled Security for Absolute 3237 Protection, "http://www.sun.com/software/solaris/ds/ 3238 trusted_extensions.jsp#3", 2008. 3240 [Song1999] 3241 Song, D., "Frag router tool", 3242 http://www.anzen.com/research/nidsbench/. 3244 [US-CERT2001] 3245 US-CERT, "US-CERT Vulnerability Note VU#446689: Check 3246 Point FireWall-1 allows fragmented packets through 3247 firewall if Fast Mode is enabled", 3248 http://www.kb.cert.org/vuls/id/446689, 2001. 3250 [US-CERT2002] 3251 US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS 3252 discloses fragments of previous packets when Express 3253 Forwarding is enabled", 3254 http://www.kb.cert.org/vuls/id/310387, 2002. 3256 [Watson2004] 3257 Watson, P., "Slipping in the Window: TCP Reset Attacks", 3258 2004 CanSecWest Conference , 2004. 3260 [Zakrzewski2002] 3261 Zakrzewski, M. and I. Haddad, "Linux Distributed Security 3262 Module", http://www.linuxjournal.com/article/6215, 2002. 3264 [daemon91996] 3265 daemon9, route, and infinity, "IP-spoofing Demystified 3266 (Trust-Relationship Exploitation)", Phrack Magazine, 3267 Volume Seven, Issue Forty-Eight, File 14 of 3268 18 http://www.phrack.org/phrack/48/P48-14 , 1988. 3270 Appendix A. Advice and guidance to vendors 3272 Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they 3273 think they may be affected by the issues described in this document. 3274 As the lead coordination center for these issues, CPNI is well placed 3275 to give advice and guidance as required. 3277 CPNI works extensively with government departments and agencies, 3278 commercial organizations and the academic community to research 3279 vulnerabilities and potential threats to IT systems especially where 3280 they may have an impact on Critical National Infrastructure's (CNI). 3282 Other ways to contact CPNI, plus CPNI's PGP public key, are available 3283 at http://www.cpni.gov.uk . 3285 Author's Address 3287 Fernando Gont 3288 Consultant 3289 Evaristo Carriego 2644 3290 Haedo, Provincia de Buenos Aires 1706 3291 Argentina 3293 Phone: +54 11 4650 8472 3294 Email: fernando@gont.com.ar 3295 URI: http://www.gont.com.ar 3297 Full Copyright Statement 3299 Copyright (C) The IETF Trust (2008). 3301 This document is subject to the rights, licenses and restrictions 3302 contained in BCP 78, and except as set forth therein, the authors 3303 retain all their rights. 3305 This document and the information contained herein are provided on an 3306 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3307 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3308 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3309 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3310 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3311 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3313 Intellectual Property 3315 The IETF takes no position regarding the validity or scope of any 3316 Intellectual Property Rights or other rights that might be claimed to 3317 pertain to the implementation or use of the technology described in 3318 this document or the extent to which any license under such rights 3319 might or might not be available; nor does it represent that it has 3320 made any independent effort to identify any such rights. Information 3321 on the procedures with respect to rights in RFC documents can be 3322 found in BCP 78 and BCP 79. 3324 Copies of IPR disclosures made to the IETF Secretariat and any 3325 assurances of licenses to be made available, or the result of an 3326 attempt made to obtain a general license or permission for the use of 3327 such proprietary rights by implementers or users of this 3328 specification can be obtained from the IETF on-line IPR repository at 3329 http://www.ietf.org/ipr. 3331 The IETF invites any interested party to bring to its attention any 3332 copyrights, patents or patent applications, or other proprietary 3333 rights that may cover technology that may be required to implement 3334 this standard. Please address the information to the IETF at 3335 ietf-ipr@ietf.org.