«Review of Roaming Implementations 1. Status of this Memo This memo provides information for the Internet community. This memo does not specify an ...»
Network Working Group B. Aboba
Request for Comments: 2194 Microsoft
Category: Informational J. Lu
Merit Network, Inc.
Review of Roaming Implementations
1. Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
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.
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 Aboba, et. al. Informational [Page 1] RFC 2194 Review of Roaming Implementations September 1997 include Internet access as well as secure access to corporate intranets via a Virtual Private Network (VPN), enabled by tunneling 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 compi
In this document we review existing roaming implementations, describing 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 several of these problem elements. These implementations typically fall into the category of shared use networks or non-IP dialup networks.
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 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 facilitate 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 service is to conclude shared use agreements with multiple networks.
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. Commercial operation began in December of 1996, and GRIC has grown to over 100 major ISPs and Telcos from all over the world, including NETCOM, USA; KDD and Mitsubishi, Japan; iStar, Canada; Easynet, UK; Connect.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 software developed by AimQuest. AimQuest Corporation’s roaming implementation comprises the following major components: the AimTraveler Authentication Server (AAS), the AimTraveler Routing Server (ARS), and the AimQuest Internet Management System (AIMS), software designed to facilitate the billing process. Information on the AimQuest roaming implementation is available from http://www.aimquest.com/.
Aboba, et. al. Informational [Page 3] RFC 2194 Review of Roaming Implementations September 1997 The AimTraveler Authentication Server (AAS) runs at each member ISP location, and handles incoming authentication requests from NAS devices and other AASes. The AimTraveler Routing Server (ARS) can run anywhere. A single 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 Accounting 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 member 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 produces usage and transaction statement reports, and includes a settlement module to produce settlement/billing reports for the roaming consortium 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 discover available phone numbers: a Web-based directory provided by the GRIC secretariat, and a GRIC phone book client on the user PC with dialing capability.
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 provider. For each provider within a country, this directory,
provided in the form of a table, offers the following information:
In order to discover phone numbers using the Web-based directory, it is expected that users will be online, and will navigate to the appropriate country and provider. They then look up the number and insert it into the AimQuest Ranger dialer.
4.1.2. GRIC phone book client The GRIC phone book client software provides for phone book presentation as well as automated updating of phone numbers. The GRIC phone book includes a list of countries, states, cities and area/city codes, as well as detailed provider information, including the cutomer support phone number, and Internet server configuration info. The Phone book, developed with Java, is available for download
from the AimQuest Web site:
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 secretariat 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 or in HTML.
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 GRIC phone book client are updated automatically upon connection. The AimTraveler server includes an address book which contains the phone numbers of all the roaming consortium members.
4.5. Connection management The AimTraveler software supports SLIP and PPP, as well as PAP and CHAP authentication.
4.6. Authentication GRIC implements distributed authentication, utilizing the user’s email address as the userID (i.e. "liu@Aimnet.com") presented to the remote NAS device.
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 authentication 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 information received from the routing server, the AAS makes an authentication request to the user’s Home ISP AAS for user id and password 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 rejection message to the Local ISP AAS, and the user will be dropped by the NAS.
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 configurations 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 routing 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 AimTraveler Server, a centralized routing server, contains the authorized ISP’s domain name, authentication servers and other information.
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, with the implementation of tunneling protocols