idnits 2.17.1 draft-ietf-radius-accounting-01.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-19) 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 134: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 137: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 140: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 146: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 148: '...h does not include this option MUST be...' (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 (November 1995) is 10383 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 958, 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 November 1995 6 RADIUS Accounting 7 draft-ietf-radius-accounting-01.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 May 31st, 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 ............................................. 4 49 3. Packet Format ......................................... 5 51 4. Packet Types .......................................... 8 52 4.1 Accounting-Request .............................. 8 53 4.2 Accounting-Response ............................. 10 55 5. Attributes ............................................ 12 56 5.1 Acct-Status-Type ................................ 13 57 5.2 Acct-Delay-Time ................................. 14 58 5.3 Acct-Input-Octets ............................... 15 59 5.4 Acct-Output-Octets .............................. 15 60 5.5 Acct-Session-Id ................................. 16 61 5.6 Acct-Authentic .................................. 17 62 5.7 Acct-Session-Time ............................... 18 63 5.8 Acct-Input-Packets .............................. 19 64 5.9 Acct-Output-Packets ............................. 19 65 5.10 Acct-Terminate-Cause ............................ 20 66 5.11 Table of Attributes ............................. 22 68 Security Considerations ...................................... 24 70 References ................................................... 24 72 Acknowledgements ............................................. 24 74 Chair's Address .............................................. 25 76 Author's Address ............................................. 25 78 1. Introduction 80 Managing dispersed serial line and modem pools for large numbers of 81 users can create the need for significant administrative support. 82 Since modem pools are by definition a link to the outside world, they 83 require careful attention to security, authorization and accounting. 84 This can be best achieved by managing a single "database" of users, 85 which allows for authentication (verifying user name and password) as 86 well as configuration information detailing the type of service to 87 deliver to the user (for example, SLIP, PPP, telnet, rlogin). 89 The RADIUS (Remote Authentication Dial In User Service) Internet- 90 Draft specifies the RADIUS protocol used for Authentication and 91 Authorization. This Internet-Draft extends the use of the RADIUS 92 protocol to cover delivery of accounting information from the Network 93 Access Server (NAS) to a RADIUS accounting server. 95 Key features of RADIUS Accounting are: 97 Client/Server Model 99 A Network Access Server (NAS) operates as a client of the 100 RADIUS accounting server. The client is responsible for 101 passing user accounting information to a designated RADIUS 102 accounting server. 104 The RADIUS accounting server is responsible for receiving the 105 accounting request and returning a response to the client 106 indicating that it has successfully received the request. 108 The RADIUS accounting server can act as a proxy client to other 109 kinds of accounting servers. 111 Network Security 113 Transactions between the client and RADIUS accounting server 114 are authenticated through the use of a shared secret, which is 115 never sent over the network. 117 Extensible Protocol 119 All transactions are comprised of variable length Attribute- 120 Length-Value 3-tuples. New attribute values can be added 121 without disturbing existing implementations of the protocol. 123 Source Code Availability 125 Livingston Enterprises is making the C source code for an example 126 RADIUS accounting server available without use restrictions. 127 Other companies have also implemented RADIUS Accounting. 129 1.1. Specification of Requirements 131 In this document, several words are used to signify the requirements 132 of the specification. These words are often capitalized. 134 MUST This word, or the adjective "required", means that the 135 definition is an absolute requirement of the specification. 137 MUST NOT This phrase means that the definition is an absolute 138 prohibition of the specification. 140 SHOULD This word, or the adjective "recommended", means that there 141 may exist valid reasons in particular circumstances to 142 ignore this item, but the full implications must be 143 understood and carefully weighed before choosing a 144 different course. 146 MAY This word, or the adjective "optional", means that this 147 item is one of an allowed set of alternatives. An 148 implementation which does not include this option MUST be 149 prepared to interoperate with another implementation which 150 does include the option. 152 1.2. Terminology 154 This document uses the following terms: 156 service The NAS provides a service to the dial-in user, such as PPP 157 or Telnet. 159 session Each service provided by the NAS to a dial-in user 160 constitutes a session, with the beginning of the session 161 defined as the point where service is first provided and 162 the end of the session defined as the point where service 163 is ended. A user may have multiple sessions in parallel or 164 series if the NAS supports that, with each session 165 generating a separate start and stop accounting record. 167 silently discard 168 This means the implementation discards the packet without 169 further processing. The implementation SHOULD provide the 170 capability of logging the error, including the contents of 171 the silently discarded packet, and SHOULD record the event 172 in a statistics counter. 174 2. Operation 176 When a client is configured to use RADIUS Accounting, at the start of 177 service delivery it will generate an Accounting Start packet 178 describing the type of service being delivered and the user it is 179 being delivered to, and will send that to the RADIUS Accounting 180 server, which will send back an acknowledgement that the packet has 181 been received. At the end of service delivery the client will 182 generate an Accounting Stop packet describing the type of service 183 that was delivered and optionally statistics such as elapsed time, 184 input and output octets, or input and output packets. It will send 185 that to the RADIUS Accounting server, which will send back an 186 acknowledgement that the packet has been received. 188 The Accounting-Request (whether for Start or Stop) is submitted to 189 the RADIUS accounting server via the network. If no response is 190 returned within a length of time, the request is re-sent a number of 191 times. The client can also forward requests to an alternate server 192 or servers in the event that the primary server is down or 193 unreachable. An alternate server can be used either after a number 194 of tries to the primary server fail, or in a round-robin fashion. 195 Retry and fallback algorithms are the topic of current research and 196 are not specified in detail in this document. 198 It is recommended that the client continue attempting to send the 199 Accounting packet until it receives an acknowledgement, using some 200 form of backoff. It MAY elect to send the packet to an alternate 201 accounting server. The nature of the timeout algorithms to be used 202 are the topic of current research, and are not further specified 203 here. 205 The RADIUS accounting server MAY make requests of other servers in 206 order to satisfy the request, in which case it acts as a client. 208 If the RADIUS accounting server is unable to successfully record the 209 accounting packet it MUST NOT send an Accounting-Response 210 acknowledgment to the client. 212 3. Packet Format 214 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 215 field [1], where the UDP Destination Port field indicates 1646 216 (decimal). 218 When a reply is generated, the source and destination ports are 219 reversed. 221 A summary of the RADIUS data format is shown below. The fields are 222 transmitted from left to right. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Code | Identifier | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 | Authenticator | 231 | | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Attributes ... 235 +-+-+-+-+-+-+-+-+-+-+-+-+- 237 Code 239 The Code field is one octet, and identifies the type of RADIUS 240 packet. When a packet is received with an invalid Code field, it is 241 silently discarded. 243 RADIUS Accounting Codes (decimal) are assigned as follows: 245 4 Accounting-Request 246 5 Accounting-Response 248 Identifier 250 The Identifier field is one octet, and aids in matching requests and 251 replies. 253 Length 255 The Length field is two octets. It indicates the length of the 256 packet including the Code, Identifier, Length, Authenticator and 257 Attribute fields. Octets outside the range of the Length field 258 should be treated as padding and should be ignored on reception. If 259 the packet is shorter than the Length field indicates, it should be 260 silently discarded. The minimum length is 20 and maximum length is 261 4096. 263 Authenticator 265 The Authenticator field is sixteen (16) octets. The most significant 266 octet is transmitted first. This value is used to authenticate the 267 messages between the client and RADIUS accounting server. 269 Request Authenticator 271 In Accounting-Request Packets, the Authenticator value is a 16 272 octet MD5 [3] checksum. 274 The NAS and RADIUS accounting server share a secret. The 275 Authenticator field in Accounting-Request packets contains a one- 276 way MD5 hash calculated over a stream of octets consisting of the 277 Code + Identifier + Length + 16 zero octets + request attributes + 278 shared secret (where + indicates concatenation). The 16 octet MD5 279 hash value is stored in the Authenticator field of the 280 Accounting-Request packet. 282 Note that the Request Authenticator of an Accounting-Request can 283 not be done the same way as the Request Authenticator of a RADIUS 284 Access-Request, because there is no User-Password attribute in an 285 Accounting-Request. 287 [Draft Note - the implementation of RADIUS Accounting in 288 Livingston's ComOS 3.1 through 3.1.4 sets the Request 289 Authenticator to all 0's. A future release will implement the 290 method described here, after which this Note will be removed 291 from the Draft.] 293 Response Authenticator 295 The Authenticator field in an Accounting-Response packet contains 296 a one-way MD5 hash calculated over a stream of octets consisting 297 of the Accounting-Response Code, Identifier, Length, the 298 Authenticator field from the Accounting-Request packet being 299 replied to, and the response attributes if any, followed by the 300 shared secret. The resulting 16 octet MD5 hash value is stored in 301 the Authenticator field of the Accounting-Response packet. 303 Attributes 305 Attributes may have multiple instances, in such a case the order of 306 attributes of the same type SHOULD be preserved. The order of 307 attributes of different types is not required to be preserved. 309 4. Packet Types 311 The RADIUS packet type is determined by the Code field in the first 312 octet of the packet. 314 4.1. Accounting-Request 316 Description 318 Accounting-Request packets are sent from a client (typically a 319 Network Access Server or its proxy) to a RADIUS accounting server, 320 and convey information used to provide accounting for a service 321 provided to a user. The client transmits a RADIUS packet with the 322 Code field set to 4 (Accounting-Request). 324 Upon receipt of an Accounting-Request, the server MUST transmit an 325 Accounting-Response reply if it successfully records the 326 accounting packet, and MUST NOT transmit any reply if it fails to 327 record the accounting packet. 329 Any attribute valid in a RADIUS Access-Request or Access-Accept 330 packet is valid in a RADIUS Accounting-Request packet, except that 331 the following attributes MUST NOT be present in an Accounting- 332 Request: User-Password, CHAP-Password, Reply-Message, State. 334 Either NAS-IP-Address or NAS-Identifier MUST be present in a 335 RADIUS Accounting-Request. 337 It SHOULD contain a NAS-Port or NAS-Port-Id attribute unless the 338 service does not involve a port or the NAS does not distinguish 339 among its ports. 341 A summary of the Accounting-Request packet format is shown below. 342 The fields are transmitted from left to right. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Code | Identifier | Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 | Authenticator | 351 | | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Attributes ... 355 +-+-+-+-+-+-+-+-+-+-+-+-+- 357 Code 359 4 for Accounting-Request. 361 Identifier 363 The Identifier field MUST be changed whenever the content of the 364 Attributes field changes, and whenever a valid reply has been 365 received for a previous request. For retransmissions where the 366 contents are identical, the Identifier MUST remain unchanged. 368 Note that if Acct-Delay-Time is included in the attributes of an 369 Accounting-Request then the Acct-Delay-Time value will be updated 370 when the packet is retransmitted, changing the content of the 371 Attributes field and requiring a new Identifier and Request 372 Authenticator. 374 Authenticator 376 The Authenticator of an Accounting-Request contains a 16-octet MD5 377 hash value calculated according to the method described in 378 "Request Authenticator", above. 380 [Draft Note - the implementation of RADIUS Accounting in 381 Livingston's ComOS 3.1 through 3.1.4 sets the Request 382 Authenticator to all 0's. A future release will implement the 383 method described here, after which this Note will be removed 384 from the Draft.] 386 Attributes 388 The Attributes field is variable in length, and contains a list of 389 Attributes. 391 4.2. Accounting-Response 393 Description 395 Accounting-Response packets are sent by the RADIUS accounting 396 server to the client to acknowledge that the Accounting-Request 397 has been received and recorded successfully. 399 If the Accounting-Request was recorded successfully then the 400 RADIUS accounting server MUST transmit a packet with the Code 401 field set to 5 (Accounting-Response). 403 A RADIUS Accounting-Response is not required to have any 404 attributes in it. 406 On reception of an Accounting-Response by the client, the 407 Identifier field is matched with a pending Accounting-Request. 408 Invalid packets are silently discarded. 410 A summary of the Accounting-Response packet format is shown below. 411 The fields are transmitted from left to right. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Code | Identifier | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 | Authenticator | 420 | | 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Attributes ... 424 +-+-+-+-+-+-+-+-+-+-+-+-+- 426 Code 428 5 for Accounting-Response. 430 Identifier 432 The Identifier field is a copy of the Identifier field of the 433 Accounting-Request which caused this Accounting-Response. 435 Authenticator 437 The Authenticator of an Accounting-Response contains a 16-octet 438 MD5 hash value calculated according to the method described in 439 "Response Authenticator", above. 441 Attributes 443 The Attributes field is variable in length, and contains a list of 444 zero or more Attributes. 446 5. Attributes 448 RADIUS Attributes carry the specific authentication, authorization 449 and accounting details for the request and response. 451 Some attributes MAY be included more than once. The effect of this 452 is attribute specific, and is specified in each attribute 453 description. 455 The end of the list of attributes is indicated by the Length of the 456 RADIUS packet. 458 A summary of the attribute format is shown below. The fields are 459 transmitted from left to right. 461 0 1 2 462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | Value ... 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Type 469 The Type field is one octet. Up-to-date values of the RADIUS Type 470 field are specified in the most recent "Assigned Numbers" RFC [2]. 471 Values 192-223 are reserved for experimental use, values 224-240 472 are reserved for implementation-specific use, and values 241-255 473 are reserved and should not be used. This specification concerns 474 the following values: 476 1-39 (refer to RADIUS Internet-Draft) 477 40 Acct-Status-Type 478 41 Acct-Delay-Time 479 42 Acct-Input-Octets 480 43 Acct-Output-Octets 481 44 Acct-Session-Id 482 45 Acct-Authentic 483 46 Acct-Session-Time 484 47 Acct-Input-Packets 485 48 Acct-Output-Packets 486 49 Acct-Termination-Cause 487 60+ (refer to RADIUS Internet-Draft) 489 Length 491 The Length field is one octet, and indicates the length of this 492 attribute including the Type, Length and Value fields. If an 493 attribute is received in an Accounting-Request with an invalid 494 Length, the entire request should be silently discarded. 496 Value 498 The Value field is zero or more octets and contains information 499 specific to the attribute. The format and length of the Value 500 field is determined by the Type and Length fields. 502 The format of the value field is one of four data types. 504 string 0-253 octets 506 address 32 bit value, most significant octet first. 508 integer 32 bit value, most significant octet first. 510 time 32 bit value, most significant octet first -- seconds 511 since 00:00:00 GMT, January 1, 1970. The standard 512 Attributes do not use this data type but it is presented 513 here for possible use within Vendor-Specific attributes. 515 5.1. Acct-Status-Type 517 Description 519 This attribute indicates whether this Accounting-Request marks the 520 beginning of the user service (Start) or the end (Stop). 522 It MAY also be used by the client to mark the start of accounting 523 (for example, upon booting) by specifying Accounting-On and to 524 mark the end of accounting (for example, just before a scheduled 525 reboot) by specifying Accounting-Off. 527 A summary of the Acct-Status-Type attribute format is shown below. 528 The fields are transmitted from left to right. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type | Length | Value 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Value (cont) | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Type 539 40 for Acct-Status-Type. 541 Length 543 6 545 Value 547 The Value field is four octets. 549 1 Start 550 2 Stop 551 3 Accounting-On 552 4 Accounting-Off 554 5.2. Acct-Delay-Time 556 Description 558 This attribute indicates how many seconds the client has been 559 trying to send this record for, and can be subtracted from the 560 time of arrival on the server to find the approximate time of the 561 event generating this Accounting-Request. (Network transit time 562 is ignored.) 564 Note that changing the Acct-Delay-Time causes the Identifier to 565 change; see the discussion under Identifier above. 567 A summary of the Acct-Delay-Time attribute format is shown below. 568 The fields are transmitted from left to right. 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type | Length | Value 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Value (cont) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Type 580 41 for Acct-Delay-Time. 582 Length 584 6 586 Value 588 The Value field is four octets. 590 5.3. Acct-Input-Octets 592 Description 594 This attribute indicates how many octets have been received from 595 the port over the course of this service being provided, and can 596 only be present in Accounting-Request records where the Acct- 597 Status-Type is set to Stop. 599 A summary of the Acct-Input-Octets attribute format is shown below. 600 The fields are transmitted from left to right. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Type | Length | Value 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Value (cont) | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Type 612 42 for Acct-Input-Octets. 614 Length 616 6 618 Value 620 The Value field is four octets. 622 5.4. Acct-Output-Octets 624 Description 625 This attribute indicates how many octets have been sent to the 626 port in the course of delivering this service, and can only be 627 present in Accounting-Request records where the Acct-Status-Type 628 is set to Stop. 630 A summary of the Acct-Output-Octets attribute format is shown below. 631 The fields are transmitted from left to right. 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Type | Length | Value 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Value (cont) | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Type 643 43 for Acct-Output-Octets. 645 Length 647 6 649 Value 651 The Value field is four octets. 653 5.5. Acct-Session-Id 655 Description 657 This attribute is a unique Accounting ID to make it easy to match 658 start and stop records in a log file. The start and stop records 659 for a given session MUST have the same Acct-Session-Id. It is 660 strongly recommended that the Acct-Session-Id be a printable ASCII 661 string. 663 For example, one implementation uses a string with an 8-digit 664 uppercase hexadecimal number, the first two digits increment on 665 each reboot (wrapping every 256 reboots) and the next 6 digits 666 counting from 0 for the first person logging in after a reboot up 667 to 2^24-1, about 16 million. Other encodings are possible. 669 A summary of the Acct-Session-Id attribute format is shown below. 671 The fields are transmitted from left to right. 673 0 1 2 674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Type | Length | String ... 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Type 681 44 for Acct-Session-Id. 683 Length 685 >= 3 687 String 689 The String field SHOULD be a string of printable ASCII characters. 691 5.6. Acct-Authentic 693 Description 695 This attribute MAY be included in an Accounting-Request to 696 indicate how the user was authenticated, whether by RADIUS, the 697 NAS itself, or another remote authentication protocol. Users who 698 are delivered service without being authenticated SHOULD NOT 699 generate Accounting records. 701 A summary of the Acct-Authentic attribute format is shown below. The 702 fields are transmitted from left to right. 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type | Length | Value 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Value (cont) | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Type 714 45 for Acct-Authentic. 716 Length 718 6 720 Value 722 The Value field is four octets. 724 1 RADIUS 725 2 Local 726 3 Remote 728 5.7. Acct-Session-Time 730 Description 732 This attribute indicates how many seconds the user has received 733 service for, and can only be present in Accounting-Request records 734 where the Acct-Status-Type is set to Stop. 736 A summary of the Acct-Session-Time attribute format is shown below. 737 The fields are transmitted from left to right. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type | Length | Value 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Value (cont) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Type 749 46 for Acct-Session-Time. 751 Length 753 6 755 Value 757 The Value field is four octets. 759 5.8. Acct-Input-Packets 761 Description 763 This attribute indicates how many packets have been received from 764 the port over the course of this service being provided to a 765 Framed User, and can only be present in Accounting-Request records 766 where the Acct-Status-Type is set to Stop. 768 A summary of the Acct-Input-packets attribute format is shown below. 769 The fields are transmitted from left to right. 771 0 1 2 3 772 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 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Type | Length | Value 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Value (cont) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Type 781 47 for Acct-Input-Packets. 783 Length 785 6 787 Value 789 The Value field is four octets. 791 5.9. Acct-Output-Packets 793 Description 795 This attribute indicates how many packets have been sent to the 796 port in the course of delivering this service to a Framed User, 797 and can only be present in Accounting-Request records where the 798 Acct-Status-Type is set to Stop. 800 A summary of the Acct-Output-Packets attribute format is shown below. 801 The fields are transmitted from left to right. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type | Length | Value 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Value (cont) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Type 813 48 for Acct-Output-Packets. 815 Length 817 6 819 Value 821 The Value field is four octets. 823 5.10. Acct-Terminate-Cause 825 Description 827 This attribute indicates how the session was terminated, and can 828 only be present in Accounting-Request records where the Acct- 829 Status-Type is set to Stop. 831 A summary of the Acct-Terminate-Cause attribute format is shown 832 below. The fields are transmitted from left to right. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Type | Length | Value 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Value (cont) | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Type 844 49 for Acct-Terminate-Cause 846 Length 848 6 850 Value 852 The Value field is four octets, containing an integer specifying 853 the cause of session termination, as follows: 855 1 User Request 856 2 Lost Carrier 857 3 Lost Service 858 4 Idle Timeout 859 5 Session Timeout 860 6 Admin Reset 861 7 Admin Reboot 862 8 Port Error 863 9 NAS Error 864 10 NAS Request 866 [Draft Note - These values are the topic of current research 867 and discussion and may change by the next draft depending on 868 implementation experience. Please contact the document editor 869 for an updated list.] 871 The termination causes are as follows: 873 User Request User requested termination of service, for 874 example with LCP Terminate or by logging out. 876 Lost Carrier DCD was dropped on the port. 878 Lost Service Service can no longer be provided; for example, 879 user's connection to a host was interrupted. 881 Idle Timeout Idle timer expired. 883 Session Timeout Maximum Session length timer expired. 885 Admin Reset Administrator reset the port or session. 887 Admin Reboot Administrator is ending service on the NAS, for 888 example prior to bringing the NAS down. 890 Port Error NAS detected an error on the port which required 891 ending the session. 893 NAS Error NAS detected some error (other than on the port) 894 which required ending the session. 896 NAS Request NAS ended session for a reason other than the 897 above. For example, a low-water mark may have 898 been reached or a resource-limit exceeded. 900 5.11. Table of Attributes 902 The following table provides a guide to which attributes may be found 903 in Accounting-Request packets. No attributes should be found in 904 Accounting-Response packets (except possibly for Vendor-Specific). 906 # Attribute 907 0-1 User-Name 908 0 User-Password 909 0 CHAP-Password 910 0-1 NAS-IP-Address [4] 911 0-1 NAS-Port 912 0-1 Service-Type 913 0-1 Framed-Protocol 914 0-1 Framed-IP-Address 915 0-1 Framed-IP-Netmask 916 0-1 Framed-Routing 917 0+ Filter-Id 918 0-1 Framed-MTU 919 0+ Framed-Compression 920 0+ Login-IP-Host 921 0-1 Login-Service 922 0-1 Login-Port 923 0 Reply-Message 924 0-1 Callback-Number 925 0-1 Callback-Id 926 0+ Framed-Route 927 0-1 Framed-IPX-Network 928 0 State 929 0+ Class 930 0+ Vendor-Specific 931 0-1 Session-Timeout 932 0-1 Idle-Timeout 933 0-1 Termination-Action 934 0-1 Called-Station-Id 935 0-1 Calling-Station-Id 936 0-1 NAS-Identifier [4] 937 0+ Proxy-State 938 0-1 Login-LAT-Service 939 0-1 Login-LAT-Node 940 0-1 Login-LAT-Group 941 0-1 Framed-AppleTalk-Link 942 0-1 Framed-AppleTalk-Network 943 0-1 Framed-AppleTalk-Zone 944 1 Acct-Status-Type 945 0-1 Acct-Delay-Time 946 0-1 Acct-Input-Octets 947 0-1 Acct-Output-Octets 948 1 Acct-Session-Id 949 0-1 Acct-Authentic 950 0-1 Acct-Session-Time 951 0-1 Acct-Input-Packets 952 0-1 Acct-Output-Packets 953 0-1 Acct-Terminate-Cause 954 0 CHAP-Challenge 955 0-1 NAS-Port-Id 956 0-1 Port-Limit 958 [4] An Accounting-Request MUST contain either a NAS-IP-Address or a 959 NAS-Identifier, and it is permitted (but not recommended) for it to 960 contain both. 962 The following table defines the meaning of the above table entries. 964 0 This attribute MUST NOT be present 965 0+ Zero or more instances of this attribute MAY be present. 966 0-1 Zero or one instance of this attribute MAY be present. 967 1 Exactly one instance of this attribute MUST be present. 969 Security Considerations 971 Security issues are briefly discussed in sections concerning the 972 authenticator included in accounting requests and responses, using a 973 shared secret which is never sent over the network. 975 References 977 [1] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 978 Sciences Institute, August 1980. 980 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 981 USC/Information Sciences Institute, October 1994. 983 [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 984 MIT Laboratory for Computer Science and RSA Data Security, 985 Inc., RFC 1321, April 1992. 987 Acknowledgments 989 RADIUS and RADIUS Accounting were originally developed by Livingston 990 Enterprises for their PortMaster series of Network Access Servers. 992 Chair's Address 994 The RADIUS working group can be contacted via the current chair: 996 Carl Rigney 997 Livingston Enterprises 998 6920 Koll Center Parkway, Suite 220 999 Pleasanton, California 94566 1001 Phone: +1 510 426 0770 1002 EMail: cdr@livingston.com 1004 Author's Address 1006 Questions about this memo can also be directed to: 1008 Carl Rigney 1009 Livingston Enterprises 1010 6920 Koll Center Parkway, Suite 220 1011 Pleasanton, California 94566 1013 EMail: cdr@livingston.com 1015 This document expires May 31st, 1996.