Network Working Group Nishit Vasavada INTERNET DRAFT Amber Networks, Inc. July 2001 Encapsulation Services Protocol Service Type for L2TP 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] packets. In accordance with the L2TP Service Type specification [L2TPST], this document provides a solution for transporting Encapsulation Services Protocol (ESP) [ESP] over L2TP. It uses [L2TPDS] for providing DS support to the L2TP control and ESP packets. 3. 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 RFC 2119 [RFC2119]. 4. Introduction The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] packets. The L2TP Service Type [L2TPST] allows layer 1 and layer 2 traffic to be tunneled through an L2TP tunnel. This document presents a solution to carry the ESP traffic over the IP network through the features offered by L2TP and the Service Type attribute. Vasavada [Page 1] INTERNET DRAFT July 2001 It talks about the use of [RFC2661] and [L2TPST] for setting up an L2TP tunnel and session containing ESP traffic, and use of [L2TPDS] for signaling DS values for the L2TP control and payload traffic. It also introduces a new AVP - End-Identifier - to convey the end identifiers to the peer. 5. ESP Service Type An ESP Service Type value of [TBD] MUST be used. The encoding of the Service Type AVP remains as specified in [L2TPST]. 6. Tunnel Establishment The basic tunnel establishment procedures defined in [RFC2661] and [L2TPST] are followed. Following are additional requirements: 6.1. Service Capabilities For supporting ESP in a tunnel, the ESP Service Type value [TBD] MUST be included in the Service Capabilities List AVP. [L2TPST] allows multiple services to be carried in different sessions inside a single L2TP tunnel. However, ESP requires that if a tunnel were to carry ESP traffic, all sessions within the tunnel be carrying ESP sessions. To accommodate this requirement, if ESP is present in the Service Capabilities AVP, the sender MUST NOT put any other service type in the Service Capabilities AVP. If a service other than ESP is also present in the Service Capabilities AVP carrying ESP service type, and if the receiving L2TP peer supports ESP, it MUST tear down the tunnel. Since ESP is the exclusive service on ESP such a tunnel (i.e., PPP is not supported on this tunnel), the M-bit of Service Capabilities AVP MUST be set. 6.2 Control Connection DS (CCDS) AVP If a DS value is made available to L2TP for the tunnel, L2TP MUST use this AVP. 7. Session Establishment The basic call establishment procedures defined in [RFC2661] and [L2TPST] remain unchanged. 7.1. Service Type AVP The ESP Service Type value [TBD] MUST be used in the Service Type AVP of an ICRQ or OCRQ of each session within the tunnel. 7.2. Session DS (SDS) AVP If a DS value is made available to L2TP for the tunnel, L2TP MUST use this AVP and use the same value as that for the CCDS AVP while setting up the tunnel. Vasavada [Page 2] INTERNET DRAFT July 2001 7.3. End-Identifier AVP (ICRQ, OCRQ) ES needs to convey the end-identifiers on both sides to the remote side while setting up a session. We introduce a new AVP - End-Identifier AVP - for this purpose. The End-Identifier AVP is encoded 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|H| rsvd | Length | 4741 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Attribute Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [until Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor ID = 4741 for Amber Networks Attribute = 1 The attribute value contains interface and other optional information depending on the access link type that ESP is encapsulating. For example, if the ESP is carrying FR payload, the additional information would DLCI numbers on both ends. No additional information is present for TDM circuits. The attribute value may be a simple ASCII string. For example, a source interface serial 1/1 and DLCI 100, and a destination interface serial 1/1 with DLCI 200 could be represented as "serial 1/1 DLCI 100, serial 1/1 DLCI 200". The format of the information contained in this AVP should be agreed on by the administrators at the two L2TP peers. When employing the End-Identifier AVP for this purpose, the AVP is mandatory (the M-bit MUST be set to 1). The AVP MAY be hidden (the H-bit set to 0 or 1). 7.2. ESP Payload Message Format The L2TP payload header format defined in [RFC2661] remains unchanged while carrying data for an ESP session. Entire ESP PDU will be carried. Vasavada [Page 3] INTERNET DRAFT July 2001 The encapsulated ESP PDU looks like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ES Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ES control message/Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As is true for the PPP traffic carried by L2TP, the frame size should consider the MTU and the additional headers to avoid IP fragmentation. 8. Effects on Standard AVPs If ESP PDUs are being tunneled in accordance with this document, the following Call Management AVPs MAY be ignored: Bearer Type Framing Type Called Number Calling Number Sub-Address Initial Received LCP CONFREQ Last Sent LCP CONFREQ Last Received LCP CONFREQ Proxy Authen Type Proxy Authen Name Proxy Authen Challenge Proxy Authen ID Proxy Authen Response ACCM 9. Security Considerations All the underlying L2TP Security considerations remain, though no 'new' ones are introduced? 10. IANA Considerations Need to obtain a value for ES Service Type from IANA. Vasavada [Page 4] INTERNET DRAFT July 2001 11. Acknowledgments Many thanks to Harisankar Mallath for helping in reviewing this draft. 12. References [RFC2661] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC 2661, February 1999. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [L2TPST] McPherson D., Nanji S., "L2TP Service Type", Work in Progress, April 2001. [ESP] Vasavada, N., "ESP: Encapsulation Services Protocol", Work in Progress, July 2001. [L2TPDS] Calhoun, P., et. al., "L2TP Differentiated Services Extension", Work in Progress, March 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 14. Author's Address Nishit Vasavada Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Phone: +1 510.687.5200 Email: nishit@ambernetworks.com Vasavada [Page 5]