diff options
Diffstat (limited to 'doc/rfc/rfc2194.txt')
| -rw-r--r-- | doc/rfc/rfc2194.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc2194.txt b/doc/rfc/rfc2194.txt new file mode 100644 index 0000000..90592c8 --- /dev/null +++ b/doc/rfc/rfc2194.txt @@ -0,0 +1,1963 @@ + + + + + + +Network Working Group B. Aboba +Request for Comments: 2194 Microsoft +Category: Informational J. Lu + AimQuest Corp. + J. Alsop + i-Pass Alliance + J. Ding + Asiainfo + W. Wang + Merit Network, Inc. + September 1997 + + + 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 compilation + Phone book update + Connection management + Authentication + NAS Configuration/Authorization + Address assignment and routing + Security + Accounting + + 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. + +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 + attributes. + + + + + + +Aboba, et. al. Informational [Page 2] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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. + + + +Aboba, et. al. Informational [Page 4] + +RFC 2194 Review of Roaming Implementations September 1997 + + +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) + 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 + 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: + + http://www.aimquest.com/dialer.html + +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. + + + + + +Aboba, et. al. Informational [Page 5] + +RFC 2194 Review of Roaming Implementations September 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 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 e- + mail 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 + + + +Aboba, et. al. Informational [Page 6] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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. + + + + + +Aboba, et. al. Informational [Page 7] + +RFC 2194 Review of Roaming Implementations September 1997 + + +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 + +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 + identical 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 + reporting: + + Attribute Number Type + --------- ------ ---- + + Roaming-Server-ID 101 string + Isp-ID 102 string + + The Roaming-Server-ID attribute identifies the AAS sending the + authentication 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). + + + + + +Aboba, et. al. Informational [Page 8] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + 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. + +5. i-Pass implementation + +5.1. Overview + + i-Pass Alliance Inc., based in Mountain View, California, has + developed and operates a commercial authentication and settlement + clearinghouse 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 serverwhere 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 + information 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 + + + +Aboba, et. al. Informational [Page 9] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + + ni-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. + + 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 onISPs 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 forwarded + to an i-Pass server. + + + + + + + +Aboba, et. al. Informational [Page 10] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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" + interfaces for the most commonly used authentication methods. At the + date of writing, the following interfaces are supported: + + Livingston RADIUS + 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 + FreeBSD + 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, + + + +Aboba, et. al. Informational [Page 11] + +RFC 2194 Review of Roaming Implementations September 1997 + + + accounting 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 + 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 and are + distributed 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 + consists 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. + + + +Aboba, et. al. Informational [Page 12] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + backbone. Constructed by Asiainfo, a Dallas based system integration + company, 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 + Internet access, most cities have the same Internet access number. + Therefore a phone book is not currently required for the ChinaNet + implementation. 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 + authenticating 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. + + + + +Aboba, et. al. Informational [Page 13] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 information in its cache, it will act as a proxy, + forwarding the authentication 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 + scalability 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 + consideration. + + + +Aboba, et. al. Informational [Page 14] + +RFC 2194 Review of Roaming Implementations September 1997 + + +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. + +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 + cooperation with access partners. Since users are able to connect to + 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 + + + + + + +Aboba, et. al. Informational [Page 15] + +RFC 2194 Review of Roaming Implementations September 1997 + + + currently 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 + compilation. + + +7.2. Phone number presentation + + The Connection Manager is responsible for the presentation and + updating 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 service 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. + However, 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 + comprised 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 comprised 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 + + + +Aboba, et. al. Informational [Page 16] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + The filename of the dialup network file + (typically refers to a script associated with the number) + + + + + + + + +Aboba, et. al. Informational [Page 17] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + introduction 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 + description 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 information useful on a per-provider basis would include: + + Provider voice phone number + Provider icon + Provider fax phone number + Provider customer support phone number + + + + + +Aboba, et. al. Informational [Page 18] + +RFC 2194 Review of Roaming Implementations September 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 + forwarded 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 + supports 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 + individual 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 + Connection 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 + version of the phone book on the client, in order to determine what + it wants to send back. + + + + +Aboba, et. al. Informational [Page 19] + +RFC 2194 Review of Roaming Implementations September 1997 + + + In the GET response, the phone book server responds 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. 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 + configured via use of Windows Dialup Networking, including PPP and + SLIP running 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 + prefix notation significantly increases the number of characters + available 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 + + + + + + +Aboba, et. al. Informational [Page 20] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 configuration file. + + While static configuration files work well for small roaming + consortia, 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 + differently, or may be from a different vendor. As a result, it may + be necessary for the RADIUS proxy to edit the attribute set returned + by the home RADIUS server, in order to provide the local NAS with the + appropriate 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 + common. 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, et. al. Informational [Page 21] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 specific 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 + customers, 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 + versions 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. + + + + + +Aboba, et. al. Informational [Page 22] + +RFC 2194 Review of Roaming Implementations September 1997 + + +7.11. Accounting + + In the MSN roaming implementation, the accounting data exchange + process 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 protocols. 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 + accounting protocol, then the record format will not be of much + usefor 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.) + + + + +Aboba, et. al. Informational [Page 23] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 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 + Washington, 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. + + + + +Aboba, et. al. Informational [Page 24] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + organization has need of the port, is implemented by having the proxy + core 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 + simultaneous guest sessions for realms. Each realm is allocated a + number of "simultaneous access tokens" - SATs. When a guest session + is authorized the end server for the realm decrements the count of + available SATs, and when the session is terminated the count of SATs + is incremented. 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 network to the total number of tokens allocated to all realms. + + + + + + + +Aboba, et. al. Informational [Page 25] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 affiliate 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 investigated. + + 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/affiliate server for approval. Session records are logged at + the Merit core server and at the member/affiliate erver. Merit bills + members/affiliates monthly, based on processing of the accounting + logs. The members and affiliates are responsible for rebilling their + users. + + The Merit AAA software supports the ability to request positive + confirmation of acceptance of charges, and provides tools for + accumulating 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 development. + + + +Aboba, et. al. Informational [Page 26] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + policies 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 huntgrup (MichNet National + and International Service), the ISP sends a RADIUS access request to + a Merit core server. The rest of the authentication and authorization + 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 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 + + + + + + + + +Aboba, et. al. Informational [Page 27] + +RFC 2194 Review of Roaming Implementations September 1997 + + + available tokens, or to limit number of simultaneous sessions for a + given AccessID. 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 maintenance 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 + sessions 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 + correspond 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 + Livingston, 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. + + + +Aboba, et. al. Informational [Page 28] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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. + 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/Authorization 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 versions 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 + synchronization 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 + numbers. 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 + transmitted 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 + proposals are available from the FidoNet archive at + http://www.fidonet.org/. + + + + +Aboba, et. al. Informational [Page 29] + +RFC 2194 Review of Roaming Implementations September 1997 + + +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. + + 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 hone book synchronization, users + need only know the FidoNet address of the systems they wish to + contact. 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 + present lists of nodes, and as a result, FidoNet Nodelist compilers + typically 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 + number, 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) + + + +Aboba, et. al. Informational [Page 30] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + modulation and error correction protocols. Reference [4] also + proposes a series of ISDN capability flags, and [5] proposes flags to + indicate times of system availability. + + +9.3. Phone number exchange + + FidoNet coordinators are responsible for maintaining up to date + information on their networks, regions, and zones. Every week network + coordinators 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 submissions 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 + possibility 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. + + + + + + +Aboba, et. al. Informational [Page 31] + +RFC 2194 Review of Roaming Implementations September 1997 + + +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. + + While it is standard practice for participating systems to get their + Nodelists from their local network coordinators, should the local + network 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. + + + + +Aboba, et. al. Informational [Page 32] + +RFC 2194 Review of Roaming Implementations September 1997 + + + 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 + administrator. + +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 preparation and transmission of the Nodediffs. A single shared + secret is used per system. + +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 acounting + are not implemented 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. + +Security Considerations + + Security issues are discussed in sections 5.6 and 6.5. + + + + + + + + +Aboba, et. al. Informational [Page 33] + +RFC 2194 Review of Roaming Implementations September 1997 + + +11. References + + [1] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for + Name Server Addresses", RFC 1877, Microsoft, December 1995. + + [2] Fielding, R., et al., "Hypertext Transfer Protocol - HTTP/1.1.", + RFC 2068, UC Irvine, January, 1997. + + [3] Baker, B., R. Moore, D. Nugent. "The Distribution + Nodelist." FTS-0005, February, 1996. + + [4] Lentz, A. "ISDN Nodelist flags." FSC-0091, June, 1996. + + [5] Thomas, D. J. "A Proposed Nodelist flag indicating Online Times + of a Node." FSC-0062, April, 1996. + + [6] Kolin, L. "Security Passwords in Nodelist Update Files." + FSC-0055, March, 1991. + + [7] Gwinn, R., D. Dodell. "Nodelist Flag Changes Draft Document." + FSC-0009, November, 1987. + + [8] Heller, R. "A Proposal for A FidoNet Domain Name + Service." FSC-0069, December, 1992. + + [9] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2058, Livingston, + Merit, Daydreamer, January 1997. + + [10] Rigney, C., "RADIUS Accounting", RFC 2059, Livingston, January + 1997. + + + + + + + + + + + + + + + + + + + + +Aboba, et. al. Informational [Page 34] + +RFC 2194 Review of Roaming Implementations September 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, et. al. Informational [Page 35] + |