This page documents the RADIUS Accounting protocol. The Radius Protocol,
as said before, provides the functions of authentication, authorization, and accounting (AAA).
In this page we will explore the third A.
We will describe a protocol for carrying accounting information between
a Network Access Server (NAS) and a shared Accounting Server.
Another functionality of RADIUS is its ability to log information about
dial-in connections. Such information is often used for billing purposes.
Managing dispersed serial line and modem pools for large numbers of
users can create the need for significant administrative support.
Modem pools are operating as links to the outside world, and therefore,
they require careful attention to security, authorization and accounting.
In this document we'll describe how the RADIUS protocol implements a
delivery of accounting information from the NAS to a RADIUS accounting server.
At the beginning of a transaction, the client always sends a RADIUS
accounting packet consisting of two elements to the RADIUS accounting server:
1.
The destination user.
2.
The type of service that occurs in this
transaction.
Whenever such a packet is received by the RADIUS accounting server, the
server immediately sends an acknowledgement that the packet has been received.
At the end of the transaction, the client sends to the RADIUS accounting
server an Accounting Stop packet stating that the transaction is over and some
additional (optional) data, such as the type of service that was delivered,
elapsed time, input and output bytes, or input and output packets and
optionally statistics.
Then the RADIUS accounting server will send back an acknowledgement that
the packet has been received.
The Accounting-Request (whether for Start
or Stop) is transferred to the RADIUS accounting server via the network. The
client should continue attempting to send the Accounting-Request packet until
it receives an acknowledgement by using some form of backoff.
In case no response is returned within a length of time, the request is
re-sent for a number of times. There is
also a possibility for the client to forward requests to an alternate server or
servers in case the primary server is down or unreachable.
If the RADIUS accounting server doesn't succeed to record the accounting
packet, it does not send an Accounting-Response acknowledgment to the client.
As described earlier, RADIUS uses the UDP protocol. The UDP data field
contains only one RADIUS Accounting packet, and
the UDP Destination Port field indicates 1813.
(The officially assigned port number for RADIUS Accounting is 1813,
decimal.)
Click here for a summary of the RADIUS data format.
Code
This field length is one Byte, and it describes the RADIUS packet type.
In case that this field contains an invalid Code field, the packet is
discarded.
RADIUS Accounting Codes (decimal) are assigned as follows:
4 -
Accounting-Request
5 -
Accounting-Response
Authenticator
The Authenticator field is sixteen (16) Bytes.
The most significant byte is transmitted first.
Authenticating between the client and RADIUS accounting server is
achieved by using this field.
Attributes
RADIUS Attributes carry the specific authentication, authorization and
accounting details for the request and response.
Some attributes may be included more than once.
The effect of this is attribute specific,
and is specified in each attribute description.
The RADIUS packet type is determined by the Code field in the first byte
of the packet.
Accounting-Request Description
To perform an Accounting-Request from the client to the RADIUS
accounting server, Accounting-Request packets are sent by the client and convey
information used to provide accounting for a service provided to a user.
The Code field set to 4 (Accounting-Request).
When receiving an Accounting-Request, the server tries to records the
accounting packet, and if it was done successfully, it transmit an
Accounting-Response reply. The server must not transmit any reply if it fails
to record the accounting packet.
Identifier
If the content of the Attributes field changes or whenever a valid reply
has been received for a previous request, the Identifier field must be changed.
For retransmissions where the contents are identical, the Identifier
must remain unchanged.
Request Authenticator
The Request Authenticator of an
Accounting-Request contains a 16-byte hash value
calculated according to a method
which details go beyond the scope of this document.
For further details on this topic see RFC 2866.
Attributes The Attributes field is variable in length, and contains a list of Attributes. Refer to RFC 2866 for information on accounting attributes.
Accounting-Response
Description
After the server received the Accounting-Request, and after it was
recorded successfully, the RADIUS accounting server acknowledges the client by
sending Accounting-Response packets. The packet's Code field is set to 5
(Accounting-Response).
A RADIUS Accounting-Response is not required to have any attributes in
it.
For a summary of the packet format.
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-byte hashvalue calculated according to a method which details go beyond the scope of thisocument (for further details on this topic see: RFC2866
Attributes
The Attributes field is variable in length, and contains a list of zero or more attributes. Refer to Attributes Table for information on accounting attributes.