idnits 2.17.00 (12 Aug 2021) /tmp/idnits477/draft-lior-radius-prepaid-extensions-04.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 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1628. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 41), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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 40 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that the PrePaid Server role is not to record accounting messages and therefore it SHOULD not respond with an Accounting Response packet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Authorize Only Access-Request MUST not include either User Password or Chap Password. In order to authenticate the message, the 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]. -- 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 14, 2004) is 6519 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2284' is mentioned on line 597, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Missing Reference: 'CHIBA' is mentioned on line 1193, but not defined == Unused Reference: 'RFC2026' is defined on line 1555, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 1569, but no explicit reference was found in the text == Unused Reference: 'REDIRECT' is defined on line 1578, 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 (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Lior 2 INTERNET-DRAFT Bridgewater Systems 3 Category: Informational P. Yegani 4 draft-lior-radius-prepaid-extensions-04.txt Cisco 5 Expires: 14 January, 2005 K. Chowdhury 6 Nortel 7 Y. Li 8 Bridgewater Systems 9 July 14, 2004 11 PrePaid Extensions to Remote Authentication Dial-In User Service 12 (RADIUS) 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance 19 with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 14, 2005 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 RADIUS Extensions for PrePaid February 2004 47 The draft presents an extension to the Remote Authentication Dial-In 48 User Service (RADIUS) protocol to support PrePaid data services for 49 a wide range of deployments such as Dial, Wireless, WLAN. 50 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 concurrent PrePaid sessions...................17 61 3.3 Support for Roaming.......................................18 62 3.4 PrePaid termination.......................................19 63 4. Operations....................................................19 64 4.1 General Requirements......................................19 65 4.1.1 Broker AAA Requirements..............................19 66 4.2 Authentication and Authorization for Prepaid Enabled Service 67 Access Devices................................................20 68 4.2.1 Multiple-Session Pre-paid............................22 69 4.3 Session Start Operation...................................22 70 4.4 Mid-Session Operation.....................................23 71 4.5 Dynamic Operations........................................25 72 4.5.1 Unsolicited Session Termination Operation............25 73 4.5.2 Unsolicited Change of Authorization Operation........26 74 4.6 Termination Operation.....................................27 75 4.7 Mobile IP Operations......................................27 76 4.8 Accounting Considerations.................................28 77 4.9 Service Device Operation..................................29 78 4.10 Interoperability with Diameter Credit Control Application29 79 5. Attributes....................................................29 80 5.1 PPAC Attribute............................................29 81 5.2 Session Termination Capability............................31 82 5.3 PPAQ Attribute............................................31 83 5.4 Table of Attributes.......................................36 84 6. Security Considerations.......................................36 85 6.1 Authentication and Authorization..........................36 86 6.2 Replenishing Procedure....................................36 87 7. IANA Considerations...........................................36 88 8. Normative References..........................................37 90 RADIUS Extensions for PrePaid February 2004 92 Acknowledgments..................................................37 93 Author's Addresses...............................................38 94 Intellectual Property Statement..................................38 95 Disclaimer of Validity...........................................39 96 Copyright Statement..............................................39 97 Expiration Date..................................................39 99 RADIUS Extensions for PrePaid February 2004 101 1. Introduction 103 This draft describes RADIUS protocol extensions supporting PrePaid 104 Data Services. 106 PrePaid data services are cropping up in many wireless and wireline 107 based networks. A PrePaid Data Service subscriber is one that 108 purchases a contract to receive a data service for either a period 109 of time, or a quantity of data. Before providing a prepaid data 110 service, the service provider checks that the prepaid subscriber has 111 sufficient funds to cover the particular service request. Only after 112 confirmation that funds are available is the service provided to the 113 user. 115 The subscriber purchases the Data Service using various means such 116 as buying a PrePaid Card, or online. How the subscriber purchases 117 their PrePaid Data Service depends on the deployment and is not in 118 scope for this document. 120 In some deployments, the PrePaid data service will be combined with 121 other Prepaid services such as PrePaid circuit voice service. This 122 is not an issue for this document other than the fact that the 123 PrePaid Data Services described in this paper should work with other 124 PrePaid data and or circuit voice services. 126 The fundamental business driver for a carrier to provide PrePaid 127 data services is to increase participation (subscriber base) and 128 thus to increase revenues. Therefore, it makes sense that PrePaid 129 services meet the following goals: 131 - Leverage existing infrastructure, hence reducing capital 132 expenditures typically required when rolling out a new service; 133 - Ability to rate service requests in real-time; 134 - Ability to check that the end userÆs account for coverage for the 135 requested service charge prior to execution of that service; 136 - Protect against revenue loss, i.e., prevent an end user from 137 generating chargeable events when the credit of that account is 138 exhausted or expired; 139 - Protect against fraud; 140 - Be as widely deployable over Dialup, Wireless and WLAN networks. 142 RADIUS Extensions for PrePaid February 2004 144 The protocol described in this document maximizes existing 145 infrastructure as much as possible ¡ hence the use of the RADIUS 146 protocol. The protocol is used in ways to protect against revenue 147 loss or revenue leakage. This is achieved by defining procedures 148 for the real-time delivery of service information to a pre-paid 149 enabled AAA server, to minimize the financial risk, for the pre-paid 150 enabled AAA server to be able to allocate small quotas to each data 151 session and having the ability to update the quotas from a central 152 quota server dynamically during the lifetime of the PrePaid data 153 session. As well, mechanisms have been designed to be able to 154 recover from errors that occur from time to time. 156 Protection against fraud is provided by recording of accounting 157 records, by providing mechanisms to thwart replay attacks. As well, 158 mechanisms have been provided to terminate data sessions when fraud 159 is detected. 161 PrePaid System will become more prevalent and sophisticated as the 162 various networks such as Dialup, Wireless and WLAN converge. This 163 protocol extension is designed to meet the challenges of converged 164 networks. The draft mainly addresses how to use the RADIUS protocol 165 to achieve a PrePaid Data Service. The prepaid architecture assumes 166 that rating of chargeable events does not occur in the element 167 providing the service. This rating could be performed in the prepaid 168 enabled AAA server or may exist in an entity behind this AAA server. 169 Business logic and service rules may define that tariffing of events 170 vary in time, e.g., the particular price per megabyte download may 171 be defined to switch at 8pm from a high tariff to a low tariff. The 172 RADIUS extensions for prepaid support scenarios enable scalable 173 implementation of tariff switched prepaid systems. 175 Furthermore, the prepaid architecture assumes that a quota server is 176 available which, through co-ordination with the rating entity and 177 centralized balance manager is able to provide a quota response in 178 response for prepaid data service. This quota server functionality 179 could be performed in the prepaid enabled AAA server or may exist in 180 an entity behind this AAA server. Finally, the details of the 181 PrePaid System, such as its persistent store, how it maintains its 182 accounts are not covered at all. However, in order to define the 183 RADIUS protocol extensions it is necessary to discuss the functional 184 behavior of the PrePaid System. 186 RADIUS Extensions for PrePaid February 2004 188 1.1 Terminology 190 Service Access Device 191 PrePaid Client 192 PrePaid Server 193 Home agent (HA) 194 Home network 195 Home AAA (HAAA) 196 Broker AAA (BAAA) 197 Visited AAA (VAAA) 198 Foreign Agent (FA) 199 WLAN 200 Service Device 201 Service Event 203 1.2 Requirements language 205 In this document, several words are used to signify the requirements 206 of the specification. These words are often capitalized. The key 207 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 209 this document are to be interpreted as described in [RFC2119]. 211 2. Architectural Model 213 The architectural model supports prepaid clients on a service access 214 device. A service access device (e.g. a NAS) typically provides a 215 access to data service to end-users. A service access device in an 216 entity on the data path that includes a RADIUS client. 218 When pre-paid service is used the service access device collects 219 service event information and reports it while and/or after services 220 are provided to the prepaid user. This event information is sent to 221 a prepaid server by using the prepaid RADIUS extensions. 223 If real-time credit control is required, the service access device 224 (prepaid client) contacts the prepaid server with service event 225 information included before the service is provided. The prepaid 226 server, depending on the service event information, performs credit 227 check and allocates a portion of available credit to the service 228 event. The rating entity converts this credit value into a time 229 and/or volume amount, which is then returned to the requesting 230 service access device. The rating entity may determine that during 232 RADIUS Extensions for PrePaid February 2004 234 the allocated quota, a tariff switch will occur in which case the 235 rating entity will include details of the quota allocated prior to 236 the tariff switch, details of the quota allocated after the tariff 237 switch together with details of when the tariff switch will occur. 239 The requesting service access device then monitors service execution 240 according to the instructions returned by the prepaid server. After 241 service completion or on a subsequent request for service, the 242 prepaid server deducts the reserved allocation of credit from the 243 prepaid userÆs account. 245 Similarly, when a user terminates an on-going prepaid service, the 246 prepaid client signals the prepaid server with the a value 247 corresponding to the unused portion of the allocated quota. The 248 prepaid server is then able to refund unused allocated funds into a 249 userÆs prepaid account. 251 There MAY be multiple prepaid servers in the system for reasons of 252 redundancy and load balancing. The system MAY also contain separate 253 rating server(s) and accounts MAY be located in a centralized 254 database. System internal interfaces can exist to relay messages 255 between servers and an account manager. However the detailed 256 architecture of prepaid system and its interfaces are implementation 257 specific and are out of scope of this specification. 259 accounting 260 +------------+ +-----------+ protocol +--------------+ 261 | Subscriber |<----->| Service | | | 262 | | | Access |<------------>| Accounting | 263 | Device | | Device |<-----+ | Server | 264 +------------+ +-----------+ | +--------------+ 265 | 266 | 267 | +--------------+ 268 +------>| PrePaid | 269 prepaid | Server | 270 protocol +--------------+ 272 Figure 1 Basic Prepaid Architecture 274 The prepaid server and accounting server in this architecture model 275 are logical entities. The real configuration MAY combine them into a 276 single host. 278 RADIUS Extensions for PrePaid February 2004 280 There MAY exist protocol transparent RADIUS Proxies between prepaid 281 client and prepaid server. These proxies transparently support the 282 prepaid RADIUS extensions. 284 In order to generalize the solution, in this paper we generalize the 285 Service Access Devices, which in reality may be a NAS in Dialup 286 deployments, PDSN (Packet Data Serving Node) or HA (Home Agent) in 287 CDMA2000 deployments, an 802.11 WLAN Access Points or GGSN (Gateway 288 GPRS Serving Node) in GPRS/UMTS deployments. To actively participate 289 in Prepaid procedures outlined here, the Service Access Device MUST 290 have the Prepaid Client capabilities. Prepaid Client Capabilities 291 include the ability to meter the usage for a prepaid data session; 292 this usage includes time or volume (e.g. number of bytes) usage. 294 In the case of roaming scenarios using mobile IP (in a wireless or 295 wireline network), the prepaid client functionality may be delegated 296 to the Home Agent. It may also be possible to deliver limited 297 prepaid services using RADIUS capabilities specified in RFC2865 and 298 RFC2866. 300 Furthermore, the device including the prepaid client functionality 301 may also have Dynamic Session Capabilities that include the ability 302 to terminate a data session and/or change the filters associated 303 with a specific data session by processing Disconnect Messages and 304 Change of Authorization messages as per [RFC3576]. 306 In this document RADIUS is used as the AAA server. There are three 307 kinds or categories of AAA servers. The AAA server in the home 308 network, the HAAA, is responsible for authentication of the 309 subscriber and also authorization of the service. In addition, the 310 HAAA communicates with the Prepaid servers using the RADIUS protocol 311 to authorize prepaid subscribers. In AAA based roaming deployments 312 the AAA server in the visited network, the VAAA, is responsible for 313 forwarding the RADIUS messages to the HAAA. The VAAA may also 314 modify the messages. In roaming deployments, the visited network 315 may be separated from the home network by one or more broker 316 networks. The AAA servers in the broker networks, BAAA are 317 responsible to route the RADIUS packets transparently and hence 318 donÆt play an active roll in the Prepaid Data Service delivery. 320 RADIUS Extensions for PrePaid February 2004 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 RADIUS Extensions for PrePaid February 2004 355 +------+ +-----+ 356 | | | | 357 +--------+ +--------+ +--| HAAA |--+--| PPS | 358 | | | | | | | | | | 359 | Sub | | Service| | +------+ | +-----+ 360 | |---| Access |--+ | 361 | Device | | Device | | +------+ | +-----+ 362 | | | | | | | | | | 363 +--------+ +--------+ +--| HAAA |--+--| PPS | 364 | | | | 365 +------+ +-----+ 367 Figure 2 Basic Prepaid Access Architecture 369 Figure 3 shows a static roaming prepaid architecture that is typical 370 of a wholesale scenario for Dial-Up users or a broker scenario used 371 in Dial-Up or WLAN roaming scenarios. 373 +----+ +----+ +----+ +-----+ 374 | | | | | | | | 375 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 376 | | | | | | | | | | | | | | | | 377 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 378 | |--|Access |-+ | | | 379 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 380 | | | | | | | | | | | | | | | | 381 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 382 | | | | | | | | 383 +----+ +----+ +----+ +-----+ 385 | Visited | |Broker | | Home | 386 | Network | |Network| | Network | 388 Figure 3 Static Roaming Prepaid Architecture 390 As in the basic prepaid architecture the subscriberÆs device 391 establishes a connection with the Service Access Device (NAS, WLAN 392 Access Point). The Service Access Device communicates with the 393 Visiting AAA server (VAAA) using the RADIUS protocol. Again for 394 redundancy there maybe more then one VAAA. The VAAA communicate 395 using the RADIUS protocol with AAA servers in the broker network 396 (BAAA). There maybe more then one Broker Network between the 398 RADIUS Extensions for PrePaid February 2004 400 Visited Network and the Home Network. The Home Network is the same 401 as in the simple architecture. 403 To support dynamic roaming the network will utilize Mobile-Ip as 404 illustrated in Figure 4. Note that typically the mobile device 405 would be moving between networks that use the same technology such 406 as Wireless or WLAN. Increasingly, device will be able to roam 407 between networks that use different technology such as between WLAN 408 and Wireless and Broadband. Fortunately, Mobile-Ip can address this 409 type of roaming and therefore we need not be concerned with the 410 underlying network technology. 412 +------+ +-------+ +----+ +----+ +----+ +-----+ 413 | | |Service| | | | | | | | | 414 |Sub | |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS | 415 | |--|Device | | | | | | | | | 416 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 417 | | | | | | 418 +------+ +------ + | | 419 | | | +----+ 420 | | | | | 421 |ROAMS +------------------+ HA | 422 | | | | 423 V +----+ | +----+ 424 +------+ +-------+ | | | | 425 | | |Service| +-|VAAA+------+ | 426 |Sub | |Access | | | | | 427 | |--|Device +-+ +----+ | 428 |Device| | (FA) | | 429 | | | +------------------------+ 430 +------+ +-------+ 432 Figure 4 Roaming using Mobile-IP and pre-paid enabled Service 433 Access Devices 435 In figure 4, the Subscriber device establishes a prepaid session 436 between the Service Access Device in the foreign network, which has 437 prepaid capabilities. The subscriberÆs home address will be 438 anchored at the Home Agent (HA) in the home network. The setup for 439 this access service is identical to the cases covered above. Notice 440 that the Service Access Device may be collocated with the Foreign 442 RADIUS Extensions for PrePaid February 2004 444 Agent (FA) in case of Mobile-IPv4. As the subscriber device moves 445 it establishes a connection with another Service Access Device in 446 the same foreign network or in another foreign network. The prepaid 447 data service should continue to be available. When a device 448 associates to another Service Access Device it MUST re-authenticate 449 at the new Service Access Device and de-associate or logoff from the 450 old Service Access Device. Furthermore, any unused quota at the old 451 Service Access Device MUST be promptly credited back to the 452 subscribers account. The reason we say promptly, is because if the 453 subscriber is very low on resources to start with, the subscriber 454 may not have enough resources to log on to the new Service Access 455 Device. The speed at which resources can be returned depend on the 456 type of handoff procedure that is used. Some of the example of 457 handoffs in wireless networks are dormant handoff, active handoff 458 and fast handoff. 460 As well, notice that if the Service Access Devices could communicate 461 with each other then there could be a way to accelerate a faster 462 handoff procedure. In particular, it could accelerate the return of 463 the unused portion of the quotas from the old Access Device. 465 Unfortunately, standards with regards to handoff are evolving with 466 each network technology creating their own scheme to make the 467 handoff procedures more efficient. 469 2.1 Why not existing RADIUS attributes? 471 It has been asked ôWhy not use existing RADIUS attributes to build a 472 prepaid solution? This will allow us to have a solution with 473 existing devices without code modification.ö 475 It is possible to build a prepaid solution using existing RADIUS 476 attributes. The RADIUS server can simply send an Access-Accept 477 message containing Session-Timeout(27) and set Termination- 478 Action(29) to RADIUS-request. Upon receiving the Access-Accept 479 message, the NAS will meter the duration of the session and upon 480 termination of the session the NAS generate an Access-Request 481 message again. The RADIUS server would re-authenticate the session 482 and reply with an Access-Accept message with additional time in 483 Session-Timeout(27) or an Access-Reject message if there were no 484 more resources in the userÆs account. 486 RADIUS Extensions for PrePaid February 2004 488 If the user terminates the session before the time expressed in 489 Session-Timeout(27). The NAS will recover any unused time from the 490 accounting stream. 492 There are several problems with such a solution: 494 -It only allows for time-based prepaid. The solution presented in 495 this document allows for both time and volume based prepaid. As 496 well as extensibility for other features such as tarified based 497 solutions. 499 -Using accounting messages to recoup unused time may be problematic 500 because RADIUS accounting messages are not real-time. A RADIUS 501 server may store-and-forward accounting messages in batches. The 502 solution presented in this paper does not rely on Accounting Packets 503 at all. It uses Access-Request, messages which do flow through any 504 network in real-time. Delaying accounting messages may cause 505 revenue leakage. 507 -Session-Timeout(27) is not a mandatory attribute. If a prepaid 508 subscriber is being serviced by a NAS that does not adhere to 509 Session-Timeout then that subscriber will obtain unlimited service. 511 -Termination-Action(29) presents its own issues. First the 512 behaviour of Termination-Action(29) is not mandatory. Second, 513 according to RFC2865 Termination-Action fires when the Service is 514 complete. But we should not be terminating the service while 515 negotiating additional quota. The refreshing of the time quota 516 should be transparent to the user. Because Termination-Action 517 occurs when the Service is complete it is unclear whether or not the 518 user experience would be transparent. For example, will the RADIUS 519 server allocate the subscriber a new IP address? Furthermore, the 520 RADIUS server has no way of telling why the Access-Request message 521 was generated. The RADIUS server will have to wait for the 522 corresponding accounting packet to determine the reason for this 523 Access-Request message. Lastly re-authenticating the subscriber may 524 take far too long. The solution presented in this document allows 525 quota replenishing to occur in an undisruptive manner from the 526 perspective of the user. No re-authentication is required and 527 quotas can be negotiated prior to the quotas running out. 529 -Prepaid ambiguity. Implementing prepaid using existing RADIUS 530 attributes presents another problem. Due to the fact that the 532 RADIUS Extensions for PrePaid February 2004 534 standard RADIUS attributes are not mandatory, then the correct 535 prepaid operation is really an act of faith on the part of the 536 RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) 537 are not supported, the prepaid subscriber will get free access. The 538 solution described in this document, requires that a prepaid capable 539 Service Access Device inform the RADIUS server whether or not it 540 supports prepaid capabilities. The RADIUS server can now determine 541 whether service should be granted or not. For example, if a prepaid 542 subscriber is connected to a NAS that does not support prepaid, the 543 RADIUS server can either instruct the NAS to tunnel the traffic to 544 another entity in the home network that does support prepaid client 545 function (e.g. Home Agent) or it may allow the subscriber to get 546 access but restrict the traffic. 548 The prepaid solution we present is a robust carrier grade prepaid 549 solution. It only requires the support of 2 mandatory attributes 550 and one optional attribute. Furthermore, it does not really 551 require much code support at the NAS. NASes already support 552 measurement of time and volume. This solution requires that they 553 advertise their prepaid capabilities in an Access-Request; that they 554 generate an Access-Request Authorize-Only packet to obtain more 555 quota at or before the quota is used up. It also requires that the 556 NAS send an Access-Request with Authorize-Only when the session 557 terminates to return any unused quota to the prepaid system. 559 Lastly the solution provided in this document is extensible. This 560 document defines the basic exchanges between a prepaid capable NAS 561 and a RADIUS server. The protocol can easily be extended to support 562 tariff switching and other prepaid business models. 564 3. Use-cases 566 In this section we present a set of use cases that will help 567 establish the requirements needed to deliver PrePaid data services. 568 These use cases donÆt address how the PrePaid account is established 569 or maintained. It is assumed that the PrePaid subscriber has 570 obtained a valid account from a service provider such as a wireless 571 operator or a WLAN operator. 573 To make the document as general as possible, the use cases cover the 574 experience from the Service Access Device and not from the UserÆs 575 Device. The connection between the UserÆs Device, which typically 576 involves setting up a layer 2 session, e.g., PPP session or GPRS PDP 578 RADIUS Extensions for PrePaid February 2004 580 Context, is specific to a given network technology and the details 581 are not required to deliver a PrePaid service. 583 3.1 Simple pre-paid access use-case 585 A PrePaid subscriber connects to his home network. As usual, the 586 Access Device that is servicing the subscriber will use the AAA 587 infrastructure to authenticate and authorize the subscriber. 589 The Service Access Device sends a RADIUS Access-Request to the AAA 590 system to authenticate the subscriber, and identify and authorize 591 the service. The Access-Request includes the subscriberÆs 592 credentials and may include the PrePaid capabilities of the Service 593 Access Device. PrePaid capabilities MUST be included if the Service 594 Access Device supports PrePaid functionality. 596 The AAA System proceeds with the authentication procedure. This may 597 involve several transactions such as in EAP [RFC2284]. Once the 598 subscriber has been authenticated, the AAA system determines that 599 the subscriber is a PrePaid subscriber and requests that the PrePaid 600 System authorize the PrePaid subscriber. The request MUST include 601 the PrePaid Capabilities of the serving Service Access Device. 603 The PrePaid System will validate that the subscriber has a PrePaid 604 Account; it will validate that the account is active; and will 605 validate that the Service Access Device has the appropriate PrePaid 606 capabilities. If all is in order, the PrePaid System will authorize 607 the subscriber to use the network. Otherwise it will reject the 608 request. The response is sent back to the AAA System. The response 609 includes attributes to indicate the allocation of a portion of the 610 subscriberÆs account called the initial quota (in units of time or 611 volume) and optionally a threshold value. 613 [Editor comments: we should leave tariff switch issues to another 614 document. One way to deal with a tariff switch is to set the 615 threshold or quota such that a new allocation is requested just 616 before or at the tariff switch period.] 618 When the rating engine has determined that a tariff switch will 619 shortly occur, the initial quota may be segmented into that which 620 SHOULD be used before the tariff switch, that which SHOULD be used 622 RADIUS Extensions for PrePaid February 2004 624 after the tariff switch together with details describing the tariff 625 switching instant. 627 The Access Device is responsible for requesting quota to be allocate 628 for a particular prepaid user. 630 [NEED A USE CASE FOR CONCURTENT PREPAID SESSIONS] 631 In order to support concurrent PrePaid sessions, at any time, the 632 PrePaid System allocates a portion of the subscribers account to a 633 given PrePaid session. For example, in a multi-service environment 634 it might happen that an end user with an already ongoing service 635 (e.g., browsing the Internet) issues a new service request (e.g., 636 for downloading a ring-tone) towards the same account. Throughout 637 the lifetime of a session the Access Device will monitor usage 638 according to the quota(s) returned from the prepaid server and will 639 request further quota updates from the PrePaid System as previously 640 allocated quotas are consumed. Conditions may be included with 641 quotas, which indicate when an allocated quota should be returned to 642 the prepaid system. These conditions can include an Idle-Timeout(28) 643 associated with the provided quota. In this case, the Access device 644 monitors the service for activity. When a single inactivity period 645 exceeds that provided in the quota conditions, the unused quota is 646 returned to the prepaid server. 648 The AAA system incorporates the PrePaid attributes received from the 649 PrePaid System into an Access-Accept message that it sends back to 650 the Service Access Device. Note the AAA System is responsible for 651 authorizing the service whereas the PrePaid System is responsible 652 for PrePaid authorization. 654 Upon receiving the Access-Response, the Service Access Device allows 655 the PrePaid data session to start and it starts to meter the session 656 based on time or volume, as indicated in the returned Quota 658 Once the usage for the session approaches the allotted quota (as 659 expressed by the threshold), the Service Access Device will request 660 an additional quota. The re-authorization for additional quota 661 flows through the AAA system to the PrePaid System. The PrePaid 662 System revalidates the subscriberÆs account; it will subtract the 663 previous quota allocation from the userÆs balance and if there is a 664 balance remaining it will reauthorize the request with an additional 665 quota allotment. Otherwise, the PrePaid System will reject the 667 RADIUS Extensions for PrePaid February 2004 669 request. Note the replenishing of the quotas is a re-authorization 670 procedure and does not involve re-authentication of the subscriber. 672 It is important to note that the PrePaid System is maintaining 673 session state for the subscriber. This state includes how much 674 account balance was allocated during the last quota allocation for a 675 particular session and how much is left in the account. Therefore, 676 it is required that all subsequent messages about the PrePaid 677 session reach the correct PrePaid System. 679 Upon receiving a re-allotment of the quota, the Service Access 680 Device will, continue the data service session until the new 681 threshold is reached. If the request for additional quota cannot be 682 fulfilled then the Service Access Device will let the subscriber use 683 up the remaining quota and terminate the session. 685 Alternatively, instead of terminating the session, the Service 686 Access Device may restrict the data session such that the subscriber 687 can only reach a particular web server. This web server maybe used 688 to allow the subscriber to replenish their account. This 689 restriction can also be used to allow new subscribers to purchase 690 their initial PrePaid Service. 692 Should the subscriber terminate the session before the quota is used 693 up, the remaining balance allotted to the session must be credited 694 back to the subscriberÆs account. 696 As well, while the Access Device is waiting for the initial quota, 697 the subscriber may have dropped the session. The initial quota must 698 be credited back to the subscribers account. 700 3.2 Support for concurrent PrePaid sessions 702 [REPLACE THIS TEXT WITH TOKEN BASED PREPAID] 704 Both prepaid support using Access Devices and prepaid support using 705 Service Devices can be configured to support a prepaid multi-service 706 environment. In such circumstances, the prepaid client capabilities 707 will indicate that the Access or Service Device supports a multi- 708 service environment [Editor: need to add this to the PPAC]. [Editor: 709 This needs to be reworked. DonÆt believe that this step is required. 710 The Service Ids should be known a priori ¡ the Access Request should 712 RADIUS Extensions for PrePaid February 2004 714 include the Service Key being requested.] In such circumstances, 715 instead of returning a quota, the prepaid service provides a list of 716 authorized services corresponding to a list of service keys to the 717 prepaid client. The Access/Service device then uses these service 718 keys to request prepaid authorization to the corresponding services. 719 The prepaid server responds with an individual quota for the 720 requested service key [Editor: add service key to PPAQ]. The 721 Access/Service Device may in parallel request prepaid authorization 722 to a second service key. In which case a separate authorization 723 exchange is used to provide an independent quota for this second 724 service. 726 Each session is treated independently. 728 The method by which a prepaid user activates a service and the 729 method for signalling this information to the Access/Service Device 730 is out of scope of this draft. 732 The method by which a granular service is defined is out of scope of 733 this draft. Only service key correlation information is required to 734 enable the prepaid server to authorize and rate a particular 735 request. 737 3.3 Support for Roaming 739 For some networks it is essential that PrePaid Data Services be 740 offered to roaming subscribers. Support for static and dynamic 741 roaming models are needed. Static roaming is where the subscriber 742 logs onto a foreign network. The foreign network has a roaming 743 agreement directly with the home network or through a broker network 744 or networks. The subscriber remains logged into the network until 745 the subscriber changes location. When changing location a new 746 connection and a new login procedure is required. 748 Dynamic roaming allows to subscriber to move between networks while 749 maintaining a connection with the home network seamlessly. As the 750 subscriber moves between networks, the data session is handed off 751 between the networks. 753 In both roaming scenarios, the subscriber always authenticates with 754 the home network. PrePaid authorization and quota replenishing for 755 the session need to be received at the home network and more 756 specifically at the PrePaid System where state is being maintained. 758 RADIUS Extensions for PrePaid February 2004 760 Dynamic roaming is particularly challenging. A subscriber that 761 established a PrePaid Data Session may roam to another Access Device 762 that doesnÆt not support PrePaid functionality. The system should 763 be capable to continue the PrePaid session. 765 3.4 PrePaid termination 767 When fraud is detected by the PrePaid System, or when an error is 768 detected, it may be beneficial for the PrePaid system to terminate a 769 specific session for the subscriber or all the sessions of a 770 subscriber. 772 Some errors can occur such that the PrePaid System is in a state 773 where it is not sure whether the session is in progress or not. 774 Under conditions such as this, the PrePaid system may wish to 775 terminate the PrePaid data session to make sure that resources are 776 not being utilized for which it canÆt charge for reliably. 778 Some handoff procedure used during dynamic roaming may require that 779 the PrePaid system explicitly terminate the subscribers PrePaid data 780 session at an Service Access Device. For example, if time based 781 PrePaid service is being used and the mobile subscriber performs a 782 dormant handoff, the PrePaid System needs to explicitly terminate 783 the PrePaid session at the old Service Access Device. 785 4. Operations 787 4.1 General Requirements 789 4.1.1 Broker AAA Requirements 791 Broker AAA servers MUST support the Message-Authenticator(80) 792 attribute as defined in [RFC2869]. If BAAA servers are used, the 793 BAAA servers function is to forward the RADIUS packets as usual to 794 the appropriate RADIUS servers. 796 Accounting messages are not needed to deliver a PrePaid service. 797 However, accounting messages can be used to keep the PrePaid Server 798 current as to what is happening with the PrePaid data session. 799 Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the 800 pass through mode described in [RFC2866]. 802 RADIUS Extensions for PrePaid February 2004 804 4.2 Authentication and Authorization for Prepaid Enabled Service Access 805 Devices 807 The Service Access Device initiates the authentication and 808 authorization procedure by sending a RADIUS Access-Request to the 809 HAAA. 811 If the Service Access Device has PrePaid Client capabilities, it 812 MUST include the PPAC(TBD) attribute in the RADIUS Access-Request. 813 The PPAC(TBD) attribute indicates to the PrePaid server the PrePaid 814 capabilities possessed by the Service Access Device. These are 815 required in order to complete the PrePaid authorization procedures. 817 If the Service Access Device supports the Disconnect-Message or the 818 Change-of-Authorization capabilities, then it SHOULD include the 819 Dynamic-Capabilities attribute. 821 In certain deployments, there may be other ways in which to 822 terminate a data session, or change authorization of an active 823 session. For example, some Service Access Devices provide a session 824 termination service via Telnet or SNMP. In these cases, the AAA 825 server MAY add the Dynamic-Capabilities message to the Access- 826 Request. Upon receiving the Change-of-Authorization message, the 827 AAA server would then be responsible for terminating the session 828 using whatever means that are supported by the device. 830 If the authentication procedure involves multiple Access-Requests 831 (as in EAP), the Service Access Device MUST include the PPAC(TBD) 832 attribute and the Dynamic-Capabilities attribute (if used) in at 833 least the last Access-Request of the authentication procedure. 835 The Access-Request will be sent as usual to the HAAA. The packet 836 may be proxied through zero or more BAAA. 838 Once the Access-Request arrives at the HAAA, the HAAA will 839 authenticate the subscriber. If the subscriber is cannot be 840 authenticated, the HAAA will send an Access-Reject message back to 841 the client. If the subscriber is authenticated, the HAAA will 842 determine whether or not the subscriber is a PrePaid subscriber. 843 The techniques used to determine whether or not a subscriber is a 844 PrePaid subscriber is beyond the scope of this document. If the 845 subscriber is not a PrePaid subscriber, then the HAAA will respond 847 RADIUS Extensions for PrePaid February 2004 849 as usual with an Access-Accept or Access-Reject message. If the 850 subscriber is a PrePaid Subscriber the HAAA SHALL forward the 851 Access-Request to a PrePaid server for further authorization. 853 The Access-Request will contain the PPAC(TBD) attribute, the 854 Dynamic-Capabilities attribute if one was included; the User-Name(1) 855 attribute MAY be set to a value that would represent the 856 SubscriberÆs PrePaid Identity. This attribute is used by the 857 PrePaid server to locate the PrePaid SubscriberÆs account. For 858 added security, the HAAA MAY also set the User-Password(2) attribute 859 to the password used between the HAAA and the PrePaid server. 861 The PrePaid server lookups the subscriberÆs PrePaid account and will 862 authorize the subscriber taking into consideration the Service 863 Access Device PrePaid Client Capabilities. 865 Upon successful authorization, the PrePaid server will generate an 866 Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD) 867 attribute. 869 The PPAC attribute returned to the client indicates the type of 870 prepaid service to be provided for the session. The PPAQ(TBD) 871 attribute includes: 873 - The QUOTA-Id, which is set by the PrePaid server to a unique 874 value that is used to correlate subsequent quota requests; 876 - Volume and/or Time quotas, which are set to a value representing a 877 portion of the subscribers account; 879 - MAY contain a Time or Volume Threshold that controls when the 880 Service Access Device requests additional quota; 882 - The IP address of the Serving PrePaid Server and one or more 883 alternative PrePaid Servers. This is used by the HAAA to route 884 subsequent quota replenishing messages to the appropriate PrePaid 885 server(s). 887 Note: Idle-Timeout(28) can be used to trigger the premature 888 termination of a pre-paid service following subscriber inactivity. 890 Depending on site policies, upon unsuccessful authorization, the 891 PrePaid server will generate an Access-Reject to terminate the 893 RADIUS Extensions for PrePaid February 2004 895 session immediately. Alternatively, the PrePaid server may generate 896 an Access-Accept blocking some or all of the traffic and/or redirect 897 some or all of the traffic to a location where the subscriber can 898 replenish their account for a period of time. Blocking of traffic 899 is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect 900 I-d). Redirection is achieved by sending Redirect-Id or Redirect- 901 Rule defined in the Redirect I-d. The period of time before the 902 blocked/redirected session last can be specified by Session- 903 Timeout(27) attribute. 905 Upon receiving the Access-Accept from the PrePaid Server, the HAAA 906 will append the usual service attributes and forward the packet to 907 the Service Access Device. The HAAA SHALL NOT append or overwrite 908 any attributes already set by the PrePaid server. If the HAAA, 909 receives an Access-Reject message, it will simply forward the packet 910 to its client. Depending on site policies, if the HAAA fails to 911 receive an Access-Accept or Access-Reject message from the PrePaid 912 server it MAY do nothing or send an Access-Reject or an Access- 913 Accept message back to its client. 915 4.2.1 Multiple-Session Pre-paid 917 To be completed in the next release. 919 4.3 Session Start Operation 921 The real start of the session is indicated by the arrival of 922 Accounting-Request(Start) packet. The Accounting-Request (Start) 923 MAY be routed to the PrePaid Server so that it can confirm the 924 initial quota allocation. 926 Note that the PrePaid Server role is not to record accounting 927 messages and therefore it SHOULD not respond with an Accounting 928 Response packet. 930 If the Prepaid server does not receive the Accounting-Request(start) 931 message it will only know that the session has started upon the 932 first reception of a quota replenishment operation. 934 If the Prepaid server does not receive indication directly (via 935 Accounting-Request(start)) or indirectly, it SHOULD after some 936 configurable time, deduce that the Session has not started. If the 938 RADIUS Extensions for PrePaid February 2004 940 Service Access Device supports termination capabilities, the PPS 941 SHOULD send a Disconnect Message to the Service Access Device to 942 ensure that the session is indeed dead. 944 4.4 Mid-Session Operation 946 During the lifetime of a PrePaid data session the Service Access 947 Device will request to replenish the quotas using Authorize-Only 948 Access-Request messages. 950 Once the allocated quota has been reached or the threshold has been 951 reached, the Service Access Device MUST send an Access-Request with 952 Service-Type(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD) 953 attribute. 955 The Service Access Device MUST also include NAS identifiers, and 956 Session identifier attributes in the Authorize Only Access-Request. 957 The Session Identifier should be the same as those used during the 958 Access-Request. For example, if the User-Name(1) attribute was used 959 in the Access-Request it MUST be included in the Authorize Only 960 Access-Request especially if the User-Name(1) attribute is used to 961 route the Access-Request to the Home AAA server. 963 The Authorize Only Access-Request MUST not include either User 964 Password or Chap Password. In order to authenticate the message, 965 the Service Access Device MUST include the Message-Authenticator(80) 966 attribute. The Service Access Device will compute the value for the 967 Message-Authenticator based on [RFC2869]. 969 When the HAAA receives the Authorize-Only Access-Request that 970 contains a PPAQ(TBD), it SHALL validate the message using the 971 Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an 972 Authorize Only Access-Request that contains a PPAQ(TBD) but not a 973 Message-Authenticator(80) it SHALL silently discard the message. An 974 Authorize Only Access-Request message that does not contain a 975 PPAQ(TBD) is either in error or belongs to another application (for 976 example, a Change of Authorization message [RFC3576]). In this case 977 the Authorize Only Access-Request will either be silently discarded 978 or handled by another application (not in scope of this document). 980 Once the Authorize Only Access-Request message is validated, the 981 HAAA SHALL forward the Authorize Only Access-Request to the 982 appropriate PrePaid Server. The HAAA MUST forward the Authorize 984 RADIUS Extensions for PrePaid February 2004 986 Only Access-Request to the PrePaid server specified in the 987 PPAQ(TBD). The HAAA MUST sign the message using the Message- 988 Authenticator(80) and the procedures in [RFC2869]. As with the 989 Access-Request message, the HAAA MAY modify the User-Name(1) 990 attribute to a value that represents the userÆs internal PrePaid 991 account in the PrePaid server. Note the PrePaid server could use 992 the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate 993 the user account. 995 Upon receiving the Authorize Only Access-Request containing a 996 PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- 997 Authenticator(80) as prescribed in [RFC2869]. If the message is 998 invalid, the PrePaid server MUST silently discard the message. If 999 it received an Authorize Only Access-Request message that does not 1000 contain a PPAQ(TBD) it MUST silently discard the message. 1002 The PrePaid server will lookup the PrePaid session by using the 1003 PrePaid Quota Id contained within the PPAQ(TBD). The PrePaid Server 1004 would, take the last allocated quota and subtract that from the 1005 UserÆs balance. If there is remaining balance, the PrePaid server 1006 re-authorizes the PrePaid session by allocate an additional quota. 1007 The PrePaid server may want to calculate a different threshold 1008 values as well. 1010 Upon successful re-authorization, the PrePaid server will generate 1011 an Access-Accept containing the PPAQ(TBD) attribute. The Access- 1012 Accept message MAY contain Service-Type(6) set to Authorize-Only and 1013 MAY contain the Message-Authenticator(80). 1015 Depending on site policies, upon unsuccessful authorization, the 1016 PrePaid server will generate an Access-Reject or an Access-Accept 1017 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 1018 and the Session-Timeout(27) attribute such that the PrePaid 1019 subscriber could get access to a restricted set of locations for a 1020 short duration to allow them to replenish their account, or create 1021 an account; or to browse free content. 1023 Upon receiving the Access-Accept from the PrePaid server, the HAAA 1024 SHALL return the packet to its client. If the HAAA, receives an 1025 Access-Reject message, it will forward the packet. Depending on 1026 site policies, if the HAAA fails to receive an Access-Accept or an 1027 Access-Reject message from the PrePaid server it MAY do nothing or 1028 it MAY send an Access-Reject message back to its client. 1030 RADIUS Extensions for PrePaid February 2004 1032 Upon receiving an Access-Accept, the Service Access Device SHALL 1033 update its quotas and threshold parameters with the values contained 1034 in the PPAQ(TBD) attribute. Note that the PrePaid server MAY update 1035 the PrePaidServer attribute(s) and these may have to be saved as 1036 well. 1038 Upon receiving an Access-Accept message containing either Filter- 1039 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 1040 The Service Access Device SHALL restrict the subscriber session 1041 accordingly. 1043 4.5 Dynamic Operations 1045 The PrePaid server may want to take advantage of the dynamic 1046 capabilities that are supported by the Service Access Device as 1047 advertised in the Dynamic-Capabilities attribute during the initial 1048 Access-Request. 1050 There are two types of actions that the PrePaid server can perform: 1051 it can request that the session be terminated; or it can request 1052 that the filters associated with the session be modified. 1054 Both of these actions require that the session be uniquely 1055 identified at the Service Access Device. As a minimum the PrePaid 1056 server: 1058 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 1059 -MUST provide at least one session identifier such as User-Name(1), 1060 Framed-IP-Address(), the Accounting-Session-Id(44). 1062 Other attributes could be used to uniquely identify a PrePaid data 1063 session. 1065 4.5.1 Unsolicited Session Termination Operation 1067 This capability is described in detail in [RFC3576]. The PrePaid 1068 server sends a Disconnect Request packet that MUST contain 1069 identifiers that uniquely identify the subscriberÆs data session and 1070 the Service Access Device servicing that session. 1072 Upon receiving the Disconnect Request packet the HAAA will either 1073 act on it or will proxy it to another AAA server until it is 1075 RADIUS Extensions for PrePaid February 2004 1077 received by the a AAA that is in the same network as the serving 1078 Service Access Device. 1080 Each AAA MUST route the Disconnect Request packet to the AAA that is 1081 in the same network as the serving Service Access Device (as per 1082 [RFC3576]). 1084 If the Service Access Device receives a Disconnect-Request packet, 1085 it will respond with either a Disconnect-ACK packet if it was able 1086 to terminate the session or else it will respond with a Disconnect- 1087 NAK packet. 1089 If the AAA server is performing the disconnect operation, it MUST 1090 respond with a Disconnect-ACK message if it successfully terminated 1091 the session or a Disconnect-NAK message if it failed to terminate 1092 the session with the appropriate Error-Cause(101) set. 1094 If any AAA server is unable to route the Disconnect-Request it MUST 1095 respond with a Disconnect-NAK packet with Error-Cause(101) set to 1096 ôRequest Not Routableö(502). 1098 4.5.2 Unsolicited Change of Authorization Operation 1100 The PrePaid Server MAY send a Change-of-Authorization message as 1101 described in [RFC3576] to restrict Internet access when the 1102 subscriber has no more balance. The COA packet may contain Filter- 1103 Id(11) and or attributes defined in Redirect I-d. 1105 The PrePaid server sends a Change-of-Authorization packet it MUST 1106 contain identifiers that will uniquely identify the subscriber 1107 session and the Service Access Device serving that session. 1109 Upon receiving the Change-of-Authorization packet the HAAA will 1110 either act on it or proxy it to another AAA server until it is 1111 received by a AAA server that is in the same network as the serving 1112 Service Access Device. 1114 Each AAA must route the packet to the serving network. How the 1115 routing decision is made is an implementation detail. 1117 Once the Change-of-Authorization packet reaches a AAA that is in the 1118 same network as the serving Service Access Device, if the Service 1120 RADIUS Extensions for PrePaid February 2004 1122 Access Device supports Change-of-Authorization message, it will 1123 forward the message to the Service Access Device. 1125 If the Service Access Device receives a Change-of-Authorization 1126 packet, it will respond with either a Change-of-Authorization-ACK 1127 packet if it was able to change the filter or else it will respond 1128 with a Change-of-Authorization-NAK packet. 1130 4.6 Termination Operation 1132 The termination phase is initiated when either: the Subscriber logs 1133 off; the quotas have been consumed, or when the Service Access 1134 Device receives a Disconnect Message. In all of these instances, if 1135 the session is a PrePaid data session, the Service Access Device 1136 will send an Authorize-Only Access-Request message with a PPAQ(TBD) 1137 Update-Reason attribute set to either ôClient Service terminationö 1138 or ôRemote Forced disconnectö and the currently used quota. 1140 The BAAA MUST forward this packet to the next BAAA or the HAAA. 1142 The HAAA MUST validate the Authorize Only Access-Request using the 1143 Message-Authenticator(80) as per [RFC2869] and if valid, use the 1144 PrePaidServer subtype in the PPAQ(TBD) to forward the Authorize Only 1145 Access-Request packet to the serving PrePaid Server or if needed, 1146 its alternate. 1148 The PrePaid Server MUST validate the Authorize Only Access Request 1149 and use the information contained in the PPAQ(TBD) attribute to 1150 adjust the subscriberÆs balance and to close the session. The 1151 PrePaid Server SHALL respond back with an Access-Accept message. 1153 4.7 Mobile IP Operations 1155 In roaming scenarios using Mobile-IP, as the mobile subscriber roams 1156 between networks, or between different types of networks such as 1157 between WLAN and CDMA2000 networks, the PrePaid data session should 1158 be maintained transparently if the HA is acting as the Service 1159 Access Device. 1161 As the subscriber device associates with the new Service Access 1162 Device (AP or PDSN that supports prepaid client capability), the 1163 Service Access Device sends a RADIUS Access-Request and the 1165 RADIUS Extensions for PrePaid February 2004 1167 subscriber is re-authenticated and reauthorized. The Service Access 1168 Device MUST include the PPAC(TBD) attribute in the RADIUS Access- 1169 Request. In this manner the procedure follows the Authentication 1170 and Authorization procedure described earlier. 1172 If the HA was acting as the Service Access Device before handoff, 1173 the userÆs prepaid session does not undergo any change after the 1174 handoff because the Mobile IP session is anchored at the HA and the 1175 userÆs Home IP address remains the same. 1177 In the case of AP or PDSN acting as the Service Access Device it is 1178 likely that the userÆs IP address will change (Care of Address). 1179 Therefore, the ongoing prepaid session will have some impact. In the 1180 case the Service Access Device shall send an Access-Request. 1181 The Access-Request message is routed to the home network and MUST 1182 reach the PrePaid System that is serving the PrePaid session. The 1183 PrePaid system will then correlate the new authorization request 1184 with the existing active session and will assign a quota to the new 1185 request. Any outstanding quota at the old Service Access Device 1186 MUST be returned to the PrePaid system. If the Mobile-IP nodes (HA 1187 and FA) supports registration revocation (Mobile IPv4 only). 1188 Specifically, the quota SHOULD be returned when the Service Access 1189 Device sends the Authorize Only Access-Request with PPAQ(TBD) 1190 Update-Reason set to either ôRemote Forced disconnectö or ôClient 1191 Service terminationö. In order to trigger the sending of this last 1192 Authorize Only Access-Request, the PrePaid system may issue a 1193 Disconnect Message [CHIBA] to the Service Access Device. 1195 If the subscriber has roamed to a Service Access Device that does 1196 not have any PrePaid Capabilities, PrePaid data service may still be 1197 possible by requesting the Home Agent (providing it has PrePaid 1198 Capabilities) to assume responsibilities for metering the service. 1199 The procedure for this scenario will be given in the next release of 1200 this draft. 1202 4.8 Accounting Considerations 1204 Accounting messages are not required to deliver PrePaid Data 1205 Service. Accounting message will typically be generated for PrePaid 1206 Data Service. This because accounting message are used for auditing 1207 purposes as well as for bill generation. 1209 RADIUS Extensions for PrePaid February 2004 1211 Accounting messages associated with PrePaid Data Sessions should 1212 include the PPAQ(TBD) attribute. 1214 4.9 Service Device Operation 1216 To be completed 1218 4.10 Interoperability with Diameter Credit Control Application 1220 RADIUS PrePaid solutions need to interoperate with Diameter 1221 protocol. Two possibilities exist: The AAA infrastructure is 1222 Diameter based and the Service Access Device are RADIUS based; or 1223 the Service Access Device is Diameter based and the AAA 1224 infrastructure is RADIUS based. 1226 The Diameter Credit Control Application [DIAMETERCC] describes how 1227 to implement a PrePaid using an all Diameter based infrastructure. 1229 1231 5. Attributes 1233 This draft is using the RADIUS [RFC2865] namespace. 1235 5.1 PPAC Attribute 1237 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1238 Access-Request message by a Prepaid Capable NAS and is used to 1239 describe the PrePaid capabilities of the NAS. The PPAC is available 1240 to be sent in an Access-Accept message by the Prepaid server to 1241 indicate the type of prepaid metering that is to be applied to this 1242 session. 1244 RADIUS Extensions for PrePaid February 2004 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | AvailableInClient (AiC) | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | SUB-TYPE 2 | LENGTH | SelectedForSession (SFS) | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 TYPE : value of PPAC 1259 LENGTH: 14 1260 VALUE : String 1262 The value MUST be encoded as follows: 1264 Sub-Type (=1) : Sub-Type for AvailableInClient attribute 1265 Length : Length of AvailableInClient attribute 1266 (= 6 octets) 1267 AvailableInClient (AiC): 1269 The optional AvailableInClient Sub-Type, generated by the PrePaid 1270 client, indicates the PrePaid Accounting capabilities of the NAS and 1271 shall be bitmap encoded. The possible values are: 1273 0x00000001 PrePaid Accounting for Volume supported 1274 0x00000010 PrePaid Accounting for Duration supported 1275 0x00000011 PrePaid Accounting for Volume and Duration supported 1276 (non concurrently) 1277 Others Reserved, treat like Not Capable of PrePaid 1278 Accounting (=0). 1280 Sub-Type (=2) : Sub-Type for SelectedForSession attribute 1281 Length : Length of SelectedForSession attribute 1282 (= 6 octets) 1283 SelectedForSession (SfS): 1285 RADIUS Extensions for PrePaid February 2004 1287 The optional SelectedForSession Sub-Type, generated by the PrePaid 1288 server, indicates the PrePaid Accounting capability to be used for a 1289 given session. The possible values are: 1291 0x00000000 PrePaid Accounting not used 1292 0x00000001 Usage of PrePaid Accounting for Volume. 1293 (only possible if the AvailableInClient supports 1294 PrePaid Accounting for Volume) 1295 0x00000010 Usage of PrePaid Accounting for Duration. 1296 (only possible if the AvailableInClient supports 1297 PrePaid Accounting for Duration) 1298 0x00000011 Usage of PrePaid Accounting for Volume and Duration 1299 (non concurrent) (only possible if the 1300 AvailableInClient supports PrePaid Accounting for 1301 Volume and duration) 1302 Others Reserved, treat like PrePaid Accounting not used(=0). 1304 5.2 Session Termination Capability 1306 The value shall be bitmap encoded rather than a raw integer. This 1307 attribute shall be included RADIUS Access-Request message to the 1308 RADIUS server and indicates whether or not the NAS supports Dynamic 1309 Authorization. 1311 0 1 2 3 1312 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 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | TYPE | LENGTH | String | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 Type : value of Session Termination Capability 1318 Length: = 4 1319 String encoded as follows: 1321 0x00000001 Dynamic Authorization Extensions (rrfc3576) is 1322 supported. 1324 5.3 PPAQ Attribute 1326 RADIUS Extensions for PrePaid February 2004 1328 The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and 1329 Access-Accept messages. In Authorize Only Access-Request messages 1330 it is used to report usage and request further quota; in an Access- 1331 Accept message it is used to allocate the quota (initial quota and 1332 subsequent quotas). 1334 The attribute consists of a number of subtypes. Subtypes not used 1335 are omitted in the message. 1337 0 1 2 3 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | QuotaIdentifier (QID) | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | SUB-TYPE 2 | LENGTH | Volume Quota | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Volume Quota | SUB-TYPE 3 | LENGTH | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | VolumeThreshold (VT) | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | SUB-TYPE 6 | LENGTH | DurationQuota (DQ) | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | DurationThreshold (DT) | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | SUB-TYPE 9 | LENGTH | PrePaidServer | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | PrePaidServer | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 Type : Value of PPAQ 1368 Length: variable, greater than 8 1370 RADIUS Extensions for PrePaid February 2004 1372 String: The String value MUST be encoded as follows: 1374 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute 1375 Length : Length of QuotaIDentifier attribute (= 6 octets) 1377 QuotaIDentifier (QID): 1379 The QuotaIDentifier Sub-Type is generated by the PrePaid server 1380 at allocation of a Volume and/or Duration Quota. The on-line 1381 quota update RADIUS Access-Request message sent from the Service 1382 Access Device to the PPS shall include a previously received 1383 QuotaIDentifier. 1385 Sub-Type (=2): Sub-Type for VolumeQuota attribute 1386 Length : length of VolumeQuota attribute (= 6 octets) 1388 VolumeQuota (VQ): 1390 The optional VolumeQuota Sub-Type is only present if Volume Based 1391 charging is used. In RADIUS Access-Accept message (PPS to Service 1392 Access Device direction), it indicates the Volume (in octets) 1393 allocated for the session by the PrePaid server. In RADIUS 1394 Authorize Only Access-Request message (Service Access Device to 1395 PPS direction), it indicates the total used volume (in octets) 1396 for both forward and reverse traffic applicable to PrePaid 1397 accounting. 1399 Sub-Type (=3): Sub-Type for VolumeQuotaOverflow 1400 Length : length of VolumeQuotaOverflow attribute (= 4 octets) 1402 VolumeQuotaOverflow (VQO): 1404 The optional VolumeQuotaOverflow Sub-Type is used to indicate how 1405 many times the VolumeQuota counter has wrapped around 2^32 over 1406 the course of the service being provided. 1408 Sub-Type (=4): Sub-Type for VolumeThreshold attribute 1409 Length : length of VolumeThreshold attribute (= 6 octets) 1411 VolumeThreshold (VT): 1413 The VolumeThreshold Sub-Type shall always be present if 1414 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1416 RADIUS Extensions for PrePaid February 2004 1418 Service Access Device direction). It is generated by the PrePaid 1419 server and indicates the volume (in octets) that shall be used 1420 before requesting quota update. This threshold should not be 1421 larger than the VolumeQuota. 1423 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow 1424 Length : Length of VolumeThresholdOverflow attribute 1425 (= 4 octets) 1427 VolumeThresholdOverflow (VTO): 1429 The optional VolumeThresholdOverflow Sub-Type is used to indicate 1430 how many times the VolumeThreshold counter has wrapped around 1431 2^32 over the course of the service being provided. 1433 Sub-Type (=6): Sub-Type for DurationQuota attribute 1434 Length : length of DurationQuota attribute (= 6 octets) 1436 DurationQuota (DQ): 1438 The optional DurationQuota Sub-Type is only present if Duration 1439 Based charging is used. In RADIUS Access-Accept message (PPS to 1440 Service Access Device direction), it indicates the Duration (in 1441 seconds) allocated for the session by the PrePaid server. In on- 1442 line RADIUS Access-Accept message (PPC to PPS direction), it 1443 indicates the total Duration (in seconds) since the start of the 1444 accounting session related to the QuotaID. 1446 Sub-Type (=7): Sub-Type for DurationThreshold attribute 1447 Length : length of DurationThreshold attribute (= 6 octets) 1449 DurationThreshold (DT): 1451 The DurationThreshold Sub-Type shall always be present if 1452 DurationQuota is present in a RADIUS Access-Accept message (PPS 1453 to Service Access Device direction). It represents the duration 1454 (in seconds) that shall be used by the session before requesting 1455 quota update. This threshold should not be larger than the 1456 DurationQuota and shall always be sent with the DurationQuota. 1458 Sub-Type (=8): Sub-Type for Update-Reason attribute 1459 Length : length of Update-Reason attribute (= 4 octets) 1461 RADIUS Extensions for PrePaid February 2004 1463 Update-Reason attribute (UR): 1465 The Update-Reason Sub-Type shall be present in the on-line RADIUS 1466 Access-Request message (Service Access Device to PPS direction). 1467 It indicates the reason for initiating the on-line quota update 1468 operation. Update reasons 4, 5, 6, 7 and 8 indicate that the 1469 associated resources are released at the client side, and 1470 therefore the PPS shall not allocate a new quota in the RADIUS 1471 Access_Accept message. 1473 1. Pre-initialization 1474 2. Initial request 1475 3. Threshold reached 1476 4. Quota reached 1477 5. Remote Forced disconnect 1478 6. Client Service termination 1479 7. Main SI released 1480 8. Service Instance not established 1482 Sub-Type (=9) : Sub-Type for PrePaidServer attribute 1483 Length : Length of PrePaidServer 1484 (IPv4 = 6 octets, IPv6= 18 octets 1486 PrePaidServer: 1488 The optional, multi-value PrePaidServer indicates the address of 1489 the serving PrePaid System. If present, the Home RADIUS server 1490 uses this address to route the message to the serving PrePaid 1491 Server. The attribute may be sent by the Home RADIUS server. If 1492 present in the incoming RADIUS Access-Accept message, the PDSN 1493 shall send this attribute back without modifying it in the 1494 subsequent RADIUS Access-Request message, except for the first 1495 one. If multiple values are present, the PDSN shall not change 1496 the order of the attributes. 1498 NOTES: 1500 Either Volume-Quota or Time-Quota MUST appear in the attribute. 1501 Volume Threshold may only appear if Volume Quota appears 1502 If the Service Access Device can measure time, and if Time-Threshold 1503 appears with Volume Quota, then the Service Access Device should 1504 trigger a quota replenishment when the Current Time >= Time- 1505 Threshold. 1507 RADIUS Extensions for PrePaid February 2004 1509 5.4 Table of Attributes 1511 TO BE COMPLETED. 1513 Request Accept Reject Challenge # Attribute 1515 Authorize_Only Request Accept Reject 1517 6. Security Considerations 1519 The protocol exchanges described are susceptible to the same 1520 vulnerabilities as RADIUS and it is recommended that IPsec be 1521 employed to afford better security. 1523 If IPsec is not available the protocol in this draft improves the 1524 security of RADIUS. The various security enhancements are explained 1525 in the following sections. 1527 6.1 Authentication and Authorization 1529 RADIUS is susceptible to replay attacks during the Authentication 1530 and Authorization procedures. A successful replay of the initial 1531 Access-Request could result in an allocation of an initial quota. 1533 To thwart such an attack... 1535 6.2 Replenishing Procedure 1537 A successful replay attacks of the Authorize Only Access-Request 1538 could deplete the subscribers prepaid account. 1540 To be completed. 1542 7. IANA Considerations 1544 To be completed. 1546 RADIUS Extensions for PrePaid February 2004 1548 This draft does create RADIUS attributes. However, the authors 1549 recognize that it may not be possible to obtain such attributes. 1550 Therefore, in subsequent drafts it will be proposed to use a Vendor 1551 space as an Application Space. 1553 8. Normative References 1555 [RFC2026] Bradner, S., "The Internet Standards Process -- 1556 Revision 3", RFC 2026, October 1996. 1557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1558 Requirement Levels", RFC 2119, March 1997. 1559 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1560 "Remote Authentication Dial In User Server 1561 (RADIUS)", RFC 2865, June 2000. 1563 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1564 2000. 1566 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1567 Extensions", RFC 2869, June 2000. 1569 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1570 Holdrege, M., Goyret, I., "RADIUS Attributes for 1571 Tunnel Protocol Support" , RFC 2868, June 2000. 1572 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1573 Aboba, B., "Dynamic Authorization Extensions to 1574 Remote Authentication Dial-In User Service 1575 (RADIUS)", RFC 3576, February 2003. 1577 [DIAMETERCC] Work in Progress. 1578 [REDIRECT] RADIUS Redirection Internet Draft. Work in progress. 1579 RFC 2284 EAP 1581 Acknowledgments 1583 The authors would like to thank Mark Grayson, Nagi Jonnala and Joel 1584 Halpern, for their contribution to this draft. 1586 RADIUS Extensions for PrePaid February 2004 1588 Author's Addresses 1590 Avi Lior Parviz Yegani, Ph.D. 1591 Bridgewater Systems Mobile Wireless Group 1592 303 Terry Fox Drive Cisco Systems 1593 Suite 100 3625 Cisco Way 1594 Ottawa Ontario San Jose, CA 95134 1595 Canada USA 1596 avi@bridgewatersystems.com pyegani@cisco.com 1598 Kuntal Chowdhury Yong Li 1599 Nortel Networks Bridgewater Systems 1600 2221, Lakeside Blvd, 303 Terry Fox Drive 1601 Richardson, TX-75082 Suite 100 1602 chowdury@nortelnetworks.com Ottawa Ontario 1603 Canada 1604 Yong.li@bridgewatersystems.com 1606 Intellectual Property Statement 1608 The IETF takes no position regarding the validity or scope of any 1609 Intellectual Property Rights or other rights that might be claimed 1610 to pertain to the implementation or use of the technology described 1611 in this document or the extent to which any license under such 1612 rights might or might not be available; nor does it represent that 1613 it has made any independent effort to identify any such rights. 1614 Information on the IETF's procedures with respect to rights in IETF 1615 Documents can be found in BCP 78 and BCP 79. 1617 Copies of IPR disclosures made to the IETF Secretariat and any 1618 assurances of licenses to be made available, or the result of an 1619 attempt made to obtain a general license or permission for the use 1620 of such proprietary rights by implementers or users of this 1621 specification can be obtained from the IETF on-line IPR repository 1622 at http://www.ietf.org/ipr. 1624 The IETF invites any interested party to bring to its attention any 1625 copyrights, patents or patent applications, or other proprietary 1626 rights that may cover technology that may be required to implement 1627 this standard. Please address the information to the IETF at ietf- 1628 ipr@ietf.org. 1630 RADIUS Extensions for PrePaid February 2004 1632 Disclaimer of Validity 1634 This document and the information contained herein are provided on 1635 an ôAS ISö basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1636 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1637 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1638 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1639 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1640 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1642 Copyright Statement 1644 Copyright ¨ The Internet Society (2004). This document is subject to 1645 the rights, licenses and restrictions contained in BCP 78, and 1646 except as set forth therein, the authors retain all their rights. 1648 Expiration Date 1650 This memo is filed as draft-lior-radius-extensions-for-prepaid- 1651 04.txt, and will expire 14 January, 2005.