idnits 2.17.00 (12 Aug 2021) /tmp/idnits3569/draft-lior-radius-prepaid-extensions-07.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 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2379. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 43), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 77 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 (February 20, 2005) is 6298 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2284' is mentioned on line 626, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) -- Looks like a reference, but probably isn't: '3576' on line 1395 == Unused Reference: 'RFC2026' is defined on line 2121, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 2135, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 2143, but no explicit reference was found in the text == Unused Reference: 'REDIRECT' is defined on line 2153, 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 (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Lior 2 INTERNET-DRAFT Bridgewater Systems 3 Category: Informational P. Yegani 4 draft-lior-radius-prepaid-extensions-07.txt Cisco 5 Expires: 20 July, 2005 K. Chowdhury 6 Starent Networks 7 Y. Li 8 Bridgewater Systems 9 C. Guenther 10 Siemens 11 February 20, 2005 13 PrePaid Extensions to Remote Authentication Dial-In User Service 14 (RADIUS) 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance 21 with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 20, 2005 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This draft presents an extension to the Remote Authentication Dial- 48 In User Service (RADIUS) protocol to support charging for prepaid 49 services. The charging models supported are namely: volume-based 50 charging, duration-based charging and one-time-based charging. 52 Table of Contents 54 1. Introduction...................................................4 55 1.1 Terminology................................................6 56 1.2 Requirements language......................................6 57 2. Overview.......................................................6 58 2.1 PrePaid Charging Model.....................................7 59 2.2 Architectural Model........................................7 60 2.3 Why not existing RADIUS attributes?.......................13 61 3. Use-cases.....................................................15 62 3.1 Simple pre-paid access use-case...........................15 63 3.2 Support for Multi-Services................................17 64 3.3 Resource Pools............................................18 65 3.4 Support for Complex Rating Functions......................20 66 3.5 One-Time-based Prepaid Charging...........................21 67 3.6 Support for Tariff Switching..............................22 68 3.7 Support for Roaming.......................................24 69 3.8 PrePaid termination.......................................24 70 3.9 Querying and Rebalancing Prepaid Resources................25 71 4. Operations....................................................25 72 4.1 General Requirements......................................25 73 4.1.1 Broker AAA Requirements..............................25 74 4.2 Authentication and Authorization for Prepaid Enabled SADs.26 75 4.3 Session Start Operation...................................28 76 4.4 Mid-Session Operation.....................................29 77 4.5 Dynamic Operations........................................31 78 4.5.1 Unsolicited Session Termination Operation............31 79 4.5.2 Unsolicited Change of Authorization Operation........32 80 4.6 Termination Operation.....................................32 81 4.7 Mobile IP Operations......................................33 82 4.8 Operation consideration for Multi-Services................34 83 4.8.1 Initial Quota Request................................34 84 4.8.2 Quota Update.........................................35 85 4.8.3 Termination..........................................35 86 4.8.4 Dynamic Operations...................................36 87 4.8.5 Support for Resource Pools...........................36 88 4.8.6 One-Time-Charging....................................36 89 4.8.7 Error Handling.......................................37 90 4.9 Accounting Considerations.................................38 91 4.10 SAD Operation............................................38 92 4.11 Interoperability with Diameter Credit Control Application38 93 5. Attributes....................................................38 94 5.1 PPAC Attribute............................................39 95 5.2 Session Termination Capability............................40 96 5.3 PPAQ Attribute............................................40 97 5.4 Prepaid Tariff Switching (PTS)............................46 98 5.5 Table of Attributes.......................................49 99 6. Security Considerations.......................................49 100 6.1 Authentication and Authorization..........................49 101 6.2 Replenishing Procedure....................................50 102 7. IANA Considerations...........................................50 103 8. Normative References..........................................51 104 9. Informative References........................................51 105 10. Call Flows...................................................52 106 10.1 Simple Concurrent Services...............................53 107 10.2 One-time Charging........................................55 108 Contributor......................................................56 109 Acknowledgments..................................................56 110 Author's Addresses...............................................56 111 Intellectual Property Statement..................................57 112 Disclaimer of Validity...........................................57 113 Copyright Statement..............................................57 114 Expiration Date..................................................58 116 1. 117 Introduction 119 This draft describes RADIUS protocol extensions supporting charging 120 for PrePaid Data Services. 122 PrePaid data services are cropping up in many wireless and wireline 123 based networks. A PrePaid Data Service subscriber is one that 124 purchases a contract to receive a data service for either a period 125 of time, or a quantity of data. Before providing a prepaid data 126 service, the service provider checks that the prepaid subscriber has 127 sufficient funds to cover the particular service request. Only after 128 confirmation that funds are available is the service provided to the 129 user. 131 The subscriber purchases the Data Service using various means such 132 as buying a PrePaid Card, or online. How the subscriber purchases 133 their PrePaid Data Service depends on the deployment and is not in 134 scope for this document. 136 In some deployments, the PrePaid data service will be combined with 137 other Prepaid services such as PrePaid circuit voice service. This 138 is not an issue for this document other than the fact that the 139 PrePaid Data Services described in this paper should work with other 140 PrePaid data and or circuit voice services. 142 The fundamental business driver for a carrier to provide PrePaid 143 data services is to increase participation (subscriber base) and 144 thus to increase revenues. Therefore, it makes sense that PrePaid 145 services meet the following goals: 147 - Leverage existing infrastructure, hence reducing capital 148 expenditures typically required when rolling out a new service; 149 - Ability to rate service requests in real-time; 150 - Ability to check that the end userÆs account for coverage for the 151 requested service charge prior to execution of that service; 152 - Protect against revenue loss, i.e., prevent an end user from 153 generating chargeable events when the credit of that account is 154 exhausted or expired; 155 - Protect against fraud; 156 - Be as widely deployable over Dialup, Wireless and WLAN networks. 158 The protocol described in this document maximizes existing 159 infrastructure as much as possible û hence the use of the RADIUS 160 protocol. The protocol is used in ways to protect against revenue 161 loss or revenue leakage. This is achieved by defining procedures 162 for the real-time delivery of service information to a pre-paid 163 enabled AAA server, to minimize the financial risk, for the pre-paid 164 enabled AAA server to be able to allocate small quotas to each data 165 session and having the ability to update the quotas from a central 166 quota server dynamically during the lifetime of the PrePaid data 167 session. As well, mechanisms have been designed to be able to 168 recover from errors that occur from time to time. 170 Protection against fraud is provided by recording of accounting 171 records, and by providing mechanisms to thwart replay attacks. As 172 well, mechanisms have been provided to terminate data sessions when 173 fraud is detected. 175 PrePaid Systems will become more prevalent and sophisticated as the 176 various networks such as Dialup, Wireless and WLAN converge. This 177 protocol extension is designed to meet the challenges of converged 178 networks. The draft mainly addresses how to use the RADIUS protocol 179 to achieve a PrePaid Data Service. The prepaid architecture assumes 180 that rating of chargeable events does not occur in the element 181 providing the service. This rating could be performed in the prepaid 182 enabled AAA server or may exist in an entity behind this AAA server. 183 Business logic and service rules may define that tariffing of events 184 vary in time, e.g., the particular price per megabyte download may 185 be defined to switch at 8pm from a high tariff to a low tariff. The 186 RADIUS extensions for prepaid support scenarios enable scalable 187 implementation of tariff switched prepaid systems. 189 Furthermore, the prepaid architecture assumes that a quota server is 190 available which, through co-ordination with the rating entity and 191 centralized balance manager is able to provide a quota response in 192 response for prepaid data service. This quota server functionality 193 could be performed in the prepaid enabled AAA server or may exist in 194 an entity behind this AAA server. Finally, the details of the 195 PrePaid System, such as its persistent store, how it maintains its 196 accounts are not covered at all. However, in order to define the 197 RADIUS protocol extensions it is necessary to discuss the functional 198 behavior of the PrePaid System. 200 1.1 201 Terminology 203 Service Access Device 204 PrePaid Client(PPC) The Prepaid Client (PPC) is the entity which 205 triggers the RADIUS message exchange 206 including prepaid extensions defined in this 207 document. Typically the Prepaid Client 208 Resides in the NAS. 209 PrePaid Server(PPS) The Prepaid Server is the entity that 210 interacts with the Prepaid Client using the 211 RADIUS prepaid extensions defined in this 212 document. 213 Home network The network which contains the user profile 214 and the userÆs prepaid account. 215 WLAN Wireless Local Area Network 216 Service Event 217 Access Service The service that is provided to the user 218 when the user is authenticated and 219 authorized. In this document the term is 220 used to differentiate between authorization 221 of services that are explicitly identified 222 by a Service Identifier. Example of Access 223 Service would be the Main Service instance 224 of 3GPP2. 226 Furthermore, we use the following Mobile IP and AAA terminology: 227 Home agent (HA), Home network, Home AAA (HAAA), Broker AAA (BAAA), 228 Visited AAA (VAAA) and Foreign Agent (FA) 230 1.2 231 Requirements language 233 In this document, several words are used to signify the requirements 234 of the specification. These words are often capitalized. The key 235 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 237 this document are to be interpreted as described in [RFC2119]. 239 2. 240 Overview 242 This section gives a concise overview of the Prepaid Charging models 243 that is supported by this document, and the Architectural model 244 relevant to this draft. 246 2.1 247 PrePaid Charging Model 249 There are several PrePaid Charging models of how to charge customers 250 for availing data services: 252 . Volume-based charging (VBC): (e.g., 2 Cents/KiloByte); 253 . Duration-based charging (DBC): (e.g., 3 Cents/minute); 254 . Subscription-based charging (SBC): (e.g., 255 Dollars/month+service);), 256 . Event-based charging (EBC): (e.g., 7 Cents/URL or email). 258 Charging models can be further divided into those with debiting of 259 prepaid user accounts and those with debiting of non-prepaid 260 accounts (such as current accounts at banks). From the perspective 261 of this document all userÆs as treated as userÆs having a prepaid 262 accounts. 264 2.2 265 Architectural Model 267 The architectural model supports prepaid clients on a service access 268 device. A SAD (e.g. a NAS) typically provides a access to data 269 service to end-users. A SAD is a network entity on the data path 270 that includes a RADIUS client and a PrePaid Client. 272 When prepaid service is used the SAD collects service event 273 information and reports it while and/or after services are provided 274 to the prepaid user. This event information is sent to a prepaid 275 server by using the prepaid RADIUS extensions. 277 If real-time credit control is required, the SAD (prepaid client) 278 contacts the prepaid server with service event information included 279 before the service is provided. The prepaid server, depending on the 280 service event information, performs credit check and allocates a 281 portion of available credit to the service event. The rating entity 282 converts this credit value into a time and/or volume amount, which 283 is then returned to the requesting SAD. The rating entity may 284 determine that during the allocated quota, a tariff switch will 285 occur in which case the rating entity will include details of the 286 quota allocated prior to the tariff switch, details of the quota 287 allocated after the tariff switch together with details of when the 288 tariff switch will occur. 290 The requesting SAD then monitors service execution according to the 291 instructions returned by the prepaid server. After service 292 completion or on a subsequent request for service, the prepaid 293 server deducts the reserved allocation of credit from the prepaid 294 userÆs account. 296 Similarly, when a user terminates an on-going prepaid service, the 297 prepaid client signals the prepaid server with the a value 298 corresponding to the unused portion of the allocated quota. The 299 prepaid server is then able to refund unused allocated funds into a 300 userÆs prepaid account. 302 There MAY be multiple prepaid servers in the system for reasons of 303 redundancy and load balancing. The system MAY also contain separate 304 rating server(s) and accounts MAY be located in a centralized 305 database. System internal interfaces can exist to relay messages 306 between servers and an account manager. However the detailed 307 architecture of prepaid system and its interfaces are implementation 308 specific and are out of scope of this specification. 310 accounting 311 +------------+ +-----------+ protocol +--------------+ 312 | Subscriber |<----->| Service | | | 313 | | | Access |<------------>| Accounting | 314 | Device | | Device |<-----+ | Server | 315 +------------+ +-----------+ | +--------------+ 316 | 317 | 318 | +--------------+ 319 +------>| PrePaid | 320 prepaid | Server | 321 protocol +--------------+ 323 Figure 1 Basic Prepaid Architecture 325 The prepaid server and accounting server in this architecture model 326 are logical entities. The real configuration MAY combine them into a 327 single host. 329 There MAY exist protocol transparent RADIUS Proxies between prepaid 330 client and prepaid server. These proxies transparently support the 331 prepaid RADIUS extensions. 333 In order to generalize the solution, in this paper we generalize the 334 SADs, which in reality may be a NAS in Dialup deployments, PDSN 335 (Packet Data Serving Node) or HA (Home Agent) in CDMA2000 336 deployments, an 802.11 WLAN Access Points or GGSN (Gateway GPRS 337 Serving Node) in GPRS/UMTS deployments. To actively participate in 338 Prepaid procedures outlined here, the SAD MUST have the Prepaid 339 Client capabilities. Prepaid Client Capabilities include the 340 ability to meter the usage for a prepaid data session; this usage 341 includes time or volume (e.g. number of bytes) usage. 343 In the case of roaming scenarios using mobile IP (in a wireless or 344 wireline network), the prepaid client functionality may be delegated 345 to the Home Agent. It may also be possible to deliver limited 346 prepaid services using RADIUS capabilities specified in RFC2865 and 347 RFC2866. 349 Furthermore, the device including the prepaid client functionality 350 may also have Dynamic Session Capabilities that include the ability 351 to terminate a data session and/or change the filters associated 352 with a specific data session by processing Disconnect Messages and 353 Change of Authorization messages as per [RFC3576]. 355 In this document RADIUS is used as the AAA server. There are three 356 kinds or categories of AAA servers. The AAA server in the home 357 network, the HAAA, is responsible for authentication of the 358 subscriber and also authorization of the service. In addition, the 359 HAAA communicates with the Prepaid servers using the RADIUS protocol 360 to authorize prepaid subscribers. In AAA based roaming deployments 361 the AAA server in the visited network, the VAAA, is responsible for 362 forwarding the RADIUS messages to the HAAA. The VAAA may also 363 modify the messages. In roaming deployments, the visited network 364 may be separated from the home network by one or more broker 365 networks. The AAA servers in the broker networks, BAAA are 366 responsible to route the RADIUS packets transparently and hence 367 donÆt play an active roll in the Prepaid Data Service delivery. 369 In this document the Prepaid Server is described in functional terms 370 related to their interface with the HAAA. The Prepaid Server 371 interfaces to entities which: 373 i) Keep the accounting state of the prepaid subscribers (balance 374 manager); 376 ii) Allow access service requests to be rated in real-time (Rating 377 Engine); and 378 iii) Allow quota to be managed for a particular pre-paid service 379 (Quota Server). 381 The various deployments for Prepaid are presented in the remainder 382 of this section. The first deployment is the basic Prepaid data 383 service and is depicted in figure 2. The SAD, which supports the 384 prepaid client functionality, the HAAA and the Prepaid Server are 385 collocated in the same provider network. 387 The Subscriber Device establishes a connection with one of several 388 Access Devices in the network. The SAD communicates with one or 389 more HAAA servers in the network. To provide redundancy more than 390 one HAAA may be available to use by a SAD. 392 The network will have one or more Prepaid Servers. Multiple Prepaid 393 Servers may be used to provide redundancy and load sharing. The 394 interface between the HAAA and the PPS is implemented using the 395 RADIUS protocol in this specification. However, in cases where the 396 PPS does not implement the RADIUS protocol, the implementation would 397 have to map the requirements defined in this document to whatever 398 protocol is used between the HAAA and the PPS. 400 +------+ +-----+ 401 | | | | 402 +--------+ +--------+ +--| HAAA |--+--| PPS | 403 | | | | | | | | | | 404 | Sub | | Service| | +------+ | +-----+ 405 | |---| Access |--+ | 406 | Device | | Device | | +------+ | +-----+ 407 | | | | | | | | | | 408 +--------+ +--------+ +--| HAAA |--+--| PPS | 409 | | | | 410 +------+ +-----+ 412 Figure 2 Basic Prepaid Access Architecture 414 Figure 3 shows a static roaming prepaid architecture that is typical 415 of a wholesale scenario for Dial-Up users or a broker scenario used 416 in Dial-Up or WLAN roaming scenarios. 418 +----+ +----+ +----+ +-----+ 419 | | | | | | | | 420 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 421 | | | | | | | | | | | | | | | | 422 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 423 | |--|Access |-+ | | | 424 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 425 | | | | | | | | | | | | | | | | 426 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 427 | | | | | | | | 428 +----+ +----+ +----+ +-----+ 430 | Visited | |Broker | | Home | 431 | Network | |Network| | Network | 433 Figure 3 Static Roaming Prepaid Architecture 435 As in the basic prepaid architecture the subscriberÆs device 436 establishes a connection with the SAD (NAS, WLAN Access Point). 437 The SAD communicates with the Visiting AAA server (VAAA) using the 438 RADIUS protocol. Again for redundancy there maybe more then one 439 VAAA. The VAAA communicate using the RADIUS protocol with AAA 440 servers in the broker network (BAAA). There maybe more then one 441 Broker Network between the Visited Network and the Home Network. 442 The Home Network is the same as in the simple architecture. 444 To support dynamic roaming the network will utilize Mobile-Ip as 445 illustrated in Figure 4. Note that typically the mobile device 446 would be moving between networks that use the same technology such 447 as Wireless or WLAN. Increasingly, device will be able to roam 448 between networks that use different technology such as between WLAN 449 and Wireless and Broadband. Fortunately, Mobile-Ip can address this 450 type of roaming and therefore we need not be concerned with the 451 underlying network technology. 453 +------+ +-------+ +----+ +----+ +----+ +-----+ 454 | | |Service| | | | | | | | | 455 |Sub | |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS | 456 | |--|Device | | | | | | | | | 457 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 458 | | | | | | 459 +------+ +------ + | | 460 | | | +----+ 461 | | | | | 462 |ROAMS +------------------+ HA | 463 | | | | 464 V +----+ | +----+ 465 +------+ +-------+ | | | | 466 | | |Service| +-|VAAA+------+ | 467 |Sub | |Access | | | | | 468 | |--|Device +-+ +----+ | 469 |Device| | (FA) | | 470 | | | +------------------------+ 471 +------+ +-------+ 473 Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs 475 In figure 4, the Subscriber device establishes a prepaid session 476 between the SAD in the foreign network, which has prepaid 477 capabilities. The subscriberÆs home address will be anchored at the 478 Home Agent (HA) in the home network. The setup for this access 479 service is identical to the cases covered above. Notice that the 480 SAD may be collocated with the Foreign Agent (FA) in case of Mobile- 481 IPv4. As the subscriber device moves it establishes a connection 482 with another SAD in the same foreign network or in another foreign 483 network. The prepaid data service should continue to be available. 484 When a device associates to another SAD it MUST re-authenticate at 485 the new SAD and de-associate or logoff from the old SAD. 486 Furthermore, any unused quota at the old SAD MUST be promptly 487 credited back to the subscribers account. The reason we say 488 promptly, is because if the subscriber is very low on resources to 489 start with, the subscriber may not have enough resources to log on 490 to the new SAD. The speed at which resources can be returned depend 491 on the type of handoff procedure that is used. Some of the example 492 of handoffs in wireless networks are dormant handoff, active handoff 493 and fast handoff. 495 As well, notice that if the SADs could communicate with each other 496 then there could be a way to accelerate a faster handoff procedure. 497 In particular, it could accelerate the return of the unused portion 498 of the quotas from the old Access Device. 500 Unfortunately, standards with regards to handoff are evolving with 501 each network technology creating their own scheme to make the 502 handoff procedures more efficient. 504 2.3 505 Why not existing RADIUS attributes? 507 It has been asked ôWhy not use existing RADIUS attributes to build a 508 prepaid solution? This will allow us to have a solution with 509 existing devices without code modification.ö 511 It is possible to build a prepaid solution using existing RADIUS 512 attributes. The RADIUS server can simply send an Access-Accept 513 message containing Session-Timeout(27) and set Termination- 514 Action(29) to RADIUS-request. Upon receiving the Access-Accept 515 message, the NAS will meter the duration of the session and upon 516 termination of the session the NAS generate an Access-Request 517 message again. The RADIUS server would re-authenticate the session 518 and reply with an Access-Accept message with additional time in 519 Session-Timeout(27) or an Access-Reject message if there were no 520 more resources in the userÆs account. 522 If the user terminates the session before the time expressed in 523 Session-Timeout(27). The NAS will recover any unused time from the 524 accounting stream. 526 There are several problems with such a solution: 528 -It only allows for time-based prepaid. The solution presented in 529 this document allows for both time and volume based prepaid. As 530 well as extensibility for other features such as tarified based 531 solutions. 533 -Using accounting messages to recoup unused time may be problematic 534 because RADIUS accounting messages are not real-time. A RADIUS 535 server may store-and-forward accounting messages in batches. The 536 solution presented in this paper does not rely on Accounting Packets 537 at all. It uses Access-Request, messages which do flow through any 538 network in real-time. Delaying accounting messages may cause 539 revenue leakage. 541 -Session-Timeout(27) is not a mandatory attribute. If a prepaid 542 subscriber is being serviced by a NAS that does not adhere to 543 Session-Timeout then that subscriber will obtain unlimited service. 545 -Termination-Action(29) presents its own issues. First the 546 behaviour of Termination-Action(29) is not mandatory. Second, 547 according to RFC2865 Termination-Action fires when the Service is 548 complete. But we should not be terminating the service while 549 negotiating additional quota. The refreshing of the time quota 550 should be transparent to the user. Because Termination-Action 551 occurs when the Service is complete it is unclear whether or not the 552 user experience would be transparent. For example, will the RADIUS 553 server allocate the subscriber a new IP address? Furthermore, the 554 RADIUS server has no way of telling why the Access-Request message 555 was generated. The RADIUS server will have to wait for the 556 corresponding accounting packet to determine the reason for this 557 Access-Request message. Lastly re-authenticating the subscriber may 558 take far too long. The solution presented in this document allows 559 quota replenishing to occur in an undisruptive manner from the 560 perspective of the user. No re-authentication is required and 561 quotas can be negotiated prior to the quotas running out. 563 -Prepaid ambiguity. Implementing prepaid using existing RADIUS 564 attributes presents another problem. Due to the fact that the 565 standard RADIUS attributes are not mandatory, then the correct 566 prepaid operation is really an act of faith on the part of the 567 RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) 568 are not supported, the prepaid subscriber will get free access. The 569 solution described in this document, requires that a prepaid capable 570 SAD inform the RADIUS server whether or not it supports prepaid 571 capabilities. The RADIUS server can now determine whether service 572 should be granted or not. For example, if a prepaid subscriber is 573 connected to a NAS that does not support prepaid, the RADIUS server 574 can either instruct the NAS to tunnel the traffic to another entity 575 in the home network that does support prepaid client function (e.g. 576 Home Agent) or it may allow the subscriber to get access but 577 restrict the traffic. 579 The prepaid solution we present is a robust carrier grade prepaid 580 solution. It only requires the support of 2 mandatory attributes 581 and one optional attribute. Furthermore, it does not really 582 require much code support at the NAS. NASes already support 583 measurement of time and volume. This solution requires that they 584 advertise their prepaid capabilities in an Access-Request; that they 585 generate an Access-Request Authorize-Only packet to obtain more 586 quota at or before the quota is used up. It also requires that the 587 NAS send an Access-Request with Authorize-Only when the session 588 terminates to return any unused quota to the prepaid system. 590 Lastly the solution provided in this document is extensible. This 591 document defines the basic exchanges between a prepaid capable NAS 592 and a RADIUS server. The protocol can easily be extended to support 593 tariff switching and other prepaid business models. 595 3. 596 Use-cases 598 In this section we present a set of use cases that help establish 599 the requirements needed to deliver PrePaid data services. These 600 use-cases donÆt address how the PrePaid account is established or 601 maintained. It is assumed that the PrePaid subscriber has obtained 602 a valid account from a service provider such as a wireless operator 603 or a WLAN operator. 605 To make the document as general as possible, the use cases cover the 606 experience from the SAD and not from the UserÆs Device. The 607 connection between the UserÆs Device, which typically involves 608 setting up a layer 2 session, e.g., PPP session or GPRS PDP Context, 609 is specific to a given network technology and the details are not 610 required to deliver a PrePaid service. 612 3.1 613 Simple pre-paid access use-case 615 A PrePaid subscriber connects to his home network. As usual, the 616 Access Device that is servicing the subscriber will use the AAA 617 infrastructure to authenticate and authorize the subscriber. 619 The SAD sends a RADIUS Access-Request to the AAA system to 620 authenticate the subscriber, and identify and authorize the service. 621 The Access-Request includes the subscriberÆs credentials and may 622 include the PrePaid capabilities of the SAD. PrePaid capabilities 623 MUST be included if the SAD supports PrePaid functionality. 625 The AAA System proceeds with the authentication procedure. This may 626 involve several transactions such as in EAP [RFC2284]. Once the 627 subscriber has been authenticated, the AAA system determines that 628 the subscriber is a PrePaid subscriber and requests that the PrePaid 629 System authorize the PrePaid subscriber. The request MUST include 630 the PrePaid Capabilities of the serving SAD. 632 The PrePaid System will validate that the subscriber has a PrePaid 633 Account; it will validate that the account is active; and will 634 validate that the SAD has the appropriate PrePaid capabilities. If 635 all is in order, the PrePaid System will authorize the subscriber to 636 use the network. Otherwise it will reject the request. The 637 response is sent back to the AAA System. The response includes 638 attributes to indicate the allocation of a portion of the 639 subscriberÆs account called the initial quota (in units of time or 640 volume) and optionally a threshold value. 642 The reason we allocate a portion of the userÆs account is that the 643 user may be engaged in other Services that may draw on the same 644 Prepaid account. For example the user may be engaged in a data 645 session and a voice session. Although, these two services would 646 draw from the same account the involved separate parts of the 647 system. If the entire quota was allocated to the data session then 648 the user would have no more funds for a voice session. 650 The AAA system incorporates the PrePaid attributes received from the 651 PrePaid System into an Access-Accept message that it sends back to 652 the SAD. Note the AAA System is responsible for authorizing the 653 service whereas the PrePaid System is responsible for PrePaid 654 authorization. 656 Upon receiving the Access-Response, the SAD allows the PrePaid data 657 session to start and it starts to meter the session based on time or 658 volume, as indicated in the returned Quota 660 Once the usage for the session approaches the allotted quota (as 661 expressed by the threshold), the SAD will request an additional 662 quota. The re-authorization for additional quota flows through the 663 AAA system to the PrePaid System. The PrePaid System revalidates 664 the subscriberÆs account; it will subtract the previous quota 665 allocation from the userÆs account balance and if there is a balance 666 remaining it will reauthorize the request with an additional quota 667 allotment. Otherwise, the PrePaid System will reject the request. 668 Note the replenishing of the quotas is a re-authorization procedure 669 and does not involve re-authentication of the subscriber. 671 It is important to note that the PrePaid System is maintaining 672 session state for the subscriber. This state includes how much 673 account balance was allocated during the last quota allocation for a 674 particular session and how much is left in the account. Therefore, 675 it is required that all subsequent messages about the PrePaid 676 session reach the correct PrePaid System. 678 Upon receiving a re-allotment of the quota, the SAD will, continue 679 the data service session until the new threshold is reached. If the 680 request for additional quota cannot be fulfilled then the SAD will 681 let the subscriber use up the remaining quota and terminate the 682 session. 684 Alternatively, instead of terminating the session, the SAD may 685 restrict the data session such that the subscriber can only reach a 686 particular web server. This web server maybe used to allow the 687 subscriber to replenish their account. This restriction can also be 688 used to allow new subscribers to purchase their initial PrePaid 689 Service. 691 Should the subscriber terminate the session before the quota is used 692 up, the remaining balance allotted to the session must be credited 693 back to the subscriberÆs account. 695 As well, while the Access Device is waiting for the initial quota, 696 the subscriber may have dropped the session. The initial quota must 697 be credited back to the subscribers account. 699 3.2 700 Support for Multi-Services 702 Up to now we were looking at session that consisted of a single 703 service, ôAccess Serviceö. An ôAccess Serviceö is the basic service 704 that is provided to the user by the SAD after successful 705 authentication and authorization. When we donÆt differentiate 706 between different types of services the ôAccess Serviceö aggregates 707 all the services that the user my be engaged in on a particular SAD. 709 For example, the user may be browsing the web, and participating in 710 a VoIP conversation, watching streaming video and downloading a 711 file. 713 Some operators may want to distinguish between these services. Some 714 services are billed at different rates and services maybe metered 715 differently. Therefore, the prepaid solution needs to be able to 716 distinguish services, and allocate quotas to the services using 717 different units (e.g. time, volume) and allow for those quotas to be 718 utilized at different rates. 720 +---------+ 721 | Session | 722 +---------+ 723 | 724 V N 725 +--------------+ +-------+ 726 | Service |------>| Quota | 727 | (service-Id) | +-------+ 728 +--------------+ 730 As shown in the above diagram, a Session can have N Services. Each 731 service is identified by a Service-Id. The format of the Service-Id 732 is not in the scope of this document but the Service-Id could be 733 expressed as an IP flow using the stand 5-tuple (Source-IP and Port, 734 the Destination-IP and Port, and the protocol type). Each service 735 is allocated an appropriate quota. 737 3.3 738 Resource Pools 740 When working with multiple services that results in multiple quota 741 allocation another problem arises. Even though quotas are portioned 742 out in fractional parts of the userÆs prepaid account, there could 743 be a situation where one Service utilizes its quota faster then 744 another Service. When the userÆs account is used up, there could be 745 a situation where one Service is unable to obtain additional quota 746 while another Service has plenty of quota remaining. Unless the 747 quotas can be rebalanced, the SAD would then have to terminate that 748 Service. As well, even before that happens, the existence of 749 several Services could generate an excessive amount of traffic as 750 the services update their quotas. 752 One method to solve these problems is to utilize resource pools. 753 Resource pools allow us to allocate resources to several services of 754 a session by allocating resources to a pool and have services draw 755 their quota from the pool at a rate appropriate to that service. 756 When the quota allocated to the pool runs out, we replenish the 757 pool. 759 +-----------+ 760 | Service-A |-----+ +--------+ 761 +-----------+ | Ma | | 762 +-------->| | 763 | Pool | 764 +-------->| (1) | 765 +-----------+ | Mb | | 766 | Service-B |-----+ +--------+ 767 +-----------+ 769 As the figure above shows, Service-A and Service-B are bound to 770 Pool(1). Ma and Mb are the pool multipliers (that are associated 771 with Service-A and Service-B respectively) that determines the rate 772 at which Service-A and Service-B draw from the pool. 774 The pool is initialized by taking the quota allocated to each 775 service and multiplying it by Mn. Therefore, the amount of 776 resources allocated to a pool is given by: 778 Poolr = Ma*Qa + Mb*Qb + . . . 780 A Pool is empty if: 782 Poolr <= Ca*Ma + Cb*Mb + . . . 784 where: 785 Ca,Cb are the consumed resources of Service-A and Service-B 786 respectively. 788 Note that the resources assigned to the pool are unit less. That 789 is, Service-A can be rated at $1 per Mbyte and Service-B can rated 790 at $0.10 per Minute. In this case if we allocate $5 worth of 791 resources on behalf of service-A to the pool we would set Ma = 10 792 and place 50 units into the pool. If we allocate $5 on behalf of 793 Service-B to the Pool, then M=1 and place 50 units into the Pool. 794 The pool would have a total sum of 100 units to be shared between 795 the two services. Each Mbyte used by Service-A will draw 10 units 796 from the pool and each minute used by Service-B will draw 1 unit 797 from the pool. 799 3.4 800 Support for Complex Rating Functions 802 The rate of use of a resource by a service can be very complex. 803 Some services use resources (e.g. time, volume) linearly. For 804 example, a service maybe consuming resources at a rate of $1 per 805 Mbyte. 807 In some cases an operator may wish to apply a much more complex 808 rating function. For example, a service provider may wish to rate a 809 service such that the first N Mbytes are free, then the next M 810 Mbytes are rated at $1 per Mbyte and volume above M bytes be rated 811 at $0.50 per Mbyte. This rating function could be achieved by 812 repeated message exchanges with the Prepaid System. 814 To avert the need to exchange many messages and to support even more 815 complex rating functions we support Rating Groups. A Rating Group 816 is provisioned at the SAD. As illustrated in the figure below, a 817 Rating Group is associated with one or more Services and defines the 818 rate that the services associated with the Rating Group consume the 819 quota. 821 +-----------+ 822 | Service-A |------+ 823 +-----------+ | +--------------+ +-------+ 824 +---->| | | Quota | 825 | Rating Group |------>| or | 826 +-----------+ +---->| | | Pool | 827 | Service-B |------+ +--------------+ +-------+ 828 +-----------+ 830 During authorization of the of a service, if the service is 831 associated with a Rating Group, the Prepaid Client sends the Rating 832 Group to the Prepaid Server. The prepaid service authorizes the 833 Rating Group by assigning it a Quota and optionally assigning it to 834 a Resource Pool. 836 When service that belongs to an authorized Rating Group is 837 instantiated, then the Prepaid Client does not need to authorize 838 that service. This could greatly reduce the amount of traffic 839 between the Prepaid Client and the Prepaid Server. 841 3.5 842 One-Time-based Prepaid Charging 844 One-Time-based Prepaid Charging is used for charging of Service 845 Events where there is no session. That is, the Service Event does 846 not have a start or an end. An example of a one-time service event 847 is the purchase of a ring-tone. The one-time event in this case is 848 the userÆs purchasing the right to use a ring-tone. The actual 849 downloading of the tone is a separate service event totally distinct 850 from the right to use the ring tone. For example, the user may have 851 already downloaded the tone and then after being totally satisfied 852 with the quality, decides to purchase the right to use the tone. 853 Subscription based services can also be modeled as a One-Time event. 854 In this case the one-time service event is the purchase of a 855 subscription to use a service for a month. While the user uses the 856 service his usage maybe metered especially if there are limits 857 associated with the service. 859 For a given user, One-time-based charging may occur in conjunction 860 with the other charging models. For example, the prepaid user maybe 861 accessing a website which is being metered based time or volume 862 while they purchase the right to use a ring tone (a one-time-based 863 event). Note: it is up to the service providers to decide whether 864 or not the user will be charged for the download of the tone and 865 also be charged for the time and volume required to download the 866 ring-tone. The facilities provided by this document gives the 867 service provider the capability to achieve their service charging 868 business goals. For example, should the service provider choose not 869 to charge for the download volume or time, then they can treat the 870 download IP flow as a separate service that is exempt from charging. 872 One-time-based charging occurs when the SAD sends an indication to 873 the PPS identifying the service, and the units that need to be 874 debited from the account. The units to be debited from the account 875 and how those units are rated (if they donÆt represent money) is not 876 in scope of this specification. 878 One-time-based charging may occur under two conditions: the SAD may 879 not have a authenticated context (or access to an authenticated 880 context for the subscriber); the SAD has access to authenticated 881 context for the subscriber. In the former case the SAD will have to 882 authenticate the subscriber. For example, the prepaid user maybe 883 authenticated by the SAD providing access service. However when the 884 user accesses the subscription server to purchase a subscription, 885 the subscription server may not have access to the authentication 886 context of the subscriber and thus will have to authenticate the 887 subscriber. Authentication of the subscriber and the generation of 888 the one-time charging event will happen at the same time. 890 Note that one-time-based charging can be used to credit the prepaid 891 userÆs account. For example, the SAD can return resources back to 892 the prepaid subscriber by making a one-time charge request that 893 includes the amount of resource to be credited back to the user. 895 3.6 896 Support for Tariff Switching 898 The PPC and the PPS may support tariff switching for volume based 899 prepaid packet service. Tariff switching allows the PPS to signal 900 the PPC when a change of rating or tariff switch is to occur. For 901 example as shown in the figure below, traffic before 18:00 hours is 902 rated at ær1Æ or business rates and traffic after 18:00 hours is 903 rated at ær2Æ or non-business rates. The PPC will then be able to 904 report usage before the tariff switch point and usage after the 905 tariff switch point. Since time is measured in seconds, tariff 906 switching only makes sense for volume based prepaid service where 907 the volume is billed at different rates: one rate before the tariff 908 switch period and another rate after the tariff switch period. 910 18:00 911 ------------------+----------------- 912 r1 | r2 913 ------------------+----------------- 914 ^ ^ 915 |<----TSI---> | 916 | | 917 Access-Accept Access-Request 919 When tariff switching is supported by the PPC it indicates support 920 for tariff switching by setting the appropriate bit in the PPAC. If 921 the PPS requires to signal a tariff switch time it will send a PTS 922 attribute which will indicate when the tariff switch period is to 923 occur as a number of seconds from the current time 924 (TarrifSwitchInterval TSI). 926 Sometime after the tariff switch period the PPC will send another 927 online Access-Request. Either the user has logged off or the volume 928 threshold has been reached. The PPC will report how much volume was 929 used using the PPAQ and how much volume was used after the tariff 930 switch using the PTSÆs VUATS subtype. 932 If the PPC will send and event before the tariff switch time, say 933 the Volume threshold has been reached, the PPS will respond with 934 another PTS with the TSI indicating how many seconds until the 935 tariff switch time. 937 In situations where there is going to be another tariff switch 938 period, as shown below, the PPS MUST specify the length of the 939 tariff switch period using the TimeIntervalAfterTariffSwitchUpdate 940 (TITSU) in the PTS attribute. 942 18:00 23:30 943 ------------------+---------------------+-------------- 944 r1 | r2 | r3 945 ------------------+---------------------+-------------- 946 ^ ^ ^ 947 |<----TSI---><-----------|-------->|TITSU 948 | | 949 Access-Accept Access-Request 951 When TITSU is specified in the PTS, the PPC MUST generate an online 952 Access-Request within the time after TSI and before TITSU expires. 953 Normally the PPC will be triggered by the Volume Threshold, but 954 there is no guarantee that the user session will generate any volume 955 during the period between 18:00 and 23:30 hours. If TITSU was not 956 specified in this case, then if there was some volume generated 957 during r2 but not enough to trigger a prepaid update before the next 958 tariff switch at 23:30. Then the PPC will not be able to report how 959 much volume was generated during r1, r2, and r3. 961 When prepaid for multiple flows is supported, then each flow could 962 have it own tariff switch period. For example, best effort flow may 963 not have a tariff switch associated with it, yet a voice over IP 964 call may have a tariff switch period. The Voice over IP call may 965 bill at one rate for the first 5 minutes and another rate for the 966 rest of the call. 968 [EDITORÆS NOTE: Need to consider tariff switching with pools. Is it 969 worthwhile?] 971 3.7 972 Support for Roaming 974 For some networks it is essential that PrePaid Data Services be 975 offered to roaming subscribers. Support for static and dynamic 976 roaming models are needed. Static roaming is where the subscriber 977 logs onto a foreign network. The foreign network has a roaming 978 agreement directly with the home network or through a broker network 979 or networks. The subscriber remains logged into the network until 980 the subscriber changes location. When changing location a new 981 connection and a new login procedure is required. 983 Dynamic roaming allows to subscriber to move between networks while 984 maintaining a connection with the home network seamlessly. As the 985 subscriber moves between networks, the data session is handed off 986 between the networks. 988 In both roaming scenarios, the subscriber always authenticates with 989 the home network. PrePaid authorization and quota replenishing for 990 the session need to be received at the home network and more 991 specifically at the PrePaid System where state is being maintained. 993 Dynamic roaming is particularly challenging. A subscriber that 994 established a PrePaid Data Session may roam to another Access Device 995 that doesnÆt not support PrePaid functionality. The system should 996 be capable to continue the PrePaid session. 998 3.8 999 PrePaid termination 1001 When fraud is detected by the PrePaid System, or when an error is 1002 detected, it may be beneficial for the PrePaid system to terminate a 1003 specific session for the subscriber or all the sessions of a 1004 subscriber. 1006 Some errors can occur such that the PrePaid System is in a state 1007 where it is not sure whether the session is in progress or not. 1008 Under conditions such as this, the PrePaid system may wish to 1009 terminate the PrePaid data session to make sure that resources are 1010 not being utilized for which it canÆt charge for reliably. 1012 Some handoff procedure used during dynamic roaming may require that 1013 the PrePaid system explicitly terminate the subscribers PrePaid data 1014 session at an SAD. For example, if time based PrePaid service is 1015 being used and the mobile subscriber performs a dormant handoff, the 1016 PrePaid System needs to explicitly terminate the PrePaid session at 1017 the old SAD. 1019 3.9 1020 Querying and Rebalancing Prepaid Resources 1022 It should be possible to allow the Prepaid Server to Query the 1023 current uses state of a prepaid balance at a SAD and adjust the 1024 prepaid resources. 1026 For example, a request to the PPS is made (e.g., a one-time charging 1027 event) but the userÆs account is depleted but resources have been 1028 allocated to the SAD. The PPS should have a the capability to query 1029 the SAD and if it has the spare resources to reassign the quotas to 1030 the SAD and to the pending request. Note that the PPS doesnÆt know 1031 resource usage until the SAD request for more resources. This can 1032 be a long time. 1034 In the absence of this capability the PPS can minimize the 1035 occurrence of this scenario by allocated smaller quotas. But the 1036 result will be many more transactions. The ability to query and to 1037 rebalance resources provides a good trade-off. 1039 4. 1040 Operations 1042 4.1 1043 General Requirements 1045 4.1.1 1046 Broker AAA Requirements 1048 Broker AAA servers MUST support the Message-Authenticator(80) 1049 attribute as defined in [RFC2869]. If BAAA servers are used, the 1050 BAAA servers function is to forward the RADIUS packets as usual to 1051 the appropriate RADIUS servers. 1053 Accounting messages are not needed to deliver a PrePaid service. 1054 However, accounting messages can be used to keep the PrePaid Server 1055 current as to what is happening with the PrePaid data session. 1056 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 1057 pass through mode described in [RFC2866]. 1059 4.2 1060 Authentication and Authorization for Prepaid Enabled SADs 1062 The SAD initiates the authentication and authorization procedure by 1063 sending a RADIUS Access-Request to the HAAA. 1065 If the SAD has PrePaid Client capabilities, it MUST include the 1066 PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD) 1067 attribute indicates to the PrePaid server the PrePaid capabilities 1068 possessed by the SAD. These are required in order to complete the 1069 PrePaid authorization procedures. 1071 If the SAD supports the Disconnect-Message or the Change-of- 1072 Authorization capabilities, then it SHOULD include the Dynamic- 1073 Capabilities attribute. 1075 In certain deployments, there may be other ways in which to 1076 terminate a data session, or change authorization of an active 1077 session. For example, some SADs provide a session termination 1078 service via Telnet or SNMP. In these cases, the AAA server MAY add 1079 the Dynamic-Capabilities message to the Access-Request. Upon 1080 receiving the Change-of-Authorization message, the AAA server would 1081 then be responsible for terminating the session using whatever means 1082 that are supported by the device. 1084 If the authentication procedure involves multiple Access-Requests 1085 (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the 1086 Dynamic-Capabilities attribute (if used) in at least the last 1087 Access-Request of the authentication procedure. 1089 The Access-Request will be sent as usual to the HAAA. The packet 1090 may be proxied through zero or more BAAA. 1092 Once the Access-Request arrives at the HAAA, the HAAA will 1093 authenticate the subscriber. If the subscriber is cannot be 1094 authenticated, the HAAA will send an Access-Reject message back to 1095 the client. If the subscriber is authenticated, the HAAA will 1096 determine whether or not the subscriber is a PrePaid subscriber. 1097 The techniques used to determine whether or not a subscriber is a 1098 PrePaid subscriber is beyond the scope of this document. If the 1099 subscriber is not a PrePaid subscriber, then the HAAA will respond 1100 as usual with an Access-Accept or Access-Reject message. If the 1101 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 1102 Access-Request to a PrePaid server for further authorization. 1104 The Access-Request will contain the PPAC(TBD) attribute, the 1105 Dynamic-Capabilities attribute if one was included; the User-Name(1) 1106 attribute MAY be set to a value that would represent the 1107 SubscriberÆs PrePaid Identity. This attribute is used by the 1108 PrePaid server to locate the PrePaid SubscriberÆs account. For 1109 added security, the HAAA MAY also set the User-Password(2) attribute 1110 to the password used between the HAAA and the PrePaid server. 1112 The PrePaid server lookups the subscriberÆs PrePaid account and will 1113 authorize the subscriber taking into consideration the SAD PrePaid 1114 Client Capabilities. 1116 Upon successful authorization, the PrePaid server will generate an 1117 Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD) 1118 attribute. 1120 The PPAC attribute returned to the client indicates the type of 1121 prepaid service to be provided for the session. The PPAQ(TBD) 1122 attribute includes: 1124 - The QUOTA-Id, which is set by the PrePaid server to a unique 1125 value that is used to correlate subsequent quota requests; 1127 - Volume and/or Time quotas, which are set to a value representing a 1128 portion of the subscribers account; 1130 - MAY contain a Time or Volume Threshold that controls when the SAD 1131 requests additional quota; 1133 - The IP address of the Serving PrePaid Server and one or more 1134 alternative PrePaid Servers. This is used by the HAAA to route 1135 subsequent quota replenishing messages to the appropriate PrePaid 1136 server(s). 1138 Note: Idle-Timeout(28) can be used to trigger the premature 1139 termination of a pre-paid service following subscriber inactivity. 1141 Depending on site policies, upon unsuccessful authorization, the 1142 PrePaid server will generate an Access-Reject to terminate the 1143 session immediately. Alternatively, the PrePaid server may generate 1144 an Access-Accept blocking some or all of the traffic and/or redirect 1145 some or all of the traffic to a location where the subscriber can 1146 replenish their account for a period of time. Blocking of traffic 1147 is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect 1148 I-d). Redirection is achieved by sending Redirect-Id or Redirect- 1149 Rule, HTTP Redirection defined in the Redirect I-d. The period of 1150 time before the blocked/redirected session last can be specified by 1151 Session-Timeout(27) attribute. 1153 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 1154 will append the usual service attributes and forward the packet to 1155 the SAD. The HAAA SHOULD NOT overwrite any attributes already set 1156 by the PrePaid server. If the HAAA, receives an Access-Reject 1157 message, it will simply forward the packet to its client. Depending 1158 on site policies, if the HAAA fails to receive an Access-Accept or 1159 Access-Reject message from the PrePaid server it MAY do nothing or 1160 send an Access-Reject or an Access-Accept message back to its 1161 client. 1163 4.3 1164 Session Start Operation 1166 The real start of the session is indicated by the arrival of 1167 Accounting-Request(Start) packet. The Accounting-Request (Start) 1168 MAY be routed to the PrePaid Server so that it can confirm the 1169 initial quota allocation. 1171 Note that the PrePaid Server role is not to record accounting 1172 messages and therefore it SHOULD not respond with an Accounting 1173 Response packet. 1175 If the Prepaid server does not receive the Accounting-Request(start) 1176 message it will only know that the session has started upon the 1177 first reception of a quota replenishment operation. 1179 If the Prepaid server does not receive indication directly (via 1180 Accounting-Request(start)) or indirectly, it SHOULD after some 1181 configurable time, deduce that the Session has not started. If the 1182 SAD supports termination capabilities, the PPS SHOULD send a 1183 Disconnect Message to the SAD to ensure that the session is indeed 1184 dead. 1186 4.4 1187 Mid-Session Operation 1189 During the lifetime of a PrePaid data session the SAD will request 1190 to replenish the quotas using Authorize-Only Access-Request 1191 messages. 1193 Once the allocated quota has been reached or the threshold has been 1194 reached, the SAD MUST send an Access-Request with Service-Type(6) 1195 set to a value of ôAuthorize Onlyö and the PPAQ(TBD) attribute. 1197 The SAD MUST also include NAS identifiers, and Session identifier 1198 attributes in the Authorize Only Access-Request. The Session 1199 Identifier should be the same as those used during the Access- 1200 Request. For example, if the User-Name(1) attribute was used in the 1201 Access-Request it MUST be included in the Authorize Only Access- 1202 Request especially if the User-Name(1) attribute is used to route 1203 the Access-Request to the Home AAA server. 1205 The Authorize Only Access-Request MUST not include either User 1206 Password or Chap Password. In order to authenticate the message, 1207 the SAD MUST include the Message-Authenticator(80) attribute. The 1208 SAD will compute the value for the Message-Authenticator based on 1209 [RFC2869]. 1211 When the HAAA receives the Authorize-Only Access-Request that 1212 contains a PPAQ(TBD), it SHALL validate the message using the 1213 Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an 1214 Authorize Only Access-Request that contains a PPAQ(TBD) but not a 1215 Message-Authenticator(80) it SHALL silently discard the message. An 1216 Authorize Only Access-Request message that does not contain a 1217 PPAQ(TBD) is either in error or belongs to another application (for 1218 example, a Change of Authorization message [RFC3576]). In this case 1219 the Authorize Only Access-Request will either be silently discarded 1220 or handled by another application (not in scope of this document). 1222 Once the Authorize Only Access-Request message is validated, the 1223 HAAA SHALL forward the Authorize Only Access-Request to the 1224 appropriate PrePaid Server. The HAAA MUST forward the Authorize 1225 Only Access-Request to the PrePaid server specified in the 1226 PPAQ(TBD). The HAAA MUST sign the message using the Message- 1227 Authenticator(80) and the procedures in [RFC2869]. As with the 1228 Access-Request message, the HAAA MAY modify the User-Name(1) 1229 attribute to a value that represents the userÆs internal PrePaid 1230 account in the PrePaid server. Note the PrePaid server could use 1231 the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate 1232 the user account. 1234 Upon receiving the Authorize Only Access-Request containing a 1235 PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- 1236 Authenticator(80) as prescribed in [RFC2869]. If the message is 1237 invalid, the PrePaid server MUST silently discard the message. If 1238 it received an Authorize Only Access-Request message that does not 1239 contain a PPAQ(TBD) it MUST silently discard the message. 1241 The PrePaid server will lookup the PrePaid session by using the 1242 PrePaid Quota Id contained within the PPAQ(TBD). The PrePaid Server 1243 would, take the last allocated quota and subtract that from the 1244 UserÆs balance. If there is remaining balance, the PrePaid server 1245 re-authorizes the PrePaid session by allocate an additional quota. 1246 The PrePaid server may want to calculate a different threshold 1247 values as well. 1249 Upon successful re-authorization, the PrePaid server will generate 1250 an Access-Accept containing the PPAQ(TBD) attribute. The Access- 1251 Accept message MAY contain Service-Type(6) set to Authorize-Only and 1252 MAY contain the Message-Authenticator(80). 1254 Depending on site policies, upon unsuccessful authorization, the 1255 PrePaid server will generate an Access-Reject or an Access-Accept 1256 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 1257 and the Session-Timeout(27) attribute such that the PrePaid 1258 subscriber could get access to a restricted set of locations for a 1259 short duration to allow them to replenish their account, or create 1260 an account; or to browse free content. 1262 Upon receiving the Access-Accept from the PrePaid server, the HAAA 1263 SHALL return the packet to its client. If the HAAA, receives an 1264 Access-Reject message, it will forward the packet. Depending on 1265 site policies, if the HAAA fails to receive an Access-Accept or an 1266 Access-Reject message from the PrePaid server it MAY do nothing or 1267 it MAY send an Access-Reject message back to its client. 1269 Upon receiving an Access-Accept, the SAD SHALL update its quotas and 1270 threshold parameters with the values contained in the PPAQ(TBD) 1271 attribute. Note that the PrePaid server MAY update the 1272 PrePaidServer attribute(s) and these may have to be saved as well. 1274 Upon receiving an Access-Accept message containing either Filter- 1275 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 1276 The SAD SHALL restrict the subscriber session accordingly. 1278 4.5 1279 Dynamic Operations 1281 The PrePaid server may want to take advantage of the dynamic 1282 capabilities that are supported by the SAD as advertised in the 1283 Dynamic-Capabilities attribute during the initial Access-Request. 1285 There are two types of actions that the PrePaid server can perform: 1286 it can request that the session be terminated; or it can request 1287 that attributes associated with the session be modified. More 1288 specifically, it can modify previously sent PPAQ(TBD) 1290 Both of these actions require that the session be uniquely 1291 identified at the SAD. As a minimum the PrePaid server: 1293 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 1294 -MUST provide at least one session identifier such as User-Name(1), 1295 Framed-IP-Address(), the Accounting-Session-Id(44). 1297 Other attributes could be used to uniquely identify a PrePaid data 1298 session. 1300 For a discussion on Dynamic Operations as they related Mutli-Service 1301 operations see further on. 1303 4.5.1 1304 Unsolicited Session Termination Operation 1306 At anytime during a session the Prepaid Server may send a Disconnect 1307 Message to terminate a session. This capability is described in 1308 detail in [RFC3576]. The PrePaid server sends a Disconnect Message 1309 that MUST contain identifiers that uniquely identify the 1310 subscriberÆs data session and the SAD servicing that session. 1312 If the SAD receives a Disconnect-Message, it will respond with 1313 either a Disconnect-ACK packet if it was able to terminate the 1314 session or else it will respond with a Disconnect-NAK packet. 1316 Upon successful termination of a session the SAD MUST return any 1317 unused quota to the Prepaid Server by issuing an Authorize Only 1318 Access-Request containing the PPAQ which contains any unused Quota 1319 and the Update-Reason set to ôRemote Forced Disconnectö. 1321 4.5.2 1322 Unsolicited Change of Authorization Operation 1324 At anytime during the prepaid session the Prepaid Client may receive 1325 a Change of Authorization (CoA) message. A Prepaid Server may send 1326 a new Quota to either add additional quota or to remove quota 1327 already allocated for the service. 1329 If the Change of Authorization contains a PPAQ then that PPAQ will 1330 override a previously received PPAQ. The PPAQ may contain more 1331 allocated Quota or less allocated quota. The PPS MUST NOT change 1332 the units used in the PPAQ. 1334 If the newly received PPAQ reduces the amount of allocated quota 1335 beyond what is currently used then the SAD will accept the new PPAQ 1336 and act as it normally would when the quota is used up. For 1337 example, if the threshold is reached then is request a quota update; 1338 if the quota received is less then the currently used level then the 1339 SAD would follow the normal procedures followed when a quota is used 1340 up. 1342 4.6 1343 Termination Operation 1345 The termination phase is initiated when either: the Subscriber logs 1346 off; the quotas have been consumed, or when the SAD receives a 1347 Disconnect Message. 1349 In the case where the user logged off, or the SAD receives a 1350 Disconnect Message, the SAD will send an Authorize-Only Access- 1351 Request message with a PPAQ(TBD) and Update-Reason attribute set to 1352 either ôClient Service terminationö or ôRemote Forced disconnectö 1353 and the currently used quota. 1355 In the case where the quota has been reached, if the PPAQ(TBD) 1356 contained Termination-Action field, the SAD will follow the 1357 specified action which would be to immediately terminate the 1358 service, to request more quota, or to Redirect/Filter the service. 1360 4.7 1361 Mobile IP Operations 1363 In roaming scenarios using Mobile-IP, as the mobile subscriber roams 1364 between networks, or between different types of networks such as 1365 between WLAN and CDMA2000 networks, the PrePaid data session should 1366 be maintained transparently if the HA is acting as the SAD. 1368 As the subscriber device associates with the new SAD (AP or PDSN 1369 that supports prepaid client capability), the SAD sends a RADIUS 1370 Access-Request and the subscriber is re-authenticated and 1371 reauthorized. The SAD MUST include the PPAC(TBD) attribute in the 1372 RADIUS Access-Request. In this manner the procedure follows the 1373 Authentication and Authorization procedure described earlier. 1375 If the HA was acting as the SAD before handoff, the userÆs prepaid 1376 session does not undergo any change after the handoff because the 1377 Mobile IP session is anchored at the HA and the userÆs Home IP 1378 address remains the same. 1380 In the case of AP or PDSN acting as the SAD it is likely that the 1381 userÆs IP address will change (Care of Address). Therefore, the 1382 ongoing prepaid session will have some impact. In the case the SAD 1383 shall send an Access-Request. 1384 The Access-Request message is routed to the home network and MUST 1385 reach the PrePaid System that is serving the PrePaid session. The 1386 PrePaid system will then correlate the new authorization request 1387 with the existing active session and will assign a quota to the new 1388 request. Any outstanding quota at the old SAD MUST be returned to 1389 the PrePaid system. If the Mobile-IP nodes (HA and FA) supports 1390 registration revocation (Mobile IPv4 only). Specifically, the quota 1391 SHOULD be returned when the SAD sends the Authorize Only Access- 1392 Request with PPAQ(TBD) Update-Reason set to either ôRemote Forced 1393 disconnectö or ôClient Service terminationö. In order to trigger 1394 the sending of this last Authorize Only Access-Request, the PrePaid 1395 system may issue a Disconnect Message [3576] to the SAD. 1397 If the subscriber has roamed to an SAD that does not have any 1398 PrePaid Capabilities, PrePaid data service may still be possible by 1399 requesting the Home Agent (providing it has PrePaid Capabilities) to 1400 assume responsibilities for metering the service. The procedure for 1401 this scenario will be given in the next release of this draft. 1403 4.8 1404 Operation consideration for Multi-Services 1406 This section describes the operation for supporting Prepaid for 1407 multi-services on the same SAD. The operations for multi-services 1408 are very similar to operations for single service. Message flows 1409 illustrating the various interactions are presented at the end of 1410 this document. 1412 A SAD that supports prepaid operations for multi-services SHOULD set 1413 the ôMulti-Services Supportedö bit in the PPAC. 1415 When working with multi-services, we need to differentiate between 1416 the services. A Service-Id attribute is used in the PPAQ(TBD) to 1417 uniquely differentiate between the services. The exact definition 1418 of the Service-Id attribute is out of scope for this document. 1420 A PPAQ that contains a Service-Id is associated with that Service. 1421 A PPAQ that contains a Rating-Group-Id is associated with that 1422 Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a 1423 Service-Id. A PPAQ that contains neither a Rating-Group-Id or a 1424 Service-Id applies to the ôAccess Serviceö. 1426 4.8.1 1427 Initial Quota Request 1429 When operations with multi-services is desired, the SAD will request 1430 the initial quota for the Service by sending a PPAQ containing the 1431 Service-Id for that Service in an Authorize-Only Access-Request 1432 packet. Similarly, if the SAD supports Rating-Groups then it may 1433 request a prepaid quota for the Rating-Group by sending a PPAQ 1434 containing the Rating-Group-Id. In both cases the Update-Reason 1435 will be set to ôInitial-Requestö. 1437 The Authorize-Only Access-Request packet may contain more than one 1438 PPAQ. The Authorize-Only Access-Request MUST include one or more 1439 attributes that serve to identify the session so that it can be 1440 linked to the original authentication. Which Session Identifier(s) 1441 is included is up to specific deployments. The Authorize-Only 1442 message must contain the Message-Authenticator(80) attribute for 1443 integrity protection of the Authorize-Only Access-Request message. 1445 Upon receiving an Authorize-Only Access-Accept message containing 1446 one or more PPAQs the Prepaid System will allocate resources to each 1447 PPAQ. The resources, can be in units of time, volume as before. 1448 Each PPAQ will be assigned a unique QID that MUST appear in a 1449 subsequent PPAQ update for that service or rating-group. As well, 1450 the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if 1451 the PPAQ applies to the ôAccess Serviceö. 1453 4.8.2 1454 Quota Update 1456 Once the services start to utilize their allotted quota they will 1457 eventually need to replenish their quotas (either the threshold is 1458 reached or no more quota remains). To replenish the quota the 1459 Prepaid Client will send an Authorize-Only Access-Request message 1460 containing one or more PPAQs. Each PPAQ MUST contain the 1461 appropriate QID, Service-ID or Group-ID (or neither the Service-ID 1462 or Group-Id if the quota replenishment is for the ôAccess Serviceö). 1463 The Update-Reason filed will indicate either ôThreshold reachedö(3), 1464 or ôQuota reachedö(4). The Authorize-Only message must contain 1465 identifiers to identify the session. 1467 Upon receiving an Authorize-Only Access-Request packet with one or 1468 more PPAQs the Prepaid Server will respond with a new PPAQ for that 1469 service. The PPAQ will contain a new QID, the Service-Id or Rating- 1470 Group-Id, a new Quota. If the Prepaid Server does not want to grant 1471 additional quota to the Service it MUST include the Termination- 1472 Action subfield in the PPAQ that will instruct the SAD what to do 1473 with the service. 1475 4.8.3 1476 Termination 1478 When an allotted quota for the service is used up the SAD shall act 1479 in accordance to the Termination-Action field set in the Quota. If 1480 the Termination-Action field is absent then the Service MUST be 1481 terminated. 1483 If the Service is to be terminated then the SAD shall send a PPAQ 1484 with the appropriate QID, the Service-Id, the used quota, and 1485 Update-Reason set to ôClient Service Terminationö. 1487 If the ôAccess Serviceö has terminated, then all other services must 1488 be terminated as well. In this case the SAD must report on all 1489 issued quotas for the various services. The Update-Reason field 1490 should be set to ôAccess Service Terminatedö. 1492 Note when sending more then on PPAQ it may be required to send 1493 multiple Authorize Only Access-Requests. 1495 4.8.4 1496 Dynamic Operations 1498 Dynamic operations for multi-services are similar to dynamic 1499 operations described for single service operations. The prepaid 1500 system may send a COA message containing a PPAQ for an existing 1501 service instance. The SAD will match the PPAQ to the service using 1502 the Service-ID attribute. The new quota could be higher then the 1503 last allocated value or it could be lower. The SAD must react to 1504 the new quota accordingly. 1506 A Disconnect message may not be send for a specific service. A 1507 disconnect message terminates the ôAccess Serviceö. As such the SAD 1508 must report back all unused quotas by sending an Authorize Only 1509 Access Request message containing a PPAQ for each active service. 1510 The Update-Reason shall indicate that the reason for the update 1511 reason. 1513 4.8.5 1514 Support for Resource Pools 1516 If the Prepaid Client supports pools as indicated by setting the 1517 ôPools supportedö bit in the PPAC(TBD) then the Prepaid Server may 1518 associate a Quota with a Pool by including the Pool-Id and the Pool- 1519 Multiplier in the PPAQ(TBD). 1521 When Resource Pools are used, the PPAQ must not use the threshold 1522 field. 1524 4.8.6 1525 One-Time-Charging 1527 To initiate a One-Time charge the PPC include the PPAQ attribute in 1528 an Access-Request packet. The Access Request packet MUST include 1529 the Message-Authenticator(80) and Event-Timestamp(55) attributes. 1531 The Service Id field of the PPAQ identifies the Service that is be 1532 charged for. The amount of to be charged is specified using the 1533 Resource Quota and Resource Quota overflow subtypes. If the value 1534 specified is negative then the resources will be credited to the 1535 userÆs account. 1537 The QID field MUST be set to a unique value and will be used by the 1538 PPS to detect duplicates should the packet be retransmitted. 1539 The Update Reason field MUST be set to One-Time Charging. 1541 Upon receiving a PPAQ configured as a One-Time charge, the RADIUS 1542 server authenticates the user and if authenticated, pass the PPAQ to 1543 the PPS. The PPS shall locate the subscriber account and debit or 1544 credit the account accordingly. The PPS MUST repond to the PPS with 1545 an Access-Accept message upon success. Or an Access-Reject message 1546 if it cant locate the userÆs account or if there is no balance 1547 remaining in the account. 1549 The RADIUS server shall respond back to the SAD with an Access 1550 Accept message. Since this is a one-time event charge the SAD must 1551 not allow the session to continue. Therefore, the RADIUS server 1552 should include in the Access-Accept a Session-Timeout set to 0. The 1553 Upon receiving an Access-Accept response the SAD shall generate an 1554 Accounting Stop message. 1556 A PPAQ used for One-Time charging may appear in an Authorize-Only 1557 Access Request. This is the case where a session already exists for 1558 the user. The PPS shall respond back with an Access-Accept to 1559 indicate that the userÆs account has been debited or an Access- 1560 Reject indicating that the account could not be debited. 1562 4.8.7 1563 Error Handling 1565 If the Prepaid Server receives a PPAQ with an invalid QID it MUST 1566 ignore that PPAQ. 1568 If the Prepaid Server receives a PPAQ containing a Service-Id, or a 1569 Rating-Group-Id that it does not recognize, then it MUST ignore that 1570 PPAQ. 1572 If the Prepaid Client receives a PPAQ containing a Service-Id, or a 1573 Rating-Group-Id that it does not recognize, then it must ignore that 1574 PPAQ. 1576 If the Prepaid Client receives a PPAQ that contains a Pool-Id 1577 without a Pool-Multiplier; or a Pool-Multiplier without a Pool-Id it 1578 must ignore that PPAQ. 1580 4.9 1581 Accounting Considerations 1583 Accounting messages are not required to deliver PrePaid Data 1584 Service. Accounting message will typically be generated for PrePaid 1585 Data Service. This because accounting message are used for auditing 1586 purposes as well as for bill generation. 1588 Accounting messages associated with PrePaid Data Sessions should 1589 include the PPAQ(TBD) attribute. 1591 4.10 1592 SAD Operation 1594 To be completed 1596 4.11 1597 Interoperability with Diameter Credit Control Application 1599 RADIUS PrePaid solutions need to interoperate with Diameter 1600 protocol. Two possibilities exist: The AAA infrastructure is 1601 Diameter based and the SAD are RADIUS based; or the SAD is Diameter 1602 based and the AAA infrastructure is RADIUS based. 1604 The Diameter Credit Control Application [DIAMETERCC] describes how 1605 to implement a PrePaid using an all Diameter based infrastructure. 1607 1609 5. 1610 Attributes 1612 This draft is using the RADIUS [RFC2865] namespace. 1614 5.1 1615 PPAC Attribute 1617 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1618 Access-Request message by a Prepaid Capable NAS and is used to 1619 describe the PrePaid capabilities of the NAS. The PPAC is available 1620 to be sent in an Access-Accept message by the Prepaid server to 1621 indicate the type of prepaid metering that is to be applied to this 1622 session. 1624 0 1 2 3 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | AvailableInClient (AiC) | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 TYPE : value of PPAC 1633 LENGTH: 8 1634 VALUE : String 1636 The value MUST be encoded as follows: 1638 Sub-Type (=1) : Sub-Type for AvailableInClient attribute 1639 Length : Length of AvailableInClient attribute 1640 (= 6 octets) 1641 AvailableInClient (AiC): 1643 The optional AvailableInClient Sub-Type, generated by the PrePaid 1644 client, indicates the PrePaid Accounting capabilities of the NAS and 1645 shall be bitmap encoded. The possible values are: 1647 0x00000001 Volume metering supported. 1648 0x00000002 Duration metering supported. 1649 0x00000004 Resource metering supported. 1650 0x00000008 Pools supported 1651 0x00000010 Rating groups supported 1652 0x00000020 Multi-Services supported. 1653 0x00000040 Tariff Switch supported. 1655 Others Reserved 1657 5.2 1658 Session Termination Capability 1660 The value shall be bitmap encoded rather than a raw integer. This 1661 attribute shall be included RADIUS Access-Request message to the 1662 RADIUS server and indicates whether or not the NAS supports Dynamic 1663 Authorization. 1665 0 1 2 3 1666 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 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | TYPE | LENGTH | String | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 Type : value of Session Termination Capability 1672 Length: = 4 1673 String encoded as follows: 1675 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1676 supported. 1678 5.3 1679 PPAQ Attribute 1681 One or more PPAQ(TBD) attributes are available to be sent in an 1682 Access Request, Authorize Only Access-Request and Access-Accept 1683 messages. In an Access Request message, it is used to One-Time 1684 charging transactions; in Authorize Only Access-Request messages it 1685 is used to for One-Time charging, report usage and request further 1686 quota or request prepaid quota for a new service instance; in an 1687 Access-Accept message it is used to allocate the quotas (initial 1688 quota and subsequent quotas). 1690 When concurrent service are supported a PPAQ is associated with a 1691 specific service as indicated by the presence of Service-Id; or a 1692 Rating Group, as indicated by the presence of a Rating-Group-Id; or 1693 the ôAccess Serviceö as indicated by the absence of a Service-Id or 1694 a Rating-Group-Id. 1696 The attribute consists of a number of subtypes. Subtypes not used 1697 are omitted in the message. 1699 0 1 2 3 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | QuotaIdentifier (QID) | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | SUB-TYPE 2 | LENGTH | Volume Quota | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Volume Quota | SUB-TYPE 3 | LENGTH | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | VolumeThreshold (VT) | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | SUB-TYPE 6 | LENGTH | DurationQuota (DQ) | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | DurationThreshold (DT) | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | SUB-TYPE 9 | LENGTH | PrePaidServer | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | PrePaidServer | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 Type : Value of PPAQ 1730 Length: variable, greater than 8 1732 String: The String value MUST be encoded as follows: 1734 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 1735 Length : Length of QuotaIDentifier attribute (= 6 octets) 1737 QuotaIDentifier (QID): 1739 The QuotaIDentifier Sub-Type is generated by the PrePaid server 1740 at allocation of a Volume and/or Duration Quota. The on-line 1741 quota update RADIUS Access-Request message sent from the SAD to 1742 the PPS shall include a previously received QuotaIDentifier. 1744 Sub-Type (=2): Sub-Type for VolumeQuota attribute 1745 Length : length of VolumeQuota attribute (= 6 octets) 1747 VolumeQuota (VQ): 1749 The optional VolumeQuota Sub-Type is only present if Volume Based 1750 charging is used. In RADIUS Access-Accept message (PPS to SAD 1751 direction), it indicates the Volume (in octets) allocated for the 1752 session by the PrePaid server. In RADIUS Authorize Only Access- 1753 Request message (SAD to PPS direction), it indicates the total 1754 used volume (in octets) for both forward and reverse traffic 1755 applicable to PrePaid accounting. 1757 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 1758 Length : length of VolumeQuotaOverflow attribute (= 4 octets) 1760 VolumeQuotaOverflow (VQO): 1762 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 1763 many times the VolumeQuota counter has wrapped around 2^32 over 1764 the course of the service being provided. 1766 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 1767 Length : length of VolumeThreshold attribute (= 6 octets) 1769 VolumeThreshold (VT): 1771 The VolumeThreshold Sub-Type shall always be present if 1772 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1773 SAD direction). It is generated by the PrePaid server and 1774 indicates the volume (in octets) that shall be used before 1775 requesting quota update. This threshold should not be larger than 1776 the VolumeQuota. 1778 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1779 Length : Length of VolumeThresholdOverflow attribute 1780 (= 4 octets) 1782 VolumeThresholdOverflow (VTO): 1784 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1785 how many times the VolumeThreshold counter has wrapped around 1786 2^32 over the course of the service being provided. 1788 Sub-Type (=6): Sub-Type for DurationQuota attribute 1789 Length : length of DurationQuota attribute (= 6 octets) 1791 DurationQuota (DQ): 1793 The optional DurationQuota Sub-Type is only present if Duration 1794 Based charging is used. In RADIUS Access-Accept message (PPS to 1795 SAD direction), it indicates the Duration (in seconds) allocated 1796 for the session by the PrePaid server. In on-line RADIUS Access- 1797 Accept message (PPC to PPS direction), it indicates the total 1798 Duration (in seconds) since the start of the accounting session 1799 related to the QuotaID. 1801 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1802 Length : length of DurationThreshold attribute (= 6 octets) 1804 DurationThreshold (DT): 1806 The DurationThreshold Sub-Type shall always be present if 1807 DurationQuota is present in a RADIUS Access-Accept message (PPS 1808 to SAD direction). It represents the duration (in seconds) that 1809 shall be used by the session before requesting quota update. This 1810 threshold should not be larger than the DurationQuota and shall 1811 always be sent with the DurationQuota. 1813 Sub-Type (=8): Sub-Type for Update-Reason attribute 1814 Length : length of Update-Reason attribute (= 4 octets) 1816 Update-Reason attribute (UR): 1818 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1819 Access-Request message (SAD to PPS direction). It indicates the 1820 reason for initiating the on-line quota update operation. Update 1821 reasons 4, 5, 6, 7 and 8 indicate that the associated resources 1822 are released at the client side, and therefore the PPS shall not 1823 allocate a new quota in the RADIUS Access_Accept message. 1825 1. Pre-initialization 1826 2. Initial Request 1827 3. Threshold Reached 1828 4. Quota Reached 1829 5. Remote Forced Disconnect 1830 6. Client Service Termination 1831 7. ôAccess Serviceö Terminated 1832 8. Service not established 1833 9. One-Time Charging 1835 Sub-Type (=9) : Sub-Type for PrePaidServer attribute 1836 Length : Length of PrePaidServer 1837 (IPv4 = 6 octets, IPv6= 18 octets 1839 PrePaidServer: 1841 The optional, multi-value PrePaidServer indicates the address of 1842 the serving PrePaid System. If present, the Home RADIUS server 1843 uses this address to route the message to the serving PrePaid 1844 Server. The attribute may be sent by the Home RADIUS server. If 1845 present in the incoming RADIUS Access-Accept message, the PDSN 1846 shall send this attribute back without modifying it in the 1847 subsequent RADIUS Access-Request message, except for the first 1848 one. If multiple values are present, the PDSN shall not change 1849 the order of the attributes. 1851 Sub-Type (=10) : Sub-Type for Service ID 1852 Length : Length of Service ID 1854 Service-Id: 1856 Opaque string that uniquely describes a service instance for which 1857 we want to apply prepaid metering to. A Service-Id could be an IP 1858 5-tuple (source address, source port, destination address, 1859 destination port, protocol). If Service-ID is present in the PPAQ 1860 the PPAQ applies to that Service. If a PPAQ does not contain a 1861 Service-Id then the PPAQ applies to the Access Service. 1863 Sub-Type (=11) : Sub-Type for Rating-Group-Id 1864 Length : 6 1866 Rating-Group-Id 1867 Identifies that this PPAQ is associated with resources allocated 1868 to a Rating Group with the corresponding ID. 1870 Sub-Type (=12) : Sub-Type for Termination-Action 1871 Length : 6 1873 This field is an enumeration of the action to take when the prepaid 1874 server does not grant additional quota. Valid actions are as 1875 follows: 1877 0 Reserved 1878 1 Terminate 1879 2 Request More Quota 1880 3 Redirect/Filter 1882 Sub-Type (=13) : Pool-Id 1883 Length : 6 1885 Identifies the Pool that this quota is to be associated with. 1887 Sub-Type (=14) : Pool-Multiplier 1888 Length : 6 1890 The pool-multiplier determines the weight that resources are 1891 inserted into the pool and the rate at which resources are taken out 1892 of the pool by this Service, or Rating-Group. 1894 Sub-Type (=13) : Sub-Type for Resource Quota 1895 Length : 6 1897 The optional ResourceQuota Sub-Type is only present if Resource 1898 Based charging is used or when One-Time charging is being used. 1899 In RADIUS Access-Accept message (PPS to SAD direction), it 1900 indicates the Resources allocated for the session by the PrePaid 1901 server. In RADIUS Authorize Only Access-Request message (SAD to 1902 PPS direction), it indicates the total used resource for both 1903 forward and reverse traffic applicable to PrePaid accounting. In 1904 one-time charging scenarios, the subtype represents the number of 1905 units to charge the user or to credit the user (negative values). 1907 Sub-Type (=14) : Sub-Type for Resource Quota Overflow 1908 Length : 6 1909 Sub-Type (=15) : Sub-Type for ResourceThreshold 1910 Length : 6 1912 NOTES: 1914 Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear in 1915 the attribute. 1916 Volume Threshold may only appear if Volume Quota appears 1918 A PPAQ MUST NOT CONTAIN both a Service-Id and a Rating-Group-Id. 1920 A PPAQ that does not contain a Service-ID or a Rating-Group-Id 1921 applies to the ôAccess Serviceö. 1923 When the PPAQ contains a Pool-Id it MUST also contain the Pool- 1924 Multiplier. 1926 5.4 1927 Prepaid Tariff Switching (PTS) 1929 This specification defines the PTS attribute to allow for 1930 changeovers from one service charge to another during service 1931 execution. 1933 Support for tariff switching is OPTIONAL for both PPC and PPS. PPCs 1934 use the flag "Tariff Switching supported" of the AvailableInClient 1935 subtype of the PPAC attribute to indicate support for tariff 1936 switching; PPSs employ the PTS attribute to announce their support 1937 for tariff switching. Details of this issue are specified later on, 1938 when the format of the PTS attribute has been defined. 1940 If a RADIUS message contains a PTS attribute, it MUST also contain 1941 at least one PPAQ attribute. This requirement is related to the 1942 identification of the service to which tariff switching applies. If 1943 a RADIUS Access-Request message contains a PTS attribute or if it 1944 contains a "Tariff Switching supported" flag, it MUST also contain 1945 an Event-Timestamp RADIUS attribute (see [RFC2869]). This 1946 requirement is related to the TariffSwitchInterval subtype of the 1947 PTS attribute (see below). 1949 0 1 2 3 1950 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 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | QuotaIDentifier (QID) | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | SUB-TYPE 2 | LENGTH | VolumeUsedAfter- | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | TariffSwitch (VUATS) | SUB-TYPE 3 | LENGTH | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | VUATSOverflow (VUATSO) | SUB-TYPE 4 | LENGTH | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | TariffSwitchInterval (TSI) | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | SUB-TYPE 5 | LENGTH | TimeIntervalAfter- | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | TariffSwitchUpdate (TITSU) | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 Type : Value of PTS 1970 Length: variable, greater than 8 1972 Subtype (=1): QuotaIDentifier (QID) 1973 Length : Length of QuotaIDentifier Subtype (= 6 octets) 1975 The QID subtype MUST be present in each PTS attribute. In an 1976 online RADIUS Access-Request message sent from the PPC to the 1977 PPS, its value MUST be a quota identifier received previously 1978 from the PPS and MUST be the same as a quota identifier of one of 1979 the PPAQ attributes included the same RADIUS message. 1981 A PPAQ attribute that is transported along with a PTS attribute 1982 and has the same quota identifier value as the PTS attribute in 1983 its own QID subfield shall be referred to as "accompanying PPAQ 1984 attribute". If a PPS receives an Access-Request message from a 1985 PPC, it associates a unique quota identifier to this service 1986 access request. Thus, a quota identifier also identifies a 1987 particular service. 1989 Subtype (=2): VolumeUsedAfterTariffSwitch (VUATS) 1990 Length : Length of VolumeUsedAfterTariffSwitch Subtype 1991 (= 6 octets) 1993 The VolumeUsedAfterTariffSwitch subtype SHALL be used in online 1994 RADIUS Access-Request messages (PPC to PPS direction). It 1995 indicates the volume (in octets) used during a session after the 1996 last tariff switch for the service specified via the QID subfield 1997 and the accompanying PPAQ attribute (see the remarks under 1998 "Subtype 1: QID"). 2000 Subtype (=3): VUATSOverflow (VUATSO) 2001 Length : Length of VUATSOverflow Subtype (= 4 octets) 2003 If an online RADIUS Access-Request message contains a VUATS 2004 subfield and if the VolumeUsedAfterTariffSwitch has wrapped 2005 around 2^32 over the course of provisioning the service 2006 identified via the QID subfield, then the VUATSO subfield MUST be 2007 present in the PTS attribute. In this case, it indicates how 2008 many times the VolumeUsedAfterTariffSwitch has wrapped around 2009 2^32. In all other cases, the VUATSO subfield MUST NOT be 2010 present in the PTS attribute. 2012 Subtype (=4): TariffSwitchInterval (TSI) 2013 Length : Length of TSI Subtype (= 6 octets) 2015 The TSI subtype MUST be present in each PTS attribute that is 2016 part of a RADIUS Access-Accept message (PPS to PPC direction). 2017 It indicates the interval (in seconds) between the value of 2018 Event-Timestamp RADIUS attribute (see [RFC2869]) of the 2019 corresponding RADIUS Access-Request message and the next tariff 2020 switch condition. 2022 Subtype (=5): TimeIntervalafterTariffSwitchUpdate (TITSU) 2023 Length : Length of TITSU Subtype 2024 (= 6 octets) 2026 The PPS MUST include the TITSU subtype if there is another tarrif 2027 switch period after this period. TITSU represents the length of 2028 the tariff switch period in seconds. If this attribute is 2029 omitted or is zero, the tariff period that commences in TSI 2030 seconds will last indefinitely or until a new PTS is received 2031 with new information. If TITSU is specified, the prepaid client 2032 must send a quota update before the end of the tariff switch 2033 period as specified by TITSU. 2035 If a RADIUS message contains a PTS attribute, it MUST also contain 2036 at least one PPAQ attribute. The PTS will be associated to the PPAQ 2037 by the QID. If multiple services are supported and if the PPAQ is 2038 associated with a service as indicated by the Service-Id sub- 2039 atrribute of the PPAQ, then the PTS will specify the tarrif switch 2040 for that service. If the PPAQ does not have a Service-Id, then the 2041 PTS will be the tarrif switch of the Access-Service. 2043 If a PPC supports tariff switching then it MUST set the 0x00000040 2044 (Tariff switching supported) flag of the AvailableInClient subtype 2045 of the PPAC attribute that is contained in the Access-Request packet 2046 starting the prepaid session. 2048 5.5 2049 Table of Attributes 2051 TO BE COMPLETED. 2053 Request Accept Reject Challenge # Attribute 2055 Authorize_Only Request Accept Reject 2057 6. 2058 Security Considerations 2060 The protocol exchanges described are susceptible to the same 2061 vulnerabilities as RADIUS and it is recommended that IPsec be 2062 employed to afford better security. 2064 If IPsec is not available the protocol in this draft improves the 2065 security of RADIUS. The various security enhancements are explained 2066 in the following sections. 2068 6.1 2069 Authentication and Authorization 2070 RADIUS is susceptible to replay attacks during the Authentication 2071 and Authorization procedures. A successful replay of the initial 2072 Access-Request could result in an allocation of an initial quota. 2074 To thwart such an attack... 2076 6.2 2077 Replenishing Procedure 2079 A successful replay attacks of the Authorize Only Access-Request 2080 could deplete the subscribers prepaid account. 2082 To be completed. 2084 7. 2085 IANA Considerations 2087 This document requires the assignment of new Radius attributes type 2088 numbers for the following attributes: 2090 1) Prepaid-Accounting-Capability (PPAC) 2091 with subtype: 2092 AvailableInClient 2094 2) Prepaid-Accounting-Operation (PPAQ) 2095 with subtypes: 2096 QuotaID (QID) 2097 VolumeQuota (VQ) 2098 VolumeQuotaOverflow (VQO) 2099 VolumeTreshold (VT) 2100 VolumeTresholdOverflow (VTO) 2101 DurationQuota (DQ) 2102 DurationTreshold (DT) 2103 UpdateReason (UR) 2104 PrePaidServer (PPS) 2105 ServiceID (SID) 2106 RatingGroupId (RGID) 2107 TerminationAction (TA) 2108 PoolID (PID) 2109 PoolMultiplier (PM) 2110 Cost (COST) 2111 TariffChangeTime (TCT) 2113 3) Prepaid-Tariff-Switch (PTS) 2114 4) Session-Termination-Capability (STC) 2116 5) International-Mobile-Subscriber-Identity (IMSI) 2118 8. 2119 Normative References 2121 [RFC2026] Bradner, S., "The Internet Standards Process -- 2122 Revision 3", RFC 2026, October 1996. 2123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2124 Requirement Levels", RFC 2119, March 1997. 2125 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 2126 "Remote Authentication Dial In User Server 2127 (RADIUS)", RFC 2865, June 2000. 2129 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2130 2000. 2132 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 2133 Extensions", RFC 2869, June 2000. 2135 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 2136 Holdrege, M., Goyret, I., "RADIUS Attributes for 2137 Tunnel Protocol Support" , RFC 2868, June 2000. 2138 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 2139 Aboba, B., "Dynamic Authorization Extensions to 2140 Remote Authentication Dial-In User Service 2141 (RADIUS)", RFC 3576, February 2003. 2143 [RFC3748] Aboba, B., et al., "Extensible Authentication 2144 Protocol", RFC 3748, June 2004. 2146 9. 2147 Informative References 2149 [DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control 2150 Application", Internet Draft, AAA WG, April 2004, 2151 Work in Progress. 2153 [REDIRECT] "RADIUS Redirection", Internet Draft, Work in 2154 progress. 2156 10. 2157 Call Flows 2159 This section includes call flows illustrating various scenarios 2160 enabled by this specification. 2161 The following are used in the call flows: 2163 RADIUS packets: 2165 AR Access Request 2166 ARA Access Accept 2167 AC Accounting Requests 2168 A Authorize-Only Access-Request 2169 AA Access-Accept for Authorize- 2170 Only Access-Request 2172 RADIUS Attributes: 2174 PPAQ PPAQ as defined in this 2175 specification 2176 SID One or more attributes 2177 representing the Session that 2178 the RADIUS packets is correlated 2179 to. 2180 PPAC PPAC as defined in this 2181 specification 2182 ASID Acct-Session-Id as defined by 2183 RADIUS 2184 MSID Acct-Multi-Session-Id as define 2185 by RADIUS 2187 PPAQ fields: 2189 SRVID Service-Id 2190 Reason Update-Reason 2191 QID Quota-Id 2193 10.1 2194 Simple Concurrent Services 2196 In this scenario the Prepaid Client authenticates and authorizes the 2197 user. The Prepaid Server responds back with Prepaid Quota for the 2198 ôAccess Serviceö instance. The NAS then request quota for Service- 2199 A. 2201 Accounting is turned on. 2203 NAS/ RADIUS/ 2204 PPC PPS 2205 === === 2206 | | 2207 | AR{SID,PPAC} | 2208 A |-------------------------------------------------->| 2209 | | 2210 | ARA{SID,PPAQ(QID=1,Q=100)} | 2211 B |<--------------------------------------------------| 2212 | | 2213 | AC(start){ASID=25,MSID=13} | 2214 C |-------------------------------------------------->| 2215 | | 2216 | A{SID,PPAQ(SRVID=SA, Reason=Initial} | 2217 D |-------------------------------------------------->| 2218 | | 2219 | AA{SID,PPAQ(QID=200,SRVID=SA, Q=50)} | 2220 E |<--------------------------------------------------| 2221 | | 2222 | AC(start){ASID=30,MSID=13, PPAQ } | 2223 F |-------------------------------------------------->| 2224 | | 2225 | A{SID, PPAQ(QID=200 SRVID=SA, Q=50 Reason=Quota)}| 2226 G |-------------------------------------------------->| 2227 | | 2228 | AA{SID,PPAQ(QID=300,SRVID=SA, Q=100)} | 2229 H |<--------------------------------------------------| 2230 | | 2231 | A{SID, | 2232 | PPAQ(QID=1, Q=100 Reason=Quota), | 2233 | PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} | 2234 I |-------------------------------------------------->| 2235 | | 2236 | AA{SID, 2237 | PPAQ(QID=3, Q=200), | 2238 | PPAQ(QID=303, SRVID=SA Q=150)} | 2239 J |<--------------------------------------------------| 2241 A This is the initial Access-Request that indicates the Prepaid 2242 Capabilities of the NAS. In this scenario it will indicate 2243 that Concurrent Session are supported. Access-Request also 2244 includes SID (Session Id) which is the Session Identifier 2245 assigned by this NAS to session. Session Identifier is out of 2246 scope in this document. It can be a single attribute such as 2247 3GPP2 Correlation ID or it could be a set of attributes that 2248 define a session. 2249 B RADIUS authenticates the user and determines that the user is 2250 prepaid. RADIUS responds with a PPAQ for the ôAccess Serviceö 2251 (PPAQ does not contain a Service-ID or Rating-Group-ID). The 2252 PPAQ has a QID=1 assigned by the Prepaid System and Quota of 2253 Q=100. The quota could be time or volume and may or may not 2254 have a threshold associated with it. 2255 C NAS starts the Access Service and generates an Accounting- 2256 Request (Start) message as normal. It will include the Acct- 2257 Session-Id and may include the Acct-Multi-Session-Id. 2258 D The NAS wants to start a new Service, call it Service-A. It 2259 sends an Authorize-Only access request to RADIUS. The SID 2260 links this Authorize-Only access request to the initial 2261 Authentication & Authorization (Step-A and Step-B).The 2262 Authorize-Only message contains a PPAQ requesting quota for 2263 Service-A, Update-Reason = Initial-Request. 2264 E PPS checks the resources available to the user and assigns 50 2265 units (time/volume etc) to this service. RADIUS sends an 2266 Access Accept message contain a PPAQ assigning quota Q=50 for 2267 Service-A. The PPAQ contains a QID = 200. 2268 F NAS starts Service-A and sends an Accounting-Request (Start) 2269 message for that service. Acct-Multi-Session-Id can be used 2270 to tie all of the sessions in the accounting streams together. 2271 G Quota for Service-A requires refreshing, the quota was 2272 completely used). An Authorize-Only message is sent 2273 containing a PPAQ with QID = 200 which corresponds to the 2274 prior QID received for this service. Note QID is sufficient 2275 for the PPS server to link this request to the previous 2276 request and hence to the original authentication steps. 2277 Therefore SID is not really required. The PPAQ will report the 2278 used part of the quota (50 units). 2279 H RADIUS deducts the used quota from the users accounts and 2280 reserves 50 more additional units for a total quota of 100 2281 (Q=100) for Service-A. It sends back a PPAQ with QID=300. 2282 I NAS needs to refresh both the ôAccess Serviceö and Service-A. 2283 It sends an Authorize Only message contain two PPAQs, one for 2284 the Main Service with QID=1 and one for Service-A with 2285 QID=300. Each PPAQ reports the used resources so far and the 2286 reason why the update is being sent. 2287 J RADIUS responds back with two PPAQs. The PPAQ without the 2288 Service-Id grants an additional 100 units for a total of 200 2289 units to the ôAccess Serviceö û QID=3; the other PPAQ, 2290 containing SRVID=SA grants an additional 50 units for a total 2291 quota to service-a of 150 units û QID=303. 2293 This step illustrates why SRVID needs to be specified in the 2294 PPAQ. If it were not, then the NAS would not be able to 2295 differentiate between the PPAQs. QIDs are not sufficient to 2296 correlate the PPAQ to a service since they are changed (and 2297 not necessarily sequentially) by the PPS at every transaction. 2299 In this scenario, notice how each PPAQ attribute represents a 2300 sequential conversation about a service between the Prepaid Client 2301 and the Prepaid Server. The links between the messages are the QIDs 2302 and the Service-Ids. 2304 As well, notice how a SID is needed to tie the Authorize-Only 2305 messages to the Authentication steps. This SID is only really 2306 needed the first time a PPAQ is sent û since the PPAQ does not have 2307 a QID. 2309 Accounting messages have an Accounting-Session-ID. But that is not 2310 enough to allow the back end system to associate that accounting 2311 message with a particular Service. We therefore need the PPAQ in 2312 the accounting message. 2314 10.2 2315 One-time Charging 2317 In this One-time charging scenario, the Prepaid Client (PPC) 2318 authenticates and authorizes the user and requests charging for a 2319 service event requested by the user. The PPC already knows the 2320 price to charge for the service event identified by SRVID=SA. 2322 Contributor 2324 We would like to thank Hannes Tschofenig for his contributions to 2325 this draft. 2327 Acknowledgments 2329 The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala 2330 and Tseno Tsenov for their contribution to this draft. 2332 Author's Addresses 2334 Avi Lior Parviz Yegani, Ph.D. 2335 Bridgewater Systems Mobile Wireless Group 2336 303 Terry Fox Drive Cisco Systems 2337 Suite 100 3625 Cisco Way 2338 Ottawa Ontario San Jose, CA 95134 2339 Canada USA 2340 avi@bridgewatersystems.com pyegani@cisco.com 2342 Kuntal Chowdhury Yong Li 2343 Starent Networks Bridgewater Systems 2344 30 International Place, 3rd Flr 303 Terry Fox Drive 2345 Tewksbury, MA 01876 Suite 100 2346 kchowdhury@starentnetworks.com Ottawa Ontario 2347 Canada 2348 Yong.li@bridgewatersystems.com 2350 Christian Guenther 2351 Siemens 2352 Otto-Hahn-Ring 6 2353 81739 Munich 2354 Germany 2355 christian.guenther@siemens.com 2357 Intellectual Property Statement 2359 The IETF takes no position regarding the validity or scope of any 2360 Intellectual Property Rights or other rights that might be claimed 2361 to pertain to the implementation or use of the technology described 2362 in this document or the extent to which any license under such 2363 rights might or might not be available; nor does it represent that 2364 it has made any independent effort to identify any such rights. 2365 Information on the IETF's procedures with respect to rights in IETF 2366 Documents can be found in BCP 78 and BCP 79. 2368 Copies of IPR disclosures made to the IETF Secretariat and any 2369 assurances of licenses to be made available, or the result of an 2370 attempt made to obtain a general license or permission for the use 2371 of such proprietary rights by implementers or users of this 2372 specification can be obtained from the IETF on-line IPR repository 2373 at http://www.ietf.org/ipr. 2375 The IETF invites any interested party to bring to its attention any 2376 copyrights, patents or patent applications, or other proprietary 2377 rights that may cover technology that may be required to implement 2378 this standard. Please address the information to the IETF at ietf- 2379 ipr@ietf.org. 2381 Disclaimer of Validity 2383 This document and the information contained herein are provided on 2384 an ôAS ISö basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2385 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2386 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2387 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2388 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2389 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2391 Copyright Statement 2393 Copyright ¨ The Internet Society (2005). This document is subject to 2394 the rights, licenses and restrictions contained in BCP 78, and 2395 except as set forth therein, the authors retain all their rights. 2397 Expiration Date 2399 This memo is filed as draft-lior-radius-extensions-for-prepaid- 2400 07.txt, and will expire 20 July, 2005.