idnits 2.17.1 draft-ietf-mpls-ip-options-07.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 24, 2010) is 4844 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 24, 2010 13 Label Edge Router Forwarding of IPv4 Option Packets 15 draft-ietf-mpls-ip-options-07.txt 17 Abstract 19 This document specifies how Label Edge Routers (LER) should behave 20 when determining whether to MPLS encapsulate an IPv4 packet with 21 header options. Lack of a formal standard has resulted in different 22 LER forwarding behaviors for IPv4 packets with header options despite 23 being associated with a prefix-based Forwarding Equivalence Class 24 (FEC). IPv4 option packets that belong to a prefix-based FEC, yet 25 are forwarded into an IPv4/MPLS network without being MPLS- 26 encapsulated, present a security risk against the MPLS 27 infrastructure. Further, LERs that are unable to MPLS encapsulate 28 IPv4 packets with header options cannot operate in certain MPLS 29 environments. While this newly defined LER behavior is mandatory to 30 implement, it is optional 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 .............. 5 76 5 Security Considerations ............................ 5 77 5.1 IPv4 Option Packets that Bypass MPLS Encapsulation . 5 78 5.2 Router Alert Label Imposition ...................... 7 79 6 IANA Considerations ................................ 8 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 IPv4 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 IPv4 packet header provides for various IPv4 options as 104 originally specified in [RFC791]. IPv4 header options are used to 105 enable control functions within the IPv4 data forwarding plane that 106 are required in some specific situations but not necessary for most 107 common IPv4 communications. Typical IPv4 header options include 108 provisions for timestamps, security, and special routing. Example 109 IPv4 header options and applications include but are not limited to: 110 o Strict and Loose Source Route Options: Used to IPv4 route the 111 IPv4 packet based on information supplied by the source. 112 o Record Route Option: Used to trace the route an IPv4 packet 113 takes. 114 o Router Alert Option: Indicates to downstream IPv4 routers to 115 examine these IPv4 packets more closely. 116 The list of current IPv4 header options can be accessed at [IANA]. 118 IPv4 packets may or may not use IPv4 header options (they are 119 optional) but IPv4 header option handling mechanisms must be 120 implemented by all IPv4 protocol stacks (hosts and routers). Each 121 IPv4 header option has distinct header fields and lengths. IPv4 122 options extend the IPv4 packet header length beyond the minimum of 20 123 octets. As a result, IPv4 packets received with header options are 124 typically handled as exceptions and in a less efficient manner due to 125 their variable length and complex processing requirements. For 126 example, many router implementations, punt such IPv4 option packets 127 from the hardware forwarding (fast) path into the software forwarding 128 (slow) path causing high CPU utilization. Even when the forwarding 129 plane can parse a variable length header, it may still need to punt 130 to the control plane, because the forwarding plane may not have the 131 clock cycles or intelligence required to process the header option. 133 Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in 134 which packets associated with a prefix-based Forwarding Equivalence 135 Class (FEC) are encapsulated with a label stack and then switched 136 along a label switched path (LSP) by a sequence of label switch 137 routers (LSRs). These intermediate LSRs do not generally perform any 138 processing of the IPv4 header as packets are forwarded. (There are 139 some exceptions to this rule, such as ICMP processing and LSP ping, 140 as described in [RFC3032] and [RFC4379], respectively.) Many MPLS 141 deployments rely on LSRs to provide layer 3 transparency much like 142 ATM switches are transparent at layer 2. Such deployments often 143 minimize the IPv4 routing information (e.g., no BGP transit routes) 144 carried by LSRs since it is not necessary for MPLS forwarding of 145 transit packets. 147 Even though MPLS encapsulation seems to offer a viable solution to 148 provide layer 3 transparency, there is currently no formal standard 149 for MPLS encapsulation of IPv4 packets with header options that 150 belong to a prefix-based FEC. Lack of a formal standard has resulted 151 in inconsistent forwarding behaviors by ingress Label Edge Routers 152 (LERs). When IPv4 packets are MPLS encapsulated by an ingress LER, 153 for example, the IPv4 header including option fields of transit 154 packets are not acted upon by downstream LSRs which forward based on 155 the MPLS label(s). Conversely, when a packet is IPv4 forwarded by an 156 ingress LER two undesirable behaviors can result. First, a 157 downstream LSR may not have sufficient IPv4 routing information to 158 forward the packet resulting in packet loss. Second, downstream LSRs 159 must apply IPv4 forwarding rules which may expose them to IPv4 160 security attacks. 162 IPv4 option packets that belong to a prefix-based FEC, yet are 163 forwarded into an IPv4/MPLS network without being MPLS-encapsulated, 164 present a security risk against the MPLS infrastructure. Further, 165 LERs that are unable to MPLS encapsulate IPv4 packets with header 166 options cannot operate as an LER in certain MPLS environments. This 167 new requirement will reduce the risk of IPv4 options-based security 168 attacks against LSRs as well as assist LER operation across MPLS 169 networks which minimize the IPv4 routing information (e.g., no BGP 170 transit routes) carried by LSRs. 172 4. Ingress Label Edge Router Requirement 174 An ingress LER MUST implement the following policy: 176 o When determining whether to push an MPLS label stack onto an IPv4 177 packet, the determination is made without considering any IPv4 178 options that may be carried in the IPv4 packet header. Further, 179 the label values that appear in the label stack are determined 180 without considering any such IPv4 options. 182 This policy MAY be configurable on an ingress LER, however, it SHOULD 183 be enabled by default. When processing of signaling messages or data 184 packets with more specific forwarding rules is enabled, this policy 185 SHOULD NOT alter the specific processing rules. This applies to, but 186 is not limited to, RSVP as per [RFC2205], source routing as per 187 [RFC791] as well as other FEC elements defined by future 188 specifications. Further, how an ingress LER processes the IPv4 189 header options of packets before MPLS encapsulation is out of scope 190 since these are processed before they enter the MPLS domain. 192 Implementation of the above policy prevents IPv4 packets that belong 193 to a prefix-based FEC from bypassing MPLS encapsulation due to header 194 options. The policy also prevents specific option types such as 195 Router Alert (option value 148) from forcing MPLS imposition of the 196 MPLS Router Alert Label (label value 1) at ingress LERs. Without 197 this policy, the MPLS infrastructure is exposed to security attacks 198 using legitimate IPv4 packets crafted with header options. Further, 199 LERs that are unable to MPLS encapsulate IPv4 packets with header 200 options cannot operate as an LER in certain MPLS environments as 201 described above in Section 3. 203 5. Security Considerations 205 There are two potential categories of attacks using crafted IPv4 206 option packets that threaten existing MPLS infrastructures. Both are 207 described below. To mitigate the risk of these specific attacks, the 208 ingress LER policy specified above is required. 210 5.1. IPv4 Option Packets that Bypass MPLS Encapsulation 212 Given that a router's exception handling process (i.e., CPU, 213 processor line-card bandwidth, etc.) used for IPv4 header option 214 processing is often shared with IPv4 control and management protocol 215 router resources, a flood of IPv4 packets with header options may 216 adversely affect a router's control and management protocols, 217 thereby, triggering a denial-of-service (DoS) condition. Note, IPv4 218 packets with header options may be valid transit IPv4 packets with 219 legitimate sources and destinations. Hence, a DoS-like condition may 220 be triggered on downstream transit IPv4 routers that lack protection 221 mechanisms even in the case of legitimate IPv4 option packets. 223 IPv4 option packets that belong to a prefix-based FEC yet bypass MPLS 224 encapsulation at an ingress LER may be inadvertently IPv4 routed 225 downstream across the MPLS core network (not label switched). This 226 allows an external attacker the opportunity to maliciously craft 227 seemingly legitimate IPv4 packets with specific IPv4 header options 228 in order to intentionally bypass MPLS encapsulation at the MPLS edge 229 (i.e., ingress LER) and trigger a DoS condition on downstream LSRs. 230 Some of the specific types of IPv4 option-based security attacks that 231 may be leveraged against MPLS networks include: 232 o Crafted IPv4 option packets that belong to a prefix-based FEC yet 233 bypass MPLS encapsulation at an ingress LER may allow an attacker 234 to DoS downstream LSRs by saturating their software forwarding 235 paths. By targeting a LSR's exception path, control and 236 management protocols may be adversely affected and, thereby, a 237 LSR's availability. This assumes, of course, that downstream 238 LSRs lack protection mechanisms. 239 o Crafted IPv4 option packets that belong to a prefix-based FEC yet 240 bypass MPLS encapsulation at an ingress LER may allow for IPv4 241 TTL expiry-based DoS attacks against downstream LSRs. MPLS 242 enables IPv4 core hiding whereby transit IPv4 traffic flows see 243 the MPLS network as a single router hop [RFC3443]. However, MPLS 244 core hiding does not apply to packets that bypass MPLS 245 encapsulation and, therefore, IPv4 option packets may be crafted 246 to expire on downstream LSRs which may trigger a DoS condition. 247 Bypassing MPLS core hiding is an additional security 248 consideration since it exposes the network topology. 249 o Crafted IPv4 option packets that belong to a prefix-based FEC yet 250 bypass MPLS encapsulation at an ingress LER may allow for DoS 251 attacks against downstream LSRs that do not carry the IPv4 252 routing information required to forward transit IPv4 traffic. 253 Lack of such IPv4 routing information may prevent legitimate IPv4 254 option packets from transiting the MPLS network and, further, may 255 trigger generation of ICMP destination unreachable messages which 256 could lead to a DoS condition. This assumes, of course, that 257 downstream LSRs lack protection mechanisms and do not carry the 258 IPv4 routing information required to forward transit traffic. 259 o Crafted IPv4 option packets that belong to a prefix-based FEC yet 260 bypass MPLS encapsulation at an ingress LER may allow an attacker 261 to bypass LSP Diff-Serv tunnels [RFC3270] and any associated MPLS 262 CoS field [RFC5462] marking policies at ingress LERs and, 263 thereby, adversely affect (i.e., DoS) high-priority traffic 264 classes within the MPLS core. Further, this could also lead to 265 theft of high-priority services by unauthorized parties. This 266 assumes, of course, that the [RFC3270] Pipe model is deployed 267 within the MPLS core. 268 o Crafted RSVP packets that belong to a prefix-based FEC yet bypass 269 MPLS encapsulation at an ingress LER may allow an attacker to 270 build RSVP soft-states [RFC2205, RFC3209] on downstream LSRs 271 which could lead to theft of service by unauthorized parties or 272 to a DoS condition caused by locking up LSR resources. This 273 assumes, of course, that the MPLS network is enabled to process 274 RSVP packets. 276 The security attacks outlined above specifically apply to IPv4 option 277 packets that belong to a prefix-based FEC yet bypass ingress LER 278 label stack imposition. Additionally, these attacks only apply to 279 IPv4 option packets forwarded using the global routing table (i.e., 280 IPv4 address family) of a ingress LER. IPv4 option packets 281 associated with a BGP/MPLS IPv4 VPN service are always MPLS 282 encapsulated by the ingress LER per [RFC4364] given that packet 283 forwarding uses a Virtual Forwarding/Routing (VRF) instance. 284 Therefore, BGP/MPLS IPv4 VPN services are not subject to the threats 285 outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use of 286 extension headers not header options and is therefore outside the 287 scope of this document. A separate security threat that does apply 288 to both BGP/MPLS IPv4 VPNs and the IPv4 address family makes use of 289 the Router Alert Label. This is 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" IPv4 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 IPv4 packets with specific IPv4 header options (e.g., 304 Router 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. Acknowledgements 316 The authors would like to thank Adrian Cepleanu, Bruce Davie, Rick 317 Huber, Chris Metz, Pradosh Mohapatra, Ashok Narayanan, Carlos 318 Pignataro, Eric Rosen, Mark Szczesniak and Yung Yu for their valuable 319 comments and suggestions. 321 8. Normative References 323 [RFC791] Postel, J., "Internet Protocol Specification," RFC791, 324 September 1981. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels," March 1997. 329 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label 330 Switching Architecture," RFC3031, January 2001. 332 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 333 Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding," 334 RFC3032, January 2001. 336 9. Informational References 338 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 339 "Resource ReSerVation Protocol -- Version 1 Functional 340 Specification," RFC2205, September 1997. 342 [RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6 343 Specification," RFC2460, December 1998. 345 [RFC3209] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, G. 346 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209, 347 December 2001. 349 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 350 P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label 351 Switching Support of Differentiated Services," RFC3270, May 2002. 353 [RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 354 Multi-Protocol Label Switching (MPLS) Networks," RFC3443, January 355 2003. 357 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 358 Networks (VPNs)," RFC4364, February 2006. 360 [RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label 361 Switched (MPLS) Data Plane Failures," RFC4379, February 2006. 363 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 364 Virtual Private Networks (VPNs)," RFC4381, February 2006. 366 [RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP 367 Extensions for Multiprotocol Label Switching," RFC4950, August 2007. 369 [IANA] "IP Option Numbers," IANA, February 15, 2007, 370 . 372 [RFC5462] Andersson, L., and R. Asati, "Multiprotocol Label Switching 373 (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class Field," 374 RFC5462, February 2009. 376 10. Authors' Addresses 378 William Jaeger 379 AT&T 380 200 S. Laurel Avenue 381 Middletown, NJ 07748 382 Email: wjaeger@att.com 384 John Mullooly 385 Cisco Systems 386 111 Wood Avenue South 387 Iselin, NJ 08830 388 E-mail: jmullool@cisco.com 390 Tom Scholl 391 nLayer Communications 392 209 West Jackson, Suite 700 393 Chicago, IL 60606 394 E-mail: tscholl@nlayer.net 395 David J. Smith 396 Cisco Systems 397 111 Wood Avenue South 398 Iselin, NJ 08830 399 E-mail: djsmith@cisco.com