rfc3193.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,572 行 · 第 1/5 页

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.




















Patel, et al.               Standards Track                     [Page 1]

RFC 3193               Securing L2TP using IPsec           November 2001


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






Patel, et al.               Standards Track                     [Page 2]

RFC 3193               Securing L2TP using IPsec           November 2001


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







Patel, et al.               Standards Track                     [Page 3]

RFC 3193               Securing L2TP using IPsec           November 2001


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.






Patel, et al.               Standards Track                     [Page 4]

RFC 3193               Securing L2TP using IPsec           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 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 RFC 2406 [4] and RFC 2402 [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,



Patel, et al.               Standards Track                     [Page 5]

RFC 3193               Securing L2TP using IPsec           November 2001


   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