[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-mpls-ip-options

Network Working Group                                     David J. Smith
Internet Draft                                             John Mullooly
Intended status: Proposed Standard                   Cisco Systems, Inc.
Expiration Date: April 2009
                                                          William Jaeger
                                                                    AT&T

                                                              Tom Scholl
                                                               AT&T Labs

                                                         October 6, 2008


  Requirements for Label Edge Router Forwarding of IPv4 Option Packets


                  draft-dasmith-mpls-ip-options-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document imposes a new requirement on Label Edge Routers (LER)
   specifying that when determining whether to MPLS encapsulate an IP
   packet, the determination is made independent of any IP options that
   may be carried in the IP packet header.  Lack of a formal standard
   may result in a different forwarding behavior for different IP



Smith, et al.                                                     [Page 1]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


   packets associated with the same prefix-based Forwarding Equivalence
   Class (FEC).  While an IP packet with either a specific option type
   or no header option may follow the MPLS label switched path (LSP)
   associated with a prefix-based FEC, an IP packet with a different
   option type but associated with the same prefix-based FEC may bypass
   MPLS encapsulation and instead be IP routed downstream.  IP option
   packets that fail to be MPLS encapsulated simply due to their header
   options present a security risk against the MPLS infrastructure.



Table of Contents

    1          Specification of Requirements  ......................   2
    2          Motivation  .........................................   3
    3          Introduction  .......................................   3
    4          Ingress Label Edge Router Requirement  ..............   4
    5          Security Considerations  ............................   5
    5.1        IP Option Packets that Bypass MPLS Encapsulation  ...   5
    5.2        Router Alert Label Imposition  ......................   7
    6          IANA Considerations  ................................   7
    7          Conclusion  .........................................   7
    8          Acknowledgements  ...................................   7
    9          Normative References  ...............................   8
   10          Informational References  ...........................   8
   11          Authors' Addresses  .................................   9
   12          Full Copyright Statement  ...........................  10
   13          Intellectual Property  ..............................  10






1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].












Smith, et al.                                                     [Page 2]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


2. Motivation

   This document is motivated by the need to formalize MPLS
   encapsulation processing of IPv4 packets with header options in order
   to mitigate the existing risks of IP options-based security attacks
   against MPLS infrastructures.  We believe that this document adds
   details that have not been fully addressed in [RFC3031] and
   [RFC3032], and that the methods presented in this document update
   [RFC3031] as well as complement [RFC3443] and [RFC4950].


3. Introduction

   The IP packet header provides for various IP options as originally
   specified in [RFC791].  IP header options are used to enable control
   functions within the IP data forwarding plane that are required in
   some specific situations but not necessary for most common IP
   communications.  Typical IP header options include provisions for
   timestamps, security, and special routing.  Example IP header options
   & applications include but are not limited to:
     o Strict & Loose Source Route Options: Used to IP route the IP
       packet based on information supplied by the source.
     o Record Route Option: Used to trace the route an IP packet takes.
     o Router Alert Option: Indicates to downstream IP routers to
       examine these IP packets more closely.
   The list of current IP header options can be accessed at [IANA].

   IP packets may or may not use IP header options (they are optional)
   but IP header option handling mechanisms must be implemented by all
   IP protocol stacks (hosts and routers).  Each IP header option has
   distinct header fields and lengths.  IP options extend the IP packet
   header length beyond the minimum of 20 octets.  As a result, IP
   packets received with header options are typically handled as
   exceptions and in a less efficient manner due to their variable
   length and complex processing requirements.  Many router
   implementations, for example, punt such packets from the hardware
   forwarding (fast) path into the software forwarding (slow) path.

   Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in
   which packets are encapsulated with a label stack and then switched
   along a label switched path (LSP) by a sequence of label switch
   routers (LSRs).  These intermediate LSRs do not generally perform any
   processing of the IP header as packets are forwarded. (There are some
   exceptions to this rule, such as ICMP processing, as described in
   [RFC3032].) Many MPLS deployments rely on LSRs to provide layer 3
   transparency much like ATM switches are transparent at layer 2.

   Even though MPLS encapsulation seems to offer a viable solution to



Smith, et al.                                                     [Page 3]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


   protect downstream LSRs from being adversely impacted by customer
   packets with IP header options, there is currently no formal standard
   for encapsulation of IP packets with header options in MPLS networks.
   When MPLS encapsulated, IP option packets are processed by downstream
   LSRs as native MPLS packets within their forwarding paths.  In this
   way, the IP header options are effectively ignored by downstream LSRs
   when encapsulated with a MPLS label stack.  However, for many LER
   implementations not all IP packets with header options are MPLS
   encapsulated by the ingress LER.

   Lack of a formal standard has resulted in inconsistent forwarding
   behaviors by ingress LERs.  Namely, IP packets with different types
   of IP header options are handled differently by an ingress LER
   despite being associated with the same prefix-based FEC as defined in
   Section 4.1.1 of [RFC3031].  For instance, some IP header options may
   fail to be MPLS encapsulated, and are instead IP routed downstream on
   a per-hop basis by downstream LSRs within the MPLS core.  The
   different forwarding behaviors not only vary across IP option types
   but also across ingress LER implementations given no formal standard
   for IP header option processing in MPLS networks.  This document
   imposes a new requirement on ingress LERs in order to reduce the risk
   of IP options-based security attacks against LSRs as well as to
   minimize the IP routing information carried by LSRs.


