idnits 2.17.00 (12 Aug 2021) /tmp/idnits64099/draft-lior-radius-prepaid-extensions-05.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 20. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1926. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 42), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** 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 65 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 Service Access Device MUST include the Message-Authenticator(80) attribute. The Service Access Device 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 (July 19, 2004) is 6514 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2284' is mentioned on line 581, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) -- Looks like a reference, but probably isn't: '3576' on line 1195 == Unused Reference: 'RFC2026' is defined on line 1699, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 1713, but no explicit reference was found in the text == Unused Reference: 'REDIRECT' is defined on line 1722, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) ** Obsolete normative reference: RFC 2284 (ref. 'REDIRECT') (Obsoleted by RFC 3748) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 INTERNET-DRAFT Bridgewater Systems 4 Category: Informational P. Yegani 5 draft-lior-radius-prepaid-extensions-05.txt Cisco 6 Expires: 17 January, 2005 K. Chowdhury 7 Nortel 8 Y. Li 9 Bridgewater Systems 10 July 19, 2004 12 PrePaid Extensions to Remote Authentication Dial-In User Service 13 (RADIUS) 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance 20 with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 17, 2005 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 The draft presents an extension to the Remote Authentication Dial-In 47 User Service (RADIUS) protocol to support PrePaid data services for 48 a wide range of deployments such as Dial, Wireless, WLAN. 49 Consideration for roaming using mobile-ip is also given. 51 Table of Contents 53 1. Introduction...................................................4 54 1.1 Terminology................................................6 55 1.2 Requirements language......................................6 56 2. Architectural Model............................................6 57 2.1 Why not existing RADIUS attributes?.......................12 58 3. Use-cases.....................................................14 59 3.1 Simple pre-paid access use-case...........................15 60 3.2 Support for Multi-Services................................17 61 3.3 Resource Pools............................................18 62 3.4 Support for Complex Rating Functions......................19 63 3.5 Support for Roaming.......................................20 64 3.6 PrePaid termination.......................................21 65 4. Operations....................................................21 66 4.1 General Requirements......................................21 67 4.1.1 Broker AAA Requirements..............................21 68 4.2 Authentication and Authorization for Prepaid Enabled Service 69 Access Devices................................................22 70 4.3 Session Start Operation...................................24 71 4.4 Mid-Session Operation.....................................25 72 4.5 Dynamic Operations........................................27 73 4.5.1 Unsolicited Session Termination Operation............27 74 4.5.2 Unsolicited Change of Authorization Operation........28 75 4.6 Termination Operation.....................................28 76 4.7 Mobile IP Operations......................................29 77 4.8 Operation consideration for Multi-Services................30 78 4.8.1 Initial Quota Request................................31 79 4.8.2 Quota Update.........................................31 80 4.8.3 Termination..........................................32 81 4.8.4 Dynamic Operations...................................32 82 4.8.5 Support for Resource Pools...........................32 83 4.8.6 Error Handling.......................................33 84 4.9 Accounting Considerations.................................33 85 4.10 Service Access Device Operation..........................33 86 4.11 Interoperability with Diameter Credit Control Application33 87 5. Attributes....................................................34 88 5.1 PPAC Attribute............................................34 89 5.2 Session Termination Capability............................35 90 5.3 PPAQ Attribute............................................35 91 5.4 Table of Attributes.......................................41 92 6. Security Considerations.......................................41 93 6.1 Authentication and Authorization..........................41 94 6.2 Replenishing Procedure....................................41 95 7. IANA Considerations...........................................42 96 8. Normative References..........................................42 97 9. Call Flows....................................................42 98 9.1 Simple Concurrent Services................................43 99 Acknowledgments..................................................46 100 Author's Addresses...............................................46 101 Intellectual Property Statement..................................47 102 Disclaimer of Validity...........................................47 103 Copyright Statement..............................................48 104 Expiration Date..................................................48 106 1. Introduction 108 This draft describes RADIUS protocol extensions supporting PrePaid 109 Data Services. 111 PrePaid data services are cropping up in many wireless and wireline 112 based networks. A PrePaid Data Service subscriber is one that 113 purchases a contract to receive a data service for either a period 114 of time, or a quantity of data. Before providing a prepaid data 115 service, the service provider checks that the prepaid subscriber has 116 sufficient funds to cover the particular service request. Only after 117 confirmation that funds are available is the service provided to the 118 user. 120 The subscriber purchases the Data Service using various means such 121 as buying a PrePaid Card, or online. How the subscriber purchases 122 their PrePaid Data Service depends on the deployment and is not in 123 scope for this document. 125 In some deployments, the PrePaid data service will be combined with 126 other Prepaid services such as PrePaid circuit voice service. This 127 is not an issue for this document other than the fact that the 128 PrePaid Data Services described in this paper should work with other 129 PrePaid data and or circuit voice services. 131 The fundamental business driver for a carrier to provide PrePaid 132 data services is to increase participation (subscriber base) and 133 thus to increase revenues. Therefore, it makes sense that PrePaid 134 services meet the following goals: 136 - Leverage existing infrastructure, hence reducing capital 137 expenditures typically required when rolling out a new service; 138 - Ability to rate service requests in real-time; 139 - Ability to check that the end userÆs account for coverage for the 140 requested service charge prior to execution of that service; 141 - Protect against revenue loss, i.e., prevent an end user from 142 generating chargeable events when the credit of that account is 143 exhausted or expired; 144 - Protect against fraud; 145 - Be as widely deployable over Dialup, Wireless and WLAN networks. 147 The protocol described in this document maximizes existing 148 infrastructure as much as possible û hence the use of the RADIUS 149 protocol. The protocol is used in ways to protect against revenue 150 loss or revenue leakage. This is achieved by defining procedures 151 for the real-time delivery of service information to a pre-paid 152 enabled AAA server, to minimize the financial risk, for the pre-paid 153 enabled AAA server to be able to allocate small quotas to each data 154 session and having the ability to update the quotas from a central 155 quota server dynamically during the lifetime of the PrePaid data 156 session. As well, mechanisms have been designed to be able to 157 recover from errors that occur from time to time. 159 Protection against fraud is provided by recording of accounting 160 records, by providing mechanisms to thwart replay attacks. As well, 161 mechanisms have been provided to terminate data sessions when fraud 162 is detected. 164 PrePaid System will become more prevalent and sophisticated as the 165 various networks such as Dialup, Wireless and WLAN converge. This 166 protocol extension is designed to meet the challenges of converged 167 networks. The draft mainly addresses how to use the RADIUS protocol 168 to achieve a PrePaid Data Service. The prepaid architecture assumes 169 that rating of chargeable events does not occur in the element 170 providing the service. This rating could be performed in the prepaid 171 enabled AAA server or may exist in an entity behind this AAA server. 172 Business logic and service rules may define that tariffing of events 173 vary in time, e.g., the particular price per megabyte download may 174 be defined to switch at 8pm from a high tariff to a low tariff. The 175 RADIUS extensions for prepaid support scenarios enable scalable 176 implementation of tariff switched prepaid systems. 178 Furthermore, the prepaid architecture assumes that a quota server is 179 available which, through co-ordination with the rating entity and 180 centralized balance manager is able to provide a quota response in 181 response for prepaid data service. This quota server functionality 182 could be performed in the prepaid enabled AAA server or may exist in 183 an entity behind this AAA server. Finally, the details of the 184 PrePaid System, such as its persistent store, how it maintains its 185 accounts are not covered at all. However, in order to define the 186 RADIUS protocol extensions it is necessary to discuss the functional 187 behavior of the PrePaid System. 189 1.1 Terminology 191 Service Access Device 192 PrePaid Client(PPC) 193 PrePaid Server(PPS) 194 Home agent (HA) 195 Home network 196 Home AAA (HAAA) 197 Broker AAA (BAAA) 198 Visited AAA (VAAA) 199 Foreign Agent (FA) 200 WLAN 201 Service Event 202 Access Service The service that is provided to the user 203 when the user is authenticated and 204 authorized. In this document the term is 205 used to differentiate between authorization 206 of services that are explicitly identified 207 by a Service Id. Example of Access Service 208 would be the Main Service instance of 3GPP2. 210 1.2 Requirements language 212 In this document, several words are used to signify the requirements 213 of the specification. These words are often capitalized. The key 214 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 216 this document are to be interpreted as described in [RFC2119]. 218 2. Architectural Model 220 The architectural model supports prepaid clients on a service access 221 device. A service access device (e.g. a NAS) typically provides a 222 access to data service to end-users. A service access device in an 223 entity on the data path that includes a RADIUS client. 225 When pre-paid service is used the service access device collects 226 service event information and reports it while and/or after services 227 are provided to the prepaid user. This event information is sent to 228 a prepaid server by using the prepaid RADIUS extensions. 230 If real-time credit control is required, the service access device 231 (prepaid client) contacts the prepaid server with service event 232 information included before the service is provided. The prepaid 233 server, depending on the service event information, performs credit 234 check and allocates a portion of available credit to the service 235 event. The rating entity converts this credit value into a time 236 and/or volume amount, which is then returned to the requesting 237 service access device. The rating entity may determine that during 238 the allocated quota, a tariff switch will occur in which case the 239 rating entity will include details of the quota allocated prior to 240 the tariff switch, details of the quota allocated after the tariff 241 switch together with details of when the tariff switch will occur. 243 The requesting service access device then monitors service execution 244 according to the instructions returned by the prepaid server. After 245 service completion or on a subsequent request for service, the 246 prepaid server deducts the reserved allocation of credit from the 247 prepaid userÆs account. 249 Similarly, when a user terminates an on-going prepaid service, the 250 prepaid client signals the prepaid server with the a value 251 corresponding to the unused portion of the allocated quota. The 252 prepaid server is then able to refund unused allocated funds into a 253 userÆs prepaid account. 255 There MAY be multiple prepaid servers in the system for reasons of 256 redundancy and load balancing. The system MAY also contain separate 257 rating server(s) and accounts MAY be located in a centralized 258 database. System internal interfaces can exist to relay messages 259 between servers and an account manager. However the detailed 260 architecture of prepaid system and its interfaces are implementation 261 specific and are out of scope of this specification. 263 accounting 264 +------------+ +-----------+ protocol +--------------+ 265 | Subscriber |<----->| Service | | | 266 | | | Access |<------------>| Accounting | 267 | Device | | Device |<-----+ | Server | 268 +------------+ +-----------+ | +--------------+ 269 | 270 | 271 | +--------------+ 272 +------>| PrePaid | 273 prepaid | Server | 274 protocol +--------------+ 276 Figure 1 Basic Prepaid Architecture 278 The prepaid server and accounting server in this architecture model 279 are logical entities. The real configuration MAY combine them into a 280 single host. 282 There MAY exist protocol transparent RADIUS Proxies between prepaid 283 client and prepaid server. These proxies transparently support the 284 prepaid RADIUS extensions. 286 In order to generalize the solution, in this paper we generalize the 287 Service Access Devices, which in reality may be a NAS in Dialup 288 deployments, PDSN (Packet Data Serving Node) or HA (Home Agent) in 289 CDMA2000 deployments, an 802.11 WLAN Access Points or GGSN (Gateway 290 GPRS Serving Node) in GPRS/UMTS deployments. To actively participate 291 in Prepaid procedures outlined here, the Service Access Device MUST 292 have the Prepaid Client capabilities. Prepaid Client Capabilities 293 include the ability to meter the usage for a prepaid data session; 294 this usage includes time or volume (e.g. number of bytes) usage. 296 In the case of roaming scenarios using mobile IP (in a wireless or 297 wireline network), the prepaid client functionality may be delegated 298 to the Home Agent. It may also be possible to deliver limited 299 prepaid services using RADIUS capabilities specified in RFC2865 and 300 RFC2866. 302 Furthermore, the device including the prepaid client functionality 303 may also have Dynamic Session Capabilities that include the ability 304 to terminate a data session and/or change the filters associated 305 with a specific data session by processing Disconnect Messages and 306 Change of Authorization messages as per [RFC3576]. 308 In this document RADIUS is used as the AAA server. There are three 309 kinds or categories of AAA servers. The AAA server in the home 310 network, the HAAA, is responsible for authentication of the 311 subscriber and also authorization of the service. In addition, the 312 HAAA communicates with the Prepaid servers using the RADIUS protocol 313 to authorize prepaid subscribers. In AAA based roaming deployments 314 the AAA server in the visited network, the VAAA, is responsible for 315 forwarding the RADIUS messages to the HAAA. The VAAA may also 316 modify the messages. In roaming deployments, the visited network 317 may be separated from the home network by one or more broker 318 networks. The AAA servers in the broker networks, BAAA are 319 responsible to route the RADIUS packets transparently and hence 320 donÆt play an active roll in the Prepaid Data Service delivery. 322 In this document the Prepaid Server is described in functional terms 323 related to their interface with the HAAA. The Prepaid Server 324 interfaces to entities which: 326 i) Keep the accounting state of the prepaid subscribers (balance 327 manager); 328 ii) Allow access service requests to be rated in real-time (Rating 329 Engine); and 330 iii) Allow quota to be managed for a particular pre-paid service 331 (Quota Server). 333 The various deployments for Prepaid are presented in the remainder 334 of this section. The first deployment is the basic Prepaid data 335 service and is depicted in figure 2. Here the Service Access Device 336 which supports the prepaid client functionality, the HAAA and the 337 Prepaid Server are collocated in the same provider network. 339 The Subscriber Device establishes a connection with one of several 340 Access Devices in the network. The Service Access Device 341 communicates with one or more HAAA servers in the network. To 342 provide redundancy more than one HAAA may be available to use by a 343 Service Access Device. 345 The network will have one or more Prepaid Servers. Multiple Prepaid 346 Servers may be used to provide redundancy and load sharing. The 347 interface between the HAAA and the PPS is implemented using the 348 RADIUS protocol in this specification. However, in cases where the 349 PPS does not implement the RADIUS protocol, the implementation would 350 have to map the requirements defined in this document to whatever 351 protocol is used between the HAAA and the PPS. 353 +------+ +-----+ 354 | | | | 355 +--------+ +--------+ +--| HAAA |--+--| PPS | 356 | | | | | | | | | | 357 | Sub | | Service| | +------+ | +-----+ 358 | |---| Access |--+ | 359 | Device | | Device | | +------+ | +-----+ 360 | | | | | | | | | | 361 +--------+ +--------+ +--| HAAA |--+--| PPS | 362 | | | | 363 +------+ +-----+ 365 Figure 2 Basic Prepaid Access Architecture 367 Figure 3 shows a static roaming prepaid architecture that is typical 368 of a wholesale scenario for Dial-Up users or a broker scenario used 369 in Dial-Up or WLAN roaming scenarios. 371 +----+ +----+ +----+ +-----+ 372 | | | | | | | | 373 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 374 | | | | | | | | | | | | | | | | 375 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 376 | |--|Access |-+ | | | 377 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 378 | | | | | | | | | | | | | | | | 379 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 380 | | | | | | | | 381 +----+ +----+ +----+ +-----+ 383 | Visited | |Broker | | Home | 384 | Network | |Network| | Network | 386 Figure 3 Static Roaming Prepaid Architecture 388 As in the basic prepaid architecture the subscriberÆs device 389 establishes a connection with the Service Access Device (NAS, WLAN 390 Access Point). The Service Access Device communicates with the 391 Visiting AAA server (VAAA) using the RADIUS protocol. Again for 392 redundancy there maybe more then one VAAA. The VAAA communicate 393 using the RADIUS protocol with AAA servers in the broker network 394 (BAAA). There maybe more then one Broker Network between the 395 Visited Network and the Home Network. The Home Network is the same 396 as in the simple architecture. 398 To support dynamic roaming the network will utilize Mobile-Ip as 399 illustrated in Figure 4. Note that typically the mobile device 400 would be moving between networks that use the same technology such 401 as Wireless or WLAN. Increasingly, device will be able to roam 402 between networks that use different technology such as between WLAN 403 and Wireless and Broadband. Fortunately, Mobile-Ip can address this 404 type of roaming and therefore we need not be concerned with the 405 underlying network technology. 407 +------+ +-------+ +----+ +----+ +----+ +-----+ 408 | | |Service| | | | | | | | | 409 |Sub | |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS | 410 | |--|Device | | | | | | | | | 411 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 412 | | | | | | 413 +------+ +------ + | | 414 | | | +----+ 415 | | | | | 416 |ROAMS +------------------+ HA | 417 | | | | 418 V +----+ | +----+ 419 +------+ +-------+ | | | | 420 | | |Service| +-|VAAA+------+ | 421 |Sub | |Access | | | | | 422 | |--|Device +-+ +----+ | 423 |Device| | (FA) | | 424 | | | +------------------------+ 425 +------+ +-------+ 427 Figure 4 Roaming using Mobile-IP and pre-paid enabled Service 428 Access Devices 430 In figure 4, the Subscriber device establishes a prepaid session 431 between the Service Access Device in the foreign network, which has 432 prepaid capabilities. The subscriberÆs home address will be 433 anchored at the Home Agent (HA) in the home network. The setup for 434 this access service is identical to the cases covered above. Notice 435 that the Service Access Device may be collocated with the Foreign 436 Agent (FA) in case of Mobile-IPv4. As the subscriber device moves 437 it establishes a connection with another Service Access Device in 438 the same foreign network or in another foreign network. The prepaid 439 data service should continue to be available. When a device 440 associates to another Service Access Device it MUST re-authenticate 441 at the new Service Access Device and de-associate or logoff from the 442 old Service Access Device. Furthermore, any unused quota at the old 443 Service Access Device MUST be promptly credited back to the 444 subscribers account. The reason we say promptly, is because if the 445 subscriber is very low on resources to start with, the subscriber 446 may not have enough resources to log on to the new Service Access 447 Device. The speed at which resources can be returned depend on the 448 type of handoff procedure that is used. Some of the example of 449 handoffs in wireless networks are dormant handoff, active handoff 450 and fast handoff. 452 As well, notice that if the Service Access Devices could communicate 453 with each other then there could be a way to accelerate a faster 454 handoff procedure. In particular, it could accelerate the return of 455 the unused portion of the quotas from the old Access Device. 457 Unfortunately, standards with regards to handoff are evolving with 458 each network technology creating their own scheme to make the 459 handoff procedures more efficient. 461 2.1 Why not existing RADIUS attributes? 463 It has been asked ôWhy not use existing RADIUS attributes to build a 464 prepaid solution? This will allow us to have a solution with 465 existing devices without code modification.ö 467 It is possible to build a prepaid solution using existing RADIUS 468 attributes. The RADIUS server can simply send an Access-Accept 469 message containing Session-Timeout(27) and set Termination- 470 Action(29) to RADIUS-request. Upon receiving the Access-Accept 471 message, the NAS will meter the duration of the session and upon 472 termination of the session the NAS generate an Access-Request 473 message again. The RADIUS server would re-authenticate the session 474 and reply with an Access-Accept message with additional time in 475 Session-Timeout(27) or an Access-Reject message if there were no 476 more resources in the userÆs account. 478 If the user terminates the session before the time expressed in 479 Session-Timeout(27). The NAS will recover any unused time from the 480 accounting stream. 482 There are several problems with such a solution: 484 -It only allows for time-based prepaid. The solution presented in 485 this document allows for both time and volume based prepaid. As 486 well as extensibility for other features such as tarified based 487 solutions. 489 -Using accounting messages to recoup unused time may be problematic 490 because RADIUS accounting messages are not real-time. A RADIUS 491 server may store-and-forward accounting messages in batches. The 492 solution presented in this paper does not rely on Accounting Packets 493 at all. It uses Access-Request, messages which do flow through any 494 network in real-time. Delaying accounting messages may cause 495 revenue leakage. 497 -Session-Timeout(27) is not a mandatory attribute. If a prepaid 498 subscriber is being serviced by a NAS that does not adhere to 499 Session-Timeout then that subscriber will obtain unlimited service. 501 -Termination-Action(29) presents its own issues. First the 502 behaviour of Termination-Action(29) is not mandatory. Second, 503 according to RFC2865 Termination-Action fires when the Service is 504 complete. But we should not be terminating the service while 505 negotiating additional quota. The refreshing of the time quota 506 should be transparent to the user. Because Termination-Action 507 occurs when the Service is complete it is unclear whether or not the 508 user experience would be transparent. For example, will the RADIUS 509 server allocate the subscriber a new IP address? Furthermore, the 510 RADIUS server has no way of telling why the Access-Request message 511 was generated. The RADIUS server will have to wait for the 512 corresponding accounting packet to determine the reason for this 513 Access-Request message. Lastly re-authenticating the subscriber may 514 take far too long. The solution presented in this document allows 515 quota replenishing to occur in an undisruptive manner from the 516 perspective of the user. No re-authentication is required and 517 quotas can be negotiated prior to the quotas running out. 519 -Prepaid ambiguity. Implementing prepaid using existing RADIUS 520 attributes presents another problem. Due to the fact that the 521 standard RADIUS attributes are not mandatory, then the correct 522 prepaid operation is really an act of faith on the part of the 523 RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) 524 are not supported, the prepaid subscriber will get free access. The 525 solution described in this document, requires that a prepaid capable 526 Service Access Device inform the RADIUS server whether or not it 527 supports prepaid capabilities. The RADIUS server can now determine 528 whether service should be granted or not. For example, if a prepaid 529 subscriber is connected to a NAS that does not support prepaid, the 530 RADIUS server can either instruct the NAS to tunnel the traffic to 531 another entity in the home network that does support prepaid client 532 function (e.g. Home Agent) or it may allow the subscriber to get 533 access but restrict the traffic. 535 The prepaid solution we present is a robust carrier grade prepaid 536 solution. It only requires the support of 2 mandatory attributes 537 and one optional attribute. Furthermore, it does not really 538 require much code support at the NAS. NASes already support 539 measurement of time and volume. This solution requires that they 540 advertise their prepaid capabilities in an Access-Request; that they 541 generate an Access-Request Authorize-Only packet to obtain more 542 quota at or before the quota is used up. It also requires that the 543 NAS send an Access-Request with Authorize-Only when the session 544 terminates to return any unused quota to the prepaid system. 546 Lastly the solution provided in this document is extensible. This 547 document defines the basic exchanges between a prepaid capable NAS 548 and a RADIUS server. The protocol can easily be extended to support 549 tariff switching and other prepaid business models. 551 3. Use-cases 553 In this section we present a set of use cases that will help 554 establish the requirements needed to deliver PrePaid data services. 555 These use cases donÆt address how the PrePaid account is established 556 or maintained. It is assumed that the PrePaid subscriber has 557 obtained a valid account from a service provider such as a wireless 558 operator or a WLAN operator. 560 To make the document as general as possible, the use cases cover the 561 experience from the Service Access Device and not from the UserÆs 562 Device. The connection between the UserÆs Device, which typically 563 involves setting up a layer 2 session, e.g., PPP session or GPRS PDP 564 Context, is specific to a given network technology and the details 565 are not required to deliver a PrePaid service. 567 3.1 Simple pre-paid access use-case 569 A PrePaid subscriber connects to his home network. As usual, the 570 Access Device that is servicing the subscriber will use the AAA 571 infrastructure to authenticate and authorize the subscriber. 573 The Service Access Device sends a RADIUS Access-Request to the AAA 574 system to authenticate the subscriber, and identify and authorize 575 the service. The Access-Request includes the subscriberÆs 576 credentials and may include the PrePaid capabilities of the Service 577 Access Device. PrePaid capabilities MUST be included if the Service 578 Access Device supports PrePaid functionality. 580 The AAA System proceeds with the authentication procedure. This may 581 involve several transactions such as in EAP [RFC2284]. Once the 582 subscriber has been authenticated, the AAA system determines that 583 the subscriber is a PrePaid subscriber and requests that the PrePaid 584 System authorize the PrePaid subscriber. The request MUST include 585 the PrePaid Capabilities of the serving Service Access Device. 587 The PrePaid System will validate that the subscriber has a PrePaid 588 Account; it will validate that the account is active; and will 589 validate that the Service Access Device has the appropriate PrePaid 590 capabilities. If all is in order, the PrePaid System will authorize 591 the subscriber to use the network. Otherwise it will reject the 592 request. The response is sent back to the AAA System. The response 593 includes attributes to indicate the allocation of a portion of the 594 subscriberÆs account called the initial quota (in units of time or 595 volume) and optionally a threshold value. 597 The reason we allocate a portion of the userÆs account is that the 598 user may be engaged in other Services that may draw on the same 599 Prepaid account. For example the user may be engaged in a data 600 session and a voice session. Although, these two services would 601 draw from the same account the involved separate parts of the 602 system. If the entire quota was allocated to the data session then 603 the user would have no more funds for a voice session. 605 The AAA system incorporates the PrePaid attributes received from the 606 PrePaid System into an Access-Accept message that it sends back to 607 the Service Access Device. Note the AAA System is responsible for 608 authorizing the service whereas the PrePaid System is responsible 609 for PrePaid authorization. 611 Upon receiving the Access-Response, the Service Access Device allows 612 the PrePaid data session to start and it starts to meter the session 613 based on time or volume, as indicated in the returned Quota 615 Once the usage for the session approaches the allotted quota (as 616 expressed by the threshold), the Service Access Device will request 617 an additional quota. The re-authorization for additional quota 618 flows through the AAA system to the PrePaid System. The PrePaid 619 System revalidates the subscriberÆs account; it will subtract the 620 previous quota allocation from the userÆs account balance and if 621 there is a balance remaining it will reauthorize the request with an 622 additional quota allotment. Otherwise, the PrePaid System will 623 reject the request. Note the replenishing of the quotas is a re- 624 authorization procedure and does not involve re-authentication of 625 the subscriber. 627 It is important to note that the PrePaid System is maintaining 628 session state for the subscriber. This state includes how much 629 account balance was allocated during the last quota allocation for a 630 particular session and how much is left in the account. Therefore, 631 it is required that all subsequent messages about the PrePaid 632 session reach the correct PrePaid System. 634 Upon receiving a re-allotment of the quota, the Service Access 635 Device will, continue the data service session until the new 636 threshold is reached. If the request for additional quota cannot be 637 fulfilled then the Service Access Device will let the subscriber use 638 up the remaining quota and terminate the session. 640 Alternatively, instead of terminating the session, the Service 641 Access Device may restrict the data session such that the subscriber 642 can only reach a particular web server. This web server maybe used 643 to allow the subscriber to replenish their account. This 644 restriction can also be used to allow new subscribers to purchase 645 their initial PrePaid Service. 647 Should the subscriber terminate the session before the quota is used 648 up, the remaining balance allotted to the session must be credited 649 back to the subscriberÆs account. 651 As well, while the Access Device is waiting for the initial quota, 652 the subscriber may have dropped the session. The initial quota must 653 be credited back to the subscribers account. 655 3.2 Support for Multi-Services 657 Up to now we were looking at session that consisted of a single 658 service, ôAccess Serviceö. An ôAccess Serviceö is the basic service 659 that is provided to the user by the Service Access Device after 660 successful authentication and authorization. When we donÆt 661 differentiate between different types of services the ôAccess 662 Serviceö aggregates all the services that the user my be engaged in 663 on a particular Service Access Device. For example, the user may be 664 browsing the web, and participating in a VoIP conversation, watching 665 streaming video and downloading a file. 667 Some operators may want to distinguish these Services. Some 668 services are billed at different rates and Services maybe metered 669 differently. Therefore, the prepaid solution needs to be able to 670 distinguish Services, and allocate quotas to the Services using 671 different units (e.g. time, volume) and allow for those quotas to be 672 utilized at different rates. 674 +---------+ 675 | Session | 676 +---------+ 677 | 678 V N 679 +--------------+ +-------+ 680 | Service |------>| Quota | 681 | (service-Id) | +-------+ 682 +--------------+ 684 As shown in the above diagram, a Session can have N Services. Each 685 service is identified by a Service-Id. The format of the Service-Id 686 is not in the scope of this document but the Service-Id could be 687 expressed as an IP flow using the IP 5-tuple (Source-IP and Port, 688 the Destination-IP and Port, and the protocol). Each Service is 689 allocated a Quota appropriate to the service. 691 3.3 Resource Pools 693 When working with multiple services which results in multiple quota 694 allocation another problem arises. Even though quotas are portioned 695 out in fractional parts of the users prepaid account, there could be 696 a situation where one Service utilizes its quota faster then another 697 Service. When the userÆs account is used up, there could be a 698 situation where one Service is unable to obtain additional quota 699 while another Service has plenty of quota remaining. Unless the 700 quotas can be rebalanced, the Service Access Device would then have 701 to terminate that Service. As well, even before that happens, the 702 existence of several Services could generate an excessive amount of 703 traffic as the services update their quotas. 705 One method to solve these problems is to utilize resource pools. 706 Resource pools allow us to allocate resources to several services of 707 a session by allocating resources to a pool and have services draw 708 their quota from the pool at a rate appropriate to that service. 709 When the quota allocated to the pool runs out, we replenish the 710 pool. 711 +-----------+ 712 | Service-A |-----+ +--------+ 713 +-----------+ | Ma | | 714 +-------->| | 715 | Pool | 716 +-------->| (1) | 717 +-----------+ | Mb | | 718 | Service-B |-----+ +--------+ 719 +-----------+ 721 As the above figure shows, Service-A and Service-B is bound to 722 Pool(1). Ma and Mb are the pool multipliers (that are associated 723 with Service-A and Service-B respectively) that determines the rate 724 at which Service-A and Service-B draw from the pool. 726 The pool is initialized by taking the quota allocated to each 727 service and multiplying it by Mn. Therefore, the amount of 728 resources allocated to a pool is given by: 730 Poolr = Ma*Qa + Mb*Qb + . . . 732 A Pool is empty if: 734 Poolr <= Ca*Ma + Cb*Mb + . . . 736 where: 737 Ca,Cb are the consumed resources of Service-A and Service-B 738 respectively. 740 Note that the resources assigned to the pool are unit less. That 741 is, Service-A can be rated at $1 per Mbyte and Service-B can rated 742 at $0.10 per Minute. In this case if we allocate $5 worth of 743 resources on behalf of service-A to the pool we would set Ma = 10 744 and place 50 units into the pool. If we allocate $5 on behalf of 745 Service-B to the Pool, then M=1 and place 50 units into the Pool. 746 The pool would have a total sum of 100 units to be shared between 747 the two services. Each Mbyte used by Service-A will draw 10 units 748 from the pool and each minute used by Service-B will draw 1 unit 749 from the pool. 751 3.4 Support for Complex Rating Functions 753 The rate of use of a resource by a service can be very complex. 754 Some services use resources (e.g. time, volume) linearly. For 755 example, a service maybe consuming resources at a rate of $1 per 756 Mbyte. 758 In some cases an operator may wish to apply a much more complex 759 rating function. For example, a service provider may wish to rate a 760 service such that the first N Mbytes are free, then the next M 761 Mbytes are rated at $1 per Mbyte and volume above M bytes be rated 762 at $0.50 per Mbyte. This rating function could be achieved by 763 repeated message exchanges with the Prepaid System. 765 To avert the need to exchange many messages and to support even more 766 complex rating functions we support Rating Groups. A Rating Group 767 is provisioned at the Service Access Device. As illustrated in the 768 figure below, a Rating Group is associated with one or more Services 769 and defines the rate that the services associated with the Rating 770 Group consume the quota. 772 +-----------+ 773 | Service-A |------+ 774 +-----------+ | +--------------+ +-------+ 775 +---->| | | Quota | 776 | Rating Group |------>| or | 777 +-----------+ +---->| | | Pool | 778 | Service-B |------+ +--------------+ +-------+ 779 +-----------+ 781 During authorization of the of a service, if the service is 782 associated with a Rating Group, the Prepaid Client sends the Rating 783 Group to the Prepaid Server. The prepaid service authorizes the 784 Rating Group by assigning it a Quota and optionally assigning it to 785 a Resource Pool. 787 When service that belongs to an authorized Rating Group is 788 instantiated, then the Prepaid Client does not need to authorize 789 that service. This could greatly reduce the amount of traffic 790 between the Prepaid Client and the Prepaid Server. 792 3.5 Support for Roaming 794 For some networks it is essential that PrePaid Data Services be 795 offered to roaming subscribers. Support for static and dynamic 796 roaming models are needed. Static roaming is where the subscriber 797 logs onto a foreign network. The foreign network has a roaming 798 agreement directly with the home network or through a broker network 799 or networks. The subscriber remains logged into the network until 800 the subscriber changes location. When changing location a new 801 connection and a new login procedure is required. 803 Dynamic roaming allows to subscriber to move between networks while 804 maintaining a connection with the home network seamlessly. As the 805 subscriber moves between networks, the data session is handed off 806 between the networks. 808 In both roaming scenarios, the subscriber always authenticates with 809 the home network. PrePaid authorization and quota replenishing for 810 the session need to be received at the home network and more 811 specifically at the PrePaid System where state is being maintained. 813 Dynamic roaming is particularly challenging. A subscriber that 814 established a PrePaid Data Session may roam to another Access Device 815 that doesnÆt not support PrePaid functionality. The system should 816 be capable to continue the PrePaid session. 818 3.6 PrePaid termination 820 When fraud is detected by the PrePaid System, or when an error is 821 detected, it may be beneficial for the PrePaid system to terminate a 822 specific session for the subscriber or all the sessions of a 823 subscriber. 825 Some errors can occur such that the PrePaid System is in a state 826 where it is not sure whether the session is in progress or not. 827 Under conditions such as this, the PrePaid system may wish to 828 terminate the PrePaid data session to make sure that resources are 829 not being utilized for which it canÆt charge for reliably. 831 Some handoff procedure used during dynamic roaming may require that 832 the PrePaid system explicitly terminate the subscribers PrePaid data 833 session at an Service Access Device. For example, if time based 834 PrePaid service is being used and the mobile subscriber performs a 835 dormant handoff, the PrePaid System needs to explicitly terminate 836 the PrePaid session at the old Service Access Device. 838 4. Operations 840 4.1 General Requirements 842 4.1.1 Broker AAA Requirements 844 Broker AAA servers MUST support the Message-Authenticator(80) 845 attribute as defined in [RFC2869]. If BAAA servers are used, the 846 BAAA servers function is to forward the RADIUS packets as usual to 847 the appropriate RADIUS servers. 849 Accounting messages are not needed to deliver a PrePaid service. 850 However, accounting messages can be used to keep the PrePaid Server 851 current as to what is happening with the PrePaid data session. 852 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 853 pass through mode described in [RFC2866]. 855 4.2 Authentication and Authorization for Prepaid Enabled Service Access 856 Devices 858 The Service Access Device initiates the authentication and 859 authorization procedure by sending a RADIUS Access-Request to the 860 HAAA. 862 If the Service Access Device has PrePaid Client capabilities, it 863 MUST include the PPAC(TBD) attribute in the RADIUS Access-Request. 864 The PPAC(TBD) attribute indicates to the PrePaid server the PrePaid 865 capabilities possessed by the Service Access Device. These are 866 required in order to complete the PrePaid authorization procedures. 868 If the Service Access Device supports the Disconnect-Message or the 869 Change-of-Authorization capabilities, then it SHOULD include the 870 Dynamic-Capabilities attribute. 872 In certain deployments, there may be other ways in which to 873 terminate a data session, or change authorization of an active 874 session. For example, some Service Access Devices provide a session 875 termination service via Telnet or SNMP. In these cases, the AAA 876 server MAY add the Dynamic-Capabilities message to the Access- 877 Request. Upon receiving the Change-of-Authorization message, the 878 AAA server would then be responsible for terminating the session 879 using whatever means that are supported by the device. 881 If the authentication procedure involves multiple Access-Requests 882 (as in EAP), the Service Access Device MUST include the PPAC(TBD) 883 attribute and the Dynamic-Capabilities attribute (if used) in at 884 least the last Access-Request of the authentication procedure. 886 The Access-Request will be sent as usual to the HAAA. The packet 887 may be proxied through zero or more BAAA. 889 Once the Access-Request arrives at the HAAA, the HAAA will 890 authenticate the subscriber. If the subscriber is cannot be 891 authenticated, the HAAA will send an Access-Reject message back to 892 the client. If the subscriber is authenticated, the HAAA will 893 determine whether or not the subscriber is a PrePaid subscriber. 894 The techniques used to determine whether or not a subscriber is a 895 PrePaid subscriber is beyond the scope of this document. If the 896 subscriber is not a PrePaid subscriber, then the HAAA will respond 897 as usual with an Access-Accept or Access-Reject message. If the 898 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 899 Access-Request to a PrePaid server for further authorization. 901 The Access-Request will contain the PPAC(TBD) attribute, the 902 Dynamic-Capabilities attribute if one was included; the User-Name(1) 903 attribute MAY be set to a value that would represent the 904 SubscriberÆs PrePaid Identity. This attribute is used by the 905 PrePaid server to locate the PrePaid SubscriberÆs account. For 906 added security, the HAAA MAY also set the User-Password(2) attribute 907 to the password used between the HAAA and the PrePaid server. 909 The PrePaid server lookups the subscriberÆs PrePaid account and will 910 authorize the subscriber taking into consideration the Service 911 Access Device PrePaid Client Capabilities. 913 Upon successful authorization, the PrePaid server will generate an 914 Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD) 915 attribute. 917 The PPAC attribute returned to the client indicates the type of 918 prepaid service to be provided for the session. The PPAQ(TBD) 919 attribute includes: 921 - The QUOTA-Id, which is set by the PrePaid server to a unique 922 value that is used to correlate subsequent quota requests; 924 - Volume and/or Time quotas, which are set to a value representing a 925 portion of the subscribers account; 927 - MAY contain a Time or Volume Threshold that controls when the 928 Service Access Device requests additional quota; 930 - The IP address of the Serving PrePaid Server and one or more 931 alternative PrePaid Servers. This is used by the HAAA to route 932 subsequent quota replenishing messages to the appropriate PrePaid 933 server(s). 935 Note: Idle-Timeout(28) can be used to trigger the premature 936 termination of a pre-paid service following subscriber inactivity. 938 Depending on site policies, upon unsuccessful authorization, the 939 PrePaid server will generate an Access-Reject to terminate the 940 session immediately. Alternatively, the PrePaid server may generate 941 an Access-Accept blocking some or all of the traffic and/or redirect 942 some or all of the traffic to a location where the subscriber can 943 replenish their account for a period of time. Blocking of traffic 944 is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect 945 I-d). Redirection is achieved by sending Redirect-Id or Redirect- 946 Rule defined in the Redirect I-d. The period of time before the 947 blocked/redirected session last can be specified by Session- 948 Timeout(27) attribute. 950 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 951 will append the usual service attributes and forward the packet to 952 the Service Access Device. The HAAA SHOULD NOT overwrite any 953 attributes already set by the PrePaid server. If the HAAA, receives 954 an Access-Reject message, it will simply forward the packet to its 955 client. Depending on site policies, if the HAAA fails to receive an 956 Access-Accept or Access-Reject message from the PrePaid server it 957 MAY do nothing or send an Access-Reject or an Access-Accept message 958 back to its client. 960 4.3 Session Start Operation 962 The real start of the session is indicated by the arrival of 963 Accounting-Request(Start) packet. The Accounting-Request (Start) 964 MAY be routed to the PrePaid Server so that it can confirm the 965 initial quota allocation. 967 Note that the PrePaid Server role is not to record accounting 968 messages and therefore it SHOULD not respond with an Accounting 969 Response packet. 971 If the Prepaid server does not receive the Accounting-Request(start) 972 message it will only know that the session has started upon the 973 first reception of a quota replenishment operation. 975 If the Prepaid server does not receive indication directly (via 976 Accounting-Request(start)) or indirectly, it SHOULD after some 977 configurable time, deduce that the Session has not started. If the 978 Service Access Device supports termination capabilities, the PPS 979 SHOULD send a Disconnect Message to the Service Access Device to 980 ensure that the session is indeed dead. 982 4.4 Mid-Session Operation 984 During the lifetime of a PrePaid data session the Service Access 985 Device will request to replenish the quotas using Authorize-Only 986 Access-Request messages. 988 Once the allocated quota has been reached or the threshold has been 989 reached, the Service Access Device MUST send an Access-Request with 990 Service-Type(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD) 991 attribute. 993 The Service Access Device MUST also include NAS identifiers, and 994 Session identifier attributes in the Authorize Only Access-Request. 995 The Session Identifier should be the same as those used during the 996 Access-Request. For example, if the User-Name(1) attribute was used 997 in the Access-Request it MUST be included in the Authorize Only 998 Access-Request especially if the User-Name(1) attribute is used to 999 route the Access-Request to the Home AAA server. 1001 The Authorize Only Access-Request MUST not include either User 1002 Password or Chap Password. In order to authenticate the message, 1003 the Service Access Device MUST include the Message-Authenticator(80) 1004 attribute. The Service Access Device will compute the value for the 1005 Message-Authenticator based on [RFC2869]. 1007 When the HAAA receives the Authorize-Only Access-Request that 1008 contains a PPAQ(TBD), it SHALL validate the message using the 1009 Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an 1010 Authorize Only Access-Request that contains a PPAQ(TBD) but not a 1011 Message-Authenticator(80) it SHALL silently discard the message. An 1012 Authorize Only Access-Request message that does not contain a 1013 PPAQ(TBD) is either in error or belongs to another application (for 1014 example, a Change of Authorization message [RFC3576]). In this case 1015 the Authorize Only Access-Request will either be silently discarded 1016 or handled by another application (not in scope of this document). 1018 Once the Authorize Only Access-Request message is validated, the 1019 HAAA SHALL forward the Authorize Only Access-Request to the 1020 appropriate PrePaid Server. The HAAA MUST forward the Authorize 1021 Only Access-Request to the PrePaid server specified in the 1022 PPAQ(TBD). The HAAA MUST sign the message using the Message- 1023 Authenticator(80) and the procedures in [RFC2869]. As with the 1024 Access-Request message, the HAAA MAY modify the User-Name(1) 1025 attribute to a value that represents the userÆs internal PrePaid 1026 account in the PrePaid server. Note the PrePaid server could use 1027 the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate 1028 the user account. 1030 Upon receiving the Authorize Only Access-Request containing a 1031 PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- 1032 Authenticator(80) as prescribed in [RFC2869]. If the message is 1033 invalid, the PrePaid server MUST silently discard the message. If 1034 it received an Authorize Only Access-Request message that does not 1035 contain a PPAQ(TBD) it MUST silently discard the message. 1037 The PrePaid server will lookup the PrePaid session by using the 1038 PrePaid Quota Id contained within the PPAQ(TBD). The PrePaid Server 1039 would, take the last allocated quota and subtract that from the 1040 UserÆs balance. If there is remaining balance, the PrePaid server 1041 re-authorizes the PrePaid session by allocate an additional quota. 1042 The PrePaid server may want to calculate a different threshold 1043 values as well. 1045 Upon successful re-authorization, the PrePaid server will generate 1046 an Access-Accept containing the PPAQ(TBD) attribute. The Access- 1047 Accept message MAY contain Service-Type(6) set to Authorize-Only and 1048 MAY contain the Message-Authenticator(80). 1050 Depending on site policies, upon unsuccessful authorization, the 1051 PrePaid server will generate an Access-Reject or an Access-Accept 1052 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 1053 and the Session-Timeout(27) attribute such that the PrePaid 1054 subscriber could get access to a restricted set of locations for a 1055 short duration to allow them to replenish their account, or create 1056 an account; or to browse free content. 1058 Upon receiving the Access-Accept from the PrePaid server, the HAAA 1059 SHALL return the packet to its client. If the HAAA, receives an 1060 Access-Reject message, it will forward the packet. Depending on 1061 site policies, if the HAAA fails to receive an Access-Accept or an 1062 Access-Reject message from the PrePaid server it MAY do nothing or 1063 it MAY send an Access-Reject message back to its client. 1065 Upon receiving an Access-Accept, the Service Access Device SHALL 1066 update its quotas and threshold parameters with the values contained 1067 in the PPAQ(TBD) attribute. Note that the PrePaid server MAY update 1068 the PrePaidServer attribute(s) and these may have to be saved as 1069 well. 1071 Upon receiving an Access-Accept message containing either Filter- 1072 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 1073 The Service Access Device SHALL restrict the subscriber session 1074 accordingly. 1076 4.5 Dynamic Operations 1078 The PrePaid server may want to take advantage of the dynamic 1079 capabilities that are supported by the Service Access Device as 1080 advertised in the Dynamic-Capabilities attribute during the initial 1081 Access-Request. 1083 There are two types of actions that the PrePaid server can perform: 1084 it can request that the session be terminated; or it can request 1085 that attributes associated with the session be modified. More 1086 specifically, it can modify previously sent PPAQ(TBD) 1088 Both of these actions require that the session be uniquely 1089 identified at the Service Access Device. As a minimum the PrePaid 1090 server: 1092 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 1093 -MUST provide at least one session identifier such as User-Name(1), 1094 Framed-IP-Address(), the Accounting-Session-Id(44). 1096 Other attributes could be used to uniquely identify a PrePaid data 1097 session. 1099 For a discussion on Dynamic Operations as they related Mutli-Service 1100 operations see further on. 1102 4.5.1 Unsolicited Session Termination Operation 1103 At anytime during a session the Prepaid Server may send a Disconnect 1104 Message to terminate a session. This capability is described in 1105 detail in [RFC3576]. The PrePaid server sends a Disconnect Message 1106 that MUST contain identifiers that uniquely identify the 1107 subscriberÆs data session and the Service Access Device servicing 1108 that session. 1110 If the Service Access Device receives a Disconnect-Message, it will 1111 respond with either a Disconnect-ACK packet if it was able to 1112 terminate the session or else it will respond with a Disconnect-NAK 1113 packet. 1115 Upon successful termination of a session the Service Access Device 1116 MUST return any unused quota to the Prepaid Server by issuing an 1117 Authorize Only Access-Request containing the PPAQ which contains any 1118 unused Quota and the Update-Reason set to ôRemote Forced 1119 Disconnectö. 1121 4.5.2 Unsolicited Change of Authorization Operation 1123 At anytime during the prepaid session the Prepaid Client may receive 1124 a Change of Authorization (CoA) message. A Prepaid Server may send 1125 a new Quota to either add additional quota or to remove quota 1126 already allocated for the service. 1128 If the Change of Authorization contains a PPAQ then that PPAQ will 1129 override a previously received PPAQ. The PPAQ may contain more 1130 allocated Quota or less allocated quota. The PPS MUST NOT change 1131 the units used in the PPAQ. 1133 If the newly received PPAQ reduces the amount of allocated quota 1134 beyond what is currently used then the Service Access Device will 1135 accept the new PPAQ and act as it normally would when the quota is 1136 used up. For example, if the threshold is reached then is request a 1137 quota update; if the quota received is less then the currently used 1138 level then the Service Access Device would follow the normal 1139 procedures followed when a quota is used up. 1141 4.6 Termination Operation 1142 The termination phase is initiated when either: the Subscriber logs 1143 off; the quotas have been consumed, or when the Service Access 1144 Device receives a Disconnect Message. 1146 In the case where the user logged off, or the Service Access Device 1147 receives a Disconnect Message, the Service Access Device will send 1148 an Authorize-Only Access-Request message with a PPAQ(TBD) and 1149 Update-Reason attribute set to either ôClient Service terminationö 1150 or ôRemote Forced disconnectö and the currently used quota. 1152 In the case where the quota has been reached, if the PPAQ(TBD) 1153 contained Termination-Action field, the Service Access Device will 1154 follow the specified action which would be to immediately terminate 1155 the service, to request more quota, or to Redirect/Filter the 1156 service. 1158 4.7 Mobile IP Operations 1160 In roaming scenarios using Mobile-IP, as the mobile subscriber roams 1161 between networks, or between different types of networks such as 1162 between WLAN and CDMA2000 networks, the PrePaid data session should 1163 be maintained transparently if the HA is acting as the Service 1164 Access Device. 1166 As the subscriber device associates with the new Service Access 1167 Device (AP or PDSN that supports prepaid client capability), the 1168 Service Access Device sends a RADIUS Access-Request and the 1169 subscriber is re-authenticated and reauthorized. The Service Access 1170 Device MUST include the PPAC(TBD) attribute in the RADIUS Access- 1171 Request. In this manner the procedure follows the Authentication 1172 and Authorization procedure described earlier. 1174 If the HA was acting as the Service Access Device before handoff, 1175 the userÆs prepaid session does not undergo any change after the 1176 handoff because the Mobile IP session is anchored at the HA and the 1177 userÆs Home IP address remains the same. 1179 In the case of AP or PDSN acting as the Service Access Device it is 1180 likely that the userÆs IP address will change (Care of Address). 1181 Therefore, the ongoing prepaid session will have some impact. In the 1182 case the Service Access Device shall send an Access-Request. 1183 The Access-Request message is routed to the home network and MUST 1184 reach the PrePaid System that is serving the PrePaid session. The 1185 PrePaid system will then correlate the new authorization request 1186 with the existing active session and will assign a quota to the new 1187 request. Any outstanding quota at the old Service Access Device 1188 MUST be returned to the PrePaid system. If the Mobile-IP nodes (HA 1189 and FA) supports registration revocation (Mobile IPv4 only). 1190 Specifically, the quota SHOULD be returned when the Service Access 1191 Device sends the Authorize Only Access-Request with PPAQ(TBD) 1192 Update-Reason set to either ôRemote Forced disconnectö or ôClient 1193 Service terminationö. In order to trigger the sending of this last 1194 Authorize Only Access-Request, the PrePaid system may issue a 1195 Disconnect Message [3576] to the Service Access Device. 1197 If the subscriber has roamed to an Service Access Device that does 1198 not have any PrePaid Capabilities, PrePaid data service may still be 1199 possible by requesting the Home Agent (providing it has PrePaid 1200 Capabilities) to assume responsibilities for metering the service. 1201 The procedure for this scenario will be given in the next release of 1202 this draft. 1204 4.8 Operation consideration for Multi-Services 1206 This section describes the operation for supporting Prepaid for 1207 multi-services on the same Service Access Device. The operations 1208 for multi-services are very similar to operations for single 1209 service. Message flows illustrating the various interactions are 1210 presented at the end of this document. 1212 A Service Access Device that supports prepaid operations for multi- 1213 services SHOULD set the ôMulti-Services Supportedö bit in the PPAC. 1215 When working with multi-services, we need to differentiate between 1216 the services. A Service-Id attribute is used in the PPAQ(TBD) to 1217 uniquely differentiate between the services. The exact definition 1218 of the Service-Id attribute is out of scope for this document. 1220 A PPAQ that contains a Service-Id is associated with that Service. 1221 A PPAQ that contains a Rating-Group-Id is associated with that 1222 Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a 1223 Service-Id. A PPAQ that contains neither a Rating-Group-Id or a 1224 Service-Id applies to the ôAccess Serviceö. 1226 4.8.1 Initial Quota Request 1228 When operations with multi-services is desired, the Service Access 1229 Device will request the initial quota for the Service by sending a 1230 PPAQ containing the Service-Id for that Service in an Authorize-Only 1231 Access-Request packet. Similarly, if the Service Access Device 1232 supports Rating-Groups then it may request a prepaid quota for the 1233 Rating-Group by sending a PPAQ containing the Rating-Group-Id. In 1234 both cases the Update-Reason will be set to ôInitial-Requestö. 1236 The Authorize-Only Access-Request packet may contain more than one 1237 PPAQ. The Authorize-Only Access-Request MUST include one or more 1238 attributes that serve to identify the session so that it can be 1239 linked to the original authentication. Which Session Identifier(s) 1240 is included is up to specific deployments. The Authorize-Only 1241 message must contain the Message-Authenticator(80) attribute for 1242 integrity protection of the Authorize-Only Access-Request message. 1244 Upon receiving an Authorize-Only Access-Accept message containing 1245 one or more PPAQs the Prepaid System will allocate resources to each 1246 PPAQ. The resources, can be in units of time, volume as before. 1247 Each PPAQ will be assigned a unique QID that MUST appear in a 1248 subsequent PPAQ update for that service or rating-group. As well, 1249 the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if 1250 the PPAQ applies to the ôAccess Serviceö. 1252 4.8.2 Quota Update 1254 Once the services start to utilize their allotted quota they will 1255 eventually need to replenish their quotas (either the threshold is 1256 reached or no more quota remains). To replenish the quota the 1257 Prepaid Client will send an Authorize-Only Access-Request message 1258 containing one or more PPAQs. Each PPAQ MUST contain the 1259 appropriate QID, Service-ID or Group-ID (or neither the Service-ID 1260 or Group-Id if the quota replenishment is for the ôAccess Serviceö). 1261 The Update-Reason filed will indicate either ôThreshold reachedö(3), 1262 or ôQuota reachedö(4). The Authorize-Only message must contain 1263 identifiers to identify the session. 1265 Upon receiving an Authorize-Only Access-Request packet with one or 1266 more PPAQs the Prepaid Server will respond with a new PPAQ for that 1267 service. The PPAQ will contain a new QID, the Service-Id or Rating- 1268 Group-Id, a new Quota. If the Prepaid Server does not want to grant 1269 additional quota to the Service it MUST include the Termination- 1270 Action subfield in the PPAQ that will instruct the Service Access 1271 Device what to do with the service. 1273 4.8.3 Termination 1275 When an allotted quota for the service is used up the Service Access 1276 Device shall act in accordance to the Termination-Action field set 1277 in the Quota. If the Termination-Action field is absent then the 1278 Service MUST be terminated. 1280 If the Service is to be terminated then the Service Access Device 1281 shall send a PPAQ with the appropriate QID, the Service-Id, the used 1282 quota, and Update-Reason set to ôClient Service Terminationö. 1284 If the ôAccess Serviceö has terminated, then all other services must 1285 be terminated as well. In this case the Service Access Device must 1286 report on all issued quotas for the various services. The Update- 1287 Reason field should be set to ôAccess Service Terminatedö. 1289 Note when sending more then on PPAQ it may be required to send 1290 multiple Authorize Only Access-Requests. 1292 4.8.4 Dynamic Operations 1294 Dynamic operations for multi-services are similar to dynamic 1295 operations described for single service operations. The prepaid 1296 system may send a COA message containing a PPAQ for an existing 1297 service instance. The Service Access Device will match the PPAQ to 1298 the service using the Service-ID attribute. The new quota could be 1299 higher then the last allocated value or it could be lower. The 1300 Service Access Device must react to the new quota accordingly. 1302 A Disconnect message may not be send for a specific service. A 1303 disconnect message terminates the ôAccess Serviceö. As such the 1304 Service Access Device must report back all unused quotas by sending 1305 an Authorize Only Access Request message containing a PPAQ for each 1306 active service. The Update-Reason shall indicate that the reason 1307 for the update reason. 1309 4.8.5 Support for Resource Pools 1310 If the Prepaid Client supports pools as indicated by setting the 1311 ôPools supportedö bit in the PPAC(TBD) then the Prepaid Server may 1312 associate a Quota with a Pool by including the Pool-Id and the Pool- 1313 Multiplier in the PPAQ(TBD). 1315 When Resource Pools are used, the PPAQ must not use the threshold 1316 field. 1318 4.8.6 Error Handling 1320 If the Prepaid Server receives a PPAQ with an invalid QID it MUST 1321 ignore that PPAQ. 1323 If the Prepaid Server receives a PPAQ containing a Service-Id, or a 1324 Rating-Group-Id that it does not recognize, then it MUST ignore that 1325 PPAQ. 1327 If the Prepaid Client receives a PPAQ containing a Service-Id, or a 1328 Rating-Group-Id that it does not recognize, then it must ignore that 1329 PPAQ. 1331 If the Prepaid Client receives a PPAQ that contains a Pool-Id 1332 without a Pool-Multiplier; or a Pool-Multiplier without a Pool-Id it 1333 must ignore that PPAQ. 1335 4.9 Accounting Considerations 1337 Accounting messages are not required to deliver PrePaid Data 1338 Service. Accounting message will typically be generated for PrePaid 1339 Data Service. This because accounting message are used for auditing 1340 purposes as well as for bill generation. 1342 Accounting messages associated with PrePaid Data Sessions should 1343 include the PPAQ(TBD) attribute. 1345 4.10 Service Access Device Operation 1347 To be completed 1349 4.11 Interoperability with Diameter Credit Control Application 1351 RADIUS PrePaid solutions need to interoperate with Diameter 1352 protocol. Two possibilities exist: The AAA infrastructure is 1353 Diameter based and the Service Access Device are RADIUS based; or 1354 the Service Access Device is Diameter based and the AAA 1355 infrastructure is RADIUS based. 1357 The Diameter Credit Control Application [DIAMETERCC] describes how 1358 to implement a PrePaid using an all Diameter based infrastructure. 1360 1362 5. Attributes 1364 This draft is using the RADIUS [RFC2865] namespace. 1366 5.1 PPAC Attribute 1368 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1369 Access-Request message by a Prepaid Capable NAS and is used to 1370 describe the PrePaid capabilities of the NAS. The PPAC is available 1371 to be sent in an Access-Accept message by the Prepaid server to 1372 indicate the type of prepaid metering that is to be applied to this 1373 session. 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | AvailableInClient (AiC) | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 TYPE : value of PPAC 1384 LENGTH: 8 1385 VALUE : String 1387 The value MUST be encoded as follows: 1389 Sub-Type (=1) : Sub-Type for AvailableInClient attribute 1390 Length : Length of AvailableInClient attribute 1391 (= 6 octets) 1392 AvailableInClient (AiC): 1394 The optional AvailableInClient Sub-Type, generated by the PrePaid 1395 client, indicates the PrePaid Accounting capabilities of the NAS and 1396 shall be bitmap encoded. The possible values are: 1398 0x00000001 Volume metering supported. 1399 0x00000002 Duration metering supported. 1400 0x00000004 Resource metering supported. 1401 0x00000008 Pools supported 1402 0x00000010 Rating groups supported 1403 0x00000020 Multi-Services supported. 1405 Others Reserved 1407 5.2 Session Termination Capability 1409 The value shall be bitmap encoded rather than a raw integer. This 1410 attribute shall be included RADIUS Access-Request message to the 1411 RADIUS server and indicates whether or not the NAS supports Dynamic 1412 Authorization. 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | TYPE | LENGTH | String | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Type : value of Session Termination Capability 1421 Length: = 4 1422 String encoded as follows: 1424 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1425 supported. 1427 5.3 PPAQ Attribute 1429 One or more PPAQ(TBD) attributes are available to be sent in 1430 Authorize Only Access-Request and Access-Accept messages. In 1431 Authorize Only Access-Request messages it is used to report usage 1432 and request further quota or request prepaid quota for a new service 1433 instance; in an Access-Accept message it is used to allocate the 1434 quotas (initial quota and subsequent quotas). 1436 When concurrent service are supported a PPAQ is associated with a 1437 specific service as indicated by the presence of Service-Id; or a 1438 Rating Group, as indicated by the presence of a Rating-Group-Id; or 1439 the ôAccess Serviceö as indicated by the absence of a Service-Id or 1440 a Rating-Group-Id. 1442 The attribute consists of a number of subtypes. Subtypes not used 1443 are omitted in the message. 1445 0 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | QuotaIdentifier (QID) | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | SUB-TYPE 2 | LENGTH | Volume Quota | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Volume Quota | SUB-TYPE 3 | LENGTH | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | VolumeThreshold (VT) | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | SUB-TYPE 6 | LENGTH | DurationQuota (DQ) | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | DurationThreshold (DT) | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | SUB-TYPE 9 | LENGTH | PrePaidServer | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | PrePaidServer | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Type : Value of PPAQ 1475 Length: variable, greater than 8 1477 String: The String value MUST be encoded as follows: 1479 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 1480 Length : Length of QuotaIDentifier attribute (= 6 octets) 1482 QuotaIDentifier (QID): 1484 The QuotaIDentifier Sub-Type is generated by the PrePaid server 1485 at allocation of a Volume and/or Duration Quota. The on-line 1486 quota update RADIUS Access-Request message sent from the Service 1487 Access Device to the PPS shall include a previously received 1488 QuotaIDentifier. 1490 Sub-Type (=2): Sub-Type for VolumeQuota attribute 1491 Length : length of VolumeQuota attribute (= 6 octets) 1493 VolumeQuota (VQ): 1495 The optional VolumeQuota Sub-Type is only present if Volume Based 1496 charging is used. In RADIUS Access-Accept message (PPS to Service 1497 Access Device direction), it indicates the Volume (in octets) 1498 allocated for the session by the PrePaid server. In RADIUS 1499 Authorize Only Access-Request message (Service Access Device to 1500 PPS direction), it indicates the total used volume (in octets) 1501 for both forward and reverse traffic applicable to PrePaid 1502 accounting. 1504 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 1505 Length : length of VolumeQuotaOverflow attribute (= 4 octets) 1507 VolumeQuotaOverflow (VQO): 1509 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 1510 many times the VolumeQuota counter has wrapped around 2^32 over 1511 the course of the service being provided. 1513 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 1514 Length : length of VolumeThreshold attribute (= 6 octets) 1516 VolumeThreshold (VT): 1518 The VolumeThreshold Sub-Type shall always be present if 1519 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1520 Service Access Device direction). It is generated by the PrePaid 1521 server and indicates the volume (in octets) that shall be used 1522 before requesting quota update. This threshold should not be 1523 larger than the VolumeQuota. 1525 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1526 Length : Length of VolumeThresholdOverflow attribute 1527 (= 4 octets) 1529 VolumeThresholdOverflow (VTO): 1531 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1532 how many times the VolumeThreshold counter has wrapped around 1533 2^32 over the course of the service being provided. 1535 Sub-Type (=6): Sub-Type for DurationQuota attribute 1536 Length : length of DurationQuota attribute (= 6 octets) 1538 DurationQuota (DQ): 1540 The optional DurationQuota Sub-Type is only present if Duration 1541 Based charging is used. In RADIUS Access-Accept message (PPS to 1542 Service Access Device direction), it indicates the Duration (in 1543 seconds) allocated for the session by the PrePaid server. In on- 1544 line RADIUS Access-Accept message (PPC to PPS direction), it 1545 indicates the total Duration (in seconds) since the start of the 1546 accounting session related to the QuotaID. 1548 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1549 Length : length of DurationThreshold attribute (= 6 octets) 1551 DurationThreshold (DT): 1553 The DurationThreshold Sub-Type shall always be present if 1554 DurationQuota is present in a RADIUS Access-Accept message (PPS 1555 to Service Access Device direction). It represents the duration 1556 (in seconds) that shall be used by the session before requesting 1557 quota update. This threshold should not be larger than the 1558 DurationQuota and shall always be sent with the DurationQuota. 1560 Sub-Type (=8): Sub-Type for Update-Reason attribute 1561 Length : length of Update-Reason attribute (= 4 octets) 1563 Update-Reason attribute (UR): 1565 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1566 Access-Request message (Service Access Device to PPS direction). 1567 It indicates the reason for initiating the on-line quota update 1568 operation. Update reasons 4, 5, 6, 7 and 8 indicate that the 1569 associated resources are released at the client side, and 1570 therefore the PPS shall not allocate a new quota in the RADIUS 1571 Access_Accept message. 1573 1. Pre-initialization 1574 2. Initial Request 1575 3. Threshold Reached 1576 4. Quota Reached 1577 5. Remote Forced Disconnect 1578 6. Client Service Termination 1579 7. ôAccess Serviceö Terminated 1580 8. Service not established 1582 Sub-Type (=9) : Sub-Type for PrePaidServer attribute 1583 Length : Length of PrePaidServer 1584 (IPv4 = 6 octets, IPv6= 18 octets 1586 PrePaidServer: 1588 The optional, multi-value PrePaidServer indicates the address of 1589 the serving PrePaid System. If present, the Home RADIUS server 1590 uses this address to route the message to the serving PrePaid 1591 Server. The attribute may be sent by the Home RADIUS server. If 1592 present in the incoming RADIUS Access-Accept message, the PDSN 1593 shall send this attribute back without modifying it in the 1594 subsequent RADIUS Access-Request message, except for the first 1595 one. If multiple values are present, the PDSN shall not change 1596 the order of the attributes. 1598 Sub-Type (=10) : Sub-Type for Service ID 1599 Length : Length of Service ID 1601 Service-Id: 1603 Opaque string that uniquely describes a service instance for which 1604 we want to apply prepaid metering to. A Service-Id could be an IP 1605 5-tuple (source address, source port, destination address, 1606 destination port, protocol). If Service-ID is present in the PPAQ 1607 the PPAQ applies to that Service. If a PPAQ does not contain a 1608 Service-Id then the PPAQ applies to the Access Service. 1610 Sub-Type (=11) : Sub-Type for Rating-Group-Id 1611 Length : 6 1613 Rating-Group-Id 1615 Identifies that this PPAQ is associated with resources allocated 1616 to a Rating Group with the corresponding ID. 1618 Sub-Type (=12) : Sub-Type for Termination-Action 1619 Length : 6 1621 This field is an enumeration of the action to take when the prepaid 1622 server does not grant additional quota. Valid actions are as 1623 follows: 1625 0 Reserved 1626 1 Terminate 1627 2 Request More Quota 1628 3 Redirect/Filter 1630 Sub-Type (=13) : Pool-Id 1631 Length : 6 1633 Identifies the Pool that this quota is to be associated with. 1635 Sub-Type (=14) : Pool-Multiplier 1636 Length : 6 1638 The pool-multiplier determines the weight that resources are 1639 inserted into the pool and the rate at which resources are taken out 1640 of the pool by this Service, or Rating-Group. 1642 NOTES: 1644 Either Volume-Quota or Time-Quota MUST appear in the attribute. 1646 Volume Threshold may only appear if Volume Quota appears 1648 A PPAQ MUST NOT CONTAIN both a Service-Id and a Rating-Group-Id. 1650 A PPAQ that does not contain a Service-ID or a Rating-Group-Id 1651 applies to the ôAccess Serviceö. 1652 When the PPAQ contains a Pool-Id it MUST also contain the Pool- 1653 Multiplier. 1655 5.4 Table of Attributes 1657 TO BE COMPLETED. 1659 Request Accept Reject Challenge # Attribute 1661 Authorize_Only Request Accept Reject 1663 6. Security Considerations 1665 The protocol exchanges described are susceptible to the same 1666 vulnerabilities as RADIUS and it is recommended that IPsec be 1667 employed to afford better security. 1669 If IPsec is not available the protocol in this draft improves the 1670 security of RADIUS. The various security enhancements are explained 1671 in the following sections. 1673 6.1 Authentication and Authorization 1675 RADIUS is susceptible to replay attacks during the Authentication 1676 and Authorization procedures. A successful replay of the initial 1677 Access-Request could result in an allocation of an initial quota. 1679 To thwart such an attack... 1681 6.2 Replenishing Procedure 1683 A successful replay attacks of the Authorize Only Access-Request 1684 could deplete the subscribers prepaid account. 1686 To be completed. 1688 7. IANA Considerations 1690 To be completed. 1692 This draft does create RADIUS attributes. However, the authors 1693 recognize that it may not be possible to obtain such attributes. 1694 Therefore, in subsequent drafts it will be proposed to use a Vendor 1695 space as an Application Space. 1697 8. Normative References 1699 [RFC2026] Bradner, S., "The Internet Standards Process -- 1700 Revision 3", RFC 2026, October 1996. 1701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1702 Requirement Levels", RFC 2119, March 1997. 1703 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1704 "Remote Authentication Dial In User Server 1705 (RADIUS)", RFC 2865, June 2000. 1707 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1708 2000. 1710 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1711 Extensions", RFC 2869, June 2000. 1713 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1714 Holdrege, M., Goyret, I., "RADIUS Attributes for 1715 Tunnel Protocol Support" , RFC 2868, June 2000. 1716 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1717 Aboba, B., "Dynamic Authorization Extensions to 1718 Remote Authentication Dial-In User Service 1719 (RADIUS)", RFC 3576, February 2003. 1721 [DIAMETERCC] Work in Progress. 1722 [REDIRECT] RADIUS Redirection Internet Draft. Work in progress. 1723 RFC 2284 EAP 1725 9. Call Flows 1726 This section includes call flows illustrating various scenarios 1727 enabled by this specification. 1728 The following are used in the call flows: 1730 RADIUS packets: 1732 AR Access Request 1733 ARA Access Accept 1734 AC Accounting Requests 1735 A Authorize-Only Access-Request 1736 AA Access-Accept for Authorize- 1737 Only Access-Request 1739 RADIUS Attributes: 1741 PPAQ PPAQ as defined in this 1742 specification 1743 SID One or more attributes 1744 representing the Session that 1745 the RADIUS packets is correlated 1746 to. 1747 PPAC PPAC as defined in this 1748 specification 1749 ASID Acct-Session-Id as defined by 1750 RADIUS 1751 MSID Acct-Multi-Session-Id as define 1752 by RADIUS 1754 PPAQ fields: 1756 SRVID Service-Id 1757 Reason Update-Reason 1758 QID Quota-Id 1760 9.1 Simple Concurrent Services 1762 In this scenario the Prepaid Client authenticates and authorizes the 1763 user. The Prepaid Server responds back with Prepaid Quota for the 1764 ôAccess Serviceö instance. The NAS then request quota for Service- 1765 A. 1767 Accounting is turned on. 1769 NAS/ RADIUS/ 1770 PPC PPS 1771 === === 1772 | | 1773 | AR{SID,PPAC} | 1774 A |-------------------------------------------------->| 1775 | | 1776 | ARA{SID,PPAQ(QID=1,Q=100)} | 1777 B |<--------------------------------------------------| 1778 | | 1779 | AC(start){ASID=25,MSID=13} | 1780 C |-------------------------------------------------->| 1781 | | 1782 | A{SID,PPAQ(SRVID=SA, Reason=Initial} | 1783 D |-------------------------------------------------->| 1784 | | 1785 | AA{SID,PPAQ(QID=200,SRVID=SA, Q=50)} | 1786 E |<--------------------------------------------------| 1787 | | 1788 | AC(start){ASID=30,MSID=13, PPAQ } | 1789 F |-------------------------------------------------->| 1790 | | 1791 | A{SID, PPAQ(QID=200 SRVID=SA, Q=50 Reason=Quota)}| 1792 G |-------------------------------------------------->| 1793 | | 1794 | AA{SID,PPAQ(QID=300,SRVID=SA, Q=100)} | 1795 H |<--------------------------------------------------| 1796 | | 1797 | A{SID, | 1798 | PPAQ(QID=1, Q=100 Reason=Quota), | 1799 | PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} | 1800 I |-------------------------------------------------->| 1801 | | 1802 | AA{SID, 1803 | PPAQ(QID=3, Q=200), | 1804 | PPAQ(QID=303, SRVID=SA Q=150)} | 1805 J |<--------------------------------------------------| 1807 A This is the initial Access-Request that indicates the Prepaid 1808 Capabilities of the NAS. In this scenario it will indicate 1809 that Concurrent Session are supported. Access-Request also 1810 includes SID (Session Id) which is the Session Identifier 1811 assigned by this NAS to session. Session Identifier is out of 1812 scope in this document. It can be a single attribute such as 1813 3GPP2 Correlation ID or it could be a set of attributes that 1814 define a session. 1815 B RADIUS authenticates the user and determines that the user is 1816 prepaid. RADIUS responds with a PPAQ for the ôAccess Serviceö 1817 (PPAQ does not contain a Service-ID or Rating-Group-ID). The 1818 PPAQ has a QID=1 assigned by the Prepaid System and Quota of 1819 Q=100. The quota could be time or volume and may or may not 1820 have a threshold associated with it. 1821 C NAS starts the Access Service and generates an Accounting- 1822 Request (Start) message as normal. It will include the Acct- 1823 Session-Id and may include the Acct-Multi-Session-Id. 1824 D The NAS wants to start a new Service, call it Service-A. It 1825 sends an Authorize-Only access request to RADIUS. The SID 1826 links this Authorize-Only access request to the initial 1827 Authentication & Authorization (Step-A and Step-B).The 1828 Authorize-Only message contains a PPAQ requesting quota for 1829 Service-A, Update-Reason = Initial-Request. 1830 E PPS checks the resources available to the user and assigns 50 1831 units (time/volume etc) to this service. RADIUS sends an 1832 Access Accept message contain a PPAQ assigning quota Q=50 for 1833 Service-A. The PPAQ contains a QID = 200. 1834 F NAS starts Service-A and sends an Accounting-Request (Start) 1835 message for that service. Acct-Multi-Session-Id can be used 1836 to tie all of the sessions in the accounting streams together. 1837 G Quota for Service-A requires refreshing, the quota was 1838 completely used). An Authorize-Only message is sent 1839 containing a PPAQ with QID = 200 which corresponds to the 1840 prior QID received for this service. Note QID is sufficient 1841 for the PPS server to link this request to the previous 1842 request and hence to the original authentication steps. 1843 Therefore SID is not really required. The PPAQ will report the 1844 used part of the quota (50 units). 1845 H RADIUS deducts the used quota from the users accounts and 1846 reserves 50 more additional units for a total quota of 100 1847 (Q=100) for Service-A. It sends back a PPAQ with QID=300. 1848 I NAS needs to refresh both the ôAccess Serviceö and Service-A. 1849 It sends an Authorize Only message contain two PPAQs, one for 1850 the Main Service with QID=1 and one for Service-A with 1851 QID=300. Each PPAQ reports the used resources so far and the 1852 reason why the update is being sent. 1853 J RADIUS responds back with two PPAQs. The PPAQ without the 1854 Service-Id grants an additional 100 units for a total of 200 1855 units to the ôAccess Serviceö û QID=3; the other PPAQ, 1856 containing SRVID=SA grants an additional 50 units for a total 1857 quota to service-a of 150 units û QID=303. 1859 This step illustrates why SRVID needs to be specified in the 1860 PPAQ. If it were not, then the NAS would not be able to 1861 differentiate between the PPAQs. QIDs are not sufficient to 1862 correlate the PPAQ to a service since they are changed (and 1863 not necessarily sequentially) by the PPS at every transaction. 1865 In this scenario, notice how each PPAQ attribute represents a 1866 sequential conversation about a service between the Prepaid Client 1867 and the Prepaid Server. The links between the messages are the QIDs 1868 and the Service-Ids. 1870 As well, notice how a SID is needed to tie the Authorize-Only 1871 messages to the Authentication steps. This SID is only really 1872 needed the first time a PPAQ is sent û since the PPAQ does not have 1873 a QID. 1875 Accounting messages have an Accounting-Session-ID. But that is not 1876 enough to allow the back end system to associate that accounting 1877 message with a particular Service. We therefore need the PPAQ in 1878 the accounting message. 1880 Acknowledgments 1882 The authors would like to thank Mark Grayson (Cisco) and Nagi 1883 Jonnala for their contribution to this draft. 1885 Author's Addresses 1887 Avi Lior Parviz Yegani, Ph.D. 1888 Bridgewater Systems Mobile Wireless Group 1889 303 Terry Fox Drive Cisco Systems 1890 Suite 100 3625 Cisco Way 1891 Ottawa Ontario San Jose, CA 95134 1892 Canada USA 1893 avi@bridgewatersystems.com pyegani@cisco.com 1895 Kuntal Chowdhury Yong Li 1896 Nortel Networks Bridgewater Systems 1897 2221, Lakeside Blvd, 303 Terry Fox Drive 1898 Richardson, TX-75082 Suite 100 1899 chowdury@nortelnetworks.com Ottawa Ontario 1900 Canada 1901 Yong.li@bridgewatersystems.com 1903 Intellectual Property Statement 1905 The IETF takes no position regarding the validity or scope of any 1906 Intellectual Property Rights or other rights that might be claimed 1907 to pertain to the implementation or use of the technology described 1908 in this document or the extent to which any license under such 1909 rights might or might not be available; nor does it represent that 1910 it has made any independent effort to identify any such rights. 1911 Information on the IETF's procedures with respect to rights in IETF 1912 Documents can be found in BCP 78 and BCP 79. 1914 Copies of IPR disclosures made to the IETF Secretariat and any 1915 assurances of licenses to be made available, or the result of an 1916 attempt made to obtain a general license or permission for the use 1917 of such proprietary rights by implementers or users of this 1918 specification can be obtained from the IETF on-line IPR repository 1919 at http://www.ietf.org/ipr. 1921 The IETF invites any interested party to bring to its attention any 1922 copyrights, patents or patent applications, or other proprietary 1923 rights that may cover technology that may be required to implement 1924 this standard. Please address the information to the IETF at ietf- 1925 ipr@ietf.org. 1926 Disclaimer of Validity 1928 This document and the information contained herein are provided on 1929 an ôAS ISö basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1930 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1931 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1932 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1933 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1934 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1936 Copyright Statement 1938 Copyright ¨ The Internet Society (2004). This document is subject to 1939 the rights, licenses and restrictions contained in BCP 78, and 1940 except as set forth therein, the authors retain all their rights. 1942 Expiration Date 1944 This memo is filed as draft-lior-radius-extensions-for-prepaid- 1945 05.txt, and will expire 17 January, 2005.