One document matched: draft-zorn-dial-roam-req-01.txt
Differences from draft-zorn-dial-roam-req-00.txt
Network Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-zorn-dial-roam-req-01.txt> Glen Zorn
30 June 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-
zorn-dial-roam-req-01.txt>, and expires January 4, 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 coporate 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 30 June 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 or L2F.
What is required to provide roaming capability to dialup users? The
following list is a first cut at defining the requirements for suc-
cessful 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
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.
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.
Aboba & Zorn [Page 2]
INTERNET-DRAFT 30 June 1996
Phone number exchange
When there is a change in the status of phone numbers (additions
or deletions) from individual providers, there must be a way for
providers in ISPGROUP to notify each other and propagate the
changes.
Phone book compilation
When these updates occur, there must be a way to compile a new
phone book for ISP A, based on the changes submitted by the indi-
vidual ISPs in ISPGROUP.
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 should 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 or L2F server for access to
the corporate intranet.
Accounting
ISP B must keep track of what resources Fred used during the ses-
sion. Relevant information might include how long Fred used the
service, 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 may include
Aboba & Zorn [Page 3]
INTERNET-DRAFT 30 June 1996
variances in the format of the client phone books, varying approaches
to presentation, etc. There is no inherent problem with this, as long
as the mechanisms by which phone number information is exchanged are
standardized and interoperable. The demands of phone number presenta-
tion have effects upon the phone book entries themselves, however, as
is illustrated below.
What information about individual numbers is needed to support the
presentation process? We can think of this information as including
various qualities associated with a given number (e.g., maximum sup-
ported speed, analog vs. ISDN, multicast capability, etc.), as well as
additional information specific to a given ISP such as their company
name, technical support number or icon.
4.1.1. Phone Number Presentation Issues
Issues relating to phone number presentation include:
Representation
How are the phone numbers represented within the phone book? What
information relating to the numbers is presented to the user?
Area grouping
We assume that, for convenience sake, it would be a good thing to
display to Fred only those phone numbers that are useful; the
phone numbers of access points in Northern Africa, for instance,
are of little use in Los Angeles. If this is true, how can it be
accomplished, given that users move around?
Number preference
What determines what numbers appear first in the list?
Primary and secondary numbers
Does the user select only a single number to call, or is there a
backup number?
Representation of external numbers
If the geographical coverage areas of two ISPs in the same group
overlap, how should they be differentiated, if at all? For exam-
ple, suppose that ISP C, another member of ISPGROUP, has some num-
bers in the same area as ISP A. Should ISP A be given better
"billing" than ISP C in the phone book, since Fred is A's cus-
tomer? If so, how should this be accomplished?
Cost
How are costs to be displayed to users? Is it necessary to propa-
gate information on the costs of individual numbers along with the
numbers themselves, or would something like a help file suffice?
Metrics
What information about individual numbers do users want to see?
As additional characteristics are added, how do we ensure that
this information can also be displayed?
Aboba & Zorn [Page 4]
INTERNET-DRAFT 30 June 1996
4.2. Phone Number Exchange
Phone number exchange involves propagation of phone number changes
between providers. In order for the providers in ISPGROUP to be able
to exchange phone book entries with each other, it essential that they
be able to interoperate. As a result, we believe there is a need to
standardize the phone number exchange protocol. What will the phone
number exchange protocol look like between an ISP's phone book server
and the Designated Server? The update messages are likely to be
fairly simple, consisting of ADD or DELETE messages along with
attribute/value pairs. These pairs will describe characteristics of
the phone number in question, such as its maximum speed, whether it is
ISDN or modem, whether it is multicast capable, etc.
4.2.1. Protocol Design Issues
Issues involved in the design of the phone number exchange protocol
include:
Phone book server discovery
How do the phone book servers of the roaming partners find each
other? While manual configuration will probably work fine as long
as ISPGROUP remains small, if ISPGROUP grows large, this could
rapidly become unwieldy.
Selection of the Designated and Backup Designated Servers
Rather than asking each provider in ISPGROUP to contact every
other provider, it makes sense to have the providers contact a
Designated Server in order to transmit their updates. The
Designed Server would then propagate the changes out to the indi-
vidual ISP phone book servers, in much the same way as this is
handled in OSPF. If the Designated Server became unavailable, a
Backup Designated Server would be used; the two servers would need
to stay synchronized.
Versioning
How do different versions of the phone book exchange protocol
interoperate?
Security
How do the interacting phone book servers prove their identities
to each other and secure the conversation?
Conversation turnaround
How do the interacting phone book servers decide who will be the
master of the conversation, and how do they then turn the conver-
sation around so each side can transmit their updates to the
other?
Duplicate elimination
How are the phone number entries uniquely identified so that
duplicate entries are eliminated? It may not be sufficient to
automatically kill identical phone numbers, since it is
Aboba & Zorn [Page 5]
INTERNET-DRAFT 30 June 1996
conceivable that two identical numbers may have different scripts
associated with them. Mechanisms for ensuring elimination of
duplicates might include generation of a unique phonebook entry
ID, and inclusion of a path attribute.
Synchronization
How often do phone book servers transmit their updates, and how do
we guard against excessively frequent updates (phone number
flaps)?
Failure recovery
If a phone number exchange fails part way through, how should
recovery be managed?
4.2.2. Phone Number Attributes
Since vendors may differ in what information is presented to the user,
it is probably a good idea to distinguish between required and
optional attributes for each phone number, and provide a mechanism for
registering optional (and possibly vendor specific) attributes. That
way vendors can extend the protocol (for example, to indicate whether
a given number supports multicast). Clients encountering unrecognized
optional attributes should ignore them; however, it is important to
ensure that the mandatory attribute set is sufficiently rich to sup-
port subsequent phone book preparation and phone number presentation.
4.2.2.1. Attribute Specification Issues
Issues involved with attribute specification include:
Phone number characteristics
What information is to be propagated relating to each phone num-
ber, in order to assist the user in choosing the "best" one? How
do we allow for addition of optional attributes?
Scripting
Is support for a script attribute required, since some ISPs may
require execution of a login script?
Origin attribute
The origin attribute distinguishes between numbers provided by the
"home" ISP (in Fred's case, ISP A) and numbers obtained from
external sources, such as other ISPs in the confederation. This
would be useful in providing the ability to differentiate between
numbers based on source in the client software.
Cost attribute
Since prices may be expressed in different currencies and rates
are likely to change frequently, it is probably undesirable to
propagate a cost attribute along with other metrics. Will users
find the absence of this information acceptable?
Aboba & Zorn [Page 6]
INTERNET-DRAFT 30 June 1996
4.3. Phone Book Compilation
Once an ISP's phone book server has received it updates from the Des-
ignated Server it needs to compile a new phone book and propagate this
phone book to all the phone book servers operated by that ISP. In the
case of ISPs whose service areas are not geographically overlapped,
this process can be quite simple. In this case the phone book will
typically consist of a list of all the numbers obtained in the update
process. Therefore, the compiled phone book will be the same for each
ISP in the ISPGROUP and the same phone book can be used by every phone
book server operated by the ISPs in ISPGROUP. This greatly simplifies
the process, since it implies that only the Designated and Backup Des-
ignated Phone Book Servers need to do the compilation, and can then
replicate the result to all other servers in ISPGROUP. As a result, a
user would be able to access any of the phone book servers from any of
the ISPs in ISPGROUP when updating their phone book.
4.3.1. Policy-based Phone Books
If the ISPs overlap in geography, however, things are more compli-
cated. In this case, an individual ISP may wish to implement policy-
based phonebooks.
Examples of phonebook policies include:
Excluding all phone numbers from a given ISP
Including only those external phone numbers not overlapping in
calling area with internal phone numbers
Excluding external phone numbers from a given city,
state/province, or country
Giving preferential listings to internal phone numbers, then to
phone numbers from ISP B, then to phone numbers from other exter-
nal sources.
Implementation of policy-based phone books will require considerable
additional work in order to define the possible policy rules and their
implementation during the compilation process. Please also note that
if the policies of the providers in ISPGROUP differ from one another,
then the phone books compiled by the providers will differ. This
introduces considerable complexity into the compilation and propaga-
tion process.
4.3.2. Standardization Requirements
The compilation process probably does not need to be standardized,
except as it impacts on the phone number exchange protocol. For exam-
ple, there may be a need to specify how tags imported from the phone
number exchange process should be stored during compilation, and sub-
sequently exported.
Aboba & Zorn [Page 7]
INTERNET-DRAFT 30 June 1996
4.4. Phone Book Update
Once the phone book is compiled, it needs to be propagated out to cus-
tomers. The phone book update process is considerably simpler than
that for phone book exchange. This is because the clients can receive
the addresses of their default and backup phone book servers during
the process of registering for service; thus there is less of a need
for autodiscovery. Also, data transfer is one-way, from the Phone
Book server to the client, so a simple version numbering scheme should
be adequate to ensure that the client has the latest version.
Finally, there is little need to authenticate the client to the
server, only for the server to prove its identity to the client.
These simplifying attributes allow the Phone Book update process to be
handled using existing protocols such as HTTP, with security issues
being handled via SSL, PCT or S/HTTP. Since the client machine may in
many cases be a very small PC, it is important to keep the update pro-
tocol as lightweight as possible.
4.4.1. Standardization Requirements
It is probably desirable to standardize some aspects of the phone book
update process, so as to allow providers to update user phone books
regardless of what client software the customer has installed. The
level of standardization desirable is an open question.
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. Although it may also be possible (depending on the
phone number and ISP chosen) to gain access to the network via SLIP,
we feel SLIP is not practical for use in roaming situations since it
does not support negotiation of connection parameters and lacks sup-
port 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. As a result, we feel that PPP is the only viable
dialup protocol for use in roaming situations.
4.5.1. Standardization Requirements
All necessary standards activity in this area is being undertaken by
the IETF PPP Extensions Working Group.
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 30 June 1996
4.6.1. Identification
As part of the authentication process, users identify themselves to
the Network Access Server (NAS). This identification may be name-
based (as in the classic user ID/password scheme) or it may be based
on the telephone number from which the call is made.
4.6.1.1. Name-based Identification
If the NAS in question is dedicated to the use of the customers of the
ISP which operates it, this identification might be as simple as a
flat user ID (e.g., "aboba" or "zorn"). If, however, the NAS is
expected to be able to authenticate users from other ISPs (such as the
members of ISPGROUP), some means must be provided to correctly route
authentication requests to the appropriate authentication server.
4.6.1.1.1. Authentication Request Routing
ISPs offering their networks for resale (or shared use, as in the case
of ISPGROUP) today frequently implement user IDs including a prefix
("MS/aboba") or suffix "aboba@isbu.microsoft.com") specifying the
user's customer affiliation in order to allow authentication to occur
against foreign authentication servers or account databases. This
method provides simple routing of both authentication requests and
accounting data. Note that, although the following discussion uses
RADIUS as the authentication protocol, other protocols should work as
well. 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". 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.
The proxy in turn will examine the user ID suffix, check whether the
given suffix represents a authorized authentication domain for roam-
ing, and then pass the request on to the appropriate RADIUS server.
The mapping between the user's domain and their RADIUS server can be
accomplished through either a configuration file on the proxy or DNS
resolution. For example, RADIUS requests going to ispa.com might be
directed to the server auth.ispa.com. Note that in order to authorize
Fred, the RADIUS server receiving the request from the proxy needs to
check both the user ID and the domain represented by the suffix. This
is to guard against possible misconfiguration of the proxy. Requests
coming in with incorrect suffices should probably result in a message
sent to the technical representative of the proxy's domain.
4.6.1.2. Telephone Number-based Identification
Today there exist ISPs that do not require a network layer authentica-
tion, instead handling authorization and accounting based on the
Aboba & Zorn [Page 9]
INTERNET-DRAFT 30 June 1996
calling phone number. For the case of a user roaming to an ISP that
implements telephone-number based billing, if an existing relationship
occurs between the phone number owner (say, a hotel) and the ISP, then
network access, accounting, and billing can often be simplified. Via
the hotel, the user is charged for the resulting 900 number call, and
the hotel in turn reimburses the ISP. For the case of a user with a
telephone-based billing account roaming to an ISP that requires a net-
work layer authentication, the issues are more complex, particularly
if the user's software is not set up to handle a network layer authen-
tication. At this point, the importance of this issue is an open
question.
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). It is outside the scope of this document to describe
all the authentication protocols extent, but we believe that the
widest possible range of authentication technologies should be sup-
ported for roaming to be successful.
4.6.3. Standardization Requirements
Other than the shared secrets issue discussed below, the authentica-
tion issue is being adequately addressed by the efforts of various
IETF Working Groups.
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. However, it is possible that ISP A and ISP B's NAS
devices are from different vendors; even if they are from the same
vendor, ISP A and ISP B may use different 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 configure ISP B's NAS device, while ISP A's RADIUS server
will perform the actual user authentication.
4.7.1. Standardization Requirements
Since the NAS configuration function is provided by the RADIUS and
TACACS+ protocols, we do not believe there is a need for additional
standardization efforts in this area.
Aboba & Zorn [Page 10]
INTERNET-DRAFT 30 June 1996
4.8. Security
Although network security is a very broad subject, in this paper we
will limit our attention to a few topics which seem most relevant to
the problem of dialup roaming. These issues include trust, secure
tunneling and scalability.
4.8.1. Trust
One of the problems which arises from the dependency on a proxied sys-
tem 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, it would probably be
unacceptable for the NAS to allow a user to authenticate using only
CHAP or PAP if the remote authorization server had returned attributes
indicating a requirement for token card use. Unfortunately, we have
no idea how (or if it is possible, in the general case) to guarantee
this compliance. Probably the best that can be done at this time is
to specify that proxies must not remove security-related parameters
from responses and require that NAS devices refuse access if they do
not support an attribute which is required for a given user.
4.8.2. Secure Tunneling
Several tunneling protocols (notably PPTP and L2F) have been proposed
for use in dialup environments. The protocols hold great promise for
the implementation of Virtual Private Networks as a means for inexpen-
sive access to remote networks.
4.8.2.1. Standardization Requirements
Both PPTP and L2F are documented in Internet-Drafts. While we feel
that there is a need for standardization in this area, and perhaps for
convergence between these two approaches, we do not feel any new tun-
neling protocol development is needed for solution of the roaming
problem. However, it does appear that there is a need for specifica-
tion of how these tunneling protocols will be integrated with advanced
authentication methods (such as smart cards) and NAS authentica-
tion/authorization protocols, particularly with respect to authentica-
tion request routing (see above).
4.8.3. Scalability
Another issue relating to security is the management of shared
secrets. This is probably the issue that most limits scalability of
roaming. In order for ISPGROUP to grow beyond a small number of ISPs
(say, 5-10) something will have to be done about the existing RADIUS
shared secret mechanism. The RADIUS protocol requires a shared secret
between the NAS and the RADIUS server. In a proxy implementation,
this translates to shared secrets between the NAS devices and the
Aboba & Zorn [Page 11]
INTERNET-DRAFT 30 June 1996
proxy, and another set of shared secrets between the proxy and the
RADIUS servers. In a roaming situation, this means that we could
potentially have a shared secret for each proxy/server pair. Assuming
that each ISP runs a proxy as well as a server, this translates to n2
shared secrets, where n is the number of ISPs in ISPGROUP. This is in
addition to m shared secrets for the NAS/proxy combinations, where m
is the total number of NAS devices operated by all the ISPs in ISP-
GROUP. Given this, it is fairly easy to see how the shared secret
management problem could easily get out of hand. One way to address
this issue would be to require assignment of public key pairs to the
NAS devices, RADIUS proxies and RADIUS servers. However, this would
require implementation of a key distribution mechanism, which is not
expected to arrive until the implementation of secure DNS. Also, the
use of public-key cryptography is likely to impose an unacceptable
computational burden on the NAS. This is really a key management
issue, though, rather than a cryptographic one. By simply requiring
that all proxies share the same key with any given server, the number
of keys in use can be drastically reduced, albeit at the cost of some
security.
4.9. Accounting
Given that Fred identifies himself as "fred@ispa.com" in order to
login to ISP B, and assuming that ISP B's NAS devices implement an
accounting protocol (RADIUS, TACACS+, SNMP, syslog, etc.), an account-
ing record will then be generated which will summarize Fred's resource
consumption during the session. This record should be provided in a
standardized format, and transmitted to an appropriate location. In
order to allow the ISPs in ISPGROUP to exchange accounting informa-
tion, it is clear that there is a need to standardize the accounting
record format, as well as the manner in which these records are trans-
mitted among providers. However, as long as the NAS devices only need
to communicate with accounting servers within their own organization,
it is not as clear that the accounting protocol must itself be stan-
dardized. This is because the accounting protocol will only be used
as a means of communicating accounting information within an individ-
ual ISP's organization. To standardize communication between
providers it will suffice to generate accounting records in a defined
format and transmit them in a standardized way. Thus, it would not
matter what protocol the NAS uses to provide accounting information
(i.e. RADIUS accounting, TACACS+, SNMP, syslog, etc.), as long as the
required records are generated and transmitted in a secure fashion.
5. Acknowledgements
Thanks to Dr. Thomas Pfenning and Don Dumitru of Microsoft for many
useful discussions of this problem space.
Aboba & Zorn [Page 12]
INTERNET-DRAFT 30 June 1996
6. 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 13]
| PAFTECH AB 2003-2026 | 2026-04-23 02:28:18 |