idnits 2.17.1 draft-ietf-mpls-ip-options-06.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 draft header indicates that this document updates RFC3031, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3031, updated by this document, for RFC5378 checks: 1998-03-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2010) is 4873 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 (==), 5 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 Updates: 3031 Cisco Systems 4 Intended Status: Proposed Standard 5 Expiration Date: June 2011 William Jaeger 6 AT&T 8 Tom Scholl 9 nLayer Communications 11 December 15, 2010 13 Requirements for Label Edge Router Forwarding of IPv4 Option Packets 15 draft-ietf-mpls-ip-options-06.txt 17 Abstract 19 This document specifies how Label Edge Routers (LER) should behave 20 when determining whether to MPLS encapsulate an IP packet with header 21 options. Lack of a formal standard has resulted in different LER 22 forwarding behaviors for IP packets with header options despite being 23 associated with a prefix-based Forwarding Equivalence Class (FEC). 24 IP option packets that belong to a prefix-based FEC, yet are 25 forwarded into an IP/MPLS network without being MPLS-encapsulated, 26 present a security risk against the MPLS infrastructure. Further, 27 LERs that are unable to MPLS encapsulate IP packets with header 28 options cannot operate in certain MPLS environments. While this 29 newly defined LER behavior is mandatory to implement, it is optional 30 to invoke. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on June 1, 2011. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 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 Acknowledgements ................................... 8 81 8 Normative References ............................... 8 82 9 Informational References ........................... 8 83 10 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 and applications include but are not limited to: 110 o Strict and 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. Even when the forwarding plane can 128 parse a variable length header, it may still need to punt to the 129 control plane, because the forwarding plane may not have the clock 130 cycles or intelligence required to process the header option. 132 Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in 133 which packets associated with a prefix-based Forwarding Equivalence 134 Class (FEC) are encapsulated with a label stack and then switched 135 along a label switched path (LSP) by a sequence of label switch 136 routers (LSRs). These intermediate LSRs do not generally perform any 137 processing of the IP header as packets are forwarded. (There are some 138 exceptions to this rule, such as ICMP processing and LSP ping, as 139 described in [RFC3032] and [RFC4379], respectively.) Many MPLS 140 deployments rely on LSRs to provide layer 3 transparency much like 141 ATM switches are transparent at layer 2. Such deployments often 142 minimize the IP routing information (e.g., no BGP transit routes) 143 carried by LSRs since it is not necessary for MPLS forwarding of 144 transit packets. 146 Even though MPLS encapsulation seems to offer a viable solution to 147 provide layer 3 transparency, there is currently no formal standard 148 for MPLS encapsulation of IP packets with header options that belong 149 to a prefix-based FEC. Lack of a formal standard has resulted in 150 inconsistent forwarding behaviors by ingress Label Edge Routers 151 (LERs). When IP packets are MPLS encapsulated by an ingress LER, for 152 example, the IP header including option fields of transit packets are 153 not acted upon by downstream LSRs which forward based on the MPLS 154 label(s). Conversely, when a packet is IP forwarded by an ingress 155 LER two undesirable behaviors can result. First, a downstream LSR may 156 not have sufficient IP routing information to forward the packet 157 resulting in packet loss. Second, downstream LSRs must apply IP 158 forwarding rules which may expose them to IP security attacks. 160 IP option packets that belong to a prefix-based FEC, yet are 161 forwarded into an IP/MPLS network without being MPLS-encapsulated, 162 present a security risk against the MPLS infrastructure. Further, 163 LERs that are unable to MPLS encapsulate IP packets with header 164 options cannot operate as an LER in certain MPLS environments. This 165 new requirement will reduce the risk of IP options-based security 166 attacks against LSRs as well as assist LER operation across MPLS 167 networks which minimize the IP routing information (e.g., no BGP 168 transit routes) carried by LSRs. 170 4. Ingress Label Edge Router Requirement 172 An ingress LER MUST implement the following policy: 174 o When determining whether to push an MPLS label stack onto an IP 175 packet, the determination is made without considering any IP 176 options that may be carried in the IP packet header. Further, 177 the label values that appear in the label stack are determined 178 without considering any such IP options. 180 This policy MAY be configurable on an ingress LER, however, it SHOULD 181 be enabled by default. When processing of signaling messages or data 182 packets with more specific forwarding rules is enabled, this policy 183 SHOULD NOT alter the specific processing rules. This applies to, but 184 is not limited to, RSVP as per [RFC2205], source routing as per 185 [RFC791] as well as other FEC elements defined by future 186 specifications. Further, how an ingress LER processes the IP header 187 options of packets before MPLS encapsulation is out of scope since 188 these are processed before they enter the MPLS domain. 190 Implementation of the above policy prevents IP packets that belong to 191 a prefix-based FEC from bypassing MPLS encapsulation due to header 192 options. The policy also prevents specific option types such as 193 Router Alert (option value 148) from forcing MPLS imposition of the 194 MPLS Router Alert Label (label value 1) at ingress LERs. Without 195 this policy, the MPLS infrastructure is exposed to security attacks 196 using legitimate IP packets crafted with header options. Further, 197 LERs that are unable to MPLS encapsulate IP packets with header 198 options cannot operate as an LER in certain MPLS environments as 199 described above in Section 3. 201 5. Security Considerations 203 There are two potential categories of attacks using crafted IP option 204 packets that threaten existing MPLS infrastructures. Both are 205 described below. To mitigate the risk of these specific attacks, the 206 ingress LER policy specified above is required. 208 5.1. IP Option Packets that Bypass MPLS Encapsulation 210 Given that a router's exception handling process (i.e., CPU, 211 processor line-card bandwidth, etc.) used for IP header option 212 processing is often shared with IP control and management protocol 213 router resources, a flood of IP packets with header options may 214 adversely affect a router's control and management protocols, 215 thereby, triggering a denial-of-service (DoS) condition. Note, IP 216 packets with header options may be valid transit IP packets with 217 legitimate sources and destinations. Hence, a DoS-like condition may 218 be triggered on downstream transit IP routers that lack protection 219 mechanisms even in the case of legitimate IP option packets. 221 IP option packets that belong to a prefix-based FEC yet bypass MPLS 222 encapsulation at an ingress LER may be inadvertently IP routed 223 downstream across the MPLS core network (not label switched). This 224 allows an external attacker the opportunity to maliciously craft 225 seemingly legitimate IP packets with specific IP header options in 226 order to intentionally bypass MPLS encapsulation at the MPLS edge 227 (i.e., ingress LER) and trigger a DoS condition on downstream LSRs. 228 Some of the specific types of IP option-based security attacks that 229 may be leveraged against MPLS networks include: 230 o Crafted IP option packets that belong to a prefix-based FEC yet 231 bypass MPLS encapsulation at an ingress LER may allow an attacker 232 to DoS downstream LSRs by saturating their software forwarding 233 paths. By targeting a LSR's exception path, control and 234 management protocols may be adversely affected and, thereby, a 235 LSR's availability. This assumes, of course, that downstream 236 LSRs lack protection mechanisms. 237 o Crafted IP option packets that belong to a prefix-based FEC yet 238 bypass MPLS encapsulation at an ingress LER may allow for IP TTL 239 expiry-based DoS attacks against downstream LSRs. MPLS enables 240 IP core hiding whereby transit IP traffic flows see the MPLS 241 network as a single router hop [RFC3443]. However, MPLS core 242 hiding does not apply to packets that bypass MPLS encapsulation 243 and, therefore, IP option packets may be crafted to expire on 244 downstream LSRs which may trigger a DoS condition. Bypassing 245 MPLS core hiding is an additional security consideration since it 246 exposes the network topology. 247 o Crafted IP option packets that belong to a prefix-based FEC yet 248 bypass MPLS encapsulation at an ingress LER may allow for DoS 249 attacks against downstream LSRs that do not carry the IP routing 250 information required to forward transit IP traffic. Lack of such 251 IP routing information may prevent legitimate IP option packets 252 from transiting the MPLS network and, further, may trigger 253 generation of ICMP destination unreachable messages which could 254 lead to a DoS condition. This assumes, of course, that 255 downstream LSRs lack protection mechanisms and do not carry the 256 IP routing information required to forward transit traffic. 257 o Crafted IP option packets that belong to a prefix-based FEC yet 258 bypass MPLS encapsulation at an ingress LER may allow an attacker 259 to bypass LSP Diff-Serv tunnels [RFC3270] and any associated MPLS 260 CoS field [RFC5462] marking policies at ingress LERs and, 261 thereby, adversely affect (i.e., DoS) high-priority traffic 262 classes within the MPLS core. Further, this could also lead to 263 theft of high-priority services by unauthorized parties. This 264 assumes, of course, that the [RFC3270] Pipe model is deployed 265 within the MPLS core. 266 o Crafted RSVP packets that belong to a prefix-based FEC yet bypass 267 MPLS encapsulation at an ingress LER may allow an attacker to 268 build RSVP soft-states [RFC2205, RFC3209] on downstream LSRs 269 which could lead to theft of service by unauthorized parties or 270 to a DoS condition caused by locking up LSR resources. This 271 assumes, of course, that the MPLS network is enabled to process 272 RSVP packets. 274 The security attacks outlined above specifically apply to IP option 275 packets that belong to a prefix-based FEC yet bypass ingress LER 276 label stack imposition. Additionally, these attacks only apply to IP 277 option packets forwarded using the global routing table (i.e., IPv4 278 address family) of a ingress LER. IP option packets associated with 279 a BGP/MPLS IP VPN service are always MPLS encapsulated by the ingress 280 LER per [RFC4364] given that packet forwarding uses a Virtual 281 Forwarding/Routing (VRF) instance. Therefore, BGP/MPLS IP VPN 282 services are not subject to the threats outlined above [RFC4381]. 283 Further, IPv6 [RFC2460] makes use of extension headers not header 284 options and is therefore outside the scope of this document. A 285 separate security threat that does apply to both BGP/MPLS IP VPNs and 286 the IPv4 address family makes use of the Router Alert Label. This is 287 described directly below. 289 5.2. Router Alert Label Imposition 291 [RFC3032] defines a "Router Alert Label" (label value of 1) which is 292 analogous to the "Router Alert" IP header option (option value of 293 148). The MPLS Router Alert Label (when exposed and processed only) 294 indicates to downstream LSRs to examine these MPLS packets more 295 closely. MPLS packets with the MPLS Router Alert Label are also 296 handled as an exception by LSRs and, again, in a less efficient 297 manner. At the time of this writing, the only legitimate use of the 298 Router Alert Label is for LSP ping/trace [RFC4379]. Since there is 299 also no formal standard for Router Alert Label imposition at ingress 300 LERs: 301 o Crafted IP packets with specific IP header options (e.g., Router 302 Alert) and that belong to a prefix-based FEC may allow an 303 attacker to force MPLS imposition of the Router Alert Label at 304 ingress LERs and, thereby, trigger a DoS condition on downstream 305 LSRs. This assumes, of course, that downstream LSRs lack 306 protection mechanisms. 308 6. IANA Considerations 310 This document has no actions for IANA. 312 7. 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 8. 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 9. 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 [RFC5462] Andersson, L., and R. Asati, "Multiprotocol Label Switching 371 (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class Field," 372 RFC5462, February 2009. 374 10. Authors' Addresses 376 William Jaeger 377 AT&T 378 200 S. Laurel Avenue 379 Middletown, NJ 07748 380 Email: wjaeger@att.com 382 John Mullooly 383 Cisco Systems 384 111 Wood Avenue South 385 Iselin, NJ 08830 386 E-mail: jmullool@cisco.com 388 Tom Scholl 389 nLayer Communications 390 209 West Jackson, Suite 700 391 Chicago, IL 60606 392 E-mail: tscholl@nlayer.net 393 David J. Smith 394 Cisco Systems 395 111 Wood Avenue South 396 Iselin, NJ 08830 397 E-mail: djsmith@cisco.com