Internet Draft

L2TPEXT Working Group                                        Baiju Patel
INTERNET-DRAFT                                                     Intel
Category: Standards Track                                  Bernard Aboba
<draft-ietf-l2tpext-security-00.txt>                       William Dixon
18 February 2000                                               Microsoft
                                                               Glen Zorn
                                                              Skip Booth
                                                           Cisco Systems

                       Securing L2TP using IPSEC


1.  Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working 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 material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

The distribution of this memo is unlimited.

2.  Copyright Notice

Copyright (C) The Internet Society (2000).  All Rights Reserved.

3.  Abstract

This document discusses how L2TP 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]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


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

5.  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 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.  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 my
      start the tunnel on demand.

   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.

   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.


6.  Introduction

L2TP, described in [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



Patel, et al.                Standards Track                    [Page 2]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


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 draft 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) 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.

7.  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. 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 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 of
control packets. It MUST be able to provide integrity and replay



Patel, et al.                Standards Track                    [Page 3]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


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 provide
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 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 user SHOULD provide for confidentiality,
authentication and integrity protection for PPP packets sent over the
dial-up link. Authentication and integrity protection are not currently
supported by PPP encryption methods, described in [11]-[13].

7.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 above requirements, all L2TP security compliant implementations
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 implementations
MUST implement replay protection mechanisms of IPSEC.




Patel, et al.                Standards Track                    [Page 4]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


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

7.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 somewhat 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/encryption
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.

8.  L2TP/IPSEC interoperability guidelines

The following guidelines are established to meet L2TP security
requirements using IPSEC in practical situations. Note that this section
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
associations, as well as to influence the IPSEC security services
negotiated.  Furthermore, it is assumed that L2TP clients and servers
are able to influence the negotiation process for PPP encryption and
compression.

8.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 packets 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.




Patel, et al.                Standards Track                    [Page 5]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


Since the LNS is capable of knowing whether confidentiality,
authentication, 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
Encryption." 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 typically
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
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
negotiate 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
typically 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
communicate with are IPSEC-capable (or if it refuses to talk to non-
IPSEC capable endstations), then it can refuse to negotiate PPP
encryption/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



Patel, et al.                Standards Track                    [Page 6]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


compression/encryption which can only be eliminated if PPP
compression/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 compression/encryption is used by offering stateless
compression/encryption methods if available in the ECP and CCP
negotiations.

8.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 encryption/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,
authentication, integrity check or replay protection is in place between
the 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 compression.
Typically the LNS will not insist that PPP encryption/compression 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 Encryption"
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 services
cannot be negotiated, it will typically be desirable to turn off PPP
compression if no stateless method is available, due to the undesirable
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,



Patel, et al.                Standards Track                    [Page 7]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


negotiating IPSEC Confidentiality, Authentication, and Integrity
protection services instead, as well as IP Compression if available.

This may result in duplicate encryption if the dial-in user is
communicating 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
association, 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 services
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 negotiate PPP
encryption and compression with the NAS. As in compulsory tunneling,
this will result in duplicate encryption and possibly compression unless
PPP compression/encryption can be turned off on a per-packet basis.

8.3.  L2TP tunnel and Phase 1 and 2 SA teardown

There are various mechanisms designed into PPP and L2TP which provide
the ability to determine both graceful and non-graceful teardown events.
In the case of PPP, an LCP TermReq and TermAck sequence corresponds to a
graceful teardown.  LCP keepalive messages and L2TP tunnel hellos
provide the capability to detect when a non-graceful teardown has
occurred.  Whenever any of these teardown events occur which cause 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.

Anytime 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 acknowledgement 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.







Patel, et al.                Standards Track                    [Page 8]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


8.4.  Fragmentation Issues

Since the default MRU for PPP connections is 1500 bytes, fragmentation
can become a concern when adding L2TP and IPSEC headers onto a PPP
packet.  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.

9.  IPSEC Filtering details when protecting L2TP

Since IKE/IPSEC is fairly agnostic about the nuances of the application
it is protecting, typically no integration is necessary between the
application and the IPSEC protocol.  However protocols such as L2TP
which allow the port number to float during the protocol negotiations
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, this behavior is not recommended
for implementations requiring protection of L2TP via IPSEC.  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 MUST be set to 7 (Try Another).  The
optional error message MUST be present and the contents MUST contain the
dotted decimal IP address (UTF-8 encoded) the Responder desires to use
for subsequent communications.  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 accomodate this behavior as well as
other mechanisms needed to protect L2TP with IPSEC are discussed in the



