Elwin Stelzer Internet Draft Naveen Gowda Corona Networks, Inc. November 2001 Expires: June 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 To support user based IP services over L2TP, existing standards does not provide direct solutions. This document extends L2TP to address the shortcomings in L2TP related to this. The document also merges the extensions mentioned in two other earlier drafts [L2TP-SU] and [L2TP-SB]. 3.0 Table of Contents 1.0 Status of this Memo ................................. 1 2.0 Abstract ............................................ 1 Elwin & Naveen [Page 1] draft-elwin-l2tpext-ipservices-01 Nov 2001 3.0 Table of Contents ................................... 1 4.0 Introduction ........................................ 2 5.0 Extensions for Session Update ....................... 3 5.1 Session-Update-Notification (SUN) Message ........... 3 6.0 IP Services AVPs .................................... 3 6.1 IPSec AVP ........................................... 4 6.2 QOS AVP ............................................. 5 7.0 Session Bundling for Diffserv ....................... 6 7.1 Control Connection Operation ........................ 7 7.1.1 Bundling Capability AVP ............................. 7 7.2 Session Operation ................................... 8 7.2.1 Base Session AVP .................................... 8 8.0 IANA Considerations ................................. 8 9.0 Security Considerations ............................. 9 10.0 References .......................................... 9 11.0 Authors' Addresses .................................. 10 4.0 Introduction Once a L2TP session is established, the current standard [L2TP-V2] and [L2TP-V3] has no explicit mechanism to update the session characteristics, during the life of the session, between the L2TP tunnel endpoints. One such requirement for this mechanism is, LNS informing LAC about the PPP-user's service characteristics, so that user-specific service actions can be applied at LAC. Eg: DSCP marking. There is a need for additional messages that will address similar requirements. An additional message, SUN, is defined in this extension for this. This document also describes extensions to L2TP that enables LAC to apply user-based services over L2TP sessions, such as IPSec and QOS. The two AVPs, IPSec AVP and QOS AVP, are used to carry information between LNS and LAC using SUN message. There is an optional extension in this document, that is applicable for cases where payload-sequencing is enabled. A single L2TP session is likely to carry different type of IP packets. Currently, one L2TP session carries only one payload session; for PPP session (payload) the LCP controls the corresponding L2TP session. Assigning one diffserv code point to a L2TP session, as mentioned in [L2TP-DS] can not provide differentiated services for the different kind of IP packets that are tunneled. For example, VoIP and FTP packets, will have to be treated the same in the backbone, even though the intermediate nodes are diffserv capable. The direct solution to reflect the tunneled IP packet's DSCP marking to the constructed outer IP header's DSCP, will have adverse effects when the L2TP session has sequencing enabled. Also reflecting may not be a proper solution for all situations, since the backbone may be in a different diffserv domain. Elwin & Naveen [Page 2] draft-elwin-l2tpext-ipservices-01 Nov 2001 A solution to this is given by defining two more AVPs: Bundling Capability AVP and Base Session AVP. This solution may also be used for non-PPP L2TP payload, which is likely to have similar issues, like carrying Ethernet over L2TP. 5.0 Extensions for Session Update Following additional message is defined to exchange session characteristics: Session-Update-Notification (SUN) message The SUN is sent either from LAC to LNS or LNS to LAC. On receiving this the recipient, if needed to respond, responds by sending another SUN message. There is no change needed in the L2TP state machine to accomodate this message. The message can be used for user-specific service information to be exchanged between LAC and LNS, even after the session is established. 5.1 Session-Update-Notification (SUN) Message The Session-Update-Notification is sent by the LNS/LAC to update its peer regarding session parameters. SUN message must be sent only after session establishment is successful. In case of LNS this message can be sent after receving ICCN or sending OCCN, and the session reaching the established state. In case of LAC this message can be sent after sending ICCN or receiving OCCN, and the session reaching the established state. Recipient MUST be able to update its session information, if required, based on the SUN message. The attribute value for Message Type AVP for SUN message is TBD. The Mandatory bit for this AVP MUST be Zero, so that the session can continue even when the peer can not recognize this message. Other existing or new AVPs can be added to the list of optional AVPs in this message as and when required. The following AVPs MUST be present in the SUN: Message Type 6.0 IP Services Extensions LNS terminates the PPP session, which is tunneled through LAC. It also authenticates the incoming user and knows about the services that are Elwin & Naveen [Page 3] draft-elwin-l2tpext-ipservices-01 Nov 2001 assigned to the incoming user. In few cases it is required to inform this service information to the LAC like QOS, IPSec etc. This extension 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 SUN. Upon receiving SUN, LAC will parse all the user specific service attribute AVPs (explained below) and send the supported Service attributes AVPs back in another SUN (response) there by informing LNS about the supported services. 6.1 IPSec AVP The IPSec AVP is used to inform the tunneling peer to use the appropriate IPSec parameters for securing the L2TP session. 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 response SUN 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 SUN reply this AVP MUST not be included. Only after receiving SUN from LAC with IPSec AVP inside it, LNS can assume that LAC can support this capability. 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 Profile Name ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be present SUN message. 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-Profile-Name 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. Elwin & Naveen [Page 4] draft-elwin-l2tpext-ipservices-01 Nov 2001 6.2 QOS AVP The QOS AVP is used to inform the tunneling peer to use the appropriate QOS marking and profile 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 response SUN indicating that the QOS AVP is valid and LAC will mark accordingly. If the LAC doesn't allow this, then in response SUN this AVP MUST not be included. Only after receiving SUN from LAC with QOS AVP inside it, LNS can assume that LAC can support this capability. 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 Profile Name ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be present in the SUN message. 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-Profile-Name in 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 Elwin & Naveen [Page 5] draft-elwin-l2tpext-ipservices-01 Nov 2001 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, with the profile mentioned, to determine the DSCP marking. 011 - reserved 1xx - reserved 7.0 Session Bundling This section addresses the problem arising due to packet reordering, due to QOS or any other factors, when payload sequencing is enabled. There is a need for multiple L2TP sessions for a single PPP session that carries multiple application sessions, and hence different class of IP traffic. The need for this can also be seen in [DIFF-TN]. The solution allows distribution of a single payload (PPP) session over multiple L2TP sessions. The group of L2TP sessions that transport one payload (PPP) session is termed as 'L2TP session bundle'. One of the sessions in this session bundle is called the 'base session', and all other sessions are 'flow sessions'. A session bundle will have one base session and 0 or more flow sessions. The base session is the first session that is created in a session bundle. For the PPP case, the PPP control packets, are sent over the base session. When there is no other flow session present, the base session will transport all the payload traffic. However this can not provide differentiated services for the different type of payload packets. When packets are to be differentially treated across LAC and LNS nodes, the flow sessions are created. The trigger for creating these additional flow sessions could be based on different criteria, like packet classification, or based on DSCP value in the payload packet, or any other configuration. The exact means to do this is outside the scope of this document. The flow sessions are dependent on base sessions and can not exist by themselves. The LAC and LNS need to know which is the base session for each flow session. Thus when the base session is teared down, the dependent flow sessions can also to be teared down, because the dependent L2TP sessions are not LCP controlled. However if a flow session needs to be explicitly teared down, that can be done with the regular L2TP mechanism, using CDN. There are no special fields required in the L2TP header to accommodate this session bundling, like the L2TP tunnel ID or the L2TP session ID. Elwin & Naveen [Page 6] draft-elwin-l2tpext-ipservices-01 Nov 2001 When there are multiple L2TP sessions in a L2TP session bundle, the base session is expected to carry the high priority traffic (EF), as it is the session that carries payload (PPP) control packets. The solution mentioned here makes simple extensions to L2TP by adding two more AVPs, the 'Bundling Capability AVP' and the 'Base Session AVP'. Older implementation that do not support these two AVPs will not permit for these additional flow sessions, and hence implementations supporting this can coexist with older implementations, and be interoperable. The L2TP session sequencing need not be disabled with this approach, since different traffic flows are sent over different L2TP sessions. Each base session and flow session will maintain its own sequence numbers. The SDS AVP mentioned in [L2TP-DS] MAY be used for both the base and flow sessions in the bundle to associate a DSCP value to the session. However other means could as well be used to achieve this. 7.1 Control Connection Operation During the L2TP tunnel creation, an L2TP tunnel terminator needs to know whether the remote peer has the capability to support this diffserv extension or not. This is achieved by sending the 'Bundling Capability AVP'. 7.1.1 Bundling Capability AVP The AVP is valid in the L2TP SCCRQ and SCCRP messages only, and it MUST NOT be marked Mandatory. The Bundling Capability AVP is encoded with vendor ID, and the attribute value as 1. Each BC AVP is encoded as follows: 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 = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 MUST be 8 octets. Vendor ID is a two octet value, set to 0 to indicate that this is an IETF-assigned attribute. Tunnel initiator sends this AVP in SCCRQ and the tunnel terminator MUST respond with same AVP in SCCRP, if it supports session bundling and MUST NOT include this AVP in SCCRP if it doesn't support this. Elwin & Naveen [Page 7] draft-elwin-l2tpext-ipservices-01 Nov 2001 7.2 Session Operation During flow session creation, the session initiator also sends the 'base-session AVP'. Note that the base session creation MUST NOT have this AVP present. 7.2.1 Base Session AVP This AVP is sent by the session initiator in ICRQ/OCRQ packet. This AVP informs the peer that the current session may not run payload control protocol (LCP) over this session. Instead it will directly send the payload (PPP) data packets. If the peer is willing to accept this behavior then it SHOULD respond by sending the same AVP in the ICRP/OCRP. If the session terminator is not willing or doesn't have resource to support this, then it should not include this AVP in the ICRP/OCRP. When the session-initiator receives the ICRP/OCRP with this AVP included in the response, then it can send the payload (PPP) data packet even on this session, even though payload control packets (LCP) aren't negotiated on this session. If the ICRP/OCRP doesn't have this AVP then the session initiator MUST send CDN for this new session and MUST send all the data on the base session itself without trying to bring up more sessions to distribute the (PPP) data packets. 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 = 2 | Peer Base-Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be present in the following message types: ICRQ/OCRQ and ICRP/OCRP. 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 MUST be 8 octets. Vendor ID is a two octet value, set to 0 to indicate that this is an IETF-assigned attribute. Session initiator sends this AVP in ICRQ/OCRQ and the session terminator will either respond with same AVP in ICRP/OCRP, if it supports this extension or does not include this AVP if it doesn't support this extension. Peer Base-Session ID is 16-bit number and it MUST contain the peer's 16-bit session id value of its base session. 8.0 IANA Considerations Should this document advance on as standards track official attribute values need to be assigned for IPSec AVP, QOS AVP, Bundling Capability AVP and Base-Session AVP. Elwin & Naveen [Page 8] draft-elwin-l2tpext-ipservices-01 Nov 2001 Also attribute value for SUN message in Message Type AVP needs to be assigned. 9.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. 10.0 References [L2TP-V2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. [L2TP-V3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Singh Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol(L2TP)", Work in progress, July 2001 [L2TP-SU] Naveen Gowda, Elwin Stelzer, Umesh Sirsiwal, "L2TP Session Update Mechanism", draft-naveen-l2tpext-sessupdate-00.txt, Work in progress, June 2001 [L2TP-SB] Naveen Gowda, Elwin Stelzer, "Differentiated Services on L2TP Sessions", draft-elwin-l2tpext-diffserv-00.txt, Work in progress, April 2001 [DIFF-AR] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [DIFF-TN] D. Black, "Differentiated Services and Tunnels", RFC 2983, October 2000. [DIFF-PH] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behaviour Identification Codes", RFC 2836, May 2000 [PPP-STD] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. Elwin & Naveen [Page 9] draft-elwin-l2tpext-ipservices-01 Nov 2001 11.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 10]