idnits 2.17.00 (12 Aug 2021) /tmp/idnits31718/draft-adrangi-radius-bandwidth-capability-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 28 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 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 27 has weird spacing: '... The list ...' == Line 35 has weird spacing: '... This docum...' == Line 422 has weird spacing: '...eration is i...' == Line 423 has weird spacing: '...ensions to...' == Line 546 has weird spacing: '... This docum...' == (2 more instances...) -- 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 (Feb 8, 2004) is 6677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 106 == Missing Reference: '6' is mentioned on line 124, but not defined ** Obsolete normative reference: RFC 3576 (ref. '3') (Obsoleted by RFC 5176) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Adrangi, Intel 3 INTERNET DRAFT P. Congdon, C. Black, Hewlett Packard 4 Category: Informational A. Lior, Bridgewater Systems 5 Expires: Aug 2004 F. Bari, AT&T Wireless 6 Feb 8, 2004 8 Access Network Bandwidth Capability 9 draft-adrangi-radius-bandwidth-capability-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes network bandwidth parameters and a 36 protocol framework within which the parameters can be exchanged 37 between an Access Network (AN) and a Home Service Network (HSN) 38 in order to determine the average minimum and maximum bandwidth 39 for both ingress and egress traffic that should be allocated by 40 the AN for the duration of an authorized client session. 42 Table of Contents 44 1. Introduction....................................................2 45 1.2 Requirements language..........................................3 46 1.3 Terminology....................................................3 47 2. Overview........................................................3 48 2.1 Bandwidth Parameters...........................................3 49 2.1.1 Ingress Minimum Bandwidth....................................3 50 2.1.2 Ingress Maximum Bandwidth....................................4 51 2.1.3 Egress Minimum Bandwidth.....................................4 52 2.1.4 Egress Maximum Bandwidth.....................................4 53 2.2 Protocol.......................................................4 54 2.2.1 Static Bandwidth Allocation..................................5 55 2.2.2 Dynamic Bandwidth Allocation.................................7 56 2.2.2.1 Push Method................................................7 57 2.2.2.2 Pull Method................................................8 58 3. Operations.....................................................10 59 4. Attribute Format/Syntax........................................10 60 5. Table of Attribute(s).........................................12 61 6. Attribute Usage Examples.......................................12 62 7. IANA Considerations............................................13 63 8. Security Considerations........................................13 64 9. Acknowledgements...............................................13 65 10. References....................................................13 66 AuthorsÆ Addresses................................................14 68 1. Introduction 70 The bandwidth that a user is authorized within an Access Network 71 (AN) can be a result of the AN bandwidth capabilities based on its 72 architecture and access technology, and the type of user 73 subscription to the home network (e.g., gold, silver, bronze user 74 types). 76 This document describes a simple protocol framework that enables 77 an Access Network (AN) to advertise its network bandwidth 78 capabilities that it can allocate for a given AN client connection 79 to the clientÆs Home Service Network (HSN). And, it also enables 80 the HSN to indicate its selection of the desired network bandwidth 81 capabilities for the client connection to the AN. 83 User bandwidth can be determined during initial authentication 84 authorization of the session. It is also desirable to change the 85 bandwidth for the mid-session. For example, the user may want to 86 purchase additional bandwidth to download a large file. This 87 document enables operators to dynamically modify the bandwidth 88 allocation for a session. 90 This document defines a new AAA attribute used for exchanging 91 network bandwidth parameters between the AN and the HSN, to 92 determine the average minimum and maximum bandwidth for both 93 ingress and egress traffic that an AN should allocate for the 94 duration of an authorized client session. This attribute is also 95 used for reporting the allocated bandwidth in accounting records. 96 The attribute is described for RADIUS [1]. 98 1.2 Requirements language 100 In this document, several words are used to signify the 101 requirements of the specification. These words are often 102 capitalized. The key words "MUST", "MUST NOT", "REQUIRED", 103 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 104 "MAY", and "OPTIONAL" in this document are to be interpreted as 105 described in [RFC2119]. 107 1.3 Terminology 109 Access Network (AN) 110 The network that provides wired or wireless connectivity 111 to the Internet for clients (or stations) present in the 112 local access area. This MAY be in a separate security and 113 routing domain with respect to the Home Service Network or a 114 Mediating Network. 116 Home Service Network (HSN) 117 The network providing the service and therefore maintaining 118 the direct relationship to its users and subscribers. All AAA 119 functions are ultimately performed by the HSN. 121 RADIUS server 122 ôThis is a server which provides for 123 authentication/authorization via the protocol described in 124 [1], and for accounting as described in [6].ö It is deployed 125 in the PWLAN AN, MN, and HSN. 127 2. Overview 129 This section describes the bandwidth parameters and the protocol 130 by which these parameters are exchanged between an AN and a HSN. 132 2.1 Bandwidth Parameters 134 Bandwidth parameters describe the average minimum and maximum 135 data rates (for both ingress and egress traffic) for a client 136 connection within an AN. There are four bandwidth parameters, 137 which are described in the following subsections. 139 2.1.1 Ingress Minimum Bandwidth 140 The ingress minimum bandwidth parameter indicates the average 141 minimum ingress data rate that an AN will try to provide to an 142 authorized user. This value is a target, rather than a 143 guarantee. 145 2.1.2 Ingress Maximum Bandwidth 147 The ingress maximum bandwidth parameter indicates the average 148 maximum ingress data rate that an AN can allow to an authorized 149 user. 151 2.1.3 Egress Minimum Bandwidth 153 The minimum egress bandwidth parameter indicates the average 154 minimum egress data rate that an AN will try to provide to an 155 authorized user. 157 2.1.4 Egress Maximum Bandwidth 159 The maximum egress bandwidth parameter indicates the average 160 maximum data rate that an AN can allow to an authorized user. 162 2.2 Protocol 164 Two protocols are described. One protocol is used to allocate 165 bandwidth when a service is initiated (referred to as Static 166 Bandwidth Allocation); the other protocol describes how to change 167 bandwidth attribute dynamically that is, mid session (referred to 168 as Dynamic Bandwidth Allocation). 170 Both protocols exchange bandwidth parameters using the various 171 RADIUS messages, and they are comprised of three phases: 172 bandwidth Advertisement, Selection, and Confirmation. 174 Bandwidth Advertisement: 176 MAY be sent in Access-Request packet from the AN to the HSN 177 and conveys possible/available bandwidth parameters that can 178 be allocated for an the AN client connection to the HSN by the 179 AN. Advertisements are optional. 181 Bandwidth Selection: 183 MAY be sent in Access-Accept packet and Change of 184 Authorization (COA) messages. Selection conveys the desired 185 bandwidth for the AN Client connection to the AN by the HSN. 187 Bandwidth Confirmation: 189 If Bandwidth Selection is received and enforced, It MUST be 190 sent in Accounting-Request packets. Confirmation indicates 191 that the desired bandwidth parameters specified by a HSN are 192 being enforced by the AN. 194 Bandwidth Attribute (BA), defined in section 3, is used to carry 195 the Bandwidth Advertisement, Selection, Confirmation in various 196 RADIUS packets. 198 An Advertisement, Selection, Confirmation is said to be valid if 199 it contains the four aforementioned bandwidth parameters and the 200 minimum bandwidth rate values for ingress and egress traffic MUST 201 be equal or less than their corresponding maximum bandwidth rate 202 values. 204 If a Selection is sent in response to an Advertisement, for the 205 Selection to be considered valid, then the bandwidth parameters 206 in the Selection MUST NOT exceed the corresponding bandwidth 207 parameters in the Advertisement. 209 The following subsections describe static and dynamic bandwidth 210 allocation. 212 2.2.1 Static Bandwidth Allocation 214 Static bandwidth allocation is preformed during the initial 215 session authentication / authorization. 217 The following diagram shows the protocol interaction between 218 the AN and the HSN for determining network bandwidth rates that 219 an AN needs to allocate for an AN client connection. 221 AN Client AN Device + AAA client HSN + AAA Server 223 | | | 224 | | | 225 | Authentication | | 226 | Phase Begin | | 227 |----------------->| Access-Request | 228 | | + | 229 | | BA for Advertisement | 230 | |----------------------------->| 231 | | | 232 |<> | 233 | | | 234 | | | 235 | |<-----------------------------| 236 | | Access-Accept | 237 | Authentication | + | 238 | Accept | BA for Selection | 239 |<-----------------| | 240 | | | 241 | | | 242 | | Accounting Request | 243 | | + | 244 | | BA for Confirmation | 245 | |----------------------------->| 246 | | | 248 The AN MAY send an Advertisement in an Access-Request message. 249 If the HSN receives an invalid Advertisement, then the HSN MUST 250 silently discard the Access-Request. 252 A HSN MAY send the Selection after receiving a valid 253 Advertisement. It MAY also send the Selection in the absence 254 of an Advertisement, based on local policies such as the AN 255 clientÆs subscription profile. When the AN receives an invalid 256 Selection, it MUST treat the Access-Accept message as an Access 257 Reject. 259 If the AN receives a valid Selection in response to an Access- 260 Request that did not contain an Advertisement, then the AN MAY 261 honor the Selection. 263 If the AN receives a valid Selection in response to an Access- 264 Request that contained a valid Advertisement, then the AN MUST 265 honor the Selection. 267 In the absence of a Selection after sending a valid 268 Advertisement, in accordance with local policy, the AN MAY 269 enforce its default bandwidth rate values or it MAY use ôbest 270 effortö bandwidth for that client connection. 272 2.2.2 Dynamic Bandwidth Allocation 274 Dynamic bandwidth allocation uses the Change of Authorization 275 (COA) message as defined in [3]. In accordance with [3] there 276 are two methods for dynamically changing authorization 277 attributes of a session. These two methods are described in 278 this section. 280 At anytime during the session the HSN may send the AN a COA 281 message containing session identification attributes (see [3] 282 for the possible options). The COA message may include 283 authorization attributes in which case it is pushing the BAs to 284 the AN; or it may instruct the AN to generate an Authorize-Only 285 Access-Request (Access-Request with Service-Type set to 286 ôAuthorize-Onlyö) in which case it is instructing the AN to 287 pull the BAs. 289 In either push or pull method, upon successful acceptance of 290 the new bandwidth parameters for the session. The AN MUST 291 generate an Accouting-Stop record that contains the old 292 bandwidth attributes followed by an Accounting-Start message 293 that contains the new bandwidth attributes. 295 In order to allow for downstream correlation of the accounting 296 records, an AN that supports dynamic bandwidth allocation MUST 297 include Acct-Multi-Session-Id when writing accounting records. 299 2.2.2.1 Push Method 301 In the Push Method, to effect a dynamic bandwidth change the 302 HSN sends a COA message and includes a valid Selection. The 303 AN MAY also include other attributes in the COA message. 305 AN HSN 306 | | 307 | | 308 | COA + BAs for Selection | 309 |<---------------------------------------------| 310 | | 311 | | 312 | COA ACK | 313 |--------------------------------------------->| 314 | | 315 | | 316 | Accounting-Stop + old BAs for Confirmation | 317 |--------------------------------------------->| 318 | | 319 | Accounting-Start + new bandwidth | 320 |--------------------------------------------->| 321 | | 322 | | 324 Upon the successful reception of the COA message (see [3] for 325 details) by the AN, if the COA message contains an invalid 326 Selection, the AN MUST respond with a COA NAK with Error 327 Cause (101) set to ôInvalid Requestö (404). 329 If the AN is able to offer the requested bandwidth to the 330 specified session, the AN MUST reply with a COA-ACK and it 331 MUST generate an Accounting-Stop record containing the old 332 bandwidth attributes followed by an Accounting-Start record 333 containing the new bandwidth attributes. If the AN can not 334 comply with the request for new bandwidth it MUST reply with 335 a COA-NAK with Error Cause (101) set to ô"Resources 336 Unavailable"(506). 338 2.2.2.2 Pull Method 340 Alternatively, in the pull method, to effect a dynamic 341 bandwidth change, as per [3], the HSN sends a COA message to 342 instruct the AN to generate an Authorize-Only request 343 (Access-Request with Service-Type set to Authorize-Only). 345 AN HSN 346 | | 347 | COA + Service-Type ôAuthorize Onlyö | 348 |<----------------------------------------------| 349 | | 350 | COA NAK + Service-Type ôAuthorize Onlyö | 351 | + Error-Cause "Request Initiated" | 352 |---------------------------------------------->| 353 | | 354 | Access-Request + Service-Type ôAuthorize Onlyö| 355 | + BAs for Advertisement | 356 |---------------------------------------------->| 357 | | 358 | Access-Accept + BAs for Selection | 359 |<----------------------------------------------| 360 | | 361 | Accounting-Stop + old BAs for Confirmation | 362 |---------------------------------------------->| 363 | | 364 | Accounting-Start + new BAs for Confirmation | 365 |---------------------------------------------->| 366 | | 367 | | 369 As with the static bandwidth allocation (described earlier), 370 the AN MAY Advertise the currently available bandwidth in the 371 Authorize-Only message. 373 Upon receiving the Authorize-Only message from the AN, the 374 HSN MUST respond with either an Access-Accept message or an 375 Access-Reject message. 377 When responding with an Access-Accept message, the HSN MAY 378 include the BAs for Selection. If the Authorize-Only message 379 included an Advertisement, the bandwidth parameters in 380 Selection MUST be within the bounds of bandwidth parameters 381 in the Advertisement received in the Authorize-Only message. 383 Upon sending an Authorize-Only message, the AN will receive 384 an Access-Accept message or an Access-Reject message. 386 Upon receiving an Access-Reject in response to the Authorize- 387 Only, the AN will terminate the session and send an 388 Accounting-Stop record. 390 Upon receiving an Access-Accept in response to an Authorize- 391 Only request that does not contain bandwidth Selection, the 392 AN MUST resume utilizing the existing bandwidth parameters, 393 and it MUST NOT generate an Accounting Stop message. 395 Upon receiving an Access-Accept packet that contains an 396 invalid Bandwidth Selection, the AN MUST treat the response 397 as an Access-Reject and immediately terminate the session. 399 Upon receiving an Access-Accept message in response to an 400 Authorize-Only message that contained the Bandwidth 401 Advertisement, then providing the bandwidth selections are 402 within the bounds of the Advertisement, then AN MUST honor 403 the requested bandwidth and generate an Accounting-Stop 404 message that contains the old bandwidth attributes followed 405 by an Account-Start message that contains the new bandwidth 406 attributes. If the bandwidth Selection were outside the 407 bounds of the Advertisement, then the AN MUST treat the 408 Access-Accept as an Access-Reject and immediately terminate 409 the session. 411 Upon receiving an Access-Accept message that contains a valid 412 Selection in response to an Authorize-Only that did not 413 contain the Advertisement, the AN MAY honor the Selection or 414 it MAY continue to honor the previously agreed to bandwidth. 415 In the former case, the AN must generate an Accounting Stop 416 message containing the old bandwidth attributes followed by 417 an Accounting-Start message containing the current bandwidth 418 attributes. 420 3. Operations 422 Operation is identical to that defined in RADIUS AAA 423 specifications [1][2] and Dynamic Authorization Extensions to 424 Remote Authentication Dial In User Service (RADIUS)[3]. 426 4. Attribute Format/Syntax 428 This section describes format and syntax for the attribute that 429 carries AN bandwidth rate parameters. The attribute is used for 430 bandwidth rate parameters Advertisement, Selection, and 431 Confirmation. 433 The attribute MAY be present in Access-Request, Access-Accept, 434 Accounting-Request. 436 A summary of the AN Bandwidth Parameter Attribute is shown below. 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | Params | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Value | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Type 447 TBD Network Bandwidth Capability 449 Length 451 8 453 Params 455 It indicates what the value signifies. The values defined 456 in the document are: 458 1 û Average Minimum Bandwidth Rate for Ingress Traffic in 459 bits per second 460 2 û Average Minimum Bandwidth Rate for Ingress Traffic in 461 Kilo bits per second 462 3 û Average Minimum Bandwidth Rate for Ingress Traffic in 463 Giga bits per second 464 4 û Average Maximum Bandwidth Rate for Ingress Traffic in 465 bits per second 466 5 û Average Maximum Bandwidth Rate for Ingress Traffic in 467 Kilo bits per second 468 6 û Average Maximum Bandwidth Rate for Ingress Traffic in 469 Giga bits per second 470 7 û Average Minimum Bandwidth Rate for Egress Traffic in 471 bits per second 472 8 û Average Minimum Bandwidth Rate for Egress Traffic in 473 Kilo bits per second 474 9 û Average Minimum Bandwidth Rate for Egress Traffic in 475 Giga bits per second 476 10 û Average Maximum Bandwidth Rate for Egress Traffic in 477 bits per second 478 11 û Average Maximum Bandwidth Rate for Egress Traffic in 479 Kilo bits per second 480 12 û Average Maximum Bandwidth Rate for Egress Traffic in 481 Giga bits per second 483 Value 485 An integer value interpreted based the value of Param. 487 5. Table of Attribute(s) 489 The following table provides a guide to which attribute(s) may be 490 found in which kinds of packets, and in what quantity. 492 Request Accept Reject Challenge Accounting # Attribute 493 Request 494 0-4 0-4 0 0 0-4 TBD Network Bandwidth 495 Capability 497 For Change-of-Authorization Messages 499 Request ACK NAK # Attribute 501 0-4 0-4 0 TBD Network Bandwidth Capability 503 6. Attribute Usage Examples 505 This section provides an example on how Bandwidth attribute can be 506 used to indicate the four bandwidth rate parameters, in 507 Advertisement, Selection, and Confirmation. 509 Ingress Minimum Bandwidth Rate for 28 Kilo bits per second 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | TBD | 7 | 2 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | 28 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Ingress Maximum Bandwidth Rate for 28 Kilo bits per second 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | TBD | 7 | 5 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | 28 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Egress Minimum Bandwidth Rate for 28 Kilo bits per second 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | TBD | 7 | 8 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | 28 | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Egress Maximum Bandwidth Rate for 28 Kilo bits per second 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | TBD | 7 | 11 | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | 28 | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 7. IANA Considerations 546 This document requires the assignment of three new RADIUS 547 attribute numbers for the following attribute(s): 549 AN-Bandwidth-Rate-Paramters 551 See section 3 for the registered list of numbers. 553 8. Security Considerations 555 The attributes in this document have no additional security 556 considerations beyond those already identified in [?]. 558 9. Acknowledgements 560 The authors would like to thank Bernard Aboba (of Microsoft), 561 Parviz Yegani (of Cisco), for their feedback and guidance. 563 10. References 565 [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 566 Authentication Dial In User Server (RADIUS)", RFC 2865, June 567 2000. 569 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 571 [3] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B., 572 ôDynamic Authorization Extensions to Remote Authentication 573 Dial In User Service (RADIUS)ö, RFC 3576, July 2003. 575 AuthorsÆ Addresses 577 Farid Adrangi, Intel Corporatation farid.adrangi@intel.com 578 Chuck Black, Hewlett Packard Company chuck.black@hp.com 579 Paul Congdon, Hewlett Packard Company paul.congdon@hp.com 580 Farooq Bari, AT&T Wireless farooq.bari@attws.com 581 Avi Lior, Bridgwater Systems Corporation avi@bridgewatersystems.com 583 Full Copyright Statement 585 Copyright (C) The Internet Society (2002). All Rights 586 Reserved. 588 This document and translations of it may be copied and 589 furnished to others, and derivative works that comment on or 590 otherwise explain it or assist in its implementation may be 591 prepared, copied, published and distributed, in whole or in 592 part, without restriction of any kind, provided that the above 593 copyright notice and this paragraph are included on all such 594 copies and derivative works. However, this document itself may 595 not be modified in any way, such as by removing the copyright 596 notice or references to the Internet Society or other Internet 597 organizations, except as needed for the purpose of developing 598 Internet standards in which case the procedures for copyrights 599 defined in the Internet Standards process must be followed, or 600 as required to translate it into languages other than English. 602 The limited permissions granted above are perpetual and will 603 not be revoked by the Internet Society or its successors or 604 assigns. 606 This document and the information contained herein is provided 607 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 608 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 609 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 610 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 611 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 612 PARTICULAR PURPOSE. 614 Acknowledgement 616 Funding for the RFC Editor function is currently provided by 617 the Internet Society.