Patel, et al.                Standards Track                    [Page 9]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


following sections.

9.1.  IKE Phase 1 Negotiations

Per IKE [7], when using pre-shared key authentication, a key must be
present for each peer which secure communication is required.  When
using Main Mode (provides identity protection) this key must correspond
to the IP address for the peer.  When using Aggressive Mode (no 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 scalability implications of using pre-
shared keys as the authentication method for phase 1.  As the number of
LAC and LNS endpoints grow, use of pre-shared keys becomes increasingly
difficult to manage.  Whenever possible, authentication with
certificates is preferred.

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



Patel, et al.                Standards Track                   [Page 10]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


+--------------------------------------------------+
|     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 typical case in today's environment is that the Initiator
and Responder do not dynamically change ports, it is a requirement that
the L2TP Security protocol be designed such that it can accomodate
emerging applications such as load balancing and QoS issues.  Both of
these problems may require that port and IP address float during L2TP
tunnel establishment.

In order to allow for this most general case, mechanisms must be
designed into L2TP and IPSEC which allow L2TP to inject filters into the
IPSEC filter database.  Note, this same techinque may be used by any
application which floats ports and requires security via IPSEC.  This
technique is described in the following sections.

The responder is not required to support the ability to float it's IP
address and port.  However, the initiator MUST support the ability to
allow the responder to float it's port and SHOULD support the ability to
let the responder float it's IP address.

Refer to Appendix A for specific examples of these cases using the
process described below.







Patel, et al.                Standards Track                   [Page 11]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


9.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 a
      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 a 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 send and receiving
      L2TP packets.  This is either the initial value of R-IPAddr1 or a
      new value of R-IPAddr2.

   I-IPAddr

      The IP address the Initiator uses to communicate with for the L2TP
      tunnel.

   Any-Addr

      The presence of Any-Address defines that IKE should accept any
      single address proposed in the local address of the quick mode ids
      sent by the peer during IKE phase 2 negotiations.  This single
      address may be formatted as an IP Single address, an IP Netmask
      address with the Netmask set to 255.255.255.255, and IP address
      Range with the range being 1, or a hostname which can be resolved
      down to one address.  Refer to [5] for more information on the
      format for quick mode ids.



Patel, et al.                Standards Track                   [Page 12]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


   Any-Port

      The presence of Any-Port defines that IKE should accept a value of
      0 or a specific port value for the port value in the port value in
      the quick mode ids negotiated during IKE phase 2.

The filters defined in the following sections are listed from highest
priority to lowest priority.

9.2.2.  Initial filters needed to protect the SCCRQ

The initial filter set on the intiator and responder are necessary to
protect the SCCRQ sent by the initiator to open the L2TP tunnel.  Both
the initiator and the responder must either be pre-configured for these
filters or L2TP must have a method to inject this information into the
IPSEC filtering database.  In either case, this filter MUST be present
before the L2TP tunnel setup messages start to flow.

  Responder Filters:
    Outbound-1: None.  They should be be dynamically created by IKE upon
             successful completion of phase 2.

    Inbound-1:  From Any-Addr,  to R-IPAddr1, UDP, src Any-Port, dst 1701

  Initiator Filters:
    Outbound-1: From I-IPAddr,  to R-IPAddr1, UDP, src I-Port,   dst 1701

    Inbound-1:  From R-IPAddr1, to I-IPAddr,  UDP, src 1701,     dst I-Port
    Inbound-2:  From R-IPAddr1, to I-IPAddr,  UDP, src Any-Port, dst I-Port

     When the initiator uses dynamic ports, L2TP must inject the filters
     into the IPSEC filter database once its source port number is
     known.  If the initiator uses a fixed port of 1701, these filters
     MAY be statically defined.

     The Any-Port definition in the initiator's inbound-2 filter
     statement is needed to handle the potential port change which may
     occur as the result of the responder changing it's port number.

If a phase 2 SA bundle is not already present to protect the SCCRQ, the
sending of a SCCRQ by the initiator SHOULD cause IKE to setup the
necessary SAs to protect this packet.  Alternatively, L2TP may also
request IKE to setup the SA bundle.  If the SA cannot be setup for some
reason, the packet MUST be dropped.

The port numbers in the Quick Mode IDs sent by the initiator MUST
contain the specific port numbers used to identify the UDP socket.  The
port numbers would be either I-Port/1701 or 1701/1701 for the initial



Patel, et al.                Standards Track                   [Page 13]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


SCCRQ.  The quick mode ids sent by the initiator will be a subset of the
Inbound-1 filter at the responder.  As a result, the quick mode exchange
will finish and IKE should inject a specific filter set into the IPSEC
filter database and associate this filter set with the phase 2 SA
established between the peers.  These filters should persist as long as
the L2TP tunnel exists.  The new filter set at the responder will be:

  Responder Filters:
    Outbound-1: From R-IPAddr1, to I-IPAddr,  UDP, src 1701,     dst I-Port

    Inbound-1:  From I-IPAddr,  to R-IPAddr1, UDP, src I-Port,   dst 1701
    Inbound-2:  From Any-Addr,  to R-IPAddr1, UDP, src Any-Port, dst 1701

Mechanisms SHOULD exist between L2TP and IPSEC such that L2TP is not
retransmitting the SCCRQ while the SA is being established .  L2TP's
control channel retransmit mechanisms should start once the SA has been
established.  This will help avoid timeout's which may occur as the
result of slow SA establishment.

Once the phase 2 SA has been established between the peers, the SCCRQ
should be sent from the initiator to the responder.

If the responder does not choose a new IP address or a new port number,
the L2TP tunnel can now proceed to establish.

9.2.3.  Responder chooses new IP Address

This step describes the process which should be followed when the
responder chooses a new IP address.  The only opportunity for the
responder to change it's IP address is after receiving the SCCRQ but
before sending a SCCRP.

The new address the responder chooses to use MUST be reflected in the
result and error code AVP of a STOPCCN message.  The Result Code MUST be
set to 2 (General Error) and the Error Code MUST be set to 7 (Try
Another).  The optional error message MUST be present and the contents
MUST contain the dotted decimal IP address (UTF-8 encoded) the Responder
desires to use for subsequent communications.

The STOPCCN Message MUST be sent using the same address and UDP port
information which the initiator used to send the SCCRQ.  This message
will be protecting using the initial SA bundle setup to protect the
SCCRQ.

Upon receiving the STOPCCN, the initiator MUST parse the IP address from
the Result and Error Code AVP and perform the necessary sanity checks to
verify this is a correctly formatted address.  If no errors are found
L2TP should inject a new set of filters into the IPSEC filter database.



Patel, et al.                Standards Track                   [Page 14]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


If using pre-shared key authentication, L2TP MAY request IKE to bind the
new IP address to the pre-shared key which was used for the original IP
address.

Since the IP address of the responder changed, a new phase 1 and phase 2
SA must be established between the peers before the new SCCRQ is sent.

Assuming the initial tunnel has been torn down and the filters needed to
create the tunnel removed, the new filters for the initiator and
responder will be:

  Initiator Filters:
    Outbound-1: From I-IPAddr,  to R-IPAddr2, UDP, src I-Port,   dst 1701

    Inbound-1:  From R-IPAddr2, to I-IPAddr,  UDP, src 1701,     dst I-Port
    Inbound-2:  From R-IPAddr2, to I-IPAddr,  UDP, src Any-Port, dst I-Port

Once IKE phase 2 completes, the new filter set at the responder will be:

  Responder Filters:
    Outbound-1: From R-IPAddr2, to I-IPAddr,  UDP, src 1701,     dst I-Port

    Inbound-1:  From I-IPAddr,  to R-IPAddr2, UDP, src I-Port,   dst 1701
    Inbound-2:  From Any-Addr,  to R-IPAddr1, UDP, src Any-Port, dst 1701

If the responder chooses not to move to a new port number, the L2TP
tunnel setup can now complete.

9.2.4.  Responder chooses new Port Number

The responder MAY choose a new UDP source port to use for L2TP tunnel
traffic.  This decision MUST be made before sending the SCCRP.  If a new
port number is chosen, then L2TP must inject new filters into the IPSEC
filter database.  The responder must start new IKE phase 2 negotiations
with the initiator.

The final filter set at the initiator and responder is as follows.

  Initiator Filters:
    Outbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port,   dst R-Port
    Outbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port,   dst 1701

    Inbound-1:  From R-IPAddr, to I-IPAddr, UDP, src R-Port,   dst I-Port
    Inbound-2:  From R-IPAddr, to I-IPAddr, UDP, src 1701,     dst I-Port
    Inbound-3:  From R-IPAddr, to I-IPAddr, UDP, src Any-Port, dst I-Port

     The Inbound-1 filter for the initiator will be injected by IKE upon
     successful completetion of the phase 2 negotiations initiated by



Patel, et al.                Standards Track                   [Page 15]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


     the peer.

  Responder Filters:
    Outbound-1: From R-IPAddr, to I-IPAddr,  UDP, src R-Port,   dst I-Port
    Outbound-2: From R-IPAddr, to I-IPAddr,  UDP, src 1701,     dst I-Port

    Inbound-1:  From I-IPAddr, to R-IPAddr,  UDP, src I-Port,   dst R-Port
    Inbound-2:  From I-IPAddr, to R-IPAddr,  UDP, src I-Port,   dst 1701
    Inbound-3:  From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701

Once the negotiations have completed, the SCCRP is sent and the L2TP
tunnel can complete establishment.  After the L2TP tunnel has been
established, any residual SAs and their associated filters may be
deleted.

9.2.5.  Gateway-gateway and L2TP Dial-out considerations

In the gateway-gateway or the L2TP dial-out scenario, either side may
initiate the L2TP.  The process outlined in the previous steps should be
followed with one addition.  The initial filter set at both sides MUST
include the following filter:

  Inbound Filter:
    1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701

When either peer decides to start a tunnel, L2TP should inject the
necessary inbound and outbound filters to protect the SCCRQ.  Tunnel
establishment then proceeds exactly as stated in the previous sections.

10.  Security considerations

IPSEC IKE negotiation MUST negotiate an authentication method specified
in the IKE RFC 2409 [7].

When X.509 certificate authentication is chosen, the LNS is expected to
use an IKE Certificate Request Payload (CRP) to request from the client
a certificate issued by a particular certificate authority or may use
several CRPs if several certificate authorities are trusted and
configured in its IPSEC IKE authentication policy.  The certificate
credentials provided by the L2TP client during the IKE negotiation MAY
be those of the machine or of the L2TP user.  When the L2TP user
certificate is used, the client MUST ensure that only traffic from that
particular user is sent down the L2TP tunnel.

The LNS SHOULD be able to trust several certificate authorities in order
to allow tunnel client end-points to connect to it using their own
certificate credential from their chosen PKI.  Client and server side
certificate revocation list checking MAY be enabled on a per-CA basis,



Patel, et al.                Standards Track                   [Page 16]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


since differences in revocation list checking exist between different
PKI providers.

L2TP implementations MAY use dynamically assigned ports for both source
and destination ports only if security for each source and destination
port combinations can be successfully negotiated by IKE.

A single preshared key for all IKE authentication to an LNS SHOULD NOT
be used.  IKE pre-shared authentication key values SHOULD be protected
in a manner similar to the user's account password used by L2TP.

11.  Acknowledgements

Thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay
Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco for
many useful discussions of this problem space.

12.  References


[1]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and
     Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August
     1999.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[3]  Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402,
     November 1998.

[4]  Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)",
     RFC 2406, November 1998.

