idnits 2.17.1 draft-ietf-roamops-imprev-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 383 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 593 instances of too long lines in the document, the longest one being 35 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...), its areas...' == Line 16 has weird spacing: '... its worki...' == Line 20 has weird spacing: '... and may ...' == Line 21 has weird spacing: '...afts as refer...' == Line 24 has weird spacing: '... To learn...' == (378 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '45' is mentioned on line 404, but not defined == Unused Reference: '2' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1186, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1877 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ROAMOPS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Lynn Liu 4 26 November 1996 Aimnet 5 John Alsop 6 i-Pass Alliance 7 James Ding 8 Asiainfo 10 Review of Roaming Implementations 12 1. Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working docu- 15 ments of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute work- 17 ing documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference mate- 22 rial or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 The distribution of this memo is unlimited. It is filed as , and expires June 1, 1997. Please send 31 comments to the authors. 33 2. Abstract 35 This document reviews the design and functionality of existing roaming 36 implementations. "Roaming capability" may be loosely defined as the 37 ability to use any one of multiple Internet service providers (ISPs), 38 while maintaining a formal, customer-vendor relationship with only 39 one. Examples of cases where roaming capability might be required 40 include ISP "confederations" and ISP-provided corporate network access 41 support. 43 3. Introduction 45 Considerable interest has arisen recently in a set of features that 46 fit within the general category of "roaming capability" for Internet 47 users. Interested parties have included: 49 Regional Internet Service Providers (ISPs) operating within a 50 particular state or province, looking to combine their efforts 51 with those of other regional providers to offer service over a 52 wider area. 54 National ISPs wishing to combine their operations with those of 55 one or more ISPs in another nation to offer more comprehensive 56 service in a group of countries or on a continent. 58 Businesses desiring to offer their employees a comprehensive 59 package of access services on a global basis. Those services may 60 include Internet access as well as secure access to corporate 61 intranets via a Virtual Private Network (VPN), enabled by tunnel- 62 ing protocols such as PPTP or L2F. 64 What is required to provide roaming capability? The following list is 65 a first cut at defining the requirements for successful roaming among 66 an arbitrary set of ISPs: 68 Phone number presentation 69 Phone number exchange 70 Phone book compilation 71 Phone book update 72 Connection management 73 Authentication 74 NAS Configuration/Authorization 75 Address assignment and routing 76 Security 77 Accounting 79 In this document we review existing roaming implementations, describ- 80 ing their functionality within this framework. In addition to full 81 fledged roaming implementations, we will also review implementations 82 that, while not meeting the strict definition of roaming, address sev- 83 eral of these problem elements. These implementations typically fall 84 into the category of shared use networks or non-IP dialup networks. 86 3.1. Terminology 88 This document frequently uses the following terms: 90 home ISP This is the Internet service provider with whom the user 91 maintains an account relationship. 93 local ISP This is the Internet service provider whom the user calls in 94 order to get access. Where roaming is implemented the local 95 ISP may be different from the home ISP. 97 phone book 98 This is a database or document containing data pertaining to 99 dialup access, including phone numbers and any associated 100 attributes. 102 shared use network 103 This is an IP dialup network whose use is shared by two or 104 more organizations. Shared use networks typically implement 105 distributed authentication and accounting in order to facil- 106 itate the relationship among the sharing parties. Since 107 these facilities are also required for implementation of 108 roaming, implementation of shared use is frequently a first 109 step toward development of roaming capabilities. In fact, 110 one of the ways by which a provider may offer roaming ser- 111 vice is to conclude shared use agreements with multiple net- 112 works. However, to date the ability to accomplish this has 113 been hampered by lack of interoperability among shared use 114 implementations. 116 non-IP dialup network 117 This is a dialup network providing user access to the member 118 systems via protocols other than IP. These networks may 119 implement phone book synchronization facilities, in order to 120 provide systems, administrators and users with a current 121 list of participating systems. Examples of non-IP dialup 122 networks supporting phone book synchronization include 123 FidoNet and WWIVnet. 125 4. Global Reach Internet Consortium (GRIC) 127 Led by a US-based Internet technology developer, Aimnet Corporation, 128 ten Internet Service Providers (ISPs) from the USA, Australia, China, 129 Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the 130 Global Reach Internet Consortium (GRIC) in May, 1996. The goals of 131 GRIC were to to facilitate the implementation of a global roaming ser- 132 vice and to coordinate billing and settlement among the membership. In 133 the future it is likely that additional ISPs from Canada, Central 134 America and Europe will join the GRIC consortium. Information on GRIC 135 is available from http://www.gric.com/. 137 In implementing their roaming service, GRIC members have chosen soft- 138 ware developed by Aimnet. Aimnet Corporation's roaming implementation 139 is comprised of the following major components: the Aimnet Ranger 140 client, the AimTraveler RADIUS/TACACS+ proxy, and the Aimnet Internet 141 Management System (AIMS) billing and settlement module. Information on 142 the Aimnet roaming implementation is available from 143 http://www.aimsoft.com/. 145 The Aimnet Ranger client provides users with an automatically updated 146 phone book, as well as handling authentication and logon. It is avail- 147 able for the Windows platform. 149 The AimTraveler proxy handles incoming authentication requests from 150 NAS devices and routes them to the appropriate home server. 152 AimTraveler is available for various UNIX platforms, and supports both 153 the Unix password file or Kerberos. A version for Windows NT is under 154 development. 156 AIMS is designed for large ISPs who need a centralized management sys- 157 tem for all ISP operations, including sales, trouble-ticketing, ser- 158 vice, and billing. AIMS produces usage and transaction statement 159 reports, and includes a settlement module to produce settle- 160 ment/billing reports for the roaming consortium members. Based on 161 these reports, the providers charge their ISP/roaming customers, and 162 pay/settle the roaming balance among the providers. AIMS currently 163 runs on Sun/Solaris/Oracle. A version for Windows NT and SQL Server is 164 expected to become available in Q4 1996. 166 4.1. Phone number presentation 168 Currently there are two principal methods by which GRIC users can dis- 169 cover available phone numbers: a Web-based directory provided by the 170 GRIC secretariat, and an automatically updated phone book supported by 171 the Aimnet Ranger software. 173 4.1.1. Web based directory 175 A directory of GRIC phone numbers is available on the GRIC home page, 176 http://www.gric.com/. The list of numbers is arranged by country and 177 provider. For each provider within a country, this directory, provided 178 in the form of a table, offers the following information: 180 Provider address, voice phone and fax 181 Customer support phone number 182 Provider domain name 183 Primary Domain Name Server 184 Secondary Domain Name Server 185 Dial-up IP Address 186 News server 187 Web page 188 POP phone numbers (i.e. 1-408-366-9000) 189 POP locations (i.e. Berkeley) 191 In order to discover phone numbers using the Web-based directory, it 192 is expected that users will be online, and will navigate to the appro- 193 priate country and provider. They then look up the number and insert 194 it into the Aimnet Ranger dialer. 196 4.1.2. Aimnet Ranger phone book 198 The Aimnet Ranger software provides for phone book presentation as 199 well as automated updating of phone numbers. The Aimnet Ranger phone 200 book includes a country list, provider list, and POP (phone number) 201 list, as well as detailed provider information, including the cutomer 202 support phone number, and Internet server configuration info. The 203 Phone book, developed with Microsoft VC++, is available for download 204 from the Aimnet ftp site: 206 ftp://ftp.aimnet.com/pub/traveler/isppb.ini 207 ftp://ftp.aimnet.com/pub/traveler/isppb.exe 209 A copy of the phone book is also available from the GRIC phone book 210 page, available at http://www.gric.com/. 212 4.2. Phone number exchange 214 GRIC members submit information both about themselves and their POPs 215 to the GRIC secretariat, which is run by Aimnet. The GRIC secretariat 216 then compiles a new phone book and provides updates on the GRIC FTP 217 and Web servers. 219 GRIC users then download the phone numbers either in Windows .ini file 220 format (viewable via the Aimnet Ranger phone book), or in HTML (view- 221 able via a Web browser). 223 4.3. Phone book compilation 225 GRIC phone books are compiled manually, and represent a concatenation 226 of available numbers from all the members of the roaming consortium, 227 with no policy application. As new POPs come online, the numbers are 228 forwarded to GRIC, which adds them to the phone book servers. 230 4.4. Phone book update 232 Phone numbers in the Aimnet Ranger phone book are updated automati- 233 cally. The AimTraveler server includes an address book which contains 234 the phone numbers of all the roaming consortium members. 236 4.5. Connection management 238 The AimTraveler and Aimnet Ranger software supports PPP and SLIP, as 239 well as PAP and CHAP authentication. 241 4.6. Authentication 243 GRIC implements distributed authentication, utilizing the user's e- 244 mail address as the userID (i.e. "liu@aimnet.com") presented to the 245 remote NAS device. The Aimnet Ranger software takes care of presenting 246 the e-mail address as the userID for PAP or CHAP authentication. 248 After the initial PPP authentication exchange, the userID, domain, and 249 pasword information (or in the case of CHAP, the challenge and the 250 response) are then passed to the AimTraveler authentication proxy, 251 which supports both TACACS+ and RADIUS. 253 The AimTraveler software then determines if the domain name is regis- 254 tered as capable of roaming. The registration check is based on local 255 configuration data, and if it succeeds, the AimTraveler software then 256 translates the authentication request to the protocol type used by the 257 home authenticating domain, and forwards the encrypted access request 258 to the home ISP. If the home ISP authorizes access, verification is 259 sent to the local ISP. AimTraveler works as an authentication gate- 260 way, routing userID and password (encrypted) to the remote authentica- 261 tion server via RADIUS, TACACS+, or other authentication protocol. 262 Since AimTraveler supports both TACACS+ and RADIUS, GRIC members may 263 use either protocol. 265 4.7. NAS Configuration/Authorization 267 AimTraveler is comprised of two components, a Client and a Server. 269 The AimTraveler Client acts as the PPP dial-up authentication server. 270 When it detects an '@' sign in the userID field, it forwards the 271 encrypted userID and password to the AimTraveler server. The AimTrav- 272 eler Server Gateway, a centralized authentication gateway, contains 273 the authorized ISPs' domain names, authentication servers and other 274 information. The AimTraveler Server routes the encrypted userID and 275 password to the remote authorized ISP's authentication server for 276 authentication. 278 The AimTraveler Gateway currently supports RADIUS and TACACS+, and 279 could be extended to support other authentication protocols. It also 280 receives all the accounting records, which are subsequently used as 281 input data for billing. 283 4.8. Address assignment and routing 285 All addresses in GRIC are assigned dynamically from within the address 286 pool of the local ISP. Static addresses and routed LAN connections 287 will be considered in the future, when GRIC offers corporate roaming 288 service. 290 4.9. Security 292 No GRIC members currently offer token card or tunneling support. 294 4.10. Accounting 296 The AimTraveler software can act as either a RADIUS or TACACS+ 297 accounting server. When accounting information is received from the 298 NAS, AimTraveler stamps a roaming transaction log at the centralized 299 Roaming Settlement Center. In the case of GRIC, the settlement center 300 is run by Aimnet. 302 The AimTraveler Server running at Aimnet keeps a record of all roam- 303 ing transactions, which are used as input to the settlement and 304 billing process. At the end of each month, Aimnet provides a roaming 305 transaction summary to GRIC members using AIMS. The AIMS software is 306 configurable so that it takes into account the settlement rules agreed 307 to by GRIC members. AimTraveler also provides accounting records to 308 the local and home ISP for verification purposes. 310 5. i-Pass implementation 312 5.1. Overview 314 i-Pass Alliance Inc., based in Palo Alto, California has developed and 315 operates a service for global roaming between Internet service 316 providers. The service is currently in field trials. 318 i-Pass Alliance Inc. has additional offices in Toronto, Hong Kong, and 319 London. More information on i-Pass can be obtained from 320 http://www.ipass.com. 322 The i-Pass network consists of a number of servers that provide real- 323 time authentication services to member ISPs. Authentication requests 324 and accounting records for roaming users are encrypted and sent to an 325 i-Pass server where they are logged, and then forwarded to a home ISP 326 for authentication and/or logging. 328 Periodically, i-Pass reconciles all accounting records, generates 329 billing statements, and acts as a single point for collecting and 330 remitting payments. 332 i-Pass provides its service only to ISPs. It does not attempt to 333 establish a business relationship with individual-user customers of 334 those ISPs. 336 5.2. Access Point Database (APD) 338 i-Pass maintains a list of roaming access points in an Oracle 339 database. This list is searchable by geographical region using a web 340 browser, and may be downloaded in its entirety using FTP. The informa- 341 tion stored for each access point includes: 343 Name of service provider 344 Country 345 State or Province 346 City or Region 347 Telephone number 348 Technical support phone number 349 Service types available 350 Technical information (help file) 351 Service pricing information 353 i-Pass member ISPs may update their information in the APD using a 354 secure web interface. 356 5.3. Phone number presentation 358 i-Pass provides information and tools to Internet Service Providers 359 and dialer application developers to assist them in integrating the i- 360 Pass access point database into their software. 362 i-Pass does not intend to be a primary developer of dialer applica- 363 tions, as it believes this requirement is best met by the above par- 364 ties. 366 5.4. Authentication 368 There are three entities involved in servicing an authentication 369 request: 371 Local ISP At the local ISP, the authentication server is modified to 372 recognize user IDs of the form username@auth_domain as being 373 remote authentication requests. These requests are for- 374 warded to an i-Pass server. 376 i-Pass Server 377 The i-Pass server receives the authentication request, logs 378 it, and forwards it to the home ISP identified by the 379 auth_domain portion of the user ID. 381 Home ISP The home ISP receives the authentication request, performs 382 authentication using its normal authentication method, and 383 returns a YES/NO response to the i-Pass server, which in 384 turn forwards the reply to the originating ISP. 386 i-Pass provides software components which run on the authentication 387 servers of the local and home ISPs. Each member ISP must integrate 388 these components with the native authentication method being used by 389 the ISP. To simplify this task, i-Pass has developed "drop-in" inter- 390 faces for the most commonly used authentication methods. At the date 391 of writing, the following interfaces are supported: 393 RADIUS (standard Livingston distribution) 394 Merit RADIUS 395 TACACS+ 396 Xylogics erpcd (Versions 10 and 11) 398 A generic interface is also provided which authenticates based on the 399 standard UNIX password file. This is intended as a starting point for 400 ISPs using authentication methods other than those listed above. 402 The software integration effort for a typical ISP is on the order of 403 2-5 man-days including testing. Platforms currently supported include 404 Solaris 2.[45], BSDI, and Digital Unix. 406 5.5. Accounting 408 Accounting transactions are handled in the same way as authentication 409 requests. In addition to being logged at the i-Pass servers, account- 410 ing transactions are sent in real-time to the home ISP. This is 411 intended to allow ISPs to update users' credit limit information on a 412 real-time basis (to the extent that this capability is supported by 413 their billing and accounting systems). 415 Settlement is performed periodically (initially once a month). The 416 settlement process involves calculating the costs associated with each 417 individual session, and aggregating them for each ISP. A net amount 418 is then calculated which is either due from i-Pass to the ISP, or from 419 the ISP to i-Pass, depending on the actual usage pattern. 421 The following reports are supplied to member ISPs: 423 A Monthly Statement showing summaries of usage, 424 service provided, and any adjustments along with the 425 net amount owing. 427 A Call Detail Report showing roaming usage by the ISP's 428 customers. 430 A Service Provided report showing detailed usage of 431 the ISP's facilities by remote users. 433 The above reports are generated as ASCII documents to facilitate 434 delivery by electronic means (e.g. e-mail) as well as hard-copy. 436 The Call Detail Report is also generated as a comma-delimited ASCII 437 file suitable for import into the ISP's billing database. (The Call 438 Detail Report will normally be used by the ISP to generate end-user 439 billing for roaming usage). 441 5.6. Security 443 All transactions between ISPs and the i-Pass servers are encrypted 444 using the SSL protocol. Public key certificates are verified at both 445 the client and server. (i-Pass issues these certificates and acts as 446 the Certification Authority). 448 Transactions are also verified based on a number of other criteria 449 such as source IP address. 451 6. ChinaNet implementation 453 ChinaNet, owned by China Telecom, is China's largest Internet back- 454 bone. Constructed by Asiainfo, a Dallas based system integration com- 455 pany, it has 31 backbone nodes in 31 Chinese provincial capital 456 cities. Each province is building its own provincial network, has its 457 own dialup servers, and administers its own user base. 459 In order to allow ChinaNet users to be able to access nodes outside 460 their province while traveling, a nationwide roaming system has been 461 implemented. The roaming system was developed by AsiaInfo, and is 462 based on the RADIUS protocol. 464 6.1. Phone number presentation 466 Since China Telecom uses one phone number (163) for nationwide Inter- 467 net access, most cities have the same Internet access number. There- 468 fore a phone book is not currently required for the ChinaNet implemen- 469 tation. A web-based phone book will be added in a future software 470 release in order to support nationwide ISP/CSP telephone numbers and 471 HTTP server addresses. 473 6.2. Connection management 475 The current roaming client and server supports both PPP and SLIP. 477 6.3. Address assignment and routing 479 ChinaNet only supports dynamic IP address assignment for roaming 480 users. In addition, static addresses are supported for users authenti- 481 cating within their home province. 483 6.4. Authentication 485 When user accesses a local NAS, it provides its userID either as 486 "username" or "username@realm". The NAS will pass the userID and 487 password to the RADIUS proxy/server. If the "username" notation is 488 used, the Radius proxy/server will assume that the user is a local 489 user and will handle local authentication accordingly. If "user- 490 name@realm" is used, the RADIUS proxy/server will process it as a 491 roaming request. 493 When the RADIUS proxy/server handles a request from a roaming user, it 494 will first check the cache to see if the user information is already 495 stored there. If there is a cache hit, the RADIUS proxy/server do the 496 local authentication accordingly. If it does not find user informa- 497 tion in its cache, it will act as a proxy, forwarding the authentica- 498 tion request to the home RADIUS server. When the home RADIUS server 499 responds, the local server will forward the response to the NAS. If 500 the user is authenticated by the home server, the local RADIUS proxy 501 will cache the user information for a period of time (3 days by 502 default). 504 Caching is used to avoid frequent proxying of requests and responses 505 between the local RADIUS proxy and the home RADIUS server. When the 506 home RADIUS server sends back a valid authentication response, the 507 local RADIUS proxy/server will cache the user information for a period 508 of time (3 days by default). When the user next authenticates 509 directly against the home RADIUS server, the home RADIUS server will 510 send a request to the local server or servers to clear the user's 511 information from the cache. 513 6.4.1. Extended hierarchy 515 In some provinces, the local telecommunications administration 516 (Provincial ISP) further delegates control to county access nodes, 517 creating another level of hierarchy. This is done to improve scalabil- 518 ity and to avoid having the provincial ISP databases grow too large. 519 In the current implementation, each provincial ISP maintains its own 520 central RADIUS server, including information on all users in the 521 province, while county nodes maintain distributed RADIUS servers. For 522 intra-province roaming requests the local RADIUS proxy/server will 523 directly forward the request to the home RADIUS server. 525 However, for inter-province roaming requests, the local RADIUS server 526 does not forward the request directly to the home RADIUS server. 527 Instead, the request is forwarded to the central provincial RADIUS 528 server for the home province. This implementation is suitable only 529 when county level ISPs do not mind combining and sharing their user 530 information. In this instance, this is acceptable, since all county 531 level ISPs are part of China Telecom. In a future release, this multi- 532 layer hierarchy will be implemented using multi-layer proxy RADIUS, in 533 a manner more resembling DNS. 535 6.5. Security 537 Encryption is used between the local RADIUS proxy/server and the home 538 RADIUS server. Public/Private key encryption will be supported in the 539 next release. IP tunneling and token card support is under considera- 540 tion. 542 6.6. Accounting 544 Accounting information is transferred between the local RADIUS 545 accounting proxy/server and home RADIUS accounting server. Every day 546 each node sends a summary accounting information record to a central 547 server in order to support nationwide settlement. The central server 548 is run by the central Data Communication Bureau of China Telecom. 549 Every month the central server sends the settlement bill to the 550 provincial ISPs. 552 6.7. Inter-ISP/CSP roaming 554 ChinaNet supports both ISP and CSP (Content Service Provider) roaming 555 on its system. For example, Shanghai Online, a Web-based commercial 556 content service, uses RADIUS for authentication of ChinaNet users who 557 do not have a Shanghai Online account. In order to support this, the 558 Shanghai Online servers function as a RADIUS client authenticating 559 against the home RADIUS server. When users access a protected document 560 on the HTTP server, they are prompted to send a username/password for 561 authentication. The user then responds with their userID in "user- 562 name@realm" notation. 564 A CGI script on the HTTP server then acts as a RADIUS authentication 565 client, sending the request to the home RADIUS server. After the home 566 RADIUS server responds, the CGI script passes the information to the 567 local authentication agent. From this point forward, everything is 568 taken care of by the local Web authentication mechanism. 570 7. Microsoft implementation 572 Microsoft's roaming implementation was originally developed in order 573 to support the Microsoft Network (MSN), which now offers Internet 574 access in seven countries (US, Canada, France, Germany, UK, Japan, and 575 Australia). In each of these countries, service is offered in cooper- 576 ation with access partners. Since users are able to use the access 577 partner networks while maintaining a customer-vendor relationship with 578 MSN, this implementation fits within the definition of roaming as used 579 in this document. 581 7.1. Implementation overview 583 The first version of the Microsoft roaming software was deployed by 584 the MSN partners in April, 1996. This version included a Phone Book 585 manager tool running under Windows 95, as well as a RADIUS 586 server/proxy implementation running under Windows NT; TACACS+ is cur- 587 rently not supported. Additional components now under development 588 include a Connection Manager client for Windows 95 as well as an HTTP- 589 based phone book server for Windows NT. The Phone Book manager tool is 590 also being upgraded to provide for more automated phone book compila- 591 tion. 593 7.2. Phone number presentation 595 The Connection Manager is responsible for the presentation and updat- 596 ing of phone numbers, as well as for dialing and making connections. 597 In order to select phone numbers, users are asked to select the 598 desired country and region/state. Phone numbers are then presented in 599 the area selected. The primary numbers are those from the users ser- 600 vice provider which match the service type (Analog, ISDN, Analog & 601 ISDN), country and region/state selected. The other numbers (selected 602 clicking on the More button) are those for other service providers 603 that have a roaming agreement with the users service provider. 605 7.2.1. Cost data 607 Cost data is not presented to users along with the phone numbers. How- 608 ever, such information may be made available by other means, such as 609 via a Web page. 611 7.2.2. Default phone book format 613 The Connection Manager supports the ability to customize the phone 614 book format, and it is expected that many ISPs will make use of this 615 capability. However, for those who wish to use it "off the shelf" a 616 default phone book format is provided. The default phone book is com- 617 prised of several files, including: 619 Service profile 620 Phone Book 621 Region file 623 The service profile provides information on a given service, which may 624 be an isolated Internet Service Provider, or may represent a roaming 625 consortium. The service profile, which is in .ini file format, is com- 626 prised of the following information: 628 The name of the service 629 The filename of the service's big icon 630 The filename of the service's little icon 631 A description of the service 632 The service phone book filename 633 The service phone book version number 634 The service regions file 635 The URL of the service phone book server 636 The prefix used by the service (i.e. "MSN/aboba") 637 The suffix or domain used by the service (i.e. "aboba@msn.com") 638 Whether the user name is optional for the service 639 Whether the password is optional for the service 640 Maximum length of the user name for the service 641 Maximum length of the password for the service 642 Information on service password handling (lowercase, mixed case, etc.) 643 Number of redials for this service 644 Delay between redials for this service 645 References to other service providers that have roaming agreements 646 The service profile filenames for each of the references 647 Mask and match phone book filters for each of the references 648 (these are 32 bit numbers that are applied against the capability flags in the phone book) 649 The dial-up connection properties configuration 650 (this is the DUN connectoid name) 652 The phone book file is a comma delimited ASCII file containing the 653 following data: 655 Unique number identifying a particular record (Index) 656 Country ID 657 A zero-base index into the region file 658 City 659 Area code 660 Local phone number 661 Minimum Speed 662 Maximum speed 663 Capability Flags: 664 Bit 0: 0=Toll, 1=Toll free 665 Bit 1: 0=X25, 1=IP 666 Bit 2: 0=Analog, 1=No analog support 667 Bit 3: 0=no ISDN support, 1=ISDN 668 Bit 4: 0 669 Bit 5: 0 670 Bit 6: 0=No Internet access, 1=Internet access 671 Bit 7: 0=No signup access, 1=Signup access 672 Bit 8-31: reserved 673 The filename of the dialup network file 674 (typically refers to a script associated with the number) 676 A sample phone book file is shown below: 678 65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile 679 200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10, 680 200133,1,1,Birmingham,205,5551212,9600,28800,0,10, 681 130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile 682 65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile 684 7.2.3. Additional attributes 686 As described previously, it is likely that some ISPs will require 687 additional phone number attributes or provider information beyond that 688 supported in the default phone book format. Attributes of interest 689 may vary between providers, or may arise as a result of the introduc- 690 tion of new technologies. As a result, the set of phone number 691 attributes is likely to evolve over time, and extensibility in the 692 phone book format is highly desirable. 694 For example, in addition to the attributes provided in the default 695 phone book, the following additional attributes have been requested by 696 customers: 698 Multicast support flag 699 External/internal flag (to differentiate display between the 700 "internal" or "other" list box) 701 Priority (for control of presentation order) 702 Modem protocol capabilities (V.34, V.32bis, etc.) 703 ISDN protocol capabilities (V.110, V.120, etc.) 704 No password flag (for numbers using telephone-based billing) 705 Provider name 707 7.2.4. Addition of information on providers 709 The default phone book does not provide a mechanism for display of 710 information on the individual ISPs within the roaming consortium, only 711 for the consortium as a whole. For example, the provider icons (big 712 and little) are included in the service profile. The service descrip- 713 tion information is expected to contain the customer support number. 714 However, this information cannot be provided on an individual basis 715 for each of the members of a roaming consortium. Additional informa- 716 tion useful on a per-provider basis would include: 718 Provider voice phone number 719 Provider icon 720 Provider fax phone number 721 Provider customer support phone number 723 7.3. Phone number exchange 725 Currently phone number exchange is not supported by the phone book 726 server. As a result, in the MSN implementation, phone number exchange 727 is handled manually. As new POPs come online, the numbers are for- 728 warded to MSN, which tests the numbers and approves them for addition 729 to the phone book server. Updated phone books are produced and loaded 730 on the phone book server on a weekly basis. 732 7.4. Phone book compilation 734 The Phone Book Manager tool was created in order to make it easier for 735 the access partners to create and update their phone books. It sup- 736 ports addition, removal, and editing of phone numbers, generating both 737 a new phone book, as well as associated difference files. 739 With version 1 of the Phone Book Admin tool, phone books are compiled 740 manually, and represent a concatenation of available numbers from all 741 partners, with no policy application. With version 1, the updates are 742 prepared by the partners and forwarded to MSN, which tests the numbers 743 and approves them for addition to the phone book. The updates are then 744 concatenated together to form the global update file. 746 The new version of the Phone Book Admin tool automates much of the 747 phone book compilation process, making it possible for phone book com- 748 pilation to be decentralized with each partner running their own phone 749 book server. Partners can then maintain and test their individual 750 phone books and post them on their own Phone Book Server. 752 7.5. Phone book update 754 The Connection Manager updates the phone book each time the user logs 755 on. This is accomplished via an HTTP GET request to the phone book 756 server, with information on the phone book version number presented as 757 part of the GET request. 759 In formulating its response, the phone book server then compares the 760 version number in the GET request to the current version number, and 761 reponds with the difference files necessary to update the client's 762 phone book to the latest version. The client then builds the new phone 763 book by successively applying these difference files. This process 764 results in the update of the entire phone book, and is simple enough 765 to allow it to be easily implemented on a variety of HTTP servers, 766 either as a CGI script or (on NT) as an ISAPI DLL. 768 The difference files used in the default phone book consist of a list 769 of phone book entries, each uniquely identified by their index number. 770 Additions consist of phone book entries with all the information filed 771 in; deletions are signified by entries with all entries zeroed out. 772 Before being sent, the update file is digitally signed. A sample dif- 773 ference file is shown below: 775 65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile 776 200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10, 777 200133,0,0,0,0,0,0,0,0,0 778 130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile 779 65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile 781 7.6. Connection management 783 The Connection Manager assumes use of PPP, and does not support SLIP. 784 The default setting is for the IP address as well as the DNS server IP 785 address to be assigned by the NAS. The DNS server assignment capabil- 786 ity is described in [1]. 788 7.7. Authentication 790 The Connection Manager client and RADIUS proxy/server both support 791 suffix style notation (i.e. "aboba@msn.com"), as well as a prefix 792 notation ("MSN/aboba"). 794 The prefix notation was developed for use with NAS devices with small 795 maximum userID lengths. For these devices the compactness of the pre- 796 fix notation significantly increases the number of characters avail- 797 able for the userID field. However, as an increasing number of NAS 798 devices are now supporting 253 octet userIDs (the maximum supported by 799 RADIUS) the need for prefix notation is declining. 801 After receiving the userID from the Connection Manager client, the NAS 802 device passes the userID/domain and password information (or in the 803 case of CHAP, the challenge and the response) to the RADIUS proxy. The 804 RADIUS proxy then checks if the domain is authorized for roaming by 805 examining a static configuration file. If the domain is authorized, 806 the RADIUS proxy then forwards the request to the appropriate RADIUS 807 server. The domain to server mapping is also made via a static config- 808 uration file. 810 While static configuration files work well for small roaming consor- 811 tia, for larger consortia static configuration will become tedious. 812 Potentially more scalable solutions include use of DNS SRV records for 813 the domain to RADIUS server mapping. 815 7.8. NAS configuration/authorization 817 Although the attributes returned by the home RADIUS server may make 818 sense to home NAS devices, the local NAS may be configured differ- 819 ently, or may be from a different vendor. As a result, it may be nec- 820 essary for the RADIUS proxy to edit the attribute set returned by the 821 home RADIUS server, in order to provide the local NAS with the appro- 822 priate configuration information. The editing occurs via attribute 823 discard and insertion of attributes by the proxy. 825 Alternatively, the home RADIUS server may be configured not to return 826 any network-specific attributes, and to allow these to be inserted by 827 the local RADIUS proxy. 829 Attributes most likely to cause conflicts include: 831 Framed IP Address 832 Framed IP Netmask 833 Framed Routing 834 Framed Route 835 Filter ID 836 Vendor Specific 837 Session Timeout 838 Idle Timeout 839 Termination Action 841 Conflicts relating to IP address assignment and routing are very com- 842 mon. Where dynamic address assignment is used, an IP address pool 843 appropriate for the local NAS can be substituted for the IP address 844 pool designated by the home RADIUS server. 846 However, not all address conflicts can be resolved by editing. In 847 some cases, (i.e., assignment of a static network address for a LAN) 848 it may not be possible for the local NAS to accept the home RADIUS 849 server's address assignment, yet the roaming hosts may not be able to 850 accept an alternative assignment. 852 Filter IDs also pose a problem. It is possible that the local NAS may 853 not implement a filter corresponding to that designated by the home 854 RADIUS server. Even if an equivalent filter is implemented, in order 855 to guarantee correct operation, the proxy's configuration must track 856 changes in the filter configurations of each of the members of the 857 roaming consortium. In practice this is likely to be unworkable. 858 Direct upload of filter configuration is not a solution either, 859 because of the wide variation in filter languages supported in today's 860 NAS devices. 862 Since by definition vendor specific attributes have meaning only to 863 devices created by that vendor, use of these attributes is problematic 864 within a heterogeneous roaming consortium. While it is possible to 865 edit these attributes, or even to discard them or allow them to be 866 ignored, this may not always be acceptable. In cases where vendor spe- 867 cific attributes relate to security, it may not be acceptable for the 868 proxy to modify or discard these attributes; the only acceptable 869 action may be for the local NAS to drop the user. Unfortunately, 870 RADIUS does not distinguish between mandatory and optional attributes, 871 so that there is no way for the proxy to take guidance from the 872 server. 874 Conflicts over session or idle timeouts may result if since both the 875 local and home ISP feel the need to adjust these parameters. While 876 the home ISP may wish to adjust the parameter to match the user's 877 software, the local ISP may wish to adjust it to match its own service 878 policy. As long as the desired parameters do not differ too greatly, a 879 compromise is often possible. 881 7.9. Address assignment and routing 883 While the Connection Manager software supports both static and dynamic 884 address assignment, in the MSN implementation, all addresses are 885 dynamically assigned. 887 However, selected partners also offer LAN connectivity to their cus- 888 tomers, usually via static address assignment. However, these accounts 889 do not have roaming privileges since no mechanism has been put in 890 place for allowing these static routes to move between providers. 891 Users looking to do LAN roaming between providers are encouraged to 892 select a router supporting Network Address Translation (NAT). NAT ver- 893 sions implemented in several low-end routers are compatible with the 894 dynamic addressing used on MSN, as well as supporting DHCP on the LAN 895 side. 897 7.10. Security 899 The RADIUS proxy/server implementation does not support token cards or 900 tunneling protocols. 902 7.11. Accounting 904 In the MSN roaming implementation, the accounting data exchange pro- 905 cess is specified in terms of an accounting record format, and a 906 method by which the records are transferred from the partners to MSN, 907 which acts as the settlement agent. Defining the interaction in terms 908 of record formats and transfer protocols implies that the partners do 909 not communicate with the settlement agent using NAS accounting proto- 910 cols. As a result, accounting protocol interoperability is not be 911 required. 913 However, for this advantage to be fully realized, it is necessary for 914 the accounting record format to be extensible. This makes it more 915 likely that the format can be adapted for use with the wide variety of 916 accounting protocols in current use (such as SNMP, syslog, RADIUS, and 917 TACACS+), as well as future protocols. After all, if the record format 918 cannot express the metrics provided by a particular partner's account- 919 ing protocol, then the record format will not be of much use for a 920 heterogeneous roaming consortium. 922 7.11.1. Accounting record format 924 The Microsoft RADIUS proxy/server supports the ability to customize 925 the accounting record format, and it is expected that some ISPs will 926 make use of this capability. However for those who want to use it "off 927 the shelf" a default accounting record format is provided. The 928 accounting record includes information provided by RADIUS: 930 User Name (String; the user's ID, including prefix or suffix) 931 NAS IP address (Integer; the IP address of the user's NAS) 932 NAS Port (Integer; identifies the physical port on the NAS) 933 Service Type (Integer; identifies the service provided to the user) 934 NAS Identifier (Integer; unique identifier for the NAS) 935 Status Type (Integer; indicates session start and stop, 936 as well as accounting on and off) 937 Delay Time (Integer; time client has been trying to send) 938 Input Octets (Integer; in stop record, octets received from port) 939 Output Octets (Integer; in stop record, octets sent to port) 940 Session ID (Integer; unique ID linking start and stop records) 941 Authentication (Integer; indicates how user was authenticated) 942 Session Time (Integer; in stop record, seconds of received service) 943 Input Packets (Integer; in stop record, packets received from port) 944 Output Packets (Integer; in stop record, packets sent to port) 945 Termination Cause (Integer; in stop record, indicates termination cause) 946 Multi-Session ID (String; for linking of multiple related sessions) 947 Link Count (Integer; number of links up when record was generated) 948 NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 950 However, since this default format is not extensible, it cannot easily 951 be adapted to protocols other than RADIUS, services other than dialup 952 (i.e. dedicated connections) or rated events (i.e. file downloads). 953 This is a serious limitation, and as a result, customers have 954 requested a more general accounting record format. 956 7.11.2. Transfer mechanism 958 Prior to being transferred, the accounting records are compressed so 959 as to save bandwidth. The transfer of accounting records is handled 960 via FTP, with the transfer being initiated by the receiving party, 961 rather than by the sending party. A duplicate set of records is kept 962 by the local ISP for verification purposes. 964 8. FidoNet implementation 966 Since its birth in 1984, FidoNet has supported phone book synchroniza- 967 tion among its member nodes, which now number approximately 35,000. 968 As a non-IP dialup network, FidoNet does not provide IP services to 969 members, and does not utilize IP-based authentication technology. 970 Instead member nodes offer bulletin-board services, including access 971 to mail and conferences known as echoes. 973 In order to be able to communicate with each other, FidoNet member 974 systems require a sychronized phone book, known as the Nodelist. The 975 purpose of the Nodelist is to enable resolution of FidoNet addresses 976 (expressed in the form zone:network/node, or 1:161/445) to phone num- 977 bers. As a dialup network, FidoNet requires phone numbers in order to 978 be deliver mail and conference traffic. 980 In order to minimize the effort required in regularly synchronizing a 981 phone book of 35,000 entries, the weekly Nodelist updates are trans- 982 mitted as difference files. These difference files, known as the 983 Nodediff, produce the Nodelist for the current week when applied to 984 the previous week's Nodelist. In order to minimize transfer time, 985 Nodediffs are compressed prior to transfer. 987 Information on FidoNet, as well as FidoNet Technical Standards (FTS) 988 documents (including the Nodelist specification) and standards propos- 989 als are available from the FidoNet archive at http://www.fidonet.org/. 991 8.1. Scaling issues 993 With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB 994 in size, and the weekly Nodediffs are 175 KB. In compressed form, the 995 Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a 996 result, the transfer of the Nodediff takes approximately 45 seconds 997 using a 28,800 bps modem. 999 In order to improve scalability, the implementation of a domain name 1000 service approach is examined in [8]. The proposal evisages use of a 1001 capability analagous to the DNS ISDN record in order to map names to 1002 phone numbers, coupled with an additional record to provide the 1003 attributes associated with a given name. 1005 8.2. Phone number presentation 1007 While FidoNet member systems perform phone book synchronization, users 1008 need only know the FidoNet address of the systems they wish to con- 1009 tact. As a result users do not need to maintain copies of the Nodelist 1010 on their own systems. This is similar to the Internet, where the DNS 1011 takes care of the domain name to IP address mapping, so that users do 1012 not have to remember IP addresses. 1014 Nevertheless, FidoNet systems often find it useful to be able to pre- 1015 sent lists of nodes, and as a result, FidoNet Nodelist compilers typi- 1016 cally produce a representation of the Nodelist that can be searched or 1017 displayed online, as well as one that is used by the system dialer. 1019 8.2.1. FidoNet Nodelist format 1021 The FidoNet Nodelist format is documented in detail in [3]. The 1022 Nodelist file consists of lines of data as well as comment lines, 1023 which begin with a semi-colon. The first line of the Nodelist is a 1024 general interest comment line that includes the date and the day num- 1025 ber, as well as a 16-bit CRC. The CRC is included so as to allow the 1026 system assembling the new Nodelist to verify its integrity. 1028 Each Nodelist data line contains eight comma separated fields: 1030 Keyword 1031 Zone/Region/Net/Node number 1032 Node name 1033 Location 1034 Sysop name 1035 Phone number 1036 Maximum Baud rate 1037 Flags (optional) 1039 FidoNet Nodelists are arranged geographically, with systems in the 1040 same zone, region, and network being grouped together. As a result, 1041 FidoNet Nodelists do not require a separate regions file. Among other 1042 things, the keyword field can be used to indicate that a system is 1043 temporarily out of service. 1045 Reference [3] discusses Nodelist flags in considerable detail. Among 1046 other things, the flags include information on supported modem modula- 1047 tion and error correction protocols. Reference [4] also proposes a 1048 series of ISDN capability flags, and [5] proposes flags to indicate 1049 times of system availability. 1051 8.3. Phone number exchange 1053 FidoNet coordinators are responsible for maintaining up to date infor- 1054 mation on their networks, regions, and zones. Every week network coor- 1055 dinators submit to their regional coordinators updated versions of 1056 their portions of the Nodelist. The regional coordinators then compile 1057 the submissions from their network coordinators, and submit them to 1058 the zone coordinator. The zone coordinators then exchange their sub- 1059 missions to produce the new Nodelist. As a result, it is possible that 1060 the view from different zones may differ at any given time. 1062 8.3.1. The Nodediff 1064 The format of the Nodediff is discussed in detail in [3]. In preparing 1065 the Nodediffs, network coordinators may transmit only their difference 1066 updates, which can be collated to produce the Nodediff directly. 1068 One weakness in the current approach is that there is no security 1069 applied to the coordinator submissions. This leaves open the possibil- 1070 ity of propagation of fraudulent updates. In order to address this, 1071 [6] proposes addition of a shared secret to the update files. 1073 8.3.2. Addition of nodes 1075 In order to apply for allocation of a FidoNet address and membership 1076 in the Nodelist, systems must demonstrate that they are functioning by 1077 sending mail to the local network coordinator. Once the local network 1078 coordinator receives the application, they then allocate a new FidoNet 1079 address, and add a Nodelist entry. 1081 8.3.3. Deletion of nodes 1083 Since FidoNet nodes are required to be functioning during the zone 1084 mail hour in order to receive mail, and since nodes receive the weekly 1085 Nodelist from their local network coordinators on a weekly basis, 1086 there is a built-in mechanism for discovery of non-functional nodes. 1088 Nodes found to be down are reported to the local network coordinator 1089 and subsequently marked as down within the Nodelist. Nodes remaining 1090 down for more than two weeks may be removed from the Nodelist, at the 1091 discretion of the network coordinator. 1093 8.4. Phone book update 1095 The Nodelist contains the phone numbers and associated attributes of 1096 each participating system. New Nodelists become available on Fridays, 1097 and are made available to participating systems by their local network 1098 coordinators, who in turn receive them from the regional and zone 1099 coordinators. 1101 While it is standard practice for participating systems to get their 1102 Nodelists from their local network coordinators, should the local net- 1103 work coordinator not be available for some reason, either the updates 1104 or the complete Nodelist may be picked up from other network, or 1105 regional coordinators. Please note that since the view from different 1106 zones may differ, nodes wishing to update their Nodelists should not 1107 contact systems from outside their zone. 1109 8.5. Phone book compilation 1111 Once FidoNet systems have received the Nodediff, the apply it to the 1112 previous week's Nodelist in order to prepare a new Nodelist. In order 1113 to receive Nodediffs and compile the Nodelist, the following software 1114 is required: 1116 A FidoNet-compatible mailer implementation, used to transfer files 1117 A Nodelist compiler 1119 One of the purposes of the Nodelist compiler is to apply Nodediffs to 1120 the previous Nodelist in order to produce an updated Nodelist. The 1121 other purpose is to compile the updated Nodelist into the format 1122 required by the particular mailer implementation used by the member 1123 system. It is important to note that while the Nodelist and Nodediff 1124 formats are standardized (FTS-0005), as is the file transfer protocol 1125 (FTS-0001), the compiled format used by each mailer is implementation 1126 dependent. 1128 One reason that compiled formats to differ is the addition of out of 1129 band information to the Nodelist during the compilation process. 1130 Added information includes phone call costs as well as shared secrets. 1132 8.5.1. Cost data 1134 Although cost information is not part of the Nodelist, in compiling 1135 the Nodelist into the format used by the mailer, Nodelist compilers 1136 support the addition of cost information. This information is then 1137 subsequently used to guide mailer behavior. 1139 Since phone call costs depend on the rates charged by the local phone 1140 company, this information is local in nature and is typically entered 1141 into the Nodelist compiler's configuration file by the system adminis- 1142 trator. 1144 8.5.2. Shared secrets 1146 In FidoNet, shared secrets are used for authenticated sessions between 1147 systems. Such authenticated sessions are particularly important 1148 between the local, regional and zone coordinators who handle prepara- 1149 tion and transmission of the Nodediffs. A single shared secret is used 1150 per system. 1152 8.6. Accounting 1154 Within FidoNet, the need for accounting arises primarily from the need 1155 of local, regional and zone coordinators to be reimbursed for their 1156 expenses. In order to support this, utilities have been developed to 1157 account for network usage at the system level according to various 1158 metrics. However, the accounting techniques are not applied at the 1159 user level. Distributed authentication and accounting are not imple- 1160 mented and therefore users may not roam between systems. 1162 9. Acknowledgements 1164 Thanks to Glen Zorn of Microsoft for many useful discussions of this 1165 problem space. 1167 10. References 1169 [1] S. Cobb. "PPP Internet Protocol Control Protocol Extensions for 1170 Name Server Addresses" RFC 1877, Microsoft, December 1995. 1172 [2] T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer 1173 Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996. 1175 [3] B. Baker, R. Moore, D. Nugent. "The Distribution Nodelist." 1176 FTS-0005, February, 1996. 1178 [4] A. Lentz. "ISDN Nodelist flags." FSC-0091, June, 1996. 1180 [5] D. J. Thomas. "A Proposed Nodelist flag indicating Online Times 1181 of a Node." FSC-0062, April, 1996. 1183 [6] L. Kolin. "Security Passwords in Nodelist Update Files." 1184 FSC-0055, March, 1991. 1186 [7] R. Gwinn, D. Dodell. "Nodelist Flag Changes Draft Document." 1187 FSC-0009, November, 1987. 1189 [8] R. Heller. "A Proposal for A FidoNet Domain Name Service." 1190 FSC-0069, December, 1992. 1192 11. Authors' Addresses 1194 Bernard Aboba 1195 Microsoft Corporation 1196 One Microsoft Way 1197 Redmond, WA 98052 1199 Phone: 206-936-6605 1200 EMail: bernarda@microsoft.com 1202 Lynn Liu 1203 Aimnet Corporation 1204 2350 Mission College Blvd., Ste. 600 1205 Santa Clara, CA 95054 1207 Phone: 408-567-3800 ext. 202 1208 EMail: yalin@aimnet.com 1210 John Alsop 1211 i-Pass Alliance Inc. 1212 555 Bryant Street, #248 1213 Palo Alto, CA 94301 1214 Phone: 415-327-5553 1215 EMail: jalsop@ipass.com 1217 James Ding 1218 Asiainfo 1219 One Galleria Tower 1220 13355 Noel Road, #1340 1221 Dallas, TX 75240 1223 Phone: 214-788-4141 1224 Fax: 214-788-0729 1225 EMail: ding@bjai.asiainfo.com