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