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
successfully.
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
attacks.
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.
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
document.
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
negotiation).
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
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].
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
1981.
[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:
http://www.iana.org/numbers.html
[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.
[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.
13.0 Authors' Addresses
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
EMail: gurdeep@microsoft.com
Bill Palter
RedBack Networks, Inc
1389 Moffett Park Drive
Sunnyvale, CA 94089
EMail: palter@zev.net
Allan Rubens
Ascend Communications
1701 Harbor Bay Parkway
Alameda, CA 94502
EMail: acr@del.com
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: townsley@cisco.com
Andrew J. Valencia
cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: vandys@cisco.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: gwz@acm.org
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
SSHTRESH.
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.
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)
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
Director.
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
rights.
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
English.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
