TXT

RFC3193

By Amy Cooper,2014-06-10 08:34
7 views 0
RFC3193

??Network Working Group B. Patel

    Request for Comments: 3193 Intel

    Category: Standards Track B. Aboba

    W. Dixon

    Microsoft

    G. Zorn

    S. Booth

    Cisco Systems

    November 2001

Securing L2TP using IPsec

Status of this Memo

    This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please 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 Reserved.

Abstract

    This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.

Table of Contents

    1. Introduction .................................................. 2 1.1 Terminology .................................................. 3 1.2 Requirements language ........................................ 3 2. L2TP security requirements ................................... 4 2.1 L2TP security protocol ....................................... 5 2.2 Stateless compression and encryption ......................... 5 3. L2TP/IPsec inter-operability guidelines ....................... 6 3.1. L2TP tunnel and Phase 1 and 2 SA teardown ................... 6 3.2. Fragmentation Issues ........................................ 6 3.3. Per-packet security checks .................................. 7 4. IPsec Filtering details when protecting L2TP .................. 7

    4.1. IKE Phase 1 Negotiations .................................... 8 4.2. IKE Phase 2 Negotiations .................................... 8 5. Security Considerations ....................................... 15 5.1 Authentication issues ........................................ 15 5.2 IPsec and PPP interactions ................................... 18 6. References .................................................... 21 Acknowledgments .................................................. 22 Authors' Addresses ............................................... 23 Appendix A: Example IPsec Filter sets ............................ 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 used to mutually authenticate the tunnel endpoints. However, L2TP does not define tunnel protection mechanisms.

    IPsec is a protocol suite which is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security Architecture document [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 document proposes use of the IPsec protocol suite for protecting L2TP traffic over IP networks, and discusses how IPsec and L2TP should be used together. This document does not attempt to

    standardize end-to-end security. When end-to-end security is required, it is recommended that additional security mechanisms (such as IPsec or TLS [14]) be used inside the tunnel, in addition to L2TP tunnel security.

    Although L2TP does not mandate the use of IP/UDP for its transport mechanism, the scope of this document is limited to L2TP over IP networks. The exact mechanisms for enabling security for non-IP networks must be addressed in appropriate standards for L2TP over specific non-IP networks.

1.1. Terminology

Voluntary Tunneling

    In voluntary tunneling, a tunnel is created by the user, typically via use of a tunneling client. As a result, the client will send 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 case 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 action from the client and without allowing the client any choice. As a result, the client 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.

    Initiator The initiator can be the LAC or the LNS and is the device which sends 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

    In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].

2. 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 vulnerable to attack. Examples of attacks include:

    [1] An adversary may try to discover user 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 service 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 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 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 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 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 security solution, and in addition does not assist in securing L2TP control channel.

    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 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

    security, in order to protect against them, the client SHOULD provide for confidentiality, authentication, replay and integrity protection for PPP packets sent 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 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.

    To meet the above requirements, all L2TP security compliant implementations MUST implement IPsec ESP for securing both L2TP control and data packets. Transport mode MUST be supported; tunnel mode MAY be supported. All the IPsec-mandated ciphersuites (described in RFC2406 [4] and RFC2402 [3]), including NULL encryption MUST be supported. Note that although an implementation MUST support all IPsec ciphersuites, it is an operator choice which ones will be used. If confidentiality is not required (e.g., L2TP data traffic), ESP with NULL encryption may be used. The implementations 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].

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, use of stateful compression/encryption is feasible, but when run over IP, this is not desirable. While providing better compression, when used without an underlying reliable delivery mechanism, stateful methods magnify packet losses. As a result, they are problematic when used over the Internet where packet loss can be significant. Although L2TP [1] is connection oriented, packet ordering is not mandatory,

    which can create difficulties in implementation of stateful compression/encryption schemes. These considerations are not as important when L2TP is run over non-IP media such as IEEE 802, ATM,

    X.25, or Frame Relay, since these media guarantee ordering, and packet losses are typically low.

3. L2TP/IPsec inter-operability guidelines

    The following guidelines are established to meet L2TP security requirements using IPsec in practical situations.

3.1. L2TP tunnel and Phase 1 and 2 SA teardown

    Mechanisms within PPP and L2TP provide for both graceful and non- graceful teardown. In the case of PPP, an LCP TermReq and TermAck sequence 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 close, the control connection teardown mechanism defined in [1] must be used. Once the L2TP tunnel is deleted by either peer, any phase 1 and phase 2 SA's which still exist as a result of the L2TP tunnel between the peers SHOULD be deleted. Phase 1 and phase 2 delete messages SHOULD be sent when this occurs.

    When IKE receives a phase 1 or phase 2 delete message, IKE should notify L2TP this event has occurred. If the L2TP state is such that a ZLB ack has been sent in response 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 IPsec headers to a PPP frame. One mechanism which can be used to reduce this problem is to provide PPP with the MTU value of the ingress/egress interface of the L2TP/IPsec tunnel minus the overhead of the extra headers. This should occur after the L2TP tunnel has been setup 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 used. This value may also be used as the initial value proposed for the MRU in the LCP config req.

    If an ICMP PMTU is received by IPsec, this value should be stored in the SA as proposed in [6]. IPsec 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 seen at the PPP interface should be checked against this new value and processed accordingly.

3.3. Per-packet security checks

    When a packet arrives from a tunnel which requires security, L2TP MUST:

    [1] Check to ensure that the packet was decrypted and/or authenticated by IPsec. Since IPsec already verifies that the packet arrived in the correct SA, L2TP can be assured that the packet was indeed sent by a trusted peer and that it did not arrive in the clear.

    [2] Verify that the IP addresses and UDP port values in the packet match the socket information which was used to setup the L2TP tunnel. This step prevents malicious peers from spoofing packets into other tunnels.

