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]
added
removed
doc/rfc/rfc2059.txt
