Skip to main content

Secure Remote Access with L2TP

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 2888.
Author Pyda Srisuresh
Last updated 2013-03-02 (Latest revision 2000-06-02)
RFC stream Legacy stream
Intended RFC status Informational
Stream Legacy state (None)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 2888 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
P. Srisuresh
INTERNET-DRAFT                                     Campio Communications
Category: Informational                                        June 2000
Expires on December 2, 2000                               

                   Secure Remote Access with L2TP

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

   The list of Internet-Draft Shadow Directories can be accessed at


   L2TP protocol is a virtual extension of PPP across IP network
   infrastructure. L2TP makes possible for an access concentrator(LAC)
   to be near remote clients, while allowing PPP termination server
   (LNS) to be located in enterprise premises. L2TP allows an
   enterprise to retain control of RADIUS data base, which is used
   to control Authentication, Authorization and Accountability (AAA)
   of dial-in users. The objective of this document is to extend
   security characteristics of IPsec to remote access users, as they
   dial-in through the Internet. This is accomplished without creating 
   new protocols and using the existing practices of Remote Access and
   IPsec. Specifically, the document proposes three new RADIUS 
   parameters for use by the LNS node, acting as Secure Remote Access 
   Server (SRAS) to mandate network level security between remote 
   clients and the enterprise. The document also discusses limitations 
   of the approach.

Srisuresh                                                       [Page 1]
Internet-Draft       Secure Remote Access with L2TP            June 2000

1. Introduction and Overview

   Now-a-days, it is common practice for employees to dial-in to their
   enterprise over the PSTN (Public Switched Telephone Network) and 
   perform day-to-day operations just as they would if they were in 
   corporate premises. This includes people who dial-in from their home
   and road warriors, who cannot be at the corporate premises. As the 
   Internet has become ubiquitous, it is appealing to dial-in through 
   the Internet to save on phone charges and save the dedicated voice 
   lines from being clogged with data traffic.

   The document suggests an approach by which remote access over the
   Internet could become a reality. The approach is founded on the
   well-known techniques and protocols already in place. Remote Access
   extensions based on L2TP, when combined with the security offered 
   by IPSec can make remote access over the Internet a reality. The 
   approach does not require inventing new protocol(s).

   The trust model of remote access discussed in this document is
   viewed principally from the perspective of an enterprise into which
   remote access clients dial-in. A remote access client may or may not
   want to enforce end-to-end IPsec from his/her end to the enterprise.
   However, it is in the interest of the enterprise to mandate security
   of every packet that it accepts from the Internet into the
   enterprise.  Independently, remote users may also pursue end-to-end
   IPsec, if they choose to do so. That would be in addition to the
   security requirement imposed by the enterprise edge device.

   Section 2 has reference to the terminology used throughout the
   document. Also mentioned are the limited scope in which some of these
   terms may be used in this document. Section 3 has a brief description
   of what constitutes remote access. Section 4 describes what
   constitutes network security from an enterprise perspective.
   Section 5 describes the model of secure remote access as a viable
   solution to enterprises. The solution presented in section 5 has some
   limitations. These limitations are listed in section 6.  Section 7 is
   devoted to describing new RADIUS attributes that may be configured to
   turn a NAS device into Secure Remote Access Server.

2. Terminology and scope

   Definition of terms used in this document may be found in one of 
   (a) L2TP Protocol document [Ref 1], (b) IP security Architecture 
   document [Ref 2], or (c) Internet Key Enchange (IKE) document 
   [Ref 5]. 

