idnits 2.17.1 draft-ietf-radius-accounting-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '... MUST This word, or the adje...' RFC 2119 keyword, line 134: '... MUST NOT This phrase means that...' RFC 2119 keyword, line 137: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 143: '... MAY This word, or the adje...' RFC 2119 keyword, line 145: '...hich does not include this option MUST...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1996) is 10200 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) == Missing Reference: '4' is mentioned on line 994, but not defined ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group C Rigney 3 INTERNET-DRAFT Livingston 4 expires in six months May 1996 6 RADIUS Accounting 7 draft-ietf-radius-accounting-02.txt 9 Status of this Memo 11 This document is a submission to the RADIUS Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the ietf-radius@livingston.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 This document expires November 24th, 1996. 35 Abstract 37 This document describes a protocol for carrying accounting 38 information between a Network Access Server and a shared Accounting 39 Server. 41 Table of Contents 43 1. Introduction .......................................... 1 44 1.1 Specification of Requirements ................ 2 45 1.2 Terminology ..................................... 2 47 2. Operation ............................................. 3 49 3. Packet Format ......................................... 4 51 4. Packet Types .......................................... 6 52 4.1 Accounting-Request .............................. 6 53 4.2 Accounting-Response ............................. 7 55 5. Attributes ............................................ 9 56 5.1 Acct-Status-Type ................................ 10 57 5.2 Acct-Delay-Time ................................. 11 58 5.3 Acct-Input-Octets ............................... 12 59 5.4 Acct-Output-Octets .............................. 12 60 5.5 Acct-Session-Id ................................. 13 61 5.6 Acct-Authentic .................................. 14 62 5.7 Acct-Session-Time ............................... 15 63 5.8 Acct-Input-Packets .............................. 16 64 5.9 Acct-Output-Packets ............................. 16 65 5.10 Acct-Terminate-Cause ............................ 17 66 5.11 Acct-Multi-Session-Id ........................... 19 67 5.12 Table of Attributes ............................. 20 69 Security Considerations ...................................... 22 71 References ................................................... 22 73 Acknowledgements ............................................. 22 75 Chair's Address .............................................. 23 77 Author's Address ............................................. 23 79 1. Introduction 81 Managing dispersed serial line and modem pools for large numbers of 82 users can create the need for significant administrative support. 83 Since modem pools are by definition a link to the outside world, they 84 require careful attention to security, authorization and accounting. 85 This can be best achieved by managing a single "database" of users, 86 which allows for authentication (verifying user name and password) as 87 well as configuration information detailing the type of service to 88 deliver to the user (for example, SLIP, PPP, telnet, rlogin). 90 The RADIUS (Remote Authentication Dial In User Service) Internet- 91 Draft specifies the RADIUS protocol used for Authentication and 92 Authorization. This Internet-Draft extends the use of the RADIUS 93 protocol to cover delivery of accounting information from the Network 94 Access Server (NAS) to a RADIUS accounting server. 96 Key features of RADIUS Accounting are: 98 Client/Server Model 100 A Network Access Server (NAS) operates as a client of the 101 RADIUS accounting server. The client is responsible for 102 passing user accounting information to a designated RADIUS 103 accounting server. 105 The RADIUS accounting server is responsible for receiving the 106 accounting request and returning a response to the client 107 indicating that it has successfully received the request. 109 The RADIUS accounting server can act as a proxy client to other 110 kinds of accounting servers. 112 Network Security 114 Transactions between the client and RADIUS accounting server 115 are authenticated through the use of a shared secret, which is 116 never sent over the network. 118 Extensible Protocol 120 All transactions are comprised of variable length Attribute- 121 Length-Value 3-tuples. New attribute values can be added 122 without disturbing existing implementations of the protocol. 124 1.1. Specification of Requirements 126 In this document, several words are used to signify the 127 requirements of the specification. These words are often 128 capitalized. 130 MUST This word, or the adjective "required", means that the 131 definition is an absolute requirement of the 132 specification. 134 MUST NOT This phrase means that the definition is an absolute 135 prohibition of the specification. 137 SHOULD This word, or the adjective "recommended", means that 138 there may exist valid reasons in particular 139 circumstances to ignore this item, but the full 140 implications must be understood and carefully weighed 141 before choosing a different course. 143 MAY This word, or the adjective "optional", means that this 144 item is one of an allowed set of alternatives. An 145 implementation which does not include this option MUST 146 be prepared to interoperate with another implementation 147 which does include the option. 149 1.2. Terminology 151 This document uses the following terms: 153 service The NAS provides a service to the dial-in user, such as PPP 154 or Telnet. 156 session Each service provided by the NAS to a dial-in user 157 constitutes a session, with the beginning of the session 158 defined as the point where service is first provided and 159 the end of the session defined as the point where service 160 is ended. A user may have multiple sessions in parallel or 161 series if the NAS supports that, with each session 162 generating a separate start and stop accounting record with 163 its own Acct-Session-Id. 165 silently discard 166 This means the implementation discards the packet without 167 further processing. The implementation SHOULD provide the 168 capability of logging the error, including the contents of 169 the silently discarded packet, and SHOULD record the event 170 in a statistics counter. 172 2. Operation 174 When a client is configured to use RADIUS Accounting, at the start of 175 service delivery it will generate an Accounting Start packet 176 describing the type of service being delivered and the user it is 177 being delivered to, and will send that to the RADIUS Accounting 178 server, which will send back an acknowledgement that the packet has 179 been received. At the end of service delivery the client will 180 generate an Accounting Stop packet describing the type of service 181 that was delivered and optionally statistics such as elapsed time, 182 input and output octets, or input and output packets. It will send 183 that to the RADIUS Accounting server, which will send back an 184 acknowledgement that the packet has been received. 186 The Accounting-Request (whether for Start or Stop) is submitted to 187 the RADIUS accounting server via the network. It is recommended that 188 the client continue attempting to send the Accounting-Request packet 189 until it receives an acknowledgement, using some form of backoff. If 190 no response is returned within a length of time, the request is re- 191 sent a number of times. The client can also forward requests to an 192 alternate server or servers in the event that the primary server is 193 down or unreachable. An alternate server can be used either after a 194 number of tries to the primary server fail, or in a round-robin 195 fashion. Retry and fallback algorithms are the topic of current 196 research and are not specified in detail in this document. 198 The RADIUS accounting server MAY make requests of other servers in 199 order to satisfy the request, in which case it acts as a client. 201 If the RADIUS accounting server is unable to successfully record the 202 accounting packet it MUST NOT send an Accounting-Response 203 acknowledgment to the client. 205 3. Packet Format 207 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 208 field [1], where the UDP Destination Port field indicates 1646 209 (decimal). 211 When a reply is generated, the source and destination ports are 212 reversed. 214 A summary of the RADIUS data format is shown below. The fields are 215 transmitted from left to right. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Code | Identifier | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 | Authenticator | 224 | | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Attributes ... 228 +-+-+-+-+-+-+-+-+-+-+-+-+- 230 Code 232 The Code field is one octet, and identifies the type of RADIUS 233 packet. When a packet is received with an invalid Code field, it is 234 silently discarded. 236 RADIUS Accounting Codes (decimal) are assigned as follows: 238 4 Accounting-Request 239 5 Accounting-Response 241 Identifier 243 The Identifier field is one octet, and aids in matching requests and 244 replies. 246 Length 248 The Length field is two octets. It indicates the length of the 249 packet including the Code, Identifier, Length, Authenticator and 250 Attribute fields. Octets outside the range of the Length field 251 should be treated as padding and should be ignored on reception. If 252 the packet is shorter than the Length field indicates, it should be 253 silently discarded. The minimum length is 20 and maximum length is 254 4096. 256 Authenticator 258 The Authenticator field is sixteen (16) octets. The most significant 259 octet is transmitted first. This value is used to authenticate the 260 messages between the client and RADIUS accounting server. 262 Request Authenticator 264 In Accounting-Request Packets, the Authenticator value is a 16 265 octet MD5 [3] checksum, called the Request Authenticator. 267 The NAS and RADIUS accounting server share a secret. The Request 268 Authenticator field in Accounting-Request packets contains a one- 269 way MD5 hash calculated over a stream of octets consisting of the 270 Code + Identifier + Length + 16 zero octets + request attributes + 271 shared secret (where + indicates concatenation). The 16 octet MD5 272 hash value is stored in the Authenticator field of the 273 Accounting-Request packet. 275 Note that the Request Authenticator of an Accounting-Request can 276 not be done the same way as the Request Authenticator of a RADIUS 277 Access-Request, because there is no User-Password attribute in an 278 Accounting-Request. 280 Response Authenticator 282 The Authenticator field in an Accounting-Response packet is called 283 the Response Authenticator, and contains a one-way MD5 hash 284 calculated over a stream of octets consisting of the Accounting- 285 Response Code, Identifier, Length, the Request Authenticator field 286 from the Accounting-Request packet being replied to, and the response 287 attributes if any, followed by the shared secret. The resulting 16 288 octet MD5 hash value is stored in the Authenticator field of the 289 Accounting-Response packet. 291 Attributes 293 Attributes may have multiple instances, in such a case the order of 294 attributes of the same type SHOULD be preserved. The order of 295 attributes of different types is not required to be preserved. 297 4. Packet Types 299 The RADIUS packet type is determined by the Code field in the first 300 octet of the packet. 302 4.1. Accounting-Request 304 Description 306 Accounting-Request packets are sent from a client (typically a 307 Network Access Server or its proxy) to a RADIUS accounting server, 308 and convey information used to provide accounting for a service 309 provided to a user. The client transmits a RADIUS packet with the 310 Code field set to 4 (Accounting-Request). 312 Upon receipt of an Accounting-Request, the server MUST transmit an 313 Accounting-Response reply if it successfully records the 314 accounting packet, and MUST NOT transmit any reply if it fails to 315 record the accounting packet. 317 Any attribute valid in a RADIUS Access-Request or Access-Accept 318 packet is valid in a RADIUS Accounting-Request packet, except that 319 the following attributes MUST NOT be present in an Accounting- 320 Request: User-Password, CHAP-Password, Reply-Message, State. 321 Either NAS-IP-Address or NAS-Identifier MUST be present in a 322 RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- 323 Port-Type attribute or both unless the service does not involve a 324 port or the NAS does not distinguish among its ports. 326 A summary of the Accounting-Request packet format is shown below. 327 The fields are transmitted from left to right. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Code | Identifier | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 | Request Authenticator | 336 | | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Attributes ... 340 +-+-+-+-+-+-+-+-+-+-+-+-+- 341 Code 343 4 for Accounting-Request. 345 Identifier 347 The Identifier field MUST be changed whenever the content of the 348 Attributes field changes, and whenever a valid reply has been 349 received for a previous request. For retransmissions where the 350 contents are identical, the Identifier MUST remain unchanged. 352 Note that if Acct-Delay-Time is included in the attributes of an 353 Accounting-Request then the Acct-Delay-Time value will be updated 354 when the packet is retransmitted, changing the content of the 355 Attributes field and requiring a new Identifier and Request 356 Authenticator. 358 Request Authenticator 360 The Request Authenticator of an Accounting-Request contains a 16- 361 octet MD5 hash value calculated according to the method described 362 in "Request Authenticator" above. 364 Attributes 366 The Attributes field is variable in length, and contains a list of 367 Attributes. 369 4.2. Accounting-Response 371 Description 373 Accounting-Response packets are sent by the RADIUS accounting 374 server to the client to acknowledge that the Accounting-Request 375 has been received and recorded successfully. If the Accounting- 376 Request was recorded successfully then the RADIUS accounting 377 server MUST transmit a packet with the Code field set to 5 378 (Accounting-Response). On reception of an Accounting-Response by 379 the client, the Identifier field is matched with a pending 380 Accounting-Request. Invalid packets are silently discarded. 382 A RADIUS Accounting-Response is not required to have any 383 attributes in it. 385 A summary of the Accounting-Response packet format is shown below. 386 The fields are transmitted from left to right. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Code | Identifier | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 | Response Authenticator | 395 | | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Attributes ... 399 +-+-+-+-+-+-+-+-+-+-+-+-+- 401 Code 403 5 for Accounting-Response. 405 Identifier 407 The Identifier field is a copy of the Identifier field of the 408 Accounting-Request which caused this Accounting-Response. 410 Response Authenticator 412 The Response Authenticator of an Accounting-Response contains a 413 16-octet MD5 hash value calculated according to the method 414 described in "Response Authenticator" above. 416 Attributes 418 The Attributes field is variable in length, and contains a list of 419 zero or more Attributes. 421 5. Attributes 423 RADIUS Attributes carry the specific authentication, authorization 424 and accounting details for the request and response. 426 Some attributes MAY be included more than once. The effect of this 427 is attribute specific, and is specified in each attribute 428 description. 430 The end of the list of attributes is indicated by the Length of the 431 RADIUS packet. 433 A summary of the attribute format is shown below. The fields are 434 transmitted from left to right. 436 0 1 2 437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | Value ... 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Type 444 The Type field is one octet. Up-to-date values of the RADIUS Type 445 field are specified in the most recent "Assigned Numbers" RFC [2]. 446 Values 192-223 are reserved for experimental use, values 224-240 447 are reserved for implementation-specific use, and values 241-255 448 are reserved and should not be used. This specification concerns 449 the following values: 451 1-39 (refer to RADIUS Internet-Draft) 452 40 Acct-Status-Type 453 41 Acct-Delay-Time 454 42 Acct-Input-Octets 455 43 Acct-Output-Octets 456 44 Acct-Session-Id 457 45 Acct-Authentic 458 46 Acct-Session-Time 459 47 Acct-Input-Packets 460 48 Acct-Output-Packets 461 49 Acct-Terminate-Cause 462 50 Acct-Multi-Session-Id 463 60+ (refer to RADIUS Internet-Draft) 465 Length 467 The Length field is one octet, and indicates the length of this 468 attribute including the Type, Length and Value fields. If an 469 attribute is received in an Accounting-Request with an invalid 470 Length, the entire request should be silently discarded. 472 Value 474 The Value field is zero or more octets and contains information 475 specific to the attribute. The format and length of the Value 476 field is determined by the Type and Length fields. 478 The format of the value field is one of four data types. 480 string 0-253 octets 482 address 32 bit value, most significant octet first. 484 integer 32 bit value, most significant octet first. 486 time 32 bit value, most significant octet first -- seconds 487 since 00:00:00 GMT, January 1, 1970. The standard 488 Attributes do not use this data type but it is presented 489 here for possible use within Vendor-Specific attributes. 491 5.1. Acct-Status-Type 493 Description 495 This attribute indicates whether this Accounting-Request marks the 496 beginning of the user service (Start) or the end (Stop). 498 It MAY be used by the client to mark the start of accounting (for 499 example, upon booting) by specifying Accounting-On and to mark the 500 end of accounting (for example, just before a scheduled reboot) by 501 specifying Accounting-Off. 503 A summary of the Acct-Status-Type attribute format is shown below. 504 The fields are transmitted from left to right. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length | Value 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Value (cont) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Type 515 40 for Acct-Status-Type. 517 Length 519 6 521 Value 523 The Value field is four octets. 525 1 Start 526 2 Stop 527 7 Accounting-On 528 8 Accounting-Off 530 5.2. Acct-Delay-Time 532 Description 534 This attribute indicates how many seconds the client has been 535 trying to send this record for, and can be subtracted from the 536 time of arrival on the server to find the approximate time of the 537 event generating this Accounting-Request. (Network transit time 538 is ignored.) 540 Note that changing the Acct-Delay-Time causes the Identifier to 541 change; see the discussion under Identifier above. 543 A summary of the Acct-Delay-Time attribute format is shown below. 544 The fields are transmitted from left to right. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Length | Value 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Value (cont) | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Type 556 41 for Acct-Delay-Time. 558 Length 560 6 562 Value 564 The Value field is four octets. 566 5.3. Acct-Input-Octets 568 Description 570 This attribute indicates how many octets have been received from 571 the port over the course of this service being provided, and can 572 only be present in Accounting-Request records where the Acct- 573 Status-Type is set to Stop. 575 A summary of the Acct-Input-Octets attribute format is shown below. 576 The fields are transmitted from left to right. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type | Length | Value 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Value (cont) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Type 588 42 for Acct-Input-Octets. 590 Length 592 6 594 Value 596 The Value field is four octets. 598 5.4. Acct-Output-Octets 600 Description 601 This attribute indicates how many octets have been sent to the 602 port in the course of delivering this service, and can only be 603 present in Accounting-Request records where the Acct-Status-Type 604 is set to Stop. 606 A summary of the Acct-Output-Octets attribute format is shown below. 607 The fields are transmitted from left to right. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Type | Length | Value 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Value (cont) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Type 619 43 for Acct-Output-Octets. 621 Length 623 6 625 Value 627 The Value field is four octets. 629 5.5. Acct-Session-Id 631 Description 633 This attribute is a unique Accounting ID to make it easy to match 634 start and stop records in a log file. The start and stop records 635 for a given session MUST have the same Acct-Session-Id. It is 636 strongly recommended that the Acct-Session-Id be a printable ASCII 637 string. 639 For example, one implementation uses a string with an 8-digit 640 upper case hexadecimal number, the first two digits increment on 641 each reboot (wrapping every 256 reboots) and the next 6 digits 642 counting from 0 for the first person logging in after a reboot up 643 to 2^24-1, about 16 million. Other encodings are possible. 645 A summary of the Acct-Session-Id attribute format is shown below. 647 The fields are transmitted from left to right. 649 0 1 2 650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Type | Length | String ... 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Type 657 44 for Acct-Session-Id. 659 Length 661 >= 3 663 String 665 The String field SHOULD be a string of printable ASCII characters. 667 5.6. Acct-Authentic 669 Description 671 This attribute MAY be included in an Accounting-Request to 672 indicate how the user was authenticated, whether by RADIUS, the 673 NAS itself, or another remote authentication protocol. Users who 674 are delivered service without being authenticated SHOULD NOT 675 generate Accounting records. 677 A summary of the Acct-Authentic attribute format is shown below. The 678 fields are transmitted from left to right. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | Value 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Value (cont) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Type 690 45 for Acct-Authentic. 692 Length 694 6 696 Value 698 The Value field is four octets. 700 1 RADIUS 701 2 Local 702 3 Remote 704 5.7. Acct-Session-Time 706 Description 708 This attribute indicates how many seconds the user has received 709 service for, and can only be present in Accounting-Request records 710 where the Acct-Status-Type is set to Stop. 712 A summary of the Acct-Session-Time attribute format is shown below. 713 The fields are transmitted from left to right. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | Value 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Value (cont) | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Type 725 46 for Acct-Session-Time. 727 Length 729 6 731 Value 733 The Value field is four octets. 735 5.8. Acct-Input-Packets 737 Description 739 This attribute indicates how many packets have been received from 740 the port over the course of this service being provided to a 741 Framed User, and can only be present in Accounting-Request records 742 where the Acct-Status-Type is set to Stop. 744 A summary of the Acct-Input-packets attribute format is shown below. 745 The fields are transmitted from left to right. 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Type | Length | Value 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Value (cont) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Type 757 47 for Acct-Input-Packets. 759 Length 761 6 763 Value 765 The Value field is four octets. 767 5.9. Acct-Output-Packets 769 Description 771 This attribute indicates how many packets have been sent to the 772 port in the course of delivering this service to a Framed User, 773 and can only be present in Accounting-Request records where the 774 Acct-Status-Type is set to Stop. 776 A summary of the Acct-Output-Packets attribute format is shown below. 777 The fields are transmitted from left to right. 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type | Length | Value 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Value (cont) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Type 789 48 for Acct-Output-Packets. 791 Length 793 6 795 Value 797 The Value field is four octets. 799 5.10. Acct-Terminate-Cause 801 Description 803 This attribute indicates how the session was terminated, and can 804 only be present in Accounting-Request records where the Acct- 805 Status-Type is set to Stop. 807 A summary of the Acct-Terminate-Cause attribute format is shown 808 below. The fields are transmitted from left to right. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type | Length | Value 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Value (cont) | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Type 820 49 for Acct-Terminate-Cause 822 Length 824 6 826 Value 828 The Value field is four octets, containing an integer specifying 829 the cause of session termination, as follows: 831 1 User Request 832 2 Lost Carrier 833 3 Lost Service 834 4 Idle Timeout 835 5 Session Timeout 836 6 Admin Reset 837 7 Admin Reboot 838 8 Port Error 839 9 NAS Error 840 10 NAS Request 841 11 NAS Reboot 842 12 Port Unneeded 843 13 Port Preempted 844 14 Port Suspended 845 15 Service Unavailable 846 16 Callback 847 17 User Error 848 18 Host Request 850 The termination causes are as follows: 852 User Request User requested termination of service, for 853 example with LCP Terminate or by logging out. 855 Lost Carrier DCD was dropped on the port. 857 Lost Service Service can no longer be provided; for 858 example, user's connection to a host was 859 interrupted. 861 Idle Timeout Idle timer expired. 863 Session Timeout Maximum session length timer expired. 865 Admin Reset Administrator reset the port or session. 867 Admin Reboot Administrator is ending service on the NAS, 868 for example prior to rebooting the NAS. 870 Port Error NAS detected an error on the port which 871 required ending the session. 873 NAS Error NAS detected some error (other than on the 874 port) which required ending the session. 876 NAS Request NAS ended session for a non-error reason not 877 otherwise listed here. 879 NAS Reboot The NAS ended the session in order to reboot 880 non-administratively ("crash"). 882 Port Unneeded NAS ended session because resource usage fell 883 below low-water mark (for example, if a 884 bandwidth-on-demand algorithm decided that 885 the port was no longer needed). 887 Port Preempted NAS ended session in order to allocate the 888 port to a higher priority use. 890 Port Suspended NAS ended session to suspend a virtual 891 session. 893 Service Unavailable NAS was unable to provide requested service. 895 Callback NAS is terminating current session in order 896 to perform callback for a new session. 898 User Error Input from user is in error, causing 899 termination of session. 901 Host Request Login Host terminated session normally. 903 5.11. Acct-Multi-Session-Id 905 Description 907 This attribute is a unique Accounting ID to make it easy to link 908 together multiple related sessions in a log file. Each session 909 linked together would have a unique Acct-Session-Id but the same 910 Acct-Multi-Session-Id. It is strongly recommended that the Acct- 911 Multi-Session-Id be a printable ASCII string. 913 A summary of the Acct-Session-Id attribute format is shown below. 914 The fields are transmitted from left to right. 916 0 1 2 917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type | Length | String ... 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Type 924 50 for Acct-Multi-Session-Id. 926 Length 928 >= 3 930 String 932 The String field SHOULD be a string of printable ASCII characters. 934 5.12. Table of Attributes 936 The following table provides a guide to which attributes may be found 937 in Accounting-Request packets. No attributes should be found in 938 Accounting-Response packets (except possibly for Vendor-Specific). 940 # Attribute 941 0-1 User-Name 942 0 User-Password 943 0 CHAP-Password 944 0-1 NAS-IP-Address [4] 945 0-1 NAS-Port 946 0-1 Service-Type 947 0-1 Framed-Protocol 948 0-1 Framed-IP-Address 949 0-1 Framed-IP-Netmask 950 0-1 Framed-Routing 951 0+ Filter-Id 952 0-1 Framed-MTU 953 0+ Framed-Compression 954 0+ Login-IP-Host 955 0-1 Login-Service 956 0-1 Login-TCP-Port 957 0 Reply-Message 958 0-1 Callback-Number 959 0-1 Callback-Id 960 0+ Framed-Route 961 0-1 Framed-IPX-Network 962 0 State 963 0+ Class 964 0+ Vendor-Specific 965 0-1 Session-Timeout 966 0-1 Idle-Timeout 967 0-1 Termination-Action 968 0-1 Called-Station-Id 969 0-1 Calling-Station-Id 970 0-1 NAS-Identifier [4] 971 0+ Proxy-State 972 0-1 Login-LAT-Service 973 0-1 Login-LAT-Node 974 0-1 Login-LAT-Group 975 0-1 Framed-AppleTalk-Link 976 0-1 Framed-AppleTalk-Network 977 0-1 Framed-AppleTalk-Zone 978 1 Acct-Status-Type 979 0-1 Acct-Delay-Time 980 0-1 Acct-Input-Octets 981 0-1 Acct-Output-Octets 982 1 Acct-Session-Id 983 0-1 Acct-Authentic 984 0-1 Acct-Session-Time 985 0-1 Acct-Input-Packets 986 0-1 Acct-Output-Packets 987 0-1 Acct-Terminate-Cause 988 0+ Acct-Multi-Session-Id 989 0 CHAP-Challenge 990 0-1 NAS-Port-Type 991 0-1 Port-Limit 992 0-1 Login-LAT-Port 994 [4] An Accounting-Request MUST contain either a NAS-IP-Address or a 995 NAS-Identifier, and it is permitted (but not recommended) for it to 996 contain both. 998 The following table defines the above table entries. 1000 0 This attribute MUST NOT be present 1001 0+ Zero or more instances of this attribute MAY be present. 1002 0-1 Zero or one instance of this attribute MAY be present. 1003 1 Exactly one instance of this attribute MUST be present. 1005 Security Considerations 1007 Security issues are briefly discussed in sections concerning the 1008 authenticator included in accounting requests and responses, using a 1009 shared secret which is never sent over the network. 1011 References 1013 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1014 USC/Information Sciences Institute, August 1980. 1016 [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1017 1700, USC/Information Sciences Institute, October 1994. 1019 [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 1020 RFC 1321, MIT Laboratory for Computer Science, RSA Data 1021 Security Inc., April 1992. 1023 Acknowledgments 1025 RADIUS and RADIUS Accounting were originally developed by Livingston 1026 Enterprises for their PortMaster series of Network Access Servers. 1028 Chair's Address 1030 The RADIUS working group can be contacted via the current chair: 1032 Carl Rigney 1033 Livingston Enterprises 1034 6920 Koll Center Parkway, Suite 220 1035 Pleasanton, California 94566 1037 Phone: +1 510 426 0770 1038 E-Mail: cdr@livingston.com 1040 Author's Address 1042 Questions about this memo can also be directed to: 1044 Carl Rigney 1045 Livingston Enterprises 1046 6920 Koll Center Parkway, Suite 220 1047 Pleasanton, California 94566 1049 E-Mail: cdr@livingston.com 1051 This document expires November 24th, 1996.