Elwin Stelzer Internet Draft Naveen Gowda Corona Networks, Inc. July 2001 Expires: January 2002 IP Services over L2TP Sessions 1.0 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 2.0 Abstract This draft describes an extension to L2TP, by adding additional AVPs. This enables LAC to apply user-based services over L2TP sessions, such as IPSec and QOS. The two AVPs are used to carry information between LNS and LAC over the SURQ and SURP messages [ref-6]. 3.0 Table of Contents 1.0 Status of this Memo ................................. 1 2.0 Abstract ............................................ 1 Elwin & Naveen [Page 1] draft-elwin-l2tpext-ipservices-00 IP Services Over L2TP July 2001 3.0 Table of Contents ................................... 1 4.0 Introduction ........................................ 2 5.0 IP Services AVPs .................................... 2 5.1 IPSec AVP ........................................... 2 5.2 QOS AVP ............................................. 3 6.0 Summary and Conclusions ............................. 4 7.0 IANA Considerations ................................. 4 8.0 Security Considerations ............................. 5 9.0 References .......................................... 5 10.0 Authors' Addresses .................................. 5 4.0 Introduction LNS terminates the PPP session, which is tunneled through LAC. It also authenticates the incoming user and knows about the services that are assigned to the incoming user. In few cases it is required to inform this service information to the LAC like QOS, IPSec etc. This draft provides a mechanism for LNS to inform LAC about the services, for a user. Currently, even though the services can be applied on per site basis (Ex. apply IPSec for all the session on a tunnel and apply a pre configured DSCP on all the packets on a tunnel), it is also required to provide such services based on the incoming user. User specific services are known only through authentication and as LNS terminates the PPP incoming user, LNS can send the user speicific service attributes to LAC through post session establishment messages like SURQ [ref-6]. Upon receiving SURQ LAC will parse all the user specific service attribute AVPs (explained below) and send the supported Service attributes AVPs back in SURP there by informing LNS about the supported services. 5.0 IP Services AVPs 5.1 IPSec AVP The IPSec AVP is used to inform the tunneling peer to use the appropriate IPSec parameters for securing the L2TP session. The information carried across can be reflected in the SPD, or any other mechanism could be used to apply this. When the LNS finds out that incoming user needs IPSec service then it can send this AVP to LAC indicating LAC to send the L2TP packets encrypted using IPSec. If the LAC supports to provide IPSec for the requested LNS then it MUST send the same AVP back in SURP indicating that the IPSec AVP is valid and LAC will send all L2TP packets through IPSec. If the LAC doesn't allow this, then in SURP this AVP MUST not Elwin & Naveen [Page 2] draft-elwin-l2tpext-ipservices-00 IP Services Over L2TP July 2001 be included. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPSec Service Info ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be present in the following message types: SURQ and SURP This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional (M-bit not set). The length (before hiding) of this AVP is 8 + Length of IPSec-Service-Info octets. Vendor ID is a two octet value, set to 3961 to indicate that this is an Corona-assigned attribute. Should this draft become a standard, the Vendor ID would become 0 and an appropriate Attribute-Type value will be assigned by IANA. Service Info can be anything that is understood by both L2TP peers. It can be service profile name or index to the policy database from which the IPSec profile is available. Exact usage of Service Info is out of scope of this document. 5.2 QOS AVP The QOS AVP is used to inform the tunneling peer to use the appropriate QOS marking to use for the L2TP session. This AVP can be used to determine how to mark the packets, from the following options: a. To reflect the marking from the payload IP packet to the outer IP header, OR b. To apply a specific PHB based marking for all packets from the user (based on PHB ID sent in this AVP), OR c. To mark based on policy lookup If the LAC can support what is requested by LNS then it MUST send the same AVP back in SURP indicating that the QOS AVP is valid and LAC will mark accordingly. If the LAC doesn't allow this, then in SURP this AVP MUST not be included. Elwin & Naveen [Page 3] draft-elwin-l2tpext-ipservices-00 IP Services Over L2TP July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type = 6 | reserved | FLG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHB ID | QOS Service Info ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be present in the following message types: SURQ and SURP This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional (M-bit not set). The length (before hiding) of this AVP is 10 + Length of QOS-Service-Info octets. Vendor ID is a two octet value, set to 3961 to indicate that this is an Corona-assigned attribute. Should this draft become a standard, the Vendor ID would become 0 and an appropriate Attribute-Type value will be assigned by IANA. The PHBID is encoded as described in [ref-7]. FLG indicates which type of marking is to be applied at LAC. Following are the valid values for this: 000 - reflect DSCP from the inner IP packet 001 - use the PHBID passed, to determine DSCP to mark the packets. For all other values of FLG, the PHBID is ignored. 010 - do a policy lookup to determine the DSCP marking. 011 - reserved 1xx - reserved 6.0 Summary and Conclusions It is possible to provide user specific services from LAC and LNS. Extensions for L2TP to achieve this are specified in this document. 7.0 IANA Considerations Should this document advance on as standards track official attribute values need to be assigned for the IPSec AVP, and QOS AVP. Elwin & Naveen [Page 4] draft-elwin-l2tpext-ipservices-00 IP Services Over L2TP July 2001 8.0 Security Considerations This document does not introduce any new security issues beyond those inherent in L2TP, and may use the same mechanisms proposed for those technologies, where applicable. 9.0 References [ref-1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14 and RFC 2119, March 1997. [ref-2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. [ref-3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [ref-4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [ref-5] D. Black, "Differentiated Services and Tunnels", RFC 2983, October 2000. [ref-6] Naveen Gowda, Elwin Stelzer, Umesh Sirsiwal, "L2TP Session Update Mechanism", draft-naveen-l2tpext-sessupdate-00.txt, Work in progress, June 2001 [ref-7] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behaviour Identification Codes", RFC 2836, May 2000 10.0 Authors' Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: elwinietf@yahoo.com Naveen PN Gowda Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: naveenietf@yahoo.com Elwin & Naveen [Page 5]