4.3 The Accounting Packet Format

As mentioned in Chapter 2, the RADIUS protocol uses a UDP foundation to transmit packets between clients , servers, and proxies. While the original RADIUS accounting RFC (number 2139, to be exact) specified that accounting transactions should take place on port 1646, the latest RFC (2866) changed the port to 1813, because port 1646 was already assigned to the sa-msg-port service.

The packets are broken down into four distinct regions , which are discussed next .

4.3.1 Code

The code region is one-octet long and indicates the type of RADIUS accounting information transmitted in that packet. Packets with invalid code fields are thrown away without notification. Valid codes are:

4

Accounting-Request

5

Accounting-Response

4.3.2 Identifier

The identifier region is one-octet long and is used to perform threading, or the automated linking of initial requests and subsequent replies. RADIUS accounting servers can generally intercept duplicate messages by examining such factors as the source IP address, the source UDP port, the time span between the suspect messages, and the identifier field.

4.3.3 Length

The length region is two-octets long and is used to specify the length of a RADIUS accounting message. The value in this field is calculated by analyzing the code, identifier, length, authenticator, and attribute fields and finding their sum. The length field is checked to ensure data integrity when an accounting server receives a packet. Valid length values range between 20 and 4095.

The RFC specification requires certain behaviors of RADIUS servers with regard to incorrect length data. If the accounting server receives a transmission with a message longer than the length field, it ignores all data past the end point designated in the length field. Conversely, if the server receives a shorter message than the length field reports , the server will discard the message.

4.3.4 Authenticator

The authenticator region, often 16-octets long, is the field in which the integrity of the packet's payload is inspected and verified . In this field, the most important octetthe value used to authenticate replies from the accounting serveris transmitted before any other.

There are two distinct types of authenticators: the request and response authenticators. Request authenticators, consisting of 16-octet MD5 checksums, are computed using a hash generated from the code, identifier, length, attributes, shared secrets, and 16 "zeroed-out" octets. The value returned from this hash is then placed into the authenticator field.

It's important to notice the distinction between how the request authenticator is computed in the accounting phase and the authentication/authorization phase. The difference lies squarely in the fact that in accounting packets, the User-Password attribute is not included.

The response authenticator is calculated in much the same way as the request authenticator. An MD5 hash is generated using the values from the code, identifier, length, request authenticator from the original request, and response attributes; the value from this hash is placed in the authenticator field.

It also is important to point out that some early RADIUS and NAS implementations send some accounting packets with the authenticator region set to all zeroes. While the RFCs have been modified to specifically forbid this behavior, for backward compatibility purposes some RADIUS servers can accept packets exhibiting this behavior.

4.3.5 Reliability of Accounting

While the specification for RADIUS accounting is promising , experience sees that accounting packets are not a sure, 100% certainty . For example, if a client sends accounting packets to a server but receives no acknowledgment or response, he will continue to send the same packet for only a limited time. This results in some sessions with inconsistent records. This presents problems with operations that require great consistency and accuracy: billing is a prime but certainly not sole example. While progress is being made in improving the reliability of the accounting mechanism ( mainly with interim records, which are covered in Chapter 9), you should be aware of the problem.