idnits 2.17.1 draft-greene-nasreq-00.txt: -(49): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(197): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(210): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-03-29) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 6 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 405 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 62 has weird spacing: '...to optimize ...' == Line 68 has weird spacing: '...ty. The carri...' == Line 111 has weird spacing: '...unction may c...' == Line 119 has weird spacing: '...proxies to ot...' == Line 212 has weird spacing: '...modems grows,...' == (2 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 ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'DSM-CC' on line 270 == Unused Reference: '1' is defined on line 391, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 394, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Nancy Greene 2 Category: Informational Nortel (Northern Telecom) 3 Title: Fernando Cuervo 4 Date: March 1998 Nortel (Northern Telecom) 5 Expires: September 1998 7 Best Current Practice for Modem Outsourcing 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 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 material 20 or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 25 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This document describes an architecture and the protocol used with 31 respect to a Network Access Server (NAS), when modems are outsourced 32 from the data network operator to the carrier network operator. At the 33 heart of modem outsourcing there are several key areas, namely, varied 34 mechanisms for authentication, authorization based on network wide state 35 and policy for resource sharing, accounting/auditing and other 36 management functions. 38 1.0 Introduction 40 Presently, dial-up connections over the public telephone network are 41 used for on-demand connection to the Internet or corporate networks. An 42 ISP may wish to outsource its modems to the telephone or carrier network 43 operator. In this case, the carrier network provides connections and 44 modems while the data network operator (e.g., an ISP or a corporate 45 network) is responsible for other functions such as subscriber 46 authentication, or accounting. Data network operators benefit by 47 replacing remote access hardware with a virtual modem pool service 48 provided by a carrier, traffic is forwarded from the resources that make 49 up the virtual modem pool over broadband connections to one or more �ISP 50 gateways�, or Home Gateways. The virtual modem pool provides the ISP 51 with independence from the signaling used at the NAS (for example, PRI 52 or SS7). 54 2.0 Modem outsourcing requirements 56 Modem outsourcing and mass deployment of dial-up access, need 57 capabilities that are beyond the functionality provided by RADIUS. When 58 NAS boxes are placed in the carrier network operator domain many new 59 factors are introduced in the way NAS boxes operate: 61 1-Resource control is more complex since network resources can be shared 62 to optimize cost (e.g., modem pools may be dynamically shared 63 between ISPs). 65 2-Resources such as tunnels may be authorized, set up and controlled in 66 many ways (e.g., according to ISP, or tunnel type). 68 3-Access becomes a carrier�s responsibility. The carrier may need to 69 manage resources for different access networks. 71 Increased flexibility is introduced when the NAS is placed in the 72 carrier network. In the case of modem outsourcing, several distinct 73 configurations can be defined depending on the following factors: 75 1-Where the point of authentication is (e.g., carrier network operator 76 domain or ISP). 78 2-The level and distribution of authorization (for example, before and 79 after end-user authentication, or just after. Note that RADIUS uses an 80 end-user based authentication-authorization model. However, in the 81 shared environment that results from modem outsourcing, authorization 82 functions in the carrier network operator domain must often be based on 83 the attributes of both the end-user and the ISP. 85 3-Whether signaling is physically co-located with the connection it 86 establishes (e.g., front-end PRI signaling), or whether it is physically 87 separate from the connection (e.g., back-end SS7 signaling). 89 4-Control and management relationships between carrier and ISP network 90 elements, e.g. ISP Home Gateways, NAS Controller/AAA Servers in the 91 carrier network, AAA Servers/Proxies. 93 These factors place requirements on the protocol that are above and 94 beyond the scope of RADIUS. The protocol described in section 6.0, DSM- 95 CC, includes functions for system configuration and resource control 96 that provide the flexibility required to properly address these 97 requirements. 99 3.0 Terminology 101 AAA Server function 102 This function provides the NAS with Authentication, Authorization, 103 Accounting and/or other management functions. It may be located in the 104 ISP, in the carrier network, or both. 106 AAA Proxy function 107 It is a proxy to a AAA Server. 109 Network Access Server (NAS) Control function 110 A NAS Control function allocates and deallocates resources according 111 to some resource policy. A NAS Control function may control many NAS. 112 It may share a server platform with AAA server functions and/or proxies 113 to other AAA Servers. It may be located at an ISP, but is more likely 114 found in a carrier network, for example, allowing NAS to be shared among 115 ISPs. 117 NAS Controller/AAA Server/Proxy (NCAP) 118 This is a server platform that hosts the NAS Control function. This 119 platform may also host AAA server functions and/or proxies to other AAA 120 Servers. It is typically deployed in the carrier network domain, for 121 example, allowing NAS to be shared among ISPs. In some situations it may 122 be deployed in the data network domain. The AAA functions may be RADIUS 123 based or other. 125 End-User 126 The subject of the authentication/authorization. 128 Data Network Operator 129 An ISP or corporation, sometimes referred to as the wholesale- 130 customer. 132 Carrier Network Operator 133 Provider of access and transport services between the end-user and a 134 data network. 136 Network Access Server (NAS) 137 The Network Access Server (NAS) is the device that provides resources 138 for users to access the data network. A NAS provides physical 139 terminations of user access connections, and modems. A NAS includes a 140 client that uses the functions of a NAS control server. 142 ISP (Home) Gateway 143 Network interworking platform between the Carrier Network and Data 144 Network domains. 146 4.0 Modem Outsourcing Architectures 148 +----------+ +------------+ 149 |NAS | |RADIUS (AAA)| 150 |Controller| |Server | 151 | | | | 152 +----------+ +------------+ 153 ^ | 154 | | 155 +-----------+ | 156 | | 157 v | 158 +-------+ +-----------+ 159 end-user --- >| | | ISP (Home)| 160 |NAS | < --------------- > | Gateway | 161 | | | | 162 +-------+ +-----------+ 164 Figure 1: Modem outsourcing architecture - scenario 1 166 In modem outsourcing there are currently two scenarios for establishing 167 a data session to an ISP. In the first scenario, authentication, 168 authorization and accounting is done by the ISP (Figure 1). PPP is 169 carried all the way to the ISP. Access to a tunnel may be subject to 170 authorization functions exercised by the NAS itself or an authorization 171 server (NAS Controller) in the carrier network operator domain. The 172 client in the NAS collects the authentication information from the user. 173 The information is then tunneled to a target network and its target 174 RADIUS (AAA) server. 176 +-----------+ +------------+ 177 |NAS | |RADIUS (AAA)| 178 |Controller/| |Server | 179 |AAA Proxy | < --- >| | 180 +-----------+ +------------+ 181 ^ | 182 | | 183 +----------+ | 184 | | 185 v | 186 +-------+ +-----------+ 187 end-user --- >| | | ISP (Home)| 188 |NAS | < --------------- > | Gateway | 189 | | | | 190 +-------+ +-----------+ 192 Figure 2: Modem outsourcing architecture - scenario 2 194 In the second scenario (Figure 2), PPP is terminated at the NAS. When 195 this is the case, a client in the NAS must contact an appropriate server 196 for user authentication. If necessary, (normally for scalability 197 reasons,) a proxy may be used between the NAS and the ISP�s AAA Server. 198 In this scenario, end-user authorization functions are more naturally 199 integrated with the authentication steps, but it is likely that some 200 level of authorization would be exercised by NAS Controller/AAA Server 201 in the carrier network operator domain (e.g., based on attributes of the 202 target ISP). Accounting is fairly independent of the setup style, the 203 NAS collects resource and traffic information that can be relayed to the 204 ISP according to the specific requirements (i.e. main accounting source, 205 auditing, monitoring functions, etc.) 207 4.1 Properties of the NCAP-NAS architecture 209 Having a few NCAPs in the network for a large number of NAS boxes makes 210 the NAS systems scaleable. Thus, instead of an ISP�s AAA server needing 211 to be able to serve a large number of NAS, as the number of outsourced 212 modems grows, it can deal with a lesser number of NCAPs in the network. 213 In modern large NAS systems (e.g., many NAS boxes, several ISPs, roaming 214 users, etc.) NAS boxes do not have the resources to store policy and 215 configuration information (let alone the complexity of maintaining all 216 these data). The NCAP is responsible for coordinating the administrative 217 functions, modem pool resource allocation and configuration policies. 218 The dependency between a NAS and a NCAP in the network varies according 219 to the NAS box capabilities for storing and enacting policy (resource 220 and administrative), and on the complexity of the interworking between 221 networking domains. The NCAP is also responsible for insulating the ISP 222 from specific aspects of NAS boxes (e.g., vintage, manufacturer, etc). 224 Additionally, as NAS boxes continue growing their port capacity the 225 NCAP-NAS protocol must be able to efficiently support the configuration 226 and control of a large number of resources and devices. 228 The interaction between the NAS and the NCAP uses a subset of the 229 ISO/IEC DSM-CC User-Network protocol [DSM-CC], with extensions [DSM-CC 230 extensions]. This is done to support the additional flexibility that 231 modem outsourcing requires (See section 2.0.) This protocol is outlined 232 in section 6.0. Interaction between the NCAP in the network and an AAA 233 Server at an ISP may be based on the DSM-CC protocol with extensions, or 234 a RADIUS proxy. Ideally, all interaction between AAA servers can be 235 supported by the same protocol as the one between the NAS and its NCAP. 237 5.0 Requirements for a NAS <-> NCAP protocol 239 >From the discussion above, we can now determine some of the requirements 240 for a NAS <-> NCAP protocol. It must: 242 - allow separation of AAA (AAA -> A/A/A) 244 Separating the AAA allows different configurations. For example, 245 authorization may be handled by an NCAP in the network, while 246 authentication is always performed by the AAA Server at the ISP. Also, 247 accounting records may be kept by the ISP or by the network, or both. 249 - be a simple light-weight and symmetric protocol that allows NAS -> 250 Server and Server -> NAS requests. 252 An ISP may require information about NAS usage, or resources available. 253 This should be available on demand. 255 - support resource policy and configuration (e.g. tunnels). 257 The protocol should allow, for instance, tunneling attributes per user 258 to be stored at an ISP or in the network, to be requested by a NAS as 259 required for tunnel setup. NAS running independently of an NCAP is an 260 example of policy and configuration since the NAS must have this 261 information. 263 - allows sharing of NAS resources between ISPs. 265 This is generally accomplished by allowing control of a NAS by an 266 intermediary such as a network operator (i.e. outsourcing). 268 6.0 DSM-CC Functionality 270 DSM-CC is a light-weight ISO standard protocol [DSM-CC]. It is a 271 request/response protocol that is usually implemented over UDP/IP. The 272 following NAS functionality is provided using its message set. 274 6.1 NAS Initialization 276 Used by the NAS to indicate that it is ready to respond to the NCAP, it 277 may indicate the �services� that it is ready to support. Basic 278 configuration information such as hardware and software versions may be 279 communicated to the NCAP. The response from the NCAP indicates whether 280 the management and control associations requested will take place. 281 Configuration information may be supplied at this point by the NCAP to 282 the NAS, for instance, several timers that govern the control 283 relationship between the NAS and the NCAP may be set at this point. 285 DSM-CC messages: 286 UN-Config*, * = 288 6.2 NAS failure recovery 290 A failed NAS will try to reestablish a control association using the NAS 291 Initialization messages. The NCAP will launch a NAS Audit to match 292 against the NAS state last known to the control server. 294 DSM-CC messages: 295 UN-Config*, * = 297 6.3 NAS Control Server reset indication 299 The NCAP must reestablish the association with the NAS. Configuration 300 information may be exchanged, including the definition of a new NCAP. 301 This action must be followed by an update of the state changes of the 302 NAS and its resources that occurred while running without the NCAP. 304 DSM-CC messages: 305 UN-Config*, * = 307 6.4 Link Failure recovery 309 The NCAP or the NAS may reestablish the association. This must be 310 followed by an update of the state changes of the NAS and its resources 311 that occurred while running without the NCAP. 313 DSM-CC messages: 314 UN-Config*, * = 316 6.5 Resource Allocate/Release 318 DSM-CC Session messages are used to allocate NAS resources to end-users. 319 Session set-up messages may involve authentication or authorization 320 functionality. A session identifier is used to simplify the control and 321 management of resources used in a single association between an end-user 322 and an ISP. Session messages may be initiated by the NAS or the NCAP, 323 depending on the location of the native signaling and authentication 324 client (e.g., in the NAS for PRI or in the NCAP for SS7). Authentication 325 may be carried out in the NCAP, proxied to another server or tunneled to 326 the ISP. Authorization functions in the NCAP determine users rights to 327 access resources before and after authentication. Separate Add/Delete 328 resource messages are provided by DSM-CC, however, they are not 329 necessary for current NAS applications. 331 DSM-CC messages: 332 ClientSessionSetUp*, * = 333 ClientRelease*, * = 335 6.6 ISP Gateway (Home Gateway) 337 Coordinated action between the NAS, the NCAP and the ISP gateway is 338 necessary. Depending on the mode of operation, the state of a target ISP 339 may be known (e.g., via management) or inferred (e.g., via retries) by 340 either the NAS or the NCAP. When the ISP Gateway is unavailable, the NAS 341 and the NCAP must coordinate their actions for Session Set-Up and 342 Release. 344 DSM-CC messages: 345 ClientSessionSetUp*, * = 346 ClientRelease*, * = 348 6.7 Initiate accounting (for local PPP termination) 350 successful establishment of an end-to-end session is notified by the NAS 351 to the NCAP. The NAS signals the NCAP to indicate that it has 352 successfully connected the data session, and that it is proceeding to 353 forward packets to the ISP. This message is used to trigger generation 354 of accounting records and to convey additional call set-up information. 356 DSM-CC Messages: 357 ClientConnect* * = 359 6.8 NAS Audit 361 The NCAP requests status of a session or sessions from the NAS. 363 DSM-CC Messages: 364 ClientStatus* * = 366 7.0 Way Forward 368 It is proposed to use DSM-CC as a basis for a RADIUS replacement 369 protocol for modern NAS. DSM-CC would provide secure, bi-directional 370 functions for subscriber authentication, resource configuration, status 371 reports and subscriber management. Since RADIUS is widely used for 372 authentication of dial-up users, DSM-CC would be adapted for 373 compatibility with RADIUS. 375 8.0 Authors 377 Fernando Cuervo 378 Nortel 379 Ottawa, ON, Canada. 380 Phone: 613-763-4628 381 EMail: cuervo@nortel.ca 383 Nancy Greene 384 Nortel 385 Ottawa, ON, Canada 386 Phone: 613-763-9789 387 Email: ngreene@nortel.ca 389 9.0 References 391 [1] ISO/IEC 13818-6 Digital Storage Media - Command and Control, N3100, 392 July 1996 394 [2] ISO/IEC 14496-6 WD 2.0, Delivery Multimedia Integrated Framework V2, 395 ISO/IEC JTC1/SC29/WG11 N2059 MPEG 98, February 6/98, San Jose 397 -----------------------------------------------------------------------