Srisuresh                                                       [Page 2]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   Note, the terms Network Access Server (NAS) and  Remote Access 
   Server(RAS) are used interchangeably throughout the document.
   While PPP may be used to carry a variety of network layer
   packets, the focus of this document is limited to carrying IP
   datagrams only. 
   "Secure Remote Access Server" (SRAS) defined in this document 
   refers to a NAS that supports tunnel-mode IPsec with its remote 
   clients. Specifically, LNS is the NAS that is referred. Further, 
   involuntary tunneling is assumed for L2TP tunnel setup, in that 
   remote clients initiating PPP session and the LAC that tunnels
   the PPP sessions are presumed to be distinct physical entities.

   Lastly, there are a variety of transport mediums by which to 
   tunnel PPP packets between a LAC and LNS. Examples include 
   Frame Relay or ATM cloud and IP network infrastructure. For 
   simplicity, the document assumes a public IP infrastructure as 
   the medium to transport PPP packets between LAC and LNS. 
   Security of IP packets (embedded within PPP) in a trusted 
   private transport medium is less of a concern for the purposes
   of this document. 

3. Remote Access operation

   Remote access is more than mere authentication of remote clients
   by a Network Access Server(NAS). Authentication, Authorization, 
   Accounting and routing are integral to remote access. A client
   must first pass the authentication test before being granted 
   link access to the network. Network level services (such as IP)
   are granted based on the authorization characteristics
   specificed for the user in RADIUS.  Network Access Servers use
   RADIUS to scale for large numbers of users supported. NAS also
   monitors the link status of the remote access clients.

   There are a variety of techniques by which remote access users
   are connected to their enterprise and the Internet. At a link 
   level, the access techniques include ISDN digital lines, analog 
   plain-old-telephone-service lines, xDSL lines, cable and wireless  
   to name a few. PPP is the most common Layer-2 (L2)protocol used 
   for carrying network layer packets over these remote access 
   links. PPP may be used to carry a variety of network layer 
   datagrams including IP, IPX and AppleTalk. The focus of this 
   document is however limited to IP datagrams only.

   L2TP is a logical extension of PPP over an IP infrastructure. 
   While a LAC provides termination of Layer 2 links,  LNS provides
   the logical termination of PPP. As a result, LNS becomes the 

Srisuresh                                                       [Page 3]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   focal point for (a) performing the AAA operations for the remote
   users, (b) assigning IP address and monitoring the logical
   link status (i.e., the status of LAC-to-LNS tunnel and the link 
   between remote user and LAC), and (c) maintaining host-route to
   remote user network and providing routing infrastructure into
   the enterprise.
   L2TP uses control messages to establish, terminate and monitor
   the status of the logical PPP sessions (from remote user to LNS). 
   These are independent of the data messages. L2TP data messages 
   contain an L2TP header, followed by PPP packets. The L2TP header
   identifies the PPP session (amongst other things) to which the 
   PPP packet belongs. The IP packets exchanged from/to the remote 
   user are carried within the PPP packets.  The L2TP data messages, 
   carrying end-to-end IP packets in an IP transport medium may be 
   described as follows. The exact details of L2TP protocol may be 
   found in [Ref 1]. 

   | IP Header            |
   | (LAC <->LNS)         |
   | UDP Header           |
   | L2TP Header          | 
   | (incl. PPP Sess-ID)  |
   | PPP Header           |
   | (Remote User<->LNS)  |
   | End-to-end IP packet |
   | (to/from Remote User)|

4. Requirements of an enterprise Security Gateway 

   Today's enterprises are aware of the various benefits of 
   connecting to the Internet. Internet is a vast source of 
   Information and a means to disseminate information and make 
   available certain resources to the external world. However, 
   enterprises are also aware that security breaches (by being 
   connected to the Internet) can severely jeopardize internal 

   As a result, most enterprises restrict access to a pre-defined 
   set of resources for external users. Typically, enterprises 

Srisuresh                                                       [Page 4]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   employ a firewall to restrict access to internal resources and 
   place externally accessible servers in the DeMilitarized Zone
   (DMZ), in front of the firewall, as described below in figure 1.

                            (                )   
                           (                  ) 
                          (      Internet      )
                           (                  ) 
                            (_______________ )  
                            WAN  |
                     |Enterprise Router|
                         |   DMZ - Network
                     |            |                |
                    +--+         +--+         +----------+
                    |__|         |__|         | Firewall |
                   /____\       /____\        +----------+
                   DMZ-Name     DMZ-Web  ...    |
                   Server       Server          |
                                    (                  )   
                                   (  Internal Network  ) 
                                  (   (private to the    )
                                   (   enterprise)      ) 
                                    (_________________ )  

   Figure 1: Security model of an Enterprise using Firewall

   Network Access Servers used to allow direct dial-in access 
   (through the PSTN) to employees are placed within the private 
   enterprise network so as to avoid access restrictions imposed 
   by a firewall. 

   With the above model, private resources of an enterprise are 
   restricted for access from the Internet. Firewall may be 
   configured to occasionally permit access to a certain resource 
   or service but is not recommended on an operational basis as 

