RFC 2866
RADIUS Accounting
RFC 2866: RADIUS Accounting 🎀
okay bestie, this one is RFC 2866, titled RADIUS Accounting 💅 It came out of the Network Working Group in June 2000, written by C. Rigney at Livingston 🧚 Its category is Informational, and it obsoletes RFC 2139 (that's the only relationship it has to other RFCs in this header) 🦋
Status of This Memo ✨
ok so this memo is just giving info to the Internet community 🌸 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💖
Copyright Notice 💜
Copyright (C) The Internet Society (2000). All Rights Reserved. 🔐
Abstract 🦋
this document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server 🫶
Implementation Note 🍓
this memo documents the RADIUS Accounting protocol. early deployment of RADIUS Accounting used UDP port number 1646, which conflicts with the "sa-msg-port" service 😭 The officially assigned port number for RADIUS Accounting is 1813 ✨
Table of Contents 📚
1. Introduction .................................... 2
1.1 Specification of Requirements ................. 3
1.2 Terminology ................................... 3
2. Operation ....................................... 4
2.1 Proxy ......................................... 4
3. Packet Format ................................... 5
4. Packet Types ................................... 7
4.1 Accounting-Request ............................ 8
4.2 Accounting-Response ........................... 9
5. Attributes ...................................... 10
5.1 Acct-Status-Type .............................. 12
5.2 Acct-Delay-Time ............................... 13
5.3 Acct-Input-Octets ............................. 14
5.4 Acct-Output-Octets ............................ 15
5.5 Acct-Session-Id ............................... 15
5.6 Acct-Authentic ................................ 16
5.7 Acct-Session-Time ............................. 17
5.8 Acct-Input-Packets ............................ 18
5.9 Acct-Output-Packets ........................... 18
5.10 Acct-Terminate-Cause .......................... 19
5.11 Acct-Multi-Session-Id ......................... 21
5.12 Acct-Link-Count ............................... 22
5.13 Table of Attributes ........................... 23
6. IANA Considerations ............................. 25
7. Security Considerations ......................... 25
8. Change Log ...................................... 25
9. References ...................................... 26
10. Acknowledgements ................................ 26
11. Chair's Address ................................. 26
12. Author's Address ................................ 27
13. Full Copyright Statement ........................ 281. Introduction ✨
okay so managing dispersed serial line and modem pools for lots of users can create a ton of admin work 😩 Modem pools are literally a link to the outside world, so they need careful attention to security, authorization, and accounting 🔐 The best way to handle that is one single "database" of users. That lets you do authentication (checking username and password) and also keep configuration info about the type of service each user gets, like SLIP, PPP, telnet, or rlogin 💅
The RADIUS (Remote Authentication Dial In User Service) document [2] spells out the RADIUS protocol used for Authentication and Authorization. This memo extends RADIUS so it can also deliver accounting info from the Network Access Server (NAS) to a RADIUS accounting server 🧚
This document obsoletes RFC 2139 [1]. You can see a summary of what changed between this document and RFC 2139 in the "Change Log" appendix 🦋
Key features of RADIUS Accounting are:
- Client/Server Model 🌈
- A Network Access Server (NAS) acts as a client of the RADIUS accounting server. The client is responsible for passing user accounting info to a designated RADIUS accounting server.
- The RADIUS accounting server is responsible for receiving the accounting request and sending back a response to the client that says it was received successfully.
- The RADIUS accounting server can act as a proxy client to other kinds of accounting servers.
- Network Security 🔐
- Transactions between the client and RADIUS accounting server are authenticated with a shared secret, which is never sent over the network 🤫
- Extensible Protocol 🎀
- All transactions are made up of variable length Attribute-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol 💖
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. These key words mean the same thing whether capitalized or not 📏
1.2. Terminology
this document uses the following terms 📖
- service: the NAS provides a service to the dial-in user, like PPP or Telnet 📞
- session: every service the NAS provides to a dial-in user is a session. A session begins at the point where service is first provided and ends at the point where service is ended. A user can have multiple sessions in parallel or in series if the NAS supports that, and each session generates its own separate start and stop accounting record with its own
Acct-Session-Id🔁 - silently discard: this means the implementation throws the packet away without any further processing 🫥 The implementation SHOULD be able to log the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter 📊
2. Operation 🎀
when a client is configured to use RADIUS Accounting, it generates an Accounting Start packet at the start of service delivery. That packet describes the type of service being delivered and the user it's being delivered to. The client sends it to the RADIUS Accounting server, which sends back an acknowledgement that the packet was received 💌 At the end of service delivery, the client generates an Accounting Stop packet describing the type of service that was delivered and, optionally, statistics like elapsed time, input and output octets, or input and output packets 🧾 It sends that to the RADIUS Accounting server too, which sends back an acknowledgement that the packet was received 💅
The Accounting-Request (whether for Start or Stop) is sent to the RADIUS accounting server over the network. It is recommended that the client keep trying to send the Accounting-Request packet until it gets an acknowledgement, using some form of backoff 🔄 If no response comes back within a length of time, the request is re-sent a number of times. The client can also forward requests to an alternate server or servers if the primary server is down or unreachable 🛟 An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. Retry and fallback algorithms are the topic of current research and are not specified in detail in this document 🧪
The RADIUS accounting server MAY make requests of other servers in order to satisfy the request, in which case it acts as a client 🤝
If the RADIUS accounting server is unable to successfully record the accounting packet, it MUST NOT send an Accounting-Response acknowledgment to the client 🚫
2.1. Proxy
see the "RADIUS" RFC [2] for info on Proxy RADIUS. Proxy Accounting RADIUS works the same way, as shown in the example below 👀
- The NAS sends an accounting-request to the forwarding server.
- The forwarding server logs the accounting-request (if desired), adds its
Proxy-State(if desired) after any otherProxy-Stateattributes, updates the Request Authenticator, and forwards the request to the remote server. - The remote server logs the accounting-request (if desired), copies all
Proxy-Stateattributes in order and unmodified from the request to the response packet, and sends the accounting-response to the forwarding server. - The forwarding server strips the last
Proxy-State(if it added one in step 2), updates the Response Authenticator, and sends the accounting-response to the NAS.
a forwarding server MUST not modify existing Proxy-State or Class attributes present in the packet 🛡️
a forwarding server may either handle forwarding in a pass through manner, where it sends retransmissions on as soon as it gets them, or it may take responsibility for retransmissions. The second option makes sense when the network link between the forwarding server and the remote server has very different characteristics than the link between the NAS and the forwarding server 🌸
extreme care should be used when implementing a proxy server that takes responsibility for retransmissions, so that its retransmission policy is robust and scalable 💀🫶
3. Packet Format ✨
okay so bestie, exactly one RADIUS Accounting packet gets tucked into the UDP Data field [4], and the UDP Destination Port is 1813 (decimal) 🎀
when a reply gets generated, the source and destination ports swap places 🦋
this memo documents the RADIUS Accounting protocol. fun fact: early RADIUS Accounting was deployed on UDP port 1646, which clashed with the sa-msg-port service 🙈 the officially assigned port for RADIUS Accounting is 1813, so that's the one we use now 💖
here's the summary of the RADIUS data format. the fields go from left to right 🌸
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-Code
the Code field is one octet and tells you what kind of RADIUS packet you're looking at 👑 when a packet shows up with an invalid Code field, it gets silently discarded. bye bye 🗑️
RADIUS Accounting Codes (decimal) are assigned like this:
4 Accounting-Request
5 Accounting-ResponseIdentifier
the Identifier field is one octet and helps match requests with replies 🧚 the RADIUS server can spot a duplicate request if it has the same client source IP address, the same source UDP port, and the same Identifier within a short span of time 👀
Length
the Length field is two octets. it tells you the length of the whole packet, counting the Code, Identifier, Length, Authenticator and Attribute fields. octets outside the range of the Length field MUST be treated as padding and ignored on reception 🫶 if the packet is shorter than the Length field says, it MUST be silently discarded. the minimum length is 20 and the maximum length is 4095 📏
Authenticator
the Authenticator field is sixteen (16) octets. the most significant octet gets sent first 💅 this value is used to authenticate the messages between the client and the RADIUS accounting server 🔐
Request Authenticator
in Accounting-Request Packets, the Authenticator value is a 16 octet MD5 [5] checksum, and it's called the Request Authenticator 🌈
the NAS and the RADIUS accounting server share a secret 🤫 the Request Authenticator field in Accounting-Request packets holds a one-way MD5 hash calculated over a stream of octets made of: Code + Identifier + Length + 16 zero octets + request attributes + shared secret (where + means concatenation). that 16 octet MD5 hash value then gets stored in the Authenticator field of the Accounting-Request packet 🧮
note that the Request Authenticator of an Accounting-Request can not be done the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password attribute in an Accounting-Request 🙅♀️
Response Authenticator
the Authenticator field in an Accounting-Response packet is called the Response Authenticator 🦋 it holds a one-way MD5 hash calculated over a stream of octets made of: the Accounting-Response Code, Identifier, Length, the Request Authenticator field from the Accounting-Request packet being replied to, and the response attributes if there are any, followed by the shared secret. the resulting 16 octet MD5 hash value is stored in the Authenticator field of the Accounting-Response packet ✨
Attributes
attributes can show up multiple times. when that happens, the order of attributes of the same type SHOULD be preserved 💜 the order of attributes of different types is not required to be preserved, so no stress there 🍓
4. Packet Types 💜
the RADIUS packet type is determined by the Code field in the first octet of the packet 🎀
4.1. Accounting-Request
Description
okay this is the main one 💅 Accounting-Request packets are sent from a client (typically a Network Access Server or its proxy) to a RADIUS accounting server, and they carry info used to provide accounting for a service given to a user 🫶 the client sends a RADIUS packet with the Code field set to 4 (Accounting-Request).
when the server gets an Accounting-Request, it MUST transmit an Accounting-Response reply if it successfully records the accounting packet, and it MUST NOT transmit any reply if it fails to record the accounting packet 🙌
any attribute that's valid in a RADIUS Access-Request or Access-Accept packet is valid in a RADIUS Accounting-Request packet too, EXCEPT that the following attributes MUST NOT be present in an Accounting-Request: User-Password, CHAP-Password, Reply-Message, State 🚫 either NAS-IP-Address or NAS-Identifier MUST be present in a RADIUS Accounting-Request. it SHOULD contain a NAS-Port or NAS-Port-Type attribute, or both, unless the service doesn't involve a port or the NAS doesn't distinguish among its ports 🔌
if the Accounting-Request packet includes a Framed-IP-Address, that attribute MUST contain the IP address of the user 🌸 if the Access-Accept used the special values for Framed-IP-Address telling the NAS to assign or negotiate an IP address for the user, then the Framed-IP-Address (if any) in the Accounting-Request MUST contain the actual IP address that was assigned or negotiated 🧚
here's the summary of the Accounting-Request packet format. the fields go from left to right 💖
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
it's 4 for Accounting-Request 🔢
Identifier
the Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request 🔄 for retransmissions where the contents are identical, the Identifier MUST remain unchanged 🧊
note that if Acct-Delay-Time is included in the attributes of an Accounting-Request, then the Acct-Delay-Time value will be updated when the packet is retransmitted. that changes the content of the Attributes field, so it requires a new Identifier and Request Authenticator 🕰️
Request Authenticator
the Request Authenticator of an Accounting-Request holds a 16-octet MD5 hash value, calculated using the method described in "Request Authenticator" above 🧮
Attributes
the Attributes field is variable in length and contains a list of Attributes 📝
4.2. Accounting-Response
Description
Accounting-Response packets are sent by the RADIUS accounting server to the client to say "yep, got your Accounting-Request and recorded it successfully" 🥰 if the Accounting-Request was recorded successfully, then the RADIUS accounting server MUST transmit a packet with the Code field set to 5 (Accounting-Response). when the client receives an Accounting-Response, the Identifier field is matched with a pending Accounting-Request. the Response Authenticator field MUST contain the correct response for the pending Accounting-Request. invalid packets are silently discarded 🗑️
a RADIUS Accounting-Response is not required to have any attributes in it 🍃
here's the summary of the Accounting-Response packet format. the fields go from left to right 🌈
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
it's 5 for Accounting-Response ✨
Identifier
the Identifier field is a copy of the Identifier field of the Accounting-Request that caused this Accounting-Response 🪞
Response Authenticator
the Response Authenticator of an Accounting-Response holds a 16-octet MD5 hash value, calculated using the method described in "Response Authenticator" above 🔐
Attributes
the Attributes field is variable in length and contains a list of zero or more Attributes 🫧
5. Attributes ✨
okay so attributes are where the juicy details live 💅 RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response. 🎀
Some attributes MAY be included more than once. ✨ How that plays out is attribute specific, and each attribute description spells it out.
The end of the list of attributes is marked by the Length of the RADIUS packet. 🌸
here's the attribute format summary, transmitted left to right 🦋
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🍓
The Type field is one octet. The up-to-date values live in the most recent "Assigned Numbers" RFC [6], so go check there for the latest tea ☕ Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used. This specification concerns the following values:
1-39 (refer to RADIUS document [2])
40 Acct-Status-Type
41 Acct-Delay-Time
42 Acct-Input-Octets
43 Acct-Output-Octets
44 Acct-Session-Id
45 Acct-Authentic
46 Acct-Session-Time
47 Acct-Input-Packets
48 Acct-Output-Packets
49 Acct-Terminate-Cause
50 Acct-Multi-Session-Id
51 Acct-Link-Count
60+ (refer to RADIUS document [2])Length 📏
The Length field is one octet, and it tells you the length of this attribute including the Type, Length and Value fields. 🧚 If an attribute shows up in an Accounting-Request with an invalid Length, the entire request MUST be silently discarded. no drama, just gone 🫥
Value 💜
The Value field is zero or more octets and holds information specific to the attribute. The format and length of the Value field are determined by the Type and Length fields. ✨
Note that none of the types in RADIUS terminate with a NUL (hex 00). 🙈 That includes "text" and "string", which don't end in a NUL (hex 00) either. The Attribute has a length field and does not use a terminator, so the length is the source of truth bestie 👑 Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. 💀 that one is a real warning, be careful!!
The format of the Value field is one of five data types. Note that type "text" is a subset of type "string." 🌈
- text: 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.
- string: 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead.
- address: 32 bit value, most significant octet first.
- integer: 32 bit unsigned value, most significant octet first.
- time: 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. 🕰️
5.1. Acct-Status-Type 🌸
Description
This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). 🎬
It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On, and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off. 🔥
Here's the Acct-Status-Type attribute format, left to right:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
40 for Acct-Status-Type.
Length
6
Value
The Value field is four octets. 🫶 The possible values are:
1 Start
2 Stop
3 Interim-Update
7 Accounting-On
8 Accounting-Off
9-14 Reserved for Tunnel Accounting
15 Reserved for Failed5.2. Acct-Delay-Time ⏰
Description
This attribute indicates how many seconds the client has been trying to send this record for. You can subtract it from the time of arrival on the server to get the approximate time of the event that generated this Accounting-Request. (Network transit time is ignored.) 🧠
Note that changing the Acct-Delay-Time causes the Identifier to change; see the discussion under Identifier above. 🙃
Here's the Acct-Delay-Time attribute format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
41 for Acct-Delay-Time.
Length
6
Value
The Value field is four octets.
5.3. Acct-Input-Octets 📥
Description
This attribute indicates how many octets have been received from the port over the course of this service being provided. It can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 🛑
Here's the Acct-Input-Octets attribute format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
42 for Acct-Input-Octets.
Length
6
Value
The Value field is four octets.
5.4. Acct-Output-Octets 📤
Description
This attribute indicates how many octets have been sent to the port in the course of delivering this service. It can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 💫
Here's the Acct-Output-Octets attribute format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
43 for Acct-Output-Octets.
Length
6
Value
The Value field is four octets.
5.5. Acct-Session-Id 🔑
Description
This attribute is a unique Accounting ID that makes it easy to match start and stop records in a log file. 🗂️ The start and stop records for a given session MUST have the same Acct-Session-Id. An Accounting-Request packet MUST have an Acct-Session-Id. An Access-Request packet MAY have an Acct-Session-Id; if it does, then the NAS MUST use the same Acct-Session-Id in the Accounting-Request packets for that session. 👑
The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters. ✨
For example, one implementation uses a string with an 8-digit upper case hexadecimal number. The first two digits increment on each reboot (wrapping every 256 reboots), and the next 6 digits count from 0 for the first person logging in after a reboot, up to 2^24-1, about 16 million. Other encodings are possible. 🧮 it's giving well-organised chaos 💅
Here's the Acct-Session-Id attribute format:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
44 for Acct-Session-Id.
Length
>= 3
String
The String field SHOULD be a string of UTF-8 encoded 10646 [7] characters.
5.6. Acct-Authentic 🪪
Description
This attribute MAY be included in an Accounting-Request to indicate how the user was authenticated, whether by RADIUS, the NAS itself, or another remote authentication protocol. 🔐 Users who are delivered service without being authenticated SHOULD NOT generate Accounting records. no auth, no accounting, periodt 🙅♀️
Here's the Acct-Authentic attribute format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
45 for Acct-Authentic.
Length
6
Value
The Value field is four octets. 🎀 The possible values are:
1 RADIUS
2 Local
3 Remote5.7. Acct-Session-Time ⏳
Description
This attribute indicates how many seconds the user has received service for. It can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 🏁
Here's the Acct-Session-Time attribute format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
46 for Acct-Session-Time.
Length
6
Value
The Value field is four octets.
5.8. Acct-Input-Packets ✨
Description
okay so this attribute counts how many packets came IN on the port while the service was being given to a Framed User 📦💖 It can ONLY show up in Accounting-Request records where the Acct-Status-Type is set to Stop, so it's the end-of-session wrap-up stat 🎀
Here's how the format looks. Fields go left to right, obviously 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
47 for Acct-Input-Packets 🔥
Length
6 🌸
Value
The Value field is four octets 🧚
5.9. Acct-Output-Packets 🦋
Description
this one is the mirror image bestie 🪞 It shows how many packets were SENT to the port while delivering this service to a Framed User 📤 Same deal: it can only be in Accounting-Request records where the Acct-Status-Type is set to Stop 💜
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
48 for Acct-Output-Packets 🍓
Length
6 ✨
Value
The Value field is four octets 💅
5.10. Acct-Terminate-Cause 💀
Description
this is the "why did it end" attribute 😭 It says how the session got terminated, and again it can ONLY be in Accounting-Request records where the Acct-Status-Type is set to Stop 🛑
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
49 for Acct-Terminate-Cause 🌈
Length
6 🎀
Value
The Value field is four octets, holding an integer that tells you the cause of the session ending. The possible values are:
1 User Request
2 Lost Carrier
3 Lost Service
4 Idle Timeout
5 Session Timeout
6 Admin Reset
7 Admin Reboot
8 Port Error
9 NAS Error
10 NAS Request
11 NAS Reboot
12 Port Unneeded
13 Port Preempted
14 Port Suspended
15 Service Unavailable
16 Callback
17 User Error
18 Host RequestNow the tea on what each one actually means 🫖☕
User Request: the user asked for the service to end, for example with LCP Terminate or by logging out 🙋♀️Lost Carrier: DCD was dropped on the port 📉Lost Service: the service can't be provided anymore, like when the user's connection to a host got interrupted 😵Idle Timeout: the idle timer expired 💤Session Timeout: the maximum session length timer expired ⏰Admin Reset: an administrator reset the port or session 🔧Admin Reboot: an administrator is ending service on the NAS, for example before the NAS gets rebooted 🔄Port Error: the NAS spotted an error on the port that meant the session had to end 🚨NAS Error: the NAS spotted some error (not on the port) that meant the session had to end 🙈NAS Request: the NAS ended the session for a non-error reason that isn't listed anywhere else here 🤷♀️NAS Reboot: the NAS ended the session so it could reboot non-administratively, aka a "crash" 💥Port Unneeded: the NAS ended the session because resource usage dropped below the low-water mark (like when a bandwidth-on-demand algorithm decided the port wasn't needed anymore) 📉✨Port Preempted: the NAS ended the session to give the port to a higher priority use 👑Port Suspended: the NAS ended the session to suspend a virtual session ⏸️Service Unavailable: the NAS couldn't provide the requested service 🙅♀️Callback: the NAS is ending the current session so it can do a callback for a new session 📞User Error: the user's input was wrong, which caused the session to end ✍️Host Request: the Login Host ended the session normally 🏠
5.11. Acct-Multi-Session-Id 🔗
Description
this attribute is a unique Accounting ID that makes it super easy to link together multiple related sessions in a log file 🪢 Each linked session gets its own unique Acct-Session-Id, but they all share the same Acct-Multi-Session-Id, so they're basically a friend group 👯♀️ It is strongly recommended that the Acct-Multi-Session-Id contain UTF-8 encoded 10646 [7] characters 🫶
0 1 2
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 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
50 for Acct-Multi-Session-Id 🌸
Length
>= 3 🧚
String
The String field SHOULD contain UTF-8 encoded 10646 [7] characters 💖
5.12. Acct-Link-Count 🔥
Description
this attribute gives the count of links that are known to have been in a given multilink session at the time the accounting record gets generated 📊 The NAS MAY include the Acct-Link-Count attribute in any Accounting-Request that might have multiple links 🔗
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
51 for Acct-Link-Count 💜
Length
6 ✨
Value
The Value field is four octets, and holds the number of links seen so far in this Multilink Session 🌈
It can help an accounting server figure out when it has ALL the records for a given Multilink session 🕵️♀️ Here's the rule: when the number of Accounting-Requests received with Acct-Status-Type = Stop, the same Acct-Multi-Session-Id, and unique Acct-Session-Ids adds up to the largest Acct-Link-Count value seen in those Accounting-Requests, then every Stop Accounting-Request for that Multilink Session has arrived 🎉
An example with 8 Accounting-Requests should make it clearer 🎀 For clarity, only the relevant attributes are shown, but additional attributes with accounting information will also be present in the Accounting-Request 📝
Multi-Session-Id Session-Id Status-Type Link-Count
"10" "10" Start 1
"10" "11" Start 2
"10" "11" Stop 2
"10" "12" Start 3
"10" "13" Start 4
"10" "12" Stop 4
"10" "13" Stop 4
"10" "10" Stop 45.13. Table of Attributes 📋
The following table is a handy guide to which attributes may be found in Accounting-Request packets 👀 No attributes should be found in Accounting-Response packets except Proxy-State and possibly Vendor-Specific 🙅♀️
# Attribute
0-1 User-Name
0 User-Password
0 CHAP-Password
0-1 NAS-IP-Address [Note 1]
0-1 NAS-Port
0-1 Service-Type
0-1 Framed-Protocol
0-1 Framed-IP-Address
0-1 Framed-IP-Netmask
0-1 Framed-Routing
0+ Filter-Id
0-1 Framed-MTU
0+ Framed-Compression
0+ Login-IP-Host
0-1 Login-Service
0-1 Login-TCP-Port
0 Reply-Message
0-1 Callback-Number
0-1 Callback-Id
0+ Framed-Route
0-1 Framed-IPX-Network
0 State
0+ Class
0+ Vendor-Specific
0-1 Session-Timeout
0-1 Idle-Timeout
0-1 Termination-Action
0-1 Called-Station-Id
0-1 Calling-Station-Id
0-1 NAS-Identifier [Note 1]
0+ Proxy-State
0-1 Login-LAT-Service
0-1 Login-LAT-Node
0-1 Login-LAT-Group
0-1 Framed-AppleTalk-Link
0-1 Framed-AppleTalk-Network
0-1 Framed-AppleTalk-Zone
1 Acct-Status-Type
0-1 Acct-Delay-Time
0-1 Acct-Input-Octets
0-1 Acct-Output-Octets
1 Acct-Session-Id
0-1 Acct-Authentic
0-1 Acct-Session-Time
0-1 Acct-Input-Packets
0-1 Acct-Output-Packets
0-1 Acct-Terminate-Cause
0+ Acct-Multi-Session-Id
0+ Acct-Link-Count
0 CHAP-Challenge
0-1 NAS-Port-Type
0-1 Port-Limit
0-1 Login-LAT-Port[Note 1] An Accounting-Request MUST contain either a NAS-IP-Address or a NAS-Identifier (or both) 🫶
The following table defines the entries above 🧠
0 This attribute MUST NOT be present
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.6. IANA Considerations 🌷
The Packet Type Codes, Attribute Types, and Attribute Values defined in this document get registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS name spaces, as described in the "IANA Considerations" section of RFC 2865 [2], in accordance with BCP 26 [8] 📚✨
7. Security Considerations 🔐
okay bestie, security gets serious here 💀. The security stuff lives in the parts that talk about the authenticator in accounting requests and responses. That authenticator works off a shared secret, and the shared secret is never sent over the network 🔒✨. So it's a secret for real, not a vibe.
8. Change Log 📝
Here's the glow-up history 🦋:
- US-ASCII got replaced by UTF-8 🌈
- Notes on Proxy got added 🧚
- Framed-IP-Address should hold the actual IP address of the user 💜
- If Acct-Session-ID was sent in an access-request, it must be used in the accounting-request for that session 🫶
- New values got added to Acct-Status-Type 🌸
- An IANA Considerations section got added 👑
- References got updated 💅
- Text strings got identified as a subset of string, so the UTF-8 use is clearer 🎀
9. References
Here's the reading list, complete with all the deets 📚💖:
- [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
- [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
- [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [5] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
- [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
- [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10. Acknowledgements 🫶
RADIUS and RADIUS Accounting were originally developed by Steve Willens of Livingston Enterprises for their PortMaster series of Network Access Servers. Iconic origin story, honestly 🌟.
11. Chair's Address 🎀
The RADIUS working group can be reached through the current chair, who is:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com12. Author's Address 💌
If you have questions about this memo, you can also send them to:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: cdr@telemancy.com13. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸
Okay, the legal bit, but I'm keeping every detail. This document and translations of it may be copied and handed out to others. Derivative works that comment on it, explain it, or help with implementing it may be written, copied, published and distributed, in whole or in part, with no real restrictions, as long as the copyright notice and this paragraph are on every copy and derivative work. The document itself may not be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organisations. The exceptions are when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it's needed to translate it into languages other than English.
The permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever 💜.
This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to whoever keeps the lights on for all of this ✨🧚
📦 where this page comes from
- ietf: rfc2866 2000-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms