idnits 2.17.1 draft-ietf-roamops-imprev-01.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-16) 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 27 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 27 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 428 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 664 instances of too long lines in the document, the longest one being 35 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 16 has weird spacing: '...), its areas...' == Line 17 has weird spacing: '... its worki...' == Line 21 has weird spacing: '... and may ...' == Line 22 has weird spacing: '...afts as refer...' == Line 25 has weird spacing: '... To learn...' == (423 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 490, but not defined == Unused Reference: '2' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1282, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1288, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1292, 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' ** Obsolete normative reference: RFC 2058 (ref. '9') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '10') (Obsoleted by RFC 2139) Summary: 16 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Juan Lu 5 21 January 1997 AimQuest Corp 6 John Alsop 7 i-Pass Alliance 8 James Ding 9 Asiainfo 11 Review of Roaming Implementations 13 1. Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working docu- 16 ments of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute work- 18 ing documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference mate- 23 rial or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 The distribution of this memo is unlimited. It is filed as , and expires August 1, 1997. Please send 32 comments to the authors. 34 2. Abstract 36 This document reviews the design and functionality of existing roaming 37 implementations. "Roaming capability" may be loosely defined as the 38 ability to use any one of multiple Internet service providers (ISPs), 39 while maintaining a formal, customer-vendor relationship with only 40 one. Examples of cases where roaming capability might be required 41 include ISP "confederations" and ISP-provided corporate network access 42 support. 44 3. Introduction 46 Considerable interest has arisen recently in a set of features that 47 fit within the general category of "roaming capability" for Internet 48 users. Interested parties have included: 50 Regional Internet Service Providers (ISPs) operating within a 51 particular state or province, looking to combine their efforts 52 with those of other regional providers to offer service over a 53 wider area. 55 National ISPs wishing to combine their operations with those of 56 one or more ISPs in another nation to offer more comprehensive 57 service in a group of countries or on a continent. 59 Businesses desiring to offer their employees a comprehensive 60 package of access services on a global basis. Those services may 61 include Internet access as well as secure access to corporate 62 intranets via a Virtual Private Network (VPN), enabled by tunnel- 63 ing protocols such as PPTP or L2F. 65 What is required to provide roaming capability? The following list is 66 a first cut at defining the requirements for successful roaming among 67 an arbitrary set of ISPs: 69 Phone number presentation 70 Phone number exchange 71 Phone book compilation 72 Phone book update 73 Connection management 74 Authentication 75 NAS Configuration/Authorization 76 Address assignment and routing 77 Security 78 Accounting 80 In this document we review existing roaming implementations, describ- 81 ing their functionality within this framework. In addition to full 82 fledged roaming implementations, we will also review implementations 83 that, while not meeting the strict definition of roaming, address sev- 84 eral of these problem elements. These implementations typically fall 85 into the category of shared use networks or non-IP dialup networks. 87 3.1. Terminology 89 This document frequently uses the following terms: 91 home ISP This is the Internet service provider with whom the user 92 maintains an account relationship. 94 local ISP This is the Internet service provider whom the user calls in 95 order to get access. Where roaming is implemented the local 96 ISP may be different from the home ISP. 98 phone book 99 This is a database or document containing data pertaining to 100 dialup access, including phone numbers and any associated 101 attributes. 103 shared use network 104 This is an IP dialup network whose use is shared by two or 105 more organizations. Shared use networks typically implement 106 distributed authentication and accounting in order to facil- 107 itate the relationship among the sharing parties. Since 108 these facilities are also required for implementation of 109 roaming, implementation of shared use is frequently a first 110 step toward development of roaming capabilities. In fact, 111 one of the ways by which a provider may offer roaming ser- 112 vice is to conclude shared use agreements with multiple net- 113 works. However, to date the ability to accomplish this has 114 been hampered by lack of interoperability among shared use 115 implementations. 117 non-IP dialup network 118 This is a dialup network providing user access to the member 119 systems via protocols other than IP. These networks may 120 implement phone book synchronization facilities, in order to 121 provide systems, administrators and users with a current 122 list of participating systems. Examples of non-IP dialup 123 networks supporting phone book synchronization include 124 FidoNet and WWIVnet. 126 4. Global Reach Internet Consortium (GRIC) 128 Led by a US-based Internet technology developer, AimQuest Corporation, 129 ten Internet Service Providers (ISPs) from the USA, Australia, China, 130 Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the 131 Global Reach Internet Connection (GRIC) in May, 1996. The goals of 132 GRIC were to facilitate the implementation of a global roaming service 133 and to coordinate billing and settlement among the membership. Commer- 134 cial operation began in December of 1996, and GRIC has grown to over 135 50 major ISPs and Telcos from all over the world, including NETCOM, 136 USA; KDD and Mitsubishi, Japan; iStar, Canada; Easynet, UK; Con- 137 nect.com, Australia; Iprolink, Switzerland; Singapore Telecom; 138 Chunghwa Telecom, Taiwan; and Telekom Malaysia. Information on GRIC 139 is available from http://www.gric.net/. 141 In implementing their roaming service, GRIC members have chosen soft- 142 ware developed by AimQuest. AimQuest Corporation's roaming implementa- 143 tion comprises the following major components: the AimTraveler Authen- 144 tication Server (AAS), the AimTraveler Routing Server (ARS), and the 145 AimQuest Internet Management System (AIMS), software designed to 146 facilitate the billing process. Information on the AimQuest roaming 147 implementation is available from http://www.aimquest.com/. 149 The AimTraveler Authentication Server (AAS) runs at each member ISP 150 location, and handles incoming authentication requests from NAS 151 devices. The AimTraveler Routing Server (ARS) can run anywhere. A 152 single routing server can be used where centralized routing is 153 desired, or multiple routing servers can be run in order to increase 154 speed and reliability or to gateway to networks of particularly large 155 partners. 157 The first version of the AimTraveler software, deployed by AimQuest in 158 May, 1996, supported direct authentication between members of the 159 roaming consortium, but as GRIC grew, management of the relationships 160 between the authentication servers became a problem. In August. 1996, 161 AimQuest began development of the AimTraveler Routing Server (ARS) in 162 order to improve scalability. 164 The routing server is comprised of two elements: The Central Account- 165 ing Server and the Central Routing Server. The Central Accounting 166 Server collects all the roaming accounting data for settlement. The 167 Central Routing Server manages and maintains information on the 168 authentication servers in the roaming consortium. Adding, deleting, or 169 updating ISP authentication server information (e.g. adding a new mem- 170 ber ISP) may be accomplished by editing of a configuration file on the 171 Central Routing Server. The configuration files of the AimTraveler 172 Authentication Servers do not need to be modified. 174 The AimTraveler Authentication and Routing Servers are available for 175 various UNIX platforms. Versions for Windows NT are under development. 176 The AimTraveler Authentication Server supports both the UNIX password 177 file and Kerberos. 179 The AimQuest Internet Management System (AIMS) is designed for large 180 ISPs who need a centralized management system for all ISP operations, 181 including sales, trouble-ticketing, service, and billing. AIMS pro- 182 duces usage and transaction statement reports, and includes a settle- 183 ment module to produce settlement/billing reports for the roaming con- 184 sortium members. Based on these reports, the providers charge their 185 ISP/roaming customers, and pay/settle the roaming balance among the 186 providers. AIMS currently runs on Sun/Solaris/Oracle. A version for 187 Windows NT and SQL Server is expected to become available in Q4 1996. 189 4.1. Phone number presentation 191 Currently there are two principal methods by which GRIC users can dis- 192 cover available phone numbers: a Web-based directory provided by the 193 GRIC secretariat, and an automatically updated phone book supported by 194 the AimQuest Ranger software. 196 4.1.1. Web based directory 198 A directory of GRIC phone numbers is available on the GRIC home page, 199 http://www.gric.com/. The list of numbers is arranged by country and 200 provider. For each provider within a country, this directory, provided 201 in the form of a table, offers the following information: 203 Provider address, voice phone and fax 204 Customer support phone number 205 Provider domain name 206 Primary Domain Name Server 207 Secondary Domain Name Server 208 Dial-up IP Address 209 News server 210 Web page 211 POP phone numbers (i.e. 1-408-366-9000) 212 POP locations (i.e. Berkeley) 213 Proxy addresses 214 Dialer configuration 216 In order to discover phone numbers using the Web-based directory, it 217 is expected that users will be online, and will navigate to the appro- 218 priate country and provider. They then look up the number and insert 219 it into the AimQuest Ranger dialer. 221 4.1.2. AimQuest Ranger phone book 223 The AimQuest Ranger software provides for phone book presentation as 224 well as automated updating of phone numbers. The AimQuest Ranger 225 phone book includes a country list, provider list, and POP (phone num- 226 ber) list, as well as detailed provider information, including the 227 cutomer support phone number, and Internet server configuration info. 228 The Phone book, developed with Microsoft VC++, is available for down- 229 load from the AimQuest ftp site: 231 ftp://ftp.Aimnet.com/pub/traveler/isppb.ini 232 ftp://ftp.Aimnet.com/pub/traveler/isppb.exe 234 A copy of the phone book is also available from the GRIC phone book 235 page, available at http://www.gric.com/. 237 4.2. Phone number exchange 239 GRIC members submit information both about themselves and their POPs 240 to the GRIC secretariat, which is run by AimQuest. The GRIC secre- 241 tariat then compiles a new phone book and provides updates on the GRIC 242 FTP and Web servers. 244 GRIC users then download the phone numbers either in Windows .ini file 245 format (viewable via the AimQuest Ranger phone book), or in HTML 246 (viewable via a Web browser). 248 4.3. Phone book compilation 250 GRIC phone books are compiled manually, and represent a concatenation 251 of available numbers from all the members of the roaming consortium, 252 with no policy application. As new POPs come online, the numbers are 253 forwarded to GRIC, which adds them to the phone book servers. 255 4.4. Phone book update 257 Phone numbers in the AimQuest Ranger phone book are updated automati- 258 cally. The AimTraveler server includes an address book which contains 259 the phone numbers of all the roaming consortium members. 261 4.5. Connection management 263 The AimTraveler and AimQuest Ranger software supports SLIP and PPP, as 264 well as PAP and CHAP authentication. 266 4.6. Authentication 268 GRIC implements distributed authentication, utilizing the user's e- 269 mail address as the userID (i.e. "liu@Aimnet.com") presented to the 270 remote NAS device. The AimQuest Ranger software takes care of present- 271 ing the e-mail address as the userID for PAP or CHAP authentication. 273 After the initial PPP authentication exchange, the userID, domain, and 274 pasword information (or in the case of CHAP, the challenge and the 275 response) are then passed by the NAS to the AimTraveler Authentication 276 Server which supports both TACACS+ and RADIUS. 278 If the authentication request comes from a regular customer login, 279 normal user id and password authentication is performed. If the user 280 requesting authentication is a "roamer," (has a userID with an @ and 281 domain name), the authentication server sends an query to the closest 282 routing server. When AimTraveler Routing Server receives the authenti- 283 cation request, it first authenticates the AAS sending the request, 284 and if this is successful, it checks its authentication server table. 285 If it is able to match the domain of the user to that of a "Home ISP", 286 then the Home ISP authentication server's routing information are sent 287 back to the local ISP's authentication server. Based on the informa- 288 tion received from the routing server, the AAS makes an authenti- 289 cation request to the user's Home ISP AAS for user id and pass- 290 word verification. 292 If the user is a valid user, the Home ISP authentication server sends 293 a "permission granted" message back to the Local ISP authentication 294 server. The Local ISP authentication server then requests the NAS to 295 grant the user a dynamic IP address from its address pool. If the 296 username or password is incorrect, the Home ISP AAS will send a rejec- 297 tion message to the Local ISP AAS, and the user will be dropped by the 298 NAS. 300 If multiple routing servers are installed, and the query to the first 301 routing server does not result in a match, the query is forwarded to 302 the next routing server. The server queries are cached on the routing 303 servers, improving speed for repeated queries. The cache is sustained 304 until a routing server table entry is updated or deleted. Updating or 305 deleting results in a message to all neighbor routing servers to 306 delete their caches. 308 The local authentication server also receives the accounting data from 309 the NAS. If the data is for a regular customer login, the data is 310 written to the Local ISP AAS log file. If the data is for a "roamer," 311 the data is written to three places: the Local ISP AAS log file, the 312 Home ISP AAS log file, and the ARS log file. 314 If the local ISP authentication server has caching turned on, then it 315 will cache information on Home ISP authentication server configura- 316 tions sent by the routing server. This means that if the same domain 317 is queried again, the local authentication server does not need to 318 query the routing server again. The local cache is cleared when the 319 local authentication server receives an update message from the rout- 320 ing server or system manager. 322 4.7. NAS Configuration/Authorization 324 AimTraveler is comprised of two components, a Client(AAS) and a 325 Server(ARS). 327 The AimTraveler Client acts as the PPP dial-up authentication server. 328 When it detects an '@' sign in the userID field, it queries the 329 AimTraverler Server for routing information, then forwards the 330 authentication request to user's home authentication server. The Aim- 331 Traveler Server, a centralized routing server, contains the autho- 332 rized ISP's domain name, authentication servers and other informa- 333 tion. 335 The AimTraveler currently supports RADIUS and TACACS+, and could 336 be extended to support other authentication protocols. It also 337 receives all the accounting records, which are subsequently used as 338 input data for billing. 340 Since ISPs' NAS devices may be configured differently, the attributes 341 returned by the home ISP AAS are discarded. 343 4.8. Address assignment and routing 345 All addresses in GRIC are assigned dynamically from within the address 346 pool of the local ISP. Static addresses and routed LAN connections 347 will be considered in the future, when GRIC offers corporate roaming 348 service. 350 4.9. Security 352 The user's password is hashed with MD5 before being sent from the 353 Local ISP AAS to the Home ISP AAS. An encryption key is shared 354 between the AAS and ARS. The current version of AimTraveler AAS does 355 not support token cards or tunneling protocols. 357 4.10. Accounting 359 The AimTraveler Authentication Server (AAS) software can act as either 360 a RADIUS or TACACS+ accounting server. When accounting information is 361 received from the NAS, the local AimTraveler Authentication Server 362 (AAS) sends accounting data (user name, domain name, login time) to 363 both the Central Accounting Server (part of the ARS) and the user's 364 Home ISP AimTraveler authentication server. In the case of GRIC, the 365 Central Accounting Server is run by AimQuest. 367 The data sent to the central accounting server and home ISP are iden- 368 tical except for the form of user id and time stamp. For a traveler 369 whose home ISP is in the US, but who is traveling in Japan, the Local 370 (Japanese) ISP AimTraveler authentication server will receive an 371 accounting record timestamped with Japan time while the Home (US) ISP 372 AimTraveler authentication server will receive an accounting record 373 timestamped with the appropriate US timezone. 375 The accounting data includes 2 new attributes for settlement report- 376 ing: 378 Attribute Number Type 379 --------- ------ ---- 381 Roaming-Server-ID 101 string 382 Isp-ID 102 string 384 The Roaming-Server-ID attribute identifies the AAS sending the authen- 385 tication request. The Isp-ID attribute identifies the local ISP. 386 Using this information the home ISP can track the roaming activities 387 of its users (where their users are logging in). 389 The AimTraveler Server running at AimQuest keeps a record of all 390 roaming transactions, which are used as input to the settlement and 391 billing process. At the end of each month, AimQuest provides a roam- 392 ing transaction summary to GRIC members using AIMS. The AIMS software 393 is configurable so that it takes into account the settlement rules 394 agreed to by GRIC members. 396 5. i-Pass implementation 398 5.1. Overview 400 i-Pass Alliance Inc., based in Palo Alto, California has developed and 401 operates a service for global roaming between Internet service 402 providers. The service is currently in field trials. 404 i-Pass Alliance Inc. has additional offices in Toronto, Hong Kong, and 405 London. More information on i-Pass can be obtained from 406 http://www.ipass.com. 408 The i-Pass network consists of a number of servers that provide real- 409 time authentication services to member ISPs. Authentication requests 410 and accounting records for roaming users are encrypted and sent to an 411 i-Pass server where they are logged, and then forwarded to a home ISP 412 for authentication and/or logging. 414 Periodically, i-Pass reconciles all accounting records, generates 415 billing statements, and acts as a single point for collecting and 416 remitting payments. 418 i-Pass provides its service only to ISPs. It does not attempt to 419 establish a business relationship with individual-user customers of 420 those ISPs. 422 5.2. Access Point Database (APD) 424 i-Pass maintains a list of roaming access points in an Oracle 425 database. This list is searchable by geographical region using a web 426 browser, and may be downloaded in its entirety using FTP. The informa- 427 tion stored for each access point includes: 429 Name of service provider 430 Country 431 State or Province 432 City or Region 433 Telephone number 434 Technical support phone number 435 Service types available 436 Technical information (help file) 437 Service pricing information 439 i-Pass member ISPs may update their information in the APD using a 440 secure web interface. 442 5.3. Phone number presentation 444 i-Pass provides information and tools to Internet Service Providers 445 and dialer application developers to assist them in integrating the i- 446 Pass access point database into their software. 448 i-Pass does not intend to be a primary developer of dialer applica- 449 tions, as it believes this requirement is best met by the above par- 450 ties. 452 5.4. Authentication 454 There are three entities involved in servicing an authentication 455 request: 457 Local ISP At the local ISP, the authentication server is modified to 458 recognize user IDs of the form username@auth_domain as being 459 remote authentication requests. These requests are for- 460 warded to an i-Pass server. 462 i-Pass Server 463 The i-Pass server receives the authentication request, logs 464 it, and forwards it to the home ISP identified by the 465 auth_domain portion of the user ID. 467 Home ISP The home ISP receives the authentication request, performs 468 authentication using its normal authentication method, and 469 returns a YES/NO response to the i-Pass server, which in 470 turn forwards the reply to the originating ISP. 472 i-Pass provides software components which run on the authentication 473 servers of the local and home ISPs. Each member ISP must integrate 474 these components with the native authentication method being used by 475 the ISP. To simplify this task, i-Pass has developed "drop-in" inter- 476 faces for the most commonly used authentication methods. At the date 477 of writing, the following interfaces are supported: 479 RADIUS (standard Livingston distribution) 480 Merit RADIUS 481 TACACS+ 482 Xylogics erpcd (Versions 10 and 11) 484 A generic interface is also provided which authenticates based on the 485 standard UNIX password file. This is intended as a starting point for 486 ISPs using authentication methods other than those listed above. 488 The software integration effort for a typical ISP is on the order of 489 2-5 man-days including testing. Platforms currently supported include 490 Solaris 2.[45], BSDI, and Digital Unix. 492 5.5. Accounting 494 Accounting transactions are handled in the same way as authentication 495 requests. In addition to being logged at the i-Pass servers, account- 496 ing transactions are sent in real-time to the home ISP. This is 497 intended to allow ISPs to update users' credit limit information on a 498 real-time basis (to the extent that this capability is supported by 499 their billing and accounting systems). 501 Settlement is performed periodically (initially once a month). The 502 settlement process involves calculating the costs associated with each 503 individual session, and aggregating them for each ISP. A net amount 504 is then calculated which is either due from i-Pass to the ISP, or from 505 the ISP to i-Pass, depending on the actual usage pattern. 507 The following reports are supplied to member ISPs: 509 A Monthly Statement showing summaries of usage, 510 service provided, and any adjustments along with the 511 net amount owing. 513 A Call Detail Report showing roaming usage by the ISP's 514 customers. 516 A Service Provided report showing detailed usage of 517 the ISP's facilities by remote users. 519 The above reports are generated as ASCII documents to facilitate 520 delivery by electronic means (e.g. e-mail) as well as hard-copy. 522 The Call Detail Report is also generated as a comma-delimited ASCII 523 file suitable for import into the ISP's billing database. (The Call 524 Detail Report will normally be used by the ISP to generate end-user 525 billing for roaming usage). 527 5.6. Security 529 All transactions between ISPs and the i-Pass servers are encrypted 530 using the SSL protocol. Public key certificates are verified at both 531 the client and server. (i-Pass issues these certificates and acts as 532 the Certification Authority). 534 Transactions are also verified based on a number of other criteria 535 such as source IP address. 537 6. ChinaNet implementation 539 ChinaNet, owned by China Telecom, is China's largest Internet back- 540 bone. Constructed by Asiainfo, a Dallas based system integration com- 541 pany, it has 31 backbone nodes in 31 Chinese provincial capital 542 cities. Each province is building its own provincial network, has its 543 own dialup servers, and administers its own user base. 545 In order to allow ChinaNet users to be able to access nodes outside 546 their province while traveling, a nationwide roaming system has been 547 implemented. The roaming system was developed by AsiaInfo, and is 548 based on the RADIUS protocol. 550 6.1. Phone number presentation 552 Since China Telecom uses one phone number (163) for nationwide Inter- 553 net access, most cities have the same Internet access number. There- 554 fore a phone book is not currently required for the ChinaNet implemen- 555 tation. A web-based phone book will be added in a future software 556 release in order to support nationwide ISP/CSP telephone numbers and 557 HTTP server addresses. 559 6.2. Connection management 561 The current roaming client and server supports both PPP and SLIP. 563 6.3. Address assignment and routing 565 ChinaNet only supports dynamic IP address assignment for roaming 566 users. In addition, static addresses are supported for users authenti- 567 cating within their home province. 569 6.4. Authentication 571 When user accesses a local NAS, it provides its userID either as 572 "username" or "username@realm". The NAS will pass the userID and 573 password to the RADIUS proxy/server. If the "username" notation is 574 used, the Radius proxy/server will assume that the user is a local 575 user and will handle local authentication accordingly. If "user- 576 name@realm" is used, the RADIUS proxy/server will process it as a 577 roaming request. 579 When the RADIUS proxy/server handles a request from a roaming user, it 580 will first check the cache to see if the user information is already 581 stored there. If there is a cache hit, the RADIUS proxy/server do the 582 local authentication accordingly. If it does not find user informa- 583 tion in its cache, it will act as a proxy, forwarding the authentica- 584 tion request to the home RADIUS server. When the home RADIUS server 585 responds, the local server will forward the response to the NAS. If 586 the user is authenticated by the home server, the local RADIUS proxy 587 will cache the user information for a period of time (3 days by 588 default). 590 Caching is used to avoid frequent proxying of requests and responses 591 between the local RADIUS proxy and the home RADIUS server. When the 592 home RADIUS server sends back a valid authentication response, the 593 local RADIUS proxy/server will cache the user information for a period 594 of time (3 days by default). When the user next authenticates 595 directly against the home RADIUS server, the home RADIUS server will 596 send a request to the local server or servers to clear the user's 597 information from the cache. 599 6.4.1. Extended hierarchy 601 In some provinces, the local telecommunications administration 602 (Provincial ISP) further delegates control to county access nodes, 603 creating another level of hierarchy. This is done to improve scalabil- 604 ity and to avoid having the provincial ISP databases grow too large. 605 In the current implementation, each provincial ISP maintains its own 606 central RADIUS server, including information on all users in the 607 province, while county nodes maintain distributed RADIUS servers. For 608 intra-province roaming requests the local RADIUS proxy/server will 609 directly forward the request to the home RADIUS server. 611 However, for inter-province roaming requests, the local RADIUS server 612 does not forward the request directly to the home RADIUS server. 613 Instead, the request is forwarded to the central provincial RADIUS 614 server for the home province. This implementation is suitable only 615 when county level ISPs do not mind combining and sharing their user 616 information. In this instance, this is acceptable, since all county 617 level ISPs are part of China Telecom. In a future release, this multi- 618 layer hierarchy will be implemented using multi-layer proxy RADIUS, in 619 a manner more resembling DNS. 621 6.5. Security 623 Encryption is used between the local RADIUS proxy/server and the home 624 RADIUS server. Public/Private key encryption will be supported in the 625 next release. IP tunneling and token card support is under considera- 626 tion. 628 6.6. Accounting 630 Accounting information is transferred between the local RADIUS 631 accounting proxy/server and home RADIUS accounting server. Every day 632 each node sends a summary accounting information record to a central 633 server in order to support nationwide settlement. The central server 634 is run by the central Data Communication Bureau of China Telecom. 635 Every month the central server sends the settlement bill to the 636 provincial ISPs. 638 6.7. Inter-ISP/CSP roaming 640 ChinaNet supports both ISP and CSP (Content Service Provider) roaming 641 on its system. For example, Shanghai Online, a Web-based commercial 642 content service, uses RADIUS for authentication of ChinaNet users who 643 do not have a Shanghai Online account. In order to support this, the 644 Shanghai Online servers function as a RADIUS client authenticating 645 against the home RADIUS server. When users access a protected document 646 on the HTTP server, they are prompted to send a username/password for 647 authentication. The user then responds with their userID in "user- 648 name@realm" notation. 650 A CGI script on the HTTP server then acts as a RADIUS authentication 651 client, sending the request to the home RADIUS server. After the home 652 RADIUS server responds, the CGI script passes the information to the 653 local authentication agent. From this point forward, everything is 654 taken care of by the local Web authentication mechanism. 656 7. Microsoft implementation 658 Microsoft's roaming implementation was originally developed in order 659 to support the Microsoft Network (MSN), which now offers Internet 660 access in seven countries: US, Canada, France, Germany, UK, Japan, and 661 Australia. In each of these countries, service is offered in 662 cooperation with access partners. Since users are able to use the 663 access partner networks while maintaining a customer-vendor relation- 664 ship with MSN, this implementation fits within the definition of roam- 665 ing as used in this document. 667 7.1. Implementation overview 669 The first version of the Microsoft roaming software was deployed by 670 the MSN partners in April, 1996. This version included a Phone Book 671 manager tool running under Windows 95, as well as a RADIUS 672 server/proxy implementation running under Windows NT; TACACS+ is cur- 673 rently not supported. Additional components now under development 674 include a Connection Manager client for Windows 95 as well as an HTTP- 675 based phone book server for Windows NT. The Phone Book manager tool is 676 also being upgraded to provide for more automated phone book compila- 677 tion. 679 7.2. Phone number presentation 681 The Connection Manager is responsible for the presentation and updat- 682 ing of phone numbers, as well as for dialing and making connections. 683 In order to select phone numbers, users are asked to select the 684 desired country and region/state. Phone numbers are then presented in 685 the area selected. The primary numbers are those from the users ser- 686 vice provider which match the service type (Analog, ISDN, Analog & 687 ISDN), country and region/state selected. The other numbers (selected 688 clicking on the More button) are those for other service providers 689 that have a roaming agreement with the users service provider. 691 7.2.1. Cost data 693 Cost data is not presented to users along with the phone numbers. How- 694 ever, such information may be made available by other means, such as 695 via a Web page. 697 7.2.2. Default phone book format 699 The Connection Manager supports the ability to customize the phone 700 book format, and it is expected that many ISPs will make use of this 701 capability. However, for those who wish to use it "off the shelf" a 702 default phone book format is provided. The default phone book is com- 703 prised of several files, including: 705 Service profile 706 Phone Book 707 Region file 709 The service profile provides information on a given service, which may 710 be an isolated Internet Service Provider, or may represent a roaming 711 consortium. The service profile, which is in .ini file format, is com- 712 prised of the following information: 714 The name of the service 715 The filename of the service's big icon 716 The filename of the service's little icon 717 A description of the service 718 The service phone book filename 719 The service phone book version number 720 The service regions file 721 The URL of the service phone book server 722 The prefix used by the service (i.e. "MSN/aboba") 723 The suffix or domain used by the service (i.e. "aboba@msn.com") 724 Whether the user name is optional for the service 725 Whether the password is optional for the service 726 Maximum length of the user name for the service 727 Maximum length of the password for the service 728 Information on service password handling (lowercase, mixed case, etc.) 729 Number of redials for this service 730 Delay between redials for this service 731 References to other service providers that have roaming agreements 732 The service profile filenames for each of the references 733 Mask and match phone book filters for each of the references 734 (these are 32 bit numbers that are applied against the capability flags in the phone book) 735 The dial-up connection properties configuration 736 (this is the DUN connectoid name) 738 The phone book file is a comma delimited ASCII file containing the 739 following data: 741 Unique number identifying a particular record (Index) 742 Country ID 743 A zero-base index into the region file 744 City 745 Area code 746 Local phone number 747 Minimum Speed 748 Maximum speed 749 Capability Flags: 750 Bit 0: 0=Toll, 1=Toll free 751 Bit 1: 0=X25, 1=IP 752 Bit 2: 0=Analog, 1=No analog support 753 Bit 3: 0=no ISDN support, 1=ISDN 754 Bit 4: 0 755 Bit 5: 0 756 Bit 6: 0=No Internet access, 1=Internet access 757 Bit 7: 0=No signup access, 1=Signup access 758 Bit 8-31: reserved 759 The filename of the dialup network file 760 (typically refers to a script associated with the number) 762 A sample phone book file is shown below: 764 65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile 765 200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10, 766 200133,1,1,Birmingham,205,5551212,9600,28800,0,10, 767 130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile 768 65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile 770 7.2.3. Additional attributes 772 As described previously, it is likely that some ISPs will require 773 additional phone number attributes or provider information beyond that 774 supported in the default phone book format. Attributes of interest 775 may vary between providers, or may arise as a result of the introduc- 776 tion of new technologies. As a result, the set of phone number 777 attributes is likely to evolve over time, and extensibility in the 778 phone book format is highly desirable. 780 For example, in addition to the attributes provided in the default 781 phone book, the following additional attributes have been requested by 782 customers: 784 Multicast support flag 785 External/internal flag (to differentiate display between the 786 "internal" or "other" list box) 787 Priority (for control of presentation order) 788 Modem protocol capabilities (V.34, V.32bis, etc.) 789 ISDN protocol capabilities (V.110, V.120, etc.) 790 No password flag (for numbers using telephone-based billing) 791 Provider name 793 7.2.4. Addition of information on providers 795 The default phone book does not provide a mechanism for display of 796 information on the individual ISPs within the roaming consortium, only 797 for the consortium as a whole. For example, the provider icons (big 798 and little) are included in the service profile. The service descrip- 799 tion information is expected to contain the customer support number. 800 However, this information cannot be provided on an individual basis 801 for each of the members of a roaming consortium. Additional informa- 802 tion useful on a per-provider basis would include: 804 Provider voice phone number 805 Provider icon 806 Provider fax phone number 807 Provider customer support phone number 809 7.3. Phone number exchange 811 Currently phone number exchange is not supported by the phone book 812 server. As a result, in the MSN implementation, phone number exchange 813 is handled manually. As new POPs come online, the numbers are for- 814 warded to MSN, which tests the numbers and approves them for addition 815 to the phone book server. Updated phone books are produced and loaded 816 on the phone book server on a weekly basis. 818 7.4. Phone book compilation 820 The Phone Book Manager tool was created in order to make it easier for 821 the access partners to create and update their phone books. It sup- 822 ports addition, removal, and editing of phone numbers, generating both 823 a new phone book, as well as associated difference files. 825 With version 1 of the Phone Book Administration tool, phone books are 826 compiled manually, and represent a concatenation of available numbers 827 from all partners, with no policy application. With version 1, the 828 updates are prepared by the partners and forwarded to MSN, which tests 829 the numbers and approves them for addition to the phone book. The 830 updates are then concatenated together to form the global update file. 832 The new version of the Phone Book Administration tool automates much 833 of the phone book compilation process, making it possible for phone 834 book compilation to be decentralized with each partner running their 835 own phone book server. Partners can then maintain and test their indi- 836 vidual phone books and post them on their own Phone Book Server. 838 7.5. Phone book update 840 There is a mechanism to download phone book deltas, as well as to 841 download arbitrary executables which can perform more complex update 842 processing. Digital signatures are only used on the downloading of 843 executables, since only these represent a security threat - the Con- 844 nection Manager client does not check for digital signatures on deltas 845 because bogus deltas can't really cause any harm. 847 The Connection Manager updates the phone book each time the user logs 848 on. This is accomplished via an HTTP GET request to the phone book 849 server. When the server is examining the request, it can take into 850 account things like the OS version on the client, the language on the 851 client, the version of Connection Manager on the client, and the ver- 852 sion of the phone book on the client, in order to determine what it 853 wants to send back. 855 In the GET response, the phone book server responds with the differ- 856 ence files necessary to update the client's phone book to the latest 857 version. The client then builds the new phone book by successively 858 applying these difference files. This process results in the update 859 of the entire phone book, and is simple enough to allow it to be eas- 860 ily implemented on a variety of HTTP servers, either as a CGI script 861 or (on NT) as an ISAPI DLL. 863 The difference files used in the default phone book consist of a list 864 of phone book entries, each uniquely identified by their index number. 865 Additions consist of phone book entries with all the information filed 866 in; deletions are signified by entries with all entries zeroed out. A 867 sample difference file is shown below: 869 65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile 870 200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10, 871 200133,0,0,0,0,0,0,0,0,0 872 130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile 873 65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile 875 7.6. Connection management 877 The Connection Manager can support any protocol which can be config- 878 ured via use of Windows Dialup Networking, including PPP and SLIP run- 879 ning over IP. The default setting is for the IP address as well as 880 the DNS server IP address to be assigned by the NAS. The DNS server 881 assignment capability is described in [1]. 883 7.7. Authentication 885 The Connection Manager client and RADIUS proxy/server both support 886 suffix style notation (i.e. "aboba@msn.com"), as well as a prefix 887 notation ("MSN/aboba"). 889 The prefix notation was developed for use with NAS devices with small 890 maximum userID lengths. For these devices the compactness of the pre- 891 fix notation significantly increases the number of characters avail- 892 able for the userID field. However, as an increasing number of NAS 893 devices are now supporting 253 octet userIDs (the maximum supported by 894 RADIUS) the need for prefix notation is declining. 896 After receiving the userID from the Connection Manager client, the NAS 897 device passes the userID/domain and password information (or in the 898 case of CHAP, the challenge and the response) to the RADIUS proxy. The 899 RADIUS proxy then checks if the domain is authorized for roaming by 900 examining a static configuration file. If the domain is authorized, 901 the RADIUS proxy then forwards the request to the appropriate RADIUS 902 server. The domain to server mapping is also made via a static config- 903 uration file. 905 While static configuration files work well for small roaming consor- 906 tia, for larger consortia static configuration will become tedious. 907 Potentially more scalable solutions include use of DNS SRV records for 908 the domain to RADIUS server mapping. 910 7.8. NAS configuration/authorization 912 Although the attributes returned by the home RADIUS server may make 913 sense to home NAS devices, the local NAS may be configured differ- 914 ently, or may be from a different vendor. As a result, it may be nec- 915 essary for the RADIUS proxy to edit the attribute set returned by the 916 home RADIUS server, in order to provide the local NAS with the appro- 917 priate configuration information. The editing occurs via attribute 918 discard and insertion of attributes by the proxy. 920 Alternatively, the home RADIUS server may be configured not to return 921 any network-specific attributes, and to allow these to be inserted by 922 the local RADIUS proxy. 924 Attributes most likely to cause conflicts include: 926 Framed IP Address 927 Framed IP Netmask 928 Framed Routing 929 Framed Route 930 Filter ID 931 Vendor Specific 932 Session Timeout 933 Idle Timeout 934 Termination Action 936 Conflicts relating to IP address assignment and routing are very com- 937 mon. Where dynamic address assignment is used, an IP address pool 938 appropriate for the local NAS can be substituted for the IP address 939 pool designated by the home RADIUS server. 941 However, not all address conflicts can be resolved by editing. In 942 some cases, (i.e., assignment of a static network address for a LAN) 943 it may not be possible for the local NAS to accept the home RADIUS 944 server's address assignment, yet the roaming hosts may not be able to 945 accept an alternative assignment. 947 Filter IDs also pose a problem. It is possible that the local NAS may 948 not implement a filter corresponding to that designated by the home 949 RADIUS server. Even if an equivalent filter is implemented, in order 950 to guarantee correct operation, the proxy's configuration must track 951 changes in the filter configurations of each of the members of the 952 roaming consortium. In practice this is likely to be unworkable. 953 Direct upload of filter configuration is not a solution either, 954 because of the wide variation in filter languages supported in today's 955 NAS devices. 957 Since by definition vendor specific attributes have meaning only to 958 devices created by that vendor, use of these attributes is problematic 959 within a heterogeneous roaming consortium. While it is possible to 960 edit these attributes, or even to discard them or allow them to be 961 ignored, this may not always be acceptable. In cases where vendor spe- 962 cific attributes relate to security, it may not be acceptable for the 963 proxy to modify or discard these attributes; the only acceptable 964 action may be for the local NAS to drop the user. Unfortunately, 965 RADIUS does not distinguish between mandatory and optional attributes, 966 so that there is no way for the proxy to take guidance from the 967 server. 969 Conflicts over session or idle timeouts may result if since both the 970 local and home ISP feel the need to adjust these parameters. While 971 the home ISP may wish to adjust the parameter to match the user's 972 software, the local ISP may wish to adjust it to match its own service 973 policy. As long as the desired parameters do not differ too greatly, a 974 compromise is often possible. 976 7.9. Address assignment and routing 978 While the Connection Manager software supports both static and dynamic 979 address assignment, in the MSN implementation, all addresses are 980 dynamically assigned. 982 However, selected partners also offer LAN connectivity to their cus- 983 tomers, usually via static address assignment. However, these accounts 984 do not have roaming privileges since no mechanism has been put in 985 place for allowing these static routes to move between providers. 986 Users looking to do LAN roaming between providers are encouraged to 987 select a router supporting Network Address Translation (NAT). NAT ver- 988 sions implemented in several low-end routers are compatible with the 989 dynamic addressing used on MSN, as well as supporting DHCP on the LAN 990 side. 992 7.10. Security 994 The RADIUS proxy/server implementation does not support token cards or 995 tunneling protocols. 997 7.11. Accounting 999 In the MSN roaming implementation, the accounting data exchange pro- 1000 cess is specified in terms of an accounting record format, and a 1001 method by which the records are transferred from the partners to MSN, 1002 which acts as the settlement agent. Defining the interaction in terms 1003 of record formats and transfer protocols implies that the partners do 1004 not communicate with the settlement agent using NAS accounting proto- 1005 cols. As a result, accounting protocol interoperability is not be 1006 required. 1008 However, for this advantage to be fully realized, it is necessary for 1009 the accounting record format to be extensible. This makes it more 1010 likely that the format can be adapted for use with the wide variety of 1011 accounting protocols in current use (such as SNMP, syslog, RADIUS, and 1012 TACACS+), as well as future protocols. After all, if the record format 1013 cannot express the metrics provided by a particular partner's account- 1014 ing protocol, then the record format will not be of much use for a 1015 heterogeneous roaming consortium. 1017 7.11.1. Accounting record format 1019 The Microsoft RADIUS proxy/server supports the ability to customize 1020 the accounting record format, and it is expected that some ISPs will 1021 make use of this capability. However for those who want to use it "off 1022 the shelf" a default accounting record format is provided. The 1023 accounting record includes information provided by RADIUS: 1025 User Name (String; the user's ID, including prefix or suffix) 1026 NAS IP address (Integer; the IP address of the user's NAS) 1027 NAS Port (Integer; identifies the physical port on the NAS) 1028 Service Type (Integer; identifies the service provided to the user) 1029 NAS Identifier (Integer; unique identifier for the NAS) 1030 Status Type (Integer; indicates session start and stop, 1031 as well as accounting on and off) 1032 Delay Time (Integer; time client has been trying to send) 1033 Input Octets (Integer; in stop record, octets received from port) 1034 Output Octets (Integer; in stop record, octets sent to port) 1035 Session ID (Integer; unique ID linking start and stop records) 1036 Authentication (Integer; indicates how user was authenticated) 1037 Session Time (Integer; in stop record, seconds of received service) 1038 Input Packets (Integer; in stop record, packets received from port) 1039 Output Packets (Integer; in stop record, packets sent to port) 1040 Termination Cause (Integer; in stop record, indicates termination cause) 1041 Multi-Session ID (String; for linking of multiple related sessions) 1042 Link Count (Integer; number of links up when record was generated) 1043 NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 1045 However, since this default format is not extensible, it cannot easily 1046 be adapted to protocols other than RADIUS, services other than dialup 1047 (i.e. dedicated connections) or rated events (i.e. file downloads). 1048 This is a serious limitation, and as a result, customers have 1049 requested a more general accounting record format. 1051 7.11.2. Transfer mechanism 1053 Prior to being transferred, the accounting records are compressed so 1054 as to save bandwidth. The transfer of accounting records is handled 1055 via FTP, with the transfer being initiated by the receiving party, 1056 rather than by the sending party. A duplicate set of records is kept 1057 by the local ISP for verification purposes. 1059 8. FidoNet implementation 1061 Since its birth in 1984, FidoNet has supported phone book synchroniza- 1062 tion among its member nodes, which now number approximately 35,000. 1063 As a non-IP dialup network, FidoNet does not provide IP services to 1064 members, and does not utilize IP-based authentication technology. 1065 Instead member nodes offer bulletin-board services, including access 1066 to mail and conferences known as echoes. 1068 In order to be able to communicate with each other, FidoNet member 1069 systems require a sychronized phone book, known as the Nodelist. The 1070 purpose of the Nodelist is to enable resolution of FidoNet addresses 1071 (expressed in the form zone:network/node, or 1:161/445) to phone num- 1072 bers. As a dialup network, FidoNet requires phone numbers in order to 1073 be deliver mail and conference traffic. 1075 In order to minimize the effort required in regularly synchronizing a 1076 phone book of 35,000 entries, the weekly Nodelist updates are trans- 1077 mitted as difference files. These difference files, known as the 1078 Nodediff, produce the Nodelist for the current week when applied to 1079 the previous week's Nodelist. In order to minimize transfer time, 1080 Nodediffs are compressed prior to transfer. 1082 Information on FidoNet, as well as FidoNet Technical Standards (FTS) 1083 documents (including the Nodelist specification) and standards propos- 1084 als are available from the FidoNet archive at http://www.fidonet.org/. 1086 8.1. Scaling issues 1088 With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB 1089 in size, and the weekly Nodediffs are 175 KB. In compressed form, the 1090 Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a 1091 result, the transfer of the Nodediff takes approximately 45 seconds 1092 using a 28,800 bps modem. 1094 In order to improve scalability, the implementation of a domain name 1095 service approach is examined in [8]. The proposal evisages use of a 1096 capability analagous to the DNS ISDN record in order to map names to 1097 phone numbers, coupled with an additional record to provide the 1098 attributes associated with a given name. 1100 8.2. Phone number presentation 1102 While FidoNet member systems perform phone book synchronization, users 1103 need only know the FidoNet address of the systems they wish to con- 1104 tact. As a result users do not need to maintain copies of the Nodelist 1105 on their own systems. This is similar to the Internet, where the DNS 1106 takes care of the domain name to IP address mapping, so that users do 1107 not have to remember IP addresses. 1109 Nevertheless, FidoNet systems often find it useful to be able to pre- 1110 sent lists of nodes, and as a result, FidoNet Nodelist compilers typi- 1111 cally produce a representation of the Nodelist that can be searched or 1112 displayed online, as well as one that is used by the system dialer. 1114 8.2.1. FidoNet Nodelist format 1116 The FidoNet Nodelist format is documented in detail in [3]. The 1117 Nodelist file consists of lines of data as well as comment lines, 1118 which begin with a semi-colon. The first line of the Nodelist is a 1119 general interest comment line that includes the date and the day num- 1120 ber, as well as a 16-bit CRC. The CRC is included so as to allow the 1121 system assembling the new Nodelist to verify its integrity. 1123 Each Nodelist data line contains eight comma separated fields: 1125 Keyword 1126 Zone/Region/Net/Node number 1127 Node name 1128 Location 1129 Sysop name 1130 Phone number 1131 Maximum Baud rate 1132 Flags (optional) 1134 FidoNet Nodelists are arranged geographically, with systems in the 1135 same zone, region, and network being grouped together. As a result, 1136 FidoNet Nodelists do not require a separate regions file. Among other 1137 things, the keyword field can be used to indicate that a system is 1138 temporarily out of service. 1140 Reference [3] discusses Nodelist flags in considerable detail. Among 1141 other things, the flags include information on supported modem modula- 1142 tion and error correction protocols. Reference [4] also proposes a 1143 series of ISDN capability flags, and [5] proposes flags to indicate 1144 times of system availability. 1146 8.3. Phone number exchange 1148 FidoNet coordinators are responsible for maintaining up to date infor- 1149 mation on their networks, regions, and zones. Every week network coor- 1150 dinators submit to their regional coordinators updated versions of 1151 their portions of the Nodelist. The regional coordinators then compile 1152 the submissions from their network coordinators, and submit them to 1153 the zone coordinator. The zone coordinators then exchange their sub- 1154 missions to produce the new Nodelist. As a result, it is possible that 1155 the view from different zones may differ at any given time. 1157 8.3.1. The Nodediff 1159 The format of the Nodediff is discussed in detail in [3]. In preparing 1160 the Nodediffs, network coordinators may transmit only their difference 1161 updates, which can be collated to produce the Nodediff directly. 1163 One weakness in the current approach is that there is no security 1164 applied to the coordinator submissions. This leaves open the possibil- 1165 ity of propagation of fraudulent updates. In order to address this, 1167 [6] proposes addition of a shared secret to the update files. 1169 8.3.2. Addition of nodes 1171 In order to apply for allocation of a FidoNet address and membership 1172 in the Nodelist, systems must demonstrate that they are functioning by 1173 sending mail to the local network coordinator. Once the local network 1174 coordinator receives the application, they then allocate a new FidoNet 1175 address, and add a Nodelist entry. 1177 8.3.3. Deletion of nodes 1179 Since FidoNet nodes are required to be functioning during the zone 1180 mail hour in order to receive mail, and since nodes receive the weekly 1181 Nodelist from their local network coordinators on a weekly basis, 1182 there is a built-in mechanism for discovery of non-functional nodes. 1184 Nodes found to be down are reported to the local network coordinator 1185 and subsequently marked as down within the Nodelist. Nodes remaining 1186 down for more than two weeks may be removed from the Nodelist, at the 1187 discretion of the network coordinator. 1189 8.4. Phone book update 1191 The Nodelist contains the phone numbers and associated attributes of 1192 each participating system. New Nodelists become available on Fridays, 1193 and are made available to participating systems by their local network 1194 coordinators, who in turn receive them from the regional and zone 1195 coordinators. 1197 While it is standard practice for participating systems to get their 1198 Nodelists from their local network coordinators, should the local net- 1199 work coordinator not be available for some reason, either the updates 1200 or the complete Nodelist may be picked up from other network, or 1201 regional coordinators. Please note that since the view from different 1202 zones may differ, nodes wishing to update their Nodelists should not 1203 contact systems from outside their zone. 1205 8.5. Phone book compilation 1207 Once FidoNet systems have received the Nodediff, the apply it to the 1208 previous week's Nodelist in order to prepare a new Nodelist. In order 1209 to receive Nodediffs and compile the Nodelist, the following software 1210 is required: 1212 A FidoNet-compatible mailer implementation, used to transfer files 1213 A Nodelist compiler 1215 One of the purposes of the Nodelist compiler is to apply Nodediffs to 1216 the previous Nodelist in order to produce an updated Nodelist. The 1217 other purpose is to compile the updated Nodelist into the format 1218 required by the particular mailer implementation used by the member 1219 system. It is important to note that while the Nodelist and Nodediff 1220 formats are standardized (FTS-0005), as is the file transfer protocol 1221 (FTS-0001), the compiled format used by each mailer is implementation 1222 dependent. 1224 One reason that compiled formats to differ is the addition of out of 1225 band information to the Nodelist during the compilation process. 1226 Added information includes phone call costs as well as shared secrets. 1228 8.5.1. Cost data 1230 Although cost information is not part of the Nodelist, in compiling 1231 the Nodelist into the format used by the mailer, Nodelist compilers 1232 support the addition of cost information. This information is then 1233 subsequently used to guide mailer behavior. 1235 Since phone call costs depend on the rates charged by the local phone 1236 company, this information is local in nature and is typically entered 1237 into the Nodelist compiler's configuration file by the system adminis- 1238 trator. 1240 8.5.2. Shared secrets 1242 In FidoNet, shared secrets are used for authenticated sessions between 1243 systems. Such authenticated sessions are particularly important 1244 between the local, regional and zone coordinators who handle prepara- 1245 tion and transmission of the Nodediffs. A single shared secret is used 1246 per system. 1248 8.6. Accounting 1250 Within FidoNet, the need for accounting arises primarily from the need 1251 of local, regional and zone coordinators to be reimbursed for their 1252 expenses. In order to support this, utilities have been developed to 1253 account for network usage at the system level according to various 1254 metrics. However, the accounting techniques are not applied at the 1255 user level. Distributed authentication and accounting are not imple- 1256 mented and therefore users may not roam between systems. 1258 9. Acknowledgements 1260 Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest 1261 for useful discussions of this problem space. 1263 10. References 1265 [1] S. Cobb. "PPP Internet Protocol Control Protocol Extensions for 1266 Name Server Addresses" RFC 1877, Microsoft, December 1995. 1268 [2] T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer 1269 Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996. 1271 [3] B. Baker, R. Moore, D. Nugent. "The Distribution Nodelist." 1272 FTS-0005, February, 1996. 1274 [4] A. Lentz. "ISDN Nodelist flags." FSC-0091, June, 1996. 1276 [5] D. J. Thomas. "A Proposed Nodelist flag indicating Online Times 1277 of a Node." FSC-0062, April, 1996. 1279 [6] L. Kolin. "Security Passwords in Nodelist Update Files." 1280 FSC-0055, March, 1991. 1282 [7] R. Gwinn, D. Dodell. "Nodelist Flag Changes Draft Document." 1283 FSC-0009, November, 1987. 1285 [8] R. Heller. "A Proposal for A FidoNet Domain Name Service." 1286 FSC-0069, December, 1992. 1288 [9] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 1289 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 1290 Daydreamer, January, 1997. 1292 [10] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1293 1997. 1295 11. Authors' Addresses 1297 Bernard Aboba 1298 Microsoft Corporation 1299 One Microsoft Way 1300 Redmond, WA 98052 1302 Phone: 206-936-6605 1303 EMail: bernarda@microsoft.com 1305 Juan Lu 1306 AimQuest Corporation 1307 1381 McCarthy Blvd. 1308 Milpitas, California 95035 1310 Phone: 408-273-2730 ext. 2762 1311 EMail: juanlu@aimnet.net 1313 John Alsop 1314 i-Pass Alliance Inc. 1315 555 Bryant Street, #248 1316 Palo Alto, CA 94301 1318 Phone: 415-327-5553 1319 EMail: jalsop@ipass.com 1321 James Ding 1322 Asiainfo 1323 One Galleria Tower 1324 13355 Noel Road, #1340 1325 Dallas, TX 75240 1327 Phone: 214-788-4141 1328 Fax: 214-788-0729 1329 EMail: ding@bjai.asiainfo.com