Srisuresh                                                       [Page 5]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   that could constitute a security threat to the enterprise. 
   It is of interest to note that even when the firewall is 
   configured to permit access to internal resources from pre-defined
   external node(s), many internal servers, such as NFS, enforce 
   address based authentication and do not co-operate when the IP 
   address of the external node is not in corporate IP address 
   domain. In other words, with the above security model, it becomes
   very difficult to allow employees to access corporate resources,
   via the Internet, even if you are willing to forego security 
   over the Internet.

   With the advent of IPsec, it is possible to secure corporate
   data across the Internet by employing a Security Gateway within 
   the enterprise. Firewall may be configured to allow IKE and 
   IPsec packets directed to a specific  Security Gateway behind 
   the firewall. It then becomes the responsibility of the Security 
   Gateway to employ the right access list for external connections
   seeking entry into the enterprise. Essentially, the access control 
   functionality for IPsec secure packets would be shifted to the 
   Security Gateway (while the access control for clear packets is 
   retained with the firewall). The following figure illustrates the 
   model where a combination of Firewall and Security Gateway control 
   access to internal resources.

Srisuresh                                                       [Page 6]
Internet-Draft       Secure Remote Access with L2TP            June 2000

                            (            )   
                           (              ) 
                          (    Internet    )
                           (              ) 
                            (___________ )  
                            WAN  |
                     |Enterprise Router|
                         |   DMZ - Network
                 |            |                     |
                +--+         +--+              +----------+
                |__|         |__|              | Firewall |
               /____\       /____\             +----------+
               DMZ-Name     DMZ-Web   ...         |
               Server       Server etc.           | LAN
                           |                          |
                      +----------+         +------------------+
                      |   LNS    |         | Security Gateway |
                      |  Server  |         |      (SGW)       |
                      +----------+         +------------------+
                                         (                  )   
                                        (  Internal Network  ) 
                                       (   (Private to the    )
                                        (   enterprise)      ) 
                                         (_________________ )  

   Figure 2: Security Model based on Firewall and Security Gateway 

   In order to allow employee dial-in over the Internet, an LNS may 
   be placed behind a firewall, and the firewall may be configured to 
   allow UDP access to the LNS from the Internet. Note, it may not be 
   possible to know all the IP addresses of the LACs located on the 
   Internet at configuration time. Hence, the need to allow UDP access 
   from any node on the Internet. The LNS may be configured to process 
   only the L2TP packets and drop any UDP packets that are not L2TP.

