idnits 2.17.00 (12 Aug 2021) /tmp/idnits2057/draft-lior-radius-prepaid-extensions-02.txt: 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: ---------------------------------------------------------------------------- == There are 31 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: Note that the PrePaid Server role is not to record accounting messages and therefore it SHOULD not respond with an Accounting Response packet. == 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: The Authorize Only Access-Request MUST not include either User Password or Chap Password. In order to authenticate the message, the Access Device MUST include the Message-Authenticator(80) attribute. The Access Device will compute the value for the Message-Authenticator based on [RFC2869]. -- 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 (October 27, 2003) is 6780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CHIBA' is mentioned on line 1300, but not defined == Unused Reference: 'RFC2868' is defined on line 1498, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 INTERNET-DRAFT Bridgewater Systems 4 Category: Informational P. Yegani 5 draft-lior-radius-prepaid-extensions-02.txt Cisco 6 Expires: 27 March, 2004 K. Chowdhury 7 Nortel 8 L. Madour 9 Ericsson Canada 10 Y. Li 11 Bridgewater Systems 12 October 27, 2003 14 PrePaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of [RFC2026]. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 The draft presents an extension to the Remote Authentication Dial-In 44 User Service (RADIUS) protocol to support PrePaid data services for 45 a wide range of deployments such as Dial, Wireless, WLAN. 46 Consideration for roaming using mobile-ip is also given. 48 Table of Contents 50 1. Introduction...................................................4 51 1.1 Terminology................................................6 52 1.2 Requirements language......................................6 53 2. Architectural Model............................................6 54 3. Use-cases.....................................................14 55 3.1 Simple pre-paid access use-case...........................15 56 3.2 Simple Service Device use-case............................17 57 3.3 Support for concurrent PrePaid sessions...................18 58 3.4 Support for Roaming.......................................19 59 3.5 PrePaid termination.......................................19 60 4. Operations....................................................20 61 4.1 General Requirements......................................20 62 4.1.1 Broker AAA Requirements..............................20 63 4.2 Authentication and Authorization for Prepaid Enabled Access 64 Devices.......................................................20 65 4.2.1 Single Service Pre-paid..............................22 66 4.2.2 Multiple-Session Pre-paid............................23 67 4.3 Session Start Operation...................................24 68 4.4 Mid-Session Operation.....................................25 69 4.5 Dynamic Operations........................................27 70 4.5.1 Unsolicited Session Termination Operation............27 71 4.5.2 Unsolicited Change of Authorization Operation........28 72 4.6 Termination Operation.....................................29 73 4.7 Mobile IP Operations......................................30 74 4.8 Accounting Considerations.................................30 75 4.9 Service Device Operation..................................31 76 4.10 Interoperability with Diameter Credit Control Application31 77 5. Attributes....................................................31 78 5.1 PPCC attribute............................................32 79 5.2 Dynamic-Capabilities attribute............................33 80 5.3 PPAQ Attribute............................................33 81 5.4 Tarrif Switch.............................................36 82 5.5 Table of Attributes.......................................36 83 6. Security Considerations.......................................36 84 6.1 Authentication and Authorization..........................37 85 6.2 Replenishing Procedure....................................37 86 7. IANA Considerations...........................................37 87 8. Normative References..........................................37 88 Acknowledgments..................................................38 89 Author's Addresses...............................................38 90 Intellectual Property Statement..................................39 91 Full Copyright Statement.........................................39 92 Expiration Date..................................................40 94 1. Introduction 96 This draft describes RADIUS protocol extensions supporting PrePaid 97 Data Services. 99 PrePaid data services are cropping up in many wireless and wireline 100 based networks. A PrePaid Data Service subscriber is one that 101 purchases a contract to deliver a data service for either a period 102 of time, or a quantity of data. Before providing a prepaid data 103 service, the service provider checks that the prepaid subscriber has 104 sufficient funds to cover the particular service request. Only after 105 confirmation that funds are available is the service provided to the 106 user. 108 The subscriber purchases the Data Service using various means such 109 as buying a PrePaid Card, or online. How the subscriber purchases 110 their PrePaid Data Service depends on the deployment and is not in 111 scope for this document. 113 In some deployments, the PrePaid data service will be combined with 114 other Prepaid services such as PrePaid voice service. This is not 115 an issue for this document other than the fact that the PrePaid Data 116 Services described in this paper should work with other PrePaid data 117 services. 119 The fundamental business driver for a carrier to provide PrePaid 120 data services is to increase participation (subscriber base) and 121 thus to increase revenues. Therefore, it makes sense that PrePaid 122 services meet the following goals: 124 - Leverage existing infrastructure, hence reducing capital 125 expenditures typically required when rolling a new service; 126 - Ability to rate service requests in real-time; 127 - Ability to check that the end user’s account for coverage for the 128 requested service charge prior to execution of that service; 129 - Protect against revenue loss, i.e., prevent an end user from 130 generating chargeable events when the credit of that account is 131 exhausted or expired; 132 - Protect against fraud; 133 - Be as widely deployable over Dialup, Wireless and WLAN networks. 135 The protocol described in this document maximizes existing 136 infrastructure as much as possible – hence the use of the RADIUS 137 protocol. The protocol is used in ways to protect against revenue 138 loss or revenue leakage. This is achieved by defining procedures 139 for the real-time delivery of service information to a pre-paid 140 enabled AAA server, to minimize the financial risk, for the pre-paid 141 enabled AAA server to be able to allocate small quotas to each data 142 session and having the ability to update the quotas from a central 143 quota server dynamically during the lifetime of the PrePaid data 144 session. As well, mechanisms have been designed to be able to 145 recover from errors that occur from time to time. 147 Protection against fraud is provided by recording of accounting 148 records, by providing mechanisms to thwart replay attacks. As well, 149 mechanisms have been provided to terminate data sessions when fraud 150 is detected. 152 PrePaid System will become more prevalent and sophisticated as the 153 various networks such as Dialup, Wireless and WLAN converge. This 154 protocol extension is designed to meet the challenges of converged 155 networks. The draft mainly addresses how to use the RADIUS protocol 156 to achieve a PrePaid Data Service. The prepaid architecture assumes 157 that rating of chargeable events does not occur in the element 158 providing the service. This rating could be performed in the prepaid 159 enabled AAA server or may exist in an entity behind this AAA server. 160 Business logic and service rules may define that tariffing of events 161 vary in time, e.g., the particular price per megabyte download may 162 be defined to switch at 8pm from a high tariff to a low tariff. The 163 RADIUS extensions for prepaid support scenarios enable scalable 164 implementation of tariff switched prepaid systems. 166 Furthermore, the prepaid architecture assumes that a quota server is 167 available which, through co-ordination with the rating entity and 168 centralized balance manager is able to provide a quota response in 169 response for prepaid data service. This quota server functionality 170 could be performed in the prepaid enabled AAA server or may exist in 171 an entity behind this AAA server. Finally, the details of the 172 PrePaid System, such as its persistent store, how it maintains its 173 accounts are not covered at all. However, in order to define the 174 RADIUS protocol extensions it is necessary to discuss the functional 175 behavior of the PrePaid System. 177 1.1 Terminology 179 Access Device 180 PrePaid Client 181 PrePaid Server 182 Home agent (HA) 183 Home network 184 Home AAA (HAAA) 185 Broker AAA (BAAA) 186 Visited AAA (VAAA) 187 Foreign Agent (FA) 188 WLAN 189 Service Device 191 1.2 Requirements language 193 In this document, several words are used to signify the requirements 194 of the specification. These words are often capitalized. The key 195 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 197 this document are to be interpreted as described in [RFC2119]. 199 2. Architectural Model 201 The architectural model supports prepaid clients on either an access 202 device or a service device. An access device (e.g. a NAS) typically 203 provides a single service to end-users, corresponding to network 204 access. The service device enables finer grain services to be 205 defined. For example, a service may be defined for access to a 206 particular destination network, which enables further segmentation 207 of services within the network. An access device and service device 208 may be combined into a single physical entity. 210 When pre-paid service is used the access or service device collects 211 service event information and reports it while and/or after services 212 are provided to the prepaid user. This event information is sent to 213 a prepaid server by using the prepaid RADIUS extensions. 215 If real-time credit control is required, the access or service 216 device (prepaid client) contacts the prepaid server with service 217 event information included before the service is provided. The 218 prepaid server, depending on the service event information, performs 219 credit check and allocates a portion of available credit to the 220 service event. The rating entity converts this credit value into a 221 time and/or volume amount, which is then returned to the requesting 222 device. The rating entity may determine that during the allocated 223 quota, a tariff switch will occur in which case the rating entity 224 will include details of the quota allocated prior to the tariff 225 switch, details of the quota allocated after the tariff switch 226 together with details of when the tariff switch will occur. 228 The requesting device (either access or service device) then 229 monitors service execution according to the instructions returned by 230 the prepaid server. After service completion or on a subsequent 231 request for service, the prepaid server deducts the reserved 232 allocation of credit from the prepaid user’s account. 234 Similarly, when a user terminates an on-going prepaid service, the 235 prepaid client signals the prepaid server with the a value 236 corresponding to the unused portion of the allocated quota. The 237 prepaid server is then able to refund unused allocated funds into a 238 user’s prepaid account. 240 There MAY be multiple prepaid servers in the system for reasons of 241 redundancy and load balancing. The system MAY also contain separate 242 rating server(s) and accounts MAY locate in a centralized database. 243 System internal interfaces can exist to relay messages between 244 servers and an account manager. However the detailed architecture 245 of prepaid system and its interfaces are implementation specific and 246 are out of scope of this specification. 248 accounting 249 +------------+ +-----------+ protocol +--------------+ 250 | Access |<----->| Service |<------------>| Accounting | 251 | Device | +-->| Device |<-----+ | Server | 252 +------------+ | +-----------+ | +--------------+ 253 | | 254 +------------+ | | 255 | Access |<--+ | +--------------+ 256 | Device | +------>| PrePaid | 257 +------------+ prepaid | Server | 258 protocol +--------------+ 260 Figure 1 Basic Prepaid Architecture 261 The prepaid server and accounting server in this architecture model 262 are logical entities. The real configuration MAY combine them into a 263 single host. 265 There MAY exist protocol transparent RADIUS Proxies between prepaid 266 client and prepaid server. These proxies transparently support the 267 prepaid RADIUS extensions. 269 In order to generalize the solution, in this paper we generalize the 270 Access Devices, which in reality may be a NAS from in Dialup 271 deployments, PDSN in CDMA2000 deployments,an 802.11 WLAN Access 272 Points or GGSN in GSM deployments. To actively participate in 273 Prepaid procedures outlined here, the Access Device MUST have 274 Prepaid Client capabilities. Prepaid Client Capabilities include 275 the ability to meter the usage for a prepaid data session; this 276 usage includes time or volume usage. 278 In circumstances when the Access Device does not support the Prepaid 279 client capabilities, prepaid client functionality may be provided 280 using either a stand alone service device or, in the case of roaming 281 scenarios using mobile IP, the prepaid client functionality may be 282 delegated to the Home Agent. It may also be possible to deliver 283 limited prepaid services using RADIUS capabilities specified in 284 RFC2865 and RFC2866. 286 Furthermore, the device including the prepaid client functionality 287 may also have Dynamic Session Capabilities that include the ability 288 to terminate a data session and/or change the filters associated 289 with a specific data session by processing Disconnect Messages and 290 Change of Filter messages as per [RFC3576]. 292 In this document RADIUS is used as the AAA server. There are three 293 kinds or categories of AAA servers. The AAA server in the home 294 network, the HAAA, is responsible for authentication of the 295 subscriber and also authorization of the service. In addition, the 296 HAAA communicates with the Prepaid servers using the RADIUS protocol 297 to authorize prepaid subscribers. In AAA based roaming deployments 298 the AAA server in the visited network, the VAAA, is responsible for 299 forwarding the RADIUS messages to the HAAA. The VAAA may also 300 modify the messages. In roaming deployments, the visited network 301 may be separated from the home network by one or more broker 302 networks. The AAA servers in the broker networks, BAAA are 303 responsible to route the RADIUS packets and hence don’t play an 304 active roll in the Prepaid Data Service delivery. 306 In this document the Prepaid Server is described in functional terms 307 related to their interface with the HAAA. The Prepaid Server 308 interfaces to entities which: 310 i) Keep the accounting state of the prepaid subscribers (balance 311 manager); 312 ii) Allow service requests to be rated in real-time (Rating Engine); 313 and 314 iii) Allow quota to be managed for a particular pre-paid service 315 (Quota Server). 317 The various deployments for Prepaid are presented in the remainder 318 of this section. The first deployment is the basic Prepaid data 319 service and is depicted in figure 2. Here the Access Device which 320 supports the prepaid client functionality, the HAAA and the Prepaid 321 Server are collocated in the same provider network. 323 The Subscriber Device establishes a connection with one of several 324 Access Devices in the network. The Access Device communicates with 325 one or more HAAA servers in the network. To provide redundancy more 326 then one HAAA is available to use by an Access Device. 328 The network will have one or more Prepaid Servers. Multiple Prepaid 329 Servers will be used to provide redundancy and load sharing. The 330 interface between the HAAA and the PPS is the RADIUS protocol in 331 this specification. However, in cases where the PPS does not 332 implement the RADIUS protocol, the implementation would have to map 333 the requirements defined in this document to whatever protocol is 334 used between the HAAA and the PPS. 336 +------+ +-----+ 337 | | | | 338 +--------+ +--------+ +--| HAAA |--+--| PPS | 339 | | | | | | | | | | 340 | Sub | | Access | | +------+ | +-----+ 341 | |---| |--+ | 342 | Device | | Device | | +------+ | +-----+ 343 | | | | | | | | | | 344 +--------+ +--------+ +--| HAAA |--+--| PPS | 345 | | | | 346 +------+ +-----+ 348 Figure 2 Basic Prepaid Access Architecture 350 In the second deployment scenario, the Access Device does not 351 support the prepaid client functionality. Instead an independent 352 Service Device provides prepaid client functionality as depicted in 353 figure 3. Here the Access Device which dose not supports the 354 prepaid client functionality is configured as AAA client to the AAA 355 proxy functionality in the Service Device. The Service device, which 356 supports the prepaid client functionality then appends prepaid 357 extensions in the AAA requests proxied to the HAAA. 359 The Subscriber Device establishes a connection with one of several 360 Access Devices in the network. The Authentication and Authorization 361 requests from the Access Device are proxied through the Service 362 Device which then appends prepaid extensions on to the requests. The 363 Service Device communicates with one or more HAAA servers in the 364 network. The Service Device is responsible for removing prepaid 365 extensions from messages received from the HAAA before proxying them 366 on to the Access Device. To provide redundancy more then one 367 Service Devices are available to use by an Access Device and more 368 than one HAAA is available for use by the Service Device. The 369 Service Device is configured to be default gateway to the Access 370 Device, enabling all traffic to be correctly metered. 372 (AAA) +---------+ +------+ +-----+ 373 +------------| Service | | | | | 374 +--------+ | | |--+--| HAAA |--+--| PPS | 375 | | +--------+ +--| Device | | | | | | | 376 | Sub | | Access | (IP)| +---------+ | +------+ | +-----+ 377 | |---| |-----+ | | 378 | Device | | Device | | +---------+ | +------+ | +-----+ 379 | | +--------+ +--| Service | | | | | | | 380 +--------+ | | |--+--| HAAA |--+--| PPS | 381 +------------| Device | | | | | 382 AAA) +---------+ +------+ +-----+ 384 Figure 3 Prepaid Service Architecture 386 The following figure 4 shows a static roaming prepaid architecture 387 that is typical of a wholesale scenario for Dial-Up users or a 388 broker scenario used in Dial-Up or WLAN roaming scenarios. 390 +----+ +----+ +----+ +-----+ 391 | | | | | | | | 392 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 393 | | | | | | | | | | | | | | | | 394 |Sub | |Access| | +----+ | +----+ | +----+ | +-----+ 395 | |--| |-+ | | | 396 |Device| |Device| | +----+ | +----+ | +----+ | +-----+ 397 | | | | | | | | | | | | | | | | 398 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 399 | | | | | | | | 400 +----+ +----+ +----+ +-----+ 402 | Visited | |Broker | | Home | 403 | Network | |Network| | Network | 405 Figure 4 Static Roaming Prepaid Architecture 407 As in the basic prepaid architecture the subscriber’s device 408 establishes a connection with the Access Device (NAS, WLAN Access 409 Point). The Access Device communicates with the Visiting AAA server 410 (VAAA) using the RADIUS protocol. Again for redundancy there maybe 411 more then one VAAA. The VAAA communicate using the RADIUS protocol 412 with AAA servers in the broker network (BAAA). There maybe more 413 then one Broker Network between the Visited Network and the Home 414 Network. The Home Network is the same as in the simple 415 architecture. 417 To support dynamic roaming the network will utilize mobile-ip. 418 Figure 5 illustrates a typical mobile-ip deployment. Note that 419 typically the mobile device would be moving between networks that 420 use the same technology such as Wireless or WLAN. Increasingly, 421 device will be able to roam between networks that use different 422 technology such as between WLAN and Wireless and Broadband. 423 Fortunately, mobile-ip can address this type of roaming and 424 therefore we need not be concerned with the underlying network 425 technology. 427 +------+ +------+ +----+ +----+ +----+ +-----+ 428 | | | | | | | | | | | | 429 |Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS | 430 | |--|Device| | | | | | | | | 431 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 432 | | | | | | 433 +------+ +------+ | | 434 | | | +----+ 435 | | | | | 436 |ROAMS +------------------+ HA | 437 | | | | 438 V +----+ | +----+ 439 +------+ +------+ | | | | 440 | | | | +-|VAAA+------+ | 441 |Sub | |Access| | | | | 442 | |--|Device+-+ +----+ | 443 |Device| | (FA) | | 444 | | | +------------------------+ 445 +------+ +------+ 447 Figure 5 Roaming using mobile-ip and pre-paid enabled Access 448 Devices 450 In figure 5, the Subscriber device establishes a prepaid session 451 between the Access Device in the foreign network, which has prepaid 452 capabilities and the Home Agent (HA). The setup for this service is 453 identical to the cases covered above. Notice that the Access Device 454 is known as the Foreign Agent (FA). As the subscriber device moves 455 to another network it establishes a connection with another Access 456 Device in another foreign network. The prepaid data service should 457 continue to be available. When a device associates to another 458 Access Device it MUST re-authenticate at the new Access Device and 459 de-associate or logoff the old Access Device. Furthermore, any 460 unused quota at the old Access Device MUST be promptly credited back 461 to the subscribers account. The reason we say promptly, is because 462 if the subscriber is very low on resources to start with, the 463 subscriber may not have enough resources to log on to the new Access 464 Device. The speed at which resources can be returned depend on the 465 type of handoff procedure that is used: dormant handoff vs. active 466 handoff vs. fast handoff. 468 As well, notice that if the Access Devices could communicate with 469 each other then there could be a way to accelerate a faster handoff 470 procedure. In particular, it could accelerate the return of the 471 unused portion of the quotas from the old Access Device. 473 Unfortunately, standards are evolving with each network technology 474 creating their own scheme to make the handoff procedures more 475 efficient. 477 Finally, pre-paid service may be provided in a roaming scenario 478 where the Access Devices do not support the prepaid client 479 capabilities. In such a scenario, a Service Device is configured as 480 AAA proxy to the Home Agent and also as default gateway for the home 481 agent, see Figure 6. 483 +------+ +------+ +----+ +----+ +----+ 484 | | | | | | | | | | 485 |Sub | |Access+---|VAAA|-|BAAA|----------------| | 486 | |-|Device| | | | | | | 487 |Device| | (FA) +-+ +----+ +-+--+ (AAA) | | 488 | | | | | | +---------+ |HAAA| 489 +------+ +------+ | | | | | | 490 | | | +----+ +---+ | | +-----+ 491 | | (IP) | | |(IP)|Ser| | | | | 492 |ROAMS +-------------+ HA |----| |--| |--| PPS | 493 | | | | |Dev| | | | | 494 V +----+ | +----+ +---+ +----+ +-----+ 495 +------+ +------+ | | | | 496 | | | | +-|VAAA+---+ | 497 |Sub | |Access| | | | | 498 | |-|Device+-+ +----+ | 499 |Device| | (FA) | (IP) | 500 | | | +-----------------+ 501 +------+ +------+ 503 Figure 6 Roaming using mobile-ip and prepaid enabled Service 504 Device behind the Home Agent. 506 3. Use-cases 508 In this section we present a set of use cases that will help 509 establish the requirements needed to deliver PrePaid data services. 510 These use cases don’t address how the PrePaid account is established 511 or maintained. It is assumed that the PrePaid subscriber has 512 obtained a valid account from a service provider such as a wireless 513 operator or a WLAN operator. 515 To make the document as general as possible, the use cases cover the 516 experience from the Access Device and not from the User’s Device. 517 The connection between the User’s Device, which typically involves 518 setting up a layer 2 session, e.g., PPP session or GPRS PDP Context, 519 is specific to a given network technology and the details are not 520 required to deliver a PrePaid service. 522 3.1 Simple pre-paid access use-case 524 A PrePaid subscriber connects to his home network. As usual, the 525 Access Device that is servicing the subscriber will use the AAA 526 infrastructure to authenticate and authorize the subscriber. 528 The Access Device sends a RADIUS Access-Request to the AAA system to 529 authenticate the subscriber, and identify and authorize the service. 530 The Access-Request includes the subscriber’s credentials and may 531 include the PrePaid capabilities of the Access Device. PrePaid 532 capabilities will be included if the Access Device supports PrePaid 533 functionality. 535 The AAA System proceeds with the authentication procedure. This may 536 involve several transactions such as in EAP. Once the subscriber 537 has been validated, the AAA system determines that the subscriber is 538 a PrePaid subscriber and requests that the PrePaid System authorize 539 the PrePaid subscriber. The request may include the PrePaid 540 Capabilities of the serving Access Device. These capabilities will 541 include whether the Access Device support optional granular prepaid 542 service. Granular prepaid service allows an Access Device to offer 543 service differentiation above plain network access, for example 544 discriminating between a prepaid service request for access to the 545 public Internet from access to a particular application server 546 hosted in the private domain of the home provider network. In the 547 simple prepaid access scenario, such capabilities are not required 548 to be supported by the Access Device. 550 The PrePaid System will validate that the subscriber has a PrePaid 551 Account; it will validate that the Account is Active; and will 552 validate that the Access Device has the appropriate PrePaid 553 capabilities. If all is in order, the PrePaid System will authorize 554 the subscriber to use the network. Otherwise it will reject the 555 request. The response is sent back to the AAA System. The response 556 includes attributes such as, definition of what services are 557 authorized. The exact definition of the service may define vanilla 558 network access or more granular service definition. The exact 559 definition of these services is not the focus of this draft. This 560 definition MAY include a “service key” which can be used to 561 correlate prepaid requests for access to a service with the service 562 definition in the prepaid system. Such service key information MUST 563 be included when the prepaid user has subscribed to more than one 564 prepaid service. If a user has subscribed to only a single service, 565 the response MAY also include an allocation of a portion of the 566 subscriber’s account called the initial quota (in units of time or 567 volume) and optionally a threshold value. When the rating engine 568 has determined that a tariff switch will shortly occur, the initial 569 quota may be segmented into that which SHOULD be used before the 570 tariff switch, that which SHOULD be used after the tariff switch 571 together with details describing the tariff switching instant. 573 The Access Device is responsible for requesting quota to be allocate 574 for a particular prepaid user. 576 In order to support concurrent PrePaid sessions, at any time, the 577 PrePaid System allocates a portion of the subscribers account to a 578 given PrePaid session. For example, in a multi-service environment 579 it might happen that an end user with an already ongoing service 580 (e.g., browsing the Internet) issues a new service request (e.g., 581 for downloading a ring-tone) towards the same account. Throughout 582 the lifetime of a session the Access Device will monitor usage 583 according to the quota(s) returned from the prepaid server and will 584 request further quota updates from the PrePaid System as previously 585 allocated quotas are consumed. Conditions may be included with 586 quotas, which indicate when an allocated quota should be returned to 587 the prepaid system. These conditions can include an idle timeout 588 associated with the provided quota. In this case, the Access device 589 monitors the service for activity. When a single inactivity period 590 exceeds that provided in the quota conditions, the unused quota is 591 returned to the prepaid server. 593 The AAA system incorporates the PrePaid attributes received from the 594 PrePaid System with the service attributes into an Access Response 595 message that it sends back to the Access Device. Note the AAA 596 System is responsible for authorizing the service whereas the 597 PrePaid System is responsible for PrePaid authorization. 599 Upon receiving the Access Response, the Access Device allows the 600 PrePaid data session to start and it starts to meter the session 601 based on time or volume, as indicated in the returned Quota 603 Once the usage for the session approaches the allotted quota (as 604 expressed by the threshold), the Access Device will request an 605 additional quota. The re-authorization for additional quota flows 606 through the AAA system to the PrePaid System. The PrePaid System 607 revalidates the subscriber’s account; it will subtract the previous 608 quota allocation from the user’s balance and if there is a balance 609 remaining it will reauthorize the request with an additional quota 610 allotment. Otherwise, the PrePaid System will reject the request. 611 Note the replenishing of the quotas is a re-authorization procedure 612 and does not involve re-authentication of the subscriber. 614 It is important to note that the PrePaid System is maintaining 615 session state for the subscriber. This state includes how much was 616 allocated during the last quota allocation for a particular session 617 and how much is left in the account. Therefore, it is required that 618 all subsequent messages about the PrePaid session reach the correct 619 PrePaid System. 621 Upon receiving a re-allotment of the quota, the Access Device will, 622 continue the data service session until the new threshold is 623 reached. If the Access Device receives a rejection, then it will 624 let the subscriber use up the remaining quota and then terminate the 625 session. 627 Alternatively, instead of terminating the session, the Access Device 628 may restrict the data session such that the subscriber can only 629 reach a particular web server. This web server maybe used to allow 630 the subscriber to replenish their account. This restriction can 631 also be used to allow new subscribers to purchase their initial 632 PrePaid Service. 634 Should the subscriber terminate the session before the session the 635 quota is used up, the remaining balance allotted to the session must 636 be credited back to the subscriber’s account. 638 As well, while the Access Device is waiting for the initial quota, 639 the subscriber may have dropped the session. The initial quota must 640 be credited back to the subscribers account. 642 3.2 Simple Service Device use-case 644 When the Access Device does not support the prepaid extensions, an 645 operator may still offer prepaid services to subscribers by using a 646 service device configured as default IP gateway to the Access 647 device. 649 A Prepaid subscriber connects to his home network in the usual way. 650 The non-prepaid enabled Access Device that is servicing the 651 subscriber will use the AAA infrastructure to authenticate and 652 authorize the subscriber. The Service device will be configured as 653 AAA proxy to the Access Device. 655 The Access Device sends an Access Request to the Service Device 656 acting as AAA proxy to authenticate the subscriber, and identify and 657 authorize the service. The Service Device will proxy the Access 658 Request and append its own Prepaid capabilities to the Access 659 Request message. These prepaid capabilities are defined identically 660 to the simple access device user-case. 662 The prepaid system performs functions as with prepaid support in the 663 Access Device, e.g., the AAA system incorporates the prepaid 664 attributes received from the Prepaid System with the service 665 attributes into an Access Response message that it sends back to the 666 Service Device. The Service device removes these attributes before 667 forwarding the Access Response message to the Access Device. 669 Upon receiving the Access Response with allocated quota, the Service 670 Device allows the prepaid data service session to start and since it 671 is configured as default gateway to the access device, it starts to 672 meter the session based on time and/or volume. 674 3.3 Support for concurrent PrePaid sessions 676 Both prepaid support using Access Devices and prepaid support using 677 Service Devices can be configured to support a prepaid multi-service 678 environment. In such circumstances, the prepaid client capabilities 679 will indicate that the Access or Service Device supports a multi- 680 service environment. In such circumstances, instead of returning a 681 quota, the prepaid service provides a list of authorized services 682 corresponding to a list of service keys to the prepaid client. The 683 Access/Service device then uses these service keys to request 684 prepaid authorization to the corresponding services. The prepaid 685 server responds with an individual quota for the requested service 686 key. The Access/Service Device may in parallel request prepaid 687 authorization to a second service key. In which case a separate 688 authorization exchange is used to provide an independent quota for 689 this second service. 691 Each session is treated independently. 693 The method by which a prepaid user activates a service and the 694 method for signaling this information to the Access/Service Device 695 is out of scope of this draft. 697 The method by which a granular service is defined is out of scope of 698 this draft. Only service key correlation information is required to 699 enable the prepaid server to authorize and rate a particular 700 request. 702 3.4 Support for Roaming 704 For some networks it is essential that PrePaid Data Services be 705 offered to roaming subscribers. Support for static and dynamic 706 roaming models are needed. Static roaming is where the subscriber 707 logs onto a foreign network. The foreign network has a roaming 708 agreement directly with the home network or through a broker network 709 or networks. The subscriber remains logged into the network until 710 the subscriber changes location. When changing location a new 711 connection and a new login procedure is required. 713 Dynamic roaming allows to subscriber to move between foreign 714 networks while maintaining a connection with the home network 715 seamlessly. As the subscriber moves between networks, the data 716 session is handed off between the networks. 718 In both roaming scenarios, the subscriber always authenticates with 719 the home network. PrePaid authorization and quota replenishing for 720 the session need to be received at the home network and more 721 specifically at the PrePaid System where state is being maintained. 723 Dynamic roaming is particularly challenging. A subscriber that 724 established a PrePaid Data Session may roam to another Access Device 725 that doesn’t not support PrePaid functionality. The system should 726 be capable to continue the PrePaid session. 728 3.5 PrePaid termination 730 When fraud is detected by the PrePaid System, or when an error is 731 detected, it may be beneficial for the PrePaid system to terminate a 732 specific session for the subscriber or all the sessions of a 733 subscriber. 735 Some errors can occur such that the PrePaid System is in a state 736 where it is not sure whether the session is in progress or not. 737 Under conditions such as this, the PrePaid system may wish to 738 terminate the PrePaid data session to make sure that resources are 739 not being utilized for which it can’t charge for reliably. 741 Some handoff procedure used during dynamic roaming may require that 742 the PrePaid system explicitly terminate the subscribers PrePaid data 743 session at an Access Device. For example, if time based PrePaid 744 service is being used and the mobile subscriber performs a dormant 745 handoff, the PrePaid System needs to explicitly terminate the 746 PrePaid session at the old Access Device. 748 4. Operations 750 4.1 General Requirements 752 4.1.1 Broker AAA Requirements 754 Broker AAA servers MUST support the Message-Authenticator(80) 755 attribute as defined in [RFC2869]. If BAAA servers are used, the 756 BAAA servers function is to forward the RADIUS packets as usual to 757 the appropriate RADIUS servers. 759 Accounting messages are not needed to deliver a PrePaid service. 760 However, accounting messages can be used to keep the PrePaid Server 761 current as to what is happening with the PrePaid data session. 762 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 763 pass through mode described in [RFC2866]. 765 4.2 Authentication and Authorization for Prepaid Enabled Access Devices 767 The Access Device initiates the authentication and authorization 768 procedure by sending a RADIUS Access-Request as usual. 770 If the Access Device has PrePaid Client capabilities, it MUST 771 include the PPCC attribute in the RADIUS Access-Request. The PPCC 772 attribute indicates to the PrePaid server the PrePaid capabilities 773 possessed by the Access Device. These are required in order to 774 complete the PrePaid authorization procedures. 776 If the Access Device supports multiple sessions-keys capabilities, 777 then it SHOULD include the MultiSession-Capabilities attribute. The 778 presence of the MultiSession-Capabilities attribute will indicate to 779 the PPS that the Access Device support prepaid service 780 differentiation above simple prepaid access. 782 If the Access Device supports the Disconnect-Message or the Change- 783 of-Auhtorization capabilities, then it SHOULD include the Dynamic- 784 Capabilities attribute. 786 In certain deployments, there may be other ways in which to 787 terminate a data session, or change authorization of an active 788 session. For example, some Access Devices provide a session 789 termination service via Telnet or SNMP. In these cases, the AAA 790 server MAY add the Dynamic-Capabilities message to the Access- 791 Request. 793 If the authentication procedure involves multiple Access-Requests 794 (as in EAP), the Access Device MUST include the PPCC attribute and 795 the Dynamic-Capabilities attribute (if used) in at least the last 796 Access-Request of the authentication procedure. 798 The Access-Request will be sent as usual to the HAAA. The packet 799 may be proxied through zero or more BAAA. 801 Once the Access-Request arrives at the HAAA, the HAAA will 802 authenticate the subscriber. If the subscriber is cannot be 803 authenticated, the HAAA will send an Access-Reject message back to 804 the client. If the subscriber is authenticated, the HAAA will 805 determine whether or not the subscriber is a PrePaid subscriber. 806 The techniques used to determine whether or not a subscriber is a 807 PrePaid subscriber is beyond the scope of this document. If the 808 subscriber is not a PrePaid subscriber, then the HAAA will respond 809 as usual with an Access-Accept or Access-Reject message. If the 810 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 811 Access-Request to a PrePaid server for further authorization. 813 The Access-Request will contain the PPCC attribute, the Dynamic- 814 Capabilities attribute if one was included; and the MultiSession- 815 Capabilities attribute if one was included, the User-Name(1) 816 attribute MAY be set to a value that would represent the 817 Subscriber’s PrePaid Identity. This attribute is used by the 818 PrePaid server to locate the PrePaid Subscriber’s account. For 819 added security, the HAAA MAY also set the User-Password(2) attribute 820 to the password used between the HAAA and the PrePaid server. 822 The PrePaid server lookups the subscriber’s PrePaid account and will 823 authorize the subscriber taking into consideration the Access Device 824 PrePaid Client Capabilities. The Prepaid Server will decide whether 825 single service prepaid access will be provided or a multiple session 826 pre-paid access will be provided. 828 4.2.1 Single Service Pre-paid 830 If a single service prepaid access is provided, upon successful 831 authorization, the PrePaid server will generate an Access-Accept 832 containing the PPAQ attribute, which contains the following sub- 833 attributes: 835 - The QUOTA-Id which is set by the PrePaid server to a unique value 836 that is used to correlate subsequent quota requests; 838 - Volume and/or Time Quotas, one of which is set to a value 839 representing a portion of the subscribers account; 841 - MAY contain a Time or Volume Threshold that controls when the 842 Access Device requests additional quota; 844 - The IP address of the Serving PrePaid Server and one or more 845 alternative PrePaid Servers. This is used by the HAAA to route 846 subsequent quota replenishing messages to the appropriate PrePaid 847 server(s). 849 - Optionally, a tariff switch time; 851 - Optionally, a Volume and Time Quota which can be used following a 852 tariff Switch; 854 Note: Idle-Timeout(28) can be used to trigger the premature 855 termination of a pre-paid service following subscriber inactivity. 857 Depending on site policies, upon unsuccessful authorization, the 858 PrePaid server will generate an Access-Reject or an Access-Accept 859 and set the Filter-Id(11) or the Ascend-Data-Filter (if supported) 860 attribute and the Session-Timeout(27) attribute such that the 861 PrePaid subscriber could get access to a restricted set of locations 862 for a short duration to allow them to replenish their account, or 863 create an account; or to browse free content. 865 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 866 will append the usual service attributes and forward the packet to 867 the Access Device. The HAAA SHALL NOT append or overwrite any 868 attributes already set by the PrePaid server. If the HAAA, receives 869 an Access-Reject message, it will simply forward the packet to its 870 client. Depending on site policies, if the HAAA fails to receive an 871 Access-Accept or Access-Reject message from the PrePaid server it 872 MAY do nothing or send an Access-Reject or an Access-Accept message 873 back to its client. 875 4.2.2 Multiple-Session Pre-paid 877 If the prepaid server decides that multiple-session prepaid service 878 is to be provided, upon successful authorization, the Prepaid server 879 will generate an Access Accept containing the initial PPQ-Response 880 attribute which contains the following sub-attributes: 882 - a list of the service keys which the Access Device can subsequently 883 use in pre-paid service authorization request. 885 The Prepaid Referral the first one is set to the IP address of the 886 Serving Prepaid Server, the second one is set to an alternate 887 Prepaid Server. This way the HAAA will be able to route subsequent 888 packets to the serving Prepaid Server or its alternate. 890 Additionally, the Prepaid server MAY set the Terminate-Action(29) to 891 RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control 892 how often interim Accounting Requests are generated. 894 Upon receiving the Access Accept from the Prepaid Server, the HAAA 895 will append the usual service attributes and forward the packet. 896 The HAAA SHALL NOT append any attributes already set by the Prepaid 897 server. If the HAAA, receives an Access Reject message, it will 898 simply forward the packet to its client. Depending on site 899 policies, if the HAAA fails to receive an Access Response message 900 from the Prepaid server it MAY do nothing or send an Access Reject 901 or an Access Accept message back to its client. 903 Upon receiving the Access Accept with a list of service keys, the 904 Access Device can trigger the authorization request for a particular 905 service corresponding to a service key. The technique for triggering 906 an authorization request for a particular service is out of scope of 907 this draft. 909 The Access Device initiates authorization for a particular service 910 by sending a RADIUS Access Request including a single service-key 911 reference. 913 For the specific service-key reference, the prepaid server will 914 check whether funds are available and will, following successful 915 allocation of funds, the Prepaid server will generate an Access 916 Accept containing the PPQ-Response attribute which contains the 917 following sub-attributes: 919 - The QUOTA-Id which is set by the Prepaid server to a unique value 920 that is used to correlate subsequent quota updates; 922 - The ServiceKey-Id which is set by the Prepaid server to the 923 service key requested by the Access Device; 925 - Volume and Time Quotas, one of which is set to a value 926 representing a portion of the subscribers account; 928 - The Time of Volume Threshold that the Prepaid server MAY set to 929 control when the Access Device requests additional quota. 931 - Optionally, a tariff switch time. 933 - Optionally, a Volume and Time Quota which can be used following a 934 tariff Switch 936 Note: Idle-Timeout(28) can be used to trigger the premature 937 termination of a pre-paid service following subscriber inactivity. 939 4.3 Session Start Operation 941 The real start of the session is indicated by the arrival of 942 Accounting-Request(Start) packet. The Accounting-Request (Start) 943 MAY be routed to the PrePaid Server so that it can confirm the 944 initial quota allocation. 946 Note that the PrePaid Server role is not to record accounting 947 messages and therefore it SHOULD not respond with an Accounting 948 Response packet. 950 If the Prepaid server does not receive the Accounting-Request(start) 951 message it will only know that the session has started upon the 952 first reception of a quota replenishment operation. 954 If the Prepaid server does not receive indication directly (via 955 Accounting-Request(start)) or indirectly, it SHOULD after some 956 configurable time, deduce that the Session has not started. If the 957 Access Device supports termination capabilities, the PPS SHOULD send 958 a Disconnect Message to the Access Device to ensure that the session 959 is indeed dead. 961 4.4 Mid-Session Operation 963 During the lifetime of a PrePaid data session the Access Device will 964 request to replenish the quotas using Authorize-Only Access-Request 965 messages. 967 Once the allocated quota has been reached or the threshold has been 968 reached, the Access Device MUST send an Access-Request with Service- 969 Type(6) set to a value of “Authorize Only” and the PPAQ attribute. 971 The Access Device MUST also include NAS identifiers, and Session 972 identifier attributes in the Authorize Only Access-Request. The 973 Session Identifier should be the same as those used during the 974 Access-Request. For example, if the User-Name(1) attribute was used 975 in the Access-Request it MUST be included in the Authorize Only 976 Access-Request especially if the User-Name(1) attribute is used to 977 route the Access-Request to the Home AAA server. 979 The Authorize Only Access-Request MUST not include either User 980 Password or Chap Password. In order to authenticate the message, 981 the Access Device MUST include the Message-Authenticator(80) 982 attribute. The Access Device will compute the value for the 983 Message-Authenticator based on [RFC2869]. 985 When the HAAA receives the Authorize-Only Access-Request that 986 contains a PPAQ, it SHALL validate the message using the Message- 987 Authenticator(80) as per [RFC2869]. If the HAAA receives an 988 Authorize Only Access-Request that contains a PPAQ but not a 989 Message-Authenticator(80) it SHALL silently discard the message. An 990 Authorize Only Access-Request message that does not contain a PPAQ 991 is either in error or belongs to another application (for example, a 992 Change of Authorization message [RFC3576]). In this case the 993 Authorize Only Access-Request will either be silently discarded or 994 handled by another application (not in scope of this document). 996 Once the Authorize Only Access-Request message is validated, the 997 HAAA SHALL forward the Authorize Only Access-Request to the 998 appropriate PrePaid Server. The HAAA MUST forward the Authorize 999 Only Access-Request to the PrePaid server specified in the PPAQ. 1000 The HAAA MUST sign the message using the Message-Authenticator(80) 1001 and the procedures in [RFC2869]. As with the Access-Request 1002 message, the HAAA MAY modify the User-Name(1) attribute to a value 1003 that represents the user’s internal PrePaid account in the PrePaid 1004 server. Note the PrePaid server could use the Quota-ID sub- 1005 attribute contained within the PPAQ to locate the user account. 1007 Upon receiving the Authorize Only Access-Request containing a PPAQ 1008 attribute, the PrePaid server MUST validate the Message- 1009 Authenticator(80) as prescribed in [RFC2869]. If the message is 1010 invalid, the PrePaid server MUST silently discard the message. If 1011 it received an Authorize Only Access-Request message that does not 1012 contain a PPAQ it MUST silently discard the message. 1014 The PrePaid server will lookup the PrePaid session by using the 1015 PrePaid Quota Id contained within the PPAQ. The PrePaid Server 1016 would, take the last allocated quota and subtract that from the 1017 User’s balance. If there is remaining balance, the PrePaid server 1018 re-authorizes the PrePaid session by allocate an additional quota. 1019 The PrePaid server may want to calculate a different threshold 1020 values as well. 1022 Upon successful re-authorization, the PrePaid server will generate 1023 an Access-Accept containing the PPAQ attribute. The Access-Accept 1024 message MAY contain Service-Type(6) set to Authorize-Only and MAY 1025 contain the Message-Authenticator(80). 1027 Depending on site policies, upon unsuccessful authorization, the 1028 PrePaid server will generate an Access-Reject or an Access-Accept 1029 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 1030 and the Session-Timeout(27) attribute such that the PrePaid 1031 subscriber could get access to a restricted set of locations for a 1032 short duration to allow them to replenish their account, or create 1033 an account; or to browse free content. 1035 Upon receiving the Access-Accept from the PrePaid server, the HAAA 1036 SHALL return the packet to its client. If the HAAA, receives an 1037 Access-Reject message, it will forward the packet. Depending on 1038 site policies, if the HAAA fails to receive an Access-Accept or an 1039 Access-Reject message from the PrePaid server it MAY do nothing or 1040 it MAY send an Access-Reject message back to its client. 1042 Upon receiving an Access-Accept, the Access Device SHALL update its 1043 quotas and threshold parameters with the values contained in the 1044 PPAQ attribute. Note that the PrePaid server MAY update the 1045 PrePaidServer attribute(s) and these may have to be saved as well. 1047 Upon receiving an Access-Accept message containing either Filter- 1048 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 1049 The Access Device SHALL restrict the subscriber session accordingly. 1051 4.5 Dynamic Operations 1053 The PrePaid server may want to take advantage of the dynamic 1054 capabilities that are supported by the Access Device as advertised 1055 in the Dynamic-Capabilities attribute during the initial Access- 1056 Request. 1058 There are two types of actions that the PrePaid server can perform: 1059 it can request that the session be terminated; or it can request 1060 that the filters associated with the session be modified. 1062 Both of these actions require that the session be uniquely 1063 identified at the Access Device. As a minimum the PrePaid server: 1065 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 1066 -MUST provide at least one session identifier such as User-Name(1), 1067 Framed-IP-Address(), the Accounting-Session-Id(44). 1069 Other attributes could be used to uniquely identify a PrePaid data 1070 session. 1072 4.5.1 Unsolicited Session Termination Operation 1073 This capability is described in detail in [RFC3576]. The PrePaid 1074 server sends a Disconnect Request packet that MUST contain 1075 identifiers that uniquely identify the subscriber’s data session and 1076 the Access Device servicing that session. 1078 Upon receiving the Disconnect Request packet the HAAA will either 1079 act on it or will proxy it to another AAA server until it is 1080 received by the a AAA that is in the same network as the serving 1081 Access Device. 1083 Each AAA MUST route the Disconnect Request packet. How the routing 1084 decision is made is an implementation detail. 1086 Once the Disconnect Request packet reaches AAA that is in the same 1087 network as the serving Access Device, if the Access Device supports 1088 Disconnect-Request (as per [RFC3576]), it sends the message directly 1089 to the Access Device; otherwise it uses other mechanisms such as 1090 SNMP or Telnet to command the Access Device to terminate the 1091 session. 1093 If the Access Device receives a Disconnect-Request packet, it will 1094 respond with either a Disconnect-ACK packet if it was able to 1095 terminate the session or else it will respond with a Disconnect-NAK 1096 packet. 1098 If the AAA server is performing the disconnect operation, it MUST 1099 respond with a Disconnect-ACK message if it successfully terminated 1100 the session or a Disconnect-NAK message if it failed to terminate 1101 the session. 1103 If any AAA server is unable to route the Disconnect-Request it MUST 1104 respond with a Disconnect-NAK packet. 1106 4.5.2 Unsolicited Change of Authorization Operation 1108 The PrePaid Server MAY send a Change-of-Authorization message as 1109 described in [RFC3576] to restrict internet access when the 1110 subscriber has no more balance. 1112 The PrePaid server sends a Change-of-Authorization packet it MUST 1113 contain identifiers that will uniquely identify the subscriber 1114 session and the Access Device serving that session. 1116 Upon receiving the Change-of-Authorization packet the HAAA will 1117 either act on it or proxy it to another AAA server until it is 1118 received by a AAA server that is in the same network as the serving 1119 Access Device. 1121 Each AAA must route the packet to the serving network. How the 1122 routing decision is made is an implementation detail. 1124 Once the Change-of-Authorization packet reaches a AAA that is in the 1125 same network as the serving Access Device, if the Access Device 1126 supports Change-of-Authorization message, it will forward the 1127 message to the Access Device; otherwise, it will use other 1128 mechanisms such as SNMP or Telnet to command the Access Device to 1129 change its filters. 1131 If the Access Device receives a Change-of-Authorization packet, it 1132 will respond with either a Change-of-Authorization-ACK packet if it 1133 was able to change the filter or else it will respond with a Change- 1134 of-Authorization-NAK packet. 1136 If the AAA server is performing the change of filter operation, it 1137 MUST respond with a Change-of-Authorization-ACK message if it 1138 successfully or a Change-of-Authorization-NAK packet if it failed to 1139 change the filter. 1141 If a AAA server was unable to route the Change-of-Authorization it 1142 MUST respond with a Change-of-Authorization-NAK packet. 1144 4.6 Termination Operation 1146 The termination phase is initiated when either: the Subscriber logs 1147 off; the quotas have been consumed, or when the Access Device 1148 receives a Disconnect Message. In all of these instances, if the 1149 session is a PrePaid data session, the Access Device will send an 1150 Authorize-Only Access-Request message with a PPAQ Update-Reason 1151 attribute set to either “Client Service termination” or “Remote 1152 Forced disconnect” and the currently used quota. 1154 The BAAA MUST forward this packet to the next BAAA or the HAAA. 1156 The HAAA MUST validate the Authorize Only Access-Request using the 1157 Message-Authenticator(80) as per [RFC2869] and if valid, use the 1158 PrePaidServer subtype in the PPAQ to forward the Authorize Only 1159 Access-Request packet to the serving PrePaid Server or if needed, 1160 its alternate. 1162 The PrePaid Server MUST validate the Authorize Only Access Request 1163 and use the information contained in the PPAQ attribute to adjust 1164 the subscriber’s balance and to close the session. The PrePaid 1165 Server SHALL respond back with an Access-Accept message. 1167 4.7 Mobile IP Operations 1169 In roaming scenarios using mobile-ip, as the mobile subscriber roams 1170 between networks, or between different types of networks such as 1171 between WLAN and CDMA2000 networks, the PrePaid data session is 1172 maintained transparently. 1174 As the subscriber device associates with the new Access Device, the 1175 Access Device sends a RADIUS Access-Request and the subscriber is 1176 re-authenticated and reauthorized. If the Access Device has PrePaid 1177 Client capabilities, it MUST include the PPCC attribute in the 1178 RADIUS Access-Request. In this manner the procedure follows the 1179 Authentication and Authorization procedure described earlier. 1181 The Access-Request message is routed to the home network and MUST 1182 reach the PrePaid System that is serving the PrePaid session. The 1183 PrePaid system will then correlate the new authorization request 1184 with the existing active session and will assign a quota to the new 1185 request. Any outstanding quota at the old Access Device will be 1186 returned to the PrePaid system due to the usual mobile-ip handoff 1187 procedures. Specifically, the quota will be returned when the 1188 Access Device sends the Authorize Only Access-Request with PPAQ 1189 Update-Reason subtype set to either “Remote Forced disconnect” or 1190 “Client Service termination”. In order to trigger the sending of 1191 this last Authorize Only Access-Request, the PrePaid system may 1192 issue a Disconnect Message [CHIBA] to the Access Device. 1194 If the subscriber has roamed to an Access Device that does not have 1195 any PrePaid Capabilities, PrePaid data service may still be possible 1196 by requesting the Home Agent (providing it has PrePaid Capabilities) 1197 to assume responsibilities for metering the service. The procedure 1198 for this scenario will be given in the next release of this draft. 1200 4.8 Accounting Considerations 1201 Accounting messages are not required to deliver PrePaid Data 1202 Service. Accounting message will typically be generated for PrePaid 1203 Data Service. This because accounting message are used for auditing 1204 purposes as well as for bill generation. 1206 Accounting messages associated with PrePaid Data Sessions should 1207 include the PPAQ attribute. 1209 4.9 Service Device Operation 1211 To be completed 1213 4.10 Interoperability with Diameter Credit Control Application 1215 RADIUS PrePaid solutions need to interoperate with Diameter 1216 protocol. Two possibilities exist: The AAA infrastructure is 1217 Diameter based and the Access Device are RADIUS based; or the Access 1218 Device is Diameter based and the AAA infrastructure is RADIUS based. 1220 The Diameter Credit Control Application [DIAMETERCC] describes how 1221 to implement a PrePaid using an all Diameter based infrastructure. 1223 1225 5. Attributes 1227 As currently written, this draft is using the RADIUS [RFC2865] 1228 namespace. 1230 Note: as currently written, this draft proposes to use container 1231 types, or attributes that contain sub-attributes, that will have 1232 attributes from the PrePaid space and also attributes belonging to 1233 RADIUS space. The technique for encoding such a structure will be 1234 identified in future release of this document. 1235 There has been some discussion on the use of subtypes. The authors 1236 are open to the concept of “flattening” the attributes. However, 1237 this will further move this specification away from the 3GPP2 1238 implementation from which this document is based. Note: that the 1239 only entities that would decode the attributes would be those that 1240 implement the prepaid capabilities. As well, the attributes that 1241 have been subtyped are related to each other semantically and the 1242 use of a single attribute would not make sense. 1244 Note: The attributes presented in this version of the draft, 1245 represent the bare minimum attributes required to implement a 1246 PrePaid solution. The use of the “Authorize Only” Pattern allows 1247 the ability to extend PrePaid by adding additional PrePaid VSA in 1248 the future. 1250 5.1 PPCC attribute 1252 The PPCC at tribute is sent in the Access-Request message and is 1253 used to describe the Access Devices PrePaid capabilities. The 1254 attribute is encrypted using the procedures defined in [RFC2868 ] 1255 section 3.5. 1257 0 1 2 3 1258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | VALUE (Event-Timestamp) | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | SUB-TYPE 2 | LENGTH | VALUE (PP-capabilities) | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 TYPE: value of PPCC 1270 LENGTH: 14 1272 SUB-TYPE 1: 55 1273 LENGTH: 6 1274 DESCRIPTION: 1275 The Event-Timestamp as defined by [RFC2869] 1277 SUB-TYPE 2: value of PP-capabilities 1278 LENGTH: 4 1279 DESCRIPTION: 1280 BIT-MAP with the following values: 1281 1 Time metering 1282 2 Volume metering 1283 >2 Reserved 1285 5.2 Dynamic-Capabilities attribute 1287 The Dynamic Capabilities attribute is sent in the Access-Request and 1288 describes the capabilities of the Access Device. Mainly it 1289 describes the method for support for unsolicited session termination 1290 and the method for support of unsolicited change of filters. 1292 Subtype: Session-Termination-Methods 1 1293 -None 1294 -Disconnect-Message [CHIBA] 1295 -Telnet 1296 -SNMP 1298 Subtype: Dynamic-Authorization-Capabilities 1 1299 -None 1300 -CoA [CHIBA] 1301 -Telenet 1302 -SNMP 1304 5.3 PPAQ Attribute 1306 The PPAQ attribute is sent in Authorize Only Access-Request and 1307 Access-Accept messages. In Authorize Only Access-Request messages 1308 it is used to report usage and request further quota; in an Access- 1309 Accept message it is used to allocate the quota (initial quota and 1310 subsequent quotas). 1312 The attribute consists of a number of subtypes. Subtypes not used 1313 are omitted in the message. 1315 Type: 26 1316 Length: variable, greater than 8 1317 Vendor-ID: 5535 1318 Vendor-Type: 90 1319 Vendor-Length: variable, greater than 2 1321 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 1322 Length: length of QuotaIDentifier attribute (= 6 octets) 1323 QuotaIDentifier (QID): 1325 The QuotaIDentifier Sub-Type is generated by the PrePaid server 1326 at allocation of a Volume and/or Duration Quota. The on-line 1327 quota update RADIUS Access-Request message sent from the Access 1328 Device to the PPS shall include a previously received 1329 QuotaIDentifier. 1331 Sub-Type (=2): Sub-Type for VolumeQuota attribute 1332 Length: length of VolumeQuota attribute (= 6 octets) 1333 VolumeQuota (VQ): 1335 The optional VolumeQuota Sub-Type is only present if Volume Based 1336 charging is used. In RADIUS Access-Accept message (PPS to Access 1337 Device direction), it indicates the Volume (in octets) allocated 1338 for the session by the PrePaid server. In RADIUS Authorize Only 1339 Access-Request message (Access Device to PPS direction), it 1340 indicates the total used volume (in octets) for both forward and 1341 reverse traffic applicable to PrePaid accounting. 1343 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 1344 Length: length of VolumeQuotaOverflow attribute (= 4 octets) 1345 VolumeQuotaOverflow (VQO): 1347 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 1348 many times the VolumeQuota counter has wrapped around 2^32 over 1349 the course of the service being provided. 1351 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 1352 Length: length of VolumeThreshold attribute (= 6 octets) 1353 VolumeThreshold (VT): 1355 The VolumeThreshold Sub-Type shall always be present if 1356 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1357 Access Device direction). It is generated by the PrePaid server 1358 and indicates the volume (in octets) that shall be used before 1359 requesting quota update. This threshold should not be larger than 1360 the VolumeQuota. 1362 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1363 Length: length of VolumeThresholdOverflow attribute (= 4 octets) 1364 VolumeThresholdOverflow (VTO): 1366 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1367 how many times the VolumeThreshold counter has wrapped around 1368 2^32 over the course of the service being provided. 1370 Sub-Type (=6): Sub-Type for DurationQuota attribute 1371 Length: length of DurationQuota attribute (= 6 octets) 1372 DurationQuota (DQ): 1374 The optional DurationQuota Sub-Type is only present if Duration 1375 Based charging is used. In RADIUS Access-Accept message (PPS to 1376 Access Device direction), it indicates the Duration (in seconds) 1377 allocated for the session by the PrePaid server. In on-line 1378 RADIUS Access-Accept message (PPC to PPS direction), it indicates 1379 the total Duration (in seconds) since the start of the accounting 1380 session related to the QuotaID. 1382 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1383 Length: length of DurationThreshold attribute (= 6 octets) 1384 DurationThreshold (DT): 1386 The DurationThreshold Sub-Type shall always be present if 1387 DurationQuota is present in a RADIUS Access-Accept message (PPS 1388 to Access Device direction). It represents the duration (in 1389 seconds) that shall be used by the session before requesting 1390 quota update. This threshold should not be larger than the 1391 DurationQuota and shall always be sent with the DurationQuota. 1393 Sub-Type (=8): Sub-Type for Update-Reason attribute 1394 Length: length of Update-Reason attribute (= 4 octets) 1395 Update-Reason attribute (UR): 1397 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1398 Access-Request message (Access Device to PPS direction). It 1399 indicates the reason for initiating the on-line quota update 1400 operation. Update reasons 4, 5, 6, 7 and 8 indicate that the 1401 associated resources are released at the client side, and 1402 therefore the PPS shall not allocate a new quota in the RADIUS 1403 Access_Accept message. 1405 1. Pre-initialization 1406 2. Initial request 1407 3. Threshold reached 1408 4. Quota reached 1409 5. Remote Forced disconnect 1410 6. Client Service termination 1411 7. Main SI released 1412 8. Service Instance not established 1414 Sub-Type (=9): Sub-Type for PrePaidServer attribute 1415 Length: Length of PrePaidServer (IPv4 = 6 octets, IPv6= 18 octets 1416 PrePaidServer: 1418 The optional, multi-value PrePaidServer indicates the address of 1419 the serving PrePaid System. If present, the Home RADIUS server 1420 uses this address to route the message to the serving PrePaid 1421 Server. The attribute may be sent by the Home RADIUS server. If 1422 present in the incoming RADIUS Access-Accept message, the PDSN 1423 shall send this attribute back without modifying it in the 1424 subsequent RADIUS Access-Request message, except for the first 1425 one. If multiple values are present, the PDSN shall not change 1426 the order of the attributes. 1428 NOTES: 1430 Either Volume-Quota or Time-Quota MUST appear in the attribute. 1431 Volume Threshold may only appear if Volume Quota appears 1432 If the Access Device can measure time, and if Time-Threshold appears 1433 with Volume Quota, then the Access device should trigger a quota 1434 replenishment when the Current Time >= Time-Threshold. 1436 5.4 Tarrif Switch 1438 TBD 1440 5.5 Table of Attributes 1442 TO BE COMPLETED. 1444 Request Accept Reject Challenge # Attribute 1446 Authorize_Only Request Accept Reject 1448 6. Security Considerations 1450 The protocol exchanges described are susceptible to the same 1451 vulnerabilities as RADIUS and it is recommended that IPsec be 1452 employed to afford better security. 1454 If IPsec is not available the protocol in this draft improves the 1455 security of RADIUS. The various security enhancements are explained 1456 in the following sections. 1458 6.1 Authentication and Authorization 1460 RADIUS is susceptible to replay attacks during the Authentication 1461 and Authorization procedures. A successful replay of the initial 1462 Access-Request could result in an allocation of an initial quota. 1464 To thwart such an attack... 1466 6.2 Replenishing Procedure 1468 A successful replay attacks of the Authorize Only Access-Request 1469 could deplete the subscribers prepaid account. 1471 To be completed. 1473 7. IANA Considerations 1475 To be completed. 1477 This draft does create RADIUS attributes. However, the authors 1478 recognize that it may not be possible to obtain such attributes. 1479 Therefore, in subsequent drafts it will be proposed to use a Vendor 1480 space as an Application Space. 1482 8. Normative References 1484 [RFC2026] Bradner, S., "The Internet Standards Process -- 1485 Revision 3", RFC 2026, October 1996. 1486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1487 Requirement Levels", RFC 2119, March 1997. 1488 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1489 "Remote Authentication Dial In User Server 1490 (RADIUS)", RFC 2865, June 2000. 1492 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1493 2000. 1495 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1496 Extensions", RFC 2869, June 2000. 1498 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1499 Holdrege, M., Goyret, I., "RADIUS Attributes for 1500 Tunnel Protocol Support" , RFC 2868, June 2000. 1501 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1502 Aboba, B., "Dynamic Authorization Extensions to 1503 Remote Authentication Dial-In User Service 1504 (RADIUS)", RFC 3576, February 2003. 1506 [DIAMETERCC] Work in Progress. 1508 Acknowledgments 1510 The authors would like to thank Mark Grayson (Cisco) for his 1511 contribution to this draft. 1513 Author's Addresses 1515 Avi Lior Parviz Yegani, Ph.D. 1516 Bridgewater Systems Mobile Wireless Group 1517 303 Terry Fox Drive Cisco Systems 1518 Suite 100 3625 Cisco Way 1519 Ottawa Ontario San Jose, CA 95134 1520 Canada USA 1521 avi@bridgewatersystems.com pyegani@cisco.com 1523 Kuntal Chowdhury Lila Madour 1524 Nortel Networks Ericsson Canada 1525 2221, Lakeside Blvd, 5400 Decarie, TMR 1526 Richardson, TX-75082 Quebec, Canada 1527 chowdury@nortelnetworks.com Lila.madour@ericsson.ca 1529 Yong Li 1530 Bridgewater Systems 1531 303 Terry Fox Drive 1532 Suite 100 1533 Ottawa Ontario 1534 Canada 1535 Yong.li@bridgewatersystems.com 1537 Intellectual Property Statement 1539 The IETF takes no position regarding the validity or scope of any 1540 intellectual property or other rights that might be claimed to 1541 pertain to the implementation or use of the technology described in 1542 this document or the extent to which any license under such rights 1543 might or might not be available; neither does it represent that it 1544 has made any effort to identify any such rights. Information on the 1545 IETF's procedures with respect to rights in standards-track and 1546 standards-related documentation can be found in BCP-11. Copies of 1547 claims of rights made available for publication and any assurances 1548 of licenses to be made available, or the result of an attempt made 1549 to obtain a general license or permission for the use of such 1550 proprietary rights by implementers or users of this specification 1551 can be obtained from the IETF Secretariat. 1553 The IETF invites any interested party to bring to its attention any 1554 copyrights, patents or patent applications, or other proprietary 1555 rights which may cover technology that may be required to practice 1556 this standard. Please address the information to the IETF Executive 1557 Director. 1559 Full Copyright Statement 1561 Copyright (C) The Internet Society (2003). All Rights Reserved. 1562 This document and translations of it may be copied and furnished to 1563 others, and derivative works that comment on or otherwise explain it 1564 or assist in its implementation may be prepared, copied, published 1565 and distributed, in whole or in part, without restriction of any 1566 kind, provided that the above copyright notice and this paragraph 1567 are included on all such copies and derivative works. However, this 1568 document itself may not be modified in any way, such as by removing 1569 the copyright notice or references to the Internet Society or other 1570 Internet organizations, except as needed for the purpose of 1571 developing Internet standards in which case the procedures for 1572 copyrights defined in the Internet Standards process must be 1573 followed, or as required to translate it into languages other than 1574 English. The limited permissions granted above are perpetual and 1575 will not be revoked by the Internet Society or its successors or 1576 assigns. This document and the information contained herein is 1577 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1578 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1579 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1580 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1583 Expiration Date 1585 This memo is filed as draft-lior-radius-extensions-for-prepaid- 1586 02.txt, and will expire 27th March, 2004.