Internet DRAFT - draft-ietf-roamops-imprev


HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 07:13:08 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 10 Jun 1997 15:38:00 GMT
ETag: "304f84-156df-339d74d8"
Accept-Ranges: bytes
Content-Length: 87775
Connection: close
Content-Type: text/plain

     ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                               Microsoft
     Category: Informational                                        Juan Lu
     <draft-ietf-roamops-imprev-03.txt>                      AimQuest Corp.
     10 June 1997                                                John Alsop
                                                            i-Pass Alliance
                                                                 James Ding
                                                                   Wei Wang
                                                        Merit Network, Inc.

                       Review of Roaming Implementations

     1.  Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''

     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   (US  East  Coast),
     (Europe), (US West Coast), or (Pacific Rim).

     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-roamops-imprev-03.txt>, and  expires  January  1,  1998.   Please
     send comments to the authors.

     2.  Abstract

     This document reviews the design and functionality of existing roaming
     implementations.  "Roaming capability" may be loosely defined  as  the
     ability  to use any one of multiple Internet service providers (ISPs),
     while maintaining a formal,  customer-vendor  relationship  with  only
     one.   Examples  of  cases  where roaming capability might be required
     include ISP "confederations" and ISP-provided corporate network access

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 1]

     INTERNET-DRAFT                                            10 June 1997

     3.  Introduction

     Considerable  interest  has  arisen recently in a set of features that
     fit within the general category of "roaming capability"  for  Internet
     users.  Interested parties have included:

          Regional  Internet  Service  Providers  (ISPs) operating within a
          particular state or province, looking to  combine  their  efforts
          with  those  of  other regional providers to offer service over a
          wider area.

          National ISPs wishing to combine their operations with  those  of
          one  or  more  ISPs in another nation to offer more comprehensive
          service in a group of countries or on a continent.

          Businesses desiring to  offer  their  employees  a  comprehensive
          package of access services on a global basis.  Those services may
          include Internet access as well as  secure  access  to  corporate
          intranets via a Virtual Private Network (VPN), enabled by tunnel-
          ing protocols such as PPTP, L2F, or L2TP.

     What is required to provide roaming capability?  The following list is
     a  first cut at defining the requirements for successful roaming among
     an arbitrary set of ISPs:

          Phone number presentation
          Phone number exchange
          Phone book compilation
          Phone book update
          Connection management
          NAS Configuration/Authorization
          Address assignment and routing

     In this document we review existing roaming implementations,  describ-
     ing  their  functionality  within this framework.  In addition to full
     fledged roaming implementations, we will also  review  implementations
     that, while not meeting the strict definition of roaming, address sev-
     eral of these problem elements. These implementations  typically  fall
     into the category of shared use networks or non-IP dialup networks.

     3.1.  Terminology

     This document frequently uses the following terms:

     home ISP  This  is  the  Internet  service provider with whom the user
               maintains an account relationship.

     local ISP This is the Internet service provider whom the user calls in
               order  to get access. Where roaming is implemented the local

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 2]

     INTERNET-DRAFT                                            10 June 1997

               ISP may be different from the home ISP.

     phone book
               This is a database or document containing data pertaining to
               dialup  access,  including  phone numbers and any associated

     shared use network
               This is an IP dialup network whose use is shared by  two  or
               more organizations.  Shared use networks typically implement
               distributed authentication and accounting in order to facil-
               itate  the  relationship  among  the  sharing parties. Since
               these facilities are also  required  for  implementation  of
               roaming,  implementation of shared use is frequently a first
               step toward development of roaming  capabilities.  In  fact,
               one  of  the ways by which a provider may offer roaming ser-
               vice is to conclude shared use agreements with multiple net-
               works.  However,  to date the ability to accomplish this has
               been hampered by lack of interoperability among  shared  use

     non-IP dialup network
               This is a dialup network providing user access to the member
               systems via protocols other than  IP.   These  networks  may
               implement phone book synchronization facilities, in order to
               provide systems, administrators and  users  with  a  current
               list  of  participating  systems.  Examples of non-IP dialup
               networks  supporting  phone  book  synchronization   include
               FidoNet and WWIVnet.

     4.  Global Reach Internet Consortium (GRIC)

     Led by a US-based Internet technology developer, AimQuest Corporation,
     ten Internet Service Providers (ISPs) from the USA, Australia,  China,
     Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the
     Global Reach Internet Connection (GRIC) in May, 1996.   The  goals  of
     GRIC were to facilitate the implementation of a global roaming service
     and to coordinate billing and settlement among the membership. Commer-
     cial  operation  began in December of 1996, and GRIC has grown to over
     50 major ISPs and Telcos from all over the  world,  including  NETCOM,
     USA;  KDD  and  Mitsubishi,  Japan;  iStar,  Canada; Easynet, UK; Con-,  Australia;  Iprolink,   Switzerland;   Singapore   Telecom;
     Chunghwa  Telecom,  Taiwan; and Telekom Malaysia.  Information on GRIC
     is available from

     In implementing their roaming service, GRIC members have chosen  soft-
     ware developed by AimQuest. AimQuest Corporation's roaming implementa-
     tion comprises the following major components: the AimTraveler Authen-
     tication  Server  (AAS), the AimTraveler Routing Server (ARS), and the
     AimQuest Internet  Management  System  (AIMS),  software  designed  to

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 3]

     INTERNET-DRAFT                                            10 June 1997

     facilitate  the  billing  process. Information on the AimQuest roaming
     implementation is available from

     The AimTraveler Authentication Server (AAS) runs at  each  member  ISP
     location,  and  handles  incoming  authentication  requests  from  NAS
     devices. The AimTraveler Routing Server (ARS) can run anywhere. A sin-
     gle  routing  server can be used where centralized routing is desired,
     or multiple routing servers can be run in order to increase speed  and
     reliability  or to gateway to networks of particularly large partners.

     The first version of the AimTraveler software, deployed by AimQuest in
     May,  1996,  supported  direct  authentication  between members of the
     roaming consortium, but as GRIC grew, management of the  relationships
     between  the authentication servers became a problem. In August. 1996,
     AimQuest began development of the AimTraveler Routing Server (ARS)  in
     order to improve scalability.

     The  routing server is comprised of two elements: The Central Account-
     ing Server and the Central  Routing  Server.  The  Central  Accounting
     Server  collects  all the roaming accounting data for settlement.  The
     Central Routing  Server  manages  and  maintains  information  on  the
     authentication servers in the roaming consortium. Adding, deleting, or
     updating ISP authentication server information (e.g. adding a new mem-
     ber ISP) may be accomplished by editing of a configuration file on the
     Central Routing Server. The configuration  files  of  the  AimTraveler
     Authentication Servers do not need to be modified.

     The  AimTraveler  Authentication and Routing Servers are available for
     various UNIX platforms. Versions for Windows NT are under development.
     The  AimTraveler Authentication Server supports both the UNIX password
     file and Kerberos.

     The AimQuest Internet Management System (AIMS) is designed  for  large
     ISPs  who need a centralized management system for all ISP operations,
     including sales, trouble-ticketing, service, and billing.   AIMS  pro-
     duces  usage and transaction statement reports, and includes a settle-
     ment module to produce settlement/billing reports for the roaming con-
     sortium  members.  Based  on these reports, the providers charge their
     ISP/roaming customers, and pay/settle the roaming  balance  among  the
     providers.  AIMS  currently  runs on Sun/Solaris/Oracle. A version for
     Windows NT and SQL Server is expected to become available in Q4  1996.

     4.1.  Phone number presentation

     Currently there are two principal methods by which GRIC users can dis-
     cover available phone numbers: a Web-bsed directory  provided  by  the
     GRIC secretariat, and an automatically updated phone book supported by
     the AimQuest Ranger software.

     4.1.1.  Web based directory

     A directory of GRIC phone numbers is available on the GRIC home  page,   The list of numbers is arranged by country and

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 4]

     INTERNET-DRAFT                                            10 June 1997

     provider. For each provider within a country, this directory, provided
     in the form of a table, offers the following information:

          Provider address, voice phone and fax
          Customer support phone number
          Provider domain name
          Primary Domain Name Server
          Secondary Domain Name Server
          Dial-up IP Address
          News server
          Web page
          POP phone numbers (i.e. 1-408-366-9000)
          POP locations (i.e. Berkeley)
          Proxy addresses
          Dialer configuration

     In  order  to discover phone numbers using the Web-based directory, it
     is expected that users will be online, and will navigate to the appro-
     priate  country  and provider. They then look up the number and insert
     it into the AimQuest Ranger dialer.

     4.1.2.  AimQuest Ranger phone book

     The AimQuest Ranger software provides for phone book  presentation  as
     well  as  automated  updating  of  phone numbers.  The AimQuest Ranger
     phone book includes a country list, provider list, and POP (phone num-
     ber)  list,  as  well  as detailed provider information, including the
     cutomer support phone number, and Internet server configuration  info.
     The  Phone book, developed with Microsoft VC++, is available for down-
     load from the AimQuest ftp site:

     A copy of the phone book is also available from the  GRIC  phone  book
     page, available at

     4.2.  Phone number exchange

     GRIC  members  submit information both about themselves and their POPs
     to the GRIC secretariat, which is run by  AimQuest.  The  GRIC  secre-
     tariat then compiles a new phone book and provides updates on the GRIC
     FTP and Web servers.

     GRIC users then download the phone numbers either in Windows .ini file
     format  (viewable  via  the  AimQuest  Ranger  phone book), or in HTML
     (viewable via a Web browser).

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 5]

     INTERNET-DRAFT                                            10 June 1997

     4.3.  Phone book compilation

     GRIC phone books are compiled manually, and represent a  concatenation
     of  available  numbers from all the members of the roaming consortium,
     with no policy application.  As new POPs come online, the numbers  are
     forwarded to GRIC, which adds them to the phone book servers.

     4.4.  Phone book update

     Phone  numbers in the AimQuest Ranger phone book are updated automati-
     cally.  The AimTraveler server includes an address book which contains
     the phone numbers of all the roaming consortium members.

     4.5.  Connection management

     The AimTraveler and AimQuest Ranger software supports SLIP and PPP, as
     well as PAP and CHAP authentication.

     4.6.  Authentication

     GRIC implements distributed authentication, utilizing  the  user's  e-
     mail  address  as  the userID (i.e. "") presented to the
     remote NAS device. The AimQuest Ranger software takes care of present-
     ing the e-mail address as the userID for PAP or CHAP authentication.

     After the initial PPP authentication exchange, the userID, domain, and
     pasword information (or in the case of CHAP,  the  challenge  and  the
     response) are then passed by the NAS to the AimTraveler Authentication
     Server which supports both TACACS+ and RADIUS.

     If the authentication request comes from  a  regular  customer  login,
     normal  user  id and password authentication is performed. If the user
     requesting authentication is a "roamer," (has a userID with an  @  and
     domain  name), the authentication server sends an query to the closest
     routing server. When AimTraveler Routing Server receives the authenti-
     cation  request,  it  first authenticates the AAS sending the request,
     and if this is successful, it checks its authentication server  table.
     If it is able to match the domain of the user to that of a "Home ISP",
     then the Home ISP authentication server's routing information are sent
     back  to  the local ISP's authentication server. Based on the informa-
     tion received from the routing server,  the  AAS  makes  an  authenti-
     cation   request   to  the  user's  Home ISP AAS for user id and pass-
     word verification.

     If the user is a valid user, the Home ISP authentication server  sends
     a  "permission  granted"  message back to the Local ISP authentication
     server. The Local ISP authentication server then requests the  NAS  to
     grant  the  user  a  dynamic  IP address from its address pool. If the
     username or password is incorrect, the Home ISP AAS will send a rejec-
     tion message to the Local ISP AAS, and the user will be dropped by the

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 6]

     INTERNET-DRAFT                                            10 June 1997

     If multiple routing servers are installed, and the query to the  first
     routing  server  does not result in a match, the query is forwarded to
     the next routing server. The server queries are cached on the  routing
     servers,  improving speed for repeated queries. The cache is sustained
     until a routing server table entry is updated or deleted.  Updating or
     deleting  results  in  a  message  to  all neighbor routing servers to
     delete their caches.

     The local authentication server also receives the accounting data from
     the  NAS.  If  the  data  is for a regular customer login, the data is
     written to the Local ISP AAS log file. If the data is for a  "roamer,"
     the  data  is written to three places: the Local ISP AAS log file, the
     Home ISP AAS log file, and the ARS log file.

     If the local ISP authentication server has caching turned on, then  it
     will  cache  information  on Home ISP authentication server configura-
     tions sent by the routing server. This means that if the  same  domain
     is  queried  again,  the  local authentication server does not need to
     query the routing server again. The local cache is  cleared  when  the
     local  authentication server receives an update message from the rout-
     ing server or system manager.

     4.7.  NAS Configuration/Authorization

     AimTraveler is comprised  of  two  components,  a  Client(AAS)  and  a

     The  AimTraveler Client acts as the PPP dial-up authentication server.
     When it detects an '@' sign in  the  userID  field,   it  queries  the
     AimTraverler  Server  for  routing  information,  then  forwards   the
     authentication request to user's home authentication server.  The Aim-
     Traveler  Server, a centralized  routing server,  contains the  autho-
     rized  ISP's  domain name, authentication servers and  other  informa-

     The  AimTraveler  currently supports  RADIUS  and  TACACS+,  and could
     be extended  to  support  other  authentication  protocols.   It  also
     receives all the accounting records, which are  subsequently  used  as
     input data for billing.

     Since  ISPs' NAS devices may be configured differently, the attributes
     returned by the home ISP AAS are discarded.

     4.8.  Address assignment and routing

     All addresses in GRIC are assigned dynamically from within the address
     pool of the local ISP.  Static addresses and  routed  LAN  connections
     will  be  considered in the future, when GRIC offers corporate roaming

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 7]

     INTERNET-DRAFT                                            10 June 1997

     4.9.  Security

     The user's password is hashed with MD5  before  being  sent  from  the
     Local  ISP  AAS  to  the  Home  ISP  AAS.  An encryption key is shared
     between the AAS and ARS. The current version of AimTraveler  AAS  does
     not support token cards or tunneling protocols.

     4.10.  Accounting

     The AimTraveler Authentication Server (AAS) software can act as either
     a RADIUS or TACACS+ accounting server.  When accounting information is
     received  from  the  NAS,  the local AimTraveler Authentication Server
     (AAS) sends accounting data (user name, domain name,  login  time)  to
     both  the  Central  Accounting Server (part of the ARS) and the user's
     Home ISP AimTraveler authentication server. In the case of  GRIC,  the
     Central Accounting Server is run by AimQuest.

     The  data sent to the central accounting server and home ISP are iden-
     tical except for the form of user id and time stamp.  For  a  traveler
     whose  home ISP is in the US, but who is traveling in Japan, the Local
     (Japanese) ISP  AimTraveler  authentication  server  will  receive  an
     accounting  record timestamped with Japan time while the Home (US) ISP
     AimTraveler authentication server will receive  an  accounting  record
     timestamped with the appropriate US timezone.

     The  accounting  data includes 2 new attributes for settlement report-

     Attribute              Number   Type
     ---------              ------   ----

     Roaming-Server-ID       101     string
     Isp-ID                  102     string

     The Roaming-Server-ID attribute identifies the AAS sending the authen-
     tication  request.   The  Isp-ID  attribute  identifies the local ISP.
     Using this information the home ISP can track the  roaming  activities
     of its users (where their users are logging in).

     The  AimTraveler  Server  running  at  AimQuest keeps a record of  all
     roaming transactions, which are used as input to  the  settlement  and
     billing  process.  At the end of each month, AimQuest provides a roam-
     ing transaction summary to GRIC members using AIMS. The AIMS  software
     is  configurable  so  that  it takes into account the settlement rules
     agreed to by GRIC members.

     5.  i-Pass implementation

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 8]

     INTERNET-DRAFT                                            10 June 1997

     5.1.  Overview

     i-Pass Alliance Inc., based in Mountain View, California,  has  devel-
     oped and operates a commercial authentication and settlement clearing-
     house service which provides global roaming between  Internet  service
     providers.  The service is fully operational.

     i-Pass Alliance Inc. has additional offices in Toronto, Singapore, and
     London.   More  information   on   i-Pass   can   be   obtained   from

     The  i-Pass network consists of a number of servers that provide real-
     time authentication services to partner ISPs.  Authentication requests
     and  accounting records for roaming users are encrypted and sent to an
     i-Pass server where they are logged, and then forwarded to a home  ISP
     for authentication and/or logging.

     Periodically,  i-Pass  reconciles  all  accounting  records, generates
     billing statements, and acts as a  single  point  for  collecting  and
     remitting payments.

     i-Pass  provides  its  service  only to ISPs and channel partners.  It
     does not attempt to establish a business relationship with individual-
     user customers of an ISP.

     5.2.  Access Point Database (APD)

     i-Pass  maintains  a  list  of  roaming  access  points  in  an Oracle
     database.  This list is searchable by geographical region using a  Web
     browser, and may be downloaded in its entirety using FTP. The informa-
     tion stored for each access point includes:

          Name of service provider
          State or Province
          City or Region
          Telephone number
          Technical support phone number
          Service types available
          Technical information (help file)
          Service pricing information

     The Access Point Database is maintained  by  i-Pass  staff,  based  on
     input from i-Pass partners.

     5.3.  Phone number presentation

     i-Pass  has  developed  a  Windows  application wth a simple point and
     click interface called the "i-Pass Dial Wizard",  which  assists  end-
     users in selecting and connecting to a local Internet access point.

     Aboba, Lu, Alsop, Ding & Wang                                 [Page 9]

     INTERNET-DRAFT                                            10 June 1997

     The Dial Wizard allows users to first select the country in which they
     are roaming.  A list of states, provinces, or  other  regions  in  the
     selected  country  is then presented.  Finally a list of access points
     within the state or province is presented.  The Dial  Wizard  displays
     the  city  name,  modem  phone  number, and price information for each
     access point within the state or region.

     When the user selects the desired access point, a Windows  95  "DialUp
     Networking"  icon  is  created  for  that access point.  If there is a
     login script associated with the access point,  the  DialUp  Scripting
     tool  is  automatically  configured.   This means that end-users never
     have to configure any login scripting requirements.

     The Dial Wizard has a built-in phonebook  containing  all  the  i-Pass
     access  points.   The  phonebook may be automatically refreshed from a
     master copy located onhe ISPs web site.

     The Dial Wizard is provided free of charge to i-Pass partners.  i-Pass
     also  provides  the  i-Pass Dial Wizard Customization Kit which allows
     ISP partners to generate customized versions of the Dial  Wizard  with
     their own logo, etc.

     5.4.  Authentication

     There  are  three  entities  involved  in  servicing an authentication

     Local ISP At the local ISP, the authentication server is  modified  to
               recognize user IDs of the form username@auth_domain as being
               remote authentication requests.   These  requests  are  for-
               warded to an i-Pass server.

     i-Pass Server
               The  i-Pass server receives the authentication request, logs
               it, and forwards it  to  the  home  ISP  identified  by  the
               auth_domain portion of the user ID.

     Home ISP  The  home  ISP receives the authentication request, performs
               authentication using its normal authentication  method,  and
               returns  a  YES/NO  response  to the i-Pass server, which in
               turn forwards the reply to the originating ISP.

     i-Pass provides software components which run  on  the  authentication
     servers  of  the  local and home ISPs.  Each member ISP must integrate
     these components with the native authentication method being  used  by
     the ISP.  To simplify this task, i-Pass has developed "drop-in" inter-
     faces for the most commonly used authentication methods.  At the  date
     of writing, the following interfaces are supported:

          Livingston RADIUS

     Aboba, Lu, Alsop, Ding & Wang                                [Page 10]

     INTERNET-DRAFT                                            10 June 1997

          Ascend RADIUS
          Merit RADIUS
          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

          Solaris 2.5 (Sparc).LI
          Solaris 2.5 (Intel)
          Digital Unix

     ISPs  may  chooe to provide authentication for their end-users roaming
     elsewhere, but not to provide access points to the i-Pass network.  In
     this  case  the software integration effort is greatly reduced and can
     be as little as 1/2 a man-day.

     5.5.  Accounting

     Accounting transactions are handled in the same way as  authentication
     requests.  In addition to being logged at the i-Pass servers, account-
     ing transactions are sent in real-time  to  the  home  ISP.   This  is
     intended  to allow ISPs to update users' credit limit information on a
     real-time basis (to the extent that this capability  is  supported  by
     their billing and accounting systems).

     Settlement is performed monthly.  The settlement process involves cal-
     culating the costs associated with each individual session, and aggre-
     gating  them  for  each ISP.  A net amount is then calculated which is
     either due from i-Pass to the ISP, or from the ISP to i-Pass,  depend-
     ing on the actual usage pattern.

     The following reports are supplied to member ISPs:

          A Monthly Statement showing summaries of usage,
          service provided, and any adjustments along with the
          net amount owing.

          A Call Detail Report showing roaming usage by the ISP's

          A Service Provided report showing detailed usage of
          the ISP's facilities by remote users.

     The above reports are generated as ASCII documents and are distributed

     Aboba, Lu, Alsop, Ding & Wang                                [Page 11]

     INTERNET-DRAFT                                            10 June 1997

     to i-Pass partners electronically, either by e-mail or from  a  secure
     area on the i-Pass web site. Hard-copy output is available on request.

     The Call Detail Report is also generated as  a  comma-delimited  ASCII
     file  suitable  for  import  into the ISP's billing database. The Call
     Detail Report will normally be used by the ISP  to  generate  end-user
     billing for roaming usage.

     5.6.  Security

     All  transactions  between  ISPs  and the i-Pass servers are encrypted
     using the SSL protocol.  Public key certificates are verified at  both
     the  client  and  server. i-Pass issues these certificates and acts as
     the Cetificate Authority.

     Transactions are also verified based on a  number  of  other  criteria
     such as source IP address.

     5.7.  Operations

     i-Pass  operates  several authentication server sites.  Each site con-
     sists of two redundant server systems located in secure facilities and
     "close" to the Internet backbone.  The authentication server sites are
     geographically distributed to minimize the possibility of failure  due
     to natural disasters etc.

     i-Pass maintains a Network Operations Center in Mountain View which is
     staffed on a 7x24 basis.  Its functions include monitoring the  i-Pass
     authentication  servers,  monitoring authentication servers located at
     partner facilities, and dealing with problem reports.

     6.  ChinaNet implementation

     ChinaNet, owned by China Telecom, is China's  largest  Internet  back-
     bone.  Constructed by Asiainfo, a Dallas based system integration com-
     pany, it has 31  backbone  nodes  in  31  Chinese  provincial  capital
     cities.  Each province is building its own provincial network, has its
     own dialup servers, and administers its own user base.

     In order to allow hinaNet users to be able  to  access  nodes  outside
     their  province  while traveling, a nationwide roaming system has been
     implemented.  The roaming system was developed  by  AsiaInfo,  and  is
     based on the RADIUS protocol.

     6.1.  Phone number presentation

     Since  China Telecom uses one phone number (163) for nationwide Inter-
     net access, most cities have the same Internet access  number.  There-
     fore a phone book is not currently required for the ChinaNet implemen-
     tation. A web-based phone book will  be added  in  a  future  software
     release  in  order to support nationwide ISP/CSP telephone numbers and

     Aboba, Lu, Alsop, Ding & Wang                                [Page 12]

     INTERNET-DRAFT                                            10 June 1997

     HTTP server addresses.

     6.2.  Connection management

     The current roaming client and server supports both PPP and SLIP.

     6.3.  Address assignment and routing

     ChinaNet only supports  dynamic  IP  address  assignment  for  roaming
     users. In addition, static addresses are supported for users authenti-
     cating within their home province.

     6.4.  Authentication

     When user accesses a local NAS,  it  provides  its  userID  either  as
     "username"  or  "username@realm".   The  NAS  will pass the userID and
     password to the RADIUS proxy/server.  If the  "username"  notation  is
     used,  the  Radius  proxy/server  will assume that the user is a local
     user and will handle local  authentication  accordingly.   If   "user-
     name@realm"  is  used,  the  RADIUS  proxy/server will process it as a
     roaming request.

     When the RADIUS proxy/server handles a request from a roaming user, it
     will  first  check the cache to see if the user information is already
     stored there. If there is a cache hit, the RADIUS proxy/server do  the
     local  authentication  accordingly.  If it does not find user informa-
     tion in its cache, it will act as a proxy, forwarding the  authentica-
     tion  request  to the home RADIUS server.  When the home RADIUS server
     responds, the local server will forward the response to the  NAS.   If
     the  user  is authenticated by the home server, the local RADIUS proxy
     will cache the user information for  a  period  of  time  (3  days  by

     Caching  is  used to avoid frequent proxying of requests and responses
     between the local RADIUS proxy and the home RADIUS  server.  When  the
     home  RADIUS  server  sends  back a valid authentication response, the
     local RADIUS proxy/server will cache the user information for a period
     of  time  (3  days  by  default).   When  the  user next authenticates
     directly against the home RADIUS server, the home RADIUS  server  will
     send  a  request  to  the  local server or servers to clear the user's
     information from the cache.

     6.4.1.  Extended hierarchy

     In  some  provinces,  the  local   telecommunications   administration
     (Provincial  ISP)  further  delegates  control to county access nodes,
     creating another level of hierarchy. This is done to improve scalabil-
     ity  and  to avoid having the provincial ISP databases grow too large.
     In the current implementation, each provincial ISP maintains  its  own
     central  RADIUS  server,  including  information  on  all users in the
     province, while county nodes maintain distributed RADIUS servers.  For

     Aboba, Lu, Alsop, Ding & Wang                                [Page 13]

     INTERNET-DRAFT                                            10 June 1997

     intra-province  roaming  requests  the  local RADIUS proxy/server will
     directly forward the request to the home RADIUS server.

     However, for inter-province roaming requests, the local RADIUS  server
     does  not  forward  the  request  directly  to the home RADIUS server.
     Instead, the request is forwarded to  the  central  provincial  RADIUS
     server  for  the  home  province. This implementation is suitable only
     when county level ISPs do not mind combining and  sharing  their  user
     information.  In  this  instance, this is acceptable, since all county
     level ISPs are part of China Telecom. In a future release, this multi-
     layer hierarchy will be implemented using multi-layer proxy RADIUS, in
     a manner more resembling DNS.

     6.5.  Security

     Encryption is used between the local RADIUS proxy/server and the  home
     RADIUS  server. Public/Private key encryption will be supported in the
     next release. IP tunneling and token card support is under  considera-

     6.6.  Accounting

     Accounting   information  is  transferred  between  the  local  RADIUS
     accounting proxy/server and home RADIUS accounting server.  Every  day
     each  node  sends a summary accounting information record to a central
     server in order to support nationwide settlement. The  central  server
     is  run  by  the  central  Data Communication Bureau of China Telecom.
     Every month the central  server  sends  the  settlement  bill  to  the
     provincial ISPs.

     6.7.  Inter-ISP/CSP roaming

     ChinaNet  supports both ISP and CSP (Content Service Provider) roaming
     on its system. For example, Shanghai Online,  a  Web-based  commercial
     content  service, uses RADIUS for authentication of ChinaNet users who
     do not have a Shanghai Online account. In order to support  this,  the
     Shanghai  Online  servers  function  as a RADIUS client authenticating
     against the home RADIUS server. When users access a protected document
     on  the HTTP server, they are prompted to send a username/password for
     authentication. The user then responds with  their  userID  in  "user-
     name@realm" notation.

     A  CGI  script on the HTTP server then acts as a RADIUS authentication
     client, sending the request to the home RADIUS server. After the  home
     RADIUS  server  responds, the CGI script passes the information to the
     local authentication agent. From this  point  forward,  everything  is
     taken care of by the local Web authentication mechanism.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 14]

     INTERNET-DRAFT                                            10 June 1997

     7.  Microsoft implementation

     Microsoft's  roaming  implementation was originally developed in order
     to support the Microsoft Network  (MSN),  which  now  offers  Internet
     access in seven countries: US, Canada, France, Germany, UK, Japan, and
     Australia.  In each of these countries, service is offered in coopera-
     tion  with  access  partners.   Since users are able to connect to the
     access partner networks while maintaining a customer-vendor  relation-
     ship with MSN, this implementation fits within the definition of roam-
     ing as used in this document.

     7.1.  Implementation overview

     The first version of the Microsoft roaming software  was  deployed  by
     the  MSN  partners in April, 1996.  This version included a Phone Book
     manager  tool  running  under  Windows  95,  as  well  as   a   RADIUS
     server/proxy  implementation running under Windows NT; TACACS+ is cur-
     rently not supported.  Additional  components  now  under  development
     include a Connection Manager client for Windows 95 as well as an HTTP-
     based phone book server for Windows NT. The Phone Book manager tool is
     also  being upgraded to provide for more automated phone book compila-

     7.2.  Phone number presentation

     The Connection Manager is responsible for the presentation and  updat-
     ing  of  phone numbers, as well as for dialing and making connections.
     In order to select phone  numbers,  users  are  asked  to  select  the
     desired country and region/state.  Phone numbers are then presented in
     the area selected.  The primary numbers are those from the users  ser-
     vice  provider  which  match  the service type (Analog, ISDN, Analog &
     IDN), country and region/state selected. The other  numbers  (selected
     clicking  on  the  More  button) are those for other service providers
     that have a roaming agreement with the users service provider.

     7.2.1.  Cost data

     Cost data is not presented to users along with the phone numbers. How-
     ever,  such  information may be made available by other means, such as
     via a Web page.

     7.2.2.  Default phone book format

     The Connection Manager supports the ability  to  customize  the  phone
     book  format,  and it is expected that many ISPs will make use of this
     capability. However, for those who wish to use it "off  the  shelf"  a
     default  phone book format is provided. The default phone book is com-
     prised of several files, including:

          Service profile

     Aboba, Lu, Alsop, Ding & Wang                                [Page 15]

     INTERNET-DRAFT                                            10 June 1997

          Phone Book
          Region file

     The service profile provides information on a given service, which may
     be  an  isolated Internet Service Provider, or may represent a roaming
     consortium. The service profile, which is in .ini file format, is com-
     prised of the following information:

          The name of the service
          The filename of the service's big icon
          The filename of the service's little icon
          A description of the service
          The service phone book filename
          The service phone book version number
          The service regions file
          The URL of the service phone book server
          The prefix used by the service (i.e. "MSN/aboba")
          The suffix or domain used by the service (i.e. "")
          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
          Area code
          Local phone number
          Minimum Speed
          Maximum speed
          Capability Flags:
               Bit 0: 0=Toll, 1=Toll free
               Bit 1: 0=X25, 1=IP
               Bit 2: 0=Analog, 1=No analog support
               Bit 3: 0=no ISDN support, 1=ISDN
               Bit 4: 0
               Bit 5: 0
               Bit 6: 0=No Internet access, 1=Internet access
               Bit 7: 0=No signup access, 1=Signup access
               Bit 8-31: reserved

     Aboba, Lu, Alsop, Ding & Wang                                [Page 16]

     INTERNET-DRAFT                                            10 June 1997

          The filename of the dialup network file
             (typically refers to a script associated with the number)

     A sample phone book file is shown below:


     7.2.3.  Additional attributes

     As described previously, it is likely  that  some  ISPs  will  require
     additional phone number attributes or provider information beyond that
     supported in the default phone book format.   Attributes  of  interest
     may  vary between providers, or may arise as a result of the introduc-
     tion of new technologies.  As  a  result,  the  set  of  phone  number
     attributes  is  likely  to  evolve over time, and extensibility in the
     phone book format is highly desirable.

     For example, in addition to the attributes  provided  in  the  default
     phone book, the following additional attributes have been requested by

          Multicast support flag
          External/internal flag (to differentiate display between the
               "internal" or "other" list box)
          Priority  (for control of presentation order)
          Modem protocol capabilities (V.34, V.32bis, etc.)
          ISDN protocol capabilities (V.110, V.120, etc.)
          No password flag (for numbers using telephone-based billing)
          Provider name

     7.2.4.  Addition of information on providers

     The default phone book does not provide a  mechanism  for  display  of
     information on the individual ISPs within the roaming consortium, only
     for the consortium as a whole. For example, the  provider  icons  (big
     and  little) are included in the service profile. The service descrip-
     tion information is expected to contain the customer  support  number.
     However,  this  information  cannot be provided on an individual basis
     for each of the members of a roaming consortium.  Additional  informa-
     tion useful on a per-provider basis would include:

          Provider voice phone number
          Provider icon
          Provider fax phone number
          Provider customer support phone number

     Aboba, Lu, Alsop, Ding & Wang                                [Page 17]

     INTERNET-DRAFT                                            10 June 1997

     7.3.  Phone number exchange

     Currently  phone  number  exchange  is not supported by the phone book
     server. As a result, in the MSN implementation, phone number  exchange
     is  handled  manually.   As new POPs come online, the numbers are for-
     warded to MSN, which tests the numbers and approves them for  addition
     to  the phone book server. Updated phone books are produced and loaded
     on the phone book server on a weekly basis.

     7.4.  Phone book compilation

     The Phone Book Manager tool was created in order to make it easier for
     the  access  partners  to create and update their phone books. It sup-
     ports addition, removal, and editing of phone numbers, generating both
     a new phone book, as well as associated difference files.

     With  version 1 of the Phone Book Administration tool, phone books are
     compiled manually, and represent a concatenation of available  numbers
     from  all  partners,  with no policy application.  With version 1, the
     updates are prepared by the partners and forwarded to MSN, which tests
     the  numbers  and  approves  them  for addition to the phone book. The
     updates are then concatenated together to form the global update file.

     The  new  version of the Phone Book Administration tool automates much
     of the phone book compilation process, making it  possible  for  phone
     book  compilation  to be decentralized with each partner running their
     own phone book server. Partners can then maintain and test their indi-
     vidual phone books and post them on their own Phone Book Server.

     7.5.  Phone book update

     There  is  a  mechanism  to  download phone book deltas, as well as to
     download arbitrary executables which can perform more  complex  update
     processing.   Digital  signatures  are only used on the downloading of
     executables, since only these represent a security threat -  the  Con-
     nection Manager client does not check for digital signatures on deltas
     because bogus deltas can't really cause any harm.

     The Connection Manager updates the phone book each time the user  logs
     on.  This  is  accomplished  via an HTTP GET request to the phone book
     server. When the server is examining the request,  it  can  take  into
     account  things like the OS version on the client, the language on the
     client, the version of Connection Manager on the client, and the  ver-
     sion  of  the  phone book on the client, in order to determine what it
     wants to send back.

     In the GET response, the phone book server responds with  the  differ-
     ence  files  necessary to update the client's phone book to the latest
     version. The client then builds the new  phone  book  by  successively
     applying  these  difference files.  This process results in the update

     Aboba, Lu, Alsop, Ding & Wang                                [Page 18]

     INTERNET-DRAFT                                            10 June 1997

     of the entire phone book, and is simple enough to allow it to be  eas-
     ily  implemented  on a variety of HTTP servers, either as a CGI script
     or (on NT) as an ISAPI DLL.

     The difference files used in the default phone book consist of a  list
     of phone book entries, each uniquely identified by their index number.
     Additions consist of phone book entries with all the information filed
     in;  deletions are signified by entries with all entries zeroed out. A
     sample difference file is shown below:


     7.6.  Connection management

     The Connection Manager can support any protocol which can  be  config-
     ured via use of Windows Dialup Networking, including PPP and SLIP run-
     ning over IP.  The default setting is for the IP address  as  well  as
     the  DNS  server  IP address to be assigned by the NAS. The DNS server
     assignment capability is described in [1].

     7.7.  Authentication

     The Connection Manager client and  RADIUS  proxy/server  both  support
     suffix  style  notation  (i.e.  ""),  as well as a prefix
     notation ("MSN/aboba").

     The prefix notation was developed for use with NAS devices with  small
     maximum userID lengths.  For these devices the compactness of the pre-
     fix notation significantly increases the number of  characters  avail-
     able  for  the  userID field.  However, as an increasing number of NAS
     devices are now supporting 253 octet userIDs (the maximum supported by
     RADIUS) the need for prefix notation is declining.

     After receiving the userID from the Connection Manager client, the NAS
     device passes the userID/domain and password information  (or  in  the
     case of CHAP, the challenge and the response) to the RADIUS proxy. The
     RADIUS proxy then checks if the domain is authorized  for  roaming  by
     examining  a  static  configuration file. If the domain is authorized,
     the RADIUS proxy then forwards the request to the  appropriate  RADIUS
     server. The domain to server mapping is also made via a static config-
     uration file.

     While static configuration files work well for small  roaming  consor-
     tia,  for  larger  consortia static configuration will become tedious.
     Potentially more scalable solutions include use of DNS SRV records for
     the domain to RADIUS server mapping.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 19]

     INTERNET-DRAFT                                            10 June 1997

     7.8.  NAS configuration/authorization

     Although  the  attributes  returned by the home RADIUS server may make
     sense to home NAS devices, the local NAS  may  be  configured  differ-
     ently, or may be from a different vendor.  As a result, it may be nec-
     essary for the RADIUS proxy to edit the attribute set returned by  the
     home  RADIUS server, in order to provide the local NAS with the appro-
     priate configuration information.  The editing  occurs  via  attribute
     discard and insertion of attributes by the proxy.

     Alternatively,  the home RADIUS server may be configured not to return
     any network-specific attributes, and to allow these to be inserted  by
     the local RADIUS proxy.

     Attributes most likely to cause conflicts include:


     Conflicts  relating to IP address assignment and routing are very com-
     mon.  Where dynamic address assignment is used,  an  IP  address  pool
     appropriate  for  the  local NAS can be substituted for the IP address
     pool designated by the home RADIUS server.

     However, not all address conflicts can be  resolved  by  editing.   In
     some  cases,  (i.e., assignment of a static network address for a LAN)
     it may not be possible for the local NAS to  accept  the  home  RADIUS
     server's  address assignment, yet the roaming hosts may not be able to
     accept an alternative assignment.

     Filter IDs also pose a problem. It is possible that the local NAS  may
     not  implement  a  filter corresponding to that designated by the home
     RADIUS server. Even if an equivalent filter is implemented,  in  order
     to  guarantee  correct operation, the proxy's configuration must track
     changes in the filter configurations of each of  the  members  of  the
     roaming  consortium.  In  practice  this  is  likely to be unworkable.
     Direct upload of  filter  configuration  is  not  a  solution  either,
     because of the wide variation in filter languages supported in today's
     NAS devices.

     Since by definition vendor specific attributes have  meaning  only  to
     devices created by that vendor, use of these attributes is problematic
     within a heterogeneous roaming consortium. While  it  is  possible  to
     edit  these  attributes,  or  even to discard them or allow them to be
     ignored, this may not always be acceptable. In cases where vendor spe-
     cific  attributes relate to security, it may not be acceptable for the
     proxy to modify or  discard  these  attributes;  the  only  acceptable

     Aboba, Lu, Alsop, Ding & Wang                                [Page 20]

     INTERNET-DRAFT                                            10 June 1997

     action  may  be  for  the  local NAS to drop the user.  Unfortunately,
     RADIUS does not distinguish between mandatory and optional attributes,
     so  that  there  is  no  way  for  the proxy to take guidance from the

     Conflicts over session or idle timeouts may result if since  both  the
     local  and  home  ISP feel the need to adjust these parameters.  While
     the home ISP may wish to adjust the  parameter  to  match  the  user's
     software, the local ISP may wish to adjust it to match its own service
     policy. As long as the desired parameters do not differ too greatly, a
     compromise is often possible.

     7.9.  Address assignment and routing

     While the Connection Manager software supports both static and dynamic
     address assignment, in  the  MSN  implementation,  all  addresses  are
     dynamically assigned.

     However,  selected  partners also offer LAN connectivity to their cus-
     tomers, usually via static address assignment. However, these accounts
     do  not  have  roaming  privileges  since no mechanism has been put in
     place for allowing these static  routes  to  move  between  providers.
     Users  looking  to  do LAN roaming between providers are encouraged to
     select a router supporting Network Address Translation (NAT). NAT ver-
     sions  implemented  in several low-end routers are compatible with the
     dynamic addressing used on MSN, as well as supporting DHCP on the  LAN

     7.10.  Security

     The RADIUS proxy/server implementation does not support token cards or
     tunneling protocols.

     7.11.  Accounting

     In the MSN roaming implementation, the accounting data  exchange  pro-
     cess  is  specified  in  terms  of  an accounting record format, and a
     method by which the records are transferred from the partners to  MSN,
     which acts as the settlement agent.  Defining the interaction in terms
     of record formats and transfer protocols implies that the partners  do
     not  communicate with the settlement agent using NAS accounting proto-
     cols.  As a result, accounting protocol  interoperability  is  not  be

     However,  for this advantage to be fully realized, it is necessary for
     the accounting record format to be  extensible.  This  makes  it  more
     likely that the format can be adapted for use with the wide variety of
     accounting protocols in current use (such as SNMP, syslog, RADIUS, and
     TACACS+), as well as future protocols. After all, if the record format
     cannot express the metrics provided by a particular partner's account-
     ing  protocol,  then  the  record format will not be of much use for a

     Aboba, Lu, Alsop, Ding & Wang                                [Page 21]

     INTERNET-DRAFT                                            10 June 1997

     heterogeneous roaming consortium.

     7.11.1.  Accounting record format

     The Microsoft RADIUS proxy/server supports the  ability  to  customize
     the  accounting  record format, and it is expected that some ISPs will
     make use of this capability. However for those who want to use it "off
     the  shelf"  a  default  accounting  record  format  is  provided. The
     accounting record includes information provided by RADIUS:

          User Name (String; the user's ID, including prefix or suffix)
          NAS IP address (Integer; the IP address of the user's NAS)
          NAS Port (Integer; identifies the physical port on the NAS)
          Service Type (Integer; identifies the service provided to the user)
          NAS Identifier (Integer; unique identifier for the NAS)
          Status Type (Integer; indicates session start and stop,
             as well as accounting on and off)
          Delay Time (Integer; time client has been trying to send)
          Input Octets (Integer; in stop record, octets received from port)
          Output Octets (Integer; in stop record, octets sent to port)
          Session ID (Integer; unique ID linking start and stop records)
          Authentication (Integer; indicates how user was authenticated)
          Session Time (Integer; in stop record, seconds of received service)
          Input Packets (Integer; in stop record, packets received from port)
          Output Packets (Integer; in stop record, packets sent to port)
          Termination Cause (Integer; in stop record, indicates termination cause)
          Multi-Session ID (String; for linking of multiple related sessions)
          Link Count (Integer; number of links up when record was generated)
          NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)

     However, since this default format is not extensible, it cannot easily
     be  adapted to protocols other than RADIUS, services other than dialup
     (i.e. dedicated connections) or rated events  (i.e.  file  downloads).
     This  is  a  serious  limitation,  and  as  a  result,  customers have
     requested a more general accounting record format.

     7.11.2.  Transfer mechanism

     Prior to being transferred, the accounting records are  compressed  so
     as  to  save bandwidth.  The transfer of accounting records is handled
     via FTP, with the transfer being initiated  by  the  receiving  party,
     rather  than by the sending party.  A duplicate set of records is kept
     by the local ISP for verification purposes.

     8.  Merit Network Implementation

     8.1.  Overview

     MichNet is a regional IP backbone network operated within the state of
     Michigan  by Merit Network, Inc., a nonprofit corporation based in Ann

     Aboba, Lu, Alsop, Ding & Wang                                [Page 22]

     INTERNET-DRAFT                                            10 June 1997

     Arbor, Michigan. Started in 1966, MichNet currently provides  backbone
     level  Internet connectivity and dial-in IP services to its member and
     affiliate universities, colleges, K-12 schools, libraries,  government
     institutions,  other  nonprofit organizations, and commercial business

     As of May 1, 1997, MichNet had 11  members  and  405  affiliates.  Its
     shared dial-in service operated 133 sites in Michigan and one in Wash-
     ington, D.C, with 4774 dial-in lines.  Additional  dial-in  lines  and
     sites are being installed daily.

     MichNet  also  provides national and international dial-in services to
     its members and affiliates through an 800 number  and  other  external
     services contracting with national and global service providers.

     The  phone  numbers  of all MichNet shared dial-in sites are published
     both on the Merit web site and in the MichNet newsletters. Merit  also
     provides  links  to  information  about the national and international
     service sites through their  respective  providers'  web  sites.  Such
     information     can    be    found    at

     8.1.1.  MichNet State-Wide Shared Dial-In Services

     Each MichNet shared dial-in service site is owned  and  maintained  by
     either  Merit or by a member or affiliate organization. All sites must
     support PPP and Telnet connections.

     Each organization participating  in  the  shared  dial-in  service  is
     assigned  a  realm-name.   Typically  the realm-name resembles a fully
     qualified domain name. Users  accessing  the  shared  dial-in  service
     identify  themselves  by  using  a  MichNet AccessID which consists of
     their local id concatenated with "@" followed by the realm-name - e.g.

     Merit  operates  a set of Authentication, Authorization and Accounting
     (AAA) servers supporting the RADIUS protocol  which  are  called  core
     servers.  The  core  servers support all the dial-in service sites and
     act as proxy servers to other AAA servers running at the participating
     organizations. For security reasons, Merit staff run all core servers;
     in particular, the user password is in the clear when the  proxy  core
     server decodes an incoming request and then re-encodes it and forwards
     it out again,

     The core servers also  enforce  a  common  policy  among  all  dial-in
     servers.  The  most  important  policy is that each provider of access
     must make dial-in ports available to others when  the  provider's  own
     users do not have a need for them. To implement this policy, the proxy
     server distinguishes between realms that are owners  and  realms  that
     are guests.

     One  piece  of the policy determining whether the provider's organiza-
     tion has need of the port, is implemented by  having  the  proxy  core

     Aboba, Lu, Alsop, Ding & Wang                                [Page 23]

     INTERNET-DRAFT                                            10 June 1997

     server track the realms associated with each of the sessions connected
     at a particular huntgroup. If there are few ports available (where few
     is  determined by a formula) then guests are denied access. Guests are
     also assigned a time limit and their  sessions  are  terminated  after
     some  amount  of time (currently one hour during prime time, two hours
     during non-prime time).

     The other part of the policy is to limit the number of guests that are
     allowed to connect.  This is done by limiting the number of simultane-
     ous guest sessions for realms.  Each realm is allocated  a  number  of
     "simultaneous  access  tokens" - SATs.  When a guest session is autho-
     rized the end server for the realm decrements the count  of  available
     SATs,  and  when  the session is terminated the count of SATs is incr-
     mented.  A Merit specific attribute is added to  the  request  by  the
     core  if the session will be a "guest" and will require a SAT. The end
     server must include a reply with an attribute containing the  name  of
     the  "token pool" from which the token for this session is taken.  The
     effect of this is to limit the number of guests connected to the  net-
     work to the total number of tokens allocated to all realms.

     Each  realm is authenticated and authorized by its own AAA server. The
     proxy core servers forward requests to the appropriate server based on
     a  configuration file showing where each realm is to be authenticated.
     Requests from realms not in the configuration are dropped.

     The Merit AAA server software supports  this  policy.  Merit  provides
     this  software  to member and affiliate organizations. The software is
     designed to work with many existing authentication  servers,  such  as
     Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS.  This enables
     most institutions to utilize the authentication mechanism they have in

     8.1.2.  MichNet National and International Dial-In Services

     In addition to the MichNet shared dial-in service, Merit also provides
     access from locations outside  of  Michigan  by  interconnecting  with
     other dial-in services. These services are typically billed by connect
     time. Merit acts as the accounting agent between its member and affil-
     iate organizations and the outside service provider.

     The services currently supported are a national 800 number and service
     via the ADP/Autonet dial-in network. Connection with  IBM/Advantis  is
     being tested, and several other service interconnects are being inves-

     Calls placed by a Merit member/affiliate user to these external  dial-
     in services are authenticated by having each of those services forward
     RADIUS authentication requests and  accounting  messages  to  a  Merit
     proxy core server. The core forwards the requests to the member/affil-
     iate server for approval. Session records are logged at the Merit core
     server and at the member/affiliate server. Merit bills members/affili-
     ates monthly, based on processing of the accounting logs. The  members
     and affiliates are responsible for rebilling their users.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 24]

     INTERNET-DRAFT                                            10 June 1997

     The  Merit  AAA software supports the ability to request positive con-
     firmation of acceptance of charges, and provides tools for  accumulat-
     ing and reporting on use by realm and by user.

     8.2.  Authentication and Authorization

     Authentication  of a Telnet session is supported using the traditional
     id and password method, with the id being a MichNet  AccessID  of  the
     form user@realm, while a PPP session may be authenticated either using
     an AccessID and password within a script, or using  PAP.  Support  for
     challenge/response authentication mechanisms using EAP is under devel-

     When  a  user dials into a MichNet shared dial-in port, the NAS  sends
     an  Access-Request  to  a  core  AAA server using the RADIUS protocol.
     First the core server applies any appropriate huntgroup  access  poli-
     cies to the request. If the Request fails the policy check, an Access-
     Reject is returned to the NAS.  Otherwise, the core server forwards it
     to  the  user's  home  authentication  server  according to the user's
     realm.  The home authentication server  authenticates  and  authorizes
     the access request.  An Access-Accept or Access-Reject is sent back to
     the core server.  If an Access-Accept is sent, the  home  server  will
     create  a  dial-in  session identifier which is unique to this session
     and insert it in a Class attribute in  the  Access-Accept.   The  core
     server  looks  at  the  request  and the response from the home server
     again and decides either to accept or reject the request. Finally, the
     core server sends either an Access-Accept or Access-Reject to the NAS.

     When a user dials into a contracted ISP's huntgroup (MichNet  National
     and  International  Service), the ISP  sends  a RADIUS  access request
     to a Merit core server. The rest of the authentication and  authoriza-
     tion  path  is  the  same  as in the  shared  dial-in service,  except
     that no huntgroup access policy is  applied  but  a  Huntgroup-Service
     attribute  is  sent  to  the home authentication server with its value
     being the name of the service, and a copy of  the  attribute  must  be
     returned by the home server with a flag appended to the original value
     to indicate a positive authorization of user access to  the  specified

     The MichNet shared dial-in service typically requires authorization of
     some sort, for example, a user dialing into a  huntgroup  as  a  guest
     must  be  authorized with a token from the user's realm. Participating
     institutions have control in defining authorization  rules.  Currently
     authorization  may  be  done using any combination of the user's group
     status and user's account status. A set of programming  interfaces  is
     also provided for incorporating new authorization policies.

     8.3.  Accounting

     In  the  Merit  AAA  server, a session is defined as starting from the
     moment the user connects to the NAS, and ending at the point when  the
     user disconnects. During the course of a session, both the core server

     Aboba, Lu, Alsop, Ding & Wang                                [Page 25]

     INTERNET-DRAFT                                            10 June 1997

     and the home server maintain status  information  about  the  session.
     This  allows  the  AAA  servers to apply policies based on the current
     status, e.g. limit guest  access  by  realm  to  number  of  available
     tokens, or to limit number of simultaneous sessions for a given Acces-
     sID. Information such as whether the session is for a  guest,  whether
     it used a token, and other information is included with the accounting
     stop information when it is logged. Merit has made enhancements to the
     RADIUS  protocol, that are local to the AAA server, to support mainte-
     nance of session status information.

     When a user session is successfully authenticated, the NAS sends out a
     RADIUS  accounting  start  request to the core server. The core server
     forwards that request to the  user's  home  server.  The  home  server
     updates  the  status of the session and then responds to the core. The
     core server in turn responds to  the  NAS.  In  the  accounting  Start
     request,  a NAS conforming to the RADIUS specification must return the
     Class attribute and value it received in  the  Access-Accept  for  the
     session,  thus  sending back the dial-in session identifier created by
     the session's home server.

     When a user ends a session, an accounting stop request is sent through
     the  same  path.   the  same  path.  The dial-in session identifier is
     again returned by the NAS, providing a means of uniquely identifying a
     session.  By  configuring  the finite state machine in each of the AAA
     servers, any accounting requests may be logged by any of  the  servers
     where the accounting requests are received.

     Because  the  same  session  logs are available on every server in the
     path of a session's authorization  and  accounting  message,  problems
     with  reconciliation  of specific sessions may be resolved easily. For
     the shared dial-in service, there are no  usage  charges.   Merit  has
     tools  to  verify  that organizations do not authorize more guest ses-
     sions than  the  number  of  SATs  allocated to the organization.  For
     surcharged sessions, Merit sends each organization a summary bill each
     month. Files with detail session records  are  available  for  problem
     resolution.  Each  organization  is  responsible  for  billing its own
     users, and should have the same session records as  are  collected  by

     Merit  receives a monthly invoice from other dial-in service providers
     and pays them directly, after first verifying that the charges  corre-
     spond to the session records logged by Merit.

     8.4.  Software and Development

     Merit  has  developed the AAA server software which supports the above
     capabilities initially by modifying the RADIUS server provided by Liv-
     ingston,  and later by doing a nearly total rewrite of the software to
     make enhancement and extension of capabilites easier.  Merit  makes  a
     basic  version  of  its server freely available for noncommercial use.
     Merit has started the Merit AAA Server Consortium  which  consists  of
     Merit  and  a  number of NAS vedors, ISPs and server software vendors.
     The consortium supports ongoing development of the Merit  AAA  server.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 26]

     INTERNET-DRAFT                                            10 June 1997

     The  goal  is  to  build  a  server that supports proxy as well as end
     server capabilities, that is feature rich, and that interoperates with
     major vendors' NAS products.

     The  building block of the Merit AAA server, the Authentication/Autho-
     rization Transfer Vector (AATV),  is  a  very  powerful  concept  that
     enables the ultimate modularity and flexibility of the AAA server. The
     structure and methods of the AATV model are published  with  all  ver-
     sions of the AAA server.

     Objects  for  extending the authorization server are also available in
     the enhanced version of the AAA server. Merit is also looking at  ways
     to  provide  a  method  of  extending the AAA server in its executable
     form, to improve the server efficiency and scalability, and to provide
     better monitoring, instrumentation and administration of the server.

     9.  FidoNet implementation

     Since its birth in 1984, FidoNet has supported phone book synchroniza-
     tion among its member nodes, which now  number  approximately  35,000.
     As  a  non-IP  dialup network, FidoNet does not provide IP services to
     members, and does  not  utilize  IP-based  authentication  technology.
     Instead  member  nodes offer bulletin-board services, including access
     to mail and conferences known as echoes.

     In order to be able to communicate with  each  other,  FidoNet  member
     systems  require  a sychronized phone book, known as the Nodelist. The
     purpose of the Nodelist is to enable resolution of  FidoNet  addresses
     (expressed  in the form zone:network/node, or 1:161/445) to phone num-
     bers.  As a dialup network, FidoNet requires phone numbers in order to
     be deliver mail and conference traffic.

     In  order to minimize the effort required in regularly synchronizing a
     phone book of 35,000 entries, the weekly Nodelist updates  are  trans-
     mitted  as  difference  files.  These  difference  files, known as the
     Nodediff, produce the Nodelist for the current week  when  applied  to
     the  previous  week's  Nodelist.   In order to minimize transfer time,
     Nodediffs are compressed prior to transfer.

     Information on FidoNet, as well as FidoNet Technical  Standards  (FTS)
     documents (including the Nodelist specification) and standards propos-
     als are available from the FidoNet archive at

     9.1.  Scaling issues

     With  a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB
     in size, and the weekly Nodediffs are 175 KB. In compressed form,  the
     Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a
     result, the transfer of the Nodediff takes  approximately  45  seconds
     using a 28,800 bps modem.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 27]

     INTERNET-DRAFT                                            10 June 1997

     In  order  to improve scalability, the implementation of a domain name
     service approach is examined in [8]. The proposal evisages  use  of  a
     capability  analagous  to the DNS ISDN record in order to map names to
     phone numbers, coupled  with  an  additional  record  to  provide  the
     attributes associated with a given name.

     9.2.  Phone number presentation

     While FidoNet member systems perform phone book synchronization, users
     need only know the FidoNet address of the systems they  wish  to  con-
     tact. As a result users do not need to maintain copies of the Nodelist
     on their own systems. This is similar to the Internet, where  the  DNS
     takes  care of the domain name to IP address mapping, so that users do
     not have to remember IP addresses.

     Nevertheless, FidoNet systems often find it useful to be able to  pre-
     sent lists of nodes, and as a result, FidoNet Nodelist compilers typi-
     cally produce a representation of the Nodelist that can be searched or
     displayed online, as well as one that is used by the system dialer.

     9.2.1.  FidoNet Nodelist format

     The  FidoNet  Nodelist  format  is  documented  in detail in [3].  The
     Nodelist file consists of lines of data  as  well  as  comment  lines,
     which  begin  with  a semi-colon.  The first line of the Nodelist is a
     general interest comment line that includes the date and the day  num-
     ber,  as  well as a 16-bit CRC. The CRC is included so as to allow the
     system assembling the new Nodelist to verify its integrity.

     Each Nodelist data line contains eight comma separated fields:

          Zone/Region/Net/Node number
          Node name
          Sysop name
          Phone number
          Maximum Baud rate
          Flags (optional)

     FidoNet Nodelists are arranged geographically,  with  systems  in  the
     same  zone,  region,  and network being grouped together. As a result,
     FidoNet Nodelists do not require a separate regions file. Among  other
     things,  the  keyword  field  can be used to indicate that a system is
     temporarily out of service.

     Reference [3] discusses Nodelist flags in considerable  detail.  Among
     other things, the flags include information on supported modem modula-
     tion and error correction protocols.  Reference [4]  also  proposes  a
     series  of  ISDN  capability flags, and [5] proposes flags to indicate
     times of system availability.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 28]

     INTERNET-DRAFT                                            10 June 1997

     9.3.  Phone number exchange

     FidoNet coordinators are responsible for maintaining up to date infor-
     mation on their networks, regions, and zones. Every week network coor-
     dinators submit to their regional  coordinators  updated  versions  of
     their portions of the Nodelist. The regional coordinators then compile
     the submissions from their network coordinators, and  submit  them  to
     the  zone  coordinator. The zone coordinators then exchange their sub-
     missions to produce the new Nodelist. As a result, it is possible that
     the view from different zones may differ at any given time.

     9.3.1.  The Nodediff

     The format of the Nodediff is discussed in detail in [3]. In preparing
     the Nodediffs, network coordinators may transmit only their difference
     updates, which can be collated to produce the Nodediff directly.

     One  weakness  in  the  current  approach is that there is no security
     applied to the coordinator submissions. This leaves oen the  possibil-
     ity  of  propagation  of fraudulent updates. In order to address this,
     [6] proposes addition of a shared secret to the update files.

     9.3.2.  Addition of nodes

     In order to apply for allocation of a FidoNet address  and  membership
     in the Nodelist, systems must demonstrate that they are functioning by
     sending mail to the local network coordinator.  Once the local network
     coordinator receives the application, they then allocate a new FidoNet
     address, and add a Nodelist entry.

     9.3.3.  Deletion of nodes

     Since FidoNet nodes are required to be  functioning  during  the  zone
     mail hour in order to receive mail, and since nodes receive the weekly
     Nodelist from their local network  coordinators  on  a  weekly  basis,
     there is a built-in mechanism for discovery of non-functional nodes.

     Nodes  found  to be down are reported to the local network coordinator
     and subsequently marked as down within the Nodelist.  Nodes  remaining
     down  for more than two weeks may be removed from the Nodelist, at the
     discretion of the network coordinator.

     9.4.  Phone book update

     The Nodelist contains the phone numbers and associated  attributes  of
     each  participating system. New Nodelists become available on Fridays,
     and are made available to participating systems by their local network
     coordinators,  who  in  turn  receive  them from the regional and zone

     Aboba, Lu, Alsop, Ding & Wang                                [Page 29]

     INTERNET-DRAFT                                            10 June 1997

     While it is standard practice for participating systems to  get  their
     Nodelists from their local network coordinators, should the local net-
     work coordinator not be available for some reason, either the  updates
     or  the  complete  Nodelist  may  be  picked up from other network, or
     regional coordinators. Please note that since the view from  different
     zones  may  differ, nodes wishing to update their Nodelists should not
     contact systems from outside their zone.

     9.5.  Phone book compilation

     Once FidoNet systems have received the Nodediff, the apply it  to  the
     previous week's Nodelist in order to prepare a new Nodelist.  In order
     to receive Nodediffs and compile the Nodelist, the following  software
     is required:

          A FidoNet-compatible mailer implementation, used to transfer files
          A Nodelist compiler

     One  of the purposes of the Nodelist compiler is to apply Nodediffs to
     the previous Nodelist in order to produce  an  updated  Nodelist.  The
     other  purpose  is  to  compile  the  updated Nodelist into the format
     required by the particular mailer implementation used  by  the  member
     system.  It  is important to note that while the Nodelist and Nodediff
     formats are standardized (FTS-0005), as is the file transfer  protocol
     (FTS-0001),  the compiled format used by each mailer is implementation

     One reason that compiled formats to differ is the addition of  out  of
     band  information  to  the  Nodelist  during  the compilation process.
     Added information includes phone call costs as well as shared secrets.

     9.5.1.  Cost data

     Although  cost  information  is not part of the Nodelist, in compiling
     the Nodelist into the format used by the  mailer,  Nodelist  compilers
     support  the  addition  of  cost information. This information is then
     subsequently used to guide mailer behavior.

     Since phone call costs depend on the rates charged by the local  phone
     company,  this information is local in nature and is typically entered
     into the Nodelist compiler's configuration file by the system adminis-

     9.5.2.  Shared secrets

     In FidoNet, shared secrets are used for authenticated sessions between
     systems.   Such  authenticated  sessions  are  particularly  important
     between  the local, regional and zone coordinators who handle prepara-
     tion and transmission of the Nodediffs. A single shared secret is used
     per system.

     Aboba, Lu, Alsop, Ding & Wang                                [Page 30]

     INTERNET-DRAFT                                            10 June 1997

     9.6.  Accounting

     Within FidoNet, the need for accounting arises primarily from the need
     of local, regional and zone coordinators to be  reimbursed  for  their
     expenses.  In  order to support this, utilities have been developed to
     account for network usage at the system  level  according  to  various
     metrics.   However,  the  accounting techniques are not applied at the
     user level. Distributed authentication and accounting are  not  imple-
     mented and therefore users may not roam between systems.

     10.  Acknowledgements

     Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest
     for useful discussions of this problem space.

     11.  References

     [1]  S. Cobb.  "PPP Internet Protocol Control Protocol Extensions  for
     Name Server Addresses" RFC 1877, Microsoft, December 1995.

     [2]   T.  Berners-Lee,  R.  Fielding, H. Frystyk.  "Hypertext Transfer
     Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996.

     [3]  B. Baker, R. Moore,  D.  Nugent.   "The  Distribution  Nodelist."
     FTS-0005, February, 1996.

     [4]  A. Lentz.  "ISDN Nodelist flags." FSC-0091, June, 1996.

     [5]   D. J. Thomas.  "A Proposed Nodelist flag indicating Online Times
     of a Node." FSC-0062, April, 1996.

     [6]   L.  Kolin.   "Security  Passwords  in  Nodelist  Update  Files."
     FSC-0055, March, 1991.

     [7]   R.  Gwinn,  D.  Dodell.  "Nodelist Flag Changes Draft Document."
     FSC-0009, November, 1987.

     [8]  R. Heller.  "A Proposal  for  A  FidoNet  Domain  Name  Service."
     FSC-0069, December, 1992.

     [9]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
     cation Dial In User Service (RADIUS)." RFC  2058,  Livingston,  Merit,
     Daydreamer, January, 1997.

     [10]   C. Rigney.  "RADIUS Accounting." RFC 2059, Livingston, January,

     Aboba, Lu, Alsop, Ding & Wang                                [Page 31]

     INTERNET-DRAFT                                            10 June 1997

     12.  Authors' Addresses

     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052

     Phone: 206-936-6605

     Juan Lu
     AimQuest Corporation
     1381 McCarthy Blvd.
     Milpitas, California 95035

     Phone: 408-273-2730  ext. 2762

     John Alsop
     i-Pass Alliance Inc.
     650 Castro St., Suite 280
     Mountain View, CA 94041

     Phone: 415-968-2200
     Fax:   415-968-2266

     James Ding
     One Galleria Tower
     13355 Noel Road, #1340
     Dallas, TX 75240

     Phone: 214-788-4141
     Fax:   214-788-0729

     Wei Wang
     Merit Network, Inc.
     4251 Plymouth Rd., Suite C
     Ann Arbor, MI 48105-2785

     Phone: 313-764-2874

     Aboba, Lu, Alsop, Ding & Wang                                [Page 32]