Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 2661


Layer Two Tunneling Protocol "L2TP"

Part 4 of 4, p. 69 to 80
Prev RFC Part


prevText      Top      Up      ToC       Page 69 
9.0 Security Considerations

   L2TP encounters several security issues in its operation.  The
   general approach of L2TP to these issues is documented here.

Top      Up      ToC       Page 70 
9.1 Tunnel Endpoint Security

   The tunnel endpoints may optionally perform an authentication
   procedure of one another during tunnel establishment.  This
   authentication has the same security attributes as CHAP, and has
   reasonable protection against replay and snooping during the tunnel
   establishment process. This mechanism is not designed to provide any
   authentication beyond tunnel establishment; it is fairly simple for a
   malicious user who can snoop the tunnel stream to inject packets once
   an authenticated tunnel establishment has been completed

   For authentication to occur, the LAC and LNS MUST share a single
   secret.  Each side uses this same secret when acting as authenticatee
   as well as authenticator. Since a single secret is used, the tunnel
   authentication AVPs include differentiating values in the CHAP ID
   fields for each message digest calculation to guard against replay

   The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3)
   SHOULD be selected in an unpredictable manner rather than
   sequentially or otherwise.  Doing so will help deter hijacking of a
   session by a malicious user who does not have access to packet traces
   between the LAC and LNS.

9.2 Packet Level Security

   Securing L2TP requires that the underlying transport make available
   encryption, integrity and authentication services for all L2TP
   traffic.  This secure transport operates on the entire L2TP packet
   and is functionally independent of PPP and the protocol being carried
   by PPP. As such, L2TP is only concerned with confidentiality,
   authenticity, and integrity of the L2TP packets between its tunnel

   endpoints (the LAC and LNS), not unlike link-layer encryption being
   concerned only about protecting the confidentiality of traffic
   between its physical endpoints.

9.3 End to End Security

   Protecting the L2TP packet stream via a secure transport does, in
   turn, also protect the data within the tunneled PPP packets while
   transported from the LAC to the LNS. Such protection should not be
   considered a substitution for end-to-end security between
   communicating hosts or applications.

Top      Up      ToC       Page 71 
9.4 L2TP and IPsec

   When running over IP, IPsec provides packet-level security via ESP
   and/or AH. All L2TP control and data packets for a particular tunnel
   appear as homogeneous UDP/IP data packets to the IPsec system.

   In addition to IP transport security, IPsec defines a mode of
   operation that allows tunneling of IP packets. The packet level
   encryption and authentication provided by IPsec tunnel mode and that
   provided by L2TP secured with IPsec provide an equivalent level of
   security for these requirements.

   IPsec also defines access control features that are  required of a
   compliant IPsec implementation. These features allow filtering of
   packets based upon network and transport layer characteristics such
   as IP address, ports, etc. In the L2TP tunneling model, analogous
   filtering is logically performed at the PPP layer or network layer
   above L2TP.  These network layer access control features may be
   handled at the LNS via vendor-specific authorization features based
   upon the authenticated PPP user, or at the network layer itself by
   using IPsec transport mode end-to-end between the communicating
   hosts. The requirements for access control mechanisms are not a part
   of the L2TP specification and as such are outside the scope of this

9.5 Proxy PPP Authentication

   L2TP defines AVPs that MAY be exchanged during session establishment
   to provide forwarding of PPP authentication information obtained at
   the LAC to the LNS for validation (see Section 4.4.5). This implies a
   direct trust relationship of the LAC on behalf of the LNS.  If the
   LNS chooses to implement proxy authentication, it MUST be able to be
   configured off, requiring a new round a PPP authentication initiated
   by the LNS (which may or may not include a new round of LCP

10.0 IANA Considerations

   This document defines a number of "magic" numbers to be maintained by
   the IANA.  This section explains the criteria to be used by the IANA
   to assign additional numbers in each of these lists. The following
   subsections describe the assignment policy for the namespaces defined
   elsewhere in this document.

10.1 AVP Attributes

   As defined in Section 4.1, AVPs contain vendor ID, Attribute and
   Value fields. For vendor ID value of 0, IANA will maintain a registry

Top      Up      ToC       Page 72 
   of assigned Attributes and in some case also values. Attributes 0-39
   are assigned as defined in Section 4.4. The remaining values are
   available for assignment through IETF Consensus [RFC 2434].

10.2 Message Type AVP Values

   As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0)
   have an associated value maintained by IANA. Values 0-16 are defined
   in Section 3.2, the remaining values are available for assignment via
   IETF Consensus [RFC 2434]

