home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-imprev-03.txt < prev    next >
Text File  |  1997-06-10  |  88KB  |  2,112 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.      ROAMOPS Working Group                                    Bernard Aboba
  7.      INTERNET-DRAFT                                               Microsoft
  8.      Category: Informational                                        Juan Lu
  9.      <draft-ietf-roamops-imprev-03.txt>                      AimQuest Corp.
  10.      10 June 1997                                                John Alsop
  11.                                                             i-Pass Alliance
  12.                                                                  James Ding
  13.                                                                    Asiainfo
  14.                                                                    Wei Wang
  15.                                                         Merit Network, Inc.
  16.  
  17.  
  18.  
  19.  
  20.                        Review of Roaming Implementations
  21.  
  22.  
  23.  
  24.      1.  Status of this Memo
  25.  
  26.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  27.      ments of the Internet Engineering Task Force (IETF),  its  areas,  and
  28.      its  working groups.  Note that other groups may also distribute work-
  29.      ing documents as Internet-Drafts.
  30.  
  31.      Internet-Drafts are draft documents valid for a maximum of six  months
  32.      and  may  be updated, replaced, or obsoleted by other documents at any
  33.      time.  It is inappropriate to use Internet-Drafts as  reference  mate-
  34.      rial or to cite them other than as ``work in progress.''
  35.  
  36.      To  learn  the  current status of any Internet-Draft, please check the
  37.      ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
  38.      Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
  39.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  40.  
  41.      The  distribution  of  this memo is unlimited.  It is filed as <draft-
  42.      ietf-roamops-imprev-03.txt>, and  expires  January  1,  1998.   Please
  43.      send comments to the authors.
  44.  
  45.  
  46.      2.  Abstract
  47.  
  48.      This document reviews the design and functionality of existing roaming
  49.      implementations.  "Roaming capability" may be loosely defined  as  the
  50.      ability  to use any one of multiple Internet service providers (ISPs),
  51.      while maintaining a formal,  customer-vendor  relationship  with  only
  52.      one.   Examples  of  cases  where roaming capability might be required
  53.      include ISP "confederations" and ISP-provided corporate network access
  54.      support.
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 1]
  64.  
  65.  
  66.  
  67.  
  68.  
  69.      INTERNET-DRAFT                                            10 June 1997
  70.  
  71.  
  72.      3.  Introduction
  73.  
  74.      Considerable  interest  has  arisen recently in a set of features that
  75.      fit within the general category of "roaming capability"  for  Internet
  76.      users.  Interested parties have included:
  77.  
  78.           Regional  Internet  Service  Providers  (ISPs) operating within a
  79.           particular state or province, looking to  combine  their  efforts
  80.           with  those  of  other regional providers to offer service over a
  81.           wider area.
  82.  
  83.           National ISPs wishing to combine their operations with  those  of
  84.           one  or  more  ISPs in another nation to offer more comprehensive
  85.           service in a group of countries or on a continent.
  86.  
  87.           Businesses desiring to  offer  their  employees  a  comprehensive
  88.           package of access services on a global basis.  Those services may
  89.           include Internet access as well as  secure  access  to  corporate
  90.           intranets via a Virtual Private Network (VPN), enabled by tunnel-
  91.           ing protocols such as PPTP, L2F, or L2TP.
  92.  
  93.      What is required to provide roaming capability?  The following list is
  94.      a  first cut at defining the requirements for successful roaming among
  95.      an arbitrary set of ISPs:
  96.  
  97.           Phone number presentation
  98.           Phone number exchange
  99.           Phone book compilation
  100.           Phone book update
  101.           Connection management
  102.           Authentication
  103.           NAS Configuration/Authorization
  104.           Address assignment and routing
  105.           Security
  106.           Accounting
  107.  
  108.      In this document we review existing roaming implementations,  describ-
  109.      ing  their  functionality  within this framework.  In addition to full
  110.      fledged roaming implementations, we will also  review  implementations
  111.      that, while not meeting the strict definition of roaming, address sev-
  112.      eral of these problem elements. These implementations  typically  fall
  113.      into the category of shared use networks or non-IP dialup networks.
  114.  
  115.      3.1.  Terminology
  116.  
  117.      This document frequently uses the following terms:
  118.  
  119.  
  120.      home ISP  This  is  the  Internet  service provider with whom the user
  121.                maintains an account relationship.
  122.  
  123.  
  124.      local ISP This is the Internet service provider whom the user calls in
  125.                order  to get access. Where roaming is implemented the local
  126.  
  127.  
  128.  
  129.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 2]
  130.  
  131.  
  132.  
  133.  
  134.  
  135.      INTERNET-DRAFT                                            10 June 1997
  136.  
  137.  
  138.                ISP may be different from the home ISP.
  139.  
  140.  
  141.      phone book
  142.                This is a database or document containing data pertaining to
  143.                dialup  access,  including  phone numbers and any associated
  144.                attributes.
  145.  
  146.  
  147.      shared use network
  148.                This is an IP dialup network whose use is shared by  two  or
  149.                more organizations.  Shared use networks typically implement
  150.                distributed authentication and accounting in order to facil-
  151.                itate  the  relationship  among  the  sharing parties. Since
  152.                these facilities are also  required  for  implementation  of
  153.                roaming,  implementation of shared use is frequently a first
  154.                step toward development of roaming  capabilities.  In  fact,
  155.                one  of  the ways by which a provider may offer roaming ser-
  156.                vice is to conclude shared use agreements with multiple net-
  157.                works.  However,  to date the ability to accomplish this has
  158.                been hampered by lack of interoperability among  shared  use
  159.                implementations.
  160.  
  161.  
  162.      non-IP dialup network
  163.                This is a dialup network providing user access to the member
  164.                systems via protocols other than  IP.   These  networks  may
  165.                implement phone book synchronization facilities, in order to
  166.                provide systems, administrators and  users  with  a  current
  167.                list  of  participating  systems.  Examples of non-IP dialup
  168.                networks  supporting  phone  book  synchronization   include
  169.                FidoNet and WWIVnet.
  170.  
  171.  
  172.      4.  Global Reach Internet Consortium (GRIC)
  173.  
  174.      Led by a US-based Internet technology developer, AimQuest Corporation,
  175.      ten Internet Service Providers (ISPs) from the USA, Australia,  China,
  176.      Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the
  177.      Global Reach Internet Connection (GRIC) in May, 1996.   The  goals  of
  178.      GRIC were to facilitate the implementation of a global roaming service
  179.      and to coordinate billing and settlement among the membership. Commer-
  180.      cial  operation  began in December of 1996, and GRIC has grown to over
  181.      50 major ISPs and Telcos from all over the  world,  including  NETCOM,
  182.      USA;  KDD  and  Mitsubishi,  Japan;  iStar,  Canada; Easynet, UK; Con-
  183.      nect.com,  Australia;  Iprolink,   Switzerland;   Singapore   Telecom;
  184.      Chunghwa  Telecom,  Taiwan; and Telekom Malaysia.  Information on GRIC
  185.      is available from http://www.gric.net/.
  186.  
  187.      In implementing their roaming service, GRIC members have chosen  soft-
  188.      ware developed by AimQuest. AimQuest Corporation's roaming implementa-
  189.      tion comprises the following major components: the AimTraveler Authen-
  190.      tication  Server  (AAS), the AimTraveler Routing Server (ARS), and the
  191.      AimQuest Internet  Management  System  (AIMS),  software  designed  to
  192.  
  193.  
  194.  
  195.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 3]
  196.  
  197.  
  198.  
  199.  
  200.  
  201.      INTERNET-DRAFT                                            10 June 1997
  202.  
  203.  
  204.      facilitate  the  billing  process. Information on the AimQuest roaming
  205.      implementation is available from http://www.aimquest.com/.
  206.  
  207.      The AimTraveler Authentication Server (AAS) runs at  each  member  ISP
  208.      location,  and  handles  incoming  authentication  requests  from  NAS
  209.      devices. The AimTraveler Routing Server (ARS) can run anywhere. A sin-
  210.      gle  routing  server can be used where centralized routing is desired,
  211.      or multiple routing servers can be run in order to increase speed  and
  212.      reliability  or to gateway to networks of particularly large partners.
  213.  
  214.      The first version of the AimTraveler software, deployed by AimQuest in
  215.      May,  1996,  supported  direct  authentication  between members of the
  216.      roaming consortium, but as GRIC grew, management of the  relationships
  217.      between  the authentication servers became a problem. In August. 1996,
  218.      AimQuest began development of the AimTraveler Routing Server (ARS)  in
  219.      order to improve scalability.
  220.  
  221.      The  routing server is comprised of two elements: The Central Account-
  222.      ing Server and the Central  Routing  Server.  The  Central  Accounting
  223.      Server  collects  all the roaming accounting data for settlement.  The
  224.      Central Routing  Server  manages  and  maintains  information  on  the
  225.      authentication servers in the roaming consortium. Adding, deleting, or
  226.      updating ISP authentication server information (e.g. adding a new mem-
  227.      ber ISP) may be accomplished by editing of a configuration file on the
  228.      Central Routing Server. The configuration  files  of  the  AimTraveler
  229.      Authentication Servers do not need to be modified.
  230.  
  231.      The  AimTraveler  Authentication and Routing Servers are available for
  232.      various UNIX platforms. Versions for Windows NT are under development.
  233.      The  AimTraveler Authentication Server supports both the UNIX password
  234.      file and Kerberos.
  235.  
  236.      The AimQuest Internet Management System (AIMS) is designed  for  large
  237.      ISPs  who need a centralized management system for all ISP operations,
  238.      including sales, trouble-ticketing, service, and billing.   AIMS  pro-
  239.      duces  usage and transaction statement reports, and includes a settle-
  240.      ment module to produce settlement/billing reports for the roaming con-
  241.      sortium  members.  Based  on these reports, the providers charge their
  242.      ISP/roaming customers, and pay/settle the roaming  balance  among  the
  243.      providers.  AIMS  currently  runs on Sun/Solaris/Oracle. A version for
  244.      Windows NT and SQL Server is expected to become available in Q4  1996.
  245.  
  246.  
  247.      4.1.  Phone number presentation
  248.  
  249.      Currently there are two principal methods by which GRIC users can dis-
  250.      cover available phone numbers: a Web-bsed directory  provided  by  the
  251.      GRIC secretariat, and an automatically updated phone book supported by
  252.      the AimQuest Ranger software.
  253.  
  254.      4.1.1.  Web based directory
  255.  
  256.      A directory of GRIC phone numbers is available on the GRIC home  page,
  257.      http://www.gric.com/.   The list of numbers is arranged by country and
  258.  
  259.  
  260.  
  261.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 4]
  262.  
  263.  
  264.  
  265.  
  266.  
  267.      INTERNET-DRAFT                                            10 June 1997
  268.  
  269.  
  270.      provider. For each provider within a country, this directory, provided
  271.      in the form of a table, offers the following information:
  272.  
  273.           Provider address, voice phone and fax
  274.           Customer support phone number
  275.           Provider domain name
  276.           Primary Domain Name Server
  277.           Secondary Domain Name Server
  278.           Dial-up IP Address
  279.           News server
  280.           Web page
  281.           POP phone numbers (i.e. 1-408-366-9000)
  282.           POP locations (i.e. Berkeley)
  283.           Proxy addresses
  284.           Dialer configuration
  285.  
  286.      In  order  to discover phone numbers using the Web-based directory, it
  287.      is expected that users will be online, and will navigate to the appro-
  288.      priate  country  and provider. They then look up the number and insert
  289.      it into the AimQuest Ranger dialer.
  290.  
  291.  
  292.      4.1.2.  AimQuest Ranger phone book
  293.  
  294.      The AimQuest Ranger software provides for phone book  presentation  as
  295.      well  as  automated  updating  of  phone numbers.  The AimQuest Ranger
  296.      phone book includes a country list, provider list, and POP (phone num-
  297.      ber)  list,  as  well  as detailed provider information, including the
  298.      cutomer support phone number, and Internet server configuration  info.
  299.      The  Phone book, developed with Microsoft VC++, is available for down-
  300.      load from the AimQuest ftp site:
  301.  
  302.      ftp://ftp.Aimnet.com/pub/traveler/isppb.ini
  303.      ftp://ftp.Aimnet.com/pub/traveler/isppb.exe
  304.  
  305.      A copy of the phone book is also available from the  GRIC  phone  book
  306.      page, available at http://www.gric.com/.
  307.  
  308.  
  309.      4.2.  Phone number exchange
  310.  
  311.      GRIC  members  submit information both about themselves and their POPs
  312.      to the GRIC secretariat, which is run by  AimQuest.  The  GRIC  secre-
  313.      tariat then compiles a new phone book and provides updates on the GRIC
  314.      FTP and Web servers.
  315.  
  316.      GRIC users then download the phone numbers either in Windows .ini file
  317.      format  (viewable  via  the  AimQuest  Ranger  phone book), or in HTML
  318.      (viewable via a Web browser).
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 5]
  328.  
  329.  
  330.  
  331.  
  332.  
  333.      INTERNET-DRAFT                                            10 June 1997
  334.  
  335.  
  336.      4.3.  Phone book compilation
  337.  
  338.      GRIC phone books are compiled manually, and represent a  concatenation
  339.      of  available  numbers from all the members of the roaming consortium,
  340.      with no policy application.  As new POPs come online, the numbers  are
  341.      forwarded to GRIC, which adds them to the phone book servers.
  342.  
  343.  
  344.      4.4.  Phone book update
  345.  
  346.      Phone  numbers in the AimQuest Ranger phone book are updated automati-
  347.      cally.  The AimTraveler server includes an address book which contains
  348.      the phone numbers of all the roaming consortium members.
  349.  
  350.  
  351.      4.5.  Connection management
  352.  
  353.      The AimTraveler and AimQuest Ranger software supports SLIP and PPP, as
  354.      well as PAP and CHAP authentication.
  355.  
  356.  
  357.      4.6.  Authentication
  358.  
  359.      GRIC implements distributed authentication, utilizing  the  user's  e-
  360.      mail  address  as  the userID (i.e. "liu@Aimnet.com") presented to the
  361.      remote NAS device. The AimQuest Ranger software takes care of present-
  362.      ing the e-mail address as the userID for PAP or CHAP authentication.
  363.  
  364.      After the initial PPP authentication exchange, the userID, domain, and
  365.      pasword information (or in the case of CHAP,  the  challenge  and  the
  366.      response) are then passed by the NAS to the AimTraveler Authentication
  367.      Server which supports both TACACS+ and RADIUS.
  368.  
  369.      If the authentication request comes from  a  regular  customer  login,
  370.      normal  user  id and password authentication is performed. If the user
  371.      requesting authentication is a "roamer," (has a userID with an  @  and
  372.      domain  name), the authentication server sends an query to the closest
  373.      routing server. When AimTraveler Routing Server receives the authenti-
  374.      cation  request,  it  first authenticates the AAS sending the request,
  375.      and if this is successful, it checks its authentication server  table.
  376.      If it is able to match the domain of the user to that of a "Home ISP",
  377.      then the Home ISP authentication server's routing information are sent
  378.      back  to  the local ISP's authentication server. Based on the informa-
  379.      tion received from the routing server,  the  AAS  makes  an  authenti-
  380.      cation   request   to  the  user's  Home ISP AAS for user id and pass-
  381.      word verification.
  382.  
  383.      If the user is a valid user, the Home ISP authentication server  sends
  384.      a  "permission  granted"  message back to the Local ISP authentication
  385.      server. The Local ISP authentication server then requests the  NAS  to
  386.      grant  the  user  a  dynamic  IP address from its address pool. If the
  387.      username or password is incorrect, the Home ISP AAS will send a rejec-
  388.      tion message to the Local ISP AAS, and the user will be dropped by the
  389.      NAS.
  390.  
  391.  
  392.  
  393.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 6]
  394.  
  395.  
  396.  
  397.  
  398.  
  399.      INTERNET-DRAFT                                            10 June 1997
  400.  
  401.  
  402.      If multiple routing servers are installed, and the query to the  first
  403.      routing  server  does not result in a match, the query is forwarded to
  404.      the next routing server. The server queries are cached on the  routing
  405.      servers,  improving speed for repeated queries. The cache is sustained
  406.      until a routing server table entry is updated or deleted.  Updating or
  407.      deleting  results  in  a  message  to  all neighbor routing servers to
  408.      delete their caches.
  409.  
  410.      The local authentication server also receives the accounting data from
  411.      the  NAS.  If  the  data  is for a regular customer login, the data is
  412.      written to the Local ISP AAS log file. If the data is for a  "roamer,"
  413.      the  data  is written to three places: the Local ISP AAS log file, the
  414.      Home ISP AAS log file, and the ARS log file.
  415.  
  416.      If the local ISP authentication server has caching turned on, then  it
  417.      will  cache  information  on Home ISP authentication server configura-
  418.      tions sent by the routing server. This means that if the  same  domain
  419.      is  queried  again,  the  local authentication server does not need to
  420.      query the routing server again. The local cache is  cleared  when  the
  421.      local  authentication server receives an update message from the rout-
  422.      ing server or system manager.
  423.  
  424.  
  425.      4.7.  NAS Configuration/Authorization
  426.  
  427.      AimTraveler is comprised  of  two  components,  a  Client(AAS)  and  a
  428.      Server(ARS).
  429.  
  430.      The  AimTraveler Client acts as the PPP dial-up authentication server.
  431.      When it detects an '@' sign in  the  userID  field,   it  queries  the
  432.      AimTraverler  Server  for  routing  information,  then  forwards   the
  433.      authentication request to user's home authentication server.  The Aim-
  434.      Traveler  Server, a centralized  routing server,  contains the  autho-
  435.      rized  ISP's  domain name, authentication servers and  other  informa-
  436.      tion.
  437.  
  438.      The  AimTraveler  currently supports  RADIUS  and  TACACS+,  and could
  439.      be extended  to  support  other  authentication  protocols.   It  also
  440.      receives all the accounting records, which are  subsequently  used  as
  441.      input data for billing.
  442.  
  443.      Since  ISPs' NAS devices may be configured differently, the attributes
  444.      returned by the home ISP AAS are discarded.
  445.  
  446.  
  447.      4.8.  Address assignment and routing
  448.  
  449.      All addresses in GRIC are assigned dynamically from within the address
  450.      pool of the local ISP.  Static addresses and  routed  LAN  connections
  451.      will  be  considered in the future, when GRIC offers corporate roaming
  452.      service.
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 7]
  460.  
  461.  
  462.  
  463.  
  464.  
  465.      INTERNET-DRAFT                                            10 June 1997
  466.  
  467.  
  468.      4.9.  Security
  469.  
  470.      The user's password is hashed with MD5  before  being  sent  from  the
  471.      Local  ISP  AAS  to  the  Home  ISP  AAS.  An encryption key is shared
  472.      between the AAS and ARS. The current version of AimTraveler  AAS  does
  473.      not support token cards or tunneling protocols.
  474.  
  475.  
  476.      4.10.  Accounting
  477.  
  478.      The AimTraveler Authentication Server (AAS) software can act as either
  479.      a RADIUS or TACACS+ accounting server.  When accounting information is
  480.      received  from  the  NAS,  the local AimTraveler Authentication Server
  481.      (AAS) sends accounting data (user name, domain name,  login  time)  to
  482.      both  the  Central  Accounting Server (part of the ARS) and the user's
  483.      Home ISP AimTraveler authentication server. In the case of  GRIC,  the
  484.      Central Accounting Server is run by AimQuest.
  485.  
  486.      The  data sent to the central accounting server and home ISP are iden-
  487.      tical except for the form of user id and time stamp.  For  a  traveler
  488.      whose  home ISP is in the US, but who is traveling in Japan, the Local
  489.      (Japanese) ISP  AimTraveler  authentication  server  will  receive  an
  490.      accounting  record timestamped with Japan time while the Home (US) ISP
  491.      AimTraveler authentication server will receive  an  accounting  record
  492.      timestamped with the appropriate US timezone.
  493.  
  494.      The  accounting  data includes 2 new attributes for settlement report-
  495.      ing:
  496.  
  497.      Attribute              Number   Type
  498.      ---------              ------   ----
  499.  
  500.      Roaming-Server-ID       101     string
  501.      Isp-ID                  102     string
  502.  
  503.      The Roaming-Server-ID attribute identifies the AAS sending the authen-
  504.      tication  request.   The  Isp-ID  attribute  identifies the local ISP.
  505.      Using this information the home ISP can track the  roaming  activities
  506.      of its users (where their users are logging in).
  507.  
  508.      The  AimTraveler  Server  running  at  AimQuest keeps a record of  all
  509.      roaming transactions, which are used as input to  the  settlement  and
  510.      billing  process.  At the end of each month, AimQuest provides a roam-
  511.      ing transaction summary to GRIC members using AIMS. The AIMS  software
  512.      is  configurable  so  that  it takes into account the settlement rules
  513.      agreed to by GRIC members.
  514.  
  515.  
  516.      5.  i-Pass implementation
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 8]
  526.  
  527.  
  528.  
  529.  
  530.  
  531.      INTERNET-DRAFT                                            10 June 1997
  532.  
  533.  
  534.      5.1.  Overview
  535.  
  536.      i-Pass Alliance Inc., based in Mountain View, California,  has  devel-
  537.      oped and operates a commercial authentication and settlement clearing-
  538.      house service which provides global roaming between  Internet  service
  539.      providers.  The service is fully operational.
  540.  
  541.      i-Pass Alliance Inc. has additional offices in Toronto, Singapore, and
  542.      London.   More  information   on   i-Pass   can   be   obtained   from
  543.      http://www.ipass.com.
  544.  
  545.      The  i-Pass network consists of a number of servers that provide real-
  546.      time authentication services to partner ISPs.  Authentication requests
  547.      and  accounting records for roaming users are encrypted and sent to an
  548.      i-Pass server where they are logged, and then forwarded to a home  ISP
  549.      for authentication and/or logging.
  550.  
  551.      Periodically,  i-Pass  reconciles  all  accounting  records, generates
  552.      billing statements, and acts as a  single  point  for  collecting  and
  553.      remitting payments.
  554.  
  555.      i-Pass  provides  its  service  only to ISPs and channel partners.  It
  556.      does not attempt to establish a business relationship with individual-
  557.      user customers of an ISP.
  558.  
  559.  
  560.      5.2.  Access Point Database (APD)
  561.  
  562.      i-Pass  maintains  a  list  of  roaming  access  points  in  an Oracle
  563.      database.  This list is searchable by geographical region using a  Web
  564.      browser, and may be downloaded in its entirety using FTP. The informa-
  565.      tion stored for each access point includes:
  566.  
  567.           Name of service provider
  568.           Country
  569.           State or Province
  570.           City or Region
  571.           Telephone number
  572.           Technical support phone number
  573.           Service types available
  574.           Technical information (help file)
  575.           Service pricing information
  576.  
  577.      The Access Point Database is maintained  by  i-Pass  staff,  based  on
  578.      input from i-Pass partners.
  579.  
  580.  
  581.      5.3.  Phone number presentation
  582.  
  583.      i-Pass  has  developed  a  Windows  application wth a simple point and
  584.      click interface called the "i-Pass Dial Wizard",  which  assists  end-
  585.      users in selecting and connecting to a local Internet access point.
  586.  
  587.  
  588.  
  589.  
  590.  
  591.      Aboba, Lu, Alsop, Ding & Wang                                 [Page 9]
  592.  
  593.  
  594.  
  595.  
  596.  
  597.      INTERNET-DRAFT                                            10 June 1997
  598.  
  599.  
  600.      The Dial Wizard allows users to first select the country in which they
  601.      are roaming.  A list of states, provinces, or  other  regions  in  the
  602.      selected  country  is then presented.  Finally a list of access points
  603.      within the state or province is presented.  The Dial  Wizard  displays
  604.      the  city  name,  modem  phone  number, and price information for each
  605.      access point within the state or region.
  606.  
  607.      When the user selects the desired access point, a Windows  95  "DialUp
  608.      Networking"  icon  is  created  for  that access point.  If there is a
  609.      login script associated with the access point,  the  DialUp  Scripting
  610.      tool  is  automatically  configured.   This means that end-users never
  611.      have to configure any login scripting requirements.
  612.  
  613.      The Dial Wizard has a built-in phonebook  containing  all  the  i-Pass
  614.      access  points.   The  phonebook may be automatically refreshed from a
  615.      master copy located onhe ISPs web site.
  616.  
  617.      The Dial Wizard is provided free of charge to i-Pass partners.  i-Pass
  618.      also  provides  the  i-Pass Dial Wizard Customization Kit which allows
  619.      ISP partners to generate customized versions of the Dial  Wizard  with
  620.      their own logo, etc.
  621.  
  622.  
  623.      5.4.  Authentication
  624.  
  625.      There  are  three  entities  involved  in  servicing an authentication
  626.      request:
  627.  
  628.  
  629.      Local ISP At the local ISP, the authentication server is  modified  to
  630.                recognize user IDs of the form username@auth_domain as being
  631.                remote authentication requests.   These  requests  are  for-
  632.                warded to an i-Pass server.
  633.  
  634.  
  635.      i-Pass Server
  636.                The  i-Pass server receives the authentication request, logs
  637.                it, and forwards it  to  the  home  ISP  identified  by  the
  638.                auth_domain portion of the user ID.
  639.  
  640.  
  641.      Home ISP  The  home  ISP receives the authentication request, performs
  642.                authentication using its normal authentication  method,  and
  643.                returns  a  YES/NO  response  to the i-Pass server, which in
  644.                turn forwards the reply to the originating ISP.
  645.  
  646.      i-Pass provides software components which run  on  the  authentication
  647.      servers  of  the  local and home ISPs.  Each member ISP must integrate
  648.      these components with the native authentication method being  used  by
  649.      the ISP.  To simplify this task, i-Pass has developed "drop-in" inter-
  650.      faces for the most commonly used authentication methods.  At the  date
  651.      of writing, the following interfaces are supported:
  652.  
  653.           Livingston RADIUS
  654.  
  655.  
  656.  
  657.      Aboba, Lu, Alsop, Ding & Wang                                [Page 10]
  658.  
  659.  
  660.  
  661.  
  662.  
  663.      INTERNET-DRAFT                                            10 June 1997
  664.  
  665.  
  666.           Ascend RADIUS
  667.           Merit RADIUS
  668.           TACACS+
  669.           Xylogics erpcd (Versions 10 and 11)
  670.  
  671.      A  generic interface is also provided which authenticates based on the
  672.      standard UNIX password file.  This is intended as a starting point for
  673.      ISPs using authentication methods other than those listed above.
  674.  
  675.      The  software  integration effort for a typical ISP is on the order of
  676.      2-5  man-days  including  testing.   Platforms   currently   supported
  677.      include:
  678.  
  679.           Solaris 2.5 (Sparc).LI
  680.           Solaris 2.5 (Intel)
  681.           BSDI
  682.           Digital Unix
  683.           Linux
  684.           HP/UX
  685.  
  686.      ISPs  may  chooe to provide authentication for their end-users roaming
  687.      elsewhere, but not to provide access points to the i-Pass network.  In
  688.      this  case  the software integration effort is greatly reduced and can
  689.      be as little as 1/2 a man-day.
  690.  
  691.  
  692.      5.5.  Accounting
  693.  
  694.      Accounting transactions are handled in the same way as  authentication
  695.      requests.  In addition to being logged at the i-Pass servers, account-
  696.      ing transactions are sent in real-time  to  the  home  ISP.   This  is
  697.      intended  to allow ISPs to update users' credit limit information on a
  698.      real-time basis (to the extent that this capability  is  supported  by
  699.      their billing and accounting systems).
  700.  
  701.      Settlement is performed monthly.  The settlement process involves cal-
  702.      culating the costs associated with each individual session, and aggre-
  703.      gating  them  for  each ISP.  A net amount is then calculated which is
  704.      either due from i-Pass to the ISP, or from the ISP to i-Pass,  depend-
  705.      ing on the actual usage pattern.
  706.  
  707.      The following reports are supplied to member ISPs:
  708.  
  709.           A Monthly Statement showing summaries of usage,
  710.           service provided, and any adjustments along with the
  711.           net amount owing.
  712.  
  713.           A Call Detail Report showing roaming usage by the ISP's
  714.           customers.
  715.  
  716.           A Service Provided report showing detailed usage of
  717.           the ISP's facilities by remote users.
  718.  
  719.      The above reports are generated as ASCII documents and are distributed
  720.  
  721.  
  722.  
  723.      Aboba, Lu, Alsop, Ding & Wang                                [Page 11]
  724.  
  725.  
  726.  
  727.  
  728.  
  729.      INTERNET-DRAFT                                            10 June 1997
  730.  
  731.  
  732.      to i-Pass partners electronically, either by e-mail or from  a  secure
  733.      area on the i-Pass web site. Hard-copy output is available on request.
  734.  
  735.      The Call Detail Report is also generated as  a  comma-delimited  ASCII
  736.      file  suitable  for  import  into the ISP's billing database. The Call
  737.      Detail Report will normally be used by the ISP  to  generate  end-user
  738.      billing for roaming usage.
  739.  
  740.  
  741.      5.6.  Security
  742.  
  743.      All  transactions  between  ISPs  and the i-Pass servers are encrypted
  744.      using the SSL protocol.  Public key certificates are verified at  both
  745.      the  client  and  server. i-Pass issues these certificates and acts as
  746.      the Cetificate Authority.
  747.  
  748.      Transactions are also verified based on a  number  of  other  criteria
  749.      such as source IP address.
  750.  
  751.  
  752.      5.7.  Operations
  753.  
  754.      i-Pass  operates  several authentication server sites.  Each site con-
  755.      sists of two redundant server systems located in secure facilities and
  756.      "close" to the Internet backbone.  The authentication server sites are
  757.      geographically distributed to minimize the possibility of failure  due
  758.      to natural disasters etc.
  759.  
  760.      i-Pass maintains a Network Operations Center in Mountain View which is
  761.      staffed on a 7x24 basis.  Its functions include monitoring the  i-Pass
  762.      authentication  servers,  monitoring authentication servers located at
  763.      partner facilities, and dealing with problem reports.
  764.  
  765.  
  766.      6.  ChinaNet implementation
  767.  
  768.      ChinaNet, owned by China Telecom, is China's  largest  Internet  back-
  769.      bone.  Constructed by Asiainfo, a Dallas based system integration com-
  770.      pany, it has 31  backbone  nodes  in  31  Chinese  provincial  capital
  771.      cities.  Each province is building its own provincial network, has its
  772.      own dialup servers, and administers its own user base.
  773.  
  774.      In order to allow hinaNet users to be able  to  access  nodes  outside
  775.      their  province  while traveling, a nationwide roaming system has been
  776.      implemented.  The roaming system was developed  by  AsiaInfo,  and  is
  777.      based on the RADIUS protocol.
  778.  
  779.      6.1.  Phone number presentation
  780.  
  781.      Since  China Telecom uses one phone number (163) for nationwide Inter-
  782.      net access, most cities have the same Internet access  number.  There-
  783.      fore a phone book is not currently required for the ChinaNet implemen-
  784.      tation. A web-based phone book will  be added  in  a  future  software
  785.      release  in  order to support nationwide ISP/CSP telephone numbers and
  786.  
  787.  
  788.  
  789.      Aboba, Lu, Alsop, Ding & Wang                                [Page 12]
  790.  
  791.  
  792.  
  793.  
  794.  
  795.      INTERNET-DRAFT                                            10 June 1997
  796.  
  797.  
  798.      HTTP server addresses.
  799.  
  800.  
  801.      6.2.  Connection management
  802.  
  803.      The current roaming client and server supports both PPP and SLIP.
  804.  
  805.  
  806.      6.3.  Address assignment and routing
  807.  
  808.      ChinaNet only supports  dynamic  IP  address  assignment  for  roaming
  809.      users. In addition, static addresses are supported for users authenti-
  810.      cating within their home province.
  811.  
  812.  
  813.      6.4.  Authentication
  814.  
  815.      When user accesses a local NAS,  it  provides  its  userID  either  as
  816.      "username"  or  "username@realm".   The  NAS  will pass the userID and
  817.      password to the RADIUS proxy/server.  If the  "username"  notation  is
  818.      used,  the  Radius  proxy/server  will assume that the user is a local
  819.      user and will handle local  authentication  accordingly.   If   "user-
  820.      name@realm"  is  used,  the  RADIUS  proxy/server will process it as a
  821.      roaming request.
  822.  
  823.      When the RADIUS proxy/server handles a request from a roaming user, it
  824.      will  first  check the cache to see if the user information is already
  825.      stored there. If there is a cache hit, the RADIUS proxy/server do  the
  826.      local  authentication  accordingly.  If it does not find user informa-
  827.      tion in its cache, it will act as a proxy, forwarding the  authentica-
  828.      tion  request  to the home RADIUS server.  When the home RADIUS server
  829.      responds, the local server will forward the response to the  NAS.   If
  830.      the  user  is authenticated by the home server, the local RADIUS proxy
  831.      will cache the user information for  a  period  of  time  (3  days  by
  832.      default).
  833.  
  834.      Caching  is  used to avoid frequent proxying of requests and responses
  835.      between the local RADIUS proxy and the home RADIUS  server.  When  the
  836.      home  RADIUS  server  sends  back a valid authentication response, the
  837.      local RADIUS proxy/server will cache the user information for a period
  838.      of  time  (3  days  by  default).   When  the  user next authenticates
  839.      directly against the home RADIUS server, the home RADIUS  server  will
  840.      send  a  request  to  the  local server or servers to clear the user's
  841.      information from the cache.
  842.  
  843.      6.4.1.  Extended hierarchy
  844.  
  845.      In  some  provinces,  the  local   telecommunications   administration
  846.      (Provincial  ISP)  further  delegates  control to county access nodes,
  847.      creating another level of hierarchy. This is done to improve scalabil-
  848.      ity  and  to avoid having the provincial ISP databases grow too large.
  849.      In the current implementation, each provincial ISP maintains  its  own
  850.      central  RADIUS  server,  including  information  on  all users in the
  851.      province, while county nodes maintain distributed RADIUS servers.  For
  852.  
  853.  
  854.  
  855.      Aboba, Lu, Alsop, Ding & Wang                                [Page 13]
  856.  
  857.  
  858.  
  859.  
  860.  
  861.      INTERNET-DRAFT                                            10 June 1997
  862.  
  863.  
  864.      intra-province  roaming  requests  the  local RADIUS proxy/server will
  865.      directly forward the request to the home RADIUS server.
  866.  
  867.      However, for inter-province roaming requests, the local RADIUS  server
  868.      does  not  forward  the  request  directly  to the home RADIUS server.
  869.      Instead, the request is forwarded to  the  central  provincial  RADIUS
  870.      server  for  the  home  province. This implementation is suitable only
  871.      when county level ISPs do not mind combining and  sharing  their  user
  872.      information.  In  this  instance, this is acceptable, since all county
  873.      level ISPs are part of China Telecom. In a future release, this multi-
  874.      layer hierarchy will be implemented using multi-layer proxy RADIUS, in
  875.      a manner more resembling DNS.
  876.  
  877.  
  878.      6.5.  Security
  879.  
  880.      Encryption is used between the local RADIUS proxy/server and the  home
  881.      RADIUS  server. Public/Private key encryption will be supported in the
  882.      next release. IP tunneling and token card support is under  considera-
  883.      tion.
  884.  
  885.  
  886.      6.6.  Accounting
  887.  
  888.      Accounting   information  is  transferred  between  the  local  RADIUS
  889.      accounting proxy/server and home RADIUS accounting server.  Every  day
  890.      each  node  sends a summary accounting information record to a central
  891.      server in order to support nationwide settlement. The  central  server
  892.      is  run  by  the  central  Data Communication Bureau of China Telecom.
  893.      Every month the central  server  sends  the  settlement  bill  to  the
  894.      provincial ISPs.
  895.  
  896.      6.7.  Inter-ISP/CSP roaming
  897.  
  898.      ChinaNet  supports both ISP and CSP (Content Service Provider) roaming
  899.      on its system. For example, Shanghai Online,  a  Web-based  commercial
  900.      content  service, uses RADIUS for authentication of ChinaNet users who
  901.      do not have a Shanghai Online account. In order to support  this,  the
  902.      Shanghai  Online  servers  function  as a RADIUS client authenticating
  903.      against the home RADIUS server. When users access a protected document
  904.      on  the HTTP server, they are prompted to send a username/password for
  905.      authentication. The user then responds with  their  userID  in  "user-
  906.      name@realm" notation.
  907.  
  908.      A  CGI  script on the HTTP server then acts as a RADIUS authentication
  909.      client, sending the request to the home RADIUS server. After the  home
  910.      RADIUS  server  responds, the CGI script passes the information to the
  911.      local authentication agent. From this  point  forward,  everything  is
  912.      taken care of by the local Web authentication mechanism.
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.      Aboba, Lu, Alsop, Ding & Wang                                [Page 14]
  922.  
  923.  
  924.  
  925.  
  926.  
  927.      INTERNET-DRAFT                                            10 June 1997
  928.  
  929.  
  930.      7.  Microsoft implementation
  931.  
  932.      Microsoft's  roaming  implementation was originally developed in order
  933.      to support the Microsoft Network  (MSN),  which  now  offers  Internet
  934.      access in seven countries: US, Canada, France, Germany, UK, Japan, and
  935.      Australia.  In each of these countries, service is offered in coopera-
  936.      tion  with  access  partners.   Since users are able to connect to the
  937.      access partner networks while maintaining a customer-vendor  relation-
  938.      ship with MSN, this implementation fits within the definition of roam-
  939.      ing as used in this document.
  940.  
  941.  
  942.      7.1.  Implementation overview
  943.  
  944.      The first version of the Microsoft roaming software  was  deployed  by
  945.      the  MSN  partners in April, 1996.  This version included a Phone Book
  946.      manager  tool  running  under  Windows  95,  as  well  as   a   RADIUS
  947.      server/proxy  implementation running under Windows NT; TACACS+ is cur-
  948.      rently not supported.  Additional  components  now  under  development
  949.      include a Connection Manager client for Windows 95 as well as an HTTP-
  950.      based phone book server for Windows NT. The Phone Book manager tool is
  951.      also  being upgraded to provide for more automated phone book compila-
  952.      tion.
  953.  
  954.  
  955.      7.2.  Phone number presentation
  956.  
  957.      The Connection Manager is responsible for the presentation and  updat-
  958.      ing  of  phone numbers, as well as for dialing and making connections.
  959.      In order to select phone  numbers,  users  are  asked  to  select  the
  960.      desired country and region/state.  Phone numbers are then presented in
  961.      the area selected.  The primary numbers are those from the users  ser-
  962.      vice  provider  which  match  the service type (Analog, ISDN, Analog &
  963.      IDN), country and region/state selected. The other  numbers  (selected
  964.      clicking  on  the  More  button) are those for other service providers
  965.      that have a roaming agreement with the users service provider.
  966.  
  967.  
  968.      7.2.1.  Cost data
  969.  
  970.      Cost data is not presented to users along with the phone numbers. How-
  971.      ever,  such  information may be made available by other means, such as
  972.      via a Web page.
  973.  
  974.  
  975.      7.2.2.  Default phone book format
  976.  
  977.      The Connection Manager supports the ability  to  customize  the  phone
  978.      book  format,  and it is expected that many ISPs will make use of this
  979.      capability. However, for those who wish to use it "off  the  shelf"  a
  980.      default  phone book format is provided. The default phone book is com-
  981.      prised of several files, including:
  982.  
  983.           Service profile
  984.  
  985.  
  986.  
  987.      Aboba, Lu, Alsop, Ding & Wang                                [Page 15]
  988.  
  989.  
  990.  
  991.  
  992.  
  993.      INTERNET-DRAFT                                            10 June 1997
  994.  
  995.  
  996.           Phone Book
  997.           Region file
  998.  
  999.      The service profile provides information on a given service, which may
  1000.      be  an  isolated Internet Service Provider, or may represent a roaming
  1001.      consortium. The service profile, which is in .ini file format, is com-
  1002.      prised of the following information:
  1003.  
  1004.           The name of the service
  1005.           The filename of the service's big icon
  1006.           The filename of the service's little icon
  1007.           A description of the service
  1008.           The service phone book filename
  1009.           The service phone book version number
  1010.           The service regions file
  1011.           The URL of the service phone book server
  1012.           The prefix used by the service (i.e. "MSN/aboba")
  1013.           The suffix or domain used by the service (i.e. "aboba@msn.com")
  1014.           Whether the user name is optional for the service
  1015.           Whether the password is optional for the service
  1016.           Maximum length of the user name for the service
  1017.           Maximum length of the password for the service
  1018.           Information on service password handling (lowercase, mixed case, etc.)
  1019.           Number of redials for this service
  1020.           Delay between redials for this service
  1021.           References to other service providers that have roaming agreements
  1022.           The service profile filenames for each of the references
  1023.           Mask and match phone book filters for each of the references
  1024.                  (these are 32 bit numbers that are applied against the capability flags in the phone book)
  1025.           The dial-up connection properties configuration
  1026.                (this is the DUN connectoid name)
  1027.  
  1028.  
  1029.      The  phone  book  file  is a comma delimited ASCII file containing the
  1030.      following data:
  1031.  
  1032.           Unique number identifying a particular record (Index)
  1033.           Country ID
  1034.           A zero-base index into the region file
  1035.           City
  1036.           Area code
  1037.           Local phone number
  1038.           Minimum Speed
  1039.           Maximum speed
  1040.           Capability Flags:
  1041.                Bit 0: 0=Toll, 1=Toll free
  1042.                Bit 1: 0=X25, 1=IP
  1043.                Bit 2: 0=Analog, 1=No analog support
  1044.                Bit 3: 0=no ISDN support, 1=ISDN
  1045.                Bit 4: 0
  1046.                Bit 5: 0
  1047.                Bit 6: 0=No Internet access, 1=Internet access
  1048.                Bit 7: 0=No signup access, 1=Signup access
  1049.                Bit 8-31: reserved
  1050.  
  1051.  
  1052.  
  1053.      Aboba, Lu, Alsop, Ding & Wang                                [Page 16]
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.      INTERNET-DRAFT                                            10 June 1997
  1060.  
  1061.  
  1062.           The filename of the dialup network file
  1063.              (typically refers to a script associated with the number)
  1064.  
  1065.  
  1066.      A sample phone book file is shown below:
  1067.  
  1068.           65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
  1069.           200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
  1070.           200133,1,1,Birmingham,205,5551212,9600,28800,0,10,
  1071.           130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile
  1072.           65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile
  1073.  
  1074.  
  1075.      7.2.3.  Additional attributes
  1076.  
  1077.      As described previously, it is likely  that  some  ISPs  will  require
  1078.      additional phone number attributes or provider information beyond that
  1079.      supported in the default phone book format.   Attributes  of  interest
  1080.      may  vary between providers, or may arise as a result of the introduc-
  1081.      tion of new technologies.  As  a  result,  the  set  of  phone  number
  1082.      attributes  is  likely  to  evolve over time, and extensibility in the
  1083.      phone book format is highly desirable.
  1084.  
  1085.      For example, in addition to the attributes  provided  in  the  default
  1086.      phone book, the following additional attributes have been requested by
  1087.      customers:
  1088.  
  1089.           Multicast support flag
  1090.           External/internal flag (to differentiate display between the
  1091.                "internal" or "other" list box)
  1092.           Priority  (for control of presentation order)
  1093.           Modem protocol capabilities (V.34, V.32bis, etc.)
  1094.           ISDN protocol capabilities (V.110, V.120, etc.)
  1095.           No password flag (for numbers using telephone-based billing)
  1096.           Provider name
  1097.  
  1098.  
  1099.      7.2.4.  Addition of information on providers
  1100.  
  1101.      The default phone book does not provide a  mechanism  for  display  of
  1102.      information on the individual ISPs within the roaming consortium, only
  1103.      for the consortium as a whole. For example, the  provider  icons  (big
  1104.      and  little) are included in the service profile. The service descrip-
  1105.      tion information is expected to contain the customer  support  number.
  1106.      However,  this  information  cannot be provided on an individual basis
  1107.      for each of the members of a roaming consortium.  Additional  informa-
  1108.      tion useful on a per-provider basis would include:
  1109.  
  1110.           Provider voice phone number
  1111.           Provider icon
  1112.           Provider fax phone number
  1113.           Provider customer support phone number
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.      Aboba, Lu, Alsop, Ding & Wang                                [Page 17]
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.      INTERNET-DRAFT                                            10 June 1997
  1126.  
  1127.  
  1128.      7.3.  Phone number exchange
  1129.  
  1130.      Currently  phone  number  exchange  is not supported by the phone book
  1131.      server. As a result, in the MSN implementation, phone number  exchange
  1132.      is  handled  manually.   As new POPs come online, the numbers are for-
  1133.      warded to MSN, which tests the numbers and approves them for  addition
  1134.      to  the phone book server. Updated phone books are produced and loaded
  1135.      on the phone book server on a weekly basis.
  1136.  
  1137.  
  1138.      7.4.  Phone book compilation
  1139.  
  1140.      The Phone Book Manager tool was created in order to make it easier for
  1141.      the  access  partners  to create and update their phone books. It sup-
  1142.      ports addition, removal, and editing of phone numbers, generating both
  1143.      a new phone book, as well as associated difference files.
  1144.  
  1145.      With  version 1 of the Phone Book Administration tool, phone books are
  1146.      compiled manually, and represent a concatenation of available  numbers
  1147.      from  all  partners,  with no policy application.  With version 1, the
  1148.      updates are prepared by the partners and forwarded to MSN, which tests
  1149.      the  numbers  and  approves  them  for addition to the phone book. The
  1150.      updates are then concatenated together to form the global update file.
  1151.  
  1152.      The  new  version of the Phone Book Administration tool automates much
  1153.      of the phone book compilation process, making it  possible  for  phone
  1154.      book  compilation  to be decentralized with each partner running their
  1155.      own phone book server. Partners can then maintain and test their indi-
  1156.      vidual phone books and post them on their own Phone Book Server.
  1157.  
  1158.  
  1159.      7.5.  Phone book update
  1160.  
  1161.  
  1162.      There  is  a  mechanism  to  download phone book deltas, as well as to
  1163.      download arbitrary executables which can perform more  complex  update
  1164.      processing.   Digital  signatures  are only used on the downloading of
  1165.      executables, since only these represent a security threat -  the  Con-
  1166.      nection Manager client does not check for digital signatures on deltas
  1167.      because bogus deltas can't really cause any harm.
  1168.  
  1169.  
  1170.      The Connection Manager updates the phone book each time the user  logs
  1171.      on.  This  is  accomplished  via an HTTP GET request to the phone book
  1172.      server. When the server is examining the request,  it  can  take  into
  1173.      account  things like the OS version on the client, the language on the
  1174.      client, the version of Connection Manager on the client, and the  ver-
  1175.      sion  of  the  phone book on the client, in order to determine what it
  1176.      wants to send back.
  1177.  
  1178.      In the GET response, the phone book server responds with  the  differ-
  1179.      ence  files  necessary to update the client's phone book to the latest
  1180.      version. The client then builds the new  phone  book  by  successively
  1181.      applying  these  difference files.  This process results in the update
  1182.  
  1183.  
  1184.  
  1185.      Aboba, Lu, Alsop, Ding & Wang                                [Page 18]
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.      INTERNET-DRAFT                                            10 June 1997
  1192.  
  1193.  
  1194.      of the entire phone book, and is simple enough to allow it to be  eas-
  1195.      ily  implemented  on a variety of HTTP servers, either as a CGI script
  1196.      or (on NT) as an ISAPI DLL.
  1197.  
  1198.      The difference files used in the default phone book consist of a  list
  1199.      of phone book entries, each uniquely identified by their index number.
  1200.      Additions consist of phone book entries with all the information filed
  1201.      in;  deletions are signified by entries with all entries zeroed out. A
  1202.      sample difference file is shown below:
  1203.  
  1204.           65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
  1205.           200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
  1206.           200133,0,0,0,0,0,0,0,0,0
  1207.           130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile
  1208.           65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile
  1209.  
  1210.  
  1211.      7.6.  Connection management
  1212.  
  1213.      The Connection Manager can support any protocol which can  be  config-
  1214.      ured via use of Windows Dialup Networking, including PPP and SLIP run-
  1215.      ning over IP.  The default setting is for the IP address  as  well  as
  1216.      the  DNS  server  IP address to be assigned by the NAS. The DNS server
  1217.      assignment capability is described in [1].
  1218.  
  1219.  
  1220.      7.7.  Authentication
  1221.  
  1222.      The Connection Manager client and  RADIUS  proxy/server  both  support
  1223.      suffix  style  notation  (i.e.  "aboba@msn.com"),  as well as a prefix
  1224.      notation ("MSN/aboba").
  1225.  
  1226.      The prefix notation was developed for use with NAS devices with  small
  1227.      maximum userID lengths.  For these devices the compactness of the pre-
  1228.      fix notation significantly increases the number of  characters  avail-
  1229.      able  for  the  userID field.  However, as an increasing number of NAS
  1230.      devices are now supporting 253 octet userIDs (the maximum supported by
  1231.      RADIUS) the need for prefix notation is declining.
  1232.  
  1233.      After receiving the userID from the Connection Manager client, the NAS
  1234.      device passes the userID/domain and password information  (or  in  the
  1235.      case of CHAP, the challenge and the response) to the RADIUS proxy. The
  1236.      RADIUS proxy then checks if the domain is authorized  for  roaming  by
  1237.      examining  a  static  configuration file. If the domain is authorized,
  1238.      the RADIUS proxy then forwards the request to the  appropriate  RADIUS
  1239.      server. The domain to server mapping is also made via a static config-
  1240.      uration file.
  1241.  
  1242.      While static configuration files work well for small  roaming  consor-
  1243.      tia,  for  larger  consortia static configuration will become tedious.
  1244.      Potentially more scalable solutions include use of DNS SRV records for
  1245.      the domain to RADIUS server mapping.
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.      Aboba, Lu, Alsop, Ding & Wang                                [Page 19]
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.      INTERNET-DRAFT                                            10 June 1997
  1258.  
  1259.  
  1260.      7.8.  NAS configuration/authorization
  1261.  
  1262.      Although  the  attributes  returned by the home RADIUS server may make
  1263.      sense to home NAS devices, the local NAS  may  be  configured  differ-
  1264.      ently, or may be from a different vendor.  As a result, it may be nec-
  1265.      essary for the RADIUS proxy to edit the attribute set returned by  the
  1266.      home  RADIUS server, in order to provide the local NAS with the appro-
  1267.      priate configuration information.  The editing  occurs  via  attribute
  1268.      discard and insertion of attributes by the proxy.
  1269.  
  1270.      Alternatively,  the home RADIUS server may be configured not to return
  1271.      any network-specific attributes, and to allow these to be inserted  by
  1272.      the local RADIUS proxy.
  1273.  
  1274.      Attributes most likely to cause conflicts include:
  1275.  
  1276.           Framed-IP-Address
  1277.           Framed-IP-Netmask
  1278.           Framed-Routing
  1279.           Framed-Route
  1280.           Filter-Id
  1281.           Vendor-Specific
  1282.           Session-Timeout
  1283.           Idle-Timeout
  1284.           Termination-Action
  1285.  
  1286.      Conflicts  relating to IP address assignment and routing are very com-
  1287.      mon.  Where dynamic address assignment is used,  an  IP  address  pool
  1288.      appropriate  for  the  local NAS can be substituted for the IP address
  1289.      pool designated by the home RADIUS server.
  1290.  
  1291.      However, not all address conflicts can be  resolved  by  editing.   In
  1292.      some  cases,  (i.e., assignment of a static network address for a LAN)
  1293.      it may not be possible for the local NAS to  accept  the  home  RADIUS
  1294.      server's  address assignment, yet the roaming hosts may not be able to
  1295.      accept an alternative assignment.
  1296.  
  1297.      Filter IDs also pose a problem. It is possible that the local NAS  may
  1298.      not  implement  a  filter corresponding to that designated by the home
  1299.      RADIUS server. Even if an equivalent filter is implemented,  in  order
  1300.      to  guarantee  correct operation, the proxy's configuration must track
  1301.      changes in the filter configurations of each of  the  members  of  the
  1302.      roaming  consortium.  In  practice  this  is  likely to be unworkable.
  1303.      Direct upload of  filter  configuration  is  not  a  solution  either,
  1304.      because of the wide variation in filter languages supported in today's
  1305.      NAS devices.
  1306.  
  1307.      Since by definition vendor specific attributes have  meaning  only  to
  1308.      devices created by that vendor, use of these attributes is problematic
  1309.      within a heterogeneous roaming consortium. While  it  is  possible  to
  1310.      edit  these  attributes,  or  even to discard them or allow them to be
  1311.      ignored, this may not always be acceptable. In cases where vendor spe-
  1312.      cific  attributes relate to security, it may not be acceptable for the
  1313.      proxy to modify or  discard  these  attributes;  the  only  acceptable
  1314.  
  1315.  
  1316.  
  1317.      Aboba, Lu, Alsop, Ding & Wang                                [Page 20]
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.      INTERNET-DRAFT                                            10 June 1997
  1324.  
  1325.  
  1326.      action  may  be  for  the  local NAS to drop the user.  Unfortunately,
  1327.      RADIUS does not distinguish between mandatory and optional attributes,
  1328.      so  that  there  is  no  way  for  the proxy to take guidance from the
  1329.      server.
  1330.  
  1331.      Conflicts over session or idle timeouts may result if since  both  the
  1332.      local  and  home  ISP feel the need to adjust these parameters.  While
  1333.      the home ISP may wish to adjust the  parameter  to  match  the  user's
  1334.      software, the local ISP may wish to adjust it to match its own service
  1335.      policy. As long as the desired parameters do not differ too greatly, a
  1336.      compromise is often possible.
  1337.  
  1338.  
  1339.      7.9.  Address assignment and routing
  1340.  
  1341.      While the Connection Manager software supports both static and dynamic
  1342.      address assignment, in  the  MSN  implementation,  all  addresses  are
  1343.      dynamically assigned.
  1344.  
  1345.      However,  selected  partners also offer LAN connectivity to their cus-
  1346.      tomers, usually via static address assignment. However, these accounts
  1347.      do  not  have  roaming  privileges  since no mechanism has been put in
  1348.      place for allowing these static  routes  to  move  between  providers.
  1349.      Users  looking  to  do LAN roaming between providers are encouraged to
  1350.      select a router supporting Network Address Translation (NAT). NAT ver-
  1351.      sions  implemented  in several low-end routers are compatible with the
  1352.      dynamic addressing used on MSN, as well as supporting DHCP on the  LAN
  1353.      side.
  1354.  
  1355.  
  1356.      7.10.  Security
  1357.  
  1358.      The RADIUS proxy/server implementation does not support token cards or
  1359.      tunneling protocols.
  1360.  
  1361.  
  1362.      7.11.  Accounting
  1363.  
  1364.      In the MSN roaming implementation, the accounting data  exchange  pro-
  1365.      cess  is  specified  in  terms  of  an accounting record format, and a
  1366.      method by which the records are transferred from the partners to  MSN,
  1367.      which acts as the settlement agent.  Defining the interaction in terms
  1368.      of record formats and transfer protocols implies that the partners  do
  1369.      not  communicate with the settlement agent using NAS accounting proto-
  1370.      cols.  As a result, accounting protocol  interoperability  is  not  be
  1371.      required.
  1372.  
  1373.      However,  for this advantage to be fully realized, it is necessary for
  1374.      the accounting record format to be  extensible.  This  makes  it  more
  1375.      likely that the format can be adapted for use with the wide variety of
  1376.      accounting protocols in current use (such as SNMP, syslog, RADIUS, and
  1377.      TACACS+), as well as future protocols. After all, if the record format
  1378.      cannot express the metrics provided by a particular partner's account-
  1379.      ing  protocol,  then  the  record format will not be of much use for a
  1380.  
  1381.  
  1382.  
  1383.      Aboba, Lu, Alsop, Ding & Wang                                [Page 21]
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.      INTERNET-DRAFT                                            10 June 1997
  1390.  
  1391.  
  1392.      heterogeneous roaming consortium.
  1393.  
  1394.  
  1395.      7.11.1.  Accounting record format
  1396.  
  1397.      The Microsoft RADIUS proxy/server supports the  ability  to  customize
  1398.      the  accounting  record format, and it is expected that some ISPs will
  1399.      make use of this capability. However for those who want to use it "off
  1400.      the  shelf"  a  default  accounting  record  format  is  provided. The
  1401.      accounting record includes information provided by RADIUS:
  1402.  
  1403.           User Name (String; the user's ID, including prefix or suffix)
  1404.           NAS IP address (Integer; the IP address of the user's NAS)
  1405.           NAS Port (Integer; identifies the physical port on the NAS)
  1406.           Service Type (Integer; identifies the service provided to the user)
  1407.           NAS Identifier (Integer; unique identifier for the NAS)
  1408.           Status Type (Integer; indicates session start and stop,
  1409.              as well as accounting on and off)
  1410.           Delay Time (Integer; time client has been trying to send)
  1411.           Input Octets (Integer; in stop record, octets received from port)
  1412.           Output Octets (Integer; in stop record, octets sent to port)
  1413.           Session ID (Integer; unique ID linking start and stop records)
  1414.           Authentication (Integer; indicates how user was authenticated)
  1415.           Session Time (Integer; in stop record, seconds of received service)
  1416.           Input Packets (Integer; in stop record, packets received from port)
  1417.           Output Packets (Integer; in stop record, packets sent to port)
  1418.           Termination Cause (Integer; in stop record, indicates termination cause)
  1419.           Multi-Session ID (String; for linking of multiple related sessions)
  1420.           Link Count (Integer; number of links up when record was generated)
  1421.           NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
  1422.  
  1423.      However, since this default format is not extensible, it cannot easily
  1424.      be  adapted to protocols other than RADIUS, services other than dialup
  1425.      (i.e. dedicated connections) or rated events  (i.e.  file  downloads).
  1426.      This  is  a  serious  limitation,  and  as  a  result,  customers have
  1427.      requested a more general accounting record format.
  1428.  
  1429.  
  1430.      7.11.2.  Transfer mechanism
  1431.  
  1432.      Prior to being transferred, the accounting records are  compressed  so
  1433.      as  to  save bandwidth.  The transfer of accounting records is handled
  1434.      via FTP, with the transfer being initiated  by  the  receiving  party,
  1435.      rather  than by the sending party.  A duplicate set of records is kept
  1436.      by the local ISP for verification purposes.
  1437.  
  1438.  
  1439.      8.  Merit Network Implementation
  1440.  
  1441.  
  1442.      8.1.  Overview
  1443.  
  1444.      MichNet is a regional IP backbone network operated within the state of
  1445.      Michigan  by Merit Network, Inc., a nonprofit corporation based in Ann
  1446.  
  1447.  
  1448.  
  1449.      Aboba, Lu, Alsop, Ding & Wang                                [Page 22]
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.      INTERNET-DRAFT                                            10 June 1997
  1456.  
  1457.  
  1458.      Arbor, Michigan. Started in 1966, MichNet currently provides  backbone
  1459.      level  Internet connectivity and dial-in IP services to its member and
  1460.      affiliate universities, colleges, K-12 schools, libraries,  government
  1461.      institutions,  other  nonprofit organizations, and commercial business
  1462.      entities.
  1463.  
  1464.      As of May 1, 1997, MichNet had 11  members  and  405  affiliates.  Its
  1465.      shared dial-in service operated 133 sites in Michigan and one in Wash-
  1466.      ington, D.C, with 4774 dial-in lines.  Additional  dial-in  lines  and
  1467.      sites are being installed daily.
  1468.  
  1469.      MichNet  also  provides national and international dial-in services to
  1470.      its members and affiliates through an 800 number  and  other  external
  1471.      services contracting with national and global service providers.
  1472.  
  1473.      The  phone  numbers  of all MichNet shared dial-in sites are published
  1474.      both on the Merit web site and in the MichNet newsletters. Merit  also
  1475.      provides  links  to  information  about the national and international
  1476.      service sites through their  respective  providers'  web  sites.  Such
  1477.      information     can    be    found    at    http://www.merit.edu/mich-
  1478.      net/shared.dialin/.
  1479.  
  1480.  
  1481.      8.1.1.  MichNet State-Wide Shared Dial-In Services
  1482.  
  1483.      Each MichNet shared dial-in service site is owned  and  maintained  by
  1484.      either  Merit or by a member or affiliate organization. All sites must
  1485.      support PPP and Telnet connections.
  1486.  
  1487.      Each organization participating  in  the  shared  dial-in  service  is
  1488.      assigned  a  realm-name.   Typically  the realm-name resembles a fully
  1489.      qualified domain name. Users  accessing  the  shared  dial-in  service
  1490.      identify  themselves  by  using  a  MichNet AccessID which consists of
  1491.      their local id concatenated with "@" followed by the realm-name - e.g.
  1492.      user@realm
  1493.  
  1494.      Merit  operates  a set of Authentication, Authorization and Accounting
  1495.      (AAA) servers supporting the RADIUS protocol  which  are  called  core
  1496.      servers.  The  core  servers support all the dial-in service sites and
  1497.      act as proxy servers to other AAA servers running at the participating
  1498.      organizations. For security reasons, Merit staff run all core servers;
  1499.      in particular, the user password is in the clear when the  proxy  core
  1500.      server decodes an incoming request and then re-encodes it and forwards
  1501.      it out again,
  1502.  
  1503.      The core servers also  enforce  a  common  policy  among  all  dial-in
  1504.      servers.  The  most  important  policy is that each provider of access
  1505.      must make dial-in ports available to others when  the  provider's  own
  1506.      users do not have a need for them. To implement this policy, the proxy
  1507.      server distinguishes between realms that are owners  and  realms  that
  1508.      are guests.
  1509.  
  1510.      One  piece  of the policy determining whether the provider's organiza-
  1511.      tion has need of the port, is implemented by  having  the  proxy  core
  1512.  
  1513.  
  1514.  
  1515.      Aboba, Lu, Alsop, Ding & Wang                                [Page 23]
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.      INTERNET-DRAFT                                            10 June 1997
  1522.  
  1523.  
  1524.      server track the realms associated with each of the sessions connected
  1525.      at a particular huntgroup. If there are few ports available (where few
  1526.      is  determined by a formula) then guests are denied access. Guests are
  1527.      also assigned a time limit and their  sessions  are  terminated  after
  1528.      some  amount  of time (currently one hour during prime time, two hours
  1529.      during non-prime time).
  1530.  
  1531.      The other part of the policy is to limit the number of guests that are
  1532.      allowed to connect.  This is done by limiting the number of simultane-
  1533.      ous guest sessions for realms.  Each realm is allocated  a  number  of
  1534.      "simultaneous  access  tokens" - SATs.  When a guest session is autho-
  1535.      rized the end server for the realm decrements the count  of  available
  1536.      SATs,  and  when  the session is terminated the count of SATs is incr-
  1537.      mented.  A Merit specific attribute is added to  the  request  by  the
  1538.      core  if the session will be a "guest" and will require a SAT. The end
  1539.      server must include a reply with an attribute containing the  name  of
  1540.      the  "token pool" from which the token for this session is taken.  The
  1541.      effect of this is to limit the number of guests connected to the  net-
  1542.      work to the total number of tokens allocated to all realms.
  1543.  
  1544.      Each  realm is authenticated and authorized by its own AAA server. The
  1545.      proxy core servers forward requests to the appropriate server based on
  1546.      a  configuration file showing where each realm is to be authenticated.
  1547.      Requests from realms not in the configuration are dropped.
  1548.  
  1549.      The Merit AAA server software supports  this  policy.  Merit  provides
  1550.      this  software  to member and affiliate organizations. The software is
  1551.      designed to work with many existing authentication  servers,  such  as
  1552.      Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS.  This enables
  1553.      most institutions to utilize the authentication mechanism they have in
  1554.      place.
  1555.  
  1556.  
  1557.      8.1.2.  MichNet National and International Dial-In Services
  1558.  
  1559.      In addition to the MichNet shared dial-in service, Merit also provides
  1560.      access from locations outside  of  Michigan  by  interconnecting  with
  1561.      other dial-in services. These services are typically billed by connect
  1562.      time. Merit acts as the accounting agent between its member and affil-
  1563.      iate organizations and the outside service provider.
  1564.  
  1565.      The services currently supported are a national 800 number and service
  1566.      via the ADP/Autonet dial-in network. Connection with  IBM/Advantis  is
  1567.      being tested, and several other service interconnects are being inves-
  1568.      tigated.
  1569.  
  1570.      Calls placed by a Merit member/affiliate user to these external  dial-
  1571.      in services are authenticated by having each of those services forward
  1572.      RADIUS authentication requests and  accounting  messages  to  a  Merit
  1573.      proxy core server. The core forwards the requests to the member/affil-
  1574.      iate server for approval. Session records are logged at the Merit core
  1575.      server and at the member/affiliate server. Merit bills members/affili-
  1576.      ates monthly, based on processing of the accounting logs. The  members
  1577.      and affiliates are responsible for rebilling their users.
  1578.  
  1579.  
  1580.  
  1581.      Aboba, Lu, Alsop, Ding & Wang                                [Page 24]
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.      INTERNET-DRAFT                                            10 June 1997
  1588.  
  1589.  
  1590.      The  Merit  AAA software supports the ability to request positive con-
  1591.      firmation of acceptance of charges, and provides tools for  accumulat-
  1592.      ing and reporting on use by realm and by user.
  1593.  
  1594.  
  1595.      8.2.  Authentication and Authorization
  1596.  
  1597.      Authentication  of a Telnet session is supported using the traditional
  1598.      id and password method, with the id being a MichNet  AccessID  of  the
  1599.      form user@realm, while a PPP session may be authenticated either using
  1600.      an AccessID and password within a script, or using  PAP.  Support  for
  1601.      challenge/response authentication mechanisms using EAP is under devel-
  1602.      opment.
  1603.  
  1604.      When  a  user dials into a MichNet shared dial-in port, the NAS  sends
  1605.      an  Access-Request  to  a  core  AAA server using the RADIUS protocol.
  1606.      First the core server applies any appropriate huntgroup  access  poli-
  1607.      cies to the request. If the Request fails the policy check, an Access-
  1608.      Reject is returned to the NAS.  Otherwise, the core server forwards it
  1609.      to  the  user's  home  authentication  server  according to the user's
  1610.      realm.  The home authentication server  authenticates  and  authorizes
  1611.      the access request.  An Access-Accept or Access-Reject is sent back to
  1612.      the core server.  If an Access-Accept is sent, the  home  server  will
  1613.      create  a  dial-in  session identifier which is unique to this session
  1614.      and insert it in a Class attribute in  the  Access-Accept.   The  core
  1615.      server  looks  at  the  request  and the response from the home server
  1616.      again and decides either to accept or reject the request. Finally, the
  1617.      core server sends either an Access-Accept or Access-Reject to the NAS.
  1618.  
  1619.      When a user dials into a contracted ISP's huntgroup (MichNet  National
  1620.      and  International  Service), the ISP  sends  a RADIUS  access request
  1621.      to a Merit core server. The rest of the authentication and  authoriza-
  1622.      tion  path  is  the  same  as in the  shared  dial-in service,  except
  1623.      that no huntgroup access policy is  applied  but  a  Huntgroup-Service
  1624.      attribute  is  sent  to  the home authentication server with its value
  1625.      being the name of the service, and a copy of  the  attribute  must  be
  1626.      returned by the home server with a flag appended to the original value
  1627.      to indicate a positive authorization of user access to  the  specified
  1628.      service.
  1629.  
  1630.      The MichNet shared dial-in service typically requires authorization of
  1631.      some sort, for example, a user dialing into a  huntgroup  as  a  guest
  1632.      must  be  authorized with a token from the user's realm. Participating
  1633.      institutions have control in defining authorization  rules.  Currently
  1634.      authorization  may  be  done using any combination of the user's group
  1635.      status and user's account status. A set of programming  interfaces  is
  1636.      also provided for incorporating new authorization policies.
  1637.  
  1638.  
  1639.      8.3.  Accounting
  1640.  
  1641.      In  the  Merit  AAA  server, a session is defined as starting from the
  1642.      moment the user connects to the NAS, and ending at the point when  the
  1643.      user disconnects. During the course of a session, both the core server
  1644.  
  1645.  
  1646.  
  1647.      Aboba, Lu, Alsop, Ding & Wang                                [Page 25]
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.      INTERNET-DRAFT                                            10 June 1997
  1654.  
  1655.  
  1656.      and the home server maintain status  information  about  the  session.
  1657.      This  allows  the  AAA  servers to apply policies based on the current
  1658.      status, e.g. limit guest  access  by  realm  to  number  of  available
  1659.      tokens, or to limit number of simultaneous sessions for a given Acces-
  1660.      sID. Information such as whether the session is for a  guest,  whether
  1661.      it used a token, and other information is included with the accounting
  1662.      stop information when it is logged. Merit has made enhancements to the
  1663.      RADIUS  protocol, that are local to the AAA server, to support mainte-
  1664.      nance of session status information.
  1665.  
  1666.      When a user session is successfully authenticated, the NAS sends out a
  1667.      RADIUS  accounting  start  request to the core server. The core server
  1668.      forwards that request to the  user's  home  server.  The  home  server
  1669.      updates  the  status of the session and then responds to the core. The
  1670.      core server in turn responds to  the  NAS.  In  the  accounting  Start
  1671.      request,  a NAS conforming to the RADIUS specification must return the
  1672.      Class attribute and value it received in  the  Access-Accept  for  the
  1673.      session,  thus  sending back the dial-in session identifier created by
  1674.      the session's home server.
  1675.  
  1676.      When a user ends a session, an accounting stop request is sent through
  1677.      the  same  path.   the  same  path.  The dial-in session identifier is
  1678.      again returned by the NAS, providing a means of uniquely identifying a
  1679.      session.  By  configuring  the finite state machine in each of the AAA
  1680.      servers, any accounting requests may be logged by any of  the  servers
  1681.      where the accounting requests are received.
  1682.  
  1683.      Because  the  same  session  logs are available on every server in the
  1684.      path of a session's authorization  and  accounting  message,  problems
  1685.      with  reconciliation  of specific sessions may be resolved easily. For
  1686.      the shared dial-in service, there are no  usage  charges.   Merit  has
  1687.      tools  to  verify  that organizations do not authorize more guest ses-
  1688.      sions than  the  number  of  SATs  allocated to the organization.  For
  1689.      surcharged sessions, Merit sends each organization a summary bill each
  1690.      month. Files with detail session records  are  available  for  problem
  1691.      resolution.  Each  organization  is  responsible  for  billing its own
  1692.      users, and should have the same session records as  are  collected  by
  1693.      Merit.
  1694.  
  1695.      Merit  receives a monthly invoice from other dial-in service providers
  1696.      and pays them directly, after first verifying that the charges  corre-
  1697.      spond to the session records logged by Merit.
  1698.  
  1699.  
  1700.      8.4.  Software and Development
  1701.  
  1702.      Merit  has  developed the AAA server software which supports the above
  1703.      capabilities initially by modifying the RADIUS server provided by Liv-
  1704.      ingston,  and later by doing a nearly total rewrite of the software to
  1705.      make enhancement and extension of capabilites easier.  Merit  makes  a
  1706.      basic  version  of  its server freely available for noncommercial use.
  1707.      Merit has started the Merit AAA Server Consortium  which  consists  of
  1708.      Merit  and  a  number of NAS vedors, ISPs and server software vendors.
  1709.      The consortium supports ongoing development of the Merit  AAA  server.
  1710.  
  1711.  
  1712.  
  1713.      Aboba, Lu, Alsop, Ding & Wang                                [Page 26]
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.      INTERNET-DRAFT                                            10 June 1997
  1720.  
  1721.  
  1722.      The  goal  is  to  build  a  server that supports proxy as well as end
  1723.      server capabilities, that is feature rich, and that interoperates with
  1724.      major vendors' NAS products.
  1725.  
  1726.      The  building block of the Merit AAA server, the Authentication/Autho-
  1727.      rization Transfer Vector (AATV),  is  a  very  powerful  concept  that
  1728.      enables the ultimate modularity and flexibility of the AAA server. The
  1729.      structure and methods of the AATV model are published  with  all  ver-
  1730.      sions of the AAA server.
  1731.  
  1732.      Objects  for  extending the authorization server are also available in
  1733.      the enhanced version of the AAA server. Merit is also looking at  ways
  1734.      to  provide  a  method  of  extending the AAA server in its executable
  1735.      form, to improve the server efficiency and scalability, and to provide
  1736.      better monitoring, instrumentation and administration of the server.
  1737.  
  1738.  
  1739.      9.  FidoNet implementation
  1740.  
  1741.      Since its birth in 1984, FidoNet has supported phone book synchroniza-
  1742.      tion among its member nodes, which now  number  approximately  35,000.
  1743.      As  a  non-IP  dialup network, FidoNet does not provide IP services to
  1744.      members, and does  not  utilize  IP-based  authentication  technology.
  1745.      Instead  member  nodes offer bulletin-board services, including access
  1746.      to mail and conferences known as echoes.
  1747.  
  1748.      In order to be able to communicate with  each  other,  FidoNet  member
  1749.      systems  require  a sychronized phone book, known as the Nodelist. The
  1750.      purpose of the Nodelist is to enable resolution of  FidoNet  addresses
  1751.      (expressed  in the form zone:network/node, or 1:161/445) to phone num-
  1752.      bers.  As a dialup network, FidoNet requires phone numbers in order to
  1753.      be deliver mail and conference traffic.
  1754.  
  1755.      In  order to minimize the effort required in regularly synchronizing a
  1756.      phone book of 35,000 entries, the weekly Nodelist updates  are  trans-
  1757.      mitted  as  difference  files.  These  difference  files, known as the
  1758.      Nodediff, produce the Nodelist for the current week  when  applied  to
  1759.      the  previous  week's  Nodelist.   In order to minimize transfer time,
  1760.      Nodediffs are compressed prior to transfer.
  1761.  
  1762.      Information on FidoNet, as well as FidoNet Technical  Standards  (FTS)
  1763.      documents (including the Nodelist specification) and standards propos-
  1764.      als are available from the FidoNet archive at http://www.fidonet.org/.
  1765.  
  1766.  
  1767.      9.1.  Scaling issues
  1768.  
  1769.      With  a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB
  1770.      in size, and the weekly Nodediffs are 175 KB. In compressed form,  the
  1771.      Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a
  1772.      result, the transfer of the Nodediff takes  approximately  45  seconds
  1773.      using a 28,800 bps modem.
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.      Aboba, Lu, Alsop, Ding & Wang                                [Page 27]
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.      INTERNET-DRAFT                                            10 June 1997
  1786.  
  1787.  
  1788.      In  order  to improve scalability, the implementation of a domain name
  1789.      service approach is examined in [8]. The proposal evisages  use  of  a
  1790.      capability  analagous  to the DNS ISDN record in order to map names to
  1791.      phone numbers, coupled  with  an  additional  record  to  provide  the
  1792.      attributes associated with a given name.
  1793.  
  1794.  
  1795.      9.2.  Phone number presentation
  1796.  
  1797.      While FidoNet member systems perform phone book synchronization, users
  1798.      need only know the FidoNet address of the systems they  wish  to  con-
  1799.      tact. As a result users do not need to maintain copies of the Nodelist
  1800.      on their own systems. This is similar to the Internet, where  the  DNS
  1801.      takes  care of the domain name to IP address mapping, so that users do
  1802.      not have to remember IP addresses.
  1803.  
  1804.      Nevertheless, FidoNet systems often find it useful to be able to  pre-
  1805.      sent lists of nodes, and as a result, FidoNet Nodelist compilers typi-
  1806.      cally produce a representation of the Nodelist that can be searched or
  1807.      displayed online, as well as one that is used by the system dialer.
  1808.  
  1809.  
  1810.      9.2.1.  FidoNet Nodelist format
  1811.  
  1812.      The  FidoNet  Nodelist  format  is  documented  in detail in [3].  The
  1813.      Nodelist file consists of lines of data  as  well  as  comment  lines,
  1814.      which  begin  with  a semi-colon.  The first line of the Nodelist is a
  1815.      general interest comment line that includes the date and the day  num-
  1816.      ber,  as  well as a 16-bit CRC. The CRC is included so as to allow the
  1817.      system assembling the new Nodelist to verify its integrity.
  1818.  
  1819.      Each Nodelist data line contains eight comma separated fields:
  1820.  
  1821.           Keyword
  1822.           Zone/Region/Net/Node number
  1823.           Node name
  1824.           Location
  1825.           Sysop name
  1826.           Phone number
  1827.           Maximum Baud rate
  1828.           Flags (optional)
  1829.  
  1830.      FidoNet Nodelists are arranged geographically,  with  systems  in  the
  1831.      same  zone,  region,  and network being grouped together. As a result,
  1832.      FidoNet Nodelists do not require a separate regions file. Among  other
  1833.      things,  the  keyword  field  can be used to indicate that a system is
  1834.      temporarily out of service.
  1835.  
  1836.      Reference [3] discusses Nodelist flags in considerable  detail.  Among
  1837.      other things, the flags include information on supported modem modula-
  1838.      tion and error correction protocols.  Reference [4]  also  proposes  a
  1839.      series  of  ISDN  capability flags, and [5] proposes flags to indicate
  1840.      times of system availability.
  1841.  
  1842.  
  1843.  
  1844.  
  1845.      Aboba, Lu, Alsop, Ding & Wang                                [Page 28]
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.      INTERNET-DRAFT                                            10 June 1997
  1852.  
  1853.  
  1854.      9.3.  Phone number exchange
  1855.  
  1856.      FidoNet coordinators are responsible for maintaining up to date infor-
  1857.      mation on their networks, regions, and zones. Every week network coor-
  1858.      dinators submit to their regional  coordinators  updated  versions  of
  1859.      their portions of the Nodelist. The regional coordinators then compile
  1860.      the submissions from their network coordinators, and  submit  them  to
  1861.      the  zone  coordinator. The zone coordinators then exchange their sub-
  1862.      missions to produce the new Nodelist. As a result, it is possible that
  1863.      the view from different zones may differ at any given time.
  1864.  
  1865.  
  1866.      9.3.1.  The Nodediff
  1867.  
  1868.      The format of the Nodediff is discussed in detail in [3]. In preparing
  1869.      the Nodediffs, network coordinators may transmit only their difference
  1870.      updates, which can be collated to produce the Nodediff directly.
  1871.  
  1872.      One  weakness  in  the  current  approach is that there is no security
  1873.      applied to the coordinator submissions. This leaves oen the  possibil-
  1874.      ity  of  propagation  of fraudulent updates. In order to address this,
  1875.      [6] proposes addition of a shared secret to the update files.
  1876.  
  1877.  
  1878.  
  1879.      9.3.2.  Addition of nodes
  1880.  
  1881.      In order to apply for allocation of a FidoNet address  and  membership
  1882.      in the Nodelist, systems must demonstrate that they are functioning by
  1883.      sending mail to the local network coordinator.  Once the local network
  1884.      coordinator receives the application, they then allocate a new FidoNet
  1885.      address, and add a Nodelist entry.
  1886.  
  1887.      9.3.3.  Deletion of nodes
  1888.  
  1889.      Since FidoNet nodes are required to be  functioning  during  the  zone
  1890.      mail hour in order to receive mail, and since nodes receive the weekly
  1891.      Nodelist from their local network  coordinators  on  a  weekly  basis,
  1892.      there is a built-in mechanism for discovery of non-functional nodes.
  1893.  
  1894.      Nodes  found  to be down are reported to the local network coordinator
  1895.      and subsequently marked as down within the Nodelist.  Nodes  remaining
  1896.      down  for more than two weeks may be removed from the Nodelist, at the
  1897.      discretion of the network coordinator.
  1898.  
  1899.      9.4.  Phone book update
  1900.  
  1901.      The Nodelist contains the phone numbers and associated  attributes  of
  1902.      each  participating system. New Nodelists become available on Fridays,
  1903.      and are made available to participating systems by their local network
  1904.      coordinators,  who  in  turn  receive  them from the regional and zone
  1905.      coordinators.
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.      Aboba, Lu, Alsop, Ding & Wang                                [Page 29]
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.      INTERNET-DRAFT                                            10 June 1997
  1918.  
  1919.  
  1920.      While it is standard practice for participating systems to  get  their
  1921.      Nodelists from their local network coordinators, should the local net-
  1922.      work coordinator not be available for some reason, either the  updates
  1923.      or  the  complete  Nodelist  may  be  picked up from other network, or
  1924.      regional coordinators. Please note that since the view from  different
  1925.      zones  may  differ, nodes wishing to update their Nodelists should not
  1926.      contact systems from outside their zone.
  1927.  
  1928.  
  1929.      9.5.  Phone book compilation
  1930.  
  1931.      Once FidoNet systems have received the Nodediff, the apply it  to  the
  1932.      previous week's Nodelist in order to prepare a new Nodelist.  In order
  1933.      to receive Nodediffs and compile the Nodelist, the following  software
  1934.      is required:
  1935.  
  1936.           A FidoNet-compatible mailer implementation, used to transfer files
  1937.           A Nodelist compiler
  1938.  
  1939.      One  of the purposes of the Nodelist compiler is to apply Nodediffs to
  1940.      the previous Nodelist in order to produce  an  updated  Nodelist.  The
  1941.      other  purpose  is  to  compile  the  updated Nodelist into the format
  1942.      required by the particular mailer implementation used  by  the  member
  1943.      system.  It  is important to note that while the Nodelist and Nodediff
  1944.      formats are standardized (FTS-0005), as is the file transfer  protocol
  1945.      (FTS-0001),  the compiled format used by each mailer is implementation
  1946.      dependent.
  1947.  
  1948.      One reason that compiled formats to differ is the addition of  out  of
  1949.      band  information  to  the  Nodelist  during  the compilation process.
  1950.      Added information includes phone call costs as well as shared secrets.
  1951.  
  1952.      9.5.1.  Cost data
  1953.  
  1954.      Although  cost  information  is not part of the Nodelist, in compiling
  1955.      the Nodelist into the format used by the  mailer,  Nodelist  compilers
  1956.      support  the  addition  of  cost information. This information is then
  1957.      subsequently used to guide mailer behavior.
  1958.  
  1959.      Since phone call costs depend on the rates charged by the local  phone
  1960.      company,  this information is local in nature and is typically entered
  1961.      into the Nodelist compiler's configuration file by the system adminis-
  1962.      trator.
  1963.  
  1964.  
  1965.      9.5.2.  Shared secrets
  1966.  
  1967.      In FidoNet, shared secrets are used for authenticated sessions between
  1968.      systems.   Such  authenticated  sessions  are  particularly  important
  1969.      between  the local, regional and zone coordinators who handle prepara-
  1970.      tion and transmission of the Nodediffs. A single shared secret is used
  1971.      per system.
  1972.  
  1973.  
  1974.  
  1975.  
  1976.  
  1977.      Aboba, Lu, Alsop, Ding & Wang                                [Page 30]
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.      INTERNET-DRAFT                                            10 June 1997
  1984.  
  1985.  
  1986.      9.6.  Accounting
  1987.  
  1988.      Within FidoNet, the need for accounting arises primarily from the need
  1989.      of local, regional and zone coordinators to be  reimbursed  for  their
  1990.      expenses.  In  order to support this, utilities have been developed to
  1991.      account for network usage at the system  level  according  to  various
  1992.      metrics.   However,  the  accounting techniques are not applied at the
  1993.      user level. Distributed authentication and accounting are  not  imple-
  1994.      mented and therefore users may not roam between systems.
  1995.  
  1996.  
  1997.      10.  Acknowledgements
  1998.  
  1999.      Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest
  2000.      for useful discussions of this problem space.
  2001.  
  2002.  
  2003.      11.  References
  2004.  
  2005.      [1]  S. Cobb.  "PPP Internet Protocol Control Protocol Extensions  for
  2006.      Name Server Addresses" RFC 1877, Microsoft, December 1995.
  2007.  
  2008.      [2]   T.  Berners-Lee,  R.  Fielding, H. Frystyk.  "Hypertext Transfer
  2009.      Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996.
  2010.  
  2011.      [3]  B. Baker, R. Moore,  D.  Nugent.   "The  Distribution  Nodelist."
  2012.      FTS-0005, February, 1996.
  2013.  
  2014.      [4]  A. Lentz.  "ISDN Nodelist flags." FSC-0091, June, 1996.
  2015.  
  2016.      [5]   D. J. Thomas.  "A Proposed Nodelist flag indicating Online Times
  2017.      of a Node." FSC-0062, April, 1996.
  2018.  
  2019.      [6]   L.  Kolin.   "Security  Passwords  in  Nodelist  Update  Files."
  2020.      FSC-0055, March, 1991.
  2021.  
  2022.      [7]   R.  Gwinn,  D.  Dodell.  "Nodelist Flag Changes Draft Document."
  2023.      FSC-0009, November, 1987.
  2024.  
  2025.      [8]  R. Heller.  "A Proposal  for  A  FidoNet  Domain  Name  Service."
  2026.      FSC-0069, December, 1992.
  2027.  
  2028.      [9]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
  2029.      cation Dial In User Service (RADIUS)." RFC  2058,  Livingston,  Merit,
  2030.      Daydreamer, January, 1997.
  2031.  
  2032.      [10]   C. Rigney.  "RADIUS Accounting." RFC 2059, Livingston, January,
  2033.      1997.
  2034.  
  2035.  
  2036.  
  2037.  
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.      Aboba, Lu, Alsop, Ding & Wang                                [Page 31]
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.      INTERNET-DRAFT                                            10 June 1997
  2050.  
  2051.  
  2052.      12.  Authors' Addresses
  2053.  
  2054.      Bernard Aboba
  2055.      Microsoft Corporation
  2056.      One Microsoft Way
  2057.      Redmond, WA 98052
  2058.  
  2059.      Phone: 206-936-6605
  2060.      EMail: bernarda@microsoft.com
  2061.  
  2062.      Juan Lu
  2063.      AimQuest Corporation
  2064.      1381 McCarthy Blvd.
  2065.      Milpitas, California 95035
  2066.  
  2067.      Phone: 408-273-2730  ext. 2762
  2068.      EMail: juanlu@aimnet.net
  2069.  
  2070.      John Alsop
  2071.      i-Pass Alliance Inc.
  2072.      650 Castro St., Suite 280
  2073.      Mountain View, CA 94041
  2074.  
  2075.      Phone: 415-968-2200
  2076.      Fax:   415-968-2266
  2077.      EMail: jalsop@ipass.com
  2078.  
  2079.      James Ding
  2080.      Asiainfo
  2081.      One Galleria Tower
  2082.      13355 Noel Road, #1340
  2083.      Dallas, TX 75240
  2084.  
  2085.      Phone: 214-788-4141
  2086.      Fax:   214-788-0729
  2087.      EMail: ding@bjai.asiainfo.com
  2088.  
  2089.      Wei Wang
  2090.      Merit Network, Inc.
  2091.      4251 Plymouth Rd., Suite C
  2092.      Ann Arbor, MI 48105-2785
  2093.  
  2094.      Phone: 313-764-2874
  2095.      EMail: weiwang@merit.edu
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.      Aboba, Lu, Alsop, Ding & Wang                                [Page 32]
  2110.  
  2111.  
  2112.