idnits 2.17.1 draft-ietf-radius-accounting-00.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-24) 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 133: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 136: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 139: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 145: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 147: '...h does not include this option MUST be...' (21 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 (July 1995) is 10511 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 839, 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 July 1995 6 RADIUS Accounting 7 draft-ietf-radius-accounting-00.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 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 January 15th, 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 .............................. 15 64 5.9 Acct-Output-Packets ............................. 16 65 5.10 Table of Attributes ............................. 17 67 Security Considerations ...................................... 19 69 References ................................................... 19 71 Acknowledgements ............................................. 19 73 Chair's Address .............................................. 20 75 Author's Address ............................................. 20 77 1. Introduction 79 Managing dispersed serial line and modem pools for large numbers of 80 users can create the need for significant administrative support. 81 Since modem pools are by definition a link to the outside world, they 82 require careful attention to security, authorization and accounting. 83 This can be best achieved by managing a single "database" of users, 84 which allows for authentication (verifying user name and password) as 85 well as configuration information detailing the type of service to 86 deliver to the user (that is, SLIP, PPP, telnet, rlogin). 88 The RADIUS (Remote Authentication Dial In User Service) Internet- 89 Draft specifies the RADIUS protocol used for Authentication and 90 Authorization. This Internet-Draft extends the use of the RADIUS 91 protocol to cover delivery of accounting information from the Network 92 Access Server (NAS) to a RADIUS accounting server. 94 Key features of RADIUS Accounting are: 96 Client/Server Model 98 A Network Access Server (NAS) operates as a client of the 99 RADIUS accounting server. The client is responsible for 100 passing user accounting information to a designated RADIUS 101 accounting server. 103 The RADIUS accounting server is responsible for receiving the 104 accounting request and returning a response to the client 105 indicating that it has successfully received the request. 107 The RADIUS accounting server can act as a proxy client to other 108 kinds of accounting servers. 110 Network Security 112 Transactions between the client and RADIUS accounting server 113 are authenticated through the use of a shared secret, which is 114 never sent over the network. 116 Extensible Protocol 118 All transactions are comprised of variable length Attribute- 119 Length-Value 3-tuples. New attribute values can be added 120 without disturbing existing implementations of the protocol. 122 Source Code Availability 124 Livingston Enterprises is making the C source code for an example 125 RADIUS accounting server available without use restrictions. 126 Other vendors have also implemented RADIUS Accounting. 128 1.1. Specification of Requirements 130 In this document, several words are used to signify the requirements 131 of the specification. These words are often capitalized. 133 MUST This word, or the adjective "required", means that the 134 definition is an absolute requirement of the specification. 136 MUST NOT This phrase means that the definition is an absolute 137 prohibition of the specification. 139 SHOULD This word, or the adjective "recommended", means that there 140 may exist valid reasons in particular circumstances to 141 ignore this item, but the full implications must be 142 understood and carefully weighed before choosing a 143 different course. 145 MAY This word, or the adjective "optional", means that this 146 item is one of an allowed set of alternatives. An 147 implementation which does not include this option MUST be 148 prepared to interoperate with another implementation which 149 does include the option. 151 1.2. Terminology 153 This document uses the following term: 155 silently discard 156 This means the implementation discards the packet without 157 further processing. The implementation SHOULD provide the 158 capability of logging the error, including the contents of 159 the silently discarded packet, and SHOULD record the event 160 in a statistics counter. 162 2. Operation 164 When a client is configured to use RADIUS Accounting, at the start of 165 service delivery it will generate an Accounting Start packet 166 describing the type of service being delivered and the user it is 167 being delivered to, and will send that to the RADIUS Accounting 168 server, which will send back an acknowledgement that the packet has 169 been received. At the end of service delivery the client will 170 generate an Accounting Stop packet describing the type of service 171 that was delivered and optionally statistics such as elapsed time, 172 input and output octets, or input and output packets. It will send 173 that to the RADIUS Accounting server, which will send back an 174 acknowledgement that the packet has been received. 176 The Accounting-Request (whether for Start or Stop) is submitted to 177 the RADIUS accounting server via the network. If no response is 178 returned within a length of time, the request is re-sent a number of 179 times. After several failed attempts, the client can also forward 180 requests to an alternate server in the event that the primary server 181 is down or unreachable. 183 It is recommended that the client continue attempting to send the 184 Accounting packet until it receives an acknowledgement, using some 185 form of backoff. It MAY elect to send the packet to an alternate 186 accounting server. The nature of the timeout algorithms to be used 187 are the topic of current research, and are not further specified 188 here. 190 The RADIUS accounting server MAY make requests of other servers in 191 order to satisfy the request, in which case it acts as a client. 193 If the RADIUS accounting server is unable to successfully record the 194 accounting packet it MUST NOT send an Accounting-Response 195 acknowledgment to the client. 197 3. Packet Format 199 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 200 field [1], where the UDP Destination Port field indicates 1646. 202 When a reply is generated, the source and destination ports are 203 reversed. 205 A summary of the RADIUS data format is shown below. The fields are 206 transmitted from left to right. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Code | Identifier | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 | Authenticator | 215 | | 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Attributes ... 219 +-+-+-+-+-+-+-+-+-+-+-+-+- 221 Code 223 The Code field is one octet, and identifies the type of RADIUS 224 packet. When a packet is received with an invalid Code field, it is 225 silently discarded. 227 RADIUS Accounting Codes (decimal) are assigned as follows: 229 4 Accounting-Request 230 5 Accounting-Response 232 Identifier 234 The Identifier field is one octet, and aids in matching requests and 235 replies. 237 Length 239 The Length field is two octets. It indicates the length of the 240 packet including the Code, Identifier, Length, Authenticator and 241 Attribute fields. Octets outside the range of the Length field 242 should be treated as padding and should be ignored on reception. 244 Authenticator 246 The Authenticator field is sixteen (16) octets. The most significant 247 octet is transmitted first. This value is used to authenticate the 248 messages between the client and RADIUS accounting server. 250 Request Authenticator 252 In Accounting-Request Packets, the Authenticator value is a 16 253 octet MD5 [3] checksum. 255 The NAS and RADIUS accounting server share a secret. The 256 Authenticator field in Accounting-Request packets contains a one- 257 way MD5 hash calculated over a stream of octets consisting of the 258 Code + Identifier + Length + 16 zero octets + request attributes + 259 shared secret (where + indicates concatenation). The 16 octet MD5 260 hash value is stored in the Authenticator field of the 261 Accounting-Request packet. 263 Note that the Request Authenticator of an Accounting-Request can 264 not be done the same way as the Request Authenticator of a RADIUS 265 Access-Request, because there is no User-Password attribute in an 266 Accounting-Request. 268 [Draft Note - the implementation of RADIUS Accounting in 269 Livingston's ComOS 3.1 through 3.1.3 sets the Request 270 Authenticator to all 0's. The next release will implement the 271 method described here, after which this Note will be removed from 272 the Draft.] 274 Response Authenticator 276 The Authenticator field in an Accounting-Response packet contains 277 a one-way MD5 hash calculated over a stream of octets consisting 278 of the Accounting-Response Code, Identifier, Length, the 279 Authenticator field from the Accounting-Request packet being 280 replied to, and the response attributes if any, followed by the 281 shared secret. The resulting 16 octet MD5 hash value is stored in 282 the Authenticator field of the Accounting-Response packet. 284 Attributes 286 Attributes may have multiple instances, in such a case the order of 287 attributes of the same type SHOULD be preserved. The order of 288 attributes of different types is not required to be preserved. 290 4. Packet Types 292 The RADIUS packet type is determined by the Code field in the first 293 octet of the packet. 295 4.1. Accounting-Request 297 Description 299 Accounting-Request packets are sent from a client (typically a 300 Network Access Server or its proxy) to a RADIUS accounting server, 301 and convey information used to provide accounting for a service 302 provided to a user. The client transmits a RADIUS packet with the 303 Code field set to 4 (Accounting-Request). 305 Upon receipt of an Accounting-Request, the server MUST transmit an 306 Accounting-Response reply if it successfully records the 307 accounting packet, and MUST NOT transmit any reply if it fails to 308 record the accounting packet. 310 Any attribute valid in a RADIUS Access-Request or Access-Accept 311 packet is valid in a RADIUS Accounting-Request packet, except that 312 the following attributes MUST NOT be present in an Accounting- 313 Request: User-Password, CHAP-Password, Reply-Message, State. 315 Either NAS-IP-Address or NAS-Identifier MUST be present in a 316 RADIUS Accounting-Request. 318 It SHOULD contain a NAS-Port attribute unless the service does not 319 involve a port or the NAS does not distinguish among its ports. 321 A summary of the Accounting-Request packet format is shown below. 322 The fields are transmitted from left to right. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Code | Identifier | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | Authenticator | 331 | | 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Attributes ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+- 336 Code 338 4 for Accounting-Request. 340 Identifier 342 The Identifier field MUST be changed whenever the content of the 343 Attributes field changes, and whenever a valid reply has been 344 received for a previous request. For retransmissions where the 345 contents are identical, the Identifier MUST remain unchanged. 347 Note that if Acct-Delay-Time is included in the attributes of an 348 Accounting-Request then the Acct-Delay-Time value will be updated 349 when the packet is retransmitted, changing the content of the 350 Attributes field and requiring a new Identifier and Request 351 Authenticator. 353 Authenticator 355 The Authenticator of an Accounting-Request contains a 16-octet MD5 356 hash value calculated according to the method described in 357 "Request Authenticator", above. 359 [Draft Note - the implementation of RADIUS Accounting in 360 Livingston's ComOS 3.1 through 3.1.3 sets the Request 361 Authenticator to all 0's. The next release will implement the 362 method described here, after which this Note will be removed from 363 the Draft.] 365 Attributes 367 The Attributes field is variable in length, and contains a list of 368 Attributes. 370 4.2. Accounting-Response 372 Description 374 Accounting-Response packets are sent by the RADIUS accounting 375 server to the client to acknowledge that the Accounting-Request 376 has been received and recorded successfully. 378 If the Accounting-Request was recorded successfully then the 379 RADIUS accounting server MUST transmit a packet with the Code 380 field set to 5 (Accounting-Response). 382 A RADIUS Accounting-Response is not required to have any 383 attributes in it. 385 On reception of an Accounting-Response by the client, the 386 Identifier field is matched with a pending Accounting-Request. 387 Invalid packets are silently discarded. 389 A summary of the Accounting-Response packet format is shown below. 390 The fields are transmitted from left to right. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Code | Identifier | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 | Authenticator | 399 | | 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Attributes ... 403 +-+-+-+-+-+-+-+-+-+-+-+-+- 405 Code 407 5 for Accounting-Response. 409 Identifier 411 The Identifier field is a copy of the Identifier field of the 412 Accounting-Request which caused this Accounting-Response. 414 Authenticator 416 The Authenticator of an Accounting-Response contains a 16-octet 417 MD5 hash value calculated according to the method described in 418 "Response Authenticator", above. 420 Attributes 422 The Attributes field is variable in length, and contains a list of 423 zero or more Attributes. 425 5. Attributes 427 RADIUS Attributes carry the specific authentication, authorization 428 and accounting details for the request and response. 430 Some attributes MAY be listed more than once. The effect of this is 431 attribute specific, and is specified by each such attribute 432 description. 434 The end of the list of attributes is indicated by the length of the 435 RADIUS packet. 437 A summary of the attribute format is shown below. The fields are 438 transmitted from left to right. 440 0 1 2 441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Length | Value ... 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Type 448 The Type field is one octet. Up-to-date values of the RADIUS Type 449 field are specified in the most recent "Assigned Numbers" RFC [2]. 450 Values 192-223 are reserved for experimental use, values 224-240 451 are reserved for implementation-specific use, and values 241-255 452 are reserved and should not be used. This specification concerns 453 the following values: 455 1-39 Refer to RADIUS Internet-Draft 456 40 Acct-Status-Type 457 41 Acct-Delay-Time 458 42 Acct-Input-Octets 459 43 Acct-Output-Octets 460 44 Acct-Session-Id 461 45 Acct-Authentic 462 46 Acct-Session-Time 463 47 Acct-Input-Packets 464 48 Acct-Output-Packets 466 Length 468 The Length field is one octet, and indicates the length of this 469 attribute including the Type, Length and Value fields. If an 470 attribute is received in an Accounting-Request with an invalid 471 Length, the entire request should be silently discarded. 473 Value 475 The Value field is zero or more octets and contains information 476 specific to the attribute. The format and length of the Value 477 field is determined by the Type and Length fields. 479 The format of the value field is one of four data types. 481 string 0-253 octets 483 address 32 bit value, most significant octet first. 485 integer 32 bit value, most significant octet first. 487 time 32 bit value, most significant octet first -- seconds 488 since 00:00:00 GMT, January 1, 1970. 490 5.1. Acct-Status-Type 492 Description 494 This attribute indicates whether this Accounting-Request marks the 495 beginning of the user service (Start) or the end (Stop). 497 A summary of the Acct-Status-Type attribute format is shown below. 498 The fields are transmitted from left to right. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | Length | Value 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Value (cont) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Type 510 40 for Acct-Status-Type. 512 Length 514 6 516 Value 518 The Value field is four octets. 520 1 Start 521 2 Stop 523 5.2. Acct-Delay-Time 525 Description 527 This attribute indicates how many seconds the client has been 528 trying to send this record for, and can be subtracted from the 529 time of arrival on the server to find the approximate time of the 530 event generating this Accounting-Request. (Network transit time 531 is ignored.) 533 A summary of the Acct-Delay-Time attribute format is shown below. 534 The fields are transmitted from left to right. 536 0 1 2 3 537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type | Length | Value 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Value (cont) | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Type 546 41 for Acct-Delay-Time. 548 Length 550 6 552 Value 554 The Value field is four octets. 556 5.3. Acct-Input-Octets 558 Description 560 This attribute indicates how many octets have been received from 561 the port over the course of this service being provided, and can 562 only be present in Accounting-Request records where the Acct- 563 Status-Type is set to Stop. 565 A summary of the Acct-Input-Octets attribute format is shown below. 566 The fields are transmitted from left to right. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type | Length | Value 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Value (cont) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Type 578 42 for Acct-Input-Octets. 580 Length 582 6 584 Value 586 The Value field is four octets. 588 5.4. Acct-Output-Octets 590 Description 592 This attribute indicates how many octets have been sent to the 593 port in the course of delivering this service, and can only be 594 present in Accounting-Request records where the Acct-Status-Type 595 is set to Stop. 597 A summary of the Acct-Output-Octets attribute format is shown below. 598 The fields are transmitted from left to right. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | Value 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Value (cont) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Type 610 43 for Acct-Output-Octets. 612 Length 614 6 616 Value 618 The Value field is four octets. 620 5.5. Acct-Session-Id 622 Description 624 This attribute is a unique Accounting ID to make it easy to match 625 start and stop records in a log file. The start and stop records 626 for a given session MUST have the same Acct-Session-Id. It is 627 strongly recommended that the Acct-Session-Id be a printable ASCII 628 string. 630 For example, one implementation uses a string with an 8-digit 631 uppercase hexadecimal number, the first two digits increment on 632 each reboot (wrapping every 256 reboots) and the next 6 digits 633 counting from 0 for the first person logging in after a reboot up 634 to 2^24-1, about 16 million. Other encodings are permissible. 636 A summary of the Acct-Session-Id attribute format is shown below. 637 The fields are transmitted from left to right. 639 0 1 2 640 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Type | Length | String ... 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Type 646 44 for Acct-Session-Id. 648 Length 650 >= 3 652 String 654 The String field is a string of printable ASCII characters. 656 5.6. Acct-Authentic 658 Description 660 This attribute indicates how the user was authenticated, whether 661 by RADIUS or by the NAS itself. Users who are delivered service 662 without being authenticated should not generate Accounting 663 records. 665 A summary of the Acct-Authentic attribute format is shown below. The 666 fields are transmitted from left to right. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Type | Length | Value 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Value (cont) | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Type 678 45 for Acct-Authentic. 680 Length 682 6 684 Value 686 The Value field is four octets. 688 1 RADIUS 689 2 Local 691 5.7. Acct-Session-Time 693 Description 695 This attribute indicates how many seconds the user has received 696 service for, and can only be present in Accounting-Request records 697 where the Acct-Status-Type is set to Stop. 699 A summary of the Acct-Session-Time attribute format is shown below. 700 The fields are transmitted from left to right. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type | Length | Value 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Value (cont) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Type 712 46 for Acct-Session-Time. 714 Length 716 6 718 Value 720 The Value field is four octets. 722 5.8. Acct-Input-Packets 724 Description 726 This attribute indicates how many packets have been received from 727 the port over the course of this service being provided to a 728 Framed User, and can only be present in Accounting-Request records 729 where the Acct-Status-Type is set to Stop. 731 A summary of the Acct-Input-packets attribute format is shown below. 732 The fields are transmitted from left to right. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type | Length | Value 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Value (cont) | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Type 744 47 for Acct-Input-Packets. 746 Length 748 6 750 Value 752 The Value field is four octets. 754 5.9. Acct-Output-Packets 756 Description 758 This attribute indicates how many packets have been sent to the 759 port in the course of delivering this service to a Framed User, 760 and can only be present in Accounting-Request records where the 761 Acct-Status-Type is set to Stop. 763 A summary of the Acct-Output-Packets attribute format is shown below. 764 The fields are transmitted from left to right. 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Type | Length | Value 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Value (cont) | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Type 775 48 for Acct-Output-Packets. 777 Length 779 6 781 Value 783 The Value field is four octets. 785 5.10. Table of Attributes 787 The following table provides a guide to which attributes may be found 788 in Accounting-Request packets. No attributes should be found in 789 Accounting-Response packets (except possibly for Vendor-Specific). 791 # Attribute 792 0-1 User-Name 793 0 User-Password 794 0 CHAP-Password 795 0-1 NAS-IP-Address [4] 796 0-1 NAS-Port 797 0-1 Service-Type 798 0-1 Framed-Protocol 799 0-1 Framed-IP-Address 800 0-1 Framed-IP-Netmask 801 0-1 Framed-Routing 802 0+ Filter-Id 803 0-1 Framed-MTU 804 0+ Framed-Compression 805 0+ Login-IP-Host 806 0-1 Login-Service 807 0-1 Login-Port 808 0 Reply-Message 809 0-1 Callback-Number 810 0-1 Callback-Id 811 0+ Framed-Route 812 0-1 Framed-IPX-Network 813 0 State 814 0+ Class 815 0+ Vendor-Specific 816 0-1 Session-Timeout 817 0-1 Idle-Timeout 818 0-1 Termination-Action 819 0-1 Called-Station-Id 820 0-1 Calling-Station-Id 821 0-1 NAS-Identifier [4] 822 0+ Proxy-State 823 0-1 Login-LAT-Service 824 0-1 Login-LAT-Node 825 0-1 Login-LAT-Group 826 0-1 Framed-AppleTalk-Link 827 0-1 Framed-AppleTalk-Network 828 0-1 Framed-AppleTalk-Zone 829 1 Acct-Status-Type 830 0-1 Acct-Delay-Time 831 0-1 Acct-Input-Octets 832 0-1 Acct-Output-Octets 833 1 Acct-Session-Id 834 0-1 Acct-Authentic 835 0-1 Acct-Session-Time 836 0-1 Acct-Input-Packets 837 0-1 Acct-Output-Packets 839 [4] An Accounting-Request MUST contain either a NAS-IP-Address or a 840 NAS-Identifier, and it is permitted (but not recommended) for it to 841 contain both. 843 The following table defines the meaning of the above table entries. 845 0 This attribute MUST NOT be present 846 0+ Zero or more instances of this attribute MAY be present. 847 0-1 Zero or one instance of this attribute MAY be present. 848 1 Exactly one instance of this attribute MUST be present. 850 Security Considerations 852 Security issues are briefly discussed in sections concerning the 853 authenticator included in accounting requests and responses, using a 854 shared secret which is never sent over the network. 856 References 858 [1] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 859 Sciences Institute, August 1980. 861 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 862 USC/Information Sciences Institute, October 1994. 864 [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 865 MIT Laboratory for Computer Science and RSA Data Security, 866 Inc., RFC 1321, April 1992. 868 Acknowledgments 870 RADIUS and RADIUS Accounting were originally developed by Livingston 871 Enterprises for their PortMaster series of Network Access Servers. 873 Chair's Address 875 The RADIUS working group can be contacted via the current chair: 877 Carl Rigney 878 Livingston Enterprises 879 6920 Koll Center Parkway, Suite 220 880 Pleasanton, California 94566 882 Phone: +1 510 426 0770 883 EMail: cdr@livingston.com 885 Author's Address 887 Questions about this memo can also be directed to: 889 Carl Rigney 890 Livingston Enterprises 891 6920 Koll Center Parkway, Suite 220 892 Pleasanton, California 94566 894 EMail: cdr@livingston.com 896 This document expires January 15th, 1996.