[5]  Piper, D., "The Internet IP Security Domain of Interpretation of
     ISAKMP", RFC 2407, November 1998.

[6]  Atkinson, R., Kent, S., "Security Architecture for the Internet
     Protocol", RFC 2401, November 1998.

[7]  Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
     2409, November 1998.

[8]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
     RFC 1661, July 1994.

[9]  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962,
     June 1996.




Patel, et al.                Standards Track                   [Page 17]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968,
     June 1996.

[11] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol (DESE)",
     RFC 1969, June 1996.

[12] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2
     (DESE-bis)", RFC 2419, September 1998.

[13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC
     2420, September 1998.

13.  Authors' Addresses

Baiju V. Patel
Intel Corp
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

William Dixon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-703-8729
EMail: wdixon@microsoft.com

Glen Zorn
Redmond, WA

EMail: gwz@acm.org

Skip Booth
Cisco Systems
7025 Kit Creek Road
RTP, NC 27709




Patel, et al.                Standards Track                   [Page 18]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


Phone: 919-392-6951
EMail: ebooth@cisco.com


Appendix A: Examples IPSEC Filter sets for L2TP Tunnel Establishment

A.1 Initiator and Responder use fixed addresses and ports

This is the most simple of the cases since nothing changes during L2TP
tunnel establishment.  Since the initiator does not know whether the
responder will change it's port number, it still must be prepared for
this case.  In this example, the initiator will use an IP address of
1.1.1.1 and the responder will use an IP address of 2.2.2.1.

The filters for this scenario are:

A.1.1 Protect the SCCRQ

Initiator Filters:
    Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701,     dst 1701

    Inbound-1:  From 2.2.2.1, to 1.1.1.1, UDP, src 1701,     dst 1701
    Inbound-2:  From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701

  Responder Filters:
    Outbound-1: None, dynamically injected when IKE Phase 2 completes

    Inbound-1:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

After IKE Phase 2 completes the filters at the initiator and responder
will be:

  Initiator Filters:
    Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701,     dst 1701

    Inbound-1:  From 2.2.2.1, to 1.1.1.1, UDP, src 1701,     dst 1701
    Inbound-2:  From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701

  Responder Filters:
    Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 1701

    Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 1701,     dst 1701
    Inbound-2:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701


A.2 Gateway to Gateway Scenario where Initiator and Responder use
dynamic ports




Patel, et al.                Standards Track                   [Page 19]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


In this scenario either side is allowed to initiate the tunnel.  Since
dynamic ports will be used, an extra phase 2 negotiation must occur to
protect the SCCRP sent from the responder to the initiator.  Other than
the additional phase 2 setup, the only other difference is that L2TP on
the responder must inject an additional filter into the IPSEC database
once the new port number is chosen.

This example also shows the additional filter needed by the initiator
which allows either side to start the tunnel.  In either the dial-out or
the gateway to gateway scenario this additional filter is required.

For this example, assume the dynamic port given to the initiator is 5000
and his IP address is 1.1.1.1.  The responder will use an IP address of
2.2.2.1 and a port number of 6000.

The filters for this scenario are:

A.2.1 Initial Filters to allow either side to respond to negotiations

In this case both peers must be able to accept phase 2 negotiations to
from L2TP peers.  My-IPAddr is defined as whatever IP address the device
is willing to accept L2TP negotiations on.

  Responder Filters present at both peers:
    Inbound-1: From Any-Addr, to My-IPAddr, UDP, src Any-Port, dst 1701

A.2.2 Protect the SCCRQ, one peer is now the intiator

  Initiator Filters:
    Outbound-1: From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701

    Inbound-1:  From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000
    Inbound-2:  From 2.2.2.1,  to 1.1.1.1, UDP, src Any-Port, dst 5000
    Inbound-3:  From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701

  Responder Filters:
    Outbound-1: None, dynamically injected when IKE Phase 2 completes

    Inbound-1:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

After IKE Phase 2 completes the filters at the initiator and responder
will be:

  Initiator Filters:
    Outbound-1: From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701

    Inbound-1:  From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000
    Inbound-2:  From 2.2.2.1,  to 1.1.1.1, UDP, src Any-Port, dst 5000



Patel, et al.                Standards Track                   [Page 20]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


    Inbound-3:  From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701

  Responder Filters:
    Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000

    Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701
    Inbound-2:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

A.2.3 Protect the SCCRP after port change

At this point the responder knows which port number it is going to use.
New filters should be injected by L2TP to reflect this new port
assignment.

The new filter set at the responder is:

  Responder Filters:
    Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 6000,     dst 5000
    Outbound-2: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000

    Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 6000
    Inbound-2:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701
    Inbound-3:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

The second phase 2 will start once L2TP sends the SCCRP.  Once the phase
2 negotiations complete, the new filter set at the initiator and the
responder will be:

  Initiator Filters:
    Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000,     dst 6000
    Outbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000,     dst 1701

    Inbound-1:  From 2.2.2.1, to 1.1.1.1, UDP, src 6000,     dst 5000
    Inbound-2:  From 2.2.2.1, to 1.1.1.1, UDP, src 1701,     dst 5000
    Inbound-3:  From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701

  Responder Filters:
    Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 6000,     dst 5000
    Outbound-2: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000

    Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 6000
    Inbound-2:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701
    Inbound-3:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

Once the L2TP tunnel has been successfully established, the original
phase 2 may be deleted.  This allows the Inbound-2 and Outbound-2 filter
statements to be removed as well.




Patel, et al.                Standards Track                   [Page 21]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


14.  Intellectual Property Statement

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


15.  Full Copyright Statement

Copyright (C) The Internet Society (2000).  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 implmentation 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."





Patel, et al.                Standards Track                   [Page 22]

INTERNET-DRAFT         Securing L2TP Using IPSEC        18 February 2000


16.  Expiration Date

This memo is filed as <draft-ietf-l2tpext-security-00.txt>, and expires
August 1, 2000.















































Patel, et al.                Standards Track                   [Page 23]