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

Versions: 00 01 02 03 rfc2194                                           
     ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-roamops-imprev-00.txt>                            Lynn Liu
     26 November 1996                                                Aimnet
                                                                 John Alsop
                                                            i-Pass Alliance
                                                                 James Ding
                       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-00.txt>, and  expires June 1, 1997.   Please  send
     comments to the authors.
     2.  Abstract
     This document reviews the design and functionality of existing roaming
     implementations.  "Roaming capability" may be loosely defined  as  the
     ability  to use any one of multiple Internet service providers (ISPs),
     while maintaining a formal,  customer-vendor  relationship  with  only
     one.   Examples  of  cases  where roaming capability might be required
     include ISP "confederations" and ISP-provided corporate network access
     3.  Introduction
     Considerable  interest  has  arisen recently in a set of features that
     fit within the general category of "roaming capability"  for  Internet
     users.  Interested parties have included:
     Aboba, Liu, Alsop, & Ding                                     [Page 1]

     INTERNET-DRAFT                                        26 November 1996
          Regional  Internet  Service  Providers  (ISPs) operating within a
          particular state or province, looking to  combine  their  efforts
          with  those  of  other regional providers to offer service over a
          wider area.
          National ISPs wishing to combine their operations with  those  of
          one  or  more  ISPs in another nation to offer more comprehensive
          service in a group of countries or on a continent.
          Businesses desiring to  offer  their  employees  a  comprehensive
          package of access services on a global basis.  Those services may
          include Internet access as well as  secure  access  to  corporate
          intranets via a Virtual Private Network (VPN), enabled by tunnel-
          ing protocols such as PPTP or L2F.
     What is required to provide roaming capability?  The following list is
     a  first cut at defining the requirements for successful roaming among
     an arbitrary set of ISPs:
          Phone number presentation
          Phone number exchange
          Phone book compilation
          Phone book update
          Connection management
          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
               ISP may be different from the home ISP.
     phone book
               This is a database or document containing data pertaining to
               dialup  access,  including  phone numbers and any associated
     Aboba, Liu, Alsop, & Ding                                     [Page 2]

     INTERNET-DRAFT                                        26 November 1996
     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, Aimnet Corporation,
     ten Internet Service Providers (ISPs) from the USA, Australia,  China,
     Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the
     Global Reach Internet Consortium (GRIC) in May,  1996.  The  goals  of
     GRIC were to to facilitate the implementation of a global roaming ser-
     vice and to coordinate billing and settlement among the membership. In
     the  future  it  is  likely  that additional ISPs from Canada, Central
     America and Europe will join the GRIC consortium. Information on  GRIC
     is available from http://www.gric.com/.
     In  implementing their roaming service, GRIC members have chosen soft-
     ware developed by Aimnet. Aimnet Corporation's roaming  implementation
     is  comprised  of  the  following  major components: the Aimnet Ranger
     client, the AimTraveler RADIUS/TACACS+ proxy, and the Aimnet  Internet
     Management System (AIMS) billing and settlement module. Information on
     the    Aimnet    roaming    implementation    is    available     from
     The  Aimnet Ranger client provides users with an automatically updated
     phone book, as well as handling authentication and logon. It is avail-
     able for the Windows platform.
     The  AimTraveler  proxy  handles incoming authentication requests from
     NAS  devices  and  routes  them  to  the  appropriate   home   server.
     Aboba, Liu, Alsop, & Ding                                     [Page 3]

     INTERNET-DRAFT                                        26 November 1996
     AimTraveler is available for various UNIX platforms, and supports both
     the Unix password file or Kerberos. A version for Windows NT is  under
     AIMS is designed for large ISPs who need a centralized management sys-
     tem for all ISP operations, including sales,  trouble-ticketing,  ser-
     vice,  and  billing.   AIMS  produces  usage and transaction statement
     reports,  and  includes  a  settlement  module  to   produce   settle-
     ment/billing  reports  for  the  roaming  consortium members. Based on
     these reports, the providers charge their ISP/roaming  customers,  and
     pay/settle  the  roaming  balance  among the providers. AIMS currently
     runs on Sun/Solaris/Oracle. A version for Windows NT and SQL Server is
     expected to become available in Q4 1996.
     4.1.  Phone number presentation
     Currently there are two principal methods by which GRIC users can dis-
     cover available phone numbers: a Web-based directory provided  by  the
     GRIC secretariat, and an automatically updated phone book supported by
     the Aimnet Ranger software.
     4.1.1.  Web based directory
     A directory of GRIC phone numbers is available on the GRIC home  page,
     http://www.gric.com/.   The list of numbers is arranged by country and
     provider. For each provider within a country, this directory, provided
     in the form of a table, offers the following information:
          Provider address, voice phone and fax
          Customer support phone number
          Provider domain name
          Primary Domain Name Server
          Secondary Domain Name Server
          Dial-up IP Address
          News server
          Web page
          POP phone numbers (i.e. 1-408-366-9000)
          POP locations (i.e. Berkeley)
     In  order  to discover phone numbers using the Web-based directory, it
     is expected that users will be online, and will navigate to the appro-
     priate  country  and provider. They then look up the number and insert
     it into the Aimnet Ranger dialer.
     4.1.2.  Aimnet Ranger phone book
     The Aimnet Ranger software provides for  phone  book  presentation  as
     well  as automated updating of phone numbers.  The Aimnet Ranger phone
     book includes a country list, provider list, and  POP  (phone  number)
     list,  as well as detailed provider information, including the cutomer
     support phone number, and Internet  server  configuration  info.   The
     Phone  book,  developed with Microsoft VC++, is available for download
     Aboba, Liu, Alsop, & Ding                                     [Page 4]

     INTERNET-DRAFT                                        26 November 1996
     from the Aimnet ftp site:
     A  copy  of  the phone book is also available from the GRIC phone book
     page, available at http://www.gric.com/.
     4.2.  Phone number exchange
     GRIC members submit information both about themselves and  their  POPs
     to  the GRIC secretariat, which is run by Aimnet. The GRIC secretariat
     then compiles a new phone book and provides updates on  the  GRIC  FTP
     and Web servers.
     GRIC users then download the phone numbers either in Windows .ini file
     format (viewable via the Aimnet Ranger phone book), or in HTML  (view-
     able via a Web browser).
     4.3.  Phone book compilation
     GRIC  phone books are compiled manually, and represent a concatenation
     of available numbers from all the members of the  roaming  consortium,
     with  no policy application.  As new POPs come online, the numbers are
     forwarded to GRIC, which adds them to the phone book servers.
     4.4.  Phone book update
     Phone numbers in the Aimnet Ranger phone book  are  updated  automati-
     cally.  The AimTraveler server includes an address book which contains
     the phone numbers of all the roaming consortium members.
     4.5.  Connection management
     The AimTraveler and Aimnet Ranger software supports PPP and  SLIP,  as
     well as PAP and CHAP authentication.
     4.6.  Authentication
     GRIC  implements  distributed  authentication, utilizing the user's e-
     mail address as the userID (i.e. "liu@aimnet.com")  presented  to  the
     remote NAS device. The Aimnet Ranger software takes care of presenting
     the e-mail address as the userID for PAP or CHAP authentication.
     After the initial PPP authentication exchange, the userID, domain, and
     pasword  information  (or  in  the case of CHAP, the challenge and the
     response) are then passed to  the  AimTraveler  authentication  proxy,
     which supports both TACACS+ and RADIUS.
     Aboba, Liu, Alsop, & Ding                                     [Page 5]

     INTERNET-DRAFT                                        26 November 1996
     The  AimTraveler software then determines if the domain name is regis-
     tered as capable of roaming.  The registration check is based on local
     configuration  data, and if it succeeds, the AimTraveler software then
     translates the authentication request to the protocol type used by the
     home  authenticating domain, and forwards the encrypted access request
     to the home ISP.  If the home ISP authorizes access,  verification  is
     sent  to  the local ISP.  AimTraveler works as an authentication gate-
     way, routing userID and password (encrypted) to the remote authentica-
     tion  server  via  RADIUS,  TACACS+, or other authentication protocol.
     Since AimTraveler supports both TACACS+ and RADIUS, GRIC  members  may
     use either protocol.
     4.7.  NAS Configuration/Authorization
     AimTraveler is comprised of two components, a Client and a Server.
     The  AimTraveler Client acts as the PPP dial-up authentication server.
     When it detects an '@' sign in  the  userID  field,  it  forwards  the
     encrypted userID and password to the AimTraveler server.  The AimTrav-
     eler Server Gateway, a centralized  authentication  gateway,  contains
     the  authorized  ISPs'  domain names, authentication servers and other
     information.  The AimTraveler Server routes the encrypted  userID  and
     password  to  the   remote  authorized ISP's authentication server for
     The AimTraveler Gateway currently supports  RADIUS  and  TACACS+,  and
     could  be extended to support other authentication protocols.  It also
     receives all the accounting records, which are  subsequently  used  as
     input data for billing.
     4.8.  Address assignment and routing
     All addresses in GRIC are assigned dynamically from within the address
     pool of the local ISP.  Static addresses and  routed  LAN  connections
     will  be  considered in the future, when GRIC offers corporate roaming
     4.9.  Security
     No GRIC members currently offer token card or tunneling support.
     4.10.  Accounting
     The AimTraveler software  can  act  as  either  a  RADIUS  or  TACACS+
     accounting  server.   When accounting information is received from the
     NAS, AimTraveler stamps a roaming transaction log at  the  centralized
     Roaming  Settlement Center. In the case of GRIC, the settlement center
     is run by Aimnet.
     Aboba, Liu, Alsop, & Ding                                     [Page 6]

     INTERNET-DRAFT                                        26 November 1996
     The AimTraveler Server running at Aimnet keeps a record of  all  roam-
     ing  transactions,  which  are  used  as  input  to the settlement and
     billing process.  At the end of each month, Aimnet provides a  roaming
     transaction  summary to GRIC members using AIMS.  The AIMS software is
     configurable so that it takes into account the settlement rules agreed
     to  by  GRIC  members. AimTraveler also provides accounting records to
     the local and home ISP for verification purposes.
     5.  i-Pass implementation
     5.1.  Overview
     i-Pass Alliance Inc., based in Palo Alto, California has developed and
     operates  a  service  for  global  roaming  between  Internet  service
     providers.  The service is currently in field trials.
     i-Pass Alliance Inc. has additional offices in Toronto, Hong Kong, and
     London.    More   information   on   i-Pass   can   be  obtained  from
     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
          State or Province
          City or Region
          Telephone number
          Technical support phone number
          Service types available
          Technical information (help file)
          Service pricing information
     i-Pass  member  ISPs  may  update their information in the APD using a
     Aboba, Liu, Alsop, & Ding                                     [Page 7]

     INTERNET-DRAFT                                        26 November 1996
     secure web interface.
     5.3.  Phone number presentation
     i-Pass provides information and tools to  Internet  Service  Providers
     and dialer application developers to assist them in integrating the i-
     Pass access point database into their software.
     i-Pass does not intend to be a primary developer  of  dialer  applica-
     tions,  as  it believes this requirement is best met by the above par-
     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:
          RADIUS (standard Livingston distribution)
          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.
     Aboba, Liu, Alsop, & Ding                                     [Page 8]

     INTERNET-DRAFT                                        26 November 1996
     The software integration effort for a typical ISP is on the  order  of
     2-5 man-days including testing.  Platforms currently supported include
     Solaris 2.[45], BSDI, and Digital Unix.
     5.5.  Accounting
     Accounting transactions are handled in the same way as  authentication
     requests.  In addition to being logged at the i-Pass servers, account-
     ing transactions are sent in real-time  to  the  home  ISP.   This  is
     intended  to allow ISPs to update users' credit limit information on a
     real-time basis (to the extent that this capability  is  supported  by
     their billing and accounting systems).
     Settlement  is  performed  periodically (initially once a month).  The
     settlement process involves calculating the costs associated with each
     individual  session,  and aggregating them for each ISP.  A net amount
     is then calculated which is either due from i-Pass to the ISP, or from
     the ISP to i-Pass, depending on the actual usage pattern.
     The following reports are supplied to member ISPs:
          A Monthly Statement showing summaries of usage,
          service provided, and any adjustments along with the
          net amount owing.
          A Call Detail Report showing roaming usage by the ISP's
          A Service Provided report showing detailed usage of
          the ISP's facilities by remote users.
     The  above  reports  are  generated  as  ASCII documents to facilitate
     delivery by electronic means (e.g. e-mail) as well as hard-copy.
     The Call Detail Report is also generated as  a  comma-delimited  ASCII
     file  suitable  for import into the ISP's billing database.  (The Call
     Detail Report will normally be used by the ISP  to  generate  end-user
     billing for roaming usage).
     5.6.  Security
     All  transactions  between  ISPs  and the i-Pass servers are encrypted
     using the SSL protocol.  Public key certificates are verified at  both
     the  client and server.  (i-Pass issues these certificates and acts as
     the Certification Authority).
     Transactions are also verified based on a  number  of  other  criteria
     such as source IP address.
     Aboba, Liu, Alsop, & Ding                                     [Page 9]

     INTERNET-DRAFT                                        26 November 1996
     6.  ChinaNet implementation
     ChinaNet,  owned  by  China Telecom, is China's largest Internet back-
     bone. Constructed by Asiainfo, a Dallas based system integration  com-
     pany,  it  has  31  backbone  nodes  in  31 Chinese provincial capital
     cities. Each province is building its own provincial network, has  its
     own dialup servers, and administers its own user base.
     In  order  to  allow ChinaNet users to be able to access nodes outside
     their province while traveling, a nationwide roaming system  has  been
     implemented.   The  roaming  system  was developed by AsiaInfo, and is
     based on the RADIUS protocol.
     6.1.  Phone number presentation
     Since China Telecom uses one phone number (163) for nationwide  Inter-
     net  access,  most cities have the same Internet access number. There-
     fore a phone book is not currently required for the ChinaNet implemen-
     tation.  A  web-based  phone  book will  be added in a future software
     release in order to support nationwide ISP/CSP telephone  numbers  and
     HTTP server addresses.
     6.2.  Connection management
     The current roaming client and server supports both PPP and SLIP.
     6.3.  Address assignment and routing
     ChinaNet  only  supports  dynamic  IP  address  assignment for roaming
     users. In addition, static addresses are supported for users authenti-
     cating within their home province.
     6.4.  Authentication
     When  user  accesses  a  local  NAS,  it provides its userID either as
     "username" or "username@realm".  The NAS  will  pass  the  userID  and
     password  to  the  RADIUS proxy/server.  If the "username" notation is
     used, the Radius proxy/server will assume that the  user  is  a  local
     user  and  will  handle  local authentication accordingly.  If  "user-
     name@realm" is used, the RADIUS proxy/server  will  process  it  as  a
     roaming request.
     When the RADIUS proxy/server handles a request from a roaming user, it
     will first check the cache to see if the user information  is  already
     stored  there. If there is a cache hit, the RADIUS proxy/server do the
     local authentication accordingly.  If it does not find  user  informa-
     tion  in its cache, it will act as a proxy, forwarding the authentica-
     tion request to the home RADIUS server.  When the home  RADIUS  server
     responds,  the  local server will forward the response to the NAS.  If
     the user is authenticated by the home server, the local  RADIUS  proxy
     will  cache  the  user  information  for  a  period of time (3 days by
     Aboba, Liu, Alsop, & Ding                                    [Page 10]

     INTERNET-DRAFT                                        26 November 1996
     Caching is used to avoid frequent proxying of requests  and  responses
     between  the  local  RADIUS proxy and the home RADIUS server. When the
     home RADIUS server sends back a  valid  authentication  response,  the
     local RADIUS proxy/server will cache the user information for a period
     of time (3  days  by  default).   When  the  user  next  authenticates
     directly  against  the home RADIUS server, the home RADIUS server will
     send a request to the local server or  servers  to  clear  the  user's
     information from the cache.
     6.4.1.  Extended hierarchy
     In   some   provinces,  the  local  telecommunications  administration
     (Provincial ISP) further delegates control  to  county  access  nodes,
     creating another level of hierarchy. This is done to improve scalabil-
     ity and to avoid having the provincial ISP databases grow  too  large.
     In  the  current implementation, each provincial ISP maintains its own
     central RADIUS server, including  information  on  all  users  in  the
     province,  while county nodes maintain distributed RADIUS servers. For
     intra-province roaming requests the  local  RADIUS  proxy/server  will
     directly forward the request to the home RADIUS server.
     However,  for inter-province roaming requests, the local RADIUS server
     does not forward the request  directly  to  the  home  RADIUS  server.
     Instead,  the  request  is  forwarded to the central provincial RADIUS
     server for the home province. This  implementation  is  suitable  only
     when  county  level  ISPs do not mind combining and sharing their user
     information. In this instance, this is acceptable,  since  all  county
     level ISPs are part of China Telecom. In a future release, this multi-
     layer hierarchy will be implemented using multi-layer proxy RADIUS, in
     a manner more resembling DNS.
     6.5.  Security
     Encryption  is used between the local RADIUS proxy/server and the home
     RADIUS server. Public/Private key encryption will be supported in  the
     next  release. IP tunneling and token card support is under considera-
     6.6.  Accounting
     Accounting  information  is  transferred  between  the  local   RADIUS
     accounting  proxy/server and home RADIUS accounting server.  Every day
     each node sends a summary accounting information record to  a  central
     server  in  order to support nationwide settlement. The central server
     is run by the central Data  Communication  Bureau  of  China  Telecom.
     Every  month  the  central  server  sends  the  settlement bill to the
     provincial ISPs.
     Aboba, Liu, Alsop, & Ding                                    [Page 11]

     INTERNET-DRAFT                                        26 November 1996
     6.7.  Inter-ISP/CSP roaming
     ChinaNet supports both ISP and CSP (Content Service Provider)  roaming
     on  its  system.  For example, Shanghai Online, a Web-based commercial
     content service, uses RADIUS for authentication of ChinaNet users  who
     do  not  have a Shanghai Online account. In order to support this, the
     Shanghai Online servers function as  a  RADIUS  client  authenticating
     against the home RADIUS server. When users access a protected document
     on the HTTP server, they are prompted to send a username/password  for
     authentication.  The  user  then  responds with their userID in "user-
     name@realm" notation.
     A CGI script on the HTTP server then acts as a  RADIUS  authentication
     client,  sending the request to the home RADIUS server. After the home
     RADIUS server responds, the CGI script passes the information  to  the
     local  authentication  agent.  From  this point forward, everything is
     taken care of by the local Web authentication mechanism.
     7.  Microsoft implementation
     Microsoft's roaming implementation was originally developed  in  order
     to  support  the  Microsoft  Network  (MSN), which now offers Internet
     access in seven countries (US, Canada, France, Germany, UK, Japan, and
     Australia).  In each of these countries, service is offered in cooper-
     ation with access partners.  Since users are able to  use  the  access
     partner networks while maintaining a customer-vendor relationship with
     MSN, this implementation fits within the definition of roaming as used
     in this document.
     7.1.  Implementation overview
     The  first  version  of the Microsoft roaming software was deployed by
     the MSN partners in April, 1996.  This version included a  Phone  Book
     manager   tool   running  under  Windows  95,  as  well  as  a  RADIUS
     server/proxy implementation running under Windows NT; TACACS+ is  cur-
     rently  not  supported.   Additional  components now under development
     include a Connection Manager client for Windows 95 as well as an HTTP-
     based phone book server for Windows NT. The Phone Book manager tool is
     also being upgraded to provide for more automated phone book  compila-
     7.2.  Phone number presentation
     The  Connection Manager is responsible for the presentation and updat-
     ing of phone numbers, as well as for dialing and  making  connections.
     In  order  to  select  phone  numbers,  users  are asked to select the
     desired country and region/state.  Phone numbers are then presented in
     the  area selected.  The primary numbers are those from the users ser-
     vice provider which match the service type  (Analog,  ISDN,  Analog  &
     ISDN),  country and region/state selected. The other numbers (selected
     clicking on the More button) are those  for  other  service  providers
     Aboba, Liu, Alsop, & Ding                                    [Page 12]

     INTERNET-DRAFT                                        26 November 1996
     that have a roaming agreement with the users service provider.
     7.2.1.  Cost data
     Cost data is not presented to users along with the phone numbers. How-
     ever, such information may be made available by other means,  such  as
     via a Web page.
     7.2.2.  Default phone book format
     The  Connection  Manager  supports  the ability to customize the phone
     book format, and it is expected that many ISPs will make use  of  this
     capability.  However,  for  those who wish to use it "off the shelf" a
     default phone book format is provided. The default phone book is  com-
     prised of several files, including:
          Service profile
          Phone Book
          Region file
     The service profile provides information on a given service, which may
     be an isolated Internet Service Provider, or may represent  a  roaming
     consortium. The service profile, which is in .ini file format, is com-
     prised of the following information:
          The name of the service
          The filename of the service's big icon
          The filename of the service's little icon
          A description of the service
          The service phone book filename
          The service phone book version number
          The service regions file
          The URL of the service phone book server
          The prefix used by the service (i.e. "MSN/aboba")
          The suffix or domain used by the service (i.e. "aboba@msn.com")
          Whether the user name is optional for the service
          Whether the password is optional for the service
          Maximum length of the user name for the service
          Maximum length of the password for the service
          Information on service password handling (lowercase, mixed case, etc.)
          Number of redials for this service
          Delay between redials for this service
          References to other service providers that have roaming agreements
          The service profile filenames for each of the references
          Mask and match phone book filters for each of the references
                 (these are 32 bit numbers that are applied against the capability flags in the phone book)
          The dial-up connection properties configuration
               (this is the DUN connectoid name)
     The phone book file is a comma delimited  ASCII  file  containing  the
     Aboba, Liu, Alsop, & Ding                                    [Page 13]

     INTERNET-DRAFT                                        26 November 1996
     following data:
          Unique number identifying a particular record (Index)
          Country ID
          A zero-base index into the region file
          Area code
          Local phone number
          Minimum Speed
          Maximum speed
          Capability Flags:
               Bit 0: 0=Toll, 1=Toll free
               Bit 1: 0=X25, 1=IP
               Bit 2: 0=Analog, 1=No analog support
               Bit 3: 0=no ISDN support, 1=ISDN
               Bit 4: 0
               Bit 5: 0
               Bit 6: 0=No Internet access, 1=Internet access
               Bit 7: 0=No signup access, 1=Signup access
               Bit 8-31: reserved
          The filename of the dialup network file
             (typically refers to a script associated with the number)
     A sample phone book file is shown below:
     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)
     Aboba, Liu, Alsop, & Ding                                    [Page 14]

     INTERNET-DRAFT                                        26 November 1996
          Provider name
     7.2.4.  Addition of information on providers
     The  default  phone  book  does not provide a mechanism for display of
     information on the individual ISPs within the roaming consortium, only
     for  the  consortium  as a whole. For example, the provider icons (big
     and little) are included in the service profile. The service  descrip-
     tion  information  is expected to contain the customer support number.
     However, this information cannot be provided on  an  individual  basis
     for  each of the members of a roaming consortium.  Additional informa-
     tion useful on a per-provider basis would include:
          Provider voice phone number
          Provider icon
          Provider fax phone number
          Provider customer support phone number
     7.3.  Phone number exchange
     Currently phone number exchange is not supported  by  the  phone  book
     server.  As a result, in the MSN implementation, phone number exchange
     is handled manually.  As new POPs come online, the  numbers  are  for-
     warded  to MSN, which tests the numbers and approves them for addition
     to the phone book server. Updated phone books are produced and  loaded
     on the phone book server on a weekly basis.
     7.4.  Phone book compilation
     The Phone Book Manager tool was created in order to make it easier for
     the access partners to create and update their phone  books.  It  sup-
     ports addition, removal, and editing of phone numbers, generating both
     a new phone book, as well as associated difference files.
     With version 1 of the Phone Book Admin tool, phone books are  compiled
     manually,  and represent a concatenation of available numbers from all
     partners, with no policy application.  With version 1, the updates are
     prepared by the partners and forwarded to MSN, which tests the numbers
     and approves them for addition to the phone book. The updates are then
     concatenated together to form the global update file.
     The  new  version  of  the Phone Book Admin tool automates much of the
     phone book compilation process, making it possible for phone book com-
     pilation to be decentralized with each partner running their own phone
     book server. Partners can then  maintain  and  test  their  individual
     phone books and post them on their own Phone Book Server.
     Aboba, Liu, Alsop, & Ding                                    [Page 15]

     INTERNET-DRAFT                                        26 November 1996
     7.5.  Phone book update
     The  Connection Manager updates the phone book each time the user logs
     on. This is accomplished via an HTTP GET request  to  the  phone  book
     server, with information on the phone book version number presented as
     part of the GET request.
     In formulating its response, the phone book server then  compares  the
     version  number  in the GET request to the current version number, and
     reponds with the difference files necessary  to  update  the  client's
     phone book to the latest version. The client then builds the new phone
     book by successively applying these difference  files.   This  process
     results  in  the update of the entire phone book, and is simple enough
     to allow it to be easily implemented on a  variety  of  HTTP  servers,
     either as a CGI script or (on NT) as an ISAPI DLL.
     The  difference files used in the default phone book consist of a list
     of phone book entries, each uniquely identified by their index number.
     Additions consist of phone book entries with all the information filed
     in; deletions are signified by entries with all  entries  zeroed  out.
     Before  being sent, the update file is digitally signed. A sample dif-
     ference file is shown below:
     7.6.  Connection management
     The Connection Manager assumes use of PPP, and does not support  SLIP.
     The default setting is for the IP address as well as the DNS server IP
     address to be assigned by the NAS. The DNS server assignment  capabil-
     ity is described in [1].
     7.7.  Authentication
     The  Connection  Manager  client  and RADIUS proxy/server both support
     suffix style notation (i.e. "aboba@msn.com"),  as  well  as  a  prefix
     notation ("MSN/aboba").
     The  prefix notation was developed for use with NAS devices with small
     maximum userID lengths.  For these devices the compactness of the pre-
     fix  notation  significantly increases the number of characters avail-
     able for the userID field.  However, as an increasing  number  of  NAS
     devices are now supporting 253 octet userIDs (the maximum supported by
     RADIUS) the need for prefix notation is declining.
     After receiving the userID from the Connection Manager client, the NAS
     device  passes  the  userID/domain and password information (or in the
     case of CHAP, the challenge and the response) to the RADIUS proxy. The
     Aboba, Liu, Alsop, & Ding                                    [Page 16]

     INTERNET-DRAFT                                        26 November 1996
     RADIUS  proxy  then  checks if the domain is authorized for roaming by
     examining a static configuration file. If the  domain  is  authorized,
     the  RADIUS  proxy then forwards the request to the appropriate RADIUS
     server. The domain to server mapping is also made via a static config-
     uration file.
     While  static  configuration files work well for small roaming consor-
     tia, for larger consortia static configuration  will  become  tedious.
     Potentially more scalable solutions include use of DNS SRV records for
     the domain to RADIUS server mapping.
     7.8.  NAS configuration/authorization
     Although the attributes returned by the home RADIUS  server  may  make
     sense  to  home  NAS  devices, the local NAS may be configured differ-
     ently, or may be from a different vendor.  As a result, it may be nec-
     essary  for the RADIUS proxy to edit the attribute set returned by the
     home RADIUS server, in order to provide the local NAS with the  appro-
     priate  configuration  information.   The editing occurs via attribute
     discard and insertion of attributes by the proxy.
     Alternatively, the home RADIUS server may be configured not to  return
     any  network-specific attributes, and to allow these to be inserted by
     the local RADIUS proxy.
     Attributes most likely to cause conflicts include:
          Framed IP Address
          Framed IP Netmask
          Framed Routing
          Framed Route
          Filter ID
          Vendor Specific
          Session Timeout
          Idle Timeout
          Termination Action
     Conflicts relating to IP address assignment and routing are very  com-
     mon.   Where  dynamic  address  assignment is used, an IP address pool
     appropriate for the local NAS can be substituted for  the  IP  address
     pool designated by the home RADIUS server.
     However,  not  all  address  conflicts can be resolved by editing.  In
     some cases, (i.e., assignment of a static network address for  a  LAN)
     it  may  not  be  possible for the local NAS to accept the home RADIUS
     server's address assignment, yet the roaming hosts may not be able  to
     accept an alternative assignment.
     Filter  IDs also pose a problem. It is possible that the local NAS may
     not implement a filter corresponding to that designated  by  the  home
     RADIUS  server.  Even if an equivalent filter is implemented, in order
     to guarantee correct operation, the proxy's configuration  must  track
     changes  in  the  filter  configurations of each of the members of the
     Aboba, Liu, Alsop, & Ding                                    [Page 17]

     INTERNET-DRAFT                                        26 November 1996
     roaming consortium. In practice  this  is  likely  to  be  unworkable.
     Direct  upload  of  filter  configuration  is  not  a solution either,
     because of the wide variation in filter languages supported in today's
     NAS devices.
     Since  by  definition  vendor specific attributes have meaning only to
     devices created by that vendor, use of these attributes is problematic
     within  a  heterogeneous  roaming  consortium. While it is possible to
     edit these attributes, or even to discard them or  allow  them  to  be
     ignored, this may not always be acceptable. In cases where vendor spe-
     cific attributes relate to security, it may not be acceptable for  the
     proxy  to  modify  or  discard  these  attributes; the only acceptable
     action may be for the local NAS  to  drop  the  user.   Unfortunately,
     RADIUS does not distinguish between mandatory and optional attributes,
     so that there is no way for  the  proxy  to  take  guidance  from  the
     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
     Aboba, Liu, Alsop, & Ding                                    [Page 18]

     INTERNET-DRAFT                                        26 November 1996
     of  record formats and transfer protocols implies that the partners do
     not communicate with the settlement agent using NAS accounting  proto-
     cols.   As  a  result,  accounting protocol interoperability is not be
     However, for this advantage to be fully realized, it is necessary  for
     the  accounting  record  format  to  be extensible. This makes it more
     likely that the format can be adapted for use with the wide variety of
     accounting protocols in current use (such as SNMP, syslog, RADIUS, and
     TACACS+), as well as future protocols. After all, if the record format
     cannot express the metrics provided by a particular partner's account-
     ing protocol, then the record format will not be of  much  use  for  a
     heterogeneous roaming consortium.
     7.11.1.  Accounting record format
     The  Microsoft  RADIUS  proxy/server supports the ability to customize
     the accounting record format, and it is expected that some  ISPs  will
     make use of this capability. However for those who want to use it "off
     the shelf"  a  default  accounting  record  format  is  provided.  The
     accounting record includes information provided by RADIUS:
          User Name (String; the user's ID, including prefix or suffix)
          NAS IP address (Integer; the IP address of the user's NAS)
          NAS Port (Integer; identifies the physical port on the NAS)
          Service Type (Integer; identifies the service provided to the user)
          NAS Identifier (Integer; unique identifier for the NAS)
          Status Type (Integer; indicates session start and stop,
             as well as accounting on and off)
          Delay Time (Integer; time client has been trying to send)
          Input Octets (Integer; in stop record, octets received from port)
          Output Octets (Integer; in stop record, octets sent to port)
          Session ID (Integer; unique ID linking start and stop records)
          Authentication (Integer; indicates how user was authenticated)
          Session Time (Integer; in stop record, seconds of received service)
          Input Packets (Integer; in stop record, packets received from port)
          Output Packets (Integer; in stop record, packets sent to port)
          Termination Cause (Integer; in stop record, indicates termination cause)
          Multi-Session ID (String; for linking of multiple related sessions)
          Link Count (Integer; number of links up when record was generated)
          NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
     However, since this default format is not extensible, it cannot easily
     be adapted to protocols other than RADIUS, services other than  dialup
     (i.e.  dedicated  connections)  or rated events (i.e. file downloads).
     This is  a  serious  limitation,  and  as  a  result,  customers  have
     requested a more general accounting record format.
     7.11.2.  Transfer mechanism
     Prior  to  being transferred, the accounting records are compressed so
     as to save bandwidth.  The transfer of accounting records  is  handled
     Aboba, Liu, Alsop, & Ding                                    [Page 19]

     INTERNET-DRAFT                                        26 November 1996
     via  FTP,  with  the  transfer being initiated by the receiving party,
     rather than by the sending party.  A duplicate set of records is  kept
     by the local ISP for verification purposes.
     8.  FidoNet implementation
     Since its birth in 1984, FidoNet has supported phone book synchroniza-
     tion among its member nodes, which now  number  approximately  35,000.
     As  a  non-IP  dialup network, FidoNet does not provide IP services to
     members, and does  not  utilize  IP-based  authentication  technology.
     Instead  member  nodes offer bulletin-board services, including access
     to mail and conferences known as echoes.
     In order to be able to communicate with  each  other,  FidoNet  member
     systems  require  a sychronized phone book, known as the Nodelist. The
     purpose of the Nodelist is to enable resolution of  FidoNet  addresses
     (expressed  in the form zone:network/node, or 1:161/445) to phone num-
     bers.  As a dialup network, FidoNet requires phone numbers in order to
     be deliver mail and conference traffic.
     In  order to minimize the effort required in regularly synchronizing a
     phone book of 35,000 entries, the weekly Nodelist updates  are  trans-
     mitted  as  difference  files.  These  difference  files, known as the
     Nodediff, produce the Nodelist for the current week  when  applied  to
     the  previous  week's  Nodelist.   In order to minimize transfer time,
     Nodediffs are compressed prior to transfer.
     Information on FidoNet, as well as FidoNet Technical  Standards  (FTS)
     documents (including the Nodelist specification) and standards propos-
     als are available from the FidoNet archive at http://www.fidonet.org/.
     8.1.  Scaling issues
     With  a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB
     in size, and the weekly Nodediffs are 175 KB. In compressed form,  the
     Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a
     result, the transfer of the Nodediff takes  approximately  45  seconds
     using a 28,800 bps modem.
     In  order  to improve scalability, the implementation of a domain name
     service approach is examined in [8]. The proposal evisages  use  of  a
     capability  analagous  to the DNS ISDN record in order to map names to
     phone numbers, coupled  with  an  additional  record  to  provide  the
     attributes associated with a given name.
     8.2.  Phone number presentation
     While FidoNet member systems perform phone book synchronization, users
     need only know the FidoNet address of the systems they  wish  to  con-
     tact. As a result users do not need to maintain copies of the Nodelist
     on their own systems. This is similar to the Internet, where  the  DNS
     Aboba, Liu, Alsop, & Ding                                    [Page 20]

     INTERNET-DRAFT                                        26 November 1996
     takes  care of the domain name to IP address mapping, so that users do
     not have to remember IP addresses.
     Nevertheless, FidoNet systems often find it useful to be able to  pre-
     sent lists of nodes, and as a result, FidoNet Nodelist compilers typi-
     cally produce a representation of the Nodelist that can be searched or
     displayed online, as well as one that is used by the system dialer.
     8.2.1.  FidoNet Nodelist format
     The  FidoNet  Nodelist  format  is  documented  in detail in [3].  The
     Nodelist file consists of lines of data  as  well  as  comment  lines,
     which  begin  with  a semi-colon.  The first line of the Nodelist is a
     general interest comment line that includes the date and the day  num-
     ber,  as  well as a 16-bit CRC. The CRC is included so as to allow the
     system assembling the new Nodelist to verify its integrity.
     Each Nodelist data line contains eight comma separated fields:
          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.
     8.3.  Phone number exchange
     FidoNet coordinators are responsible for maintaining up to date infor-
     mation on their networks, regions, and zones. Every week network coor-
     dinators submit to their regional  coordinators  updated  versions  of
     their portions of the Nodelist. The regional coordinators then compile
     the submissions from their network coordinators, and  submit  them  to
     the  zone  coordinator. The zone coordinators then exchange their sub-
     missions to produce the new Nodelist. As a result, it is possible that
     the view from different zones may differ at any given time.
     Aboba, Liu, Alsop, & Ding                                    [Page 21]

     INTERNET-DRAFT                                        26 November 1996
     8.3.1.  The Nodediff
     The format of the Nodediff is discussed in detail in [3]. In preparing
     the Nodediffs, network coordinators may transmit only their difference
     updates, which can be collated to produce the Nodediff directly.
     One  weakness  in  the  current  approach is that there is no security
     applied to the coordinator submissions. This leaves open the possibil-
     ity  of  propagation  of fraudulent updates. In order to address this,
     [6] proposes addition of a shared secret to the update files.
     8.3.2.  Addition of nodes
     In order to apply for allocation of a FidoNet address  and  membership
     in the Nodelist, systems must demonstrate that they are functioning by
     sending mail to the local network coordinator.  Once the local network
     coordinator receives the application, they then allocate a new FidoNet
     address, and add a Nodelist entry.
     8.3.3.  Deletion of nodes
     Since FidoNet nodes are required to be  functioning  during  the  zone
     mail hour in order to receive mail, and since nodes receive the weekly
     Nodelist from their local network  coordinators  on  a  weekly  basis,
     there is a built-in mechanism for discovery of non-functional nodes.
     Nodes  found  to be down are reported to the local network coordinator
     and subsequently marked as down within the Nodelist.  Nodes  remaining
     down  for more than two weeks may be removed from the Nodelist, at the
     discretion of the network coordinator.
     8.4.  Phone book update
     The Nodelist contains the phone numbers and associated  attributes  of
     each  participating system. New Nodelists become available on Fridays,
     and are made available to participating systems by their local network
     coordinators,  who  in  turn  receive  them from the regional and zone
     While it is standard practice for participating systems to  get  their
     Nodelists from their local network coordinators, should the local net-
     work coordinator not be available for some reason, either the  updates
     or  the  complete  Nodelist  may  be  picked up from other network, or
     regional coordinators. Please note that since the view from  different
     zones  may  differ, nodes wishing to update their Nodelists should not
     contact systems from outside their zone.
     8.5.  Phone book compilation
     Once FidoNet systems have received the Nodediff, the apply it  to  the
     previous week's Nodelist in order to prepare a new Nodelist.  In order
     Aboba, Liu, Alsop, & Ding                                    [Page 22]

     INTERNET-DRAFT                                        26 November 1996
     to receive Nodediffs and compile the Nodelist, the following  software
     is required:
          A FidoNet-compatible mailer implementation, used to transfer files
          A Nodelist compiler
     One  of the purposes of the Nodelist compiler is to apply Nodediffs to
     the previous Nodelist in order to produce  an  updated  Nodelist.  The
     other  purpose  is  to  compile  the  updated Nodelist into the format
     required by the particular mailer implementation used  by  the  member
     system.  It  is important to note that while the Nodelist and Nodediff
     formats are standardized (FTS-0005), as is the file transfer  protocol
     (FTS-0001),  the compiled format used by each mailer is implementation
     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-
     8.5.2.  Shared secrets
     In FidoNet, shared secrets are used for authenticated sessions between
     systems.   Such  authenticated  sessions  are  particularly  important
     between  the local, regional and zone coordinators who handle prepara-
     tion and transmission of the Nodediffs. A single shared secret is used
     per system.
     8.6.  Accounting
     Within FidoNet, the need for accounting arises primarily from the need
     of local, regional and zone coordinators to be  reimbursed  for  their
     expenses.  In  order to support this, utilities have been developed to
     account for network usage at the system  level  according  to  various
     metrics.   However,  the  accounting techniques are not applied at the
     user level. Distributed authentication and accounting are  not  imple-
     mented and therefore users may not roam between systems.
     Aboba, Liu, Alsop, & Ding                                    [Page 23]

     INTERNET-DRAFT                                        26 November 1996
     9.  Acknowledgements
     Thanks  to  Glen Zorn of Microsoft for many useful discussions of this
     problem space.
     10.  References
     [1]  S. Cobb.  "PPP Internet Protocol Control Protocol Extensions  for
     Name Server Addresses" RFC 1877, Microsoft, December 1995.
     [2]   T.  Berners-Lee,  R.  Fielding, H. Frystyk.  "Hypertext Transfer
     Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996.
     [3]  B. Baker, R. Moore,  D.  Nugent.   "The  Distribution  Nodelist."
     FTS-0005, February, 1996.
     [4]  A. Lentz.  "ISDN Nodelist flags." FSC-0091, June, 1996.
     [5]   D. J. Thomas.  "A Proposed Nodelist flag indicating Online Times
     of a Node." FSC-0062, April, 1996.
     [6]   L.  Kolin.   "Security  Passwords  in  Nodelist  Update  Files."
     FSC-0055, March, 1991.
     [7]   R.  Gwinn,  D.  Dodell.  "Nodelist Flag Changes Draft Document."
     FSC-0009, November, 1987.
     [8]  R. Heller.  "A Proposal  for  A  FidoNet  Domain  Name  Service."
     FSC-0069, December, 1992.
     11.  Authors' Addresses
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     Lynn Liu
     Aimnet Corporation
     2350 Mission College Blvd., Ste. 600
     Santa Clara, CA 95054
     Phone: 408-567-3800 ext. 202
     EMail: yalin@aimnet.com
     John Alsop
     i-Pass Alliance Inc.
     555 Bryant Street, #248
     Palo Alto, CA 94301
     Aboba, Liu, Alsop, & Ding                                    [Page 24]

     INTERNET-DRAFT                                        26 November 1996
     Phone: 415-327-5553
     EMail: jalsop@ipass.com
     James Ding
     One Galleria Tower
     13355 Noel Road, #1340
     Dallas, TX 75240
     Phone: 214-788-4141
     Fax:   214-788-0729
     EMail: ding@bjai.asiainfo.com
     Aboba, Liu, Alsop, & Ding                                    [Page 25]