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