idnits 2.17.1 draft-ietf-nasreq-criteria-00.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == The page length should not exceed 58 lines per page, but there was 10 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 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** There are 154 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 262 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 305: '... This interface MUST support the P...' RFC 2119 keyword, line 322: '... work, a NAS MUST provide routing ...' RFC 2119 keyword, line 336: '...e a AAA protocol MUST support authenti...' RFC 2119 keyword, line 339: '... a AAA protocol MUST support carrying...' RFC 2119 keyword, line 343: '... Authentication Protocol [EAP]. Therefore a AAA protocol MUST support...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 13 has weird spacing: '... uments of t...' == Line 14 has weird spacing: '...tribute work-...' == Line 18 has weird spacing: '...cuments at a...' == Line 22 has weird spacing: '... The list...' == Line 25 has weird spacing: '... The list ...' == (149 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.) -- The document date (25 February 1999) is 9185 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'KEYWORDS' on line 442 looks like a reference -- Missing reference section? 'PPP' on line 439 looks like a reference -- Missing reference section? 'SNMP' on line 434 looks like a reference -- Missing reference section? 'L2TP' on line 448 looks like a reference -- Missing reference section? 'PPP CHAP' on line 341 looks like a reference -- Missing reference section? 'EAP' on line 454 looks like a reference -- Missing reference section? 'NAI' on line 457 looks like a reference -- Missing reference section? 'L2TP-IPSEC' on line 463 looks like a reference -- Missing reference section? 'ROUTER REQUIREMENTS' on line 427 looks like a reference -- Missing reference section? 'ROAMING REQUIREMENTS' on line 460 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NASREQ Working Group M. Beadles 2 INTERNET-DRAFT MCI WorldCom 3 Category: Informational 4 5 25 February 1999 7 Criteria for Evaluating Network Access Server Protocols 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working doc- 13 uments 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 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 The distribution of this draft is unlimited. It is filed as 29 and expires August 25, 1999. 30 Please send comments to the author. 32 2. Copyright Statement 34 Copyright (C) The Internet Society 1999. All Rights Reserved. 36 3. Abstract 38 This document defines and analyzes requirements for modern Network 39 Access Servers (NAS). The NAS is the initial entry point to a network 40 for the majority of users of network services. It is the first device 41 in the network to provide services and enforce policy for an end user, 42 and acts as a gateway for all further services. As such, its impor- 43 tance to users and service providers alike is paramount. However, the 44 concept of a NAS has grown up over the years without a formal defini- 45 tion or framework for analysis. This document defines a NAS, analyzes 46 the functionality of NAS's, and sets requirements for protocols that 47 provide this functionality. Functions provided adequately by already 48 standardized protocols will be documented as such. 50 4. Requirements language 52 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 53 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 54 described in [KEYWORDS]. 56 5. Introduction 58 This document defines a Network Access Server (NAS), analyzes the 59 functionality of NAS's, and sets requirements for protocols that pro- 60 vide this functionality. This document does not define what a NAS 61 must do. Rather, it defines how a NAS must do what it does if it 62 chooses to. That is, it does not set functional requirements, but 63 sets requirements for protocols or systems that provide functionality. 64 Implementors may choose not to provide certain features at their dis- 65 cretion. 67 This document makes reference to many standard protocols that a NAS 68 will use. This document incorporates by reference the RFC's and other 69 documents describing the current specifications for these protocols. 70 It adds additional discussion and guidance for implementors of these 71 protocols where they apply to a NAS. Where existing protocols meeet 72 these requirements, they will be noted. In particular, [ROUTER 73 REQUIREMENTS] is referred to as a primary source for requirements and 74 implementation of the routing functionality of a NAS. 76 Note that, although NAS's often support more than one protocol suite, 77 this document is only concerned with requirements for NAS's that use 78 the TCP/IP protocol suite. 80 6. Definition of a Network Access Server 82 A Network Access Server is a device which sits on the edge of a net- 83 work, and provides access to services on that network in a controlled 84 fashion, based on the identity of the user of the network services in 85 question. For the purposes of this document, a Network Access Server 86 is a device which accepts multiple point-to-point [PPP] links on one 87 set of interfaces, providing access to a routed TCP/IP network or net- 88 works on another set of interfaces. Examples of Network Access 89 Servers include: 91 A remote access server which provides access to a private network 92 via attached modems which are directly dialed by the user. 94 A tunneling server which sits at the border of a protected net- 95 work, and acts as a gateway for users to enter the protected net- 96 work from the Internet. 98 A shared commercial dial access server operated by a Network Ser- 99 vice Provider, where incoming users connect via modems operated 100 by a Telephone Service Provider, and access is provided to many 101 dissimilar private and public networks, including the Internet. 103 A broadband access server which provides authenticated access to 104 the Internet for users connecting via point-to-point links over 105 broadband media such as xDSL or cable modems. 107 Note that there are many things that a Network Access Server is not. 108 A NAS is not just a router, although all NAS's are routers. A NAS is 109 not necessarily a dial access server, although dial access is one com- 110 mon means of network access, and brings its own particular set of 111 requirements to NAS's. 113 A NAS is the first device in the network to provide services to an end 114 user and acts as a gateway for all further services. It is the point 115 at which users are authenticated, access policy is enforced, network 116 services are authorized, network usage is audited, and resource con- 117 sumption is tracked. That is, a NAS acts as the Policy Enforcement 118 Point (PEP) for network AAA (authentication, authorization, and 119 accounting) services. A NAS is typically the first place in a network 120 where security measures and policy may be implemented. 122 7. Interested parties 124 The following are examples of parties who are concerned with the oper- 125 ation of Network Access Servers. This list is by no means exhaustive. 127 Network Service Providers (NSPs) who operate and manage NAS's, 128 AAA servers, policy servers, and networks; and who provide net- 129 work services to end users. 131 End users who gain access to their private and public networks 132 through NAS's. 134 Businesses and other entities who operate NAS's for their users' 135 public and private network access, or who outsource the operation 136 and management of NAS's to a NSP. 138 Telephone Service Providers (TSPs) who operate and manage modems 139 and telephony networks; and who provide telephony services to end 140 users, NSP's, and businesses. 142 Manufacturers of NAS's, AAA servers, policy servers, modems, etc. 144 8. Reference Model of a NAS 146 For reference in discussion of NAS requirements, a diagram of a NAS, 147 its dependencies, and its interfaces is given below. This diagram is 148 intended as an abstraction of a NAS as a reference model, and is not 149 intended to represent any particular NAS implementation. 151 Users 152 v v v v v v v 153 | | Telco | | 154 | | or | | 155 |encapsulated 156 +-------------------+ 157 | Modems or Virtual | 158 +-------------------+ 159 | | | | | | | 160 | | | | | | | 161 | | | | | | | 162 +--+----------------------------+ 163 | | | 164 |N | Client Interface | 165 | | | 166 |A +----------Routing ----------+ 167 | | | 168 |S | Network Interface | 169 | | | 170 +--+----------------------------+ 171 / | \ 172 / | \ 173 / | \ 174 / | \ 175 POLICY MANAGEMENT/ | \ DEVICE MANAGEMENT 176 +---------------+ | +-------------------+ 177 | Authentication| _/^\_ |Device Provisioning| 178 +---------------+ _/ \_ +-------------------+ 179 | Authorization | _/ \_ |Device Monitoring | 180 +---------------+ _/ \_ +-------------------+ 181 | Accounting | / The \ 182 +---------------+ \_ Network(s) _/ 183 \_ _/ 184 \_ _/ 185 \_ _/ 186 \_/ 188 8.1. Description of Model Elements 190 Following is a description of the modules and interfaces in the refer- 191 ence model for a NAS given above: 193 Client Interfaces 194 A NAS has one or more client interfaces, which provide the 195 interface to the end users who are requesting network 196 access. Users may connect to these client interfaces via 197 modems over a switched telephone network, via encapsulated 198 tunnels over data network, or by some similar means. 200 Network Interfaces 201 A NAS has one or more network interfaces, which connect to 202 the TCP/IP networks to which access is being granted. 204 Routing Since this document assumes that the network to which access 205 is being granted is a routed TCP/IP network, a NAS includes 206 routing functionality. 208 Policy Management Interface 209 Policy is defined as a set of business rules for operation 210 of a network, applied here to the authorization of network 211 access. The specific application of policy rules depends on 212 user identity and the current network state. A NAS provides 213 an interface which allows access to network services to be 214 managed on a per-user, per-session basis. Although this 215 interface historically may have been a configuration file, a 216 graphical user interface, or an API, this document assumes 217 that a AAA protocol provides this interface. This interface 218 provides a mechanism for granular resource management and 219 policy enforcement. 221 Authentication 222 Authentication refers to the confirmation that a user who is 223 requesting services is a valid user of the network services 224 requested. . Authentication does not establish that a user 225 is authorized to receive any services, it just establishes 226 who the user is to a predetermined degree of certainty. 227 Authentication is accomplished via the presentation of an 228 identity and credentials. Examples of types of credentials 229 are passwords, one-time tokens, digital certificates, and 230 phone numbers (calling/called). 232 Authorization 233 Authorization refers to the granting of specific types of 234 service (including "no service") to a user, based on their 235 authentication, what services they are requesting, and the 236 current system state. Authorization may be based on restric- 237 tions, for example time-of-day restrictions, or physical 238 location restrictions, or restrictions against multiple 239 logins by the same user. Authorization determines the 240 nature of the service which is granted to a user. Examples 241 of types of service include, but are not limited to: IP 242 address filtering, address assignment, route assignment, 243 QoS/differential services, bandwidth control/traffic manage- 244 ment, compulsory tunneling to a specific endpoint, and 245 encryption. 247 Accounting 248 Accounting refers to the tracking of the consumption of 249 resources by users. This information may be used for man- 250 agement, planning, billing, auditing, or other purposes. 251 Real-time accounting refers to accounting information that 252 is delivered concurrently with the consumption of the 253 resources. Batch accounting refers to accounting informa- 254 tion that is saved until it is delivered at a later time. 255 Typical information that is gathered in accounting is the 256 identity of the user, the nature of the service delivered, 257 when the service began, and when it ended. 259 AAA Server 260 A AAA Server is a server or servers that provide authentica- 261 tion, authorization, and accounting services. These may be 262 colocated with the NAS, but this document assumes they are 263 located on a seperate server and communicate with the NAS's 264 User Management Interface via a AAA protocol. The three AAA 265 functions may be located on a single server, or may be bro- 266 ken up among multiple servers. 268 Device Management Interface 269 A NAS is a network device which is owned, operated, and man- 270 aged by some entity. This interface provides a means for 271 this entity to operate, manage, and maintain the NAS. This 272 is a logically separate function from policy management, and 273 in fact separate entities may manage the policy and the 274 device itself. This interface may be a configuration file, 275 a graphical user interface, an API, or a protocol such as 276 SNMP [SNMP]. 278 Device Monitoring 279 Device monitoring refers to the tracking of status, activ- 280 ity, and usage of the NAS as a network device. It does not 281 mean the tracking of individual user activity or status. 283 Device Provisioning 284 Device provisioning refers to the configurations, settings, 285 and control of the NAS as a network device. This means gen- 286 eral device settings and control, and not the dynamic con- 287 trol that is associated with authorizing a particular user 288 to receive services within the context of a session. 290 9. Analysis and Requirements 292 Using the reference model above , the following is an analysis of the 293 functions of a NAS and requirements for protocols and services to per- 294 form these functions. 296 9.1. NAS Interfaces 298 NAS's have two basic sets of interfaces; one set provides client con- 299 nections serving individual users, and the other set faces the net- 300 works on which access is controlled. 302 9.1.1. Client Interface 304 The NAS Client Interface accepts individual point-to-point connec- 305 tions. This interface MUST support the Point- to-Point Protocol 306 [PPP]. 308 9.1.2. Access Media 310 Various access media can be supported by the NAS. They can be divided 311 into three types: dial telephony, encapsulated tunnels, and broadband 312 media. Dial telephony includes POTS and ISDN and is provided through 313 a modem, terminal adapter, or similar device. Encapsulated tunnels 314 include Layer Two Tunneling Protocol [L2TP] sessions encapsulating 315 PPP, provided through a virtual interface. Broadband media, such as 316 xDSL and Cable Modems, can be considered a special case of encapsu- 317 lated media. 319 9.1.3. Network Interface 321 If the network that the NAS controls access on is a routed TCP/IP net- 322 work, a NAS MUST provide routing functionality as defined in [ROUTER 323 REQUIREMENTS]. 325 9.2. Services provided by a NAS 326 9.2.1. Authentication and Security 328 A NAS provides authentication services to end users. The NAS does not 329 check the user's credentials itself; rather it offloads authentication 330 to an external authentication server via a AAA protocol. The types of 331 authentication provided by a NAS can range from simple identification 332 to advanced multi-phase authentication methods. Identification (pre- 333 sentation of some form of identity with no supporting credentials) can 334 include presentation of a user name alone, or even presentation of no 335 user name at all, relying on (for example) a calling phone number to 336 identify a user. Therefore a AAA protocol MUST support authentication 337 sessions that carry a user name with no password, and authentication 338 sessions that carry no user name. For standard authentication by user 339 name and password, a AAA protocol MUST support carrying a user name 340 and associated password, both in clear text and secured by challenge- 341 response [PPP CHAP]. Advanced authentication methods such as one-time 342 passwords or digital certificates are enabled in PPP by the Extensible 343 Authentication Protocol [EAP]. Therefore a AAA protocol MUST support 344 transporting of EAP sessions. 346 Since a NAS may need to participate in a public key infrastructure, a 347 AAA protocol SHOULD support a standard key exchange mechanism. 349 9.2.2. Authorization and Policy 351 A NAS is the initial point where services are authorized to end users. 352 The NAS does not itself authorize services; it performs the delivery 353 of services authorized by an external authorization server via a AAA 354 protocol. Since a user's authorization profile is a reflection of 355 policy, the NAS can be regarded as a Policy Enforcement Point for net- 356 work access. The AAA protocol communicates profile information from 357 the AAA server, which acts a the Policy Decision Point for network 358 access. Since policy is a reflection of business rules that may 359 change arbitrarily, and authorization profiles may grow to include new 360 functionality as it arises, the AAA protocol MUST provide a built-in 361 extension mechanism for adding new types of authorization profile 362 information to be transmitted to the NAS. 364 Authorization is performed based on user identity and affiliation, 365 policy rules, and system state. User identity and affiliation are 366 commonly derived from the Network Access Identifier [NAI]; the AAA 367 protocol MUST support the NAI format for user identity. System state 368 includes information about the NAS itself (such as an identifier or an 369 address), information about the access medium (such as phone numbers 370 and speeds), and real-world information (such as locale and time of 371 day). TO DO: Expand this list in detail: what attributes are required 372 in a AAA protocol? 374 Profile information directs the NAS to deliver specific services to 375 the user. Examples of services are IP address filtering, address 376 assignment, route assignment, QoS/differential services, bandwidth 377 control/traffic management, compulsory tunneling to a specific 378 endpoint, and encryption. TO DO: Expand this list in detail. What 379 attributes are required? 381 A user's requested or authorized service profile may change dynami- 382 cally at any time during a session. The AAA protocol MUST support 383 dynamic authorization at any time during delivery of services to the 384 user. 386 9.2.3. Accounting 388 A NAS provides accounting of the resources consumed and released by 389 users. This accounting information is used for a variety of purposes. 390 Some of these purposes impose no restrictions on the timing of 391 accounting; other purposes, such as on-line auditing and dynamic 392 resource management, require that accounting information be transmit- 393 ted in real time, as resources are consumed. Therefore a AAA protocol 394 MUST support real-time accounting, and SHOULD support a batch method 395 of accounting when the overhead of real-time accounting is not 396 required. 398 Component failures and data loss may occur at any place in a network, 399 but tracking of resource consumption is required functionality regard- 400 less. Also, tracking of current NAS state is required in order to 401 implement resource management policy. Since a NAS or a AAA server may 402 fail and then come back on line, a AAA protocol MUST support on-demand 403 accounting to provide recovery. As a safeguard against data loss, a 404 AAA protocol SHOULD support periodic updates of accounting, rather 405 than simply accounting at the beginning and end of a session. 407 9.3. Applications of NAS's 409 9.3.1. Virtual Private Networks 411 NAS's often particpate in VPN's or provide VPN services to users. 412 Examples include dial NAS's building compulsory VPN's, dial NAS's pro- 413 viding services to voluntary VPN users, and tunnel NAS's providing 414 tunnel termination services. If a NAS provides compulsory VPN's, it 415 MUST support the building of L2TP tunnels [L2TP] secured by IPSec 416 [L2TP-IPSEC]. 418 9.3.2. Roaming 420 NAS's are often used to provide roaming services. If a NAS is part of 421 a network that provides roaming, then the AAA protocol that it imple- 422 ments MUST support roaming requirements as detailed in [ROAMING 423 REQUIREMENTS]. 425 10. Acknowledgements 427 Some of the text in this document is taken from [ROUTER REQUIREMENTS], 428 and many thanks go to its author. Thanks also to Dave Mitton of Bay 429 Networks and Rich Petke of MCI WorldCom for many useful discussions of 430 this problem space. 432 11. References 434 [SNMP] J. Case, M. Fedor, M. Schoffstall, and J. Davin. "A Simple 435 Network Management Protocol (SNMP)." RFC 1157, SNMP Research, Perfor- 436 mance Systems International, Performance Systems International, and 437 MIT Laboratory for Computer Science, May 1990. 439 [PPP] W. Simpson. "The Point-to-Point Protocol (PPP)." RFC 1661, 440 Daydreamer, July 1994. 442 [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate 443 Requirement Levels." RFC 2119, Harvard University, March 1997. 445 [ROUTER REQUIREMENTS] F. Baker. "Requirements for IP Version 4 446 Routers." RFC 1812, Cisco Systems, June 1995. 448 [L2TP] W. M. Townsley, et al. "Layer Two Tunneling Protocol (L2TP)." 449 Work in progress. 451 [PPP CHAP] W. Simpson. "PPP Challenge Handshake Authentication Pro- 452 tocol (CHAP)." RFC 1994, Daydreamer, August 1996. 454 [EAP] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto- 455 col (EAP)." RFC 2284, Merit Network, Inc., March 1998. 457 [NAI] B. Aboba, M. Beadles. "The Network Access Identifier." RFC 458 2486, Microsoft, WorldCom Advanced Networks, January 1999. 460 [ROAMING REQUIREMENTS] B. Aboba, G. Zorn. "Criteria for Evaluating 461 Roaming Protocols." RFC 2477, Microsoft, January 1999. 463 [L2TP-IPSEC] B. Patel, B. Aboba. "Securing L2TP using IPSec." Work 464 in progress. 466 12. Author's Address 468 Mark Anthony Beadles 469 MCI WorldCom 470 5000 Britton Rd. 471 Hilliard, OH 43026 473 Phone: 614-723-1941 474 EMail: mbeadles@wcom.net 476 13. Full Copyright Statement 478 Copyright (C) The Internet Society (1999). All Rights Reserved. 480 This document and translations of it may be copied and furnished to 481 others, and derivative works that comment on or otherwise explain it 482 or assist in its implmentation may be prepared, copied, published and 483 distributed, in whole or in part, without restriction of any kind, 484 provided that the above copyright notice and this paragraph are 485 included on all such copies and derivative works. However, this docu- 486 ment itself may not be modified in any way, such as by removing the 487 copyright notice or references to the Internet Society or other Inter- 488 net organizations, except as needed for the purpose of developing 489 Internet standards in which case the procedures for copyrights defined 490 in the Internet Standards process must be followed, or as required to 491 translate it into languages other than English. The limited permis- 492 sions granted above are perpetual and will not be revoked by the 493 Internet Society or its successors or assigns. This document and the 494 information contained herein is provided on an "AS IS" basis and THE 495 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 496 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 497 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 498 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 499 PARTICULAR PURPOSE." 501 14. Expiration Date 503 This document is filed as , and 504 expires August 25, 1999.