Srisuresh                                                       [Page 7]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   Such a configuration allows remote access over the Internet. 
   However, the above setup is prone to a variety of security attacks
   over the Internet. It is easy for someone on the Internet to steal
   a remote access session and gain  access to precious resources of 
   the enterprise. Hence it is important that all packets are 
   preserved with IPsec to a security Gateway (SGW) behind the LNS, 
   so the Security Gateway will not allow IP packets into corporate 
   network unless it can authenticate the same. 
   The trust model of secure remote access assumes that the enterprise
   and the end user are trusted domains. Everything in between is not
   trusted. Any examination of the end-to-end packets by the nodes 
   enroute would violate this trust model. From this perspective, even
   the LAC node enroute must not be trusted with the end-to-end IP
   packets. Hence, location and operation of LAC is not relevant for 
   the discussion on security. On the other hand, location and 
   operation of LNS and the Security Gateway (SGW) are precisely the 
   basis for discussion.  

   Having security processing done on an independent Security gateway 
   has the following shortcomings.

   1. Given the trust model for remote access, the SGW must be 
      configured with a set of security profiles, access control lists 
      and IKE authentication parameters for each user. This mandates
      an independent provisioning of security parameters on a per-user
      basis. This may not be able to take advantage of the user-centric
      provisioning on RADIUS, used by the LNS node. 

   2. Unlike the LNS, SGW may not be in the routing path of remote 
      access packets. I.e., there is no guarantee that the egress IP 
      packets wil go through the chain of SGW and LNS before they are 
      delivered to remote user. As a result, packets may be subject 
      to IPSec in one direction, but not in the other. This can be a 
      significant threat to the remote access trust model.

   3. Lastly, the SGW node does not have a way to know when a remote 
      user node(s) simply died or the LAC-LNS tunnel failed. Being 
      unable to delete the SAs for users that no longer exist could 
      drain the resources of the SGW. Further, the LNS cannot even 
      communicate the user going away to the SGW because, the SGW 
      maintains its peer nodes based on IKE user ID, which could be 
      different the user IDs employed by the LNS node.

Srisuresh                                                       [Page 8]
Internet-Draft       Secure Remote Access with L2TP            June 2000

5. Secure Remote Access

   Combining the functions of IPsec Security Gateway and LNS into 
   a single system promises to offer a viable solution for secure 
   remote access. By doing this, remote access clients will use a 
   single node as both (a) PPP termination point providing NAS 
   service, and (b) the Security gateway node into the enterprise. 
   We will refer this node as "Secure Remote Access Server" (SRAS).

   The SRAS can benefit greatly from the confluence of PPP session 
   and IPsec tunnel end points. PPP session monitoring capability 
   of L2TP directly translates to being able to monitor IPsec tunnels. 
   Radius based user authorization ability could be used to configure
   the security characteristics for IPsec tunnel. This includes setting
   access control filters and security preferences specific to each 
   user. This may also be extended to configuring IKE authentication 
   and other negotiation parameters, when automated key exchange is 
   solicited. Security attributes that may be defined in Radius 
   are discussed in detail in section 7. Needless to say, the 
   centralized provisioning capability and scalability of Radius helps 
   in the configuration of IPsec. 
   As for remote access, the benefit is one of IPsec security as 
   befitting the trust model solicited by enterprises for the 
   end-to-end IP packets traversing the Internet. You may use simply AH 
   where there is no fear of external eaves-dropping, but you simply
   need to authenticate packet data, including the source of packet. 
   You may use ESP (including ESP-authentication), where there is no 
   trust of the network and you donot want to permit eaves-dropping 
   on corporate activities. 

   Operation of SRAS requires that the firewall be configured to permit 
   UDP traffic into the SRAS node. The SRAS node in turn will process
   just the L2TP packets and drop the rest. Further, the SRAS will 
   require all IP packets embedded within PPP to be one of AH and 
   ESP packets, directed to itself. In addition, the SRAS will also 
   permit IKE UDP packets (with source and destination ports sets 
   to 500) directed to itself in order to perform IKE negotiation
   and generate IPsec keys dynamically. All other IP packets embedded
   within PPP will be dropped. This enforces the security policy for
   the enterprise by permitting only the secure remote access packets 
   into the enterprise. When a PPP session is dropped, the IPsec and 
   ISAKMP SAs associated with the remote access user are dropped from 
   the SRAS. All the shortcomings listed in the previous section with
   LNS and SGW on two systems disappear withe Secure Remote Access 
   Server. Figure 3 below is a typical description of an enterprise
   supporting remote access users using SRAS system.

