HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:13:00 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 27 Nov 1996 00:17:00 GMT ETag: "361bbc-faf0-329b887c" Accept-Ranges: bytes Content-Length: 64240 Connection: close Content-Type: text/plain ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Lynn Liu 26 November 1996 Aimnet John Alsop i-Pass Alliance James Ding Asiainfo 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 , and expires June 1, 1997. 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. 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: Aboba, Liu, Alsop, & Ding [Page 1] INTERNET-DRAFT 26 November 1996 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 or L2F. 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 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 Aboba, Liu, Alsop, & Ding [Page 2] INTERNET-DRAFT 26 November 1996 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, Aimnet Corporation, ten Internet Service Providers (ISPs) from the USA, Australia, China, Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the Global Reach Internet Consortium (GRIC) in May, 1996. The goals of GRIC were to to facilitate the implementation of a global roaming ser- vice and to coordinate billing and settlement among the membership. In the future it is likely that additional ISPs from Canada, Central America and Europe will join the GRIC consortium. Information on GRIC is available from http://www.gric.com/. In implementing their roaming service, GRIC members have chosen soft- ware developed by Aimnet. Aimnet Corporation's roaming implementation is comprised of the following major components: the Aimnet Ranger client, the AimTraveler RADIUS/TACACS+ proxy, and the Aimnet Internet Management System (AIMS) billing and settlement module. Information on the Aimnet roaming implementation is available from http://www.aimsoft.com/. The Aimnet Ranger client provides users with an automatically updated phone book, as well as handling authentication and logon. It is avail- able for the Windows platform. The AimTraveler proxy handles incoming authentication requests from NAS devices and routes them to the appropriate home server. Aboba, Liu, Alsop, & Ding [Page 3] INTERNET-DRAFT 26 November 1996 AimTraveler is available for various UNIX platforms, and supports both the Unix password file or Kerberos. A version for Windows NT is under development. AIMS is designed for large ISPs who need a centralized management sys- tem for all ISP operations, including sales, trouble-ticketing, ser- vice, and billing. AIMS produces usage and transaction statement reports, and includes a settlement module to produce settle- ment/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 dis- cover available phone numbers: a Web-based directory provided by the GRIC secretariat, and an automatically updated phone book supported by the Aimnet 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 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) 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 Aimnet Ranger dialer. 4.1.2. Aimnet Ranger phone book The Aimnet Ranger software provides for phone book presentation as well as automated updating of phone numbers. The Aimnet Ranger phone book includes a country list, provider list, and POP (phone number) 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 download Aboba, Liu, Alsop, & Ding [Page 4] INTERNET-DRAFT 26 November 1996 from the Aimnet 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 Aimnet. 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 (viewable via the Aimnet Ranger phone book), or in HTML (view- able via a Web browser). 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 Aimnet 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 Aimnet Ranger software supports PPP and SLIP, 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 Aimnet Ranger software takes care of presenting 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 to the AimTraveler authentication proxy, which supports both TACACS+ and RADIUS. Aboba, Liu, Alsop, & Ding [Page 5] INTERNET-DRAFT 26 November 1996 The AimTraveler software then determines if the domain name is regis- tered as capable of roaming. The registration check is based on local configuration data, and if it succeeds, the AimTraveler software then translates the authentication request to the protocol type used by the home authenticating domain, and forwards the encrypted access request to the home ISP. If the home ISP authorizes access, verification is sent to the local ISP. AimTraveler works as an authentication gate- way, routing userID and password (encrypted) to the remote authentica- tion server via RADIUS, TACACS+, or other authentication protocol. Since AimTraveler supports both TACACS+ and RADIUS, GRIC members may use either protocol. 4.7. NAS Configuration/Authorization AimTraveler is comprised of two components, a Client and a Server. The AimTraveler Client acts as the PPP dial-up authentication server. When it detects an '@' sign in the userID field, it forwards the encrypted userID and password to the AimTraveler server. The AimTrav- eler Server Gateway, a centralized authentication gateway, contains the authorized ISPs' domain names, authentication servers and other information. The AimTraveler Server routes the encrypted userID and password to the remote authorized ISP's authentication server for authentication. The AimTraveler Gateway 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. 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. 4.9. Security No GRIC members currently offer token card or tunneling support. 4.10. Accounting The AimTraveler software can act as either a RADIUS or TACACS+ accounting server. When accounting information is received from the NAS, AimTraveler stamps a roaming transaction log at the centralized Roaming Settlement Center. In the case of GRIC, the settlement center is run by Aimnet. Aboba, Liu, Alsop, & Ding [Page 6] INTERNET-DRAFT 26 November 1996 The AimTraveler Server running at Aimnet keeps a record of all roam- ing transactions, which are used as input to the settlement and billing process. At the end of each month, Aimnet provides a roaming 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. AimTraveler also provides accounting records to the local and home ISP for verification purposes. 5. i-Pass implementation 5.1. Overview i-Pass Alliance Inc., based in Palo Alto, California has developed and operates a service for global roaming between Internet service providers. The service is currently in field trials. i-Pass Alliance Inc. has additional offices in Toronto, Hong Kong, 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 member 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. It does not attempt to establish a business relationship with individual-user customers of those ISPs. 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 i-Pass member ISPs may update their information in the APD using a Aboba, Liu, Alsop, & Ding [Page 7] INTERNET-DRAFT 26 November 1996 secure web interface. 5.3. Phone number presentation i-Pass provides information and tools to Internet Service Providers and dialer application developers to assist them in integrating the i- Pass access point database into their software. i-Pass does not intend to be a primary developer of dialer applica- tions, as it believes this requirement is best met by the above par- ties. 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: RADIUS (standard Livingston distribution) 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. Aboba, Liu, Alsop, & Ding [Page 8] INTERNET-DRAFT 26 November 1996 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.[45], BSDI, and Digital Unix. 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 periodically (initially once a month). The settlement process involves calculating the costs associated with each individual session, and aggregating 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, depending 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 to facilitate delivery by electronic means (e.g. e-mail) as well as hard-copy. 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 Certification Authority). Transactions are also verified based on a number of other criteria such as source IP address. Aboba, Liu, Alsop, & Ding [Page 9] INTERNET-DRAFT 26 November 1996 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 ChinaNet 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 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 Aboba, Liu, Alsop, & Ding [Page 10] INTERNET-DRAFT 26 November 1996 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 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. Aboba, Liu, Alsop, & Ding [Page 11] INTERNET-DRAFT 26 November 1996 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. 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 cooper- ation with access partners. Since users are able to use the access partner networks while maintaining a customer-vendor relationship with MSN, this implementation fits within the definition of roaming 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 & ISDN), country and region/state selected. The other numbers (selected clicking on the More button) are those for other service providers Aboba, Liu, Alsop, & Ding [Page 12] INTERNET-DRAFT 26 November 1996 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 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 Aboba, Liu, Alsop, & Ding [Page 13] INTERNET-DRAFT 26 November 1996 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 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) Aboba, Liu, Alsop, & Ding [Page 14] INTERNET-DRAFT 26 November 1996 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 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 Admin 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 Admin tool automates much of the phone book compilation process, making it possible for phone book com- pilation to be decentralized with each partner running their own phone book server. Partners can then maintain and test their individual phone books and post them on their own Phone Book Server. Aboba, Liu, Alsop, & Ding [Page 15] INTERNET-DRAFT 26 November 1996 7.5. Phone book update 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, with information on the phone book version number presented as part of the GET request. In formulating its response, the phone book server then compares the version number in the GET request to the current version number, and reponds with the difference 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 of the entire phone book, and is simple enough to allow it to be easily 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. Before being sent, the update file is digitally signed. A sample dif- ference 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 assumes use of PPP, and does not support SLIP. 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 capabil- ity 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 Aboba, Liu, Alsop, & Ding [Page 16] INTERNET-DRAFT 26 November 1996 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. 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 Aboba, Liu, Alsop, & Ding [Page 17] INTERNET-DRAFT 26 November 1996 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 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 Aboba, Liu, Alsop, & Ding [Page 18] INTERNET-DRAFT 26 November 1996 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 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 Aboba, Liu, Alsop, & Ding [Page 19] INTERNET-DRAFT 26 November 1996 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. 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/. 8.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. 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. 8.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 Aboba, Liu, Alsop, & Ding [Page 20] INTERNET-DRAFT 26 November 1996 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. 8.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. 8.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. Aboba, Liu, Alsop, & Ding [Page 21] INTERNET-DRAFT 26 November 1996 8.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 open the possibil- ity of propagation of fraudulent updates. In order to address this, [6] proposes addition of a shared secret to the update files. 8.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. 8.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. 8.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. 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. 8.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 Aboba, Liu, Alsop, & Ding [Page 22] INTERNET-DRAFT 26 November 1996 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. 8.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. 8.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. 8.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. Aboba, Liu, Alsop, & Ding [Page 23] INTERNET-DRAFT 26 November 1996 9. Acknowledgements Thanks to Glen Zorn of Microsoft for many useful discussions of this problem space. 10. 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. 11. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Lynn Liu Aimnet Corporation 2350 Mission College Blvd., Ste. 600 Santa Clara, CA 95054 Phone: 408-567-3800 ext. 202 EMail: yalin@aimnet.com John Alsop i-Pass Alliance Inc. 555 Bryant Street, #248 Palo Alto, CA 94301 Aboba, Liu, Alsop, & Ding [Page 24] INTERNET-DRAFT 26 November 1996 Phone: 415-327-5553 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 Aboba, Liu, Alsop, & Ding [Page 25]