10.3 Result Code AVP Values

   As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1)
   contain three fields.  Two of these fields (the Result Code and Error
   Code fields) have associated values maintained by IANA.

10.3.1 Result Code Field Values

   The Result Code AVP may be included in CDN and StopCCN messages. The
   allowable values for the Result Code field of the AVP differ
   depending upon the value of the Message Type AVP.  For the StopCCN
   message, values 0-7 are defined in Section 4.4.2; for the StopCCN
   message, values 0-11 are defined in the same section.  The remaining
   values of the Result Code field for both messages are available for
   assignment via IETF Consensus [RFC 2434].

10.3.2 Error Code Field Values

   Values 0-7 are defined in Section 4.4.2.  Values 8-32767 are
   available for assignment via IETF Consensus [RFC 2434]. The remaining
   values of the Error Code field are available for assignment via First
   Come First Served [RFC 2434].

10.4 Framing Capabilities & Bearer Capabilities

   The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in
   Section 4.4.3) both contain 32-bit bitmasks. Additional bits should
   only be defined via a Standards Action [RFC 2434].

10.5 Proxy Authen Type AVP Values

   The Proxy Authen Type AVP (Attribute Type 29) has an associated value
   maintained by IANA. Values 0-5 are defined in Section 4.4.5, the
   remaining values are available for assignment via First Come First
   Served [RFC 2434].

Top      Up      ToC       Page 73 
10.6 AVP Header Bits

   There are four remaining reserved bits in the AVP header. Additional
   bits should only be assigned via a Standards Action [RFC 2434].

