PPP Working Group William Palter Request for Comments: DRAFT RedBack Networks Category: Internet Draft Title: draft-ietf-l2tpext-adc-00.txt Date: October 1999 L2TP Alternate Data Channel (``ADC'') Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``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. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for tunneling PPP sessions over arbitrary media. There exists a class of services for which different types of data packets should be segregated from each other, over the lower layer transport. This document describes the solution space addressed, its underlying motivations, and the protocol modifications required. This enhancement to the L2TP protocol is called L2TP Alternate Data Channel, or ``L2TPADC''. 1. Introduction L2TP [1] defines a general purpose mechanism for tunneling PPP over various media. By design, it insulates L2TP operation from the details of the media over which it operates. There are conditions where it may be desirable to send the data portion or some subset of the data portion of an L2TP tunnel over a different media, or using different options of the lower layer medium than is used for the control portion of the tunnel. Palter expires March 2000 [Page 1] INTERNET DRAFT October 1999 2. Tunnel Establishment 2.1 Negotiation L2TPADC is negotiated by an optional AVP ``L2TPADC'' which is placed in the SCCRQ/SCCRP tunnel establishment messages. The effect of this AVP on a given session will never occur until L2TP reaches a state where payload data may be forwarded for a session in the tunnel. Additionally, each side intending to use L2TPADC MUST NOT do so until it both sends and receives this AVP. Unless an L2TPADC AVP exists in both the SCCRQ and SCCRP packets, L2TP will operate in its regular mode 2.2 AVP Format The AVP L2TPADC is encoded as Vendor ID 9, Attribute is the 16-bit quantity 2 (the ID 9 reflects Cisco Systems, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). The Value is divided into two fields one indicating the channel type and usage of this alternate data channel and one for media specific information about the channel. This AVP itself is optional. The only type that is currently defined is the Degraded IPSEC Channel (see section 2.3.1). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 + data length | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media Specific Data ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.3 Channel Types 2.3.1 Degraded IPSEC Channel The Degraded IPSEC Channel, Channel Type 0, is for use when the data flow on a tunnel may require strong security on some sessions (or packets within a session) and less secure security for other data packets and/or sessions. The control channel (which is also the primary data channel) should be setup with the highest level of security that is required. The media specific data should be set to a 16 bit value indicating another UDP port to which data packets can be sent that have less security associated with them. For example, a tunnel is created with IPSEC encryption on the control channel, and a client establishes a PPP session over the tunnel in which ECP is also enabled and doing encryption. In this case the ECP PPP frames can be sent over the Degraded IPSEC Channel, and non ECP protected frames can be sent over the primary data channel. The policy for which packets can be sent over the degraded channel Palter expires March 2000 [Page 2] INTERNET DRAFT October 1999 is beyond the scope of this document. An implementation MUST send traffic over the strongest channel, unless it has specific policies permitting it to send a packet over the degraded channel. 2.4 Data Packet Flow When data packets for a single session are sent over more than one, data channel the sequence number space is shared among both flows, L2TP SHOULD process all packets for a tunnel without regard for which channel the packet is received upon. 2.5 Control Packet Flow Control packets MUST be sent over the primary channel. If a control packet is received on the alternate channel, it MUST be discarded. 3. Security Considerations Security can be compromised by using this option. It is assumed that implementation policies with regard to determining which packets can go over a degraded channel will be sufficient to protect security. In addition since the security policies may not be symmetrical, an implementation should have the ability to be configured not to allow this option to be used. 4. Acknowledgments Thanks to Andrew J. Valencia, W. Mark Townsley, and Robert Adams of Cisco Systems for help in creating, and reviewing this draft. 5. Contacts William Palter RedBack Networks 1389 Moffett Park Drive Sunnyvale, CA 94089 palter.ietf@zev.net 6. References [1] A. Valencia, ``Layer 2 Tunnel Protocol (L2TP)'', Internet Draft, October 1997 Palter expires March 2000 [Page 3] INTERNET DRAFT October 1999 Palter expires March 2000 [Page 4]