Network Working Group                                   W. Mark Townsley
Internet-Draft                                             cisco Systems
<draft-ietf-mpls-over-l2tpv3-00.txt>                           Ted Seely
February 2005                                                     Sprint
                                                        Jeffery S. Young
                                                                 Alcatel

    Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 .

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

Abstract

   The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
   protocol for tunneling a variety of payload types over IP networks.
   This document defines how to carry an MPLS label or label stack and
   its payload over L2TPv3. This enables an application which
   traditionally requires an MPLS-enabled core network to utilize an
   L2TPv3 encapsulation over an IP network instead.






Townsley                    Standards Track                     [Page 1]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


   Contents

   Status of this Memo..........................................    1

   1. Introduction..............................................    2

   2. MPLS over L2TPv3 Encoding.................................    2

   3. Assigning the L2TPv3 Session ID and Cookie................    4

   4. Applicability.............................................    4

   5. Security Considerations...................................    5

   6. IANA Considerations.......................................    6

   7. Acknowledgments...........................................    6

   8. References................................................    6
      8.1 Normative References..................................    6
      8.2 Informative References................................    6

   9. Contacts..................................................    6

Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].


1. Introduction

   This document defines how to encapsulate an MPLS label or label stack
   and its payload over L2TPv3. After defining the MPLS over L2TPv3
   encapsulation procedure, other MPLS over IP encapsulation options
   including IP, GRE and IPsec are discussed in context with MPLS over
   L2TPv3 in an Applicability section. This document only describes
   encapsulation and does not concern itself with all possible MPLS-
   based applications which may be enabled over L2TPv3.

2. MPLS over L2TPv3 Encoding

   MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] over an
   IP network utilizing the L2TPv3 encapsulation defined in [RFC3931].
   The MPLS Label Stack and payload is carried in its entirety after IP



Townsley                    Standards Track                     [Page 2]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


   and L2TPv3.

         +-+-+-+-+-+-+-+-+-+-+
         |        IP         |
         +-+-+-+-+-+-+-+-+-+-+
         |      L2TPv3       |
         +-+-+-+-+-+-+-+-+-+-+
         | MPLS Label Stack  |
         +-+-+-+-+-+-+-+-+-+-+

   Figure 2.1 MPLS Stack over L2TPv3/IP

   The L2TPv3 encapsulation carrying a single MPLS label is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Session ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Cookie (optional, maximum 64 bits)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
   |                Label                  | Exp |S|       TTL     | Stack
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

             Figure 2.2 MPLS label over L2TPv3 encapsulation

   When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific-Sublayer
   MUST NOT be present. The L2TPv3 Session ID MUST be present. The
   Cookie MAY be present.

   Session ID

      The L2TPv3 Session ID is a 32-bit identifier field locally
      selected as a lookup key for the context of an L2TP Session.  An
      L2TP Session contains necessary context for processing a received
      L2TP packet. At a minimum, such context contains whether the
      Cookie (see description below) is present, the value it was
      assigned, as well as what type of tunneled encapsulation follows
      (i.e., Frame Relay, Ethernet, MPLS, etc).

   Cookie

      The L2TPv3 Cookie field contains a variable length (maximum 64
      bits) randomly assigned value.  It is intended to provide an
      additional level of guarantee that a data packet has been directed
      to the proper L2TP session by the Session ID.  While the Session



Townsley                    Standards Track                     [Page 3]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


      ID may be encoded and assigned any value (perhaps optimizing for
      local lookup capabilities, redirection in a distributed forwarding
      architecture, etc.), the Cookie MUST be selected as a
      cryptographically random value [RFC1750], with the added
      restriction that it not be the same as a recently used value for a
      given Session ID.  A well-chosen Cookie will prevent inadvertent
      misdirection of a stray packet containing a recently reused
      Session ID, a Session ID that is subject to packet corruption, and
      protection against some specific malicious packet insertion
      attacks as described in more detail in Section 4 of this document.

   Label Stack Entry

      An MPLS label as defined in [RFC3032].

   The optional L2-Specific-Sublayer defined in [RFC3931] is generally
   not present for MPLS over L2TPv3.

   Generic IP encapsulation procedures such as MTU considerations,
   handling of TTL, EXP and DSCP bits, etc. are the same as the "Common
   Procedures" for IP encapsulation of MPLS defined in Section 5 of
   [MPLS-IP-GRE] and are not reiterated here.

3. Assigning the L2TPv3 Session ID and Cookie

   Much like an MPLS label, the L2TPv3 Session ID and Cookie must be
   selected and exchanged between participating nodes before L2TPv3 can
   operate. These values may be configured manually, or distributed via
   a signaling protocol. This document concerns itself only with the
   encapsulation of MPLS over L2TPv3, thus the particular method of
   assigning the Session ID and Cookie is out of scope.

