idnits 2.17.1 draft-ietf-radius-accounting-v2-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A forwarding server MUST not modify existing Proxy-State or Class attributes present in the packet. -- 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 (February 2000) is 8831 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Note 1' on line 1131 ** Obsolete normative reference: RFC 2139 (ref. '1') (Obsoleted by RFC 2866) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2279 (ref. '7') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RADIUS Working Group C Rigney 2 INTERNET-DRAFT Livingston 3 expires August 2000 February 2000 5 RADIUS Accounting 6 draft-ietf-radius-accounting-v2-04.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 This document obsoletes RFC 2139 [1]. A summary of the changes 14 between this document and RFC 2139 is available in the "Change Log" 15 appendix. 17 This document is a submission to the RADIUS Working Group of the 18 Internet Engineering Task Force (IETF). Comments should be submitted 19 to the ietf-radius@livingston.com mailing list. 21 Distribution of this memo is unlimited. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2000). All Rights Reserved. 43 Abstract 45 This document describes a protocol for carrying accounting 46 information between a Network Access Server and a shared Accounting 47 Server. 49 Implementation Note 51 This memo documents the RADIUS Accounting protocol. The early 52 deployment of RADIUS Accounting was done using UDP port number 1646, 53 which conflicts with the "sa-msg-port" service. The officially 54 assigned port number for RADIUS Accounting is 1813. 56 Table of Contents 58 1. Introduction .......................................... 4 59 1.1 Specification of Requirements ................... 5 60 1.2 Terminology ..................................... 5 62 2. Operation ............................................. 5 63 2.1 Proxy ........................................... 6 65 3. Packet Format ......................................... 7 67 4. Packet Types .......................................... 9 68 4.1 Accounting-Request .............................. 9 69 4.2 Accounting-Response ............................. 11 71 5. Attributes ............................................ 12 72 5.1 Acct-Status-Type ................................ 13 73 5.2 Acct-Delay-Time ................................. 14 74 5.3 Acct-Input-Octets ............................... 15 75 5.4 Acct-Output-Octets .............................. 16 76 5.5 Acct-Session-Id ................................. 17 77 5.6 Acct-Authentic .................................. 18 78 5.7 Acct-Session-Time ............................... 19 79 5.8 Acct-Input-Packets .............................. 19 80 5.9 Acct-Output-Packets ............................. 20 81 5.10 Acct-Terminate-Cause ............................ 21 82 5.11 Acct-Multi-Session-Id ........................... 23 83 5.12 Acct-Link-Count ................................. 24 84 5.13 Table of Attributes ............................. 25 86 6. IANA Considerations ................................... 27 88 7. Security Considerations ............................... 27 90 8. Change Log ............................................ 27 92 9. References ............................................ 27 93 10. Acknowledgements ...................................... 28 95 11. Chair's Address ....................................... 28 97 12. Author's Address ...................................... 28 99 13. Full Copyright Statement .............................. 29 101 1. Introduction 103 Managing dispersed serial line and modem pools for large numbers of 104 users can create the need for significant administrative support. 105 Since modem pools are by definition a link to the outside world, they 106 require careful attention to security, authorization and accounting. 107 This can be best achieved by managing a single "database" of users, 108 which allows for authentication (verifying user name and password) as 109 well as configuration information detailing the type of service to 110 deliver to the user (for example, SLIP, PPP, telnet, rlogin). 112 The RADIUS (Remote Authentication Dial In User Service) document [2] 113 specifies the RADIUS protocol used for Authentication and 114 Authorization. This memo extends the use of the RADIUS protocol to 115 cover delivery of accounting information from the Network Access 116 Server (NAS) to a RADIUS accounting server. 118 This document obsoletes RFC 2139 [1]. A summary of the changes 119 between this document and RFC 2139 is available in the "Change Log" 120 appendix. 122 Key features of RADIUS Accounting are: 124 Client/Server Model 126 A Network Access Server (NAS) operates as a client of the 127 RADIUS accounting server. The client is responsible for 128 passing user accounting information to a designated RADIUS 129 accounting server. 131 The RADIUS accounting server is responsible for receiving the 132 accounting request and returning a response to the client 133 indicating that it has successfully received the request. 135 The RADIUS accounting server can act as a proxy client to other 136 kinds of accounting servers. 138 Network Security 140 Transactions between the client and RADIUS accounting server 141 are authenticated through the use of a shared secret, which is 142 never sent over the network. 144 Extensible Protocol 146 All transactions are comprised of variable length Attribute- 147 Length-Value 3-tuples. New attribute values can be added 148 without disturbing existing implementations of the protocol. 150 1.1. Specification of Requirements 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 RFC 2119 [3]. These 155 key words mean the same thing whether capitalized or not. 157 1.2. Terminology 159 This document uses the following terms: 161 service The NAS provides a service to the dial-in user, such as PPP 162 or Telnet. 164 session Each service provided by the NAS to a dial-in user 165 constitutes a session, with the beginning of the session 166 defined as the point where service is first provided and 167 the end of the session defined as the point where service 168 is ended. A user may have multiple sessions in parallel or 169 series if the NAS supports that, with each session 170 generating a separate start and stop accounting record with 171 its own Acct-Session-Id. 173 silently discard 174 This means the implementation discards the packet without 175 further processing. The implementation SHOULD provide the 176 capability of logging the error, including the contents of 177 the silently discarded packet, and SHOULD record the event 178 in a statistics counter. 180 2. Operation 182 When a client is configured to use RADIUS Accounting, at the start of 183 service delivery it will generate an Accounting Start packet 184 describing the type of service being delivered and the user it is 185 being delivered to, and will send that to the RADIUS Accounting 186 server, which will send back an acknowledgement that the packet has 187 been received. At the end of service delivery the client will 188 generate an Accounting Stop packet describing the type of service 189 that was delivered and optionally statistics such as elapsed time, 190 input and output octets, or input and output packets. It will send 191 that to the RADIUS Accounting server, which will send back an 192 acknowledgement that the packet has been received. 194 The Accounting-Request (whether for Start or Stop) is submitted to 195 the RADIUS accounting server via the network. It is recommended that 196 the client continue attempting to send the Accounting-Request packet 197 until it receives an acknowledgement, using some form of backoff. If 198 no response is returned within a length of time, the request is re- 199 sent a number of times. The client can also forward requests to an 200 alternate server or servers in the event that the primary server is 201 down or unreachable. An alternate server can be used either after a 202 number of tries to the primary server fail, or in a round-robin 203 fashion. Retry and fallback algorithms are the topic of current 204 research and are not specified in detail in this document. 206 The RADIUS accounting server MAY make requests of other servers in 207 order to satisfy the request, in which case it acts as a client. 209 If the RADIUS accounting server is unable to successfully record the 210 accounting packet it MUST NOT send an Accounting-Response 211 acknowledgment to the client. 213 2.1. Proxy 215 See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy 216 Accounting RADIUS works the same way, as illustrated by the following 217 example. 219 1. The NAS sends an accounting-request to the forwarding server. 221 2. The forwarding server logs the accounting-request (if desired), 222 adds its Proxy-State (if desired) after any other Proxy-State 223 attributes, updates the Request Authenticator, and forwards the 224 request to the remote server. 226 3. The remote server logs the accounting-request (if desired), 227 copies all Proxy-State attributes in order and unmodified from 228 the request to the response packet, and sends the accounting- 229 response to the forwarding server. 231 4 The forwarding server strips the last Proxy-State (if it added 232 one in step 2), updates the Response Authenticator and sends 233 the accounting-response to the NAS. 235 A forwarding server MUST not modify existing Proxy-State or Class 236 attributes present in the packet. 238 A forwarding server may either perform its forwarding function in a 239 pass through manner, where it sends retransmissions on as soon as it 240 gets them, or it may take responsibility for retransmissions, for 241 example in cases where the network link between forwarding and remote 242 server has very different characteristics than the link between NAS 243 and forwarding server. 245 Extreme care should be used when implementing a proxy server that 246 takes responsibility for retransmissions so that its retransmission 247 policy is robust and scalable. 249 3. Packet Format 251 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 252 field [4], where the UDP Destination Port field indicates 1813 253 (decimal). 255 When a reply is generated, the source and destination ports are 256 reversed. 258 This memo documents the RADIUS Accounting protocol. The early 259 deployment of RADIUS Accounting was done using UDP port number 1646, 260 which conflicts with the "sa-msg-port" service. The officially 261 assigned port number for RADIUS Accounting is 1813. 263 A summary of the RADIUS data format is shown below. The fields are 264 transmitted from left to right. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Code | Identifier | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 | Authenticator | 273 | | 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Attributes ... 277 +-+-+-+-+-+-+-+-+-+-+-+-+- 279 Code 281 The Code field is one octet, and identifies the type of RADIUS 282 packet. When a packet is received with an invalid Code field, it is 283 silently discarded. 285 RADIUS Accounting Codes (decimal) are assigned as follows: 287 4 Accounting-Request 288 5 Accounting-Response 290 Identifier 292 The Identifier field is one octet, and aids in matching requests and 293 replies. The RADIUS server can detect a duplicate request if it has 294 the same client source IP address and source UDP port and Identifier 295 within a short span of time. 297 Length 299 The Length field is two octets. It indicates the length of the 300 packet including the Code, Identifier, Length, Authenticator and 301 Attribute fields. Octets outside the range of the Length field MUST 302 be treated as padding and ignored on reception. If the packet is 303 shorter than the Length field indicates, it MUST be silently 304 discarded. The minimum length is 20 and maximum length is 4095. 306 Authenticator 308 The Authenticator field is sixteen (16) octets. The most significant 309 octet is transmitted first. This value is used to authenticate the 310 messages between the client and RADIUS accounting server. 312 Request Authenticator 314 In Accounting-Request Packets, the Authenticator value is a 16 315 octet MD5 [5] checksum, called the Request Authenticator. 317 The NAS and RADIUS accounting server share a secret. The Request 318 Authenticator field in Accounting-Request packets contains a one- 319 way MD5 hash calculated over a stream of octets consisting of the 320 Code + Identifier + Length + 16 zero octets + request attributes + 321 shared secret (where + indicates concatenation). The 16 octet MD5 322 hash value is stored in the Authenticator field of the 323 Accounting-Request packet. 325 Note that the Request Authenticator of an Accounting-Request can 326 not be done the same way as the Request Authenticator of a RADIUS 327 Access-Request, because there is no User-Password attribute in an 328 Accounting-Request. 330 Response Authenticator 332 The Authenticator field in an Accounting-Response packet is called 333 the Response Authenticator, and contains a one-way MD5 hash 334 calculated over a stream of octets consisting of the Accounting- 335 Response Code, Identifier, Length, the Request Authenticator field 336 from the Accounting-Request packet being replied to, and the 337 response attributes if any, followed by the shared secret. The 338 resulting 16 octet MD5 hash value is stored in the Authenticator 339 field of the Accounting-Response packet. 341 Attributes 343 Attributes may have multiple instances, in such a case the order of 344 attributes of the same type SHOULD be preserved. The order of 345 attributes of different types is not required to be preserved. 347 4. Packet Types 349 The RADIUS packet type is determined by the Code field in the first 350 octet of the packet. 352 4.1. Accounting-Request 354 Description 356 Accounting-Request packets are sent from a client (typically a 357 Network Access Server or its proxy) to a RADIUS accounting server, 358 and convey information used to provide accounting for a service 359 provided to a user. The client transmits a RADIUS packet with the 360 Code field set to 4 (Accounting-Request). 362 Upon receipt of an Accounting-Request, the server MUST transmit an 363 Accounting-Response reply if it successfully records the 364 accounting packet, and MUST NOT transmit any reply if it fails to 365 record the accounting packet. 367 Any attribute valid in a RADIUS Access-Request or Access-Accept 368 packet is valid in a RADIUS Accounting-Request packet, except that 369 the following attributes MUST NOT be present in an Accounting- 370 Request: User-Password, CHAP-Password, Reply-Message, State. 371 Either NAS-IP-Address or NAS-Identifier MUST be present in a 372 RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- 373 Port-Type attribute or both unless the service does not involve a 374 port or the NAS does not distinguish among its ports. 376 If the Accounting-Request packet includes a Framed-IP-Address, 377 that attribute MUST contain the IP address of the user. If the 378 Access-Accept used the special values for Framed-IP-Address 379 telling the NAS to assign or negotiate an IP address for the user, 380 the Framed-IP-Address (if any) in the Accounting-Request MUST 381 contain the actual IP address assigned or negotiated. 383 A summary of the Accounting-Request packet format is shown below. 385 The fields are transmitted from left to right. 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Code | Identifier | Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 | Request Authenticator | 394 | | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Attributes ... 398 +-+-+-+-+-+-+-+-+-+-+-+-+- 400 Code 402 4 for Accounting-Request. 404 Identifier 406 The Identifier field MUST be changed whenever the content of the 407 Attributes field changes, and whenever a valid reply has been 408 received for a previous request. For retransmissions where the 409 contents are identical, the Identifier MUST remain unchanged. 411 Note that if Acct-Delay-Time is included in the attributes of an 412 Accounting-Request then the Acct-Delay-Time value will be updated 413 when the packet is retransmitted, changing the content of the 414 Attributes field and requiring a new Identifier and Request 415 Authenticator. 417 Request Authenticator 419 The Request Authenticator of an Accounting-Request contains a 16- 420 octet MD5 hash value calculated according to the method described 421 in "Request Authenticator" above. 423 Attributes 425 The Attributes field is variable in length, and contains a list of 426 Attributes. 428 4.2. Accounting-Response 430 Description 432 Accounting-Response packets are sent by the RADIUS accounting 433 server to the client to acknowledge that the Accounting-Request 434 has been received and recorded successfully. If the Accounting- 435 Request was recorded successfully then the RADIUS accounting 436 server MUST transmit a packet with the Code field set to 5 437 (Accounting-Response). On reception of an Accounting-Response by 438 the client, the Identifier field is matched with a pending 439 Accounting-Request. The Response Authenticator field MUST contain 440 the correct response for the pending Accounting-Request. Invalid 441 packets are silently discarded. 443 A RADIUS Accounting-Response is not required to have any 444 attributes in it. 446 A summary of the Accounting-Response packet format is shown below. 447 The fields are transmitted from left to right. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Code | Identifier | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 | Response Authenticator | 456 | | 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Attributes ... 460 +-+-+-+-+-+-+-+-+-+-+-+-+- 462 Code 464 5 for Accounting-Response. 466 Identifier 468 The Identifier field is a copy of the Identifier field of the 469 Accounting-Request which caused this Accounting-Response. 471 Response Authenticator 473 The Response Authenticator of an Accounting-Response contains a 474 16-octet MD5 hash value calculated according to the method 475 described in "Response Authenticator" above. 477 Attributes 479 The Attributes field is variable in length, and contains a list of 480 zero or more Attributes. 482 5. Attributes 484 RADIUS Attributes carry the specific authentication, authorization 485 and accounting details for the request and response. 487 Some attributes MAY be included more than once. The effect of this 488 is attribute specific, and is specified in each attribute 489 description. 491 The end of the list of attributes is indicated by the Length of the 492 RADIUS packet. 494 A summary of the attribute format is shown below. The fields are 495 transmitted from left to right. 497 0 1 2 498 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type | Length | Value ... 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Type 505 The Type field is one octet. Up-to-date values of the RADIUS Type 506 field are specified in the most recent "Assigned Numbers" RFC [6]. 507 Values 192-223 are reserved for experimental use, values 224-240 508 are reserved for implementation-specific use, and values 241-255 509 are reserved and should not be used. This specification concerns 510 the following values: 512 1-39 (refer to RADIUS document [2]) 513 40 Acct-Status-Type 514 41 Acct-Delay-Time 515 42 Acct-Input-Octets 516 43 Acct-Output-Octets 517 44 Acct-Session-Id 518 45 Acct-Authentic 519 46 Acct-Session-Time 520 47 Acct-Input-Packets 521 48 Acct-Output-Packets 522 49 Acct-Terminate-Cause 523 50 Acct-Multi-Session-Id 524 51 Acct-Link-Count 525 60+ (refer to RADIUS document [2]) 527 Length 529 The Length field is one octet, and indicates the length of this 530 attribute including the Type, Length and Value fields. If an 531 attribute is received in an Accounting-Request with an invalid 532 Length, the entire request MUST be silently discarded. 534 Value 536 The Value field is zero or more octets and contains information 537 specific to the attribute. The format and length of the Value 538 field is determined by the Type and Length fields. 540 Note that a "string" in RADIUS does not terminate with a NUL (hex 541 00). The Attribute has a length field and does not use a 542 terminator. Strings may contain UTF-8 [7] characters or 8-bit 543 binary data and servers and servers and clients MUST be able to 544 deal with embedded nulls. RADIUS implementers using C are 545 cautioned not to use strcpy() when handling strings. 547 The format of the value field is one of four data types. 549 string 1-253 octets. Strings of length zero (0) MUST NOT be 550 sent; omit the entire attribute instead. 552 address 32 bit value, most significant octet first. 554 integer 32 bit unsigned value, most significant octet first. 556 time 32 bit unsigned value, most significant octet first -- 557 seconds since 00:00:00 UTC, January 1, 1970. The 558 standard Attributes do not use this data type but it is 559 presented here for possible use within future 560 attributes. 562 5.1. Acct-Status-Type 564 Description 566 This attribute indicates whether this Accounting-Request marks the 567 beginning of the user service (Start) or the end (Stop). 569 It MAY be used by the client to mark the start of accounting (for 570 example, upon booting) by specifying Accounting-On and to mark the 571 end of accounting (for example, just before a scheduled reboot) by 572 specifying Accounting-Off. 574 A summary of the Acct-Status-Type attribute format is shown below. 575 The fields are transmitted from left to right. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | Length | Value 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Value (cont) | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Type 587 40 for Acct-Status-Type. 589 Length 591 6 593 Value 595 The Value field is four octets. 597 1 Start 598 2 Stop 599 3 Interim-Update 600 7 Accounting-On 601 8 Accounting-Off 602 9-14 Reserved for Tunnel Accounting 603 15 Reserved for Failed 605 5.2. Acct-Delay-Time 607 Description 609 This attribute indicates how many seconds the client has been 610 trying to send this record for, and can be subtracted from the 611 time of arrival on the server to find the approximate time of the 612 event generating this Accounting-Request. (Network transit time 613 is ignored.) 615 Note that changing the Acct-Delay-Time causes the Identifier to 616 change; see the discussion under Identifier above. 618 A summary of the Acct-Delay-Time attribute format is shown below. 619 The fields are transmitted from left to right. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Length | Value 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Value (cont) | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Type 631 41 for Acct-Delay-Time. 633 Length 635 6 637 Value 639 The Value field is four octets. 641 5.3. Acct-Input-Octets 643 Description 645 This attribute indicates how many octets have been received from 646 the port over the course of this service being provided, and can 647 only be present in Accounting-Request records where the Acct- 648 Status-Type is set to Stop. 650 A summary of the Acct-Input-Octets attribute format is shown below. 651 The fields are transmitted from left to right. 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Type | Length | Value 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Value (cont) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Type 663 42 for Acct-Input-Octets. 665 Length 667 6 669 Value 671 The Value field is four octets. 673 5.4. Acct-Output-Octets 675 Description 677 This attribute indicates how many octets have been sent to the 678 port in the course of delivering this service, and can only be 679 present in Accounting-Request records where the Acct-Status-Type 680 is set to Stop. 682 A summary of the Acct-Output-Octets attribute format is shown below. 683 The fields are transmitted from left to right. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Type | Length | Value 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Value (cont) | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Type 695 43 for Acct-Output-Octets. 697 Length 699 6 701 Value 703 The Value field is four octets. 705 5.5. Acct-Session-Id 707 Description 709 This attribute is a unique Accounting ID to make it easy to match 710 start and stop records in a log file. The start and stop records 711 for a given session MUST have the same Acct-Session-Id. An 712 Accounting-Request packet MUST have an Acct-Session-Id. An 713 Access-Request packet MAY have an Acct-Session-Id; if it does, 714 then the NAS MUST use the same Acct-Session-Id in the Accounting- 715 Request packets for that session. 717 It is strongly recommended that the Acct-Session-Id be a printable 718 UTF-8 string. For example, one implementation uses a string with 719 an 8-digit upper case hexadecimal number, the first two digits 720 increment on each reboot (wrapping every 256 reboots) and the next 721 6 digits counting from 0 for the first person logging in after a 722 reboot up to 2^24-1, about 16 million. Other encodings are 723 possible. 725 A summary of the Acct-Session-Id attribute format is shown below. 726 The fields are transmitted from left to right. 728 0 1 2 729 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type | Length | String ... 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Type 736 44 for Acct-Session-Id. 738 Length 740 >= 3 742 String 744 The String field SHOULD be a string of printable UTF-8 characters. 746 5.6. Acct-Authentic 748 Description 750 This attribute MAY be included in an Accounting-Request to 751 indicate how the user was authenticated, whether by RADIUS, the 752 NAS itself, or another remote authentication protocol. Users who 753 are delivered service without being authenticated SHOULD NOT 754 generate Accounting records. 756 A summary of the Acct-Authentic attribute format is shown below. The 757 fields are transmitted from left to right. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type | Length | Value 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Value (cont) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Type 769 45 for Acct-Authentic. 771 Length 773 6 775 Value 777 The Value field is four octets. 779 1 RADIUS 780 2 Local 781 3 Remote 783 5.7. Acct-Session-Time 785 Description 787 This attribute indicates how many seconds the user has received 788 service for, and can only be present in Accounting-Request records 789 where the Acct-Status-Type is set to Stop. 791 A summary of the Acct-Session-Time attribute format is shown below. 792 The fields are transmitted from left to right. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Length | Value 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Value (cont) | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 Type 804 46 for Acct-Session-Time. 806 Length 808 6 810 Value 812 The Value field is four octets. 814 5.8. Acct-Input-Packets 816 Description 818 This attribute indicates how many packets have been received from 819 the port over the course of this service being provided to a 820 Framed User, and can only be present in Accounting-Request records 821 where the Acct-Status-Type is set to Stop. 823 A summary of the Acct-Input-packets attribute format is shown below. 824 The fields are transmitted from left to right. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type | Length | Value 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Value (cont) | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Type 836 47 for Acct-Input-Packets. 838 Length 840 6 842 Value 844 The Value field is four octets. 846 5.9. Acct-Output-Packets 848 Description 850 This attribute indicates how many packets have been sent to the 851 port in the course of delivering this service to a Framed User, 852 and can only be present in Accounting-Request records where the 853 Acct-Status-Type is set to Stop. 855 A summary of the Acct-Output-Packets attribute format is shown below. 856 The fields are transmitted from left to right. 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Type | Length | Value 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Value (cont) | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 Type 868 48 for Acct-Output-Packets. 870 Length 872 6 874 Value 876 The Value field is four octets. 878 5.10. Acct-Terminate-Cause 880 Description 882 This attribute indicates how the session was terminated, and can 883 only be present in Accounting-Request records where the Acct- 884 Status-Type is set to Stop. 886 A summary of the Acct-Terminate-Cause attribute format is shown 887 below. The fields are transmitted from left to right. 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type | Length | Value 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Value (cont) | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 Type 899 49 for Acct-Terminate-Cause 901 Length 903 6 905 Value 907 The Value field is four octets, containing an integer specifying 908 the cause of session termination, as follows: 910 1 User Request 911 2 Lost Carrier 912 3 Lost Service 913 4 Idle Timeout 914 5 Session Timeout 915 6 Admin Reset 916 7 Admin Reboot 917 8 Port Error 918 9 NAS Error 919 10 NAS Request 920 11 NAS Reboot 921 12 Port Unneeded 922 13 Port Preempted 923 14 Port Suspended 924 15 Service Unavailable 925 16 Callback 926 17 User Error 927 18 Host Request 929 The termination causes are as follows: 931 User Request User requested termination of service, for 932 example with LCP Terminate or by logging out. 934 Lost Carrier DCD was dropped on the port. 936 Lost Service Service can no longer be provided; for 937 example, user's connection to a host was 938 interrupted. 940 Idle Timeout Idle timer expired. 942 Session Timeout Maximum session length timer expired. 944 Admin Reset Administrator reset the port or session. 946 Admin Reboot Administrator is ending service on the NAS, 947 for example prior to rebooting the NAS. 949 Port Error NAS detected an error on the port which 950 required ending the session. 952 NAS Error NAS detected some error (other than on the 953 port) which required ending the session. 955 NAS Request NAS ended session for a non-error reason not 956 otherwise listed here. 958 NAS Reboot The NAS ended the session in order to reboot 959 non-administratively ("crash"). 961 Port Unneeded NAS ended session because resource usage fell 962 below low-water mark (for example, if a 963 bandwidth-on-demand algorithm decided that 964 the port was no longer needed). 966 Port Preempted NAS ended session in order to allocate the 967 port to a higher priority use. 969 Port Suspended NAS ended session to suspend a virtual 970 session. 972 Service Unavailable NAS was unable to provide requested service. 974 Callback NAS is terminating current session in order 975 to perform callback for a new session. 977 User Error Input from user is in error, causing 978 termination of session. 980 Host Request Login Host terminated session normally. 982 5.11. Acct-Multi-Session-Id 984 Description 986 This attribute is a unique Accounting ID to make it easy to link 987 together multiple related sessions in a log file. Each session 988 linked together would have a unique Acct-Session-Id but the same 989 Acct-Multi-Session-Id. It is strongly recommended that the Acct- 990 Multi-Session-Id be a printable UTF-8 string. 992 A summary of the Acct-Session-Id attribute format is shown below. 993 The fields are transmitted from left to right. 995 0 1 2 996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Type | Length | String ... 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Type 1002 50 for Acct-Multi-Session-Id. 1004 Length 1006 >= 3 1008 String 1010 The String field SHOULD be a string of printable UTF-8 characters. 1012 5.12. Acct-Link-Count 1014 Description 1016 This attribute gives the count of links which are known to have 1017 been in a given multilink session at the time the accounting 1018 record is generated. The NAS MAY include the Acct-Link-Count 1019 attribute in any Accounting-Request which might have multiple 1020 links. 1022 A summary of the Acct-Link-Count attribute format is show below. The 1023 fields are transmitted from left to right. 1025 0 1 2 3 1026 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 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Type | Length | Value 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 Value (cont) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Type 1035 51 for Acct-Link-Count. 1037 Length 1039 6 1041 Value 1043 The Value field is four octets, and contains the number of links 1044 seen so far in this Multilink Session. 1046 It may be used to make it easier for an accounting server to know 1047 when it has all the records for a given Multilink session. When 1048 the number of Accounting-Requests received with Acct-Status-Type = 1049 Stop and the same Acct-Multi-Session-Id and unique Acct-Session- 1050 Id's equals the largest value of Acct-Link-Count seen in those 1051 Accounting-Requests, all Stop Accounting-Requests for that 1052 Multilink Session have been received. 1054 An example showing 8 Accounting-Requests should make things 1055 clearer. For clarity only the relevant attributes are shown, but 1056 additional attributes containing accounting information will also 1057 be present in the Accounting-Request. 1059 Multi-Session-Id Session-Id Status-Type Link-Count 1060 "10" "10" Start 1 1061 "10" "11" Start 2 1062 "10" "11" Stop 2 1063 "10" "12" Start 3 1064 "10" "13" Start 4 1065 "10" "12" Stop 4 1066 "10" "13" Stop 4 1067 "10" "10" Stop 4 1069 5.13. Table of Attributes 1071 The following table provides a guide to which attributes may be found 1072 in Accounting-Request packets. No attributes should be found in 1073 Accounting-Response packets except Proxy-State and possibly Vendor- 1074 Specific. 1076 # Attribute 1077 0-1 User-Name 1078 0 User-Password 1079 0 CHAP-Password 1080 0-1 NAS-IP-Address [Note 1] 1081 0-1 NAS-Port 1082 0-1 Service-Type 1083 0-1 Framed-Protocol 1084 0-1 Framed-IP-Address 1085 0-1 Framed-IP-Netmask 1086 0-1 Framed-Routing 1087 0+ Filter-Id 1088 0-1 Framed-MTU 1089 0+ Framed-Compression 1090 0+ Login-IP-Host 1091 0-1 Login-Service 1092 0-1 Login-TCP-Port 1093 0 Reply-Message 1094 0-1 Callback-Number 1095 0-1 Callback-Id 1096 0+ Framed-Route 1097 0-1 Framed-IPX-Network 1098 0 State 1099 0+ Class 1100 0+ Vendor-Specific 1101 0-1 Session-Timeout 1102 0-1 Idle-Timeout 1103 0-1 Termination-Action 1104 0-1 Called-Station-Id 1105 0-1 Calling-Station-Id 1106 0-1 NAS-Identifier [Note 1] 1107 0+ Proxy-State 1108 0-1 Login-LAT-Service 1109 0-1 Login-LAT-Node 1110 0-1 Login-LAT-Group 1111 0-1 Framed-AppleTalk-Link 1112 0-1 Framed-AppleTalk-Network 1113 0-1 Framed-AppleTalk-Zone 1114 1 Acct-Status-Type 1115 0-1 Acct-Delay-Time 1116 0-1 Acct-Input-Octets 1117 0-1 Acct-Output-Octets 1118 1 Acct-Session-Id 1119 0-1 Acct-Authentic 1120 0-1 Acct-Session-Time 1121 0-1 Acct-Input-Packets 1122 0-1 Acct-Output-Packets 1123 0-1 Acct-Terminate-Cause 1124 0+ Acct-Multi-Session-Id 1125 0+ Acct-Link-Count 1126 0 CHAP-Challenge 1127 0-1 NAS-Port-Type 1128 0-1 Port-Limit 1129 0-1 Login-LAT-Port 1131 [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address 1132 or a NAS-Identifier (or both). 1134 The following table defines the above table entries. 1136 0 This attribute MUST NOT be present 1137 0+ Zero or more instances of this attribute MAY be present. 1138 0-1 Zero or one instance of this attribute MAY be present. 1139 1 Exactly one instance of this attribute MUST be present. 1141 6. IANA Considerations 1143 The Packet Type Codes, Attribute Types, and Attribute Values defined 1144 in this document are registered by the Internet Assigned Numbers 1145 Authority (IANA) from the RADIUS name spaces as described in the 1146 "IANA Considerations" section of RFC xxxx [2], in accordance with BCP 1147 26 [8]. 1149 7. Security Considerations 1151 Security issues are discussed in sections concerning the 1152 authenticator included in accounting requests and responses, using a 1153 shared secret which is never sent over the network. 1155 8. Change Log 1157 US-ASCII replaced by UTF-8. 1159 Added notes on Proxy. 1161 Framed-IP-Address should contain the actual IP address of the user. 1163 If Acct-Session-ID was sent in an access-request, it must be used in 1164 the accounting-request for that session. 1166 New values added to Acct-Status-Type. 1168 Added an IANA Considerations section. 1170 Updated references. 1172 9. References 1174 [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1176 [2] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote 1177 Authentication Dial In User Service (RADIUS)", RFC xxxx, 1178 February 2000. 1180 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1181 Levels." BCP14, RFC 2119, March, 1997. 1183 [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1184 1980. 1186 [5] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", 1187 RFC 1321, April 1992. 1189 [6] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1190 1700, October 1994. 1192 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1193 2279, January 1998. 1195 [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1196 Considerations Section in RFCs", BCP 26, RFC 2434, October 1197 1998. 1199 10. Acknowledgements 1201 RADIUS and RADIUS Accounting were originally developed by Steve 1202 Willens of Livingston Enterprises for their PortMaster series of 1203 Network Access Servers. 1205 11. Chair's Address 1207 The RADIUS working group can be contacted via the current chair: 1209 Carl Rigney 1210 Livingston Enterprises 1211 4464 Willow Road 1212 Pleasanton, California 94588 1214 Phone: +1 925 737 2100 1215 EMail: cdr@livingston.com 1217 12. Author's Address 1219 Questions about this memo can also be directed to: 1221 Carl Rigney 1222 Livingston Enterprises 1223 4464 Willow Road 1224 Pleasanton, California 94588 1226 EMail: cdr@livingston.com 1228 13. Full Copyright Statement 1230 Copyright (C) The Internet Society (2000). All Rights Reserved. 1232 This document and translations of it may be copied and furnished to 1233 others, and derivative works that comment on or otherwise explain it 1234 or assist in its implmentation may be prepared, copied, published and 1235 distributed, in whole or in part, without restriction of any kind, 1236 provided that the above copyright notice and this paragraph are 1237 included on all such copies and derivative works. However, this 1238 document itself may not be modified in any way, such as by removing 1239 the copyright notice or references to the Internet Society or other 1240 Internet organizations, except as needed for the purpose of 1241 developing Internet standards in which case the procedures for 1242 copyrights defined in the Internet Standards process must be 1243 followed, or as required to translate it into languages other than 1244 English. 1246 The limited permissions granted above are perpetual and will not be 1247 revoked by the Internet Society or its successors or assigns. 1249 This document and the information contained herein is provided on an 1250 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1251 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1252 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1253 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1254 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."