idnits 2.17.1 draft-ietf-mpls-ip-options-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 (May 21, 2010) is 5082 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) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group David J. Smith 2 Internet Draft John Mullooly 3 Intended status: Proposed Standard Cisco Systems, Inc. 4 Expiration Date: November 2010 5 William Jaeger 6 AT&T 8 Tom Scholl 9 AT&T Labs 11 May 21, 2010 13 Requirements for Label Edge Router Forwarding of IPv4 Option Packets 15 draft-ietf-mpls-ip-options-04.txt 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 1, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 This document specifies how Label Edge Routers (LER) should behave 58 when determining whether to MPLS encapsulate an IP packet with header 59 options. Lack of a formal standard has resulted in different LER 60 forwarding behaviors for IP packets with header options despite being 61 associated with a prefix-based Forwarding Equivalence Class (FEC). 62 IP option packets that belong to a prefix-based FEC but fail to be 63 MPLS encapsulated simply due to their header options present a 64 security risk against the MPLS infrastructure. Further, LERs that are 65 unable to MPLS encapsulate IP packets with header options cannot 66 operate in certain MPLS environments. While this newly defined LER 67 behavior is mandatory to implement, it is optional to invoke. 69 Table of Contents 71 1 Specification of Requirements ...................... 3 72 2 Motivation ......................................... 3 73 3 Introduction ....................................... 3 74 4 Ingress Label Edge Router Requirement .............. 4 75 5 Security Considerations ............................ 5 76 5.1 IP Option Packets that Bypass MPLS Encapsulation ... 5 77 5.2 Router Alert Label Imposition ...................... 7 78 6 IANA Considerations ................................ 8 79 7 Conclusion ......................................... 8 80 8 Acknowledgements ................................... 8 81 9 Normative References ............................... 8 82 10 Informational References ........................... 8 83 11 Authors' Addresses ................................. 9 85 1. Specification of Requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Motivation 93 This document is motivated by the need to formalize MPLS 94 encapsulation processing of IPv4 packets with header options in order 95 to mitigate the existing risks of IP options-based security attacks 96 against MPLS infrastructures. We believe that this document adds 97 details that have not been fully addressed in [RFC3031] and 98 [RFC3032], and that the methods presented in this document update 99 [RFC3031] as well as complement [RFC3270], [RFC3443] and [RFC4950]. 101 3. Introduction 103 The IP packet header provides for various IP options as originally 104 specified in [RFC791]. IP header options are used to enable control 105 functions within the IP data forwarding plane that are required in 106 some specific situations but not necessary for most common IP 107 communications. Typical IP header options include provisions for 108 timestamps, security, and special routing. Example IP header options 109 & applications include but are not limited to: 110 o Strict & Loose Source Route Options: Used to IP route the IP 111 packet based on information supplied by the source. 112 o Record Route Option: Used to trace the route an IP packet takes. 113 o Router Alert Option: Indicates to downstream IP routers to 114 examine these IP packets more closely. 115 The list of current IP header options can be accessed at [IANA]. 117 IP packets may or may not use IP header options (they are optional) 118 but IP header option handling mechanisms must be implemented by all 119 IP protocol stacks (hosts and routers). Each IP header option has 120 distinct header fields and lengths. IP options extend the IP packet 121 header length beyond the minimum of 20 octets. As a result, IP 122 packets received with header options are typically handled as 123 exceptions and in a less efficient manner due to their variable 124 length and complex processing requirements. For example, many router 125 implementations, punt such IP option packets from the hardware 126 forwarding (fast) path into the software forwarding (slow) path 127 causing high CPU utilization. 129 Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in 130 which packets associated with a prefix-based Forwarding Equivalence 131 Class (FEC) are encapsulated with a label stack and then switched 132 along a label switched path (LSP) by a sequence of label switch 133 routers (LSRs). These intermediate LSRs do not generally perform any 134 processing of the IP header as packets are forwarded. (There are some 135 exceptions to this rule, such as ICMP processing and LSP ping, as 136 described in [RFC3032] and [RFC4379], respectively.) Many MPLS 137 deployments rely on LSRs to provide layer 3 transparency much like 138 ATM switches are transparent at layer 2. Such deployments often 139 minimize the IP routing information (e.g., no BGP transit routes) 140 carried by LSRs since not necessary for MPLS forwarding of transit 141 packets. 143 Even though MPLS encapsulation seems to offer a viable solution to 144 provide layer 3 transparency, there is currently no formal standard 145 for MPLS encapsulation of IP packets with header options that belong 146 to a prefix-based FEC. Lack of a formal standard has resulted in 147 inconsistent forwarding behaviors by ingress LERs. When IP packets 148 are MPLS encapsulated by an ingress LER, for example, the IP header 149 including option fields of transit packets are transparent to 150 downstream LSRs which forward based on the MPLS label(s). 151 Conversely, when a packet is IP forwarded by an ingress LER two 152 undesirable behaviors can result. First a downstream LSR may have not 153 have sufficient IP routing information to forward the packet 154 resulting in packet loss. Second downstream LSRs must apply IP 155 forwarding rules which may expose them to IP security attacks. 157 IP option packets that belong to a prefix-based FEC but fail to be 158 MPLS encapsulated simply due to their header options present a 159 security risk against the MPLS infrastructure. Further, LERs that 160 are unable to MPLS encapsulate IP packets with header options cannot 161 operate as an LER in certain MPLS environments. This new requirement 162 will reduce the risk of IP options-based security attacks against 163 LSRs as well as assist LER operation across MPLS networks which 164 minimize the IP routing information (e.g., no BGP transit routes) 165 carried by LSRs. 167 4. Ingress Label Edge Router Requirement 169 An ingress LER MUST implement the following policy: 171 o When determining whether to push an MPLS label stack onto an IP 172 packet, the determination is made without considering any IP 173 options that may be carried in the IP packet header. Further, 174 the label values that appear in the label stack are determined 175 without considering any such IP options. 177 This policy MAY be configurable on an ingress LER, however, it SHOULD 178 be enabled by default. When processing of signaling messages or data 179 packets with more specific forwarding rules is enabled, this policy 180 SHOULD NOT alter the specific processing rules. This applies to, but 181 is not limited to, RSVP as per [RFC2205] as well as other FEC 182 elements defined by future specifications. Further, how an ingress 183 LER processes the IP header options of packets before MPLS 184 encapsulation is out of scope since the IP packets are received as 185 they enter the MPLS domain. 187 Implementation of the above policy prevents IP packets that belong to 188 a prefix-based FEC from bypassing MPLS encapsulation due to header 189 options. The policy also prevents specific option types such as 190 Router Alert (option value 148), for example, from forcing MPLS 191 imposition of the MPLS Router Alert Label (label value 1) at ingress 192 LERs. Without this policy, the MPLS infrastructure is exposed to 193 security attacks using legitimate IP packets crafted with header 194 options. Further, LERs that are unable to MPLS encapsulate IP 195 packets with header options cannot operate as an LER in certain MPLS 196 environments as described above in Section 3. 198 5. Security Considerations 200 There are two potential categories of attacks using crafted IP option 201 packets that threaten existing MPLS infrastructures. Both are 202 described below. To mitigate the risk of these specific attacks, the 203 ingress LER policy specified above is required. 205 5.1. IP Option Packets that Bypass MPLS Encapsulation 207 Given that a router's exception handling process (i.e., CPU, 208 processor line-card bandwidth, etc.) used for IP header option 209 processing is often shared with IP control and management protocol 210 router resources, a flood of IP packets with header options may 211 adversely affect a router's control and management protocols, 212 thereby, triggering a denial-of-service (DoS) condition. Note, IP 213 packets with header options may be valid transit IP packets with 214 legitimate sources and destinations. Hence, a DoS-like condition may 215 be triggered on downstream transit IP routers that lack protection 216 mechanisms even in the case of legitimate IP option packets. 218 IP option packets that belong to a prefix-based FEC yet bypass MPLS 219 encapsulation at a ingress LER may be inadvertently IP routed 220 downstream across the MPLS core network (not label switched). This 221 allows an external attacker the opportunity to maliciously craft 222 seemingly legitimate IP packets with specific IP header options in 223 order to intentionally bypass MPLS encapsulation at the MPLS edge 224 (i.e., ingress LER) and trigger a DoS condition on downstream LSRs. 225 Some of the specific types of IP option-based security attacks that 226 may be leveraged against MPLS networks include: 227 o Crafted IP option packets that belong to a prefix-based FEC yet 228 bypass MPLS encapsulation at a ingress LER may allow an attacker 229 to DoS downstream LSRs by saturating their software forwarding 230 paths. By targeting a LSR's exception path, control and 231 management protocols may be adversely affected and, thereby, a 232 LSR's availability. This assumes, of course, that downstream 233 LSRs lack protection mechanisms. 234 o Crafted IP option packets that belong to a prefix-based FEC yet 235 bypass MPLS encapsulation at a ingress LER may allow for IP TTL 236 expiry-based DoS attacks against downstream LSRs. MPLS enables 237 IP core hiding whereby transit IP traffic flows see the MPLS 238 network as a single router hop [RFC3443]. However, MPLS core 239 hiding does not apply to packets that bypass MPLS encapsulation 240 and, therefore, IP option packets may be crafted to expire on 241 downstream LSRs which may trigger a DoS condition. Bypassing 242 MPLS core hiding is an additional security consideration since it 243 exposes the network topology. 244 o Crafted IP option packets that belong to a prefix-based FEC yet 245 bypass MPLS encapsulation at a ingress LER may allow for DoS 246 attacks against downstream LSRs that do not carry the IP routing 247 information required to forward transit IP traffic. Lack of such 248 IP routing information may prevent legitimate IP option packets 249 from transiting the MPLS network and, further, may trigger 250 generation of ICMP destination unreachable messages which could 251 lead to a DoS condition. This assumes, of course, that 252 downstream LSRs lack protection mechanisms and do not carry the 253 IP routing information required to forward transit traffic. 254 o Crafted IP option packets that belong to a prefix-based FEC yet 255 bypass MPLS encapsulation at a ingress LER may allow an attacker 256 to bypass LSP Diff-Serv tunnels [RFC3270] and any associated MPLS 257 CoS field [RFC5462] marking policies at ingress LERs and, 258 thereby, adversely affect (i.e., DoS) high-priority traffic 259 classes within the MPLS core. Further, this could also lead to 260 theft of high-priority services by unauthorized parties. This 261 assumes, of course, that the [RFC3270] Pipe model is deployed 262 within the MPLS core. 263 o Crafted IP strict and loose source route option packets that 264 belong to a prefix-based FEC yet bypass MPLS encapsulation at a 265 ingress LER may allow an attacker to specify explicit IP 266 forwarding path(s) across an MPLS network and, thereby, target 267 specific LSRs with any of the DoS attacks outlined above. This 268 assumes, of course, that the MPLS network is enabled to process 269 IP strict and loose source route options. 271 o Crafted RSVP packets that belong to a prefix-based FEC yet bypass 272 MPLS encapsulation at a ingress LER may allow an attacker to 273 build RSVP soft-states [RFC2205, RFC3209] on downstream LSRs 274 which could lead to theft of service by unauthorized parties or 275 to a DoS condition caused by locking up LSR resources. This 276 assumes, of course, that the MPLS network is enabled to process 277 RSVP packets. 279 The security attacks outlined above specifically apply to IP option 280 packets that belong to a prefix-based FEC yet bypass ingress LER 281 label stack imposition. Additionally, these attacks only apply to IP 282 option packets forwarded using the global routing table (i.e., IPv4 283 address family) of a ingress LER. IP option packets associated with 284 a BGP/MPLS IP VPN service are always MPLS encapsulated by the ingress 285 LER per [RFC4364] given that packet forwarding uses a Virtual 286 Forwarding/Routing (VRF) instance. Therefore, BGP/MPLS IP VPN 287 services are not subject to the threats outlined above [RFC4381]. 288 Further, IPv6 [RFC2460] makes use of extension headers not header 289 options and is therefore outside the scope of this document. A 290 separate security threat that does apply to both BGP/MPLS IP VPNs and 291 the IPv4 address family makes use of the Router Alert Label. This is 292 described directly below. 294 5.2. Router Alert Label Imposition 296 [RFC3032] defines a "Router Alert Label" (label value of 1) which is 297 analogous to the "Router Alert" IP header option (option value of 298 148). The MPLS Router Alert Label (when exposed and processed only) 299 indicates to downstream LSRs to examine these MPLS packets more 300 closely. MPLS packets with the MPLS Router Alert Label are also 301 handled as an exception by LSRs and, again, in a less efficient 302 manner. At the time of this writing, the only legitimate use of the 303 Router Alert Label is for LSP ping/trace [RFC4379]. Since there is 304 also no formal standard for Router Alert Label imposition at ingress 305 LERs: 306 o Crafted IP packets with specific IP header options (e.g., Router 307 Alert) and that belong to a prefix-based FEC may allow an 308 attacker to force MPLS imposition of the Router Alert Label at 309 ingress LERs and, thereby, trigger a DoS condition on downstream 310 LSRs. This assumes, of course, that downstream LSRs lack 311 protection mechanisms. 313 6. IANA Considerations 315 This document has no actions for IANA. 317 7. Conclusion 319 This document imposes a new requirement on ingress LERs in order to 320 reduce the risk of IP options-based security attacks against LSRs as 321 well as to assist LER operation across MPLS networks which minimize 322 the IP routing information carried by LSRs. 324 8. Acknowledgements 326 The authors would like to thank Adrian Cepleanu, Bruce Davie, Rick 327 Huber, Chris Metz, Pradosh Mohapatra, Ashok Narayanan, Carlos 328 Pignataro, Eric Rosen, Mark Szczesniak and Yung Yu for their valuable 329 comments and suggestions. 331 9. Normative References 333 [RFC791] Postel, J., "Internet Protocol Specification," RFC791, 334 September 1981. 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels," March 1997. 339 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label 340 Switching Architecture," RFC3031, January 2001. 342 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 343 Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding," 344 RFC3032, January 2001. 346 10. Informational References 348 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 349 "Resource ReSerVation Protocol -- Version 1 Functional 350 Specification," RFC2205, September 1997. 352 [RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6 353 Specification," RFC2460, December 1998. 355 [RFC3209] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, G. 356 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209, 357 December 2001. 359 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 360 P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label 361 Switching Support of Differentiated Services," RFC3270, May 2002. 363 [RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 364 Multi-Protocol Label Switching (MPLS) Networks," RFC3443, January 365 2003. 367 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 368 Networks (VPNs)," RFC4364, February 2006. 370 [RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label 371 Switched (MPLS) Data Plane Failures," RFC4379, February 2006. 373 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 374 Virtual Private Networks (VPNs)," RFC4381, February 2006. 376 [RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP 377 Extensions for Multiprotocol Label Switching," RFC4950, August 2007. 379 [IANA] "IP Option Numbers," IANA, February 15, 2007, 380 . 382 [RFC5462] Andersson, L., and R. Asati, "Multiprotocol Label Switching 383 (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class Field," 384 RFC5462, February 2009. 386 11. Authors' Addresses 388 William Jaeger 389 AT&T 390 200 S. Laurel Avenue 391 Middletown, NJ 07748 392 Email: wjaeger@att.com 394 John Mullooly 395 Cisco Systems, Inc. 396 111 Wood Avenue 397 Iselin, NJ 08830 398 E-mail: jmullool@cisco.com 399 Tom Scholl 400 AT&T Labs 401 200 S. Laurel Avenue 402 Middletown, NJ 07748 403 Email: ts3127@att.com 405 David J. Smith 406 Cisco Systems, Inc. 407 111 Wood Avenue 408 Iselin, NJ 08830 409 E-mail: djsmith@cisco.com