Review of Roaming Implementations
draft-ietf-roamops-imprev-03
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2194.
|
|
|---|---|---|---|
| Authors | Juan Lu , John Alsop , James Ding , Dr. Bernard D. Aboba , Wei Wang | ||
| Last updated | 2013-03-02 (Latest revision 1997-06-10) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 2194 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-roamops-imprev-03
ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Informational Juan Lu
<draft-ietf-roamops-imprev-03.txt> AimQuest Corp.
10 June 1997 John Alsop
i-Pass Alliance
James Ding
Asiainfo
Wei Wang
Merit Network, Inc.
Review of Roaming Implementations
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-imprev-03.txt>, and expires January 1, 1998. Please
send comments to the authors.
2. Abstract
This document reviews the design and functionality of existing roaming
implementations. "Roaming capability" may be loosely defined as the
ability to use any one of multiple Internet service providers (ISPs),
while maintaining a formal, customer-vendor relationship with only
one. Examples of cases where roaming capability might be required
include ISP "confederations" and ISP-provided corporate network access
support.
Aboba, Lu, Alsop, Ding & Wang [Page 1]
INTERNET-DRAFT 10 June 1997
3. Introduction
Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for 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 service 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
service in a group of countries or on a continent.
Businesses desiring to offer their employees a comprehensive
package of access 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 is required to provide roaming capability? The following list is
a first cut at defining the requirements 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 and routing
Security
Accounting
In this document we review existing roaming implementations, describ-
ing their functionality within this framework. In addition to full
fledged roaming implementations, we will also review implementations
that, while not meeting the strict definition of roaming, address sev-
eral of these problem elements. These implementations typically fall
into the category of shared use networks or non-IP dialup networks.
3.1. Terminology
This document frequently uses the following terms:
home ISP This is the Internet service provider with whom the user
maintains an account relationship.
local ISP This is the Internet service provider whom the user calls in
order to get access. Where roaming is implemented the local
Aboba, Lu, Alsop, Ding & Wang [Page 2]
INTERNET-DRAFT 10 June 1997
ISP may be different from the home ISP.
phone book
This is a database or document containing data pertaining to
dialup access, including phone numbers and any associated
attributes.
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
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 may 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.
non-IP dialup network
This is a dialup network providing user access to the member
systems via protocols other than IP. These networks may
implement phone book synchronization facilities, in order to
provide systems, administrators and users with a current
list of participating systems. Examples of non-IP dialup
networks supporting phone book synchronization include
FidoNet and WWIVnet.
4. Global Reach Internet Consortium (GRIC)
Led by a US-based Internet technology developer, AimQuest Corporation,
ten Internet Service Providers (ISPs) from the USA, Australia, China,
Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the
Global Reach Internet Connection (GRIC) in May, 1996. The goals of
GRIC were to facilitate the implementation of a global roaming service
and to coordinate billing and settlement among the membership. Commer-
cial operation began in December of 1996, and GRIC has grown to over
50 major ISPs and Telcos from all over the world, including NETCOM,
USA; KDD and Mitsubishi, Japan; iStar, Canada; Easynet, UK; Con-
nect.com, Australia; Iprolink, Switzerland; Singapore Telecom;
Chunghwa Telecom, Taiwan; and Telekom Malaysia. Information on GRIC
is available from http://www.gric.net/.
In implementing their roaming service, GRIC members have chosen soft-
ware developed by AimQuest. AimQuest Corporation's roaming implementa-
tion comprises the following major components: the AimTraveler Authen-
tication Server (AAS), the AimTraveler Routing Server (ARS), and the
AimQuest Internet Management System (AIMS), software designed to
Aboba, Lu, Alsop, Ding & Wang [Page 3]
INTERNET-DRAFT 10 June 1997
facilitate the billing process. Information on the AimQuest roaming
implementation is available from http://www.aimquest.com/.
The AimTraveler Authentication Server (AAS) runs at each member ISP
location, and handles incoming authentication requests from NAS
devices. The AimTraveler Routing Server (ARS) can run anywhere. A sin-
gle routing server can be used where centralized routing is desired,
or multiple routing servers can be run in order to increase speed and
reliability or to gateway to networks of particularly large partners.
The first version of the AimTraveler software, deployed by AimQuest in
May, 1996, supported direct authentication between members of the
roaming consortium, but as GRIC grew, management of the relationships
between the authentication servers became a problem. In August. 1996,
AimQuest began development of the AimTraveler Routing Server (ARS) in
order to improve scalability.
The routing server is comprised of two elements: The Central Account-
ing Server and the Central Routing Server. The Central Accounting
Server collects all the roaming accounting data for settlement. The
Central Routing Server manages and maintains information on the
authentication servers in the roaming consortium. Adding, deleting, or
updating ISP authentication server information (e.g. adding a new mem-
ber ISP) may be accomplished by editing of a configuration file on the
Central Routing Server. The configuration files of the AimTraveler
Authentication Servers do not need to be modified.
The AimTraveler Authentication and Routing Servers are available for
various UNIX platforms. Versions for Windows NT are under development.
The AimTraveler Authentication Server supports both the UNIX password
file and Kerberos.
The AimQuest Internet Management System (AIMS) is designed for large
ISPs who need a centralized management system for all ISP operations,
including sales, trouble-ticketing, service, and billing. AIMS pro-
duces usage and transaction statement reports, and includes a settle-
ment module to produce settlement/billing reports for the roaming con-
sortium members. Based on these reports, the providers charge their
ISP/roaming customers, and pay/settle the roaming balance among the
providers. AIMS currently runs on Sun/Solaris/Oracle. A version for
Windows NT and SQL Server is expected to become available in Q4 1996.
4.1. Phone number presentation
Currently there are two principal methods by which GRIC users can dis-
cover available phone numbers: a Web-bsed directory provided by the
GRIC secretariat, and an automatically updated phone book supported by
the AimQuest Ranger software.
4.1.1. Web based directory
A directory of GRIC phone numbers is available on the GRIC home page,
http://www.gric.com/. The list of numbers is arranged by country and
Aboba, Lu, Alsop, Ding & Wang [Page 4]
INTERNET-DRAFT 10 June 1997
provider. For each provider within a country, this directory, provided
in the form of a table, offers the following information:
Provider address, voice phone and fax
Customer support phone number
Provider domain name
Primary Domain Name Server
Secondary Domain Name Server
Dial-up IP Address
News server
Web page
POP phone numbers (i.e. 1-408-366-9000)
POP locations (i.e. Berkeley)
Proxy addresses
Dialer configuration
In order to discover phone numbers using the Web-based directory, it
is expected that users will be online, and will navigate to the appro-
priate country and provider. They then look up the number and insert
it into the AimQuest Ranger dialer.
4.1.2. AimQuest Ranger phone book
The AimQuest Ranger software provides for phone book presentation as
well as automated updating of phone numbers. The AimQuest Ranger
phone book includes a country list, provider list, and POP (phone num-
ber) list, as well as detailed provider information, including the
cutomer support phone number, and Internet server configuration info.
The Phone book, developed with Microsoft VC++, is available for down-
load from the AimQuest ftp site:
ftp://ftp.Aimnet.com/pub/traveler/isppb.ini
ftp://ftp.Aimnet.com/pub/traveler/isppb.exe
A copy of the phone book is also available from the GRIC phone book
page, available at http://www.gric.com/.
4.2. Phone number exchange
GRIC members submit information both about themselves and their POPs
to the GRIC secretariat, which is run by AimQuest. The GRIC secre-
tariat then compiles a new phone book and provides updates on the GRIC
FTP and Web servers.
GRIC users then download the phone numbers either in Windows .ini file
format (viewable via the AimQuest Ranger phone book), or in HTML
(viewable via a Web browser).
Aboba, Lu, Alsop, Ding & Wang [Page 5]
INTERNET-DRAFT 10 June 1997
4.3. Phone book compilation
GRIC phone books are compiled manually, and represent a concatenation
of available numbers from all the members of the roaming consortium,
with no policy application. As new POPs come online, the numbers are
forwarded to GRIC, which adds them to the phone book servers.
4.4. Phone book update
Phone numbers in the AimQuest Ranger phone book are updated automati-
cally. The AimTraveler server includes an address book which contains
the phone numbers of all the roaming consortium members.
4.5. Connection management
The AimTraveler and AimQuest Ranger software supports SLIP and PPP, as
well as PAP and CHAP authentication.
4.6. Authentication
GRIC implements distributed authentication, utilizing the user's e-
mail address as the userID (i.e. "liu@Aimnet.com") presented to the
remote NAS device. The AimQuest Ranger software takes care of present-
ing the e-mail address as the userID for PAP or CHAP authentication.
After the initial PPP authentication exchange, the userID, domain, and
pasword information (or in the case of CHAP, the challenge and the
response) are then passed by the NAS to the AimTraveler Authentication
Server which supports both TACACS+ and RADIUS.
If the authentication request comes from a regular customer login,
normal user id and password authentication is performed. If the user
requesting authentication is a "roamer," (has a userID with an @ and
domain name), the authentication server sends an query to the closest
routing server. When AimTraveler Routing Server receives the authenti-
cation request, it first authenticates the AAS sending the request,
and if this is successful, it checks its authentication server table.
If it is able to match the domain of the user to that of a "Home ISP",
then the Home ISP authentication server's routing information are sent
back to the local ISP's authentication server. Based on the informa-
tion received from the routing server, the AAS makes an authenti-
cation request to the user's Home ISP AAS for user id and pass-
word verification.
If the user is a valid user, the Home ISP authentication server sends
a "permission granted" message back to the Local ISP authentication
server. The Local ISP authentication server then requests the NAS to
grant the user a dynamic IP address from its address pool. If the
username or password is incorrect, the Home ISP AAS will send a rejec-
tion message to the Local ISP AAS, and the user will be dropped by the
NAS.
Aboba, Lu, Alsop, Ding & Wang [Page 6]
INTERNET-DRAFT 10 June 1997
If multiple routing servers are installed, and the query to the first
routing server does not result in a match, the query is forwarded to
the next routing server. The server queries are cached on the routing
servers, improving speed for repeated queries. The cache is sustained
until a routing server table entry is updated or deleted. Updating or
deleting results in a message to all neighbor routing servers to
delete their caches.
The local authentication server also receives the accounting data from
the NAS. If the data is for a regular customer login, the data is
written to the Local ISP AAS log file. If the data is for a "roamer,"
the data is written to three places: the Local ISP AAS log file, the
Home ISP AAS log file, and the ARS log file.
If the local ISP authentication server has caching turned on, then it
will cache information on Home ISP authentication server configura-
tions sent by the routing server. This means that if the same domain
is queried again, the local authentication server does not need to
query the routing server again. The local cache is cleared when the
local authentication server receives an update message from the rout-
ing server or system manager.
4.7. NAS Configuration/Authorization
AimTraveler is comprised of two components, a Client(AAS) and a
Server(ARS).
The AimTraveler Client acts as the PPP dial-up authentication server.
When it detects an '@' sign in the userID field, it queries the
AimTraverler Server for routing information, then forwards the
authentication request to user's home authentication server. The Aim-
Traveler Server, a centralized routing server, contains the autho-
rized ISP's domain name, authentication servers and other informa-
tion.
The AimTraveler currently supports RADIUS and TACACS+, and could
be extended to support other authentication protocols. It also
receives all the accounting records, which are subsequently used as
input data for billing.
Since ISPs' NAS devices may be configured differently, the attributes
returned by the home ISP AAS are discarded.
4.8. Address assignment and routing
All addresses in GRIC are assigned dynamically from within the address
pool of the local ISP. Static addresses and routed LAN connections
will be considered in the future, when GRIC offers corporate roaming
service.
Aboba, Lu, Alsop, Ding & Wang [Page 7]
INTERNET-DRAFT 10 June 1997
4.9. Security
The user's password is hashed with MD5 before being sent from the
Local ISP AAS to the Home ISP AAS. An encryption key is shared
between the AAS and ARS. The current version of AimTraveler AAS does
not support token cards or tunneling protocols.
4.10. Accounting
The AimTraveler Authentication Server (AAS) software can act as either
a RADIUS or TACACS+ accounting server. When accounting information is
received from the NAS, the local AimTraveler Authentication Server
(AAS) sends accounting data (user name, domain name, login time) to
both the Central Accounting Server (part of the ARS) and the user's
Home ISP AimTraveler authentication server. In the case of GRIC, the
Central Accounting Server is run by AimQuest.
The data sent to the central accounting server and home ISP are iden-
tical except for the form of user id and time stamp. For a traveler
whose home ISP is in the US, but who is traveling in Japan, the Local
(Japanese) ISP AimTraveler authentication server will receive an
accounting record timestamped with Japan time while the Home (US) ISP
AimTraveler authentication server will receive an accounting record
timestamped with the appropriate US timezone.
The accounting data includes 2 new attributes for settlement report-
ing:
Attribute Number Type
--------- ------ ----
Roaming-Server-ID 101 string
Isp-ID 102 string
The Roaming-Server-ID attribute identifies the AAS sending the authen-
tication request. The Isp-ID attribute identifies the local ISP.
Using this information the home ISP can track the roaming activities
of its users (where their users are logging in).
The AimTraveler Server running at AimQuest keeps a record of all
roaming transactions, which are used as input to the settlement and
billing process. At the end of each month, AimQuest provides a roam-
ing transaction summary to GRIC members using AIMS. The AIMS software
is configurable so that it takes into account the settlement rules
agreed to by GRIC members.
5. i-Pass implementation
Aboba, Lu, Alsop, Ding & Wang [Page 8]
INTERNET-DRAFT 10 June 1997
5.1. Overview
i-Pass Alliance Inc., based in Mountain View, California, has devel-
oped and operates a commercial authentication and settlement clearing-
house service which provides global roaming between Internet service
providers. The service is fully operational.
i-Pass Alliance Inc. has additional offices in Toronto, Singapore, and
London. More information on i-Pass can be obtained from
http://www.ipass.com.
The i-Pass network consists of a number of servers that provide real-
time authentication services to partner ISPs. Authentication requests
and accounting records for roaming users are encrypted and sent to an
i-Pass server where they are logged, and then forwarded to a home ISP
for authentication and/or logging.
Periodically, i-Pass reconciles all accounting records, generates
billing statements, and acts as a single point for collecting and
remitting payments.
i-Pass provides its service only to ISPs and channel partners. It
does not attempt to establish a business relationship with individual-
user customers of an ISP.
5.2. Access Point Database (APD)
i-Pass maintains a list of roaming access points in an Oracle
database. This list is searchable by geographical region using a Web
browser, and may be downloaded in its entirety using FTP. The informa-
tion stored for each access point includes:
Name of service provider
Country
State or Province
City or Region
Telephone number
Technical support phone number
Service types available
Technical information (help file)
Service pricing information
The Access Point Database is maintained by i-Pass staff, based on
input from i-Pass partners.
5.3. Phone number presentation
i-Pass has developed a Windows application wth a simple point and
click interface called the "i-Pass Dial Wizard", which assists end-
users in selecting and connecting to a local Internet access point.
Aboba, Lu, Alsop, Ding & Wang [Page 9]
INTERNET-DRAFT 10 June 1997
The Dial Wizard allows users to first select the country in which they
are roaming. A list of states, provinces, or other regions in the
selected country is then presented. Finally a list of access points
within the state or province is presented. The Dial Wizard displays
the city name, modem phone number, and price information for each
access point within the state or region.
When the user selects the desired access point, a Windows 95 "DialUp
Networking" icon is created for that access point. If there is a
login script associated with the access point, the DialUp Scripting
tool is automatically configured. This means that end-users never
have to configure any login scripting requirements.
The Dial Wizard has a built-in phonebook containing all the i-Pass
access points. The phonebook may be automatically refreshed from a
master copy located onhe ISPs web site.
The Dial Wizard is provided free of charge to i-Pass partners. i-Pass
also provides the i-Pass Dial Wizard Customization Kit which allows
ISP partners to generate customized versions of the Dial Wizard with
their own logo, etc.
5.4. Authentication
There are three entities involved in servicing an authentication
request:
Local ISP At the local ISP, the authentication server is modified to
recognize user IDs of the form username@auth_domain as being
remote authentication requests. These requests are for-
warded to an i-Pass server.
i-Pass Server
The i-Pass server receives the authentication request, logs
it, and forwards it to the home ISP identified by the
auth_domain portion of the user ID.
Home ISP The home ISP receives the authentication request, performs
authentication using its normal authentication method, and
returns a YES/NO response to the i-Pass server, which in
turn forwards the reply to the originating ISP.
i-Pass provides software components which run on the authentication
servers of the local and home ISPs. Each member ISP must integrate
these components with the native authentication method being used by
the ISP. To simplify this task, i-Pass has developed "drop-in" inter-
faces for the most commonly used authentication methods. At the date
of writing, the following interfaces are supported:
Livingston RADIUS
Aboba, Lu, Alsop, Ding & Wang [Page 10]
INTERNET-DRAFT 10 June 1997
Ascend RADIUS
Merit RADIUS
TACACS+
Xylogics erpcd (Versions 10 and 11)
A generic interface is also provided which authenticates based on the
standard UNIX password file. This is intended as a starting point for
ISPs using authentication methods other than those listed above.
The software integration effort for a typical ISP is on the order of
2-5 man-days including testing. Platforms currently supported
include:
Solaris 2.5 (Sparc).LI
Solaris 2.5 (Intel)
BSDI
Digital Unix
Linux
HP/UX
ISPs may chooe to provide authentication for their end-users roaming
elsewhere, but not to provide access points to the i-Pass network. In
this case the software integration effort is greatly reduced and can
be as little as 1/2 a man-day.
5.5. Accounting
Accounting transactions are handled in the same way as authentication
requests. In addition to being logged at the i-Pass servers, account-
ing transactions are sent in real-time to the home ISP. This is
intended to allow ISPs to update users' credit limit information on a
real-time basis (to the extent that this capability is supported by
their billing and accounting systems).
Settlement is performed monthly. The settlement process involves cal-
culating the costs associated with each individual session, and aggre-
gating them for each ISP. A net amount is then calculated which is
either due from i-Pass to the ISP, or from the ISP to i-Pass, depend-
ing on the actual usage pattern.
The following reports are supplied to member ISPs:
A Monthly Statement showing summaries of usage,
service provided, and any adjustments along with the
net amount owing.
A Call Detail Report showing roaming usage by the ISP's
customers.
A Service Provided report showing detailed usage of
the ISP's facilities by remote users.
The above reports are generated as ASCII documents and are distributed
Aboba, Lu, Alsop, Ding & Wang [Page 11]
INTERNET-DRAFT 10 June 1997
to i-Pass partners electronically, either by e-mail or from a secure
area on the i-Pass web site. Hard-copy output is available on request.
The Call Detail Report is also generated as a comma-delimited ASCII
file suitable for import into the ISP's billing database. The Call
Detail Report will normally be used by the ISP to generate end-user
billing for roaming usage.
5.6. Security
All transactions between ISPs and the i-Pass servers are encrypted
using the SSL protocol. Public key certificates are verified at both
the client and server. i-Pass issues these certificates and acts as
the Cetificate Authority.
Transactions are also verified based on a number of other criteria
such as source IP address.
5.7. Operations
i-Pass operates several authentication server sites. Each site con-
sists of two redundant server systems located in secure facilities and
"close" to the Internet backbone. The authentication server sites are
geographically distributed to minimize the possibility of failure due
to natural disasters etc.
i-Pass maintains a Network Operations Center in Mountain View which is
staffed on a 7x24 basis. Its functions include monitoring the i-Pass
authentication servers, monitoring authentication servers located at
partner facilities, and dealing with problem reports.
6. ChinaNet implementation
ChinaNet, owned by China Telecom, is China's largest Internet back-
bone. Constructed by Asiainfo, a Dallas based system integration com-
pany, it has 31 backbone nodes in 31 Chinese provincial capital
cities. Each province is building its own provincial network, has its
own dialup servers, and administers its own user base.
In order to allow hinaNet users to be able to access nodes outside
their province while traveling, a nationwide roaming system has been
implemented. The roaming system was developed by AsiaInfo, and is
based on the RADIUS protocol.
6.1. Phone number presentation
Since China Telecom uses one phone number (163) for nationwide Inter-
net access, most cities have the same Internet access number. There-
fore a phone book is not currently required for the ChinaNet implemen-
tation. A web-based phone book will be added in a future software
release in order to support nationwide ISP/CSP telephone numbers and
Aboba, Lu, Alsop, Ding & Wang [Page 12]
INTERNET-DRAFT 10 June 1997
HTTP server addresses.
6.2. Connection management
The current roaming client and server supports both PPP and SLIP.
6.3. Address assignment and routing
ChinaNet only supports dynamic IP address assignment for roaming
users. In addition, static addresses are supported for users authenti-
cating within their home province.
6.4. Authentication
When user accesses a local NAS, it provides its userID either as
"username" or "username@realm". The NAS will pass the userID and
password to the RADIUS proxy/server. If the "username" notation is
used, the Radius proxy/server will assume that the user is a local
user and will handle local authentication accordingly. If "user-
name@realm" is used, the RADIUS proxy/server will process it as a
roaming request.
When the RADIUS proxy/server handles a request from a roaming user, it
will first check the cache to see if the user information is already
stored there. If there is a cache hit, the RADIUS proxy/server do the
local authentication accordingly. If it does not find user informa-
tion in its cache, it will act as a proxy, forwarding the authentica-
tion request to the home RADIUS server. When the home RADIUS server
responds, the local server will forward the response to the NAS. If
the user is authenticated by the home server, the local RADIUS proxy
will cache the user information for a period of time (3 days by
default).
Caching is used to avoid frequent proxying of requests and responses
between the local RADIUS proxy and the home RADIUS server. When the
home RADIUS server sends back a valid authentication response, the
local RADIUS proxy/server will cache the user information for a period
of time (3 days by default). When the user next authenticates
directly against the home RADIUS server, the home RADIUS server will
send a request to the local server or servers to clear the user's
information from the cache.
6.4.1. Extended hierarchy
In some provinces, the local telecommunications administration
(Provincial ISP) further delegates control to county access nodes,
creating another level of hierarchy. This is done to improve scalabil-
ity and to avoid having the provincial ISP databases grow too large.
In the current implementation, each provincial ISP maintains its own
central RADIUS server, including information on all users in the
province, while county nodes maintain distributed RADIUS servers. For
Aboba, Lu, Alsop, Ding & Wang [Page 13]
INTERNET-DRAFT 10 June 1997
intra-province roaming requests the local RADIUS proxy/server will
directly forward the request to the home RADIUS server.
However, for inter-province roaming requests, the local RADIUS server
does not forward the request directly to the home RADIUS server.
Instead, the request is forwarded to the central provincial RADIUS
server for the home province. This implementation is suitable only
when county level ISPs do not mind combining and sharing their user
information. In this instance, this is acceptable, since all county
level ISPs are part of China Telecom. In a future release, this multi-
layer hierarchy will be implemented using multi-layer proxy RADIUS, in
a manner more resembling DNS.
6.5. Security
Encryption is used between the local RADIUS proxy/server and the home
RADIUS server. Public/Private key encryption will be supported in the
next release. IP tunneling and token card support is under considera-
tion.
6.6. Accounting
Accounting information is transferred between the local RADIUS
accounting proxy/server and home RADIUS accounting server. Every day
each node sends a summary accounting information record to a central
server in order to support nationwide settlement. The central server
is run by the central Data Communication Bureau of China Telecom.
Every month the central server sends the settlement bill to the
provincial ISPs.
6.7. Inter-ISP/CSP roaming
ChinaNet supports both ISP and CSP (Content Service Provider) roaming
on its system. For example, Shanghai Online, a Web-based commercial
content service, uses RADIUS for authentication of ChinaNet users who
do not have a Shanghai Online account. In order to support this, the
Shanghai Online servers function as a RADIUS client authenticating
against the home RADIUS server. When users access a protected document
on the HTTP server, they are prompted to send a username/password for
authentication. The user then responds with their userID in "user-
name@realm" notation.
A CGI script on the HTTP server then acts as a RADIUS authentication
client, sending the request to the home RADIUS server. After the home
RADIUS server responds, the CGI script passes the information to the
local authentication agent. From this point forward, everything is
taken care of by the local Web authentication mechanism.
Aboba, Lu, Alsop, Ding & Wang [Page 14]
INTERNET-DRAFT 10 June 1997
7. Microsoft implementation
Microsoft's roaming implementation was originally developed in order
to support the Microsoft Network (MSN), which now offers Internet
access in seven countries: US, Canada, France, Germany, UK, Japan, and
Australia. In each of these countries, service is offered in coopera-
tion with access partners. Since users are able to connect to the
access partner networks while maintaining a customer-vendor relation-
ship with MSN, this implementation fits within the definition of roam-
ing as used in this document.
7.1. Implementation overview
The first version of the Microsoft roaming software was deployed by
the MSN partners in April, 1996. This version included a Phone Book
manager tool running under Windows 95, as well as a RADIUS
server/proxy implementation running under Windows NT; TACACS+ is cur-
rently not supported. Additional components now under development
include a Connection Manager client for Windows 95 as well as an HTTP-
based phone book server for Windows NT. The Phone Book manager tool is
also being upgraded to provide for more automated phone book compila-
tion.
7.2. Phone number presentation
The Connection Manager is responsible for the presentation and updat-
ing of phone numbers, as well as for dialing and making connections.
In order to select phone numbers, users are asked to select the
desired country and region/state. Phone numbers are then presented in
the area selected. The primary numbers are those from the users ser-
vice provider which match the service type (Analog, ISDN, Analog &
IDN), country and region/state selected. The other numbers (selected
clicking on the More button) are those for other service providers
that have a roaming agreement with the users service provider.
7.2.1. Cost data
Cost data is not presented to users along with the phone numbers. How-
ever, such information may be made available by other means, such as
via a Web page.
7.2.2. Default phone book format
The Connection Manager supports the ability to customize the phone
book format, and it is expected that many ISPs will make use of this
capability. However, for those who wish to use it "off the shelf" a
default phone book format is provided. The default phone book is com-
prised of several files, including:
Service profile
Aboba, Lu, Alsop, Ding & Wang [Page 15]
INTERNET-DRAFT 10 June 1997
Phone Book
Region file
The service profile provides information on a given service, which may
be an isolated Internet Service Provider, or may represent a roaming
consortium. The service profile, which is in .ini file format, is com-
prised of the following information:
The name of the service
The filename of the service's big icon
The filename of the service's little icon
A description of the service
The service phone book filename
The service phone book version number
The service regions file
The URL of the service phone book server
The prefix used by the service (i.e. "MSN/aboba")
The suffix or domain used by the service (i.e. "aboba@msn.com")
Whether the user name is optional for the service
Whether the password is optional for the service
Maximum length of the user name for the service
Maximum length of the password for the service
Information on service password handling (lowercase, mixed case, etc.)
Number of redials for this service
Delay between redials for this service
References to other service providers that have roaming agreements
The service profile filenames for each of the references
Mask and match phone book filters for each of the references
(these are 32 bit numbers that are applied against the capability flags in the phone book)
The dial-up connection properties configuration
(this is the DUN connectoid name)
The phone book file is a comma delimited ASCII file containing the
following data:
Unique number identifying a particular record (Index)
Country ID
A zero-base index into the region file
City
Area code
Local phone number
Minimum Speed
Maximum speed
Capability Flags:
Bit 0: 0=Toll, 1=Toll free
Bit 1: 0=X25, 1=IP
Bit 2: 0=Analog, 1=No analog support
Bit 3: 0=no ISDN support, 1=ISDN
Bit 4: 0
Bit 5: 0
Bit 6: 0=No Internet access, 1=Internet access
Bit 7: 0=No signup access, 1=Signup access
Bit 8-31: reserved
Aboba, Lu, Alsop, Ding & Wang [Page 16]
INTERNET-DRAFT 10 June 1997
The filename of the dialup network file
(typically refers to a script associated with the number)
A sample phone book file is shown below:
65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
200133,1,1,Birmingham,205,5551212,9600,28800,0,10,
130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile
65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile
7.2.3. Additional attributes
As described previously, it is likely that some ISPs will require
additional phone number attributes or provider information beyond that
supported in the default phone book format. Attributes of interest
may vary between providers, or may arise as a result of the introduc-
tion of new technologies. As a result, the set of phone number
attributes is likely to evolve over time, and extensibility in the
phone book format is highly desirable.
For example, in addition to the attributes provided in the default
phone book, the following additional attributes have been requested by
customers:
Multicast support flag
External/internal flag (to differentiate display between the
"internal" or "other" list box)
Priority (for control of presentation order)
Modem protocol capabilities (V.34, V.32bis, etc.)
ISDN protocol capabilities (V.110, V.120, etc.)
No password flag (for numbers using telephone-based billing)
Provider name
7.2.4. Addition of information on providers
The default phone book does not provide a mechanism for display of
information on the individual ISPs within the roaming consortium, only
for the consortium as a whole. For example, the provider icons (big
and little) are included in the service profile. The service descrip-
tion information is expected to contain the customer support number.
However, this information cannot be provided on an individual basis
for each of the members of a roaming consortium. Additional informa-
tion useful on a per-provider basis would include:
Provider voice phone number
Provider icon
Provider fax phone number
Provider customer support phone number
Aboba, Lu, Alsop, Ding & Wang [Page 17]
INTERNET-DRAFT 10 June 1997
7.3. Phone number exchange
Currently phone number exchange is not supported by the phone book
server. As a result, in the MSN implementation, phone number exchange
is handled manually. As new POPs come online, the numbers are for-
warded to MSN, which tests the numbers and approves them for addition
to the phone book server. Updated phone books are produced and loaded
on the phone book server on a weekly basis.
7.4. Phone book compilation
The Phone Book Manager tool was created in order to make it easier for
the access partners to create and update their phone books. It sup-
ports addition, removal, and editing of phone numbers, generating both
a new phone book, as well as associated difference files.
With version 1 of the Phone Book Administration tool, phone books are
compiled manually, and represent a concatenation of available numbers
from all partners, with no policy application. With version 1, the
updates are prepared by the partners and forwarded to MSN, which tests
the numbers and approves them for addition to the phone book. The
updates are then concatenated together to form the global update file.
The new version of the Phone Book Administration tool automates much
of the phone book compilation process, making it possible for phone
book compilation to be decentralized with each partner running their
own phone book server. Partners can then maintain and test their indi-
vidual phone books and post them on their own Phone Book Server.
7.5. Phone book update
There is a mechanism to download phone book deltas, as well as to
download arbitrary executables which can perform more complex update
processing. Digital signatures are only used on the downloading of
executables, since only these represent a security threat - the Con-
nection Manager client does not check for digital signatures on deltas
because bogus deltas can't really cause any harm.
The Connection Manager updates the phone book each time the user logs
on. This is accomplished via an HTTP GET request to the phone book
server. When the server is examining the request, it can take into
account things like the OS version on the client, the language on the
client, the version of Connection Manager on the client, and the ver-
sion of the phone book on the client, in order to determine what it
wants to send back.
In the GET response, the phone book server responds with the differ-
ence files necessary to update the client's phone book to the latest
version. The client then builds the new phone book by successively
applying these difference files. This process results in the update
Aboba, Lu, Alsop, Ding & Wang [Page 18]
INTERNET-DRAFT 10 June 1997
of the entire phone book, and is simple enough to allow it to be eas-
ily implemented on a variety of HTTP servers, either as a CGI script
or (on NT) as an ISAPI DLL.
The difference files used in the default phone book consist of a list
of phone book entries, each uniquely identified by their index number.
Additions consist of phone book entries with all the information filed
in; deletions are signified by entries with all entries zeroed out. A
sample difference file is shown below:
65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
200133,0,0,0,0,0,0,0,0,0
130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile
65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile
7.6. Connection management
The Connection Manager can support any protocol which can be config-
ured via use of Windows Dialup Networking, including PPP and SLIP run-
ning over IP. The default setting is for the IP address as well as
the DNS server IP address to be assigned by the NAS. The DNS server
assignment capability is described in [1].
7.7. Authentication
The Connection Manager client and RADIUS proxy/server both support
suffix style notation (i.e. "aboba@msn.com"), as well as a prefix
notation ("MSN/aboba").
The prefix notation was developed for use with NAS devices with small
maximum userID lengths. For these devices the compactness of the pre-
fix notation significantly increases the number of characters avail-
able for the userID field. However, as an increasing number of NAS
devices are now supporting 253 octet userIDs (the maximum supported by
RADIUS) the need for prefix notation is declining.
After receiving the userID from the Connection Manager client, the NAS
device passes the userID/domain and password information (or in the
case of CHAP, the challenge and the response) to the RADIUS proxy. The
RADIUS proxy then checks if the domain is authorized for roaming by
examining a static configuration file. If the domain is authorized,
the RADIUS proxy then forwards the request to the appropriate RADIUS
server. The domain to server mapping is also made via a static config-
uration file.
While static configuration files work well for small roaming consor-
tia, for larger consortia static configuration will become tedious.
Potentially more scalable solutions include use of DNS SRV records for
the domain to RADIUS server mapping.
Aboba, Lu, Alsop, Ding & Wang [Page 19]
INTERNET-DRAFT 10 June 1997
7.8. NAS configuration/authorization
Although the attributes returned by the home RADIUS server may make
sense to home NAS devices, the local NAS may be configured differ-
ently, or may be from a different vendor. As a result, it may be nec-
essary for the RADIUS proxy to edit the attribute set returned by the
home RADIUS server, in order to provide the local NAS with the appro-
priate configuration information. The editing occurs via attribute
discard and insertion of attributes by the proxy.
Alternatively, the home RADIUS server may be configured not to return
any network-specific attributes, and to allow these to be inserted by
the local RADIUS proxy.
Attributes most likely to cause conflicts include:
Framed-IP-Address
Framed-IP-Netmask
Framed-Routing
Framed-Route
Filter-Id
Vendor-Specific
Session-Timeout
Idle-Timeout
Termination-Action
Conflicts relating to IP address assignment and routing are very com-
mon. Where dynamic address assignment is used, an IP address pool
appropriate for the local NAS can be substituted for the IP address
pool designated by the home RADIUS server.
However, not all address conflicts can be resolved by editing. In
some cases, (i.e., assignment of a static network address for a LAN)
it may not be possible for the local NAS to accept the home RADIUS
server's address assignment, yet the roaming hosts may not be able to
accept an alternative assignment.
Filter IDs also pose a problem. It is possible that the local NAS may
not implement a filter corresponding to that designated by the home
RADIUS server. Even if an equivalent filter is implemented, in order
to guarantee correct operation, the proxy's configuration must track
changes in the filter configurations of each of the members of the
roaming consortium. In practice this is likely to be unworkable.
Direct upload of filter configuration is not a solution either,
because of the wide variation in filter languages supported in today's
NAS devices.
Since by definition vendor specific attributes have meaning only to
devices created by that vendor, use of these attributes is problematic
within a heterogeneous roaming consortium. While it is possible to
edit these attributes, or even to discard them or allow them to be
ignored, this may not always be acceptable. In cases where vendor spe-
cific attributes relate to security, it may not be acceptable for the
proxy to modify or discard these attributes; the only acceptable
Aboba, Lu, Alsop, Ding & Wang [Page 20]
INTERNET-DRAFT 10 June 1997
action may be for the local NAS to drop the user. Unfortunately,
RADIUS does not distinguish between mandatory and optional attributes,
so that there is no way for the proxy to take guidance from the
server.
Conflicts over session or idle timeouts may result if since both the
local and home ISP feel the need to adjust these parameters. While
the home ISP may wish to adjust the parameter to match the user's
software, the local ISP may wish to adjust it to match its own service
policy. As long as the desired parameters do not differ too greatly, a
compromise is often possible.
7.9. Address assignment and routing
While the Connection Manager software supports both static and dynamic
address assignment, in the MSN implementation, all addresses are
dynamically assigned.
However, selected partners also offer LAN connectivity to their cus-
tomers, usually via static address assignment. However, these accounts
do not have roaming privileges since no mechanism has been put in
place for allowing these static routes to move between providers.
Users looking to do LAN roaming between providers are encouraged to
select a router supporting Network Address Translation (NAT). NAT ver-
sions implemented in several low-end routers are compatible with the
dynamic addressing used on MSN, as well as supporting DHCP on the LAN
side.
7.10. Security
The RADIUS proxy/server implementation does not support token cards or
tunneling protocols.
7.11. Accounting
In the MSN roaming implementation, the accounting data exchange pro-
cess is specified in terms of an accounting record format, and a
method by which the records are transferred from the partners to MSN,
which acts as the settlement agent. Defining the interaction in terms
of record formats and transfer protocols implies that the partners do
not communicate with the settlement agent using NAS accounting proto-
cols. As a result, accounting protocol interoperability is not be
required.
However, for this advantage to be fully realized, it is necessary for
the accounting record format to be extensible. This makes it more
likely that the format can be adapted for use with the wide variety of
accounting protocols in current use (such as SNMP, syslog, RADIUS, and
TACACS+), as well as future protocols. After all, if the record format
cannot express the metrics provided by a particular partner's account-
ing protocol, then the record format will not be of much use for a
Aboba, Lu, Alsop, Ding & Wang [Page 21]
INTERNET-DRAFT 10 June 1997
heterogeneous roaming consortium.
7.11.1. Accounting record format
The Microsoft RADIUS proxy/server supports the ability to customize
the accounting record format, and it is expected that some ISPs will
make use of this capability. However for those who want to use it "off
the shelf" a default accounting record format is provided. The
accounting record includes information provided by RADIUS:
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)
Status Type (Integer; indicates session start and stop,
as well as accounting on and off)
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 linking start and stop records)
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.)
However, since this default format is not extensible, it cannot easily
be adapted to protocols other than RADIUS, services other than dialup
(i.e. dedicated connections) or rated events (i.e. file downloads).
This is a serious limitation, and as a result, customers have
requested a more general accounting record format.
7.11.2. Transfer mechanism
Prior to being transferred, the accounting records are compressed so
as to save bandwidth. The transfer of accounting records is handled
via FTP, with the transfer being initiated by the receiving party,
rather than by the sending party. A duplicate set of records is kept
by the local ISP for verification purposes.
8. Merit Network Implementation
8.1. Overview
MichNet is a regional IP backbone network operated within the state of
Michigan by Merit Network, Inc., a nonprofit corporation based in Ann
Aboba, Lu, Alsop, Ding & Wang [Page 22]
INTERNET-DRAFT 10 June 1997
Arbor, Michigan. Started in 1966, MichNet currently provides backbone
level Internet connectivity and dial-in IP services to its member and
affiliate universities, colleges, K-12 schools, libraries, government
institutions, other nonprofit organizations, and commercial business
entities.
As of May 1, 1997, MichNet had 11 members and 405 affiliates. Its
shared dial-in service operated 133 sites in Michigan and one in Wash-
ington, D.C, with 4774 dial-in lines. Additional dial-in lines and
sites are being installed daily.
MichNet also provides national and international dial-in services to
its members and affiliates through an 800 number and other external
services contracting with national and global service providers.
The phone numbers of all MichNet shared dial-in sites are published
both on the Merit web site and in the MichNet newsletters. Merit also
provides links to information about the national and international
service sites through their respective providers' web sites. Such
information can be found at http://www.merit.edu/mich-
net/shared.dialin/.
8.1.1. MichNet State-Wide Shared Dial-In Services
Each MichNet shared dial-in service site is owned and maintained by
either Merit or by a member or affiliate organization. All sites must
support PPP and Telnet connections.
Each organization participating in the shared dial-in service is
assigned a realm-name. Typically the realm-name resembles a fully
qualified domain name. Users accessing the shared dial-in service
identify themselves by using a MichNet AccessID which consists of
their local id concatenated with "@" followed by the realm-name - e.g.
user@realm
Merit operates a set of Authentication, Authorization and Accounting
(AAA) servers supporting the RADIUS protocol which are called core
servers. The core servers support all the dial-in service sites and
act as proxy servers to other AAA servers running at the participating
organizations. For security reasons, Merit staff run all core servers;
in particular, the user password is in the clear when the proxy core
server decodes an incoming request and then re-encodes it and forwards
it out again,
The core servers also enforce a common policy among all dial-in
servers. The most important policy is that each provider of access
must make dial-in ports available to others when the provider's own
users do not have a need for them. To implement this policy, the proxy
server distinguishes between realms that are owners and realms that
are guests.
One piece of the policy determining whether the provider's organiza-
tion has need of the port, is implemented by having the proxy core
Aboba, Lu, Alsop, Ding & Wang [Page 23]
INTERNET-DRAFT 10 June 1997
server track the realms associated with each of the sessions connected
at a particular huntgroup. If there are few ports available (where few
is determined by a formula) then guests are denied access. Guests are
also assigned a time limit and their sessions are terminated after
some amount of time (currently one hour during prime time, two hours
during non-prime time).
The other part of the policy is to limit the number of guests that are
allowed to connect. This is done by limiting the number of simultane-
ous guest sessions for realms. Each realm is allocated a number of
"simultaneous access tokens" - SATs. When a guest session is autho-
rized the end server for the realm decrements the count of available
SATs, and when the session is terminated the count of SATs is incr-
mented. A Merit specific attribute is added to the request by the
core if the session will be a "guest" and will require a SAT. The end
server must include a reply with an attribute containing the name of
the "token pool" from which the token for this session is taken. The
effect of this is to limit the number of guests connected to the net-
work to the total number of tokens allocated to all realms.
Each realm is authenticated and authorized by its own AAA server. The
proxy core servers forward requests to the appropriate server based on
a configuration file showing where each realm is to be authenticated.
Requests from realms not in the configuration are dropped.
The Merit AAA server software supports this policy. Merit provides
this software to member and affiliate organizations. The software is
designed to work with many existing authentication servers, such as
Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS. This enables
most institutions to utilize the authentication mechanism they have in
place.
8.1.2. MichNet National and International Dial-In Services
In addition to the MichNet shared dial-in service, Merit also provides
access from locations outside of Michigan by interconnecting with
other dial-in services. These services are typically billed by connect
time. Merit acts as the accounting agent between its member and affil-
iate organizations and the outside service provider.
The services currently supported are a national 800 number and service
via the ADP/Autonet dial-in network. Connection with IBM/Advantis is
being tested, and several other service interconnects are being inves-
tigated.
Calls placed by a Merit member/affiliate user to these external dial-
in services are authenticated by having each of those services forward
RADIUS authentication requests and accounting messages to a Merit
proxy core server. The core forwards the requests to the member/affil-
iate server for approval. Session records are logged at the Merit core
server and at the member/affiliate server. Merit bills members/affili-
ates monthly, based on processing of the accounting logs. The members
and affiliates are responsible for rebilling their users.
Aboba, Lu, Alsop, Ding & Wang [Page 24]
INTERNET-DRAFT 10 June 1997
The Merit AAA software supports the ability to request positive con-
firmation of acceptance of charges, and provides tools for accumulat-
ing and reporting on use by realm and by user.
8.2. Authentication and Authorization
Authentication of a Telnet session is supported using the traditional
id and password method, with the id being a MichNet AccessID of the
form user@realm, while a PPP session may be authenticated either using
an AccessID and password within a script, or using PAP. Support for
challenge/response authentication mechanisms using EAP is under devel-
opment.
When a user dials into a MichNet shared dial-in port, the NAS sends
an Access-Request to a core AAA server using the RADIUS protocol.
First the core server applies any appropriate huntgroup access poli-
cies to the request. If the Request fails the policy check, an Access-
Reject is returned to the NAS. Otherwise, the core server forwards it
to the user's home authentication server according to the user's
realm. The home authentication server authenticates and authorizes
the access request. An Access-Accept or Access-Reject is sent back to
the core server. If an Access-Accept is sent, the home server will
create a dial-in session identifier which is unique to this session
and insert it in a Class attribute in the Access-Accept. The core
server looks at the request and the response from the home server
again and decides either to accept or reject the request. Finally, the
core server sends either an Access-Accept or Access-Reject to the NAS.
When a user dials into a contracted ISP's huntgroup (MichNet National
and International Service), the ISP sends a RADIUS access request
to a Merit core server. The rest of the authentication and authoriza-
tion path is the same as in the shared dial-in service, except
that no huntgroup access policy is applied but a Huntgroup-Service
attribute is sent to the home authentication server with its value
being the name of the service, and a copy of the attribute must be
returned by the home server with a flag appended to the original value
to indicate a positive authorization of user access to the specified
service.
The MichNet shared dial-in service typically requires authorization of
some sort, for example, a user dialing into a huntgroup as a guest
must be authorized with a token from the user's realm. Participating
institutions have control in defining authorization rules. Currently
authorization may be done using any combination of the user's group
status and user's account status. A set of programming interfaces is
also provided for incorporating new authorization policies.
8.3. Accounting
In the Merit AAA server, a session is defined as starting from the
moment the user connects to the NAS, and ending at the point when the
user disconnects. During the course of a session, both the core server
Aboba, Lu, Alsop, Ding & Wang [Page 25]
INTERNET-DRAFT 10 June 1997
and the home server maintain status information about the session.
This allows the AAA servers to apply policies based on the current
status, e.g. limit guest access by realm to number of available
tokens, or to limit number of simultaneous sessions for a given Acces-
sID. Information such as whether the session is for a guest, whether
it used a token, and other information is included with the accounting
stop information when it is logged. Merit has made enhancements to the
RADIUS protocol, that are local to the AAA server, to support mainte-
nance of session status information.
When a user session is successfully authenticated, the NAS sends out a
RADIUS accounting start request to the core server. The core server
forwards that request to the user's home server. The home server
updates the status of the session and then responds to the core. The
core server in turn responds to the NAS. In the accounting Start
request, a NAS conforming to the RADIUS specification must return the
Class attribute and value it received in the Access-Accept for the
session, thus sending back the dial-in session identifier created by
the session's home server.
When a user ends a session, an accounting stop request is sent through
the same path. the same path. The dial-in session identifier is
again returned by the NAS, providing a means of uniquely identifying a
session. By configuring the finite state machine in each of the AAA
servers, any accounting requests may be logged by any of the servers
where the accounting requests are received.
Because the same session logs are available on every server in the
path of a session's authorization and accounting message, problems
with reconciliation of specific sessions may be resolved easily. For
the shared dial-in service, there are no usage charges. Merit has
tools to verify that organizations do not authorize more guest ses-
sions than the number of SATs allocated to the organization. For
surcharged sessions, Merit sends each organization a summary bill each
month. Files with detail session records are available for problem
resolution. Each organization is responsible for billing its own
users, and should have the same session records as are collected by
Merit.
Merit receives a monthly invoice from other dial-in service providers
and pays them directly, after first verifying that the charges corre-
spond to the session records logged by Merit.
8.4. Software and Development
Merit has developed the AAA server software which supports the above
capabilities initially by modifying the RADIUS server provided by Liv-
ingston, and later by doing a nearly total rewrite of the software to
make enhancement and extension of capabilites easier. Merit makes a
basic version of its server freely available for noncommercial use.
Merit has started the Merit AAA Server Consortium which consists of
Merit and a number of NAS vedors, ISPs and server software vendors.
The consortium supports ongoing development of the Merit AAA server.
Aboba, Lu, Alsop, Ding & Wang [Page 26]
INTERNET-DRAFT 10 June 1997
The goal is to build a server that supports proxy as well as end
server capabilities, that is feature rich, and that interoperates with
major vendors' NAS products.
The building block of the Merit AAA server, the Authentication/Autho-
rization Transfer Vector (AATV), is a very powerful concept that
enables the ultimate modularity and flexibility of the AAA server. The
structure and methods of the AATV model are published with all ver-
sions of the AAA server.
Objects for extending the authorization server are also available in
the enhanced version of the AAA server. Merit is also looking at ways
to provide a method of extending the AAA server in its executable
form, to improve the server efficiency and scalability, and to provide
better monitoring, instrumentation and administration of the server.
9. FidoNet implementation
Since its birth in 1984, FidoNet has supported phone book synchroniza-
tion among its member nodes, which now number approximately 35,000.
As a non-IP dialup network, FidoNet does not provide IP services to
members, and does not utilize IP-based authentication technology.
Instead member nodes offer bulletin-board services, including access
to mail and conferences known as echoes.
In order to be able to communicate with each other, FidoNet member
systems require a sychronized phone book, known as the Nodelist. The
purpose of the Nodelist is to enable resolution of FidoNet addresses
(expressed in the form zone:network/node, or 1:161/445) to phone num-
bers. As a dialup network, FidoNet requires phone numbers in order to
be deliver mail and conference traffic.
In order to minimize the effort required in regularly synchronizing a
phone book of 35,000 entries, the weekly Nodelist updates are trans-
mitted as difference files. These difference files, known as the
Nodediff, produce the Nodelist for the current week when applied to
the previous week's Nodelist. In order to minimize transfer time,
Nodediffs are compressed prior to transfer.
Information on FidoNet, as well as FidoNet Technical Standards (FTS)
documents (including the Nodelist specification) and standards propos-
als are available from the FidoNet archive at http://www.fidonet.org/.
9.1. Scaling issues
With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB
in size, and the weekly Nodediffs are 175 KB. In compressed form, the
Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a
result, the transfer of the Nodediff takes approximately 45 seconds
using a 28,800 bps modem.
Aboba, Lu, Alsop, Ding & Wang [Page 27]
INTERNET-DRAFT 10 June 1997
In order to improve scalability, the implementation of a domain name
service approach is examined in [8]. The proposal evisages use of a
capability analagous to the DNS ISDN record in order to map names to
phone numbers, coupled with an additional record to provide the
attributes associated with a given name.
9.2. Phone number presentation
While FidoNet member systems perform phone book synchronization, users
need only know the FidoNet address of the systems they wish to con-
tact. As a result users do not need to maintain copies of the Nodelist
on their own systems. This is similar to the Internet, where the DNS
takes care of the domain name to IP address mapping, so that users do
not have to remember IP addresses.
Nevertheless, FidoNet systems often find it useful to be able to pre-
sent lists of nodes, and as a result, FidoNet Nodelist compilers typi-
cally produce a representation of the Nodelist that can be searched or
displayed online, as well as one that is used by the system dialer.
9.2.1. FidoNet Nodelist format
The FidoNet Nodelist format is documented in detail in [3]. The
Nodelist file consists of lines of data as well as comment lines,
which begin with a semi-colon. The first line of the Nodelist is a
general interest comment line that includes the date and the day num-
ber, as well as a 16-bit CRC. The CRC is included so as to allow the
system assembling the new Nodelist to verify its integrity.
Each Nodelist data line contains eight comma separated fields:
Keyword
Zone/Region/Net/Node number
Node name
Location
Sysop name
Phone number
Maximum Baud rate
Flags (optional)
FidoNet Nodelists are arranged geographically, with systems in the
same zone, region, and network being grouped together. As a result,
FidoNet Nodelists do not require a separate regions file. Among other
things, the keyword field can be used to indicate that a system is
temporarily out of service.
Reference [3] discusses Nodelist flags in considerable detail. Among
other things, the flags include information on supported modem modula-
tion and error correction protocols. Reference [4] also proposes a
series of ISDN capability flags, and [5] proposes flags to indicate
times of system availability.
Aboba, Lu, Alsop, Ding & Wang [Page 28]
INTERNET-DRAFT 10 June 1997
9.3. Phone number exchange
FidoNet coordinators are responsible for maintaining up to date infor-
mation on their networks, regions, and zones. Every week network coor-
dinators submit to their regional coordinators updated versions of
their portions of the Nodelist. The regional coordinators then compile
the submissions from their network coordinators, and submit them to
the zone coordinator. The zone coordinators then exchange their sub-
missions to produce the new Nodelist. As a result, it is possible that
the view from different zones may differ at any given time.
9.3.1. The Nodediff
The format of the Nodediff is discussed in detail in [3]. In preparing
the Nodediffs, network coordinators may transmit only their difference
updates, which can be collated to produce the Nodediff directly.
One weakness in the current approach is that there is no security
applied to the coordinator submissions. This leaves oen the possibil-
ity of propagation of fraudulent updates. In order to address this,
[6] proposes addition of a shared secret to the update files.
9.3.2. Addition of nodes
In order to apply for allocation of a FidoNet address and membership
in the Nodelist, systems must demonstrate that they are functioning by
sending mail to the local network coordinator. Once the local network
coordinator receives the application, they then allocate a new FidoNet
address, and add a Nodelist entry.
9.3.3. Deletion of nodes
Since FidoNet nodes are required to be functioning during the zone
mail hour in order to receive mail, and since nodes receive the weekly
Nodelist from their local network coordinators on a weekly basis,
there is a built-in mechanism for discovery of non-functional nodes.
Nodes found to be down are reported to the local network coordinator
and subsequently marked as down within the Nodelist. Nodes remaining
down for more than two weeks may be removed from the Nodelist, at the
discretion of the network coordinator.
9.4. Phone book update
The Nodelist contains the phone numbers and associated attributes of
each participating system. New Nodelists become available on Fridays,
and are made available to participating systems by their local network
coordinators, who in turn receive them from the regional and zone
coordinators.
Aboba, Lu, Alsop, Ding & Wang [Page 29]
INTERNET-DRAFT 10 June 1997
While it is standard practice for participating systems to get their
Nodelists from their local network coordinators, should the local net-
work coordinator not be available for some reason, either the updates
or the complete Nodelist may be picked up from other network, or
regional coordinators. Please note that since the view from different
zones may differ, nodes wishing to update their Nodelists should not
contact systems from outside their zone.
9.5. Phone book compilation
Once FidoNet systems have received the Nodediff, the apply it to the
previous week's Nodelist in order to prepare a new Nodelist. In order
to receive Nodediffs and compile the Nodelist, the following software
is required:
A FidoNet-compatible mailer implementation, used to transfer files
A Nodelist compiler
One of the purposes of the Nodelist compiler is to apply Nodediffs to
the previous Nodelist in order to produce an updated Nodelist. The
other purpose is to compile the updated Nodelist into the format
required by the particular mailer implementation used by the member
system. It is important to note that while the Nodelist and Nodediff
formats are standardized (FTS-0005), as is the file transfer protocol
(FTS-0001), the compiled format used by each mailer is implementation
dependent.
One reason that compiled formats to differ is the addition of out of
band information to the Nodelist during the compilation process.
Added information includes phone call costs as well as shared secrets.
9.5.1. Cost data
Although cost information is not part of the Nodelist, in compiling
the Nodelist into the format used by the mailer, Nodelist compilers
support the addition of cost information. This information is then
subsequently used to guide mailer behavior.
Since phone call costs depend on the rates charged by the local phone
company, this information is local in nature and is typically entered
into the Nodelist compiler's configuration file by the system adminis-
trator.
9.5.2. Shared secrets
In FidoNet, shared secrets are used for authenticated sessions between
systems. Such authenticated sessions are particularly important
between the local, regional and zone coordinators who handle prepara-
tion and transmission of the Nodediffs. A single shared secret is used
per system.
Aboba, Lu, Alsop, Ding & Wang [Page 30]
INTERNET-DRAFT 10 June 1997
9.6. Accounting
Within FidoNet, the need for accounting arises primarily from the need
of local, regional and zone coordinators to be reimbursed for their
expenses. In order to support this, utilities have been developed to
account for network usage at the system level according to various
metrics. However, the accounting techniques are not applied at the
user level. Distributed authentication and accounting are not imple-
mented and therefore users may not roam between systems.
10. Acknowledgements
Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest
for useful discussions of this problem space.
11. References
[1] S. Cobb. "PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses" RFC 1877, Microsoft, December 1995.
[2] T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer
Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996.
[3] B. Baker, R. Moore, D. Nugent. "The Distribution Nodelist."
FTS-0005, February, 1996.
[4] A. Lentz. "ISDN Nodelist flags." FSC-0091, June, 1996.
[5] D. J. Thomas. "A Proposed Nodelist flag indicating Online Times
of a Node." FSC-0062, April, 1996.
[6] L. Kolin. "Security Passwords in Nodelist Update Files."
FSC-0055, March, 1991.
[7] R. Gwinn, D. Dodell. "Nodelist Flag Changes Draft Document."
FSC-0009, November, 1987.
[8] R. Heller. "A Proposal for A FidoNet Domain Name Service."
FSC-0069, December, 1992.
[9] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[10] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
1997.
Aboba, Lu, Alsop, Ding & Wang [Page 31]
INTERNET-DRAFT 10 June 1997
12. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Juan Lu
AimQuest Corporation
1381 McCarthy Blvd.
Milpitas, California 95035
Phone: 408-273-2730 ext. 2762
EMail: juanlu@aimnet.net
John Alsop
i-Pass Alliance Inc.
650 Castro St., Suite 280
Mountain View, CA 94041
Phone: 415-968-2200
Fax: 415-968-2266
EMail: jalsop@ipass.com
James Ding
Asiainfo
One Galleria Tower
13355 Noel Road, #1340
Dallas, TX 75240
Phone: 214-788-4141
Fax: 214-788-0729
EMail: ding@bjai.asiainfo.com
Wei Wang
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105-2785
Phone: 313-764-2874
EMail: weiwang@merit.edu
Aboba, Lu, Alsop, Ding & Wang [Page 32]