doc: Add RFC documents

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]
+