idnits 2.17.1 draft-ietf-radext-rfc3576bis-12.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 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1528. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3576, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (18 October 2007) is 6027 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 989, but not defined == Missing Reference: 'Note 3' is mentioned on line 1003, but not defined == Missing Reference: 'Notes 1' is mentioned on line 941, but not defined -- Looks like a reference, but probably isn't: '6' on line 941 == Missing Reference: 'Note 2' is mentioned on line 995, but not defined == Missing Reference: 'Note 7' is mentioned on line 1031, but not defined == Missing Reference: 'Note 5' is mentioned on line 1015, but not defined == Missing Reference: 'Note 4' is mentioned on line 1009, but not defined == Missing Reference: 'Note 6' is mentioned on line 1020, but not defined ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Murtaza S. Chiba 3 INTERNET-DRAFT Gopal Dommety 4 Obsoletes: 3576 Mark Eklund 5 Category: Informational Cisco Systems, Inc. 6 Expires: April 25, 2008 David Mitton 7 RSA Security, Inc. 8 Bernard Aboba 9 Microsoft Corporation 10 18 October 2007 12 Dynamic Authorization Extensions to Remote Authentication Dial In User 13 Service (RADIUS) 14 draft-ietf-radext-rfc3576bis-12.txt 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 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 April 25, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). All Rights Reserved. 43 Abstract 45 This document describes a currently deployed extension to the Remote 46 Authentication Dial In User Service (RADIUS) protocol, allowing 47 dynamic changes to a user session, as implemented by network access 48 server products. This includes support for disconnecting users and 49 changing authorizations applicable to a user session. 51 Table of Contents 53 1. Introduction .......................................... 3 54 1.1 Applicability ................................... 3 55 1.2 Requirements Language ........................... 4 56 1.3 Terminology ..................................... 4 57 2. Overview ............................................. 5 58 2.1 Disconnect Messages (DM) ........................ 5 59 2.2 Change-of-Authorization Messages (CoA) .......... 5 60 2.3 Packet Format ................................... 6 61 3. Attributes ............................................ 10 62 3.1 Proxy State ..................................... 13 63 3.2 Authorize Only .................................. 13 64 3.3 State ........................................... 14 65 3.4 Message-Authenticator ........................... 15 66 3.5 Error-Cause ..................................... 16 67 3.6 Table of Attributes ............................. 19 68 4. Diameter Considerations ............................... 22 69 5. IANA Considerations ................................... 25 70 6. Security Considerations ............................... 25 71 6.1 Authorization Issues ............................ 25 72 6.2 IPsec Usage Guidelines .......................... 26 73 6.3 Replay Protection ............................... 27 74 7. Example Traces ........................................ 27 75 8. References ............................................ 28 76 8.1 Normative References ............................ 28 77 8.2 Informative References .......................... 29 78 ACKNOWLEDGMENTS .............................................. 29 79 AUTHORS' ADDRESSES ........................................... 30 80 Appendix A - Changes from RFC 3576 ........................... 31 81 Full Copyright Statement ..................................... 33 82 Intellectual Property ........................................ 33 83 1. Introduction 85 The RADIUS protocol, defined in [RFC2865], does not support 86 unsolicited messages sent from the RADIUS server to the Network 87 Access Server (NAS). 89 However, there are many instances in which it is desirable for 90 changes to be made to session characteristics, without requiring the 91 NAS to initiate the exchange. For example, it may be desirable for 92 administrators to be able to terminate user session(s) in progress. 93 Alternatively, if the user changes authorization level, this may 94 require that authorization attributes be added/deleted from user 95 session(s). 97 To overcome these limitations, several vendors have implemented 98 additional RADIUS commands in order to be able to support unsolicited 99 messages to be sent to the NAS. These extended commands provide 100 support for Disconnect and Change-of-Authorization (CoA) packets. 101 Disconnect packets cause user session(s) to be terminated 102 immediately, whereas CoA packets modify session authorization 103 attributes such as data filters. 105 1.1. Applicability 107 This protocol is being recommended for publication as an 108 Informational RFC rather than as a standards-track RFC because of 109 problems that cannot be fixed without creating incompatibilities with 110 deployed implementations. This includes security vulnerabilities, as 111 well as semantic ambiguities resulting from the design of the Change- 112 of-Authorization (CoA) commands. While fixes are recommended, they 113 cannot be made mandatory since this would be incompatible with 114 existing implementations. 116 Existing implementations of this protocol do not support 117 authorization checks, so that an ISP sharing a NAS with another ISP 118 could disconnect or change authorizations for another ISP's users. 119 In order to remedy this problem, a "Reverse Path Forwarding" check is 120 described; see Section 6.1. for details. 122 Existing implementations utilize per-packet authentication and 123 integrity protection algorithms with known weaknesses [MD5Attack]. 124 To provide stronger per-packet authentication and integrity 125 protection, the use of IPsec is recommended. See Section 6.2 for 126 details. 128 Existing implementations lack replay protection. In order to support 129 replay detection, it is recommended that an Event-Timestamp Attribute 130 be added to all packets in situations where IPsec replay protection 131 is not employed. See Section 6.3 for details. 133 The approach taken with CoA commands in existing implementations 134 results in a semantic ambiguity. Existing implementations of the 135 CoA-Request identify the affected session, as well as supply the 136 authorization changes. Since RADIUS Attributes included within 137 existing implementations of the CoA-Request can be used for session 138 identification or authorization change, it may not be clear which 139 function a given attribute is serving. 141 The problem does not exist within the Diameter protocol [RFC3588], in 142 which server-initiated authorization change is initiated using a Re- 143 Auth-Request (RAR) command identifying the session via User-Name and 144 Session-Id AVPs and containing a Re-Auth-Request-Type AVP with value 145 "AUTHORIZE_ONLY". This results in initiation of a standard 146 Request/Response sequence where authorization changes are supplied. 147 As a result, in no command can Diameter AVPs have multiple potential 148 meanings. 150 1.2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 1.3. Terminology 158 This document frequently uses the following terms: 160 Dynamic Authorization Client (DAC) 161 The entity originating Change of Authorization (CoA) Requests or 162 Disconnect-Requests. While it is possible that the DAC is co- 163 resident with a RADIUS authentication or accounting server, this 164 need not necessarily be the case. 166 Dynamic Authorization Server (DAS) 167 The entity receiving CoA-Request or Disconnect-Request packets. 168 The DAS may be a NAS or a RADIUS proxy. 170 Network Access Server (NAS) 171 The device providing access to the network. 173 service 174 The NAS provides a service to the user, such as IEEE 802 or Point- 175 to-Point Protocol (PPP). 177 session 178 Each service provided by the NAS to a user constitutes a session, 179 with the beginning of the session defined as the point where 180 service is first provided and the end of the session defined as the 181 point where service is ended. A user may have multiple sessions in 182 parallel or series if the NAS supports that. 184 silently discard 185 This means the implementation discards the packet without further 186 processing. The implementation SHOULD provide the capability of 187 logging the error, including the contents of the silently discarded 188 packet, and SHOULD record the event in a statistics counter. 190 2. Overview 192 This section describes the most commonly implemented features of 193 Disconnect and Change-of-Authorization (CoA) packets. 195 2.1. Disconnect Messages (DM) 197 A Disconnect-Request packet is sent by the Dynamic Authorization 198 Client in order to terminate user session(s) on a NAS and discard all 199 associated session context. The Disconnect-Request packet is sent to 200 UDP port 3799, and identifies the NAS as well as the user session(s) 201 to be terminated by inclusion of the identification attributes 202 described in Section 3. 204 +----------+ +----------+ 205 | | Disconnect-Request | | 206 | | <-------------------- | | 207 | NAS | | DAC | 208 | | Disconnect-Response | | 209 | | ---------------------> | | 210 +----------+ +----------+ 212 The NAS responds to a Disconnect-Request packet sent by a Dynamic 213 Authorization Client with a Disconnect-ACK if all associated session 214 context is discarded and the user session(s) are no longer connected, 215 or a Disconnect-NAK, if the NAS was unable to disconnect one or more 216 sessions and discard all associated session context. A Disconnect- 217 ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] 218 with the value set to 6 for Admin-Reset. 220 2.2. Change-of-Authorization Messages (CoA) 222 CoA-Request packets contain information for dynamically changing 223 session authorizations. Typically this is used to change data 224 filters. The data filters can be of either the ingress or egress 225 kind, and are sent in addition to the identification attributes as 226 described in section 3. The port used, and packet format (described 227 in Section 2.3), are the same as that for Disconnect-Request packets. 229 The following attributes MAY be sent in a CoA-Request: 231 Filter-ID (11) - Indicates the name of a data filter list 232 to be applied for the session(s) that the 233 identification attributes map to. 235 NAS-Filter-Rule (92) - Provides a filter list to be applied 236 for the session(s) that the identification 237 attributes map to [RFC4849]. 239 +----------+ +----------+ 240 | | CoA-Request | | 241 | | <-------------------- | | 242 | NAS | | DAC | 243 | | CoA-Response | | 244 | | ---------------------> | | 245 +----------+ +----------+ 247 The NAS responds to a CoA-Request sent by a Dynamic Authorization 248 Client with a CoA-ACK if the NAS is able to successfully change the 249 authorizations for the user session(s), or a CoA-NAK if the CoA- 250 Request is unsuccessful. A NAS MUST respond to a CoA-Request 251 including a Service-Type Attribute with an unsupported value with a 252 CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" 253 SHOULD be included. 255 2.3. Packet Format 257 For either Disconnect-Request or CoA-Request packets UDP port 3799 is 258 used as the destination port. For responses, the source and 259 destination ports are reversed. Exactly one RADIUS packet is 260 encapsulated in the UDP Data field. 262 A summary of the data format is shown below. The fields are 263 transmitted from left to right. 265 The packet format consists of the fields: Code, Identifier, Length, 266 Authenticator, and Attributes in Type:Length:Value (TLV) format. All 267 fields hold the same meaning as those described in RADIUS [RFC2865]. 268 The Authenticator field MUST be calculated in the same way as is 269 specified for an Accounting-Request in [RFC2866]. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Code | Identifier | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 | Authenticator | 278 | | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Attributes ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+- 284 Code 286 The Code field is one octet, and identifies the type of RADIUS 287 packet. Packets received with an invalid Code field MUST be 288 silently discarded. RADIUS codes (decimal) for this extension are 289 assigned as follows: 291 40 - Disconnect-Request [RFC3575] 292 41 - Disconnect-ACK [RFC3575] 293 42 - Disconnect-NAK [RFC3575] 294 43 - CoA-Request [RFC3575] 295 44 - CoA-ACK [RFC3575] 296 45 - CoA-NAK [RFC3575] 298 Identifier 300 The Identifier field is one octet, and aids in matching requests 301 and replies. A Dynamic Authorization Server implementing this 302 specification MUST be capable of detecting a duplicate request if 303 it has the same source IP address, source UDP port and Identifier 304 within a short span of time. 306 The responsibility for retransmission of Disconnect-Request and 307 CoA-Request packets lies with the Dynamic Authorization Client. 308 If after sending these packets, the Dynamic Authorization Client 309 does not receive a response, it will retransmit. 311 The Identifier field MUST be changed whenever the content of the 312 Attributes field changes, or whenever a valid reply has been 313 received for a previous request. For retransmissions where the 314 contents are identical, the Identifier MUST remain unchanged. 316 If the Dynamic Authorization Client is retransmitting a 317 Disconnect-Request or CoA-Request to the same Dynamic 318 Authorization Server as before, and the Attributes haven't 319 changed, the same Request Authenticator, Identifier and source 320 port MUST be used. If any Attributes have changed, a new 321 Authenticator and Identifier MUST be used. 323 If the Request to a primary Dynamic Authorization Server fails, a 324 secondary Dynamic Authorization Server must be queried, if 325 available; issues relating to failover algorithms are described in 326 [RFC3539]. Since this represents a new request, a new Request 327 Authenticator and Identifier MUST be used. However, where the 328 Dynamic Authorization Client is sending directly to the NAS, 329 failover typically does not make sense, since CoA-Request or 330 Disconnect-Request packets need to be delivered to the NAS where 331 the session resides. 333 Length 335 The Length field is two octets. It indicates the length of the 336 packet including the Code, Identifier, Length, Authenticator and 337 Attribute fields. Octets outside the range of the Length field 338 MUST be treated as padding and ignored on reception. If the 339 packet is shorter than the Length field indicates, it MUST be 340 silently discarded. The minimum length is 20 and maximum length 341 is 4096. 343 Authenticator 345 The Authenticator field is sixteen (16) octets. The most 346 significant octet is transmitted first. This value is used to 347 authenticate packets between the Dynamic Authorization Client and 348 the Dynamic Authorization Server. 350 Request Authenticator 352 In Request packets, the Authenticator value is a 16 octet MD5 353 [RFC1321] checksum, called the Request Authenticator. The 354 Request Authenticator is calculated the same way as for an 355 Accounting-Request, specified in [RFC2866]. 357 Note that the Request Authenticator of a CoA-Request or 358 Disconnect-Request cannot be computed the same way as the 359 Request Authenticator of a RADIUS Access-Request, because there 360 is no User-Password Attribute in a CoA-Request or Disconnect- 361 Request. 363 Response Authenticator 365 The Authenticator field in a Response packet (e.g. Disconnect- 366 ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the 367 Response Authenticator, and contains a one-way MD5 hash 368 calculated over a stream of octets consisting of the Code, 369 Identifier, Length, the Request Authenticator field from the 370 packet being replied to, and the response Attributes if any, 371 followed by the shared secret. The resulting 16 octet MD5 hash 372 value is stored in the Authenticator field of the Response 373 packet. 375 Administrative note: As noted in [RFC2865] Section 3, the secret 376 (password shared between the Dynamic Authorization Client and the 377 Dynamic Authorization Server) SHOULD be at least as large and 378 unguessable as a well-chosen password. The Dynamic Authorization 379 Server MUST use the source IP address of the RADIUS UDP packet to 380 decide which shared secret to use, so that requests can be 381 proxied. 383 Attributes 385 In CoA-Request and Disconnect-Request packets, all attributes MUST 386 be treated as mandatory. If one or more authorization changes 387 specified in a CoA-Request cannot be carried out, the NAS MUST 388 send a CoA-NAK. A NAS MUST respond to a CoA-Request containing 389 one or more unsupported Attributes or Attribute values with a CoA- 390 NAK; an Error-Cause Attribute with value 401 (Unsupported 391 Attribute) or 407 (Invalid Attribute Value) MAY be included. A 392 NAS MUST respond to a Disconnect-Request containing one or more 393 unsupported Attributes or Attribute values with a Disconnect-NAK; 394 an Error-Cause Attribute with value 401 (Unsupported Attribute) or 395 407 (Invalid Attribute Value) MAY be included. 397 State changes resulting from a CoA-Request MUST be atomic: if the 398 CoA-Request is successful for all matching sessions, the NAS MUST 399 send a CoA-ACK in reply, and all requested authorization changes 400 MUST be made. If the CoA-Request is unsuccessful for any matching 401 sessions, the NAS MUST send as CoA-NAK in reply, and the requested 402 authorization changes MUST NOT be made for any of the matching 403 sessions. Similarly, a state change MUST NOT occur as a result of 404 a Disconnect-Request that is unsuccessful with respect to any of 405 the matching sessions; a NAS MUST send a Disconnect-NAK in reply 406 if any of the matching sessions cannot be successfully terminated. 407 A NAS which does not support dynamic authorization changes 408 applying to multiple sessions MUST send a CoA-NAK or Disconnect- 409 NAK in reply; an Error-Cause Attribute with value 508 (Multiple 410 Session Selection Unsupported) SHOULD be included. 412 Within this specification attributes can be used for 413 identification, authorization or other purposes. RADIUS Attribute 414 specifications created after publication of this document SHOULD 415 state whether an attribute can be included in CoA or Disconnect 416 messages and if so, which messages it can be included in and 417 whether it serves as an identification or authorization attribute. 419 Even if a NAS implements an attribute for use with RADIUS 420 authentication and accounting, it is possible that it will not 421 support inclusion of that attribute within CoA-Request and 422 Disconnect-Request packets, given the difference in attribute 423 semantics. This is true even for attributes specified as 424 allowable within Access-Accept packets (such as those defined 425 within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], 426 [RFC4372], [RFC4675], [RFC4818] and [RFC4849]). 428 3. Attributes 430 In Disconnect-Request and CoA-Request packets, certain attributes are 431 used to uniquely identify the NAS as well as user session(s) on the 432 NAS. The combination of NAS and session identification attributes 433 included in a CoA-Request or Disconnect-Request packet MUST match at 434 least one session in order for a Request to be successful; otherwise 435 a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification 436 attributes match, and more than one session matches all of the 437 session identification attributes, then a CoA-Request or Disconnect- 438 Request MUST apply to all matching sessions. 440 Identification attributes include NAS and session identification 441 attributes, as described below. 443 NAS identification attributes 445 Attribute # Reference Description 446 --------- --- --------- ----------- 447 NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. 448 NAS-Identifier 32 [RFC2865] String identifying the NAS. 449 NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. 451 Session identification attributes 453 Attribute # Reference Description 454 --------- --- --------- ----------- 455 User-Name 1 [RFC2865] The name of the user 456 associated with one or 457 more sessions. 458 NAS-Port 5 [RFC2865] The port on which a 459 session is terminated. 460 Framed-IP-Address 8 [RFC2865] The IPv4 address associated 461 with a session. 462 Vendor-Specific 26 [RFC2865] One or more vendor-specific 463 identification attributes. 464 Called-Station-Id 30 [RFC2865] The link address to which 465 a session is connected. 466 Calling-Station-Id 31 [RFC2865] The link address from which 467 one or more sessions are 468 connected. 469 Acct-Session-Id 44 [RFC2866] The identifier uniquely 470 identifying a session 471 on the NAS. 472 Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely 473 identifying related sessions. 474 NAS-Port-Id 87 [RFC2869] String identifying the port 475 where a session is. 476 Chargeable-User- 89 [RFC4372] The CUI associated with one 477 Identity or more sessions. Needed 478 where a privacy NAI is used, 479 since in this case the 480 User-Name (e.g. "anonymous") 481 may not identify sessions 482 belonging to a given user. 483 Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier 484 associated with a session; 485 always sent with 486 Framed-IPv6-Prefix. 487 Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated 488 with a session, always sent 489 with Framed-Interface-Id. 491 To address security concerns described in Section 6.1, either the 492 User-Name or Chargeable-User-Identity attribute SHOULD be present in 493 Disconnect-Request and CoA-Request packets. 495 Where a Diameter client utilizes the same Session-Id for both 496 authorization and accounting, inclusion of an Acct-Session-Id 497 Attribute in a Disconnect-Request or CoA-Request can assist with 498 Diameter/RADIUS translation, since Diameter RAR and ASR commands 499 include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be 500 included in Disconnect-Request and CoA-Request packets. 502 A NAS implementing this specification SHOULD send an Acct-Session-Id 503 or Acct-Multi-Session-Id Attribute within an Access-Request. Where 504 an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included 505 within an Access-Request, the Dynamic Authorization Client will not 506 know the Acct-Session-Id or Acct-Multi-Session-Id of the session it 507 is attempting to target, unless it also has access to the accounting 508 data for that session. 510 Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not 511 present in a CoA-Request or Disconnect-Request, it is possible that 512 the the User-Name or Chargeable-User-Identity attributes will not be 513 sufficient to uniquely identify a single session (e.g. if the same 514 user has multiple sessions on the NAS, or if the privacy NAI is 515 used). In this case if it is desired to identify a single session, 516 session identification MAY be performed by using one or more of the 517 Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- 518 Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes. 520 To assist RADIUS proxies in routing Request packets to their 521 destination, one or more of the NAS-IP-Address or NAS-IPv6-Address 522 Attributes SHOULD be present in CoA-Request and Disconnect-Request 523 packets; the NAS-Identifier Attribute MAY be present. Impersonation 524 issues with NAS Identification attributes are discussed in [RFC3579] 525 Section 4.3.7. 527 A Disconnect-Request MUST contain only NAS and session identification 528 attributes. If other attributes are included in a Disconnect- 529 Request, implementations MUST send a Disconnect-NAK; an Error-Cause 530 Attribute with value "Unsupported Attribute" MAY be included. 532 The DAC may require access to data from RADIUS authentication or 533 accounting packets. It uses this data to compose compliant CoA- 534 Request or Disconnect-Request packets. For example, as described in 535 Section 3.3, a CoA-Request packet containing a Service-Type Attribute 536 with value of "Authorize Only" is required to contain a State 537 Attribute. The NAS will subsequently transmit this attribute to the 538 RADIUS server in an Access-Request. In order for the DAC to include 539 a State Attribute that the RADIUS server will subsequently accept, 540 some coordination between the two parties may be required. 542 This coordination can be acheived in multiple ways. The DAC may be 543 co-located with a RADIUS server, in which case it is presumed to have 544 access to the necessary data. The RADIUS server may also store that 545 information in a common database. The DAC can then be separated from 546 the RADIUS server, so long as it has access to that common database. 548 Where the DAC is not co-located with a RADIUS server, and does not 549 have access to a common database, the DAC SHOULD send CoA- Request or 550 Disconnect-Request packets to a RADIUS server acting as a proxy, 551 rather than sending them directly to the NAS. 553 A RADIUS server receiving a CoA-Request or Disconnect-Request packet 554 from the DAC MAY then add or update attributes (such as adding NAS or 555 session identification attributes or appending a State Attribute), 556 prior to forwarding the packet. Having CoA/Disconnect-Requests 557 forwarded by a RADIUS server can also enable upstream RADIUS proxies 558 to perform a Reverse Path Forwarding (RPF) check (see Section 6.1). 560 3.1. Proxy State 562 If there are any Proxy-State attributes in a Disconnect-Request or 563 CoA-Request received from the Dynamic Authorization Client, the 564 Dynamic Authorization Server MUST include those Proxy-State 565 attributes in its response to the Dynamic Authorization Client. 567 A forwarding proxy or NAS MUST NOT modify existing Proxy-State, 568 State, or Class attributes present in the packet. The forwarding 569 proxy or NAS MUST treat any Proxy-State attributes already in the 570 packet as opaque data. Its operation MUST NOT depend on the content 571 of Proxy-State attributes added by previous proxies. The forwarding 572 proxy MUST NOT modify any other Proxy-State attributes that were in 573 the packet; it may choose not to forward them, but it MUST NOT change 574 their contents. If the forwarding proxy omits the Proxy-State 575 attributes in the request, it MUST attach them to the response before 576 sending it. 578 When the proxy forwards a Disconnect or CoA-Request, it MAY add a 579 Proxy-State Attribute, but it MUST NOT add more than one. If a 580 Proxy-State Attribute is added to a packet when forwarding the 581 packet, the Proxy-State Attribute MUST be added after any existing 582 Proxy-State attributes. The forwarding proxy MUST NOT change the 583 order of any attributes of the same type, including Proxy-State. 584 Other attributes can be placed before, after or even between the 585 Proxy-State attributes. 587 When the proxy receives a response to a CoA-Request or Disconnect- 588 Request, it MUST remove its own Proxy-State (the last Proxy- State in 589 the packet) Attribute before forwarding the response. Since 590 Disconnect and CoA responses are authenticated on the entire packet 591 contents, the stripping of the Proxy-State Attribute invalidates the 592 integrity check - so the proxy MUST recompute it. 594 3.2. Authorize Only 596 To simplify translation between RADIUS and Diameter, Dynamic 597 Authorization Clients can include a Service-Type Attribute with value 598 "Authorize Only" within a CoA-Request; see Section 4 for details on 599 Diameter considerations. Support for a CoA-Request including a 600 Service-Type Attribute with value "Authorize Only" is OPTIONAL on the 601 NAS and Dynamic Authorization Client. A Service-Type Attribute MUST 602 NOT be included within a Disconnect-Request. 604 A NAS MUST respond to a CoA-Request including a Service-Type 605 Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST 606 NOT be sent. If the NAS does not support a Service-Type value of 607 "Authorize Only" then it MUST respond with a CoA-NAK; an Error-Cause 608 value of 405 (Unsupported Service) SHOULD be included. 610 A CoA-Request containing a Service-Type Attribute with value 611 "Authorize Only" MUST in addition contain only NAS or session 612 identification attributes, as well as a State Attribute. If other 613 attributes are included in such a CoA-Request, a CoA-NAK MUST be 614 sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) 615 SHOULD be included. 617 If a CoA-Request packet including a Service-Type value of "Authorize 618 Only" is successfully processed, the NAS MUST respond with a CoA-NAK 619 containing a Service-Type Attribute with value "Authorize Only", and 620 an Error-Cause Attribute with value 507 (Request Initiated). The NAS 621 then MUST send an Access-Request to the RADIUS server including a 622 Service-Type Attribute with value "Authorize Only", along with a 623 State Attribute. This Access-Request SHOULD contain the NAS 624 identification attributes from the CoA-Request, as well as the 625 session identification attributes from the CoA-Request permitted in 626 an Access-Request; it also MAY contain other attributes permitted in 627 an Access-Request. 629 As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute 630 SHOULD be included in an Access-Request that does not contain a User- 631 Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The 632 RADIUS server then will respond to the Access-Request with an Access- 633 Accept to (re-)authorize the session or an Access-Reject to refuse to 634 (re-)authorize it. 636 3.3. State 638 The State Attribute is available to be sent by the Dynamic 639 Authorization Client to the NAS in a CoA-Request packet and MUST be 640 sent unmodified from the NAS to the Dynamic Authorization Client in a 641 subsequent ACK or NAK packet. 643 [RFC2865] Section 5.44 states: 645 An Access-Request MUST contain either a User-Password or a CHAP- 646 Password or State. An Access-Request MUST NOT contain both a 647 User-Password and a CHAP-Password. If future extensions allow 648 other kinds of authentication information to be conveyed, the 649 attribute for that can be used in an Access-Request instead of 650 User-Password or CHAP-Password. 652 In order to satisfy the requirements of [RFC2865] Section 5.44, an 653 Access-Request with Service-Type="Authorize-Only" MUST contain a 654 State attribute. 656 In order to provide a State attribute to the NAS, a Dynamic 657 Authorization Client sending a CoA-Request with a Service-Type value 658 of "Authorize-Only" MUST include a State Attribute, and the NAS MUST 659 send the State Attribute unmodified to the RADIUS server in the 660 resulting Access-Request, if any. A NAS receiving a CoA-Request 661 containing a Service-Type value of "Authorize-Only" but lacking a 662 State attribute MUST send a CoA-NAK and SHOULD include an Error-Cause 663 attribute with value 402 (Missing Attribute). 665 The State Attribute is also available to be sent by the Dynamic 666 Authorization Client to the NAS in a CoA-Request that also includes a 667 Termination-Action Attribute with the value of RADIUS-Request. If 668 the NAS performs the Termination-Action by sending a new Access- 669 Request upon termination of the current session, it MUST include the 670 State Attribute unchanged in that Access-Request. In either usage, 671 the Dynamic Authorization Server MUST NOT interpret the Attribute 672 locally. A CoA-Request packet MUST have only zero or one State 673 Attribute. Usage of the State Attribute is implementation dependent. 675 3.4. Message-Authenticator 677 The Message-Authenticator Attribute MAY be used to authenticate and 678 integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, 679 Disconnect-ACK and Disconnect-NAK packets order to prevent spoofing. 681 A Dynamic Authorization Server receiving a CoA-Request or Disconnect- 682 Request with a Message-Authenticator Attribute present MUST calculate 683 the correct value of the Message-Authenticator and silently discard 684 the packet if it does not match the value sent. A Dynamic 685 Authorization Client receiving a CoA/Disconnect-ACK or 686 CoA/Disconnect-NAK with a Message-Authenticator Attribute present 687 MUST calculate the correct value of the Message-Authenticator and 688 silently discard the packet if it does not match the value sent. 690 When a Message-Authenticator Attribute is included within a CoA- 691 Request or Disconnect-Request, it is calculated as follows: 693 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 694 Request Authenticator, Attributes) 696 When the HMAC-MD5 message integrity check is calculated the 697 Request Authenticator field and Message-Authenticator Attribute 698 MUST each be considered to be sixteen octets of zero. The 699 Message-Authenticator Attribute is calculated and inserted in the 700 packet before the Request Authenticator is calculated. 702 When a Message-Authenticator Attribute is included within a CoA- 703 ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK, it is calculated 704 as follows: 706 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 707 Request Authenticator, Attributes) 709 When the HMAC-MD5 message integrity check is calculated the 710 Message-Authenticator Attribute MUST be considered to be sixteen 711 octets of zero. The Request Authenticator is taken from the 712 corresponding CoA/Disconnect-Request. The Message-Authenticator 713 is calculated and inserted in the packet before the Response 714 Authenticator is calculated. 716 3.5. Error-Cause 718 Description 720 It is possible that a Dynamic Authorization Server cannot honor 721 Disconnect-Request or CoA-Request packets for some reason. The 722 Error-Cause Attribute provides more detail on the cause of the 723 problem. It MAY be included within CoA-NAK and Disconnect-NAK 724 packets. 726 A summary of the Error-Cause Attribute format is shown below. The 727 fields are transmitted from left to right. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Type | Length | Value 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Value (cont) | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Type 739 101 for Error-Cause 741 Length 743 6 745 Value 747 The Value field is four octets, containing an integer specifying 748 the cause of the error. Values 0-199 and 300-399 are reserved. 749 Values 200-299 represent successful completion, so that these 750 values may only be sent within CoA-ACK or Disconnect-ACK packets 751 and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. 753 Values 400-499 represent fatal errors committed by the Dynamic 754 Authorization Client, so that they MAY be sent within CoA-NAK or 755 Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or 756 Disconnect-ACK packets. Values 500-599 represent fatal errors 757 occurring on a Dynamic Authorization Server, so that they MAY be 758 sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be 759 sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values 760 SHOULD be logged by the Dynamic Authorization Client. Error-Code 761 values (expressed in decimal) include: 763 # Value 764 --- ----- 765 201 Residual Session Context Removed 766 202 Invalid EAP Packet (Ignored) 767 401 Unsupported Attribute 768 402 Missing Attribute 769 403 NAS Identification Mismatch 770 404 Invalid Request 771 405 Unsupported Service 772 406 Unsupported Extension 773 407 Invalid Attribute Value 774 501 Administratively Prohibited 775 502 Request Not Routable (Proxy) 776 503 Session Context Not Found 777 504 Session Context Not Removable 778 505 Other Proxy Processing Error 779 506 Resources Unavailable 780 507 Request Initiated 781 508 Multiple Session Selection Unsupported 783 "Residual Session Context Removed" is sent in response to a 784 Disconnect-Request if one or more user session(s) are no longer 785 active, but residual session context was found and successfully 786 removed. This value is only sent within a Disconnect-ACK and MUST 787 NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK. 789 "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT 790 be sent by implementations of this specification. 792 "Unsupported Attribute" is a fatal error sent if a Request 793 contains an attribute (such as a Vendor-Specific or EAP-Message 794 Attribute) that is not supported. 796 "Missing Attribute" is a fatal error sent if critical attributes 797 (such as NAS or session identification attributes) are missing 798 from a Request. 800 "NAS Identification Mismatch" is a fatal error sent if one or more 801 NAS identification attributes (see Section 3) do not match the 802 identity of the NAS receiving the Request. 804 "Invalid Request" is a fatal error sent if some other aspect of 805 the Request is invalid, such as if one or more attributes (such as 806 EAP- Message Attribute(s)) are not formatted properly. 808 "Unsupported Service" is a fatal error sent if a Service-Type 809 Attribute included with the Request is sent with an invalid or 810 unsupported value. This error cannot be sent in response to a 811 Disconnect-Request. 813 "Unsupported Extension" is a fatal error sent due to lack of 814 support for an extension such as Disconnect and/or CoA packets. 815 This will typically be sent by a proxy receiving an ICMP port 816 unreachable message after attempting to forward a CoA-Request or 817 Disconnect-Request to the NAS. 819 "Invalid Attribute Value" is a fatal error sent if a CoA-Request 820 or Disconnect-Request contains an attribute with an unsupported 821 value. 823 "Administratively Prohibited" is a fatal error sent if the NAS is 824 configured to prohibit honoring of CoA-Request or Disconnect- 825 Request packets for the specified session. 827 "Request Not Routable" is a fatal error which MAY be sent by a 828 proxy and MUST NOT be sent by a NAS. It indicates that the proxy 829 was unable to determine how to route a CoA-Request or Disconnect- 830 Request to the NAS. For example, this can occur if the required 831 entries are not present in the proxy's realm routing table. 833 "Session Context Not Found" is a fatal error sent if the session 834 context identified in the CoA-Request or Disconnect-Request does 835 not exist on the NAS. 837 "Session Context Not Removable" is a fatal error sent in response 838 to a Disconnect-Request if the NAS was able to locate the session 839 context, but could not remove it for some reason. It MUST NOT be 840 sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a 841 Disconnect-NAK. 843 "Other Proxy Processing Error" is a fatal error sent in response 844 to a CoA or Disconnect-Request that could not be processed by a 845 proxy, for reasons other than routing. 847 "Resources Unavailable" is a fatal error sent when a CoA or 848 Disconnect-Request could not be honored due to lack of available 849 NAS resources (memory, non- volatile storage, etc.). 851 "Request Initiated" is a fatal error sent by a NAS in response to 852 a CoA-Request including a Service-Type Attribute with a value of 853 "Authorize Only". It indicates that the CoA-Request has not been 854 honored, but that the NAS is sending one or more RADIUS Access- 855 Request(s) including a Service-Type Attribute with value 856 "Authorize Only" to the RADIUS server. 858 "Multiple Session Selection Unsupported" is a fatal error sent by 859 a NAS in response to a CoA-Request or Disconnect-Request whose 860 session identification attributes match multiple sessions, where 861 the NAS does not support Requests applying to multiple sessions. 863 3.6. Table of Attributes 865 The following table provides a guide to which attributes may be found 866 in which packets, and in what quantity. 868 Change-of-Authorization Messages 870 Request ACK NAK # Attribute 871 0-1 0 0 1 User-Name [Note 1] 872 0-1 0 0 4 NAS-IP-Address [Note 1] 873 0-1 0 0 5 NAS-Port [Note 1] 874 0-1 0 0-1 6 Service-Type 875 0-1 0 0 7 Framed-Protocol [Note 3] 876 0-1 0 0 8 Framed-IP-Address [Notes 1,6] 877 0-1 0 0 9 Framed-IP-Netmask [Note 3] 878 0-1 0 0 10 Framed-Routing [Note 3] 879 0+ 0 0 11 Filter-ID [Note 3] 880 0-1 0 0 12 Framed-MTU [Note 3] 881 0+ 0 0 13 Framed-Compression [Note 3] 882 0+ 0 0 14 Login-IP-Host [Note 3] 883 0-1 0 0 15 Login-Service [Note 3] 884 0-1 0 0 16 Login-TCP-Port [Note 3] 885 0+ 0 0 18 Reply-Message [Note 2] 886 0-1 0 0 19 Callback-Number [Note 3] 887 0-1 0 0 20 Callback-Id [Note 3] 888 0+ 0 0 22 Framed-Route [Note 3] 889 0-1 0 0 23 Framed-IPX-Network [Note 3] 890 0-1 0-1 0-1 24 State 891 0+ 0 0 25 Class [Note 3] 892 0+ 0 0 26 Vendor-Specific [Note 7] 893 0-1 0 0 27 Session-Timeout [Note 3] 894 0-1 0 0 28 Idle-Timeout [Note 3] 895 0-1 0 0 29 Termination-Action [Note 3] 896 Request ACK NAK # Attribute 897 Request ACK NAK # Attribute 898 0-1 0 0 30 Called-Station-Id [Note 1] 899 0-1 0 0 31 Calling-Station-Id [Note 1] 900 0-1 0 0 32 NAS-Identifier [Note 1] 901 0+ 0+ 0+ 33 Proxy-State 902 0-1 0 0 34 Login-LAT-Service [Note 3] 903 0-1 0 0 35 Login-LAT-Node [Note 3] 904 0-1 0 0 36 Login-LAT-Group [Note 3] 905 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 906 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 907 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 908 0-1 0 0 44 Acct-Session-Id [Note 1] 909 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 910 0-1 0-1 0-1 55 Event-Timestamp 911 0+ 0 0 56 Egress-VLANID [Note 3] 912 0-1 0 0 57 Ingress-Filters [Note 3] 913 0+ 0 0 58 Egress-VLAN-Name [Note 3] 914 0-1 0 0 59 User-Priority-Table [Note 3] 915 0-1 0 0 61 NAS-Port-Type [Note 3] 916 0-1 0 0 62 Port-Limit [Note 3] 917 0-1 0 0 63 Login-LAT-Port [Note 3] 918 0+ 0 0 64 Tunnel-Type [Note 5] 919 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 920 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 921 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 922 0+ 0 0 69 Tunnel-Password [Note 5] 923 0-1 0 0 71 ARAP-Features [Note 3] 924 0-1 0 0 72 ARAP-Zone-Access [Note 3] 925 0+ 0 0 78 Configuration-Token [Note 3] 926 0+ 0-1 0 79 EAP-Message [Note 2] 927 0-1 0-1 0-1 80 Message-Authenticator 928 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 929 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 930 0+ 0 0 83 Tunnel-Preference [Note 5] 931 0-1 0 0 85 Acct-Interim-Interval [Note 3] 932 0-1 0 0 87 NAS-Port-Id [Note 1] 933 0-1 0 0 88 Framed-Pool [Note 3] 934 0-1 0 0 89 Chargeable-User-Identity [Note 1] 935 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 936 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 937 0-1 0 0 92 NAS-Filter-Rule [Note 3] 938 0 0 0 94 Originating-Line-Info 939 0-1 0 0 95 NAS-IPv6-Address [Note 1] 940 0-1 0 0 96 Framed-Interface-Id [Notes 1,6] 941 0+ 0 0 97 Framed-IPv6-Prefix [Notes 1,6] 942 0+ 0 0 98 Login-IPv6-Host [Note 3] 943 0+ 0 0 99 Framed-IPv6-Route [Note 3] 944 Request ACK NAK # Attribute 945 Request ACK NAK # Attribute 946 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 947 0 0 0+ 101 Error-Cause 948 0+ 0 0 123 Delegated-IPv6-Prefix [Note 3] 949 Request ACK NAK # Attribute 951 Disconnect Messages 953 Request ACK NAK # Attribute 954 0-1 0 0 1 User-Name [Note 1] 955 0-1 0 0 4 NAS-IP-Address [Note 1] 956 0-1 0 0 5 NAS-Port [Note 1] 957 0 0 0 6 Service-Type 958 0 0 0 8 Framed-IP-Address [Note 1] 959 0+ 0 0 18 Reply-Message [Note 2] 960 0 0 0 24 State 961 0+ 0 0 25 Class [Note 4] 962 0+ 0 0 26 Vendor-Specific [Note 7] 963 0-1 0 0 30 Called-Station-Id [Note 1] 964 0-1 0 0 31 Calling-Station-Id [Note 1] 965 0-1 0 0 32 NAS-Identifier [Note 1] 966 0+ 0+ 0+ 33 Proxy-State 967 0-1 0 0 44 Acct-Session-Id [Note 1] 968 0-1 0-1 0 49 Acct-Terminate-Cause 969 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 970 0-1 0-1 0-1 55 Event-Timestamp 971 0 0 0 61 NAS-Port-Type 972 0+ 0-1 0 79 EAP-Message [Note 2] 973 0-1 0-1 0-1 80 Message-Authenticator 974 0-1 0 0 87 NAS-Port-Id [Note 1] 975 0-1 0 0 89 Chargeable-User-Identity [Note 1] 976 0-1 0 0 95 NAS-IPv6-Address [Note 1] 977 0 0 0 96 Framed-Interface-Id [Note 1] 978 0 0 0 97 Framed-IPv6-Prefix [Note 1] 979 0 0 0+ 101 Error-Cause 980 Request ACK NAK # Attribute 982 The following table defines the meaning of the above table entries. 984 0 This attribute MUST NOT be present in packet. 985 0+ Zero or more instances of this attribute MAY be present in packet. 986 0-1 Zero or one instance of this attribute MAY be present in packet. 987 1 Exactly one instance of this attribute MUST be present in packet. 989 [Note 1] Where NAS or session identification attributes are included 990 in Disconnect-Request or CoA-Request packets, they are used for 991 identification purposes only. These attributes MUST NOT be used for 992 purposes other than identification (e.g. within CoA-Request packets 993 to request authorization changes). 995 [Note 2] The Reply-Message Attribute is used to present a displayable 996 message to the user. The message is only displayed as a result of a 997 successful Disconnect-Request or CoA-Request (where a Disconnect-ACK 998 or CoA-ACK is subsequently sent). Where EAP is used for 999 authentication, an EAP-Message/Notification-Request Attribute is sent 1000 instead, and Disconnect-ACK or CoA-ACK packets contain an EAP- 1001 Message/Notification-Response Attribute. 1003 [Note 3] When included within a CoA-Request, these attributes 1004 represent an authorization change request. When one of these 1005 attributes is omitted from a CoA-Request, the NAS assumes that the 1006 attribute value is to remain unchanged. Attributes included in a 1007 CoA-Request replace all existing value(s) of the same attribute(s). 1009 [Note 4] When included within a successful Disconnect-Request (where 1010 a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be 1011 sent unmodified by the NAS to the RADIUS accounting server in the 1012 Accounting Stop packet. If the Disconnect-Request is unsuccessful, 1013 then the Class Attribute is not processed. 1015 [Note 5] When included within a CoA-Request, these attributes 1016 represent an authorization change request. Where tunnel attribute(s) 1017 are included within a successful CoA-Request, all existing tunnel 1018 attributes are removed and replaced by the new attribute(s). 1020 [Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and Framed- 1021 Interface-Id attributes are used for session identification, 1022 renumbering cannot be accomplished by including values of these 1023 attributes within a CoA-Request. Instead, a CoA-Request including a 1024 Service-Type Attribute with a value of "Authorize Only" is sent; new 1025 values can be supplied in an Access-Accept sent in response to the 1026 ensuing Access-Request. Note that renumbering will not be possible 1027 in all situations. For example, in order to change an IP address, 1028 IPCP or IPv6CP re-negotiation could be required, which is not 1029 supported by all PPP implementations. 1031 [Note 7] Within Disconnect-Request packets, Vendor-Specific 1032 Attributes (VSAs) MAY be used for session identification. Within 1033 CoA-Request packets, VSAs MAY be used for either session 1034 identification or authorization change. However, the same Attribute 1035 MUST NOT be used for both purposes simultaneously. 1037 4. Diameter Considerations 1039 Due to differences in handling change-of-authorization requests in 1040 RADIUS and Diameter, it may be difficult or impossible for a 1041 Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth- 1042 Request (RAR) to a CoA-Request and vice versa. For example, since a 1043 CoA-Request only initiates an authorization change but does not 1044 initiate re-authentication, a RAR command containing a Re-Auth- 1045 Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be 1046 directly translated to a CoA-Request. A Diameter/RADIUS gateway 1047 receiving a CoA-Request containing authorization changes will need to 1048 translate this into two Diameter exchanges. First, the 1049 Diameter/RADIUS gateway will issue a RAR command including a Session- 1050 Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". 1051 Then the Diameter/RADIUS gateway will respond to the ensuing access 1052 request with a response including the authorization attributes 1053 gleaned from the CoA-Request. To enable translation, the CoA-Request 1054 SHOULD include a Acct-Session-Id Attribute. If the Diameter client 1055 uses the same Session-Id for both authorization and accounting, then 1056 the Diameter/RADIUS gateway can copy the contents of the Acct- 1057 Session-Id Attribute into the Session-Id AVP; otherwise, it will 1058 need to map the Acct-Session-Id value to an equivalent Session-Id for 1059 use within a RAR command. 1061 Where an Acct-Session-Id attribute is not present in a CoA-Request or 1062 Disconnect-Request, a Diameter/RADIUS gateway will either need to 1063 determine the appropriate Acct-Session-Id, or if it cannot do so, it 1064 can send a CoA-NAK or Disconnect-NAK in reply, possibly including an 1065 Error-Cause Attribute with value 508 (Multiple Session Identification 1066 Unsupported). 1068 To simplify translation between RADIUS and Diameter, Dynamic 1069 Authorization Clients can include a Service-Type Attribute with value 1070 "Authorize Only" within a CoA-Request, as described in Section 3.2. 1071 A Diameter/RADIUS gateway receiving a CoA-Request containing a 1072 Service-Type with value "Authorize Only" translates this to a RAR 1073 with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The 1074 received RAA is then translated to a CoA-NAK with a Service-Type 1075 value of "Authorize Only". If the Result-Code AVP in the RAA has a 1076 value in the success category, then an Error-Cause Attribute with 1077 value "Request Initiated" is included in the CoA-NAK. If the 1078 Result-Code AVP in the RAA has a value indicating a Protocol Error or 1079 a Transient or Permanent Failure, then an alternate Error-Cause 1080 Attribute is returned as suggested below. 1082 Within Diameter, a server can request that a session be aborted by 1083 sending an Abort-Session-Request (ASR), identifying the session to be 1084 terminated using Session-ID and User-Name AVPs. The ASR command is 1085 translated to a Disconnect-Request containing Acct-Session-Id and 1086 User-Name attributes. If the Diameter client utilizes the same 1087 Session-Id in both authorization and accounting, then the value of 1088 the Session-ID AVP may be placed in the Acct-Session-Id attribute; 1089 otherwise the value of the Session-ID AVP will need to be mapped to 1090 an appropriate Acct-Session-Id value. To enable translation of a 1091 Disconnect-Request to an ASR, an Acct-Session-Id attribute SHOULD be 1092 present. 1094 If the Diameter client utilizes the same Session-Id in both 1095 authorization and accounting, then the value of the Acct-Session-Id 1096 may be placed into the Session-ID AVP within the ASR; otherwise the 1097 value of the Acct-Session-Id will need to be mapped to an appropriate 1098 Session-ID value. 1100 An Abort-Session-Answer (ASA) command is sent in response to an ASR 1101 in order to indicate the disposition of the request. A 1102 Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to 1103 an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A 1104 Disconnect-NAK received from the NAS is translated to an ASA command 1105 with a Result-Code AVP which depends on the value of the Error-Cause 1106 Attribute. Suggested translations between Error-Cause Attribute 1107 values and Result-Code AVP values are included below: 1109 # Error-Cause Attribute Value Result-Code AVP 1110 --- --------------------------- ------------------------ 1111 201 Residual Session Context DIAMETER_SUCCESS 1112 Removed 1113 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS 1114 (Ignored) 1115 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED 1116 402 Missing Attribute DIAMETER_MISSING_AVP 1117 403 NAS Identification DIAMETER_REALM_NOT_SERVED 1118 Mismatch 1119 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY 1120 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED 1121 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED 1122 407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE 1123 501 Administratively DIAMETER_AUTHORIZATION_REJECTED 1124 Prohibited 1125 502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER 1126 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID 1127 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED 1128 Removable 1129 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY 1130 Error 1131 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED 1132 507 Request Initiated DIAMETER_SUCCESS 1134 Since both the ASR/ASA and Disconnect-Request/Disconnect- 1135 NAK/Disconnect-ACK exchanges involve just a request and response, 1136 inclusion of an "Authorize Only" Service-Type within a Disconnect- 1137 Request is not needed to assist in Diameter/RADIUS translation, and 1138 may make translation more difficult. As a result, as noted in 1139 Section 3.2, the Service-Type Attribute MUST NOT be used within a 1140 Disconnect-Request. 1142 5. IANA Considerations 1144 This document uses the RADIUS [RFC2865] namespace, see 1145 . In addition to the 1146 allocations already made in [RFC3575] and [RFC3576], this 1147 specification requests allocation of additional values of the Error- 1148 Cause Attribute (101): 1150 # Value 1151 --- ----- 1152 407 Invalid Attribute Value 1153 508 Multiple Session Selection Unsupported 1155 6. Security Considerations 1157 6.1. Authorization Issues 1159 Where a NAS is shared by multiple providers, it is undesirable for 1160 one provider to be able to send Disconnect-Request or CoA-Requests 1161 affecting the sessions of another provider. 1163 A Dynamic Authorization Server MUST silently discard Disconnect- 1164 Request or CoA-Request packets from untrusted sources. In situations 1165 where the Dynamic Authorization Client is co-resident with a RADIUS 1166 authentication or accounting server, a proxy MAY perform a "reverse 1167 path forwarding" (RPF) check to verify that a Disconnect-Request or 1168 CoA-Request originates from an authorized Dynamic Authorization 1169 Client. In addition, it SHOULD be possible to explicitly authorize 1170 additional sources of Disconnect-Request or CoA-Request packets 1171 relating to certain classes of sessions. For example, a particular 1172 source can be explicitly authorized to send CoA-Request packets 1173 relating to users within a set of realms. 1175 To perform the RPF check, the Dynamic Authorization Server uses the 1176 session identification attributes included in Disconnect-Request or 1177 CoA-Request packets, in order to determine the RADIUS server(s) to 1178 which an equivalent Access-Request could be routed. If the source 1179 address of the Disconnect-Request or CoA-Request is within this set, 1180 then the CoA-Request or Disconnect-Request is forwarded; otherwise it 1181 MUST be silently discarded. 1183 Typically the Dynamic Authorization Server will extract the realm 1184 from the Network Access Identifier [RFC4282] included within the 1185 User-Name or Chargeable-User-Identity Attribute, and determine the 1186 corresponding RADIUS servers in the realm routing tables. If the 1187 Dynamic Authorization Server maintains long-term session state, it 1188 MAY perform the authorization check based on the session 1189 identification attributes in the CoA-Request. The session 1190 identification attributes can be used to tie a session to a 1191 particular proxy or set of proxies, as with the NAI realm. 1193 Where no proxy is present, the RPF check can only be performed by the 1194 NAS if it maintains its own a realm routing table. If the NAS does 1195 not maintain a realm routing table (e.g. it selects forwarding 1196 proxies based on primary/secondary configuration and/or liveness 1197 checks), then an RPF check cannot be performed. 1199 Since authorization to send a Disconnect-Request or CoA-Request is 1200 determined based on the source address and the corresponding shared 1201 secret, the Dynamic Authorization Server SHOULD configure a different 1202 shared secret for each Dynamic Authorization Client. 1204 6.2. IPsec Usage Guidelines 1206 In addition to security vulnerabilities unique to Disconnect or CoA 1207 packets, the protocol exchanges described in this document are 1208 susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is 1209 RECOMMENDED that IPsec be employed to afford better security, 1210 utilizing the profile described in [RFC3579] Section 4.2. 1212 For Dynamic Authorization Servers implementing this specification the 1213 IPsec policy would be "Require IPsec, from any to me, destination 1214 port UDP 3799". This causes the Dynamic Authorization Server to 1215 require use of IPsec. If some Dynamic Authorization Clients do not 1216 support IPsec, then a more granular policy will be required: "Require 1217 IPsec, from IPsec-Capable-DAC to me." 1219 For Dynamic Authorization Clients implementing this specification, 1220 the IPsec policy would be "Initiate IPsec, from me to any, 1221 destination port UDP 3799". This causes the Dynamic Authorization 1222 Client to initiate IPsec when sending Dynamic Authorization traffic 1223 to any Dynamic Authorization Server. If some Dynamic Authorization 1224 Servers contacted by the Dynamic Authorization Client do not support 1225 IPsec, then a more granular policy will be required, such as 1226 "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 1227 3799". 1229 Where IPsec is used for security, and no RADIUS shared secret is 1230 configured, it is important that the DAC and DAS perform an 1231 authorization check. Before enabling a host to act as a DAS, the DAC 1232 SHOULD check whether the host is authorized to act in that role. 1234 Similarly, before enabling a host to act as a DAC, the DAS SHOULD 1235 check whether the host is authorized for that role, utilizing the 1236 mechanisms described in [RFC3579] Section 4.2. 1238 6.3. Replay Protection 1240 Where IPsec replay protection is not used, an Event-Timestamp (55) 1241 [RFC2869] Attribute SHOULD be included within CoA-Request and 1242 Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- 1243 NAK, Disconnect-ACK and Disconnect-NAK packets. 1245 When the Event-Timestamp attribute is present, both the Dynamic 1246 Authorization Server and the Dynamic Authorization Client MUST check 1247 that the Event-Timestamp Attribute is current within an acceptable 1248 time window. If the Event-Timestamp Attribute is not current, then 1249 the packet MUST be silently discarded. This implies the need for 1250 loose time synchronization within the network, which can be achieved 1251 by a variety of means, including SNTP, as described in [RFC4330]. 1252 Implementations SHOULD be configurable to discard CoA-Request or 1253 Disconnect-Request packets not containing an Event-Timestamp 1254 attribute. 1256 If the Event-Timestamp Attribute is included, it represents the time 1257 at which the original packet was sent, and therefore it SHOULD NOT be 1258 updated when the packet is retransmitted. If the Event-Timestamp 1259 attribute is not updated, this implies that the Identifier is not 1260 changed in retransmitted packets. As a result, the ability to detect 1261 replay within the time window is dependent on support for duplicate 1262 detection within that same window. As noted in Section 2.3, 1263 duplicate detection is REQUIRED for Dynamic Authorization Servers 1264 implementing this specification. 1266 The time window used for duplicate detection MUST be the same as the 1267 window used to detect stale Event-Timestamp Attributes. Since the 1268 RADIUS Identifier cannot be repeated within the selected time window, 1269 no more than 256 Requests can be accepted within the time window. As 1270 a result, the chosen time window will depend on the expected maximum 1271 volume of CoA/Disconnect-Requests, so that unnecessary discards can 1272 be avoided. A default time window of 300 seconds should be adequate 1273 in many circumstances. 1275 7. Example Traces 1277 Disconnect Request with User-Name: 1279 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 1280 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 1281 32: 6d63 6869 6261 1283 Disconnect Request with Acct-Session-ID: 1285 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 1286 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 1287 32: 3930 3233 3435 3637 90234567 1289 Disconnect Request with Framed-IP-Address: 1291 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 1292 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 1293 32: 0a00 0203 1295 8. References 1297 8.1. Normative References 1299 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1300 April 1992. 1302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1303 Requirement Levels", RFC 2119, March 1997. 1305 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1306 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1307 2000. 1309 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1311 [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", 1312 RFC 2869, June 2000. 1314 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1315 3162, August 2001. 1317 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 1318 2003. 1320 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1321 Authentication Protocol (EAP)", RFC 3579, September 2003. 1323 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 1324 Access Identifier", RFC 4282, December 2005. 1326 8.2. Informative References 1328 [MD5Attack] 1329 Dobbertin, H., "The Status of MD5 After a Recent Attack", 1330 CryptoBytes Vol.2 No.2, Summer 1996. 1332 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 1333 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1334 Support", RFC 2868, June 2000. 1336 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 1337 Accounting Transport Profile", RFC 3539, June 2003. 1339 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1340 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1342 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1343 "Dynamic Authorization Extensions to Remote Authentication 1344 Dial In User Service (RADIUS)", RFC 3576, July 2003. 1346 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1347 IPv4, IPv6 and OSI", RFC 4330, January 2006. 1349 [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, 1350 "Chargeable User Identity", RFC 4372, January 2006. 1352 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1353 Virtual LAN and Priority Support", RFC 4675, September 2006. 1355 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1356 Attribute", RFC 4818, April 2007. 1358 [RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter Rule 1359 Attribute", RFC 4849, April 2007. 1361 Acknowledgments 1363 This protocol was first developed and distributed by Ascend 1364 Communications. Example code was distributed in their free server 1365 kit. 1367 The authors would like to acknowledge valuable suggestions and 1368 feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark 1369 Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, 1370 Russ Housley, Joe Salowey, Alan DeKok and David Nelson. 1372 Authors' Addresses 1374 Murtaza Chiba 1375 Cisco Systems, Inc. 1376 170 West Tasman Dr. 1377 San Jose CA, 95134 1379 EMail: mchiba@cisco.com 1380 Phone: +1 408 525 7198 1382 Gopal Dommety 1383 Cisco Systems, Inc. 1384 170 West Tasman Dr. 1385 San Jose, CA 95134 1387 EMail: gdommety@cisco.com 1388 Phone: +1 408 525 1404 1390 Mark Eklund 1391 Cisco Systems, Inc. 1392 170 West Tasman Dr. 1393 San Jose, CA 95134 1395 EMail: meklund@cisco.com 1396 Phone: +1 865 671 6255 1398 David Mitton 1399 RSA Security, Inc. 1400 174 Middlesex Turnpike 1401 Bedford, MA 01730 1403 EMail: dmitton@circularnetworks.com 1405 Bernard Aboba 1406 Microsoft Corporation 1407 One Microsoft Way 1408 Redmond, WA 98052 1410 EMail: bernarda@microsoft.com 1411 Phone: +1 425 706 6605 1412 Fax: +1 425 936 7329 1414 Appendix A - Changes from RFC 3576 1416 This Appendix lists the major changes between [RFC3576] and this 1417 document. Minor changes, including style, grammar, spelling, and 1418 editorial changes are not mentioned here. 1420 o The term "Dynamic Authorization Client" is used instead of RADIUS 1421 server where it applies to the originator of CoA-Request and 1422 Disconnect-Request packets. The term "Dynamic Authorization Server" 1423 is used instead of NAS where it applies to the receiver of CoA- 1424 Request and Disconnect-Request packets. Definitions of these terms 1425 have been added (Section 1.3). 1427 o Added requirement for duplicate detection on the Dynamic 1428 Authorization Server (Section 2.3). 1430 o Clarified expected behavior when session identification attributes 1431 match more than one session (Sections 2.3, 3, 3.5, 4). 1433 o Added Chargeable-User-Identity as a session identification 1434 attribute. Removed NAS-Port-Type as a session identification 1435 attribute (Section 3). 1437 o Added recommendation that an Acct-Session-Id or Acct-Mult-Session- 1438 Id Attribute be included in an Access-Request (Section 3). 1440 o Added discussion of scenarios in which the "Dynamic Authorization 1441 Client" and RADIUS server are not co-located (Section 3). 1443 o Added details relating to handling of the Proxy-State Attribute 1444 (Section 3.1). 1446 o Added clarification that support for a Service-Type Attribute with 1447 value "Authorize Only" is optional on both the NAS and Dynamic 1448 Authorization Client (Section 3.2). Use of the Service-Type 1449 Attribute within a Disconnect-Request is prohibited (Sections 3.2, 1450 3.6). 1452 o Added requirement for inclusion of the State Attribute in CoA- 1453 Request packets including a Service-Type Attribute with a value of 1454 "Authorize Only" (Section 3.3). 1456 o Added clarification on the calculation of the Message-Authenticator 1457 Attribute (Section 3.4). 1459 o Additional Error-Cause Attribute values are allocated for Invalid 1460 Attribute Value (407) and Multiple Session Identification Unsupported 1461 (508) (Sections 3.5, 4). 1463 o Updated the CoA-Request Attribute Table to include Filter-Rule, 1464 Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN- 1465 Name and User-Priority attributes (Section 3.6). 1467 o Added the Chargeable-User-Identity Attribute to both the CoA- 1468 Request and Disconnect-Request Attribute table (Section 3.6). 1470 o Use of Vendor-Specific Attributes (VSAs) for session identification 1471 and authorization change has been clarified (Section 3.6). 1473 o Added Note 6 on the use of the CoA-Request for renumbering, and 1474 Note 7 on the use of Vendor-Specific attributes (Section 3.6). 1476 o Added Diameter Considerations (Section 4). 1478 o Event-Timestamp Attribute should not be recalculated on 1479 retransmission. The implications for replay and duplicate detection 1480 are discussed (Section 6.3). 1482 o Operation of the Reverse Path Forwarding (RPF) check has been 1483 clarified. Use of the RPF check is optional rather than recommended 1484 by default (Section 6.1). 1486 o Text on impersonation (included in [RFC3579] Section 4.3.7) and 1487 IPsec operation (included in [RFC3579] Section 4.2) has been removed, 1488 and is now referenced. 1490 Full Copyright Statement 1492 Copyright (C) The IETF Trust (2007). 1494 This document is subject to the rights, licenses and restrictions 1495 contained in BCP 78, and except as set forth therein, the authors 1496 retain all their rights. 1498 This document and the information contained herein are provided on an 1499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1501 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1502 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1503 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1506 Intellectual Property 1508 The IETF takes no position regarding the validity or scope of any 1509 Intellectual Property Rights or other rights that might be claimed to 1510 pertain to the implementation or use of the technology described in 1511 this document or the extent to which any license under such rights 1512 might or might not be available; nor does it represent that it has 1513 made any independent effort to identify any such rights. Information 1514 on the procedures with respect to rights in RFC documents can be 1515 found in BCP 78 and BCP 79. 1517 Copies of IPR disclosures made to the IETF Secretariat and any 1518 assurances of licenses to be made available, or the result of an 1519 attempt made to obtain a general license or permission for the use of 1520 such proprietary rights by implementers or users of this 1521 specification can be obtained from the IETF on-line IPR repository at 1522 http://www.ietf.org/ipr. 1524 The IETF invites any interested party to bring to its attention any 1525 copyrights, patents or patent applications, or other proprietary 1526 rights that may cover technology that may be required to implement 1527 this standard. Please address the information to the IETF at 1528 ietf-ipr@ietf.org. 1530 Acknowledgment 1532 Funding for the RFC Editor function is currently provided by the 1533 Internet Society. 1535 Open issues 1537 Open issues relating to this specification are tracked on the 1538 following web site: 1540 http://www.drizzle.com/~aboba/RADEXT/