Srisuresh                                                       [Page 9]
Internet-Draft       Secure Remote Access with L2TP            June 2000

              Remote Access  +-------------+      (            )   
        +--+______   Link    | Local Access|     (              )
        |__|     /___________| Concentrator|----(    Internet    )
       /____\                |    (LAC)    |     (              )    
       RA-Host               +-------------+      (____________)  
                                       WAN  |
                                |Enterprise Router|
                                    |   DMZ - Network
                 |            |                     |
                +--+         +--+              +----------+
                |__|         |__|              | Firewall |
               /____\       /____\             +----------+
               DMZ-Name     DMZ-Web   ...         |
               Server       Server etc.           | LAN
                                     | Secure Remote |
                                     | Access Server |
                                     |    (SRAS)     |
                                   (                     )   
                      +--+       (    Internal Network    )
                      |__|------(     (Private to the      )
                     /____\      (     enterprise)        )
                     Ent-Host     (______________________)  

   Figure 3: Secure Remote Access Server operation in an Enterprise

   The following is an illustration of secure remote access data flow 
   as end-to-end IP packets traverse the Internet and the SRAS. The 
   example shows IP packet tunneling and IPsec transformation as
   packets are exchanged between a remote Access host (RA-Host) and a 
   host within the enterprise (say, Ent-Host).

Srisuresh                                                      [Page 10]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   Note, the IP packets originating from or directed to RA-Host are 
   shown within PPP encapsulation, whereas, all other packets are shown 
   simply as IP packets.  It is done this way to highlight the PPP 
   packets encapsulated within L2TP tunnel. The PPP headers below are 
   identified by their logical source and destination in parenthesis. 
   Note, however, the source and recipient information of the PPP data
   is not a part of PPP header. This is described thus, just for 
   clarity. In the case of an L2TP tunnel, the L2TP header carries the 
   PPP session ID, which indirectly identifies the PPP end points to the
   LAC and the LNS. Lastly, the IPsec Headers section below include the
   tunneling overhead and the AH/ESP headers that are attached to the

Srisuresh                                                      [Page 11]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   RA-Host to Ent-Host Packet traversal:

   RA-Host              LAC                   SRAS              Ent-Host

   | PPP Header           |
   | (RA-Host ->SRAS)     |
   | Tunnel-Mode IPsec    |
   | Hdr(s)(RA-Host->SRAS)|
   | End-to-end IP packet |
   | transformed as needed|
   | (RA-Host->Ent-Host)  |

                        | IP Header            |
                        | (LAC->SRAS)          |
                        | UDP Header           |
                        | L2TP Header          | 
                        | (incl. PPP Sess-ID)  |
                        | PPP Header           |
                        | (RA-Host ->SRAS)     |
                        | Tunnel-Mode IPsec    |
                        | Hdr(s)(RA-Host->SRAS)|
                        | End-to-end IP packet |
                        | transformed as needed|
                        | (RA-Host->Ent-Host)  |

                                           | End-to-end IP packet |
                                           | (RA-Host->Ent-Host)  |

Srisuresh                                                      [Page 12]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   Ent-Host to RA-Host Packet traversal:

   Ent-Host             SRAS                  LAC               RA-Host

   | End-to-end IP packet |
   | (Ent-Host->Ra-Host)  |

                        | IP Header            |
                        | (SRAS->LAC)          |
                        | UDP Header           |
                        | L2TP Header          | 
                        | (incl. PPP Sess-ID)  |
                        | PPP Header           |
                        | (SRAS->RA-Host)      |
                        | Tunnel-Mode IPsec    |
                        | Hdr(s)(SRAS->RA-Host)|
                        | End-to-end IP packet |
                        | transformed as needed|
                        | (Ent-Host->RA-Host)  |

                                          | PPP Header           |
                                          | (SRAS->RA-Host)      |
                                          | Tunnel-Mode IPsec    |
                                          | Hdr(s)(SRAS->RA-Host)|
                                          | End-to-end IP packet |
                                          | transformed as needed|
                                          | (Ent-Host->RA-Host)  |

Srisuresh                                                      [Page 13]
Internet-Draft       Secure Remote Access with L2TP            June 2000

