PPPEXT Working Group Baiju Patel
INTERNET-DRAFT Intel
Category: Standards Track Bernard Aboba
<draft-ietf-pppext-l2tp-security-02.txt> Microsoft
22 May 1998
Securing L2TP using IPSEC
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-pppext-l2tp-security-02.txt> and expires December 1, 1998.
Please send comments to the authors.
2. Abstract
This document discusses how L2TP may utilize IPSEC to provide for tun-
nel authentication, privacy protection, integrity check and replay
protection. Both the voluntary and compulsory tunneling cases are dis-
cussed.
3. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [2].
4. Terminology
Voluntary Tunneling
In voluntary tunneling, a tunnel is created by the user,
typically via use of a tunneling client. As a result, the
user will send L2TP packets to the NAS which will forward
Patel & Aboba [Page 1]
INTERNET-DRAFT 22 May 1998
them on to the LNS. In voluntary tunneling, the NAS does not
need to support L2TP, and the LAC resides on the same
machine as the user.
Compulsory Tunneling
In compulsory tunneling, a tunnel is created without any
action from the user and without allowing the user any
choice. As a result, the user will send PPP packets to the
NAS/LAC, which will encapsulate them in L2TP and tunnel them
to the LNS. In the compulsory tunneling case, the NAS/LAC
must be L2TP capable.
5. Introduction
L2TP, described in [1], is a protocol that tunnels PPP traffic over
variety of networks (e.g., IP, SONET, ATM). Since the protocol encap-
sulates PPP, L2TP inherits PPP authentication, as well as the PPP
Encryption Control Protocol (ECP) (described in [10]), and the Com-
pression Control Protocol (CCP) (described in [9]). L2TP also includes
support for tunnel authentication, which can be used to mutually
authenticate the tunnel endpoints. However, L2TP does not define tun-
nel protection mechanisms.
IPSEC is a protocol suite defined by IETF working group on IP security
to secure communication at the network layer between communicating
peers. This protocol is comprised of IP Security Architecture docu-
ment [6], IKE, described in [7], IPSEC AH, described in [3] and IPSEC
ESP, described in [4]. IKE is the key management protocol while AH and
ESP are used to protect IP traffic.
This draft proposes use of the IPSEC protocol suite for protecting
L2TP traffic over IP and Non-IP networks, and discusses how IPSEC and
L2TP should be used together. This document does not attempt to stan-
dardize end-to-end security. When end-to-end security is required, it
is recommended that additional security mechanisms (such as IPSEC or
TLS) be used inside the tunnel, in addition to L2TP tunnel security.
6. L2TP security requirements
L2TP tunnels PPP traffic over the IP and non-IP public networks.
Therefore, both the control and data packets of L2TP protocol are vul-
nerable to attack. Examples of attacks include:
1. The adversary may try to discover user identities by snooping data
packets.
2. The adversary may try to modify packets (both control and data).
3. The adversary may try to hijack the L2TP tunnel or the PPP connec-
tion inside the tunnel.
4. An adversary can launch denial of service attacks by terminating
Patel & Aboba [Page 2]
INTERNET-DRAFT 22 May 1998
PPP connections, or L2TP tunnels.
5. An adversary may attempt to disrupt the PPP ECP negotiation in
order to weaken or remove confidentiality protection. Alternatively,
an adversary may wish to disrupt the PPP LCP authentication negotia-
tion so as to weaken the PPP authentication process or gain access to
user passwords.
To address these threats, the L2TP security protocol MUST be able to
provide authentication, integrity and replay protection for control
packets. In addition, it SHOULD be able to protect confidentiality of
control packets. It MUST be able to provide integrity and replay pro-
tection of data packets, and MAY be able to protect confidentiality of
data packets. An L2TP security protocol MUST also provide a scalable
approach to key management.
The L2TP protocol, and PPP authentication and encryption do not meet
the security requirements for L2TP. L2TP authentication typically
mutually authenticates LAC to LNS at tunnel origination and may peri-
odically re-authenticate. Therefore, it does not protect control and
data traffic on a per packet basis. Thus, L2TP tunnel authentication
leaves L2TP tunnel vulnerable to attack. PPP authenticates the client
to the LNS, but also does not provide per- packet authentication,
integrity, or replay protection. PPP encryption meets confidentiality
requirements for PPP traffic but does not address authentication,
integrity and key management requirements. In addition, PPP ECP nego-
tiation, outlined in [10] does not provide for a protected ciphersuite
negotiation. Therefore, PPP encryption provides a weak security solu-
tion, and in addition does not assist in securing L2TP control chan-
nel.
Key management facilities are not provided by the L2TP protocol. How-
ever, where L2TP tunnel authentication is desired, it is necessary to
distribute tunnel passwords.
Note that several of the attacks outlined above can be carried out on
PPP packets sent over the link between the client and the NAS/LAC,
prior to encapsulation of the packets within an L2TP tunnel. While
strictly speaking these attacks are outside the scope of L2TP secu-
rity, in order to protect against them, the user SHOULD provide for
confidentiality, authentication and integrity protection for PPP pack-
ets sent over the dial-up link. Authentication and integrity protec-
tion are not currently supported by PPP encryption methods, described
in [11]-[13].
6.1. L2TP Security Protocol
The L2TP security protocol MUST provide authentication, integrity and
replay protection for control packets. In addition, it SHOULD protect
confidentiality of control packets. It MUST provide integrity and
replay protection of data packets, and MAY protect confidentiality of
data packets. An L2TP security protocol MUST also provide a scalable
approach to key management.
Patel & Aboba [Page 3]
INTERNET-DRAFT 22 May 1998
To meet above requirements, all L2TP security compliant implementa-
tions MUST implement IPSEC ESP for securing L2TP control packets
and SHOULD implement IPSEC ESP for protection of L2Tp data packets.
All mandated cipher suites, including NULL encryption, of IPSEC ESP
MUST be supported. Note that if confidentiality is not required (e.g.,
L2TP data traffic), ESP with NULL encryption may be used. The imple-
mentations MUST implement replay protection mechanisms of IPSEC.
L2TP security MUST meet the key management requirements of the IPSEC
protocol suite. IKE SHOULD be supported for authentication, security
association negotiation, and key management using the IPSEC DOI [5].
6.2. Stateless compression and encryption
Stateless encryption and/or compression is highly desirable when L2TP
is run over IP. Since L2TP is a connection-oriented protocol, use of
stateful compression/encryption is feasible, but when run over IP,
this is not desirable. While providing better compression, and some-
what more secure encryption, when used without an underlying reliable
delivery mechanism stateful methods magnify packet losses, and thus
are problematic when used over the Internet where packet loss can be
significant. In addition, although L2TP is connection oriented, the
L2TP specification [1] does not mandate packet ordering, which can
create difficulties in implementation of stateful compression/encryp-
tion schemes. However, these considerations are not as important when
L2TP is run over non-IP media such as ATM, X.25, or Frame Relay, since
these media guarantee ordering, and packet losses are typically low.
6.3. Implementation considerations for L2TP over Non-IP networks
L2TP requires that a non-IP network supports packet transport, so that
the non-IP network should be able to carry L2TP control and data pack-
ets.
Since ESP functions are defined on the IP payload (excluding the IP
header), the presence of an IP header is not a requirement for use of
ESP. Therefore, L2TP implemented on non-IP networks MUST be able to
transport IPSEC ESP packets. The next payload field of the ESP header
MUST be set to the L2TP protocol number. IANA has assigned 115 as the
protocol number for L2TP.
IKE messages use UDP transport. Therefore, in order to be compliant
with the IKE protocol on non-IP media, the non-IP media (which is
capable of transporting packets) MUST support transport of UDP data-
grams. Since the IP header is not present in the UDP datagram over
non-IP media, the UDP checksum MUST be set to zero by the source and
ignored by the destination.
The exact mechanisms for enabling transport of ESP and UDP packets
over non-IP media MUST be addressed in appropriate standards for L2TP
over specific non-IP networks.
Patel & Aboba [Page 4]
INTERNET-DRAFT 22 May 1998
7. L2TP/IPSEC interoperability guidelines
The following guidelines are established to meet L2TP security
requirements using IPSEC in practical situations. Note that this sec-
tion is not a requirement for an implementation to be L2TP security
compliant. Its purpose to make the implementors aware of certain
efficiency and security considerations.
In the scenarios that follow, it is assumed that both L2TP clients and
servers are able to set and get the properties of IPSEC security asso-
ciations, as well as to influence the IPSEC security services negoti-
ated. Furthermore, it is assumed that L2TP clients and servers are
able to influence the negotiation process for PPP encryption and com-
pression.
7.1. Compulsory tunnel
In the case of a compulsory tunnel, the dial-in user will be sending
PPP packets to the LAC, and will typically not be aware that its pack-
ets are being tunneled, nor that any security services are in place
between the LAC and LNS. From the LNS's point of view, it will note
arrival of a PPP data packet encapsulated in L2TP, which is itself
encapsulated in an IP packet. Assuming that the LNS is able to
retrieve the properties of the Security Association set up between
itself and the LAC, it will have knowledge of the security services in
place between the LAC and itself. Thus in the compulsory tunneling
case, the dial-in user and the LNS have unequal knowledge of the
security services in place between them.
Since the LNS is capable of knowing whether confidentiality, authenti-
cation, integrity and replay protection are in place between the LAC
and itself, it can use this knowledge in order to modify its behavior
during PPP ECP and CCP negotiation. For example, let us assume that
LNS confidentiality policy can be described by one of the following
terms: "Require Encryption," "Allow Encryption" or "Prohibit Encryp-
tion." If IPSEC confidentiality services are in place, then an LNS
implementing a "Prohibit Encryption" policy will act as though the
policy had been violated. Similarly, an LNS implementing a "Require
Encryption" or "Allow Encryption" policy will act as though these
policies were satisfied, and would not mandate use of PPP encryption
or compression. Note however, that this is not the same as insisting
that PPP encryption and compression be turned off, since this decision
will depend on the policy of the dialin user.
Since the dial-in user has no knowledge of the security services in
place between the LAC and the LNS, and since it may not trust the LAC
or the wire between itself and the LAC, the dial-in user will typi-
cally want to ensure sufficient security through use of end-to-end
IPSEC or PPP encryption/compression between itself and the LNS.
A dial-in user wishing to ensure security services over the entire
travel path would not modify this behavior even if it had knowledge of
the security services in place between the LAC and the LNS. This is
Patel & Aboba [Page 5]
INTERNET-DRAFT 22 May 1998
because the dial-in user needs to negotiate confidentiality services
between itself and the LNS in order to provide privacy on the wire
between itself and the LAC. Similarly, the dial-in user needs to nego-
tiate end-to-end security between itself and the endstation in order
to ensure confidentiality on the portion of the path between the LNS
and the endstation.
Given that the dial-in user will typically not trust the LAC and will
negotiate confidentiality and compression services on its own, the LAC
may only wish to negotiate IPSEC ESP with null encryption (described
in []) with the LNS, and the LNS will request replay protection. This
will ensure that confidentiality and compression services will not be
duplicated over the path between the LAC and the LNS. This will typi-
cally result in better scalability for the LAC, since encryption will
be handled by the dial-in user and the LNS.
The dial-in user can satisfy its desire for confidentiality services
in one of two ways. If it knows that all endstations that it will com-
municate with are IPSEC-capable (or if it refuses to talk to non-IPSEC
capable endstations), then it can refuse to negotiate PPP encryp-
tion/compression and negotiate IPSEC ESP with the endstations instead.
If the client does not know that all endstations it will contact are
IPSEC capable (the most likely case), then it will negotiate PPP
encryption/compression. This may result in duplicate compres-
sion/encryption which can only be eliminated if PPP compres-
sion/encryption can be turned off on a per-packet basis. Note that
since the LNS knows that the dial-in user's packets are being tunneled
but the dial-in user does not, the LNS can ensure that stateless com-
pression/encryption is used by offering stateless compression/encryp-
tion methods if available in the ECP and CCP negotiations.
7.2. Voluntary tunnel
In the case of a voluntary tunnel, the dial-in user will be sending
L2TP packets to the NAS, which will route them to the LNS. Over a
dialup link, these L2TP packets will be encapsulated in IP and PPP.
Assuming that it is possible for the dial-in user to retrieve the
properties of the Security Association between itself and the LNS, the
dial-in user will have knowledge of any security services negotiated
between itself and the LNS. It will also have knowledge of PPP encryp-
tion/compression services negotiated between itself and the NAS.
From the LNS's point of view, it will note a PPP packet encapsulated
in L2TP, which is itself encapsulated in an IP frame. This situation
is identical to the compulsory tunneling case. Assuming that the LNS
is able to retrieve the properties of the Security Association set up
between itself and the dial-in user, it will have knowledge of the
security services in place between the dial-in user and itself. Thus
in the voluntary tunneling case, the dial-in user and the LNS have
symmetric knowledge of the security services in place between them.
Since the LNS is capable of knowing whether confidentiality, authenti-
cation, integrity check or replay protection is in place between the
Patel & Aboba [Page 6]
INTERNET-DRAFT 22 May 1998
dial-in user and itself, it is able to use this knowledge to modify
its PPP ECP and CCP negotiation stance. If IPSEC confidentiality is in
place, the LNS can behave as though a "Require Encryption" directive
had been fulfilled, not mandating use of PPP encryption or compres-
sion. Typically the LNS will not insist that PPP encryption/compres-
sion be turned off, instead leaving this decision to the dial-in user.
Since the dial-in user has knowledge of the security services in place
between itself and the LNS, it can act as though a "Require Encryp-
tion" directive had been fulfilled if IPSEC ESP was already in place
between itself and the LNS. Thus, it can request that PPP encryption
and compression not be negotiated. Note that if IP compression ser-
vices cannot be negotiated, it will typically be desirable to turn off
PPP compression if no stateless method is available, due to the unde-
sirable effects of stateful PPP compression.
Thus in the voluntary tunneling case the dial-in user and LNS will
typically be able to avoid use of PPP encryption and compression,
negotiating IPSEC Confidentiality, Authentication, and Integrity pro-
tection services instead, as well as IP Compression if avail-
able.
This may result in duplicate encryption if the dial-in user is commu-
nicating with an IPSEC-capable endstation. In order to avoid duplicate
encryption/compression, the dial-in user may negotiate two Security
Associations with the LNS, one with ESP with null encryption, and one
with confidentiality/compression. Packets going to an IPSEC-capable
endstation would run over the ESP with null encryption security asso-
ciation, and packets to a non-IPSEC capable endstation would run over
the other security association. Note that many IPSEC implementations
cannot support this without allowing L2TP packets on the same tunnel
to be originated from multiple UDP ports. This requires modifications
to the L2TP specification.
Also note that the dial-in user may wish to put confidentiality ser-
vices in place for non-tunneled packets travelling between itself and
the NAS. This will protect the dial-in user against eavesdropping on
the wire between itself and the NAS. As a result, it may wish to nego-
tiate PPP encryption and compression with the NAS. As in compulsory
tunneling, this will result in duplicate encryption and possibly com-
pression unless PPP compression/encryption can be turned off on a per-
packet basis.
8. Security considerations
This draft defines a security protocol.
9. Acknowledgements
Thanks to Gurdeep Singh Pall, David Eitelbach, William Dixon, Peter
Ford, and Sanjay Anand of Microsoft, John Richardson of Intel and Rob
Adams of Cisco for many useful discussions of this problem space.
Patel & Aboba [Page 7]
INTERNET-DRAFT 22 May 1998
10. References
[1] K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, B. Palter, A.
Valencia, G. S. Pall, J. Taarud, W. M. Townsley, W. Verthein. "Layer
Two Tunneling Protocol -- L2TP." Internet draft (work in progress),
draft-ietf-pppext-l2tp-10.txt, April 1998.
[2] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, March 1997.
[3] S. Kent, R. Atkinson. "IP Authentication Header." Internet draft
(work in progress), draft-ietf-ipsec-auth-header-06.txt, May 1998.
[4] S. Kent, R. Atkinson. "IP Encapsulating Security Payload (ESP)."
Internet draft (work in progress), draft-ietf-ipsec-esp-v2-05.txt,
May 1998.
[5] D. Piper. "The Internet IP Security Domain of Interpretation of
ISAKMP." Internet draft (work in progress), draft-ietf-ipsec-ipsec-
doi-09.txt, May 1998.
[6] R. Atkinson, S. Kent. "Security Architecture for the Internet Pro-
tocol." Internet draft (work in progress), draft-ietf-ipsec-arch-
sec-05.txt, May 1998.
[7] D. Harkins, D. Carrel. "The Internet Key Exchange (IKE)." Inter-
net draft (work in progress), draft-ietf-ipsec-isakmp-oakley-07.txt,
March 1998.
[8] W. Simpson. "The Point-to-Point Protocol (PPP)". RFC 1661, July
1994.
[9] D. Rand. "The PPP Compression Control Protocol (CCP)". RFC 1962,
Novell, June 1996.
[10] G. Meyer. "The PPP Encryption Control Protocol (ECP)". RFC 1968,
Spider Systems, June 1996.
[11] K. Sklower, G. Meyer. "The PPP DES Encryption Protocol (DESE)".
RFC 1969, UCB, Spider Systems, June 1996.
[12] K. Sklower, G. Meyer. "The PPP DES Encryption Protocol, Version
2 (DESE-bis)". Internet draft (work in progress), draft-ietf-pppext-
des-encrypt-v2-02.txt, UC Berkeley, Shiva, March 1998.
[13] H. Kummert. "The PPP Triple-DES Encryption Protocol (3DESE)".
Internet draft (work in progress), draft-ietf-pppext-3des-
encrypt-00.txt, Nentec GmbH, July 1997.
11. Authors' Addresses
Baiju V. Patel
Intel Corp
Patel & Aboba [Page 8]
INTERNET-DRAFT 22 May 1998
2511 NE 25th Ave
Hillsboro, OR 97124
Phone: 503-264-2422
Email: baiju.v.patel@intel.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Patel & Aboba [Page 9]
