idnits 2.17.00 (12 Aug 2021) /tmp/idnits9345/draft-ietf-roamops-imprev-03.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 (2022-05-14) 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) 2022 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 552 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 857 instances of too long lines in the document, the longest one being 35 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 18 has weird spacing: '...), its areas...' == Line 19 has weird spacing: '... its worki...' == Line 23 has weird spacing: '... and may ...' == Line 24 has weird spacing: '...afts as refer...' == Line 27 has weird spacing: '... To learn...' == (547 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 1549, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1563, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1569, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1573, 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 10 June 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 mate- 25 rial 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 sev- 86 eral of these problem elements. These implementations typically fall 87 into the category of shared use networks or non-IP dialup networks. 89 3.1. Terminology 91 This document frequently uses the following terms: 93 home ISP This is the Internet service provider with whom the user 94 maintains an account relationship. 96 local ISP This is the Internet service provider whom the user calls in 97 order to get access. Where roaming is implemented the local 98 ISP may be different from the home ISP. 100 phone book 101 This 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; Con- 139 nect.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 soft- 144 ware developed by AimQuest. AimQuest Corporation's roaming implementa- 145 tion comprises the following major components: the AimTraveler Authen- 146 tication Server (AAS), the AimTraveler Routing Server (ARS), and the 147 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 153 devices. The AimTraveler Routing Server (ARS) can run anywhere. A sin- 154 gle routing server can be used where centralized routing is desired, 155 or 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 mem- 171 ber ISP) may be accomplished by editing of a configuration file on the 172 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 appro- 219 priate country and provider. They then look up the number and insert 220 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 226 phone book includes a country list, provider list, and POP (phone num- 227 ber) list, as well as detailed provider information, including the 228 cutomer support phone number, and Internet server configuration info. 229 The Phone book, developed with Microsoft VC++, is available for down- 230 load 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 autho- 333 rized 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 355 between the AAS and ARS. The current version of AimTraveler AAS does 356 not support 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 iden- 369 tical 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 roam- 393 ing transaction summary to GRIC members using AIMS. The AIMS software 394 is configurable so that it takes into account the settlement rules 395 agreed to by GRIC members. 397 5. i-Pass implementation 398 5.1. Overview 400 i-Pass Alliance Inc., based in Mountain View, California, has devel- 401 oped and operates a commercial authentication and settlement clearing- 402 house service which provides global roaming between Internet service 403 providers. The service is fully operational. 405 i-Pass Alliance Inc. has additional offices in Toronto, Singapore, and 406 London. More information on i-Pass can be obtained from 407 http://www.ipass.com. 409 The i-Pass network consists of a number of servers that provide real- 410 time authentication services to partner ISPs. Authentication requests 411 and accounting records for roaming users are encrypted and sent to an 412 i-Pass server where they are logged, and then forwarded to a home ISP 413 for authentication and/or logging. 415 Periodically, i-Pass reconciles all accounting records, generates 416 billing statements, and acts as a single point for collecting and 417 remitting payments. 419 i-Pass provides its service only to ISPs and channel partners. It 420 does not attempt to establish a business relationship with individual- 421 user customers of an ISP. 423 5.2. Access Point Database (APD) 425 i-Pass maintains a list of roaming access points in an Oracle 426 database. This list is searchable by geographical region using a Web 427 browser, and may be downloaded in its entirety using FTP. The informa- 428 tion stored for each access point includes: 430 Name of service provider 431 Country 432 State or Province 433 City or Region 434 Telephone number 435 Technical support phone number 436 Service types available 437 Technical information (help file) 438 Service pricing information 440 The Access Point Database is maintained by i-Pass staff, based on 441 input from i-Pass partners. 443 5.3. Phone number presentation 445 i-Pass has developed a Windows application wth a simple point and 446 click interface called the "i-Pass Dial Wizard", which assists end- 447 users in selecting and connecting to a local Internet access point. 449 The Dial Wizard allows users to first select the country in which they 450 are roaming. A list of states, provinces, or other regions in the 451 selected country is then presented. Finally a list of access points 452 within the state or province is presented. The Dial Wizard displays 453 the city name, modem phone number, and price information for each 454 access point within the state or region. 456 When the user selects the desired access point, a Windows 95 "DialUp 457 Networking" icon is created for that access point. If there is a 458 login script associated with the access point, the DialUp Scripting 459 tool is automatically configured. This means that end-users never 460 have to configure any login scripting requirements. 462 The Dial Wizard has a built-in phonebook containing all the i-Pass 463 access points. The phonebook may be automatically refreshed from a 464 master copy located onhe ISPs web site. 466 The Dial Wizard is provided free of charge to i-Pass partners. i-Pass 467 also provides the i-Pass Dial Wizard Customization Kit which allows 468 ISP partners to generate customized versions of the Dial Wizard with 469 their own logo, etc. 471 5.4. Authentication 473 There are three entities involved in servicing an authentication 474 request: 476 Local ISP At the local ISP, the authentication server is modified to 477 recognize user IDs of the form username@auth_domain as being 478 remote authentication requests. These requests are for- 479 warded to an i-Pass server. 481 i-Pass Server 482 The i-Pass server receives the authentication request, logs 483 it, and forwards it to the home ISP identified by the 484 auth_domain portion of the user ID. 486 Home ISP The home ISP receives the authentication request, performs 487 authentication using its normal authentication method, and 488 returns a YES/NO response to the i-Pass server, which in 489 turn forwards the reply to the originating ISP. 491 i-Pass provides software components which run on the authentication 492 servers of the local and home ISPs. Each member ISP must integrate 493 these components with the native authentication method being used by 494 the ISP. To simplify this task, i-Pass has developed "drop-in" inter- 495 faces for the most commonly used authentication methods. At the date 496 of writing, the following interfaces are supported: 498 Livingston RADIUS 499 Ascend RADIUS 500 Merit RADIUS 501 TACACS+ 502 Xylogics erpcd (Versions 10 and 11) 504 A generic interface is also provided which authenticates based on the 505 standard UNIX password file. This is intended as a starting point for 506 ISPs using authentication methods other than those listed above. 508 The software integration effort for a typical ISP is on the order of 509 2-5 man-days including testing. Platforms currently supported 510 include: 512 Solaris 2.5 (Sparc).LI 513 Solaris 2.5 (Intel) 514 BSDI 515 Digital Unix 516 Linux 517 HP/UX 519 ISPs may chooe to provide authentication for their end-users roaming 520 elsewhere, but not to provide access points to the i-Pass network. In 521 this case the software integration effort is greatly reduced and can 522 be as little as 1/2 a man-day. 524 5.5. Accounting 526 Accounting transactions are handled in the same way as authentication 527 requests. In addition to being logged at the i-Pass servers, account- 528 ing transactions are sent in real-time to the home ISP. This is 529 intended to allow ISPs to update users' credit limit information on a 530 real-time basis (to the extent that this capability is supported by 531 their billing and accounting systems). 533 Settlement is performed monthly. The settlement process involves cal- 534 culating the costs associated with each individual session, and aggre- 535 gating them for each ISP. A net amount is then calculated which is 536 either due from i-Pass to the ISP, or from the ISP to i-Pass, depend- 537 ing on the actual usage pattern. 539 The following reports are supplied to member ISPs: 541 A Monthly Statement showing summaries of usage, 542 service provided, and any adjustments along with the 543 net amount owing. 545 A Call Detail Report showing roaming usage by the ISP's 546 customers. 548 A Service Provided report showing detailed usage of 549 the ISP's facilities by remote users. 551 The above reports are generated as ASCII documents and are distributed 552 to i-Pass partners electronically, either by e-mail or from a secure 553 area on the i-Pass web site. Hard-copy output is available on request. 555 The Call Detail Report is also generated as a comma-delimited ASCII 556 file suitable for import into the ISP's billing database. The Call 557 Detail Report will normally be used by the ISP to generate end-user 558 billing for roaming usage. 560 5.6. Security 562 All transactions between ISPs and the i-Pass servers are encrypted 563 using the SSL protocol. Public key certificates are verified at both 564 the client and server. i-Pass issues these certificates and acts as 565 the Cetificate Authority. 567 Transactions are also verified based on a number of other criteria 568 such as source IP address. 570 5.7. Operations 572 i-Pass operates several authentication server sites. Each site con- 573 sists of two redundant server systems located in secure facilities and 574 "close" to the Internet backbone. The authentication server sites are 575 geographically distributed to minimize the possibility of failure due 576 to natural disasters etc. 578 i-Pass maintains a Network Operations Center in Mountain View which is 579 staffed on a 7x24 basis. Its functions include monitoring the i-Pass 580 authentication servers, monitoring authentication servers located at 581 partner facilities, and dealing with problem reports. 583 6. ChinaNet implementation 585 ChinaNet, owned by China Telecom, is China's largest Internet back- 586 bone. Constructed by Asiainfo, a Dallas based system integration com- 587 pany, it has 31 backbone nodes in 31 Chinese provincial capital 588 cities. Each province is building its own provincial network, has its 589 own dialup servers, and administers its own user base. 591 In order to allow hinaNet users to be able to access nodes outside 592 their province while traveling, a nationwide roaming system has been 593 implemented. The roaming system was developed by AsiaInfo, and is 594 based on the RADIUS protocol. 596 6.1. Phone number presentation 598 Since China Telecom uses one phone number (163) for nationwide Inter- 599 net access, most cities have the same Internet access number. There- 600 fore a phone book is not currently required for the ChinaNet implemen- 601 tation. A web-based phone book will be added in a future software 602 release in order to support nationwide ISP/CSP telephone numbers and 603 HTTP server addresses. 605 6.2. Connection management 607 The current roaming client and server supports both PPP and SLIP. 609 6.3. Address assignment and routing 611 ChinaNet only supports dynamic IP address assignment for roaming 612 users. In addition, static addresses are supported for users authenti- 613 cating within their home province. 615 6.4. Authentication 617 When user accesses a local NAS, it provides its userID either as 618 "username" or "username@realm". The NAS will pass the userID and 619 password to the RADIUS proxy/server. If the "username" notation is 620 used, the Radius proxy/server will assume that the user is a local 621 user and will handle local authentication accordingly. If "user- 622 name@realm" is used, the RADIUS proxy/server will process it as a 623 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 648 (Provincial ISP) further delegates control to county access nodes, 649 creating another level of hierarchy. This is done to improve scalabil- 650 ity and to avoid having the provincial ISP databases grow too large. 651 In the current implementation, each provincial ISP maintains its own 652 central RADIUS server, including information on all users in the 653 province, 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 multi- 664 layer hierarchy will be implemented using multi-layer proxy RADIUS, in 665 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 682 provincial 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 "user- 694 name@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 cur- 719 rently not supported. Additional components now under development 720 include a Connection Manager client for Windows 95 as well as an HTTP- 721 based phone book server for Windows NT. The Phone Book manager tool is 722 also being upgraded to provide for more automated phone book compila- 723 tion. 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 IDN), 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 com- 749 prised 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 com- 758 prised 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 806 The filename of the dialup network file 807 (typically refers to a script associated with the number) 809 A sample phone book file is shown below: 811 65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile 812 200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10, 813 200133,1,1,Birmingham,205,5551212,9600,28800,0,10, 814 130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile 815 65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile 817 7.2.3. Additional attributes 819 As described previously, it is likely that some ISPs will require 820 additional phone number attributes or provider information beyond that 821 supported in the default phone book format. Attributes of interest 822 may vary between providers, or may arise as a result of the introduc- 823 tion of new technologies. As a result, the set of phone number 824 attributes is likely to evolve over time, and extensibility in the 825 phone book format is highly desirable. 827 For example, in addition to the attributes provided in the default 828 phone book, the following additional attributes have been requested by 829 customers: 831 Multicast support flag 832 External/internal flag (to differentiate display between the 833 "internal" or "other" list box) 834 Priority (for control of presentation order) 835 Modem protocol capabilities (V.34, V.32bis, etc.) 836 ISDN protocol capabilities (V.110, V.120, etc.) 837 No password flag (for numbers using telephone-based billing) 838 Provider name 840 7.2.4. Addition of information on providers 842 The default phone book does not provide a mechanism for display of 843 information on the individual ISPs within the roaming consortium, only 844 for the consortium as a whole. For example, the provider icons (big 845 and little) are included in the service profile. The service descrip- 846 tion information is expected to contain the customer support number. 847 However, this information cannot be provided on an individual basis 848 for each of the members of a roaming consortium. Additional informa- 849 tion useful on a per-provider basis would include: 851 Provider voice phone number 852 Provider icon 853 Provider fax phone number 854 Provider customer support phone number 856 7.3. Phone number exchange 858 Currently phone number exchange is not supported by the phone book 859 server. As a result, in the MSN implementation, phone number exchange 860 is handled manually. As new POPs come online, the numbers are for- 861 warded to MSN, which tests the numbers and approves them for addition 862 to the phone book server. Updated phone books are produced and loaded 863 on the phone book server on a weekly basis. 865 7.4. Phone book compilation 867 The Phone Book Manager tool was created in order to make it easier for 868 the access partners to create and update their phone books. It sup- 869 ports addition, removal, and editing of phone numbers, generating both 870 a new phone book, as well as associated difference files. 872 With version 1 of the Phone Book Administration tool, phone books are 873 compiled manually, and represent a concatenation of available numbers 874 from all partners, with no policy application. With version 1, the 875 updates are prepared by the partners and forwarded to MSN, which tests 876 the numbers and approves them for addition to the phone book. The 877 updates are then concatenated together to form the global update file. 879 The new version of the Phone Book Administration tool automates much 880 of the phone book compilation process, making it possible for phone 881 book compilation to be decentralized with each partner running their 882 own phone book server. Partners can then maintain and test their indi- 883 vidual phone books and post them on their own Phone Book Server. 885 7.5. Phone book update 887 There is a mechanism to download phone book deltas, as well as to 888 download arbitrary executables which can perform more complex update 889 processing. Digital signatures are only used on the downloading of 890 executables, since only these represent a security threat - the Con- 891 nection Manager client does not check for digital signatures on deltas 892 because bogus deltas can't really cause any harm. 894 The Connection Manager updates the phone book each time the user logs 895 on. This is accomplished via an HTTP GET request to the phone book 896 server. When the server is examining the request, it can take into 897 account things like the OS version on the client, the language on the 898 client, the version of Connection Manager on the client, and the ver- 899 sion of the phone book on the client, in order to determine what it 900 wants to send back. 902 In the GET response, the phone book server responds with the differ- 903 ence files necessary to update the client's phone book to the latest 904 version. The client then builds the new phone book by successively 905 applying these difference files. This process results in the update 906 of the entire phone book, and is simple enough to allow it to be eas- 907 ily implemented on a variety of HTTP servers, either as a CGI script 908 or (on NT) as an ISAPI DLL. 910 The difference files used in the default phone book consist of a list 911 of phone book entries, each uniquely identified by their index number. 912 Additions consist of phone book entries with all the information filed 913 in; deletions are signified by entries with all entries zeroed out. A 914 sample difference file is shown below: 916 65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile 917 200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10, 918 200133,0,0,0,0,0,0,0,0,0 919 130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile 920 65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile 922 7.6. Connection management 924 The Connection Manager can support any protocol which can be config- 925 ured via use of Windows Dialup Networking, including PPP and SLIP run- 926 ning over IP. The default setting is for the IP address as well as 927 the DNS server IP address to be assigned by the NAS. The DNS server 928 assignment capability is described in [1]. 930 7.7. Authentication 932 The Connection Manager client and RADIUS proxy/server both support 933 suffix style notation (i.e. "aboba@msn.com"), as well as a prefix 934 notation ("MSN/aboba"). 936 The prefix notation was developed for use with NAS devices with small 937 maximum userID lengths. For these devices the compactness of the pre- 938 fix notation significantly increases the number of characters avail- 939 able for the userID field. However, as an increasing number of NAS 940 devices are now supporting 253 octet userIDs (the maximum supported by 941 RADIUS) the need for prefix notation is declining. 943 After receiving the userID from the Connection Manager client, the NAS 944 device passes the userID/domain and password information (or in the 945 case of CHAP, the challenge and the response) to the RADIUS proxy. The 946 RADIUS proxy then checks if the domain is authorized for roaming by 947 examining a static configuration file. If the domain is authorized, 948 the RADIUS proxy then forwards the request to the appropriate RADIUS 949 server. The domain to server mapping is also made via a static config- 950 uration file. 952 While static configuration files work well for small roaming consor- 953 tia, for larger consortia static configuration will become tedious. 954 Potentially more scalable solutions include use of DNS SRV records for 955 the domain to RADIUS server mapping. 957 7.8. NAS configuration/authorization 959 Although the attributes returned by the home RADIUS server may make 960 sense to home NAS devices, the local NAS may be configured differ- 961 ently, or may be from a different vendor. As a result, it may be nec- 962 essary for the RADIUS proxy to edit the attribute set returned by the 963 home RADIUS server, in order to provide the local NAS with the appro- 964 priate configuration information. The editing occurs via attribute 965 discard and insertion of attributes by the proxy. 967 Alternatively, the home RADIUS server may be configured not to return 968 any network-specific attributes, and to allow these to be inserted by 969 the local RADIUS proxy. 971 Attributes most likely to cause conflicts include: 973 Framed-IP-Address 974 Framed-IP-Netmask 975 Framed-Routing 976 Framed-Route 977 Filter-Id 978 Vendor-Specific 979 Session-Timeout 980 Idle-Timeout 981 Termination-Action 983 Conflicts relating to IP address assignment and routing are very com- 984 mon. Where dynamic address assignment is used, an IP address pool 985 appropriate for the local NAS can be substituted for the IP address 986 pool designated by the home RADIUS server. 988 However, not all address conflicts can be resolved by editing. In 989 some cases, (i.e., assignment of a static network address for a LAN) 990 it may not be possible for the local NAS to accept the home RADIUS 991 server's address assignment, yet the roaming hosts may not be able to 992 accept an alternative assignment. 994 Filter IDs also pose a problem. It is possible that the local NAS may 995 not implement a filter corresponding to that designated by the home 996 RADIUS server. Even if an equivalent filter is implemented, in order 997 to guarantee correct operation, the proxy's configuration must track 998 changes in the filter configurations of each of the members of the 999 roaming consortium. In practice this is likely to be unworkable. 1000 Direct upload of filter configuration is not a solution either, 1001 because of the wide variation in filter languages supported in today's 1002 NAS devices. 1004 Since by definition vendor specific attributes have meaning only to 1005 devices created by that vendor, use of these attributes is problematic 1006 within a heterogeneous roaming consortium. While it is possible to 1007 edit these attributes, or even to discard them or allow them to be 1008 ignored, this may not always be acceptable. In cases where vendor spe- 1009 cific attributes relate to security, it may not be acceptable for the 1010 proxy to modify or discard these attributes; the only acceptable 1011 action may be for the local NAS to drop the user. Unfortunately, 1012 RADIUS does not distinguish between mandatory and optional attributes, 1013 so that there is no way for the proxy to take guidance from the 1014 server. 1016 Conflicts over session or idle timeouts may result if since both the 1017 local and home ISP feel the need to adjust these parameters. While 1018 the home ISP may wish to adjust the parameter to match the user's 1019 software, the local ISP may wish to adjust it to match its own service 1020 policy. As long as the desired parameters do not differ too greatly, a 1021 compromise is often possible. 1023 7.9. Address assignment and routing 1025 While the Connection Manager software supports both static and dynamic 1026 address assignment, in the MSN implementation, all addresses are 1027 dynamically assigned. 1029 However, selected partners also offer LAN connectivity to their cus- 1030 tomers, usually via static address assignment. However, these accounts 1031 do not have roaming privileges since no mechanism has been put in 1032 place for allowing these static routes to move between providers. 1033 Users looking to do LAN roaming between providers are encouraged to 1034 select a router supporting Network Address Translation (NAT). NAT ver- 1035 sions implemented in several low-end routers are compatible with the 1036 dynamic addressing used on MSN, as well as supporting DHCP on the LAN 1037 side. 1039 7.10. Security 1041 The RADIUS proxy/server implementation does not support token cards or 1042 tunneling protocols. 1044 7.11. Accounting 1046 In the MSN roaming implementation, the accounting data exchange pro- 1047 cess is specified in terms of an accounting record format, and a 1048 method by which the records are transferred from the partners to MSN, 1049 which acts as the settlement agent. Defining the interaction in terms 1050 of record formats and transfer protocols implies that the partners do 1051 not communicate with the settlement agent using NAS accounting proto- 1052 cols. As a result, accounting protocol interoperability is not be 1053 required. 1055 However, for this advantage to be fully realized, it is necessary for 1056 the accounting record format to be extensible. This makes it more 1057 likely that the format can be adapted for use with the wide variety of 1058 accounting protocols in current use (such as SNMP, syslog, RADIUS, and 1059 TACACS+), as well as future protocols. After all, if the record format 1060 cannot express the metrics provided by a particular partner's account- 1061 ing protocol, then the record format will not be of much use for a 1062 heterogeneous roaming consortium. 1064 7.11.1. Accounting record format 1066 The Microsoft RADIUS proxy/server supports the ability to customize 1067 the accounting record format, and it is expected that some ISPs will 1068 make use of this capability. However for those who want to use it "off 1069 the shelf" a default accounting record format is provided. The 1070 accounting record includes information provided by RADIUS: 1072 User Name (String; the user's ID, including prefix or suffix) 1073 NAS IP address (Integer; the IP address of the user's NAS) 1074 NAS Port (Integer; identifies the physical port on the NAS) 1075 Service Type (Integer; identifies the service provided to the user) 1076 NAS Identifier (Integer; unique identifier for the NAS) 1077 Status Type (Integer; indicates session start and stop, 1078 as well as accounting on and off) 1079 Delay Time (Integer; time client has been trying to send) 1080 Input Octets (Integer; in stop record, octets received from port) 1081 Output Octets (Integer; in stop record, octets sent to port) 1082 Session ID (Integer; unique ID linking start and stop records) 1083 Authentication (Integer; indicates how user was authenticated) 1084 Session Time (Integer; in stop record, seconds of received service) 1085 Input Packets (Integer; in stop record, packets received from port) 1086 Output Packets (Integer; in stop record, packets sent to port) 1087 Termination Cause (Integer; in stop record, indicates termination cause) 1088 Multi-Session ID (String; for linking of multiple related sessions) 1089 Link Count (Integer; number of links up when record was generated) 1090 NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 1092 However, since this default format is not extensible, it cannot easily 1093 be adapted to protocols other than RADIUS, services other than dialup 1094 (i.e. dedicated connections) or rated events (i.e. file downloads). 1095 This is a serious limitation, and as a result, customers have 1096 requested a more general accounting record format. 1098 7.11.2. Transfer mechanism 1100 Prior to being transferred, the accounting records are compressed so 1101 as to save bandwidth. The transfer of accounting records is handled 1102 via FTP, with the transfer being initiated by the receiving party, 1103 rather than by the sending party. A duplicate set of records is kept 1104 by the local ISP for verification purposes. 1106 8. Merit Network Implementation 1108 8.1. Overview 1110 MichNet is a regional IP backbone network operated within the state of 1111 Michigan by Merit Network, Inc., a nonprofit corporation based in Ann 1112 Arbor, Michigan. Started in 1966, MichNet currently provides backbone 1113 level Internet connectivity and dial-in IP services to its member and 1114 affiliate universities, colleges, K-12 schools, libraries, government 1115 institutions, other nonprofit organizations, and commercial business 1116 entities. 1118 As of May 1, 1997, MichNet had 11 members and 405 affiliates. Its 1119 shared dial-in service operated 133 sites in Michigan and one in Wash- 1120 ington, D.C, with 4774 dial-in lines. Additional dial-in lines and 1121 sites are being installed daily. 1123 MichNet also provides national and international dial-in services to 1124 its members and affiliates through an 800 number and other external 1125 services contracting with national and global service providers. 1127 The phone numbers of all MichNet shared dial-in sites are published 1128 both on the Merit web site and in the MichNet newsletters. Merit also 1129 provides links to information about the national and international 1130 service sites through their respective providers' web sites. Such 1131 information can be found at http://www.merit.edu/mich- 1132 net/shared.dialin/. 1134 8.1.1. MichNet State-Wide Shared Dial-In Services 1136 Each MichNet shared dial-in service site is owned and maintained by 1137 either Merit or by a member or affiliate organization. All sites must 1138 support PPP and Telnet connections. 1140 Each organization participating in the shared dial-in service is 1141 assigned a realm-name. Typically the realm-name resembles a fully 1142 qualified domain name. Users accessing the shared dial-in service 1143 identify themselves by using a MichNet AccessID which consists of 1144 their local id concatenated with "@" followed by the realm-name - e.g. 1145 user@realm 1147 Merit operates a set of Authentication, Authorization and Accounting 1148 (AAA) servers supporting the RADIUS protocol which are called core 1149 servers. The core servers support all the dial-in service sites and 1150 act as proxy servers to other AAA servers running at the participating 1151 organizations. For security reasons, Merit staff run all core servers; 1152 in particular, the user password is in the clear when the proxy core 1153 server decodes an incoming request and then re-encodes it and forwards 1154 it out again, 1156 The core servers also enforce a common policy among all dial-in 1157 servers. The most important policy is that each provider of access 1158 must make dial-in ports available to others when the provider's own 1159 users do not have a need for them. To implement this policy, the proxy 1160 server distinguishes between realms that are owners and realms that 1161 are guests. 1163 One piece of the policy determining whether the provider's organiza- 1164 tion has need of the port, is implemented by having the proxy core 1165 server track the realms associated with each of the sessions connected 1166 at a particular huntgroup. If there are few ports available (where few 1167 is determined by a formula) then guests are denied access. Guests are 1168 also assigned a time limit and their sessions are terminated after 1169 some amount of time (currently one hour during prime time, two hours 1170 during non-prime time). 1172 The other part of the policy is to limit the number of guests that are 1173 allowed to connect. This is done by limiting the number of simultane- 1174 ous guest sessions for realms. Each realm is allocated a number of 1175 "simultaneous access tokens" - SATs. When a guest session is autho- 1176 rized the end server for the realm decrements the count of available 1177 SATs, and when the session is terminated the count of SATs is incr- 1178 mented. A Merit specific attribute is added to the request by the 1179 core if the session will be a "guest" and will require a SAT. The end 1180 server must include a reply with an attribute containing the name of 1181 the "token pool" from which the token for this session is taken. The 1182 effect of this is to limit the number of guests connected to the net- 1183 work to the total number of tokens allocated to all realms. 1185 Each realm is authenticated and authorized by its own AAA server. The 1186 proxy core servers forward requests to the appropriate server based on 1187 a configuration file showing where each realm is to be authenticated. 1188 Requests from realms not in the configuration are dropped. 1190 The Merit AAA server software supports this policy. Merit provides 1191 this software to member and affiliate organizations. The software is 1192 designed to work with many existing authentication servers, such as 1193 Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS. This enables 1194 most institutions to utilize the authentication mechanism they have in 1195 place. 1197 8.1.2. MichNet National and International Dial-In Services 1199 In addition to the MichNet shared dial-in service, Merit also provides 1200 access from locations outside of Michigan by interconnecting with 1201 other dial-in services. These services are typically billed by connect 1202 time. Merit acts as the accounting agent between its member and affil- 1203 iate organizations and the outside service provider. 1205 The services currently supported are a national 800 number and service 1206 via the ADP/Autonet dial-in network. Connection with IBM/Advantis is 1207 being tested, and several other service interconnects are being inves- 1208 tigated. 1210 Calls placed by a Merit member/affiliate user to these external dial- 1211 in services are authenticated by having each of those services forward 1212 RADIUS authentication requests and accounting messages to a Merit 1213 proxy core server. The core forwards the requests to the member/affil- 1214 iate server for approval. Session records are logged at the Merit core 1215 server and at the member/affiliate server. Merit bills members/affili- 1216 ates monthly, based on processing of the accounting logs. The members 1217 and affiliates are responsible for rebilling their users. 1219 The Merit AAA software supports the ability to request positive con- 1220 firmation of acceptance of charges, and provides tools for accumulat- 1221 ing and reporting on use by realm and by user. 1223 8.2. Authentication and Authorization 1225 Authentication of a Telnet session is supported using the traditional 1226 id and password method, with the id being a MichNet AccessID of the 1227 form user@realm, while a PPP session may be authenticated either using 1228 an AccessID and password within a script, or using PAP. Support for 1229 challenge/response authentication mechanisms using EAP is under devel- 1230 opment. 1232 When a user dials into a MichNet shared dial-in port, the NAS sends 1233 an Access-Request to a core AAA server using the RADIUS protocol. 1234 First the core server applies any appropriate huntgroup access poli- 1235 cies to the request. If the Request fails the policy check, an Access- 1236 Reject is returned to the NAS. Otherwise, the core server forwards it 1237 to the user's home authentication server according to the user's 1238 realm. The home authentication server authenticates and authorizes 1239 the access request. An Access-Accept or Access-Reject is sent back to 1240 the core server. If an Access-Accept is sent, the home server will 1241 create a dial-in session identifier which is unique to this session 1242 and insert it in a Class attribute in the Access-Accept. The core 1243 server looks at the request and the response from the home server 1244 again and decides either to accept or reject the request. Finally, the 1245 core server sends either an Access-Accept or Access-Reject to the NAS. 1247 When a user dials into a contracted ISP's huntgroup (MichNet National 1248 and International Service), the ISP sends a RADIUS access request 1249 to a Merit core server. The rest of the authentication and authoriza- 1250 tion path is the same as in the shared dial-in service, except 1251 that no huntgroup access policy is applied but a Huntgroup-Service 1252 attribute is sent to the home authentication server with its value 1253 being the name of the service, and a copy of the attribute must be 1254 returned by the home server with a flag appended to the original value 1255 to indicate a positive authorization of user access to the specified 1256 service. 1258 The MichNet shared dial-in service typically requires authorization of 1259 some sort, for example, a user dialing into a huntgroup as a guest 1260 must be authorized with a token from the user's realm. Participating 1261 institutions have control in defining authorization rules. Currently 1262 authorization may be done using any combination of the user's group 1263 status and user's account status. A set of programming interfaces is 1264 also provided for incorporating new authorization policies. 1266 8.3. Accounting 1268 In the Merit AAA server, a session is defined as starting from the 1269 moment the user connects to the NAS, and ending at the point when the 1270 user disconnects. During the course of a session, both the core server 1271 and the home server maintain status information about the session. 1272 This allows the AAA servers to apply policies based on the current 1273 status, e.g. limit guest access by realm to number of available 1274 tokens, or to limit number of simultaneous sessions for a given Acces- 1275 sID. Information such as whether the session is for a guest, whether 1276 it used a token, and other information is included with the accounting 1277 stop information when it is logged. Merit has made enhancements to the 1278 RADIUS protocol, that are local to the AAA server, to support mainte- 1279 nance of session status information. 1281 When a user session is successfully authenticated, the NAS sends out a 1282 RADIUS accounting start request to the core server. The core server 1283 forwards that request to the user's home server. The home server 1284 updates the status of the session and then responds to the core. The 1285 core server in turn responds to the NAS. In the accounting Start 1286 request, a NAS conforming to the RADIUS specification must return the 1287 Class attribute and value it received in the Access-Accept for the 1288 session, thus sending back the dial-in session identifier created by 1289 the session's home server. 1291 When a user ends a session, an accounting stop request is sent through 1292 the same path. the same path. The dial-in session identifier is 1293 again returned by the NAS, providing a means of uniquely identifying a 1294 session. By configuring the finite state machine in each of the AAA 1295 servers, any accounting requests may be logged by any of the servers 1296 where the accounting requests are received. 1298 Because the same session logs are available on every server in the 1299 path of a session's authorization and accounting message, problems 1300 with reconciliation of specific sessions may be resolved easily. For 1301 the shared dial-in service, there are no usage charges. Merit has 1302 tools to verify that organizations do not authorize more guest ses- 1303 sions than the number of SATs allocated to the organization. For 1304 surcharged sessions, Merit sends each organization a summary bill each 1305 month. Files with detail session records are available for problem 1306 resolution. Each organization is responsible for billing its own 1307 users, and should have the same session records as are collected by 1308 Merit. 1310 Merit receives a monthly invoice from other dial-in service providers 1311 and pays them directly, after first verifying that the charges corre- 1312 spond to the session records logged by Merit. 1314 8.4. Software and Development 1316 Merit has developed the AAA server software which supports the above 1317 capabilities initially by modifying the RADIUS server provided by Liv- 1318 ingston, and later by doing a nearly total rewrite of the software to 1319 make enhancement and extension of capabilites easier. Merit makes a 1320 basic version of its server freely available for noncommercial use. 1321 Merit has started the Merit AAA Server Consortium which consists of 1322 Merit and a number of NAS vedors, ISPs and server software vendors. 1323 The consortium supports ongoing development of the Merit AAA server. 1325 The goal is to build a server that supports proxy as well as end 1326 server capabilities, that is feature rich, and that interoperates with 1327 major vendors' NAS products. 1329 The building block of the Merit AAA server, the Authentication/Autho- 1330 rization Transfer Vector (AATV), is a very powerful concept that 1331 enables the ultimate modularity and flexibility of the AAA server. The 1332 structure and methods of the AATV model are published with all ver- 1333 sions of the AAA server. 1335 Objects for extending the authorization server are also available in 1336 the enhanced version of the AAA server. Merit is also looking at ways 1337 to provide a method of extending the AAA server in its executable 1338 form, to improve the server efficiency and scalability, and to provide 1339 better monitoring, instrumentation and administration of the server. 1341 9. FidoNet implementation 1343 Since its birth in 1984, FidoNet has supported phone book synchroniza- 1344 tion among its member nodes, which now number approximately 35,000. 1345 As a non-IP dialup network, FidoNet does not provide IP services to 1346 members, and does not utilize IP-based authentication technology. 1347 Instead member nodes offer bulletin-board services, including access 1348 to mail and conferences known as echoes. 1350 In order to be able to communicate with each other, FidoNet member 1351 systems require a sychronized phone book, known as the Nodelist. The 1352 purpose of the Nodelist is to enable resolution of FidoNet addresses 1353 (expressed in the form zone:network/node, or 1:161/445) to phone num- 1354 bers. As a dialup network, FidoNet requires phone numbers in order to 1355 be deliver mail and conference traffic. 1357 In order to minimize the effort required in regularly synchronizing a 1358 phone book of 35,000 entries, the weekly Nodelist updates are trans- 1359 mitted as difference files. These difference files, known as the 1360 Nodediff, produce the Nodelist for the current week when applied to 1361 the previous week's Nodelist. In order to minimize transfer time, 1362 Nodediffs are compressed prior to transfer. 1364 Information on FidoNet, as well as FidoNet Technical Standards (FTS) 1365 documents (including the Nodelist specification) and standards propos- 1366 als are available from the FidoNet archive at http://www.fidonet.org/. 1368 9.1. Scaling issues 1370 With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB 1371 in size, and the weekly Nodediffs are 175 KB. In compressed form, the 1372 Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a 1373 result, the transfer of the Nodediff takes approximately 45 seconds 1374 using a 28,800 bps modem. 1376 In order to improve scalability, the implementation of a domain name 1377 service approach is examined in [8]. The proposal evisages use of a 1378 capability analagous to the DNS ISDN record in order to map names to 1379 phone numbers, coupled with an additional record to provide the 1380 attributes associated with a given name. 1382 9.2. Phone number presentation 1384 While FidoNet member systems perform phone book synchronization, users 1385 need only know the FidoNet address of the systems they wish to con- 1386 tact. As a result users do not need to maintain copies of the Nodelist 1387 on their own systems. This is similar to the Internet, where the DNS 1388 takes care of the domain name to IP address mapping, so that users do 1389 not have to remember IP addresses. 1391 Nevertheless, FidoNet systems often find it useful to be able to pre- 1392 sent lists of nodes, and as a result, FidoNet Nodelist compilers typi- 1393 cally produce a representation of the Nodelist that can be searched or 1394 displayed online, as well as one that is used by the system dialer. 1396 9.2.1. FidoNet Nodelist format 1398 The FidoNet Nodelist format is documented in detail in [3]. The 1399 Nodelist file consists of lines of data as well as comment lines, 1400 which begin with a semi-colon. The first line of the Nodelist is a 1401 general interest comment line that includes the date and the day num- 1402 ber, as well as a 16-bit CRC. The CRC is included so as to allow the 1403 system assembling the new Nodelist to verify its integrity. 1405 Each Nodelist data line contains eight comma separated fields: 1407 Keyword 1408 Zone/Region/Net/Node number 1409 Node name 1410 Location 1411 Sysop name 1412 Phone number 1413 Maximum Baud rate 1414 Flags (optional) 1416 FidoNet Nodelists are arranged geographically, with systems in the 1417 same zone, region, and network being grouped together. As a result, 1418 FidoNet Nodelists do not require a separate regions file. Among other 1419 things, the keyword field can be used to indicate that a system is 1420 temporarily out of service. 1422 Reference [3] discusses Nodelist flags in considerable detail. Among 1423 other things, the flags include information on supported modem modula- 1424 tion and error correction protocols. Reference [4] also proposes a 1425 series of ISDN capability flags, and [5] proposes flags to indicate 1426 times of system availability. 1428 9.3. Phone number exchange 1430 FidoNet coordinators are responsible for maintaining up to date infor- 1431 mation on their networks, regions, and zones. Every week network coor- 1432 dinators submit to their regional coordinators updated versions of 1433 their portions of the Nodelist. The regional coordinators then compile 1434 the submissions from their network coordinators, and submit them to 1435 the zone coordinator. The zone coordinators then exchange their sub- 1436 missions to produce the new Nodelist. As a result, it is possible that 1437 the view from different zones may differ at any given time. 1439 9.3.1. The Nodediff 1441 The format of the Nodediff is discussed in detail in [3]. In preparing 1442 the Nodediffs, network coordinators may transmit only their difference 1443 updates, which can be collated to produce the Nodediff directly. 1445 One weakness in the current approach is that there is no security 1446 applied to the coordinator submissions. This leaves oen the possibil- 1447 ity of propagation of fraudulent updates. In order to address this, 1448 [6] proposes addition of a shared secret to the update files. 1450 9.3.2. Addition of nodes 1452 In order to apply for allocation of a FidoNet address and membership 1453 in the Nodelist, systems must demonstrate that they are functioning by 1454 sending mail to the local network coordinator. Once the local network 1455 coordinator receives the application, they then allocate a new FidoNet 1456 address, and add a Nodelist entry. 1458 9.3.3. Deletion of nodes 1460 Since FidoNet nodes are required to be functioning during the zone 1461 mail hour in order to receive mail, and since nodes receive the weekly 1462 Nodelist from their local network coordinators on a weekly basis, 1463 there is a built-in mechanism for discovery of non-functional nodes. 1465 Nodes found to be down are reported to the local network coordinator 1466 and subsequently marked as down within the Nodelist. Nodes remaining 1467 down for more than two weeks may be removed from the Nodelist, at the 1468 discretion of the network coordinator. 1470 9.4. Phone book update 1472 The Nodelist contains the phone numbers and associated attributes of 1473 each participating system. New Nodelists become available on Fridays, 1474 and are made available to participating systems by their local network 1475 coordinators, who in turn receive them from the regional and zone 1476 coordinators. 1478 While it is standard practice for participating systems to get their 1479 Nodelists from their local network coordinators, should the local net- 1480 work coordinator not be available for some reason, either the updates 1481 or the complete Nodelist may be picked up from other network, or 1482 regional coordinators. Please note that since the view from different 1483 zones may differ, nodes wishing to update their Nodelists should not 1484 contact systems from outside their zone. 1486 9.5. Phone book compilation 1488 Once FidoNet systems have received the Nodediff, the apply it to the 1489 previous week's Nodelist in order to prepare a new Nodelist. In order 1490 to receive Nodediffs and compile the Nodelist, the following software 1491 is required: 1493 A FidoNet-compatible mailer implementation, used to transfer files 1494 A Nodelist compiler 1496 One of the purposes of the Nodelist compiler is to apply Nodediffs to 1497 the previous Nodelist in order to produce an updated Nodelist. The 1498 other purpose is to compile the updated Nodelist into the format 1499 required by the particular mailer implementation used by the member 1500 system. It is important to note that while the Nodelist and Nodediff 1501 formats are standardized (FTS-0005), as is the file transfer protocol 1502 (FTS-0001), the compiled format used by each mailer is implementation 1503 dependent. 1505 One reason that compiled formats to differ is the addition of out of 1506 band information to the Nodelist during the compilation process. 1507 Added information includes phone call costs as well as shared secrets. 1509 9.5.1. Cost data 1511 Although cost information is not part of the Nodelist, in compiling 1512 the Nodelist into the format used by the mailer, Nodelist compilers 1513 support the addition of cost information. This information is then 1514 subsequently used to guide mailer behavior. 1516 Since phone call costs depend on the rates charged by the local phone 1517 company, this information is local in nature and is typically entered 1518 into the Nodelist compiler's configuration file by the system adminis- 1519 trator. 1521 9.5.2. Shared secrets 1523 In FidoNet, shared secrets are used for authenticated sessions between 1524 systems. Such authenticated sessions are particularly important 1525 between the local, regional and zone coordinators who handle prepara- 1526 tion and transmission of the Nodediffs. A single shared secret is used 1527 per system. 1529 9.6. Accounting 1531 Within FidoNet, the need for accounting arises primarily from the need 1532 of local, regional and zone coordinators to be reimbursed for their 1533 expenses. In order to support this, utilities have been developed to 1534 account for network usage at the system level according to various 1535 metrics. However, the accounting techniques are not applied at the 1536 user level. Distributed authentication and accounting are not imple- 1537 mented and therefore users may not roam between systems. 1539 10. Acknowledgements 1541 Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest 1542 for useful discussions of this problem space. 1544 11. References 1546 [1] S. Cobb. "PPP Internet Protocol Control Protocol Extensions for 1547 Name Server Addresses" RFC 1877, Microsoft, December 1995. 1549 [2] T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer 1550 Protocol - HTTP/1.0." RFC 1945, MIT/LCS, UC Irvine, May 1996. 1552 [3] B. Baker, R. Moore, D. Nugent. "The Distribution Nodelist." 1553 FTS-0005, February, 1996. 1555 [4] A. Lentz. "ISDN Nodelist flags." FSC-0091, June, 1996. 1557 [5] D. J. Thomas. "A Proposed Nodelist flag indicating Online Times 1558 of a Node." FSC-0062, April, 1996. 1560 [6] L. Kolin. "Security Passwords in Nodelist Update Files." 1561 FSC-0055, March, 1991. 1563 [7] R. Gwinn, D. Dodell. "Nodelist Flag Changes Draft Document." 1564 FSC-0009, November, 1987. 1566 [8] R. Heller. "A Proposal for A FidoNet Domain Name Service." 1567 FSC-0069, December, 1992. 1569 [9] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 1570 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 1571 Daydreamer, January, 1997. 1573 [10] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1574 1997. 1576 12. Authors' Addresses 1578 Bernard Aboba 1579 Microsoft Corporation 1580 One Microsoft Way 1581 Redmond, WA 98052 1583 Phone: 206-936-6605 1584 EMail: bernarda@microsoft.com 1586 Juan Lu 1587 AimQuest Corporation 1588 1381 McCarthy Blvd. 1589 Milpitas, California 95035 1591 Phone: 408-273-2730 ext. 2762 1592 EMail: juanlu@aimnet.net 1594 John Alsop 1595 i-Pass Alliance Inc. 1596 650 Castro St., Suite 280 1597 Mountain View, CA 94041 1599 Phone: 415-968-2200 1600 Fax: 415-968-2266 1601 EMail: jalsop@ipass.com 1603 James Ding 1604 Asiainfo 1605 One Galleria Tower 1606 13355 Noel Road, #1340 1607 Dallas, TX 75240 1609 Phone: 214-788-4141 1610 Fax: 214-788-0729 1611 EMail: ding@bjai.asiainfo.com 1613 Wei Wang 1614 Merit Network, Inc. 1615 4251 Plymouth Rd., Suite C 1616 Ann Arbor, MI 48105-2785 1618 Phone: 313-764-2874 1619 EMail: weiwang@merit.edu