idnits 2.17.1 draft-gont-opsec-ip-options-filtering-04.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 (March 11, 2012) is 4422 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) == Missing Reference: 'ZSu' is mentioned on line 1122, but not defined == Missing Reference: 'Finn' is mentioned on line 1123, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 1124, but not defined == Missing Reference: 'Lee' is mentioned on line 1125, but not defined ** Downref: Normative reference to an Historic RFC: RFC 1108 ** Obsolete normative reference: RFC 1770 (Obsoleted by RFC 6814) ** Downref: Normative reference to an Experimental RFC: RFC 4782 == Outdated reference: A later version (-02) exists of draft-gp-intarea-obsolete-ipv4-options-iana-00 -- 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) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 6 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: September 12, 2012 C. Pignataro 7 Cisco 8 March 11, 2012 10 Recommendations on filtering of IPv4 packets containing IPv4 options 11 draft-gont-opsec-ip-options-filtering-04.txt 13 Abstract 15 This document document provides advice on the filtering of IPv4 16 packets based on the IPv4 options they contain. Additionally, it 17 discusses the operational and interoperability implications of 18 dropping packets 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 September 12, 2012. 37 Copyright Notice 39 Copyright (c) 2012 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 2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. General Security Implications of IP options . . . . . . . . . 5 58 3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5 59 4. Advice on the Handling of Packets with Specific IP Options . . 5 60 4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 5 61 4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 6 62 4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 7 63 4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . . 8 64 4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 9 65 4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 10 66 4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 11 67 4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 12 68 4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 13 69 4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 13 70 4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 14 71 4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 14 72 4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 16 73 4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 17 74 4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 19 75 4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 19 76 4.17. Address Extension (Type = 147) . . . . . . . . . . . . . . 20 77 4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 20 78 4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 21 79 4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . . 22 80 4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 22 81 4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) . 23 82 4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . . 24 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 91 1. Introduction 93 This document document discusses the filtering of IPv4 packets based 94 on the IPv4 options they contain. Since various protocols may use 95 IPv4 options to some extent, dropping packets based on the options 96 they contain may have implications on the proper functioning of the 97 protocol. Therefore, this document attempts to discuss the 98 operational and interoperability implications of such dropping. 99 Additionally, it outlines what a network operator might do in a 100 typical enterprise or Service Provider environments. 102 We note that data seems to indicate that there is a current 103 widespread practice of blocking IPv4 optioned packets. There are 104 various plausible approaches to minimize the potential negative 105 effects of IPv4 optioned packets while allowing some options 106 semantics. One approach is to allow for specific options that are 107 expected or needed, and a default deny. A different approach is to 108 deny unneeded options and a default allow. Yet a third possible 109 approach is to allow for end-to-end semantics by ignoring options and 110 treating packets as un-optioned while in transit. Experiments and 111 currently-available data tends to support the first or third 112 approaches as more realistic. Some results of regarding the current 113 state of affairs with respect to dropping packets containing IP 114 options can be found in [MEDINA]. 116 We also note that while this document provides advice on dropping 117 packets on a "per IP option type", not all devices may provide this 118 capability with such granularity. Additionally, even in cases in 119 which such functionality is provided, the operator might want to 120 specify a dropping policy with a coarser granularity (rather than on 121 a "per IP option type" granularity), as indicated above. 123 Finally, in scenarios in which processing of IP options by 124 intermediate systems is not required, a widespread approach is to 125 simply ignore IP options, and process the corresponding packets as if 126 they do not contain any IP options. 128 1.1. Terminology and Conventions Used in This Document 130 The terms "fast path", "slow path", and associated relative terms 131 ("faster path" and "slower path") are loosely defined as in Section 2 132 of [RFC6398]. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. IP Options 140 IP options allow for the extension of the Internet Protocol 142 There are two cases for the format of an option: 144 o Case 1: A single byte of option-type. 146 o Case 2: An option-type byte, an option-length byte, and the actual 147 option-data bytes. 149 IP options of Case 1 have the following syntax: 151 +-+-+-+-+-+-+-+-+- - - - - - - - - 152 | option-type | option-data 153 +-+-+-+-+-+-+-+-+- - - - - - - - - 155 The length of IP options of Case 1 is implicitly specified by the 156 option-type byte. 158 IP options of Case 2 have the following syntax: 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 161 | option-type | option-length | option-data 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 164 In this case, the option-length byte counts the option-type byte and 165 the option-length byte, as well as the actual option-data bytes. 167 All current and future options except "End of Option List" (Type = 0) 168 and "No Operation" (Type = 1), are of Class 2. 170 The option-type has three fields: 172 o 1 bit: copied flag. 174 o 2 bits: option class. 176 o 5 bits: option number. 178 The copied flag indicates whether this option should be copied to all 179 fragments in the event the packet carrying it needs to be fragmented: 181 o 0 = not copied. 183 o 1 = copied. 185 The values for the option class are: 187 o 0 = control. 189 o 1 = reserved for future use. 191 o 2 = debugging and measurement. 193 o 3 = reserved for future use. 195 This format allows for the creation of new options for the extension 196 of the Internet Protocol (IP). 198 Finally, the option number identifies the syntax of the rest of the 199 option. 201 The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the 202 currently assigned IP option numbers. 204 3. General Security Implications of IP options 206 3.1. Processing Requirements 208 Router architectures can perform IP option processing in a slower 209 path. Unless protective measures are taken, this represents a 210 potential Denial of Service (DoS) risk, as there is possibility for 211 the option processing to overwhelm the router's CPU or the protocols 212 processed in the router's slow path. Additional considerations for 213 protecting the router control plane from IP optioned packets can be 214 found in [RFC6192]. 216 4. Advice on the Handling of Packets with Specific IP Options 218 The following subsections contain a description of each of the IP 219 options that have so far been specified, a discussion of possible 220 interoperability implications if packets containing such options are 221 dropped, and specific advice on whether to drop packets containing 222 these options in a typical enterprise or Service Provider 223 environment. 225 4.1. End of Option List (Type = 0) 227 4.1.1. Uses 229 This option is used to indicate the "end of options" in those cases 230 in which the end of options would not coincide with the end of the 231 Internet Protocol Header. 233 4.1.2. Option Specification 235 Specified in RFC 791 [RFC0791]. 237 4.1.3. Threats 239 No security issues are known for this option, other than the general 240 security implications of IP options discussed in Section 3. 242 4.1.4. Operational and Interoperability Impact if Blocked 244 Packets containing any IP options are likely to include an End of 245 Option List. Therefore, if packets containing this option are 246 dropped, it is very likely that legitimate traffic is blocked. 248 4.1.5. Advice 250 Routers, security gateways, and firewalls SHOULD NOT drop packets 251 containing this option. 253 4.2. No Operation (Type = 1) 255 4.2.1. Uses 257 The no-operation option is basically meant to allow the sending 258 system to align subsequent options in, for example, 32-bit 259 boundaries. 261 4.2.2. Option Specification 263 Specified in RFC 791 [RFC0791]. 265 4.2.3. Threats 267 No security issues are known for this option, other than the general 268 security implications of IP options discussed in Section 3. 270 4.2.4. Operational and Interoperability Impact if Blocked 272 Packets containing any IP options are likely to include a No 273 Operation option. Therefore, if packets containing this option are 274 dropped, it is very likely that legitimate traffic is blocked. 276 4.2.5. Advice 278 Routers, security gateways, and firewalls SHOULD NOT drop packets 279 containing this option. 281 4.3. Loose Source and Record Route (LSRR) (Type = 131) 283 RFC 791 states that this option should appear, at most, once in a 284 given packet. Thus, if a packet contains more than one LSRR option, 285 it should be dropped, and this event should be logged (e.g., a 286 counter could be incremented to reflect the packet drop). 287 Additionally, packets containing a combination of LSRR and SSRR 288 options should be dropped, and this event should be logged (e.g., a 289 counter could be incremented to reflect the packet drop). 291 4.3.1. Uses 293 This option lets the originating system specify a number of 294 intermediate systems a packet must pass through to get to the 295 destination host. Additionally, the route followed by the packet is 296 recorded in the option. The receiving host (end-system) must use the 297 reverse of the path contained in the received LSRR option. 299 The LSSR option can be of help in debugging some network problems. 300 Some ISP (Internet Service Provider) peering agreements require 301 support for this option in the routers within the peer of the ISP. 303 4.3.2. Option Specification 305 Specified in RFC 791 [RFC0791]. 307 4.3.3. Threats 309 The LSRR option has well-known security implications. Among other 310 things, the option can be used to: 312 o Bypass firewall rules 314 o Reach otherwise unreachable internet systems 316 o Establish TCP connections in a stealthy way 318 o Learn about the topology of a network 320 o Perform bandwidth-exhaustion attacks 322 Of these attack vectors, the one that has probably received least 323 attention is the use of the LSRR option to perform bandwidth 324 exhaustion attacks. The LSRR option can be used as an amplification 325 method for performing bandwidth-exhaustion attacks, as an attacker 326 could make a packet bounce multiple times between a number of systems 327 by carefully crafting an LSRR option. 329 This is the IPv4-version of the IPv6 amplification attack that was 330 widely publicized in 2007 [Biondi2007]. The only difference is 331 that the maximum length of the IPv4 header (and hence the LSRR 332 option) limits the amplification factor when compared to the IPv6 333 counter-part. 335 Additionally, some implementations have been found to fail to include 336 proper sanity checks on the LSRR option, thus leading to security 337 issues. 339 [Microsoft1999] is a security advisory about a vulnerability 340 arising from improper validation of the Pointer field of the LSRR 341 option. 343 Finally, we note that some systems were known for providing a system- 344 wide toggle to enable support for this option for those scenarios in 345 which this option is required. However, improper implementation of 346 such system-wide toggle caused those systems to support the LSRR 347 option even when explicitly configured not to do so. 349 [OpenBSD1998] is a security advisory about an improper 350 implementation of such a system-wide toggle in 4.4BSD kernels. 352 4.3.4. Operational and Interoperability Impact if Blocked 354 Network troubleshooting techniques that may employ the LSRR option 355 (such as ping or traceroute) would break. Nevertheless, it should be 356 noted that it is virtually impossible to use the LSRR option for 357 troubleshooting, due to widespread dropping of packets that contain 358 such option. 360 4.3.5. Advice 362 Routers, security gateways, and firewalls SHOULD, by default, drop IP 363 packets that contain an LSRR option. 365 4.4. Strict Source and Record Route (SSRR) (Type = 137) 367 4.4.1. Uses 369 This option allows the originating system to specify a number of 370 intermediate systems a packet must pass through to get to the 371 destination host. Additionally, the route followed by the packet is 372 recorded in the option, and the destination host (end-system) must 373 use the reverse of the path contained in the received SSRR option. 375 This option is similar to the Loose Source and Record Route (LSRR) 376 option, with the only difference that in the case of SSRR, the route 377 specified in the option is the exact route the packet must take 378 (i.e., no other intervening routers are allowed to be in the route). 380 The SSSR option can be of help in debugging some network problems. 381 Some ISP (Internet Service Provider) peering agreements require 382 support for this option in the routers within the peer of the ISP. 384 4.4.2. Option Specification 386 Specified in RFC 791 [RFC0791]. 388 4.4.3. Threats 390 The SSRR option has the same security implications as the LSRR 391 option. Please refer to Section 4.3 for a discussion of such 392 security implications. 394 4.4.4. Operational and Interoperability Impact if Blocked 396 Network troubleshooting techniques that may employ the SSRR option 397 (such as ping or traceroute) would break. Nevertheless, it should be 398 noted that it is virtually impossible to use the SSR option for 399 trouble-shooting, due to widespread dropping of packets that contain 400 such option. 402 4.4.5. Advice 404 Routers, security gateways, and firewalls SHOULD, by default, drop IP 405 packets that contain an SSRR option. 407 4.5. Record Route (Type = 7) 409 4.5.1. Uses 411 This option provides a means to record the route that a given packet 412 follows. 414 4.5.2. Option Specification 416 Specified in RFC 791 [RFC0791]. 418 4.5.3. Threats 420 This option can be exploited to map the topology of a network. 421 However, the limited space in the IP header limits the usefulness of 422 this option for that purpose. 424 4.5.4. Operational and Interoperability Impact if Blocked 426 Network troubleshooting techniques that may employ the RR option 427 (such as ping with the RR option) would break. Nevertheless, it 428 should be noted that it is virtually impossible to use such 429 techniques due to widespread dropping of packets that contain RR 430 options. 432 4.5.5. Advice 434 Routers, security gateways, and firewalls SHOULD drop IP packets 435 containing a Record Route option. 437 4.6. Stream Identifier (Type = 136) (obsolete) 439 The Stream Identifier option originally provided a means for the 16- 440 bit SATNET stream Identifier to be carried through networks that did 441 not support the stream concept. 443 However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and 444 Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. 445 Therefore, it must be ignored by the processing systems. See also 446 Section 5. 448 RFC 791 states that this option appears at most once in a given 449 datagram. Therefore, if a packet contains more than one instance of 450 this option, it should be dropped, and this event should be logged 451 (e.g., a counter could be incremented to reflect the packet drop). 453 4.6.1. Uses 455 This option is obsolete. There is no current use for this option. 457 4.6.2. Option Specification 459 Specified in RFC 791 [RFC0791], and obsoleted in RFC 1122 [RFC1122] 460 and RFC 1812 [RFC1812]. 462 4.6.3. Threats 464 No security issues are known for this option, other than the general 465 security implications of IP options discussed in Section 3. 467 4.6.4. Operational and Interoperability Impact if Blocked 469 None. 471 4.6.5. Advice 473 Routers, security gateways, and firewalls SHOULD drop IP packets 474 containing a Stream Identifier option. 476 4.7. Internet Timestamp (Type = 68) 478 4.7.1. Uses 480 This option provides a means for recording the time at which each 481 system processed this datagram. 483 4.7.2. Option Specification 485 Specified by RFC 791 [RFC0791]. 487 4.7.3. Threats 489 The timestamp option has a number of security implications. Among 490 them are: 492 o It allows an attacker to obtain the current time of the systems 493 that process the packet, which the attacker may find useful in a 494 number of scenarios. 496 o It may be used to map the network topology, in a similar way to 497 the IP Record Route option. 499 o It may be used to fingerprint the operating system in use by a 500 system processing the datagram. 502 o It may be used to fingerprint physical devices, by analyzing the 503 clock skew. 505 [Kohno2005] describes a technique for fingerprinting devices by 506 measuring the clock skew. It exploits, among other things, the 507 timestamps that can be obtained by means of the ICMP timestamp 508 request messages [RFC0791]. However, the same fingerprinting method 509 could be implemented with the aid of the Internet Timestamp option. 511 4.7.4. Operational and Interoperability Impact if Blocked 513 No security issues are known for this option, other than the general 514 security implications of IP options discussed in Section 3. 516 4.7.5. Advice 518 Routers, security gateways, and firewalls SHOULD drop IP packets 519 containing an Internet Timestamp option. 521 4.8. Router Alert (Type = 148) 523 4.8.1. Uses 525 The Router Alert option has the semantic "routers should examine this 526 packet more closely, if they participate in the functionality denoted 527 by the Value of the option". 529 4.8.2. Option Specification 531 The Router Alert option is defined in RFC 2113 [RFC2113] and later 532 updates to it have been clarified by RFC 5350 [RFC5350]. It contains 533 a 16-bit Value governed by an IANA registry (see [RFC5350]). 535 4.8.3. Threats 537 The security implications of the Router Alert option have been 538 discussed in detail in [RFC6398]. Basically, the Router Alert option 539 might be exploited to perform a Denial of Service (DoS) attack by 540 exhausting CPU resources at the processing routers. 542 4.8.4. Operational and Interoperability Impact if Blocked 544 Applications that employ the Router Alert option (such as RSVP 545 [RFC2205]) would break. 547 4.8.5. Advice 549 This option SHOULD be allowed only in controlled environments, where 550 the option can be used safely. [RFC6398] identifies some such 551 environments. In unsafe environments, packets containing this option 552 SHOULD be dropped. 554 A given router, security gateway, or firewall system has no way of 555 knowing a priori whether this option is valid in its operational 556 environment. Therefore, routers, security gateways, and firewalls 557 SHOULD, by default, ignore the Router Alert option. Additionally, 558 Routers, security gateways, and firewalls SHOULD have a configuration 559 setting that indicates whether they should react act on the Router 560 Alert option as indicated in the corresponding specification or 561 ignore the option, or whether packets containing this option should 562 be dropped (with the default configuration being to ignore the Router 563 Alert option). 565 4.9. Probe MTU (Type = 11) (obsolete) 567 4.9.1. Uses 569 This option originally provided a mechanism to discover the Path-MTU. 570 It has been declared obsolete. 572 4.9.2. Option Specification 574 This option was originally defined in RFC 1063 [RFC1063], and was 575 obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as 576 RFC 1191 obsoletes RFC 1063 without using IP options. 578 4.9.3. Threats 580 No security issues are known for this option, other than the general 581 security implications of IP options discussed in Section 3. 583 4.9.4. Operational and Interoperability Impact if Blocked 585 None 587 4.9.5. Advice 589 Routers, security gateways, and firewalls SHOULD drop IP packets that 590 contain a Probe MTU option. 592 4.10. Reply MTU (Type = 12) (obsolete) 594 4.10.1. Uses 596 This option and originally provided a mechanism to discover the Path- 597 MTU. It is now obsolete. 599 4.10.2. Option Specification 601 This option was originally defined in RFC 1063 [RFC1063], and was 602 obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as 603 RFC 1191 obsoletes RFC 1063 without using IP options. 605 4.10.3. Threats 607 No security issues are known for this option, other than the general 608 security implications of IP options discussed in Section 3. 610 4.10.4. Operational and Interoperability Impact if Blocked 612 None 614 4.10.5. Advice 616 Routers, security gateways, and firewalls SHOULD drop IP packets that 617 contain a Reply MTU option. 619 4.11. Traceroute (Type = 82) 621 4.11.1. Uses 623 This option originally provided a mechanism to trace the path to a 624 host. 626 4.11.2. Option Specification 628 This option was originally specified by RFC 1393 [RFC1393]. The 629 Traceroute option is defined as "experimental" and it was never 630 widely deployed on the public Internet. 632 4.11.3. Threats 634 No security issues are known for this option, other than the general 635 security implications of IP options discussed in Section 3. 637 4.11.4. Operational and Interoperability Impact if Blocked 639 None 641 4.11.5. Advice 643 Routers, security gateways, and firewalls SHOULD drop IP packets that 644 contain a Traceroute option. 646 4.12. DoD Basic Security Option (Type = 130) 648 4.12.1. Uses 650 This option is used by Multi-Level-Secure (MLS) end-systems and 651 intermediate systems in specific environments to [RFC1108]: 653 o Transmit from source to destination in a network standard 654 representation the common security labels required by computer 655 security models [Landwehr81], 657 o Validate the datagram as appropriate for transmission from the 658 source and delivery to the destination, and, 660 o Ensure that the route taken by the datagram is protected to the 661 level required by all protection authorities indicated on the 662 datagram. 664 The DoD Basic Security Option (BSO) is currently implemented in a 665 number of operating systems (e.g., [IRIX2008], [SELinux2008], 666 [Solaris2008], and [Cisco-IPSO]), and deployed in a number of high- 667 security networks. These networks are typically either in physically 668 secure locations, protected by military/governmental communications 669 security equipment, or both. Such networks are typically built using 670 commercial off-the-shelf (COTS) IP routers and Ethernet switches, but 671 are not normally interconnected with the global public Internet. 672 This option probably has more deployment now than when the IESG 673 removed this option from the IETF standards-track. [RFC5570] 674 describes a similar option recently defined for IPv6 and has much 675 more detailed explanations of how sensitivity label options are used 676 in real-world deployments. 678 4.12.2. Option Specification 680 It is specified by RFC 1108 [RFC1108]], which obsoleted RFC 1038 681 [RFC1038] (which in turn obsoleted the Security Option defined in RFC 682 791 [RFC0791]). 684 RFC 791 [RFC0791] defined the "Security Option" (Type = 130), 685 which used the same option type as the DoD Basic Security option 686 discussed in this section. Later, RFC 1038 [RFC1038] revised the 687 IP security options, and in turn was obsoleted by RFC 1108 688 [RFC1108]. The "Security Option" specified in RFC 791 is 689 considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and 690 Section 4.2.2.1 of RFC 1812 [RFC1812], and therefore the 691 discussion in this section is focused on the DoD Basic Security 692 option specified by RFC 1108 [RFC1108]. 694 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 695 this option". 697 Many Cisco routers that run Cisco IOS include support dropping 698 packets that contain this option with per-interface granularity. 699 This capability has been present in many Cisco routers since the 700 early 1990s [Cisco-IPSO-Cmds]. Some governmental products 701 reportedly support BSO, notably CANEWARE [RFC4949]. Support for 702 BSO is included in the "IPsec Configuration Policy Information 703 Model" [RFC3585] and in the "IPsec Security Policy Database 704 Configuration MIB" [RFC4807]. 706 4.12.3. Threats 708 Presence of this option in a packet does not by itself create any 709 specific new threat (other than the usual generic issues that might 710 be created if packets with options are forwarded via the "slow 711 path"). Packets with this option ought not normally be seen on the 712 global public Internet. 714 4.12.4. Operational and Interoperability Impact if Blocked 716 If packets with this option are blocked or if the option is stripped 717 from the packet during transmission from source to destination, then 718 the packet itself is likely to be dropped by the receiver because it 719 isn't properly labelled. In some cases, the receiver might receive 720 the packet but associate an incorrect sensitivity label with the 721 received data from the packet whose BSO was stripped by an 722 intermediate router or firewall. Associating an incorrect 723 sensitivity label can cause the received information either to be 724 handled as more sensitive than it really is ("upgrading") or as less 725 sensitive than it really is ("downgrading"), either of which is 726 problematic. 728 4.12.5. Advice 730 Routers, security gateways, and firewalls SHOULD NOT by default 731 modify or remove this option from IP packets and SHOULD NOT by 732 default drop packets containing this option. For auditing reasons, 733 Routers, security gateways, and firewalls SHOULD be capable of 734 logging the numbers of packets containing the BSO on a per-interface 735 basis. Also, Routers, security gateways, and firewalls SHOULD be 736 capable of dropping packets based on the BSO presence as well as the 737 BSO values. 739 4.13. DoD Extended Security Option (Type = 133) 741 4.13.1. Uses 743 This option permits additional security labeling information, beyond 744 that present in the Basic Security Option (Section 4.12), to be 745 supplied in an IP datagram to meet the needs of registered 746 authorities. 748 4.13.2. Option Specification 750 The DoD Extended Security Option (ESO) is specified by RFC 1108 751 [RFC1108]. 753 Many Cisco routers that run Cisco IOS include support for dropping 754 packets that contain this option with a per-interface granularity. 755 This capability has been present in many Cisco routers since the 756 early 1990s [Cisco-IPSO-Cmds]. Some governmental products 757 reportedly support ESO, notably CANEWARE [RFC4949]. Support for 758 ESO is included in the "IPsec Configuration Policy Information 759 Model" [RFC3585] and in the "IPsec Security Policy Database 760 Configuration MIB" [RFC4807]. 762 4.13.3. Threats 764 Presence of this option in a packet does not by itself create any 765 specific new threat (other than the usual generic issues that might 766 be created if packets with options are forwarded via the "slow 767 path"). Packets with this option ought not normally be seen on the 768 global public Internet 770 4.13.4. Operational and Interoperability Impact if Blocked 772 If packets with this option are blocked or if the option is stripped 773 from the packet during transmission from source to destination, then 774 the packet itself is likely to be dropped by the receiver because it 775 isn't properly labelled. In some cases, the receiver might receive 776 the packet but associate an incorrect sensitivity label with the 777 received data from the packet whose ESO was stripped by an 778 intermediate router or firewall. Associating an incorrect 779 sensitivity label can cause the received information either to be 780 handled as more sensitive than it really is ("upgrading") or as less 781 sensitive than it really is ("downgrading"), either of which is 782 problematic. 784 4.13.5. Advice 786 Routers, security gateways, and firewalls SHOULD NOT by default 787 modify or remove this option from IP packets and SHOULD NOT by 788 default drop packets containing this option. For auditing reasons, 789 Routers, security gateways, and firewalls SHOULD be capable of 790 logging the numbers of packets containing the ESO on a per-interface 791 basis. Also, Routers, security gateways, and firewalls SHOULD be 792 capable of dropping packets based on the ESO presence as well as the 793 ESO values. 795 4.14. Commercial IP Security Option (CIPSO) (Type = 134) 797 4.14.1. Uses 799 This option was proposed by the Trusted Systems Interoperability 800 Group (TSIG), with the intent of meeting trusted networking 801 requirements for the commercial trusted systems market place. 803 It is currently implemented in a number of operating systems (e.g., 804 IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris 805 [Solaris2008]), and deployed in a number of high-security networks. 807 4.14.2. Option Specification 809 This option is specified in [CIPSO1992] and [FIPS1994]. There are 810 zero known IP router implementations of CIPSO. Several MLS operating 811 systems support CIPSO, generally the same MLS operating systems that 812 support IPSO. 814 The TSIG proposal was taken to the Commercial Internet Security 815 Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an 816 Internet-Draft was produced [CIPSO1992]. The Internet-Draft was 817 never published as an RFC, but the proposal was later standardized 818 by the U.S. National Institute of Standards and Technology (NIST) 819 as "Federal Information Processing Standard Publication 188" 820 [FIPS1994]. 822 4.14.3. Threats 824 Presence of this option in a packet does not by itself create any 825 specific new threat (other than the usual generic issues that might 826 be created if packets with options are forwarded via the "slow 827 path"). Packets with this option ought not normally be seen on the 828 global public Internet. 830 4.14.4. Operational and Interoperability Impact if Blocked 832 If packets with this option are blocked or if the option is stripped 833 from the packet during transmission from source to destination, then 834 the packet itself is likely to be dropped by the receiver because it 835 isn't properly labelled. In some cases, the receiver might receive 836 the packet but associate an incorrect sensitivity label with the 837 received data from the packet whose CIPSO was stripped by an 838 intermediate router or firewall. Associating an incorrect 839 sensitivity label can cause the received information either to be 840 handled as more sensitive than it really is ("upgrading") or as less 841 sensitive than it really is ("downgrading"), either of which is 842 problematic. 844 4.14.5. Advice 846 Because of the design of this option, with variable syntax and 847 variable length, it is not practical to support specialized filtering 848 using the CIPSO information. No routers or firewalls are known to 849 support this option. However, Routers, security gateways, and 850 firewalls SHOULD NOT by default modify or remove this option from IP 851 packets and SHOULD NOT by default drop packets containing this 852 option. 854 4.15. VISA (Type = 142) 856 4.15.1. Uses 858 This options was part of an experiment at USC and was never widely 859 deployed. 861 4.15.2. Option Specification 863 Not publicly available. 865 4.15.3. Threats 867 Not possible to determine (other the general security implications of 868 IP options discussed in Section 3), since the corresponding 869 specification is not publicly available. 871 4.15.4. Operational and Interoperability Impact if Blocked 873 None. 875 4.15.5. Advice 877 Routers, security gateways, and firewalls SHOULD drop IP packets that 878 contain this option. 880 4.16. Extended Internet Protocol (Type = 145) 882 4.16.1. Uses 884 The EIP option was introduced by one of the proposals submitted 885 during the IPng efforts to address the problem of IPv4 address 886 exhaustion. 888 4.16.2. Option Specification 890 Specified in [RFC1385]. This option is in the process of being 891 formally obsoleted by [I-D.gp-intarea-obsolete-ipv4-options-iana]. 893 4.16.3. Threats 895 There are no know threats arising from this option, other than the 896 general security implications of IP options discussed in Section 3. 898 4.16.4. Operational and Interoperability Impact if Blocked 900 None. 902 4.16.5. Advice 904 Routers, security gateways, and firewalls SHOULD drop packets that 905 contain this option. 907 4.17. Address Extension (Type = 147) 909 4.17.1. Uses 911 The Address Extension option was introduced by one of the proposals 912 submitted during the IPng efforts to address the problem of IPv4 913 address exhaustion. 915 4.17.2. Option Specification 917 Specified in [RFC1475]. This option is in the process of being 918 formally obsoleted by [I-D.gp-intarea-obsolete-ipv4-options-iana]. 920 4.17.3. Threats 922 There are no know threats arising from this option, other than the 923 general security implications of IP options discussed in Section 3. 925 4.17.4. Operational and Interoperability Impact if Blocked 927 None. 929 4.17.5. Advice 931 Routers, security gateways, and firewalls SHOULD drop packets that 932 contain this option. 934 4.18. Sender Directed Multi-Destination Delivery (Type = 149) 936 4.18.1. Uses 938 This option originally provided unreliable UDP delivery to a set of 939 addresses included in the option. 941 4.18.2. Option Specification 943 This option is defined in RFC 1770 [RFC1770]. 945 4.18.3. Threats 947 This option could have been exploited for bandwidth-amplification in 948 Denial of Service (DoS) attacks. 950 4.18.4. Operational and Interoperability Impact if Blocked 952 None. 954 4.18.5. Advice 956 Routers, security gateways, and firewalls SHOULD drop IP packets that 957 contain a Sender Directed Multi-Destination Delivery option. 959 4.19. Dynamic Packet State (Type = 151) 961 4.19.1. Uses 963 The Dynamic Packet State option was used to specify specified Dynamic 964 Packet State (DPS) in the context of the differentiated service 965 architecture. 967 4.19.2. Option Specification 969 The Dynamic Packet State option was specified in 970 [I-D.stoica-diffserv-dps]. The aforementioned document was meant to 971 be published as "Experimental", but never made it into an RFC. This 972 option is in the process of being formally obsoleted by 973 [I-D.gp-intarea-obsolete-ipv4-options-iana]. 975 4.19.3. Threats 977 Possible threats include theft of service and Denial of Service. 978 However, we note that is option has never been widely implemented or 979 deployed. 981 4.19.4. Operational and Interoperability Impact if Blocked 983 None. 985 4.19.5. Advice 987 Routers, security gateways, and firewalls SHOULD drop packets that 988 contain this option. 990 4.20. Upstream Multicast Pkt. (Type = 152) 992 4.20.1. Uses 994 This option was meant to solve the problem of doing upstream 995 forwarding of multicast packets on a multi-access LAN. 997 4.20.2. Option Specification 999 This option was originally specified in [draft-farinacci-bidir-pim]. 1000 Its use was obsoleted by [RFC5015], which employs a control plane 1001 mechanism to solve the problem of doing upstream forwarding of 1002 multicast packets on a multi-access LAN. This option is in the 1003 process of being formally obsoleted by 1004 [I-D.gp-intarea-obsolete-ipv4-options-iana]. 1006 4.20.3. Threats 1008 TBD. 1010 4.20.4. Operational and Interoperability Impact if Blocked 1012 None. 1014 4.20.5. Advice 1016 Routers, security gateways, and firewalls SHOULD drop packets that 1017 contain this option. 1019 4.21. Quick-Start (Type = 25) 1021 4.21.1. Uses 1023 This IP Option is used in the specification of Quick-Start for TCP 1024 and IP, which is an experimental mechanism that allows transport 1025 protocols, in cooperation with routers, to determine an allowed 1026 sending rate at the start and, at times, in the middle of a data 1027 transfer (e.g., after an idle period) [RFC4782]. 1029 4.21.2. Option Specification 1031 Specified in RFC 4782 [RFC4782], on the "Experimental" track. 1033 4.21.3. Threats 1035 Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two 1036 kinds of attacks: 1038 o attacks to increase the routers' processing and state load, and, 1040 o attacks with bogus Quick-Start Requests to temporarily tie up 1041 available Quick-Start bandwidth, preventing routers from approving 1042 Quick-Start Requests from other connections 1044 4.21.4. Operational and Interoperability Impact if Blocked 1046 The Quick-Start functionality would be disabled, and additional 1047 delays in e.g. TCP's connection establishment could be introduced 1048 (please see Section 4.7.2 of [RFC4782]. We note, however, that 1049 Quick-Start has been proposed as mechanism that could be of use in 1050 controlled environments, and not as a mechanism that would be 1051 intended or appropriate for ubiquitous deployment in the global 1052 Internet [RFC4782]. 1054 4.21.5. Advice 1056 A given router, security gateway, or firewall system has no way of 1057 knowing a priori whether this option is valid in its operational 1058 environment. Therefore, routers, security gateways, and firewalls 1059 SHOULD, by default, ignore the Quick Start option. Additionally, 1060 routers, security gateways, and firewalls SHOULD have a configuration 1061 setting that indicates whether they should react act on the Quick 1062 Start option as indicated in the corresponding specification or 1063 ignore the option, or whether packets containing this option should 1064 be dropped (with the default configuration being to ignore the Quick 1065 Start option). 1067 We note that if routers in a given environment do not implement 1068 and enable the Quick-Start mechanism, only the general security 1069 implications of IP options (discussed in Section 3) would apply. 1071 4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) 1073 Section 2.5 of RFC 4727 [RFC4727] allocates an option number with all 1074 defined values of the "copy" and "class" fields for RFC3692-style 1075 experiments. This results in four distinct option type codes: 30, 1076 94, 158, and 222. 1078 4.22.1. Uses 1080 It is only appropriate to use these values in explicitly-configured 1081 experiments; they MUST NOT be shipped as defaults in implementations. 1083 4.22.2. Option Specification 1085 Specified in RFC 4727 [RFC4727] in the context of RFC3692-style 1086 experiments. 1088 4.22.3. Threats 1090 No security issues are known for this option, other than the general 1091 security implications of IP options discussed in Section 3. 1093 4.22.4. Operational and Interoperability Impact if Blocked 1095 None. 1097 4.22.5. Advice 1099 Routers, security gateways, and firewalls SHOULD drop IP packets that 1100 contain RFC3692-style Experiment options. 1102 4.23. Other IP Options 1104 Unrecognized IP Options are to be ignored. Section 3.2.1.8 of RFC 1105 1122 [RFC1122] and Section 4.2.2.6 of RFC 1812 [RFC1812] specify this 1106 behavior as follows: 1108 RFC 1122: "The IP and transport layer MUST each interpret those IP 1109 options that they understand and silently ignore the 1110 others." 1112 RFC 1812: "A router MUST ignore IP options which it does not 1113 recognize." 1115 This document adds that unrecognized IP Options MAY also be logged. 1117 A number of additional options are specified in the "IP OPTIONS 1118 NUMBERS" IANA registry [IANA-IP]. Specifically: 1120 Copy Class Number Value Name Reference 1121 ---- ----- ------ ----- ------------------------------- ------------ 1122 0 0 10 10 ZSU - Experimental Measurement [ZSu] 1123 1 2 13 205 FINN - Experimental Flow Control [Finn] 1124 0 0 15 15 ENCODE - ??? [VerSteeg] 1125 1 0 16 144 IMITD - IMI Traffic Descriptor [Lee] 1126 1 0 22 150 - Unassigned (Released 18 Oct. 2005) 1128 5. IANA Considerations 1130 The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the 1131 currently assigned IP option numbers. This registry also denotes an 1132 obsoleted IP Option Number by marking it with a single asterisk 1133 ("*"). The Stream Identifier Option (Type = 136) is obsolete (see 1134 Section 4.6 and should therefore be marked as such. 1136 [[ IANA is requested to mark it as such, please remove this note upon 1137 publication. ]] [[ IANA is also requested to fix the "Expermental" 1138 typo. ]] 1140 6. Security Considerations 1142 This document provides advice on the filtering of IP packets that 1143 contain IP options. Dropping such packets can help to mitigate the 1144 security issues that arise from use of different IP options. 1146 7. Acknowledgements 1148 The authors would like to thank Panos Kampanakis and Donald Smith for 1149 providing valuable comments on earlier versions of this document. 1151 Part of this document is based on the document "Security Assessment 1152 of the Internet Protocol" [CPNI2008] that is the result of a project 1153 carried out by Fernando Gont on behalf of UK CPNI (formerly NISCC). 1155 Fernando Gont would like to thank UK CPNI (formerly NISCC) for their 1156 continued support. 1158 8. References 1160 8.1. Normative References 1162 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1163 September 1981. 1165 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 1167 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1168 Communication Layers", STD 3, RFC 1122, October 1989. 1170 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1171 November 1990. 1173 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 1174 Destination Delivery", RFC 1770, March 1995. 1176 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1177 RFC 1812, June 1995. 1179 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1180 February 1997. 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, March 1997. 1185 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1186 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1188 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1189 Start for TCP and IP", RFC 4782, January 2007. 1191 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1192 "Bidirectional Protocol Independent Multicast (BIDIR- 1193 PIM)", RFC 5015, October 2007. 1195 8.2. Informative References 1197 [Biondi2007] 1198 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 1199 CanSecWest 2007 Security Conference , 2007. 1202 [CIPSO1992] 1203 CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", 1204 draft-ietf-cipso-ipsecurity-01 (work in progress), 1992. 1206 [CIPSOWG1994] 1207 CIPSOWG, "Commercial Internet Protocol Security Option 1208 (CIPSO) Working Group", 1994, . 1211 [CPNI2008] 1212 Gont, F., "Security Assessment of the Internet Protocol", 1213 , 2008. 1215 [Cisco-IPSO] 1216 Cisco Systems, Inc., "Cisco IOS Security Configuration 1217 Guide, Release 12.2 - Configuring IP Security Options", < 1218 http://www.cisco.com/en/US/docs/ios/12_2/security/ 1219 configuration/guide/scfipso.html>, 2006. 1221 [Cisco-IPSO-Cmds] 1222 Cisco Systems, Inc., "Cisco IOS Security Command 1223 Reference, Release 12.2 - IP Security Options Commands", 1224 . 1227 [FIPS1994] 1228 FIPS, "Standard Security Label for Information Transfer", 1229 Federal Information Processing Standards Publication. FIP 1230 PUBS 188, , 1994. 1233 [I-D.gp-intarea-obsolete-ipv4-options-iana] 1234 Pignataro, C. and F. Gont, "Formally Obsoleting some 1235 Historic IPv4 Options", 1236 draft-gp-intarea-obsolete-ipv4-options-iana-00 (work in 1237 progress), February 2012. 1239 [I-D.stoica-diffserv-dps] 1240 Stoica, I., Zhang, H., Baker, F., and Y. Bernet, "Per Hop 1241 Behaviors Based on Dynamic Packet State", 1242 draft-stoica-diffserv-dps-02 (work in progress), 1243 October 2002. 1245 [IANA-IP] Internet Assigned Numbers Authority, "IP OPTION NUMBERS", 1246 April 2011, 1247 . 1249 [IRIX2008] 1250 IRIX, "IRIX 6.5 trusted_networking(7) manual page", , 2008. 1255 [Kohno2005] 1256 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 1257 Device Fingerprinting", IEEE Transactions on Dependable 1258 and Secure Computing Vol. 2, No. 2, 2005. 1260 [Landwehr81] 1261 Landwehr, C., "Formal Models for Computer Security", ACM 1262 Computing Surveys Vol 13, No 3, September 1981, Assoc for 1263 Computing Machinery, New York, NY, USA, 1981. 1265 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 1266 Interactions Between Transport Protocols and Middleboxes", 1267 Proc. 4th ACM SIGCOMM/USENIX Conference on 1268 Internet Measurement, October 2004. 1270 [Microsoft1999] 1271 Microsoft, "Microsoft Security Program: Microsoft Security 1272 Bulletin (MS99-038). Patch Available for "Spoofed Route 1273 Pointer" Vulnerability", 1999, . 1276 [OpenBSD1998] 1277 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 1278 Problem", 1998, 1279 . 1281 [RFC1038] St. Johns, M., "Draft revised IP security option", 1282 RFC 1038, January 1988. 1284 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 1285 MTU discovery options", RFC 1063, July 1988. 1287 [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, 1288 November 1992. 1290 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1291 January 1993. 1293 [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, 1294 June 1993. 1296 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1297 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1298 Functional Specification", RFC 2205, September 1997. 1300 [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec 1301 Configuration Policy Information Model", RFC 3585, 1302 August 2003. 1304 [RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. 1305 Wang, "IPsec Security Policy Database Configuration MIB", 1306 RFC 4807, March 2007. 1308 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1309 RFC 4949, August 2007. 1311 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 1312 IPv4 and IPv6 Router Alert Options", RFC 5350, 1313 September 2008. 1315 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1316 Architecture Label IPv6 Security Option (CALIPSO)", 1317 RFC 5570, July 2009. 1319 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1320 Router Control Plane", RFC 6192, March 2011. 1322 [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and 1323 Usage", BCP 168, RFC 6398, October 2011. 1325 [SELinux2008] 1326 Security Enhanced Linux, "http://www.nsa.gov/selinux/". 1328 [Solaris2008] 1329 Solaris Trusted Extensions - Labeled Security for Absolute 1330 Protection, "http://www.sun.com/software/solaris/ds/ 1331 trusted_extensions.jsp#3", 2008. 1333 [draft-farinacci-bidir-pim] 1334 Estrin, D. and D. Farinacci, "Bi-Directional Shared Trees 1335 in PIM-SM", IETF Internet Draft, 1336 draft-farinacci-bidir-pim, work in progress, May 1999. 1338 Authors' Addresses 1340 Fernando Gont 1341 UTN-FRH / SI6 Networks 1342 Evaristo Carriego 2644 1343 Haedo, Provincia de Buenos Aires 1706 1344 Argentina 1346 Phone: +54 11 4650 8472 1347 Email: fgont@si6networks.com 1348 URI: http://www.si6networks.com 1350 RJ Atkinson 1351 Consultant 1352 McLean, VA 22103 1353 USA 1355 Email: rja.lists@gmail.com 1356 Carlos Pignataro 1357 Cisco Systems, Inc. 1358 7200-12 Kit Creek Road 1359 Research Triangle Park, NC 27709 1360 US 1362 Email: cpignata@cisco.com