idnits 2.17.1 draft-ietf-opsec-ip-options-filtering-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2013) is 3762 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1038 (Obsoleted by RFC 1108) -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) -- Obsolete informational reference (is this intentional?): RFC 1385 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1393 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1475 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1770 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) UTN-FRH / SI6 Networks 4 Internet-Draft R. Atkinson 5 Intended status: BCP Consultant 6 Expires: June 12, 2014 C. Pignataro 7 Cisco 8 December 9, 2013 10 Recommendations on filtering of IPv4 packets containing IPv4 options. 11 draft-ietf-opsec-ip-options-filtering-07 13 Abstract 15 This document provides advice on the filtering of IPv4 packets based 16 on the IPv4 options they contain. Additionally, it discusses the 17 operational and interoperability implications of dropping packets 18 based on the IP options they contain. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 12, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology and Conventions Used in This Document . . . . 3 56 1.2. Operational Focus . . . . . . . . . . . . . . . . . . . . 4 57 2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. General Security Implications of IP options . . . . . . . . . 5 59 3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5 60 4. Advice on the Handling of Packets with Specific IP Options . . 7 61 4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7 62 4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7 63 4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8 64 4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . . 10 65 4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 11 66 4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 12 67 4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 13 68 4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 14 69 4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 15 70 4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 16 71 4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 16 72 4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 17 73 4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 20 74 4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 22 75 4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 23 76 4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 23 77 4.17. Address Extension (Type = 147) . . . . . . . . . . . . . . 24 78 4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 25 79 4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 25 80 4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . . 26 81 4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 27 82 4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) . 28 83 4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . . 28 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 92 1. Introduction 94 This document discusses the filtering of IPv4 packets based on the 95 IPv4 options they contain. Since various protocols may use IPv4 96 options to some extent, dropping packets based on the options they 97 contain may have implications on the proper functioning of the 98 protocol. Therefore, this document attempts to discuss the 99 operational and interoperability implications of such dropping. 100 Additionally, it outlines what a network operator might do in a 101 typical enterprise or Service Provider environments. This document 102 also draws and is partly derifed from [RFC6274], which also received 103 review from the operational community. 105 We note that data seems to indicate that there is a current 106 widespread practice of blocking IPv4 optioned packets. There are 107 various plausible approaches to minimize the potential negative 108 effects of IPv4 optioned packets while allowing some options 109 semantics. One approach is to allow for specific options that are 110 expected or needed, and a default deny. A different approach is to 111 deny unneeded options and a default allow. Yet a third possible 112 approach is to allow for end-to-end semantics by ignoring options and 113 treating packets as un-optioned while in transit. Experiments and 114 currently-available data tends to support the first or third 115 approaches as more realistic. Some results of regarding the current 116 state of affairs with respect to dropping packets containing IP 117 options can be found in [MEDINA] [FONSECA]. Additionally, 118 [BREMIER-BARR] points out that the deployed Internet already has many 119 routers that do not process IP options. 121 We also note that while this document provides advice on dropping 122 packets on a "per IP option type", not all devices (routers, security 123 gateways, and firewalls) may provide this capability with such 124 granularity. Additionally, even in cases in which such functionality 125 is provided, the operator might want to specify a dropping policy 126 with a coarser granularity (rather than on a "per IP option type" 127 granularity), as indicated above. 129 Finally, in scenarios in which processing of IP options by 130 intermediate systems is not required, a widespread approach is to 131 simply ignore IP options, and process the corresponding packets as if 132 they do not contain any IP options. 134 1.1. Terminology and Conventions Used in This Document 136 The terms "fast path", "slow path", and associated relative terms 137 ("faster path" and "slower path") are loosely defined as in Section 2 138 of [RFC6398]. 140 Because of the security-oriented nature of this document, we are 141 deliberately including some historical citations. This is 142 intentional, and has the goal of explicitly retaining and showing 143 history, as well as removing ambiguity and confusion. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 1.2. Operational Focus 151 All of the recommendations in this document have been made in an 152 effort to optimise for operational community consensus, as best the 153 editors have been able to determine that. This has included not only 154 accepting feedback from public lists, but also accepting off-list 155 feedback from people at various network operators (e.g. ISPs, 156 content providers, educational institutions, commercial firms). 158 2. IP Options 160 IP options allow for the extension of the Internet Protocol. As 161 specified in [RFC0791], there are two cases for the format of an 162 option: 164 o Case 1: A single byte of option-type. 166 o Case 2: An option-type byte, an option-length byte, and the actual 167 option-data bytes. 169 IP options of Case 1 have the following syntax: 171 +-+-+-+-+-+-+-+-+- - - - - - - - - 172 | option-type | option-data 173 +-+-+-+-+-+-+-+-+- - - - - - - - - 175 The length of IP options of Case 1 is implicitly specified by the 176 option-type byte. 178 IP options of Case 2 have the following syntax: 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 181 | option-type | option-length | option-data 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 184 In this case, the option-length byte counts the option-type byte and 185 the option-length byte, as well as the actual option-data bytes. 187 All current and future options except "End of Option List" (Type = 0) 188 and "No Operation" (Type = 1), are of Class 2. 190 The option-type has three fields: 192 o 1 bit: copied flag. 194 o 2 bits: option class. 196 o 5 bits: option number. 198 The copied flag indicates whether this option should be copied to all 199 fragments in the event the packet carrying it needs to be fragmented: 201 o 0 = not copied. 203 o 1 = copied. 205 The values for the option class are: 207 o 0 = control. 209 o 1 = reserved for future use. 211 o 2 = debugging and measurement. 213 o 3 = reserved for future use. 215 This format allows for the creation of new options for the extension 216 of the Internet Protocol (IP). 218 Finally, the option number identifies the syntax of the rest of the 219 option. 221 The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the 222 currently assigned IP option numbers. 224 3. General Security Implications of IP options 226 3.1. Processing Requirements 228 Historically, most IP routers used a general-purpose CPU to process 229 IP packets and forward them towards their destination. This same CPU 230 usually also processed network management traffic (e.g., SNMP), 231 configuration commands (e.g., command line interface), and various 232 routing protocols (e.g., RIP, OSPF, BGP, IS-IS) or other control 233 protocols (e.g., RSVP, ICMP). In such architectures it has been 234 common for the general-purpose CPU also to perform any packet 235 filtering that has been enabled on the router (or router interface). 236 An IP router built using this architecture often has a significant 237 (Distributed) Denial-of-Service (DDOS) attack risk if the router 238 control plane (e.g., CPU) is overwhelmed by a large number of IPv4 239 packets that contain IPv4 options. 241 From about 1995 onwards, a growing number of IP routers have 242 incorporated specialized IP packet processing silicon (i.e., FPGA, 243 ASIC), thereby separating the IP packet forwarding function from the 244 other functions of the router. Such router architectures tend to be 245 more resilient to DDOS attacks that might be seen in the global 246 public Internet. Depending upon various implementation and 247 configuration details, routers with a silicon packet forwarding 248 engine can handle high volumes of IP packets containing IP Options 249 without any adverse impact on packet forwarding rates or on the 250 router's control plane (e.g., general-purpose CPU). Some 251 implementations have a configuration knob simply to forward all IP 252 packets containing IP Options at wire-speed in silicon as if the IP 253 packet did not contain an IP option ("ignore options & forward"). 254 Other implementations support wire-speed silicon-based packet 255 filtering, thereby enabling packets containing certain IP options to 256 be selectively dropped ("drop"), packets containing certain other IP 257 options to have those IP options ignored ("ignore options & 258 forward"), and other packets containing different IP options to have 259 those options processed, either on a general-purpose CPU or using 260 custom logic (e.g., FPGA, ASIC), while the packet is being forwarded 261 ("process option & forward"). 263 Broadly speaking, any IP packet that requires processing by an IP 264 router's general-purpose CPU can be a DDOS risk to that router's 265 general-purpose CPU (and thence to the router itself). However, at 266 present, the particular architectural and engineering details of the 267 particular IP router being considered are important to understand 268 when evaluating the operational security risks associated with a 269 particular IP packet type or IP option type. 271 Operators are urged to consider IP option filtering and IP option 272 handling capabilities of potential IP routers as they make deployment 273 decisions in future. 275 Additional considerations for protecting the control plane from 276 packets containing IP Options can be found in [RFC6192]. 278 Finally, in addition to advice to operators, this document also 279 provides advice to router, security gateway, and firewall 280 implementers in terms of providing the capability to filter packets 281 with different granularities: both on a "per IP option type" 282 granularity (to maximize flexibility) as well as more coarse filters 283 (to minimize configuration complexity). 285 4. Advice on the Handling of Packets with Specific IP Options 287 The following subsections contain a description of each of the IP 288 options that have so far been specified, a discussion of possible 289 interoperability implications if packets containing such options are 290 dropped, and specific advice on whether to drop packets containing 291 these options in a typical enterprise or Service Provider 292 environment. 294 4.1. End of Option List (Type = 0) 296 4.1.1. Uses 298 This option is used to indicate the "end of options" in those cases 299 in which the end of options would not coincide with the end of the 300 Internet Protocol Header. 302 4.1.2. Option Specification 304 Specified in RFC 791 [RFC0791]. 306 4.1.3. Threats 308 No specific security issues are known for this IPv4 option. 310 4.1.4. Operational and Interoperability Impact if Blocked 312 Packets containing any IP options are likely to include an End of 313 Option List. Therefore, if packets containing this option are 314 dropped, it is very likely that legitimate traffic is blocked. 316 4.1.5. Advice 318 Routers, security gateways, and firewalls SHOULD NOT drop packets 319 because they contain this option. 321 4.2. No Operation (Type = 1) 323 4.2.1. Uses 325 The no-operation option is basically meant to allow the sending 326 system to align subsequent options in, for example, 32-bit 327 boundaries. 329 4.2.2. Option Specification 331 Specified in RFC 791 [RFC0791]. 333 4.2.3. Threats 335 No specific security issues are known for this IPv4 option. 337 4.2.4. Operational and Interoperability Impact if Blocked 339 Packets containing any IP options are likely to include a No 340 Operation option. Therefore, if packets containing this option are 341 dropped, it is very likely that legitimate traffic is blocked. 343 4.2.5. Advice 345 Routers, security gateways, and firewalls SHOULD NOT drop packets 346 because they contain this option. 348 4.3. Loose Source and Record Route (LSRR) (Type = 131) 350 RFC 791 states that this option should appear at most once in a given 351 packet. Thus, if a packet contains more than one LSRR option, it 352 should be dropped, and this event should be logged (e.g., a counter 353 could be incremented to reflect the packet drop). Additionally, 354 packets containing a combination of LSRR and SSRR options should be 355 dropped, and this event should be logged (e.g., a counter could be 356 incremented to reflect the packet drop). 358 4.3.1. Uses 360 This option lets the originating system specify a number of 361 intermediate systems a packet must pass through to get to the 362 destination host. Additionally, the route followed by the packet is 363 recorded in the option. The receiving host (end-system) must use the 364 reverse of the path contained in the received LSRR option. 366 The LSSR option can be of help in debugging some network problems. 367 Some ISP (Internet Service Provider) peering agreements require 368 support for this option in the routers within the peer of the ISP. 370 4.3.2. Option Specification 372 Specified in RFC 791 [RFC0791]. 374 4.3.3. Threats 376 The LSRR option has well-known security implications [RFC6274]. 377 Among other things, the option can be used to: 379 o Bypass firewall rules. 381 o Reach otherwise unreachable internet systems. 383 o Establish TCP connections in a stealthy way. 385 o Learn about the topology of a network. 387 o Perform bandwidth-exhaustion attacks. 389 Of these attack vectors, the one that has probably received least 390 attention is the use of the LSRR option to perform bandwidth 391 exhaustion attacks. The LSRR option can be used as an amplification 392 method for performing bandwidth-exhaustion attacks, as an attacker 393 could make a packet bounce multiple times between a number of systems 394 by carefully crafting an LSRR option. 396 This is the IPv4-version of the IPv6 amplification attack that was 397 widely publicized in 2007 [Biondi2007]. The only difference is 398 that the maximum length of the IPv4 header (and hence the LSRR 399 option) limits the amplification factor when compared to the IPv6 400 counter-part. 402 Additionally, some implementations have been found to fail to include 403 proper sanity checks on the LSRR option, thus leading to security 404 issues. These specific issues are believed to be solved in all 405 modern implementations. 407 [Microsoft1999] is a security advisory about a vulnerability 408 arising from improper validation of the Pointer field of the LSRR 409 option. 411 Finally, we note that some systems were known for providing a system- 412 wide toggle to enable support for this option for those scenarios in 413 which this option is required. However, improper implementation of 414 such system-wide toggle caused those systems to support the LSRR 415 option even when explicitly configured not to do so. 417 [OpenBSD1998] is a security advisory about an improper 418 implementation of such a system-wide toggle in 4.4BSD kernels. 419 This issue was resolved in later versions of the corresponding 420 operating system. 422 4.3.4. Operational and Interoperability Impact if Blocked 424 Network troubleshooting techniques that may employ the LSRR option 425 (such as ping or traceroute with the appropriate arguments) would 426 break when using the LSRR option (ping and traceroute without IPv4 427 options are not impacted). Nevertheless, it should be noted that it 428 is virtually impossible to use the LSRR option for troubleshooting, 429 due to widespread dropping of packets that contain such option. 431 4.3.5. Advice 433 Routers, security gateways, and firewalls SHOULD implement an option- 434 specific configuration knob whether packets with this option are 435 dropped, packets with this IP option are forwarded as if they did not 436 contain this IP option, or packets with this option are processed and 437 forwarded as per [RFC0791]. The default setting for this knob SHOULD 438 be "drop", and the default setting MUST be documented. 440 Please note that treating packets with LSRR as if they did not 441 contain this option can result in such packets being sent to a 442 different device that the initially intended destination. With 443 appropriate ingress filtering this should not open an attack vector 444 into the infrastructure. Nonetheless, it could result in traffic 445 that would never reach the initially intended destination. Dropping 446 these packets prevents unnecessary network traffic, and does not make 447 end-to-end communication any worse. 449 4.4. Strict Source and Record Route (SSRR) (Type = 137) 451 4.4.1. Uses 453 This option allows the originating system to specify a number of 454 intermediate systems a packet must pass through to get to the 455 destination host. Additionally, the route followed by the packet is 456 recorded in the option, and the destination host (end-system) must 457 use the reverse of the path contained in the received SSRR option. 459 This option is similar to the Loose Source and Record Route (LSRR) 460 option, with the only difference that in the case of SSRR, the route 461 specified in the option is the exact route the packet must take 462 (i.e., no other intervening routers are allowed to be in the route). 464 The SSSR option can be of help in debugging some network problems. 465 Some ISP (Internet Service Provider) peering agreements require 466 support for this option in the routers within the peer of the ISP. 468 4.4.2. Option Specification 470 Specified in RFC 791 [RFC0791]. 472 4.4.3. Threats 474 The SSRR option has the same security implications as the LSRR 475 option. Please refer to Section 4.3 for a discussion of such 476 security implications. 478 4.4.4. Operational and Interoperability Impact if Blocked 480 Network troubleshooting techniques that may employ the SSRR option 481 (such as ping or traceroute with the appropriate arguments) would 482 break when using the SSRR option (ping and traceroute without IPv4 483 options are not impacted). Nevertheless, it should be noted that it 484 is virtually impossible to use the SSRR option for trouble-shooting, 485 due to widespread dropping of packets that contain such option. 487 4.4.5. Advice 489 Routers, security gateways, and firewalls SHOULD implement an option- 490 specific configuration knob whether packets with this option are 491 dropped, packets with this IP option are forwarded as if they did not 492 contain this IP option, or packets with this option are processed and 493 forwarded as per [RFC0791]. The default setting for this knob SHOULD 494 be "drop", and the default setting MUST be documented. 496 Please note that treating packets with SSRR as if they did not 497 contain this option can result in such packets being sent to a 498 different device that the initially intended destination. With 499 appropriate ingress filtering this should not open an attack vector 500 into the infrastructure. Nonetheless, it could result in traffic 501 that would never reach the initially intended destination. Dropping 502 these packets prevents unnecessary network traffic, and does not make 503 end-to-end communication any worse. 505 4.5. Record Route (Type = 7) 507 4.5.1. Uses 509 This option provides a means to record the route that a given packet 510 follows. 512 4.5.2. Option Specification 514 Specified in RFC 791 [RFC0791]. 516 4.5.3. Threats 518 This option can be exploited to map the topology of a network. 519 However, the limited space in the IP header limits the usefulness of 520 this option for that purpose. 522 4.5.4. Operational and Interoperability Impact if Blocked 524 Network troubleshooting techniques that may employ the RR option 525 (such as ping with the RR option) would break when using the RR 526 option (ping without IPv4 options is not impacted). Nevertheless, it 527 should be noted that it is virtually impossible to use such 528 techniques due to widespread dropping of packets that contain RR 529 options. 531 4.5.5. Advice 533 Routers, security gateways, and firewalls SHOULD implement an option- 534 specific configuration knob whether packets with this option are 535 dropped, packets with this IP option are forwarded as if they did not 536 contain this IP option, or packets with this option are processed and 537 forwarded as per [RFC0791]. The default setting for this knob SHOULD 538 be "drop", and the default setting MUST be documented. 540 4.6. Stream Identifier (Type = 136) (obsolete) 542 The Stream Identifier option originally provided a means for the 16- 543 bit SATNET stream Identifier to be carried through networks that did 544 not support the stream concept. 546 However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and 547 Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. 548 Therefore, it must be ignored by the processing systems. See also 549 [IANA-IP] and [RFC6814]. 551 RFC 791 states that this option appears at most once in a given 552 datagram. Therefore, if a packet contains more than one instance of 553 this option, it should be dropped, and this event should be logged 554 (e.g., a counter could be incremented to reflect the packet drop). 556 4.6.1. Uses 558 This option is obsolete. There is no current use for this option. 560 4.6.2. Option Specification 562 Specified in RFC 791 [RFC0791], and deprecated in RFC 1122 [RFC1122] 563 and RFC 1812 [RFC1812]. This option has been formally obsoleted by 565 [RFC6814]. 567 4.6.3. Threats 569 No specific security issues are known for this IPv4 option. 571 4.6.4. Operational and Interoperability Impact if Blocked 573 None. 575 4.6.5. Advice 577 Routers, security gateways, and firewalls SHOULD drop IP packets 578 containing a Stream Identifier option. 580 4.7. Internet Timestamp (Type = 68) 582 4.7.1. Uses 584 This option provides a means for recording the time at which each 585 system (or a specified set of systems) processed this datagram, and 586 may optionally record the addresses of the systems providing the 587 timestamps. 589 4.7.2. Option Specification 591 Specified by RFC 791 [RFC0791]. 593 4.7.3. Threats 595 The timestamp option has a number of security implications [RFC6274]. 596 Among them are: 598 o It allows an attacker to obtain the current time of the systems 599 that process the packet, which the attacker may find useful in a 600 number of scenarios. 602 o It may be used to map the network topology, in a similar way to 603 the IP Record Route option. 605 o It may be used to fingerprint the operating system in use by a 606 system processing the datagram. 608 o It may be used to fingerprint physical devices, by analyzing the 609 clock skew. 611 [Kohno2005] describes a technique for fingerprinting devices by 612 measuring the clock skew. It exploits, among other things, the 613 timestamps that can be obtained by means of the ICMP timestamp 614 request messages [RFC0791]. However, the same fingerprinting method 615 could be implemented with the aid of the Internet Timestamp option. 617 4.7.4. Operational and Interoperability Impact if Blocked 619 Network troubleshooting techniques that may employ the Internet 620 Timestamp option (such as ping with the Timestamp option) would break 621 when using the Timestamp option (ping without IPv4 options is not 622 impacted). Nevertheless, it should be noted that it is virtually 623 impossible to use such techniques due to widespread dropping of 624 packets that contain Internet Timestamp options. 626 4.7.5. Advice 628 Routers, security gateways, and firewalls SHOULD drop IP packets 629 containing an Internet Timestamp option. 631 4.8. Router Alert (Type = 148) 633 4.8.1. Uses 635 The Router Alert option has the semantic "routers should examine this 636 packet more closely, if they participate in the functionality denoted 637 by the Value of the option". 639 4.8.2. Option Specification 641 The Router Alert option is defined in RFC 2113 [RFC2113] and later 642 updates to it have been clarified by RFC 5350 [RFC5350]. It contains 643 a 16-bit Value governed by an IANA registry (see [RFC5350]). 645 4.8.3. Threats 647 The security implications of the Router Alert option have been 648 discussed in detail in [RFC6398]. Basically, the Router Alert option 649 might be exploited to perform a Denial of Service (DoS) attack by 650 exhausting CPU resources at the processing routers. 652 4.8.4. Operational and Interoperability Impact if Blocked 654 Applications that employ the Router Alert option (such as RSVP 655 [RFC2205]) would break. 657 4.8.5. Advice 659 This option SHOULD be allowed only in controlled environments, where 660 the option can be used safely. [RFC6398] identifies some such 661 environments. In unsafe environments, packets containing this option 662 SHOULD be dropped. 664 A given router, security gateway, or firewall system has no way of 665 knowing a priori whether this option is valid in its operational 666 environment. Therefore, routers, security gateways, and firewalls 667 SHOULD, by default, ignore the Router Alert option. Additionally, 668 Routers, security gateways, and firewalls SHOULD have a configuration 669 setting that governs their reaction in the presence of packets 670 containing the Router Alert option. This configuration setting 671 SHOULD allow to honor and process the option, ignore the option, or 672 drop packets containing this option. 674 4.9. Probe MTU (Type = 11) (obsolete) 676 4.9.1. Uses 678 This option originally provided a mechanism to discover the Path-MTU. 679 It has been declared obsolete. 681 4.9.2. Option Specification 683 This option was originally defined in RFC 1063 [RFC1063], and was 684 obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as 685 RFC 1191 obsoletes RFC 1063 without using IP options. 687 4.9.3. Threats 689 This option is obsolete. This option could have been exploited to 690 cause a host to set its PMTU estimate to an inordinately low or an 691 inordinately high value, thereby causing performance problems. 693 4.9.4. Operational and Interoperability Impact if Blocked 695 None 697 This option is NOT employed with the modern "Path MTU Discovery" 698 (PMTUD) mechanism [RFC1191], which employs special ICMP messages 699 (Type 3, Code 4) in combination with the IP DF bit. PLPMTUD 700 [RFC4821] can perform PMTUD without the need of any special 701 packets. 703 4.9.5. Advice 705 Routers, security gateways, and firewalls SHOULD drop IP packets that 706 contain a Probe MTU option. 708 4.10. Reply MTU (Type = 12) (obsolete) 710 4.10.1. Uses 712 This option and originally provided a mechanism to discover the Path- 713 MTU. It is now obsolete. 715 4.10.2. Option Specification 717 This option was originally defined in RFC 1063 [RFC1063], and was 718 obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as 719 RFC 1191 obsoletes RFC 1063 without using IP options. 721 4.10.3. Threats 723 This option is obsolete. This option could have been exploited to 724 cause a host to set its PMTU estimate to an inordinately low or an 725 inordinately high value, thereby causing performance problems. 727 4.10.4. Operational and Interoperability Impact if Blocked 729 None 731 This option is NOT employed with the modern "Path MTU Discovery" 732 (PMTUD) mechanism [RFC1191], which employs special ICMP messages 733 (Type 3, Code 4) in combination with the IP DF bit. PLPMTUD 734 [RFC4821] can perform PMTUD without the need of any special 735 packets. 737 4.10.5. Advice 739 Routers, security gateways, and firewalls SHOULD drop IP packets that 740 contain a Reply MTU option. 742 4.11. Traceroute (Type = 82) 744 4.11.1. Uses 746 This option originally provided a mechanism to trace the path to a 747 host. 749 4.11.2. Option Specification 751 This option was originally specified by RFC 1393 [RFC1393] as 752 "experimental", and it was never widely deployed on the public 753 Internet. This option has been formally obsoleted by [RFC6814]. 755 4.11.3. Threats 757 This option is obsolete. Because this option required each router in 758 the path both to provide special processing and to send an ICMP 759 message, it could have been exploited to perform a Denial of Service 760 (DoS) attack by exhausting CPU resources at the processing routers. 762 4.11.4. Operational and Interoperability Impact if Blocked 764 None 766 4.11.5. Advice 768 Routers, security gateways, and firewalls SHOULD drop IP packets that 769 contain a Traceroute option. 771 4.12. DoD Basic Security Option (Type = 130) 773 4.12.1. Uses 775 This option is used by Multi-Level-Secure (MLS) end-systems and 776 intermediate systems in specific environments to [RFC1108]: 778 o Transmit from source to destination in a network standard 779 representation the common security labels required by computer 780 security models [Landwehr81], 782 o validate the datagram as appropriate for transmission from the 783 source and delivery to the destination, and, 785 o ensure that the route taken by the datagram is protected to the 786 level required by all protection authorities indicated on the 787 datagram. 789 The DoD Basic Security Option (BSO) was implemented in IRIX 790 [IRIX2008] and is currently implemented in a number of operating 791 systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris 792 [Solaris2008], and Cisco IOS [Cisco-IPSO]). It is also currently 793 deployed in a number of high-security networks. These networks are 794 typically either in physically secure locations, protected by 795 military/governmental communications security equipment, or both. 796 Such networks are typically built using commercial off-the-shelf 797 (COTS) IP routers and Ethernet switches, but are not normally 798 interconnected with the global public Internet. Multi-Level Secure 799 (MLS) systems are much more widely deployed now than they were at the 800 time the then-IESG decided to remove IPSO (IP Security Options) from 801 the IETF standards-track. Since nearly all MLS systems also support 802 IPSO BSO and IPSO ESO, this option is believed to have more 803 deployment now than when the IESG removed this option from the IETF 804 standards-track. [RFC5570] describes a similar option recently 805 defined for IPv6 and has much more detailed explanations of how 806 sensitivity label options are used in real-world deployments. 808 4.12.2. Option Specification 810 It is specified by RFC 1108 [RFC1108]], which obsoleted RFC 1038 811 [RFC1038] (which in turn obsoleted the Security Option defined in RFC 812 791 [RFC0791]). 814 RFC 791 [RFC0791] defined the "Security Option" (Type = 130), 815 which used the same option type as the DoD Basic Security option 816 discussed in this section. Later, RFC 1038 [RFC1038] revised the 817 IP security options, and in turn was obsoleted by RFC 1108 818 [RFC1108]. The "Security Option" specified in RFC 791 is 819 considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and 820 Section 4.2.2.1 of RFC 1812 [RFC1812], and therefore the 821 discussion in this section is focused on the DoD Basic Security 822 option specified by RFC 1108 [RFC1108]. 824 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 825 this option". 827 Some private IP networks consider IP router-based per-interface 828 selective filtering of packets based on (a) the presence of an 829 IPSO option (including BSO and ESO) and (b) based on the contents 830 of that IPSO option to be important for operational security 831 reasons. The recent IPv6 CALIPSO option specification discusses 832 this in additional detail, albeit in an IPv6 context [RFC5570]. 834 Such private IP networks commonly are built using both commercial 835 and open-source products - for hosts, guards, firewalls, switches, 836 routers, etc. Some commercial IP routers support this option, as 837 do some IP routers which are built on top of Multi-Level Secure 838 (MLS) operating systems (e.g., on top of Trusted Solaris 839 [Solaris2008] or Security-Enhanced Linux [SELinux2008]). 841 For example, many Cisco routers that run Cisco IOS include support 842 for selectively filtering packets that contain the IP Security 843 Options (IPSO) with per-interface granularity. This capability 844 has been present in many Cisco routers since the early 1990s 845 [Cisco-IPSO-Cmds]. Some government sector products reportedly 846 also support the IP Security Options (IPSO), for example CANEWARE 847 [RFC4949]. 849 Support for the IPSO Basic Security Option also is included in the 850 "IPsec Configuration Policy Information Model" [RFC3585] and in 851 the "IPsec Security Policy Database Configuration MIB" [RFC4807]. 852 Section 4.6.1 of the IP Security Domain of Interpretation 853 [RFC2407] includes support for labeled IPsec security associations 854 compatible with the IP Security Options. 856 4.12.3. Threats 858 Presence of this option in a packet does not by itself create any 859 specific new threat. Packets with this option ought not normally be 860 seen on the global public Internet. 862 4.12.4. Operational and Interoperability Impact if Blocked 864 If packets with this option are blocked or if the option is stripped 865 from the packet during transmission from source to destination, then 866 the packet itself is likely to be dropped by the receiver because it 867 isn't properly labeled. In some cases, the receiver might receive 868 the packet but associate an incorrect sensitivity label with the 869 received data from the packet whose BSO was stripped by an 870 intermediate router or firewall. Associating an incorrect 871 sensitivity label can cause the received information either to be 872 handled as more sensitive than it really is ("upgrading") or as less 873 sensitive than it really is ("downgrading"), either of which is 874 problematic. 876 4.12.5. Advice 878 A given IP router, security gateway, or firewall has no way to know a 879 priori what environment it has been deployed into. Even closed IP 880 deployments generally use exactly the same commercial routers, 881 security gateways, and firewalls that are used in the public 882 Internet. 884 Since operational problems result in environments where this option 885 is needed if either the option is dropped or IP packets containing 886 this option are dropped, but no harm results if the option is carried 887 in environments where it is not needed, the default configuration 888 SHOULD NOT (a) modify or remove this IP option or (b) drop an IP 889 packet because the IP packet contains this option. 891 A given IP router, security gateway, or firewall MAY be configured to 892 drop this option or to drop IP packets containing this option in an 893 environment known to not use this option. 895 For auditing reasons, Routers, security gateways, and firewalls 896 SHOULD be capable of logging the numbers of packets containing the 897 BSO on a per-interface basis. Also, Routers, security gateways, and 898 firewalls SHOULD be capable of dropping packets based on the BSO 899 presence as well as the BSO values. 901 4.13. DoD Extended Security Option (Type = 133) 903 4.13.1. Uses 905 This option permits additional security labeling information, beyond 906 that present in the Basic Security Option (Section 4.12), to be 907 supplied in an IP datagram to meet the needs of registered 908 authorities. 910 4.13.2. Option Specification 912 The DoD Extended Security Option (ESO) is specified by RFC 1108 913 [RFC1108]. 915 Some private IP networks consider IP router-based per-interface 916 selective filtering of packets based on (a) the presence of an 917 IPSO option (including BSO and ESO) and (b) based on the contents 918 of that IPSO option to be important for operational security 919 reasons. The recent IPv6 CALIPSO option specification discusses 920 this in additional detail, albeit in an IPv6 context [RFC5570]. 922 Such private IP networks commonly are built using both commercial 923 and open-source products - for hosts, guards, firewalls, switches, 924 routers, etc. Some commercial IP routers support this option, as 925 do some IP routers which are built on top of Multi-Level Secure 926 (MLS) operating systems (e.g., on top of Trusted Solaris 927 [Solaris2008] or Security-Enhanced Linux [SELinux2008]). 929 For example, many Cisco routers that run Cisco IOS include support 930 for selectively filtering packets that contain the IP Security 931 Options (IPSO) with per-interface granularity. This capability 932 has been present in many Cisco routers since the early 1990s 933 [Cisco-IPSO-Cmds]. Some government sector products reportedly 934 also support the IP Security Options (IPSO), for example CANEWARE 935 [RFC4949]. 937 Support for the IPSO Extended Security Option also is included in 938 the "IPsec Configuration Policy Information Model" [RFC3585] and 939 in the "IPsec Security Policy Database Configuration MIB" 940 [RFC4807]. Section 4.6.1 of the IP Security Domain of 941 Interpretation [RFC2407] includes support for labeled IPsec 942 security associations compatible with the IP Security Options. 944 4.13.3. Threats 946 Presence of this option in a packet does not by itself create any 947 specific new threat. Packets with this option ought not normally be 948 seen on the global public Internet. 950 4.13.4. Operational and Interoperability Impact if Blocked 952 If packets with this option are blocked or if the option is stripped 953 from the packet during transmission from source to destination, then 954 the packet itself is likely to be dropped by the receiver because it 955 isn't properly labeled. In some cases, the receiver might receive 956 the packet but associate an incorrect sensitivity label with the 957 received data from the packet whose ESO was stripped by an 958 intermediate router or firewall. Associating an incorrect 959 sensitivity label can cause the received information either to be 960 handled as more sensitive than it really is ("upgrading") or as less 961 sensitive than it really is ("downgrading"), either of which is 962 problematic. 964 4.13.5. Advice 966 A given IP router, security gateway, or firewall has no way to know a 967 priori what environment it has been deployed into. Even closed IP 968 deployments generally use exactly the same commercial routers, 969 security gateways, and firewalls that are used in the public 970 Internet. 972 Since operational problems result in environments where this option 973 is needed if either the option is dropped or IP packets containing 974 this option are dropped, but no harm results if the option is carried 975 in environments where it is not needed, the default configuration 976 SHOULD NOT (a) modify or remove this IP option or (b) drop an IP 977 packet because the IP packet contains this option. 979 A given IP router, security gateway, or firewall MAY be configured to 980 drop this option or to drop IP packets containing this option in an 981 environment known to not use this option. 983 For auditing reasons, Routers, security gateways, and firewalls 984 SHOULD be capable of logging the numbers of packets containing the 985 ESO on a per-interface basis. Also, Routers, security gateways, and 986 firewalls SHOULD be capable of dropping packets based on the ESO 987 presence as well as the ESO values. 989 4.14. Commercial IP Security Option (CIPSO) (Type = 134) 991 4.14.1. Uses 993 This option was proposed by the Trusted Systems Interoperability 994 Group (TSIG), with the intent of meeting trusted networking 995 requirements for the commercial trusted systems market place. 997 It was implemented in IRIX [IRIX2008] and is currently implemented in 998 a number of operating systems (e.g., Security-Enhanced Linux 999 [SELinux2008], and Solaris [Solaris2008]). It is also currently 1000 deployed in a number of high-security networks. 1002 4.14.2. Option Specification 1004 This option is specified in [I-D.ietf-cipso-ipsecurity] and 1005 [FIPS1994]. There are zero known IP router implementations of CIPSO. 1006 Several MLS operating systems support CIPSO, generally the same MLS 1007 operating systems that support IPSO. 1009 The TSIG proposal was taken to the Commercial Internet Security 1010 Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an 1011 Internet-Draft was produced [I-D.ietf-cipso-ipsecurity]. The 1012 Internet-Draft was never published as an RFC, but the proposal was 1013 later standardized by the U.S. National Institute of Standards and 1014 Technology (NIST) as "Federal Information Processing Standard 1015 Publication 188" [FIPS1994]. 1017 4.14.3. Threats 1019 Presence of this option in a packet does not by itself create any 1020 specific new threat. Packets with this option ought not normally be 1021 seen on the global public Internet. 1023 4.14.4. Operational and Interoperability Impact if Blocked 1025 If packets with this option are blocked or if the option is stripped 1026 from the packet during transmission from source to destination, then 1027 the packet itself is likely to be dropped by the receiver because it 1028 isn't properly labeled. In some cases, the receiver might receive 1029 the packet but associate an incorrect sensitivity label with the 1030 received data from the packet whose CIPSO was stripped by an 1031 intermediate router or firewall. Associating an incorrect 1032 sensitivity label can cause the received information either to be 1033 handled as more sensitive than it really is ("upgrading") or as less 1034 sensitive than it really is ("downgrading"), either of which is 1035 problematic. 1037 4.14.5. Advice 1039 Because of the design of this option, with variable syntax and 1040 variable length, it is not practical to support specialized filtering 1041 using the CIPSO information. No routers or firewalls are known to 1042 support this option. However, Routers, security gateways, and 1043 firewalls SHOULD NOT by default modify or remove this option from IP 1044 packets and SHOULD NOT by default drop packets because they contain 1045 this option. For auditing reasons, routers, security gateways, and 1046 firewalls SHOULD be capable of logging the numbers of packets 1047 containing the CIPSO on a per-interface basis. Also, Routers, 1048 security gateways, and firewalls SHOULD be capable of dropping 1049 packets based on the CIPSO presence. 1051 4.15. VISA (Type = 142) 1053 4.15.1. Uses 1055 This options was part of an experiment at USC and was never widely 1056 deployed. 1058 4.15.2. Option Specification 1060 The original option specification is not publicly available. This 1061 option has been formally obsoleted by [RFC6814]. 1063 4.15.3. Threats 1065 Not possible to determine (other the general security implications of 1066 IP options discussed in Section 3), since the corresponding 1067 specification is not publicly available. 1069 4.15.4. Operational and Interoperability Impact if Blocked 1071 None. 1073 4.15.5. Advice 1075 Routers, security gateways, and firewalls SHOULD drop IP packets that 1076 contain this option. 1078 4.16. Extended Internet Protocol (Type = 145) 1080 4.16.1. Uses 1082 The EIP option was introduced by one of the proposals submitted 1083 during the IPng efforts to address the problem of IPv4 address 1084 exhaustion. 1086 4.16.2. Option Specification 1088 Specified in [RFC1385]. This option has been formally obsoleted by 1089 [RFC6814]. 1091 4.16.3. Threats 1093 This option is obsolete. This option was used (or was intended to be 1094 used) to signal that a packet superficially similar to an IPv4 packet 1095 actually containted a different protocol, opening up the possibility 1096 that an IPv4 node that simply ignored this option would process a 1097 received packet in a manner inconsistent with the intent of the 1098 sender. There are no know threats arising from this option, other 1099 than the general security implications of IP options discussed in 1100 Section 3. 1102 4.16.4. Operational and Interoperability Impact if Blocked 1104 None. 1106 4.16.5. Advice 1108 Routers, security gateways, and firewalls SHOULD drop packets that 1109 contain this option. 1111 4.17. Address Extension (Type = 147) 1113 4.17.1. Uses 1115 The Address Extension option was introduced by one of the proposals 1116 submitted during the IPng efforts to address the problem of IPv4 1117 address exhaustion. 1119 4.17.2. Option Specification 1121 Specified in [RFC1475]. This option has been formally obsoleted by 1122 [RFC6814]. 1124 4.17.3. Threats 1126 There are no know threats arising from this option, other than the 1127 general security implications of IP options discussed in Section 3. 1129 4.17.4. Operational and Interoperability Impact if Blocked 1131 None. 1133 4.17.5. Advice 1135 Routers, security gateways, and firewalls SHOULD drop packets that 1136 contain this option. 1138 4.18. Sender Directed Multi-Destination Delivery (Type = 149) 1140 4.18.1. Uses 1142 This option originally provided unreliable UDP delivery to a set of 1143 addresses included in the option. 1145 4.18.2. Option Specification 1147 This option is specified in RFC 1770 [RFC1770]. It has been formally 1148 obsoleted by [RFC6814]. 1150 4.18.3. Threats 1152 This option could have been exploited for bandwidth-amplification in 1153 Denial of Service (DoS) attacks. 1155 4.18.4. Operational and Interoperability Impact if Blocked 1157 None. 1159 4.18.5. Advice 1161 Routers, security gateways, and firewalls SHOULD drop IP packets that 1162 contain a Sender Directed Multi-Destination Delivery option. 1164 4.19. Dynamic Packet State (Type = 151) 1166 4.19.1. Uses 1168 The Dynamic Packet State option was used to specify specified Dynamic 1169 Packet State (DPS) in the context of the differentiated service 1170 architecture. 1172 4.19.2. Option Specification 1174 The Dynamic Packet State option was specified in 1175 [I-D.stoica-diffserv-dps]. The aforementioned document was meant to 1176 be published as "Experimental", but never made it into an RFC. This 1177 option has been formally obsoleted by [RFC6814]. 1179 4.19.3. Threats 1181 Possible threats include theft of service and Denial of Service. 1182 However, we note that is option has never been widely implemented or 1183 deployed. 1185 4.19.4. Operational and Interoperability Impact if Blocked 1187 None. 1189 4.19.5. Advice 1191 Routers, security gateways, and firewalls SHOULD drop packets that 1192 contain this option. 1194 4.20. Upstream Multicast Pkt. (Type = 152) 1196 4.20.1. Uses 1198 This option was meant to solve the problem of doing upstream 1199 forwarding of multicast packets on a multi-access LAN. 1201 4.20.2. Option Specification 1203 This option was originally specified in [I-D.farinacci-bidir-pim]. 1204 It was never formally standardized in the RFC series, and was never 1205 widely implemented and deployed. Its use was obsoleted by [RFC5015], 1206 which employs a control plane mechanism to solve the problem of doing 1207 upstream forwarding of multicast packets on a multi-access LAN. This 1208 option has been formally obsoleted by [RFC6814]. 1210 4.20.3. Threats 1212 This option is obsolete. A router that ignored this option instead 1213 of processing it as specified in [I-D.farinacci-bidir-pim] could have 1214 forwarded multicast packets to an unintended destination. 1216 4.20.4. Operational and Interoperability Impact if Blocked 1218 None. 1220 4.20.5. Advice 1222 Routers, security gateways, and firewalls SHOULD drop packets that 1223 contain this option. 1225 4.21. Quick-Start (Type = 25) 1227 4.21.1. Uses 1229 This IP Option is used in the specification of Quick-Start for TCP 1230 and IP, which is an experimental mechanism that allows transport 1231 protocols, in cooperation with routers, to determine an allowed 1232 sending rate at the start and, at times, in the middle of a data 1233 transfer (e.g., after an idle period) [RFC4782]. 1235 4.21.2. Option Specification 1237 Specified in RFC 4782 [RFC4782], on the "Experimental" track. 1239 4.21.3. Threats 1241 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 1242 kinds of attacks: 1244 o Attacks to increase the routers' processing and state load, and, 1246 o attacks with bogus Quick-Start Requests to temporarily tie up 1247 available Quick-Start bandwidth, preventing routers from approving 1248 Quick-Start Requests from other connections. 1250 4.21.4. Operational and Interoperability Impact if Blocked 1252 The Quick-Start functionality would be disabled, and additional 1253 delays in e.g., TCP's connection establishment could be introduced 1254 (please see Section 4.7.2 of [RFC4782]. We note, however, that 1255 Quick-Start has been proposed as mechanism that could be of use in 1256 controlled environments, and not as a mechanism that would be 1257 intended or appropriate for ubiquitous deployment in the global 1258 Internet [RFC4782]. 1260 4.21.5. Advice 1262 A given router, security gateway, or firewall system has no way of 1263 knowing a priori whether this option is valid in its operational 1264 environment. Therefore, routers, security gateways, and firewalls 1265 SHOULD, by default, ignore the Quick Start option. Additionally, 1266 Routers, security gateways, and firewalls SHOULD have a configuration 1267 setting that governs their reaction in the presence of packets 1268 containing the Quick Start option. This configuration setting SHOULD 1269 allow to honor and process the option, ignore the option, or drop 1270 packets containing this option. The default configuration is to 1271 ignore the Quick Start option. 1273 We note that if routers in a given environment do not implement 1274 and enable the Quick-Start mechanism, only the general security 1275 implications of IP options (discussed in Section 3) would apply. 1277 4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) 1279 Section 2.5 of RFC 4727 [RFC4727] allocates an option number with all 1280 defined values of the "copy" and "class" fields for RFC3692-style 1281 experiments. This results in four distinct option type codes: 30, 1282 94, 158, and 222. 1284 4.22.1. Uses 1286 It is only appropriate to use these values in explicitly configured 1287 experiments; they MUST NOT be shipped as defaults in implementations. 1289 4.22.2. Option Specification 1291 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1292 experiments. 1294 4.22.3. Threats 1296 No specific security issues are known for this IPv4 option. 1298 4.22.4. Operational and Interoperability Impact if Blocked 1300 None. 1302 4.22.5. Advice 1304 Routers, security gateways, and firewalls SHOULD have configuration 1305 knobs for IP packets that contain RFC3692-style Experiment options to 1306 select between "ignore & forward" and "drop & log"). Otherwise, no 1307 legitimate experiment using these options will be able to traverse 1308 any IP router. 1310 Special care needs to be taken in the case of "drop & log". Devices 1311 SHOULD count the number of packets dropped, but the logging of drop 1312 events SHOULD be limited to not overburden device resources. 1314 The aforementioned configuration knob SHOULD default to "drop & log". 1316 4.23. Other IP Options 1317 4.23.1. Specification 1319 Unrecognized IP Options are to be ignored. Section 3.2.1.8 of RFC 1320 1122 [RFC1122] and Section 4.2.2.6 of RFC 1812 [RFC1812] specify this 1321 behavior as follows: 1323 RFC 1122: "The IP and transport layer MUST each interpret those IP 1324 options that they understand and silently ignore the 1325 others." 1327 RFC 1812: "A router MUST ignore IP options which it does not 1328 recognize." 1330 This document adds that unrecognized IP Options MAY also be logged. 1332 Further, routers, security gateways, and firewalls MUST provide the 1333 ability to log drop events of IP packets containing unrecognized or 1334 obsolete options. 1336 A number of additional options are listed in the "IP OPTIONS NUMBERS" 1337 IANA registry [IANA-IP] as of the time this document was last edited. 1338 Specifically: 1340 Copy Class Number Value Name 1341 ---- ----- ------ ----- ------------------------------------------- 1342 0 0 10 10 ZSU - Experimental Measurement 1343 1 2 13 205 FINN - Experimental Flow Control 1344 0 0 15 15 ENCODE - ??? 1345 1 0 16 144 IMITD - IMI Traffic Descriptor 1346 1 0 22 150 - Unassigned (Released 18 Oct. 2005) 1348 The ENCODE option (type 15) has been formally obsoleted by [RFC6814]. 1350 4.23.2. Threats 1352 The lack of open specifications for these options makes it impossible 1353 to evaluate their security implications. 1355 4.23.3. Operational and Interoperability Impact if Blocked 1357 The lack of open specifications for these options makes it impossible 1358 to evaluate the operational and interoperability impact if packets 1359 containing these options are blocked. 1361 4.23.4. Advice 1363 Routers, security gateways, and firewalls SHOULD have configuration 1364 knobs for IP packets containing these options (or other options not 1365 recognized) to select between "ignore & forward" and "drop & log"). 1367 Section 4.23.1 points out that [RFC1122] and [RFC1812] specify that 1368 unrecognized IP options MUST be ignored. However, the previous 1369 paragraph states that routers, security gateways, and firewalls 1370 SHOULD have a configuration option for dropping and logging IP 1371 packets containing unrecognized options. While is is acknowledged 1372 that this advice contradicts the previous RFC requirements, the 1373 advice in this document reflects current operational reality. 1375 Special care needs to be taken in the case of "drop & log". Devices 1376 SHOULD count the number of packets dropped, but the logging of drop 1377 events SHOULD be limited to not overburden device resources. 1379 5. IANA Considerations 1381 This document has no actions for IANA. 1383 6. Security Considerations 1385 This document provides advice on the filtering of IP packets that 1386 contain IP options. Dropping such packets can help to mitigate the 1387 security issues that arise from use of different IP options. Many of 1388 the IPv4 options listed in this document are deprecated and cause no 1389 operational impact if dropped. However, dropping packets containing 1390 IPv4 options that are in use can cause real operational problems in 1391 deployed networks. Therefore, the practice of dropping all IPv4 1392 packets containing one or more IPv4 options without careful 1393 consideration is not recommended. 1395 7. Acknowledgements 1397 The authors would like to thank (in alphabetical order) Ron Bonica, 1398 C. M. Heard, Merike Kaeo, Panos Kampanakis, Suresh Krishnan, Arturo 1399 Servin, SM, and Donald Smith for providing thorough reviews and 1400 valuable comments. Merike Kaeo also contributed text used in this 1401 document. 1403 The authors also wish to thank various network operations folks who 1404 supplied feedback on earlier versions of this document, but did not 1405 wish to be named explicitly in this document. 1407 Part of this document is initially based on the document "Security 1408 Assessment of the Internet Protocol" [CPNI2008] that is the result of 1409 a project carried out by Fernando Gont on behalf of UK CPNI (formerly 1410 NISCC). Fernando Gont would like to thank UK CPNI (formerly NISCC) 1411 for their continued support. 1413 8. References 1415 8.1. Normative References 1417 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1418 September 1981. 1420 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1421 Communication Layers", STD 3, RFC 1122, October 1989. 1423 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1424 November 1990. 1426 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1427 RFC 1812, June 1995. 1429 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1430 February 1997. 1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1433 Requirement Levels", BCP 14, RFC 2119, March 1997. 1435 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1436 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1438 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1439 Discovery", RFC 4821, March 2007. 1441 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1442 "Bidirectional Protocol Independent Multicast (BIDIR- 1443 PIM)", RFC 5015, October 2007. 1445 [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and 1446 Usage", BCP 168, RFC 6398, October 2011. 1448 [RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 1449 Options", RFC 6814, November 2012. 1451 8.2. Informative References 1453 [BREMIER-BARR] 1454 Bremier-Barr, A. and H. Levy, "Spoofing prevention 1455 method", Proceedings of IEEE InfoCom 2005 Volume 1, pp. 1456 536-547, IEEE, March 2005. 1458 [Biondi2007] 1459 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1460 CanSecWest 2007 Security Conference , 2007. 1463 [CIPSOWG1994] 1464 CIPSOWG, "Commercial Internet Protocol Security Option 1465 (CIPSO) Working Group", 1994, . 1468 [CPNI2008] 1469 Gont, F., "Security Assessment of the Internet Protocol", 1470 , 2008. 1472 [Cisco-IPSO] 1473 Cisco Systems, Inc., "Cisco IOS Security Configuration 1474 Guide, Release 12.2 - Configuring IP Security Options", 1475 2006, . 1478 [Cisco-IPSO-Cmds] 1479 Cisco Systems, Inc., "Cisco IOS Security Command 1480 Reference, Release 12.2 - IP Security Options Commands", 1481 . 1484 [FIPS1994] 1485 FIPS, "Standard Security Label for Information Transfer", 1486 Federal Information Processing Standards Publication. FIP 1487 PUBS 188, , 1994. 1490 [FONSECA] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. 1491 Stoica, "IP Options are not an option", December 2005. 1493 [I-D.farinacci-bidir-pim] 1494 Estrin, D. and D. Farinacci, "Bi-Directional Shared Trees 1495 in PIM-SM", draft-farinacci-bidir-pim (work in progress), 1496 May 1999. 1498 [I-D.ietf-cipso-ipsecurity] 1499 IETF CIPSO Working Group, "COMMERCIAL IP SECURITY OPTION 1500 (CIPSO 2.2)", draft-ietf-cipso-ipsecurity-01 (work in 1501 progress), 1992. 1503 [I-D.stoica-diffserv-dps] 1504 Stoica, I., Zhang, H., Baker, F., and Y. Bernet, "Per Hop 1505 Behaviors Based on Dynamic Packet State", 1506 draft-stoica-diffserv-dps-02 (work in progress), 1507 October 2002. 1509 [IANA-IP] Internet Assigned Numbers Authority, "IP OPTION NUMBERS", 1510 April 2011, 1511 . 1513 [IRIX2008] 1514 IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008, 1515 . 1519 [Kohno2005] 1520 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 1521 Device Fingerprinting", IEEE Transactions on Dependable 1522 and Secure Computing Vol. 2, No. 2, 2005. 1524 [Landwehr81] 1525 Landwehr, C., "Formal Models for Computer Security", ACM 1526 Computing Surveys Vol 13, No 3, September 1981, Assoc for 1527 Computing Machinery, New York, NY, USA, 1981. 1529 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 1530 Interactions Between Transport Protocols and Middleboxes", 1531 Proc. 4th ACM SIGCOMM/USENIX Conference on 1532 Internet Measurement, October 2004. 1534 [Microsoft1999] 1535 Microsoft, "Microsoft Security Program: Microsoft Security 1536 Bulletin (MS99-038). Patch Available for "Spoofed Route 1537 Pointer" Vulnerability", 1999, . 1540 [OpenBSD1998] 1541 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 1542 Problem", 1998, 1543 . 1545 [RFC1038] St. Johns, M., "Draft revised IP security option", 1546 RFC 1038, January 1988. 1548 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 1549 MTU discovery options", RFC 1063, July 1988. 1551 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 1553 [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, 1554 November 1992. 1556 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1557 January 1993. 1559 [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, 1560 June 1993. 1562 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 1563 Destination Delivery", RFC 1770, March 1995. 1565 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1566 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1567 Functional Specification", RFC 2205, September 1997. 1569 [RFC2407] Piper, D., "The Internet IP Security Domain of 1570 Interpretation for ISAKMP", RFC 2407, November 1998. 1572 [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec 1573 Configuration Policy Information Model", RFC 3585, 1574 August 2003. 1576 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1577 Start for TCP and IP", RFC 4782, January 2007. 1579 [RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. 1580 Wang, "IPsec Security Policy Database Configuration MIB", 1581 RFC 4807, March 2007. 1583 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1584 RFC 4949, August 2007. 1586 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 1587 IPv4 and IPv6 Router Alert Options", RFC 5350, 1588 September 2008. 1590 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1591 Architecture Label IPv6 Security Option (CALIPSO)", 1592 RFC 5570, July 2009. 1594 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1595 Router Control Plane", RFC 6192, March 2011. 1597 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1598 Version 4", RFC 6274, July 2011. 1600 [SELinux2008] 1601 National Security Agency, "Security-Enhanced Linux - NSA/ 1602 CSS", January 2009, 1603 . 1605 [Solaris2008] 1606 "Solaris Trusted Extensions - Labeled Security for 1607 Absolute Protection", 2008, . 1610 Authors' Addresses 1612 Fernando Gont 1613 UTN-FRH / SI6 Networks 1614 Evaristo Carriego 2644 1615 Haedo, Provincia de Buenos Aires 1706 1616 Argentina 1618 Phone: +54 11 4650 8472 1619 Email: fgont@si6networks.com 1620 URI: http://www.si6networks.com 1622 RJ Atkinson 1623 Consultant 1624 McLean, VA 22103 1625 USA 1627 Email: rja.lists@gmail.com 1629 Carlos Pignataro 1630 Cisco Systems, Inc. 1631 7200-12 Kit Creek Road 1632 Research Triangle Park, NC 27709 1633 US 1635 Email: cpignata@cisco.com