idnits 2.17.1 draft-dasmith-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. 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 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 (June 30, 2008) is 5750 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) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-cosfield-def-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 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: December 2008 6 William Jaeger 7 Tom Scholl 8 AT&T 10 June 30, 2008 12 Requirements for Label Edge Router Forwarding of IPv4 Option Packets 14 draft-dasmith-mpls-ip-options-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of 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 Abstract 41 This document imposes a new requirement on Label Edge Routers (LER) 42 specifying that when determining whether to MPLS encapsulate an IP 43 packet, the determination is made independent of any IP options that 44 may be carried in the IP packet header. Lack of a formal standard 45 may result in a different forwarding behavior for different IP 46 packets associated with the same prefix-based Forwarding Equivalence 47 Class (FEC). While an IP packet with either a specific option type 48 or no header option may follow the MPLS label switched path (LSP) 49 associated with a prefix-based FEC, an IP packet with a different 50 option type but associated with the same prefix-based FEC may bypass 51 MPLS encapsulation and instead be IP routed downstream. IP option 52 packets that inadvertently bypass MPLS encapsulation present an 53 increased security risk against the MPLS infrastructure. 55 Table of Contents 57 1 Specification of Requirements ...................... 2 58 2 Motivation ......................................... 2 59 3 Introduction ....................................... 3 60 4 Ingress Label Edge Router Requirement .............. 4 61 5 Security Considerations ............................ 5 62 5.1 IP Option Packets that Bypass MPLS Encapsulation ... 5 63 5.2 Router Alert Label Imposition ...................... 6 64 6 IANA Considerations ................................ 7 65 7 Conclusion ......................................... 7 66 8 Acknowledgements ................................... 7 67 9 Normative References ............................... 7 68 10 Informational References ........................... 8 69 11 Authors' Addresses ................................. 8 70 12 Full Copyright Statement ........................... 9 71 13 Intellectual Property .............................. 10 73 1.0 Specification of Requirements 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2.0 Motivation 81 This document is motivated by the need to formalize MPLS 82 encapsulation processing of IP packets with header options transiting 83 an MPLS network. We believe that this document adds details that 84 have not been fully addressed in [RFC3031] and [RFC3032], and that 85 the methods presented in this document update [RFC3031] as well as 86 complement [RFC3443] and [RFC4950]. 88 3.0 Introduction 90 The IP packet header provides for various IP options as originally 91 specified in [RFC791]. IP header options are used to enable control 92 functions within the IP data forwarding plane that are required in 93 some specific situations but not necessary for most common IP 94 communications. Typical IP header options include provisions for 95 timestamps, security, and special routing. Example IP header options 96 & applications include but are not limited to: 97 o Strict & Loose Source Route Options: Used to IP route the IP 98 packet based on information supplied by the source. 99 o Record Route Option: Used to trace the route an IP packet takes. 100 o Router Alert Option: Indicates to downstream IP routers to 101 examine these IP packets more closely. 102 The list of current IP header options can be accessed at [IANA]. 104 IP packets may or may not use IP header options (they are optional) 105 but IP header option handling mechanisms must be implemented by all 106 IP protocol stacks (hosts and routers). Each IP header option has 107 distinct header fields and lengths. IP options extend the IP packet 108 header length beyond the minimum of 20 octets. As a result, IP 109 packets received with header options are typically handled as 110 exceptions and in a less efficient manner due to their variable 111 length and complex processing requirements. Many router 112 implementations, for example, punt such packets from the hardware 113 forwarding (fast) path into the software forwarding (slow) path. 115 Multi-Protocol Label Switching (MPLS) [RFC3031] is primarily a 116 service provider (SP) technology where IP traffic can be encapsulated 117 with a label stack and then label switched across a network via Label 118 Switched Paths (LSPs) and Routers (LSRs). MPLS forwarding will 119 follow either hop-by-hop routing or source-routing as determined by 120 IP routing policies. MPLS provides SPs with the control plane 121 intelligence of IP while at the same time enabling layer 3 122 transparency much like ATM switches are transparent at layer 2. That 123 is, when a MPLS label stack is imposed at a ingress Label Edge Router 124 (LER), downstream LSRs generally use the MPLS label information for 125 their forwarding decision instead of the encapsulated IP header 126 information. In this way, except when ICMP processing is required per 127 [RFC3032] LSRs can avoid processing the IP network layer headers of 128 transit traffic. 130 Even though MPLS encapsulation seems to offer a viable solution to 131 protect downstream LSRs from being adversely impacted by customer 132 packets with IP header options, there is currently no formal standard 133 for encapsulation of IP packets with header options in MPLS networks. 134 When MPLS encapsulated, IP option packets are processed by downstream 135 LSRs as native MPLS packets within their forwarding paths. In this 136 way, the IP header options are effectively ignored by downstream LSRs 137 when encapsulated with a MPLS label stack. However, for many LER 138 implementations not all IP packets with header options are MPLS 139 encapsulated by the ingress LER. 141 Lack of a formal standard has resulted in inconsistent forwarding 142 behaviors by ingress LERs. Namely, IP packets with different types 143 of IP header options are handled differently by an ingress LER 144 despite being associated with the same prefix-based FEC as defined in 145 Section 4.1.1 of [RFC3031]. For instance, some IP header options may 146 inadvertently bypass MPLS encapsulation and the associated LSPs, and 147 are instead IP routed downstream on a per-hop basis by downstream 148 LSRs within the MPLS core. The different forwarding behaviors not 149 only vary across IP option types but also across ingress LER 150 implementations given no formal standard for IP header option 151 processing in MPLS networks. This document imposes a new requirement 152 on ingress LERs in order to reduce the risk of IP options-based 153 security attacks against LSRs as well as to minimize the IP routing 154 information carried by LSRs. 156 4.0 Ingress Label Edge Router Requirement 158 An ingress LER MUST implement the following policy, and the policy 159 MUST be enabled by default: 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, the 164 label values that appear in the label stack are determined 165 without considering any such IP options. 167 Further, how an ingress LER processes IP header options before MPLS 168 encapsulation is out of scope as it is not relevant to MPLS. 169 Similarly, an egress LER SHOULD only process IP options in those 170 cases where the egress LER forwarding decision is based on the native 171 IP packet. When the egress LER forwarding decision is based on a 172 popped label, the MPLS encapsulated IP header information including 173 IP options should be ignored with the exception of the IP TTL per 174 [RFC3443] and the Tunneled Diff-Serv information per [RFC3270]. 176 Implementation of the above policy prevents IP packets from 177 inadvertently bypassing MPLS encapsulation due to header options. The 178 policy also prevents specific option types such as Router Alert 179 (value 148), for example, from forcing MPLS imposition of the MPLS 180 Router Alert Label (value 1) at ingress LERs. Without this policy, 181 the MPLS infrastructure is exposed to security attacks using 182 legitimate IP packets crafted with header options. 184 5.0 Security Considerations 186 There are two potential categories of attacks using crafted IP option 187 packets that threaten the MPLS infrastructure. Both are described 188 below. 190 5.1. IP Option Packets that Bypass MPLS Encapsulation 192 Given that a router's exception handling process (i.e., CPU, 193 processor line-card bandwidth, etc.) used for IP header option 194 processing is often shared with IP control and management protocol 195 router resources, a flood of IP packets with header options may 196 adversely affect a router's control and management protocols, 197 thereby, triggering a denial-of- service (DoS) condition. Note, IP 198 packets with header options may be valid transit IP packets with 199 legitimate sources and destinations. Hence, a DoS-like condition may 200 be triggered on downstream transit IP routers that lack protection 201 mechanisms even in the case of legitimate IP option packets. 203 IP option packets that bypass MPLS encapsulation at a ingress LER may 204 be inadvertently IP routed downstream across the MPLS core network 205 (not label switched). This allows an external attacker the 206 opportunity to maliciously craft seemingly legitimate IP packets with 207 specific IP header options in order to intentionally bypass MPLS 208 encapsulation at the MPLS edge (i.e., ingress LER) and trigger a DoS 209 condition on downstream LSRs. Some of the specific types of IP 210 option-based security attacks that may be leveraged against MPLS 211 networks include: 212 o Crafted IP option packets that bypass MPLS encapsulation at a 213 ingress LER may allow an attacker to DoS downstream LSRs by 214 saturating their software forwarding paths. By targeting a LSR's 215 exception path, control and management protocols may be adversely 216 affected and, thereby, a LSR's availability. This assumes, of 217 course, that downstream LSRs lack protection mechanisms. 218 o Crafted IP option packets that bypass MPLS encapsulation at a 219 ingress LER may allow for IP TTL expiry-based DoS attacks against 220 downstream LSRs. MPLS enables IP core hiding whereby transit IP 221 customers see the MPLS network as a single router hop [RFC3443]. 222 However, MPLS core hiding does not apply to packets that bypass 223 MPLS encapsulation and, therefore, IP option packets may be 224 crafted to expire on downstream LSRs which may trigger a DoS 225 condition. This assumes, of course, that downstream LSRs lack 226 protection mechanisms. Bypassing MPLS core hiding is an 227 additional security consideration since it exposes the network 228 topology. 230 o Crafted IP option packets that bypass MPLS encapsulation at a 231 ingress LER may allow an attacker to bypass LSP Diff-Serv tunnels 232 [RFC3270] and any associated MPLS CoS field [MPLSCOS] marking 233 policies at ingress LERs and, thereby, adversely affect (i.e., 234 DoS) high-priority traffic classes within the MPLS core. Further, 235 this could also lead to theft of high-priority services by 236 unauthorized parties. This assumes, of course, that the 237 [RFC3270] Pipe model is deployed within the MPLS core. 238 o Crafted IP strict and loose source route option packets that 239 bypass MPLS encapsulation at a ingress LER may allow an attacker 240 to specify explicit IP forwarding path(s) across an MPLS network 241 and, thereby, target specific LSRs with any of the DoS attacks 242 outlined above. This assumes, of course, that the MPLS network 243 is enabled to process IP strict and loose source route options. 244 o Crafted RSVP packets that bypass MPLS encapsulation at a ingress 245 LER may allow an attacker to build RSVP soft-states [RFC2205] on 246 downstream LSRs which could lead to theft of service by 247 unauthorized parties or to a DoS condition caused by locking up 248 LSR resources. This assumes, of course, that the MPLS network is 249 enabled to process RSVP packets. 251 The security attacks outlined above specifically apply to IP option 252 packets that bypass ingress LER label stack imposition. Additionally, 253 these attacks apply to IP option packets forwarded using the global 254 routing table (i.e., IPv4 address family) of a ingress LER. IP 255 option packets associated with a BGP/MPLS IP VPN service are always 256 MPLS encapsulated by the LER per [RFC4364] given that packet 257 forwarding uses a Virtual Forwarding/Routing (VRF) instance. 258 Therefore, BGP/MPLS IP VPN services are not subject to the threats 259 outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use of 260 extension headers not header options and is therefore outside the 261 scope of this document. A separate security threat that does apply 262 to both BGP/MPLS IP VPNs and an IPv4 address family makes use of the 263 Router Alert Label. This is described directly below. 265 5.2. Router Alert Label Imposition 267 [RFC3032] defines a "Router Alert Label" (value of 1) which is 268 analogous to the "Router Alert" IP header option. The MPLS Router 269 Alert Label (when exposed and processed only) indicates to downstream 270 LSRs to examine these MPLS packets more closely. MPLS packets with 271 the MPLS Router Alert Label are also handled as an exception by LSRs 272 and, again, in a less efficient manner. At the time of this writing, 273 the only legitimate use of the Router Alert Label is for LSP 274 ping/trace [RFC4379]. Since there is also no formal standard for 275 Router Alert Label imposition at ingress LERs: 277 o Crafted IP packets with specific IP header options (e.g., Router 278 Alert) may allow an attacker to force MPLS imposition of the 279 Router Alert Label at ingress LERs and, thereby, trigger a DoS 280 condition on downstream LSRs. This assumes, of course, that 281 downstream LSRs lack protection mechanisms. 283 6.0 IANA Considerations 285 This document has no actions for IANA. 287 7.0 Conclusion 289 This document imposes a new requirement on ingress LERs that helps to 290 mitigate the risk of crafted security attacks using IP option packets 291 against MPLS infrastructures. The security threats were described 292 and exist as a result of no formal ingress LER specification for MPLS 293 encapsulation of IP packets with header options. Adoption of this 294 requirement will also eliminate the variability among ingress LER 295 implementations. 297 8.0 Acknowledgements 299 The authors would like to thank Pradosh Mohapatra, Carlos Pignataro, 300 Eric Rosen and Mark Szczesniak for their valuable comments and 301 suggestions. 303 9.0 Normative References 305 [RFC791] Postel, J., "Internet Protocol Specification," RFC791, 306 September 1981. 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels," March 1997. 311 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label 312 Switching Architecture," RFC3031, January 2001. 314 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 315 Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding," 316 RFC3032, January 2001. 318 10.0 Informational References 320 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 321 "Resource ReSerVation Protocol -- Version 1 Functional 322 Specification," RFC2205, September 1997. 324 [RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6 325 Specification," RFC2460, December 1998. 327 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 328 P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label 329 Switching Support of Differentiated Services," RFC3270, May 2002. 331 [RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 332 Multi-Protocol Label Switching (MPLS) Networks," RFC3443, January 333 2003. 335 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 336 Networks (VPNs)," RFC4364, February 2006. 338 [RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label 339 Switched (MPLS) Data Plane Failures," RFC4379, February 2006. 341 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 342 Virtual Private Networks (VPNs)," RFC4381, February 2006. 344 [RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP 345 Extensions for Multiprotocol Label Switching," RFC4950, August 2007. 347 [IANA] "IP Option Numbers," IANA, February 15, 2007, 348 . 350 [MPLSCOS] Andersson, L., "EXP Field Renamed to CoS Field," IETF 351 draft-ietf-mpls-cosfield-def-02.txt, June 11, 2008. 353 11.0 Authors' Addresses 355 William Jaeger 356 AT&T 357 200 S. Laurel Avenue 358 Middletown, NJ 07748 359 Email: wjaeger@att.com 360 John Mullooly 361 Cisco Systems, Inc. 362 111 Wood Avenue 363 Iselin, NJ 08837 364 E-mail: jmullool@cisco.com 366 Tom Scholl 367 AT&T 368 200 S. Laurel Avenue 369 Middletown, NJ 07748 370 Email: ts3127@att.com 372 David J. Smith 373 Cisco Systems, Inc. 374 111 Wood Avenue 375 Iselin, NJ 08837 376 E-mail: dasmith@cisco.com 378 12.0 Full Copyright Statement 380 Copyright (C) The IETF Trust (2008). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 389 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 390 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 13.0 Intellectual Property 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at ietf- 416 ipr@ietf.org.