4. Ingress Label Edge Router Requirement

   An ingress LER MUST implement the following policy, and the policy
   MUST be enabled by default:

     o When determining whether to push an MPLS label stack onto an IP
       packet, the determination is made without considering any IP
       options that may be carried in the IP packet header.  Further,
       the label values that appear in the label stack are determined
       without considering any such IP options.

   When processing of signaling messages or data packets with more
   specific forwarding rules is enabled, this policy SHOULD NOT alter
   the specific processing rules. This applies to, but is not limited
   to, RSVP as per [RFC2205].  Further, how an ingress LER processes IP
   header options before MPLS encapsulation is out of scope as it is not
   relevant to MPLS.

   Implementation of the above policy prevents IP packets from failing
   to be MPLS encapsulated due to header options.  The policy also
   prevents specific option types such as Router Alert (value 148), for
   example, from forcing MPLS imposition of the MPLS Router Alert Label
   (value 1) at ingress LERs.  Without this policy, the MPLS



Smith, et al.                                                     [Page 4]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


   infrastructure is exposed to security attacks using legitimate IP
   packets crafted with header options.


5. Security Considerations

   There are two potential categories of attacks using crafted IP option
   packets that threaten existing MPLS infrastructures.  Both are
   described below. To mitigate the risk of these specific attacks, the
   ingress LER policy specified above is required.


5.1. IP Option Packets that Bypass MPLS Encapsulation

   Given that a router's exception handling process (i.e., CPU,
   processor line-card bandwidth, etc.) used for IP header option
   processing is often shared with IP control and management protocol
   router resources, a flood of IP packets with header options may
   adversely affect a router's control and management protocols,
   thereby, triggering a denial-of-service (DoS) condition.  Note, IP
   packets with header options may be valid transit IP packets with
   legitimate sources and destinations. Hence, a DoS-like condition may
   be triggered on downstream transit IP routers that lack protection
   mechanisms even in the case of legitimate IP option packets.

   IP option packets that bypass MPLS encapsulation at a ingress LER may
   be inadvertently IP routed downstream across the MPLS core network
   (not label switched).  This allows an external attacker the
   opportunity to maliciously craft seemingly legitimate IP packets with
   specific IP header options in order to intentionally bypass MPLS
   encapsulation at the MPLS edge (i.e., ingress LER) and trigger a DoS
   condition on downstream LSRs.  Some of the specific types of IP
   option-based security attacks that may be leveraged against MPLS
   networks include:
     o Crafted IP option packets that bypass MPLS encapsulation at a
       ingress LER may allow an attacker to DoS downstream LSRs by
       saturating their software forwarding paths.  By targeting a LSR's
       exception path, control and management protocols may be adversely
       affected and, thereby, a LSR's availability.  This assumes, of
       course, that downstream LSRs lack protection mechanisms.
     o Crafted IP option packets that bypass MPLS encapsulation at a
       ingress LER may allow for IP TTL expiry-based DoS attacks against
       downstream LSRs.  MPLS enables IP core hiding whereby transit IP
       customers see the MPLS network as a single router hop [RFC3443].
       However, MPLS core hiding does not apply to packets that bypass
       MPLS encapsulation and, therefore, IP option packets may be
       crafted to expire on downstream LSRs which may trigger a DoS
       condition.  Bypassing MPLS core hiding is an additional security



Smith, et al.                                                     [Page 5]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


       consideration since it exposes the network topology.
     o Crafted IP option packets that bypass MPLS encapsulation at a
       ingress LER may allow for DoS attacks against downstream LSRs
       that do not carry the IP routing information required to forward
       transit IP traffic. Lack of such IP routing information may
       prevent legitimate IP option packets from transiting the MPLS
       network and, further, may trigger generation of ICMP destination
       unreachable messages which could lead to a DoS condition.  This
       assumes, of course, that downstream LSRs lack protection
       mechanisms and do not carry the IP routing information required
       to forward transit traffic.
     o Crafted IP option packets that bypass MPLS encapsulation at a
       ingress LER may allow an attacker to bypass LSP Diff-Serv tunnels
       [RFC3270] and any associated MPLS CoS field [MPLSCOS] marking
       policies at ingress LERs and, thereby, adversely affect (i.e.,
       DoS) high-priority traffic classes within the MPLS core.
       Further, this could also lead to theft of high-priority services
       by unauthorized parties.  This assumes, of course, that the
       [RFC3270] Pipe model is deployed within the MPLS core.
     o Crafted IP strict and loose source route option packets that
       bypass MPLS encapsulation at a ingress LER may allow an attacker
       to specify explicit IP forwarding path(s) across an MPLS network
       and, thereby, target specific LSRs with any of the DoS attacks
       outlined above.  This assumes, of course, that the MPLS network
       is enabled to process IP strict and loose source route options.
     o Crafted RSVP packets that bypass MPLS encapsulation at a ingress
       LER may allow an attacker to build RSVP soft-states [RFC2205] on
       downstream LSRs which could lead to theft of service by
       unauthorized parties or to a DoS condition caused by locking up
       LSR resources.  This assumes, of course, that the MPLS network is
       enabled to process RSVP packets.

   The security attacks outlined above specifically apply to IP option
   packets that bypass ingress LER label stack imposition.
   Additionally, these attacks apply to IP option packets forwarded
   using the global routing table (i.e., IPv4 address family) of a
   ingress LER.  IP option packets associated with a BGP/MPLS IP VPN
   service are always MPLS encapsulated by the LER per [RFC4364] given
   that packet forwarding uses a Virtual Forwarding/Routing (VRF)
   instance.  Therefore, BGP/MPLS IP VPN services are not subject to the
   threats outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use
   of extension headers not header options and is therefore outside the
   scope of this document.  A separate security threat that does apply
   to both BGP/MPLS IP VPNs and an IPv4 address family makes use of the
   Router Alert Label.  This is described directly below.






