[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 rfc2194                                           
     ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-roamops-imprev-01.txt>                             Juan Lu
     21 January 1997                                          AimQuest Corp
                                                                 John Alsop
                                                            i-Pass Alliance
                                                                 James Ding
                                                                   Asiainfo
     
     
     
     
                       Review of Roaming Implementations
     
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-roamops-imprev-01.txt>, and  expires August 1, 1997.  Please send
     comments to the authors.
     
     
     2.  Abstract
     
     This document reviews the design and functionality of existing roaming
     implementations.  "Roaming capability" may be loosely defined  as  the
     ability  to use any one of multiple Internet service providers (ISPs),
     while maintaining a formal,  customer-vendor  relationship  with  only
     one.   Examples  of  cases  where roaming capability might be required
     include ISP "confederations" and ISP-provided corporate network access
     support.
     
     
     3.  Introduction
     
     Considerable  interest  has  arisen recently in a set of features that
     fit within the general category of "roaming capability"  for  Internet
     users.  Interested parties have included:
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 1]


     INTERNET-DRAFT                                         21 January 1997
     
     
          Regional  Internet  Service  Providers  (ISPs) operating within a
          particular state or province, looking to  combine  their  efforts
          with  those  of  other regional providers to offer service over a
          wider area.
     
          National ISPs wishing to combine their operations with  those  of
          one  or  more  ISPs in another nation to offer more comprehensive
          service in a group of countries or on a continent.
     
          Businesses desiring to  offer  their  employees  a  comprehensive
          package of access services on a global basis.  Those services may
          include Internet access as well as  secure  access  to  corporate
          intranets via a Virtual Private Network (VPN), enabled by tunnel-
          ing protocols such as PPTP or L2F.
     
     What is required to provide roaming capability?  The following list is
     a  first cut at defining the requirements for successful roaming among
     an arbitrary set of ISPs:
     
          Phone number presentation
          Phone number exchange
          Phone book compilation
          Phone book update
          Connection management
          Authentication
          NAS Configuration/Authorization
          Address assignment and routing
          Security
          Accounting
     
     In this document we review existing roaming implementations,  describ-
     ing  their  functionality  within this framework.  In addition to full
     fledged roaming implementations, we will also  review  implementations
     that, while not meeting the strict definition of roaming, address sev-
     eral of these problem elements. These implementations  typically  fall
     into the category of shared use networks or non-IP dialup networks.
     
     3.1.  Terminology
     
     This document frequently uses the following terms:
     
     
     home ISP  This  is  the  Internet  service provider with whom the user
               maintains an account relationship.
     
     
     local ISP This is the Internet service provider whom the user calls in
               order  to get access. Where roaming is implemented the local
               ISP may be different from the home ISP.
     
     
     phone book
               This is a database or document containing data pertaining to
               dialup  access,  including  phone numbers and any associated
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 2]


     INTERNET-DRAFT                                         21 January 1997
     
     
               attributes.
     
     
     shared use network
               This is an IP dialup network whose use is shared by  two  or
               more organizations.  Shared use networks typically implement
               distributed authentication and accounting in order to facil-
               itate  the  relationship  among  the  sharing parties. Since
               these facilities are also  required  for  implementation  of
               roaming,  implementation of shared use is frequently a first
               step toward development of roaming  capabilities.  In  fact,
               one  of  the ways by which a provider may offer roaming ser-
               vice is to conclude shared use agreements with multiple net-
               works.  However,  to date the ability to accomplish this has
               been hampered by lack of interoperability among  shared  use
               implementations.
     
     
     non-IP dialup network
               This is a dialup network providing user access to the member
               systems via protocols other than  IP.   These  networks  may
               implement phone book synchronization facilities, in order to
               provide systems, administrators and  users  with  a  current
               list  of  participating  systems.  Examples of non-IP dialup
               networks  supporting  phone  book  synchronization   include
               FidoNet and WWIVnet.
     
     
     4.  Global Reach Internet Consortium (GRIC)
     
     Led by a US-based Internet technology developer, 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-
     nect.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  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
     facilitate  the  billing  process. Information on the AimQuest roaming
     implementation is available from http://www.aimquest.com/.
     
     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
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 3]


     INTERNET-DRAFT                                         21 January 1997
     
     
     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 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-based 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,
     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
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 4]


     INTERNET-DRAFT                                         21 January 1997
     
     
          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:
     
     ftp://ftp.Aimnet.com/pub/traveler/isppb.ini
     ftp://ftp.Aimnet.com/pub/traveler/isppb.exe
     
     A copy of the phone book is also available from the  GRIC  phone  book
     page, available at http://www.gric.com/.
     
     
     4.2.  Phone number exchange
     
     GRIC  members  submit information both about themselves and their POPs
     to the GRIC secretariat, which is run by  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).
     
     
     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.
     
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 5]


     INTERNET-DRAFT                                         21 January 1997
     
     
     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. "liu@Aimnet.com") 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
     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.
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 6]


     INTERNET-DRAFT                                         21 January 1997
     
     
     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
     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 Aim-
     Traveler  Server, a centralized  routing server,  contains the  autho-
     rized  ISP's  domain name, authentication servers and  other  informa-
     tion.
     
     The  AimTraveler  currently supports  RADIUS  and  TACACS+,  and could
     be extended  to  support  other  authentication  protocols.   It  also
     receives all the accounting records, which are  subsequently  used  as
     input data for billing.
     
     Since  ISPs' NAS devices may be configured differently, the attributes
     returned by the home ISP AAS are discarded.
     
     
     4.8.  Address assignment and routing
     
     All addresses in GRIC are assigned dynamically from within the address
     pool of the local ISP.  Static addresses and  routed  LAN  connections
     will  be  considered in the future, when GRIC offers corporate roaming
     service.
     
     
     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.
     
     
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 7]


     INTERNET-DRAFT                                         21 January 1997
     
     
     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-
     ing:
     
     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
     
     
     5.1.  Overview
     
     i-Pass Alliance Inc., based in Palo Alto, California has developed and
     operates  a  service  for  global  roaming  between  Internet  service
     providers.  The service is currently in field trials.
     
     i-Pass Alliance Inc. has additional offices in Toronto, Hong Kong, and
     London.    More   information   on   i-Pass   can   be  obtained  from
     http://www.ipass.com.
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 8]


     INTERNET-DRAFT                                         21 January 1997
     
     
     The i-Pass network consists of a number of servers that provide  real-
     time  authentication services to member ISPs.  Authentication requests
     and accounting records for roaming users are encrypted and sent to  an
     i-Pass  server where they are logged, and then forwarded to a home ISP
     for authentication and/or logging.
     
     Periodically, i-Pass  reconciles  all  accounting  records,  generates
     billing  statements,  and  acts  as  a single point for collecting and
     remitting payments.
     
     i-Pass provides its service only to ISPs.   It  does  not  attempt  to
     establish  a  business  relationship with individual-user customers of
     those ISPs.
     
     5.2.  Access Point Database (APD)
     
     i-Pass maintains  a  list  of  roaming  access  points  in  an  Oracle
     database.   This list is searchable by geographical region using a web
     browser, and may be downloaded in its entirety using FTP. The informa-
     tion stored for each access point includes:
     
          Name of service provider
          Country
          State or Province
          City or Region
          Telephone number
          Technical support phone number
          Service types available
          Technical information (help file)
          Service pricing information
     
     i-Pass  member  ISPs  may  update their information in the APD using a
     secure web interface.
     
     
     5.3.  Phone number presentation
     
     i-Pass provides information and tools to  Internet  Service  Providers
     and dialer application developers to assist them in integrating the i-
     Pass access point database into their software.
     
     i-Pass does not intend to be a primary developer  of  dialer  applica-
     tions,  as  it believes this requirement is best met by the above par-
     ties.
     
     
     5.4.  Authentication
     
     There are three  entities  involved  in  servicing  an  authentication
     request:
     
     
     Local ISP At  the  local ISP, the authentication server is modified to
               recognize user IDs of the form username@auth_domain as being
     
     
     
     Aboba, Lu, Alsop, & Ding                                      [Page 9]


     INTERNET-DRAFT                                         21 January 1997
     
     
               remote  authentication  requests.   These  requests are for-
               warded to an i-Pass server.
     
     
     i-Pass Server
               The i-Pass server receives the authentication request,  logs
               it,  and  forwards  it  to  the  home  ISP identified by the
               auth_domain portion of the user ID.
     
     
     Home ISP  The home ISP receives the authentication  request,  performs
               authentication  using  its normal authentication method, and
               returns a YES/NO response to the  i-Pass  server,  which  in
               turn forwards the reply to the originating ISP.
     
     i-Pass  provides  software  components which run on the authentication
     servers of the local and home ISPs.  Each member  ISP  must  integrate
     these  components  with the native authentication method being used by
     the ISP.  To simplify this task, i-Pass has developed "drop-in" inter-
     faces  for the most commonly used authentication methods.  At the date
     of writing, the following interfaces are supported:
     
          RADIUS (standard Livingston distribution)
          Merit RADIUS
          TACACS+
          Xylogics erpcd (Versions 10 and 11)
     
     A generic interface is also provided which authenticates based on  the
     standard UNIX password file.  This is intended as a starting point for
     ISPs using authentication methods other than those listed above.
     
     The software integration effort for a typical ISP is on the  order  of
     2-5 man-days including testing.  Platforms currently supported include
     Solaris 2.[45], BSDI, and Digital Unix.
     
     
     5.5.  Accounting
     
     Accounting transactions are handled in the same way as  authentication
     requests.  In addition to being logged at the i-Pass servers, account-
     ing transactions are sent in real-time  to  the  home  ISP.   This  is
     intended  to allow ISPs to update users' credit limit information on a
     real-time basis (to the extent that this capability  is  supported  by
     their billing and accounting systems).
     
     Settlement  is  performed  periodically (initially once a month).  The
     settlement process involves calculating the costs associated with each
     individual  session,  and aggregating them for each ISP.  A net amount
     is then calculated which is either due from i-Pass to the ISP, or from
     the ISP to i-Pass, depending on the actual usage pattern.
     
     The following reports are supplied to member ISPs:
     
          A Monthly Statement showing summaries of usage,
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 10]


     INTERNET-DRAFT                                         21 January 1997
     
     
          service provided, and any adjustments along with the
          net amount owing.
     
          A Call Detail Report showing roaming usage by the ISP's
          customers.
     
          A Service Provided report showing detailed usage of
          the ISP's facilities by remote users.
     
     The  above  reports  are  generated  as  ASCII documents to facilitate
     delivery by electronic means (e.g. e-mail) as well as hard-copy.
     
     The Call Detail Report is also generated as  a  comma-delimited  ASCII
     file  suitable  for import into the ISP's billing database.  (The Call
     Detail Report will normally be used by the ISP  to  generate  end-user
     billing for roaming usage).
     
     
     5.6.  Security
     
     All  transactions  between  ISPs  and the i-Pass servers are encrypted
     using the SSL protocol.  Public key certificates are verified at  both
     the  client and server.  (i-Pass issues these certificates and acts as
     the Certification Authority).
     
     Transactions are also verified based on a  number  of  other  criteria
     such as source IP address.
     
     
     6.  ChinaNet implementation
     
     ChinaNet,  owned  by  China Telecom, is China's largest Internet back-
     bone. Constructed by Asiainfo, a Dallas based system integration  com-
     pany,  it  has  31  backbone  nodes  in  31 Chinese provincial capital
     cities. Each province is building its own provincial network, has  its
     own dialup servers, and administers its own user base.
     
     In  order  to  allow ChinaNet users to be able to access nodes outside
     their province while traveling, a nationwide roaming system  has  been
     implemented.   The  roaming  system  was developed by AsiaInfo, and is
     based on the RADIUS protocol.
     
     6.1.  Phone number presentation
     
     Since China Telecom uses one phone number (163) for nationwide  Inter-
     net  access,  most cities have the same Internet access number. There-
     fore a phone book is not currently required for the ChinaNet implemen-
     tation.  A  web-based  phone  book will  be added in a future software
     release in order to support nationwide ISP/CSP telephone  numbers  and
     HTTP server addresses.
     
     
     
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 11]


     INTERNET-DRAFT                                         21 January 1997
     
     
     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
     default).
     
     Caching is used to avoid frequent proxying of requests  and  responses
     between  the  local  RADIUS proxy and the home RADIUS server. When the
     home RADIUS server sends back a  valid  authentication  response,  the
     local RADIUS proxy/server will cache the user information for a period
     of time (3  days  by  default).   When  the  user  next  authenticates
     directly  against  the home RADIUS server, the home RADIUS server will
     send a request to the local server or  servers  to  clear  the  user's
     information from the cache.
     
     6.4.1.  Extended hierarchy
     
     In   some   provinces,  the  local  telecommunications  administration
     (Provincial ISP) further delegates control  to  county  access  nodes,
     creating another level of hierarchy. This is done to improve scalabil-
     ity and to avoid having the provincial ISP databases grow  too  large.
     In  the  current implementation, each provincial ISP maintains its own
     central RADIUS server, including  information  on  all  users  in  the
     province,  while county nodes maintain distributed RADIUS servers. For
     intra-province roaming requests the  local  RADIUS  proxy/server  will
     directly forward the request to the home RADIUS server.
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 12]


     INTERNET-DRAFT                                         21 January 1997
     
     
     However,  for inter-province roaming requests, the local RADIUS server
     does not forward the request  directly  to  the  home  RADIUS  server.
     Instead,  the  request  is  forwarded to the central provincial RADIUS
     server for the home province. This  implementation  is  suitable  only
     when  county  level  ISPs do not mind combining and sharing their user
     information. In this instance, this is acceptable,  since  all  county
     level ISPs are part of China Telecom. In a future release, this multi-
     layer hierarchy will be implemented using multi-layer proxy RADIUS, in
     a manner more resembling DNS.
     
     
     6.5.  Security
     
     Encryption  is used between the local RADIUS proxy/server and the home
     RADIUS server. Public/Private key encryption will be supported in  the
     next  release. IP tunneling and token card support is under considera-
     tion.
     
     
     6.6.  Accounting
     
     Accounting  information  is  transferred  between  the  local   RADIUS
     accounting  proxy/server and home RADIUS accounting server.  Every day
     each node sends a summary accounting information record to  a  central
     server  in  order to support nationwide settlement. The central server
     is run by the central Data  Communication  Bureau  of  China  Telecom.
     Every  month  the  central  server  sends  the  settlement bill to the
     provincial ISPs.
     
     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
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 13]


     INTERNET-DRAFT                                         21 January 1997
     
     
     cooperation with access partners.  Since users are  able  to  use  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-
     tion.
     
     
     7.2.  Phone number presentation
     
     The  Connection Manager is responsible for the presentation and updat-
     ing of phone numbers, as well as for dialing and  making  connections.
     In  order  to  select  phone  numbers,  users  are asked to select the
     desired country and region/state.  Phone numbers are then presented in
     the  area selected.  The primary numbers are those from the users ser-
     vice provider which match the service type  (Analog,  ISDN,  Analog  &
     ISDN),  country and region/state selected. The other numbers (selected
     clicking on the More button) are those  for  other  service  providers
     that have a roaming agreement with the users service provider.
     
     
     
     7.2.1.  Cost data
     
     Cost data is not presented to users along with the phone numbers. How-
     ever, such information may be made available by other means,  such  as
     via a Web page.
     
     
     7.2.2.  Default phone book format
     
     The  Connection  Manager  supports  the ability to customize the phone
     book format, and it is expected that many ISPs will make use  of  this
     capability.  However,  for  those who wish to use it "off the shelf" a
     default phone book format is provided. The default phone book is  com-
     prised of several files, including:
     
          Service profile
          Phone Book
          Region file
     
     The service profile provides information on a given service, which may
     be an isolated Internet Service Provider, or may represent  a  roaming
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 14]


     INTERNET-DRAFT                                         21 January 1997
     
     
     consortium. The service profile, which is in .ini file format, is com-
     prised of the following information:
     
          The name of the service
          The filename of the service's big icon
          The filename of the service's little icon
          A description of the service
          The service phone book filename
          The service phone book version number
          The service regions file
          The URL of the service phone book server
          The prefix used by the service (i.e. "MSN/aboba")
          The suffix or domain used by the service (i.e. "aboba@msn.com")
          Whether the user name is optional for the service
          Whether the password is optional for the service
          Maximum length of the user name for the service
          Maximum length of the password for the service
          Information on service password handling (lowercase, mixed case, etc.)
          Number of redials for this service
          Delay between redials for this service
          References to other service providers that have roaming agreements
          The service profile filenames for each of the references
          Mask and match phone book filters for each of the references
                 (these are 32 bit numbers that are applied against the capability flags in the phone book)
          The dial-up connection properties configuration
               (this is the DUN connectoid name)
     
     
     The phone book file is a comma delimited  ASCII  file  containing  the
     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, Lu, Alsop, & Ding                                     [Page 15]


     INTERNET-DRAFT                                         21 January 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  introduc-
     tion  of  new  technologies.   As  a  result,  the set of phone number
     attributes is likely to evolve over time,  and  extensibility  in  the
     phone book format is highly desirable.
     
     For  example,  in  addition  to the attributes provided in the default
     phone book, the following additional attributes have been requested by
     customers:
     
          Multicast support flag
          External/internal flag (to differentiate display between the
               "internal" or "other" list box)
          Priority  (for control of presentation order)
          Modem protocol capabilities (V.34, V.32bis, etc.)
          ISDN protocol capabilities (V.110, V.120, etc.)
          No password flag (for numbers using telephone-based billing)
          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                                     [Page 16]


     INTERNET-DRAFT                                         21 January 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                                     [Page 17]


     INTERNET-DRAFT                                         21 January 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:
     
          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 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. "aboba@msn.com"),  as  well  as  a  prefix
     notation ("MSN/aboba").
     
     The  prefix notation was developed for use with NAS devices with small
     maximum userID lengths.  For these devices the compactness of the pre-
     fix  notation  significantly increases the number of characters avail-
     able for the userID field.  However, as an increasing  number  of  NAS
     devices are now supporting 253 octet userIDs (the maximum supported by
     RADIUS) the need for prefix notation is declining.
     
     After receiving the userID from the Connection Manager client, the NAS
     device  passes  the  userID/domain and password information (or in the
     case of CHAP, the challenge and the response) to the RADIUS proxy. The
     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                                     [Page 18]


     INTERNET-DRAFT                                         21 January 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:
     
          Framed IP Address
          Framed IP Netmask
          Framed Routing
          Framed Route
          Filter ID
          Vendor Specific
          Session Timeout
          Idle Timeout
          Termination Action
     
     Conflicts relating to IP address assignment and routing are very  com-
     mon.   Where  dynamic  address  assignment is used, an IP address pool
     appropriate for the local NAS can be substituted for  the  IP  address
     pool designated by the home RADIUS server.
     
     However,  not  all  address  conflicts can be resolved by editing.  In
     some cases, (i.e., assignment of a static network address for  a  LAN)
     it  may  not  be  possible for the local NAS to accept the home RADIUS
     server's address assignment, yet the roaming hosts may not be able  to
     accept an alternative assignment.
     
     Filter  IDs also pose a problem. It is possible that the local NAS may
     not implement a filter corresponding to that designated  by  the  home
     RADIUS  server.  Even if an equivalent filter is implemented, in order
     to guarantee correct operation, the proxy's configuration  must  track
     changes  in  the  filter  configurations of each of the members of the
     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                                     [Page 19]


     INTERNET-DRAFT                                         21 January 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
     server.
     
     Conflicts  over  session or idle timeouts may result if since both the
     local and home ISP feel the need to adjust  these  parameters.   While
     the  home  ISP  may  wish  to adjust the parameter to match the user's
     software, the local ISP may wish to adjust it to match its own service
     policy. As long as the desired parameters do not differ too greatly, a
     compromise is often possible.
     
     
     7.9.  Address assignment and routing
     
     While the Connection Manager software supports both static and dynamic
     address  assignment,  in  the  MSN  implementation,  all addresses are
     dynamically assigned.
     
     However, selected partners also offer LAN connectivity to  their  cus-
     tomers, usually via static address assignment. However, these accounts
     do not have roaming privileges since no  mechanism  has  been  put  in
     place  for  allowing  these  static  routes to move between providers.
     Users looking to do LAN roaming between providers  are  encouraged  to
     select a router supporting Network Address Translation (NAT). NAT ver-
     sions implemented in several low-end routers are compatible  with  the
     dynamic  addressing used on MSN, as well as supporting DHCP on the LAN
     side.
     
     
     7.10.  Security
     
     The RADIUS proxy/server implementation does not support token cards or
     tunneling protocols.
     
     
     7.11.  Accounting
     
     In  the  MSN roaming implementation, the accounting data exchange pro-
     cess is specified in terms of  an  accounting  record  format,  and  a
     method  by which the records are transferred from the partners to MSN,
     which acts as the settlement agent.  Defining the interaction in terms
     of  record formats and transfer protocols implies that the partners do
     not communicate with the settlement agent using NAS accounting  proto-
     cols.   As  a  result,  accounting protocol interoperability is not be
     required.
     
     However, for this advantage to be fully realized, it is necessary  for
     the  accounting  record  format  to  be extensible. This makes it more
     likely that the format can be adapted for use with the wide variety of
     accounting protocols in current use (such as SNMP, syslog, RADIUS, and
     TACACS+), as well as future protocols. After all, if the record format
     cannot express the metrics provided by a particular partner's account-
     ing protocol, then the record format will not be of  much  use  for  a
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 20]


     INTERNET-DRAFT                                         21 January 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.  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
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 21]


     INTERNET-DRAFT                                         21 January 1997
     
     
     to mail and conferences known as echoes.
     
     In order to be able to communicate with  each  other,  FidoNet  member
     systems  require  a sychronized phone book, known as the Nodelist. The
     purpose of the Nodelist is to enable resolution of  FidoNet  addresses
     (expressed  in the form zone:network/node, or 1:161/445) to phone num-
     bers.  As a dialup network, FidoNet requires phone numbers in order to
     be deliver mail and conference traffic.
     
     In  order to minimize the effort required in regularly synchronizing a
     phone book of 35,000 entries, the weekly Nodelist updates  are  trans-
     mitted  as  difference  files.  These  difference  files, known as the
     Nodediff, produce the Nodelist for the current week  when  applied  to
     the  previous  week's  Nodelist.   In order to minimize transfer time,
     Nodediffs are compressed prior to transfer.
     
     Information on FidoNet, as well as FidoNet Technical  Standards  (FTS)
     documents (including the Nodelist specification) and standards propos-
     als are available from the FidoNet archive at http://www.fidonet.org/.
     
     
     8.1.  Scaling issues
     
     With  a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB
     in size, and the weekly Nodediffs are 175 KB. In compressed form,  the
     Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a
     result, the transfer of the Nodediff takes  approximately  45  seconds
     using a 28,800 bps modem.
     
     In  order  to improve scalability, the implementation of a domain name
     service approach is examined in [8]. The proposal evisages  use  of  a
     capability  analagous  to the DNS ISDN record in order to map names to
     phone numbers, coupled  with  an  additional  record  to  provide  the
     attributes associated with a given name.
     
     
     8.2.  Phone number presentation
     
     While FidoNet member systems perform phone book synchronization, users
     need only know the FidoNet address of the systems they  wish  to  con-
     tact. As a result users do not need to maintain copies of the Nodelist
     on their own systems. This is similar to the Internet, where  the  DNS
     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.
     
     
     
     
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 22]


     INTERNET-DRAFT                                         21 January 1997
     
     
     8.2.1.  FidoNet Nodelist format
     
     The  FidoNet  Nodelist  format  is  documented  in detail in [3].  The
     Nodelist file consists of lines of data  as  well  as  comment  lines,
     which  begin  with  a semi-colon.  The first line of the Nodelist is a
     general interest comment line that includes the date and the day  num-
     ber,  as  well as a 16-bit CRC. The CRC is included so as to allow the
     system assembling the new Nodelist to verify its integrity.
     
     Each Nodelist data line contains eight comma separated fields:
     
          Keyword
          Zone/Region/Net/Node number
          Node name
          Location
          Sysop name
          Phone number
          Maximum Baud rate
          Flags (optional)
     
     FidoNet Nodelists are arranged geographically,  with  systems  in  the
     same  zone,  region,  and network being grouped together. As a result,
     FidoNet Nodelists do not require a separate regions file. Among  other
     things,  the  keyword  field  can be used to indicate that a system is
     temporarily out of service.
     
     Reference [3] discusses Nodelist flags in considerable  detail.  Among
     other things, the flags include information on supported modem modula-
     tion and error correction protocols.  Reference [4]  also  proposes  a
     series  of  ISDN  capability flags, and [5] proposes flags to indicate
     times of system availability.
     
     
     8.3.  Phone number exchange
     
     FidoNet coordinators are responsible for maintaining up to date infor-
     mation on their networks, regions, and zones. Every week network coor-
     dinators submit to their regional  coordinators  updated  versions  of
     their portions of the Nodelist. The regional coordinators then compile
     the submissions from their network coordinators, and  submit  them  to
     the  zone  coordinator. The zone coordinators then exchange their sub-
     missions to produce the new Nodelist. As a result, it is possible that
     the view from different zones may differ at any given time.
     
     
     8.3.1.  The Nodediff
     
     The format of the Nodediff is discussed in detail in [3]. In preparing
     the Nodediffs, network coordinators may transmit only their difference
     updates, which can be collated to produce the Nodediff directly.
     
     One  weakness  in  the  current  approach is that there is no security
     applied to the coordinator submissions. This leaves open the possibil-
     ity  of  propagation  of fraudulent updates. In order to address this,
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 23]


     INTERNET-DRAFT                                         21 January 1997
     
     
     [6] proposes addition of a shared secret to the update files.
     
     
     
     8.3.2.  Addition of nodes
     
     In order to apply for allocation of a FidoNet address  and  membership
     in the Nodelist, systems must demonstrate that they are functioning by
     sending mail to the local network coordinator.  Once the local network
     coordinator receives the application, they then allocate a new FidoNet
     address, and add a Nodelist entry.
     
     8.3.3.  Deletion of nodes
     
     Since FidoNet nodes are required to be  functioning  during  the  zone
     mail hour in order to receive mail, and since nodes receive the weekly
     Nodelist from their local network  coordinators  on  a  weekly  basis,
     there is a built-in mechanism for discovery of non-functional nodes.
     
     Nodes  found  to be down are reported to the local network coordinator
     and subsequently marked as down within the Nodelist.  Nodes  remaining
     down  for more than two weeks may be removed from the Nodelist, at the
     discretion of the network coordinator.
     
     8.4.  Phone book update
     
     The Nodelist contains the phone numbers and associated  attributes  of
     each  participating system. New Nodelists become available on Fridays,
     and are made available to participating systems by their local network
     coordinators,  who  in  turn  receive  them from the regional and zone
     coordinators.
     
     While it is standard practice for participating systems to  get  their
     Nodelists from their local network coordinators, should the local net-
     work coordinator not be available for some reason, either the  updates
     or  the  complete  Nodelist  may  be  picked up from other network, or
     regional coordinators. Please note that since the view from  different
     zones  may  differ, nodes wishing to update their Nodelists should not
     contact systems from outside their zone.
     
     
     8.5.  Phone book compilation
     
     Once FidoNet systems have received the Nodediff, the apply it  to  the
     previous week's Nodelist in order to prepare a new Nodelist.  In order
     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
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 24]


     INTERNET-DRAFT                                         21 January 1997
     
     
     required by the particular mailer implementation used  by  the  member
     system.  It  is important to note that while the Nodelist and Nodediff
     formats are standardized (FTS-0005), as is the file transfer  protocol
     (FTS-0001),  the compiled format used by each mailer is implementation
     dependent.
     
     One reason that compiled formats to differ is the addition of  out  of
     band  information  to  the  Nodelist  during  the compilation process.
     Added information includes phone call costs as well as shared secrets.
     
     8.5.1.  Cost data
     
     Although  cost  information  is not part of the Nodelist, in compiling
     the Nodelist into the format used by the  mailer,  Nodelist  compilers
     support  the  addition  of  cost information. This information is then
     subsequently used to guide mailer behavior.
     
     Since phone call costs depend on the rates charged by the local  phone
     company,  this information is local in nature and is typically entered
     into the Nodelist compiler's configuration file by the system adminis-
     trator.
     
     
     8.5.2.  Shared secrets
     
     In FidoNet, shared secrets are used for authenticated sessions between
     systems.   Such  authenticated  sessions  are  particularly  important
     between  the local, regional and zone coordinators who handle prepara-
     tion and transmission of the Nodediffs. A single shared secret is used
     per system.
     
     
     8.6.  Accounting
     
     Within FidoNet, the need for accounting arises primarily from the need
     of local, regional and zone coordinators to be  reimbursed  for  their
     expenses.  In  order to support this, utilities have been developed to
     account for network usage at the system  level  according  to  various
     metrics.   However,  the  accounting techniques are not applied at the
     user level. Distributed authentication and accounting are  not  imple-
     mented and therefore users may not roam between systems.
     
     
     9.  Acknowledgements
     
     Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest
     for useful discussions of this problem space.
     
     
     10.  References
     
     [1]  S. Cobb.  "PPP Internet Protocol Control Protocol Extensions  for
     Name Server Addresses" RFC 1877, Microsoft, December 1995.
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 25]


     INTERNET-DRAFT                                         21 January 1997
     
     
     [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,
     1997.
     
     
     
     
     11.  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.
     555 Bryant Street, #248
     Palo Alto, CA 94301
     
     Phone: 415-327-5553
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 26]


     INTERNET-DRAFT                                         21 January 1997
     
     
     EMail: jalsop@ipass.com
     
     James Ding
     Asiainfo
     One Galleria Tower
     13355 Noel Road, #1340
     Dallas, TX 75240
     
     Phone: 214-788-4141
     Fax:   214-788-0729
     EMail: ding@bjai.asiainfo.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba, Lu, Alsop, & Ding                                     [Page 27]