RFC 2139
RADIUS Accounting
RFC 2139: RADIUS Accounting 🎀
- Series: Network Working Group 🌸
- Request for Comments: 2139 ✨
- Author: C. Rigney, Livingston 💖
- Date: April 1997 🗓️
- Category: Informational 🧚
- Obsoletes: RFC 2059 💅 (this one replaces it, bestie)
- Updates: nothing listed 🙈
Status of this Memo 📜
okay so this memo is giving "information for the Internet community" 💁♀️. It does NOT set an Internet standard of any kind, and distribution is totally unlimited 🌈.
Abstract ✨
this doc describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. That's the whole main-character plot 🦋.
Implementation Note 🔥
so the RADIUS Accounting protocol was documented here, and there was some confusion about port numbers 🙃. Early deployments used port 1646, which clashes with the "sa-msg-port" service 💀. The officially assigned port for RADIUS Accounting is 1813 💜. Remember 1813, the real one 🫶.
Table of Contents 🗂️
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Operation ............................................. 4
3. Packet Format ......................................... 5
4. Packet Types .......................................... 7
4.1 Accounting-Request .............................. 7
4.2 Accounting-Response ............................. 8
5. Attributes ............................................ 10
5.1 Acct-Status-Type ................................ 11
5.2 Acct-Delay-Time ................................. 12
5.3 Acct-Input-Octets ............................... 13
5.4 Acct-Output-Octets .............................. 14
5.5 Acct-Session-Id ................................. 14
5.6 Acct-Authentic .................................. 15
5.7 Acct-Session-Time ............................... 16
5.8 Acct-Input-Packets .............................. 16
5.9 Acct-Output-Packets ............................. 17
5.10 Acct-Terminate-Cause ............................ 18
5.11 Acct-Multi-Session-Id ........................... 20
5.12 Acct-Link-Count ................................. 21
5.13 Table of Attributes ............................. 22
Security Considerations ...................................... 24
References ................................................... 24
Acknowledgements ............................................. 24
Chair's Address .............................................. 24
Author's Address ............................................. 251. Introduction 🌷
okay so managing dispersed serial line and modem pools for a ton of users can take serious admin support 😩. Modem pools are literally a link to the outside world, so they need careful attention to security, authorization and accounting 🔐. The bestie move is managing one single "database" of users 💾. That covers authentication (checking user name and password) and also config info saying what kind of service to hand out, like SLIP, PPP, telnet or rlogin 📞.
The RADIUS (Remote Authentication Dial In User Service) document [4] is where the RADIUS protocol for Authentication and Authorization lives 🧠. This memo extends RADIUS so it can deliver accounting info from the Network Access Server (NAS) to a RADIUS accounting server 🚀.
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 in charge of passing user accounting info to a designated RADIUS accounting server 📨. The accounting server receives the accounting request and sends back a response saying it got it successfully 💌. The RADIUS accounting server can also act as a proxy client to other kinds of accounting servers 🪞.
- Network Security 🔒: transactions between the client and the RADIUS accounting server are authenticated with a shared secret, and that secret is never sent over the network 🤫.
- Extensible Protocol 🧩: every transaction is made 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 📋
In this document, several words are used to signify the requirements of the specification 🎯. These words are often capitalized 💅.
- MUST: this word, or the adjective "required", means the definition is an absolute requirement of the specification 🔥.
- MUST NOT: this phrase means the definition is an absolute prohibition of the specification 🚫.
- SHOULD: this word, or the adjective "recommended", means there may exist valid reasons in particular circumstances to ignore this item. But the full implications must be understood and carefully weighed before choosing a different course 🤔.
- MAY: this word, or the adjective "optional", means this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option 🦋.
1.2. Terminology 📖
This document uses the following terms 💕:
- service 🛎️: the NAS provides a service to the dial-in user, such as PPP or Telnet.
- session 🎟️: each service the NAS provides to a dial-in user counts as a session. A session begins at the point where service is first provided and ends at the point where service is ended. A user may have multiple sessions in parallel or in series if the NAS supports that, and each session generates a separate start and stop accounting record with its own Acct-Session-Id 🌈.
- silently discard 🤐: the implementation discards the packet without any further processing. The implementation SHOULD provide the capability of logging 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 arrived 💌. At the end of service delivery, the client generates an Accounting Stop packet describing the type of service that was delivered, and optionally stats like elapsed time, input and output octets, or input and output packets 📈. It sends that to the RADIUS Accounting server too, which again sends back an acknowledgement 💖.
The Accounting-Request (whether it's for Start or Stop) is submitted 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 set 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. No receipt for a packet it couldn't record, bestie 🚫💅.
3. Packet Format 📦
Exactly one RADIUS Accounting packet is encapsulated in the UDP Data field [1], where the UDP Destination Port field indicates 1813 (decimal) 🎯.
When a reply is generated, the source and destination ports are reversed 🔄.
This memo documents the RADIUS Accounting protocol. There has been some confusion in the assignment of port numbers for this protocol. The early deployment of RADIUS Accounting was done using the erroneously chosen port number 1646, which conflicts with the "sa-msg-port" service. The officially assigned port number for RADIUS Accounting is 1813 🙃✨.
A summary of the RADIUS data format is shown below. The fields are transmitted 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 identifies the type of RADIUS packet. When a packet is received with an invalid Code field, it is silently discarded 🗑️.
RADIUS Accounting Codes (decimal) are assigned as follows 📇:
- 4: Accounting-Request
- 5: Accounting-Response
Identifier 🪪
The Identifier field is one octet, and helps match requests with replies 🧷.
Length 📏
The Length field is two octets. It indicates the length of the packet, including the Code, Identifier, Length, Authenticator and Attribute fields 📐. Octets outside the range of the Length field should be treated as padding and should be ignored on reception 🧹. If the packet is shorter than the Length field indicates, it should be silently discarded 💨. The minimum length is 20 and the maximum length is 4096 🌟.
Authenticator 🔐
The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first 🥇. This value is used to authenticate the messages between the client and the RADIUS accounting server 💜.
Request Authenticator 🔐
okay so in Accounting-Request packets, the Authenticator value is a 16 octet MD5 [3] checksum, and it's called the Request Authenticator 💖
The NAS and 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 + just means concatenation 🧩). That 16 octet MD5 hash value 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: the Accounting-Response Code, Identifier, Length, the Request Authenticator field from the Accounting-Request packet being replied to, and the response attributes if any, followed by the shared secret. The resulting 16 octet MD5 hash value gets stored in the Authenticator field of the Accounting-Response packet 🎀
Attributes 🧁
Attributes can show up more than once, and in that case 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
Accounting-Request packets get sent from a client (typically a Network Access Server or its proxy) to a RADIUS accounting server 📤 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) 💌
Once 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 also valid in a RADIUS Accounting-Request packet, 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 🌈
A summary of the Accounting-Request packet format is shown below. The fields are transmitted 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
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 and requires a new Identifier and Request Authenticator. 💀
Request Authenticator
The Request Authenticator of an Accounting-Request contains a 16-octet MD5 hash value, calculated according to 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 acknowledge that the Accounting-Request has been received and recorded 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. Invalid packets are silently discarded 🙅♀️
A RADIUS Accounting-Response is not required to have any attributes in it 🌷
A summary of the Accounting-Response packet format is shown below. The fields are transmitted 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
5 for Accounting-Response 🦋
Identifier
The Identifier field is a copy of the Identifier field of the Accounting-Request which caused this Accounting-Response 🪞
Response Authenticator
The Response Authenticator of an Accounting-Response contains a 16-octet MD5 hash value, calculated according to 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 🎀
RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response 💼
Some attributes MAY be included more than once 🌈 What that does is attribute specific, and it's spelled out in each attribute description 📖
The end of the list of attributes is indicated by the Length of the RADIUS packet 📏
A summary of the attribute format is shown below. The fields are transmitted from 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 🍓 Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [2]. 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 [4])
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 [4])Length
The Length field is one octet, and indicates the length of this attribute including the Type, Length and Value fields. If an attribute is received in an Accounting-Request with an invalid Length, the entire request should be silently discarded 🗑️
Value
The Value field is zero or more octets and contains information specific to the attribute. The format and length of the Value field is determined by the Type and Length fields 🧮
The format of the Value field is one of four data types 💅
string 0-253 octets
address 32 bit value, most significant octet first.
integer 32 bit value, most significant octet first.
time 32 bit value, most significant octet first -- seconds
since 00:00:00 GMT, January 1, 1970. The standard
Attributes do not use this data type but it is presented
here for possible use within Vendor-Specific 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 🔌
A summary of the Acct-Status-Type attribute format is shown below. The fields are transmitted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
40 for Acct-Status-Type 🧸
Length
6
Value
The Value field is four octets 🫧
1 Start
2 Stop
7 Accounting-On
8 Accounting-Off5.2. Acct-Delay-Time 🕰️
Description
This attribute indicates how many seconds the client has been trying to send this record for. It can be subtracted from the time of arrival on the server to find the approximate time of the event generating 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 🔄
A summary of the Acct-Delay-Time attribute format is shown below. The fields are transmitted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Okay bestie, this one counts how many octets came IN through the port over the whole time the service was being provided. 🌊 It can ONLY show up in Accounting-Request records where the Acct-Status-Type is set to Stop. 💅
A quick peek at the Acct-Input-Octets format is below. The fields go 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
42 is the type for Acct-Input-Octets. 🎀
Length
6 💖
Value
The Value field is four octets. 🫶
5.4. Acct-Output-Octets 📤
Description
This is the mirror image of the last one! 🪞 It tells you how many octets were sent OUT to the port while delivering the service. Like Acct-Input-Octets, it can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 🦋
Here's the format, left to right as always. 🌸
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 is the type for Acct-Output-Octets. 🍓
Length
6 ✨
Value
The Value field is four octets. 💜
5.5. Acct-Session-Id 🔑
Description
This one is the unique Accounting ID that makes start and stop records easy to match up in a log file. 🗂️ Ngl, it's the main character of matching! 👑 The start and stop records for a given session MUST have the same Acct-Session-Id. Non-negotiable, bestie. 🙅♀️ It is strongly recommended that the Acct-Session-Id be a printable ASCII string. 🔤
For example, one implementation uses a string with an 8-digit upper case hexadecimal number. The first two digits increment on each reboot and wrap every 256 reboots. The next 6 digits count from 0 for the first person logging in after a reboot, going up to 2^24-1, which is about 16 million. Other encodings are possible. 🧚
Here's the format, 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 | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
44 is the type for Acct-Session-Id. 🌈
Length
>= 3 💖
String
The String field SHOULD be a string of printable ASCII characters. 🔤✨
5.6. Acct-Authentic 🪪
Description
This attribute MAY be included in an Accounting-Request to show how the user was authenticated. That could be by RADIUS, by the NAS itself, or by another remote authentication protocol. 🛡️ Users who are given service without being authenticated SHOULD NOT generate Accounting records. Bestie, no ID, no records! 🙅♀️💅
Here's the 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
45 is the type for Acct-Authentic. 🎀
Length
6 🌸
Value
The Value field is four octets, and it's an integer with these meanings: 🔢
1 RADIUS
2 Local
3 Remote5.7. Acct-Session-Time ⏱️
Description
This one tells you 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. Time's up, bestie! 💀
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
46 is the type for Acct-Session-Time. 💖
Length
6 ✨
Value
The Value field is four octets. 🫶
5.8. Acct-Input-Packets 📦
Description
This one counts how many packets came IN through the port while the service was being provided to a Framed User. 📥 It can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 🧚
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
47 is the type for Acct-Input-Packets. 🎀
Length
6 💜
Value
The Value field is four octets. 🦋
5.9. Acct-Output-Packets 📨
Description
The outbound packet counterpart! 🔥 This one tells you how many packets were sent OUT to the port while delivering the service to a Framed User. Same rule as always: it can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 🛑
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
48 is the type for Acct-Output-Packets. 🍓
Length
6 ✨
Value
The Value field is four octets. 💅
5.10. Acct-Terminate-Cause 🚪
Description
This one spills the tea on HOW the session ended. ☕ It can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. 🙈
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
49 is the type for Acct-Terminate-Cause. 🌈
Length
6 🎀
Value
The Value field is four octets, containing an integer that specifies the cause of session termination. Here's the lineup: 🔢👑
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 RequestAnd here's what each one actually means, bestie. 🫶
User Request User requested termination of service, for
example with LCP Terminate or by logging out.
Lost Carrier DCD was dropped on the port.
Lost Service Service can no longer be provided; for
example, user's connection to a host was
interrupted.
Idle Timeout Idle timer expired.
Session Timeout Maximum session length timer expired.
Admin Reset Administrator reset the port or session.
Admin Reboot Administrator is ending service on the NAS,
for example prior to rebooting the NAS.
Port Error NAS detected an error on the port which
required ending the session.
NAS Error NAS detected some error (other than on the
port) which required ending the session.
NAS Request NAS ended session for a non-error reason not
otherwise listed here.
NAS Reboot The NAS ended the session in order to reboot
non-administratively ("crash").
Port Unneeded NAS ended session because resource usage fell
below low-water mark (for example, if a
bandwidth-on-demand algorithm decided that
the port was no longer needed).
Port Preempted NAS ended session in order to allocate the
port to a higher priority use.
Port Suspended NAS ended session to suspend a virtual
session.
Service Unavailable NAS was unable to provide requested service.
Callback NAS is terminating current session in order
to perform callback for a new session.
User Error Input from user is in error, causing
termination of session.
Host Request Login Host terminated session normally.5.11. Acct-Multi-Session-Id 🧩
Description
This is the unique Accounting ID that links together multiple related sessions in a log file. 🔗 Each session linked together would have its own unique Acct-Session-Id, but they'd all share the same Acct-Multi-Session-Id. Squad goals! 👯♀️💖 It is strongly recommended that the Acct-Multi-Session-Id be a printable ASCII string. 🔤
Format, 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 | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeType
50 is the type for Acct-Multi-Session-Id. 🌸
Length
>= 3 💜
String
The String field SHOULD be a string of printable ASCII characters. 🔤🫶
5.12. Acct-Link-Count ✨
Description 💖
okay so this attribute tells the server how many links have been part of a given multilink session at the moment the accounting record gets made 📊 the NAS MAY include the Acct-Link-Count attribute in any Accounting-Request that might have multiple links 🦋
Type 🎀
51 for Acct-Link-Count 🌸
Length 📏
6
Value 💅
ngl this one is a little bit iconic 👑 the Value field is four octets and holds the number of links seen so far in this Multilink Session ✨
it helps an accounting server figure out when it has every record for a given Multilink session 🧚 here's the logic: once the number of Accounting-Requests received with Acct-Status-Type = Stop, sharing the same Acct-Multi-Session-Id and unique Acct-Session-Id's, equals the biggest Acct-Link-Count value seen in those requests, then all the Stop Accounting-Requests for that Multilink Session have arrived 🙌
here's an example with 8 Accounting-Requests so it's easier to picture 💜 only the relevant attributes are shown, but the Accounting-Request will also carry more attributes with accounting info 🍓
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 📋
this table is your cheat sheet for which attributes can show up 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 [5]
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 [4]
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[5] An Accounting-Request MUST contain either a NAS-IP-Address or a NAS-Identifier, and it is permitted (but not recommended) for it to contain both. ⚠️
heads up bestie, that [5] note is the big one: an Accounting-Request MUST contain either a NAS-IP-Address or a NAS-Identifier 🚨 it's allowed to have both, but that's not recommended 💀
the table below defines what the entries above mean 🌈
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.Security Considerations 🔒
okay bestie, this part is SERIOUS 😭 security issues get briefly covered in the sections about the authenticator that goes inside accounting requests and responses 🛡️ that authenticator uses a shared secret, and that secret is never sent over the network 🤫🔐
References 📚
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.
[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992.
[4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
Acknowledgments 🫶
RADIUS and RADIUS Accounting were originally developed by Livingston Enterprises for their PortMaster series of Network Access Servers 🌟
Chair's Address 🎀
The RADIUS working group can be contacted via the current chair:
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Phone: +1 510 426 0770 EMail: cdr@livingston.com
Author's Address 💌
Questions about this memo can also be directed to:
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
EMail: cdr@livingston.com
📦 where this page comes from
- ietf: rfc2139 1997-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms