ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-roamreq-00.txt> Glen Zorn
26 November 1996 Microsoft Corporation
Dialup Roaming Requirements
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-roamops-roamreq-00.txt>, and expires June 1, 1997. Please send
comments to the authors.
2. Abstract
This document describes the features required for the provision of
"roaming capability" for dialup Internet users, as well as offering
some suggestions for future protocol standardization work. "Roaming
capability" may be loosely defined as the ability to use any one of
multiple Internet service providers (ISPs), while maintaining a for-
mal, customer-vendor relationship with only one. Examples of cases
where roaming capability might be required include ISP "confedera-
tions" and ISP-provided corporate network access support.
3. Introduction
Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for dialup
Internet users. Interested parties have included:
Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service
Aboba & Zorn [Page 1]
INTERNET-DRAFT 26 November 1996
over a wider area.
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent.
Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services may
include Internet access as well as secure access to corporate
intranets via a Virtual Private Network (VPN), enabled by tunnel-
ing protocols such as PPTP, L2F, or L2TP.
What are the elements of a dialup roaming architecture? The following
list is a first cut at defining the elements for successful roaming
among an arbitrary set of ISPs:
Phone number presentation
Phone number exchange
Phone book compilation
Phone book update
Connection management
Authentication
NAS Configuration/Authorization
Address Assignment/Routing
Security
Accounting
These topics are discussed further in following sections.
3.1. Terminology
This document frequently uses the following terms:
phone book
This is a database or document containing data pertaining to
dialup access, including phone numbers and any associated
attributes.
phone book server
This is a server that maintains the latest version of the
phone book. Clients communicate with phone book servers in
order to keep their phone books up to date.
Network Access Server
The Network Access Server (NAS) is the device that clients
dial in order to get access to the network.
RADIUS server
This is a server which provides for authentica-
tion/authorization via the protocol described in [3], and
for accounting as described in [4].
Aboba & Zorn [Page 2]
INTERNET-DRAFT 26 November 1996
RADIUS proxy
In order to provide for the routing of RADIUS authentication
and accounting requests, a RADIUS proxy may 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 (known
as the Network Access Identifier or NAI) and in the subse-
quent RADIUS authentication and accounting requests, may
contain structure. This structure provides a means by which
the RADIUS proxy will locate the RADIUS server that is to
receive the request.
3.2. Requirements language
This specification uses the same words as RFC 1123 [4] for defining
the significance of each particular requirement. These words are:
MUST This word or the adjective "required" means that the item is
an absolute requirement of the specification.
SHOULD This word or the adjective "recommended" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be under-
stood and the case carefully weighed before choosing a dif-
ferent course.
MAY This word or the adjective "optional" means that this item
is truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit
the same item.
An implementation is not compliant if it fails to satisfy
one or more of the MUST requirements for the protocols it
implements. An implementation that satisfies all the MUST
and all the SHOULD requirements for its protocols is said to
be "unconditionally compliant"; one that satisfies all the
MUST requirements but not all the SHOULD requirements for
its protocols is said to be "conditionally compliant."
4. Requirements for Dialup Roaming
Suppose we have a customer, Fred, who has signed up for Internet
access with ISP A in his local area, through his company, BIGCO. ISP
A has joined an association of other ISPs (which we will call
Aboba & Zorn [Page 3]
INTERNET-DRAFT 26 November 1996
ISPGROUP) in order to offer service outside the local area. Now Fred
travels to another part of the world, and wishes to dial into a phone
number offered by ISP B (also a member of ISPGROUP). What is involved
in allowing this to occur?
Phone number presentation
Fred must be able to find and select the phone number offered by
ISP B.
Phone number exchange
When there is a change in the status of phone numbers (additions
or deletions) from individual providers, providers in ISPGROUP
will typically notify each other and propagate the changes.
Phone book compilation
When these updates occur, a new phone book will be compiled,
based on the changes submitted by the individual ISPs in ISP-
GROUP.
Phone book update
Once a new phone book is compiled, there must be a way to update
the phone books of customers such as Fred, so that the changes
are reflected in the user phone books.
Connection management
Fred's machine must be able to dial the phone number, success-
fully connect, and interoperate with the Network Access Server
(NAS) on the other end of the line.
Authentication
Fred must be able to secure access to the network.
NAS configuration/authorization
The Network Access Server (NAS) must receive configuration param-
eters in order to set up Fred's session.
Security
If desired by BIGCO, additional security measures may be sup-
ported for Fred's session. These could include supporting use of
token cards, or setting up Fred's account so that he is automati-
cally tunneled to the corporate PPTP, L2F or L2TP server for
access to the corporate intranet.
Address assignment/routing
Fred must be assigned a routable IP address by the NAS.
Accounting
ISP B must keep track of what resources Fred used during the ses-
sion. Relevant information may include how long Fred used the
service, what speed he connected at, whether he connected via
ISDN or modem, etc.
Aboba & Zorn [Page 4]
INTERNET-DRAFT 26 November 1996
Note that some of these requirements may not require standardization
or lie outside the scope of the IETF; they are all listed for com-
pleteness' sake.
4.1. Phone Number Presentation
Phone number presentation involves the display of available phone num-
bers to the user, and culminates in the choosing of a number. Since
the user interface and sequence of events involved in phone number
presentation is a function of the connection management software that
Fred is using, it is likely that individual vendors will take differ-
ent approaches to the problem. These differences may include vari-
ances in the format of the client phone books, varying approaches to
presentation, etc. There is no inherent problem with this. As a
result, phone number presentation need not be standardized.
4.2. Phone Number Exchange
Phone number exchange involves propagation of phone number changes
between providers in a roaming association. As described in [2] how-
ever, no current roaming implementations provide for complete automa-
tion of the phone number exchange process. As a result, phone number
exchange need not be standardized at this time.
4.3. Phone Book Compilation
Once an ISP's phone book server has received its updates it needs to
compile a new phone book and propagate this phone book to all the
phone book servers operated by that ISP. Given that the compilation
process does not affect protocol interoperability, it need not be
standardized.
4.4. Phone Book Update
Once the phone book is compiled, it needs to be propagated to cus-
tomers. Standardization of the phone book update process allows for
providers to update the phone books of users, independent of their
client and operating system. As a result, roaming implementations pro-
viding for phone book update MUST implement the standard update proto-
col.
4.4.1. Phone book update protocol requirements
What must a phone book update protocol do to be successful?
Portability
The update protocol must allow for updating of clients on a range
Aboba & Zorn [Page 5]
INTERNET-DRAFT 26 November 1996
of platforms and operating systems. Therefore the update mecha-
nism must not impose any operating system-specific requirements.
Authentication
The client must be able to determine the authenticity of the
server sending the phone book update. The server should also be
able to authenticate the client.
Versioning
The update protocol must provide for updating of the phone book
from an arbitrary previous version to the latest available ver-
sion.
Integrity Checking
The client must be able to determine the integrity of the
received update before applying it, as well as the integrity of
the newly produced phone book after updating it.
Light weight transfers
Since the client machine may in many cases be a low-end PC, the
update protocol must be lightweight.
Language support
The phone book update mechanism must support the ability to
request that the phone book be transmitted in a particular lan-
guage and character set. For example, if the customer has a Rus-
sian language software package, then the propagation and update
protocols must provide a mechanism for the user to request a Rus-
sian language phone book.
4.4.2. Phone book format requirements
What must a phone book format do to be successful?
Phone number attributes
The phone book format must support phone number attributes com-
monly used by Internet service providers. These attributes are
required in order to provide users with information on the capa-
bilities of the available phone numbers.
Provider attributes
In addition to providing information relating to a given phone
number, the phone book must provide information on the individual
roaming consortium members. These attributes are required in
order to provide users with information about the individual
providers in the roaming consortium.
Aboba & Zorn [Page 6]
INTERNET-DRAFT 26 November 1996
Service attributes
In addition to providing information relating to a given phone
number, and service provider, the phone book must provide infor-
mation relevant to configuration of the service. These attributes
are necessary to provide the client with information relating to
the operation of the service.
Extensibility
Since it may be necessary to add phone book attributes, the phone
book format must support the addition of phone number, provider
and service attributes without modification to the update proto-
col or phone book format. Registration of new phone book
attributes will be handled by IANA. To accommodate growth, the
attribute space must be sufficiently large to allow for growth.
Compactness
Since phone book may be frequently updated, the phone book format
must be compact so as to minimize the bandwidth used in updating
it.
4.4.2.1. Phone number attributes
Examples of phone number attributes include:
Unique identifier for the phone number
City
State or Region
Country
Area code
Local phone number
Minimum speed
Maximum speed
Modem protocols supported (V.32bis, V.34, etc.)
ISDN protocols supported (V.110, V.120, etc.)
Multicast capability
Times of operation
Priority level (for control of presentation order)
External/internal flag (denoting whether the number has been imported)
4.4.2.2. Provider attributes
Examples of provider attributes include:
Provider name
Provider address
Provider voice phone number
Provider fax phone number
Customer support phone number
Provider icon
Aboba & Zorn [Page 7]
INTERNET-DRAFT 26 November 1996
Provider domain name
Primary Domain Name Server
Secondary Domain Name Server
Dial-up IP Address
News server
Mail server
Web page
Maximum length of the user name for the provider
Maximum length of the password for the provider
4.4.2.3. Service attributes
Examples of service attributes include:
The name of the service
A description of the service
The URL of the service phone book server
The service phone book filename
The service phone book version number
4.5. Connection Management
Once Fred has chosen a number from his phone book, he will need to
connect to ISP B via ISDN or modem, and bring up a dialup network con-
nection. In the case of a PPP session, this will include CHAP or PAP
authentication.
4.5.1. Requirements
To be successful, a roaming implementation must provide:
PPP Support
Given the current popularity and near ubiquity of PPP, a roaming
standard must provide support for PPP. While an implementation
may choose to support other framing protocols such as SLIP, SLIP
support is expected to prove difficult since SLIP does not sup-
port negotiation of connection parameters and lacks support for
protocols other than IP. Support for non-IP protocols (e.g., IPX)
may be necessary for the provision of corporate intranet access
via the Internet.
4.6. Authentication
Authentication may be seen as consisting of two parts: the claim of
identity (or identification) and the proof of the claim (or verifica-
tion).
Aboba & Zorn [Page 8]
INTERNET-DRAFT 26 November 1996
In order for Fred to obtain network access from ISP B, he must have
been assigned a user ID which identifies him as a customer of a member
of ISPGROUP (in this case, ISP A). If a user ID suffix is used, Fred
might identify himself as "fred@ispa.com"; if a prefix is used, he
might identify himself as "ISPA/fred". Note that some NAS vendors may
need to modify their devices so as to support the longer user IDs
resulting from addition of prefixes or suffixes.
After obtaining Fred's user ID and other authentication data, the NAS
device will then forward a RADIUS request packet to a RADIUS proxy or
server. If a proxy is being used, it must examine the user ID prefix
or suffix, check whether it represents an authorized authentication
realm, and then pass the request either to an appropriate RADIUS
server, or to another proxy for further routing.
4.6.1. Identification
As part of the authentication process, users identify themselves to
the Network Access Server (NAS) in a manner that allows the NAS to
route the authentication request to its home destination.
4.6.1.1. Naming requirements
What must an identification scheme have to do to be successful?
Authentication routing
A roaming standard must provide a mechanism for the remote ISP to
efficiently route the authentication request to the home authen-
tication server. As part of this, there must be a way for the
remote ISP to determine the IP address of the authentication
server that is to be contacted.
Robustness
Authentication routing must be carried out in a manner that
allows the authentication request to reach its the destination,
and for the response to be returned to the querying NAS, all
within a time period compatible with typical RADIUS timeout
parameters.
4.6.2. Verification of Identity
CHAP and PAP are the two authentication protocols used within the PPP
framework today. Some groups of users are requiring different forms of
proof of identity (e.g., token or smart cards, Kerberos credentials,
etc.) for special purposes(such as acquiring access to corporate
intranets).
Aboba & Zorn [Page 9]
INTERNET-DRAFT 26 November 1996
4.6.3. Requirements
A roaming standard must provide:
Support for PAP and CHAP
A successful roaming implementation must support both CHAP and
PAP authentication.
RADIUS Support
Given the current popularity and near ubiquity of RADIUS, a roam-
ing standard must support RADIUS, as defined in [2] and [3].
Other protocols may be supported. However, it is the responsibil-
ity of participating ISPs and/or software vendors to produce
gateways between those protocols and RADIUS.
Security
A roaming standard must provide a mechanism for the remote ISP to
determine whether the home authentication server has a valid
business relationship with the remote ISP. This implies either
that the authenticating party is a member of the roaming associa-
tion, or that the authenticating party has a valid business rela-
tionship with a member of the roaming association.
Scalability
A roaming standard, once available, is likely to be widely
deployed on the Internet. A roaming standard must therefore pro-
vide sufficient scalability. At a minimum, a roaming standard
must scale to accomodate no less
than 20 ISPs within a roaming association. In addition, a roam-
ing standard must support the use of at least 10 "sub-domains"
per ISP. These subdomains may consist of ISP customers running
their own authentication servers. Thus, the standard must be able
to deal with the possibility of 200 authentication servers oper-
ating within a roaming association.
4.7. NAS Configuration/Authorization
In order for Fred to be able to log in to ISP B, it is necessary for
ISP A's RADIUS server to return the proper configuration information
to ISP B's NAS.
4.7.1. Configuration/Authorization requirements
In order to be successful, a roaming standard must provide:
Aboba & Zorn [Page 10]
INTERNET-DRAFT 26 November 1996
Masking of heterogeneity
ISP A and ISP B's NAS devices may be from different vendors; even
if they are from the same vendor, ISP A and ISP B may use differ-
ent NAS configurations. As a result, the NASs may each require
different parameters in order to properly configure them. In the
case of RADIUS, this problem can be solved through the use of a
proxy which adds ISP- and NAS-specific attributes to the response
returned by ISP A's RADIUS server, with the result being that ISP
B's RADIUS proxy will provide the attributes necessary to config-
ure ISP B's NAS device, while ISP A's RADIUS server will perform
the actual user authentication. In order to support heterogene-
ity among providers within the roaming association, RADIUS prox-
ies must support attribute editing.
4.8. Address assignment/routing
Given that no existing roaming implementations support static address
assignment, a roaming standard need only concern itself with dynamic
address assignment.
However, static address assignment, if it is to be supported, will
most likely be accomplished via use of tunneling protocols such as
PPTP, L2F, or L2TP. These protocols hold great promise for the imple-
mentation of Virtual Private Networks as a means for inexpensive
access to remote networks. Therefore proxy implementations must not
preclude mandatory tunneling.
4.9. Security
Although network security is a very broad subject, in this paper we
will limit our attention to the problems of secure proxying and shared
secret management.
4.9.1. Requirements
What must a roaming standard do to be successful?
Secure proxying
One of the problems which arises from the dependency on a proxied
system of authorization is how to guarantee that the proxy will
properly forward the security-related parameters returned by the
remote server and that the NAS will enforce them. For example,
the user must not be allowed to authenticate using only CHAP or
PAP if the remote authorization server had returned attributes
indicating a requirement for token card use. Similarly, a user
must not be allowed access to the Internet if the remote autho-
rization server had returned attributes indicating a requirement
for a mandatory tunnel. As a result, RADIUS proxies must not
remove security-related parameters from responses.
Aboba & Zorn [Page 11]
INTERNET-DRAFT 26 November 1996
Shared secret management
A roaming standard must provide for efficient management of share
secrets. This is required since the RADIUS protocol requires a
shared secret between the NAS and the RADIUS server. This along
with authentication routing and timeout constraints are the
issues most limiting the scalability of roaming. In a proxy
implementation, this translates to shared secrets between the NAS
devices and the ISP proxy, and another set of shared secrets
between the ISP proxies and second level proxies or RADIUS
servers. Note that the issue of shared secret management is inti-
mately connected with authentication routing, since the routing
scheme determines the number of hops that must be traversed for
the authentication request to reach its destination. This in turn
influences the number of shared secrets that must be maintained
on each proxy or server.
4.10. Accounting
Today there is no proposed standard for how NAS accounting should be
accomplished, and there is wide variation in the protocols used by
providers to communicate accounting information within their own orga-
nizations. As a result, rather than requiring the use of a particular
accounting protocol (RADIUS, TACACS+, SNMP, SYSLOG, etc.), a roaming
standard will require that accounting records be generated in a stan-
dardized format and transmitted in a standardized way.
4.10.1. Accounting requirements
What must an accounting record format and transfer protocol do?
Identification of the settlement agent
Prior to setting up the accounting record transfer, the roaming
implementation must be able to determine who the records should
be sent to. .
Tagging and bagging
The transfer protocol must be able to tag and bag the transferred
records so as to identify the version and type of record being
transferred.
Accounting metrics
The account record format must be able to encode metrics commonly
used by Internet Service Providers to determine the user's bill.
Extensibility
Since these metrics change over time, the accounting record for-
mat must be extensible so as to be able to add future metrics as
Aboba & Zorn [Page 12]
INTERNET-DRAFT 26 November 1996
they come along. The record format must support both standard
metrics as well as vendor-specific metrics.
Encryption
For the sake of security, the record transfer protocol must pro-
vide for encrypted transfer of records via an encryption mecha-
nism that can be legally deployed in at least a minimal set of
countries.
Authentication
Also for the sake of security, the record must provide for sign-
ing of the accounting records, so as to assure their integrity
and authenticity. In addition, during the transfer process the
sender and receiver must mutually authenticate.
Compactness
For the sake of efficiency, the record format must be compact.
Robustness
The accounting transfer protocol must be capable of recovering
from a variety of faults, including partially completed transfers
and undecodable metrics.
Non-repudiation
Once an accounting record file has been transferred or processed,
the sender must be able to secure a receipt from the receiver.
4.10.1.1. Example accounting metrics
Examples of accounting metrics include:
User Name (String; the user's ID, including prefix or suffix)
NAS IP address (Integer; the IP address of the user's NAS)
NAS Port (Integer; identifies the physical port on the NAS)
Service Type (Integer; identifies the service provided to the user)
NAS Identifier (Integer; unique identifier for the NAS)
Delay Time (Integer; time client has been trying to send)
Input Octets (Integer; in stop record, octets received from port)
Output Octets (Integer; in stop record, octets sent to port)
Session ID (Integer; unique ID identifying the session)
Authentication (Integer; indicates how user was authenticated)
Session Time (Integer; in stop record, seconds of received service)
Input Packets (Integer; in stop record, packets received from port)
Output Packets (Integer; in stop record, packets sent to port)
Termination Cause (Integer; in stop record, indicates termination cause)
Multi-Session ID (String; for linking of multiple related sessions)
Link Count (Integer; number of links up when record was generated)
NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
Aboba & Zorn [Page 13]
INTERNET-DRAFT 26 November 1996
5. Acknowledgements
Thanks to Dr. Thomas Pfenning and Don Dumitru of Microsoft for many
useful discussions of this problem space.
6. References
[1] B. Aboba, L. Liu, J. Alsop, J. Ding. "Review of Roaming Imple-
mentations." draft-ietf-roamops-imprev-00.txt, Microsoft, Aimnet, i-
Pass Alliance, Asiainfo, September, 1996.
[2] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote
Authentication Dial In User Service (RADIUS)." draft-ietf-radius-
radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
[3] C. Rigney. "RADIUS Accounting." draft-ietf-radius-
accounting-05.txt, Livingston, July 1996.
[4] R. Braden. "Requirements for Internet hosts - application and
support." STD 3, RFC 1123, IETF, October 1989.
[5] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft-
zorn-radius-tunnel-auth-00.txt, Microsoft Corporation, October, 1996.
[6] B. Aboba. "Implementation of Mandatory Tunneling via RADIUS."
draft-aboba-radius-tunnel-imp-01.txt, Microsoft Corporation, October,
1996.
7. Authors' Addresses
Bernard Aboba
Microsoft Corporation
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 14]
