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