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