6. Limitations to Secure Remote Access using L2TP

   The SRAS model described is not without its limitations. Below is
   a list of the limitations.
   1. Tunneling overhead: There is considerable tunneling overhead on 
      the end-to-end IP packet. Arguably, there is overlap of 
      information between tunneling headers. This overhead will 
      undercut packet throughput.
      The overhead is particularly apparent at the LAC and SRAS nodes.
      Specifically, the SRAS has the additional computational overhead 
      of IPsec processing on all IP packets exchanged with remote 
      users. This can be a significant bottleneck in the ability of 
      SRAS to scale for large numbers of remote users. 

   2. Fragmentation and reassembly: Large IP packets may be required to
      undergo Fragmentation and reassembly at the LAC or the LNS as a 
      result of multiple tunnel overhead tagged to the packet. 
      Fragmentation and reassembly can havoc on packet throughput and
      latency. However, it is possible to avoid the overhead by 
      reducing the MTU permitted within PPP frames. 

   3. Multiple identity and authentication requirement: Remote Access 
      users are required to authenticate themselves to the SRAS in 
      order to be obtain access to the link. Further, when they require 
      the use of IKE to automate IPsec key exchange, they will need to
      authenticate once again with the same or different ID and
      a distinct authentication approach. The authentication 
      requirements of IKE phase 1 [Ref 8] and LCP [Ref 3] are 
      However, it is possible to have a single authentication approach 
      (i.e., a single ID and authentication mechanism) that can be 
      shared between LCP and IKE phase 1.  The Extended Authentication 
      Protocol(EAP) [Ref 4] may be used as the base to transport IKE 
      authentication mechanism into PPP. Note, the configuration
      overhead is not a drag on the functionality perse.

   4. Weak security of Link level authentication: As LCP packets 
      traverse the Internet, the Identity of the remote user and the
      password (if a password is used) is sent in the clear. This makes
      it a target for someone on the net to steal the information and 
      masquerade as remote user. Note, however, this type of password 
      stealing will not jeopardize the security of the enterprise per 
      se, but could result in denial of service to remote users. An
      intruder can collect the password data and simply steal the 

Srisuresh                                                      [Page 14]
Internet-Draft       Secure Remote Access with L2TP            June 2000

      link, but will not be able to run any IP applications 
      subsequently, as the SRAS will fail non-IPsec packet data. 
      A better approach would be to employ Extended Authentication 
      Protocol (EAP) [Ref 4] and select an authentication technique 
      that is not prone to stealing over the Internet. Alternately, 
      the LAC and the SRAS may be independently configured to use 
      IPsec to secure all LCP traffic exchanged between themselves.

7. Configuring RADIUS to support Secure Remote Access.

   A centralized RADIUS database is used by enterprises to maintain
   the authentication and authorization requirements of the dial-in
   Users. It is also belived that direct dial-in access (e.g., through
   the PSTN network is) safe and trusted and does not need any
   scrutiny outside of the link level authentication enforced 
   in LCP. This belief is certainly not shared with the dial-in 
   access through the Internet.

   So, while the same RADIUS database may be used for a user directly 
   dialing-in or dialing in through the Internet, the security 
   requirements may vary. The following RADIUS attributes may be 
   used to mandate IPsec for the users dialing-in through the Internet.
   The exact values for the attributes and its values may be obtained
   from IANA (refer Section 10).

7.1. Security mandate based on access method

   A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each
   user. This attribute may be given one of the following values.

        NONE            (= 0)    No IPsec mandated on the IP packets
                                 embedded within PPP.

        LNS_AS_SRAS     (=1)     Mandates Tunnel mode IPsec on the IP 
                                 packets embedded within PPP, only so 
                                 long as the PPP session terminates 
                                 at an LNS. LNS would be the tunnel 
                                 mode IPsec end point.

        SRAS            (=2)     Mandates Tunnel mode IPsec on the IP
                                 packets embedded within PPP, 
                                 irrespective of the NAS type the PPP
                                 terminates in. I.e., the IPsec mandate
                                 is not specific to LNS alone, and is
                                 applicable to any NAS, terminating 
                                 PPP. NAS would be the tunnel mode 

