Network Working Group B. Patel
najinRequest for Comments: 3193 Intel
Category: Standards Track B. Aboba
W. Dixon
Microsoft
G. Zorn
S. Booth
Cisco Systems
November 2001
Securing L2TP using IPc
Status of this Memo
高等院校排名
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Rerved.
Abstract
This document discuss how L2TP (Layer Two Tunneling Protocol) may
utilize IPc to provide for tunnel authentication, privacy
protection, integrity checking and replay protection. Both the
voluntary and compulsory tunneling cas are discusd.
Patel, et al. Standards Track [Page 1]
RFC 3193 Securing L2TP using IPc November 2001
Table of Contents
1. Introduction .................................................. 2
1.1 Terminology .................................................. 3
1.2 Requirements language ........................................ 3
2. L2TP curity requirements ................................... 4
2.1 L2TP curity protocol ....................................... 5
2.2 Stateless compression and encryption ......................... 5
3. L2TP/IPc inter-operability guidelines ....................... 6
3.1. L2TP tunnel and Pha 1 and 2 SA teardown ................... 6
3.2. Fragmentation Issues ........................................ 6
3.3. Per-packet curity checks .................................. 7
4. IPc Filtering details when protecting L2TP .................. 7
4.1. IKE Pha 1 Negotiations .................................... 8
4.2. IKE Pha 2 Negotiations .................................... 8
5. Security Considerations ....................................... 15
5.1 Authentication issues ........................................ 15
5.2 IPc and PPP interactions ................................... 18
6. References .................................................... 21
Acknowledgments ..........................
.
....................... 22
Authors' Address ............................................... 23
Appendix A: Example IPc Filter ts ............................ 24
Intellectual Property Statement .................................. 27
Full Copyright Statement ......................................... 28
1. Introduction
L2TP [1] is a protocol that tunnels PPP traffic over variety of
networks (e.g., IP, SONET, ATM). Since the protocol encapsulates
PPP, L2TP inherits PPP authentication, as well as the PPP Encryption
Control Protocol (ECP) (described in [10]), and the Compression
Control Protocol (CCP) (described in [9]). L2TP also includes
support for tunnel authentication, which can be ud to mutually
authenticate the tunnel endpoints. However, L2TP does not define
tunnel protection mechanisms.
IPc is a protocol suite which is ud to cure communication at
the network layer between two peers. This protocol is comprid of
IP Security Architecture document [6], IKE, described in [7], IPc
AH, described in [3] and IPc ESP, described in [4]. IKE is the key
management protocol while AH and ESP are ud to protect IP traffic.
This document propos u of the IPc protocol suite for protecting
L2TP traffic over IP networks, and discuss how IPc and L2TP
should be ud together. This document does not attempt to
Patel, et al. Standards Track [Page 2]
RFC 3193 Securing L2TP using IPc November 2001
standardize end-to-end curity. When end-to-end curity is
required, it is recommended that additional curity mechanisms (such
as IPc or TLS [14]) be ud inside the tunnel, in addition to L2TP
tunnel curity.
Although L2TP does not mandate the u of IP/UDP for its transport
mechanism, the scope of this document is limited to L2TP over IP
networks. The exact mechanisms for enabling curity for non-IP
gnar
networks must be addresd in appropriate standards for L2TP over
specific non-IP networks.
1.1. Terminology
Voluntary Tunneling
In voluntary tunneling, a tunnel is created by the ur,
typically via u of a tunneling client. As a result, the
client will nd L2TP packets to the NAS which will forward
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 client. Another example of voluntary
tunneling is the gateway to gateway scenario. In this ca
the tunnel is created by a network device, typically a
router or network appliance. In this scenario either side
may start the tunnel on demand.
Compulsory Tunneling
In compulsory tunneling, a tunnel is created without any
a
ction from the client and without allowing the client any
choice. As a result, the client will nd PPP packets to
the NAS/LAC, which will encapsulate them in L2TP and tunnel
them to the LNS. In the compulsory tunneling ca, the
NAS/LAC must be L2TP-capable.
Initiator The initiator can be the LAC or the LNS and is the device
which nds the SCCRQ and receives the SCCRP.
Responder The responder can be the LAC or the LNS and is the device
which receives the SCCRQ and replies with a SCCRP.
1.2. Requirements language
obd是什么意思
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [2].
Patel, et al. Standards Track [Page 3]
RFC 3193 Securing L2TP using IPc November 2001
2. L2TP curity requirements
L2TP tunnels PPP traffic over the IP and non-IP public networks.
Therefore, both the control and data packets of L2TP protocol are
vulnerable to attack. Examples of attacks include:
[1] An adversary may try to discover ur identities by snooping data
packets.
[2] An adversary may try to modify packets (both control and data).
[3] An adversary may try to hijack the L2TP tunnel or the PPP
connection inside the tunnel.
[4] An adversary can launch denial of rvice attacks by terminating
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 negotiation so as to weaken the PPP authentication
process or gain access to ur passwords.
To address the threats, the L2TP curity protocol MUST be able to
provide authentication, integrity and replay protection for control
packets. In addition, it SHOULD be able to protect confidentiality
for control packets. It MUST be able to provide integrity and replay
protection of data packets, and MAY be able to protect
confidentiality of data packets. An L2TP curity protocol MUST also
provide a scalable approach to key management.
The L2TP protocol, and PPP authentication and encryption do not meet
the curity requirements for L2TP. L2TP tunnel authentication
provides mutual authentication between the LAC and the LNS at tunnel
origination. Therefore, it does not protect control and data traffic
on a per packet basis. Thus, L2TP tunnel authentication leaves the
L2TP tunnel vulnerable to attacks. 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, replay protection and key management
requirements. In addition, PPP ECP negotiation, outlined in [10]
does not provide for a protected ciphersuite negotiation. Therefore,
PPP encryption provides a weak curity solution, and in addition
does not assist in curing L2TP control channel.
Patel, et al. Standards Track [Page 4]
RFC 3193 Securing L2TP using IPc November 2001
Key management facilities are not provided by the L2TP protocol.
However, where L2TP tunnel authentication is desired, it is necessary
to distribute tunnel passwords.
Note that veral of the attacks outlined above can be carried out on
PPP packets nt over the link between the client and the NAS/LAC,
prior to encapsulation of the packets within an L2TP tunnel. While
strictly speaking the attacks are outside the scope of L2TP
curity, in order to protect against them, the client SHOULD provide
for confidentiality, authentication, replay and integrity protection
for PPP packets nt over the dial-up link. Authentication, replay
and integrity protection are not currently supported by PPP
encryption methods, described in [11]-[13].
2.1. L2TP Security Protocol
The L2TP curity 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 curity protocol MUST also
provide a scalable approach to key management.
To meet the above requirements, all L2TP curity compliant
implementations MUST implement IPc ESP for curing both L2TP
control and data packets. Transport mode MUST be supported; tunnel
mode MAY be supported. All the IPc-mandated ciphersuites
(described in RFC 2406 [4] and RFC 2402 [3]), including NULL
encryption MUST be supported. Note that although an implementation
MUST support all IPc ciphersuites, it is an operator choice which
ones will be ud. If confidentiality is not required (e.g., L2TP
data traffic), ESP with NULL encryption may be ud. The
implementations MUST implement replay protection mechanisms of IPc.
L2TP curity MUST meet the key management requirements of the IPc
janusprotocol suite. IKE SHOULD be supported for authentication, curity
association negotiation, and key management using the IPc DOI [5].
2.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, u of
stateful compression/encryption is feasible, but when run over IP,
this is not desirable. While providing better compression, when ud
wi
thout an underlying reliable delivery mechanism, stateful methods
magnify packet loss. As a result, they are problematic when ud
over the Internet where packet loss can be significant. Although
L2TP [1] is connection oriented, packet ordering is not mandatory,
Patel, et al. Standards Track [Page 5]
RFC 3193 Securing L2TP using IPc November 2001
which can create difficulties in implementation of stateful
compression/encryption schemes. The considerations are not as
bunga
important when L2TP is run over non-IP media such as IEEE 802, ATM,
X.25, or Frame Relay, since the media guarantee ordering, and
packet loss are typically low.
3. L2TP/IPc inter-operability guidelines
The following guidelines are established to meet L2TP curity
requirements using IPc in practical situations.
3.1. L2TP tunnel and Pha 1 and 2 SA teardown
Mechanisms within PPP and L2TP provide for both graceful and non-
graceful teardown. In the ca of PPP, an LCP TermReq and TermAck
quence corresponds to a graceful teardown. LCP keep-alive messages
and L2TP tunnel hellos provide the capability to detect when a non-
graceful teardown has occurred. Whenever teardown events occur,
causing the tunnel to clo, the control connection teardown
mechanism defined in [1] must be ud. Once the L2TP tunnel is
halt
deleted by either peer, any pha 1 and pha 2 SA's which still
exist as a result of the L2TP tunnel between the peers SHOULD be
deleted. Pha 1 and pha 2 delete messages SHOULD be nt when
this occurs.
When IKE receives a pha 1 or pha 2 delete message, IKE should
notify L2TP this event has occurred. If the L2TP state is such that
a ZLB ack has been nt in respon to a STOPCCN, this can be assumed
to be positive acknowledgment that the peer received the ZLB ack and
has performed a teardown of any L2TP tunnel state associated with the
peer. The L2TP tunnel state and any associated filters can now be
safely removed.
3.2. Fragmentation Issues
Since the default MRU for PPP connections is 1500 bytes,
fragmentation can become a concern when prepending L2TP and IPc
headers to a PPP frame. One mechanism which can be ud to reduce
this problem is to provide PPP with the MTU value of the
ingress/egress interface of the L2TP/IPc tunnel minus the overhead
of the extra headers. This should occur after the L2TP tunnel has
been tup and but before LCP negotiations begin. If the MTU value
of the ingress/egress interface for the tunnel is less than PPP's
default MTU, it may replace the value being ud. This value may
also be ud as the initial value propod for the MRU in the LCP
config req.
Patel, et al. Standards Track [Page 6]
RFC 3193 Securing
L2TP using IPc November 2001
If an ICMP PMTU is received by IPc, this value should be stored in
the SA as propod in [6]. IPc should also provide notification of
this event to L2TP so that the new MTU value can be reflected into
the PPP interface. Any new PTMU discoveries en at the PPP
interface should be checked against this new value and procesd
accordingly.
3.3. Per-packet curity checks
When a packet arrives from a tunnel which requires curity, L2TP
MUST:
[1] Check to ensure that the packet was decrypted and/or
authenticated by IPc. Since IPc already verifies that the
packet arrived in the correct SA, L2TP can be assured that thepink什么意思
packet was indeed nt by a trusted peer and that it did not
arrive in the clear.
[2] Verify that the IP address and UDP port values in the packet
match the socket information which was ud to tup the L2TP
tunnel. This step prevents malicious peers from spoofing packets
into other tunnels.
4. IPc Filtering details when protecting L2TP
Since IKE/IPc is agnostic about the nuances of the application it
基层公务员工资attendee
is protecting, typically no integration is necessary between the
application and the IPc protocol. However, protocols which allow
the port number to float during the protocol negotiations (such as
L2TP), can cau problems within the current IKE framework. The L2TP
specification [1] states that implementations MAY u a dynamically
assigned UDP source port. This port change is reflected in the SCCRP
nt from the responder to the initiator.
Although the current L2TP specification allows the responder to u a
new IP address when nding the SCCRP, implementations requiring
protection of L2TP via IPc SHOULD NOT do this. To allow for this
behavior when using L2TP and IPc, when the responder choos a new
IP address it MUST nd a StopCCN to the initiator, with the Result
and Error Code AVP prent. The Result Code MUST be t to 2
(General Error) and the Error Code SHOULD be t to 7 (Try Another).
If the Error Code is t to 7, then the optional error message MUST
be prent and the contents MUST contain the IP address (ASCII
encoded) that the Responder desires to u for subquent
communications. Only the ASCII encoded IP address should be prent
in the error message. The IP address is encoded in dotted decimal
format for IPv4 or in RFC 2373 [17] format for IPv6. The initiator
MUST par the result and error code information and nd a new SCCRQ
Patel, et al. Standards Track [Page 7]
RFC 3193 Securing L2TP using IPc November 2001
to the new IP address contained in the error message. This approach
reduces complexity since now the initiator always knows precily the
IP address
