idnits 2.17.1 draft-gont-opsec-ip-options-filtering-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2011) is 4512 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) == Unused Reference: 'RFC0826' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC2644' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC3927' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'RFC5735' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'Barisani2006' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'CERT1996a' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'CERT1996c' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'CERT1997' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'CERT1999' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'CIPSOWG1994' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'Haddad2004' is defined on line 988, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-mtuassurance' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'I-D.wilson-class-e' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'IANA2006a' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'IANA2006c' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'Linux2006' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'Microsoft1999' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'Northcutt2000' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'OpenBSD-PF' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'OpenBSD1998' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'Paxson2001' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC0815' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC1858' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'RFC3128' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'RFC4963' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'RFC4987' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'RFC5082' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'Silbersack2005' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'US-CERT2001' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'US-CERT2002' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'Zakrzewski2002' is defined on line 1177, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1038 (Obsoleted by RFC 1108) ** Obsolete normative reference: RFC 1063 (Obsoleted by RFC 1191) ** Downref: Normative reference to an Historic RFC: RFC 1108 ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 1770 (Obsoleted by RFC 6814) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 9 errors (**), 0 flaws (~~), 48 warnings (==), 2 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 4 Internet-Draft R. Atkinson 5 Intended status: BCP Consultant 6 Expires: June 19, 2012 December 17, 2011 8 Recommendations on filtering of IP packets containing IP options 9 draft-gont-opsec-ip-options-filtering-02.txt 11 Abstract 13 This document document provides advice on the filtering of packets 14 based on the IP options they contain. Additionally, it discusses the 15 operational and interoperability implications of such filtering. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 19, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. General security implications of IP options . . . . . . . . . 6 54 3.1. Processing requirements . . . . . . . . . . . . . . . . . 7 55 4. Advice on handling of specific IP Options . . . . . . . . . . 7 56 4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7 57 4.1.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1.2. Option specification . . . . . . . . . . . . . . . . . 7 59 4.1.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1.4. Operational/interoperability impact if blocked . . . . 7 61 4.1.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7 63 4.2.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.2. Option specification . . . . . . . . . . . . . . . . . 8 65 4.2.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.4. Operational/interoperability impact if blocked . . . . 8 67 4.2.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8 69 4.3.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3.2. Option specification . . . . . . . . . . . . . . . . . 8 71 4.3.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3.4. Operational/interoperability impact if blocked . . . . 9 73 4.3.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . . 9 75 4.4.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.4.2. Option specification . . . . . . . . . . . . . . . . . 10 77 4.4.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.4.4. Operational/interoperability impact if blocked . . . . 10 79 4.4.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 10 81 4.5.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.5.2. Option specification . . . . . . . . . . . . . . . . . 10 83 4.5.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 10 84 4.5.4. Operational/interoperability impact if blocked . . . . 11 85 4.5.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 11 86 4.6. Stream Identifier (Type = 136) . . . . . . . . . . . . . . 11 87 4.6.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.6.2. Option specification . . . . . . . . . . . . . . . . . 11 89 4.6.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.6.4. Operational/interoperability impact if blocked . . . . 11 91 4.6.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 12 93 4.7.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 4.7.2. Option specification . . . . . . . . . . . . . . . . . 12 95 4.7.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 12 96 4.7.4. Operational/interoperability impact if blocked . . . . 12 97 4.7.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 12 98 4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 13 99 4.8.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 4.8.2. Option specification . . . . . . . . . . . . . . . . . 13 101 4.8.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 13 102 4.8.4. Operational/interoperability impact if blocked . . . . 13 103 4.8.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 13 104 4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 13 105 4.9.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13 106 4.9.2. Option specification . . . . . . . . . . . . . . . . . 13 107 4.9.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 14 108 4.9.4. Operational/interoperability impact if blocked . . . . 14 109 4.9.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 14 110 4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 14 111 4.10.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 14 112 4.10.2. Option specification . . . . . . . . . . . . . . . . . 14 113 4.10.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 14 114 4.10.4. Operational/interoperability impact if blocked . . . . 14 115 4.10.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 14 116 4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 14 117 4.11.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 14 118 4.11.2. Option specification . . . . . . . . . . . . . . . . . 14 119 4.11.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 15 120 4.11.4. Operational/interoperability impact if blocked . . . . 15 121 4.11.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 15 122 4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 15 123 4.12.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 15 124 4.12.2. Option specification . . . . . . . . . . . . . . . . . 15 125 4.12.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 16 126 4.12.4. Operational/interoperability impact if blocked . . . . 16 127 4.12.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 16 128 4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 16 129 4.13.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 17 130 4.13.2. Option specification . . . . . . . . . . . . . . . . . 17 131 4.13.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 17 132 4.13.4. Operational/interoperability impact if blocked . . . . 17 133 4.13.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 17 134 4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 18 135 4.14.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 18 136 4.14.2. Option specification . . . . . . . . . . . . . . . . . 18 137 4.14.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 18 138 4.14.4. Operational/interoperability impact if blocked . . . . 18 139 4.14.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 18 140 4.15. Sender Directed Multi-Destination Delivery (Type = 149) . 19 141 4.15.1. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 19 142 4.15.2. Option specification . . . . . . . . . . . . . . . . . 19 143 4.15.3. Threats . . . . . . . . . . . . . . . . . . . . . . . 19 144 4.15.4. Operational/interoperability impact if blocked . . . . 19 145 4.15.5. Advice . . . . . . . . . . . . . . . . . . . . . . . . 19 146 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 147 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 148 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 149 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 150 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 151 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 152 Appendix A. Changes from previous versions of the draft (to 153 be removed by the RFC Editor before publishing 154 this document as an RFC) . . . . . . . . . . . . . . 26 155 A.1. Changes introduced in 156 draft-gont-opsec-ip-options-filtering-01 . . . . . . . . . 26 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 159 1. Introduction 161 Various protocols may use IP Options to some extent, therefore the 162 filtering of such options may have implications on proper functioning 163 of the protocol. As such, this document attempts to discuss the 164 operational and interoperability implications of such filtering. 165 Additionally, this document will outline what a network operator 166 might do in a typical enterprise or Service Provider environment. 168 We note that data seems to indicate that there is a current 169 widespread practice of blocking IPv4 optioned packets. There are 170 various plausible approaches to minimize the potential negative 171 effects of IPv4 optioned packets while allowing some options 172 semantics. One approach is to allow for specific options that are 173 expected or needed, and a default deny. A different approach is to 174 deny unneeded options and a default allow. Yet a third option is to 175 allow for end-to-end semantics by ignoring options and treating 176 packets as un-optioned while in transit. The current state tends to 177 support the first or third approaches as more realistic. Some 178 results of regarding the current state of affairs with respect to 179 filtering of packets containing IP options can be found in [MEDINA]. 181 We also note that while this document provides advice on a "per IP 182 option type", not all devices may provide functionality to filter IP 183 packets on a "per IP option type". Additionally, even in cases in 184 which such functionality is provided, the operator might want to 185 specify a filtering policy with a coarser granularity (rather than on 186 a "per IP option type" granularity), as indicated above. 188 Finally, in scenarios in which processing of IP options by 189 intermediate systems is not required, a widespread approach is to 190 simply ignore IP options, and process the corresponding packets as if 191 they do not contain any IP options. 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 2. IP Options 199 IP options allow for the extension of the Internet Protocol 201 There are two cases for the format of an option: 203 o Case 1: A single byte of option-type. 205 o Case 2: An option-type byte, an option-length byte, and the actual 206 option-data bytes. 208 In the Case 2, the option-length byte counts the option-type byte and 209 the option-length byte, as well as the actual option-data bytes. 211 All current and future options except "End of Option List" (Type = 0) 212 and "No Operation" (Type = 1), are of Class 2. 214 The option-type has three fields: 216 o 1 bit: copied flag. 218 o 2 bits: option class. 220 o 5 bits: option number. 222 The copied flag indicates whether this option should be copied to all 223 fragments in the event the packet carrying it needs to be fragmented: 225 o 0 = not copied. 227 o 1 = copied. 229 The values for the option class are: 231 o 0 = control. 233 o 1 = reserved for future use. 235 o 2 = debugging and measurement. 237 o 3 = reserved for future use. 239 This format allows for the creation of new options for the extension 240 of the Internet Protocol (IP). 242 Finally, the option number identifies the syntax of the rest of the 243 option. 245 [IANA2006b] contains the list of the currently assigned IP option 246 numbers. 248 3. General security implications of IP options 249 3.1. Processing requirements 251 Router manufacturers tend to do IP option processing in a slower 252 path. Unless special care is taken, this represents Denial of 253 Service (DoS) risk, as there is potential for overwhelming the router 254 with option processing. 256 The following sections contain a description of each of the IP 257 options that have so far been specified, a discussion of possible 258 interoperability implications if packets containing such options are 259 filtered, and specific advice on whether to filter packets containing 260 these options in a typical enterprise or Service Provider 261 environment. 263 4. Advice on handling of specific IP Options 265 4.1. End of Option List (Type = 0) 267 4.1.1. Uses 269 This option is used to indicate the "end of options" in those cases 270 in which the end of options would not coincide with the end of the 271 Internet Protocol Header. 273 4.1.2. Option specification 275 Specified in RFC 791 [RFC0791]. 277 4.1.3. Threats 279 No security issues are known for this option, other than the general 280 security implications of IP options discussed in Section 3. 282 4.1.4. Operational/interoperability impact if blocked 284 Packets containing any IP options are likely to include an End of 285 Option List. Therefore, if packets containing this option are 286 filtered, it is very likely that legitimate traffic is filtered. 288 4.1.5. Advice 290 Do not filter packets containing this option. 292 4.2. No Operation (Type = 1) 293 4.2.1. Uses 295 The no-operation option is basically meant to allow the sending 296 system to align subsequent options in, for example, 32-bit 297 boundaries. 299 4.2.2. Option specification 301 Specified in RFC 791 [RFC0791]. 303 4.2.3. Threats 305 No security issues are known for this option, other than the general 306 security implications of IP options discussed in Section 3. 308 4.2.4. Operational/interoperability impact if blocked 310 4.2.5. Advice 312 Do not filter packets containing this option. 314 4.3. Loose Source and Record Route (LSRR) (Type = 131) 316 RFC 791 states that this option should appear, at most, once in a 317 given packet. Thus, if a packet contains more than one LSRR option, 318 it should be dropped, and this event should be logged (e.g., a 319 counter could be incremented to reflect the packet drop). 320 Additionally, packets containing a combination of LSRR and SSRR 321 options should be dropped, and this event should be logged (e.g., a 322 counter could be incremented to reflect the packet drop). 324 4.3.1. Uses 326 This option lets the originating system specify a number of 327 intermediate systems a packet must pass through to get to the 328 destination host. Additionally, the route followed by the packet is 329 recorded in the option. The receiving host (end-system) must use the 330 reverse of the path contained in the received LSRR option. 332 The LSSR option can be of help in debugging some network problems. 333 Some ISP (Internet Service Provider) peering agreements require 334 support for this option in the routers within the peer of the ISP. 336 4.3.2. Option specification 338 Specified in RFC 791 [RFC0791]. 340 4.3.3. Threats 342 The LSRR option has well-known security implications. Among other 343 things, the option can be used to: 345 o Bypass firewall rules 347 o Reach otherwise unreachable internet systems 349 o Establish TCP connections in a stealthy way 351 o Learn about the topology of a network 353 o Perform bandwidth-exhaustion attacks 355 Of these attack vectors, the one that has probably received least 356 attention is the use of the LSRR option to perform bandwidth 357 exhaustion attacks. The LSRR option can be used as an amplification 358 method for performing bandwidth-exhaustion attacks, as an attacker 359 could make a packet bounce multiple times between a number of systems 360 by carefully crafting an LSRR option. 362 This is the IPv4-version of the IPv6 amplification attack that was 363 widely publicized in 2007 [Biondi2007]. The only difference is 364 that the maximum length of the IPv4 header (and hence the LSRR 365 option) limits the amplification factor when compared to the IPv6 366 counter-part. 368 4.3.4. Operational/interoperability impact if blocked 370 Network troubleshooting techniques that may employ the LSRR option 371 (such as ping or traceroute) would break. Nevertheless, it should be 372 noted that it is virtually impossible to use such techniques due to 373 widespread filtering of the LSRR option. 375 4.3.5. Advice 377 All systems should, by default, drop IP packets that contain an LSRR 378 option. 380 4.4. Strict Source and Record Route (SSRR) (Type = 137) 382 4.4.1. Uses 384 This option allows the originating system to specify a number of 385 intermediate systems a packet must pass through to get to the 386 destination host. Additionally, the route followed by the packet is 387 recorded in the option, and the destination host (end-system) must 388 use the reverse of the path contained in the received SSRR option. 390 This option is similar to the Loose Source and Record Route (LSRR) 391 option, with the only difference that in the case of SSRR, the route 392 specified in the option is the exact route the packet must take 393 (i.e., no other intervening routers are allowed to be in the route). 395 The SSSR option can be of help in debugging some network problems. 396 Some ISP (Internet Service Provider) peering agreements require 397 support for this option in the routers within the peer of the ISP. 399 4.4.2. Option specification 401 Specified in RFC 791 [RFC0791]. 403 4.4.3. Threats 405 The SSRR option has the same security implications as the LSRR 406 option. Please refer to Section 4.3 for a discussion of such 407 security implications. 409 4.4.4. Operational/interoperability impact if blocked 411 Network troubleshooting techniques that may employ the SSRR option 412 (such as ping or traceroute) would break. Nevertheless, it should be 413 noted that it is virtually impossible to use such techniques due to 414 widespread filtering of the SSRR option. 416 4.4.5. Advice 418 All systems should, by default, drop IP packets that contain an SSRR 419 option. 421 4.5. Record Route (Type = 7) 423 4.5.1. Uses 425 This option provides a means to record the route that a given packet 426 follows. 428 4.5.2. Option specification 430 Specified in RFC 791 [RFC0791]. 432 4.5.3. Threats 434 This option can be exploited to map the topology of a network. 435 However, the limited space in the IP header limits the usefulness of 436 this option for that purpose. 438 4.5.4. Operational/interoperability impact if blocked 440 Network troubleshooting techniques that may employ the RR option 441 (such as ping with the RR option) would break. Nevertheless, it 442 should be noted that it is virtually impossible to use such 443 techniques due to widespread filtering of the RR option. 445 4.5.5. Advice 447 Drop IP packets that contain a Record Route option. 449 4.6. Stream Identifier (Type = 136) 451 The Stream Identifier option originally provided a means for the 16- 452 bit SATNET stream Identifier to be carried through networks that did 453 not support the stream concept. 455 However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this 456 option is obsolete. Therefore, it must be ignored by the processing 457 systems. 459 In the case of legacy systems still using this option, the length 460 field of the option should be checked to be 4. If the option does 461 not pass this check, it should be dropped, and this event should be 462 logged (e.g., a counter could be incremented to reflect the packet 463 drop). 465 RFC 791 states that this option appears at most once in a given 466 datagram. Therefore, if a packet contains more than one instance of 467 this option, it should be dropped, and this event should be logged 468 (e.g., a counter could be incremented to reflect the packet drop). 470 4.6.1. Uses 472 4.6.2. Option specification 474 Specified in RFC 791 [RFC0791]. 476 4.6.3. Threats 478 TBD 480 4.6.4. Operational/interoperability impact if blocked 482 None. 484 4.6.5. Advice 486 Filter IP packets that contain a Stream Identifier option. 488 4.7. Internet Timestamp (Type = 68) 490 4.7.1. Uses 492 This option provides a means for recording the time at which each 493 system processed this datagram. 495 4.7.2. Option specification 497 Specified by RFC 791 [RFC0791]. 499 4.7.3. Threats 501 The timestamp option has a number of security implications. Among 502 them are: 504 o It allows an attacker to obtain the current time of the systems 505 that process the packet, which the attacker may find useful in a 506 number of scenarios. 508 o It may be used to map the network topology, in a similar way to 509 the IP Record Route option. 511 o It may be used to fingerprint the operating system in use by a 512 system processing the datagram. 514 o It may be used to fingerprint physical devices, by analyzing the 515 clock skew. 517 [Kohno2005] describes a technique for fingerprinting devices by 518 measuring the clock skew. It exploits, among other things, the 519 timestamps that can be obtained by means of the ICMP timestamp 520 request messages [RFC0791]. However, the same fingerprinting method 521 could be implemented with the aid of the Internet Timestamp option. 523 4.7.4. Operational/interoperability impact if blocked 525 No security issues are known for this option, other than the general 526 security implications of IP options discussed in Section 3. 528 4.7.5. Advice 530 Filter IP packets that contain an Internet Timestamp option. 532 4.8. Router Alert (Type = 148) 534 4.8.1. Uses 536 The Router Alert option has the semantic "routers should examine this 537 packet more closely, if they participate in the functionality denoted 538 by the Value of the option". 540 4.8.2. Option specification 542 The Router Alert option is defined in RFC 2113 [RFC2113] and later 543 updates to it have been clarified by RFC 5350 [RFC5350]. It contains 544 a 16-bit Value governed by an IANA registry (see [RFC5350]). 546 4.8.3. Threats 548 The security implications of the Router Alert option have been 549 discussed in detail in 550 [I-D.ietf-intarea-router-alert-considerations]. Basically, the 551 Router Alert option might be exploited to perform a Denial of Service 552 (DoS) attack by exhausting CPU resources at the processing routers. 554 4.8.4. Operational/interoperability impact if blocked 556 Applications that employ the Router Alert option (such as RSVP 557 [RFC2205]) would break. 559 4.8.5. Advice 561 This option should be allowed only on controlled environments, where 562 the option can be used safely 563 ([I-D.ietf-intarea-router-alert-considerations] identifies such 564 environments). In other environments, packets containing this option 565 should be dropped. 567 4.9. Probe MTU (Type = 11) (obsolete) 569 4.9.1. Uses 571 This option originally provided a mechanism to discover the Path-MTU. 572 It has been declared obsolete. 574 4.9.2. Option specification 576 This option was defined in RFC 1063 [RFC1063]. This option is 577 obsolete. 579 4.9.3. Threats 581 None 583 4.9.4. Operational/interoperability impact if blocked 585 None 587 4.9.5. Advice 589 Filter IP packets that contain a Probe MTU option. 591 4.10. Reply MTU (Type = 12) (obsolete) 593 4.10.1. Uses 595 This option and originally provided a mechanism to discover the Path- 596 MTU. It is now obsolete. 598 4.10.2. Option specification 600 This option was originally specified by RFC 1063 [RFC1063], and is 601 now obsolete. 603 4.10.3. Threats 605 None. 607 4.10.4. Operational/interoperability impact if blocked 609 None 611 4.10.5. Advice 613 Filter IP packets that contain a Reply MTU option. 615 4.11. Traceroute (Type = 82) 617 4.11.1. Uses 619 This option originally provided a mechanism to trace the path to a 620 host. 622 4.11.2. Option specification 624 This option was originally specified by RFC 1393 [RFC1393]. It has 625 been declared obsolete. 627 4.11.3. Threats 629 None 631 4.11.4. Operational/interoperability impact if blocked 633 None 635 4.11.5. Advice 637 Filter IP packets that contain a Traceroute option. 639 4.12. DoD Basic Security Option (Type = 130) 641 4.12.1. Uses 643 This option is used by Multi-Level-Secure (MLS) end-systems and 644 intermediate systems in specific environments to [RFC1108]: 646 o Transmit from source to destination in a network standard 647 representation the common security labels required by computer 648 security models [Landwehr81], 650 o Validate the datagram as appropriate for transmission from the 651 source and delivery to the destination, and, 653 o Ensure that the route taken by the datagram is protected to the 654 level required by all protection authorities indicated on the 655 datagram. 657 The DoD Basic Security Option (BSO) is currently implemented in a 658 number of operating systems (e.g., [IRIX2008], [SELinux2008], 659 [Solaris2008], and [Cisco2008]), and deployed in a number of high- 660 security networks. These networks are typically either in physically 661 secure locations, protected by military/governmental communications 662 security equipment, or both. Such networks are typically built using 663 commercial off-the-shelf (COTS) IP routers and Ethernet switches, but 664 are not normally interconnected with the global public Internet. 665 This option probably has more deployment now than when the IESG 666 removed this option from the IETF standards-track. [RFC5570] 667 describes a similar option recently defined for IPv6 and has much 668 more detailed explanations of how sensitivity label options are used 669 in real-world deployments. 671 4.12.2. Option specification 673 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 674 [RFC1038]). 676 RFC 791 [RFC0791] defined the "Security Option" (Type = 130), 677 which used the same option type as the DoD Basic Security option 678 discussed in this section. The "Security Option" specified in RFC 679 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and 680 therefore the discussion in this section is focused on the DoD 681 Basic Security option specified by RFC 1108 [RFC1108]. 683 Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement 684 this option". 686 [IOS-12.2][RFC4949][RFC3585][RFC4807] 688 4.12.3. Threats 690 Presence of this option in a packet does not by itself create any 691 specific new threat (other than the usual generic issues that might 692 be created if packets with options are forwarded via the "slow 693 path"). Packets with this option ought not normally be seen on the 694 global public Internet. 696 4.12.4. Operational/interoperability impact if blocked 698 If packets with this option are blocked or if the option is stripped 699 from the packet during transmission from source to destination, then 700 the packet itself is likely to be dropped by the receiver because it 701 isn't properly labelled. In some cases, the receiver might receive 702 the packet but associate an incorrect sensitivity label with the 703 received data from the packet whose BSO was stripped by an 704 intermediate router or firewall. Associating an incorrect 705 sensitivity label can cause the received information either to be 706 handled as more sensitive than it really is ("upgrading") or as less 707 sensitive than it really is ("downgrading"), either of which is 708 problematic. 710 4.12.5. Advice 712 Routers and firewalls ought not by default drop packets containing 713 IPSO and also ought not by default strip the IPSO from the packet. 714 For auditing reasons, routers and firewalls SHOULD be capable of 715 logging the numbers of packets containing the BSO on a per-interface 716 basis. Also, routers and firewalls SHOULD be capable of filtering 717 packets based on the BSO presence as well as the BSO values. 719 4.13. DoD Extended Security Option (Type = 133) 720 4.13.1. Uses 722 This option permits additional security labeling information, beyond 723 that present in the Basic Security Option (Section 4.12), to be 724 supplied in an IP datagram to meet the needs of registered 725 authorities. 727 4.13.2. Option specification 729 The DoD Extended Security Option (ESO) is specified by RFC 1108 730 [RFC1108]. 732 [IOS-12.2][RFC4949][RFC3585][RFC4807] 734 4.13.3. Threats 736 Presence of this option in a packet does not by itself create any 737 specific new threat (other than the usual generic issues that might 738 be created if packets with options are forwarded via the "slow 739 path"). Packets with this option ought not normally be seen on the 740 global public Internet 742 4.13.4. Operational/interoperability impact if blocked 744 If packets with this option are blocked or if the option is stripped 745 from the packet during transmission from source to destination, then 746 the packet itself is likely to be dropped by the receiver because it 747 isn't properly labelled. In some cases, the receiver might receive 748 the packet but associate an incorrect sensitivity label with the 749 received data from the packet whose ESO was stripped by an 750 intermediate router or firewall. Associating an incorrect 751 sensitivity label can cause the received information either to be 752 handled as more sensitive than it really is ("upgrading") or as less 753 sensitive than it really is ("downgrading"), either of which is 754 problematic. 756 4.13.5. Advice 758 Routers and firewalls ought not by default drop packets containing an 759 ESO and also ought not by default strip the ESO from the packet. For 760 auditing reasons, routers and firewalls SHOULD be capable of logging 761 the numbers of packets containing the ESO on a per-interface basis. 762 Also, routers and firewalls SHOULD be capable of filtering packets 763 based on the ESO presence as well as the ESO values. 765 4.14. Commercial IP Security Option (CIPSO) (Type = 134) 767 4.14.1. Uses 769 This option was proposed by the Trusted Systems Interoperability 770 Group (TSIG), with the intent of meeting trusted networking 771 requirements for the commercial trusted systems market place. 773 It is currently implemented in a number of operating systems (e.g., 774 IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris 775 [Solaris2008]), and deployed in a number of high-security networks. 777 4.14.2. Option specification 779 This option is specified in [CIPSO1992] and [FIPS1994]. There are 780 zero known IP router implementations of CIPSO. Several MLS operating 781 systems support CIPSO, generally the same MLS operating systems that 782 support IPSO. 784 4.14.3. Threats 786 Presence of this option in a packet does not by itself create any 787 specific new threat (other than the usual generic issues that might 788 be created if packets with options are forwarded via the "slow 789 path"). Packets with this option ought not normally be seen on the 790 global public Internet. 792 4.14.4. Operational/interoperability impact if blocked 794 If packets with this option are blocked or if the option is stripped 795 from the packet during transmission from source to destination, then 796 the packet itself is likely to be dropped by the receiver because it 797 isn't properly labelled. In some cases, the receiver might receive 798 the packet but associate an incorrect sensitivity label with the 799 received data from the packet whose CIPSO was stripped by an 800 intermediate router or firewall. Associating an incorrect 801 sensitivity label can cause the received information either to be 802 handled as more sensitive than it really is ("upgrading") or as less 803 sensitive than it really is ("downgrading"), either of which is 804 problematic. 806 4.14.5. Advice 808 Because of the design of this option, with variable syntax and 809 variable length, it is not practical to support specialized filtering 810 using the CIPSO information. No routers or firewalls are known to 811 support this option. However, by default a router or firewall should 812 not modify or remove this option from IP packets and a router or 813 firewall should not by default drop packets containing this option. 815 4.15. Sender Directed Multi-Destination Delivery (Type = 149) 817 4.15.1. Uses 819 This option originally provided unreliable UDP delivery to a set of 820 addresses included in the option. It is currently obsolete. 822 4.15.2. Option specification 824 This option is defined in RFC 1770 [RFC1770]. 826 4.15.3. Threats 828 This option could have been exploited for bandwidth-amplification in 829 Denial of Service (DoS) attacks. 831 4.15.4. Operational/interoperability impact if blocked 833 None. 835 4.15.5. Advice 837 Filter IP packets that contain a Sender Directed Multi-Destination 838 Delivery option. 840 5. Security Considerations 842 This document provides advice on the filtering of IP packets that 843 contain IP options. Filtering of such packets can help to mitigate 844 the security issues that arise from use of different IP options. 846 6. Acknowledgements 848 The authors would like to thank Carlos Pignataro and Donald Smith for 849 providing valuable comments on earlier versions of this document. 851 Part of this document is based on the document &Security Assesment of 852 the Internet Protocol& [CPNI2008] that is the result of a project 853 carried out by Fernando Gont on behalf of UK CPNI (formerly NISCC). 855 Fernando Gont would like to thank UK CPNI (formerly NISCC) for their 856 continued support. 858 7. Contributors 860 Carlos Pignataro provided material that was incorporated into this 861 document. 863 8. References 865 8.1. Normative References 867 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 868 September 1981. 870 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 871 converting network protocol addresses to 48.bit Ethernet 872 address for transmission on Ethernet hardware", STD 37, 873 RFC 826, November 1982. 875 [RFC1038] St. Johns, M., "Draft revised IP security option", 876 RFC 1038, January 1988. 878 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 879 MTU discovery options", RFC 1063, July 1988. 881 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 883 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 884 RFC 1112, August 1989. 886 [RFC1122] Braden, R., "Requirements for Internet Hosts - 887 Communication Layers", STD 3, RFC 1122, October 1989. 889 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 890 November 1990. 892 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 893 Suite", RFC 1349, July 1992. 895 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 896 January 1993. 898 [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi- 899 Destination Delivery", RFC 1770, March 1995. 901 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 902 RFC 1812, June 1995. 904 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 905 February 1997. 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, March 1997. 910 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 911 "Definition of the Differentiated Services Field (DS 912 Field) in the IPv4 and IPv6 Headers", RFC 2474, 913 December 1998. 915 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 916 and W. Weiss, "An Architecture for Differentiated 917 Services", RFC 2475, December 1998. 919 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 920 in Routers", BCP 34, RFC 2644, August 1999. 922 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 923 Configuration of IPv4 Link-Local Addresses", RFC 3927, 924 May 2005. 926 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 927 Discovery", RFC 4821, March 2007. 929 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 930 BCP 153, RFC 5735, January 2010. 932 8.2. Informative References 934 [Barisani2006] 935 Barisani, A., "FTester - Firewall and IDS testing tool", 936 Available at: http://dev.inversepath.com/trac/ftester , 937 2001. 939 [Biondi2007] 940 Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", 941 CanSecWest 2007 Security Conference http://www.secdev.org/ 942 conf/IPv6_RH_security-csw07.pdf, 2007. 944 [CERT1996a] 945 CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of- 946 Service Attack", 947 http://www.cert.org/advisories/CA-1996-01.html, 1996. 949 [CERT1996c] 950 CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack 951 via ping", 952 http://www.cert.org/advisories/CA-1996-26.html, 1996. 954 [CERT1997] 955 CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service 956 Attacks", http://www.cert.org/advisories/CA-1997-28.html, 957 1997. 959 [CERT1999] 960 CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 961 http://www.cert.org/advisories/CA-1999-17.html, 1999. 963 [CIPSO1992] 964 CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", IETF 965 Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work 966 in progress , 1992. 968 [CIPSOWG1994] 969 CIPSOWG, "Commercial Internet Protocol Security Option 970 (CIPSO) Working Group", http://www.ietf.org/proceedings/ 971 94jul/charters/cipso-charter.html, 1994. 973 [CPNI2008] 974 Gont, F., "Security Assessment of the Internet Protocol", 975 http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008. 977 [Cisco2008] 978 Cisco, "Cisco IOS Security Configuration Guide, Release 979 12.2", http://www.cisco.com/en/US/docs/ios/12_2/security/ 980 configuration/guide/scfipso.html, 2003. 982 [FIPS1994] 983 FIPS, "Standard Security Label for Information Transfer", 984 Federal Information Processing Standards Publication. FIP 985 PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ 986 fips188.pdf, 1994. 988 [Haddad2004] 989 Haddad, I. and M. Zakrzewski, "Security Distribution for 990 Linux Clusters", Linux 991 Journal http://www.linuxjournal.com/article/6943, 2004. 993 [I-D.ietf-intarea-router-alert-considerations] 994 Faucheur, F., "IP Router Alert Considerations and Usage", 995 draft-ietf-intarea-router-alert-considerations-10 (work in 996 progress), August 2011. 998 [I-D.templin-mtuassurance] 999 Templin, F., "Requirements for IP-in-IP Tunnel MTU 1000 Assurance", draft-templin-mtuassurance-02 (work in 1001 progress), October 2006. 1003 [I-D.wilson-class-e] 1004 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 1005 of 240/4 from "Future Use" to "Private Use"", 1006 draft-wilson-class-e-02 (work in progress), 1007 September 2008. 1009 [IANA2006a] 1010 Ether Types, 1011 "http://www.iana.org/assignments/ethernet-numbers". 1013 [IANA2006b] 1014 IP Parameters, 1015 "http://www.iana.org/assignments/ip-parameters". 1017 [IANA2006c] 1018 Protocol Numbers, 1019 "http://www.iana.org/assignments/protocol-numbers". 1021 [IOS-12.2] 1022 Cisco, "IP Security Options Commands", http:// 1023 www.cisco.com/en/US/docs/ios/12_2/security/command/ 1024 reference/srfipso.html, 2011. 1026 [IRIX2008] 1027 IRIX, "IRIX 6.5 trusted_networking(7) manual page", http: 1028 //techpubs.sgi.com/library/tpl/cgi-bin/ 1029 getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ 1030 cat7/trusted_networking.z, 2008. 1032 [Kohno2005] 1033 Kohno, T., Broido, A., and kc. Claffy, "Remote Physical 1034 Device Fingerprinting", IEEE Transactions on Dependable 1035 and Secure Computing Vol. 2, No. 2, 2005. 1037 [Landwehr81] 1038 Landwehr, C., "Formal Models for Computer Security", ACM 1039 Computing Surveys Vol 13, No 3, September 1981, Assoc for 1040 Computing Machinery, New York, NY, USA, 1981. 1042 [Linux2006] 1043 The Linux Project, "http://www.kernel.org". 1045 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 1046 Interactions Between Transport Protocols and Middleboxes", 1047 Proc. 4th ACM SIGCOMM/USENIX Conference on 1048 Internet Measurement, October 2004. 1050 [Microsoft1999] 1051 Microsoft, "Microsoft Security Program: Microsoft Security 1052 Bulletin (MS99-038). Patch Available for "Spoofed Route 1053 Pointer" Vulnerability", http://www.microsoft.com/ 1054 technet/security/bulletin/ms99-038.mspx, 1999. 1056 [Northcutt2000] 1057 Northcut, S. and Novak, "Network Intrusion Detection - An 1058 Analyst's Handbook", Second Edition New Riders Publishing, 1059 2000. 1061 [OpenBSD-PF] 1062 Sanfilippo, S., "PF: Scrub (Packet Normalization)", 1063 http://www.openbsd.org/faq/pf/scrub.html, 2010. 1065 [OpenBSD1998] 1066 OpenBSD, "OpenBSD Security Advisory: IP Source Routing 1067 Problem", 1068 http://www.openbsd.org/advisories/sourceroute.txt, 1998. 1070 [Paxson2001] 1071 Paxson, V., Handley, M., and C. Kreibich, "Network 1072 Intrusion Detection: Evasion, Traffic Normalization, and 1073 End-to-End Protocol Semantics", USENIX Conference, 2001, 1074 2001. 1076 [RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, 1077 July 1982. 1079 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1080 Considerations for IP Fragment Filtering", RFC 1858, 1081 October 1995. 1083 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1084 E. Lear, "Address Allocation for Private Internets", 1085 BCP 5, RFC 1918, February 1996. 1087 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1088 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1089 Functional Specification", RFC 2205, September 1997. 1091 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1092 Network Interconnect Devices", RFC 2544, March 1999. 1094 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1095 Defeating Denial of Service Attacks which employ IP Source 1096 Address Spoofing", BCP 38, RFC 2827, May 2000. 1098 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1099 via IPv4 Clouds", RFC 3056, February 2001. 1101 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1102 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1104 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1105 of Explicit Congestion Notification (ECN) to IP", 1106 RFC 3168, September 2001. 1108 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 1109 Beame, C., Eisler, M., and D. Noveck, "Network File System 1110 (NFS) version 4 Protocol", RFC 3530, April 2003. 1112 [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec 1113 Configuration Policy Information Model", RFC 3585, 1114 August 2003. 1116 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1117 Networks", BCP 84, RFC 3704, March 2004. 1119 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1120 Network Tunneling", RFC 4459, April 2006. 1122 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1123 (CIDR): The Internet Address Assignment and Aggregation 1124 Plan", BCP 122, RFC 4632, August 2006. 1126 [RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. 1127 Wang, "IPsec Security Policy Database Configuration MIB", 1128 RFC 4807, March 2007. 1130 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1131 RFC 4949, August 2007. 1133 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1134 Errors at High Data Rates", RFC 4963, July 2007. 1136 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1137 Mitigations", RFC 4987, August 2007. 1139 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1140 Pignataro, "The Generalized TTL Security Mechanism 1141 (GTSM)", RFC 5082, October 2007. 1143 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 1144 IPv4 and IPv6 Router Alert Options", RFC 5350, 1145 September 2008. 1147 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 1148 Architecture Label IPv6 Security Option (CALIPSO)", 1149 RFC 5570, July 2009. 1151 [SELinux2008] 1152 Security Enhanced Linux, "http://www.nsa.gov/selinux/". 1154 [Silbersack2005] 1155 Silbersack, M., "Improving TCP/IP security through 1156 randomization without sacrificing interoperability", 1157 EuroBSDCon 2005 Conference http://www.silby.com/ 1158 eurobsdcon05/eurobsdcon_slides.pdf, 2005. 1160 [Solaris2008] 1161 Solaris Trusted Extensions - Labeled Security for Absolute 1162 Protection, "http://www.sun.com/software/solaris/ds/ 1163 trusted_extensions.jsp#3", 2008. 1165 [US-CERT2001] 1166 US-CERT, "US-CERT Vulnerability Note VU#446689: Check 1167 Point FireWall-1 allows fragmented packets through 1168 firewall if Fast Mode is enabled", 1169 http://www.kb.cert.org/vuls/id/446689, 2001. 1171 [US-CERT2002] 1172 US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS 1173 discloses fragments of previous packets when Express 1174 Forwarding is enabled", 1175 http://www.kb.cert.org/vuls/id/310387, 2002. 1177 [Zakrzewski2002] 1178 Zakrzewski, M. and I. Haddad, "Linux Distributed Security 1179 Module", http://www.linuxjournal.com/article/6215, 2002. 1181 Appendix A. Changes from previous versions of the draft (to be removed 1182 by the RFC Editor before publishing this document as an 1183 RFC) 1185 A.1. Changes introduced in draft-gont-opsec-ip-options-filtering-01 1187 o Populated many sections that had a "TBD" placeholder. 1189 o Many unused references were prunned from the "References" section. 1191 o Addresses part of the comments provided by Carlos Pignataro and 1192 Donald Smith. 1194 Authors' Addresses 1196 Fernando Gont 1197 Universidad Tecnologica Nacional / Facultad Regional Haedo 1198 Evaristo Carriego 2644 1199 Haedo, Provincia de Buenos Aires 1706 1200 Argentina 1202 Phone: +54 11 4650 8472 1203 Email: fernando@gont.com.ar 1204 URI: http://www.gont.com.ar 1206 RJ Atkinson 1207 Consultant 1208 McLean, VA 22103 1209 USA 1211 Email: rja.lists@gmail.com