idnits 2.17.1 draft-ietf-mpls-ip-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 437. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document date (December 7, 2008) is 5609 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3209' is defined on line 343, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-cosfield-def-07 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David J. Smith 3 Internet Draft John Mullooly 4 Intended status: Proposed Standard Cisco Systems, Inc. 5 Expiration Date: June 2009 6 William Jaeger 7 AT&T 9 Tom Scholl 10 AT&T Labs 12 December 7, 2008 14 Requirements for Label Edge Router Forwarding of IPv4 Option Packets 16 draft-ietf-mpls-ip-options-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document imposes a new requirement on Label Edge Routers (LER) 44 specifying that when determining whether to MPLS encapsulate an IP 45 packet, the determination is made independent of any IP options that 46 may be carried in the IP packet header. Lack of a formal standard 47 has resulted in different LER forwarding behaviors for IP packets 48 with header options despite being associated with a prefix-based 49 Forwarding Equivalence Class (FEC). IP option packets that belong to 50 a prefix-based FEC but fail to be MPLS encapsulated simply due to 51 their header options present a security risk against the MPLS 52 infrastructure. Further, LERs that are unable to MPLS encapsulate IP 53 packets with header options cannot operate in certain MPLS 54 environments. This new requirement will reduce the risk of IP 55 options-based security attacks against LSRs as well as assist LER 56 operation across MPLS networks which minimize the IP routing 57 information carried by LSRs. 59 Table of Contents 61 1 Specification of Requirements ...................... 2 62 2 Motivation ......................................... 3 63 3 Introduction ....................................... 3 64 4 Ingress Label Edge Router Requirement .............. 4 65 5 Security Considerations ............................ 5 66 5.1 IP Option Packets that Bypass MPLS Encapsulation ... 5 67 5.2 Router Alert Label Imposition ...................... 7 68 6 IANA Considerations ................................ 7 69 7 Conclusion ......................................... 7 70 8 Acknowledgements ................................... 8 71 9 Normative References ............................... 8 72 10 Informational References ........................... 8 73 11 Authors' Addresses ................................. 9 74 12 Full Copyright Statement ........................... 10 75 13 Intellectual Property .............................. 10 77 1. Specification of Requirements 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Motivation 85 This document is motivated by the need to formalize MPLS 86 encapsulation processing of IPv4 packets with header options in order 87 to mitigate the existing risks of IP options-based security attacks 88 against MPLS infrastructures. We believe that this document adds 89 details that have not been fully addressed in [RFC3031] and 90 [RFC3032], and that the methods presented in this document update 91 [RFC3031] as well as complement [RFC3270], [RFC3443] and [RFC4950]. 93 3. Introduction 95 The IP packet header provides for various IP options as originally 96 specified in [RFC791]. IP header options are used to enable control 97 functions within the IP data forwarding plane that are required in 98 some specific situations but not necessary for most common IP 99 communications. Typical IP header options include provisions for 100 timestamps, security, and special routing. Example IP header options 101 & applications include but are not limited to: 102 o Strict & Loose Source Route Options: Used to IP route the IP 103 packet based on information supplied by the source. 104 o Record Route Option: Used to trace the route an IP packet takes. 105 o Router Alert Option: Indicates to downstream IP routers to 106 examine these IP packets more closely. 107 The list of current IP header options can be accessed at [IANA]. 109 IP packets may or may not use IP header options (they are optional) 110 but IP header option handling mechanisms must be implemented by all 111 IP protocol stacks (hosts and routers). Each IP header option has 112 distinct header fields and lengths. IP options extend the IP packet 113 header length beyond the minimum of 20 octets. As a result, IP 114 packets received with header options are typically handled as 115 exceptions and in a less efficient manner due to their variable 116 length and complex processing requirements. Many router 117 implementations, for example, punt such IP option packets from the 118 hardware forwarding (fast) path into the software forwarding (slow) 119 path. 121 Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in 122 which packets associated with a prefix-based Forwarding Equivalence 123 Class (FEC) are encapsulated with a label stack and then switched 124 along a label switched path (LSP) by a sequence of label switch 125 routers (LSRs). These intermediate LSRs do not generally perform any 126 processing of the IP header as packets are forwarded. (There are some 127 exceptions to this rule, such as ICMP processing and LSP ping, as 128 described in [RFC3032] and [RFC4379], respectively.) Many MPLS 129 deployments rely on LSRs to provide layer 3 transparency much like 130 ATM switches are transparent at layer 2. Such deployments often 131 minimize the IP routing information (e.g., no BGP transit routes) 132 carried by LSRs since not necessary for MPLS forwarding of transit 133 packets. 135 Even though MPLS encapsulation seems to offer a viable solution to 136 provide layer 3 transparency, there is currently no formal standard 137 for MPLS encapsulation of IP packets with header options that below 138 to a prefix-based FEC. Lack of a formal standard has resulted in 139 inconsistent forwarding behaviors by ingress LERs. When MPLS 140 encapsulated by an ingress LER, for example, the IP header including 141 option fields of transit packets are transparent to downstream LSRs 142 given MPLS forwarding. Conversely, when IP routed by an ingress LER, 143 downstream LSRs must apply IP forwarding rules which may expose the 144 LSRs to IP security attacks and for which they (the LSRs) may have 145 insufficient IP routing information. 147 IP option packets that belong to a prefix-based FEC but fail to be 148 MPLS encapsulated simply due to their header options present a 149 security risk against the MPLS infrastructure. Further, LERs that 150 are unable to MPLS encapsulate IP packets with header options cannot 151 operate as an LER in certain MPLS environments. This new requirement 152 will reduce the risk of IP options-based security attacks against 153 LSRs as well as assist LER operation across MPLS networks which 154 minimize the IP routing information (e.g., no BGP transit routes) 155 carried by LSRs. 157 4. Ingress Label Edge Router Requirement 159 An ingress LER MUST implement the following policy: 161 o When determining whether to push an MPLS label stack onto an IP 162 packet, the determination is made without considering any IP 163 options that may be carried in the IP packet header. Further, 164 the label values that appear in the label stack are determined 165 without considering any such IP options. 167 This policy MAY be configurable on an ingress LER, however, it SHOULD 168 be enabled by default. When processing of signaling messages or data 169 packets with more specific forwarding rules is enabled, this policy 170 SHOULD NOT alter the specific processing rules. This applies to, but 171 is not limited to, RSVP as per [RFC2205] as well as other FEC 172 elements defined by future specifications. Further, how an ingress 173 LER processes the IP header options of packets before MPLS 174 encapsulation is out of scope since the IP packets are received as 175 they enter the MPLS domain. 177 Implementation of the above policy prevents IP packets that belong to 178 a prefix-based FEC from bypassing MPLS encapsulation due to header 179 options. The policy also prevents specific option types such as 180 Router Alert (option value 148), for example, from forcing MPLS 181 imposition of the MPLS Router Alert Label (label value 1) at ingress 182 LERs. Without this policy, the MPLS infrastructure is exposed to 183 security attacks using legitimate IP packets crafted with header 184 options. Further, LERs that are unable to MPLS encapsulate IP 185 packets with header options cannot operate as an LER in certain MPLS 186 environments as described above in Section 3. 188 5. Security Considerations 190 There are two potential categories of attacks using crafted IP option 191 packets that threaten existing MPLS infrastructures. Both are 192 described below. To mitigate the risk of these specific attacks, the 193 ingress LER policy specified above is required. 195 5.1. IP Option Packets that Bypass MPLS Encapsulation 197 Given that a router's exception handling process (i.e., CPU, 198 processor line-card bandwidth, etc.) used for IP header option 199 processing is often shared with IP control and management protocol 200 router resources, a flood of IP packets with header options may 201 adversely affect a router's control and management protocols, 202 thereby, triggering a denial-of-service (DoS) condition. Note, IP 203 packets with header options may be valid transit IP packets with 204 legitimate sources and destinations. Hence, a DoS-like condition may 205 be triggered on downstream transit IP routers that lack protection 206 mechanisms even in the case of legitimate IP option packets. 208 IP option packets that below to a prefix-based FEC yet bypass MPLS 209 encapsulation at a ingress LER may be inadvertently IP routed 210 downstream across the MPLS core network (not label switched). This 211 allows an external attacker the opportunity to maliciously craft 212 seemingly legitimate IP packets with specific IP header options in 213 order to intentionally bypass MPLS encapsulation at the MPLS edge 214 (i.e., ingress LER) and trigger a DoS condition on downstream LSRs. 215 Some of the specific types of IP option-based security attacks that 216 may be leveraged against MPLS networks include: 217 o Crafted IP option packets that below to a prefix-based FEC yet 218 bypass MPLS encapsulation at a ingress LER may allow an attacker 219 to DoS downstream LSRs by saturating their software forwarding 220 paths. By targeting a LSR's exception path, control and 221 management protocols may be adversely affected and, thereby, a 222 LSR's availability. This assumes, of course, that downstream 223 LSRs lack protection mechanisms. 224 o Crafted IP option packets that below to a prefix-based FEC yet 225 bypass MPLS encapsulation at a ingress LER may allow for IP TTL 226 expiry-based DoS attacks against downstream LSRs. MPLS enables 227 IP core hiding whereby transit IP traffic flows see the MPLS 228 network as a single router hop [RFC3443]. However, MPLS core 229 hiding does not apply to packets that bypass MPLS encapsulation 230 and, therefore, IP option packets may be crafted to expire on 231 downstream LSRs which may trigger a DoS condition. Bypassing 232 MPLS core hiding is an additional security consideration since it 233 exposes the network topology. 234 o Crafted IP option packets that below to a prefix-based FEC yet 235 bypass MPLS encapsulation at a ingress LER may allow for DoS 236 attacks against downstream LSRs that do not carry the IP routing 237 information required to forward transit IP traffic. Lack of such 238 IP routing information may prevent legitimate IP option packets 239 from transiting the MPLS network and, further, may trigger 240 generation of ICMP destination unreachable messages which could 241 lead to a DoS condition. This assumes, of course, that 242 downstream LSRs lack protection mechanisms and do not carry the 243 IP routing information required to forward transit traffic. 244 o Crafted IP option packets that below to a prefix-based FEC yet 245 bypass MPLS encapsulation at a ingress LER may allow an attacker 246 to bypass LSP Diff-Serv tunnels [RFC3270] and any associated MPLS 247 CoS field [MPLSCOS] marking policies at ingress LERs and, 248 thereby, adversely affect (i.e., DoS) high-priority traffic 249 classes within the MPLS core. Further, this could also lead to 250 theft of high-priority services by unauthorized parties. This 251 assumes, of course, that the [RFC3270] Pipe model is deployed 252 within the MPLS core. 253 o Crafted IP strict and loose source route option packets that 254 below to a prefix-based FEC yet bypass MPLS encapsulation at a 255 ingress LER may allow an attacker to specify explicit IP 256 forwarding path(s) across an MPLS network and, thereby, target 257 specific LSRs with any of the DoS attacks outlined above. This 258 assumes, of course, that the MPLS network is enabled to process 259 IP strict and loose source route options. 260 o Crafted RSVP packets that below to a prefix-based FEC yet bypass 261 MPLS encapsulation at a ingress LER may allow an attacker to 262 build RSVP soft-states [RFC2205] on downstream LSRs which could 263 lead to theft of service by unauthorized parties or to a DoS 264 condition caused by locking up LSR resources. This assumes, of 265 course, that the MPLS network is enabled to process RSVP packets. 267 The security attacks outlined above specifically apply to IP option 268 packets that below to a prefix-based FEC yet bypass ingress LER label 269 stack imposition. Additionally, these attacks only apply to IP 270 option packets forwarded using the global routing table (i.e., IPv4 271 address family) of a ingress LER. IP option packets associated with 272 a BGP/MPLS IP VPN service are always MPLS encapsulated by the ingress 273 LER per [RFC4364] given that packet forwarding uses a Virtual 274 Forwarding/Routing (VRF) instance. Therefore, BGP/MPLS IP VPN 275 services are not subject to the threats outlined above [RFC4381]. 276 Further, IPv6 [RFC2460] makes use of extension headers not header 277 options and is therefore outside the scope of this document. A 278 separate security threat that does apply to both BGP/MPLS IP VPNs and 279 the IPv4 address family makes use of the Router Alert Label. This is 280 described directly below. 282 5.2. Router Alert Label Imposition 284 [RFC3032] defines a "Router Alert Label" (label value of 1) which is 285 analogous to the "Router Alert" IP header option (option value of 286 148). The MPLS Router Alert Label (when exposed and processed only) 287 indicates to downstream LSRs to examine these MPLS packets more 288 closely. MPLS packets with the MPLS Router Alert Label are also 289 handled as an exception by LSRs and, again, in a less efficient 290 manner. At the time of this writing, the only legitimate use of the 291 Router Alert Label is for LSP ping/trace [RFC4379]. Since there is 292 also no formal standard for Router Alert Label imposition at ingress 293 LERs: 294 o Crafted IP packets with specific IP header options (e.g., Router 295 Alert) and that below to a prefix-based FEC may allow an attacker 296 to force MPLS imposition of the Router Alert Label at ingress 297 LERs and, thereby, trigger a DoS condition on downstream LSRs. 298 This assumes, of course, that downstream LSRs lack protection 299 mechanisms. 301 6. IANA Considerations 303 This document has no actions for IANA. 305 7. Conclusion 307 This document imposes a new requirement on ingress LERs in order to 308 reduce the risk of IP options-based security attacks against LSRs as 309 well as to assist LER operation across MPLS networks which minimize 310 the IP routing information carried by LSRs. 312 8. Acknowledgements 314 The authors would like to thank Adrian Cepleanu, Bruce Davie, Rick 315 Huber, Chris Metz, Pradosh Mohapatra, Ashok Narayanan, Carlos 316 Pignataro, Eric Rosen, Mark Szczesniak and Yung Yu for their valuable 317 comments and suggestions. 319 9. Normative References 321 [RFC791] Postel, J., "Internet Protocol Specification," RFC791, 322 September 1981. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels," March 1997. 327 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label 328 Switching Architecture," RFC3031, January 2001. 330 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 331 Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding," 332 RFC3032, January 2001. 334 10. Informational References 336 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 337 "Resource ReSerVation Protocol -- Version 1 Functional 338 Specification," RFC2205, September 1997. 340 [RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6 341 Specification," RFC2460, December 1998. 343 [RFC3209] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, G. 344 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209, 345 December 2001. 347 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 348 P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label 349 Switching Support of Differentiated Services," RFC3270, May 2002. 351 [RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 352 Multi-Protocol Label Switching (MPLS) Networks," RFC3443, January 353 2003. 355 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 356 Networks (VPNs)," RFC4364, February 2006. 358 [RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label 359 Switched (MPLS) Data Plane Failures," RFC4379, February 2006. 361 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 362 Virtual Private Networks (VPNs)," RFC4381, February 2006. 364 [RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP 365 Extensions for Multiprotocol Label Switching," RFC4950, August 2007. 367 [IANA] "IP Option Numbers," IANA, February 15, 2007, 368 . 370 [MPLSCOS] Andersson, L., "EXP Field renamed to Traffic Class Field," 371 IETF draft-ietf-mpls-cosfield-def-07.txt, November 17, 2008. 373 11. Authors' Addresses 375 William Jaeger 376 AT&T 377 200 S. Laurel Avenue 378 Middletown, NJ 07748 379 Email: wjaeger@att.com 381 John Mullooly 382 Cisco Systems, Inc. 383 111 Wood Avenue 384 Iselin, NJ 08830 385 E-mail: jmullool@cisco.com 387 Tom Scholl 388 AT&T Labs 389 200 S. Laurel Avenue 390 Middletown, NJ 07748 391 Email: ts3127@att.com 393 David J. Smith 394 Cisco Systems, Inc. 395 111 Wood Avenue 396 Iselin, NJ 08830 397 E-mail: djsmith@cisco.com 399 12. Full Copyright Statement 401 Copyright (C) The IETF Trust (2008). 403 This document is subject to the rights, licenses and restrictions 404 contained in BCP 78, and except as set forth therein, the authors 405 retain all their rights. 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 410 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 411 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 412 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 13. Intellectual Property 417 The IETF takes no position regarding the validity or scope of any 418 Intellectual Property Rights or other rights that might be claimed to 419 pertain to the implementation or use of the technology described in 420 this document or the extent to which any license under such rights 421 might or might not be available; nor does it represent that it has 422 made any independent effort to identify any such rights. Information 423 on the procedures with respect to rights in RFC documents can be 424 found in BCP 78 and BCP 79. 426 Copies of IPR disclosures made to the IETF Secretariat and any 427 assurances of licenses to be made available, or the result of an 428 attempt made to obtain a general license or permission for the use of 429 such proprietary rights by implementers or users of this 430 specification can be obtained from the IETF on-line IPR repository at 431 http://www.ietf.org/ipr. 433 The IETF invites any interested party to bring to its attention any 434 copyrights, patents or patent applications, or other proprietary 435 rights that may cover technology that may be required to implement 436 this standard. Please address the information to the IETF at ietf- 437 ipr@ietf.org.