As per Relevance of the word tunneling, we have this rfc below:
Network Working Group B.
Request for Comments: 2809
Category: Informational G.
April 2000
Implementation of L2TP Compulsory Tunneling via
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document discusses implementation issues arising in
provisioning of compulsory tunneling in dial-up networks using
L2TP protocol. This provisioning can be accomplished via
integration of RADIUS and tunneling protocols. Implementation
encountered with other tunneling protocols are left to
documents
1.
Voluntary
In voluntary tunneling, a tunnel is created by the user
typically via use of a tunneling client
Compulsory
In compulsory tunneling, a tunnel is created without
action from the user and without allowing the user
choice
Tunnel Network
This is a server which terminates a tunnel. In L2
terminology, this is known as the L2TP Network
(LNS).
Aboba & Zorn Informational [Page 1]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
Network Access
The Network Access Server (NAS) is the device that
contact in order to get access to the network. In L2
terminology, a NAS performing compulsory tunneling
referred to as the L2TP Access Concentrator (LAC).
RADIUS authentication
This is a server which provides
authentication/authorization via the protocol described
[1].
RADIUS
In order to provide for the routing of
authentication requests, a RADIUS proxy can be employed
To the NAS, the RADIUS proxy appears to act as a
server, and to the RADIUS server, the proxy appears to
as a RADIUS client. Can be used to locate the
endpoint when realm-based tunneling is used
2. Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted
described in [4].
3.
Many applications of tunneling protocols involve dial-up
access. Some, such as the provisioning of secure access to
intranets via the Internet, are characterized by voluntary tunneling
the tunnel is created at the request of the user for a
purpose. Other applications involve compulsory tunneling: the
is created without any action from the user and without allowing
user any choice
Examples of applications that might be implemented using
tunnels are Internet software upgrade servers, software
servers and banking services. These are all services which,
compulsory tunneling, would probably be provided using
networks or at least dedicated network access servers (NAS),
they are characterized by the need to limit user access to
hosts
Given the existence of widespread support for compulsory tunneling
however, these types of services could be accessed via any
service provider (ISP). The most popular means of authorizing dial
up network users today is through the RADIUS protocol. The use
RADIUS allows the dial-up users' authorization and
Aboba & Zorn Informational [Page 2]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
data to be maintained in a central location, rather than on each NAS
It makes sense to use RADIUS to centrally administer
tunneling, since RADIUS is widely deployed and was designed to
this type of information. New RADIUS attributes are needed to
the tunneling information from the RADIUS server to the NAS.
attributes are defined in [3].
3.1. Advantages of RADIUS-based compulsory
Current proposals for routing of tunnel requests include
tunneling, where all users are automatically tunneled to a
endpoint, and realm-based tunneling, where the tunnel endpoint
determined from the realm portion of the userID. User-based
as provided by integration of RADIUS and tunnel protocols
significant advantages over both of these approaches
Static tunneling requires dedication of a NAS device to the purpose
In the case of an ISP, this is undesirable because it requires
to dedicate a NAS to tunneling service for a given customer,
than allowing them to use existing NASes deployed in the field. As
result static tunneling is likely to be costly for deployment of
global service
Realm-based tunneling assumes that all users within a given
wish to be treated the same way. This limits flexibility in
management. For example, BIGCO may desire to provide Janet with
account that allows access to both the Internet and the intranet
with Janet's intranet access provided by a tunnel server located
the engineering department. However BIGCO may desire to provide
with an account that provides only access to the intranet,
Fred's intranet access provided by a tunnel network server located
the sales department. Such a situation cannot be accommodated
realm-based tunneling, but can be accommodated via user-
tunneling as enabled by the attributes defined in [3].
4. Authentication
RADIUS-based compulsory tunneling can support both
authentication, where the user is authenticated at the NAS or
server, or dual authentication, where the user is authenticated
both the NAS and the tunnel server. When single authentication
supported, a variety of modes are possible, including telephone
number based authentication. When dual-authentication is used,
number of modes are available, including dual CHAP authentications
Aboba & Zorn Informational [Page 3]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/
authentication, using the same EAP type for both authentications.
is described in [5].
The alternatives are described in more detail below
4.1. Single
Single authentication alternatives include
NAS
NAS authentication with RADIUS reply
Tunnel server
4.1.1. NAS
With this approach, authentication and authorization (
tunneling information) occurs once, at the NAS. The advantages
this approach are that it disallows network access for
NAS users, and permits accounting to done at the NAS.
are that it requires that the tunnel server trust the NAS, since
user authentication occurs at the tunnel server. Due to the lack
user authentication, accounting cannot take place at the
server with strong assurance that the correct party is being billed
NAS-only authentication is most typically employed along with
forwarding and tunnel authentication, both of which are supported
L2TP, described in [2]. Thus, the tunnel server can be set up
accept all calls occurring within authenticated tunnels,
requiring PPP authentication. However, this approach is
compatible with roaming, since the tunnel server will typically
be set up to accept tunnels from a restricted set of NASes. A
initiation sequence looks like this
Client and NAS: Call
Client and NAS: PPP LCP
Client and NAS: PPP
NAS to RADIUS Server: RADIUS Access-
RADIUS server to NAS: RADIUS Access-Accept/Access-
NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP
Tunnel Server to NAS: L2TP Incoming-Call-
NAS to Tunnel Server: L2TP Incoming-Call-
Client and Tunnel Server: NCP
Aboba & Zorn Informational [Page 4]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
The process begins with an incoming call to the NAS, and the PPP
negotiation between the client and the NAS. In order to
the client, the NAS will send a RADIUS Access-Request to the
server and will receive a RADIUS Access-Accept including
attributes, or an Access-Reject
In the case where an L2TP tunnel is indicated, the NAS will now
up a control connection if none existed before, and the NAS
tunnel server will bring up the call. At this point, data will
to flow through the tunnel. The NAS will typically employ
forwarding, although it is also possible for the tunnel server
renegotiate LCP. If LCP renegotiation is to be permitted, the
SHOULD NOT send an LCP CONFACK completing LCP negotiation.
than sending an LCP CONFACK, the NAS will instead send an
Configure-Request packet, described in [6]. The Client MAY
renegotiate LCP, and from that point forward, all PPP
originated from the client will be encapsulated and sent to
tunnel server
Since address assignment will occur at the tunnel server, the
and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation
occur between the client and the tunnel server
4.1.2. NAS authentication with RADIUS reply
With this approach, authentication and authorization occurs once
the NAS and the RADIUS reply is forwarded to the tunnel server.
approach disallows network access for unauthorized NAS users;
not require trust between the NAS and tunnel server; and allows
accounting to be done at both ends of the tunnel. However, it
requires that both ends share the same secret with the RADIUS server
since that is the only way that the tunnel server can check
RADIUS Access-Reply
In this approach, the tunnel server will share secrets with all
NASes and associated RADIUS servers, and there is no provision
LCP renegotiation by the tunnel server. Also, the tunnel server
need to know how to handle and verify RADIUS Access-Accept messages
While this scheme can be workable if the reply comes directly from
RADIUS server, it would become unmanageable if a RADIUS proxy
involved, since the reply would be authenticated using the
shared by the client and proxy, rather than the RADIUS server. As
result, this scheme is impractical
Aboba & Zorn Informational [Page 5]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
4.1.2.1. Tunnel server
In this scheme, authentication and authorization occurs once at
tunnel server. This requires that the NAS determine that the
needs to be tunneled (through RADIUS or NAS configuration).
RADIUS is used, the determination can be made using one of
following methods
Telephone-number based
4.1.2.2. Telephone-number based
Using the Calling-Station-Id and Called-Station-Id RADIUS attributes
authorization and subsequent tunnel attributes can be based on
phone number originating the call, or the number being called.
allows the RADIUS server to authorize users based on the
phone number or to provide tunnel attributes based on the Calling
Station-Id or Called-Station-Id. Similarly, in L2TP the
server MAY choose to reject or accept the call based on the
Number and Dialing Number included in the L2TP Incoming-Call-
packet sent by the NAS. Accounting can also take place based on
Calling-Station-Id and Called-Station-Id
RADIUS as defined in [1] requires that an Access-Request
contain a User-Name attribute as well as either a CHAP-Password
User-Password attribute, which must be non-empty. To satisfy
requirement the Called-Station-Id or Calling-Station-Id MAY
furnished in the User-Name attribute and a dummy value MAY be used
the User-Password or CHAP-Password attribute
In the case of telephone-number based authentication, a
initiation sequence looks like this
Client and NS: Call
NAS to RADIUS Server: RADIUS Access-
RADIUS server to NAS: RADIUS Access-Accept/Access-
NAS to Tunnel Server: L2TP Incoming-Call-
Tunnel Server to NAS: L2TP Incoming-Call-
NAS to Tunnel Server: L2TP Incoming-Call-
Client and Tunnel Server: PPP LCP
Client and Tunnel Server: PPP
Tunnel Server to RADIUS Server: RADIUS Access-request (optional
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-
Client and Tunnel Server: NCP
Aboba & Zorn Informational [Page 6]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
The process begins with an incoming call to the NAS. If
for telephone-number based authentication, the NAS sends a
Access-Request containing the Calling-Station-Id and the Called
Station-Id attributes. The RADIUS server will then respond with
RADIUS Access-Accept or Access-Reject
The NAS MUST NOT begin PPP authentication before bringing up
tunnel. If timing permits, the NAS MAY bring up the tunnel prior
beginning LCP negotiation with the peer. If this is done, then
will not need to be renegotiated between the peer and tunnel server
nor will LCP forwarding need to be employed
If the initial telephone-number based authentication is unsuccessful
the RADIUS server sends a RADIUS Access-Reject. In this case, the
MUST send an LCP-Terminate and disconnect the user
In the case where tunnel attributes are included in the
Access-Accept, and an L2TP tunnel is indicated, the NAS will
bring up a control connection if none existed before. This
accomplished by sending an L2TP Start-Control-Connection-
message to the tunnel server. The tunnel server will then reply
an L2TP Start-Control-Connection-Reply. If this message indicates
error, or if the control connection is terminated at any future time
then the NAS MUST send an LCP-Terminate and disconnect the user
The NAS will then send an L2TP Incoming-Call-Request message to
tunnel server. Among other things, this message will contain the
Serial Number, which along with the NAS-IP-Address and Tunnel
Server-Endpoint is used to uniquely identify the call. The
server will reply with an L2TP Incoming-Call-Reply message. If
message indicates an error, then the NAS MUST send an LCP-
and disconnect the user. If no error is indicated, the NAS
replies with an L2TP Incoming-Call-Connected message
At this point, data can begin to flow through the tunnel. If
negotiation had been begun between the NAS and the client, then
forwarding may be employed, or the client and tunnel server will
renegotiate LCP and begin PPP authentication. Otherwise, the
and tunnel server will negotiate LCP for the first time, and
move on to PPP authentication
If a renegotiation is required, at the time that the
begins, the NAS SHOULD NOT have sent an LCP CONFACK completing
negotiation, and the client and NAS MUST NOT have begun
negotiation. Rather than sending an LCP CONFACK, the NAS
instead send an LCP Configure-Request Packet, described in [6].
Client MAY then renegotiate LCP, and from that point forward, all
packets originated from the client will be encapsulated and sent
Aboba & Zorn Informational [Page 7]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
the tunnel server. When LCP re-negotiation has been concluded,
NCP phase will begin, and the tunnel server will assign an address
the client
If L2TP is being used as the tunnel protocol, and LCP
is required, the NAS MAY in its initial setup notification include
copy of the LCP CONFACKs sent in each direction which completed
negotiation. The tunnel server MAY then use this information to
an additional LCP negotiation. With L2TP, the initial
notification can also include the authentication information
to allow the tunnel server to authenticate the user and decide
accept or decline the connection. However, in telephone-number
authentication, PPP authentication MUST NOT occur prior to the
bringing up the tunnel. As a result, L2TP authentication
MUST NOT be employed
In performing the PPP authentication, the tunnel server can
its own user database, or alternatively can send a RADIUS Access
Request. The latter approach is useful in cases where
forwarding is enabled, such as with roaming or shared use networks
In this case, the RADIUS and tunnel servers are under the
administration and are typically located close together, possibly
the same LAN. Therefore having the tunnel server act as a
client provides for unified user administration. Note that the
server's RADIUS Access-Request is typically sent directly to
local RADIUS server rather than being forwarded via a proxy
The interactions involved in initiation of a compulsory tunnel
telephone-number based authentication are summarized below. In
to simplify the diagram that follows, we have left out the client
However, it is understood that the client participates via
negotiation, authentication and subsequent data interchange with
Tunnel Server
Aboba & Zorn Informational [Page 8]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
INITIATION
NAS Tunnel Server RADIUS
--- ------------- -------------
Call
Send
Access-
with Called-Station-Id
and/or Calling-Station-
LCP
IF
Send
ELSE Send
IF NAK
IF no
connection
Start-Control-Connection-
to Tunnel
Start-Control-Connection-
to
Incoming-Call-
message to Tunnel
Send Incoming-Call-
to
Incoming-Call-
message to Tunnel
Send data through the
Re-negotiate LCP
authenticate user
bring up IPCP
start
Aboba & Zorn Informational [Page 9]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
4.1.2.3. User-
Since authentication will occur only at the tunnel-server,
initiation must occur prior to user authentication at the NAS. As
result, this scheme typically uses either the domain portion of
userID or attribute-specific processing on the RADIUS server.
the user identity is never verified by the NAS, either the
server owner must be willing to be billed for all incoming calls,
other information such as the Calling-Station-Id must be used
verify the user's identity for accounting purposes
In attribute-specific processing RADIUS may be employed and
attribute is used to signal tunnel initiation. For example,
attributes can be sent back if the User-Password attribute contains
dummy value (such as "tunnel" or "L2TP"). Alternatively, a
beginning with a special character ('*') could be used to
the need to initiate a tunnel. When attribute-specific processing
used, the tunnel server may need to renegotiate LCP
Another solution involves using the domain portion of the userID;
users in domain X would be tunneled to address Y. This
supports compulsory tunneling, but does not provide for user-
tunneling
In order for the NAS to start accounting on the connection, it
need to use the identity claimed by the user in authenticating to
tunnel server, since it did not verify the identity via RADIUS
However, in order for that to be of any use in accounting, the
endpoint needs to have an account relationship with the NAS owner
Thus even if a user has an account with the NAS owner, they
use this account for tunneling unless the tunnel endpoint also has
business relationship with the NAS owner. Thus this approach
incompatible with roaming
A typical initiation sequence involving use of the domain portion
the userID looks like this
Client and NAS: Call
Client and NAS: PPP LCP
Client and NAS:
NAS to Tunnel Server: L2TP Incoming-Call-
Tunnel Server to NAS: L2TP Incoming-Call-
NAS to Tunnel Server: L2TP Incoming-Call-
Client and Tunnel Server: PPP LCP re-
Client and Tunnel Server: PPP
Tunnel Server to RADIUS Server: RADIUS Access-request (optional
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-
Client and Tunnel Server: NCP
Aboba & Zorn Informational [Page 10]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
The process begins with an incoming call to the NAS, and the PPP
negotiation between the Client and NAS. The authentication
will then begin and based on the domain portion of the userID,
NAS will now bring up a control connection if none existed before
and the NAS and tunnel server will bring up the call. At this point
data MAY begin to flow through the tunnel. The client and
server MAY now renegotiate LCP and will complete PPP authentication
At the time that the renegotiation begins, the NAS SHOULD NOT
sent an LCP CONFACK completing LCP negotiation, and the client
NAS MUST NOT have begun NCP negotiation. Rather than sending an
CONFACK, the NAS will instead send an LCP Configure-Request packet
described in [6]. The Client MAY then renegotiate LCP, and from
point forward, all PPP packets originated from the client will
encapsulated and sent to the tunnel server. In single
compulsory tunneling, L2TP authentication forwarding MUST NOT
employed. When LCP re-negotiation has been concluded, the NCP
will begin, and the tunnel server will assign an address to
client
In performing the PPP authentication, the tunnel server can
its own user database, or it MAY send a RADIUS Access-Request.
the tunnel has been brought up, the NAS and tunnel server can
accounting
Aboba & Zorn Informational [Page 11]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
The interactions are summarized below
INITIATION
NAS Tunnel Server RADIUS
--- ------------- -------------
Call
LCP
phase
IF no
connection
Start-Control-Connection-
to Tunnel
IF no
connection
Start-Control-Connection-
to
Incoming-Call-
message to Tunnel
Send Incoming-Call-
to
Incoming-Call-
message to Tunnel
Send data through the
Re-negotiate LCP
authenticate user
bring up IPCP
start
4.2. Dual
In this scheme, authentication occurs both at the NAS and the
server. This requires the dial-up client to handle
authentication, with attendant LCP re-negotiations. In order to
the NAS and tunnel network server to authenticate against the
database, this requires RADIUS client capability on the
network server, and possibly a RADIUS proxy on the NAS end
Aboba & Zorn Informational [Page 12]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
Advantages of dual authentication include support for
and accounting at both ends of the tunnel; use of a
userID/password pair via implementation of RADIUS on the
network server; no requirement for telephone-number
authentication, or attribute-specific processing on the
server
Dual authentication allows for accounting records to be generated
both the NAS and tunnel server ends, making auditing possible.
the tunnel endpoint does not need to have an account
with the NAS owner, making this approach compatible with roaming
A disadvantage of dual authentication is that unless LCP
is used, LCP will need to be renegotiated; some clients do
support it at all, and others only support only a subset of the
authentication combinations. Feasible combinations
PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP
CHAP/EAP, EAP/CHAP, and EAP/EAP. EAP is described in [5].
In the case of a dual authentication, a typical initiation
looks like this
Client and NAS: PPP LCP
Client and NAS: PPP
NAS to RADIUS Server: RADIUS Access-
RADIUS server to NAS: RADIUS Access-Accept/Access-
NAS to Tunnel Server: L2TP Incoming-Call-
Tunnel Server to NAS: L2TP Incoming-Call-
NAS to Tunnel Server: L2TP Incoming-Call-
Client and Tunnel Server: PPP LCP re-negotiation (optional
Client and Tunnel Server: PPP
Tunnel Server to RADIUS Server: RADIUS Access-request (optional
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-
Client and Tunnel Server: NCP
The process begins with an incoming call to the NAS. The client
NAS then begin LCP negotiation. Subsequently the PPP
phase starts, and the NAS sends a RADIUS Access-Request message
the RADIUS server. If the authentication is successful, the
server responds with a RADIUS Access-Accept containing
attributes
In the case where an L2TP tunnel is indicated, the NAS will now
up a control connection if none existed before, and the NAS
tunnel server will bring up the call. At this point, data MAY
to flow through the tunnel. The client and tunnel server MAY
renegotiate LCP and go through another round of PPP authentication
At the time that this renegotiation begins, the NAS SHOULD NOT
Aboba & Zorn Informational [Page 13]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
sent an LCP CONFACK completing LCP negotiation, and the client
NAS MUST NOT have begun NCP negotiation. Rather than sending an
CONFACK, the NAS will instead send an LCP Configure-Request packet
described in [6]. The Client MAY then renegotiate LCP, and from
point forward, all PPP packets originated from the client will
encapsulated and sent to the tunnel server. When LCP re-
has been concluded, the NCP phase will begin, and the tunnel
will assign an address to the client
If L2TP is being used as the tunnel protocol, the NAS MAY in
initial setup notification include a copy of the LCP CONFACKs sent
each direction which completed LCP negotiation. The tunnel server
then use this information to avoid an additional LCP negotiation
With L2TP, the initial setup notification can also include
authentication information required to allow the tunnel server
authenticate the user and decide to accept or decline the connection
However, this facility creates a vulnerability to replay attacks,
can create problems in the case where the NAS and tunnel
authenticate against different RADIUS servers. As a result,
user-based tunneling via RADIUS is implemented, L2TP
forwarding SHOULD NOT be employed
In performing the PPP authentication, the tunnel server can
its own user database, or it MAY send a RADIUS Access-Request.
the tunnel has been brought up, the NAS and tunnel server can
accounting
The interactions involved in initiation of a compulsory tunnel
dual authentication are summarized below
Aboba & Zorn Informational [Page 14]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
INITIATION
NAS Tunnel Server RADIUS
--- ------------- -------------
Call
LCP
PPP
phase
Send
Access-
with userID
authentication
IF
Send
ELSE Send
IF NAK
IF no
connection
Start-Control-Connection-
to Tunnel
Start-Control-Connection-
to
Incoming-Call-
message to Tunnel
Send Incoming-Call-
to
Incoming-Call-
message to Tunnel
Send data through the
Re-negotiate LCP
authenticate user
bring up IPCP
start
Aboba & Zorn Informational [Page 15]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
5. Termination
The tear down of a compulsory tunnel involves an interaction
the client, NAS and Tunnel Server. This interaction is
identical regardless of whether telephone-number
authentication, single authentication, or dual authentication
being used. In any of the cases, the following events occur
Tunnel Server to NAS: L2TP Call-Clear-Request (optional
NAS to Tunnel Server: L2TP Call-Disconnect-
Tunnel termination can occur due to a client request (
termination), a tunnel server request (Call-Clear-Request), or a
problem (call disconnect).
In the case of a client-requested termination, the tunnel server
terminate the PPP session. The tunnel server MUST subsequently send
Call-Clear-Request to the NAS. The NAS MUST then send a Call
Disconnect-Notify message to the tunnel server, and will
the call
The NAS MUST also respond with a Call-Disconnect-Notify message
disconnection if it receives a Call-Clear-Request from the
server without a client-requested termination
In the case of a line problem or user hangup, the NAS MUST send
Call-Disconnect-Notify to the tunnel server. Both sides will
tear down the call
The interactions involved in termination of a compulsory tunnel
summarized below. In order to simplify the diagram that follows,
have left out the client. However, it is understood that the
MAY participate via PPP termination and disconnection
Aboba & Zorn Informational [Page 16]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
TERMINATION
NAS Tunnel Server RADIUS
--- ------------- -------------
IF user
Call-Disconnect-
message to tunnel
Tear down the
stop
ELSE IF client
Call-Clear-
to the
Call-Disconnect-
message to tunnel
Disconnect the
Tear down the
stop
6. Use of distinct RADIUS
In the case that the NAS and the tunnel server are using
RADIUS servers, some interesting cases can arise in the
of compulsory tunnels
6.1. Distinct
If distinct RADIUS servers are being used, it is likely that
userID/password pairs will be required to complete the RADIUS
tunnel authentications. One pair will be used in the initial
authentication with the NAS, and the second pair will be used
authentication at the tunnel server
This has implications if the NAS attempts to forward
information to the tunnel server in the initial setup notification
Since the userID/password pair used for tunnel authentication
different from that used to authenticate against the NAS,
authentication information in this manner will cause the
authentication to fail. As a result, where user-based tunneling
RADIUS is implemented, L2TP authentication forwarding SHOULD NOT
employed
Aboba & Zorn Informational [Page 17]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
In order to provide maximum ease of use in the case where
userID/password pairs are identical, tunnel clients typically
authentication with the same userID/password pair as was used in
initial PPP negotiation. Only after this fails do they prompt
user for the second pair. Rather than putting up an error
indicating an authentication failure, it is preferable to present
dialog requesting the tunnel userID/password combination
A similar issue arises when extended authentication methods are
used, as is enabled by EAP, described in [5]. In particular,
one-time passwords or cryptographic calculators are being used
different passwords will be used for the first and
authentications. Thus the user will need to be prompted to enter
second password
6.2. Multilink PPP
It is possible for the two RADIUS servers to return different Port
Limit attributes. For example, it is conceivable that the NAS
server will only grant use of a single channel, while the
RADIUS server will grant more than one channel. In this case,
correct behavior is for the tunnel client to open a connection
another NAS in order to bring up a multilink bundle on the
server. The client MUST NOT indicate to the NAS that this
link is being brought up as part of a multilink bundle; this
only be indicated in the subsequent negotiation with the
server
It is also conceivable that the NAS RADIUS server will allow
client to bring up multiple channels, but that the tunnel
server will allow fewer channels than the NAS RADIUS server. In
case, the client should terminate use of the excess channels
7. UserID
In the provisioning of roaming and shared use networks, one of
requirements is to be able to route the authentication request to
user's home RADIUS server. This authentication routing
accomplished based on the userID submitted by the user to the NAS
the initial PPP authentication. The userID is subsequently relayed
the NAS to the RADIUS server in the User-Name attribute, as part
the RADIUS Access-Request
Similarly, [2] refers to use of the userID in determining the
endpoint, although it does not provide guidelines for how RADIUS
tunnel routing is to be accomplished. Thus the possibility
conflicting interpretations exists
Aboba & Zorn Informational [Page 18]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
The use of RADIUS in provisioning of compulsory tunneling
the userID from having to do double duty. Rather than being used
for routing of the RADIUS authentication/authorization request
well for determination of the tunnel endpoint, the userID is now
solely for routing of RADIUS authentication/authorization requests
Tunnel attributes returned in the RADIUS Access-Response are
used to determine the tunnel endpoint
Since the framework described in this document allows both ISPs
tunnel users to authenticate users as well as to account
resources consumed by them, and provides for maintenance of
distinct userID/password pairs, this scheme provides a high degree
flexibility. Where RADIUS proxies and tunneling are employed, it
possible to allow the user to authenticate with a
userID/password pair at both the NAS and the tunnel endpoint. This
accomplished by routing the NAS RADIUS Access-Request to the
RADIUS server used by the tunnel server
8.
[1] Rigney C., Rubens A., Simpson W. and S. Willens, "
Authentication Dial In User Service (RADIUS)", RFC 2138,
1997.
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
Goyret, I., "RADIUS Attributes for Tunnel Protocol Support",
Work in Progress
[4] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible
Protocol (EAP)", RFC 2284, March 1998.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, July 1994.
Aboba & Zorn Informational [Page 19]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
9. Security
In PPP-based tunneling, PPP security is negotiated between the
and the tunnel server, and covers the entire length of the path.
is because the client does not have a way to know that they are
tunneled. Thus, any security the NAS may negotiate with the
server will occur in addition to that negotiated between the
and NAS
In L2TP compulsory tunneling, this means that PPP encryption
compression will be negotiated between the client and the
server. In addition, the NAS may bring up an IPSEC
association between itself and the tunnel server. This
protection against a number of possible attacks
Where RADIUS proxies are deployed, the Access-Reply sent by
RADIUS server may be processed by one or more proxies prior to
received by the NAS. In order to ensure that tunnel
arrive without modification, intermediate RADIUS proxies
the Access-Reply MUST NOT modify tunnel attributes. If the
proxy does not support tunnel attributes, then it MUST send
Access-Reject to the NAS. This is necessary to ensure that the
is only granted access if the services requested by the RADIUS
can be provided
Since RADIUS tunnel attributes are used for compulsory tunneling
address assignment is handled by the tunnel server rather than
NAS. As a result, if tunnel attributes are present, the NAS
ignore any address assignment attributes sent by the RADIUS server
In addition, the NAS and client MUST NOT begin NCP negotiation,
this could create a time window in which the client will be
of sending packets to the transport network, which is not
in compulsory tunneling
10.
Thanks to Gurdeep Singh Pall of Microsoft for many useful
of this problem space, and to Allan Rubens of Tut Systems
Bertrand Buclin of AT&T Labs Europe for their comments on
document
Most of the work on this document was performed while Glen Zorn
employed by the Microsoft Corporation
Aboba & Zorn Informational [Page 20]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
11. Chair's
The RADIUS Working Group can be contacted via the current chair
Carl
Livingston
4464 Willow
Pleasanton, California 94588
Phone: +1 510-426-0770
EMail: cdr@livingston.
12. Authors'
Bernard
Microsoft
One Microsoft
Redmond, WA 98052
Phone: +1 425-936-6605
EMail: bernarda@microsoft.
Glen
Cisco Systems, Inc
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.
Aboba & Zorn Informational [Page 21]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
13. Intellectual Property
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
Aboba & Zorn Informational [Page 22]
RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
14. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Aboba & Zorn Informational [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
