idnits 2.17.1 draft-ietf-roamops-roamreq-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 12 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 12 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 163 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 253 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == Line 24 has weird spacing: '...ctories on ...' == (158 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- 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.) -- The document date (11 July 1997) is 9779 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 524, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-roamops-imprev is -03, but you're referring to -04. ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-imprev (ref. '1') ** Obsolete normative reference: RFC 2138 (ref. '2') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '3') (Obsoleted by RFC 2866) == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-02 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '5') == Outdated reference: A later version (-07) exists of draft-ietf-radius-tunnel-imp-02 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-imp (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-00 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '7') ** Obsolete normative reference: RFC 2002 (ref. '8') (Obsoleted by RFC 3220) Summary: 18 errors (**), 0 flaws (~~), 14 warnings (==), 3 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: Standards Track Glen Zorn 5 Microsoft 6 11 July 1997 8 Dialup Roaming Requirements 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups MAY also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and MAY be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires January 1, 1998. Please 29 send comments to the authors. 31 2. Abstract 33 This document describes the features required for the provision of 34 "roaming capability" for dialup Internet users, as well as offering 35 some suggestions for future protocol standardization work. "Roaming 36 capability" is defined as the ability to use any one of multiple 37 Internet service providers (ISPs), while maintaining a formal, cus- 38 tomer-vendor relationship with only one. Examples of cases where 39 roaming capability might be required include ISP "confederations" and 40 ISP-provided corporate network access support. 42 3. Introduction 44 Considerable interest has arisen recently in a set of features that 45 fit within the general category of "roaming capability" for dialup 46 Internet users. Interested parties have included: 48 Regional Internet Service Providers (ISPs) operating within a 49 particular state or province, looking to combine their efforts 50 with those of other regional providers to offer dialup service 51 over a wider area. 53 National ISPs wishing to combine their operations with those of 54 one or more ISPs in another nation to offer more comprehensive 55 dialup service in a group of countries or on a continent. 57 Businesses desiring to offer their employees a comprehensive 58 package of dialup services on a global basis. Those services can 59 include Internet access as well as secure access to corporate 60 intranets via a Virtual Private Network (VPN), enabled by tunnel- 61 ing protocols such as PPTP, L2F, or L2TP. 63 What are the elements of a dialup roaming architecture? The following 64 list is a first cut at defining the elements for successful roaming 65 among an arbitrary set of ISPs: 67 Phone number presentation 68 Phone number exchange 69 Phone book compilation 70 Phone book update 71 Connection management 72 Authentication 73 NAS Configuration/Authorization 74 Address Assignment/Routing 75 Security 76 Accounting 78 These topics are discussed further in following sections. 80 3.1. Terminology 82 This document frequently uses the following terms: 84 phone book 85 This is a database or document containing data pertaining to 86 dialup access, including phone numbers and any associated 87 attributes. 89 phone book server 90 This is a server that maintains the latest version of the 91 phone book. Clients communicate with phone book servers in 92 order to keep their phone books up to date. 94 Network Access Server 95 The Network Access Server (NAS) is the device that clients 96 dial in order to get access to the network. 98 RADIUS server 99 This is a server which provides for authentication/autho- 100 rization via the protocol described in [3], and for account- 101 ing as described in [4]. 103 RADIUS proxy 104 In order to provide for the routing of RADIUS authentication 105 and accounting requests, a RADIUS proxy can be employed. To 106 the NAS, the RADIUS proxy appears to act as a RADIUS server, 107 and to the RADIUS server, the proxy appears to act as a 108 RADIUS client. 110 Network Access Identifier 111 In order to provide for the routing of RADIUS authentication 112 and accounting requests, the userID field used in PPP (known 113 as the Network Access Identifier or NAI) and in the subse- 114 quent RADIUS authentication and accounting requests, can 115 contain structure. This structure provides a means by which 116 the RADIUS proxy will locate the RADIUS server that is to 117 receive the request. 119 3.2. Requirements language 121 This specification uses the same words as [4] for defining the signif- 122 icance of each particular requirement. These words are: 124 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 125 that the definition is an absolute requirement of the speci- 126 fication. 128 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 129 nition is an absolute prohibition of the specification. 131 SHOULD This word, or the adjective "RECOMMENDED", means that there 132 may exist valid reasons in particular circumstances to 133 ignore a particular item, but the full implications must be 134 understood and carefully weighed before choosing a different 135 course. 137 SHOULD NOT 138 This phrase means that there may exist valid reasons in par- 139 ticular circumstances when the particular behavior is 140 acceptable or even useful, but the full implications should 141 be understood and the case carefully weighed before imple- 142 menting any behavior described with this label. 144 MAY This word, or the adjective "OPTIONAL", means that an item 145 is truly optional. One vendor may choose to include the 146 item because a particular marketplace requires it or because 147 the vendor feels that it enhances the product while another 148 vendor may omit the same item. An implementation which does 149 not include a particular option MUST be prepared to interop- 150 erate with another implementation which does include the 151 option, though perhaps with reduced functionality. In the 152 same vein an implementation which does include a particular 153 option MUST be prepared to interoperate with another imple- 154 mentation which does not include the option.(except, of 155 course, for the feature the option provides) 157 An implementation is not compliant if it fails to satisfy one or more 158 of the must or must not requirements for the protocols it implements. 159 An implementation that satisfies all the must, must not, should and 160 should not requirements for its protocols is said to be "uncondition- 161 ally compliant"; one that satisfies all the must and must not require- 162 ments but not all the should or should not requirements for its proto- 163 cols is said to be "conditionally compliant." 165 4. Requirements for Dialup Roaming 167 Suppose we have a customer, Fred, who has signed up for Internet 168 access with ISP A in his local area, through his company, BIGCO. ISP 169 A has joined an association of other ISPs (which we will call ISP- 170 GROUP) in order to offer service outside the local area. Now Fred 171 travels to another part of the world, and wishes to dial into a phone 172 number offered by ISP B (also a member of ISPGROUP). What is involved 173 in allowing this to occur? 175 Phone number presentation 176 Fred MUST be able to find and select the phone number offered by 177 ISP B. 179 Phone number exchange 180 When there is a change in the status of phone numbers (additions 181 or deletions) from individual providers, providers in ISPGROUP 182 will typically notify each other and propagate the changes. 184 Phone book compilation 185 When these updates occur, a new phone book will be compiled, 186 based on the changes submitted by the individual ISPs in ISP- 187 GROUP. 189 Phone book update 190 Once a new phone book is compiled, there MUST be a way to update 191 the phone books of customers such as Fred, so that the changes 192 are reflected in the user phone books. 194 Connection management 195 Fred's machine MUST be able to dial the phone number, success- 196 fully connect, and interoperate with the Network Access Server 197 (NAS) on the other end of the line. 199 Authentication 200 Fred MUST be able to secure access to the network. If desired by 201 BIGCO, additional security measures SHOULD be supported for 202 Fred's session. This could include support for smart cards, 203 cryptographic calculators, or one-time passwords. 205 NAS configuration/authorization 206 The Network Access Server (NAS) MUST receive configuration param- 207 eters in order to set up Fred's session. 209 Security 210 A roaming standard must provide mechanisms for fraud prevention 211 and detection. 213 Address assignment/routing 214 Fred MUST be assigned a routable IP address by the NAS. Roaming 215 MUST also support tunneling using either layer 2 or layer 3 tun- 216 neling protocols. 218 Accounting 219 ISP B MUST keep track of what resources Fred used during the ses- 220 sion. Relevant information includes how long Fred used the ser- 221 vice, what speed he connected at, whether he connected via ISDN 222 or modem, etc. 224 Note that some of these requirements may not require standardization 225 or lie outside the scope of the IETF; they are all listed for com- 226 pleteness' sake. 228 4.1. Phone Number Presentation 230 Phone number presentation involves the display of available phone num- 231 bers to the user, and culminates in the choosing of a number. Since 232 the user interface and sequence of events involved in phone number 233 presentation is a function of the connection management software that 234 Fred is using, it is likely that individual vendors will take differ- 235 ent approaches to the problem. These differences can include vari- 236 ances in the format of the client phone books, varying approaches to 237 presentation, etc. There is no inherent problem with this. As a 238 result, phone number presentation need not be standardized. 240 4.2. Phone Number Exchange 242 Phone number exchange involves propagation of phone number changes 243 between providers in a roaming association. As described in [1], no 244 current roaming implementations provide for complete automation of the 245 phone number exchange process. As a result, phone number exchange need 246 not be standardized at this time. 248 4.3. Phone Book Compilation 250 Once an ISP's phone book server has received its updates it needs to 251 compile a new phone book and propagate this phone book to all the 252 phone book servers operated by that ISP. Given that the compilation 253 process does not affect protocol interoperability, it need not be 254 standardized. 256 4.4. Phone Book Update 258 Once the phone book is compiled, it needs to be propagated to cus- 259 tomers. Standardization of the phone book update process allows for 260 providers to update the phone books of users, independent of their 261 client and operating system. As a result, roaming implementations pro- 262 viding for phone book update MUST implement the standard update proto- 263 col. 265 4.4.1. Phone book update protocol requirements 267 What are the requirements for a phone book update protocol? 269 Portability 270 The update protocol MUST allow for updating of clients on a range 271 of platforms and operating systems. Therefore the update mecha- 272 nism MUST not impose any operating system-specific requirements. 274 Authentication 275 The client MUST be able to determine the authenticity of the 276 server sending the phone book update. The server MAY also be 277 able to authenticate the client. 279 Versioning 280 The update protocol MUST provide for updating of the phone book 281 from an arbitrary previous version to the latest available ver- 282 sion. 284 Integrity Checking 285 The client MUST be able to determine the integrity of the 286 received update before applying it, as well as the integrity of 287 the newly produced phone book after updating it. 289 Light weight transfers 290 Since the client machine can be a low-end PC, the update protocol 291 MUST be lightweight. 293 Language pport 294 The phone book update mechanism MUST support the ability to 295 request that the phone book be transmitted in a particular lan- 296 guage and character set. For example, if the customer has a Rus- 297 sian language software package, then the propagation and update 298 protocols MUST provide a mechanism for the user to request a Rus- 299 sian language phone book. 301 4.4.2. Phone book format requirements 303 What are the requirements for a phone book format? 305 Phone number attributes 306 The phone book format MUST support phone number attributes com- 307 monly used by Internet service providers. These attributes are 308 required in order to provide users with information on the capa- 309 bilities of the available phone numbers. 311 Provider attributes 312 In addition to providing information relating to a given phone 313 number, the phone book MUST provide information on the individual 314 roaming consortium members. These attributes are required in 315 order to provide users with information about the individual 316 providers in the roaming consortium. 318 Service attributes 319 In addition to providing information relating to a given phone 320 number, and service provider, the phone book MUST provide infor- 321 mation relevant to configuration of the service. These attributes 322 are necessary to provide the client with information relating to 323 the operation of the service. 325 Extensibility 326 Since it will frequently be necessary to add phone book 327 attributes, the phone book format MUST support the addition of 328 phone number, provider and service attributes without modifica- 329 tion to the update protocol. Registration of new phone book 330 attributes will be handled by IANA. The attribute space MUST be 331 sufficiently large to accomodate growth. 333 Compactness 334 Since phone book will typically be frequently updated, the phone 335 book format MUST be compact so as to minimize the bandwidth used 336 in updating it. 338 4.5. Connection Management 340 Once Fred has chosen a number from his phone book, he will need to 341 connect to ISP B via ISDN or modem, and bring up a dialup network con- 342 nection. In the case of a PPP session, this will include CHAP or PAP 343 authentication. 345 Given the current popularity and near ubiquity of PPP, a roaming stan- 346 dard MUST provide support for PPP. While an implementation MAY choose 347 to support other framing protocols such as SLIP, SLIP support is 348 expected to prove difficult since SLIP does not support negotiation of 349 connection parameters and lacks support for protocols other than IP. 350 Support for non-IP protocols (e.g., IPX) MAY be useful for the provi- 351 sion of corporate intranet access via the Internet. Since it is 352 intended that the client will begin PPP negotiation immediately on 353 connection, support for scripting will not be part of a roaming stan- 354 dard. 356 4.6. Authentication 358 Authentication consists of two parts: the claim of identity (or iden- 359 tification) and the proof of the claim (or verification). 361 In order for Fred to obtain network access from ISP B, he MUST have 362 been assigned a user ID which identifies him as a customer of a member 363 of ISPGROUP (in this case, ISP A). 365 4.6.1. Identification 367 As part of the authentication process, users identify themselves to 368 the Network Access Server (NAS) in a manner that allows the authenti- 369 cation request to be routed its home destination. A roaming standard 370 must be provide a standardized format for the userID and realm pre- 371 sented to the NAS. This userID is also commonly known as the Network 372 Access Identifier (NAI). 374 4.6.2. Verification of Identity 376 CHAP and PAP are the two authentication protocols used within the PPP 377 framework today. Some groups of users are requiring different forms 378 of proof of identity (e.g., token or smart cards, Kerberos creden- 379 tials, etc.) for special purposes (such as acquiring access to corpo- 380 rate intranets). 382 4.6.3. Requirements 384 What are the requirements for authentication? 386 Authentication types 387 A roaming standard MUST support CHAP, and SHOULD support EAP. 388 Due to concerns over security in chained proxy systems, PAP 389 authentication SHOULD NOT be supported. A possible exception is 390 where PAP is used to support a one time password or token. 392 RADIUS Support 393 Given the current popularity and near ubiquity of RADIUS, a roam- 394 ing standard MUST support RADIUS authentication as defined in 395 [2]. Other protocols MAY be supported. However, it is the 396 responsibility of participating ISPs and/or software vendors to 397 produce gateways between those protocols and RADIUS. 399 Scalability 400 A roaming standard, once available, is likely to be widely 401 deployed on the Internet. A roaming standard MUST therefore pro- 402 vide sufficient scalability to allow for the formation of roaming 403 associations with thousands of ISP members. 405 4.7. NAS Configuration/Authorization 407 In order for Fred to be able to log in to ISP B, it is necessary for 408 ISP A's RADIUS server to return the proper configuration information 409 to ISP B's NAS. 411 In order to ensure compatibility with the parameters of the NAS or the 412 local network, a RADIUS proxy MAY need to add, delete, or modify 413 attributes returned by the home RADIUS server. In addition, a RADIUS 414 proxy may need to performance resource management functions. In order 415 to ensure interoperability between RADIUS proxy implementations, a 416 roaming standard MUST provide guidance on acceptable RADIUS proxy 417 behavior. 419 4.8. Address assignment/routing 421 A roaming standard MUST support dynamic address assignment. Static 422 address assignment MAY be supported, most likely via layer 2 or layer 423 3 tunneling. 425 Layer 2 tunneling protocols 426 Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold 427 great promise for the implementation of Virtual Private Networks 428 as a means for inexpensive access to remote networks. Therefore 429 proxy implementations MUST NOT preclude use of layer 2 tunneling. 430 Support of compulsory tunneling via the RADIUS protocol is 431 described in [5] and [6]. 433 Layer 3 tunneling protocols 434 Layer-3 tunneling protocols as embodied in Mobile IP, described 435 in [8], hold great promise for providing "live", transparent 436 mobility on the part of mobile nodes on the Internet. Therefore, 437 proxy implementations MUST NOT preclude the provision of Mobile 438 IP Foreign Agents or other Mobile IP functionality on the part of 439 service providers. 441 4.9. Security 443 Although network security is a very broad subject, in this paper we 444 will limit our attention to the problems of secure proxying and shared 445 secret management. 447 4.9.1. Requirements 449 What are the security requirements? 451 Security analysis 452 A roaming standard must include a thorough security analysis, 453 including a description of security threats and countermeasures. 455 End-to-end security 456 In a RADIUS proxy system, access responses are verified hop-by- 457 hop, rather than on an end-to-end basis. As a result, without 458 additional security measures, it is impossible to detect a man- 459 in-the middle attack by a rogue proxy. While end-to-end security 460 is not a requirement of a roaming standard, it MAY be provided as 461 an optional capability. 463 4.10. Accounting requirements 465 What are the accounting requirements for roaming? 467 Real-time accounting 468 In today's roaming implementations, real-time accounting is a 469 practical necessity in order to support fraud detection and risk 470 management. As a result, a roaming standard MUST provide support 471 for real-time accounting. 473 Accounting record formats 474 Today there is no proposed standard for NAS accounting, and there 475 is wide variation in the protocols used by providers to communi- 476 cate accounting information within their own organizations. As a 477 result, a roaming standard MUST prescribe a standardized format 478 for accounting records. 480 Accounting Metrics 481 A standard accounting record format MUST be able to encode met- 482 rics commonly used by Internet Service Providers to determine the 483 user's bill. 485 Extensibility 486 Since these metrics change over time, the accounting record for- 487 mat MUST be extensible so as to be able to add future metrics as 488 they come along. The record format MUST support both standard 489 metrics as well as vendor-specific metrics. 491 Compactness 492 For the sake of efficiency, the record format MUST be compact. 494 5. Acknowledgements 496 Thanks to Pat Calhoun of USR, Dr. Thomas Pfenning and Don Dumitru of 497 Microsoft for many useful discussions of this problem space. 499 6. References 501 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 502 Implementations." Internet draft (work in progress), draft-ietf- 503 roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, 504 Merit, June, 1997. 506 [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 507 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 508 Daydreamer, April, 1997. 510 [3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April, 511 1997. 513 [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement 514 Levels." RFC 2119, Harvard University, March, 1997. 516 [5] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter- 517 net draft (work in progress), draft-ietf-radius-tunnel-auth-02.txt, 518 Microsoft, July, 1997. 520 [6] B. Aboba. "Implementation of PPTP/L2TP Mandatory Tunneling via 521 RADIUS." Internet draft (work in progress), draft-ietf-radius-tunnel- 522 imp-02.txt, Microsoft, July, 1997. 524 [7] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work 525 in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997. 527 [8] C. Perkins. "IP Mobility Support." RFC 2002, IBM, October, 1996. 529 7. Authors' Addresses 531 Bernard Aboba 532 Microsoft Corporation 533 One Microsoft Way 534 Redmond, WA 98052 536 Phone: 425-936-6605 537 EMail: bernarda@microsoft.com 538 Glen Zorn 539 Microsoft Corporation 540 One Microsoft Way 541 Redmond, WA 98052 543 Phone: 425-703-1559 544 EMail: glennz@microsoft.com