idnits 2.17.1 draft-ietf-opsec-ip-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2010) is 5179 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3927' is defined on line 2961, but no explicit reference was found in the text == Unused Reference: 'CERT2001' is defined on line 3034, but no explicit reference was found in the text == Unused Reference: 'I-D.stjohns-sipso' is defined on line 3131, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-mtuassurance' is defined on line 3136, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 3258, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3265, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 3275, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 3282, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1038 (Obsoleted by RFC 1108) ** Obsolete normative reference: RFC 1063 (Obsoleted by RFC 1191) ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 1770 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-10 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 2 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) February 20, 2010 5 Internet-Draft 6 Intended status: Informational 7 Expires: August 24, 2010 9 Security Assessment of the Internet Protocol version 4 10 draft-ietf-opsec-ip-security-02.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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 24, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 63 1.3. Organization of this document . . . . . . . . . . . . . . 7 64 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 7 65 3. Internet Protocol header fields . . . . . . . . . . . . . . . 8 66 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 9 68 3.3. Differentiated Services field . . . . . . . . . . . . . . 10 69 3.4. Explicit Congestion Notification (ECN) . . . . . . . . . . 11 70 3.5. Total Length . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.6. Identification (ID) . . . . . . . . . . . . . . . . . . . 13 72 3.6.1. Some workarounds implemented by the industry . . . . . 14 73 3.6.2. Possible security improvements . . . . . . . . . . . . 14 74 3.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 3.8. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 18 76 3.9. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 19 77 3.9.1. Fingerprinting the operating system in use by the 78 source host . . . . . . . . . . . . . . . . . . . . . 20 79 3.9.2. Fingerprinting the physical device from which the 80 packets originate . . . . . . . . . . . . . . . . . . 20 81 3.9.3. Locating the source host in the network topology . . . 20 82 3.9.4. Evading Network Intrusion Detection Systems . . . . . 22 83 3.9.5. Improving the security of applications that make 84 use of the Internet Protocol (IP) . . . . . . . . . . 22 85 3.10. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 3.11. Header Checksum . . . . . . . . . . . . . . . . . . . . . 24 87 3.12. Source Address . . . . . . . . . . . . . . . . . . . . . . 24 88 3.13. Destination Address . . . . . . . . . . . . . . . . . . . 25 89 3.14. Options . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 3.14.1. General issues with IP options . . . . . . . . . . . . 26 91 3.14.1.1. Processing requirements . . . . . . . . . . . . . 26 92 3.14.1.2. Processing of the options by the upper layer 93 protocol . . . . . . . . . . . . . . . . . . . . 27 94 3.14.1.3. General sanity checks on IP options . . . . . . . 27 95 3.14.2. Issues with specific options . . . . . . . . . . . . . 29 96 3.14.2.1. End of Option List (Type = 0) . . . . . . . . . . 29 97 3.14.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 29 98 3.14.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 29 99 3.14.2.4. Strict Source and Record Route (SSRR) (Type = 100 137) . . . . . . . . . . . . . . . . . . . . . . 32 101 3.14.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34 102 3.14.2.6. Stream Identifier (Type = 136) . . . . . . . . . 36 103 3.14.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36 104 3.14.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39 105 3.14.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40 106 3.14.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40 107 3.14.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40 108 3.14.2.12. DoD Basic Security Option (Type = 130) . . . . . 41 109 3.14.2.13. DoD Extended Security Option (Type = 133) . . . . 42 110 3.14.2.14. Commercial IP Security Option (CIPSO) (Type = 111 134) . . . . . . . . . . . . . . . . . . . . . . 42 112 3.14.2.15. Sender Directed Multi-Destination Delivery 113 (Type = 149) . . . . . . . . . . . . . . . . . . 43 114 3.15. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 115 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 45 116 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 45 117 4.1.1. Security Implications of Fragment Reassembly . . . . . 46 118 4.1.1.1. Problems related with memory allocation . . . . . 46 119 4.1.1.2. Problems that arise from the length of the IP 120 Identification field . . . . . . . . . . . . . . 48 121 4.1.1.3. Problems that arise from the complexity of 122 the reassembly algorithm . . . . . . . . . . . . 48 123 4.1.1.4. Problems that arise from the ambiguity of the 124 reassembly process . . . . . . . . . . . . . . . 49 125 4.1.1.5. Problems that arise from the size of the IP 126 fragments . . . . . . . . . . . . . . . . . . . . 50 127 4.1.2. Possible security improvements . . . . . . . . . . . . 50 128 4.1.2.1. Memory allocation for fragment reassembly . . . . 50 129 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 51 130 4.1.2.3. A more selective fragment buffer flushing 131 strategy . . . . . . . . . . . . . . . . . . . . 52 132 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 54 133 4.1.2.5. Counter-measure for some IDS evasion 134 techniques . . . . . . . . . . . . . . . . . . . 55 135 4.1.2.6. Counter-measure for firewall-rules bypassing . . 55 136 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 55 137 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 55 138 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 56 139 4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 57 140 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 58 141 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 58 142 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 58 143 4.3.2. Private address space . . . . . . . . . . . . . . . . 58 144 4.3.3. Class D addresses (224/4 address block) . . . . . . . 59 145 4.3.4. Class E addresses (240/4 address block) . . . . . . . 59 146 4.3.5. Broadcast and multicast addresses, and 147 connection-oriented protocols . . . . . . . . . . . . 59 148 4.3.6. Broadcast and network addresses . . . . . . . . . . . 60 149 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 60 150 5. Security Considerations . . . . . . . . . . . . . . . . . . . 62 151 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 152 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 153 7.1. Normative References . . . . . . . . . . . . . . . . . . . 63 154 7.2. Informative References . . . . . . . . . . . . . . . . . . 64 155 Appendix A. Advice and guidance to vendors . . . . . . . . . . . 72 156 Appendix B. Changes from previous versions of the draft (to 157 be removed by the RFC Editor before publishing 158 this document as an RFC) . . . . . . . . . . . . . . 73 159 B.1. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 73 160 B.2. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 73 161 B.3. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73 162 B.4. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 73 163 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 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 it 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 in flaws in 187 some protocol implementations, affecting only a reduced number of 188 systems, while others were based in 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 counter-measures, and analyzes their respective 228 effectiveness. 230 This document is the result of an assessment the IETF specifications 231 of the Internet Protocol (IP), from a security point of view. 232 Possible threats were identified and, where possible, counter- 233 measures were proposed. Additionally, many implementation flaws that 234 have led to security vulnerabilities have been referenced in the hope 235 that future implementations will not incur the same problems. 236 Furthermore, this document does not limit itself to performing a 237 security assessment of the relevant IETF specifications, but also 238 provides an assessment of common implementation strategies found in 239 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 1.2. Scope of this document 261 While there are a number of protocols that affect the way in which IP 262 systems operate, this document focuses only on the specifications of 263 the Internet Protocol (IP). For example, routing and bootstrapping 264 protocols are considered out of the scope of this project. 266 The following IETF RFCs were selected for assessment as part of this 267 work: 269 o RFC 791, "Internet Protocol. DARPA Internet Program. Protocol 270 Specification" (51 pages). 272 o RFC 815, "IP datagram reassembly algorithms" (9 pages). 274 o RFC 1122, "Requirements for Internet Hosts -- Communication 275 Layers" (116 pages). 277 o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages). 279 o RFC 2474, "Definition of the Differentiated Services Field (DS 280 Field) in the IPv4 and IPv6 Headers" (20 pages). 282 o RFC 2475, "An Architecture for Differentiated Services" (36 283 pages). 285 o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) 286 to IP" (63 pages). 288 1.3. Organization of this document 290 This document is basically organized in two parts: "Internet Protocol 291 header fields" and "Internet Protocol mechanisms". The former 292 contains an analysis of each of the fields of the Internet Protocol 293 header, identifies their security implications, and discusses the 294 possible counter-measures. The latter contains an analysis of the 295 security implications of the mechanisms implemented by the Internet 296 Protocol. 298 2. The Internet Protocol 300 The Internet Protocol (IP) provides a basic data transfer function, 301 in the form of data blocks called "datagrams", from a source host to 302 a destination host, across the possible intervening networks. 303 Additionally, it provides some functions that are useful for the 304 interconnection of heterogeneous networks, such as fragmentation and 305 reassembly. 307 The "datagram" has a number of characteristics that makes it 308 convenient for interconnecting systems [Clark1988]: 310 o It eliminates the need of connection state within the network, 311 which improves the survivability characteristics of the network. 313 o It provides a basic service of data transport that can be used as 314 a building block for other transport services (reliable data 315 transport services, etc.). 317 o It represents the minimum network service assumption, which 318 enables IP to be run over virtually any network technology. 320 3. Internet Protocol header fields 322 The IETF specifications of the Internet Protocol define the syntax of 323 the protocol header, along with the semantics of each of its fields. 324 Figure 1 shows the format of an IP datagram. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Version| IHL |Type of Service| Total Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Identification |Flags| Fragment Offset | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Time to Live | Protocol | Header Checksum | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Source Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Destination Address | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Options | Padding | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 1: Internet Protocol header format 344 Even when the minimum IP header size is 20 bytes, an IP module might 345 be handed an (illegitimate) "datagram" of less than 20 bytes. 346 Therefore, before doing any processing of the IP header fields, the 347 following check should be performed by the IP module on the packets 348 handed by the link layer: 350 LinkLayer.PayloadSize >= 20 352 If the packet does not pass this check, it should be dropped, and 353 this event should be logged (e.g., a counter could be incremented 354 reflecting the packet drop). 356 The following subsections contain further sanity checks that should 357 be performed on IP packets. 359 3.1. Version 361 This is a 4-bit field that indicates the version of the Internet 362 Protocol (IP), and thus the syntax of the packet. For IPv4, this 363 field must be 4. 365 When a Link-Layer protocol de-multiplexes a packet to an internet 366 module, it does so based on a "Protocol Type" field in the data-link 367 packet header. 369 In theory, different versions of IP could coexist on a network by 370 using the same "Protocol Type" at the Link-layer, but a different 371 value in the Version field of the IP header. Thus, a single IP 372 module could handle all versions of the Internet Protocol, 373 differentiating them by means of this field. 375 However, in practice different versions of IP are identified by a 376 different "Protocol Type" number in the link-layer protocol header. 377 For example, IPv4 datagrams are encapsulated in Ethernet frames using 378 a "Protocol Type" field of 0x0800, while IPv6 datagrams are 379 encapsulated in Ethernet frames using a "Protocol Type" field of 380 0x86DD [IANA2006a]. 382 Therefore, if an IPv4 module receives a packet, the Version field 383 must be checked to be 4. If this check fails, the packet should be 384 silently dropped, and this event should be logged (e.g., a counter 385 could be incremented reflecting the packet drop). 387 3.2. IHL (Internet Header Length) 389 The IHL (Internet Header Length) indicates the length of the internet 390 header in 32-bit words (4 bytes). As the minimum datagram size is 20 391 bytes, the minimum legal value for this field is 5. Therefore, the 392 following check should be enforced: 394 IHL >= 5 396 If the packet does not pass this check, it should be dropped, and 397 this event should be logged (e.g., a counter could be incremented 398 reflecting the packet drop). 400 For obvious reasons, the Internet header cannot be larger than the 401 whole Internet datagram it is part of. Therefore, the following 402 check should be enforced: 404 IHL * 4 <= Total Length 406 If the packet does not pass this check, it should be dropped, and 407 this event should be logged (e.g., a counter could be incremented 408 reflecting the packet drop). 410 The above check allows for Internet datagrams with no data bytes in 411 the payload that, while nonsensical for virtually every protocol that 412 runs over IP, it is still legal. 414 3.3. Differentiated Services field 416 The Differentiated Services Architecture is intended to enable 417 scalable service discrimination in the Internet without the need for 418 per-flow state and signaling at every hop [RFC2475]. RFC 2474 419 [RFC2474] defines a Differentiated Services Field (DS Field), which 420 is intended to supersede the original Type of Service field. Figure 421 5 shows the format of the field. 423 0 1 2 3 4 5 6 7 424 +---+---+---+---+---+---+---+---+ 425 | DSCP | CU | 426 +---+---+---+---+---+---+---+---+ 428 Figure 2: Structure of the DS Field 430 The DSCP ("Differentiated Services CodePoint").is used to select the 431 treatment the packet is to receive within the Differentiated Services 432 Domain. The CU ("Currently Unused") field was, at the time the 433 specification was issued, reserved for future use. The DSCP field is 434 used to select a PHB, by matching against the entire 6-bit field. 436 Considering that the DSCP field determines how a packet is treated 437 within a DS domain, an attacker send packets with a forged DSCP field 438 to perform a theft of service or even a Denial of Service attack. In 439 particular, an attacker could forge packets with a codepoint of the 440 type '11x000' which, according to Section 4.2.2.2 of RFC 2474 441 [RFC2474], would give the packets preferential forwarding treatment 442 when compared with the PHB selected by the codepoint '000000'. If 443 strict priority queuing were utilized, a continuous stream of such 444 pockets could perform a Denial of Service to other flows which have a 445 DSCP of lower relative order. 447 As the DS field is incompatible with the original Type of Service 448 field, both DS domains and networks using the original Type of 449 Service field should protect themselves by remarking the 450 corresponding field where appropriate, probably deploying remarking 451 boundary nodes. Nevertheless, care must be taken so that packets 452 received with an unrecognized DSCP do not cause the handling system 453 to malfunction. 455 3.4. Explicit Congestion Notification (ECN) 457 RFC 3168 [RFC3168] specifies a mechanism for routers to signal 458 congestion to hosts sending IP packets, by marking the offending 459 packets, rather than discarding them. RFC 3168 defines the ECN 460 field, which utilizes the CU unused field of the DSCP field described 461 in Section 3.14 of this document. Figure 6 shows the syntax of the 462 ECN field, together with the DSCP field used for Differentiated 463 Services. 465 0 1 2 3 4 5 6 7 466 +-----+-----+-----+-----+-----+-----+-----+-----+ 467 | DS FIELD, DSCP | ECN FIELD | 468 +-----+-----+-----+-----+-----+-----+-----+-----+ 470 Figure 3: The Differentiated Services and ECN fields in IP 472 As such, the ECN field defines four codepoints: 474 +-----------+-----------+ 475 | ECN field | Codepoint | 476 +-----------+-----------+ 477 | 00 | Not-ECT | 478 +-----------+-----------+ 479 | 01 | ECT(1) | 480 +-----------+-----------+ 481 | 10 | ECT(0) | 482 +-----------+-----------+ 483 | 11 | CE | 484 +-----------+-----------+ 486 Table 1: ECN codepoints 488 The security implications of ECN are discussed in detail in a number 489 of Sections of RFC 3168. Of the possible threats discussed in the 490 ECN specification, we believe that one that can be easily exploited 491 is that of host falsely indicating ECN-Capability. 493 An attacker could set the ECT codepoint in the packets it sends, to 494 signal the network that the endpoints of the transport protocol are 495 ECN-capable. Consequently, when experiencing moderate congestion, 496 routers using active queue management based on RED would mark the 497 packets (with the CE codepoint) rather than discard them. In the 498 same scenario, packets of competing flows that do not have the ECT 499 codepoint set would be dropped. Therefore, an attacker would get 500 better network service than the competing flows. 502 However, if this moderate congestion turned into heavy congestion, 503 routers should switch to drop packets, regardless of whether the 504 packets have the ECT codepoint set or not. 506 A number of other threats could arise if an attacker was a man in the 507 middle (i.e., was in the middle of the path the packets travel to get 508 to the destination host). For a detailed discussion of those cases, 509 we urge the reader to consult Section 16 of RFC 3168. 511 3.5. Total Length 513 The Total Length field is the length of the datagram, measured in 514 bytes, including both the IP header and the IP payload. Being a 16- 515 bit field, it allows for datagrams of up to 65535 bytes. RFC 791 516 [RFC0791] states that all hosts should be prepared to receive 517 datagrams of up to 576 bytes (whether they arrive as a whole, or in 518 fragments). However, most modern implementations can reassemble 519 datagrams of at least 9 Kbytes. 521 Usually, a host will not send to a remote peer an IP datagram larger 522 than 576 bytes, unless it is explicitly signaled that the remote peer 523 is able to receive such "large" datagrams (for example, by means of 524 TCP's MSS option). However, systems should assume that they may be 525 sent datagrams larger than 576 bytes, regardless of whether they 526 signal their remote peers to do so or not. In fact, it is common for 527 NFS [RFC3530]implementations to send datagrams larger than 576 bytes, 528 even without explicit signaling that the destination system can 529 receive such "large" datagram. 531 o Additionally, see the discussion in Section 4.1 "Fragment 532 reassembly" regarding the possible packet sizes resulting from 533 fragment reassembly. 535 Implementations should be aware that the IP module could be handed a 536 packet larger than the value actually contained in the Total Length 537 field. Such a difference usually has to do with legitimate padding 538 bytes at the link-layer protocol, but it could also be the result of 539 malicious activity by an attacker. Furthermore, even when the 540 maximum length of an IP datagram is 65535 bytes, if the link-layer 541 technology in use allows for payloads larger than 65535 bytes, an 542 attacker could forge such a large link-layer packet, meaning it for 543 the IP module. If the IP module of the receiving system were not 544 prepared to handle such an oversized link-layer payload, an 545 unexpected failure might occur. Therefore, the memory buffer used by 546 the IP module to store the link-layer payload should be allocated 547 according to the payload size reported by the link-layer, rather than 548 according to the Total Length field of the IP packet it contains. 550 The IP module could also be handled a packet that is smaller than the 551 actual IP packet size claimed by the Total Length field. This could 552 be used, for example, to produce an information leakage. Therefore, 553 the following check should be performed: 555 LinkLayer.PayloadSize >= Total Length 557 If this check fails, the IP packet should be dropped, and this event 558 should be logged (e.g., a counter could be incremented reflecting the 559 packet drop). As the previous expression implies, the number of 560 bytes passed by the link-layer to the IP module should contain at 561 least as many bytes as claimed by the Total Length field of the IP 562 header. 564 o [US-CERT2002] is an example of the exploitation of a forged IP 565 Total Length field to produce an information leakage attack. 567 3.6. Identification (ID) 569 The Identification field is set by the sending host to aid in the 570 reassembly of fragmented datagrams. At any time, it needs to be 571 unique for each set of {Source Address, Destination Address, 572 Protocol}. 574 In many systems, the value used for this field is determined at the 575 IP layer, on a protocol-independent basis. Many of those systems 576 also simply increment the IP Identification field for each packet 577 they send. 579 This implementation strategy is inappropriate for a number of 580 reasons. First, if the Identification field is set on a protocol- 581 independent basis, it will wrap more often than necessary, and thus 582 the implementation will be more prone to the problems discussed in 583 [Kent1987] and [RFC4963]. 585 Additionally, this implementation strategy opens the door to an 586 information leakage that can be exploited to in a number of ways. 587 [Sanfilippo1998a] originally pointed out how this field could be 588 examined to determine the packet rate at which a given system is 589 transmitting information. Later, [Sanfilippo1998b] described how a 590 system with such an implementation can be used to perform a stealth 591 port scan to a third (victim) host. [Sanfilippo1999] explained how 592 to exploit this implementation strategy to uncover the rules of a 593 number of firewalls. [Bellovin2002] explains how the IP 594 Identification field can be exploited to count the number of systems 595 behind a NAT. [Fyodor2004] is an entire paper on most (if not all) 596 the ways to exploit the information provided by the Identification 597 field of the IP header. 599 3.6.1. Some workarounds implemented by the industry 601 As the IP Identification field is only used for the reassembly of 602 datagrams, some operating systems (such as Linux) decided to set this 603 field to 0 in all packets that have the DF bit set. This would, in 604 principle, avoid any type of information leakage. However, it was 605 detected that some non-RFC-compliant middle-boxes fragmented packets 606 even if they had the DF bit set. In such a scenario, all datagrams 607 originally sent with the DF bit set would all result in fragments 608 that would have an Identification field of 0, which would lead to 609 problems ("collision" of the Identification number) in the reassembly 610 process. 612 Linux (and Solaris) later set the IP Identification field on a per- 613 IP-address basis. This avoids some of the security implications of 614 the IP Identification field, but not all. For example, systems 615 behind a load balancer can still be counted. 617 3.6.2. Possible security improvements 619 Contrary to common wisdom, the IP Identification field does not need 620 to be system-wide unique for each packet, but has to be unique for 621 each {Source Address, Destination Address, Protocol} tuple. 623 o For instance, the TCP specification defines a generic send() 624 function which takes the IP ID as one of its arguments. 626 We provide an analysis of the possible security improvements that 627 could be implemented, based on whether the protocol using the 628 services of IP is connection-oriented or connection-less. 630 Connection-oriented protocols 632 To avoid the security implications of the information leakage 633 described above, a pseudo-random number generator (PRNG) could be 634 used to set the IP Identification field on a {Source Address, 635 Destination Address} basis (for each connection-oriented transport 636 protocol). 638 o [Klein2007] is a security advisory that describes a weakness in 639 the pseudo random number generator (PRNG) in use for the 640 generation of the IP Identification by a number of operating 641 systems. 643 While in theory a pseudo-random number generator could lead to 644 scenarios in which a given Identification number is used more than 645 once in the same time-span for datagrams that end up getting 646 fragmented (with the corresponding potential reassembly problems), in 647 practice this is unlikely to cause trouble. 649 By default, most implementations of connection-oriented protocols, 650 such as TCP, implement some mechanism for avoiding fragmentation 651 (such as the Path-MTU Discovery mechanism described in [RFC1191]). 652 Thus, fragmentation will only take place sporadically, when a non- 653 RFC-compliant middle-box is placed somewhere along the path that the 654 packets travel to get to the destination host. Once the sending 655 system is signaled by the middle-box that it should reduce the size 656 of the packets it sends, fragmentation would be avoided. Also, for 657 reassembly problems to arise, the same Identification field should be 658 reused very frequently, and either strong packet reordering or packet 659 loss should take place. 661 Nevertheless, regardless of what policy is used for selecting the 662 Identification field, with the current link speeds fragmentation is 663 already bad enough to rely on it. A mechanism for avoiding 664 fragmentation should be implemented, instead. 666 Connectionless protocols 668 Connectionless protocols usually have these characteristics: 670 o lack of flow-control mechanisms, 672 o lack of packet sequencing mechanisms, and, 674 o lack of reliability mechanisms (such as "timeout and retransmit"). 676 This basically means that the scenarios and/or applications for which 677 connection-less transport protocols are used assume that: 679 o Applications will be used in environments in which packet 680 reordering is very unlikely (such as Local Area Networks), as the 681 transport protocol itself does not provide data sequencing. 683 o The data transfer rates will be low enough that flow control will 684 be unnecessary. 686 o Packet loss is not important and probably also unlikely. 688 With these assumptions in mind, the Identification field could still 689 be set according to a pseudo-random number generator (PRNG). In the 690 event a given Identification number was reused while the first 691 instance of the same number is still on the network, the first IP 692 datagram would be reassembled before the fragments of the second IP 693 datagram get to their destination. 695 In the event this was not the case, the reassembly of fragments would 696 result in a corrupt datagram. While some existing work 697 [Silbersack2005] assumes that this error would be caught by some 698 upper-layer error detection code, the error detection code in 699 question (such as UDP's checksum) might be intended to detect single 700 bit errors, rather than data corruption arising from the replacement 701 of a complete data block (as is the case in corruption arising from 702 collision of IP Identification numbers). 704 o In the case of UDP, unfortunately some systems have been known to 705 not enable the UDP checksum by default. For most applications, 706 packets containing errors should be dropped. Probably the only 707 application that may benefit from disabling the checksum is 708 streaming media, to avoid dropping a complete sample for a single- 709 bit error. 711 In general, if IP Identification number collisions become an issue 712 for the application using the connection-less protocol, then use of a 713 different transport protocol (which hopefully avoids fragmentation) 714 should be considered. 716 It must be noted that an attacker could intentionally exploit 717 collisions of IP Identification numbers to perform a Denial of 718 Service attack, by sending forged fragments that would cause the 719 reassembly process to result in a corrupt datagram that would either 720 be dropped by the transport protocol, or would incorrectly be handed 721 to the corresponding application. This issue is discussed in detail 722 in section 4.1 ("Fragment Reassembly"). 724 3.7. Flags 726 The IP header contains 3 control bits, two of which are currently 727 used for the fragmentation and reassembly function. 729 As described by RFC 791, their meaning is: 731 Bit 0: reserved, must be zero 733 Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment 734 Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments 736 The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) 737 mechanism described in [RFC1191]. However, it can also be exploited 738 by an attacker to evade Network Intrusion Detection Systems. An 739 attacker could send a packet with the DF bit set to a system 740 monitored by a NIDS, and depending on the Path-MTU to the intended 741 recipient, the packet might be dropped by some intervening router 742 (because of being too big to be forwarded without fragmentation), 743 without the NIDS being aware of it. 745 (still to be added) 746 (See Figure 3 in Page 13 of the CPNI document) 748 Figure 4: NIDS evasion by means of the Internet Protocol DF bit 750 In Figure 3, an attacker sends a 17914-byte datagram meant to the 751 victim host in the same figure. The attacker's packet probably 752 contains an overlapping IP fragment or an overlapping TCP segment, 753 aiming at "confusing" the NIDS, as described in [Ptacek1998]. The 754 packet is screened by the NIDS sensor at the network perimeter, which 755 probably reassembles IP fragments and TCP segments for the purpose of 756 assessing the data transferred to and from the monitored systems. 757 However, as the attacker's packet should transit a link with an MTU 758 smaller than 17914 bytes (1500 bytes in this example), the router 759 that encounters that this packet cannot be forwarded without 760 fragmentation (Router B) discards the packet, and sends an ICMP 761 "fragmentation needed and DF bit set" error message to the source 762 host. In this scenario, the NIDS may remain unaware that the 763 screened packet never reached the intended destination, and thus get 764 an incorrect picture of the data being transferred to the monitored 765 systems. 767 o [Shankar2003] introduces a technique named "Active Mapping" that 768 prevents evasion of a NIDS by acquiring sufficient knowledge about 769 the network being monitored, to assess which packets will arrive 770 at the intended recipient, and how they will be interpreted by it. 772 Some firewalls are known to drop packets that have both the MF (More 773 Fragments) and the DF (Don't fragment) bits set. While in principle 774 such a packet might seem nonsensical, there are a number of reasons 775 for which non-malicious packets with these two bits set can be found 776 in a network. First, they may exist as the result of some middle-box 777 processing a packet that was too large to be forwarded without 778 fragmentation. Instead of simply dropping the corresponding packet 779 and sending an ICMP error message to the source host, some middle- 780 boxes fragment the packet (copying the DF bit to each fragment), and 781 also send an ICMP error message to the originating system. Second, 782 some systems (notably Linux) set both the MF and the DF bits to 783 implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should 784 be taken into account when configuring firewalls and/or tuning 785 Network Intrusion Detection Systems (NIDS). 787 3.8. Fragment Offset 789 The Fragment Offset is used for the fragmentation and reassembly of 790 IP datagrams. It indicates where in the original datagram the 791 fragment belongs, and is measured in units of eight bytes. As a 792 consequence, all fragments (except the last one), have to be aligned 793 on an 8-byte boundary. Therefore, if a packet has the MF flag set, 794 the following check should be enforced: 796 (Total Length - IHL * 4) % 8 == 0 798 If the packet does not pass this check, it should be dropped, and 799 this event should be logged (e.g., a counter could be incremented 800 reflecting the packet drop). 802 Given that Fragment Offset is a 13-bit field, it can hold a value of 803 up to 8191, which would correspond to an offset 65528 bytes within 804 the original (non-fragmented) datagram. As such, it is possible for 805 a fragment to implicitly claim to belong to a datagram larger than 806 65535 bytes (the maximum size for a legitimate IP datagram). Even 807 when the fragmentation mechanism would seem to allow fragments that 808 could reassemble into such large datagrams, the intent of the 809 specification is to allow for the transmission of datagrams of up to 810 65535 bytes. Therefore, if a given fragment would reassemble into a 811 datagram of more than 65535 bytes, the resulting datagram should be 812 dropped, and this event should be logged (e.g., a counter could be 813 incremented reflecting the packet drop). To detect such a case, the 814 following check should be enforced on all packets for which the 815 Fragment Offset contains a non-zero value: 817 Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535 819 In the worst-case scenario, the reassembled datagram could have a 820 size of up to 131043 bytes. 822 o Such a datagram would result when the first fragment has a 823 Fragment Offset of 0 and a Total Length of 65532, and the second 824 (and last) fragment has a Fragment Offset of 8189 (65512 bytes), 825 and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header 826 length of 20 bytes), the reassembled datagram would be 65532 + 827 (65535 - 20) = 131047 bytes. 829 Additionally, the IP module should implement all the necessary 830 measures to be able to handle such illegitimate reassembled 831 datagrams, so as to avoid them from overflowing the buffer(s) used 832 for the reassembly function. 834 o [CERT1996c] and [Kenney1996] describe the exploitation of this 835 issue to perform a Denial of Service (DoS) attack. 837 3.9. Time to Live (TTL) 839 The Time to Live (TTL) field has two functions: to bind the lifetime 840 of the upper-layer packets (e.g., TCP segments) and to prevent 841 packets from looping indefinitely in the network. 843 Originally, this field was meant to indicate maximum time a datagram 844 was allowed to remain in the internet system, in units of seconds. 845 As every internet module that processes a datagram must decrement the 846 TTL by at least one, the original definition of the TTL field became 847 obsolete, and it must now be interpreted as a hop count. 849 Most systems allow the administrator to configure the TTL to be used 850 for the packets sent, with the default value usually being a power of 851 2. The recommended value for the TTL field, as specified by the IANA 852 is 64 [IANA2006b]. This value reflects the assumed "diameter" of the 853 Internet, plus a margin to accommodate its growth. 855 The TTL field has a number of properties that are interesting from a 856 security point of view. Given that the default value used for the 857 TTL is usually a power of eight, chances are that, unless the 858 originating system has been explicitly tuned to use a non-default 859 value, if a packet arrives with a TTL of 60, the packet was 860 originally sent with a TTL of 64. In the same way, if a packet is 861 received with a TTL of 120, chances are that the original packet had 862 a TTL of 128. 864 o This discussion assumes there was no protocol scrubber, 865 transparent proxy, or some other middle-box that overwrites the 866 TTL field in a non-standard way, between the originating system 867 and the point of the network in which the packet was received. 869 Asserting the TTL with which a packet was originally sent by the 870 source system can help to obtain valuable information. Among other 871 things, it may help in: 873 o Fingerprinting the operating system being used by the source host. 875 o Fingerprinting the physical device from which the packets 876 originate. 878 o Locating the source host in the network topology. 880 Additionally, it can be used to perform functions such as: 882 o Evading Network Intrusion Detection Systems. 884 o Improving the security of applications that make use of the 885 Internet Protocol (IP). 887 3.9.1. Fingerprinting the operating system in use by the source host 889 Different operating systems use a different default TTL for the 890 packets they send. Thus, asserting the TTL with which a packet was 891 originally sent will help to reduce the number of possible operating 892 systems in use by the source host. 894 3.9.2. Fingerprinting the physical device from which the packets 895 originate 897 When several systems are behind a middle-box such as a NAT or a load 898 balancer, the TTL may help to count the number of systems behind the 899 middle-box. If each of the systems behind the middle-box use a 900 different default TTL for the packets they send, or they are located 901 in a different place of the network topology, an attacker could 902 stimulate responses from the devices being fingerprinted, and each 903 response that arrives with a different TTL could be assumed to come 904 from a different device. 906 o Of course, there are many other and much more precise techniques 907 to fingerprint physical devices. Among drawbacks of this method, 908 while many systems differ in the default TTL they use for the 909 packets they send, there are also many implementations which use 910 the same default TTL. Additionally, packets sent by a given 911 device may take different routes (e.g., due to load sharing or 912 route changes), and thus a given packet may incorrectly be 913 presumed to come from a different device, when in fact it just 914 traveled a different route. 916 3.9.3. Locating the source host in the network topology 918 The TTL field may also be used to locate the source system in the 919 network topology [Northcutt2000]. 921 +---+ +---+ +---+ +---+ +---+ 922 | A |-----| R |------| R |----| R |-----| R | 923 +---+ +---+ +---+ +---+ +---+ 924 / | / \ 925 / | / \ 926 / | / +---+ 927 / +---+ +---+ +---+ | E | 928 / | R |----| R |------| R |-- +---+ 929 / +---+ +---+\ +---+ \ 930 / / / \ \ \ 931 / ---- / +---+ \ \+---+ 932 / / / | F | \ | D | 933 +---+ +---+ +---+ \ +---| 934 | R |----------| R |-- \ 935 +---+ +---+ \ \ 936 | \ / \ +---+| +---+ 937 | \ / ----| R |------| R | 938 | \ / +---+ +---+ 939 +---+ \ +---+ +---+ 940 | B | \| R |----| C | 941 +---+ +---+ +---+ 943 Figure 5: Tracking a host by means of the TTL field 945 Consider network topology of Figure 5. Assuming that an attacker 946 ("F" in the figure) is performing some type of attack that requires 947 forging the Source Address (such as a TCP-based DoS reflection 948 attack), and some of the involved hosts are willing to cooperate to 949 locate the attacking system. 951 Assuming that: 953 o All the packets A gets have a TTL of 61. 955 o All the packets B gets have a TTL of 61. 957 o All the packets C gets have a TTL of 61. 959 o All the packets D gets have a TTL of 62. 961 Based on this information, and assuming that the system's default 962 value was not overridden, it would be fair to assume that the 963 original TTL of the packets was 64. With this information, the 964 number of hops between the attacker and each of the aforementioned 965 hosts can be calculated. 967 The attacker is: 969 o Three hops away from A. 971 o Three hops away from B. 973 o Three hops away from C. 975 o Two hops away from D. 977 In the network setup of Figure 3, the only system that satisfies all 978 these conditions is the one marked as the "F". 980 The scenario described above is for illustration purposes only. In 981 practice, there are a number of factors that may prevent this 982 technique from being successfully applied: 984 o Unless there is a "large" number of cooperating systems, and the 985 attacker is assumed to be no more than a few hops away from these 986 a systems, the number of "candidate" hosts will usually be too 987 large for the information to be useful. 989 o The attacker may be using a non-default TTL value, or, what is 990 worse, using a pseudo-random value for the TTL of the packets it 991 sends. 993 o The packets sent by the attacker may take different routes, as a 994 result of a change in network topology, load sharing, etc., and 995 thus may lead to an incorrect analysis. 997 3.9.4. Evading Network Intrusion Detection Systems 999 The TTL field can be used to evade Network Intrusion Detection 1000 Systems. Depending on the position of a sensor relative to the 1001 destination host of the examined packet, the NIDS may get a different 1002 picture from that of the intended destination system. As an example, 1003 a sensor may process a packet that will expire before getting to the 1004 destination host. A general counter-measure for this type of attack 1005 is to normalize the traffic that gets to an organizational network. 1006 Examples of such traffic normalization can be found in [Paxson2001]. 1008 3.9.5. Improving the security of applications that make use of the 1009 Internet Protocol (IP) 1011 In some scenarios, the TTL field can be also used to improve the 1012 security of an application, by restricting the hosts that can 1013 communicate with the given application . For example, there are 1014 applications for which the communicating systems are typically in the 1015 same network segment (i.e., there are no intervening routers). Such 1016 an application is the BGP (Border Gateway Protocol) between utilized 1017 by two peer routers. 1019 If both systems use a TTL of 255 for all the packets they send to 1020 each other, then a check could be enforced to require all packets 1021 meant for the application in question to have a TTL of 255. 1023 As all packets sent by systems that are not in the same network 1024 segment will have a TTL smaller than 255, those packets will not pass 1025 the check enforced by these two cooperating peers. This check 1026 reduces the set of systems that may perform attacks against the 1027 protected application (BGP in this case), thus mitigating the attack 1028 vectors described in [NISCC2004] and [Watson2004]. 1030 o This same check is enforced for related ICMP error messages, with 1031 the intent of mitigating the attack vectors described in 1032 [NISCC2005] and [I-D.ietf-tcpm-icmp-attacks]. 1034 The TTL field can be used in a similar way in scenarios in which the 1035 cooperating systems either do not use a default TTL of 255, or are 1036 not in the same network segment (i.e., multi-hop peering). In that 1037 case, the following check could be enforced: 1039 TTL >= 255 - DeltaHops 1041 This means that the set of hosts from which packets will be accepted 1042 for the protected application will be reduced to those that are no 1043 more than DeltaHops away. While for obvious reasons the level of 1044 protection will be smaller than in the case of directly-connected 1045 peers, the use of the TTL field for protecting multi-hop peering 1046 still reduces the set of hosts that could potentially perform a 1047 number of attacks against the protected application. 1049 This use of the TTL field has been officially documented by the IETF 1050 under the name "Generalized TTL Security Mechanism" (GTSM) in 1051 [RFC5082]. 1053 Some protocol scrubbers enforce a minimum value for the TTL field of 1054 the packets they forward. It must be understood that depending on 1055 the minimum TTL being enforced, and depending on the particular 1056 network setup, the protocol scrubber may actually help attackers to 1057 fool the GTSM, by "raising" the TTL of the attacking packets. 1059 3.10. Protocol 1061 The Protocol field indicates the protocol encapsulated in the 1062 internet datagram. The Protocol field may not only contain a value 1063 corresponding to an implemented protocol within the system, but also 1064 a value corresponding to a protocol not implemented, or even a value 1065 not yet assigned by the IANA [IANA2006c]. 1067 While in theory there should not be security implications from the 1068 use of any value in the protocol field, there have been security 1069 issues in the past with systems that had problems when handling 1070 packets with some specific protocol numbers [Cisco2003] [CERT2003]. 1072 3.11. Header Checksum 1074 The Header Checksum field is an error detection mechanism meant to 1075 detect errors in the IP header. While in principle there should not 1076 be security implications arising from this field, it should be noted 1077 that due to non-RFC-compliant implementations, the Header Checksum 1078 might be exploited to detect firewalls and/or evade network intrusion 1079 detection systems (NIDS). 1081 [Ed3f2002] describes the exploitation of the TCP checksum for 1082 performing such actions. As there are internet routers known to not 1083 check the IP Header Checksum, and there might also be middle-boxes 1084 (NATs, firewalls, etc.) not checking the IP checksum allegedly due to 1085 performance reasons, similar malicious activity to the one described 1086 in [Ed3f2002] might be performed with the IP checksum. 1088 3.12. Source Address 1090 The Source Address of an IP datagram identifies the node from which 1091 the packet originated. 1093 o Strictly speaking, the Source Address of an IP datagram identifies 1094 the interface of the sending system from which the packet was 1095 sent, (rather than the originating "system"), as in the Internet 1096 Architecture there's no concept of "node". 1098 Unfortunately, it is trivial to forge the Source Address of an 1099 Internet datagram. This has been exploited in the past for 1100 performing a variety of DoS (Denial of Service) attacks [NISCC2004] 1101 [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate as 1102 other systems in scenarios in which authentication was based on the 1103 Source Address of the sending system [daemon91996]. 1105 The extent to which these attacks can be successfully performed in 1106 the Internet can be reduced through deployment of ingress/egress 1107 filtering in the internet routers. [NISCC2006] is a detailed guide 1108 on ingress and egress filtering. [RFC3704] and [RFC2827] discuss 1109 ingress filtering. [GIAC2000] discusses egress filtering. 1111 o Even when the obvious field on which to perform checks for 1112 ingress/egress filtering is the Source Address and Destination 1113 Address fields of the IP header, there are other occurrences of IP 1114 addresses on which the same type of checks should be performed. 1115 One example is the IP addresses contained in the payload of ICMP 1116 error messages, as discussed in [I-D.ietf-tcpm-icmp-attacks] and 1117 [Gont2006]. 1119 There are a number of sanity checks that should be performed on the 1120 Source Address of an IP datagram. Details can be found in Section 1121 4.2 ("Addressing"). 1123 Additionally, there exist freely available tools that allow 1124 administrators to monitor which IP addresses are used with which MAC 1125 addresses [LBNL2006]. This functionality is also included in many 1126 Network Intrusion Detection Systems (NIDS). 1128 It is also very important to understand that authentication should 1129 never rely on the Source Address of the communicating systems. 1131 3.13. Destination Address 1133 The Destination Address of an IP datagram identifies the destination 1134 host to which the packet is meant to be delivered. 1136 o Strictly speaking, the Destination Address of an IP datagram 1137 identifies the interface of the destination network interface, 1138 rather than the destination "system", as in the Internet 1139 Architecture there's no concept of "node". 1141 There are a number of sanity checks that should be performed on the 1142 Destination Address of an IP datagram. Details can be found in 1143 Section 4.2 ("Addressing"). 1145 3.14. Options 1147 According to RFC 791, IP options must be implemented by all IP 1148 modules, both in hosts and gateways (i.e., end-systems and 1149 intermediate-systems). 1151 There are two cases for the format of an option: 1153 o Case 1: A single byte of option-type. 1155 o Case 2: An option-type byte, an option-length byte, and the actual 1156 option-data bytes. 1158 In the Case 2, the option-length byte counts the option-type byte and 1159 the option-length byte, as well as the actual option-data bytes. 1161 All options except "End of Option List" (Type = 0) and "No Operation" 1162 (Type = 1), are of Class 2. 1164 The option-type has three fields: 1166 o 1 bit: copied flag. 1168 o 2 bits: option class. 1170 o 5 bits: option number. 1172 The copied flag indicates whether this option should be copied to all 1173 fragments in the event the packet carrying it needs to be fragmented: 1175 o 0 = not copied. 1177 o 1 = copied. 1179 The values for the option class are: 1181 o 0 = control. 1183 o 1 = reserved for future use. 1185 o 2 = debugging and measurement. 1187 o 3 = reserved for future use. 1189 This format allows for the creation of new options for the extension 1190 of the Internet Protocol (IP). 1192 Finally, the option number identifies the syntax of the rest of the 1193 option. 1195 3.14.1. General issues with IP options 1197 The following subsections discuss security issues that apply to all 1198 IP options. The proposed checks should be performed in addition to 1199 any option-specific checks proposed in the next sections. 1201 3.14.1.1. Processing requirements 1203 Router manufacturers tend to do IP option processing on the main 1204 processor, rather than on line cards. Unless special care is taken, 1205 this represents Denial of Service (DoS) risk, as there is potential 1206 for overwhelming the router with option processing. 1208 To reduce the impact of these packets on the system performance, a 1209 few counter-measures could be implemented: 1211 o Rate-limit the number of packets with IP options that are 1212 processed by the system. 1214 o Enforce a limit on the maximum number of options to be accepted on 1215 a given internet datagram. 1217 The first check avoids a flow of packets with IP options to overwhelm 1218 the system in question. The second check avoids packets with 1219 multiple IP options to affect the performance of the system. 1221 3.14.1.2. Processing of the options by the upper layer protocol 1223 Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options 1224 received in IP datagrams must be passed to the transport layer (or to 1225 ICMP processing when the datagram is an ICMP message). Therefore, 1226 care in option processing must be taken not only at the internet 1227 layer, but also in every protocol module that may end up processing 1228 the options included in an IP datagram. 1230 3.14.1.3. General sanity checks on IP options 1232 There are a number of sanity checks that should be performed on IP 1233 options before further option processing is done. They help prevent 1234 a number of potential security problems, including buffer overflows. 1235 When these checks fail, the packet carrying the option should be 1236 dropped, and this event should be logged (e.g., a counter could be 1237 incremented to reflect the packet drop). 1239 RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" 1240 message to the originating system when a packet is dropped because of 1241 a invalid value in a field, such as the cases discussed in the 1242 following subsections. Sending such a message might help in 1243 debugging some network problems. However, it would also alert 1244 attackers about the system that is dropping packets because of the 1245 invalid values in the protocol fields. 1247 We advice that systems default to sending an ICMP "Parameter Problem" 1248 error message when a packet is dropped because of an invalid value in 1249 a protocol field (e.g., as a result of dropping a packet due to the 1250 sanity checks described in this section). However, we recommend that 1251 systems provide a system-wide toggle that allows an administrator to 1252 override the default behavior so that packets can be silently dropped 1253 due when an invalid value in a protocol field is encountered. 1255 Option length 1256 Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must 1257 not crash as the result of an option length that is outside the 1258 possible range, and mentions that erroneous option lengths have been 1259 observed to put some IP implementations into infinite loops. 1261 For options that belong to the "Case 2" described in the previous 1262 section, the following check should be performed: 1264 option-length >= 2 1266 o The value "2" accounts for the option-type byte, and the option- 1267 length byte. 1269 This check prevents, among other things, loops in option processing 1270 that may arise from incorrect option lengths. 1272 Additionally, while the option-length byte of IP options of "Case 2" 1273 allows for an option length of up to 255 bytes, there is a limit on 1274 legitimate option length imposed by the syntax of the IP header. 1276 For all options of "Case 2", the following check should be enforced: 1278 option-offset + option-length <= IHL * 4 1280 Where option-offset is the offset of the first byte of the option 1281 within the IP header, with the first byte of the IP header being 1282 assigned an offset of 0. 1284 If a packet does not pass these checks, the corresponding packet 1285 should be dropped, and this event should be logged (e.g., a counter 1286 could be incremented to reflect the packet drop). 1288 The aforementioned check is meant to detect forged option-length 1289 values that might make an option overlap with the IP payload. This 1290 would be particularly dangerous for those IP options which request 1291 the processing systems to write information into the option-data area 1292 (such as the Record Route option), as it would allow the generation 1293 of overflows. 1295 Data types 1297 Many IP options use pointer and length fields. Care must be taken as 1298 to the data type used for these fields in the implementation. For 1299 example, if an 8-bit signed data type were used to hold an 8-bit 1300 pointer, then, pointer values larger than 128 might mistakenly be 1301 interpreted as negative numbers, and thus might lead to unpredictable 1302 results. 1304 3.14.2. Issues with specific options 1306 3.14.2.1. End of Option List (Type = 0) 1308 This option is used to indicate the "end of options" in those cases 1309 in which the end of options would not coincide with the end of the 1310 Internet Protocol Header. 1312 IP systems are required to ignore those options they do not 1313 implement. Therefore, even in those cases in which this option is 1314 required, but is missing, IP systems should be able to process the 1315 remaining bytes of the IP header without any problems. 1317 3.14.2.2. No Operation (Type = 1) 1319 The no-operation option is basically meant to allow the sending 1320 system to align subsequent options in, for example, 32-bit 1321 boundaries. 1323 This option does not have security implications. 1325 3.14.2.3. Loose Source Record Route (LSRR) (Type = 131) 1327 This option lets the originating system specify a number of 1328 intermediate systems a packet must pass through to get to the 1329 destination host. Additionally, the route followed by the packet is 1330 recorded in the option. The receiving host (end-system) must use the 1331 reverse of the path contained in the received LSRR option. 1333 The LSSR option can be of help in debugging some network problems. 1334 Some ISP (Internet Service Provider) peering agreements require 1335 support for this option in the routers within the peer of the ISP. 1337 The LSRR option has well-known security implications. Among other 1338 things, the option can be used to: 1340 o Bypass firewall rules 1342 o Reach otherwise unreachable internet systems 1344 o Establish TCP connections in a stealthy way 1346 o Learn about the topology of a network 1348 o Perform bandwidth-exhaustion attacks 1349 Of these attack vectors, the one that has probably received least 1350 attention is the use of the LSRR option to perform bandwidth 1351 exhaustion attacks. The LSRR option can be used as an amplification 1352 method for performing bandwidth-exhaustion attacks, as an attacker 1353 could make a packet bounce multiple times between a number of systems 1354 by carefully crafting an LSRR option. 1356 o This is the IPv4-version of the IPv6 amplification attack that was 1357 widely publicized in 2007 [Biondi2007]. The only difference is 1358 that the maximum length of the IPv4 header (and hence the LSRR 1359 option) limits the amplification factor when compared to the IPv6 1360 counter-part. 1362 While the LSSR option may be of help in debugging some network 1363 problems, its security implications outweigh any legitimate use. 1365 All systems should, by default, drop IP packets that contain an LSRR 1366 option, and should log this event (e.g., a counter could be 1367 incremented to reflect the packet drop). However, they should 1368 provide a system-wide toggle to enable support for this option for 1369 those scenarios in which this option is required. Such system-wide 1370 toggle should default to "off" (or "disable"). 1372 [OpenBSD1998] is a security advisory about an improper 1373 implementation of such a system-wide toggle in 4.4BSD kernels. 1375 Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to 1376 act as an intermediate hop in a source route, forwarding a source- 1377 routed datagram to the next specified hop. We strongly discourage 1378 host software from forwarding source-routed datagrams. 1380 If processing of source-routed datagrams is explicitly enabled in a 1381 system, the following sanity checks should be performed. 1383 RFC 791 states that this option should appear, at most, once in a 1384 given packet. Thus, if a packet is found to have more than one LSRR 1385 option, it should be dropped, and this event should be logged (e.g., 1386 a counter could be incremented to reflect the packet drop). 1387 Therefore, hosts and routers should discard packets that contain more 1388 than one LSRR option. Additionally, if a packet were found to have 1389 both LSRR and SSRR options, it should be dropped, and this event 1390 should be logged (e.g., a counter could be incremented to reflect the 1391 packet drop). 1393 As many other IP options, the LSSR contains a Length field that 1394 indicates the length of the option. Given the format of the option, 1395 the Length field should be checked to be at least 3 (three): 1397 LSRR.Length >= 3 1399 If the packet does not pass this check, it should be dropped, and 1400 this event should be logged (e.g., a counter could be incremented to 1401 reflect the packet drop). 1403 Additionally, the following check should be performed on the Length 1404 field: 1406 LSRR.Offset + LSRR.Length < IHL *4 1408 This check assures that the option does not overlap with the IP 1409 payload (i.e., it does not go past the IP header). If the packet 1410 does not pass this check, it should be dropped, and this event should 1411 be logged (e.g., a counter could be incremented to reflect the packet 1412 drop). 1414 The Pointer is relative to this option. Thus, the minimum legal 1415 value is 4. Therefore, the following check should be performed. 1417 LSRR.Pointer >= 4 1419 If the packet does not pass this check, it should be dropped, and 1420 this event should be logged (e.g., a counter could be incremented to 1421 reflect the packet drop). Additionally, the Pointer field should be 1422 a multiple of 4. Consequently, the following check should be 1423 performed: 1425 LSRR.Pointer % 4 == 0 1427 If a packet does not pass this check, it should be dropped, and this 1428 event should be logged (e.g., a counter could be incremented to 1429 reflect the packet drop). 1431 When a system receives an IP packet with the LSRR route option, it 1432 should check whether the source route is empty or not. The option is 1433 empty if: 1435 LSRR.Pointer > LSRR.Length 1437 In that case, routing should be based on the Destination Address 1438 field, and no further processing should be done on the LSRR option. 1440 o [Microsoft1999] is a security advisory about a vulnerability 1441 arising from improper validation of the LSRR.Pointer field. 1443 If the address in the Destination Address field has been reached, and 1444 the option is not empty, the next address in the source route 1445 replaces the address in the Destination Address field. 1447 The IP address of the interface that will be used to forward this 1448 datagram should be recorded into the LSRR. However, before writing 1449 in the route data area, the following check should be performed: 1451 LSRR.Length - LSRR.Pointer >= 3 1453 This assures that there will be at least 4 bytes of space in which to 1454 record the IP address. If the packet does not pass this check, it 1455 should be dropped, and this event should be logged (e.g., a counter 1456 could be incremented to reflect the packet drop). 1458 o An offset of "1" corresponds to the option type, that's why the 1459 performed check is LSRR.Length - LSRR.Pointer >=3, and not 1460 LSRR.Length - LSRR.Pointer >=4. 1462 The LSRR must be copied on fragmentation. This means that if a 1463 packet that carries the LSRR is fragmented, each of the fragments 1464 will have to go through the list of systems specified in the LSRR 1465 option. 1467 3.14.2.4. Strict Source and Record Route (SSRR) (Type = 137) 1469 This option allows the originating system to specify a number of 1470 intermediate systems a packet must pass through to get to the 1471 destination host. Additionally, the route followed by the packet is 1472 recorded in the option, and the destination host (end-system) must 1473 use the reverse of the path contained in the received SSRR option. 1475 This option is similar to the Loose Source and Record Route (LSRR) 1476 option, with the only difference that in the case of SSRR, the route 1477 specified in the option is the exact route the packet must take 1478 (i.e., no other intervening routers are allowed to be in the route). 1480 The SSSR option can be of help in debugging some network problems. 1481 Some ISP (Internet Service Provider) peering agreements require 1482 support for this option in the routers within the peer of the ISP. 1484 The SSRR option has the same security implications as the LSRR 1485 option. Please refer to Section Section 3.14.2.3 for a discussion of 1486 such security implications. 1488 As with the LSRR, while the SSSR option may be of help in debugging 1489 some network problems, its security implications outweigh any 1490 legitimate use of it. 1492 All systems should, by default, drop IP packets that contain an LSRR 1493 option, and should log this event (e.g., a counter could be 1494 incremented to reflect the packet drop). However, they should 1495 provide a system-wide toggle to enable support for this option for 1496 those scenarios in which this option is required. Such system-wide 1497 toggle should default to "off" (or "disable"). 1499 [OpenBSD1998] is a security advisory about an improper 1500 implementation of such a system-wide toggle in 4.4BSD kernels. 1502 In the event processing of the SSRR option were explicitly enabled, 1503 the same sanity checks described for the LSRR option in 1504 Section 3.14.2.3 should be performed on the SSRR option. Namely, 1505 sanity checks shoudl be performed on the option length (SSRR.Length) 1506 and the Pointer field (SSRR.Pointer). 1508 If the packet passes the aforementioned sanity checks, the receiving 1509 system should determine whether the Destination Address of the packet 1510 corresponds to one of its IP addresses. If does not, it should be 1511 dropped, and this event should be logged (e.g., a counter could be 1512 incremented to reflect the packet drop). 1514 Contrary to the IP Loose Source and Record Route (LSRR) option, 1515 the SSRR option does not allow in the route other routers than 1516 those contained in the option. If the system implements the weak 1517 end-system model, it is allowed for the system to receive a packet 1518 destined to any of its IP addresses, on any of its interfaces. If 1519 the system implements the strong end-system model, a packet 1520 destined to it can be received only on the interface that 1521 corresponds to the IP address contained in the Destination Address 1522 field [RFC1122]. 1524 If the packet passes this check, the receiving system should 1525 determine whether the source route is empty or not. The option is 1526 empty if: 1528 SSRR.Pointer > SSRR.Length 1530 In that case, if the address in the destination field has not been 1531 reached, the packet should be dropped, and this event should be 1532 logged (e.g., a counter could be incremented to reflect the packet 1533 drop). 1535 [Microsoft1999] is a security advisory about a vulnerability 1536 arising from improper validation of the SSRR.Pointer field. 1538 If the option is not empty, and the address in the Destination 1539 Address field has been reached, the next address in the source route 1540 replaces the address in the Destination Address field. This IP 1541 address must be reachable without the use of any intervening router 1542 (i.e., the address must belong to any of the networks to which the 1543 system is directly attached). If that is not the case, the packet 1544 should be dropped, and this event should be logged (e.g., a counter 1545 could be incremented to reflect the packet drop). 1547 The IP address of the interface that will be used to forward this 1548 datagram should be recorded into the SSRR. However, before doing 1549 that, the following check should be performed: 1551 SSRR.Length - SSRR.Pointer >=3 1553 An offset of "1" corresponds to the option type, that's why the 1554 performed check is SSRR.Length - SSRR.Pointer >=3, and not 1555 SSRR.Length - SSRR.Pointer >=4. 1557 This assures that there will be at least 4 bytes of space on which to 1558 record the IP address. If the packet does not pass this check, it 1559 should be dropped, and this event should be logged (e.g., a counter 1560 could be incremented to reflect the packet drop). 1562 The SSRR option must be copied on fragmentation. This means that if 1563 a packet that carries the SSRR is fragmented, each of the fragments 1564 will have to go through the list of systems specified in the SSRR 1565 option. 1567 3.14.2.5. Record Route (Type = 7) 1569 This option provides a means to record the route that a given packet 1570 follows. 1572 The option begins with an 8-bit option code, which must be equal to 1573 7. The second byte is the option length, which includes the option- 1574 type byte, the option-length byte, the pointer byte, and the actual 1575 option-data. The third byte is a pointer into the route data, 1576 indicating the first byte of the area in which to store the next 1577 route data. The pointer is relative to the option start. 1579 RFC 791 states that this option should appear, at most, once in a 1580 given packet. Therefore, if a packet has more than one instance of 1581 this option, it should be dropped, and this event should be logged 1582 (e.g., a counter could be incremented to reflect the packet drop). 1584 The same sanity checks performed for the Length field and the Pointer 1585 field of the LSRR and the SSRR options should be performed on the 1586 Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR 1587 option. And, as with the LSRR and SSRR options, if the packet does 1588 not pass these checks it should be dropped, and this event should be 1589 logged (e.g., a counter could be incremented to reflect the packet 1590 drop). 1592 When a system receives an IP packet with the Record Route option, it 1593 should check whether there is space in the option to store route 1594 information. The option is full if: 1596 RR.Pointer > RR.Length 1598 If the option is full, the datagram should be forwarded without 1599 further processing of this option. If not, the following check 1600 should be performed before writing any route data into the option: 1602 RR.Pointer - RR.Length >= 3 1604 If the packet does not pass this check, the packet should be 1605 considered in error, and therefore should be dropped, and this event 1606 should be logged (e.g., a counter could be incremented to reflect the 1607 packet drop). 1609 If the option is not full (i.e., RR.Pointer <= RR.Length), but 1610 RR.Pointer - RR.Length < 4, it means that while there's space in 1611 the option, there is not not enough space to store an IP address. 1612 It is fair to assume that such an scenario will only occur when 1613 the packet has been crafted. 1615 If the packet passes this check, the IP address of the interface that 1616 will be used to forward this datagram should be recorded into the 1617 area pointed by the RR.Pointer, and RR.Pointer should then be 1618 incremented by 4. 1620 This option is not copied on fragmentation, and thus appears in the 1621 first fragment only. If a fragment other than the one with offset 0 1622 contains the Record Route option, it should be dropped, and this 1623 event should be logged (e.g., a counter could be incremented to 1624 reflect the packet drop). 1626 3.14.2.6. Stream Identifier (Type = 136) 1628 The Stream Identifier option originally provided a means for the 16- 1629 bit SATNET stream Identifier to be carried through networks that did 1630 not support the stream concept. 1632 However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this 1633 option is obsolete. Therefore, it should be ignored by the 1634 processing systems. 1636 In the case of legacy systems still using this option, the length 1637 field of the option should be checked to be 4. If the option does 1638 not pass this check, it should be dropped, and this event should be 1639 logged (e.g., a counter could be incremented to reflect the packet 1640 drop). 1642 RFC 791 states that this option appears at most once in a given 1643 datagram. Therefore, if a packet contains more than one instance of 1644 this option, it should be dropped, and this event should be logged 1645 (e.g., a counter could be incremented to reflect the packet drop). 1647 3.14.2.7. Internet Timestamp (Type = 68) 1649 This option provides a means for recording the time at which each 1650 system processed this datagram. The timestamp option has a number of 1651 security implications. Among them are: 1653 o It allows an attacker to obtain the current time of the systems 1654 that process the packet, which the attacker may find useful in a 1655 number of scenarios. 1657 o It may be used to map the network topology, in a similar way to 1658 the IP Record Route option. 1660 o It may be used to fingerprint the operating system in use by a 1661 system processing the datagram. 1663 o It may be used to fingerprint physical devices, by analyzing the 1664 clock skew. 1666 Therefore, by default, the timestamp option should be ignored. 1668 For those systems that have been explicitly configured to honor this 1669 option, the rest of this subsection describes some sanity checks that 1670 should be enforced on the option before further processing. 1672 The option begins with an option-type byte, which must be equal to 1673 68. The second byte is the option-length, which includes the option- 1674 type byte, the option-length byte, the pointer, and the overflow/flag 1675 byte. The minimum legal value for the option-length byte is 4, which 1676 corresponds to an Internet Timestamp option that is empty (no space 1677 to store timestamps). Therefore, upon receipt of a packet that 1678 contains an Internet Timestamp option, the following check should be 1679 performed: 1681 IT.Length >= 4 1683 If the packet does not pass this check, it should be dropped, and 1684 this event should be logged (e.g., a counter could be incremented to 1685 reflect the packet drop). 1687 Additionally, the following check should be performed on the option 1688 length field: 1690 IT.Offset + IT.Length < IHL *4 1692 This check assures that the option does not overlap with the IP 1693 payload (i.e., it does not go past the IP header). If the packet 1694 does not pass this check, it should be dropped, and this event should 1695 be logged (e.g., a counter could be incremented to reflect the packet 1696 drop). 1698 The pointer byte points to the first byte of the area in which the 1699 next timestamp data should be stored. As its value is relative to 1700 the beginning of the option, its minimum legal value is 5. 1701 Consequently, the following check should be performed on a packet 1702 that contains the Internet Timestamp option: 1704 IT.Pointer >= 5 1706 If the packet does not pass this check, it should be dropped, and 1707 this event should be logged (e.g., a counter could be incremented to 1708 reflect the packet drop). 1710 The flag field has three possible legal values: 1712 o 0: Record time stamps only, stored in consecutive 32-bit words. 1714 o 1: Record each timestamp preceded with the internet address of the 1715 registering entity. 1717 o 3: The internet address fields of the option are pre-specified. 1718 An IP module only registers its timestamp if it matches its own 1719 address with the next specified internet address. 1721 Therefore the following check should be performed: 1723 IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 1725 If the packet does not pass this check, it should be dropped, and 1726 this event should be logged (e.g., a counter could be incremented to 1727 reflect the packet drop). 1729 The timestamp field is a right-justified 32-bit timestamp in 1730 milliseconds since UT. If the time is not available in milliseconds, 1731 or cannot be provided with respect to UT, then any time may be 1732 inserted as a timestamp, provided the high order bit of the timestamp 1733 is set, to indicate this non-standard value. 1735 According to RFC 791, the initial contents of the timestamp area must 1736 be initialized to zero, or internet address/zero pairs. However, 1737 internet systems should be able to handle non-zero values, possibly 1738 discarding the offending datagram. 1740 When an internet system receives a packet with an Internet Timestamp 1741 option, it decides whether it should record its timestamp in the 1742 option. If it determines that it should, it should then determine 1743 whether the timestamp data area is full, by means of the following 1744 check: 1746 IT.Pointer > IT.Length 1748 If this condition is true, the timestamp data area is full. If not, 1749 there is room in the timestamp data area. 1751 If the timestamp data area is full, the overflow byte should be 1752 incremented, and the packet should be forwarded without inserting the 1753 timestamp. If the overflow byte itself overflows, the packet should 1754 be dropped, and this event should be logged (e.g., a counter could be 1755 incremented to reflect the packet drop). 1757 If timestamp data area is not full, then further checks should be 1758 performed before actually inserting any data. 1760 If the IT.Flag byte is 0, the following check should be performed: 1762 IT.Length - IT.Pointer >= 3 1764 If the packet does not pass this check, it should be dropped, and 1765 this event should be logged (e.g., a counter could be incremented to 1766 reflect the packet drop). If the packet passes this check, there is 1767 room for at least one 32-bit timestamp. The system's 32-bit 1768 timestamp should be inserted at the area pointed by the pointer byte, 1769 and the pointer byte should be incremented by four. 1771 If the IT.Flag byte is 1, then the following check should be 1772 performed: 1774 IT.Length - IT.Pointer >= 7 1776 If the packet does not pass this check, it should be dropped, and 1777 this event should be logged (e.g., a counter could be incremented to 1778 reflect the packet drop). If the packet does pass this check, it 1779 means there is space in the timestamp data area to store at least one 1780 IP address plus the corresponding 32-bit timestamp. The IP address 1781 of the system should be stored at the area pointed to by the pointer 1782 byte, followed by the 32-bit system timestamp. The pointer byte 1783 should then be incremented by 8. 1785 If the flag byte is 3, then the following check should be performed: 1787 IT.Length - IT.Pointer >= 7 1789 If the packet does not pass this check, it should be dropped, and 1790 this event should be logged (e.g., a counter could be incremented to 1791 reflect the packet drop). If it does, it means there is space in the 1792 timestamp data area to store an IP address and store the 1793 corresponding 32-bit timestamp. The system's timestamp should be 1794 stored at the area pointed by IT.Pointer + 4. Then, the pointer byte 1795 should be incremented by 8. 1797 [Kohno2005] describes a technique for fingerprinting devices by 1798 measuring the clock skew. It exploits, among other things, the 1799 timestamps that can be obtained by means of the ICMP timestamp 1800 request messages [RFC0791]. However, the same fingerprinting method 1801 could be implemented with the aid of the Internet Timestamp option. 1803 3.14.2.8. Router Alert (Type = 148) 1805 The Router Alert option is defined in RFC 2113 [RFC2113]. It has the 1806 semantic "routers should examine this packet more closely". A packet 1807 that contains a Router Alert option will not go through the router's 1808 fast-path and will be processed in the router more slowly than if the 1809 option were not set. Therefore, this option may impact the 1810 performance of the systems that handle the packet carrying it. 1812 According to the syntax of the option as defined in RFC 2113, the 1813 following check should be enforced: 1815 RA.Length == 4 1817 If the packet does not pass this check, it should be dropped, and 1818 this event should be logged (e.g., a counter could be incremented to 1819 reflect the packet drop). Furthermore, the following check should be 1820 performed on the Value field: 1822 RA.Value == 0 1824 If the packet does not pass this check, it should be dropped, and 1825 this event should be logged (e.g., a counter could be incremented to 1826 reflect the packet drop). 1828 As explained in RFC 2113, hosts should ignore this option. 1830 3.14.2.9. Probe MTU (Type =11) 1832 This option is defined in RFC 1063 [RFC1063], and originally provided 1833 a mechanism to discover the Path-MTU. 1835 This option is obsolete, and therefore any packet that is received 1836 containing this option should be dropped, and this event should be 1837 logged (e.g., a counter could be incremented to reflect the packet 1838 drop). 1840 3.14.2.10. Reply MTU (Type = 12) 1842 This option is defined in RFC 1063 [RFC1063], and originally provided 1843 a mechanism to discover the Path-MTU. 1845 This option is obsolete, and therefore any packet that is received 1846 containing this option should be dropped, and this event should be 1847 logged (e.g., a counter could be incremented to reflect the packet 1848 drop). 1850 3.14.2.11. Traceroute (Type = 82) 1852 This option is defined in RFC 1393 [RFC1393], and originally provided 1853 a mechanism to trace the path to a host. 1855 This option is obsolete, and therefore any packet that is received 1856 containing this option should be dropped, and this event should be 1857 logged (e.g., a counter could be incremented to reflect the packet 1858 drop). 1860 3.14.2.12. DoD Basic Security Option (Type = 130) 1862 This option is used by end-systems and intermediate systems of an 1863 internet to [RFC1108]: 1865 o Transmit from source to destination in a network standard 1866 representation the common security labels required by computer 1867 security models, 1869 o Validate the datagram as appropriate for transmission from the 1870 source and delivery to the destination, and, 1872 o Ensure that the route taken by the datagram is protected to the 1873 level required by all protection authorities indicated on the 1874 datagram. 1876 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 1877 [RFC1038]). 1879 o RFC 791 [RFC0791] defined the "Security Option" (Type = 130), 1880 which used the same option type as the DoD Basic Security option 1881 discussed in this section. The "Security Option" specified in RFC 1882 791 is considered obsolete by Section 4.2.2.1 of RFC 1812, and 1883 therefore the discussion in this section is focused on the DoD 1884 Basic Security option specified by RFC 1108 [RFC1108]. 1886 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 1887 this option". 1889 The DoD Basic Security Option is currently implemented in a number of 1890 operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], 1891 and [Cisco2008]), and deployed in a number of high-security networks. 1893 RFC 1108 states that the option should appear at most once in a 1894 datagram. Therefore, if more than one DoD Basic Security option 1895 (BSO) appears in a given datagram, the corresponding datagram should 1896 be dropped, and this event should be logged (e.g., a counter could be 1897 incremented to reflect the packet drop). 1899 RFC 1108 states that the option Length is variable, with a minimum 1900 option Length of 3 bytes. Therefore, the following check should be 1901 performed: 1903 BSO.Length >= 3 1905 If the packet does not pass this check, it should be dropped, and 1906 this event should be logged (e.g., a counter could be incremented to 1907 reflect the packet drop). 1909 Systems that belong to networks in which this option is in use should 1910 process the DoD Basic Security option contained in each packet as 1911 specified in [RFC1108]. 1913 o Current deployments of the DoD Security Options have motivated the 1914 proposal of a "Common Architecture Label IPv6 Security Option 1915 (CALIPSO)" for the IPv6 protocol. [RFC1038]. 1917 3.14.2.13. DoD Extended Security Option (Type = 133) 1919 This option permits additional security labeling information, beyond 1920 that present in the Basic Security Option (Section 3.13.2.12), to be 1921 supplied in an IP datagram to meet the needs of registered 1922 authorities. It is specified by RFC 1108 [RFC1108]. 1924 This option may be present only in conjunction with the DoD Basic 1925 Security option. Therefore, if a packet contains a DoD Extended 1926 Security option (ESO), but does not contain a DoD Basic Security 1927 option, it should be dropped, and this event should be logged (e.g., 1928 a counter could be incremented to reflect the packet drop). It 1929 should be noted that, unlike the DoD Basic Security option, this 1930 option may appear multiple times in a single IP header. 1932 RFC 1108 states that the option Length is variable, with a minimum 1933 option Length of 3 bytes. Therefore, the following check should be 1934 performed: 1936 ESO.Length >= 3 1938 If the packet does not pass this check, it should be dropped, and 1939 this event should be logged (e.g., a counter could be incremented to 1940 reflect the packet drop). 1942 Systems that belong to networks in which this option is in use, 1943 should process the DoD Extended Security option contained in each 1944 packet as specified in RFC 1108 [RFC1108]. 1946 3.14.2.14. Commercial IP Security Option (CIPSO) (Type = 134) 1948 This option was proposed by the Trusted Systems Interoperability 1949 Group (TSIG), with the intent of meeting trusted networking 1950 requirements for the commercial trusted systems market place. It is 1951 specified in [CIPSO1992] and [FIPS1994]. 1953 o The TSIG proposal was taken to the Commercial Internet Security 1954 Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an 1955 Internet-Draft was produced [CIPSO1992]. The Internet-Draft was 1956 never published as an RFC, and the proposal was later standardized 1957 by the U.S. National Institute of Standards and Technology (NIST) 1958 as "Federal Information Processing Standard Publication 188" 1959 [FIPS1994]. 1961 It is currently implemented in a number of operating systems (e.g., 1962 IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris 1963 [Solaris2008]), and deployed in a number of high-security networks. 1965 o [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux 1966 implementation. 1968 According to the option syntax specified in [CIPSO1992] the following 1969 validation check should be performed: 1971 CIPSO.Length >= 6 1973 If a packet does not pass this check, it should be dropped, and this 1974 event should be logged (e.g., a counter could be incremented to 1975 reflect the packet drop). 1977 Systems that belong to networks in which this option is in use should 1978 process the CIPSO option contained in each packet as specified in 1979 [CIPSO1992]. 1981 3.14.2.15. Sender Directed Multi-Destination Delivery (Type = 149) 1983 This option is defined in RFC 1770 [RFC1770], and originally provided 1984 unreliable UDP delivery to a set of addresses included in the option. 1986 This option is obsolete. If a received packet contains this option, 1987 it should be dropped, and this event should be logged (e.g., a 1988 counter could be incremented to reflect the packet drop). 1990 3.15. TOS 1992 Figure 2 shows the syntax of the Type of Service field, as defined by 1993 RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. We provide a 1994 discussion of this obsoleted definition, legacy implementations might 1995 still be using these semantics. 1997 0 1 2 3 4 5 6 7 1998 +-----+-----+-----+-----+-----+-----+-----+-----+ 1999 | PRECEDENCE | D | T | R | C | 0 | 2000 +-----+-----+-----+-----+-----+-----+-----+-----+ 2002 Figure 6: Type of Service field 2004 +----------+----------------------------------------------+ 2005 | Bits 0-2 | Precedence | 2006 +----------+----------------------------------------------+ 2007 | Bit 3 | 0 = Normal Delay, 1 = Low Delay | 2008 +----------+----------------------------------------------+ 2009 | Bit 4 | 0 = Normal Throughput, 1 = High Throughput | 2010 +----------+----------------------------------------------+ 2011 | Bit 5 | 0 = Normal Reliability, 1 = High Reliability | 2012 +----------+----------------------------------------------+ 2013 | Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost | 2014 +----------+----------------------------------------------+ 2015 | Bits 7 | Reserved for Future Use (must be zero) | 2016 +----------+----------------------------------------------+ 2018 Table 2: TOS bits 2020 +-----+-----------------+ 2021 | 111 | Network Control | 2022 +-----+-----------------+ 2023 | 110 | Internetwork | 2024 +-----+-----------------+ 2025 | 101 | CRITIC/ECP | 2026 +-----+-----------------+ 2027 | 100 | Flash Override | 2028 +-----+-----------------+ 2029 | 011 | Flash | 2030 +-----+-----------------+ 2031 | 010 | Immediate | 2032 +-----+-----------------+ 2033 | 001 | Priority | 2034 +-----+-----------------+ 2035 | 000 | Routine | 2036 +-----+-----------------+ 2038 Table 3: Precedence field 2040 The Type of Service field can be used to affect the way in which the 2041 packet is treated by the systems of a network that process it. 2042 Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 2043 ("Weak TOS") of this document describe the security implications of 2044 the Type of Service field in the forwarding of packets. 2046 4. Internet Protocol Mechanisms 2048 4.1. Fragment reassembly 2050 To accommodate networks with different Maximum Transmission Units 2051 (MTUs), the Internet Protocol provides a mechanism for the 2052 fragmentation of IP packets by end-systems (hosts) and/or 2053 intermediate systems (routers). Reassembly of fragments is performed 2054 only by the end-systems. 2056 o [Cerf1974] provides the rationale for which packet reassembly is 2057 not performed by intermediate systems. 2059 During the last few decades, IP fragmentation and reassembly has been 2060 exploited in a number of ways, to perform actions such as evading 2061 Network Intrusion Detection Systems (NIDS), bypassing firewall rules, 2062 and performing Denial of Service (DoS) attacks. 2064 o [Bendi1998] and [Humble1998] are examples of the exploitation of 2065 these issues for performing Denial of Service (DoS) attacks. 2066 [CERT1997] and [CERT1998b] document these issues. [Anderson2001] 2067 is a survey of fragmentation attacks. [US-CERT2001] is an example 2068 of the exploitation of IP fragmentation to bypass firewall rules. 2069 [CERT1999] describes the implementation of fragmentation attacks 2070 in Distributed Denial of Service (DDoS) attack tools. 2072 The problem with IP fragment reassembly basically has to do with the 2073 complexity of the function, in a number of aspects: 2075 o Fragment reassembly is a stateful operation for a stateless 2076 protocol (IP). The IP module at the host performing the 2077 reassembly function must allocate memory buffers both for 2078 temporarily storing the received fragments, and to perform the 2079 reassembly function. Attackers can exploit this fact to exhaust 2080 memory buffers at the system performing the fragment reassembly. 2082 o The fragmentation and reassembly mechanisms were designed at a 2083 time in which the available bandwidths were very different from 2084 the bandwidths available nowadays. With the current available 2085 bandwidths, a number of interoperability problems may arise. And 2086 these issues may be intentionally exploited by attackers to 2087 perform Denial of Service (DoS) attacks. 2089 o Fragment reassembly must usually be performed without any 2090 knowledge of the properties of the path the fragments follow. 2091 Without this information, hosts cannot make any educated guess on 2092 how long they should wait for missing fragments to arrive. 2094 o The fragment reassembly algorithm, as described by the IETF 2095 specifications, is ambiguous, and allows for a number of 2096 interpretations, each of which has found place in different TCP/IP 2097 stack implementations. 2099 o The reassembly process is somewhat complex. Fragments may arrive 2100 out of order, duplicated, overlapping each other, etc. This 2101 complexity has lead to numerous bugs in different implementations 2102 of the IP protocol. 2104 4.1.1. Security Implications of Fragment Reassembly 2106 4.1.1.1. Problems related with memory allocation 2108 When an IP datagram is received by an end-system, it will be 2109 temporarily stored in system memory, until the IP module processes it 2110 and hands it to the protocol machine that corresponds to the 2111 encapsulated protocol. 2113 In the case of fragmented IP packets, while the IP module may perform 2114 preliminary processing of the IP header (such as checking the header 2115 for errors and processing IP options), fragments must be kept in 2116 system buffers until all fragments are received and are reassembled 2117 into a complete internet datagram. 2119 As mentioned above, the fact that the internet layer will not usually 2120 have information about the characteristics of the path between the 2121 system and the remote host, no educated guess can be made on the 2122 amount of time that should be waited for the other fragments to 2123 arrive. Therefore, the specifications recommend to wait for a period 2124 of time that will be acceptable for virtually all the possible 2125 network scenarios in which the protocols might operate. 2126 Specifically, RFC 1122 [RFC1122] states that the reassembly timeout 2127 should be a fixed value between 60 and 120 seconds. If after waiting 2128 for that period of time the remaining fragments have not yet arrived, 2129 all the received fragments for the corresponding packet are 2130 discarded. 2132 o The original IP Specification, RFC 791 [RFC0791], states that 2133 systems should wait for at least 15 seconds for the missing 2134 fragments to arrive. Systems that follow the "Example Reassembly 2135 Procedure" described in Section 3.2 of RFC 791 may end up using a 2136 reassembly timer of up to 4.25 minutes, with minimum of 15 2137 seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this 2138 advice, stating that the reassembly timeout should be a fixed 2139 value between 60 and 120 seconds. 2141 However, the longer the system waits for the missing fragments to 2142 arrive, the longer the corresponding system resources must be tied to 2143 the corresponding packet. The amount of system memory is finite, and 2144 even with today's systems, it can still be considered a scarce 2145 resource. 2147 An attacker could take advantage of the uncomfortable situation the 2148 system performing fragment reassembly is in, by sending forged 2149 fragments that will never reassemble into a complete datagram. That 2150 is, an attacker would send many different fragments, with different 2151 IP IDs, without ever sending all the necessary fragments that would 2152 be needed to reassemble them into a full IP datagram. For each of 2153 the fragments, the IP module would allocate resources and tie them to 2154 the corresponding fragment, until any the reassembly timer for the 2155 corresponding packet expires. 2157 There are some implementation strategies which could increase the 2158 impact of this attack. For example, upon receipt of a fragment, some 2159 systems allocate a memory buffer that will be large enough to 2160 reassemble the whole datagram. While this might be beneficial in 2161 legitimate cases, this just amplifies the impact of the possible 2162 attacks, as a single small fragment could tie up memory buffers for 2163 the size of an extremely large (and unlikely) datagram. The 2164 implementation strategy suggested in RFC 815 [RFC0815] leads to such 2165 an implementation. 2167 The impact of the aforementioned attack may vary depending on some 2168 specific implementation details: 2170 o If the system does not enforce limits on the amount of memory that 2171 can be allocated by the IP module, then an attacker could tie all 2172 system memory to fragments, at which point the system would become 2173 unusable, probably crashing. 2175 o If the system enforces limits on the amount of memory that can be 2176 allocated by the IP module as a whole, then, when this limit is 2177 reached, all further IP packets that arrive would be discarded, 2178 until some fragments time out and free memory is available again. 2180 o If the system enforces limits on the amount memory that can be 2181 allocated for the reassembly of fragments (in addition to 2182 enforcing a limit for the IP module as a whole), then, when this 2183 limit is reached, all further fragments that arrive would be 2184 discarded, until some fragment(s) time out and free memory is 2185 available again. 2187 4.1.1.2. Problems that arise from the length of the IP Identification 2188 field 2190 The Internet Protocols are currently being used in environments that 2191 are quite different from the ones in which they were conceived. For 2192 instance, the availability of bandwidth at the time the Internet 2193 Protocol was designed was completely different from the availability 2194 of bandwidth in today's networks. 2196 The Identification field is a 16-bit field that is used for the 2197 fragmentation and reassembly function. In the event a datagram gets 2198 fragmented, all the corresponding fragments will share the same 2199 Identification number. Thus, the system receiving the fragments will 2200 be able to uniquely identify them as fragments that correspond to the 2201 same IP datagram. At a given point in time, there must be at most 2202 only one packet in the network with a given Identification number. 2203 If not, an Identification number "collision" might occur, and the 2204 receiving system might end up "mixing" fragments that correspond to 2205 different IP datagrams which simply reused the same Identification 2206 number. 2208 For each group of fragments whose Identification numbers "collide", 2209 the fragment reassembly will lead to corrupted packets. The IP 2210 payload of the reassembled datagram will be handed to the 2211 corresponding upper layer protocol, where the error will (hopefully) 2212 be detected by some error detecting code (such as the TCP checksum) 2213 and the packet will be discarded. 2215 An attacker could exploit this fact to intentionally cause a system 2216 to discard all or part of the fragmented traffic it gets, thus 2217 performing a Denial of Service attack. Such an attacker would simply 2218 establish a flow of fragments with different IP Identification 2219 numbers, to trash all or part of the IP Identification space. As a 2220 result, the receiving system would use the attacker's fragments for 2221 the reassembly of legitimate datagrams, leading to corrupted packets 2222 which would later (and hopefully) get dropped. 2224 In most cases, use of a long fragment timeout will benefit the 2225 attacker, as forged fragments will keep the IP Identification space 2226 trashed for a longer period of time. 2228 4.1.1.3. Problems that arise from the complexity of the reassembly 2229 algorithm 2231 As IP packets can be duplicated by the network, and each packet may 2232 take a different path to get to the destination host, fragments may 2233 arrive not only out of order and/or duplicated, but also overlapping. 2234 This means that the reassembly process can be somewhat complex, with 2235 the corresponding implementation being not specifically trivial. 2237 [Shannon2001] analyzes the causes and attributes of fragment traffic 2238 measured in several types of WANs. 2240 During the years, a number of attacks have exploited bugs in the 2241 reassembly function of a number of operating systems, producing 2242 buffer overflows that have led, in most cases, to a crash of the 2243 attacked system. 2245 4.1.1.4. Problems that arise from the ambiguity of the reassembly 2246 process 2248 Network Intrusion Detection Systems (NIDSs) typically monitor the 2249 traffic on a given network with the intent of identifying traffic 2250 patterns that might indicate network intrusions. 2252 In the presence of IP fragments, in order to detect illegitimate 2253 activity at the transport or application layers (i.e., any protocol 2254 layer above the network layer), a NIDS must perform IP fragment 2255 reassembly. 2257 In order to correctly assess the traffic, the result of the 2258 reassembly function performed by the NIDS should be the same as that 2259 of the reassembly function performed by the intended recipient of the 2260 packets. 2262 However, a number of factors make the result of the reassembly 2263 process ambiguous: 2265 o The IETF specifications are ambiguous as to what should be done in 2266 the event overlapping fragments were received. Thus, in the 2267 presence of overlapping data, the system performing the reassembly 2268 function is free to either honor the first set of data received, 2269 the latest copy received, or any other copy received in between. 2271 o As the specifications do not enforce any specific fragment timeout 2272 value, different systems may choose different values for the 2273 fragment timeout. This means that given a set of fragments 2274 received at some specified time intervals, some systems will 2275 reassemble the fragments into a full datagram, while others may 2276 timeout the fragments and therefore drop them. 2278 o As mentioned before, as the fragment buffers get full, a Denial of 2279 Service (DoS) condition will occur unless some action is taken. 2280 Many systems flush part of the fragment buffers when some 2281 threshold is reached. Thus, depending on fragment load, timing 2282 issues, and flushing policy, a NIDS may get incorrect assumptions 2283 about how (and if) fragments are being reassembled by their 2284 intended recipient. 2286 As originally discussed by [Ptacek1998], these issues can be 2287 exploited by attackers to evade intrusion detection systems. 2289 There exist freely available tools to forcefully fragment IP 2290 datagrams so as to help evade Intrusion Detection Systems. Frag 2291 router [Song1999] is an example of such a tool; it allows an attacker 2292 to perform all the evasion techniques described in [Ptacek1998]. 2293 Ftester [Barisani2006] is a tool that helps to audit systems 2294 regarding fragmentation issues. 2296 4.1.1.5. Problems that arise from the size of the IP fragments 2298 One approach to fragment filtering involves keeping track of the 2299 results of applying filter rules to the first fragment (i.e., the 2300 fragment with a Fragment Offset of 0), and applying them to 2301 subsequent fragments of the same packet. The filtering module would 2302 maintain a list of packets indexed by the Source Address, Destination 2303 Address, Protocol, and Identification number. When the initial 2304 fragment is seen, if the MF bit is set, a list item would be 2305 allocated to hold the result of filter access checks. When packets 2306 with a non-zero Fragment Offset come in, look up the list element 2307 with a matching Source Address/Destination Address/Protocol/ 2308 Identification and apply the stored result (pass or block). When a 2309 fragment with a zero MF bit is seen, free the list element. 2310 Unfortunately, the rules of this type of packet filter can usually be 2311 bypassed. [RFC1858] describes the details of the involved technique. 2313 4.1.2. Possible security improvements 2315 4.1.2.1. Memory allocation for fragment reassembly 2317 A design choice usually has to be made as to how to allocate memory 2318 to reassemble the fragments of a given packet. There are basically 2319 two options: 2321 o Upon receipt of the first fragment, allocate a buffer that will be 2322 large enough to concatenate the payload of each fragment. 2324 o Upon receipt of the first fragment, create the first node of a 2325 linked list to which each of the following fragments will be 2326 linked. When all fragments have been received, copy the IP 2327 payload of each of the fragments (in the correct order) to a 2328 separate buffer that will be handed to the protocol being 2329 encapsulated in the IP payload. 2331 While the first of the choices might seem to be the most straight- 2332 forward, it implies that even when a single small fragment of a given 2333 packet is received, the amount of memory that will be allocated for 2334 that fragment will account for the size of the complete IP datagram, 2335 thus using more system resources than what is actually needed. 2337 Furthermore, the only situation in which the actual size of the whole 2338 datagram will be known is when the last fragment of the packet is 2339 received first, as that is the only packet from which the total size 2340 of the IP datagram can be asserted. Otherwise, memory should be 2341 allocated for largest possible packet size (65535 bytes). 2343 The IP module should also enforce a limit on the amount of memory 2344 that can be allocated for IP fragments, as well as a limit on the 2345 number of fragments that at any time will be allowed in the system. 2346 This will basically limit the resources spent on the reassembly 2347 process, and prevent an attacker from trashing the whole system 2348 memory. 2350 Furthermore, the IP module should keep a different buffer for IP 2351 fragments than for complete IP datagrams. This will basically 2352 separate the effects of fragment attacks on non-fragmented traffic. 2353 Most TCP/IP implementations, such as that in Linux and those in BSD- 2354 derived systems, already implement this. 2356 [Jones2002] contains an analysis about the amount of memory that may 2357 be needed for the fragment reassembly buffer depending on a number of 2358 network characteristics. 2360 4.1.2.2. Flushing the fragment buffer 2362 In the case of those attacks that aim to consume the memory buffers 2363 used for fragments, and those that aim to cause a collision of IP 2364 Identification numbers, there are a number of counter-measures that 2365 can be implemented. 2367 The IP module should enforce a limit on the amount of memory that can 2368 be allocated for IP fragments, as well as a limit on the number of 2369 fragments that at any time will be allowed in the system. This will 2370 basically limit the resources spent on the reassembly process, and 2371 prevent an attacker from trashing the whole system memory. 2373 Additionally, the IP module should keep a different buffer for IP 2374 fragments than for complete IP datagrams. This will basically 2375 separate the effects of fragment attacks on non-fragmented traffic. 2376 Most TCP/IP implementations, such as that in Linux and those in BSD- 2377 derived systems, already implement this. 2379 Even with these counter-measures in place, there is still the issue 2380 of what to do when the buffer used for IP fragments get full. 2381 Basically, if the fragment buffer is full, no instance of 2382 communication that relies on fragmentation will be able to progress. 2384 Unfortunately, there are not many options for reacting to this 2385 situation. If nothing is done, all the instances of communication 2386 that rely on fragmentation will experience a denial of service. 2387 Thus, the only thing that can be done is flush all or part of the 2388 fragment buffer, on the premise that legitimate traffic will be able 2389 to make use of the freed buffer space to allow communication flows to 2390 progress. 2392 There are a number of factors that should be taken into consideration 2393 when flushing the fragment buffer. First, if a fragment of a given 2394 packet (i.e., fragment with a given Identification number) is 2395 flushed, all the other fragments that correspond to the same datagram 2396 should be flushed. As in order for a packet to be reassembled all of 2397 its fragments must be received by the system performing the 2398 reassembly function, flushing only a subset of the fragments of a 2399 given packet would keep the corresponding buffers tied to fragments 2400 that would never reassemble into a complete datagram. Additionally, 2401 care must be taken so that, in the event that subsequent buffer 2402 flushes need to be performed, it is not always the same set of 2403 fragments that get dropped, as such a behavior would probably cause a 2404 selective Denial of Service (DoS) to the traffic flows to which that 2405 set of fragments belong. 2407 Many TCP/IP implementations define a threshold for the number of 2408 fragments that, when reached, triggers a fragment-buffer flush. Some 2409 systems flush 1/2 of the fragment buffer when the threshold is 2410 reached. As mentioned before, the idea of flushing the buffer is to 2411 create some free space in the fragment buffer, on the premise that 2412 this will allow for new and legitimate fragments to be processed by 2413 the IP module, thus letting communication survive the overwhelming 2414 situation. On the other hand, the idea of flushing a somewhat large 2415 portion of the buffer is to avoid flushing always the same set of 2416 packets. 2418 4.1.2.3. A more selective fragment buffer flushing strategy 2420 One of the difficulties in implementing counter-measures for the 2421 fragmentation attacks described in this document is that it is 2422 difficult to perform validation checks on the received fragments. 2423 For instance, the fragment on which validity checks could be 2424 performed, the first fragment, may be not the first fragment to 2425 arrive at the destination host. 2427 Fragments can not only arrive out of order because of packet 2428 reordering performed by the network, but also because the system (or 2429 systems) that fragmented the IP datagram may indeed transmit the 2430 fragments out of order. A notable example of this is the Linux 2431 TCP/IP stack, which transmits the fragments in reverse order. 2433 o This means that we cannot enforce checks on the fragments for 2434 which we allocate reassembly resources, as the first fragment we 2435 receive for a given packet may be some other fragment than the 2436 first one (the one with an Fragment Offset of 0). 2438 However, at the point in which we decide to free some space in the 2439 fragment buffer, some refinements can be done to the flushing policy. 2440 The first thing we would like to do is to stop different types of 2441 traffic from interfering with each other. This means, in principle, 2442 that we do not want fragmented UDP traffic to interfere with 2443 fragmented TCP traffic. In order to implement this traffic 2444 separation for the different protocols, a different fragment buffer 2445 would be needed, in principle, for each of the 256 different 2446 protocols that can be encapsulated in an IP datagram. 2448 We believe a tradeoff is to implement two separate fragment buffers: 2449 one for IP datagrams that encapsulate IPsec packets, and another for 2450 the rest of the traffic. This basically means that traffic not 2451 protected by IPsec will not interfere with those flows of 2452 communication that are being protected by IPsec. 2454 The processing of each of these two different fragment buffers would 2455 be completely independent from each other. In the case of the IPsec 2456 fragment buffer, when the buffer needs to be flushed, the following 2457 refined policy could be applied: 2459 o First, for each packet for which the IPsec header has been 2460 received, check that the SPI field of the IPsec header corresponds 2461 to an existing IPsec Security Association (SA), and probably also 2462 check that the IPsec sequence number is valid. If the check 2463 fails, drop all the fragments that correspond to this packet. 2465 o Second, if the fragment buffer still needs to be flushed, drop all 2466 the fragments that correspond to packets for which the full IPsec 2467 header has not yet been received. The number of packets for which 2468 this flushing is performed depends on the amount of free space 2469 that needs to be created. 2471 o Third, if after flushing packets with invalid IPsec information 2472 (First step), and packets on which validation checks could not be 2473 performed (Second step), there is still not enough space in the 2474 fragment buffer, drop all the fragments that correspond to packets 2475 that passed the checks of the first step, until the necessary free 2476 space is created. 2478 The rationale behind this policy is that, at the point of flushing 2479 the fragment buffer, we prefer to keep those packets on which we 2480 could successfully perform a number of validation checks, over those 2481 packets on which those checks failed, or the checks could not even be 2482 performed. 2484 By checking both the IPsec SPI and the IPsec sequence number, it is 2485 virtually impossible for an attacker that is off-path to perform a 2486 Denial of Service attack to communication flows being protected by 2487 IPsec. 2489 Unfortunately, some IP implementations (such as that in Linux 2490 [Linux2006]), when performing fragmentation, send the corresponding 2491 fragments in reverse order. In such cases, at the point of flushing 2492 the fragment buffer, legitimate fragments will receive the same 2493 treatment as the possible forged fragments. 2495 This refined flushing policy provides an increased level of 2496 protection against this type of resource exhaustion attack, while not 2497 making the situation of out-of-order IPsec-secured traffic worse than 2498 with the simplified flushing policy described in the previous 2499 section. 2501 4.1.2.4. Reducing the fragment timeout 2503 RFC 1122 [RFC1122] states that the reassembly timeout should be a 2504 fixed value between 60 and 120 seconds. The rationale behind these 2505 long timeout values is that they should accommodate any path 2506 characteristics, such as long-delay paths. However, it must be noted 2507 that this timer is really measuring inter-fragment delays, or, more 2508 specifically, fragment jitter. 2510 If all fragments take paths of similar characteristics, the inter- 2511 fragment delay will usually be, at most, a few seconds. 2512 Nevertheless, even if fragments take different paths of different 2513 characteristics, the recommended 60 to 120 seconds are, in practice, 2514 excessive. 2516 Some systems have already reduced the fragment timeout to 30 seconds 2517 [Linux2006]. The fragment timeout could probably be further reduced 2518 to approximately 15 seconds; although further research on this issue 2519 is necessary. 2521 It should be noted that in network scenarios of long-delay and high- 2522 bandwidth (usually referred to as "Long-Fat Networks"), using a long 2523 fragment timeout would likely increase the probability of collision 2524 of IP ID numbers. Therefore, in such scenarios it is highly 2525 desirable to avoid the use of fragmentation with techniques such as 2526 PMTUD [RFC1191] or PLPMTUD [RFC4821]. 2528 4.1.2.5. Counter-measure for some IDS evasion techniques 2530 [Shankar2003] introduces a technique named "Active Mapping" that 2531 prevents evasion of a NIDS by acquiring sufficient knowledge about 2532 the network being monitored, to assess which packets will arrive at 2533 the intended recipient, and how they will be interpreted by it. 2534 [Novak2005] describes some techniques that are applied by the Snort 2535 NIDS to avoid evasion. 2537 4.1.2.6. Counter-measure for firewall-rules bypassing 2539 One of the classical techniques to bypass firewall rules involves 2540 sending packets in which the header of the encapsulated protocol is 2541 fragmented. Even when it would be legal (as far as the IETF 2542 specifications are concerned) to receive such a packets, the MTUs of 2543 the network technologies used in practice are not that small to 2544 require the header of the encapsulated protocol to be fragmented. 2545 Therefore, the system performing reassembly should drop all packets 2546 which fragment the upper-layer protocol header, and this event should 2547 be logged (e.g., a counter could be incremented to reflect the packet 2548 drop). The necessary information to perform this check could be 2549 stored by the IP module together with the rest of the upper-layer 2550 protocol information. 2552 Additionally, given that many middle-boxes such as firewalls create 2553 state according to the contents of the first fragment of a given 2554 packet, it is best that, in the event an end-system receives 2555 overlapping fragments, it honors the information contained in the 2556 fragment that was received first. 2558 RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass 2559 firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. 2561 4.2. Forwarding 2563 4.2.1. Precedence-ordered queue service 2565 Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should 2566 implement precedence-ordered queue service. This means that when a 2567 packet is selected for output on a (logical) link, the packet of 2568 highest precedence that has been queued for that link is sent. 2569 Section 5.3.3.2 of RFC 1812 advices routers to default to maintaining 2570 strict precedence-ordered service. 2572 Unfortunately, given that it is trivial to forge the IP precedence 2573 field of the IP header, an attacker could simply forge a high 2574 precedence number in the packets it sends, to illegitimately get 2575 better network service. If precedence-ordered queued service is not 2576 required in a particular network infrastructure, it should be 2577 disabled, and thus all packets would receive the same type of 2578 service, despite the values in their Type of Service or 2579 Differentiated Services fields. 2581 When Precedence-ordered queue service is required in the network 2582 infrastructure, in order to mitigate the attack vector discussed in 2583 the previous paragraph, edge routers or switches should be configured 2584 to police and remark the Type of Service or Differentiated Services 2585 values, according to the type of service at which each end-system has 2586 been allowed to send packets. 2588 Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT 2589 change precedence settings on packets it did not originate". 2590 However, given the security implications of the Precedence field, it 2591 is fair for routers, switches or other middle-boxes, particularly 2592 those in the network edge, to overwrite the Type of Service (or 2593 Differentiated Services) field of the packets they are forwarding, 2594 according to a configured network policy. 2596 Section 5.3.3.1 and Section 5.3.6 of RFC 1812 states that if 2597 precedence-ordered queue service is implemented and enabled, the 2598 router "MUST NOT discard a packet whose precedence is higher than 2599 that of a packet that is not discarded". While this recommendation 2600 makes sense given the semantics of the Precedence field, it is 2601 important to note that it would be simple for an attacker to send 2602 packets with forged high Precedence value to congest some internet 2603 router(s), and cause all (or most) traffic with a lower Precedence 2604 value to be discarded. 2606 4.2.2. Weak Type of Service 2608 Section 5.2.4.3 of RFC 1812 describes the algorithm for determining 2609 the next-hop address (i.e., the forwarding algorithm). Bullet 3, 2610 "Weak TOS", addresses the case in which routes contain a "type of 2611 service" attribute. It states that in case a packet contains a non- 2612 default TOS (i.e., 0000), only routes with the same TOS or with the 2613 default TOS should be considered for forwarding that packet. 2614 However, this means that among the longest match routes for a given 2615 in packet are routes with some TOS other than the one contained in 2616 the received packet, and no routes with the default TOS, the 2617 corresponding packet would be dropped. This may or may not be a 2618 desired behavior. 2620 An alternative to this would be to, in the case among the "longest 2621 match" routes there are only routes with non-default type of services 2622 which do not match the TOS contained in the received packet, to use a 2623 route with any other TOS. While this route would most likely not be 2624 able to address the type of service requested by packet, it would, at 2625 least, provide a "best effort" service. 2627 It must be noted that Section 5.3.2 of RFC 1812 allows for routers 2628 for not honoring the TOS field. Therefore, the proposed alternative 2629 behavior is still compliant with the IETF specifications. 2631 o While officially specified in the RFC series, TOS-based routing is 2632 not widely deployed in the Internet. 2634 4.2.3. Address Resolution 2636 In the case of broadcast link-layer technologies, in order for a 2637 system to transfer an IP datagram it must usually first map an IP 2638 address to the corresponding link-layer address (for example, by 2639 means of the ARP protocol [RFC0826]) . This means that while this 2640 operation is being performed, the packets that would require such a 2641 mapping would need to be kept in memory. This may happen both in the 2642 case of hosts and in the case of routers. 2644 This situation might be exploited by an attacker, which could send a 2645 large amount of packets to a non-existent host which would supposedly 2646 be directly connected to the attacked router. While trying to map 2647 the corresponding IP address into a link-layer address, the attacked 2648 router would keep in memory all the packets that would need to make 2649 use of that link-layer address. At the point in which the mapping 2650 function times out, depending on the policy implemented by the 2651 attacked router, only the packet that triggered the call to the 2652 mapping function might be dropped. In that case, the same operation 2653 would be repeated for every packet destined to the non-existent host. 2654 Depending on the timeout value for the mapping function, this 2655 situation might lead to the router buffers to run out of free space, 2656 with the consequence that incoming legitimate packets would have to 2657 be dropped, or that legitimate packets already stored in the router's 2658 buffers might get dropped. Both of these situations would lead 2659 either to a complete Denial of Service, or to a degradation of the 2660 network service. 2662 One counter-measure to this problem would be to drop, at the point 2663 the mapping function times out all the packets destined to the 2664 address that timed out. In addition, a "negative cache entry" might 2665 be kept in the module performing the matching function, so that for 2666 some amount of time, the mapping function would return an error when 2667 the IP module requests to perform a mapping for some address for 2668 which the mapping has recently timed out. 2670 o A common implementation strategy for routers is that when a packet 2671 is received that requires an ARP request to be performed before 2672 the packet can be forwarded, the packet is dropped and the router 2673 is then engaged in the ARP procedure. 2675 4.2.4. Dropping packets 2677 In some scenarios, it may be necessary for a host or router to drop 2678 packets from the output queue. In the event one of such packets 2679 happens to be an IP fragment, and there were other fragments of the 2680 same packet in the queue, those other fragments should also be 2681 dropped. The rationale for this policy is that it is nonsensical to 2682 spend system resources on those other fragments, because, as long as 2683 one fragment is missing, it will be impossible for the receiving 2684 system to reassemble them into a complete IP datagram. 2686 Some systems have been known to drop just a subset of fragments of a 2687 given datagram, leading to a denial of service condition, as only a 2688 subset of all the fragments of the packets were actually transferred 2689 to the next hop. 2691 4.3. Addressing 2693 4.3.1. Unreachable addresses 2695 It is important to understand that while there are some addresses 2696 that are supposed to be unreachable from the public Internet (such as 2697 those described in RFC 1918 [RFC1918], or the "loopback" address), 2698 there are a number of tricks an attacker can perform to reach those 2699 IP addresses that would otherwise be unreachable (e.g., exploit the 2700 LSRR or SSRR IP options). Therefore, when applicable, packet 2701 filtering should be performed at organizational network boundary to 2702 assure that those addresses will be unreachable. 2704 [RFC5735] provides a summary of special use IPv4 addresses. 2706 4.3.2. Private address space 2708 The Internet Assigned Numbers Authority (IANA) has reserved the 2709 following three blocks of the IP address space for private internets: 2711 o 10.0.0.0 - 10.255.255.255 (10/8 prefix) 2713 o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 2714 o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 2716 Use of these address blocks is described in RFC 1918 [RFC1918]. 2718 Where applicable, packet filtering should be performed at the 2719 organizational perimeter to assure that these addresses are not 2720 reachable from outside the enterprise network. 2722 4.3.3. Class D addresses (224/4 address block) 2724 The Class D addresses correspond to the 224/4 address block, and are 2725 used for Internet multicast. Therefore, if a packet is received with 2726 a Class D address as the Source Address, it should be dropped, and 2727 this event should be logged (e.g., a counter could be incremented to 2728 reflect the packet drop). Additionally, if an IP packet with a 2729 multicast Destination Address is received for a connection-oriented 2730 protocol (e.g., TCP), the packet should be dropped, and this event 2731 should be logged (e.g., a counter could be incremented to reflect the 2732 packet drop). 2734 4.3.4. Class E addresses (240/4 address block) 2736 The Class E addresses correspond to the 240/4 address block, and are 2737 currently reserved for experimental use. As a result, a number of 2738 implementations discard packets that contain a Class E address as the 2739 Source Address or Destination Address. 2741 However, there exists ongoing work to reclassify the Class E (240/4) 2742 address block as usable unicast address spaces [Fuller2008a] 2743 [I-D.fuller-240space] [I-D.wilson-class-e]. Therefore, we recommend 2744 implementations to accept addresses in the 240/4 block as valid 2745 addresses for the Source Address and Destination Address. 2747 It should be noted that the broadcast address 255.255.255.255 still 2748 must be treated as indicated in Section 4.3.7 of this document. 2750 4.3.5. Broadcast and multicast addresses, and connection-oriented 2751 protocols 2753 For connection-oriented protocols, such as TCP, shared state is 2754 maintained between only two endpoints at a time. Therefore, if an IP 2755 packet with a multicast (or broadcast) Destination Address is 2756 received for a connection-oriented protocol (e.g., TCP), the packet 2757 should be dropped, and this event should be logged (e.g., a counter 2758 could be incremented to reflect the packet drop). 2760 4.3.6. Broadcast and network addresses 2762 Originally, the IETF specifications did not permit IP addresses to 2763 have the value 0 or -1 for any of the Host number, network number, or 2764 subnet number fields, except for the cases indicated in Section 2765 4.3.7. However, this changed fundamentally with the deployment of 2766 Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a 2767 system cannot know a priori what the subnet mask is for a particular 2768 IP address. 2770 Many systems now allow administrators to use the values 0 or -1 for 2771 those fields. Despite that according to the IETF specifications 2772 these addresses are illegal, modern IP implementations should 2773 consider these addresses to be valid. 2775 4.3.7. Special Internet addresses 2777 RFC 1812 [RFC1812] discusses the use of some special internet 2778 addresses, which is of interest to perform some sanity checks on the 2779 Source Address and Destination Address fields of an IP packet. It 2780 uses the following notation for an IP address: 2782 { , } 2784 o RFC 1122 [RFC1122] contained a similar discussion of special 2785 internet addresses, including some of the form { , 2786 , }. However, as explained in 2787 Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number 2788 is clearly an extension of the network prefix and cannot be 2789 interpreted without the remainder of the prefix. 2791 {0, 0} 2793 This address means "this host on this network". It is meant to be 2794 used only during the initialization procedure, by which the host 2795 learns its own IP address. 2797 If a packet is received with 0.0.0.0 as the Source Address for any 2798 purpose other than bootstrapping, the corresponding packet should be 2799 silently dropped, and this event should be logged (e.g., a counter 2800 could be incremented to reflect the packet drop). If a packet is 2801 received with 0.0.0.0 as the Destination Address, it should be 2802 silently dropped, and this event should be logged (e.g., a counter 2803 could be incremented to reflect the packet drop). 2805 {0, Host number} 2807 This address means "the specified host, in this network". As in the 2808 previous case, it is meant to be used only during the initialization 2809 procedure by which the host learns its own IP address. If a packet 2810 is received with such an address as the Source Address for any 2811 purpose other than bootstrapping, it should be dropped, and this 2812 event should be logged (e.g., a counter could be incremented to 2813 reflect the packet drop). If a packet is received with such an 2814 address as the Destination Address, it should be dropped, and this 2815 event should be logged (e.g., a counter could be incremented to 2816 reflect the packet drop). 2818 {-1, -1} 2820 This address is the local broadcast address. It should not be used 2821 as a source IP address. If a packet is received with 255.255.255.255 2822 as the Source Address, it should be dropped, and this event should be 2823 logged (e.g., a counter could be incremented to reflect the packet 2824 drop). 2826 o Some systems, when receiving an ICMP echo request, for example, 2827 will use the Destination Address in the ICMP echo request packet 2828 as the Source Address of the response they send (in this case, an 2829 ICMP echo reply). Thus, when such systems receive a request sent 2830 to a broadcast address, the Source Address of the response will 2831 contain a broadcast address. This should be considered a bug, 2832 rather than a malicious use of the limited broadcast address. 2834 {Network number, -1} 2836 This is the directed broadcast to the specified network. As 2837 recommended by RFC 2644 [RFC2644], routers should not forward 2838 network-directed broadcasts. This avoids the corresponding network 2839 from being utilized as, for example, a "smurf amplifier" [CERT1998a]. 2841 As noted in Section 4.3.6 of this document, many systems now allow 2842 administrators to configure these addresses as unicast addresses for 2843 network interfaces. In such scenarios, routers should forward these 2844 addresses as if they were traditional unicast addresses. 2846 In some scenarios a host may have knowledge about a particular IP 2847 address being a network-directed broadcast address, rather than a 2848 unicast address (e.g., that IP address is configured on the local 2849 system as a "broadcast address"). In such scenarios, if a system can 2850 infer the Source Address of a received packet is a network-directed 2851 broadcast address, the packet should be dropped, and this event 2852 should be logged (e.g., a counter could be incremented to reflect the 2853 packet drop). 2855 As noted in Section 4.3.6 of this document, with the deployment of 2856 CIDR [RFC4632], it may be difficult for a system to infer whether a 2857 particular IP address that does not belong to a directly attached 2858 subnet is a broadcast address. 2860 {127, any} 2862 This is the internal host loopback address. Any packet that arrives 2863 on any physical interface containing this address as the Source 2864 Address, the Destination Address, or as part of a source route 2865 (either LSRR or SSRR), should be dropped, and this event should be 2866 logged (e.g., a counter could be incremented to reflect the packet 2867 drop). 2869 For example, packets with a Destination Address in the 127.0.0.0/8 2870 address block that are received on an interface other than loopback 2871 should be silently dropped, and this event should be logged (e.g., a 2872 counter could be incremented to reflect the packet drop). Packets 2873 received on any interface other than loopback with a Source Address 2874 corresponding to the system receiving the packet should also be 2875 dropped, and this event should be logged (e.g., a counter could be 2876 incremented to reflect the packet drop). 2878 5. Security Considerations 2880 This document discusses the security implications of the Internet 2881 Protocol (IP), and discusses a number of implementation strategies 2882 that help to mitigate a number of vulnerabilities found in the 2883 protocol during the last 25 years or so. 2885 6. Acknowledgements 2887 The author would like to thank Alfred Hoenes, Joel Jaeggli, Bruno 2888 Rohee, and Andrew Yourtchenko for providing valuable comments on 2889 earlier versions of this document. 2891 This document was written by Fernando Gont on behalf of the UK CPNI 2892 (United Kingdom's Centre for the Protection of National 2893 Infrastructure), and is heavily based on the "Security Assessment of 2894 the Internet Protocol" [CPNI2008] published by the UK Centre for the 2895 Protection of National Infrastructure (CPNI). 2897 The author would like to thank Randall Atkinson, John Day, Juan 2898 Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka 2899 Savola, and Christos Zoulas for providing valuable comments on 2900 earlier versions of [CPNI2008], on which this document is based. 2902 The author would like to thank Randall Atkinson and Roque Gagliano, 2903 who generously answered a number of questions. 2905 Finally, the author would like to thank UK CPNI (formerly NISCC) for 2906 their continued support. 2908 7. References 2910 7.1. Normative References 2912 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2913 September 1981. 2915 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2916 converting network protocol addresses to 48.bit Ethernet 2917 address for transmission on Ethernet hardware", STD 37, 2918 RFC 826, November 1982. 2920 [RFC1038] St. Johns, M., "Draft revised IP security option", 2921 RFC 1038, January 1988. 2923 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 2924 MTU discovery options", RFC 1063, July 1988. 2926 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 2928 [RFC1122] Braden, R., "Requirements for Internet Hosts - 2929 Communication Layers", STD 3, RFC 1122, October 1989. 2931 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2932 November 1990. 2934 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 2935 Suite", RFC 1349, July 1992. 2937 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 2938 January 1993. 2940 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 2941 Destination Delivery", RFC 1770, March 1995. 2943 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 2944 RFC 1812, June 1995. 2946 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 2947 February 1997. 2949 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2950 "Definition of the Differentiated Services Field (DS 2951 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2952 December 1998. 2954 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2955 and W. Weiss, "An Architecture for Differentiated 2956 Services", RFC 2475, December 1998. 2958 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 2959 in Routers", BCP 34, RFC 2644, August 1999. 2961 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 2962 Configuration of IPv4 Link-Local Addresses", RFC 3927, 2963 May 2005. 2965 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2966 Discovery", RFC 4821, March 2007. 2968 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 2969 BCP 153, RFC 5735, January 2010. 2971 7.2. Informative References 2973 [Anderson2001] 2974 Anderson, J., "An Analysis of Fragmentation Attacks", 2975 Available at: http://www.ouah.org/fragma.html , 2001. 2977 [Barisani2006] 2978 Barisani, A., "FTester - Firewall and IDS testing tool", 2979 Available at: http://dev.inversepath.com/trac/ftester , 2980 2001. 2982 [Bellovin1989] 2983 Bellovin, S., "Security Problems in the TCP/IP Protocol 2984 Suite", Computer Communication Review Vol. 19, No. 2, pp. 2985 32-48, 1989. 2987 [Bellovin2002] 2988 Bellovin, S., "A Technique for Counting NATted Hosts", 2989 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 2991 [Bendi1998] 2992 Bendi, "Boink exploit", http://www.insecure.org/sploits/ 2993 95.NT.fragmentation.bonk.html , 1998. 2995 [Biondi2007] 2996 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 2997 CanSecWest 2007 Security Conference http://www.secdev.org/ 2998 conf/IPv6_RH_security-csw07.pdf, 2007. 3000 [CERT1996a] 3001 CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- 3002 Service Attack", 3003 http://www.cert.org/advisories/CA-1996-01.html, 1996. 3005 [CERT1996b] 3006 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 3007 Spoofing Attacks", 3008 http://www.cert.org/advisories/CA-1996-21.html, 1996. 3010 [CERT1996c] 3011 CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack 3012 via ping", 3013 http://www.cert.org/advisories/CA-1996-26.html, 1996. 3015 [CERT1997] 3016 CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service 3017 Attacks", http://www.cert.org/advisories/CA-1997-28.html, 3018 1997. 3020 [CERT1998a] 3021 CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- 3022 Service Attacks", 3023 http://www.cert.org/advisories/CA-1998-01.html, 1998. 3025 [CERT1998b] 3026 CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain 3027 TCP/IP Implementations", 3028 http://www.cert.org/advisories/CA-1998-13.html, 1998. 3030 [CERT1999] 3031 CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 3032 http://www.cert.org/advisories/CA-1999-17.html, 1999. 3034 [CERT2001] 3035 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 3036 TCP/IP Initial Sequence Numbers", 3037 http://www.cert.org/advisories/CA-2001-09.html, 2001. 3039 [CERT2003] 3040 CERT, "CERT Advisory CA-2003-15 Cisco IOS Interface 3041 Blocked by IPv4 Packet", 3042 http://www.cert.org/advisories/CA-2003-15.html, 2003. 3044 [CIPSO1992] 3045 CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF 3046 Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work 3047 in progress , 1992. 3049 [CIPSOWG1994] 3050 CIPSOWG, "Commercial Internet Protocol Security Option 3051 (CIPSO) Working Group", http://www.ietf.org/proceedings/ 3052 94jul/charters/cipso-charter.html, 1994. 3054 [CPNI2008] 3055 Gont, F., "Security Assessment of the Internet Protocol", 3056 http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. 3058 [Cerf1974] 3059 Cerf, V. and R. Kahn, "A Protocol for Packet Network 3060 Intercommunication", IEEE Transactions on 3061 Communications Vol. 22, No. 5, May 1974, pp. 637-648, 3062 1974. 3064 [Cisco2003] 3065 Cisco, "Cisco Security Advisory: Cisco IOS Interface 3066 Blocked by IPv4 packet", http://www.cisco.com/en/US/ 3067 products/products_security_advisory09186a00801a34c2.shtml, 3068 2003. 3070 [Cisco2008] 3071 Cisco, "Cisco IOS Security Configuration Guide, Release 3072 12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/ 3073 configuration/guide/scfipso.html, 2003. 3075 [Clark1988] 3076 Clark, D., "The Design Philosophy of the DARPA Internet 3077 Protocols", Computer Communication Review Vol. 18, No. 4, 3078 1988. 3080 [Ed3f2002] 3081 Ed3f, "Firewall spotting and networks analisys with a 3082 broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, 3083 Phile #0x0c of 0x10 http://www.phrack.org/ 3084 issues.html?issue=60&id=12&mode=txt, 2002. 3086 [FIPS1994] 3087 FIPS, "Standard Security Label for Information Transfer", 3088 Federal Information Processing Standards Publication. FIP 3089 PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ 3090 fips188.pdf, 1994. 3092 [Fuller2008a] 3093 Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The 3094 Future Begins Now", Routing SIG Meeting, 25th APNIC Open 3095 Policy Meeting, February 25 - 29 2008, Taipei, Taiwan http 3096 ://www.apnic.net/meetings/25/program/routing/ 3097 fuller-240-future.pdf, 2008. 3099 [Fyodor2004] 3100 Fyodor, "Idle scanning and related IP ID games", 3101 http://www.insecure.org/nmap/idlescan.html, 2004. 3103 [GIAC2000] 3104 GIAC, "Egress Filtering v 0.2", 3105 http://www.sans.org/y2k/egress.htm, 2000. 3107 [Gont2006] 3108 Gont, F., "Advanced ICMP packet filtering", 3109 http://www.gont.com.ar/papers/icmp-filtering.html, 2006. 3111 [Haddad2004] 3112 Haddad, I. and M. Zakrzewski, "Security Distribution for 3113 Linux Clusters", Linux 3114 Journal http://www.linuxjournal.com/article/6943, 2004. 3116 [Humble1998] 3117 Gont, F., "Nestea exploit", 3118 http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 3119 1998. 3121 [I-D.fuller-240space] 3122 Fuller, V., "Reclassifying 240/4 as usable unicast address 3123 space", draft-fuller-240space-02 (work in progress), 3124 March 2008. 3126 [I-D.ietf-tcpm-icmp-attacks] 3127 Gont, F., "ICMP attacks against TCP", 3128 draft-ietf-tcpm-icmp-attacks-10 (work in progress), 3129 January 2010. 3131 [I-D.stjohns-sipso] 3132 StJohns, M., "Common Architecture Label IPv6 Security 3133 Option (CALIPSO)", draft-stjohns-sipso-11 (work in 3134 progress), March 2009. 3136 [I-D.templin-mtuassurance] 3137 Templin, F., "Requirements for IP-in-IP Tunnel MTU 3138 Assurance", draft-templin-mtuassurance-02 (work in 3139 progress), October 2006. 3141 [I-D.wilson-class-e] 3142 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 3143 of 240/4 from "Future Use" to "Private Use"", 3144 draft-wilson-class-e-02 (work in progress), 3145 September 2008. 3147 [IANA2006a] 3148 Ether Types, 3149 "http://www.iana.org/assignments/ethernet-numbers". 3151 [IANA2006b] 3152 IP Parameters, 3153 "http://www.iana.org/assignments/ip-parameters". 3155 [IANA2006c] 3156 Protocol Numbers, 3157 "http://www.iana.org/assignments/protocol-numbers". 3159 [IRIX2008] 3160 IRIX, "IRIX 6.5 trusted_networking(7) manual page", http: 3161 //techpubs.sgi.com/library/tpl/cgi-bin/ 3162 getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ 3163 cat7/trusted_networking.z, 2008. 3165 [Jones2002] 3166 Jones, R., "A Method Of Selecting Values For the 3167 Parameters Controlling IP Fragment Reassembly", ftp:// 3168 ftp.cup.hp.com/dist/networking/briefs/ip_reass_tuning.txt, 3169 2002. 3171 [Kenney1996] 3172 Kenney, M., "The Ping of Death Page", 3173 http://www.insecure.org/sploits/ping-o-death.html, 1996. 3175 [Kent1987] 3176 Kent, C. and J. Mogul, "Fragmentation considered harmful", 3177 Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987. 3179 [Klein2007] 3180 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 3181 Predictable IP ID Vulnerability", http:// 3182 www.trusteer.com/files/ 3183 OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP 3184 _ID_Vulnerability.pdf, 2007. 3186 [Kohno2005] 3187 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 3188 Device Fingerprinting", IEEE Transactions on Dependable 3189 and Secure Computing Vol. 2, No. 2, 2005. 3191 [LBNL2006] 3192 LBNL/NRG, "arpwatch tool", http://ee.lbl.gov/, 2006. 3194 [Linux2006] 3195 The Linux Project, "http://www.kernel.org". 3197 [Microsoft1999] 3198 Microsoft, "Microsoft Security Program: Microsoft Security 3199 Bulletin (MS99-038). Patch Available for "Spoofed Route 3200 Pointer" Vulnerability", http://www.microsoft.com/ 3201 technet/security/bulletin/ms99-038.mspx, 1999. 3203 [NISCC2004] 3204 NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability 3205 Issues in TCP", 3206 http://www.uniras.gov.uk/niscc/docs/ 3207 re-20040420-00391.pdf, 2004. 3209 [NISCC2005] 3210 NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: 3211 Vulnerability Issues in ICMP packets with TCP payloads", 3212 http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf, 3213 2005. 3215 [NISCC2006] 3216 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 3217 Filtering", http://www.niscc.gov.uk/niscc/docs/ 3218 re-20060420-00294.pdf?lang=en, 2006. 3220 [Northcutt2000] 3221 Northcut, S. and Novak, "Network Intrusion Detection - An 3222 Analyst's Handbook", Second Edition New Riders Publishing, 3223 2000. 3225 [Novak2005] 3226 Novak, "Target-Based Fragmentation Reassembly", 3227 http://www.snort.org/reg/docs/target_based_frag.pdf, 3228 2005. 3230 [OpenBSD1998] 3231 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 3232 Problem", 3233 http://www.openbsd.org/advisories/sourceroute.txt, 1998. 3235 [Paxson2001] 3236 Paxson, V., Handley, M., and C. Kreibich, "Network 3237 Intrusion Detection: Evasion, Traffic Normalization, and 3238 End-to-End Protocol Semantics", USENIX Conference, 2001, 3239 2001. 3241 [Ptacek1998] 3242 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 3243 of Service: Eluding Network Intrusion Detection", 3244 http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps, 3245 1998. 3247 [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, 3248 July 1982. 3250 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 3251 Considerations for IP Fragment Filtering", RFC 1858, 3252 October 1995. 3254 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3255 E. Lear, "Address Allocation for Private Internets", 3256 BCP 5, RFC 1918, February 1996. 3258 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 3259 Network Interconnect Devices", RFC 2544, March 1999. 3261 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3262 Defeating Denial of Service Attacks which employ IP Source 3263 Address Spoofing", BCP 38, RFC 2827, May 2000. 3265 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3266 via IPv4 Clouds", RFC 3056, February 2001. 3268 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 3269 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 3271 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3272 of Explicit Congestion Notification (ECN) to IP", 3273 RFC 3168, September 2001. 3275 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 3276 Beame, C., Eisler, M., and D. Noveck, "Network File System 3277 (NFS) version 4 Protocol", RFC 3530, April 2003. 3279 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3280 Networks", BCP 84, RFC 3704, March 2004. 3282 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 3283 Network Tunneling", RFC 4459, April 2006. 3285 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3286 (CIDR): The Internet Address Assignment and Aggregation 3287 Plan", BCP 122, RFC 4632, August 2006. 3289 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3290 Errors at High Data Rates", RFC 4963, July 2007. 3292 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 3293 Mitigations", RFC 4987, August 2007. 3295 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 3296 Pignataro, "The Generalized TTL Security Mechanism 3297 (GTSM)", RFC 5082, October 2007. 3299 [SELinux2008] 3300 Security Enhanced Linux, "http://www.nsa.gov/selinux/". 3302 [Sanfilippo1998a] 3303 Sanfilippo, S., "about the ip header id", Post to Bugtraq 3304 mailing-list, Mon Dec 14 3305 1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998. 3307 [Sanfilippo1998b] 3308 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing- 3309 list http://www.kyuzz.org/antirez/papers/dumbscan.html, 3310 1998. 3312 [Sanfilippo1999] 3313 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 3314 list http://www.kyuzz.org/antirez/papers/moreipid.html, 3315 1999. 3317 [Shankar2003] 3318 Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS 3319 Evasion Without Altering Traffic", 3320 http://www.icir.org/vern/papers/activemap-oak03.pdf, 3321 2003. 3323 [Shannon2001] 3324 Shannon, C., Moore, D., and K. Claffy, "Characteristics of 3325 Fragmented IP Traffic on Internet Links", 2001. 3327 [Silbersack2005] 3328 Silbersack, M., "Improving TCP/IP security through 3329 randomization without sacrificing interoperability", 3330 EuroBSDCon 2005 Conference http://www.silby.com/ 3331 eurobsdcon05/eurobsdcon_slides.pdf, 2005. 3333 [Solaris2008] 3334 Solaris Trusted Extensions - Labeled Security for Absolute 3335 Protection, "http://www.sun.com/software/solaris/ds/ 3336 trusted_extensions.jsp#3", 2008. 3338 [Song1999] 3339 Song, D., "Frag router tool", 3340 http://www.anzen.com/research/nidsbench/. 3342 [US-CERT2001] 3343 US-CERT, "US-CERT Vulnerability Note VU#446689: Check 3344 Point FireWall-1 allows fragmented packets through 3345 firewall if Fast Mode is enabled", 3346 http://www.kb.cert.org/vuls/id/446689, 2001. 3348 [US-CERT2002] 3349 US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS 3350 discloses fragments of previous packets when Express 3351 Forwarding is enabled", 3352 http://www.kb.cert.org/vuls/id/310387, 2002. 3354 [Watson2004] 3355 Watson, P., "Slipping in the Window: TCP Reset Attacks", 3356 2004 CanSecWest Conference , 2004. 3358 [Zakrzewski2002] 3359 Zakrzewski, M. and I. Haddad, "Linux Distributed Security 3360 Module", http://www.linuxjournal.com/article/6215, 2002. 3362 [daemon91996] 3363 daemon9, route, and infinity, "IP-spoofing Demystified 3364 (Trust-Relationship Exploitation)", Phrack Magazine, 3365 Volume Seven, Issue Forty-Eight, File 14 of 3366 18 http://www.phrack.org/phrack/48/P48-14 , 1988. 3368 Appendix A. Advice and guidance to vendors 3370 Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they 3371 think they may be affected by the issues described in this document. 3372 As the lead coordination center for these issues, CPNI is well placed 3373 to give advice and guidance as required. 3375 CPNI works extensively with government departments and agencies, 3376 commercial organizations and the academic community to research 3377 vulnerabilities and potential threats to IT systems especially where 3378 they may have an impact on Critical National Infrastructure's (CNI). 3380 Other ways to contact CPNI, plus CPNI's PGP public key, are available 3381 at http://www.cpni.gov.uk . 3383 Appendix B. Changes from previous versions of the draft (to be removed 3384 by the RFC Editor before publishing this document as an 3385 RFC) 3387 B.1. Changes from draft-ietf-opsec-ip-security-01 3389 o Addresses rest of the feedback received from Andrew Yourtchenko 3390 (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) 3392 o Addresses a very thorough review by Alfred Hoenes (sent off-list) 3394 o Addresses feedback submitted by Joel Jaeggli (off-list) 3396 o Addresses feedback submitted (off-list) by Bruno Rohee. 3398 o Miscellaneous edits (centers expressions, fills missing graphics 3399 with ASCII-art, etc.) 3401 B.2. Changes from draft-ietf-opsec-ip-security-00 3403 o Addresses part of the feedback received from Andrew Yourtchenko 3404 (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) 3406 B.3. Changes from draft-gont-opsec-ip-security-01 3408 o Draft resubmitted as draft-ietf, as a result of wg consensus on 3409 adopting the document as an opsec wg item. 3411 B.4. Changes from draft-gont-opsec-ip-security-00 3413 o Fixed author's affiliation. 3415 o Added Figure 5. 3417 o Fixed a few typos. 3419 o (no technical changes) 3421 Author's Address 3423 Fernando Gont 3424 UK Centre for the Protection of National Infrastructure 3426 Email: fernando@gont.com.ar 3427 URI: http://www.cpni.gov.uk