RADIUS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-radius-tunnel-imp-01.txt> Glen Zorn
7 March 1997 Microsoft Corporation
Implementation of Mandatory Tunneling via RADIUS
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-radius-tunnel-imp-01.txt> and expires September 15, 1997.
Please send comments to the authors.
2. Abstract
This document discusses implementation issues arising in the provi-
sioning of mandatory tunneling in dial-up networks using the PPTP and
L2TP protocols. This provisioning can be accomplished via the inte-
gration of RADIUS and tunneling protocols.
3. Terminology
Roaming "Roaming capability" can be loosely defined as the ability
to use any one of multiple Internet service providers
(ISPs), while maintaining a formal, customer-vendor rela-
tionship with only one. Examples of cases where roaming
capability might be required include ISP "confederations"
and ISP-provided corporate network access support.
Shared Use Network
This is an IP dialup network whose use is shared by two or
more organizations. Shared use networks typically implement
distributed authentication and accounting in order to facil-
itate the relationship among the sharing parties. Since
Aboba & Zorn [Page 1]
INTERNET-DRAFT 7 March 1997
these facilities are also required for implementation of
roaming, implementation of shared use is frequently a first
step toward development of roaming capabilities. In fact,
one of the ways by which a provider can offer roaming ser-
vice is to conclude shared use agreements with multiple net-
works. However, to date the ability to accomplish this has
been hampered by lack of interoperability among shared use
implementations.
Tunnel Network Server
This is a server which terminates a tunnel. In PPTP termi-
nology, this is known as the PPTP Network Server (PNS). In
L2TP terminology, this is known as the L2TP Network Server
(LNS).
Network Access Server
The Network Access Server (NAS) is the device that clients
contact in order to get access to the network. In PPTP ter-
minology this is referred to as the PPTP Access Concentrator
(PAC). In L2TP terminology, the NAS is referred to as the
L2TP Access Concentrator (LAC).
RADIUS server
This is a server which provides for authentication/autho-
rization via the protocol described in [3], and for account-
ing as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
and accounting requests, a RADIUS proxy can be employed. To
the NAS, the RADIUS proxy appears to act as a RADIUS server,
and to the RADIUS server, the proxy appears to act as a
RADIUS client.
Network Access Identifier
In order to provide for the routing of RADIUS authentication
and accounting requests, the userID field used in PPP and in
the subsequent RADIUS authentication and accounting
requests, known as the Network Access Identifier (NAI) MAY
contain structure. This structure provides a means by which
the RADIUS proxy will locate the RADIUS server that is to
receive the request. This same structure MAY also be used to
locate the tunnel endpoint when domain-based tunneling is
used.
4. Requirements language
This specification uses the same words as [9] for defining the signif-
icance of each particular requirement. These words are:
MUST This word, or the adjectives "REQUIRED" or "SHALL", means
that the definition is an absolute requirement of the
Aboba & Zorn [Page 2]
INTERNET-DRAFT 7 March 1997
specification.
MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi-
nition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", means that there
MAY exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
SHOULD NOT
This phrase means that there MAY exist valid reasons in par-
ticular circumstances when the particular behavior is
acceptable or even useful, but the full implications should
be understood and the case carefully weighed before imple-
menting any behavior described with this label.
MAY This word, or the adjective "OPTIONAL", means that an item
is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or because
the vendor feels that it enhances the product while another
vendor may omit the same item. An implementation which does
not include a particular option MUST be prepared to interop-
erate with another implementation which does include the
option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular
option MUST be prepared to interoperate with another imple-
mentation which does not include the option.(except, of
course, for the feature the option provides)
Silently Discard
The implementation discards the datagram without further
processing, and without indicating an error to the sender.
The implementation SHOULD provide the capability of logging
the error, including the contents of the discarded datagram,
and SHOULD record the event in a statistics counter.
An implementation is not compliant if it fails to satisfy one or more
of the MUST or MUST NOT requirements for the protocols it implements.
An implementation that satisfies all the MUST, MUST NOT, SHOULD and
SHOULD NOT requirements for its protocols is said to be "uncondition-
ally compliant"; one that satisfies all the MUST and MUST NOT require-
ments but not all the SHOULD or SHOULD NOT requirements for its proto-
cols is said to be "conditionally compliant."
5. Introduction
Many of the most interesting applications of tunneling protocols
involve dial-up network access. Some, such as the provisioning of
secure access to corporate intranets via the Internet, are character-
ized by voluntary tunneling: the tunnel is created at the request of
the user for a specific purpose. Other applications involve compulsory
Aboba & Zorn [Page 3]
INTERNET-DRAFT 7 March 1997
tunneling: the tunnel is created automatically, without any action
from the user and more importantly, without allowing the user any
choice in the matter.
Examples of applications that might be implemented using compulsory
tunnels are Internet software upgrade servers, software registration
servers and banking services. These are all services which, without
mandatory tunneling, would probably be provided using dedicated net-
works or at least dedicated network access servers (NAS), since they
are characterized by the need to limit user access to specific hosts.
Given the existence of widespread support for mandatory tunneling,
however, these types of services could be accessed via virtually any
Internet service provider (ISP). The most popular means of authoriz-
ing dial-up network users today is through the RADIUS protocol. The
use of RADIUS allows the dial-up users' authorization and authentica-
tion data to be maintained in a central location, rather than being
subject to manual configuration. It makes sense to use RADIUS to cen-
trally administer compulsory tunneling, since RADIUS is widely
deployed and was designed to carry this type of information. New
RADIUS attributes are needed to carry the tunneling information from
the RADIUS server to the NAS and to transfer accounting data from the
NAS to the RADIUS server; those attributes are defined in [7].
This document focuses on implementation issues arising in the provi-
sioning of mandatory tunneling in dialup networks. The use of RADIUS
in provisioning of mandatory tunneling has several advantages. These
include:
User-based tunneling
Auditing capabilities
Telephone-number based authentication and accounting
5.1. User-based Tunneling
Current proposals for routing of tunnel requests include static tun-
neling, where all users are automatically tunneled to a given end-
point, and realm-based tunneling, where the tunnel endpoint is deter-
mined from the realm portion of the userID. User-based tunneling as
provided by integration of RADIUS and tunnel protocols offers signifi-
cant 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 them to
dedicate a NAS to tunneling service for a given corporate customer,
rather than allowing them to use existing NASes deployed in the field.
As a result static tunneling is likely to be costly for deployment of
a global service.
Realm-based tunneling assumes that all users within a given realm wish
to be treated the same way. This limits a corporation's flexibility in
managing the account rights of their users. For example, BIGCO may
desire to provide Janet with an account that allows access to both the
Aboba & Zorn [Page 4]
INTERNET-DRAFT 7 March 1997
Internet and the intranet, with Janet's intranet access provided by a
tunnel server located in the engineering department. However BIGCO may
desire to provide Fred with an account that provides only access to
the intranet, with Fred's intranet access provided by a tunnel network
server located in the sales department. Such a situation cannot be
accommodated with realm-based tunneling.
On the other hand, user-based tunneling as enabled by the attributes
defined in [7] provides BIGCO with the flexibility to administer tun-
neling behavior on a per-user basis. When deployed in concert with
roaming, user-based tunneling offers corporations the ability to pro-
vide their users with access to the corporate Intranet on a global
basis.
As described in [7], provisioning of mandatory tunneling requires no
new RADIUS messages, and implementation of three new RADIUS
attributes. During authentication, the new attributes allow the RADIUS
server to indicate the tunnel protocol (PPTP, L2F, L2TP, etc.), the
tunnel medium (X.25, ATM, Frame Relay, IP) and the address of the
remote tunnel endpoint. During accounting, the new attributes allow
the NAS to provide the RADIUS server with these same attributes, as
well as the tunnel client address and Connection Identifier. Together
the Connection Identifier and tunnel client and endpoint addresses
uniquely identify the call, linking together the NAS and tunnel server
accounting records for a given call.
5.2. Auditing Capabilities
The integration of RADIUS and tunnel protocols allows the ISP and the
corporation to synchronize their accounting activities so that each
side receives a record of the user's resource consumption. This pro-
vides the corporation with the means to audit ISP bills. This capabil-
ity is particularly important when the user is taking advantage of
roaming capabilities in order to connect to the corporate intranet
from a remote location.
As described in [7], auditing requires implementation of number of new
RADIUS attributes. These new attributes allow the RADIUS server to
provide information within the Accounting-Request packet that will
allow matching with the corresponding tunnel server Accounting-Request
packet. This information includes the Connection-Identifier, the tun-
nel protocol (PPTP, L2F, L2TP, etc.), tunnel-media (X.25, ATM, Frame
Relay, IP) the address of the remote tunnel endpoint, and the tunnel
client address.
5.2.1. Connection-Identifier
In L2TP the Call-Serial-Number is used as the Connection Identifier,
and the tuple (userID, tunnel-client-endpoint address, tunnel-server-
endpoint address, Call-Serial-Number) is used to uniquely identify the
call. In order to protect against wrapping due to reboots or call vol-
ume, it is recommended that a 64-bit NTP timestamp be used as the
Aboba & Zorn [Page 5]
INTERNET-DRAFT 7 March 1997
Call-Serial Number.
While the PPTP specification states that the Call-Serial-Number SHOULD
be unique, it does not mandate this. In addition, no method for deter-
mining the Call-Serial-Number is specified, which leaves open the pos-
sibility of wrapping after a reboot. Finally since the Call-Serial-
Number is a 16-bit value, the Call-Serial-Number is not sufficient to
distinguish a given call from all other calls over an extended time
period. For example, let us assume that the Call Serial Number is
assigned monotonically, and that the NAS in question has 96 ports. If
the NAS ports are kept continually busy and the average call is of 20
minutes duration, then the Call Serial Number will wrap within
65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days.
In order to rectify this, it is recommended that another message be
added to PPTP so that the NAS could provide the tunnel server with a
unique Connection Identifier. It is recommended that a 64-bit NTP
timestamp be used for this purpose. This is not an issue in L2TP since
the Call-Serial-Number string MAY be of variable length.
5.3. Telephone-number based authentication and accounting
Using the Calling-Station-ID and Called-Station-ID RADIUS attributes,
authorization and subsequent tunnel attributes can be based on the
phone number originating the call, or the number being called. This
allows the RADIUS server to authorize users based on the calling phone
number (with or without a userID/password combination), or to select
the tunnel type, tunnel medium, or tunnel endpoint address based on
the calling or called phone number. Similarly, the tunnel server MAY
choose to reject or accept the call based on the Dialed Number and
Dialing Number included in the Incoming-Call-Request packet sent by
the NAS.
The use of RADIUS accounting by the NAS and/or the tunnel server
allows for accounting to take place based on the Calling-Station-ID
and/or Called-Station-ID.
6. Alternatives for implementation of mandatory tunneling
There are several alternatives for integration of RADIUS and tunnel-
ing:
Authenticate at the NAS
Authenticate at the NAS, and forward the RADIUS reply
Authenticate at the tunnel network server
Authenticate at both the NAS and the tunnel network server
We discuss each of these alternatives in turn.
Aboba & Zorn [Page 6]
INTERNET-DRAFT 7 March 1997
6.1. Authenticate at the NAS
With this approach, authentication and authorization (including tun-
neling information) occurs once, at the NAS. The advantages of this
approach are that it disallows network access for unauthorized NAS
users; and allows RADIUS accounting to be used at the NAS. Disadvan-
tages are that it requires that the tunnel network server trust the
NAS, since no user authentication occurs on the tunnel network server
end of the tunnel. Another disadvantage is that this does not allow
LCP parameters to be re-negotiated by the tunnel network server. Also,
due to the lack of user authentication, accounting cannot take place
at the tunnel network server with strong assurance that the correct
party is being billed.
6.2. Authenticate at the NAS, and forward the RADIUS reply
With this approach, authentication and authorization occurs once, at
the NAS end of the tunnel and the RADIUS reply is forwarded to the
tunnel network server. This approach disallows network access for
unauthorized NAS users; does not require trust between the NAS and
tunnel network server ends of the tunnel; and allows for RADIUS
accounting to be used at both ends of the tunnel. However, it also
requires that both ends share the same secret with the RADIUS server,
since that's the only way that the tunnel network server could check
the RADIUS reply. Also, the tunnel network server MUST share secrets
with all the NASes and associated RADIUS servers. Other disadvantages
include lack of provision for LCP renegotiation by the tunnel network
server; and the tunnel network server MUST know how to handle and ver-
ify RADIUS Access-Accept messages.
While this scheme can be workable if the reply comes directly from a
RADIUS server, it would become unmanageable if a RADIUS proxy is
involved, since the reply would be authenticated using the secret
shared by the client and proxy, rather than the RADIUS server.
6.3. Authenticate at the tunnel network server
In this scheme, authentication and authorization occurs once at the
tunnel network server. This requires that the NAS determine that the
user needs to be tunneled (through a RADIUS request, manual configura-
tion, etc.). Since the RADIUS specification [3] requires that either a
CHAP or PAP password be present in an Access-Request message, but
doesn't require that it be non-empty, this scheme probably requires
either attribute-specific processing on the RADIUS server, or addition
of a new "Authorize-Only" RADIUS message.
In attribute-specific processing an attribute is used to signal tunnel
initiation. For example, tunnel attributes can be sent back if the PAP
password is empty (or "tunnel" or "L2TP"). Alternatively, a user
could prefix his NAI with some special character ('*') if he wanted to
be tunneled. This particular solution does not support compulsory tun-
neling. Another solution involves keying on the domain portion of the
NAI; all users in domain 'X' would be tunneled to address 'Y'. This
proposal supports compulsory tunneling, but does not provide for user-
Aboba & Zorn [Page 7]
INTERNET-DRAFT 7 March 1997
based tunneling.
An Authorize-Only message would not include a CHAP or PAP password;
nevertheless, in response the RADIUS server would return the attribute
list. In order to prevent password guessing attacks, an Authorize-Only
message would need to be authenticated via the RADIUS shared secret.
This could be accomplished via the Signature attribute described in
[10].
Note that when either attribute-specific processing or authorization-
only messages are used, the tunnel network server would need to rene-
gotiate LCP. Note also that in order for the NAS to start accounting
on the connection, it would need to use the identity claimed by the
user in authenticating to the tunnel network server, since it did not
verify the identity via RADIUS. However, in order for that to be of
any use in accounting, the tunnel endpoint needs to have an account
relationship with the NAS owner. Thus even if a user has an account
with the NAS owner, they cannot use this account for tunneling unless
the tunnel endpoint also has a business relationship with the NAS
owner. Without putting in place a public key infrastructure, it is not
clear how the NAS would be able to verify the existence of such a
business relationship in a scalable manner. Thus this approach nulli-
fies many of the benefits of roaming.
6.4. Authenticate at both the NAS and the tunnel network server
In this scheme, authentication occurs both at the NAS and the tunnel
network server. This requires the dial-up PPP peer to handle dual
authentications, with attendant LCP re-negotiations. In order to allow
the NAS and tunnel network server to authenticate against the same
database, this requires RADIUS client capability on the tunnel network
server, and possibly a RADIUS proxy on the NAS end.
Advantages of this scheme are that it allows secure authentication and
accounting at both ends of the tunnel; allows the use of a single
userID/password pair via implementation of RADIUS on the tunnel net-
work server; and does not require attribute-specific processing or
addition of an Authorize-Only message on the RADIUS server. This
scheme allows for accounting records to be generated on both the NAS
and tunnel server ends allowing for auditing. Also, in contrast to the
previous scheme, the tunnel endpoint does not need to have an account
relationship with the NAS owner. Thus this scheme is compatible with
roaming. Disadvantages are that unless LCP forwarding is used, LCP
will need to be renegotiated, and that dual authentications are
required.
Considering all the advantages and disadvantages of the various
schemes, we believe that this scheme is the best choice, and as a
result, the rest of this document focuses on the dual authentication
scheme.
Aboba & Zorn [Page 8]
INTERNET-DRAFT 7 March 1997
7. Initiation Sequence
The provisioning of a mandatory tunnel involves an interaction between
the client, NAS, Tunnel Server, and RADIUS server. The following
events occur in initiation of the connection:
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-reply/Access-Reject
NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP re-negotiation (optional)
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-reply/Access-Reject
Client and Tunnel Server: NCP negotiation
NAS to RADIUS Server: RADIUS Accounting-Request/START
RADIUS Server to NAS: RADIUS Accounting-Reply
Tunnel Server to RADIUS Server: RADIUS Accounting-Request/START (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Reply
The process begins with an incoming call to the NAS. The client and
NAS then begin LCP negotiation. Subsequently the PPP authentication
phase starts, and the NAS sends a RADIUS Access-Request message to the
RADIUS server. If the authentication is successful, the RADIUS server
responds with a RADIUS Access-Accept including the Tunnel-Type (L2F,
PPTP, L2TP, etc.), Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP),
and Tunnel-Server-Endpoint attributes.
RADIUS proxies MAY be used to forward the Access-Reply message from
the RADIUS server to the NAS. In order to ensure that the mandatory
tunnel attributes arrive without modification, RADIUS proxies present
in the path MUST NOT modify these attributes. If the tunnel attributes
received from the RADIUS server are not acceptable to the proxy, then
the proxy MUST send an Access-Reject to the NAS.
Since this is a mandatory tunnel, address assignment will be handled
by the tunnel server rather than the NAS. As a result, if tunnel
attributes are present, the NAS MUST ignore any address assignment
attributes sent by the RADIUS server. In addition, the NAS and client
MUST NOT begin NCP negotiation, since this could create a time window
in which the client will be capable of sending packets to the trans-
port network, which is not permitted under mandatory tunneling. If
the authentication is unsuccessful, the RADIUS server sends a RADIUS
Access-Reject. In this case, the NAS MUST disconnect the user.
The NAS will now bring up a control connection to the tunnel server if
none existed before. This is accomplished by sending a PPTP/L2TP
Start-Control-Connection-Request message to the tunnel server. The
tunnel server replies with a PPTP/L2TP Start-Control-Connection-Reply.
If this message indicates an error, or if the control connection is
terminated at any future time, then the NAS MUST disconnect the user.
Aboba & Zorn [Page 9]
INTERNET-DRAFT 7 March 1997
The NAS will then proceed to send a PPTP/L2TP Incoming-Call-Request
message to the tunnel server. Among other things, this message will
contain the Call Serial Number, which along with the IP addresses of
the NAS and tunnel server, is used to uniquely identify the call. The
tunnel server will reply with a PPTP/L2TP Incoming-Call-Reply message.
If this message indicates an error, then the NAS MUST disconnect the
user. The NAS then replies with an Incoming-Call-Connected message.
At this point, data MAY begin to flow through the tunnel. The client
and tunnel server MAY now renegotiate LCP and go through another round
of PPP authentication. At the time that this renegotiation begins, the
NAS SHOULD NOT have sent the final packet confirming the success of
the initial authentication, and the client and NAS MUST NOT have begun
NCP negotiation. Rather than sending the final confirmation packet,
the NAS will instead send an LCP down message. The Client MAY then
renegotiate LCP, and from that point forward, all PPP packets origi-
nated from the client will be encapsulated and sent to the tunnel
server. When LCP re-negotiation has been concluded, the NCP phase
will begin, and the tunnel server will assign an address to the
client.
If L2TP is being used as the tunnel protocol, the NAS MAY in its ini-
tial setup notification include a copy of the LCP CONFACKs sent in
each direction which completed LCP negotiation. The tunnel server MAY
then use this information to avoid an additional LCP negotiation. With
L2TP, the initial setup notification can also include the authentica-
tion information required to allow the tunnel server to authenticate
the user and decide to accept or decline the connection. However, this
facility creates a vulnerability to replay attacks, and can create
problems in the case where the NAS and tunnel server authenticate
against different RADIUS servers. As a result, where user-based tun-
neling via RADIUS is implemented, L2TP authentication forwarding
SHOULD NOT be employed.
In performing the PPP authentication, the tunnel server can access its
own user database, or it MAY send a RADIUS Access-Request. The latter
approach is useful in cases where authentication forwarding is
enabled, such as with roaming or shared use networks. In this case,
the RADIUS and tunnel servers are under the same administration and
are typically located close together, possibly on the same LAN. There-
fore having the tunnel server act as a RADIUS client provides for uni-
fied user administration. Other methods are also available, such as
use of LDAP by both the tunnel and RADIUS servers. Note that the tun-
nel server's RADIUS Access-Request is typically sent directly to the
local RADIUS server rather than being forwarded via proxy.
After the tunnel has been brought up, the NAS and tunnel server MAY
start accounting. In the case of the NAS, this is done by sending a
RADIUS Accounting-Request/START packet to the RADIUS server. The
Accounting-Request packet MUST include the following attributes: Tun-
nel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-
Endpoint, and Connection-Identifier.
Aboba & Zorn [Page 10]
INTERNET-DRAFT 7 March 1997
The tunnel server can produce its own accounting records, or it MAY
send a RADIUS Accounting-Request/START packet to a local RADIUS
server. In the latter case, the RADIUS Accounting-Request/START packet
MUST contain the following attributes: Tunnel-Type, Tunnel-Medium-
Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection-
Identifier.
The interactions involved in initiation of a mandatory tunnel are sum-
marized below. In order to simplify the diagram that follows, we have
left out the client. However, it is understood that the client partic-
ipates via PPP negotiation, authentication and subsequent data inter-
change with the Tunnel Server.
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
PPP authentication
phase starts
Send RADIUS
Access-Request
with username and
authentication data
IF authentication
succeeds
Send ACK with
Tunnel-Type,
Tunnel-Medium-Type,
Tunnel-Server-Endpoint
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Aboba & Zorn [Page 11]
INTERNET-DRAFT 7 March 1997
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
Send RADIUS
Accounting-Request
(optional)
Send
RADIUS
Accounting-Reply
Send a RADIUS
Accounting-Request message
with Acct-Status-Type
set to Start, containing
Tunnel-Type, Tunnel-Medium-Type,
Tunnel-Client-Endpoint,
Tunnel-Server-Endpoint, and
Connection-Identifier.
Send
RADIUS
Accounting-Reply
ENDIF
8. Termination Sequence
As with initiation, the tear down of a mandatory tunnel involves an
interaction between the client, NAS, Tunnel Server, and RADIUS server.
The following events occur in termination of the connection:
Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional)
NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify
NAS to RADIUS Server: RADIUS Accounting-Request/STOP
RADIUS Server to NAS: RADIUS Accounting-Reply
Tunnel Server to RADIUS Server: RADIUS Accounting-Request/STOP (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Reply
Tunnel termination can occur due to a client request (PPP termina-
tion), a tunnel server request (Call-Clear-Request), or a line problem
(call disconnect).
In the case of a client-requested termination, the tunnel server MUST
terminate the PPP session. The tunnel server MUST subsequently send a
Call-Clear-Request to the NAS. The NAS MUST then send a Call-Discon-
nect-Notify message to the tunnel server, and will disconnect the
call.
The NAS MUST also respond with a Call-Disconnect-Notify message and
disconnection if it receives a Call-Clear-Request from the tunnel
server without a client-requested termination.
Aboba & Zorn [Page 12]
INTERNET-DRAFT 7 March 1997
In the case of a line problem or user hangup, the NAS MUST send a
Call-Disconnect-Notify to the tunnel server. Both sides will then tear
down the call.
After call tear down is complete, if RADIUS accounting is being used
then the NAS MUST send a RADIUS Accounting-Request/STOP packet to the
RADIUS server. The Accounting-Request/STOP packet MUST include the
following attributes: Tunnel-Type, Tunnel-Medium-Type, Tunnel-Client-
Endpoint, Tunnel-Server-Endpoint, and Connection-Identifier.
The tunnel server MAY produce its own accounting records, or it MAY
use RADIUS accounting. If RADIUS accounting is being used then the
tunnel server MUST send a RADIUS Accounting-Request/STOP packet to a
local RADIUS server. The Accounting-Request/STOP packet MUST contain
the following attributes: Tunnel-Type, Tunnel-Medium-Type, Tunnel-
Client-Endpoint, Tunnel-Server-Endpoint, and Connection-Identifier.
The interactions involved in termination of a mandatory tunnel are
summarized below. In order to simplify the diagram that follows, we
have left out the client. However, it is understood that the client
MAY participate via PPP termination and disconnection.
TERMINATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
Send RADIUS
Accounting-Request/STOP
message (optional)
Send RADIUS
Accounting-Reply
ELSE IF client requests
termination
send
Call-Clear-Request
to the NAS
Send
Call-Disconnect-Notify
message to tunnel server
Disconnect the user
Tear down the call
stop accounting
Send RADIUS
Accounting-Request/STOP
message (optional)
Send RADIUS
Accounting-Reply
Aboba & Zorn [Page 13]
INTERNET-DRAFT 7 March 1997
Send a RADIUS
Accounting-Request message
with Acct-Status-Type
set to Stop, containing
Tunnel-Type, Tunnel-Medium-Type,
Tunnel-Client-Endpoint,
Tunnel-Server-Endpoint, and
Connection-Identifier.
Send RADIUS
Accounting-Reply
ENDIF
9. Use of distinct RADIUS servers
In the case that the NAS and the tunnel server are using distinct
RADIUS servers, some interesting cases can arise in the provisioning
of mandatory tunnels.
9.1. Distinct userIDs
If distinct RADIUS servers are being used, it is likely that two dis-
tinct userID/password pairs will be required to complete the RADIUS
and tunnel authentications. One pair will be used in the initial PPP
authentication with the NAS, and the second pair will be used for the
tunnel authentication.
However, in order to provide maximum ease of use in the case where the
userID/password pairs are identical, tunnel clients typically attempt
authentication with the same userID/password pair as was used in the
initial PPP negotiation. Only after this fails do they prompt the user
for the second pair.
In this case, tunnel client implementations SHOULD take care not to
put up error messages indicating a bad password. Instead a dialog
SHOULD be presented requesting the tunnel userID/password combination.
In the case where token cards are being used for both authentications,
the tunnel client MUST NOT attempt to present the token used in the
first authentication during the second authentication, since these
will never be identical. Instead the user SHOULD be prompted to enter
the second token.
The same issue arises in L2TP if the NAS attempts to forward authenti-
cation information to the tunnel server in the initial setup notifica-
tion. Since the userID/password pair used for tunnel authentication is
different from that used to authenticate against the NAS, forwarding
authentication information in this manner will cause the tunnel
authentication to fail. As a result, where user-based tunneling via
RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be
employed.
Aboba & Zorn [Page 14]
INTERNET-DRAFT 7 March 1997
9.2. Multilink PPP issues
It is possible for the two RADIUS servers to return distinct MAX CHAN-
NEL attributes. For example, it is conceivable that the NAS RADIUS
server will only grant use of a single channel to the user, while the
tunnel RADIUS server will grant more than one channel. In this case,
the correct behavior is for the tunnel client to open a connection to
another NAS in order to bring up a multilink bundle on the tunnel
server. The client MUST NOT indicate to the NAS that this additional
link is being brought up as part of a multilink bundle; this will only
be indicated in the subsequent negotiation with the tunnel server.
It is also conceivable that the NAS RADIUS server will allow the
client to bring up multiple channels, but that the tunnel RADIUS
server will allow fewer channels than the NAS RADIUS server. In this
case, the client should terminate use of the excess channels.
10. UserID Issues
In the provisioning of roaming and shared use networks, one of the
requirements is to be able to route the authentication request to the
user's home RADIUS server. This authentication routing is accomplished
based on the userID submitted by the user to the NAS in the initial
PPP authentication.
Similarly, references [5] and [6] refer to use of the userID in deter-
mining the tunnel endpoint. However, since none of these references
provide guidelines for how RADIUS or tunnel routing is to be accom-
plished, the possibility of conflicting interpretations exists.
10.1. UserID convergence in user-based tunneling
The use of RADIUS in provisioning of mandatory tunneling relieves the
userID from having to do double duty. Rather than being used both for
routing of the RADIUS authentication/authorization request as well for
determination of the tunnel endpoint, the userID is now used solely
for routing of RADIUS authentication/authorization requests. The
response to that request is in turn used to determine the tunnel end-
point.
Since the framework described in this document allows both ISPs and
tunnel users to authenticate users as well as account for resources
consumed by them, and provides for maintenance of two distinct
userID/password pairs, it is believed that this scheme offers the max-
imum degree of flexibility. Where RADIUS proxies and tunneling are
employed, it is possible to allow the user to authenticate with a sin-
gle userID/password pair at both the NAS and the tunnel endpoint. This
is accomplished by routing the NAS RADIUS Access-Request to the same
RADIUS server used by the tunnel server.
Aboba & Zorn [Page 15]
INTERNET-DRAFT 7 March 1997
As described in [8], the recommended form for the user ID is
userID@domain, i.e. fred@bigco.com.
11. Acknowledgements
Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions
of this problem space, and to Bertrand Buclin of AT&T Labs Europe for
his comments on this document.
12. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen-
tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass
Alliance, Asiainfo, January, 1997.
[2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf-
roamops-roamreq-02.txt, Microsoft, January, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
1997.
[5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft-
ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996.
[6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, J. Taarud, W. A.
Little. "Point-to-Point Tunneling Protocol -- PPTP." draft-ietf-
pppext-pptp-00.txt, Ascend Communications, June, 1996.
[7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft-
ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996.
[8] B. Aboba. "The Network Access Identifier." draft-ietf-roamops-
nai-02.txt, Microsoft Corporation, March, 1997.
[9] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." draft-bradner-key-words-02.txt, Harvard University, August,
1996.
[10] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius-
ext-00.txt, Livingston, January, 1997.
13. Authors' Addresses
Bernard Aboba
Microsoft Corporation
Aboba & Zorn [Page 16]
INTERNET-DRAFT 7 March 1997
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-703-1559
EMail: glennz@microsoft.com
Aboba & Zorn [Page 17]
