idnits 2.17.00 (12 Aug 2021) /tmp/idnits61187/draft-lior-radius-prepaid-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 17 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 -- 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 (24 February 2003) is 7025 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-chiba-radius-dynamic-authorization has been published as RFC 3576 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 INTERNET-DRAFT Bridgewater Systems 4 Category: Informational 5 draft-lior-radius-prepaid-extensions-00.txt P. Yegani 6 Expires: 25 August 2003 Cisco 8 Y. Li 9 Bridgewater Systems 10 24 February 2003 12 Prepaid Extensions to Remote Authentication Dial-In User Service 13 (RADIUS) 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of [RFC2026]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 The draft presents an extension to the Remote Authentication Dial-In 42 User Service (RADIUS) protocol to support Prepaid data services for 43 a wide range of deployments such as Dial, Wireless, WLAN. 44 Consideration for roaming using mobile-ip is also given. 46 Table of Contents 48 1. Introduction...................................................3 49 1.1 Terminology................................................4 50 1.2 Requirements language......................................4 51 2. Use-cases......................................................4 52 2.1 Simple use-case............................................5 53 2.2 Support for concurrent Prepaid sessions....................7 54 2.3 Support for Roaming........................................7 55 2.4 Prepaid termination........................................8 56 3. Architecture...................................................8 57 4. Operations....................................................12 58 4.1 General Requirements......................................12 59 4.1.1 Broker AAA Requirements..............................12 60 4.2 Authentication and Authorization..........................13 61 4.3 Session Start Operation...................................15 62 4.4 Mid-Session Operation.....................................16 63 4.4.1 Accounting Operation.................................16 64 4.4.2 Quota Replenishing Operation.........................16 65 4.5 Dynamic Operations........................................18 66 4.5.1 Unsolicited Session Termination Operation............19 67 4.5.2 Unsolicited Change Filter Operation..................19 68 4.6 Termination Operation.....................................20 69 4.7 Mobile IP Operations......................................21 70 5. Attributes....................................................22 71 5.1 PPCC attribute............................................22 72 5.2 Dynamic-Capabilities attribute............................23 73 5.3 PPQ-Response attribute....................................24 74 5.4 PPQ Attribute.............................................25 75 5.5 Service Type..............................................26 76 5.6 Table of Attributes.......................................26 77 6. Security Considerations.......................................26 78 6.1 Authentication and Authorization..........................26 79 6.2 Accounting Messages.......................................27 80 6.3 Replenishing Procedure....................................27 81 7. IANA Considerations...........................................28 82 8. Normative References..........................................28 83 9. Acknowledgments...............................................28 84 10. Author's Addresses...........................................29 85 11. Intellectual Property Statement..............................29 86 12. Full Copyright Statement.....................................30 87 Expiration Date..................................................30 89 1. Introduction 91 This draft describes RADIUS protocol extensions supporting Prepaid 92 Data Services. 94 Prepaid data services are cropping up in many wireless and wireline 95 based networks. A Prepaid Data Service subscriber is one that 96 purchases a contract to deliver a data service for either a period 97 of time, or a quantity of data. The subscriber purchases the Data 98 Service using various means such as buying a Prepaid Card, or 99 online. How the subscriber purchases his Prepaid Data Service 100 depends on the deployment and is not in scope for this document. 101 In some deployments, the Prepaid data service will be combined with 102 a prepaid voice service. This is not an issue for this document 103 other than the fact that the Prepaid Data Services described in this 104 paper should work with other prepaid data services. 105 The fundamental business driver for a carrier to provide prepaid 106 data services is to increase participation (subscriber base) and 107 therefore to increase revenues. 109 Therefore, it makes sense that prepaid services meet the following 110 goals: 112 - Leverage existing infrastructure, hence reducing capital 113 expenditures typically required when rolling a new service; 114 - Protect against revenue loss; 115 - Protect against fraud; 116 - Be as widely deployable over Dialup, Wireless and WLAN 117 networks. 119 The protocol described in this document maximizes existing 120 infrastructure as much as possible - hence the use of the RADIUS 121 protocol. The protocol is used in ways to protect against revenue 122 loss or revenue leakage. This is achieved by allocating small 123 quotas to each data session and having the ability to update the 124 quotas dynamically during the lifetime of a prepaid data session. 125 As well, mechanisms have been designed to be able to recover from 126 errors that occur from time to time. 128 Protection against fraud is provided by recording of accounting 129 records, by providing mechanisms to thwart replay attacks. As well, 130 mechanisms have been provided to terminate data sessions when fraud 131 is detected. 133 Prepaid System will become more prevalent and sophisticated as the 134 various networks such as Dialup, Wireless and WLAN converge. This 135 protocol extension is designed to meet the challenges of converged 136 networks. 138 The draft mainly addresses how to use the RADIUS protocol to achieve 139 a Prepaid Data Service. The details of the Prepaid System, such as 140 its persistent store, its rating capabilities, how it maintains its 141 accounts are not covered at all. However, in order to define the 142 RADIUS protocol extensions it is necessary to discuss the functional 143 behavior of the Prepaid System. 145 1.1 Terminology 147 Access Device 148 Prepaid Client 149 Prepaid Server 150 Home agent (HA) 151 Home AAA (HAAA) 152 Broker AAA (BAAA) 153 Visited AAA (VAAA) 154 Foreign Agent (FA) 156 1.2 Requirements language 158 In this document, several words are used to signify the requirements 159 of the specification. These words are often capitalized. The key 160 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 162 this document are to be interpreted as described in [RFC2119]. 164 2. Use-cases 166 In this section we present a set of use case that will help 167 establish the requirements needed to deliver a prepaid data service. 168 These use cases donÆt address how the prepaid account is established 169 or maintained. It is assumed that the prepaid subscriber has 170 obtained a valid account with a provider. 172 To make the document as general as possible, the use cases cover the 173 experience from the Access Device and not from the UserÆs Device. 174 The connection between the UserÆs Device, which typically involves 175 setting up a PPP session is specific to a given network technology 176 and the details are not required to deliver a Prepaid service. 178 2.1 Simple use-case 180 A Prepaid subscriber connects to his home network. As usual, the 181 Access Device that is servicing the subscriber will use the AAA 182 infrastructure to authenticate authorize the subscriber. 184 The Access Device sends an Access Request to the AAA system to 185 authenticate the subscriber, and identify and authorize the service. 186 The Access Request includes the subscriberÆs credentials and may 187 include the Prepaid capabilities of the Access Device. Prepaid 188 capabilities will be included if the Access Device has Prepaid 189 Client capabilities. 191 The AAA System proceeds with the authentication procedure. This may 192 involve several transactions such as in EAP. Once the subscriber 193 has been validated, the AAA system determines that the subscriber is 194 a Prepaid subscriber and makes a request of the Prepaid System to 195 authorize the prepaid subscriber. The request may include the 196 Prepaid Capabilities of the serving Access Device. 198 The Prepaid System will validate that the subscriber has a Prepaid 199 Account; it will validate that the Account is Active; and will 200 validate that the Access Device has the appropriate Prepaid 201 capabilities. If all is in order, the Prepaid System will authorize 202 the subscriber to use the network. Otherwise it will reject the 203 request. The response is sent back to the AAA System. The response 204 will include attributes for the Prepaid Client such as, the initial 205 quota (time or volume) and maybe a threshold value. 207 The Prepaid System allocates a portion of the subscribers account so 208 that we can support concurrent prepaid sessions. For example, the 209 subscriber may be on a prepaid voice call and may also have a 210 concurrent prepaid data session. Throughout the life of a session 211 the Access Device will request quota updates from the Prepaid 212 System. 214 The AAA system incorporates the prepaid attributes received from the 215 Prepaid System with the service attributes into an Access Response 216 message that it sends back to the Access Device. Note, the AAA 217 System determines the type of service whereas the Prepaid System is 218 only responsible for prepaid authorization. 220 Upon receiving the Access Response, the Access Device allows the 221 prepaid data session to start and it starts to meter the session 222 based on time or volume. 224 Once the usage for the session approaches the allotted quota, the 225 Access Device will, as instructed by the Prepaid System, request for 226 additional quotas. The re-authorization for additional quota flows 227 through the AAA system to the Prepaid System. The Prepaid System 228 revalidates the subscriberÆs account and if there is still a balance 229 it will reauthorize the request with an additional quota allotment. 230 Otherwise, the Prepaid System will reject the request. Note the 231 replenishing of the quotas is not a re-authentication procedure but 232 rather a re-authorization procedure. 234 It is important to note that the Prepaid System is maintaining 235 session state for the subscriber. In this case the state is how 236 much was allocated for the session and how much is left in the 237 account. It is required that all subsequent messages about the 238 prepaid session reach the correct Prepaid System. 240 Upon receiving a re-allotment of the quota, the Access Device will, 241 continue to service until the new threshold is reached. If the 242 Access Device receives a rejection, then it will let the subscriber 243 use up the remaining quota and then terminate the session. 245 Alternatively, instead of terminating the session, the Access Device 246 may restrict the data session such that the subscriber can only 247 reach a particular web server. This web server maybe used to allow 248 the subscriber to replenish their account. This restriction can 249 also be used to allow new subscribers to purchase a Prepaid Service. 250 Quota Recovery 252 In the above scenario, should the subscriber terminate the session 253 before the session is terminated the remaining balance allotted to 254 the session must be credited back to the subscriberÆs account. 256 As well, while the Access Device is waiting for the initial quota, 257 the subscriber may have dropped the session. The initial quota must 258 be credited back to the subscribers account. 260 2.2 Support for concurrent Prepaid sessions 262 The subscriber at any given time may initiate more than one session. 263 To support concurrent sessions the Prepaid System allocates a 264 portion of the account to any given session at any given time. 266 Each session is treated independently. 268 2.3 Support for Roaming 270 For some networks it is essential that Prepaid Data Services be 271 offered to roaming subscribers. Support for static and dynamic 272 roaming models are needed. Static roaming is where the subscriber 273 logs onto a foreign network. The foreign network has some roaming 274 agreement directly with the Home network or through a broker network 275 or networks. The subscriber remains logged into the network until 276 the subscriber changes location. When changing location a new 277 connection and a new login procedure is required. 279 Dynamic roaming allows to subscriber to move around and maintain a 280 connection with the home network seamlessly. As the subscriber 281 moves between networks, the data session is handed off between the 282 networks. 284 In both roaming scenarios, the subscriber always authenticates with 285 the home network. As well, subsequent messaging for the session 286 need to be received at the home network and more specifically at the 287 Prepaid System where state is being maintained. This behavior is 288 particularly challenging for dynamic roaming. To illustrate this, 289 supposing a subscriber establishes a prepaid session and is then 290 handed off to an Access Device that does not support prepaid 291 capabilities. 293 Static roaming is handled by proxy chains of broker AAA servers. 295 Static roaming or Dynamic roaming is handled by mobile-ip. Note 296 mobile-ip may also involve proxy chains. 298 2.4 Prepaid termination 300 When fraud is detected by the Prepaid System, or when an error is 301 detected, it may be beneficial for the Prepaid system to terminate a 302 specific session for the subscriber or all the sessions of a 303 subscriber. 305 Some errors can occur such that the Prepaid System is in a state 306 where it is not sure whether the session is in progress or not. 307 Under conditions such as this, the Prepaid system may wish to 308 terminate the prepaid data session to make sure that resources are 309 not being utilized for which it canÆt charge for reliably. 311 3. Architecture 313 A Prepaid Data Service deployment consists of Access Devices, AAA 314 servers, and Prepaid Servers. The subscriber device is not 315 implicated in the delivery of Prepaid Data Services. In mobile-ip, 316 the Home Agent may also be implicated in delivering a Prepaid Data 317 Service. 319 In order to be have as general a solution as possible, in this paper 320 we generalize the Access Devices, which in reality may be a NAS from 321 in Dialup deployments, PDSN in CDMA2000 deployments or an 802.11 322 WLAN Access Points. To actively participate in Prepaid procedures 323 outlined here, the Access Device MUST have Prepaid Client 324 capabilities. Prepaid Client Capabilities include the ability to 325 meter the usage for a prepaid data session; this usage includes time 326 or volume usage. An exception to this rule is during dynamic 327 roaming scenarios, where the Access Device can relegate its Prepaid 328 Client Capabilities to the Home Agent (HA). Furthermore, the Access 329 Device may also have Dynamic Session Capabilities that include the 330 ability to terminate a data session and/or change the filters 331 associated with a specific data session by processing Disconnect 332 Messages and Change of Filter messages as per [CHIBA]. 334 In this document RADIUS is used as the AAA server. There are three 335 kinds or categories of AAA servers. The AAA server in the home 336 network, the HAAA, is responsible for authentication of the 337 subscriber and also authorization of the service. In addition, the 338 HAAA communicates with the Prepaid servers using the RADIUS protocol 339 to authorize prepaid subscribers. In roaming deployments the AAA 340 server in the visited network, the VAAA, is responsible for 341 forwarding the RADIUS messages to the HAAA. The VAAA may also 342 modify the messages. In roaming deployments, the visited network 343 may be separated from the home network by one or more broker 344 networks. The AAA servers in the broker networks, BAAA are 345 responsible to route the RADIUS packets and hence donÆt play an 346 active roll in the Prepaid Data Service delivery. 348 In this document the Prepaid Server are described in functional 349 terms related to their interface with the HAAA. The Prepaid Server 350 maintains the accounting state of the prepaid subscribers. As well, 351 the Prepaid Server maintains state for each active prepaid data 352 service session. This state includes, allocated quotas, the last 353 known activity counters (time or volume) for the prepaid 354 subscriberÆs data session. These counters are continuously being 355 updated during the lifetime of the Prepaid data service. 357 The various deployments for Prepaid are presented in the remainder 358 of this section. The first deployment is the basic Prepaid data 359 service and is depicted in figure 1. Here the Access Device and the 360 HAAA and the Prepaid Server are collocated in the same provider 361 network. 363 The Subscriber Device establishes a connection with one of several 364 Access Devices in the network. The Access Device communicates with 365 one or more HAAA servers in the network. To provide redundancy more 366 then one HAAA is available to use by an Access Device. 368 The network will have one or more Prepaid Servers. Multiple Prepaid 369 Servers will be used to provide redundancy and load sharing. The 370 interface between the HAAA and the PPS is the RADIUS protocol in 371 this specification. However, in cases where the PPS does not 372 implement the RADIUS protocol, the implementation would have to map 373 the requirements defined in this document to whatever protocol is 374 used between the HAAA and the PPS. 376 +------+ +-----+ 377 | | | | 378 +--------+ +--------+ +--| HAAA |--+--| PPS | 379 | | | | | | | | | | 380 | Sub | | Access | | +------+ | +-----+ 381 | |---| |--+ | 382 | Device | | Device | | +------+ | +-----+ 383 | | | | | | | | | | 384 +--------+ +--------+ +--| HAAA |--+--| PPS | 385 | | | | 386 +------+ +-----+ 388 Figure 1 Basic Prepaid Architecture 390 The following figure shows a static roaming prepaid architecture 391 that is typical of a wholesale scenario for Dial-Up users or a 392 broker scenario used in Dial-Up or WLAN roaming scenarios. 394 +----+ +----+ +----+ +-----+ 395 | | | | | | | | 396 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 397 | | | | | | | | | | | | | | | | 398 |Sub | |Access| | +----+ | +----+ | +----+ | +-----+ 399 | |--| |-+ | | | 400 |Device| |Device| | +----+ | +----+ | +----+ | +-----+ 401 | | | | | | | | | | | | | | | | 402 +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 403 | | | | | | | | 404 +----+ +----+ +----+ +-----+ 406 | Visited | |Broker | | Home | 407 | Network | |Network| | Network | 409 Figure 2 Static Roaming Prepaid Architecture 411 As in the basic prepaid architecture the subscriberÆs device 412 establishes a connection with the Access Device (NAS, WLAN Access 413 Point). The Access Device communicates with the Visiting AAA server 414 (VAAA) using the RADIUS protocol. Again for redundancy there maybe 415 more then one VAAA. The VAAA communicate using the RADIUS protocol 416 with AAA servers in the broker network (BAAA). There maybe more 417 then one Broker Network between the Visited Network and the Home 418 Network. The Home Network is the same as in the simple 419 architecture. 421 To support dynamic roaming the network will utilize mobile-ip. 422 Figure 3 illustrates a typical mobile-ip deployment. Note that 423 typically the mobile device would be moving between networks that 424 use the same technology such as Wireless or WLAN. Increasingly, 425 device will be able to roam between networks that use different 426 technology such as between WLAN and Wireless and Broadband. 427 Fortunately, mobile-ip can address this type of roaming and 428 therefore we need not be concerned with the underlying network 429 technology. 431 +------+ +------+ +----+ +----+ +----+ +-----+ 432 | | | | | | | | | | | | 433 |Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS | 434 | |--|Device| | | | | | | | | 435 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 436 | | | | | | 437 +------+ +------+ | | 438 | | | +----+ 439 | | | | | 440 |ROAMS +------------------+ HA | 441 | | | | 442 V +----+ | +----+ 443 +------+ +------+ | | | | 444 | | | | +-|VAAA+------+ | 445 |Sub | |Access| | | | | 446 | |--|Device+-+ +----+ | 447 |Device| | (FA) | | 448 | | | +------------------------+ 449 +------+ +------+ 451 Figure 3 Roaming using mobile-ip 453 In the figure 3, the Subscriber device establishes a prepaid session 454 between the Access Device in the foreign network, which has prepaid 455 capabilities and the Home Agent (HA). The setup for this service is 456 identical to the cases covered above. Notice that the Access Device 457 is known as the Foreign Agent (FA). As the subscriber device moves 458 to another network it establishes a connection with another Access 459 Device in another foreign network. The prepaid data service should 460 continue to be available. When a device associates to another 461 Access Device it MUST re-authenticate at the new Access Device and 462 de-associate or logoff the old Access Device. Furthermore, any 463 unused quota at the old Access Device MUST be promptly credited back 464 to the subscribers account. The reason we say promptly, is because 465 if the subscriber is very low on resources to start with, the 466 subscriber may not have enough resources to log on to the new Access 467 Device. The speed at which resources can be returned depend on the 468 type of handoff procedure that is used: dormant handoff vs. active 469 handoff vs. fast handoff. 471 As well, notice that if the Access Devices could communicate with 472 each other then there could be a way to accelerate a faster handoff 473 procedure. In particular, it could accelerate the return of the 474 unused portion of the quotas from the old Access Device. 476 Unfortunately, standards are evolving with each network technology 477 creating their own scheme to make the handoff procedures more 478 efficient. 480 4. Operations 482 4.1 General Requirements 484 4.1.1 Broker AAA Requirements 486 The intent of this document is to minimize the requirement impacts 487 on the Broker AAA servers. The BAAA servers function is to forward 488 the RADIUS packets as usual to the appropriate RADIUS servers with 489 the following considerations. 491 Accounting messages are used to keep the Prepaid Server current as 492 to what is happening with the prepaid data session. Therefore, 493 Broker AAA servers SHOULD perform their forwarding function of 494 accounting packets associated with prepaid data sessions in a pass 495 through fashion as described in [RFC2866] section 2.1. 497 In addition, if the BAAA server fails to forward the prepaid data 498 session accounting packets, it MAY store them locally but it SHOULD 499 NOT generated an Accounting Response packet back to its client. 501 The BAAA MUST be capable of supporting the encryption procedures 502 specified in [RFC2868] section 3.5. 504 4.2 Authentication and Authorization 506 The Access Device initiates the authentication and authorization 507 procedure by sending a RADIUS Access Request as usual. 509 If the Access Device has Prepaid Client capabilities, it MUST 510 include the PPCC attribute in the RADIUS Access Request. The PPCC 511 attribute indicates to the Prepaid server the prepaid capabilities 512 possessed by the Access Device. These are required in order to 513 complete the prepaid authorization procedures. 515 The PPCC is encrypted using the same procedure as in [RFC2868] 516 Section 3.5 and includes the Event-Timestamp(55) which protects 517 against replay attacks. 519 If the Access Device supports the Disconnect Message capabilities or 520 the Change of Filter Message capabilities, then it SHOULD include 521 the Dynamic-Capabilities attribute. The Dynamic-Capabilities 522 attribute will indicate to the PPS if the Access Device will support 523 the Disconnect Message or the Change of Filter Message. 525 In certain deployments, there may be other ways in which to 526 terminate a data session, or change the filter id on an Access 527 device. For example, some Access Devices provide a session 528 termination service via Telnet or SNMP. In these cases the AAA 529 server MAY add the Dynamic-Capabilities message to the Access 530 Request. 532 If the authentication procedure involves multiple Access Requests 533 (as in EAP), the Access Device MUST include the PPCC attribute and 534 the Dynamic-Capabilities attribute (if used) in at least the last 535 Access Request during the authentication procedure. 536 The Access Request will be sent as usual to the HAAA. The packet 537 may be proxied through zero or more BAAA. The BAAA SHALL treat the 538 PPCC as a undistinguished octets and re-encrypt the PPCC as it 539 forwards the Access Request to the HAAA. No interpretation by the 540 BAAA should be made. 542 Once the Access Request arrives at the HAAA, the HAAA will 543 authenticate the subscriber. If the subscriber is not 544 authenticated, the HAAA will send an Access Reject message back to 545 the client. If the subscriber is authenticated, the HAAA will 546 determine whether or not the subscriber is a Prepaid subscriber. 547 The techniques used to determine whether or not a subscriber is a 548 prepaid subscriber is beyond the scope of this document. If the 549 subscriber is not a prepaid subscriber, then the HAAA will respond 550 as usual with an Access Accept or Access Reject message. If the 551 subscriber is a Prepaid Subscriber the HAAA SHALL forward the Access 552 Request to a Prepaid server for further authorization. 554 The Access Request will contain the PPCC attribute, the Dynamic- 555 Capabilities attribute if one was included; the User-Name(1) 556 attribute would be set to a value that would represent the 557 SubscriberÆs Prepaid Identity. This attribute will be used by the 558 Prepaid server to locate the Prepaid SubscriberÆs account. For 559 added security, the HAAA MAY also set the User-Password(2) attribute 560 to the password used between the HAAA and the Prepaid server. 562 The Prepaid server will validate the Access Request by decrypting 563 the PPCC and checking the Event-Timestamp(55). The Prepaid server 564 will lookup the subscriberÆs prepaid account and authorize the 565 subscriber taking into consideration the Access Device Prepaid 566 Client Capabilities. 568 Upon successful authorization, the Prepaid server will generate an 569 Access Accept containing the initial PPQ-Response attribute which 570 contains the following sub-attributes: 572 -The QUOTA-Id which is set by the Prepaid server to a unique 573 value that is used to correlate subsequent quota updates; 575 -Volume and Time Quotas, one of which is set to a value 576 representing a portion of the subscribers account; 578 -The Time of Volume Threshold that the Prepaid server MAY set to 579 control when the Access Device requests additional quota. 581 The Prepaid Referral the first one is set to the IP address of the 582 Serving Prepaid Server, the second one is set to an alternate 583 Prepaid Server. This way the HAAA will be able to route subsequent 584 packets to the serving Prepaid Server or its alternate. 586 Additionally, the Prepaid server MAY set the Terminate-Action(29) to 587 RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control 588 how often interim Accounting Requests are generated. 590 Depending on site policies, upon unsuccessful authorization, the 591 Prepaid server will generate an Access Reject or an Access Accept 592 and set the Filter-Id(11) or the Ascend-Data-Filter (if supported) 593 attribute and the Session-Timeout(27) attribute such that the 594 Prepaid subscriber could get access to a restricted set of locations 595 for a short duration to allow them to replenish their account, or 596 create an account; or to browse free content. 598 Upon receiving the Access Accept from the Prepaid Server, the HAAA 599 will append the usual service attributes and forward the packet. 600 The HAAA SHALL NOT append any attributes already set by the Prepaid 601 server. If the HAAA, receives an Access Reject message, it will 602 simply forward the packet to its client. Depending on site 603 policies, if the HAAA fails to receive an Access Response message 604 from the Prepaid server it MAY do nothing or send an Access Reject 605 or an Access Accept message back to its client. 607 4.3 Session Start Operation 609 The real start of the session is indicated by the arrival of 610 Accounting Request(Start) packet. The Accounting Request (Start) 611 MUST be routed to the Prepaid Server so that it can confirm the 612 initial quota allocation. 614 In addition to the usual attributes, the Accounting Request(Start) 615 message MUST contain the PPQ attribute. 617 HAAA receives the Accounting Request(Start) packet and MAY record 618 it. If the packet is associated with a prepaid subscriber (it 619 contains a PPQ attribute) it SHALL forward the packet to the serving 620 Prepaid server or its secondary if any. 622 The Prepaid server SHALL respond with an Accounting Response packet 623 as usual. 625 The HAAA server SHALL respond with an Accounting Response packet if 626 it forwarded the Accounting Request(Start) packet to the Prepaid 627 server and it received the Accounting Response packet; and if it was 628 responsible for recording the Accounting Request(Start) packet, it 629 did so successfully. 631 4.4 Mid-Session Operation 633 During the lifetime of a session the Access Device will generate 634 accounting messages as usual and request to replenish the quotas. 636 4.4.1 Accounting Operation 638 During the normal data session the Access Device will generate 639 Accounting Requests(start), Accounting Requests(stop) and Accounting 640 Request(Interim). 642 These Accounting records are needed by the Prepaid server to keep an 643 accurate running usage record for each data session and to be able 644 to correctly credit the accounts of a prepaid subscriber during 645 faults. 647 If these Accounting messages are associated with a Prepaid data 648 service, then the Access Device MUST include the PPQ attribute. 650 The HAAA will forward any accounting packets received to the primary 651 Prepaid server and failing that the secondary Prepaid server 652 identified in the PPQ attribute. 654 The HAAA may record the accounting packets locally as well. 656 The Prepaid Server MUST respond with an Accounting Response packet. 658 The HAAA server MUST respond with an Accounting Response packet if 659 it forwarded the Accounting Request packet to the Prepaid server and 660 it received the Accounting Response packet; and if it was 661 responsible for recording the Accounting Request packet, it did so 662 successfully. 664 4.4.2 Quota Replenishing Operation 666 Once the allocated quota has been reached or the threshold has been 667 reached, the Access Device MUST send an Access Request with Service- 668 Type(6) set to a value of Prepaid and it MUST contain the PPQ 669 attribute. 671 The other attributes should be the same as were used in the Access 672 Request during the Authentication and Authorization phase except for 673 the User Password or Chap Password, which should be left out. This 674 Access Request is only used for reauthorization and not re- 675 authentication and the passwords are not required. The encrypted 676 PPQ attribute acts as the credential for the Access Request. 678 As during the Authentication and Authorization phase, the BAAA SHALL 679 forward the Access Request message to the HAAA validating decrypting 680 and re-encrypting the PPQ attribute. Note that the BAAA will treat 681 the PPQ as non-distinguished octets. 683 The HAAA SHALL receive the Access Request, decrypt the PPQ, validate 684 it and use the PPS-referral attributes to route the Access Request 685 to the correct Prepaid server. The HAAA MAY modify the User-Name(1) 686 attribute as it has done during the initial Access Request. Note 687 the Prepaid server will use the Quota-ID sub-attribute contained 688 within the PPQ to locate the user account. The HAAA MAY add the 689 Username-Password(2) attribute and set itÆs value to the password it 690 shares with the Prepaid server. The HAAA will re-encrypt the PPQ. 692 The Prepaid server will validate the Access Request by decrypting 693 the PPQ and checking the Event-Timestamp. If the User-Password(2) 694 is specified, the Prepaid server will use it to ensure that the HAAA 695 is valid. 697 The Prepaid server will lookup the prepaid session by using the 698 Prepaid Quota Id contained within the PPQ. The Prepaid Server would 699 then re-authorize the subscriber by allotting it a new quota. The 700 Prepaid Server may want to calculate a different threshold values as 701 well. 703 Note: At the Prepaid server, the PPQ and the QUOTA-ID is acting as 704 the credential for the subscriber. The User-Name(1) attribute is 705 used to route the Access Request to the correct HAAA. The User- 706 Password if supplied, is used to authenticate the HAAA at the 707 Prepaid server. 709 Upon successful re-authorization, the Prepaid server will generate 710 an Access Accept containing the PPQ-Response attribute. 712 Depending on site policies, upon unsuccessful authorization, the 713 Prepaid server will generate an Access Reject or an Access Accept 714 with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute 715 and the Session Timeout attribute such that the Prepaid subscriber 716 could get access to a restricted set of locations for a short 717 duration to allow them to replenish their account, or create an 718 account. Or to browse free content. The Prepaid server MAY add the 719 Terminate-Action(29) attribute with the value of RADIUS-Request, to 720 allow the Access Device to try to get a new quota allocated before 721 booting the subscriber off. 723 Upon receiving the Access Accept from the Prepaid server, the HAAA 724 SHALL return the packet to its client. If the HAAA, receives an 725 Access Reject message, it will forward the packet. Depending on 726 site policies, if the HAAA fails to receive an Access Response 727 message from the Prepaid server it MAY do nothing or send an Access 728 Reject message back to its client. 730 Upon receiving an Access Accept, the Access Device SHALL update its 731 quotas and threshold parameters with the values contained in the 732 PPQ-Response packet. Note that the Prepaid server MAY update the 733 PPS-referral attributes and these may have to be saved as well. 735 Upon receiving an Access Accept message containing either Filter- 736 Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). 737 The Access Device SHALL restrict the subscriber session accordingly. 739 4.5 Dynamic Operations 741 The Prepaid server may want to take advantage of the dynamic 742 capabilities that are supported by the PPClient as advertised in the 743 Dynamic-Capabilities attribute during Access Request. 745 There are two type of actions that the Prepaid server can perform: 746 it can request that the session be terminated; or it can request 747 that the filters associated with the session be modified. 749 Both of these actions require that the session be uniquely 750 identified at the Access Device. As a minimum the Prepaid server: 752 -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) 753 -MUST provide the Accounting-Session-Id(44) 755 Other attributes could be used to uniquely identify a prepaid data 756 session. 758 4.5.1 Unsolicited Session Termination Operation 760 Prepaid server send a Disconnect Request packet that MUST contain 761 identifiers that uniquely identify the subscriberÆs data session and 762 the Access Device holding that session. 764 The HAAA upon receiving the Disconnect Request packet will either 765 act on it or will proxy it to another AAA server until it is 766 received by a AAA that can process the Disconnection Request packet. 768 Each AAA MUST have the knowledge to route the packet. How the 769 routing decision is made is an implementation detail. 771 Once the Disconnect Request packet reaches a AAA that can act on it. 772 The AAA will either send the Disconnect Request packet to the Access 773 Device directly or it may have to use SNMP or Telnet to command the 774 Access Device to terminate the session. 776 If the Access Device receives a Disconnect Request packet, it will 777 respond with either a Disconnect-ACK packet if it was able to 778 terminate the session or else it will respond with a Disconnect-NAK 779 packet. 781 If the AAA server is performing the disconnect operation, it MUST 782 respond with a Disconnect ACK message if it successfully terminated 783 the session or a Disconnect NAK message if it failed to terminate 784 the session. 786 If a AAA server was unable to route the Disconnect request it MUST 787 respond with a Disconnect-NAK packet. 789 Issue: A reason code in the NAK message should be provided so that 790 the prepaid server knows why the Disconnect failed. This may be 791 under consideration now by Chiba et al. 793 4.5.2 Unsolicited Change Filter Operation 795 The Prepaid server sends a Change of Filter packet it MUST contain 796 identifiers that will uniquely identify the subscriber session and 797 the Access Device serving that session. 799 The HAAA upon receiving the Change of Filter packet will either act 800 on it or will proxy it to another AAA server until it is received by 801 a AAA that can process the Change of Filter packet. 803 Each AAA MUST have the knowledge to route the packet. How the 804 routing decision is made is an implementation detail. 806 Once the Change of Filter packet reaches a AAA that can act on it. 807 The AAA will either send the Change of Filter packet to the Access 808 Device directly or it may have to use SNMP or Telnet to command the 809 Access Device to change its filters. 811 If the Access Device receives a Change of Filter packet, it will 812 respond with either a Change of Filter-ACK packet if it was able to 813 change the filter or else it will respond with a Change of Filter - 814 NAK packet 816 If the AAA server is performing the change of filter operation, it 817 MUST respond with a Change of Filter-ACK message if it successfully 818 or a Change of Filter-NAK packet if it failed to change the filter. 819 If a AAA server was unable to route the Change of Filter request it 820 MUST respond with a Change of Filter-NAK packet. 822 Issue: A reason code in the NAK message should be provided so that 823 the prepaid server knows why the Change of Filter failed. 825 4.6 Termination Operation 827 The termination phase is initiated when the Subscriber logs off, the 828 quotas have been consumed, or when the Access Device receives a 829 Disconnect Message. In all of these instances, if the session is a 830 prepaid data session, the Access Device will generate and Accounting 831 Request (stop) packet that MUST contain the PPQ attribute with 832 Reason set to Terminate. 834 The BAAA MUST forward this packet to the next BAAA or the HAAA. 836 The HAAA MUST use the referral information in the PPQ to forward the 837 Accounting Request(stop) packet to the serving Prepaid Server or its 838 alternate if needed. The HAAA MAY record the Accounting 839 Request(stop) packet. 841 The Prepaid Server SHALL use the information contained in the PPQ 842 attribute of the Accounting Request(stop) packet to adjust the 843 subscriberÆs balance and to close the session. The Prepaid Server 844 SHALL respond back with an Accounting Response. 846 The HAAA SHALL respond with an Access Response packet if it has 847 received the Access Response from the Prepaid Server, and if it was 848 responsible for recording the Accounting message, it did so 849 successfully. 851 In addition to getting the Accounting Request(stop) packet, at the 852 end of the data session. In more robust deployments, the Access 853 Device MAY have been instructed by the Prepaid Server to generate an 854 Access Request message by the inclusion of the Terminate-Action(29) 855 attribute with a value of RADIUS-Request in the Access Accept 856 message. In this case, if the session is prepaid, the Access Device 857 generates an Access Request that MUST containing the PPQ attribute 858 with a Service-Type(6) set to Prepaid. The Reason sub-attribute of 859 the PPQ attribute SHALL be set to Terminate. 861 The BAAA SHALL forward the Access Request to the next BAAA or the 862 HAAA. 864 Upon receiving an Access Request message with Service-Type(6) set to 865 Prepaid, the HAAA SHALL use the referral information contained in 866 the PPQ attribute to route the Access Request to the serving Prepaid 867 Server or its alternate. The HAAA MAY add the User-Password(2) 868 attribute with the password shared between it and the Prepaid 869 Server. 871 Upon the receiving the Access Request, the Prepaid server will 872 examine the PPQ attribute and use the Quota-ID to locate the session 873 and adjust the subscriberÆs account accordingly and close the 874 session. The Prepaid Server SHALL reply with an Access Accept 875 message. 877 4.7 Mobile IP Operations 879 In roaming scenarios using mobile-ip, as the mobile subscriber roams 880 between networks, or between different types of networks such as 881 between WLAN and CDMA2000 networks, the prepaid data session is 882 maintained transparently. 884 As the subscriber device associates with the new Access Device, the 885 Access Device sends a RADIUS Access Request and the subscriber is 886 re-authenticated and reauthorized. If the Access Device has Prepaid 887 Client capabilities, it MUST include the PPCC attribute in the 888 RADIUS Access Request. In this manner the procedure follows the 889 Authentication and Authorization procedure described earlier. 891 The Access Request message is routed to the home network and MUST 892 reach the Prepaid System that is serving the prepaid session. The 893 Prepaid system will then correlate the new authorization request 894 with the existing active session and will assign a quota to the new 895 request. Any outstanding quota at the old Access Device will be 896 returned to the Prepaid system due to the usual mobile-ip handoff 897 procedures. Specifically, the quota will be returned when the 898 Access Device sends the Accounting Request (stop) message. The 899 Prepaid system may issue a Disconnect Message to the Access Device 900 as well. 902 If the subscriber has roamed to an Access Device that does not have 903 any Prepaid Capabilities, prepaid data service may still be possible 904 by requesting the Home Agent (providing it has Prepaid Capabilities) 905 to assume responsibilities for metering the service. The procedure 906 for this scenario will be given in the next release of this draft. 908 5. Attributes 910 As currently written, this draft is using the RADIUS [RFC2865] 911 namespace. 913 Subsequent version will probably be written to use VSAs. However, 914 the Vendor Identifier that would be proposed would be Prepaid 915 Application. 917 Note as currently written, this draft proposes to use container 918 types, or attributes that contain sub-attributes, that will have 919 attributes from the prepaid space and also attributes belonging to 920 RADIUS space. The technique for encoding such a structure will be 921 identified in future release of this document. 923 5.1 PPCC attribute 925 The PPCC at tribute is sent in the Access Request message and is 926 used to describe the Access Devices prepaid capabilities. The 927 attribute is encrypted using the procedures defined in [RFC2868 ] 928 section 3.5. 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | VALUE (Event-Timestamp) | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | SUB-TYPE 2 | LENGTH | VALUE (PP-capabilities) | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 TYPE: value of PPCC 943 LENGTH: 14 945 SUB-TYPE 1: 55 946 LENGTH: 6 947 DESCRIPTION: 948 The Event-Timestamp as defined by [RFC2869] 950 SUB-TYPE 2: value of PP-capabilities 951 LENGTH: 4 952 DESCRIPTION: 953 BIT-MAP with the following values: 954 1 Time metering 955 2 Volume metering 956 >2 Reserved 958 5.2 Dynamic-Capabilities attribute 960 The Dynamic Capabilities attribute is sent in the Access Request and 961 describes the capabilities of the Access Device. Mainly it 962 describes the method for support for unsolicited session termination 963 and the method for support of unsolicited change of filters. 965 Subtype: Session-Termination-Methods 1 966 -None 967 -Disconnect-Message [CHIBA] 968 -Telnet 969 -SNMP 971 Subtype: Dynamic-Filter-Capabilities 1 972 -None 973 -CoF [CHIBA] 974 -Telenet 975 -SNMP 977 5.3 PPQ-Response attribute 979 The PPQ-Response attribute is sent in the Access Response and 980 describes the current quota for a given prepaid data session. 982 Subtype Quota ID 1 984 Assigned by the Prepaid server at the start of the session. It is 985 used to correlate all other transactions for the given prepaid data 986 session. 988 Subtype Volume-Quota 0-1 990 Optional. The maximum number of octets that are allowed for this 991 session since the beginning of the session. 993 Subtype Volume-Threshold 0-1 995 Optional. Defines when to trigger quota replenishment. Current 996 Octets >= Volume-Threshold. 998 Subtype Time-Quota 0-1 1000 Optional. The maximum number of seconds that are allowed for this 1001 session as measured from the beginning of the session. 1003 Subtype Time-Threshold 0-1 1005 Optional. Defines when to trigger quota replenishment. Current 1006 Octets >= Time-Threshold 1008 Subtype Action 1 1010 Defines what to do when the quota has been reached. 1012 -Drop the session 1013 -Replenish 1015 Subtype PPS-Referral 1..2 1017 The first PPS-Referral attribute MUST be included and contains the 1018 IP address of the primary serving Prepaid server. The second PPS- 1019 Referral attributes MAY be included and contains the IP address of 1020 the secondary serving Prepaid server. 1022 NOTES: 1024 Either Volume-Quota or Time-Quota MUST appear in the attribute. 1025 Volume Threshold may only appear if Volume Quota appears 1026 If the Access Device can measure time, and if Time-Threshold appears 1027 with Volume Quota, then the Access device should trigger a quota 1028 replenishment when the Current Time >= Time-Threshold. 1030 5.4 PPQ Attribute 1032 This attribute reports the current prepaid usage at the access 1033 device. It is contained in both the Access Request messages and 1034 Accounting Requests message. 1036 Subtype Quota ID 1 1038 The Quota-ID assigned by the Prepaid server during the Access 1039 Response. 1041 Subtype Event-Timestamp(55) 1 1043 Used to protect against replay attacks 1045 Subtype Current-Volume 0-1 1047 Optional. The current volume in octets since the session started. 1049 Subtype Current-Time 0-1 1051 Optional. The number of seconds since the session started. 1053 Subtype Reason 1 1054 The reason for sending this attribute: 1056 -Interim, 1057 -QuotaReplenish, 1058 -Terminate 1060 Subtype PPS-Referral 1..2 1062 The IP address of the primary serving Prepaid Server and optionally 1063 the IP address of the secondary serving Prepaid server. 1065 5.5 Service Type 1067 The following is a new value for the Service-Type(6) attribute. 1069 12 Prepaid 1071 5.6 Table of Attributes 1073 TO BE COMPLETED. 1075 Request Accept Reject Challenge # Attribute 1077 6. Security Considerations 1079 The protocol exchanges described are susceptible to the same 1080 vulnerabilities as RADIUS and it is recommended that IPsec be 1081 employed to afford better security. 1083 If IPsec is not available the protocol in this draft improves the 1084 security of RADIUS. The various security enhancements are explained 1085 in the following sections. 1087 6.1 Authentication and Authorization 1089 RADIUS is susceptible to replay attacks during the Authentication 1090 and Authorization procedures. The protocol given in this draft 1091 prevents replay attacks that can cause havoc such as the depletition 1092 the subscribers prepaid account. 1094 The Access Request originating at a Prepaid Capable access device 1095 include the PPCC attribute which contains the Event-Timestamp(55) 1096 attribute and the PPCC is encrypted. Therefore the Prepaid System 1097 can use the attribute to detect replay attacks. 1099 6.2 Accounting Messages 1101 Accounting messages are signed by the RADIUS protocol but they are 1102 also susceptible to replay attacks. However, since accounting 1103 messages are designed for recording purposes, no harm come by a 1104 replay attack. The accounting subsystem should be able to detect 1105 and remove duplicate records. Accounting records associated with 1106 prepaid data session contain the PPQ attribute with contains the 1107 Event-Timestamp(55) attribute. Even though Accounting messages are 1108 still only used for record keeping, replay attacks can be detected 1109 and prevented. 1111 6.3 Replenishing Procedure 1113 The Access Request message used in the Replenishing procedure 1114 contains the User-Name(1) attribute but does not contain User- 1115 Password or Chap-Password. This is because this message is used for 1116 Re-authorizing additional quotas. Never-the-less security is a 1117 concern. 1119 The subscriber password is not used because it is only available 1120 during subscriber authentication. The Access Device should not keep 1121 the subscriber's password. Furthermore, the password may not have 1122 been available in the first place since the EAP type of 1123 authentication may have been used. EAP only exists during 1124 authentication. 1126 The User-Name(1) attribute contains the NAI of the subscriber. The 1127 purpose of this attribute is to route the Access Request message to 1128 the home network. 1130 The Access Request contains the PPQ attribute which contains the 1131 Event-Timestamp(55) and the Quota-ID sub-attributes. This attribute 1132 is encrypted and provides the following security mechanisms. The 1133 inclusion of the Event-Timestamp(55) is used to prevent replay 1134 attacks. The Quota-ID was allocated by the Prepaid server and 1135 uniquely identifies the subscriber. Therefore the Prepaid Server 1136 uses the PPQ attribute as the credential of the subscriber. Since 1137 this attribute is encrypted it forms a very reliable credential for 1138 the prepaid subscriber at the Prepaid server. 1140 7. IANA Considerations 1142 This draft does create RADIUS attributes nor any new 1143 number spaces for IANA administration. However, the authors 1144 recognize that it may not be possible to obtain such attributes. 1145 Therefore, is subsequent drafts it will be proposed to use a Vendor 1146 space as an Application Space. 1147 This draft requires assignment of new values to existing RADIUS 1148 attributes. These include: 1150 Attribute Values Required 1151 ========= =============== 1152 Service-Type Prepaid(12) 1154 8. Normative References 1156 [RFC2026] Bradner, S., "The Internet Standards Process -- 1157 Revision 3", RFC 2026, October 1996. 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", RFC 2119, March 1997. 1160 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1161 "Remote Authentication Dial In User Server (RADIUS)", 1162 RFC 2865, June 2000. 1164 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1166 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1167 Extensions", RFC 2869, June 2000. 1169 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1170 Holdrege, M., Goyret, I., "RADIUS Attributes for 1171 Tunnel Protocol Support" , RFC 2868, June 2000. 1172 [CHIBA] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1173 Aboba, B., "Dynamic Authorization Extensions to 1174 Remote Authentication Dial-In User Service (RADIUS)", 1175 Internet Draft (work in progress), draft-chiba- 1176 radius-dynamic-authorization-07.txt, February 2003. 1178 Acknowledgments 1179 Author's Addresses 1181 Avi Lior Parviz Yegani, Ph.D. 1182 Bridgewater Systems Mobile Wireless Group 1183 303 Terry Fox Drive Cisco Systems 1184 Suite 100 3625 Cisco Way 1185 Ottawa Ontario San Jose, CA 95134 1186 Canada USA 1187 avi@bridgewatersystems.com pyegani@cisco.com 1189 Yong Li 1190 Bridgewater Systems 1191 303 Terry Fox Drive 1192 Suite 100 1193 Ottawa Ontario 1194 Canada 1195 Yong.li@bridgewatersystems.com 1197 Intellectual Property Statement 1199 The IETF takes no position regarding the validity or scope of any 1200 intellectual property or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; neither does it represent that it 1204 has made any effort to identify any such rights. Information on the 1205 IETF's procedures with respect to rights in standards-track and 1206 standards-related documentation can be found in BCP-11. Copies of 1207 claims of rights made available for publication and any assurances 1208 of licenses to be made available, or the result of an attempt made 1209 to obtain a general license or permission for the use of such 1210 proprietary rights by implementers or users of this specification 1211 can be obtained from the IETF Secretariat. 1213 The IETF invites any interested party to bring to its attention any 1214 copyrights, patents or patent applications, or other proprietary 1215 rights which may cover technology that may be required to practice 1216 this standard. Please address the information to the IETF Executive 1217 Director. 1219 Full Copyright Statement 1221 Copyright (C) The Internet Society (2003). All Rights Reserved. 1222 This document and translations of it may be copied and furnished to 1223 others, and derivative works that comment on or otherwise explain it 1224 or assist in its implementation may be prepared, copied, published 1225 and distributed, in whole or in part, without restriction of any 1226 kind, provided that the above copyright notice and this paragraph 1227 are included on all such copies and derivative works. However, this 1228 document itself may not be modified in any way, such as by removing 1229 the copyright notice or references to the Internet Society or other 1230 Internet organizations, except as needed for the purpose of 1231 developing Internet standards in which case the procedures for 1232 copyrights defined in the Internet Standards process must be 1233 followed, or as required to translate it into languages other than 1234 English. The limited permissions granted above are perpetual and 1235 will not be revoked by the Internet Society or its successors or 1236 assigns. This document and the information contained herein is 1237 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1238 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1239 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1240 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1243 Expiration Date 1245 This memo is filed as , and will expire 25th August, 2003.