Srisuresh                                                      [Page 15]
Internet-Draft       Secure Remote Access with L2TP            June 2000

                                 IPsec end point.

  When IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or SRAS,
  that would direct the NAS to drop any IP packets in PPP that are not
  associated with an AH or ESP protocol. As an exception, the NAS will
  continue to process IKE packets (UDP packets, with source and 
  destination port set to 500) directed from remote users. Further, the
  security profile parameter, defined in the following section may add
  additional criteria for which security is not mandatory.

7.2. Security profile for the user 

   A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to 
   describe security access requirements for the users. The profile 
   could contain information such as the access control security 
   filters, security preferences and the nature of Keys (manual or 
   automatic generated via the IKE protocol) used for security 

   The SECURITY-PROFILE attribute can be assigned a filename, as a 
   string of characters. The contents of the file could be vendor 
   specific. But, the contents should include (a) a prioritized
   list access control security policies, (b) Security Association
   security preferences associated with each security policy.

7.3. IKE negotiation profile for the user

   If the security profile of a user requires dynamicic generation of 
   security keys, the parameters necessary for IKE negotiation may be 
   configured separately using a new IKE_NEGOTIATION_PROFILE (93)
   parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be 
   assigned a filename, as a string of characters. The contents of 
   the file could however be vendor specific. The contents would 
   typically include (a) the IKE ID of the user and  SRAS, 
   (b) preferred authentication approach and the associated 
   parameters, such as a pre-shared-key or a pointer to X.509 digital
   Certificate, and, (c) ISAKMP security negotiation preferences for 
   phase I. 

8. Acknowledgements

   The author would like to express sincere thanks to Steve Willens 
   for initially suggesting this idea. The author is also thankful to 
   Steve for the many informal conversations which were instrumental 
   in the author being able to appreciate the diverse needs of the 
   Remote Access area.

Srisuresh                                                      [Page 16]
Internet-Draft       Secure Remote Access with L2TP            June 2000

9. Security Considerations 

   This document is about providing secure remote access to 
   enterprises via the Internet. However, the document does 
   not address security issues for network layers other than 
   IP. While the document focus is on security over the 
   Internet, the security model provided is not limited to the
   Internet or the IP infrastructure alone. It may also be 
   applied over other transport media such as Frame Relay and 
   ATM clouds. If the transport media is a trusted private 
   network infrastructure, the security measures described may
   not be as much of an issue. The solution suggested in the 
   document is keeping in view the trust model between a 
   remote user and enterprise.

10. IANA Considerations

   This document proposes a total of three new RADIUS attributes to 
   be maintained by the IANA. These attributes IPSEC_MANDATE,
   the values 91, 92 and 93 respectively so as not to conflict with
   the defintions for recognized radius types, as defined in
   The following sub-section explains the criteria to be used by 
   the IANA to assign additional numbers as values to the 
   IPSEC-MANDATE attribute described in section 7.1.

10.1.  IPSEC-MANDATE attribute Value

   Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in 
   Section 7.1; the remaining values [3-255] are available for 
   assignment by the IANA with IETF Consensus [Ref 11].


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

   [2] Rigney, C., Rubens, A., Simpson, W. and Willens, S.
       "Remote Authentication Dial In User Service (RADIUS)", RFC2138

   [3] Simpson, W. "The Point-to-Point Protocol (PPP)", STD 51, 
       RFC 1661

Srisuresh                                                      [Page 17]
Internet-Draft       Secure Remote Access with L2TP            June 2000

   [4] Blunk, L., and Vollbrecht, J. "PPP Extensible Authentication 
       Protocol (EAP)", RFC 2284

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

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

   [7] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402

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

   [9] D. Piper, "The Internet IP Security Domain of Interpretation 
       for ISAKMP", RFC 2407

   [10] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700.
        See also

   [11] Narten, T., Alvestrand, H., "Guidelines for writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434.

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

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

Author's Address:

   Pyda Srisuresh
   Campio Communications
   630 Alder Drive
   Milpitas, CA 95035

   Voice: +1 (408) 519-3849

Srisuresh                                                      [Page 18]