4. Applicability

   The methods defined [MPLS-IP-GRE], [MPLS-IPSEC] and this document all
   describe methods for carrying MPLS over an IP network. Cases where
   MPLS over L2TPv3 may be applicable compared to other alternatives are
   discussed in this section.

   It is generally simpler to have one's border routers refuse to accept
   an MPLS packet than to configure a router to refuse to accept certain
   MPLS packets carried in IP or GRE to or from certain IP sources or
   destinations. Thus, the use of IP or GRE to carry MPLS labels
   increases the opportunity for MPLS label spoofing attacks. L2TPv3
   provides an additional level of protection against packet spoofing
   before allowing a packet to enter a VPN (much like IPsec provides an
   additional level of protection at a PE rather than relying on ACL
   filters). Checking the value of the L2TPv3 Cookie is similar to any



Townsley                    Standards Track                     [Page 4]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


   sort of ACL which inspects the contents of a packet header, except
   that we give ourselves the luxury of "seeding" the L2TPv3 header with
   a very difficult to spoof value.

   MPLS over L2TPv3 may be favorable compared to [MPLS-IP-GRE], if:

      Two routers are "adjacent" over an L2TPv3 tunnel that exists for
      some reason outside the scope of this document, and those two
      routers need to send MPLS packets over that adjacency.

      Implementation considerations dictate the use of MPLS over L2TPv3.
      For example, a hardware device may be able to take advantage of
      the L2TPv3 encapsulation for faster processing.

      Packet spoofing and insertion is of concern. The L2TPv3 Cookie
      allows simple validation, over and above that of IP ACLs, of the
      source of an L2TPv3 packet before allowing processing to continue.

   (The first two of the above applicability statements were adopted
   from [MPLS-IP-GRE])

   In summary, L2TPv3 can provide a balance between the limited security
   against IP spoofing attacks offered by [MPLS-IP-GRE] vs. the greater
   security and associated operational and processing overhead offered
   by [MPLS-IPSEC].  Further, MPLS over L2TPv3 may be faster in some
   hardware, particularly if it is already optimized to classify
   incoming L2TPv3 packets carrying IP framed in a variety of ways. For
   example, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be
   considered not that far removed from IP encapsulated by MPLS over
   L2TPv3.

5. Security Considerations

   The L2TPv3 Cookie does not provide protection via encryption.
   However, when used with a sufficiently random 64-bit value which is
   kept secret from a hacker, the L2TPv3 Cookie may be used as a simple
   yet effective packet source authentication check which is quite
   resistent to brute force packet spoofing attacks. It also alleviates
   the need to rely solely on filter lists based on a list of valid
   source IP addresses, and thwarts attacks which could benefit by
   spoofing a permitted source IP address.

   L2TPv3 tunnels may also be secured using IPsec.  When using IPsec,
   the tunnel head and the tunnel tail should be treated as the
   endpoints of a Security Association.  The MPLS over L2TPv3
   encapsulated packets should be considered as originating at the
   tunnel head and as being destined for the tunnel tail; IPsec
   transport mode should thus be used. Key distribution may be done



Townsley                    Standards Track                     [Page 5]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


   either manually or automatically.

   Security is also discussed as part of the applicability discussion in
   section 4 of this document.

6. IANA Considerations

   There are no IANA considerations for this document.

7. Acknowledgments

   Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their
   review of this document. Some text was adopted from [MPLS-IP-GRE].

8. References

8.1 Normative References

   [RFC3931]     J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
                 Protocol (Version 3)", work in progress,
                 draft-ietf-l2tpext-l2tp-base-15.txt, December 2004.

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

   [MPLS-IP-GRE] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating
                 MPLS in IP or Generic Routing Encapsulation (GRE)",
                 work in progress, draft-ietf-mpls-in-ip-or-gre-08.txt,
                 June 2004.

8.2 Informative References

   [RFC2547]     E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.

   [RFC3032]     R. Rosen, et. al., "MPLS Label Stack Encoding," RFC 3032,
                 January 2001.

   [MPLS-IPSEC]  E. Rosen, J. De Clercq, O/ Paridaens, Y. T'Joens,
                 C. Sargor, "Use of PE-PE IPsec in RFC2547 VPNs",
                 work in progress, draft-ietf-l3vpn-ipsec-2547-01.txt,
                 August 2003.

9. Contacts

   W. Mark Townsley
   cisco Systems
   mark@townsley.net




Townsley                    Standards Track                     [Page 6]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


   Ted Seely
   Sprint
   tseely@sprint.net

   Jeffrey S. Young
   Alcatel
   Jeffrey.S.Young@alcatel.com



   Intellectual Property Statement

      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.

   Disclaimer of Validity

      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 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.

   Copyright Statement

      Copyright (C) The Internet Society (2004). This document is subject
      to the rights, licenses and restrictions contained in BCP 78, and



Townsley                    Standards Track                     [Page 7]


INTERNET DRAFT              MPLS over L2TPv3               February 2005


      except as set forth therein, the authors retain all their rights.

   Acknowledgment

      Funding for the RFC Editor function is currently provided by the
      Internet Society.













































Townsley                    Standards Track                     [Page 8]