HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:13:54 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 17 Jan 1997 00:20:00 GMT ETag: "361bc1-8ce5-32dec5b0" Accept-Ranges: bytes Content-Length: 36069 Connection: close Content-Type: text/plain ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Glen Zorn 11 January 1997 Microsoft Corporation Dialup Roaming Requirements 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups MAY also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and MAY be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires August 1, 1997. Please send comments to the authors. 2. Abstract This document describes the features required for the provision of "roaming capability" for dialup Internet users, as well as offering some suggestions for future protocol standardization work. "Roaming capability" is defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, cus- tomer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. 3. Introduction Considerable interest has arisen recently in a set of features that fit within the general category of "roaming capability" for dialup Internet users. Interested parties have included: Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service Aboba & Zorn [Page 1] INTERNET-DRAFT 11 January 1997 over a wider area. National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent. Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services can include Internet access as well as secure access to corporate intranets via a Virtual Private Network (VPN), enabled by tunnel- ing protocols such as PPTP, L2F, or L2TP. What are the elements of a dialup roaming architecture? The following list is a first cut at defining the elements for successful roaming among an arbitrary set of ISPs: Phone number presentation Phone number exchange Phone book compilation Phone book update Connection management Authentication NAS Configuration/Authorization Address Assignment/Routing Security Accounting These topics are discussed further in following sections. 3.1. Terminology This document frequently uses the following terms: phone book This is a database or document containing data pertaining to dialup access, including phone numbers and any associated attributes. phone book server This is a server that maintains the latest version of the phone book. Clients communicate with phone book servers in order to keep their phone books up to date. Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network. RADIUS server This is a server which provides for authentication/autho- rization via the protocol described in [3], and for account- ing as described in [4]. Aboba & Zorn [Page 2] INTERNET-DRAFT 11 January 1997 RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the subse- quent RADIUS authentication and accounting requests, can contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. 3.2. Requirements language This specification uses the same words as [4] for defining the signif- icance of each particular requirement. These words are: MUST This word, or the adjectives "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the speci- fication. MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- nition is an absolute prohibition of the specification. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interop- erate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another imple- mentation which does not include the option.(except, of Aboba & Zorn [Page 3] INTERNET-DRAFT 11 January 1997 course, for the feature the option provides) An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "uncondition- ally compliant"; one that satisfies all the must and must not require- ments but not all the should or should not requirements for its proto- cols is said to be "conditionally compliant." 4. Requirements for Dialup Roaming Suppose we have a customer, Fred, who has signed up for Internet access with ISP A in his local area, through his company, BIGCO. ISP A has joined an association of other ISPs (which we will call ISP- GROUP) in order to offer service outside the local area. Now Fred travels to another part of the world, and wishes to dial into a phone number offered by ISP B (also a member of ISPGROUP). What is involved in allowing this to occur? Phone number presentation Fred MUST be able to find and select the phone number offered by ISP B. Phone number exchange When there is a change in the status of phone numbers (additions or deletions) from individual providers, providers in ISPGROUP will typically notify each other and propagate the changes. Phone book compilation When these updates occur, a new phone book will be compiled, based on the changes submitted by the individual ISPs in ISP- GROUP. Phone book update Once a new phone book is compiled, there MUST be a way to update the phone books of customers such as Fred, so that the changes are reflected in the user phone books. Connection management Fred's machine MUST be able to dial the phone number, success- fully connect, and interoperate with the Network Access Server (NAS) on the other end of the line. Authentication Fred MUST be able to secure access to the network. NAS configuration/authorization The Network Access Server (NAS) MUST receive configuration param- eters in order to set up Fred's session. Aboba & Zorn [Page 4] INTERNET-DRAFT 11 January 1997 Security If desired by BIGCO, additional security measures SHOULD be sup- ported for Fred's session. These could include supporting use of token cards, or setting up Fred's account so that he is automati- cally tunneled to the corporate PPTP, L2F or L2TP server for access to the corporate intranet. Address assignment/routing Fred MUST be assigned a routable IP address by the NAS. Accounting ISP B MUST keep track of what resources Fred used during the ses- sion. Relevant information includes how long Fred used the ser- vice, what speed he connected at, whether he connected via ISDN or modem, etc. Note that some of these requirements may not require standardization or lie outside the scope of the IETF; they are all listed for com- pleteness' sake. 4.1. Phone Number Presentation Phone number presentation involves the display of available phone num- bers to the user, and culminates in the choosing of a number. Since the user interface and sequence of events involved in phone number presentation is a function of the connection management software that Fred is using, it is likely that individual vendors will take differ- ent approaches to the problem. These differences can include vari- ances in the format of the client phone books, varying approaches to presentation, etc. There is no inherent problem with this. As a result, phone number presentation need not be standardized. 4.2. Phone Number Exchange Phone number exchange involves propagation of phone number changes between providers in a roaming association. As described in [2], no current roaming implementations provide for complete automation of the phone number exchange process. As a result, phone number exchange need not be standardized at this time. 4.3. Phone Book Compilation Once an ISP's phone book server has received its updates it needs to compile a new phone book and propagate this phone book to all the phone book servers operated by that ISP. Given that the compilation process does not affect protocol interoperability, it need not be standardized. Aboba & Zorn [Page 5] INTERNET-DRAFT 11 January 1997 4.4. Phone Book Update Once the phone book is compiled, it needs to be propagated to cus- tomers. Standardization of the phone book update process allows for providers to update the phone books of users, independent of their client and operating system. As a result, roaming implementations pro- viding for phone book update MUST implement the standard update proto- col. 4.4.1. Phone book update protocol requirements What are the requirements for a phone book update protocol? Portability The update protocol MUST allow for updating of clients on a range of platforms and operating systems. Therefore the update mecha- nism MUST not impose any operating system-specific requirements. Authentication The client MUST be able to determine the authenticity of the server sending the phone book update. The server MAY also be able to authenticate the client. Versioning The update protocol MUST provide for updating of the phone book from an arbitrary previous version to the latest available ver- sion. Integrity Checking The client MUST be able to determine the integrity of the received update before applying it, as well as the integrity of the newly produced phone book after updating it. Light weight transfers Since the client machine can be a low-end PC, the update protocol MUST be lightweight. Language support The phone book update mechanism MUST support the ability to request that the phone book be transmitted in a particular lan- guage and character set. For example, if the customer has a Rus- sian language software package, then the propagation and update protocols MUST provide a mechanism for the user to request a Rus- sian language phone book. Similarly, the phone book standard Aboba & Zorn [Page 6] INTERNET-DRAFT 11 January 1997 4.4.2. Phone book format requirements What are the requirements for a phone book format? Phone number attributes The phone book format MUST support phone number attributes com- monly used by Internet service providers. These attributes are required in order to provide users with information on the capa- bilities of the available phone numbers. Since it is intended that the client will begin PPP negotiation immediately on connec- tion, support for scripting will not be part of a roaming stan- dard. Provider attributes In addition to providing information relating to a given phone number, the phone book MUST provide information on the individual roaming consortium members. These attributes are required in order to provide users with information about the individual providers in the roaming consortium. Service attributes In addition to providing information relating to a given phone number, and service provider, the phone book MUST provide infor- mation relevant to configuration of the service. These attributes are necessary to provide the client with information relating to the operation of the service. Extensibility Since it will frequently be necessary to add phone book attributes, the phone book format MUST support the addition of phone number, provider and service attributes without modifica- tion to the update protocol. Registration of new phone book attributes will be handled by IANA. The attribute space MUST be sufficiently large to accomodate growth. Compactness Since phone book will typically be frequently updated, the phone book format MUST be compact so as to minimize the bandwidth used in updating it. 4.4.2.1. Phone number attributes Examples of phone number attributes include: Unique identifier for the phone number City State or Region Aboba & Zorn [Page 7] INTERNET-DRAFT 11 January 1997 Country Area code Local phone number Minimum speed Maximum speed Modem protocols supported (V.32bis, V.34, etc.) ISDN protocols supported (V.110, V.120, etc.) Multicast capability Dialout capability Times of operation Priority level (for control of presentation order) External/internal flag (denoting whether the number has been imported) 4.4.2.2. Provider attributes Examples of provider attributes include: Provider name Provider address Provider voice phone number Provider fax phone number Customer support phone number Provider icon Provider domain name Primary Domain Name Server Secondary Domain Name Server Dial-up IP Address News server Mail server Web page Maximum length of the user name for the provider Maximum length of the password for the provider 4.4.2.3. Service attributes Examples of service attributes include: The name of the service A description of the service The URL of the service phone book server The service phone book filename The service phone book version number 4.5. Connection Management Once Fred has chosen a number from his phone book, he will need to connect to ISP B via ISDN or modem, and bring up a dialup network con- nection. In the case of a PPP session, this will include CHAP or PAP authentication. Aboba & Zorn [Page 8] INTERNET-DRAFT 11 January 1997 4.5.1. Requirements What are the requirements for connection management? PPP Support Given the current popularity and near ubiquity of PPP, a roaming standard MUST provide support for PPP. While an implementation MAY choose to support other framing protocols such as SLIP, SLIP support is expected to prove difficult since SLIP does not sup- port negotiation of connection parameters and lacks support for protocols other than IP. Support for non-IP protocols (e.g., IPX) MAY be necessary for the provision of corporate intranet access via the Internet. Since it is intended that the client will begin PPP negotiation immediately on connection, support for scripting will not be part of a roaming standard. 4.6. Authentication Authentication consists of two parts: the claim of identity (or iden- tification) and the proof of the claim (or verification). In order for Fred to obtain network access from ISP B, he MUST have been assigned a user ID which identifies him as a customer of a member of ISPGROUP (in this case, ISP A). For example, if a user ID suffix is used, Fred might identify himself as "fred@ispa.com". Note that some NAS vendors will need to modify their devices so as to support the longer user IDs resulting from addition of prefixes or suffixes. After obtaining Fred's user ID and other authentication data, the NAS device will then send a RADIUS request packet to a RADIUS proxy or server. If a proxy is being used, it MUST examine the user ID prefix or suffix, check whether it represents an authorized authentication realm, and then pass the request either to an appropriate RADIUS server, or to another proxy for further routing. 4.6.1. Identification As part of the authentication process, users identify themselves to the Network Access Server (NAS) in a manner that allows the NAS to route the authentication request to its home destination. 4.6.1.1. Naming requirements What are the requirements for an identification scheme? Authentication routing A roaming standard MUST provide a mechanism for the remote ISP to efficiently route the authentication request to the home authen- tication server. As part of this, there MUST be a way for the Aboba & Zorn [Page 9] INTERNET-DRAFT 11 January 1997 remote ISP to determine the IP address of the authentication server that is to be contacted. Robustness Authentication routing MUST be carried out in a manner that allows the authentication request to reach its the destination, and for the response to be returned to the querying NAS, all within a time period compatible with typical timeout parameters. 4.6.2. Verification of Identity CHAP and PAP are the two authentication protocols used within the PPP framework today. Some groups of users are requiring different forms of proof of identity (e.g., token or smart cards, Kerberos credentials, etc.) for special purposes(such as acquiring access to corporate intranets). 4.6.3. Requirements What are the requirements for authentication? Authentication types A successful roaming implementation MUST support CHAP, and SHOULD support EAP. PAP authentication MAY be supported. RADIUS Support Given the current popularity and near ubiquity of RADIUS, a roam- ing standard MUST support RADIUS, as defined in [2] and [3]. Other protocols MAY be supported. However, it is the responsibil- ity of participating ISPs and/or software vendors to produce gateways between those protocols and RADIUS. Business relationships A roaming standard MUST provide a mechanism for the remote ISP to determine whether the home authentication server has a valid business relationship with the remote ISP. This implies either that the authenticating party is a member of the roaming associa- tion, or that the authenticating party has a valid business rela- tionship with a member of the roaming association. Scalability A roaming standard, once available, is likely to be widely deployed on the Internet. A roaming standard MUST therefore pro- vide sufficient scalability to allow for the formation of roaming associations with hundreds of ISP members, and hundreds of "sub- domains" per ISP. Thus, a roaming standard MUST be able to deal with a hundred thousand RADIUS servers operating within a roaming Aboba & Zorn [Page 10] INTERNET-DRAFT 11 January 1997 association. Non-repudiation In a RADIUS proxy system, access responses are verified hop-by- hop, rather than on an end-to-end basis. This means that without additional security measures, it is possible for a compromised RADIUS proxy to modify security attributes returned by the home ISP, or even to change a NAK to an ACK. While non-repudiation of Access-Replies is not a requirement for a roaming standard, it is considered desirable, and therefore MAY be provided as an optional capability. 4.7. NAS Configuration/Authorization In order for Fred to be able to log in to ISP B, it is necessary for ISP A's RADIUS server to return the proper configuration information to ISP B's NAS. 4.7.1. Configuration/Authorization requirements What are the requirements for configuration/authorization? Masking of heterogeneity ISP A and ISP B's NAS devices can be from different vendors; even if they are from the same vendor, ISP A and ISP B can use differ- ent NAS configurations. As a result, the NASs can each require different parameters in order to properly configure them. In the case of RADIUS, this problem can be solved through the use of a proxy which adds ISP and NAS-specific attributes to the response returned by ISP A's RADIUS server, with the result being that ISP B's RADIUS proxy will provide the attributes necessary to config- ure ISP B's NAS device, while ISP A's RADIUS server will perform the actual user authentication. In order to support heterogene- ity among providers within the roaming association, RADIUS prox- ies MUST support attribute editing. 4.8. Address assignment/routing A roaming standard MUST support dynamic address assignment. Static address assignment MAY be supported. Static address assignment, if it is to be supported, will most likely be accomplished via one of two mechanisms: Layer 2 tunneling protocols Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold great promise for the implementation of Virtual Private Networks as a means for inexpensive access to remote networks. Therefore, proxy implementations MUST NOT preclude mandatory tunneling. Aboba & Zorn [Page 11] INTERNET-DRAFT 11 January 1997 Layer 3 tunneling protocols Layer-3 tunneling protocols as embodied in Mobile IP [RFC2002] hold great promise for providing "live", transparent mobility on the part of mobile nodes on the Internet. Therefore, proxy implementations MUST NOT preclude the provision of Mobile IP For- eign Agents or other Mobile IP functionality on the part of ser- vice providers. 4.9. Security Although network security is a very broad subject, in this paper we will limit our attention to the problems of secure proxying and shared secret management. 4.9.1. Requirements What are the security requirements? Secure proxying One of the problems which arises from the dependency on a proxied system of authorization is how to guarantee that the proxy will properly forward the security-related parameters returned by the remote server and that the NAS will enforce them. RADIUS proxies MUST not remove security-related parameters from responses. For example, the user MUST not be allowed to authenticate using CHAP or PAP if the remote authorization server had returned attributes indicating a requirement for token card use. Similarly, a user MUST not be allowed access to the Internet if the remote autho- rization server had returned attributes indicating a requirement for a mandatory tunnel. Shared secret management A roaming standard MUST provide for efficient management of share secrets. This is required since the RADIUS protocol requires a shared secret between the NAS and the RADIUS server. This along with authentication routing and timeout constraints are the issues most limiting the scalability of roaming. In a proxy implementation, this translates to shared secrets between the NAS devices and the ISP proxy, and another set of shared secrets between the ISP proxies and second level proxies or RADIUS servers. Note that the issue of shared secret management is inti- mately connected with authentication routing, since the routing scheme determines the number of hops that MUST be traversed for the authentication request to reach its destination. This in turn influences the number of shared secrets that need to be main- tained on each proxy or server. Aboba & Zorn [Page 12] INTERNET-DRAFT 11 January 1997 4.10. Accounting Today there is no proposed standard for NAS accounting, and there is wide variation in the protocols used by providers to communicate accounting information within their own organizations. As a result, rather than requiring the use of a particular accounting protocol (RADIUS, TACACS+, SNMP, SYSLOG, etc.), a roaming standard MUST pre- scribe a standardized format and transmission method for accounting records. 4.10.1. Accounting requirements What are the accounting requirements for roaming? Identification of the accounting agent Prior to setting up the accounting record transfer, the roaming implementation MUST be able to determine the endpoint for the accounting record transfer. Tagging and bagging The transfer protocol MUST be able to tag and bag the transferred records so as to identify the version and type of record being transferred. Accounting metrics The account record format MUST be able to encode metrics commonly used by Internet Service Providers to determine the user's bill. Extensibility Since these metrics change over time, the accounting record for- mat MUST be extensible so as to be able to add future metrics as they come along. The record format MUST support both standard metrics as well as vendor-specific metrics. Encryption For the sake of security, the record transfer protocol MUST pro- vide for encrypted transfer of records via an encryption mecha- nism that can be legally deployed in at least a minimal set of countries. Authentication Also for the sake of security, the record MUST provide for sign- ing of the accounting records, so as to assure their integrity and authenticity. In addition, during the transfer process the sender and receiver MUST mutually authenticate. Aboba & Zorn [Page 13] INTERNET-DRAFT 11 January 1997 Compactness For the sake of efficiency, the record format MUST be compact. Robustness The accounting transfer protocol MUST be capable of recovering from a variety of faults, including partially completed transfers and non-supported metrics. Non-repudiation Once an accounting record file has been transferred, the sender MUST be able to secure a receipt from the receiver. Similarly, a receipt MUST be sent once the accounting record file has been processed. Along with the receipt, the receiver SHOULD include error messages associated with processing the accounting records. 4.10.1.1. Example accounting metrics Examples of accounting metrics include: User Name (String; the user's ID, including prefix or suffix) NAS IP address (Integer; the IP address of the user's NAS) NAS Port (Integer; identifies the physical port on the NAS) Service Type (Integer; identifies the service provided to the user) NAS Identifier (Integer; unique identifier for the NAS) Delay Time (Integer; time client has been trying to send) Input Octets (Integer; in stop record, octets received from port) Output Octets (Integer; in stop record, octets sent to port) Session ID (Integer; unique ID identifying the session) Authentication (Integer; indicates how user was authenticated) Session Time (Integer; in stop record, seconds of received service) Input Packets (Integer; in stop record, packets received from port) Output Packets (Integer; in stop record, packets sent to port) Termination Cause (Integer; in stop record, indicates termination cause) Multi-Session ID (String; for linking of multiple related sessions) Link Count (Integer; number of links up when record was generated) NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 5. Acknowledgements Thanks to Dr. Thomas Pfenning and Don Dumitru of Microsoft for many useful discussions of this problem space. 6. References [1] B. Aboba, L. Liu, J. Alsop, J. Ding. "Review of Roaming Imple- mentations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i- Pass Alliance, Asiainfo, January, 1997. Aboba & Zorn [Page 14] INTERNET-DRAFT 11 January 1997 [2] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authen- tication Dial In User Service (RADIUS)." draft-ietf-radius- radius-05.txt, Livingston, Merit, Daydreamer, July 1996. [3] C. Rigney. "RADIUS Accounting." draft-ietf-radius-account- ing-05.txt, Livingston, July 1996. [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." draft-bradner-key-words-02.txt, Harvard University, August, 1996. [5] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft- ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996. [6] B. Aboba. "Implementation of Mandatory Tunneling via RADIUS." draft-aboba-radius-tunnel-imp-01.txt, Microsoft Corporation, November, 1996. 7. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-703-1559 EMail: glennz@microsoft.com Aboba & Zorn [Page 15]