idnits 2.17.1 draft-ietf-radius-accounting-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A forwarding server MUST not modify existing Proxy-State or Class attributes present in the packet. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9194 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Note 1' on line 1103 ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2279 (ref. '6') (Obsoleted by RFC 3629) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 September 1999 February 1999 6 RADIUS Accounting 7 draft-ietf-radius-accounting-v2-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is a submission to the RADIUS Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the ietf-radius@livingston.com mailing list. 18 Distribution of this memo is unlimited. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (1997). All Rights Reserved. 40 Abstract 42 This document describes a protocol for carrying accounting 43 information between a Network Access Server and a shared Accounting 44 Server. 46 Implementation Note 48 This memo documents the RADIUS Accounting protocol. The early 49 deployment of RADIUS Accounting was done using UDP port number 1646, 50 which conflicts with the "sa-msg-port" service. The officially 51 assigned port number for RADIUS Accounting is 1813. 53 Table of Contents 55 1. Introduction .......................................... 3 56 1.1 Specification of Requirements ................... 4 57 1.2 Terminology ..................................... 4 59 2. Operation ............................................. 4 60 2.1 Proxy ........................................... 5 62 3. Packet Format ......................................... 6 64 4. Packet Types .......................................... 8 65 4.1 Accounting-Request .............................. 8 66 4.2 Accounting-Response ............................. 10 68 5. Attributes ............................................ 11 69 5.1 Acct-Status-Type ................................ 12 70 5.2 Acct-Delay-Time ................................. 13 71 5.3 Acct-Input-Octets ............................... 14 72 5.4 Acct-Output-Octets .............................. 15 73 5.5 Acct-Session-Id ................................. 15 74 5.6 Acct-Authentic .................................. 16 75 5.7 Acct-Session-Time ............................... 17 76 5.8 Acct-Input-Packets .............................. 18 77 5.9 Acct-Output-Packets ............................. 19 78 5.10 Acct-Terminate-Cause ............................ 19 79 5.11 Acct-Multi-Session-Id ........................... 22 80 5.12 Acct-Link-Count ................................. 22 81 5.13 Table of Attributes ............................. 24 83 6. Security Considerations ............................... 25 84 7. Change Log ............................................ 25 85 8. References ............................................ 26 86 9. Acknowledgements ...................................... 26 87 10. Chair's Address ....................................... 26 88 11. Author's Address ...................................... 26 89 12. Full Copyright Statement .............................. 27 91 1. Introduction 93 Managing dispersed serial line and modem pools for large numbers of 94 users can create the need for significant administrative support. 95 Since modem pools are by definition a link to the outside world, they 96 require careful attention to security, authorization and accounting. 97 This can be best achieved by managing a single "database" of users, 98 which allows for authentication (verifying user name and password) as 99 well as configuration information detailing the type of service to 100 deliver to the user (for example, SLIP, PPP, telnet, rlogin). 102 The RADIUS (Remote Authentication Dial In User Service) document [1] 103 specifies the RADIUS protocol used for Authentication and 104 Authorization. This memo extends the use of the RADIUS protocol to 105 cover delivery of accounting information from the Network Access 106 Server (NAS) to a RADIUS accounting server. 108 Key features of RADIUS Accounting are: 110 Client/Server Model 112 A Network Access Server (NAS) operates as a client of the 113 RADIUS accounting server. The client is responsible for 114 passing user accounting information to a designated RADIUS 115 accounting server. 117 The RADIUS accounting server is responsible for receiving the 118 accounting request and returning a response to the client 119 indicating that it has successfully received the request. 121 The RADIUS accounting server can act as a proxy client to other 122 kinds of accounting servers. 124 Network Security 126 Transactions between the client and RADIUS accounting server 127 are authenticated through the use of a shared secret, which is 128 never sent over the network. 130 Extensible Protocol 132 All transactions are comprised of variable length Attribute- 133 Length-Value 3-tuples. New attribute values can be added 134 without disturbing existing implementations of the protocol. 136 1.1. Specification of Requirements 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [2]. 142 1.2. Terminology 144 This document uses the following terms: 146 service The NAS provides a service to the dial-in user, such as PPP 147 or Telnet. 149 session Each service provided by the NAS to a dial-in user 150 constitutes a session, with the beginning of the session 151 defined as the point where service is first provided and 152 the end of the session defined as the point where service 153 is ended. A user may have multiple sessions in parallel or 154 series if the NAS supports that, with each session 155 generating a separate start and stop accounting record with 156 its own Acct-Session-Id. 158 silently discard 159 This means the implementation discards the packet without 160 further processing. The implementation SHOULD provide the 161 capability of logging the error, including the contents of 162 the silently discarded packet, and SHOULD record the event 163 in a statistics counter. 165 2. Operation 167 When a client is configured to use RADIUS Accounting, at the start of 168 service delivery it will generate an Accounting Start packet 169 describing the type of service being delivered and the user it is 170 being delivered to, and will send that to the RADIUS Accounting 171 server, which will send back an acknowledgement that the packet has 172 been received. At the end of service delivery the client will 173 generate an Accounting Stop packet describing the type of service 174 that was delivered and optionally statistics such as elapsed time, 175 input and output octets, or input and output packets. It will send 176 that to the RADIUS Accounting server, which will send back an 177 acknowledgement that the packet has been received. 179 The Accounting-Request (whether for Start or Stop) is submitted to 180 the RADIUS accounting server via the network. It is recommended that 181 the client continue attempting to send the Accounting-Request packet 182 until it receives an acknowledgement, using some form of backoff. If 183 no response is returned within a length of time, the request is re- 184 sent a number of times. The client can also forward requests to an 185 alternate server or servers in the event that the primary server is 186 down or unreachable. An alternate server can be used either after a 187 number of tries to the primary server fail, or in a round-robin 188 fashion. Retry and fallback algorithms are the topic of current 189 research and are not specified in detail in this document. 191 The RADIUS accounting server MAY make requests of other servers in 192 order to satisfy the request, in which case it acts as a client. 194 If the RADIUS accounting server is unable to successfully record the 195 accounting packet it MUST NOT send an Accounting-Response 196 acknowledgment to the client. 198 2.1. Proxy 200 See the "RADIUS" RFC [1] for information on Proxy RADIUS. Proxy 201 Accounting RADIUS works the same way, as illustrated by the following 202 example. 204 1. The NAS sends an accounting-request to the forwarding server. 206 2. The forwarding server logs the accounting-request (if desired), 207 adds its Proxy-State (if desired) after any other Proxy-State 208 attributes, updates the Request Authenticator, and forwards the 209 request to the remote server. 211 3. The remote server logs the accounting-request (if desired), 212 copies all Proxy-State attributes in order and unmodified from 213 the request to the response packet, and sends the accounting- 214 response to the forwarding server. 216 4 The forwarding server strips the last Proxy-State (if it added 217 one in step 2), updates the Response Authenticator and sends 218 the accounting-response to the NAS. 220 A forwarding server MUST not modify existing Proxy-State or Class 221 attributes present in the packet. 223 A forwarding server may either perform its forwarding function in a 224 pass through manner, where it sends retransmissions on as soon as it 225 gets them, or it may take responsibility for retransmissions, for 226 example in cases where the network link between forwarding and remote 227 server has very different characteristics than the link between NAS 228 and forwarding server. 230 Extreme care should be used when implementing a proxy server that 231 takes responsibility for retransmissions so that its retransmission 232 policy is robust and scalable. 234 3. Packet Format 236 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 237 field [3], where the UDP Destination Port field indicates 1813 238 (decimal). 240 When a reply is generated, the source and destination ports are 241 reversed. 243 This memo documents the RADIUS Accounting protocol. The early 244 deployment of RADIUS Accounting was done using UDP port number 1646, 245 which conflicts with the "sa-msg-port" service. The officially 246 assigned port number for RADIUS Accounting is 1813. 248 A summary of the RADIUS data format is shown below. The fields are 249 transmitted from left to right. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Code | Identifier | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 | Authenticator | 258 | | 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Attributes ... 262 +-+-+-+-+-+-+-+-+-+-+-+-+- 264 Code 266 The Code field is one octet, and identifies the type of RADIUS 267 packet. When a packet is received with an invalid Code field, it is 268 silently discarded. 270 RADIUS Accounting Codes (decimal) are assigned as follows: 272 4 Accounting-Request 273 5 Accounting-Response 275 Identifier 277 The Identifier field is one octet, and aids in matching requests and 278 replies. The RADIUS server can detect a duplicate request if it has 279 the same client source IP address and source UDP port and Identifier 280 within a short span of time. 282 Length 284 The Length field is two octets. It indicates the length of the 285 packet including the Code, Identifier, Length, Authenticator and 286 Attribute fields. Octets outside the range of the Length field 287 should be treated as padding and should be ignored on reception. If 288 the packet is shorter than the Length field indicates, it should be 289 silently discarded. The minimum length is 20 and maximum length is 290 4096. 292 Authenticator 294 The Authenticator field is sixteen (16) octets. The most significant 295 octet is transmitted first. This value is used to authenticate the 296 messages between the client and RADIUS accounting server. 298 Request Authenticator 300 In Accounting-Request Packets, the Authenticator value is a 16 301 octet MD5 [4] checksum, called the Request Authenticator. 303 The NAS and RADIUS accounting server share a secret. The Request 304 Authenticator field in Accounting-Request packets contains a one- 305 way MD5 hash calculated over a stream of octets consisting of the 306 Code + Identifier + Length + 16 zero octets + request attributes + 307 shared secret (where + indicates concatenation). The 16 octet MD5 308 hash value is stored in the Authenticator field of the 309 Accounting-Request packet. 311 Note that the Request Authenticator of an Accounting-Request can 312 not be done the same way as the Request Authenticator of a RADIUS 313 Access-Request, because there is no User-Password attribute in an 314 Accounting-Request. 316 Response Authenticator 318 The Authenticator field in an Accounting-Response packet is called 319 the Response Authenticator, and contains a one-way MD5 hash 320 calculated over a stream of octets consisting of the Accounting- 321 Response Code, Identifier, Length, the Request Authenticator field 322 from the Accounting-Request packet being replied to, and the 323 response attributes if any, followed by the shared secret. The 324 resulting 16 octet MD5 hash value is stored in the Authenticator 325 field of the Accounting-Response packet. 327 Attributes 329 Attributes may have multiple instances, in such a case the order of 330 attributes of the same type SHOULD be preserved. The order of 331 attributes of different types is not required to be preserved. 333 4. Packet Types 335 The RADIUS packet type is determined by the Code field in the first 336 octet of the packet. 338 4.1. Accounting-Request 340 Description 342 Accounting-Request packets are sent from a client (typically a 343 Network Access Server or its proxy) to a RADIUS accounting server, 344 and convey information used to provide accounting for a service 345 provided to a user. The client transmits a RADIUS packet with the 346 Code field set to 4 (Accounting-Request). 348 Upon receipt of an Accounting-Request, the server MUST transmit an 349 Accounting-Response reply if it successfully records the 350 accounting packet, and MUST NOT transmit any reply if it fails to 351 record the accounting packet. 353 Any attribute valid in a RADIUS Access-Request or Access-Accept 354 packet is valid in a RADIUS Accounting-Request packet, except that 355 the following attributes MUST NOT be present in an Accounting- 356 Request: User-Password, CHAP-Password, Reply-Message, State. 357 Either NAS-IP-Address or NAS-Identifier MUST be present in a 358 RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- 359 Port-Type attribute or both unless the service does not involve a 360 port or the NAS does not distinguish among its ports. 362 If the Accounting-Request packet includes a Framed-IP-Address, 363 that attribute MUST contain the IP address of the user. If the 364 Access-Accept used the special values for Framed-IP-Address 365 telling the NAS to assign or negotiate an IP address for the user, 366 the Framed-IP-Address (if any) in the Accounting-Request MUST 367 contain the actual IP address assigned or negotiated. 369 A summary of the Accounting-Request packet format is shown below. 370 The fields are transmitted from left to right. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Code | Identifier | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | Request Authenticator | 379 | | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Attributes ... 383 +-+-+-+-+-+-+-+-+-+-+-+-+- 385 Code 387 4 for Accounting-Request. 389 Identifier 391 The Identifier field MUST be changed whenever the content of the 392 Attributes field changes, and whenever a valid reply has been 393 received for a previous request. For retransmissions where the 394 contents are identical, the Identifier MUST remain unchanged. 396 Note that if Acct-Delay-Time is included in the attributes of an 397 Accounting-Request then the Acct-Delay-Time value will be updated 398 when the packet is retransmitted, changing the content of the 399 Attributes field and requiring a new Identifier and Request 400 Authenticator. 402 Request Authenticator 404 The Request Authenticator of an Accounting-Request contains a 16- 405 octet MD5 hash value calculated according to the method described 406 in "Request Authenticator" above. 408 Attributes 410 The Attributes field is variable in length, and contains a list of 411 Attributes. 413 4.2. Accounting-Response 415 Description 417 Accounting-Response packets are sent by the RADIUS accounting 418 server to the client to acknowledge that the Accounting-Request 419 has been received and recorded successfully. If the Accounting- 420 Request was recorded successfully then the RADIUS accounting 421 server MUST transmit a packet with the Code field set to 5 422 (Accounting-Response). On reception of an Accounting-Response by 423 the client, the Identifier field is matched with a pending 424 Accounting-Request. Invalid packets are silently discarded. 426 A RADIUS Accounting-Response is not required to have any 427 attributes in it. 429 A summary of the Accounting-Response packet format is shown below. 430 The fields are transmitted from left to right. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Code | Identifier | Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 | Response Authenticator | 439 | | 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Attributes ... 443 +-+-+-+-+-+-+-+-+-+-+-+-+- 445 Code 447 5 for Accounting-Response. 449 Identifier 451 The Identifier field is a copy of the Identifier field of the 452 Accounting-Request which caused this Accounting-Response. 454 Response Authenticator 456 The Response Authenticator of an Accounting-Response contains a 457 16-octet MD5 hash value calculated according to the method 458 described in "Response Authenticator" above. 460 Attributes 462 The Attributes field is variable in length, and contains a list of 463 zero or more Attributes. 465 5. Attributes 467 RADIUS Attributes carry the specific authentication, authorization 468 and accounting details for the request and response. 470 Some attributes MAY be included more than once. The effect of this 471 is attribute specific, and is specified in each attribute 472 description. 474 The end of the list of attributes is indicated by the Length of the 475 RADIUS packet. 477 A summary of the attribute format is shown below. The fields are 478 transmitted from left to right. 480 0 1 2 481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | Value ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Type 488 The Type field is one octet. Up-to-date values of the RADIUS Type 489 field are specified in the most recent "Assigned Numbers" RFC [5]. 490 Values 192-223 are reserved for experimental use, values 224-240 491 are reserved for implementation-specific use, and values 241-255 492 are reserved and should not be used. This specification concerns 493 the following values: 495 1-39 (refer to RADIUS document [1]) 496 40 Acct-Status-Type 497 41 Acct-Delay-Time 498 42 Acct-Input-Octets 499 43 Acct-Output-Octets 500 44 Acct-Session-Id 501 45 Acct-Authentic 502 46 Acct-Session-Time 503 47 Acct-Input-Packets 504 48 Acct-Output-Packets 505 49 Acct-Terminate-Cause 506 50 Acct-Multi-Session-Id 507 51 Acct-Link-Count 508 60+ (refer to RADIUS document [1]) 510 Length 512 The Length field is one octet, and indicates the length of this 513 attribute including the Type, Length and Value fields. If an 514 attribute is received in an Accounting-Request with an invalid 515 Length, the entire request should be silently discarded. 517 Value 519 The Value field is zero or more octets and contains information 520 specific to the attribute. The format and length of the Value 521 field is determined by the Type and Length fields. 523 The format of the value field is one of four data types. 525 string 0-253 octets 527 address 32 bit value, most significant octet first. 529 integer 32 bit unsigned value, most significant octet first. 531 time 32 bit unsigned value, most significant octet first -- 532 seconds since 00:00:00 GMT, January 1, 1970. The 533 standard Attributes do not use this data type but it is 534 presented here for possible use within Vendor-Specific 535 attributes. 537 5.1. Acct-Status-Type 539 Description 541 This attribute indicates whether this Accounting-Request marks the 542 beginning of the user service (Start) or the end (Stop). 544 It MAY be used by the client to mark the start of accounting (for 545 example, upon booting) by specifying Accounting-On and to mark the 546 end of accounting (for example, just before a scheduled reboot) by 547 specifying Accounting-Off. 549 A summary of the Acct-Status-Type attribute format is shown below. 550 The fields are transmitted from left to right. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type | Length | Value 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Value (cont) | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Type 562 40 for Acct-Status-Type. 564 Length 566 6 568 Value 570 The Value field is four octets. 572 1 Start 573 2 Stop 574 3 Interim-Update 575 7 Accounting-On 576 8 Accounting-Off 577 9-13 Reserved for Tunnel Accounting 579 5.2. Acct-Delay-Time 581 Description 583 This attribute indicates how many seconds the client has been 584 trying to send this record for, and can be subtracted from the 585 time of arrival on the server to find the approximate time of the 586 event generating this Accounting-Request. (Network transit time 587 is ignored.) 589 Note that changing the Acct-Delay-Time causes the Identifier to 590 change; see the discussion under Identifier above. 592 A summary of the Acct-Delay-Time attribute format is shown below. 593 The fields are transmitted from left to right. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | Value 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Value (cont) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Type 605 41 for Acct-Delay-Time. 607 Length 609 6 611 Value 613 The Value field is four octets. 615 5.3. Acct-Input-Octets 617 Description 619 This attribute indicates how many octets have been received from 620 the port over the course of this service being provided, and can 621 only be present in Accounting-Request records where the Acct- 622 Status-Type is set to Stop. 624 A summary of the Acct-Input-Octets attribute format is shown below. 625 The fields are transmitted from left to right. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Type | Length | Value 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Value (cont) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Type 637 42 for Acct-Input-Octets. 639 Length 641 6 643 Value 645 The Value field is four octets. 647 5.4. Acct-Output-Octets 649 Description 651 This attribute indicates how many octets have been sent to the 652 port in the course of delivering this service, and can only be 653 present in Accounting-Request records where the Acct-Status-Type 654 is set to Stop. 656 A summary of the Acct-Output-Octets attribute format is shown below. 657 The fields are transmitted from left to right. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type | Length | Value 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Value (cont) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Type 669 43 for Acct-Output-Octets. 671 Length 673 6 675 Value 677 The Value field is four octets. 679 5.5. Acct-Session-Id 681 Description 682 This attribute is a unique Accounting ID to make it easy to match 683 start and stop records in a log file. The start and stop records 684 for a given session MUST have the same Acct-Session-Id. An 685 Accounting-Request packet MUST have an Acct-Session-Id. An 686 Access-Request packet MAY have an Acct-Session-Id; if it does, 687 then the NAS MUST use the same Acct-Session-Id in the Accounting- 688 Request packets for that session. 690 It is strongly recommended that the Acct-Session-Id be a printable 691 UTF-8 [6] string. For example, one implementation uses a string 692 with an 8-digit upper case hexadecimal number, the first two 693 digits increment on each reboot (wrapping every 256 reboots) and 694 the next 6 digits counting from 0 for the first person logging in 695 after a reboot up to 2^24-1, about 16 million. Other encodings 696 are possible. 698 A summary of the Acct-Session-Id attribute format is shown below. 699 The fields are transmitted from left to right. 701 0 1 2 702 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type | Length | String ... 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Type 709 44 for Acct-Session-Id. 711 Length 713 >= 3 715 String 717 The String field SHOULD be a string of printable ASCII characters. 719 5.6. Acct-Authentic 721 Description 723 This attribute MAY be included in an Accounting-Request to 724 indicate how the user was authenticated, whether by RADIUS, the 725 NAS itself, or another remote authentication protocol. Users who 726 are delivered service without being authenticated SHOULD NOT 727 generate Accounting records. 729 A summary of the Acct-Authentic attribute format is shown below. The 730 fields are transmitted from left to right. 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Type | Length | Value 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Value (cont) | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Type 742 45 for Acct-Authentic. 744 Length 746 6 748 Value 750 The Value field is four octets. 752 1 RADIUS 753 2 Local 754 3 Remote 756 5.7. Acct-Session-Time 758 Description 760 This attribute indicates how many seconds the user has received 761 service for, and can only be present in Accounting-Request records 762 where the Acct-Status-Type is set to Stop. 764 A summary of the Acct-Session-Time attribute format is shown below. 765 The fields are transmitted from left to right. 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type | Length | Value 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 Value (cont) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Type 777 46 for Acct-Session-Time. 779 Length 781 6 783 Value 785 The Value field is four octets. 787 5.8. Acct-Input-Packets 789 Description 791 This attribute indicates how many packets have been received from 792 the port over the course of this service being provided to a 793 Framed User, and can only be present in Accounting-Request records 794 where the Acct-Status-Type is set to Stop. 796 A summary of the Acct-Input-packets attribute format is shown below. 797 The fields are transmitted from left to right. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Type | Length | Value 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Value (cont) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Type 809 47 for Acct-Input-Packets. 811 Length 813 6 815 Value 817 The Value field is four octets. 819 5.9. Acct-Output-Packets 821 Description 823 This attribute indicates how many packets have been sent to the 824 port in the course of delivering this service to a Framed User, 825 and can only be present in Accounting-Request records where the 826 Acct-Status-Type is set to Stop. 828 A summary of the Acct-Output-Packets attribute format is shown below. 829 The fields are transmitted from left to right. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Type | Length | Value 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Value (cont) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Type 841 48 for Acct-Output-Packets. 843 Length 845 6 847 Value 849 The Value field is four octets. 851 5.10. Acct-Terminate-Cause 853 Description 854 This attribute indicates how the session was terminated, and can 855 only be present in Accounting-Request records where the Acct- 856 Status-Type is set to Stop. 858 A summary of the Acct-Terminate-Cause attribute format is shown 859 below. The fields are transmitted from left to right. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Type | Length | Value 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 Value (cont) | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Type 871 49 for Acct-Terminate-Cause 873 Length 875 6 877 Value 879 The Value field is four octets, containing an integer specifying 880 the cause of session termination, as follows: 882 1 User Request 883 2 Lost Carrier 884 3 Lost Service 885 4 Idle Timeout 886 5 Session Timeout 887 6 Admin Reset 888 7 Admin Reboot 889 8 Port Error 890 9 NAS Error 891 10 NAS Request 892 11 NAS Reboot 893 12 Port Unneeded 894 13 Port Preempted 895 14 Port Suspended 896 15 Service Unavailable 897 16 Callback 898 17 User Error 899 18 Host Request 900 The termination causes are as follows: 902 User Request User requested termination of service, for 903 example with LCP Terminate or by logging out. 905 Lost Carrier DCD was dropped on the port. 907 Lost Service Service can no longer be provided; for 908 example, user's connection to a host was 909 interrupted. 911 Idle Timeout Idle timer expired. 913 Session Timeout Maximum session length timer expired. 915 Admin Reset Administrator reset the port or session. 917 Admin Reboot Administrator is ending service on the NAS, 918 for example prior to rebooting the NAS. 920 Port Error NAS detected an error on the port which 921 required ending the session. 923 NAS Error NAS detected some error (other than on the 924 port) which required ending the session. 926 NAS Request NAS ended session for a non-error reason not 927 otherwise listed here. 929 NAS Reboot The NAS ended the session in order to reboot 930 non-administratively ("crash"). 932 Port Unneeded NAS ended session because resource usage fell 933 below low-water mark (for example, if a 934 bandwidth-on-demand algorithm decided that 935 the port was no longer needed). 937 Port Preempted NAS ended session in order to allocate the 938 port to a higher priority use. 940 Port Suspended NAS ended session to suspend a virtual 941 session. 943 Service Unavailable NAS was unable to provide requested service. 945 Callback NAS is terminating current session in order 946 to perform callback for a new session. 948 User Error Input from user is in error, causing 949 termination of session. 951 Host Request Login Host terminated session normally. 953 5.11. Acct-Multi-Session-Id 955 Description 957 This attribute is a unique Accounting ID to make it easy to link 958 together multiple related sessions in a log file. Each session 959 linked together would have a unique Acct-Session-Id but the same 960 Acct-Multi-Session-Id. It is strongly recommended that the Acct- 961 Multi-Session-Id be a printable ASCII string. 963 A summary of the Acct-Session-Id attribute format is shown below. 964 The fields are transmitted from left to right. 966 0 1 2 967 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Type | Length | String ... 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Type 974 50 for Acct-Multi-Session-Id. 976 Length 978 >= 3 980 String 982 The String field SHOULD be a string of printable ASCII characters. 984 5.12. Acct-Link-Count 986 Description 988 This attribute gives the count of links which are known to have 989 been in a given multilink session at the time the accounting 990 record is generated. The NAS MAY include the Acct-Link-Count 991 attribute in any Accounting-Request which might have multiple 992 links. 994 A summary of the Acct-Link-Count attribute format is show below. The 995 fields are transmitted from left to right. 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Type | Length | Value 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 Value (cont) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Type 1007 51 for Acct-Link-Count. 1009 Length 1011 6 1013 Value 1015 The Value field is four octets, and contains the number of links 1016 seen so far in this Multilink Session. 1018 It may be used to make it easier for an accounting server to know 1019 when it has all the records for a given Multilink session. When 1020 the number of Accounting-Requests received with Acct-Status-Type = 1021 Stop and the same Acct-Multi-Session-Id and unique Acct-Session- 1022 Id's equals the largest value of Acct-Link-Count seen in those 1023 Accounting-Requests, all Stop Accounting-Requests for that 1024 Multilink Session have been received. 1026 An example showing 8 Accounting-Requests should make things 1027 clearer. For clarity only the relevant attributes are shown, but 1028 additional attributes containing accounting information will also 1029 be present in the Accounting-Request. 1031 Multi-Session-Id Session-Id Status-Type Link-Count 1032 "10" "10" Start 1 1033 "10" "11" Start 2 1034 "10" "11" Stop 2 1035 "10" "12" Start 3 1036 "10" "13" Start 4 1037 "10" "12" Stop 4 1038 "10" "13" Stop 4 1039 "10" "10" Stop 4 1041 5.13. Table of Attributes 1043 The following table provides a guide to which attributes may be found 1044 in Accounting-Request packets. No attributes should be found in 1045 Accounting-Response packets except Proxy-State and possibly Vendor- 1046 Specific. 1048 # Attribute 1049 0-1 User-Name 1050 0 User-Password 1051 0 CHAP-Password 1052 0-1 NAS-IP-Address [Note 1] 1053 0-1 NAS-Port 1054 0-1 Service-Type 1055 0-1 Framed-Protocol 1056 0-1 Framed-IP-Address 1057 0-1 Framed-IP-Netmask 1058 0-1 Framed-Routing 1059 0+ Filter-Id 1060 0-1 Framed-MTU 1061 0+ Framed-Compression 1062 0+ Login-IP-Host 1063 0-1 Login-Service 1064 0-1 Login-TCP-Port 1065 0 Reply-Message 1066 0-1 Callback-Number 1067 0-1 Callback-Id 1068 0+ Framed-Route 1069 0-1 Framed-IPX-Network 1070 0 State 1071 0+ Class 1072 0+ Vendor-Specific 1073 0-1 Session-Timeout 1074 0-1 Idle-Timeout 1075 0-1 Termination-Action 1076 0-1 Called-Station-Id 1077 0-1 Calling-Station-Id 1078 0-1 NAS-Identifier [Note 1] 1079 0+ Proxy-State 1080 0-1 Login-LAT-Service 1081 0-1 Login-LAT-Node 1082 0-1 Login-LAT-Group 1083 0-1 Framed-AppleTalk-Link 1084 0-1 Framed-AppleTalk-Network 1085 0-1 Framed-AppleTalk-Zone 1086 1 Acct-Status-Type 1087 0-1 Acct-Delay-Time 1088 0-1 Acct-Input-Octets 1089 0-1 Acct-Output-Octets 1090 1 Acct-Session-Id 1091 0-1 Acct-Authentic 1092 0-1 Acct-Session-Time 1093 0-1 Acct-Input-Packets 1094 0-1 Acct-Output-Packets 1095 0-1 Acct-Terminate-Cause 1096 0+ Acct-Multi-Session-Id 1097 0+ Acct-Link-Count 1098 0 CHAP-Challenge 1099 0-1 NAS-Port-Type 1100 0-1 Port-Limit 1101 0-1 Login-LAT-Port 1103 [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address 1104 or a NAS-Identifier, and it is permitted (but not recommended) for it 1105 to contain both. 1107 The following table defines the above table entries. 1109 0 This attribute MUST NOT be present 1110 0+ Zero or more instances of this attribute MAY be present. 1111 0-1 Zero or one instance of this attribute MAY be present. 1112 1 Exactly one instance of this attribute MUST be present. 1114 6. Security Considerations 1116 Security issues are discussed in sections concerning the 1117 authenticator included in accounting requests and responses, using a 1118 shared secret which is never sent over the network. 1120 7. Change Log 1122 US-ASCII replaced by UTF-8. 1124 Added notes on Proxy. 1126 Framed-IP-Address should contain the actual IP address of the user. 1128 If Acct-Session-ID was sent in an access-request, it must be used in 1129 the accounting-request for that session. 1131 Interim-Update added to Acct-Status-Type. 1133 8. References 1135 [1] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote 1136 Authentication Dial In User Service (RADIUS)", RFC 2138, 1137 January 1997. 1139 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1140 Levels." BCP14, RFC 2119, March, 1997. 1142 [3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1143 1980. 1145 [4] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", 1146 RFC 1321, April 1992. 1148 [5] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1149 1700, October 1994. 1151 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1152 2279, January 1998. 1154 9. Acknowledgements 1156 RADIUS and RADIUS Accounting were originally developed by Steve 1157 Willens of Livingston Enterprises for their PortMaster series of 1158 Network Access Servers. 1160 10. Chair's Address 1162 The RADIUS working group can be contacted via the current chair: 1164 Carl Rigney 1165 Livingston Enterprises 1166 4464 Willow Road 1167 Pleasanton, California 94588 1169 Phone: +1 925 737 2100 1170 EMail: cdr@livingston.com 1172 11. Author's Address 1174 Questions about this memo can also be directed to: 1176 Carl Rigney 1177 Livingston Enterprises 1178 4464 Willow Road 1179 Pleasanton, California 94588 1181 EMail: cdr@livingston.com 1183 12. Full Copyright Statement 1185 Copyright (C) The Internet Society (1997). All Rights Reserved. 1187 This document and translations of it may be copied and furnished to 1188 others, and derivative works that comment on or otherwise explain it 1189 or assist in its implmentation may be prepared, copied, published and 1190 distributed, in whole or in part, without restriction of any kind, 1191 provided that the above copyright notice and this paragraph are 1192 included on all such copies and derivative works. However, this 1193 document itself may not be modified in any way, such as by removing 1194 the copyright notice or references to the Internet Society or other 1195 Internet organizations, except as needed for the purpose of 1196 developing Internet standards in which case the procedures for 1197 copyrights defined in the Internet Standards process must be 1198 followed, or as required to translate it into languages other than 1199 English. 1201 The limited permissions granted above are perpetual and will not be 1202 revoked by the Internet Society or its successors or assigns. 1204 This document and the information contained herein is provided on an 1205 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1206 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1207 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1208 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1209 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."