11.0 References

   [DSS1]    ITU-T Recommendation, "Digital subscriber Signaling System
             No. 1 (DSS 1) - ISDN user-network interface layer 3
             specification for basic call control", Rec. Q.931(I.451),
             May 1998

   [KPS]     Kaufman, C., Perlman, R., and Speciner, M., "Network
             Security:  Private Communications in a Public World",
             Prentice Hall, March 1995, ISBN 0-13-061466-1

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September

   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
             STD 13, RFC 1034, November 1987.

   [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
             Serial Links", RFC 1144, February 1990.

   [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
             RFC 1661, July 1994.

   [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
             July 1994.

   [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.

   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.  See also:
   [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
             Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
             August 1996.

   [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
             Protocol (CHAP)", RFC 1994, August 1996.

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
             and E. Lear, "Address Allocation for Private Internets",
             BCP 5, RFC 1918, February 1996.

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

   [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
             Authentication Dial In User Service (RADIUS)", RFC 2138,
             April 1997.

   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
             Languages", BCP 18, RFC 2277, January 1998.

   [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
             Forwarding (Protocol) L2F", RFC 2341, May 1998.

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

   [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
             and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
             RFC 2637, July 1999.

   [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
             Protocols", Addison-Wesley Publishing Company, Inc., March
             1996, ISBN 0-201-63346-9

12.0 Acknowledgments

   The basic concept for L2TP and many of its protocol constructs were
   adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A.
   Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein,
   J. Taarud, W. Little, and G. Zorn.

   Dory Leifer made valuable refinements to the protocol definition of
   L2TP and contributed to the editing of this document.

   Steve Cobb and Evan Caves redesigned the state machine tables.

   Barney Wolff provided a great deal of design input on the endpoint
   authentication mechanism.

   John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
   Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
   review at the 43rd IETF in Orlando, FL., which led to improvement of
   the overall readability and clarity of this document.

Top      Up      ToC       Page 75 
13.0 Authors' Addresses

   Gurdeep Singh Pall
   Microsoft Corporation
   Redmond, WA


   Bill Palter
   RedBack Networks, Inc
   1389 Moffett Park Drive
   Sunnyvale, CA 94089


   Allan Rubens
   Ascend Communications
   1701 Harbor Bay Parkway
   Alameda, CA 94502


   W. Mark Townsley
   cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709


   Andrew J. Valencia
   cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706


   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052


Top      Up      ToC       Page 76 
Appendix A: Control Channel Slow Start and Congestion Avoidance

   Although each side has indicated the maximum size of its receive
   window, it is recommended that a slow start and congestion avoidance
   method be used to transmit control packets.  The methods described
   here are based upon the TCP congestion avoidance algorithm as
   described in section 21.6 of TCP/IP Illustrated, Volume I, by W.
   Richard Stevens [STEVENS].

   Slow start and congestion avoidance make use of several variables.
   The congestion window (CWND) defines the number of packets a sender
   may send before waiting for an acknowledgment. The size of CWND
   expands and contracts as described below. Note however, that CWND is
   never allowed to exceed the size of the advertised window obtained
   from the Receive Window AVP (in the text below, it is assumed any
   increase will be limited by the Receive Window Size). The variable
   SSTHRESH determines when the sender switches from slow start to
   congestion avoidance. Slow start is used while CWND is less than

   A sender starts out in the slow start phase. CWND is initialized to
   one packet, and SSHTRESH is initialized to the advertised window
   (obtained from the Receive Window AVP).  The sender then transmits
   one packet and waits for its acknowledgement (either explicit or
   piggybacked). When the acknowledgement is received, the congestion
   window is incremented from one to two.  During slow start, CWND is
   increased by one packet each time an ACK (explicit ZLB or
   piggybacked) is received. Increasing CWND by one on each ACK has the
   effect of doubling CWND with each round trip, resulting in an
   exponential increase. When the value of CWND reaches SSHTRESH, the
   slow start phase ends and the congestion avoidance phase begins.

   During congestion avoidance, CWND expands more slowly. Specifically,
   it increases by 1/CWND for every new ACK received. That is, CWND is
   increased by one packet after CWND new ACKs have been received.
   Window expansion during the congestion avoidance phase is effectively
   linear, with CWND increasing by one packet each round trip.

   When congestion occurs (indicated by the triggering of a
   retransmission) one half of the CWND is saved in SSTHRESH, and CWND
   is set to one. The sender then reenters the slow start phase.

Top      Up      ToC       Page 77 
Appendix B: Control Message Examples

B.1: Lock-step tunnel establishment

   In this example, an LAC establishes a tunnel, with the exchange
   involving each side alternating in sending messages.  This example
   shows the final acknowledgment explicitly sent within a ZLB ACK
   message. An alternative would be to piggyback the acknowledgement
   within a message sent as a reply to the ICRQ or OCRQ that will likely
   follow from the side that initiated the tunnel.

          LAC or LNS               LNS or LAC
          ----------               ----------

          SCCRQ     ->
          Nr: 0, Ns: 0
                                   <-     SCCRP
                                   Nr: 1, Ns: 0
          SCCCN     ->
          Nr: 1, Ns: 1
                                   <-       ZLB
                                   Nr: 2, Ns: 1

B.2: Lost packet with retransmission

   An existing tunnel has a new session requested by the LAC.  The ICRP
   is lost and must be retransmitted by the LNS.  Note that loss of the
   ICRP has two impacts: not only does it keep the upper level state
   machine from progressing, but it also keeps the LAC from seeing a
   timely lower level acknowledgment of its ICRQ.

            LAC                               LNS
            ---                               ---

        ICRQ      ->
        Nr: 1, Ns: 2

                         (packet lost)   <-      ICRP
                                         Nr: 3, Ns: 1

      (pause; LAC's timer started first, so fires first)

       ICRQ      ->
       Nr: 1, Ns: 2

       (Realizing that it has already seen this packet,
       the LNS discards the packet and sends a ZLB)

Top      Up      ToC       Page 78 
                                         <-       ZLB
                                         Nr: 3, Ns: 2

                       (LNS's retransmit timer fires)

                                         <-      ICRP
                                         Nr: 3, Ns: 1
       ICCN      ->
       Nr: 2, Ns: 3

                                         <-       ZLB
                                         Nr: 4, Ns: 2

Top      Up      ToC       Page 79 
Appendix C: Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat."

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed

Top      Up      ToC       Page 80 
Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


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