idnits 2.17.00 (12 Aug 2021) /tmp/idnits4335/draft-lior-radius-prepaid-extensions-03.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 35 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 44 pages 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 (February 16, 2003) is 7033 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CHIBA' is mentioned on line 1386, but not defined == Unused Reference: 'RFC2868' is defined on line 1760, but no explicit reference was found in the text == Unused Reference: 'REDIRECT' is defined on line 1769, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) Summary: 2 errors (**), 0 flaws (~~), 8 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-03.txt Cisco 6 Expires: 16 July, 2004 K. Chowdhury 7 Nortel 8 L. Madour 9 Ericsson Canada 10 Y. Li 11 Bridgewater Systems 12 February 16, 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 RADIUS Extensions for PrePaid February 2004 50 Table of Contents 52 1. Introduction...................................................4 53 1.1 Terminology................................................6 54 1.2 Requirements language......................................6 55 2. Architectural Model............................................6 56 2.1 Why not existing RADIUS attributes?.......................14 57 3. Use-cases.....................................................16 58 3.1 Simple pre-paid access use-case...........................17 59 3.2 Simple Service Device use-case............................20 60 3.3 Support for concurrent PrePaid sessions...................20 61 3.4 Support for Roaming.......................................21 62 3.5 PrePaid termination.......................................22 63 4. Operations....................................................22 64 4.1 General Requirements......................................22 65 4.1.1 Broker AAA Requirements..............................22 66 4.2 Authentication and Authorization for Prepaid Enabled Access 67 Devices.......................................................23 68 4.2.1 Single Service Pre-paid..............................24 69 4.2.2 Multiple-Session Pre-paid............................25 70 4.3 Session Start Operation...................................27 71 4.4 Mid-Session Operation.....................................28 72 4.5 Dynamic Operations........................................30 73 4.5.1 Unsolicited Session Termination Operation............30 74 4.5.2 Unsolicited Change of Authorization Operation........31 75 4.6 Termination Operation.....................................32 76 4.7 Mobile IP Operations......................................32 77 4.8 Accounting Considerations.................................33 78 4.9 Service Device Operation..................................33 79 4.10 Interoperability with Diameter Credit Control Application34 80 5. Attributes....................................................34 81 5.1 PPAC Attribute............................................34 82 5.2 Session Termination Capability............................36 83 5.3 PPAQ Attribute............................................36 84 5.4 Table of Attributes.......................................40 85 6. Security Considerations.......................................41 86 6.1 Authentication and Authorization..........................41 87 6.2 Replenishing Procedure....................................41 88 7. IANA Considerations...........................................41 89 8. Normative References..........................................41 90 Acknowledgments..................................................42 91 Author's Addresses...............................................42 92 Intellectual Property Statement..................................43 94 RADIUS Extensions for PrePaid February 2004 96 Full Copyright Statement.........................................43 97 Expiration Date..................................................44 99 RADIUS Extensions for PrePaid February 2004 101 1. Introduction 103 This draft describes RADIUS protocol extensions supporting PrePaid 104 Data Services. 106 PrePaid data services are cropping up in many wireless and wireline 107 based networks. A PrePaid Data Service subscriber is one that 108 purchases a contract to deliver a data service for either a period 109 of time, or a quantity of data. Before providing a prepaid data 110 service, the service provider checks that the prepaid subscriber has 111 sufficient funds to cover the particular service request. Only after 112 confirmation that funds are available is the service provided to the 113 user. 115 The subscriber purchases the Data Service using various means such 116 as buying a PrePaid Card, or online. How the subscriber purchases 117 their PrePaid Data Service depends on the deployment and is not in 118 scope for this document. 120 In some deployments, the PrePaid data service will be combined with 121 other Prepaid services such as PrePaid voice service. This is not 122 an issue for this document other than the fact that the PrePaid Data 123 Services described in this paper should work with other PrePaid data 124 and or voice services. 126 The fundamental business driver for a carrier to provide PrePaid 127 data services is to increase participation (subscriber base) and 128 thus to increase revenues. Therefore, it makes sense that PrePaid 129 services meet the following goals: 131 - Leverage existing infrastructure, hence reducing capital 132 expenditures typically required when rolling a new service; 133 - Ability to rate service requests in real-time; 134 - Ability to check that the end userÆs account for coverage for the 135 requested service charge prior to execution of that service; 136 - Protect against revenue loss, i.e., prevent an end user from 137 generating chargeable events when the credit of that account is 138 exhausted or expired; 139 - Protect against fraud; 140 - Be as widely deployable over Dialup, Wireless and WLAN networks. 142 RADIUS Extensions for PrePaid February 2004 144 The protocol described in this document maximizes existing 145 infrastructure as much as possible ¡ hence the use of the RADIUS 146 protocol. The protocol is used in ways to protect against revenue 147 loss or revenue leakage. This is achieved by defining procedures 148 for the real-time delivery of service information to a pre-paid 149 enabled AAA server, to minimize the financial risk, for the pre-paid 150 enabled AAA server to be able to allocate small quotas to each data 151 session and having the ability to update the quotas from a central 152 quota server dynamically during the lifetime of the PrePaid data 153 session. As well, mechanisms have been designed to be able to 154 recover from errors that occur from time to time. 156 Protection against fraud is provided by recording of accounting 157 records, by providing mechanisms to thwart replay attacks. As well, 158 mechanisms have been provided to terminate data sessions when fraud 159 is detected. 161 PrePaid System will become more prevalent and sophisticated as the 162 various networks such as Dialup, Wireless and WLAN converge. This 163 protocol extension is designed to meet the challenges of converged 164 networks. The draft mainly addresses how to use the RADIUS protocol 165 to achieve a PrePaid Data Service. The prepaid architecture assumes 166 that rating of chargeable events does not occur in the element 167 providing the service. This rating could be performed in the prepaid 168 enabled AAA server or may exist in an entity behind this AAA server. 169 Business logic and service rules may define that tariffing of events 170 vary in time, e.g., the particular price per megabyte download may 171 be defined to switch at 8pm from a high tariff to a low tariff. The 172 RADIUS extensions for prepaid support scenarios enable scalable 173 implementation of tariff switched prepaid systems. 175 Furthermore, the prepaid architecture assumes that a quota server is 176 available which, through co-ordination with the rating entity and 177 centralized balance manager is able to provide a quota response in 178 response for prepaid data service. This quota server functionality 179 could be performed in the prepaid enabled AAA server or may exist in 180 an entity behind this AAA server. Finally, the details of the 181 PrePaid System, such as its persistent store, how it maintains its 182 accounts are not covered at all. However, in order to define the 183 RADIUS protocol extensions it is necessary to discuss the functional 184 behavior of the PrePaid System. 186 RADIUS Extensions for PrePaid February 2004 188 1.1 Terminology 190 Access Device 191 PrePaid Client 192 PrePaid Server 193 Home agent (HA) 194 Home network 195 Home AAA (HAAA) 196 Broker AAA (BAAA) 197 Visited AAA (VAAA) 198 Foreign Agent (FA) 199 WLAN 200 Service Device 202 1.2 Requirements language 204 In this document, several words are used to signify the requirements 205 of the specification. These words are often capitalized. The key 206 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 208 this document are to be interpreted as described in [RFC2119]. 210 2. Architectural Model 212 The architectural model supports prepaid clients on either an access 213 device or a service device. An access device (e.g. a NAS) typically 214 provides a single service to end-users, corresponding to network 215 access. The service device enables finer grain services to be 216 defined. For example, a service may be defined for access to a 217 particular destination network, which enables further segmentation 218 of services within the network. An access device and service device 219 may be combined into a single physical entity. 221 When pre-paid service is used the access or service device collects 222 service event information and reports it while and/or after services 223 are provided to the prepaid user. This event information is sent to 224 a prepaid server by using the prepaid RADIUS extensions. 226 If real-time credit control is required, the access or service 227 device (prepaid client) contacts the prepaid server with service 228 event information included before the service is provided. The 229 prepaid server, depending on the service event information, performs 230 credit check and allocates a portion of available credit to the 232 RADIUS Extensions for PrePaid February 2004 234 service event. The rating entity converts this credit value into a 235 time and/or volume amount, which is then returned to the requesting 236 device. The rating entity may determine that during the allocated 237 quota, a tariff switch will occur in which case the rating entity 238 will include details of the quota allocated prior to the tariff 239 switch, details of the quota allocated after the tariff switch 240 together with details of when the tariff switch will occur. 242 The requesting device (either access or service device) then 243 monitors service execution according to the instructions returned by 244 the prepaid server. After service completion or on a subsequent 245 request for service, the prepaid server deducts the reserved 246 allocation of credit from the prepaid userÆs account. 248 Similarly, when a user terminates an on-going prepaid service, the 249 prepaid client signals the prepaid server with the a value 250 corresponding to the unused portion of the allocated quota. The 251 prepaid server is then able to refund unused allocated funds into a 252 userÆs prepaid account. 254 There MAY be multiple prepaid servers in the system for reasons of 255 redundancy and load balancing. The system MAY also contain separate 256 rating server(s) and accounts MAY locate in a centralized database. 257 System internal interfaces can exist to relay messages between 258 servers and an account manager. However the detailed architecture 259 of prepaid system and its interfaces are implementation specific and 260 are out of scope of this specification. 262 accounting 263 +------------+ +-----------+ protocol +--------------+ 264 | Access |<----->| Service |<------------>| Accounting | 265 | Device | +-->| Device |<-----+ | Server | 266 +------------+ | +-----------+ | +--------------+ 267 | | 268 +------------+ | | 269 | Access |<--+ | +--------------+ 270 | Device | +------>| PrePaid | 271 +------------+ prepaid | Server | 272 protocol +--------------+ 274 Figure 1 Basic Prepaid Architecture 276 RADIUS Extensions for PrePaid February 2004 278 The prepaid server and accounting server in this architecture model 279 are logical entities. The real configuration MAY combine them into a 280 single host. 282 There MAY exist protocol transparent RADIUS Proxies between prepaid 283 client and prepaid server. These proxies transparently support the 284 prepaid RADIUS extensions. 286 In order to generalize the solution, in this paper we generalize the 287 Access Devices, which in reality may be a NAS from in Dialup 288 deployments, PDSN in CDMA2000 deployments,an 802.11 WLAN Access 289 Points or GGSN in GSM deployments. To actively participate in 290 Prepaid procedures outlined here, the Access Device MUST have 291 Prepaid Client capabilities. Prepaid Client Capabilities include 292 the ability to meter the usage for a prepaid data session; this 293 usage includes time or volume usage. 295 In circumstances when the Access Device does not support the Prepaid 296 client capabilities, prepaid client functionality may be provided 297 using either a stand alone service device or, in the case of roaming 298 scenarios using mobile IP, the prepaid client functionality may be 299 delegated to the Home Agent. It may also be possible to deliver 300 limited prepaid services using RADIUS capabilities specified in 301 RFC2865 and RFC2866. 303 Furthermore, the device including the prepaid client functionality 304 may also have Dynamic Session Capabilities that include the ability 305 to terminate a data session and/or change the filters associated 306 with a specific data session by processing Disconnect Messages and 307 Change of Filter messages as per [RFC3576]. 309 In this document RADIUS is used as the AAA server. There are three 310 kinds or categories of AAA servers. The AAA server in the home 311 network, the HAAA, is responsible for authentication of the 312 subscriber and also authorization of the service. In addition, the 313 HAAA communicates with the Prepaid servers using the RADIUS protocol 314 to authorize prepaid subscribers. In AAA based roaming deployments 315 the AAA server in the visited network, the VAAA, is responsible for 316 forwarding the RADIUS messages to the HAAA. The VAAA may also 317 modify the messages. In roaming deployments, the visited network 318 may be separated from the home network by one or more broker 319 networks. The AAA servers in the broker networks, BAAA are 321 RADIUS Extensions for PrePaid February 2004 323 responsible to route the RADIUS packets and hence donÆt play an 324 active roll in the Prepaid Data Service delivery. 326 In this document the Prepaid Server is described in functional terms 327 related to their interface with the HAAA. The Prepaid Server 328 interfaces to entities which: 330 i) Keep the accounting state of the prepaid subscribers (balance 331 manager); 332 ii) Allow service requests to be rated in real-time (Rating Engine); 333 and 334 iii) Allow quota to be managed for a particular pre-paid service 335 (Quota Server). 337 The various deployments for Prepaid are presented in the remainder 338 of this section. The first deployment is the basic Prepaid data 339 service and is depicted in figure 2. Here the Access Device which 340 supports the prepaid client functionality, the HAAA and the Prepaid 341 Server are collocated in the same provider network. 343 The Subscriber Device establishes a connection with one of several 344 Access Devices in the network. The Access Device communicates with 345 one or more HAAA servers in the network. To provide redundancy more 346 then one HAAA is available to use by an Access Device. 348 The network will have one or more Prepaid Servers. Multiple Prepaid 349 Servers will be used to provide redundancy and load sharing. The 350 interface between the HAAA and the PPS is the RADIUS protocol in 351 this specification. However, in cases where the PPS does not 352 implement the RADIUS protocol, the implementation would have to map 353 the requirements defined in this document to whatever protocol is 354 used between the HAAA and the PPS. 356 RADIUS Extensions for PrePaid February 2004 358 +------+ +-----+ 359 | | | | 360 +--------+ +--------+ +--| HAAA |--+--| PPS | 361 | | | | | | | | | | 362 | Sub | | Access | | +------+ | +-----+ 363 | |---| |--+ | 364 | Device | | Device | | +------+ | +-----+ 365 | | | | | | | | | | 366 +--------+ +--------+ +--| HAAA |--+--| PPS | 367 | | | | 368 +------+ +-----+ 370 Figure 2 Basic Prepaid Access Architecture 372 In the second deployment scenario, the Access Device does not 373 support the prepaid client functionality. Instead an independent 374 Service Device provides prepaid client functionality as depicted in 375 figure 3. Here the Access Device which dose not supports the 376 prepaid client functionality is configured as AAA client to the AAA 377 proxy functionality in the Service Device. The Service device, which 378 supports the prepaid client functionality then appends prepaid 379 extensions in the AAA requests proxied to the HAAA. 381 The Subscriber Device establishes a connection with one of several 382 Access Devices in the network. The Authentication and Authorization 383 requests from the Access Device are proxied through the Service 384 Device which then appends prepaid extensions on to the requests. The 385 Service Device communicates with one or more HAAA servers in the 386 network. The Service Device is responsible for removing prepaid 387 extensions from messages received from the HAAA before proxying them 388 on to the Access Device. To provide redundancy more then one 389 Service Devices are available to use by an Access Device and more 390 than one HAAA is available for use by the Service Device. The 391 Service Device is configured to be default gateway to the Access 392 Device, enabling all traffic to be correctly metered. 394 RADIUS Extensions for PrePaid February 2004 396 (AAA) +---------+ +------+ +-----+ 397 +------------| Service | | | | | 398 +--------+ | | |--+--| HAAA |--+--| PPS | 399 | | +--------+ +--| Device | | | | | | | 400 | Sub | | Access | (IP)| +---------+ | +------+ | +-----+ 401 | |---| |-----+ | | 402 | Device | | Device | | +---------+ | +------+ | +-----+ 403 | | +--------+ +--| Service | | | | | | | 404 +--------+ | | |--+--| HAAA |--+--| PPS | 405 +------------| Device | | | | | 406 AAA) +---------+ +------+ +-----+ 408 Figure 3 Prepaid Service Architecture 410 The following figure 4 shows a static roaming prepaid architecture 411 that is typical of a wholesale scenario for Dial-Up users or a 412 broker scenario used in Dial-Up or WLAN roaming scenarios. 414 +----+ +----+ +----+ +-----+ 415 | | | | | | | | 416 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 417 | | | | | | | | | | | | | | | | 418 |Sub | |Access| | +----+ | +----+ | +----+ | +-----+ 419 | |--| |-+ | | | 420 |Device| |Device| | +----+ | +----+ | +----+ | +-----+ 421 | | | | | | | | | | | | | | | | 422 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 423 | | | | | | | | 424 +----+ +----+ +----+ +-----+ 426 | Visited | |Broker | | Home | 427 | Network | |Network| | Network | 429 Figure 4 Static Roaming Prepaid Architecture 431 As in the basic prepaid architecture the subscriberÆs device 432 establishes a connection with the Access Device (NAS, WLAN Access 433 Point). The Access Device communicates with the Visiting AAA server 434 (VAAA) using the RADIUS protocol. Again for redundancy there maybe 435 more then one VAAA. The VAAA communicate using the RADIUS protocol 436 with AAA servers in the broker network (BAAA). There maybe more 437 then one Broker Network between the Visited Network and the Home 439 RADIUS Extensions for PrePaid February 2004 441 Network. The Home Network is the same as in the simple 442 architecture. 444 To support dynamic roaming the network will utilize mobile-ip. 445 Figure 5 illustrates a typical mobile-ip deployment. Note that 446 typically the mobile device would be moving between networks that 447 use the same technology such as Wireless or WLAN. Increasingly, 448 device will be able to roam between networks that use different 449 technology such as between WLAN and Wireless and Broadband. 450 Fortunately, mobile-ip can address this type of roaming and 451 therefore we need not be concerned with the underlying network 452 technology. 454 +------+ +------+ +----+ +----+ +----+ +-----+ 455 | | | | | | | | | | | | 456 |Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS | 457 | |--|Device| | | | | | | | | 458 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 459 | | | | | | 460 +------+ +------+ | | 461 | | | +----+ 462 | | | | | 463 |ROAMS +------------------+ HA | 464 | | | | 465 V +----+ | +----+ 466 +------+ +------+ | | | | 467 | | | | +-|VAAA+------+ | 468 |Sub | |Access| | | | | 469 | |--|Device+-+ +----+ | 470 |Device| | (FA) | | 471 | | | +------------------------+ 472 +------+ +------+ 474 Figure 5 Roaming using mobile-ip and pre-paid enabled Access 475 Devices 477 In figure 5, the Subscriber device establishes a prepaid session 478 between the Access Device in the foreign network, which has prepaid 479 capabilities and the Home Agent (HA). The setup for this service is 480 identical to the cases covered above. Notice that the Access Device 481 is known as the Foreign Agent (FA). As the subscriber device moves 483 RADIUS Extensions for PrePaid February 2004 485 to another network it establishes a connection with another Access 486 Device in another foreign network. The prepaid data service should 487 continue to be available. When a device associates to another 488 Access Device it MUST re-authenticate at the new Access Device and 489 de-associate or logoff the old Access Device. Furthermore, any 490 unused quota at the old Access Device MUST be promptly credited back 491 to the subscribers account. The reason we say promptly, is because 492 if the subscriber is very low on resources to start with, the 493 subscriber may not have enough resources to log on to the new Access 494 Device. The speed at which resources can be returned depend on the 495 type of handoff procedure that is used: dormant handoff vs. active 496 handoff vs. fast handoff. 498 As well, notice that if the Access Devices could communicate with 499 each other then there could be a way to accelerate a faster handoff 500 procedure. In particular, it could accelerate the return of the 501 unused portion of the quotas from the old Access Device. 503 Unfortunately, standards are evolving with each network technology 504 creating their own scheme to make the handoff procedures more 505 efficient. 507 Finally, pre-paid service may be provided in a roaming scenario 508 where the Access Devices do not support the prepaid client 509 capabilities. In such a scenario, a Service Device is configured as 510 AAA proxy to the Home Agent and also as default gateway for the home 511 agent, see Figure 6. 513 RADIUS Extensions for PrePaid February 2004 515 +------+ +------+ +----+ +----+ +----+ 516 | | | | | | | | | | 517 |Sub | |Access+---|VAAA|-|BAAA|----------------| | 518 | |-|Device| | | | | | | 519 |Device| | (FA) +-+ +----+ +-+--+ (AAA) | | 520 | | | | | | +---------+ |HAAA| 521 +------+ +------+ | | | | | | 522 | | | +----+ +---+ | | +-----+ 523 | | (IP) | | |(IP)|Ser| | | | | 524 |ROAMS +-------------+ HA |----| |--| |--| PPS | 525 | | | | |Dev| | | | | 526 V +----+ | +----+ +---+ +----+ +-----+ 527 +------+ +------+ | | | | 528 | | | | +-|VAAA+---+ | 529 |Sub | |Access| | | | | 530 | |-|Device+-+ +----+ | 531 |Device| | (FA) | (IP) | 532 | | | +-----------------+ 533 +------+ +------+ 535 Figure 6 Roaming using mobile-ip and prepaid enabled Service 536 Device behind the Home Agent. 538 2.1 Why not existing RADIUS attributes? 540 It has been asked ôWhy not use existing RADIUS attributes to build a 541 prepaid solution? This will allow us to have a solution with 542 existing devices without code modification.ö 544 It is possible to build a prepaid solution using existing RADIUS 545 attributes. The RADIUS server can simply send an Access-Accept 546 message containing Session-Timeout(27) and set Termination- 547 Action(29) to RADIUS-request. Upon receiving the Access-Accept 548 message, the NAS will time the session and upon termination of the 549 session the NAS generate an Access-Request message again. The 550 RADIUS server would re-authenticate the session and reply with an 551 Access-Accept message with additional time in Session-Timeout(27) or 552 an Access-Reject message if there were no more resources in the 553 userÆs account. 555 If the user terminates the session before the time expressed in 556 Session-Timeout(27). The NAS will recover any unused time from the 557 accounting stream. 559 RADIUS Extensions for PrePaid February 2004 561 There are several problems with such a solution: 563 -It only allows for time-based prepaid. The solution presented in 564 this document allows for both time and volume based prepaid. As 565 well as extensibility for other features such as tarified based 566 solutions. 568 -This solution only allows for prepaid based on Access. The 569 solution presented in this document allows the use of this protocol 570 to support prepaid solutions for other services not just Access. 572 -Using accounting messages to recoup unused time may be problematic 573 because RADIUS accounting messages are not real-time. A RADIUS 574 server may store-and-forward accounting messages in batches. The 575 solution presented in this paper does not rely on Accounting Packets 576 at all. It uses Access-Request, messages which do flow through any 577 network in real-time. Delaying accounting messages may cause 578 revenue leakage. 580 -Session-Timeout(27) is not a mandatory attribute. If a prepaid 581 subscriber is being serviced by a NAS that does not adhere to 582 Session-Timeout then that subscriber will obtain unlimited service. 584 -Termination-Action(29) presents its own issues. First the 585 behaviour of Termination-Action(29) is not mandatory. Second, 586 according to RFC2865 Termination-Action fires when the Service is 587 complete. But we should not be terminating the service we really 588 should only be terminating a session when we are negotiating 589 additional quota. The refreshing of the time quota should be 590 transparent to the user. Because Termination-Action occurs when the 591 Service is complete it is unclear whether or not the user experience 592 would be transparent. For example, will the RADIUS server allocate 593 the subscriber a new IP address? Furthermore, the RADIUS server has 594 no way of telling why the Access-Request message was generated. The 595 RADIUS server will have to wait for the corresponding accounting 596 packet to determine the reason for this Access-Request message. 597 Lastly re-authenticating the subscriber may take far too long. The 598 solution presented in this document allows quota replenishing to 599 occur in an undisruptive manner from the perspective of the user. 600 No re-authentication is required and quotas can be negotiated prior 601 to the quotas running out. 603 RADIUS Extensions for PrePaid February 2004 605 -Prepaid ambiguity. Implementing prepaid using existing RADIUS 606 attributes presents another problem. Due to the fact that the 607 standard RADIUS attributes are not mandatory, then the correct 608 prepaid operation is really an act of faith on the part of the 609 RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) 610 are not supported, the prepaid subscriber will get free access. The 611 solution described in this document, requires that a prepaid capable 612 NAS inform the RADIUS server whether or not it supports prepaid 613 capabilities. The RADIUS server can now determine whether service 614 should be granted or not. For example, if a prepaid subscriber is 615 connected to a NAS that does not support prepaid, the RADIUS server 616 can either instruct the NAS to tunnel the traffic to a gateway that 617 does support prepaid metering, or it may allow the subscriber on but 618 restrict their traffic. 620 The prepaid solution we present is a robust carrier grade prepaid 621 solution. It only requires the support of 2 mandatory attributes 622 and one optional attribute. Furthermore, it does not really 623 require much code support at the NAS. NASes already support 624 measurement of time and volume. This solution requires that they 625 advertise their prepaid capabilities in an Access-Request; that they 626 generate an Access-Request Authorize-Only packet to obtain more 627 quota at or before the quota is used up. It also requires that the 628 NAS send an Access-Request with Authorize-Only when the session 629 terminates to return any unused quota to the prepaid system. 631 Lastly the solution provided in this document is extensible. This 632 document defines the basic exchanges between a prepaid capable NAS 633 and a RADIUS server. The protocol can easily be extended to support 634 tariff switching and other prepaid business models. 636 3. Use-cases 638 In this section we present a set of use cases that will help 639 establish the requirements needed to deliver PrePaid data services. 640 These use cases donÆt address how the PrePaid account is established 641 or maintained. It is assumed that the PrePaid subscriber has 642 obtained a valid account from a service provider such as a wireless 643 operator or a WLAN operator. 645 To make the document as general as possible, the use cases cover the 646 experience from the Access Device and not from the UserÆs Device. 647 The connection between the UserÆs Device, which typically involves 649 RADIUS Extensions for PrePaid February 2004 651 setting up a layer 2 session, e.g., PPP session or GPRS PDP Context, 652 is specific to a given network technology and the details are not 653 required to deliver a PrePaid service. 655 3.1 Simple pre-paid access use-case 657 A PrePaid subscriber connects to his home network. As usual, the 658 Access Device that is servicing the subscriber will use the AAA 659 infrastructure to authenticate and authorize the subscriber. 661 The Access Device sends a RADIUS Access-Request to the AAA system to 662 authenticate the subscriber, and identify and authorize the service. 663 The Access-Request includes the subscriberÆs credentials and may 664 include the PrePaid capabilities of the Access Device. PrePaid 665 capabilities MUST be included if the Access Device supports PrePaid 666 functionality. 668 The AAA System proceeds with the authentication procedure. This may 669 involve several transactions such as in EAP. Once the subscriber 670 has been validated, the AAA system determines that the subscriber is 671 a PrePaid subscriber and requests that the PrePaid System authorize 672 the PrePaid subscriber. The request MUST include the PrePaid 673 Capabilities of the serving Access Device. These capabilities will 674 include whether the Access Device support optional granular prepaid 675 service. Granular prepaid service allows an Access Device to offer 676 service differentiation above plain network access, for example 677 discriminating between a prepaid service request for access to the 678 public Internet from access to a particular application server 679 hosted in the private domain of the home provider network. In the 680 simple prepaid access scenario, such capabilities are not required 681 to be supported by the Access Device. 683 The PrePaid System will validate that the subscriber has a PrePaid 684 Account; it will validate that the account is active; and will 685 validate that the Access Device has the appropriate PrePaid 686 capabilities. If all is in order, the PrePaid System will authorize 687 the subscriber to use the network. Otherwise it will reject the 688 request. The response is sent back to the AAA System. The response 689 includes attributes such as, definition of what services are 691 RADIUS Extensions for PrePaid February 2004 693 authorized. The exact definition of the service may define vanilla 694 network access or more granular service definition. The exact 695 definition of these services is not the focus of this draft. This 696 definition MAY include a ôservice keyö which can be used to 697 correlate prepaid requests for access to a service with the service 698 definition in the prepaid system. Such service key information MUST 699 be included when the prepaid user has subscribed to more than one 700 prepaid service. If a user has subscribed to only a single service, 701 the response MAY also include an allocation of a portion of the 702 subscriberÆs account called the initial quota (in units of time or 703 volume) and optionally a threshold value. 705 [Editor comments: we should leave tariff switch issues to another 706 document. One way to deal with a tariff switch is to set the 707 threshold or quota such that a new allocation is requested just 708 before or at the tariff switch period.] 710 When the rating engine has determined that a tariff switch will 711 shortly occur, the initial quota may be segmented into that which 712 SHOULD be used before the tariff switch, that which SHOULD be used 713 after the tariff switch together with details describing the tariff 714 switching instant. 716 The Access Device is responsible for requesting quota to be allocate 717 for a particular prepaid user. 719 In order to support concurrent PrePaid sessions, at any time, the 720 PrePaid System allocates a portion of the subscribers account to a 721 given PrePaid session. For example, in a multi-service environment 722 it might happen that an end user with an already ongoing service 723 (e.g., browsing the Internet) issues a new service request (e.g., 724 for downloading a ring-tone) towards the same account. Throughout 725 the lifetime of a session the Access Device will monitor usage 726 according to the quota(s) returned from the prepaid server and will 727 request further quota updates from the PrePaid System as previously 728 allocated quotas are consumed. Conditions may be included with 729 quotas, which indicate when an allocated quota should be returned to 730 the prepaid system. These conditions can include an Idle-Timeout(28) 731 associated with the provided quota. In this case, the Access device 732 monitors the service for activity. When a single inactivity period 733 exceeds that provided in the quota conditions, the unused quota is 734 returned to the prepaid server. 736 RADIUS Extensions for PrePaid February 2004 738 The AAA system incorporates the PrePaid attributes received from the 739 PrePaid System with the service attributes into an Access-Accept 740 message that it sends back to the Access Device. Note the AAA 741 System is responsible for authorizing the service whereas the 742 PrePaid System is responsible for PrePaid authorization. 744 Upon receiving the Access-Response, the Access Device allows the 745 PrePaid data session to start and it starts to meter the session 746 based on time or volume, as indicated in the returned Quota 748 Once the usage for the session approaches the allotted quota (as 749 expressed by the threshold), the Access Device will request an 750 additional quota. The re-authorization for additional quota flows 751 through the AAA system to the PrePaid System. The PrePaid System 752 revalidates the subscriberÆs account; it will subtract the previous 753 quota allocation from the userÆs balance and if there is a balance 754 remaining it will reauthorize the request with an additional quota 755 allotment. Otherwise, the PrePaid System will reject the request. 756 Note the replenishing of the quotas is a re-authorization procedure 757 and does not involve re-authentication of the subscriber. 759 It is important to note that the PrePaid System is maintaining 760 session state for the subscriber. This state includes how much was 761 allocated during the last quota allocation for a particular session 762 and how much is left in the account. Therefore, it is required that 763 all subsequent messages about the PrePaid session reach the correct 764 PrePaid System. 766 Upon receiving a re-allotment of the quota, the Access Device will, 767 continue the data service session until the new threshold is 768 reached. If the request for additional quota cannot be fulfilled 769 then the Access Device will let the subscriber use up the remaining 770 quota and terminate the session. 772 Alternatively, instead of terminating the session, the Access Device 773 may restrict the data session such that the subscriber can only 774 reach a particular web server. This web server maybe used to allow 775 the subscriber to replenish their account. This restriction can 776 also be used to allow new subscribers to purchase their initial 777 PrePaid Service. 779 RADIUS Extensions for PrePaid February 2004 781 Should the subscriber terminate the session before the session the 782 quota is used up, the remaining balance allotted to the session must 783 be credited back to the subscriberÆs account. 785 As well, while the Access Device is waiting for the initial quota, 786 the subscriber may have dropped the session. The initial quota must 787 be credited back to the subscribers account. 789 3.2 Simple Service Device use-case 791 When the Access Device does not support the prepaid extensions, an 792 operator may still offer prepaid services to subscribers by using a 793 service device configured as default IP gateway to the Access 794 device. 796 A Prepaid subscriber connects to his home network in the usual way. 797 The non-prepaid enabled Access Device that is servicing the 798 subscriber will use the AAA infrastructure to authenticate and 799 authorize the subscriber. The Service device will be configured as 800 AAA proxy to the Access Device. 802 The Access Device sends an Access Request to the Service Device 803 acting as AAA proxy to authenticate the subscriber, and identify and 804 authorize the service. The Service Device will proxy the Access 805 Request and append its own Prepaid capabilities to the Access 806 Request message. These prepaid capabilities are defined identically 807 to the simple access device user-case. 809 The prepaid system performs functions as with prepaid support in the 810 Access Device, e.g., the AAA system incorporates the prepaid 811 attributes received from the Prepaid System with the service 812 attributes into an Access-Accept message that it sends back to the 813 Service Device. The Service device removes these attributes before 814 forwarding the Access-Accept message to the Access Device. 816 Upon receiving the Access-Accept with allocated quota, the Service 817 Device allows the prepaid data service session to start and since it 818 is configured as default gateway to the access device, it starts to 819 meter the session based on time and/or volume. 821 3.3 Support for concurrent PrePaid sessions 823 RADIUS Extensions for PrePaid February 2004 825 Both prepaid support using Access Devices and prepaid support using 826 Service Devices can be configured to support a prepaid multi-service 827 environment. In such circumstances, the prepaid client capabilities 828 will indicate that the Access or Service Device supports a multi- 829 service environment [Editor: need to add this to the PPAC]. [Editor: 830 This needs to be reworked. DonÆt believe that this step is required. 831 The Service Ids should be known a priori ¡ the Access Request should 832 include the Service Key being requested.] In such circumstances, 833 instead of returning a quota, the prepaid service provides a list of 834 authorized services corresponding to a list of service keys to the 835 prepaid client. The Access/Service device then uses these service 836 keys to request prepaid authorization to the corresponding services. 837 The prepaid server responds with an individual quota for the 838 requested service key [Editor: add service key to PPAQ]. The 839 Access/Service Device may in parallel request prepaid authorization 840 to a second service key. In which case a separate authorization 841 exchange is used to provide an independent quota for this second 842 service. 844 Each session is treated independently. 846 The method by which a prepaid user activates a service and the 847 method for signaling this information to the Access/Service Device 848 is out of scope of this draft. 850 The method by which a granular service is defined is out of scope of 851 this draft. Only service key correlation information is required to 852 enable the prepaid server to authorize and rate a particular 853 request. 855 3.4 Support for Roaming 857 For some networks it is essential that PrePaid Data Services be 858 offered to roaming subscribers. Support for static and dynamic 859 roaming models are needed. Static roaming is where the subscriber 860 logs onto a foreign network. The foreign network has a roaming 861 agreement directly with the home network or through a broker network 862 or networks. The subscriber remains logged into the network until 863 the subscriber changes location. When changing location a new 864 connection and a new login procedure is required. 866 Dynamic roaming allows to subscriber to move between foreign 867 networks while maintaining a connection with the home network 869 RADIUS Extensions for PrePaid February 2004 871 seamlessly. As the subscriber moves between networks, the data 872 session is handed off between the networks. 874 In both roaming scenarios, the subscriber always authenticates with 875 the home network. PrePaid authorization and quota replenishing for 876 the session need to be received at the home network and more 877 specifically at the PrePaid System where state is being maintained. 879 Dynamic roaming is particularly challenging. A subscriber that 880 established a PrePaid Data Session may roam to another Access Device 881 that doesnÆt not support PrePaid functionality. The system should 882 be capable to continue the PrePaid session. 884 3.5 PrePaid termination 886 When fraud is detected by the PrePaid System, or when an error is 887 detected, it may be beneficial for the PrePaid system to terminate a 888 specific session for the subscriber or all the sessions of a 889 subscriber. 891 Some errors can occur such that the PrePaid System is in a state 892 where it is not sure whether the session is in progress or not. 893 Under conditions such as this, the PrePaid system may wish to 894 terminate the PrePaid data session to make sure that resources are 895 not being utilized for which it canÆt charge for reliably. 897 Some handoff procedure used during dynamic roaming may require that 898 the PrePaid system explicitly terminate the subscribers PrePaid data 899 session at an Access Device. For example, if time based PrePaid 900 service is being used and the mobile subscriber performs a dormant 901 handoff, the PrePaid System needs to explicitly terminate the 902 PrePaid session at the old Access Device. 904 4. Operations 906 4.1 General Requirements 908 4.1.1 Broker AAA Requirements 910 Broker AAA servers MUST support the Message-Authenticator(80) 911 attribute as defined in [RFC2869]. If BAAA servers are used, the 913 RADIUS Extensions for PrePaid February 2004 915 BAAA servers function is to forward the RADIUS packets as usual to 916 the appropriate RADIUS servers. 918 Accounting messages are not needed to deliver a PrePaid service. 919 However, accounting messages can be used to keep the PrePaid Server 920 current as to what is happening with the PrePaid data session. 921 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 922 pass through mode described in [RFC2866]. 924 4.2 Authentication and Authorization for Prepaid Enabled Access Devices 926 The Access Device initiates the authentication and authorization 927 procedure by sending a RADIUS Access-Request as usual. 929 If the Access Device has PrePaid Client capabilities, it MUST 930 include the PPAC(TBD) attribute in the RADIUS Access-Request. The 931 PPAC(TBD) attribute indicates to the PrePaid server the PrePaid 932 capabilities possessed by the Access Device. These are required in 933 order to complete the PrePaid authorization procedures. 935 [Editor: add support for the MultiSession-Capabilities attribute] 936 If the Access Device supports multiple sessions-keys capabilities, 937 then it SHOULD include the MultiSession-Capabilities attribute. The 938 presence of the MultiSession-Capabilities attribute will indicate to 939 the PPS that the Access Device support prepaid service 940 differentiation above simple prepaid access. 942 If the Access Device supports the Disconnect-Message or the Change- 943 of-Authorization capabilities, then it SHOULD include the Dynamic- 944 Capabilities attribute. 946 In certain deployments, there may be other ways in which to 947 terminate a data session, or change authorization of an active 948 session. For example, some Access Devices provide a session 949 termination service via Telnet or SNMP. In these cases, the AAA 950 server MAY add the Dynamic-Capabilities message to the Access- 951 Request. Upon receiving the Change-of-Authorization message, the 952 AAA server would then be responsible for terminating the session 953 using whatever means that are supported by the device. 955 If the authentication procedure involves multiple Access-Requests 956 (as in EAP), the Access Device MUST include the PPAC(TBD) attribute 958 RADIUS Extensions for PrePaid February 2004 960 and the Dynamic-Capabilities attribute (if used) in at least the 961 last Access-Request of the authentication procedure. 963 The Access-Request will be sent as usual to the HAAA. The packet 964 may be proxied through zero or more BAAA. 966 Once the Access-Request arrives at the HAAA, the HAAA will 967 authenticate the subscriber. If the subscriber is cannot be 968 authenticated, the HAAA will send an Access-Reject message back to 969 the client. If the subscriber is authenticated, the HAAA will 970 determine whether or not the subscriber is a PrePaid subscriber. 971 The techniques used to determine whether or not a subscriber is a 972 PrePaid subscriber is beyond the scope of this document. If the 973 subscriber is not a PrePaid subscriber, then the HAAA will respond 974 as usual with an Access-Accept or Access-Reject message. If the 975 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 976 Access-Request to a PrePaid server for further authorization. 978 The Access-Request will contain the PPAC(TBD) attribute, the 979 Dynamic-Capabilities attribute if one was included; and the 980 MultiSession-Capabilities attribute if one was included, the User- 981 Name(1) attribute MAY be set to a value that would represent the 982 SubscriberÆs PrePaid Identity. This attribute is used by the 983 PrePaid server to locate the PrePaid SubscriberÆs account. For 984 added security, the HAAA MAY also set the User-Password(2) attribute 985 to the password used between the HAAA and the PrePaid server. 987 The PrePaid server lookups the subscriberÆs PrePaid account and will 988 authorize the subscriber taking into consideration the Access Device 989 PrePaid Client Capabilities. The Prepaid Server will decide whether 990 single service prepaid access will be provided or a multiple session 991 pre-paid access will be provided. 993 4.2.1 Single Service Pre-paid 995 If a single service prepaid access is provided, upon successful 996 authorization, the PrePaid server will generate an Access-Accept 997 containing the PPAC(TBD) attribute and the PPAQ(TBD) attribute. 999 The PPAC attribute returned to the client indicates the type of 1000 prepaid service to be provided for the session. 1001 which contains the following sub-attributes: 1003 RADIUS Extensions for PrePaid February 2004 1005 - The QUOTA-Id which is set by the PrePaid server to a unique value 1006 that is used to correlate subsequent quota requests; 1008 - Volume and/or Time Quotas, one of which is set to a value 1009 representing a portion of the subscribers account; 1011 - MAY contain a Time or Volume Threshold that controls when the 1012 Access Device requests additional quota; 1014 - The IP address of the Serving PrePaid Server and one or more 1015 alternative PrePaid Servers. This is used by the HAAA to route 1016 subsequent quota replenishing messages to the appropriate PrePaid 1017 server(s). 1019 Note: Idle-Timeout(28) can be used to trigger the premature 1020 termination of a pre-paid service following subscriber inactivity. 1022 Depending on site policies, upon unsuccessful authorization, the 1023 PrePaid server will generate an Access-Reject to terminate the 1024 session immediately. Alternatively, the PrePaid server may generate 1025 an Access-Accept blocking some or all of the traffic and/or redirect 1026 some or all of the traffic to a location where the subscriber can 1027 replenish their account for a period of time. Blocking of traffic 1028 is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect 1029 I-d). Redirection is achieved by sending Redirect-Id or Redirect- 1030 Rule defined in the Redirect I-d. The period of time before the 1031 blocked/redirected session last can be specified by Session- 1032 Timeout(27) attribute. 1034 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 1035 will append the usual service attributes and forward the packet to 1036 the Access Device. The HAAA SHALL NOT append or overwrite any 1037 attributes already set by the PrePaid server. If the HAAA, receives 1038 an Access-Reject message, it will simply forward the packet to its 1039 client. Depending on site policies, if the HAAA fails to receive an 1040 Access-Accept or Access-Reject message from the PrePaid server it 1041 MAY do nothing or send an Access-Reject or an Access-Accept message 1042 back to its client. 1044 4.2.2 Multiple-Session Pre-paid 1046 RADIUS Extensions for PrePaid February 2004 1048 If the prepaid server decides that multiple-session prepaid service 1049 is to be provided, upon successful authorization, the Prepaid server 1050 will generate an Access-Accept containing the PPAQ attribute which 1051 contains the following sub-attributes: 1053 - a list of the service keys which the Access Device can subsequently 1054 use in pre-paid service authorization request. 1056 [Editor: if this stands (see earlier comments) then instead of 1057 issuing an access-accept the PPS should issue a Challenge that 1058 contains the service-keys] 1060 The first PrepaidServer subtype is set to the IP address of the 1061 Serving Prepaid Server, the second one is set to an alternate 1062 Prepaid Server if any. This way the HAAA will be able to route 1063 subsequent packets to the serving Prepaid Server or its alternate. 1065 [Editor: this should only be done on the Access Accept that deliver 1066 the quota for the specific service.] 1067 Additionally, the Prepaid server MAY set the Terminate-Action(29) to 1068 RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control 1069 how often interim Accounting Requests are generated. 1071 Upon receiving the Access-Accept from the Prepaid Server, the HAAA 1072 will append the usual service attributes and forward the packet. 1073 The HAAA SHALL NOT append any attributes already set by the Prepaid 1074 server. If the HAAA, receives an Access-Reject message, it will 1075 simply forward the packet to its client. Depending on site 1076 policies, if the HAAA fails to receive an Access-Accept message from 1077 the Prepaid server it MAY do nothing or send an Access-Reject or an 1078 Access-Accept message back to its client. 1080 Upon receiving the Access-Accept with a list of service keys, the 1081 Access Device can trigger the authorization request for a particular 1082 service corresponding to a service key. The technique for triggering 1083 an authorization request for a particular service is out of scope of 1084 this draft. 1086 The Access Device initiates authorization for a particular service 1087 by sending a RADIUS Access Request including a single service-key 1088 reference. 1090 RADIUS Extensions for PrePaid February 2004 1092 For the specific service-key reference, the prepaid server will 1093 check whether funds are available and will, following successful 1094 allocation of funds, the Prepaid server will generate an Access- 1095 Accept containing the PPQ-Response attribute which contains the 1096 following sub-attributes: 1098 - The QUOTA-Id which is set by the Prepaid server to a unique value 1099 that is used to correlate subsequent quota updates; 1101 - The ServiceKey-Id which is set by the Prepaid server to the 1102 service key requested by the Access Device; 1104 - Volume and Time Quotas, one of which is set to a value 1105 representing a portion of the subscribers account; 1107 - The Time of Volume Threshold that the Prepaid server MAY set to 1108 control when the Access Device requests additional quota. 1110 Note: Idle-Timeout(28) can be used to trigger the premature 1111 termination of a pre-paid service following subscriber inactivity. 1113 4.3 Session Start Operation 1115 The real start of the session is indicated by the arrival of 1116 Accounting-Request(Start) packet. The Accounting-Request (Start) 1117 MAY be routed to the PrePaid Server so that it can confirm the 1118 initial quota allocation. 1120 Note that the PrePaid Server role is not to record accounting 1121 messages and therefore it SHOULD not respond with an Accounting 1122 Response packet. 1124 If the Prepaid server does not receive the Accounting-Request(start) 1125 message it will only know that the session has started upon the 1126 first reception of a quota replenishment operation. 1128 If the Prepaid server does not receive indication directly (via 1129 Accounting-Request(start)) or indirectly, it SHOULD after some 1130 configurable time, deduce that the Session has not started. If the 1131 Access Device supports termination capabilities, the PPS SHOULD send 1132 a Disconnect Message to the Access Device to ensure that the session 1133 is indeed dead. 1135 RADIUS Extensions for PrePaid February 2004 1137 4.4 Mid-Session Operation 1139 During the lifetime of a PrePaid data session the Access Device will 1140 request to replenish the quotas using Authorize-Only Access-Request 1141 messages. 1143 Once the allocated quota has been reached or the threshold has been 1144 reached, the Access Device MUST send an Access-Request with Service- 1145 Type(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD) 1146 attribute. 1148 The Access Device MUST also include NAS identifiers, and Session 1149 identifier attributes in the Authorize Only Access-Request. The 1150 Session Identifier should be the same as those used during the 1151 Access-Request. For example, if the User-Name(1) attribute was used 1152 in the Access-Request it MUST be included in the Authorize Only 1153 Access-Request especially if the User-Name(1) attribute is used to 1154 route the Access-Request to the Home AAA server. 1156 The Authorize Only Access-Request MUST not include either User 1157 Password or Chap Password. In order to authenticate the message, 1158 the Access Device MUST include the Message-Authenticator(80) 1159 attribute. The Access Device will compute the value for the 1160 Message-Authenticator based on [RFC2869]. 1162 When the HAAA receives the Authorize-Only Access-Request that 1163 contains a PPAQ(TBD), it SHALL validate the message using the 1164 Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an 1165 Authorize Only Access-Request that contains a PPAQ(TBD) but not a 1166 Message-Authenticator(80) it SHALL silently discard the message. An 1167 Authorize Only Access-Request message that does not contain a 1168 PPAQ(TBD) is either in error or belongs to another application (for 1169 example, a Change of Authorization message [RFC3576]). In this case 1170 the Authorize Only Access-Request will either be silently discarded 1171 or handled by another application (not in scope of this document). 1173 Once the Authorize Only Access-Request message is validated, the 1174 HAAA SHALL forward the Authorize Only Access-Request to the 1175 appropriate PrePaid Server. The HAAA MUST forward the Authorize 1176 Only Access-Request to the PrePaid server specified in the 1177 PPAQ(TBD). The HAAA MUST sign the message using the Message- 1178 Authenticator(80) and the procedures in [RFC2869]. As with the 1180 RADIUS Extensions for PrePaid February 2004 1182 Access-Request message, the HAAA MAY modify the User-Name(1) 1183 attribute to a value that represents the userÆs internal PrePaid 1184 account in the PrePaid server. Note the PrePaid server could use 1185 the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate 1186 the user account. 1188 Upon receiving the Authorize Only Access-Request containing a 1189 PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- 1190 Authenticator(80) as prescribed in [RFC2869]. If the message is 1191 invalid, the PrePaid server MUST silently discard the message. If 1192 it received an Authorize Only Access-Request message that does not 1193 contain a PPAQ(TBD) it MUST silently discard the message. 1195 The PrePaid server will lookup the PrePaid session by using the 1196 PrePaid Quota Id contained within the PPAQ(TBD). The PrePaid Server 1197 would, take the last allocated quota and subtract that from the 1198 UserÆs balance. If there is remaining balance, the PrePaid server 1199 re-authorizes the PrePaid session by allocate an additional quota. 1200 The PrePaid server may want to calculate a different threshold 1201 values as well. 1203 Upon successful re-authorization, the PrePaid server will generate 1204 an Access-Accept containing the PPAQ(TBD) attribute. The Access- 1205 Accept message MAY contain Service-Type(6) set to Authorize-Only and 1206 MAY contain the Message-Authenticator(80). 1208 Depending on site policies, upon unsuccessful authorization, the 1209 PrePaid server will generate an Access-Reject or an Access-Accept 1210 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 1211 and the Session-Timeout(27) attribute such that the PrePaid 1212 subscriber could get access to a restricted set of locations for a 1213 short duration to allow them to replenish their account, or create 1214 an account; or to browse free content. 1216 Upon receiving the Access-Accept from the PrePaid server, the HAAA 1217 SHALL return the packet to its client. If the HAAA, receives an 1218 Access-Reject message, it will forward the packet. Depending on 1219 site policies, if the HAAA fails to receive an Access-Accept or an 1220 Access-Reject message from the PrePaid server it MAY do nothing or 1221 it MAY send an Access-Reject message back to its client. 1223 Upon receiving an Access-Accept, the Access Device SHALL update its 1224 quotas and threshold parameters with the values contained in the 1226 RADIUS Extensions for PrePaid February 2004 1228 PPAQ(TBD) attribute. Note that the PrePaid server MAY update the 1229 PrePaidServer attribute(s) and these may have to be saved as well. 1231 Upon receiving an Access-Accept message containing either Filter- 1232 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 1233 The Access Device SHALL restrict the subscriber session accordingly. 1235 4.5 Dynamic Operations 1237 The PrePaid server may want to take advantage of the dynamic 1238 capabilities that are supported by the Access Device as advertised 1239 in the Dynamic-Capabilities attribute during the initial Access- 1240 Request. 1242 There are two types of actions that the PrePaid server can perform: 1243 it can request that the session be terminated; or it can request 1244 that the filters associated with the session be modified. 1246 Both of these actions require that the session be uniquely 1247 identified at the Access Device. As a minimum the PrePaid server: 1249 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 1250 -MUST provide at least one session identifier such as User-Name(1), 1251 Framed-IP-Address(), the Accounting-Session-Id(44). 1253 Other attributes could be used to uniquely identify a PrePaid data 1254 session. 1256 4.5.1 Unsolicited Session Termination Operation 1258 This capability is described in detail in [RFC3576]. The PrePaid 1259 server sends a Disconnect Request packet that MUST contain 1260 identifiers that uniquely identify the subscriberÆs data session and 1261 the Access Device servicing that session. 1263 Upon receiving the Disconnect Request packet the HAAA will either 1264 act on it or will proxy it to another AAA server until it is 1265 received by the a AAA that is in the same network as the serving 1266 Access Device. 1268 Each AAA MUST route the Disconnect Request packet. How the routing 1269 decision is made is an implementation detail. 1271 RADIUS Extensions for PrePaid February 2004 1273 Once the Disconnect Request packet reaches AAA that is in the same 1274 network as the serving Access Device, if the Access Device supports 1275 Disconnect-Request (as per [RFC3576]), it sends the message directly 1276 to the Access Device; otherwise it uses other mechanisms such as 1277 SNMP or Telnet to command the Access Device to terminate the session 1278 (this is an implementation detail). 1280 If the Access Device receives a Disconnect-Request packet, it will 1281 respond with either a Disconnect-ACK packet if it was able to 1282 terminate the session or else it will respond with a Disconnect-NAK 1283 packet. 1285 If the AAA server is performing the disconnect operation, it MUST 1286 respond with a Disconnect-ACK message if it successfully terminated 1287 the session or a Disconnect-NAK message if it failed to terminate 1288 the session with the appropriate Error-Cause(101) set. 1290 If any AAA server is unable to route the Disconnect-Request it MUST 1291 respond with a Disconnect-NAK packet with Error-Cause(101) set to 1292 ôRequest Not Routableö(502). 1294 4.5.2 Unsolicited Change of Authorization Operation 1296 The PrePaid Server MAY send a Change-of-Authorization message as 1297 described in [RFC3576] to restrict Internet access when the 1298 subscriber has no more balance. The COA packet may contain Filter- 1299 Id(11) and or attributes defined in Redirect I-d. 1301 The PrePaid server sends a Change-of-Authorization packet it MUST 1302 contain identifiers that will uniquely identify the subscriber 1303 session and the Access Device serving that session. 1305 Upon receiving the Change-of-Authorization packet the HAAA will 1306 either act on it or proxy it to another AAA server until it is 1307 received by a AAA server that is in the same network as the serving 1308 Access Device. 1310 Each AAA must route the packet to the serving network. How the 1311 routing decision is made is an implementation detail. 1313 Once the Change-of-Authorization packet reaches a AAA that is in the 1314 same network as the serving Access Device, if the Access Device 1315 supports Change-of-Authorization message, it will forward the 1317 RADIUS Extensions for PrePaid February 2004 1319 message to the Access Device; otherwise, it will use other 1320 mechanisms such as SNMP or Telnet to command the Access Device to 1321 change its filters. 1323 If the Access Device receives a Change-of-Authorization packet, it 1324 will respond with either a Change-of-Authorization-ACK packet if it 1325 was able to change the filter or else it will respond with a Change- 1326 of-Authorization-NAK packet. 1328 If the AAA server is performing the change of filter operation, it 1329 MUST respond with a Change-of-Authorization-ACK message if it 1330 successfully or a Change-of-Authorization-NAK packet if it failed to 1331 change the filter. 1333 If a AAA server was unable to route the Change-of-Authorization it 1334 MUST respond with a Change-of-Authorization-NAK packet. 1336 4.6 Termination Operation 1338 The termination phase is initiated when either: the Subscriber logs 1339 off; the quotas have been consumed, or when the Access Device 1340 receives a Disconnect Message. In all of these instances, if the 1341 session is a PrePaid data session, the Access Device will send an 1342 Authorize-Only Access-Request message with a PPAQ(TBD) Update-Reason 1343 attribute set to either ôClient Service terminationö or ôRemote 1344 Forced disconnectö and the currently used quota. 1346 The BAAA MUST forward this packet to the next BAAA or the HAAA. 1348 The HAAA MUST validate the Authorize Only Access-Request using the 1349 Message-Authenticator(80) as per [RFC2869] and if valid, use the 1350 PrePaidServer subtype in the PPAQ(TBD) to forward the Authorize Only 1351 Access-Request packet to the serving PrePaid Server or if needed, 1352 its alternate. 1354 The PrePaid Server MUST validate the Authorize Only Access Request 1355 and use the information contained in the PPAQ(TBD) attribute to 1356 adjust the subscriberÆs balance and to close the session. The 1357 PrePaid Server SHALL respond back with an Access-Accept message. 1359 4.7 Mobile IP Operations 1361 RADIUS Extensions for PrePaid February 2004 1363 In roaming scenarios using mobile-ip, as the mobile subscriber roams 1364 between networks, or between different types of networks such as 1365 between WLAN and CDMA2000 networks, the PrePaid data session is 1366 maintained transparently. 1368 As the subscriber device associates with the new Access Device, the 1369 Access Device sends a RADIUS Access-Request and the subscriber is 1370 re-authenticated and reauthorized. If the Access Device has PrePaid 1371 Client capabilities, it MUST include the PPAC(TBD) attribute in the 1372 RADIUS Access-Request. In this manner the procedure follows the 1373 Authentication and Authorization procedure described earlier. 1375 The Access-Request message is routed to the home network and MUST 1376 reach the PrePaid System that is serving the PrePaid session. The 1377 PrePaid system will then correlate the new authorization request 1378 with the existing active session and will assign a quota to the new 1379 request. Any outstanding quota at the old Access Device will be 1380 returned to the PrePaid system due to the usual mobile-ip handoff 1381 procedures. Specifically, the quota will be returned when the 1382 Access Device sends the Authorize Only Access-Request with PPAQ(TBD) 1383 Update-Reason subtype set to either ôRemote Forced disconnectö or 1384 ôClient Service terminationö. In order to trigger the sending of 1385 this last Authorize Only Access-Request, the PrePaid system may 1386 issue a Disconnect Message [CHIBA] to the Access Device. 1388 If the subscriber has roamed to an Access Device that does not have 1389 any PrePaid Capabilities, PrePaid data service may still be possible 1390 by requesting the Home Agent (providing it has PrePaid Capabilities) 1391 to assume responsibilities for metering the service. The procedure 1392 for this scenario will be given in the next release of this draft. 1394 4.8 Accounting Considerations 1396 Accounting messages are not required to deliver PrePaid Data 1397 Service. Accounting message will typically be generated for PrePaid 1398 Data Service. This because accounting message are used for auditing 1399 purposes as well as for bill generation. 1401 Accounting messages associated with PrePaid Data Sessions should 1402 include the PPAQ(TBD) attribute. 1404 4.9 Service Device Operation 1406 RADIUS Extensions for PrePaid February 2004 1408 To be completed 1410 4.10 Interoperability with Diameter Credit Control Application 1412 RADIUS PrePaid solutions need to interoperate with Diameter 1413 protocol. Two possibilities exist: The AAA infrastructure is 1414 Diameter based and the Access Device are RADIUS based; or the Access 1415 Device is Diameter based and the AAA infrastructure is RADIUS based. 1417 The Diameter Credit Control Application [DIAMETERCC] describes how 1418 to implement a PrePaid using an all Diameter based infrastructure. 1420 1422 5. Attributes 1424 This draft is using the RADIUS [RFC2865] namespace. 1426 5.1 PPAC Attribute 1428 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1429 Access-Request message by a Prepaid Capable NAS and is used to 1430 describe the PrePaid capabilities of the NAS. The PPAC is available 1431 to be sent in an Access-Accept message by the Prepaid server to 1432 indicate the type of prepaid metering that is to be applied to this 1433 session. 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | AvailableInClient (AiC) | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | SUB-TYPE 2 | LENGTH | SelectedForSession (SFS) | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 TYPE : value of PPAC 1449 RADIUS Extensions for PrePaid February 2004 1451 LENGTH: 14 1452 VALUE : String 1454 The value MUST be encoded as follows: 1456 Sub-Type (=1) : Sub-Type for AvailableInClient attribute 1457 Length : Length of AvailableInClient attribute 1458 (= 6 octets) 1459 AvailableInClient (AiC): 1461 The optional AvailableInClient Sub-Type, generated by the PrePaid 1462 client, indicates the PrePaid Accounting capabilities of the NAS and 1463 shall be bitmap encoded. The possible values are: 1465 0x00000001 PrePaid Accounting for Volume supported 1466 0x00000010 PrePaid Accounting for Duration supported 1467 0x00000011 PrePaid Accounting for Volume and Duration supported 1468 (non concurrently) 1469 Others Reserved, treat like Not Capable of PrePaid 1470 Accounting (=0). 1472 Sub-Type (=2) : Sub-Type for SelectedForSession attribute 1473 Length : Length of SelectedForSession attribute 1474 (= 6 octets) 1475 SelectedForSession (SfS): 1477 The optional SelectedForSession Sub-Type, generated by the PrePaid 1478 server, indicates the PrePaid Accounting capability to be used for a 1479 given session. The possible values are: 1481 0x00000000 PrePaid Accounting not used 1482 0x00000001 Usage of PrePaid Accounting for Volume. 1483 (only possible if the AvailableInClient supports 1484 PrePaid Accounting for Volume) 1485 0x00000010 Usage of PrePaid Accounting for Duration. 1486 (only possible if the AvailableInClient supports 1487 PrePaid Accounting for Duration) 1488 0x00000011 Usage of PrePaid Accounting for Volume and Duration 1489 (non concurrent) (only possible if the 1490 AvailableInClient supports PrePaid Accounting for 1491 Volume and duration) 1492 Others Reserved, treat like PrePaid Accounting not used(=0). 1494 RADIUS Extensions for PrePaid February 2004 1496 5.2 Session Termination Capability 1498 The value shall be bitmap encoded rather than a raw integer. This 1499 attribute shall be included RADIUS Access-Request message to the 1500 RADIUS server and indicates whether or not the NAS supports Dynamic 1501 Authorization. 1503 0 1 2 3 1504 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 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | TYPE | LENGTH | String | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 Type : value of Session Termination Capability 1510 Length: = 4 1511 String encoded as follows: 1513 0x00000001 Dynamic Authorization Extensions (rrfc3576) is 1514 supported. 1516 5.3 PPAQ Attribute 1518 The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and 1519 Access-Accept messages. In Authorize Only Access-Request messages 1520 it is used to report usage and request further quota; in an Access- 1521 Accept message it is used to allocate the quota (initial quota and 1522 subsequent quotas). 1524 The attribute consists of a number of subtypes. Subtypes not used 1525 are omitted in the message. 1527 RADIUS Extensions for PrePaid February 2004 1529 0 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | QuotaIdentifier (QID) | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | SUB-TYPE 2 | LENGTH | Volume Quota | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Volume Quota | SUB-TYPE 3 | LENGTH | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | VolumeThreshold (VT) | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | SUB-TYPE 6 | LENGTH | DurationQuota (DQ) | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | DurationThreshold (DT) | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | SUB-TYPE 9 | LENGTH | PrePaidServer | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | PrePaidServer | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Type : Value of PPAQ 1560 Length: variable, greater than 8 1562 String: The String value MUST be encoded as follows: 1564 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 1565 Length : Length of QuotaIDentifier attribute (= 6 octets) 1567 QuotaIDentifier (QID): 1569 The QuotaIDentifier Sub-Type is generated by the PrePaid server 1570 at allocation of a Volume and/or Duration Quota. The on-line 1572 RADIUS Extensions for PrePaid February 2004 1574 quota update RADIUS Access-Request message sent from the Access 1575 Device to the PPS shall include a previously received 1576 QuotaIDentifier. 1578 Sub-Type (=2): Sub-Type for VolumeQuota attribute 1579 Length : length of VolumeQuota attribute (= 6 octets) 1581 VolumeQuota (VQ): 1583 The optional VolumeQuota Sub-Type is only present if Volume Based 1584 charging is used. In RADIUS Access-Accept message (PPS to Access 1585 Device direction), it indicates the Volume (in octets) allocated 1586 for the session by the PrePaid server. In RADIUS Authorize Only 1587 Access-Request message (Access Device to PPS direction), it 1588 indicates the total used volume (in octets) for both forward and 1589 reverse traffic applicable to PrePaid accounting. 1591 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 1592 Length : length of VolumeQuotaOverflow attribute (= 4 octets) 1594 VolumeQuotaOverflow (VQO): 1596 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 1597 many times the VolumeQuota counter has wrapped around 2^32 over 1598 the course of the service being provided. 1600 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 1601 Length : length of VolumeThreshold attribute (= 6 octets) 1603 VolumeThreshold (VT): 1605 The VolumeThreshold Sub-Type shall always be present if 1606 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1607 Access Device direction). It is generated by the PrePaid server 1608 and indicates the volume (in octets) that shall be used before 1609 requesting quota update. This threshold should not be larger than 1610 the VolumeQuota. 1612 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1613 Length : Length of VolumeThresholdOverflow attribute 1614 (= 4 octets) 1616 VolumeThresholdOverflow (VTO): 1618 RADIUS Extensions for PrePaid February 2004 1620 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1621 how many times the VolumeThreshold counter has wrapped around 1622 2^32 over the course of the service being provided. 1624 Sub-Type (=6): Sub-Type for DurationQuota attribute 1625 Length : length of DurationQuota attribute (= 6 octets) 1627 DurationQuota (DQ): 1629 The optional DurationQuota Sub-Type is only present if Duration 1630 Based charging is used. In RADIUS Access-Accept message (PPS to 1631 Access Device direction), it indicates the Duration (in seconds) 1632 allocated for the session by the PrePaid server. In on-line 1633 RADIUS Access-Accept message (PPC to PPS direction), it indicates 1634 the total Duration (in seconds) since the start of the accounting 1635 session related to the QuotaID. 1637 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1638 Length : length of DurationThreshold attribute (= 6 octets) 1640 DurationThreshold (DT): 1642 The DurationThreshold Sub-Type shall always be present if 1643 DurationQuota is present in a RADIUS Access-Accept message (PPS 1644 to Access Device direction). It represents the duration (in 1645 seconds) that shall be used by the session before requesting 1646 quota update. This threshold should not be larger than the 1647 DurationQuota and shall always be sent with the DurationQuota. 1649 Sub-Type (=8): Sub-Type for Update-Reason attribute 1650 Length : length of Update-Reason attribute (= 4 octets) 1652 Update-Reason attribute (UR): 1654 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1655 Access-Request message (Access Device to PPS direction). It 1656 indicates the reason for initiating the on-line quota update 1657 operation. Update reasons 4, 5, 6, 7 and 8 indicate that the 1658 associated resources are released at the client side, and 1659 therefore the PPS shall not allocate a new quota in the RADIUS 1660 Access_Accept message. 1662 RADIUS Extensions for PrePaid February 2004 1664 1. Pre-initialization 1665 2. Initial request 1666 3. Threshold reached 1667 4. Quota reached 1668 5. Remote Forced disconnect 1669 6. Client Service termination 1670 7. Main SI released 1671 8. Service Instance not established 1673 Sub-Type (=9) : Sub-Type for PrePaidServer attribute 1674 Length : Length of PrePaidServer 1675 (IPv4 = 6 octets, IPv6= 18 octets 1677 PrePaidServer: 1679 The optional, multi-value PrePaidServer indicates the address of 1680 the serving PrePaid System. If present, the Home RADIUS server 1681 uses this address to route the message to the serving PrePaid 1682 Server. The attribute may be sent by the Home RADIUS server. If 1683 present in the incoming RADIUS Access-Accept message, the PDSN 1684 shall send this attribute back without modifying it in the 1685 subsequent RADIUS Access-Request message, except for the first 1686 one. If multiple values are present, the PDSN shall not change 1687 the order of the attributes. 1689 NOTES: 1691 Either Volume-Quota or Time-Quota MUST appear in the attribute. 1692 Volume Threshold may only appear if Volume Quota appears 1693 If the Access Device can measure time, and if Time-Threshold appears 1694 with Volume Quota, then the Access device should trigger a quota 1695 replenishment when the Current Time >= Time-Threshold. 1697 5.4 Table of Attributes 1699 TO BE COMPLETED. 1701 Request Accept Reject Challenge # Attribute 1703 Authorize_Only Request Accept Reject 1705 RADIUS Extensions for PrePaid February 2004 1707 6. Security Considerations 1709 The protocol exchanges described are susceptible to the same 1710 vulnerabilities as RADIUS and it is recommended that IPsec be 1711 employed to afford better security. 1713 If IPsec is not available the protocol in this draft improves the 1714 security of RADIUS. The various security enhancements are explained 1715 in the following sections. 1717 6.1 Authentication and Authorization 1719 RADIUS is susceptible to replay attacks during the Authentication 1720 and Authorization procedures. A successful replay of the initial 1721 Access-Request could result in an allocation of an initial quota. 1723 To thwart such an attack... 1725 6.2 Replenishing Procedure 1727 A successful replay attacks of the Authorize Only Access-Request 1728 could deplete the subscribers prepaid account. 1730 To be completed. 1732 7. IANA Considerations 1734 To be completed. 1736 This draft does create RADIUS attributes. However, the authors 1737 recognize that it may not be possible to obtain such attributes. 1738 Therefore, in subsequent drafts it will be proposed to use a Vendor 1739 space as an Application Space. 1741 8. Normative References 1743 [RFC2026] Bradner, S., "The Internet Standards Process -- 1744 Revision 3", RFC 2026, October 1996. 1745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1746 Requirement Levels", RFC 2119, March 1997. 1747 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1749 RADIUS Extensions for PrePaid February 2004 1751 "Remote Authentication Dial In User Server 1752 (RADIUS)", RFC 2865, June 2000. 1754 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1755 2000. 1757 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1758 Extensions", RFC 2869, June 2000. 1760 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1761 Holdrege, M., Goyret, I., "RADIUS Attributes for 1762 Tunnel Protocol Support" , RFC 2868, June 2000. 1763 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1764 Aboba, B., "Dynamic Authorization Extensions to 1765 Remote Authentication Dial-In User Service 1766 (RADIUS)", RFC 3576, February 2003. 1768 [DIAMETERCC] Work in Progress. 1769 [REDIRECT] RADIUS Redirection Internet Draft. Work in progress. 1771 Acknowledgments 1773 The authors would like to thank Mark Grayson (Cisco) and Nagi 1774 Jonnala for their contribution to this draft. 1776 Author's Addresses 1778 Avi Lior Parviz Yegani, Ph.D. 1779 Bridgewater Systems Mobile Wireless Group 1780 303 Terry Fox Drive Cisco Systems 1781 Suite 100 3625 Cisco Way 1782 Ottawa Ontario San Jose, CA 95134 1783 Canada USA 1784 avi@bridgewatersystems.com pyegani@cisco.com 1786 Kuntal Chowdhury Lila Madour 1787 Nortel Networks Ericsson Canada 1788 2221, Lakeside Blvd, 5400 Decarie, TMR 1789 Richardson, TX-75082 Quebec, Canada 1790 chowdury@nortelnetworks.com Lila.madour@ericsson.ca 1792 Yong Li 1793 Bridgewater Systems 1795 RADIUS Extensions for PrePaid February 2004 1797 303 Terry Fox Drive 1798 Suite 100 1799 Ottawa Ontario 1800 Canada 1801 Yong.li@bridgewatersystems.com 1803 Intellectual Property Statement 1805 The IETF takes no position regarding the validity or scope of any 1806 intellectual property or other rights that might be claimed to 1807 pertain to the implementation or use of the technology described in 1808 this document or the extent to which any license under such rights 1809 might or might not be available; neither does it represent that it 1810 has made any effort to identify any such rights. Information on the 1811 IETF's procedures with respect to rights in standards-track and 1812 standards-related documentation can be found in BCP-11. Copies of 1813 claims of rights made available for publication and any assurances 1814 of licenses to be made available, or the result of an attempt made 1815 to obtain a general license or permission for the use of such 1816 proprietary rights by implementers or users of this specification 1817 can be obtained from the IETF Secretariat. 1819 The IETF invites any interested party to bring to its attention any 1820 copyrights, patents or patent applications, or other proprietary 1821 rights which may cover technology that may be required to practice 1822 this standard. Please address the information to the IETF Executive 1823 Director. 1825 Full Copyright Statement 1827 Copyright (C) The Internet Society (2003). All Rights Reserved. 1828 This document and translations of it may be copied and furnished to 1829 others, and derivative works that comment on or otherwise explain it 1830 or assist in its implementation may be prepared, copied, published 1831 and distributed, in whole or in part, without restriction of any 1832 kind, provided that the above copyright notice and this paragraph 1833 are included on all such copies and derivative works. However, this 1834 document itself may not be modified in any way, such as by removing 1835 the copyright notice or references to the Internet Society or other 1836 Internet organizations, except as needed for the purpose of 1837 developing Internet standards in which case the procedures for 1839 RADIUS Extensions for PrePaid February 2004 1841 copyrights defined in the Internet Standards process must be 1842 followed, or as required to translate it into languages other than 1843 English. The limited permissions granted above are perpetual and 1844 will not be revoked by the Internet Society or its successors or 1845 assigns. This document and the information contained herein is 1846 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1847 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1848 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1849 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1850 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1852 Expiration Date 1854 This memo is filed as draft-lior-radius-extensions-for-prepaid- 1855 03.txt, and will expire 16th July, 2004.