Network Working Group Glen Zorn
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-radius-tunnel-auth-00.txt>
25 November 1996
RADIUS Attributes for Tunnel Protocol Support
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-auth-00.txt>, and expires May 1, 1997. Please send com-
ments to the author.
2. Abstract
This document specifies a set of RADIUS attributes designed to support
the provision of mandatory tunneling in dial-up networks. RADIUS
attributes for both authorization and accounting are specified.
3. Introduction
Many of the most interesting applications of tunneling protocols such
as PPTP [PPTP] and L2TP [L2TP] involve dial-up network access. Some,
such as the provision of secure access to corporate intranets via the
Internet, are characterized by voluntary tunneling: the tunnel is cre-
ated at the request of the user for a specific purpose. Other, poten-
tially more compelling, applications involve compulsory 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
Zorn [Page 1]
INTERNET-DRAFT 25 November 1996
compulsory 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 compulsory 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; this document defines those attributes.
4. Attributes
4.1. Tunnel-Type
Description
This Attribute indicates the tunneling protocol to be used. It
MAY be used in both Access-Request and Access-Accept packets. A
NAS is not required to implement all of these tunnel types, and
MUST treat unknown or unsupported Tunnel-Types as though an
Access-Reject had been received instead.
A summary of the Tunnel-Type Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
64 for Tunnel-Type
Length
6
Value
The Value field is four octets.
1 PPTP
Zorn [Page 2]
INTERNET-DRAFT 25 November 1996
2 L2F
3 L2TP
4.2. Tunnel-Medium-Type
Description
The Tunnel-Medium-Type Attribute indicates which transport
medium to use when creating a tunnel for those protocols (such
as L2TP) that can operate over multiple transports.
A summary of the Tunnel-Medium-Type Attribute format is given
below. The fields are transmitted left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
65 for Tunnel-Medium-Type
Length
6
Value
The Value field is four octets.
1 IP
2 X.25
3 ATM
4 Frame Relay
4.3. Tunnel-Client-Endpoint
Description
This Attribute indicates the address of the NAS end of the tun-
nel.
A summary of the Tunnel-Client-Endpoint Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Zorn [Page 3]
INTERNET-DRAFT 25 November 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
66 for Tunnel-Client-Endpoint.
Length
>= 3
String
The format of the address represented by the String field
depends upon the value of the Tunnel-Medium-Type attribute.
This attribute, along with the Tunnel-Server-Endpoint and Tun-
nel-ID attributes, may be used to provide a globally unique
means to identify a tunnel for accounting purposes.
4.4. Tunnel-Server-Endpoint
Description
This Attribute indicates the address of the server end of the
tunnel.
A summary of the Tunnel-Server-Endpoint Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
67 for Tunnel-Server-Endpoint.
Length
>= 3
String
The format of the address represented by the String field
depends upon the value of the Tunnel-Medium-Type attribute.
This attribute, along with the Tunnel-Client-Endpoint and Tun-
nel-ID attributes, may be used to provide a globally unique
means to identify a tunnel for accounting purposes.
Zorn [Page 4]
INTERNET-DRAFT 25 November 1996
4.5. Connection-Identifier
Description
This Attribute indicates the identifier assigned to the call.
A summary of the Connection-Identifier Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
68 for Connection-Identifier
Length
>= 3
String
The format of the identifier represented by the String field
depends upon the value of the Tunnel-Type attribute. This
attribute, along with the Tunnel-Client-Endpoint and Tunnel-
Server-Endpoint attributes, may be used to provide a globally
unique means to identify a call for accounting purposes.
5. Acknowledgements
Thanks to Gurdeep Singh Pall and Bernard Aboba of Microsoft Corpora-
tion, Andy Valencia of cisco Systems, and Kory Hamzeh of Ascend Commu-
nications for salient input and review.
6. Author's Address
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-703-1559
EMail: glennz@microsoft.com
Zorn [Page 5]