Smith, et al.                                                     [Page 6]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


5.2. Router Alert Label Imposition

   [RFC3032] defines a "Router Alert Label" (value of 1) which is
   analogous to the "Router Alert" IP header option.  The MPLS Router
   Alert Label (when exposed and processed only) indicates to downstream
   LSRs to examine these MPLS packets more closely.  MPLS packets with
   the MPLS Router Alert Label are also handled as an exception by LSRs
   and, again, in a less efficient manner.  At the time of this writing,
   the only legitimate use of the Router Alert Label is for LSP
   ping/trace [RFC4379].  Since there is also no formal standard for
   Router Alert Label imposition at ingress LERs:
     o Crafted IP packets with specific IP header options (e.g., Router
       Alert) may allow an attacker to force MPLS imposition of the
       Router Alert Label at ingress LERs and, thereby, trigger a DoS
       condition on downstream LSRs.  This assumes, of course, that
       downstream LSRs lack protection mechanisms.


6. IANA Considerations

   This document has no actions for IANA.


7. Conclusion

   This document imposes a new requirement on ingress LERs that helps to
   mitigate the risk of crafted security attacks using IP option packets
   against MPLS infrastructures.  The security threats were described
   and exist as a result of no formal ingress LER specification for MPLS
   encapsulation of IP packets with header options.  Adoption of this
   requirement will also eliminate the variability among ingress LER
   implementations.


8. Acknowledgements

   The authors would like to thank Adrian Cepleanu, Bruce Davie, Rick
   Huber, Pradosh Mohapatra, Ashok Narayanan, Carlos Pignataro, Eric
   Rosen, Mark Szczesniak and Yung Yu for their valuable comments and
   suggestions.











Smith, et al.                                                     [Page 7]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


9. Normative References

   [RFC791] Postel, J., "Internet Protocol Specification," RFC791,
   September 1981.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels," March 1997.

   [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label
   Switching Architecture," RFC3031, January 2001.

   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
   Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding,"
   RFC3032, January 2001.


10. Informational References

   [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
   "Resource ReSerVation Protocol -- Version 1 Functional
   Specification," RFC2205, September 1997.

   [RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6
   Specification," RFC2460, December 1998.

   [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
   P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label
   Switching Support of Differentiated Services," RFC3270, May 2002.

   [RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
   Multi-Protocol Label Switching (MPLS) Networks," RFC3443, January
   2003.

   [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
   Networks (VPNs)," RFC4364, February 2006.

   [RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label
   Switched (MPLS) Data Plane Failures," RFC4379, February 2006.

   [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
   Virtual Private Networks (VPNs)," RFC4381, February 2006.

   [RFC3209] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, G.
   Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209,
   December 2001.

   [RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP
   Extensions for Multiprotocol Label Switching," RFC4950, August 2007.



Smith, et al.                                                     [Page 8]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


   [IANA] "IP Option Numbers," IANA, February 15, 2007,
   <www.iana.org/assignments/ip-parameters>.

   [MPLSCOS] Andersson, L., "EXP Field Renamed to CoS Field," IETF
   draft-ietf-mpls-cosfield-def-02.txt, June 11, 2008.


11. Authors' Addresses


      William Jaeger
      AT&T
      200 S. Laurel Avenue
      Middletown, NJ  07748
      Email: wjaeger@att.com



      John Mullooly
      Cisco Systems, Inc.
      111 Wood Avenue
      Iselin, NJ  08830
      E-mail: jmullool@cisco.com



      Tom Scholl
      AT&T Labs
      200 S. Laurel Avenue
      Middletown, NJ  07748
      Email: ts3127@att.com



      David J. Smith
      Cisco Systems, Inc.
      111 Wood Avenue
      Iselin, NJ  08830
      E-mail: djsmith@cisco.com












Smith, et al.                                                     [Page 9]

Internet Draft    draft-dasmith-mpls-ip-options-01.txt      October 2008


12. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


13. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.











Smith, et al.                                                    [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/