7 Network Working Group C. Rigney
8 Request for Comments: 2059 Livingston
9 Category: Informational January 1996
16 This memo provides information for the Internet community. This memo
17 does not specify an Internet standard of any kind. Distribution of
18 this memo is unlimited.
22 This document describes a protocol for carrying accounting
23 information between a Network Access Server and a shared Accounting
28 1. Introduction .......................................... 2
29 1.1 Specification of Requirements ................... 3
30 1.2 Terminology ..................................... 3
31 2. Operation ............................................. 3
32 3. Packet Format ......................................... 4
33 4. Packet Types .......................................... 6
34 4.1 Accounting-Request .............................. 7
35 4.2 Accounting-Response ............................. 8
36 5. Attributes ............................................ 9
37 5.1 Acct-Status-Type ................................ 11
38 5.2 Acct-Delay-Time ................................. 12
39 5.3 Acct-Input-Octets ............................... 13
40 5.4 Acct-Output-Octets .............................. 13
41 5.5 Acct-Session-Id ................................. 14
42 5.6 Acct-Authentic .................................. 15
43 5.7 Acct-Session-Time ............................... 16
44 5.8 Acct-Input-Packets .............................. 17
45 5.9 Acct-Output-Packets ............................. 17
46 5.10 Acct-Terminate-Cause ............................ 18
47 5.11 Acct-Multi-Session-Id ........................... 20
48 5.12 Acct-Link-Count ................................. 21
49 5.13 Table of Attributes ............................. 22
50 Security Considerations ...................................... 24
51 References ................................................... 24
52 Acknowledgements ............................................. 24
53 Chair's Address .............................................. 25
54 Author's Address ............................................. 25
58 Rigney Informational [Page 1]
60 RFC 2059 RADIUS Accounting January 1997
65 Managing dispersed serial line and modem pools for large numbers of
66 users can create the need for significant administrative support.
67 Since modem pools are by definition a link to the outside world, they
68 require careful attention to security, authorization and accounting.
69 This can be best achieved by managing a single "database" of users,
70 which allows for authentication (verifying user name and password) as
71 well as configuration information detailing the type of service to
72 deliver to the user (for example, SLIP, PPP, telnet, rlogin).
74 The RADIUS (Remote Authentication Dial In User Service) document [4]
75 specifies the RADIUS protocol used for Authentication and
76 Authorization. This memo extends the use of the RADIUS protocol to
77 cover delivery of accounting information from the Network Access
78 Server (NAS) to a RADIUS accounting server.
80 Key features of RADIUS Accounting are:
84 A Network Access Server (NAS) operates as a client of the
85 RADIUS accounting server. The client is responsible for
86 passing user accounting information to a designated RADIUS
89 The RADIUS accounting server is responsible for receiving the
90 accounting request and returning a response to the client
91 indicating that it has successfully received the request.
93 The RADIUS accounting server can act as a proxy client to other
94 kinds of accounting servers.
98 Transactions between the client and RADIUS accounting server
99 are authenticated through the use of a shared secret, which is
100 never sent over the network.
104 All transactions are comprised of variable length Attribute-
105 Length-Value 3-tuples. New attribute values can be added
106 without disturbing existing implementations of the protocol.
108 In this document, several words are used to signify the requirements
109 of the specification. These words are often capitalized.
114 Rigney Informational [Page 2]
116 RFC 2059 RADIUS Accounting January 1997
119 1.1 Specification of Requirements
121 MUST This word, or the adjective "required", means that the
122 definition is an absolute requirement of the specification.
124 MUST NOT This phrase means that the definition is an absolute
125 prohibition of the specification.
127 SHOULD This word, or the adjective "recommended", means that there
128 may exist valid reasons in particular circumstances to
129 ignore this item, but the full implications must be
130 understood and carefully weighed before choosing a
133 MAY This word, or the adjective "optional", means that this
134 item is one of an allowed set of alternatives. An
135 implementation which does not include this option MUST be
136 prepared to interoperate with another implementation which
137 does include the option.
141 This document uses the following terms:
143 service The NAS provides a service to the dial-in user, such as PPP
146 session Each service provided by the NAS to a dial-in user
147 constitutes a session, with the beginning of the session
148 defined as the point where service is first provided and
149 the end of the session defined as the point where service
150 is ended. A user may have multiple sessions in parallel or
151 series if the NAS supports that, with each session
152 generating a separate start and stop accounting record with
153 its own Acct-Session-Id.
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.
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
170 Rigney Informational [Page 3]
172 RFC 2059 RADIUS Accounting January 1997
175 being delivered to, and will send that to the RADIUS Accounting
176 server, which will send back an acknowledgement that the packet has
177 been received. At the end of service delivery the client will
178 generate an Accounting Stop packet describing the type of service
179 that was delivered and optionally statistics such as elapsed time,
180 input and output octets, or input and output packets. It will send
181 that to the RADIUS Accounting server, which will send back an
182 acknowledgement that the packet has been received.
184 The Accounting-Request (whether for Start or Stop) is submitted to
185 the RADIUS accounting server via the network. It is recommended that
186 the client continue attempting to send the Accounting-Request packet
187 until it receives an acknowledgement, using some form of backoff. If
188 no response is returned within a length of time, the request is re-
189 sent a number of times. The client can also forward requests to an
190 alternate server or servers in the event that the primary server is
191 down or unreachable. An alternate server can be used either after a
192 number of tries to the primary server fail, or in a round-robin
193 fashion. Retry and fallback algorithms are the topic of current
194 research and are not specified in detail in this document.
196 The RADIUS accounting server MAY make requests of other servers in
197 order to satisfy the request, in which case it acts as a client.
199 If the RADIUS accounting server is unable to successfully record the
200 accounting packet it MUST NOT send an Accounting-Response
201 acknowledgment to the client.
205 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
206 field [1], where the UDP Destination Port field indicates 1813
209 When a reply is generated, the source and destination ports are
226 Rigney Informational [Page 4]
228 RFC 2059 RADIUS Accounting January 1997
231 A summary of the RADIUS data format is shown below. The fields are
232 transmitted from left to right.
235 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
236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
237 | Code | Identifier | Length |
238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
245 +-+-+-+-+-+-+-+-+-+-+-+-+-
249 The Code field is one octet, and identifies the type of RADIUS
250 packet. When a packet is received with an invalid Code field, it is
253 RADIUS Accounting Codes (decimal) are assigned as follows:
256 5 Accounting-Response
261 The Identifier field is one octet, and aids in matching requests and
266 The Length field is two octets. It indicates the length of the
267 packet including the Code, Identifier, Length, Authenticator and
268 Attribute fields. Octets outside the range of the Length field
269 should be treated as padding and should be ignored on reception. If
270 the packet is shorter than the Length field indicates, it should be
271 silently discarded. The minimum length is 20 and maximum length is
276 The Authenticator field is sixteen (16) octets. The most significant
277 octet is transmitted first. This value is used to authenticate the
278 messages between the client and RADIUS accounting server.
282 Rigney Informational [Page 5]
284 RFC 2059 RADIUS Accounting January 1997
287 Request Authenticator
289 In Accounting-Request Packets, the Authenticator value is a 16
290 octet MD5 [3] checksum, called the Request Authenticator.
292 The NAS and RADIUS accounting server share a secret. The Request
293 Authenticator field in Accounting-Request packets contains a one-
294 way MD5 hash calculated over a stream of octets consisting of the
295 Code + Identifier + Length + 16 zero octets + request attributes +
296 shared secret (where + indicates concatenation). The 16 octet MD5
297 hash value is stored in the Authenticator field of the
298 Accounting-Request packet.
300 Note that the Request Authenticator of an Accounting-Request can
301 not be done the same way as the Request Authenticator of a RADIUS
302 Access-Request, because there is no User-Password attribute in an
305 Response Authenticator
307 The Authenticator field in an Accounting-Response packet is called
308 the Response Authenticator, and contains a one-way MD5 hash
309 calculated over a stream of octets consisting of the Accounting-
310 Response Code, Identifier, Length, the Request Authenticator field
311 from the Accounting-Request packet being replied to, and the response
312 attributes if any, followed by the shared secret. The resulting 16
313 octet MD5 hash value is stored in the Authenticator field of the
314 Accounting-Response packet.
318 Attributes may have multiple instances, in such a case the order of
319 attributes of the same type SHOULD be preserved. The order of
320 attributes of different types is not required to be preserved.
324 The RADIUS packet type is determined by the Code field in the first
338 Rigney Informational [Page 6]
340 RFC 2059 RADIUS Accounting January 1997
343 4.1. Accounting-Request
347 Accounting-Request packets are sent from a client (typically a
348 Network Access Server or its proxy) to a RADIUS accounting server,
349 and convey information used to provide accounting for a service
350 provided to a user. The client transmits a RADIUS packet with the
351 Code field set to 4 (Accounting-Request).
353 Upon receipt of an Accounting-Request, the server MUST transmit an
354 Accounting-Response reply if it successfully records the
355 accounting packet, and MUST NOT transmit any reply if it fails to
356 record the accounting packet.
358 Any attribute valid in a RADIUS Access-Request or Access-Accept
359 packet is valid in a RADIUS Accounting-Request packet, except that
360 the following attributes MUST NOT be present in an Accounting-
361 Request: User-Password, CHAP-Password, Reply-Message, State.
362 Either NAS-IP-Address or NAS-Identifier MUST be present in a
363 RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
364 Port-Type attribute or both unless the service does not involve a
365 port or the NAS does not distinguish among its ports.
367 A summary of the Accounting-Request packet format is shown below.
368 The fields are transmitted from left to right.
371 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
372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
373 | Code | Identifier | Length |
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376 | Request Authenticator |
379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381 +-+-+-+-+-+-+-+-+-+-+-+-+-
385 4 for Accounting-Request.
389 The Identifier field MUST be changed whenever the content of the
390 Attributes field changes, and whenever a valid reply has been
394 Rigney Informational [Page 7]
396 RFC 2059 RADIUS Accounting January 1997
399 received for a previous request. For retransmissions where the
400 contents are identical, the Identifier MUST remain unchanged.
402 Note that if Acct-Delay-Time is included in the attributes of an
403 Accounting-Request then the Acct-Delay-Time value will be updated
404 when the packet is retransmitted, changing the content of the
405 Attributes field and requiring a new Identifier and Request
408 Request Authenticator
410 The Request Authenticator of an Accounting-Request contains a 16-
411 octet MD5 hash value calculated according to the method described
412 in "Request Authenticator" above.
416 The Attributes field is variable in length, and contains a list of
419 4.2. Accounting-Response
423 Accounting-Response packets are sent by the RADIUS accounting
424 server to the client to acknowledge that the Accounting-Request
425 has been received and recorded successfully. If the Accounting-
426 Request was recorded successfully then the RADIUS accounting
427 server MUST transmit a packet with the Code field set to 5
428 (Accounting-Response). On reception of an Accounting-Response by
429 the client, the Identifier field is matched with a pending
430 Accounting-Request. Invalid packets are silently discarded.
432 A RADIUS Accounting-Response is not required to have any
450 Rigney Informational [Page 8]
452 RFC 2059 RADIUS Accounting January 1997
455 A summary of the Accounting-Response packet format is shown below.
456 The fields are transmitted from left to right.
459 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
460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461 | Code | Identifier | Length |
462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
464 | Response Authenticator |
467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
469 +-+-+-+-+-+-+-+-+-+-+-+-+-
474 5 for Accounting-Response.
478 The Identifier field is a copy of the Identifier field of the
479 Accounting-Request which caused this Accounting-Response.
481 Response Authenticator
483 The Response Authenticator of an Accounting-Response contains a
484 16-octet MD5 hash value calculated according to the method
485 described in "Response Authenticator" above.
489 The Attributes field is variable in length, and contains a list of
490 zero or more Attributes.
494 RADIUS Attributes carry the specific authentication, authorization
495 and accounting details for the request and response.
497 Some attributes MAY be included more than once. The effect of this
498 is attribute specific, and is specified in each attribute
501 The end of the list of attributes is indicated by the Length of the
506 Rigney Informational [Page 9]
508 RFC 2059 RADIUS Accounting January 1997
511 A summary of the attribute format is shown below. The fields are
512 transmitted from left to right.
515 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
517 | Type | Length | Value ...
518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 The Type field is one octet. Up-to-date values of the RADIUS Type
524 field are specified in the most recent "Assigned Numbers" RFC [2].
525 Values 192-223 are reserved for experimental use, values 224-240
526 are reserved for implementation-specific use, and values 241-255
527 are reserved and should not be used. This specification concerns
528 the following values:
530 1-39 (refer to RADIUS document [4])
534 43 Acct-Output-Octets
538 47 Acct-Input-Packets
539 48 Acct-Output-Packets
540 49 Acct-Terminate-Cause
541 50 Acct-Multi-Session-Id
543 60+ (refer to RADIUS document [4])
547 The Length field is one octet, and indicates the length of this
548 attribute including the Type, Length and Value fields. If an
549 attribute is received in an Accounting-Request with an invalid
550 Length, the entire request should be silently discarded.
554 The Value field is zero or more octets and contains information
555 specific to the attribute. The format and length of the Value
556 field is determined by the Type and Length fields.
558 The format of the value field is one of four data types.
562 Rigney Informational [Page 10]
564 RFC 2059 RADIUS Accounting January 1997
569 address 32 bit value, most significant octet first.
571 integer 32 bit value, most significant octet first.
573 time 32 bit value, most significant octet first -- seconds
574 since 00:00:00 GMT, January 1, 1970. The standard
575 Attributes do not use this data type but it is presented
576 here for possible use within Vendor-Specific attributes.
578 5.1. Acct-Status-Type
582 This attribute indicates whether this Accounting-Request marks the
583 beginning of the user service (Start) or the end (Stop).
585 It MAY be used by the client to mark the start of accounting (for
586 example, upon booting) by specifying Accounting-On and to mark the
587 end of accounting (for example, just before a scheduled reboot) by
588 specifying Accounting-Off.
590 A summary of the Acct-Status-Type attribute format is shown below.
591 The fields are transmitted from left to right.
594 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
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596 | Type | Length | Value
597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
604 40 for Acct-Status-Type.
618 Rigney Informational [Page 11]
620 RFC 2059 RADIUS Accounting January 1997
625 The Value field is four octets.
637 This attribute indicates how many seconds the client has been
638 trying to send this record for, and can be subtracted from the
639 time of arrival on the server to find the approximate time of the
640 event generating this Accounting-Request. (Network transit time
643 Note that changing the Acct-Delay-Time causes the Identifier to
644 change; see the discussion under Identifier above.
646 A summary of the Acct-Delay-Time attribute format is shown below.
647 The fields are transmitted from left to right.
650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
652 | Type | Length | Value
653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
660 41 for Acct-Delay-Time.
668 The Value field is four octets.
674 Rigney Informational [Page 12]
676 RFC 2059 RADIUS Accounting January 1997
679 5.3. Acct-Input-Octets
683 This attribute indicates how many octets have been received from
684 the port over the course of this service being provided, and can
685 only be present in Accounting-Request records where the Acct-
686 Status-Type is set to Stop.
688 A summary of the Acct-Input-Octets attribute format is shown below.
689 The fields are transmitted from left to right.
692 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
693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
694 | Type | Length | Value
695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
702 42 for Acct-Input-Octets.
710 The Value field is four octets.
712 5.4. Acct-Output-Octets
716 This attribute indicates how many octets have been sent to the
717 port in the course of delivering this service, and can only be
718 present in Accounting-Request records where the Acct-Status-Type
730 Rigney Informational [Page 13]
732 RFC 2059 RADIUS Accounting January 1997
735 A summary of the Acct-Output-Octets attribute format is shown below.
736 The fields are transmitted from left to right.
739 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
740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
741 | Type | Length | Value
742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
749 43 for Acct-Output-Octets.
757 The Value field is four octets.
763 This attribute is a unique Accounting ID to make it easy to match
764 start and stop records in a log file. The start and stop records
765 for a given session MUST have the same Acct-Session-Id. It is
766 strongly recommended that the Acct-Session-Id be a printable ASCII
769 For example, one implementation uses a string with an 8-digit
770 upper case hexadecimal number, the first two digits increment on
771 each reboot (wrapping every 256 reboots) and the next 6 digits
772 counting from 0 for the first person logging in after a reboot up
773 to 2^24-1, about 16 million. Other encodings are possible.
786 Rigney Informational [Page 14]
788 RFC 2059 RADIUS Accounting January 1997
791 A summary of the Acct-Session-Id attribute format is shown below.
792 The fields are transmitted from left to right.
795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
797 | Type | Length | String ...
798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
803 44 for Acct-Session-Id.
811 The String field SHOULD be a string of printable ASCII characters.
817 This attribute MAY be included in an Accounting-Request to
818 indicate how the user was authenticated, whether by RADIUS, the
819 NAS itself, or another remote authentication protocol. Users who
820 are delivered service without being authenticated SHOULD NOT
821 generate Accounting records.
823 A summary of the Acct-Authentic attribute format is shown below. The
824 fields are transmitted from left to right.
827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
829 | Type | Length | Value
830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
837 45 for Acct-Authentic.
842 Rigney Informational [Page 15]
844 RFC 2059 RADIUS Accounting January 1997
853 The Value field is four octets.
859 5.7. Acct-Session-Time
863 This attribute indicates how many seconds the user has received
864 service for, and can only be present in Accounting-Request records
865 where the Acct-Status-Type is set to Stop.
867 A summary of the Acct-Session-Time attribute format is shown below.
868 The fields are transmitted from left to right.
871 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
872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
873 | Type | Length | Value
874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
880 46 for Acct-Session-Time.
888 The Value field is four octets.
898 Rigney Informational [Page 16]
900 RFC 2059 RADIUS Accounting January 1997
903 5.8. Acct-Input-Packets
907 This attribute indicates how many packets have been received from
908 the port over the course of this service being provided to a
909 Framed User, and can only be present in Accounting-Request records
910 where the Acct-Status-Type is set to Stop.
912 A summary of the Acct-Input-packets attribute format is shown below.
913 The fields are transmitted from left to right.
916 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
917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 | Type | Length | Value
919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
926 47 for Acct-Input-Packets.
934 The Value field is four octets.
936 5.9. Acct-Output-Packets
940 This attribute indicates how many packets have been sent to the
941 port in the course of delivering this service to a Framed User,
942 and can only be present in Accounting-Request records where the
943 Acct-Status-Type is set to Stop.
954 Rigney Informational [Page 17]
956 RFC 2059 RADIUS Accounting January 1997
959 A summary of the Acct-Output-Packets attribute format is shown below.
960 The fields are transmitted from left to right.
963 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
964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
965 | Type | Length | Value
966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
973 48 for Acct-Output-Packets.
981 The Value field is four octets.
984 5.10. Acct-Terminate-Cause
988 This attribute indicates how the session was terminated, and can
989 only be present in Accounting-Request records where the Acct-
990 Status-Type is set to Stop.
992 A summary of the Acct-Terminate-Cause attribute format is shown
993 below. The fields are transmitted from left to right.
996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
998 | Type | Length | Value
999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1006 49 for Acct-Terminate-Cause
1010 Rigney Informational [Page 18]
1012 RFC 2059 RADIUS Accounting January 1997
1021 The Value field is four octets, containing an integer specifying
1022 the cause of session termination, as follows:
1038 15 Service Unavailable
1044 The termination causes are as follows:
1046 User Request User requested termination of service, for
1047 example with LCP Terminate or by logging out.
1049 Lost Carrier DCD was dropped on the port.
1051 Lost Service Service can no longer be provided; for
1052 example, user's connection to a host was
1055 Idle Timeout Idle timer expired.
1057 Session Timeout Maximum session length timer expired.
1059 Admin Reset Administrator reset the port or session.
1061 Admin Reboot Administrator is ending service on the NAS,
1062 for example prior to rebooting the NAS.
1066 Rigney Informational [Page 19]
1068 RFC 2059 RADIUS Accounting January 1997
1071 Port Error NAS detected an error on the port which
1072 required ending the session.
1074 NAS Error NAS detected some error (other than on the
1075 port) which required ending the session.
1077 NAS Request NAS ended session for a non-error reason not
1078 otherwise listed here.
1080 NAS Reboot The NAS ended the session in order to reboot
1081 non-administratively ("crash").
1083 Port Unneeded NAS ended session because resource usage fell
1084 below low-water mark (for example, if a
1085 bandwidth-on-demand algorithm decided that
1086 the port was no longer needed).
1088 Port Preempted NAS ended session in order to allocate the
1089 port to a higher priority use.
1091 Port Suspended NAS ended session to suspend a virtual
1094 Service Unavailable NAS was unable to provide requested service.
1096 Callback NAS is terminating current session in order
1097 to perform callback for a new session.
1099 User Error Input from user is in error, causing
1100 termination of session.
1102 Host Request Login Host terminated session normally.
1104 5.11. Acct-Multi-Session-Id
1108 This attribute is a unique Accounting ID to make it easy to link
1109 together multiple related sessions in a log file. Each session
1110 linked together would have a unique Acct-Session-Id but the same
1111 Acct-Multi-Session-Id. It is strongly recommended that the Acct-
1112 Multi-Session-Id be a printable ASCII string.
1122 Rigney Informational [Page 20]
1124 RFC 2059 RADIUS Accounting January 1997
1127 A summary of the Acct-Session-Id attribute format is shown below.
1128 The fields are transmitted from left to right.
1131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1133 | Type | Length | String ...
1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1139 50 for Acct-Multi-Session-Id.
1147 The String field SHOULD be a string of printable ASCII characters.
1149 5.12. Acct-Link-Count
1153 This attribute gives the count of links which are known to have
1154 been in a given multilink session at the time the accounting
1155 record is generated. The NAS MAY include the Acct-Link-Count
1156 attribute in any Accounting-Request which might have multiple
1159 A summary of the Acct-Link-Count attribute format is show below. The
1160 fields are transmitted from left to right.
1163 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
1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1165 | Type | Length | Value
1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1173 51 for Acct-Link-Count.
1178 Rigney Informational [Page 21]
1180 RFC 2059 RADIUS Accounting January 1997
1189 The Value field is four octets, and contains the number of links
1190 seen so far in this Multilink Session.
1192 It may be used to make it easier for an accounting server to know
1193 when it has all the records for a given Multilink session. When
1194 the number of Accounting-Requests received with Acct-Status-Type =
1195 Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
1196 Id's equals the largest value of Acct-Link-Count seen in those
1197 Accounting-Requests, all Stop Accounting-Requests for that
1198 Multilink Session have been received.
1200 An example showing 8 Accounting-Requests should make things
1201 clearer. For clarity only the relevant attributes are shown, but
1202 additional attributes containing accounting information will also
1203 be present in the Accounting-Request.
1205 Multi-Session-Id Session-Id Status-Type Link-Count
1215 5.13. Table of Attributes
1217 The following table provides a guide to which attributes may be found
1218 in Accounting-Request packets. No attributes should be found in
1219 Accounting-Response packets except Proxy-State and possibly Vendor-
1227 0-1 NAS-IP-Address [4]
1234 Rigney Informational [Page 22]
1236 RFC 2059 RADIUS Accounting January 1997
1239 0-1 Framed-IP-Address
1240 0-1 Framed-IP-Netmask
1244 0+ Framed-Compression
1252 0-1 Framed-IPX-Network
1258 0-1 Termination-Action
1259 0-1 Called-Station-Id
1260 0-1 Calling-Station-Id
1261 0-1 NAS-Identifier [4]
1263 0-1 Login-LAT-Service
1266 0-1 Framed-AppleTalk-Link
1267 0-1 Framed-AppleTalk-Network
1268 0-1 Framed-AppleTalk-Zone
1271 0-1 Acct-Input-Octets
1272 0-1 Acct-Output-Octets
1275 0-1 Acct-Session-Time
1276 0-1 Acct-Input-Packets
1277 0-1 Acct-Output-Packets
1278 0-1 Acct-Terminate-Cause
1279 0+ Acct-Multi-Session-Id
1290 Rigney Informational [Page 23]
1292 RFC 2059 RADIUS Accounting January 1997
1295 [4] An Accounting-Request MUST contain either a NAS-IP-Address or a
1296 NAS-Identifier, and it is permitted (but not recommended) for it to
1299 The following table defines the above table entries.
1301 0 This attribute MUST NOT be present
1302 0+ Zero or more instances of this attribute MAY be present.
1303 0-1 Zero or one instance of this attribute MAY be present.
1304 1 Exactly one instance of this attribute MUST be present.
1306 Security Considerations
1308 Security issues are briefly discussed in sections concerning the
1309 authenticator included in accounting requests and responses, using a
1310 shared secret which is never sent over the network.
1314 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
1315 USC/Information Sciences Institute, August 1980.
1317 [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1318 1700, USC/Information Sciences Institute, October 1994.
1320 [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
1321 RFC 1321, MIT Laboratory for Computer Science, RSA Data
1322 Security Inc., April 1992.
1324 [4] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
1325 Authentication Dial In User Service (RADIUS)", RFC 2058,
1330 RADIUS and RADIUS Accounting were originally developed by Livingston
1331 Enterprises for their PortMaster series of Network Access Servers.
1346 Rigney Informational [Page 24]
1348 RFC 2059 RADIUS Accounting January 1997
1353 The RADIUS working group can be contacted via the current chair:
1356 Livingston Enterprises
1357 6920 Koll Center Parkway, Suite 220
1358 Pleasanton, California 94566
1360 Phone: +1 510 426 0770
1361 EMail: cdr@livingston.com
1366 Questions about this memo can also be directed to:
1369 Livingston Enterprises
1370 6920 Koll Center Parkway, Suite 220
1371 Pleasanton, California 94566
1373 EMail: cdr@livingston.com
1402 Rigney Informational [Page 25]
projects / freeradius.git / blob