ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Standards Track Glen Zorn
<draft-ietf-roamops-roamreq-05.txt> Microsoft
11 July 1997
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-05.txt>, and expires January 1, 1998. 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" is defined as the ability to use any one of multiple
Internet service providers (ISPs), while maintaining a formal, cus-
tomer-vendor relationship with only one. Examples of cases where
roaming capability might be required include ISP "confederations" 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 11 July 1997
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 can
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 authentication/autho-
rization via the protocol described in [3], and for account-
ing as described in [4].
Aboba & Zorn [Page 2]
INTERNET-DRAFT 11 July 1997
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 (known
as the Network Access Identifier or NAI) and in the subse-
quent RADIUS authentication and accounting requests, can
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 [4] 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 speci-
fication.
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
Aboba & Zorn [Page 3]
INTERNET-DRAFT 11 July 1997
course, for the feature the option provides)
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."
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 ISP-
GROUP) 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. If desired by
BIGCO, additional security measures SHOULD be supported for
Fred's session. This could include support for smart cards,
cryptographic calculators, or one-time passwords.
Aboba & Zorn [Page 4]
INTERNET-DRAFT 11 July 1997
NAS configuration/authorization
The Network Access Server (NAS) MUST receive configuration param-
eters in order to set up Fred's session.
Security
A roaming standard must provide mechanisms for fraud prevention
and detection.
Address assignment/routing
Fred MUST be assigned a routable IP address by the NAS. Roaming
MUST also support tunneling using either layer 2 or layer 3 tun-
neling protocols.
Accounting
ISP B MUST keep track of what resources Fred used during the ses-
sion. Relevant information includes how long Fred used the ser-
vice, what speed he connected at, whether he connected via ISDN
or modem, etc.
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 can 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 [1], no
current roaming implementations provide for complete automation 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.
Aboba & Zorn [Page 5]
INTERNET-DRAFT 11 July 1997
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 are the requirements for a phone book update protocol?
Portability
The update protocol MUST allow for updating of clients on a range
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 MAY 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 can be a low-end PC, the update protocol
MUST be lightweight.
Language pport
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.
Aboba & Zorn [Page 6]
INTERNET-DRAFT 11 July 1997
4.4.2. Phone book format requirements
What are the requirements for a phone book format?
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.
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 will frequently be necessary to add phone book
attributes, the phone book format MUST support the addition of
phone number, provider and service attributes without modifica-
tion to the update protocol. Registration of new phone book
attributes will be handled by IANA. The attribute space MUST be
sufficiently large to accomodate growth.
Compactness
Since phone book will typically be frequently updated, the phone
book format MUST be compact so as to minimize the bandwidth used
in updating it.
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.
Given the current popularity and near ubiquity of PPP, a roaming stan-
dard MUST provide support for PPP. While an implementation MAY choose
to support other framing protocols such as SLIP, SLIP support is
Aboba & Zorn [Page 7]
INTERNET-DRAFT 11 July 1997
expected to prove difficult since SLIP does not support negotiation of
connection parameters and lacks support for protocols other than IP.
Support for non-IP protocols (e.g., IPX) MAY be useful for the provi-
sion of corporate intranet access via the Internet. Since it is
intended that the client will begin PPP negotiation immediately on
connection, support for scripting will not be part of a roaming stan-
dard.
4.6. Authentication
Authentication consists of two parts: the claim of identity (or iden-
tification) and the proof of the claim (or verification).
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).
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 authenti-
cation request to be routed its home destination. A roaming standard
must be provide a standardized format for the userID and realm pre-
sented to the NAS. This userID is also commonly known as the Network
Access Identifier (NAI).
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 creden-
tials, etc.) for special purposes (such as acquiring access to corpo-
rate intranets).
4.6.3. Requirements
What are the requirements for authentication?
Authentication types
A roaming standard MUST support CHAP, and SHOULD support EAP.
Due to concerns over security in chained proxy systems, PAP
authentication SHOULD NOT be supported. A possible exception is
where PAP is used to support a one time password or token.
RADIUS Support
Given the current popularity and near ubiquity of RADIUS, a roam-
ing standard MUST support RADIUS authentication as defined in
[2]. Other protocols MAY be supported. However, it is the
Aboba & Zorn [Page 8]
INTERNET-DRAFT 11 July 1997
responsibility of participating ISPs and/or software vendors to
produce gateways between those protocols and RADIUS.
Scalability
A roaming standard, once available, is likely to be widely
deployed on the Internet. A roaming standard MUST therefore pro-
vide sufficient scalability to allow for the formation of roaming
associations with thousands of ISP members.
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.
In order to ensure compatibility with the parameters of the NAS or the
local network, a RADIUS proxy MAY need to add, delete, or modify
attributes returned by the home RADIUS server. In addition, a RADIUS
proxy may need to performance resource management functions. In order
to ensure interoperability between RADIUS proxy implementations, a
roaming standard MUST provide guidance on acceptable RADIUS proxy
behavior.
4.8. Address assignment/routing
A roaming standard MUST support dynamic address assignment. Static
address assignment MAY be supported, most likely via layer 2 or layer
3 tunneling.
Layer 2 tunneling protocols
Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold
great promise for the implementation of Virtual Private Networks
as a means for inexpensive access to remote networks. Therefore
proxy implementations MUST NOT preclude use of layer 2 tunneling.
Support of compulsory tunneling via the RADIUS protocol is
described in [5] and [6].
Layer 3 tunneling protocols
Layer-3 tunneling protocols as embodied in Mobile IP, described
in [8], hold great promise for providing "live", transparent
mobility on the part of mobile nodes on the Internet. Therefore,
proxy implementations MUST NOT preclude the provision of Mobile
IP Foreign Agents or other Mobile IP functionality on the part of
service providers.
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
Aboba & Zorn [Page 9]
INTERNET-DRAFT 11 July 1997
secret management.
4.9.1. Requirements
What are the security requirements?
Security analysis
A roaming standard must include a thorough security analysis,
including a description of security threats and countermeasures.
End-to-end security
In a RADIUS proxy system, access responses are verified hop-by-
hop, rather than on an end-to-end basis. As a result, without
additional security measures, it is impossible to detect a man-
in-the middle attack by a rogue proxy. While end-to-end security
is not a requirement of a roaming standard, it MAY be provided as
an optional capability.
4.10. Accounting requirements
What are the accounting requirements for roaming?
Real-time accounting
In today's roaming implementations, real-time accounting is a
practical necessity in order to support fraud detection and risk
management. As a result, a roaming standard MUST provide support
for real-time accounting.
Accounting record formats
Today there is no proposed standard for NAS accounting, and there
is wide variation in the protocols used by providers to communi-
cate accounting information within their own organizations. As a
result, a roaming standard MUST prescribe a standardized format
for accounting records.
Accounting Metrics
A standard accounting record format MUST be able to encode met-
rics 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
they come along. The record format MUST support both standard
metrics as well as vendor-specific metrics.
Aboba & Zorn [Page 10]
INTERNET-DRAFT 11 July 1997
Compactness
For the sake of efficiency, the record format MUST be compact.
5. Acknowledgements
Thanks to Pat Calhoun of USR, Dr. Thomas Pfenning and Don Dumitru of
Microsoft for many useful discussions of this problem space.
6. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." Internet draft (work in progress), draft-ietf-
roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo,
Merit, June, 1997.
[2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April, 1997.
[3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April,
1997.
[4] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[5] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter-
net draft (work in progress), draft-ietf-radius-tunnel-auth-02.txt,
Microsoft, July, 1997.
[6] B. Aboba. "Implementation of PPTP/L2TP Mandatory Tunneling via
RADIUS." Internet draft (work in progress), draft-ietf-radius-tunnel-
imp-02.txt, Microsoft, July, 1997.
[7] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work
in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
[8] C. Perkins. "IP Mobility Support." RFC 2002, IBM, October, 1996.
7. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Aboba & Zorn [Page 11]
INTERNET-DRAFT 11 July 1997
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-703-1559
EMail: glennz@microsoft.com
Aboba & Zorn [Page 12]
