idnits 2.17.00 (12 Aug 2021) /tmp/idnits59758/draft-lior-radius-prepaid-extensions-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2129. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 44), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 41 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 SAD MUST include the Message-Authenticator(80) attribute. The SAD will compute the value for the Message-Authenticator based on [RFC2869]. == 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: A PPAQ that contains a Service-Id is associated with that Service. A PPAQ that contains a Rating-Group-Id is associated with that Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a Service-Id. A PPAQ that contains neither a Rating-Group-Id or a Service-Id applies to the "Access Service". -- 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 25, 2004) is 6416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2284' is mentioned on line 616, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) -- Looks like a reference, but probably isn't: '3576' on line 1291 == Unused Reference: 'RFC2026' is defined on line 1874, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 1888, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 1896, but no explicit reference was found in the text == Unused Reference: 'REDIRECT' is defined on line 1905, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 7 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-06.txt Cisco 6 Expires: 24 March, 2005 K. Chowdhury 7 Nortel 8 Y. Li 9 Bridgewater Systems 10 C. Guenther 11 Siemens 12 October 25, 2004 14 PrePaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance 22 with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 24, 2005 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 This draft presents an extension to the Remote Authentication Dial- 49 In User Service (RADIUS) protocol to support charging for prepaid 50 services. The charging models supported are namely: volume-based 51 charging, duration-based charging and one-time-based charging. 53 Table of Contents 55 1. Introduction...................................................4 56 1.1 Terminology................................................6 57 1.2 Requirements language......................................6 58 2. Overview.......................................................6 59 2.1 PrePaid Charging Model.....................................7 60 2.2 Architectural Model........................................7 61 2.3 Why not existing RADIUS attributes?.......................13 62 3. Use-cases.....................................................15 63 3.1 Simple pre-paid access use-case...........................15 64 3.2 Support for Multi-Services................................17 65 3.3 Resource Pools............................................18 66 3.4 Support for Complex Rating Functions......................20 67 3.5 One-Time-based Prepaid Charging...........................21 68 3.6 Support for Roaming.......................................22 69 3.7 PrePaid termination.......................................23 70 3.8 Querying and Rebalancing Prepaid Resources................23 71 4. Operations....................................................24 72 4.1 General Requirements......................................24 73 4.1.1 Broker AAA Requirements..............................24 74 4.2 Authentication and Authorization for Prepaid Enabled SADs.24 75 4.3 Session Start Operation...................................26 76 4.4 Mid-Session Operation.....................................27 77 4.5 Dynamic Operations........................................29 78 4.5.1 Unsolicited Session Termination Operation............30 79 4.5.2 Unsolicited Change of Authorization Operation........30 80 4.6 Termination Operation.....................................31 81 4.7 Mobile IP Operations......................................31 82 4.8 Operation consideration for Multi-Services................32 83 4.8.1 Initial Quota Request................................33 84 4.8.2 Quota Update.........................................33 85 4.8.3 Termination..........................................34 86 4.8.4 Dynamic Operations...................................34 87 4.8.5 Support for Resource Pools...........................35 88 4.8.6 One-Time-Charging....................................35 89 4.8.7 Error Handling.......................................36 90 4.9 Accounting Considerations.................................36 91 4.10 SAD Operation............................................36 92 4.11 Interoperability with Diameter Credit Control Application36 93 5. Attributes....................................................37 94 5.1 PPAC Attribute............................................37 95 5.2 Session Termination Capability............................38 96 5.3 PPAQ Attribute............................................38 97 5.4 Table of Attributes.......................................44 98 6. Security Considerations.......................................44 99 6.1 Authentication and Authorization..........................45 100 6.2 Replenishing Procedure....................................45 101 7. IANA Considerations...........................................45 102 8. Normative References..........................................46 103 9. Informative References........................................46 104 10. Call Flows...................................................47 105 10.1 Simple Concurrent Services...............................48 106 10.2 One-time Charging........................................50 107 Contributor......................................................51 108 Acknowledgments..................................................51 109 Author's Addresses...............................................51 110 Intellectual Property Statement..................................52 111 Disclaimer of Validity...........................................52 112 Copyright Statement..............................................52 113 Expiration Date..................................................53 115 1. Introduction 117 This draft describes RADIUS protocol extensions supporting charging 118 for PrePaid Data Services. 120 PrePaid data services are cropping up in many wireless and wireline 121 based networks. A PrePaid Data Service subscriber is one that 122 purchases a contract to receive a data service for either a period 123 of time, or a quantity of data. Before providing a prepaid data 124 service, the service provider checks that the prepaid subscriber has 125 sufficient funds to cover the particular service request. Only after 126 confirmation that funds are available is the service provided to the 127 user. 129 The subscriber purchases the Data Service using various means such 130 as buying a PrePaid Card, or online. How the subscriber purchases 131 their PrePaid Data Service depends on the deployment and is not in 132 scope for this document. 134 In some deployments, the PrePaid data service will be combined with 135 other Prepaid services such as PrePaid circuit voice service. This 136 is not an issue for this document other than the fact that the 137 PrePaid Data Services described in this paper should work with other 138 PrePaid data and or circuit voice services. 140 The fundamental business driver for a carrier to provide PrePaid 141 data services is to increase participation (subscriber base) and 142 thus to increase revenues. Therefore, it makes sense that PrePaid 143 services meet the following goals: 145 - Leverage existing infrastructure, hence reducing capital 146 expenditures typically required when rolling out a new service; 147 - Ability to rate service requests in real-time; 148 - Ability to check that the end userÆs account for coverage for the 149 requested service charge prior to execution of that service; 150 - Protect against revenue loss, i.e., prevent an end user from 151 generating chargeable events when the credit of that account is 152 exhausted or expired; 153 - Protect against fraud; 154 - Be as widely deployable over Dialup, Wireless and WLAN networks. 156 The protocol described in this document maximizes existing 157 infrastructure as much as possible hence the use of the RADIUS 158 protocol. The protocol is used in ways to protect against revenue 159 loss or revenue leakage. This is achieved by defining procedures 160 for the real-time delivery of service information to a pre-paid 161 enabled AAA server, to minimize the financial risk, for the pre-paid 162 enabled AAA server to be able to allocate small quotas to each data 163 session and having the ability to update the quotas from a central 164 quota server dynamically during the lifetime of the PrePaid data 165 session. As well, mechanisms have been designed to be able to 166 recover from errors that occur from time to time. 168 Protection against fraud is provided by recording of accounting 169 records, and by providing mechanisms to thwart replay attacks. As 170 well, mechanisms have been provided to terminate data sessions when 171 fraud is detected. 173 PrePaid Systems will become more prevalent and sophisticated as the 174 various networks such as Dialup, Wireless and WLAN converge. This 175 protocol extension is designed to meet the challenges of converged 176 networks. The draft mainly addresses how to use the RADIUS protocol 177 to achieve a PrePaid Data Service. The prepaid architecture assumes 178 that rating of chargeable events does not occur in the element 179 providing the service. This rating could be performed in the prepaid 180 enabled AAA server or may exist in an entity behind this AAA server. 181 Business logic and service rules may define that tariffing of events 182 vary in time, e.g., the particular price per megabyte download may 183 be defined to switch at 8pm from a high tariff to a low tariff. The 184 RADIUS extensions for prepaid support scenarios enable scalable 185 implementation of tariff switched prepaid systems. 187 Furthermore, the prepaid architecture assumes that a quota server is 188 available which, through co-ordination with the rating entity and 189 centralized balance manager is able to provide a quota response in 190 response for prepaid data service. This quota server functionality 191 could be performed in the prepaid enabled AAA server or may exist in 192 an entity behind this AAA server. Finally, the details of the 193 PrePaid System, such as its persistent store, how it maintains its 194 accounts are not covered at all. However, in order to define the 195 RADIUS protocol extensions it is necessary to discuss the functional 196 behavior of the PrePaid System. 198 1.1 Terminology 200 Service Access Device 201 PrePaid Client(PPC) The Prepaid Client (PPC) is the entity which 202 triggers the RADIUS message exchange 203 including prepaid extensions defined in this 204 document. Typically the Prepaid Client 205 Resides in the NAS. 206 PrePaid Server(PPS) The Prepaid Server is the entity that 207 interacts with the Prepaid Client using the 208 RADIUS prepaid extensions defined in this 209 document. 210 Home network The network which contains the user profile 211 and the userÆs prepaid account. 212 WLAN Wireless Local Area Network 213 Service Event 214 Access Service The service that is provided to the user 215 when the user is authenticated and 216 authorized. In this document the term is 217 used to differentiate between authorization 218 of services that are explicitly identified 219 by a Service Identifier. Example of Access 220 Service would be the Main Service instance 221 of 3GPP2. 223 Furthermore, we use the following Mobile IP and AAA terminology: 224 Home agent (HA), Home network, Home AAA (HAAA), Broker AAA (BAAA), 225 Visited AAA (VAAA) and Foreign Agent (FA) 227 1.2 Requirements language 229 In this document, several words are used to signify the requirements 230 of the specification. These words are often capitalized. The key 231 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 233 this document are to be interpreted as described in [RFC2119]. 235 2. Overview 237 This section gives a concise overview of the Prepaid Charging models 238 that is supported by this document, and the Architectural model 239 relevant to this draft. 241 2.1 PrePaid Charging Model 243 There are several PrePaid Charging models of how to charge customers 244 for availing data services: 246 . Volume-based charging (VBC): (e.g., 2 Cents/KiloByte); 247 . Duration-based charging (DBC): (e.g., 3 Cents/minute); 248 . Subscription-based charging (SBC): (e.g., 249 Dollars/month+service);), 250 . Event-based charging (EBC): (e.g., 7 Cents/URL or email). 252 Charging models can be further divided into those with debiting of 253 prepaid user accounts and those with debiting of non-prepaid 254 accounts (such as current accounts at banks). From the perspective 255 of this document all userÆs as treated as userÆs having a prepaid 256 accounts. 258 2.2 Architectural Model 260 The architectural model supports prepaid clients on a service access 261 device. A SAD (e.g. a NAS) typically provides a access to data 262 service to end-users. A SAD is a network entity on the data path 263 that includes a RADIUS client and a PrePaid Client. 265 When prepaid service is used the SAD collects service event 266 information and reports it while and/or after services are provided 267 to the prepaid user. This event information is sent to a prepaid 268 server by using the prepaid RADIUS extensions. 270 If real-time credit control is required, the SAD (prepaid client) 271 contacts the prepaid server with service event information included 272 before the service is provided. The prepaid server, depending on the 273 service event information, performs credit check and allocates a 274 portion of available credit to the service event. The rating entity 275 converts this credit value into a time and/or volume amount, which 276 is then returned to the requesting SAD. The rating entity may 277 determine that during the allocated quota, a tariff switch will 278 occur in which case the rating entity will include details of the 279 quota allocated prior to the tariff switch, details of the quota 280 allocated after the tariff switch together with details of when the 281 tariff switch will occur. 283 The requesting SAD then monitors service execution according to the 284 instructions returned by the prepaid server. After service 285 completion or on a subsequent request for service, the prepaid 286 server deducts the reserved allocation of credit from the prepaid 287 userÆs account. 289 Similarly, when a user terminates an on-going prepaid service, the 290 prepaid client signals the prepaid server with the a value 291 corresponding to the unused portion of the allocated quota. The 292 prepaid server is then able to refund unused allocated funds into a 293 userÆs prepaid account. 295 There MAY be multiple prepaid servers in the system for reasons of 296 redundancy and load balancing. The system MAY also contain separate 297 rating server(s) and accounts MAY be located in a centralized 298 database. System internal interfaces can exist to relay messages 299 between servers and an account manager. However the detailed 300 architecture of prepaid system and its interfaces are implementation 301 specific and are out of scope of this specification. 303 accounting 304 +------------+ +-----------+ protocol +--------------+ 305 | Subscriber |<----->| Service | | | 306 | | | Access |<------------>| Accounting | 307 | Device | | Device |<-----+ | Server | 308 +------------+ +-----------+ | +--------------+ 309 | 310 | 311 | +--------------+ 312 +------>| PrePaid | 313 prepaid | Server | 314 protocol +--------------+ 316 Figure 1 Basic Prepaid Architecture 318 The prepaid server and accounting server in this architecture model 319 are logical entities. The real configuration MAY combine them into a 320 single host. 322 There MAY exist protocol transparent RADIUS Proxies between prepaid 323 client and prepaid server. These proxies transparently support the 324 prepaid RADIUS extensions. 326 In order to generalize the solution, in this paper we generalize the 327 SADs, which in reality may be a NAS in Dialup deployments, PDSN 328 (Packet Data Serving Node) or HA (Home Agent) in CDMA2000 329 deployments, an 802.11 WLAN Access Points or GGSN (Gateway GPRS 330 Serving Node) in GPRS/UMTS deployments. To actively participate in 331 Prepaid procedures outlined here, the SAD MUST have the Prepaid 332 Client capabilities. Prepaid Client Capabilities include the 333 ability to meter the usage for a prepaid data session; this usage 334 includes time or volume (e.g. number of bytes) usage. 336 In the case of roaming scenarios using mobile IP (in a wireless or 337 wireline network), the prepaid client functionality may be delegated 338 to the Home Agent. It may also be possible to deliver limited 339 prepaid services using RADIUS capabilities specified in RFC2865 and 340 RFC2866. 342 Furthermore, the device including the prepaid client functionality 343 may also have Dynamic Session Capabilities that include the ability 344 to terminate a data session and/or change the filters associated 345 with a specific data session by processing Disconnect Messages and 346 Change of Authorization messages as per [RFC3576]. 348 In this document RADIUS is used as the AAA server. There are three 349 kinds or categories of AAA servers. The AAA server in the home 350 network, the HAAA, is responsible for authentication of the 351 subscriber and also authorization of the service. In addition, the 352 HAAA communicates with the Prepaid servers using the RADIUS protocol 353 to authorize prepaid subscribers. In AAA based roaming deployments 354 the AAA server in the visited network, the VAAA, is responsible for 355 forwarding the RADIUS messages to the HAAA. The VAAA may also 356 modify the messages. In roaming deployments, the visited network 357 may be separated from the home network by one or more broker 358 networks. The AAA servers in the broker networks, BAAA are 359 responsible to route the RADIUS packets transparently and hence 360 donÆt play an active roll in the Prepaid Data Service delivery. 362 In this document the Prepaid Server is described in functional terms 363 related to their interface with the HAAA. The Prepaid Server 364 interfaces to entities which: 366 i) Keep the accounting state of the prepaid subscribers (balance 367 manager); 369 ii) Allow access service requests to be rated in real-time (Rating 370 Engine); and 371 iii) Allow quota to be managed for a particular pre-paid service 372 (Quota Server). 374 The various deployments for Prepaid are presented in the remainder 375 of this section. The first deployment is the basic Prepaid data 376 service and is depicted in figure 2. The SAD, which supports the 377 prepaid client functionality, the HAAA and the Prepaid Server are 378 collocated in the same provider network. 380 The Subscriber Device establishes a connection with one of several 381 Access Devices in the network. The SAD communicates with one or 382 more HAAA servers in the network. To provide redundancy more than 383 one HAAA may be available to use by a SAD. 385 The network will have one or more Prepaid Servers. Multiple Prepaid 386 Servers may be used to provide redundancy and load sharing. The 387 interface between the HAAA and the PPS is implemented using the 388 RADIUS protocol in this specification. However, in cases where the 389 PPS does not implement the RADIUS protocol, the implementation would 390 have to map the requirements defined in this document to whatever 391 protocol is used between the HAAA and the PPS. 393 +------+ +-----+ 394 | | | | 395 +--------+ +--------+ +--| HAAA |--+--| PPS | 396 | | | | | | | | | | 397 | Sub | | Service| | +------+ | +-----+ 398 | |---| Access |--+ | 399 | Device | | Device | | +------+ | +-----+ 400 | | | | | | | | | | 401 +--------+ +--------+ +--| HAAA |--+--| PPS | 402 | | | | 403 +------+ +-----+ 405 Figure 2 Basic Prepaid Access Architecture 407 Figure 3 shows a static roaming prepaid architecture that is typical 408 of a wholesale scenario for Dial-Up users or a broker scenario used 409 in Dial-Up or WLAN roaming scenarios. 411 +----+ +----+ +----+ +-----+ 412 | | | | | | | | 413 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 414 | | | | | | | | | | | | | | | | 415 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 416 | |--|Access |-+ | | | 417 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 418 | | | | | | | | | | | | | | | | 419 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 420 | | | | | | | | 421 +----+ +----+ +----+ +-----+ 423 | Visited | |Broker | | Home | 424 | Network | |Network| | Network | 426 Figure 3 Static Roaming Prepaid Architecture 428 As in the basic prepaid architecture the subscriberÆs device 429 establishes a connection with the SAD (NAS, WLAN Access Point). 430 The SAD communicates with the Visiting AAA server (VAAA) using the 431 RADIUS protocol. Again for redundancy there maybe more then one 432 VAAA. The VAAA communicate using the RADIUS protocol with AAA 433 servers in the broker network (BAAA). There maybe more then one 434 Broker Network between the Visited Network and the Home Network. 435 The Home Network is the same as in the simple architecture. 437 To support dynamic roaming the network will utilize Mobile-Ip as 438 illustrated in Figure 4. Note that typically the mobile device 439 would be moving between networks that use the same technology such 440 as Wireless or WLAN. Increasingly, device will be able to roam 441 between networks that use different technology such as between WLAN 442 and Wireless and Broadband. Fortunately, Mobile-Ip can address this 443 type of roaming and therefore we need not be concerned with the 444 underlying network technology. 446 +------+ +-------+ +----+ +----+ +----+ +-----+ 447 | | |Service| | | | | | | | | 448 |Sub | |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS | 449 | |--|Device | | | | | | | | | 450 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 451 | | | | | | 452 +------+ +------ + | | 453 | | | +----+ 454 | | | | | 455 |ROAMS +------------------+ HA | 456 | | | | 457 V +----+ | +----+ 458 +------+ +-------+ | | | | 459 | | |Service| +-|VAAA+------+ | 460 |Sub | |Access | | | | | 461 | |--|Device +-+ +----+ | 462 |Device| | (FA) | | 463 | | | +------------------------+ 464 +------+ +-------+ 466 Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs 468 In figure 4, the Subscriber device establishes a prepaid session 469 between the SAD in the foreign network, which has prepaid 470 capabilities. The subscriberÆs home address will be anchored at the 471 Home Agent (HA) in the home network. The setup for this access 472 service is identical to the cases covered above. Notice that the 473 SAD may be collocated with the Foreign Agent (FA) in case of Mobile- 474 IPv4. As the subscriber device moves it establishes a connection 475 with another SAD in the same foreign network or in another foreign 476 network. The prepaid data service should continue to be available. 477 When a device associates to another SAD it MUST re-authenticate at 478 the new SAD and de-associate or logoff from the old SAD. 479 Furthermore, any unused quota at the old SAD MUST be promptly 480 credited back to the subscribers account. The reason we say 481 promptly, is because if the subscriber is very low on resources to 482 start with, the subscriber may not have enough resources to log on 483 to the new SAD. The speed at which resources can be returned depend 484 on the type of handoff procedure that is used. Some of the example 485 of handoffs in wireless networks are dormant handoff, active handoff 486 and fast handoff. 488 As well, notice that if the SADs could communicate with each other 489 then there could be a way to accelerate a faster handoff procedure. 490 In particular, it could accelerate the return of the unused portion 491 of the quotas from the old Access Device. 493 Unfortunately, standards with regards to handoff are evolving with 494 each network technology creating their own scheme to make the 495 handoff procedures more efficient. 497 2.3 Why not existing RADIUS attributes? 499 It has been asked "Why not use existing RADIUS attributes to build a 500 prepaid solution? This will allow us to have a solution with 501 existing devices without code modification." 503 It is possible to build a prepaid solution using existing RADIUS 504 attributes. The RADIUS server can simply send an Access-Accept 505 message containing Session-Timeout(27) and set Termination- 506 Action(29) to RADIUS-request. Upon receiving the Access-Accept 507 message, the NAS will meter the duration of the session and upon 508 termination of the session the NAS generate an Access-Request 509 message again. The RADIUS server would re-authenticate the session 510 and reply with an Access-Accept message with additional time in 511 Session-Timeout(27) or an Access-Reject message if there were no 512 more resources in the userÆs account. 514 If the user terminates the session before the time expressed in 515 Session-Timeout(27). The NAS will recover any unused time from the 516 accounting stream. 518 There are several problems with such a solution: 520 -It only allows for time-based prepaid. The solution presented in 521 this document allows for both time and volume based prepaid. As 522 well as extensibility for other features such as tarified based 523 solutions. 525 -Using accounting messages to recoup unused time may be problematic 526 because RADIUS accounting messages are not real-time. A RADIUS 527 server may store-and-forward accounting messages in batches. The 528 solution presented in this paper does not rely on Accounting Packets 529 at all. It uses Access-Request, messages which do flow through any 530 network in real-time. Delaying accounting messages may cause 531 revenue leakage. 533 -Session-Timeout(27) is not a mandatory attribute. If a prepaid 534 subscriber is being serviced by a NAS that does not adhere to 535 Session-Timeout then that subscriber will obtain unlimited service. 537 -Termination-Action(29) presents its own issues. First the 538 behaviour of Termination-Action(29) is not mandatory. Second, 539 according to RFC2865 Termination-Action fires when the Service is 540 complete. But we should not be terminating the service while 541 negotiating additional quota. The refreshing of the time quota 542 should be transparent to the user. Because Termination-Action 543 occurs when the Service is complete it is unclear whether or not the 544 user experience would be transparent. For example, will the RADIUS 545 server allocate the subscriber a new IP address? Furthermore, the 546 RADIUS server has no way of telling why the Access-Request message 547 was generated. The RADIUS server will have to wait for the 548 corresponding accounting packet to determine the reason for this 549 Access-Request message. Lastly re-authenticating the subscriber may 550 take far too long. The solution presented in this document allows 551 quota replenishing to occur in an undisruptive manner from the 552 perspective of the user. No re-authentication is required and 553 quotas can be negotiated prior to the quotas running out. 555 -Prepaid ambiguity. Implementing prepaid using existing RADIUS 556 attributes presents another problem. Due to the fact that the 557 standard RADIUS attributes are not mandatory, then the correct 558 prepaid operation is really an act of faith on the part of the 559 RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) 560 are not supported, the prepaid subscriber will get free access. The 561 solution described in this document, requires that a prepaid capable 562 SAD inform the RADIUS server whether or not it supports prepaid 563 capabilities. The RADIUS server can now determine whether service 564 should be granted or not. For example, if a prepaid subscriber is 565 connected to a NAS that does not support prepaid, the RADIUS server 566 can either instruct the NAS to tunnel the traffic to another entity 567 in the home network that does support prepaid client function (e.g. 568 Home Agent) or it may allow the subscriber to get access but 569 restrict the traffic. 571 The prepaid solution we present is a robust carrier grade prepaid 572 solution. It only requires the support of 2 mandatory attributes 573 and one optional attribute. Furthermore, it does not really 574 require much code support at the NAS. NASes already support 575 measurement of time and volume. This solution requires that they 576 advertise their prepaid capabilities in an Access-Request; that they 577 generate an Access-Request Authorize-Only packet to obtain more 578 quota at or before the quota is used up. It also requires that the 579 NAS send an Access-Request with Authorize-Only when the session 580 terminates to return any unused quota to the prepaid system. 582 Lastly the solution provided in this document is extensible. This 583 document defines the basic exchanges between a prepaid capable NAS 584 and a RADIUS server. The protocol can easily be extended to support 585 tariff switching and other prepaid business models. 587 3. Use-cases 589 In this section we present a set of use cases that help establish 590 the requirements needed to deliver PrePaid data services. These 591 use-cases donÆt address how the PrePaid account is established or 592 maintained. It is assumed that the PrePaid subscriber has obtained 593 a valid account from a service provider such as a wireless operator 594 or a WLAN operator. 596 To make the document as general as possible, the use cases cover the 597 experience from the SAD and not from the UserÆs Device. The 598 connection between the UserÆs Device, which typically involves 599 setting up a layer 2 session, e.g., PPP session or GPRS PDP Context, 600 is specific to a given network technology and the details are not 601 required to deliver a PrePaid service. 603 3.1 Simple pre-paid access use-case 605 A PrePaid subscriber connects to his home network. As usual, the 606 Access Device that is servicing the subscriber will use the AAA 607 infrastructure to authenticate and authorize the subscriber. 609 The SAD sends a RADIUS Access-Request to the AAA system to 610 authenticate the subscriber, and identify and authorize the service. 611 The Access-Request includes the subscriberÆs credentials and may 612 include the PrePaid capabilities of the SAD. PrePaid capabilities 613 MUST be included if the SAD supports PrePaid functionality. 615 The AAA System proceeds with the authentication procedure. This may 616 involve several transactions such as in EAP [RFC2284]. Once the 617 subscriber has been authenticated, the AAA system determines that 618 the subscriber is a PrePaid subscriber and requests that the PrePaid 619 System authorize the PrePaid subscriber. The request MUST include 620 the PrePaid Capabilities of the serving SAD. 622 The PrePaid System will validate that the subscriber has a PrePaid 623 Account; it will validate that the account is active; and will 624 validate that the SAD has the appropriate PrePaid capabilities. If 625 all is in order, the PrePaid System will authorize the subscriber to 626 use the network. Otherwise it will reject the request. The 627 response is sent back to the AAA System. The response includes 628 attributes to indicate the allocation of a portion of the 629 subscriberÆs account called the initial quota (in units of time or 630 volume) and optionally a threshold value. 632 The reason we allocate a portion of the userÆs account is that the 633 user may be engaged in other Services that may draw on the same 634 Prepaid account. For example the user may be engaged in a data 635 session and a voice session. Although, these two services would 636 draw from the same account the involved separate parts of the 637 system. If the entire quota was allocated to the data session then 638 the user would have no more funds for a voice session. 640 The AAA system incorporates the PrePaid attributes received from the 641 PrePaid System into an Access-Accept message that it sends back to 642 the SAD. Note the AAA System is responsible for authorizing the 643 service whereas the PrePaid System is responsible for PrePaid 644 authorization. 646 Upon receiving the Access-Response, the SAD allows the PrePaid data 647 session to start and it starts to meter the session based on time or 648 volume, as indicated in the returned Quota 650 Once the usage for the session approaches the allotted quota (as 651 expressed by the threshold), the SAD will request an additional 652 quota. The re-authorization for additional quota flows through the 653 AAA system to the PrePaid System. The PrePaid System revalidates 654 the subscriberÆs account; it will subtract the previous quota 655 allocation from the userÆs account balance and if there is a balance 656 remaining it will reauthorize the request with an additional quota 657 allotment. Otherwise, the PrePaid System will reject the request. 658 Note the replenishing of the quotas is a re-authorization procedure 659 and does not involve re-authentication of the subscriber. 661 It is important to note that the PrePaid System is maintaining 662 session state for the subscriber. This state includes how much 663 account balance was allocated during the last quota allocation for a 664 particular session and how much is left in the account. Therefore, 665 it is required that all subsequent messages about the PrePaid 666 session reach the correct PrePaid System. 668 Upon receiving a re-allotment of the quota, the SAD will, continue 669 the data service session until the new threshold is reached. If the 670 request for additional quota cannot be fulfilled then the SAD will 671 let the subscriber use up the remaining quota and terminate the 672 session. 674 Alternatively, instead of terminating the session, the SAD may 675 restrict the data session such that the subscriber can only reach a 676 particular web server. This web server maybe used to allow the 677 subscriber to replenish their account. This restriction can also be 678 used to allow new subscribers to purchase their initial PrePaid 679 Service. 681 Should the subscriber terminate the session before the quota is used 682 up, the remaining balance allotted to the session must be credited 683 back to the subscriberÆs account. 685 As well, while the Access Device is waiting for the initial quota, 686 the subscriber may have dropped the session. The initial quota must 687 be credited back to the subscribers account. 689 3.2 Support for Multi-Services 691 Up to now we were looking at session that consisted of a single 692 service, "Access Service". An "Access Service" is the basic service 693 that is provided to the user by the SAD after successful 694 authentication and authorization. When we donÆt differentiate 695 between different types of services the "Access Service" aggregates 696 all the services that the user my be engaged in on a particular SAD. 698 For example, the user may be browsing the web, and participating in 699 a VoIP conversation, watching streaming video and downloading a 700 file. 702 Some operators may want to distinguish between these services. Some 703 services are billed at different rates and services maybe metered 704 differently. Therefore, the prepaid solution needs to be able to 705 distinguish services, and allocate quotas to the services using 706 different units (e.g. time, volume) and allow for those quotas to be 707 utilized at different rates. 709 +---------+ 710 | Session | 711 +---------+ 712 | 713 V N 714 +--------------+ +-------+ 715 | Service |------>| Quota | 716 | (service-Id) | +-------+ 717 +--------------+ 719 As shown in the above diagram, a Session can have N Services. Each 720 service is identified by a Service-Id. The format of the Service-Id 721 is not in the scope of this document but the Service-Id could be 722 expressed as an IP flow using the stand 5-tuple (Source-IP and Port, 723 the Destination-IP and Port, and the protocol type). Each service 724 is allocated an appropriate quota. 726 3.3 Resource Pools 728 When working with multiple services that results in multiple quota 729 allocation another problem arises. Even though quotas are portioned 730 out in fractional parts of the userÆs prepaid account, there could 731 be a situation where one Service utilizes its quota faster then 732 another Service. When the userÆs account is used up, there could be 733 a situation where one Service is unable to obtain additional quota 734 while another Service has plenty of quota remaining. Unless the 735 quotas can be rebalanced, the SAD would then have to terminate that 736 Service. As well, even before that happens, the existence of 737 several Services could generate an excessive amount of traffic as 738 the services update their quotas. 740 One method to solve these problems is to utilize resource pools. 741 Resource pools allow us to allocate resources to several services of 742 a session by allocating resources to a pool and have services draw 743 their quota from the pool at a rate appropriate to that service. 744 When the quota allocated to the pool runs out, we replenish the 745 pool. 747 +-----------+ 748 | Service-A |-----+ +--------+ 749 +-----------+ | Ma | | 750 +-------->| | 751 | Pool | 752 +-------->| (1) | 753 +-----------+ | Mb | | 754 | Service-B |-----+ +--------+ 755 +-----------+ 757 As the figure above shows, Service-A and Service-B are bound to 758 Pool(1). Ma and Mb are the pool multipliers (that are associated 759 with Service-A and Service-B respectively) that determines the rate 760 at which Service-A and Service-B draw from the pool. 762 The pool is initialized by taking the quota allocated to each 763 service and multiplying it by Mn. Therefore, the amount of 764 resources allocated to a pool is given by: 766 Poolr = Ma*Qa + Mb*Qb + . . . 768 A Pool is empty if: 770 Poolr <= Ca*Ma + Cb*Mb + . . . 772 where: 773 Ca,Cb are the consumed resources of Service-A and Service-B 774 respectively. 776 Note that the resources assigned to the pool are unit less. That 777 is, Service-A can be rated at $1 per Mbyte and Service-B can rated 778 at $0.10 per Minute. In this case if we allocate $5 worth of 779 resources on behalf of service-A to the pool we would set Ma = 10 780 and place 50 units into the pool. If we allocate $5 on behalf of 781 Service-B to the Pool, then M=1 and place 50 units into the Pool. 782 The pool would have a total sum of 100 units to be shared between 783 the two services. Each Mbyte used by Service-A will draw 10 units 784 from the pool and each minute used by Service-B will draw 1 unit 785 from the pool. 787 3.4 Support for Complex Rating Functions 789 The rate of use of a resource by a service can be very complex. 790 Some services use resources (e.g. time, volume) linearly. For 791 example, a service maybe consuming resources at a rate of $1 per 792 Mbyte. 794 In some cases an operator may wish to apply a much more complex 795 rating function. For example, a service provider may wish to rate a 796 service such that the first N Mbytes are free, then the next M 797 Mbytes are rated at $1 per Mbyte and volume above M bytes be rated 798 at $0.50 per Mbyte. This rating function could be achieved by 799 repeated message exchanges with the Prepaid System. 801 To avert the need to exchange many messages and to support even more 802 complex rating functions we support Rating Groups. A Rating Group 803 is provisioned at the SAD. As illustrated in the figure below, a 804 Rating Group is associated with one or more Services and defines the 805 rate that the services associated with the Rating Group consume the 806 quota. 808 +-----------+ 809 | Service-A |------+ 810 +-----------+ | +--------------+ +-------+ 811 +---->| | | Quota | 812 | Rating Group |------>| or | 813 +-----------+ +---->| | | Pool | 814 | Service-B |------+ +--------------+ +-------+ 815 +-----------+ 817 During authorization of the of a service, if the service is 818 associated with a Rating Group, the Prepaid Client sends the Rating 819 Group to the Prepaid Server. The prepaid service authorizes the 820 Rating Group by assigning it a Quota and optionally assigning it to 821 a Resource Pool. 823 When service that belongs to an authorized Rating Group is 824 instantiated, then the Prepaid Client does not need to authorize 825 that service. This could greatly reduce the amount of traffic 826 between the Prepaid Client and the Prepaid Server. 828 3.5 One-Time-based Prepaid Charging 830 One-Time-based Prepaid Charging is used for charging of Service 831 Events where there is no session. That is, the Service Event does 832 not have a start or an end. An example of a one-time service event 833 is the purchase of a ring-tone. The one-time event in this case is 834 the userÆs purchasing the right to use a ring-tone. The actual 835 downloading of the tone is a separate service event totally distinct 836 from the right to use the ring tone. For example, the user may have 837 already downloaded the tone and then after being totally satisfied 838 with the quality, decides to purchase the right to use the tone. 839 Subscription based services can also be modeled as a One-Time event. 840 In this case the one-time service event is the purchase of a 841 subscription to use a service for a month. While the user uses the 842 service his usage maybe metered especially if there are limits 843 associated with the service. 845 For a given user, One-time-based charging may occur in conjunction 846 with the other charging models. For example, the prepaid user maybe 847 accessing a website which is being metered based time or volume 848 while they purchase the right to use a ring tone (a one-time-based 849 event). Note: it is up to the service providers to decide whether 850 or not the user will be charged for the download of the tone and 851 also be charged for the time and volume required to download the 852 ring-tone. The facilities provided by this document gives the 853 service provider the capability to achieve their service charging 854 business goals. For example, should the service provider choose not 855 to charge for the download volume or time, then they can treat the 856 download IP flow as a separate service that is exempt from charging. 858 One-time-based charging occurs when the SAD sends an indication to 859 the PPS identifying the service, and the units that need to be 860 debited from the account. The units to be debited from the account 861 and how those units are rated (if they donÆt represent money) is not 862 in scope of this specification. 864 One-time-based charging may occur under two conditions: the SAD may 865 not have a authenticated context (or access to an authenticated 866 context for the subscriber); the SAD has access to authenticated 867 context for the subscriber. In the former case the SAD will have to 868 authenticate the subscriber. For example, the prepaid user maybe 869 authenticated by the SAD providing access service. However when the 870 user accesses the subscription server to purchase a subscription, 871 the subscription server may not have access to the authentication 872 context of the subscriber and thus will have to authenticate the 873 subscriber. Authentication of the subscriber and the generation of 874 the one-time charging event will happen at the same time. 876 Note that one-time-based charging can be used to credit the prepaid 877 userÆs account. For example, the SAD can return resources back to 878 the prepaid subscriber by making a one-time charge request that 879 includes the amount of resource to be credited back to the user. 881 3.6 Support for Roaming 883 For some networks it is essential that PrePaid Data Services be 884 offered to roaming subscribers. Support for static and dynamic 885 roaming models are needed. Static roaming is where the subscriber 886 logs onto a foreign network. The foreign network has a roaming 887 agreement directly with the home network or through a broker network 888 or networks. The subscriber remains logged into the network until 889 the subscriber changes location. When changing location a new 890 connection and a new login procedure is required. 892 Dynamic roaming allows to subscriber to move between networks while 893 maintaining a connection with the home network seamlessly. As the 894 subscriber moves between networks, the data session is handed off 895 between the networks. 897 In both roaming scenarios, the subscriber always authenticates with 898 the home network. PrePaid authorization and quota replenishing for 899 the session need to be received at the home network and more 900 specifically at the PrePaid System where state is being maintained. 902 Dynamic roaming is particularly challenging. A subscriber that 903 established a PrePaid Data Session may roam to another Access Device 904 that doesnÆt not support PrePaid functionality. The system should 905 be capable to continue the PrePaid session. 907 3.7 PrePaid termination 909 When fraud is detected by the PrePaid System, or when an error is 910 detected, it may be beneficial for the PrePaid system to terminate a 911 specific session for the subscriber or all the sessions of a 912 subscriber. 914 Some errors can occur such that the PrePaid System is in a state 915 where it is not sure whether the session is in progress or not. 916 Under conditions such as this, the PrePaid system may wish to 917 terminate the PrePaid data session to make sure that resources are 918 not being utilized for which it canÆt charge for reliably. 920 Some handoff procedure used during dynamic roaming may require that 921 the PrePaid system explicitly terminate the subscribers PrePaid data 922 session at an SAD. For example, if time based PrePaid service is 923 being used and the mobile subscriber performs a dormant handoff, the 924 PrePaid System needs to explicitly terminate the PrePaid session at 925 the old SAD. 927 3.8 Querying and Rebalancing Prepaid Resources 929 It should be possible to allow the Prepaid Server to Query the 930 current uses state of a prepaid balance at a SAD and adjust the 931 prepaid resources. 933 For example, a request to the PPS is made (e.g., a one-time charging 934 event) but the userÆs account is depleted but resources have been 935 allocated to the SAD. The PPS should have a the capability to query 936 the SAD and if it has the spare resources to reassign the quotas to 937 the SAD and to the pending request. Note that the PPS doesnÆt know 938 resource usage until the SAD request for more resources. This can 939 be a long time. 941 In the absence of this capability the PPS can minimize the occurance 942 of this scenario by allocated smaller quotas. But the result will 943 be many more transactions. The ability to query and to rebalance 944 resources provides a good trade-off. 946 4. Operations 948 4.1 General Requirements 950 4.1.1 Broker AAA Requirements 952 Broker AAA servers MUST support the Message-Authenticator(80) 953 attribute as defined in [RFC2869]. If BAAA servers are used, the 954 BAAA servers function is to forward the RADIUS packets as usual to 955 the appropriate RADIUS servers. 957 Accounting messages are not needed to deliver a PrePaid service. 958 However, accounting messages can be used to keep the PrePaid Server 959 current as to what is happening with the PrePaid data session. 960 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 961 pass through mode described in [RFC2866]. 963 4.2 Authentication and Authorization for Prepaid Enabled SADs 965 The SAD initiates the authentication and authorization procedure by 966 sending a RADIUS Access-Request to the HAAA. 968 If the SAD has PrePaid Client capabilities, it MUST include the 969 PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD) 970 attribute indicates to the PrePaid server the PrePaid capabilities 971 possessed by the SAD. These are required in order to complete the 972 PrePaid authorization procedures. 974 If the SAD supports the Disconnect-Message or the Change-of- 975 Authorization capabilities, then it SHOULD include the Dynamic- 976 Capabilities attribute. 978 In certain deployments, there may be other ways in which to 979 terminate a data session, or change authorization of an active 980 session. For example, some SADs provide a session termination 981 service via Telnet or SNMP. In these cases, the AAA server MAY add 982 the Dynamic-Capabilities message to the Access-Request. Upon 983 receiving the Change-of-Authorization message, the AAA server would 984 then be responsible for terminating the session using whatever means 985 that are supported by the device. 987 If the authentication procedure involves multiple Access-Requests 988 (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the 989 Dynamic-Capabilities attribute (if used) in at least the last 990 Access-Request of the authentication procedure. 992 The Access-Request will be sent as usual to the HAAA. The packet 993 may be proxied through zero or more BAAA. 995 Once the Access-Request arrives at the HAAA, the HAAA will 996 authenticate the subscriber. If the subscriber is cannot be 997 authenticated, the HAAA will send an Access-Reject message back to 998 the client. If the subscriber is authenticated, the HAAA will 999 determine whether or not the subscriber is a PrePaid subscriber. 1000 The techniques used to determine whether or not a subscriber is a 1001 PrePaid subscriber is beyond the scope of this document. If the 1002 subscriber is not a PrePaid subscriber, then the HAAA will respond 1003 as usual with an Access-Accept or Access-Reject message. If the 1004 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 1005 Access-Request to a PrePaid server for further authorization. 1007 The Access-Request will contain the PPAC(TBD) attribute, the 1008 Dynamic-Capabilities attribute if one was included; the User-Name(1) 1009 attribute MAY be set to a value that would represent the 1010 SubscriberÆs PrePaid Identity. This attribute is used by the 1011 PrePaid server to locate the PrePaid SubscriberÆs account. For 1012 added security, the HAAA MAY also set the User-Password(2) attribute 1013 to the password used between the HAAA and the PrePaid server. 1015 The PrePaid server lookups the subscriberÆs PrePaid account and will 1016 authorize the subscriber taking into consideration the SAD PrePaid 1017 Client Capabilities. 1019 Upon successful authorization, the PrePaid server will generate an 1020 Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD) 1021 attribute. 1023 The PPAC attribute returned to the client indicates the type of 1024 prepaid service to be provided for the session. The PPAQ(TBD) 1025 attribute includes: 1027 - The QUOTA-Id, which is set by the PrePaid server to a unique 1028 value that is used to correlate subsequent quota requests; 1030 - Volume and/or Time quotas, which are set to a value representing a 1031 portion of the subscribers account; 1033 - MAY contain a Time or Volume Threshold that controls when the SAD 1034 requests additional quota; 1036 - The IP address of the Serving PrePaid Server and one or more 1037 alternative PrePaid Servers. This is used by the HAAA to route 1038 subsequent quota replenishing messages to the appropriate PrePaid 1039 server(s). 1041 Note: Idle-Timeout(28) can be used to trigger the premature 1042 termination of a pre-paid service following subscriber inactivity. 1044 Depending on site policies, upon unsuccessful authorization, the 1045 PrePaid server will generate an Access-Reject to terminate the 1046 session immediately. Alternatively, the PrePaid server may generate 1047 an Access-Accept blocking some or all of the traffic and/or redirect 1048 some or all of the traffic to a location where the subscriber can 1049 replenish their account for a period of time. Blocking of traffic 1050 is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect 1051 I-d). Redirection is achieved by sending Redirect-Id or Redirect- 1052 Rule defined in the Redirect I-d. The period of time before the 1053 blocked/redirected session last can be specified by Session- 1054 Timeout(27) attribute. 1056 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 1057 will append the usual service attributes and forward the packet to 1058 the SAD. The HAAA SHOULD NOT overwrite any attributes already set 1059 by the PrePaid server. If the HAAA, receives an Access-Reject 1060 message, it will simply forward the packet to its client. Depending 1061 on site policies, if the HAAA fails to receive an Access-Accept or 1062 Access-Reject message from the PrePaid server it MAY do nothing or 1063 send an Access-Reject or an Access-Accept message back to its 1064 client. 1066 4.3 Session Start Operation 1068 The real start of the session is indicated by the arrival of 1069 Accounting-Request(Start) packet. The Accounting-Request (Start) 1070 MAY be routed to the PrePaid Server so that it can confirm the 1071 initial quota allocation. 1073 Note that the PrePaid Server role is not to record accounting 1074 messages and therefore it SHOULD not respond with an Accounting 1075 Response packet. 1077 If the Prepaid server does not receive the Accounting-Request(start) 1078 message it will only know that the session has started upon the 1079 first reception of a quota replenishment operation. 1081 If the Prepaid server does not receive indication directly (via 1082 Accounting-Request(start)) or indirectly, it SHOULD after some 1083 configurable time, deduce that the Session has not started. If the 1084 SAD supports termination capabilities, the PPS SHOULD send a 1085 Disconnect Message to the SAD to ensure that the session is indeed 1086 dead. 1088 4.4 Mid-Session Operation 1090 During the lifetime of a PrePaid data session the SAD will request 1091 to replenish the quotas using Authorize-Only Access-Request 1092 messages. 1094 Once the allocated quota has been reached or the threshold has been 1095 reached, the SAD MUST send an Access-Request with Service-Type(6) 1096 set to a value of "Authorize Only" and the PPAQ(TBD) attribute. 1098 The SAD MUST also include NAS identifiers, and Session identifier 1099 attributes in the Authorize Only Access-Request. The Session 1100 Identifier should be the same as those used during the Access- 1101 Request. For example, if the User-Name(1) attribute was used in the 1102 Access-Request it MUST be included in the Authorize Only Access- 1103 Request especially if the User-Name(1) attribute is used to route 1104 the Access-Request to the Home AAA server. 1106 The Authorize Only Access-Request MUST not include either User 1107 Password or Chap Password. In order to authenticate the message, 1108 the SAD MUST include the Message-Authenticator(80) attribute. The 1109 SAD will compute the value for the Message-Authenticator based on 1110 [RFC2869]. 1112 When the HAAA receives the Authorize-Only Access-Request that 1113 contains a PPAQ(TBD), it SHALL validate the message using the 1114 Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an 1115 Authorize Only Access-Request that contains a PPAQ(TBD) but not a 1116 Message-Authenticator(80) it SHALL silently discard the message. An 1117 Authorize Only Access-Request message that does not contain a 1118 PPAQ(TBD) is either in error or belongs to another application (for 1119 example, a Change of Authorization message [RFC3576]). In this case 1120 the Authorize Only Access-Request will either be silently discarded 1121 or handled by another application (not in scope of this document). 1123 Once the Authorize Only Access-Request message is validated, the 1124 HAAA SHALL forward the Authorize Only Access-Request to the 1125 appropriate PrePaid Server. The HAAA MUST forward the Authorize 1126 Only Access-Request to the PrePaid server specified in the 1127 PPAQ(TBD). The HAAA MUST sign the message using the Message- 1128 Authenticator(80) and the procedures in [RFC2869]. As with the 1129 Access-Request message, the HAAA MAY modify the User-Name(1) 1130 attribute to a value that represents the userÆs internal PrePaid 1131 account in the PrePaid server. Note the PrePaid server could use 1132 the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate 1133 the user account. 1135 Upon receiving the Authorize Only Access-Request containing a 1136 PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- 1137 Authenticator(80) as prescribed in [RFC2869]. If the message is 1138 invalid, the PrePaid server MUST silently discard the message. If 1139 it received an Authorize Only Access-Request message that does not 1140 contain a PPAQ(TBD) it MUST silently discard the message. 1142 The PrePaid server will lookup the PrePaid session by using the 1143 PrePaid Quota Id contained within the PPAQ(TBD). The PrePaid Server 1144 would, take the last allocated quota and subtract that from the 1145 UserÆs balance. If there is remaining balance, the PrePaid server 1146 re-authorizes the PrePaid session by allocate an additional quota. 1147 The PrePaid server may want to calculate a different threshold 1148 values as well. 1150 Upon successful re-authorization, the PrePaid server will generate 1151 an Access-Accept containing the PPAQ(TBD) attribute. The Access- 1152 Accept message MAY contain Service-Type(6) set to Authorize-Only and 1153 MAY contain the Message-Authenticator(80). 1155 Depending on site policies, upon unsuccessful authorization, the 1156 PrePaid server will generate an Access-Reject or an Access-Accept 1157 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 1158 and the Session-Timeout(27) attribute such that the PrePaid 1159 subscriber could get access to a restricted set of locations for a 1160 short duration to allow them to replenish their account, or create 1161 an account; or to browse free content. 1163 Upon receiving the Access-Accept from the PrePaid server, the HAAA 1164 SHALL return the packet to its client. If the HAAA, receives an 1165 Access-Reject message, it will forward the packet. Depending on 1166 site policies, if the HAAA fails to receive an Access-Accept or an 1167 Access-Reject message from the PrePaid server it MAY do nothing or 1168 it MAY send an Access-Reject message back to its client. 1170 Upon receiving an Access-Accept, the SAD SHALL update its quotas and 1171 threshold parameters with the values contained in the PPAQ(TBD) 1172 attribute. Note that the PrePaid server MAY update the 1173 PrePaidServer attribute(s) and these may have to be saved as well. 1175 Upon receiving an Access-Accept message containing either Filter- 1176 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 1177 The SAD SHALL restrict the subscriber session accordingly. 1179 4.5 Dynamic Operations 1181 The PrePaid server may want to take advantage of the dynamic 1182 capabilities that are supported by the SAD as advertised in the 1183 Dynamic-Capabilities attribute during the initial Access-Request. 1185 There are two types of actions that the PrePaid server can perform: 1186 it can request that the session be terminated; or it can request 1187 that attributes associated with the session be modified. More 1188 specifically, it can modify previously sent PPAQ(TBD) 1190 Both of these actions require that the session be uniquely 1191 identified at the SAD. As a minimum the PrePaid server: 1193 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 1194 -MUST provide at least one session identifier such as User-Name(1), 1195 Framed-IP-Address(), the Accounting-Session-Id(44). 1197 Other attributes could be used to uniquely identify a PrePaid data 1198 session. 1200 For a discussion on Dynamic Operations as they related Mutli-Service 1201 operations see further on. 1203 4.5.1 Unsolicited Session Termination Operation 1205 At anytime during a session the Prepaid Server may send a Disconnect 1206 Message to terminate a session. This capability is described in 1207 detail in [RFC3576]. The PrePaid server sends a Disconnect Message 1208 that MUST contain identifiers that uniquely identify the 1209 subscriberÆs data session and the SAD servicing that session. 1211 If the SAD receives a Disconnect-Message, it will respond with 1212 either a Disconnect-ACK packet if it was able to terminate the 1213 session or else it will respond with a Disconnect-NAK packet. 1215 Upon successful termination of a session the SAD MUST return any 1216 unused quota to the Prepaid Server by issuing an Authorize Only 1217 Access-Request containing the PPAQ which contains any unused Quota 1218 and the Update-Reason set to "Remote Forced Disconnect". 1220 4.5.2 Unsolicited Change of Authorization Operation 1222 At anytime during the prepaid session the Prepaid Client may receive 1223 a Change of Authorization (CoA) message. A Prepaid Server may send 1224 a new Quota to either add additional quota or to remove quota 1225 already allocated for the service. 1227 If the Change of Authorization contains a PPAQ then that PPAQ will 1228 override a previously received PPAQ. The PPAQ may contain more 1229 allocated Quota or less allocated quota. The PPS MUST NOT change 1230 the units used in the PPAQ. 1232 If the newly received PPAQ reduces the amount of allocated quota 1233 beyond what is currently used then the SAD will accept the new PPAQ 1234 and act as it normally would when the quota is used up. For 1235 example, if the threshold is reached then is request a quota update; 1236 if the quota received is less then the currently used level then the 1237 SAD would follow the normal procedures followed when a quota is used 1238 up. 1240 4.6 Termination Operation 1242 The termination phase is initiated when either: the Subscriber logs 1243 off; the quotas have been consumed, or when the SAD receives a 1244 Disconnect Message. 1246 In the case where the user logged off, or the SAD receives a 1247 Disconnect Message, the SAD will send an Authorize-Only Access- 1248 Request message with a PPAQ(TBD) and Update-Reason attribute set to 1249 either "Client Service termination" or "Remote Forced disconnect" 1250 and the currently used quota. 1252 In the case where the quota has been reached, if the PPAQ(TBD) 1253 contained Termination-Action field, the SAD will follow the 1254 specified action which would be to immediately terminate the 1255 service, to request more quota, or to Redirect/Filter the service. 1257 4.7 Mobile IP Operations 1259 In roaming scenarios using Mobile-IP, as the mobile subscriber roams 1260 between networks, or between different types of networks such as 1261 between WLAN and CDMA2000 networks, the PrePaid data session should 1262 be maintained transparently if the HA is acting as the SAD. 1264 As the subscriber device associates with the new SAD (AP or PDSN 1265 that supports prepaid client capability), the SAD sends a RADIUS 1266 Access-Request and the subscriber is re-authenticated and 1267 reauthorized. The SAD MUST include the PPAC(TBD) attribute in the 1268 RADIUS Access-Request. In this manner the procedure follows the 1269 Authentication and Authorization procedure described earlier. 1271 If the HA was acting as the SAD before handoff, the userÆs prepaid 1272 session does not undergo any change after the handoff because the 1273 Mobile IP session is anchored at the HA and the userÆs Home IP 1274 address remains the same. 1276 In the case of AP or PDSN acting as the SAD it is likely that the 1277 userÆs IP address will change (Care of Address). Therefore, the 1278 ongoing prepaid session will have some impact. In the case the SAD 1279 shall send an Access-Request. 1280 The Access-Request message is routed to the home network and MUST 1281 reach the PrePaid System that is serving the PrePaid session. The 1282 PrePaid system will then correlate the new authorization request 1283 with the existing active session and will assign a quota to the new 1284 request. Any outstanding quota at the old SAD MUST be returned to 1285 the PrePaid system. If the Mobile-IP nodes (HA and FA) supports 1286 registration revocation (Mobile IPv4 only). Specifically, the quota 1287 SHOULD be returned when the SAD sends the Authorize Only Access- 1288 Request with PPAQ(TBD) Update-Reason set to either "Remote Forced 1289 disconnect" or "Client Service termination". In order to trigger 1290 the sending of this last Authorize Only Access-Request, the PrePaid 1291 system may issue a Disconnect Message [3576] to the SAD. 1293 If the subscriber has roamed to an SAD that does not have any 1294 PrePaid Capabilities, PrePaid data service may still be possible by 1295 requesting the Home Agent (providing it has PrePaid Capabilities) to 1296 assume responsibilities for metering the service. The procedure for 1297 this scenario will be given in the next release of this draft. 1299 4.8 Operation consideration for Multi-Services 1301 This section describes the operation for supporting Prepaid for 1302 multi-services on the same SAD. The operations for multi-services 1303 are very similar to operations for single service. Message flows 1304 illustrating the various interactions are presented at the end of 1305 this document. 1307 A SAD that supports prepaid operations for multi-services SHOULD set 1308 the "Multi-Services Supported" bit in the PPAC. 1310 When working with multi-services, we need to differentiate between 1311 the services. A Service-Id attribute is used in the PPAQ(TBD) to 1312 uniquely differentiate between the services. The exact definition 1313 of the Service-Id attribute is out of scope for this document. 1315 A PPAQ that contains a Service-Id is associated with that Service. 1316 A PPAQ that contains a Rating-Group-Id is associated with that 1317 Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a 1318 Service-Id. A PPAQ that contains neither a Rating-Group-Id or a 1319 Service-Id applies to the "Access Service". 1321 4.8.1 Initial Quota Request 1323 When operations with multi-services is desired, the SAD will request 1324 the initial quota for the Service by sending a PPAQ containing the 1325 Service-Id for that Service in an Authorize-Only Access-Request 1326 packet. Similarly, if the SAD supports Rating-Groups then it may 1327 request a prepaid quota for the Rating-Group by sending a PPAQ 1328 containing the Rating-Group-Id. In both cases the Update-Reason 1329 will be set to "Initial-Request". 1331 The Authorize-Only Access-Request packet may contain more than one 1332 PPAQ. The Authorize-Only Access-Request MUST include one or more 1333 attributes that serve to identify the session so that it can be 1334 linked to the original authentication. Which Session Identifier(s) 1335 is included is up to specific deployments. The Authorize-Only 1336 message must contain the Message-Authenticator(80) attribute for 1337 integrity protection of the Authorize-Only Access-Request message. 1339 Upon receiving an Authorize-Only Access-Accept message containing 1340 one or more PPAQs the Prepaid System will allocate resources to each 1341 PPAQ. The resources, can be in units of time, volume as before. 1342 Each PPAQ will be assigned a unique QID that MUST appear in a 1343 subsequent PPAQ update for that service or rating-group. As well, 1344 the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if 1345 the PPAQ applies to the "Access Service". 1347 4.8.2 Quota Update 1349 Once the services start to utilize their allotted quota they will 1350 eventually need to replenish their quotas (either the threshold is 1351 reached or no more quota remains). To replenish the quota the 1352 Prepaid Client will send an Authorize-Only Access-Request message 1353 containing one or more PPAQs. Each PPAQ MUST contain the 1354 appropriate QID, Service-ID or Group-ID (or neither the Service-ID 1355 or Group-Id if the quota replenishment is for the "Access Service"). 1356 The Update-Reason filed will indicate either "Threshold reached"(3), 1357 or "Quota reached"(4). The Authorize-Only message must contain 1358 identifiers to identify the session. 1360 Upon receiving an Authorize-Only Access-Request packet with one or 1361 more PPAQs the Prepaid Server will respond with a new PPAQ for that 1362 service. The PPAQ will contain a new QID, the Service-Id or Rating- 1363 Group-Id, a new Quota. If the Prepaid Server does not want to grant 1364 additional quota to the Service it MUST include the Termination- 1365 Action subfield in the PPAQ that will instruct the SAD what to do 1366 with the service. 1368 4.8.3 Termination 1370 When an allotted quota for the service is used up the SAD shall act 1371 in accordance to the Termination-Action field set in the Quota. If 1372 the Termination-Action field is absent then the Service MUST be 1373 terminated. 1375 If the Service is to be terminated then the SAD shall send a PPAQ 1376 with the appropriate QID, the Service-Id, the used quota, and 1377 Update-Reason set to "Client Service Termination". 1379 If the "Access Service" has terminated, then all other services must 1380 be terminated as well. In this case the SAD must report on all 1381 issued quotas for the various services. The Update-Reason field 1382 should be set to "Access Service Terminated". 1384 Note when sending more then on PPAQ it may be required to send 1385 multiple Authorize Only Access-Requests. 1387 4.8.4 Dynamic Operations 1389 Dynamic operations for multi-services are similar to dynamic 1390 operations described for single service operations. The prepaid 1391 system may send a COA message containing a PPAQ for an existing 1392 service instance. The SAD will match the PPAQ to the service using 1393 the Service-ID attribute. The new quota could be higher then the 1394 last allocated value or it could be lower. The SAD must react to 1395 the new quota accordingly. 1397 A Disconnect message may not be send for a specific service. A 1398 disconnect message terminates the "Access Service". As such the SAD 1399 must report back all unused quotas by sending an Authorize Only 1400 Access Request message containing a PPAQ for each active service. 1401 The Update-Reason shall indicate that the reason for the update 1402 reason. 1404 4.8.5 Support for Resource Pools 1406 If the Prepaid Client supports pools as indicated by setting the 1407 "Pools supported" bit in the PPAC(TBD) then the Prepaid Server may 1408 associate a Quota with a Pool by including the Pool-Id and the Pool- 1409 Multiplier in the PPAQ(TBD). 1411 When Resource Pools are used, the PPAQ must not use the threshold 1412 field. 1414 4.8.6 One-Time-Charging 1416 To initiate a One-Time charge the PPC include the PPAQ attribute in 1417 an Access-Request packet. The Access Request packet MUST include 1418 the Message-Authenticator(80) and Event-Timestamp(55) attributes. 1420 The Service Id field of the PPAQ identifies the Service that is be 1421 charged for. The amount of to be charged is specified using the 1422 Resource Quota and Resource Quota overflow subtypes. If the value 1423 specified is negative then the resources will be credited to the 1424 userÆs account. 1426 The QID field MUST be set to a unique value and will be used by the 1427 PPS to detect duplicates should the packet be retransmitted. 1428 The Update Reason field MUST be set to One-Time Charging. 1430 Upon receiving a PPAQ configured as a One-Time charge, the RADIUS 1431 server authenticates the user and if authenticated, pass the PPAQ to 1432 the PPS. The PPS shall locate the subscriber account and debit or 1433 credit the account accordingly. The PPS MUST repond to the PPS with 1434 an Access-Accept message upon success. Or an Access-Reject message 1435 if it cant locate the userÆs account or if there is no balance 1436 remaining in the account. 1438 The RADIUS server shall respond back to the SAD with an Access 1439 Accept message. Since this is a one-time event charge the SAD must 1440 not allow the session to continue. Therefore, the RADIUS server 1441 should include in the Access-Accept a Session-Timeout set to 0. The 1442 Upon receiving an Access-Accept response the SAD shall generate an 1443 Accounting Stop message. 1445 A PPAQ used for One-Time charging may appear in an Authorize-Only 1446 Access Request. This is the case where a session already exists for 1447 the user. The PPS shall respond back with an Access-Accept to 1448 indicate that the userÆs account has been debited or an Access- 1449 Reject indicating that the account could not be debited. 1451 4.8.7 Error Handling 1453 If the Prepaid Server receives a PPAQ with an invalid QID it MUST 1454 ignore that PPAQ. 1456 If the Prepaid Server receives a PPAQ containing a Service-Id, or a 1457 Rating-Group-Id that it does not recognize, then it MUST ignore that 1458 PPAQ. 1460 If the Prepaid Client receives a PPAQ containing a Service-Id, or a 1461 Rating-Group-Id that it does not recognize, then it must ignore that 1462 PPAQ. 1464 If the Prepaid Client receives a PPAQ that contains a Pool-Id 1465 without a Pool-Multiplier; or a Pool-Multiplier without a Pool-Id it 1466 must ignore that PPAQ. 1468 4.9 Accounting Considerations 1470 Accounting messages are not required to deliver PrePaid Data 1471 Service. Accounting message will typically be generated for PrePaid 1472 Data Service. This because accounting message are used for auditing 1473 purposes as well as for bill generation. 1475 Accounting messages associated with PrePaid Data Sessions should 1476 include the PPAQ(TBD) attribute. 1478 4.10 SAD Operation 1480 To be completed 1482 4.11 Interoperability with Diameter Credit Control Application 1484 RADIUS PrePaid solutions need to interoperate with Diameter 1485 protocol. Two possibilities exist: The AAA infrastructure is 1486 Diameter based and the SAD are RADIUS based; or the SAD is Diameter 1487 based and the AAA infrastructure is RADIUS based. 1489 The Diameter Credit Control Application [DIAMETERCC] describes how 1490 to implement a PrePaid using an all Diameter based infrastructure. 1492 1494 5. Attributes 1496 This draft is using the RADIUS [RFC2865] namespace. 1498 5.1 PPAC Attribute 1500 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1501 Access-Request message by a Prepaid Capable NAS and is used to 1502 describe the PrePaid capabilities of the NAS. The PPAC is available 1503 to be sent in an Access-Accept message by the Prepaid server to 1504 indicate the type of prepaid metering that is to be applied to this 1505 session. 1507 0 1 2 3 1508 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 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | AvailableInClient (AiC) | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 TYPE : value of PPAC 1516 LENGTH: 8 1517 VALUE : String 1519 The value MUST be encoded as follows: 1521 Sub-Type (=1) : Sub-Type for AvailableInClient attribute 1522 Length : Length of AvailableInClient attribute 1523 (= 6 octets) 1524 AvailableInClient (AiC): 1526 The optional AvailableInClient Sub-Type, generated by the PrePaid 1527 client, indicates the PrePaid Accounting capabilities of the NAS and 1528 shall be bitmap encoded. The possible values are: 1530 0x00000001 Volume metering supported. 1531 0x00000002 Duration metering supported. 1532 0x00000004 Resource metering supported. 1533 0x00000008 Pools supported 1534 0x00000010 Rating groups supported 1535 0x00000020 Multi-Services supported. 1537 Others Reserved 1539 5.2 Session Termination Capability 1541 The value shall be bitmap encoded rather than a raw integer. This 1542 attribute shall be included RADIUS Access-Request message to the 1543 RADIUS server and indicates whether or not the NAS supports Dynamic 1544 Authorization. 1546 0 1 2 3 1547 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 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | TYPE | LENGTH | String | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Type : value of Session Termination Capability 1553 Length: = 4 1554 String encoded as follows: 1556 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1557 supported. 1559 5.3 PPAQ Attribute 1561 One or more PPAQ(TBD) attributes are available to be sent in an 1562 Access Request, Authorize Only Access-Request and Access-Accept 1563 messages. In an Access Request message, it is used to One-Time 1564 charging transactions; in Authorize Only Access-Request messages it 1565 is used to for One-Time charging, report usage and request further 1566 quota or request prepaid quota for a new service instance; in an 1567 Access-Accept message it is used to allocate the quotas (initial 1568 quota and subsequent quotas). 1570 When concurrent service are supported a PPAQ is associated with a 1571 specific service as indicated by the presence of Service-Id; or a 1572 Rating Group, as indicated by the presence of a Rating-Group-Id; or 1573 the "Access Service" as indicated by the absence of a Service-Id or 1574 a Rating-Group-Id. 1576 The attribute consists of a number of subtypes. Subtypes not used 1577 are omitted in the message. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | QuotaIdentifier (QID) | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | SUB-TYPE 2 | LENGTH | Volume Quota | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Volume Quota | SUB-TYPE 3 | LENGTH | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | VolumeThreshold (VT) | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | SUB-TYPE 6 | LENGTH | DurationQuota (DQ) | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | DurationThreshold (DT) | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | SUB-TYPE 9 | LENGTH | PrePaidServer | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | PrePaidServer | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Type : Value of PPAQ 1610 Length: variable, greater than 8 1611 String: The String value MUST be encoded as follows: 1613 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 1614 Length : Length of QuotaIDentifier attribute (= 6 octets) 1616 QuotaIDentifier (QID): 1618 The QuotaIDentifier Sub-Type is generated by the PrePaid server 1619 at allocation of a Volume and/or Duration Quota. The on-line 1620 quota update RADIUS Access-Request message sent from the SAD to 1621 the PPS shall include a previously received QuotaIDentifier. 1623 Sub-Type (=2): Sub-Type for VolumeQuota attribute 1624 Length : length of VolumeQuota attribute (= 6 octets) 1626 VolumeQuota (VQ): 1628 The optional VolumeQuota Sub-Type is only present if Volume Based 1629 charging is used. In RADIUS Access-Accept message (PPS to SAD 1630 direction), it indicates the Volume (in octets) allocated for the 1631 session by the PrePaid server. In RADIUS Authorize Only Access- 1632 Request message (SAD to PPS direction), it indicates the total 1633 used volume (in octets) for both forward and reverse traffic 1634 applicable to PrePaid accounting. 1636 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 1637 Length : length of VolumeQuotaOverflow attribute (= 4 octets) 1639 VolumeQuotaOverflow (VQO): 1641 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 1642 many times the VolumeQuota counter has wrapped around 2^32 over 1643 the course of the service being provided. 1645 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 1646 Length : length of VolumeThreshold attribute (= 6 octets) 1648 VolumeThreshold (VT): 1650 The VolumeThreshold Sub-Type shall always be present if 1651 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1652 SAD direction). It is generated by the PrePaid server and 1653 indicates the volume (in octets) that shall be used before 1654 requesting quota update. This threshold should not be larger than 1655 the VolumeQuota. 1657 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1658 Length : Length of VolumeThresholdOverflow attribute 1659 (= 4 octets) 1661 VolumeThresholdOverflow (VTO): 1663 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1664 how many times the VolumeThreshold counter has wrapped around 1665 2^32 over the course of the service being provided. 1667 Sub-Type (=6): Sub-Type for DurationQuota attribute 1668 Length : length of DurationQuota attribute (= 6 octets) 1670 DurationQuota (DQ): 1672 The optional DurationQuota Sub-Type is only present if Duration 1673 Based charging is used. In RADIUS Access-Accept message (PPS to 1674 SAD direction), it indicates the Duration (in seconds) allocated 1675 for the session by the PrePaid server. In on-line RADIUS Access- 1676 Accept message (PPC to PPS direction), it indicates the total 1677 Duration (in seconds) since the start of the accounting session 1678 related to the QuotaID. 1680 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1681 Length : length of DurationThreshold attribute (= 6 octets) 1683 DurationThreshold (DT): 1685 The DurationThreshold Sub-Type shall always be present if 1686 DurationQuota is present in a RADIUS Access-Accept message (PPS 1687 to SAD direction). It represents the duration (in seconds) that 1688 shall be used by the session before requesting quota update. This 1689 threshold should not be larger than the DurationQuota and shall 1690 always be sent with the DurationQuota. 1692 Sub-Type (=8): Sub-Type for Update-Reason attribute 1693 Length : length of Update-Reason attribute (= 4 octets) 1695 Update-Reason attribute (UR): 1697 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1698 Access-Request message (SAD to PPS direction). It indicates the 1699 reason for initiating the on-line quota update operation. Update 1700 reasons 4, 5, 6, 7 and 8 indicate that the associated resources 1701 are released at the client side, and therefore the PPS shall not 1702 allocate a new quota in the RADIUS Access_Accept message. 1704 1. Pre-initialization 1705 2. Initial Request 1706 3. Threshold Reached 1707 4. Quota Reached 1708 5. Remote Forced Disconnect 1709 6. Client Service Termination 1710 7. "Access Service" Terminated 1711 8. Service not established 1712 9. One-Time Charging 1714 Sub-Type (=9) : Sub-Type for PrePaidServer attribute 1715 Length : Length of PrePaidServer 1716 (IPv4 = 6 octets, IPv6= 18 octets 1718 PrePaidServer: 1720 The optional, multi-value PrePaidServer indicates the address of 1721 the serving PrePaid System. If present, the Home RADIUS server 1722 uses this address to route the message to the serving PrePaid 1723 Server. The attribute may be sent by the Home RADIUS server. If 1724 present in the incoming RADIUS Access-Accept message, the PDSN 1725 shall send this attribute back without modifying it in the 1726 subsequent RADIUS Access-Request message, except for the first 1727 one. If multiple values are present, the PDSN shall not change 1728 the order of the attributes. 1730 Sub-Type (=10) : Sub-Type for Service ID 1731 Length : Length of Service ID 1733 Service-Id: 1735 Opaque string that uniquely describes a service instance for which 1736 we want to apply prepaid metering to. A Service-Id could be an IP 1737 5-tuple (source address, source port, destination address, 1738 destination port, protocol). If Service-ID is present in the PPAQ 1739 the PPAQ applies to that Service. If a PPAQ does not contain a 1740 Service-Id then the PPAQ applies to the Access Service. 1742 Sub-Type (=11) : Sub-Type for Rating-Group-Id 1743 Length : 6 1745 Rating-Group-Id 1747 Identifies that this PPAQ is associated with resources allocated 1748 to a Rating Group with the corresponding ID. 1750 Sub-Type (=12) : Sub-Type for Termination-Action 1751 Length : 6 1753 This field is an enumeration of the action to take when the prepaid 1754 server does not grant additional quota. Valid actions are as 1755 follows: 1757 0 Reserved 1758 1 Terminate 1759 2 Request More Quota 1760 3 Redirect/Filter 1762 Sub-Type (=13) : Pool-Id 1763 Length : 6 1765 Identifies the Pool that this quota is to be associated with. 1767 Sub-Type (=14) : Pool-Multiplier 1768 Length : 6 1770 The pool-multiplier determines the weight that resources are 1771 inserted into the pool and the rate at which resources are taken out 1772 of the pool by this Service, or Rating-Group. 1774 Sub-Type (=13) : Sub-Type for Resource Quota 1775 Length : 6 1777 The optional ResourceQuota Sub-Type is only present if Resource 1778 Based charging is used or when One-Time charging is being used. 1779 In RADIUS Access-Accept message (PPS to SAD direction), it 1780 indicates the Resources allocated for the session by the PrePaid 1781 server. In RADIUS Authorize Only Access-Request message (SAD to 1782 PPS direction), it indicates the total used resource for both 1783 forward and reverse traffic applicable to PrePaid accounting. In 1784 one-time charging scenarios, the subtype represents the number of 1785 units to charge the user or to credit the user (negative values). 1787 Sub-Type (=14) : Sub-Type for Resource Quota Overflow 1788 Length : 6 1790 Sub-Type (=15) : Sub-Type for ResourceThreshold 1791 Length : 6 1793 NOTES: 1795 Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear in 1796 the attribute. 1797 Volume Threshold may only appear if Volume Quota appears 1799 A PPAQ MUST NOT CONTAIN both a Service-Id and a Rating-Group-Id. 1801 A PPAQ that does not contain a Service-ID or a Rating-Group-Id 1802 applies to the "Access Service". 1804 When the PPAQ contains a Pool-Id it MUST also contain the Pool- 1805 Multiplier. 1807 5.4 Table of Attributes 1809 TO BE COMPLETED. 1811 Request Accept Reject Challenge # Attribute 1813 Authorize_Only Request Accept Reject 1815 6. Security Considerations 1817 The protocol exchanges described are susceptible to the same 1818 vulnerabilities as RADIUS and it is recommended that IPsec be 1819 employed to afford better security. 1821 If IPsec is not available the protocol in this draft improves the 1822 security of RADIUS. The various security enhancements are explained 1823 in the following sections. 1825 6.1 Authentication and Authorization 1827 RADIUS is susceptible to replay attacks during the Authentication 1828 and Authorization procedures. A successful replay of the initial 1829 Access-Request could result in an allocation of an initial quota. 1831 To thwart such an attack... 1833 6.2 Replenishing Procedure 1835 A successful replay attacks of the Authorize Only Access-Request 1836 could deplete the subscribers prepaid account. 1838 To be completed. 1840 7. IANA Considerations 1842 This document requires the assignment of new Radius attributes type 1843 numbers for the following attributes: 1845 1) Prepaid-Accounting-Capability (PPAC) 1846 with subtype: 1847 AvailableInClient 1849 2) Prepaid-Accounting-Operation (PPAQ) 1850 with subtypes: 1851 QuotaID (QID) 1852 VolumeQuota (VQ) 1853 VolumeQuotaOverflow (VQO) 1854 VolumeTreshold (VT) 1855 VolumeTresholdOverflow (VTO) 1856 DurationQuota (DQ) 1857 DurationTreshold (DT) 1858 UpdateReason (UR) 1859 PrePaidServer (PPS) 1860 ServiceID (SID) 1861 RatingGroupId (RGID) 1862 TerminationAction (TA) 1863 PoolID (PID) 1864 PoolMultiplier (PM) 1865 Cost (COST) 1866 TariffChangeTime (TCT) 1868 3) Session-Termination-Capability (STC) 1870 4) International-Mobile-Subscriber-Identity (IMSI) 1872 8. Normative References 1874 [RFC2026] Bradner, S., "The Internet Standards Process -- 1875 Revision 3", RFC 2026, October 1996. 1876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1877 Requirement Levels", RFC 2119, March 1997. 1878 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1879 "Remote Authentication Dial In User Server 1880 (RADIUS)", RFC 2865, June 2000. 1882 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1883 2000. 1885 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1886 Extensions", RFC 2869, June 2000. 1888 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1889 Holdrege, M., Goyret, I., "RADIUS Attributes for 1890 Tunnel Protocol Support" , RFC 2868, June 2000. 1891 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1892 Aboba, B., "Dynamic Authorization Extensions to 1893 Remote Authentication Dial-In User Service 1894 (RADIUS)", RFC 3576, February 2003. 1896 [RFC3748] Aboba, B., et al., "Extensible Authentication 1897 Protocol", RFC 3748, June 2004. 1899 9. Informative References 1901 [DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control 1902 Application", Internet Draft, AAA WG, April 2004, 1903 Work in Progress. 1905 [REDIRECT] "RADIUS Redirection", Internet Draft, Work in 1906 progress. 1908 10. Call Flows 1910 This section includes call flows illustrating various scenarios 1911 enabled by this specification. 1912 The following are used in the call flows: 1914 RADIUS packets: 1916 AR Access Request 1917 ARA Access Accept 1918 AC Accounting Requests 1919 A Authorize-Only Access-Request 1920 AA Access-Accept for Authorize- 1921 Only Access-Request 1923 RADIUS Attributes: 1925 PPAQ PPAQ as defined in this 1926 specification 1927 SID One or more attributes 1928 representing the Session that 1929 the RADIUS packets is correlated 1930 to. 1931 PPAC PPAC as defined in this 1932 specification 1933 ASID Acct-Session-Id as defined by 1934 RADIUS 1935 MSID Acct-Multi-Session-Id as define 1936 by RADIUS 1938 PPAQ fields: 1940 SRVID Service-Id 1941 Reason Update-Reason 1942 QID Quota-Id 1944 10.1 Simple Concurrent Services 1946 In this scenario the Prepaid Client authenticates and authorizes the 1947 user. The Prepaid Server responds back with Prepaid Quota for the 1948 "Access Service" instance. The NAS then request quota for Service- 1949 A. 1951 Accounting is turned on. 1953 NAS/ RADIUS/ 1954 PPC PPS 1955 === === 1956 | | 1957 | AR{SID,PPAC} | 1958 A |-------------------------------------------------->| 1959 | | 1960 | ARA{SID,PPAQ(QID=1,Q=100)} | 1961 B |<--------------------------------------------------| 1962 | | 1963 | AC(start){ASID=25,MSID=13} | 1964 C |-------------------------------------------------->| 1965 | | 1966 | A{SID,PPAQ(SRVID=SA, Reason=Initial} | 1967 D |-------------------------------------------------->| 1968 | | 1969 | AA{SID,PPAQ(QID=200,SRVID=SA, Q=50)} | 1970 E |<--------------------------------------------------| 1971 | | 1972 | AC(start){ASID=30,MSID=13, PPAQ } | 1973 F |-------------------------------------------------->| 1974 | | 1975 | A{SID, PPAQ(QID=200 SRVID=SA, Q=50 Reason=Quota)}| 1976 G |-------------------------------------------------->| 1977 | | 1978 | AA{SID,PPAQ(QID=300,SRVID=SA, Q=100)} | 1979 H |<--------------------------------------------------| 1980 | | 1981 | A{SID, | 1982 | PPAQ(QID=1, Q=100 Reason=Quota), | 1983 | PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} | 1984 I |-------------------------------------------------->| 1985 | | 1986 | AA{SID, 1987 | PPAQ(QID=3, Q=200), | 1988 | PPAQ(QID=303, SRVID=SA Q=150)} | 1989 J |<--------------------------------------------------| 1991 A This is the initial Access-Request that indicates the Prepaid 1992 Capabilities of the NAS. In this scenario it will indicate 1993 that Concurrent Session are supported. Access-Request also 1994 includes SID (Session Id) which is the Session Identifier 1995 assigned by this NAS to session. Session Identifier is out of 1996 scope in this document. It can be a single attribute such as 1997 3GPP2 Correlation ID or it could be a set of attributes that 1998 define a session. 1999 B RADIUS authenticates the user and determines that the user is 2000 prepaid. RADIUS responds with a PPAQ for the "Access Service" 2001 (PPAQ does not contain a Service-ID or Rating-Group-ID). The 2002 PPAQ has a QID=1 assigned by the Prepaid System and Quota of 2003 Q=100. The quota could be time or volume and may or may not 2004 have a threshold associated with it. 2005 C NAS starts the Access Service and generates an Accounting- 2006 Request (Start) message as normal. It will include the Acct- 2007 Session-Id and may include the Acct-Multi-Session-Id. 2008 D The NAS wants to start a new Service, call it Service-A. It 2009 sends an Authorize-Only access request to RADIUS. The SID 2010 links this Authorize-Only access request to the initial 2011 Authentication & Authorization (Step-A and Step-B).The 2012 Authorize-Only message contains a PPAQ requesting quota for 2013 Service-A, Update-Reason = Initial-Request. 2014 E PPS checks the resources available to the user and assigns 50 2015 units (time/volume etc) to this service. RADIUS sends an 2016 Access Accept message contain a PPAQ assigning quota Q=50 for 2017 Service-A. The PPAQ contains a QID = 200. 2018 F NAS starts Service-A and sends an Accounting-Request (Start) 2019 message for that service. Acct-Multi-Session-Id can be used 2020 to tie all of the sessions in the accounting streams together. 2021 G Quota for Service-A requires refreshing, the quota was 2022 completely used). An Authorize-Only message is sent 2023 containing a PPAQ with QID = 200 which corresponds to the 2024 prior QID received for this service. Note QID is sufficient 2025 for the PPS server to link this request to the previous 2026 request and hence to the original authentication steps. 2027 Therefore SID is not really required. The PPAQ will report the 2028 used part of the quota (50 units). 2029 H RADIUS deducts the used quota from the users accounts and 2030 reserves 50 more additional units for a total quota of 100 2031 (Q=100) for Service-A. It sends back a PPAQ with QID=300. 2032 I NAS needs to refresh both the "Access Service" and Service-A. 2033 It sends an Authorize Only message contain two PPAQs, one for 2034 the Main Service with QID=1 and one for Service-A with 2035 QID=300. Each PPAQ reports the used resources so far and the 2036 reason why the update is being sent. 2037 J RADIUS responds back with two PPAQs. The PPAQ without the 2038 Service-Id grants an additional 100 units for a total of 200 2039 units to the "Access Service" QID=3; the other PPAQ, 2040 containing SRVID=SA grants an additional 50 units for a total 2041 quota to service-a of 150 units QID=303. 2043 This step illustrates why SRVID needs to be specified in the 2044 PPAQ. If it were not, then the NAS would not be able to 2045 differentiate between the PPAQs. QIDs are not sufficient to 2046 correlate the PPAQ to a service since they are changed (and 2047 not necessarily sequentially) by the PPS at every transaction. 2049 In this scenario, notice how each PPAQ attribute represents a 2050 sequential conversation about a service between the Prepaid Client 2051 and the Prepaid Server. The links between the messages are the QIDs 2052 and the Service-Ids. 2054 As well, notice how a SID is needed to tie the Authorize-Only 2055 messages to the Authentication steps. This SID is only really 2056 needed the first time a PPAQ is sent since the PPAQ does not have 2057 a QID. 2059 Accounting messages have an Accounting-Session-ID. But that is not 2060 enough to allow the back end system to associate that accounting 2061 message with a particular Service. We therefore need the PPAQ in 2062 the accounting message. 2064 10.2 One-time Charging 2066 In this One-time charging scenario, the Prepaid Client (PPC) 2067 authenticates and authorizes the user and requests charging for a 2068 service event requested by the user. The PPC already knows the 2069 price to charge for the service event identified by SRVID=SA. 2071 Contributor 2073 We would like to thank Hannes Tschofenig for his contributions to 2074 this draft. 2076 Acknowledgments 2078 The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala 2079 and Tseno Tsenov for their contribution to this draft. 2081 Author's Addresses 2083 Avi Lior Parviz Yegani, Ph.D. 2084 Bridgewater Systems Mobile Wireless Group 2085 303 Terry Fox Drive Cisco Systems 2086 Suite 100 3625 Cisco Way 2087 Ottawa Ontario San Jose, CA 95134 2088 Canada USA 2089 avi@bridgewatersystems.com pyegani@cisco.com 2091 Kuntal Chowdhury Yong Li 2092 Nortel Networks Bridgewater Systems 2093 2221, Lakeside Blvd, 303 Terry Fox Drive 2094 Richardson, TX-75082 Suite 100 2095 chowdury@nortelnetworks.com Ottawa Ontario 2096 Canada 2097 Yong.li@bridgewatersystems.com 2099 Christian Guenther 2100 Siemens 2101 Otto-Hahn-Ring 6 2102 82739 Munich 2103 Germany 2104 Christian.guenther@siemens.com 2106 Intellectual Property Statement 2108 The IETF takes no position regarding the validity or scope of any 2109 Intellectual Property Rights or other rights that might be claimed 2110 to pertain to the implementation or use of the technology described 2111 in this document or the extent to which any license under such 2112 rights might or might not be available; nor does it represent that 2113 it has made any independent effort to identify any such rights. 2114 Information on the IETF's procedures with respect to rights in IETF 2115 Documents can be found in BCP 78 and BCP 79. 2117 Copies of IPR disclosures made to the IETF Secretariat and any 2118 assurances of licenses to be made available, or the result of an 2119 attempt made to obtain a general license or permission for the use 2120 of such proprietary rights by implementers or users of this 2121 specification can be obtained from the IETF on-line IPR repository 2122 at http://www.ietf.org/ipr. 2124 The IETF invites any interested party to bring to its attention any 2125 copyrights, patents or patent applications, or other proprietary 2126 rights that may cover technology that may be required to implement 2127 this standard. Please address the information to the IETF at ietf- 2128 ipr@ietf.org. 2129 Disclaimer of Validity 2131 This document and the information contained herein are provided on 2132 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2133 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2134 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2135 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2136 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2137 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2139 Copyright Statement 2141 Copyright ¨ The Internet Society (2004). This document is subject to 2142 the rights, licenses and restrictions contained in BCP 78, and 2143 except as set forth therein, the authors retain all their rights. 2145 Expiration Date 2147 This memo is filed as draft-lior-radius-extensions-for-prepaid- 2148 06.txt, and will expire 24 March, 2005.