4. IPsec Filtering details when protecting L2TP

    Since IKE/IPsec is agnostic about the nuances of the application it is protecting, typically no integration is necessary between the application and the IPsec protocol. However, protocols which allow the port number to float during the protocol negotiations (such as L2TP), can cause problems within the current IKE framework. The L2TP specification [1] states that implementations MAY use a dynamically assigned UDP source port. This port change is reflected in the SCCRP sent from the responder to the initiator.

    Although the current L2TP specification allows the responder to use a new IP address when sending the SCCRP, implementations requiring protection of L2TP via IPsec SHOULD NOT do this. To allow for this behavior when using L2TP and IPsec, when the responder chooses a new IP address it MUST send a StopCCN to the initiator, with the Result and Error Code AVP present. The Result Code MUST be set to 2 (General Error) and the Error Code SHOULD be set to 7 (Try Another). If the Error Code is set to 7, then the optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) that the Responder desires to use for subsequent

    communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC2373 [17] format for IPv6. The initiator MUST parse the result and error code information and send a new SCCRQ

    to the new IP address contained in the error message. This approach reduces complexity since now the initiator always knows precisely the IP address of its peer. This also allows a controlled mechanism for L2TP to tie IPsec filters and policy to the same peer.

    The filtering details required to accommodate this behavior as well as other mechanisms needed to protect L2TP with IPsec are discussed in the following sections.

4.1. IKE Phase 1 Negotiations

    Per IKE [7], when using pre-shared key authentication, a key must be present for each peer to which secure communication is required. When using Main Mode (which provides identity protection), this key must correspond to the IP address for the peer. When using Aggressive Mode (which does not provide identity protection), the pre-shared key must map to one of the valid id types defined in the IPsec DOI [5].

    If the initiator receives a StopCCN with the result and error code AVP set to "try another" and a valid IP address is present in the message, it MAY bind the original pre-shared key used by IKE to the new IP address contained in the error-message.

    One may may wish to consider the implications for scalability of using pre-shared keys as the authentication method for phase 1. As the number of LAC and LNS endpoints grow, pre-shared keys become increasingly difficult to manage. Whenever possible, authentication with certificates is preferred.

4.2. IKE Phase 2 Negotiations

    During the IKE phase 2 negotiations, the peers agree on what traffic is to be protected by the IPsec protocols. The quick mode IDs represent the traffic which the peers agree to protect and are comprised of address space, protocol, and port information.

    When securing L2TP with IPsec, the following cases must be considered:

Cases:

    +--------------------------------------------------+ | Initiator Port | Responder Addr | Responder Port | +--------------------------------------------------+ | 1701 | Fixed | 1701 |

    +--------------------------------------------------+ | 1701 | Fixed | Dynamic |

    +--------------------------------------------------+ | 1701 | Dynamic | 1701 |

    +--------------------------------------------------+ | 1701 | Dynamic | Dynamic |

    +--------------------------------------------------+ | Dynamic | Fixed | 1701 |

    +--------------------------------------------------+ | Dynamic | Fixed | Dynamic |

    +--------------------------------------------------+ | Dynamic | Dynamic | 1701 |

    +--------------------------------------------------+ | Dynamic | Dynamic | Dynamic |

    +--------------------------------------------------+

    By solving the most general case of the above permutations, all cases are covered. The most general case is the last one in the list. This scenario is when the initiator chooses a new port number and the responder chooses a new address and port number. The L2TP message flow which occurs to setup this sequence is as follows:

    -> IKE Phase 1 and Phase 2 to protect Initial SCCRQ

    SCCRQ -> (Fixed IP address, Dynamic Initiator Port) <- STOPCCN (Responder chooses new IP address)

    -> New IKE Phase 1 and Phase 2 to protect new SCCRQ

SCCRQ -> (SCCRQ to Responder's new IP address)

    <- New IKE Phase 2 to for port number change by the responder

<- SCCRP (Responder chooses new port number)

    SCCCN -> (L2TP Tunnel Establishment completes)

    Although the Initiator and Responder typically do not dynamically

    change ports, L2TP security must accommodate emerging applications such as load balancing and QoS. This may require that the port and IP address float during L2TP tunnel establishment.

    To support the general case, mechanisms must be designed into L2TP and IPsec which allow L2TP to inject filters into the IPsec filter database. This technique may be used by any application which floats ports and requires security via IPsec, and is described in the following sections.

    The responder is not required to support the ability to float its IP address and port. However, the initiator MUST allow the responder to float its port and SHOULD allow the responder to choose a new IP address (see section 4.2.3, below).

    Appendix A provides examples of these cases using the process described below.

    4.2.1. Terminology definitions used for filtering statements

I-Port The UDP port number the Initiator chooses to

    originate/receive L2TP traffic on. This can be a static port such as 1701 or an ephemeral one assigned by the socket.

R-Port The UDP port number the Responder chooses to

    originate/receive L2TP traffic on. This can be the port number 1701 or an ephemeral one assigned by the socket. This is the port number the Responder uses after

    receiving the initial SCCRQ.

    R-IPAddr1 The IP address the Responder listens on for initial SCCRQ. If the responder does not choose a new IP

    address, this address will be used for all subsequent L2TP traffic.

    R-IPAddr2 The IP address the Responder chooses upon receiving the SCCRQ. This address is used to send the SCCRP and all subsequent L2TP tunnel traffic is sent and received on this address.

    R-IPAddr The IP address which the responder uses for sending and receiving L2TP packets. This is either the initial value of R-IPAddr1 or a new value of R-IPAddr2.

Report this document

For any questions or suggestions please email
cust-service@docsford.com