guidelines compatible with existing RADIUS RFCs. As a result, RADIUS
operational model issues discussed in Section 3.3 contain citations
to existing RFCs.
In this particular case, while RFC 2866 indicates that there are no
required attributes in an Accounting-Response, it doesn't prohibit
them. So is the issue the inclusion of attributes, or is it the use
of those attributes?
From Section 4.2:
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). On reception of an Accounting-Response by
the client, 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.
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.
Join me |
> Date: Sat, 13 Dec 2008 10:16:53 +0100
> From: aland@deployingradius.com
> To: radiusext@ops.ietf.org
> Subject: Issue with Guidelines document
>
> This might be a little late, but it may be worth adding one more note:
>
> ---
> Accounting-Response packets SHOULD contain only Proxy-State.
>
> State changes in the RADIUS client based on Accounting-Response
> packets are NOT RECOMMENDED. They do not fit within the traditional
> RADIUS operational model. Despite the text in [RFC2866] Section 5.13
> saying that "possibly" Vendor-Specific is permitted, such use is NOT
> RECOMMENDED.
> ---
>
>
> Is it too late for this? Do we have Area Director agreement that this
> is a good idea?
>
> The background is a growing number of NAS equipment that I'm seeing
> which *does* look for attributes in an Accounting-Response. It's not
> clear what the NAS does with those attributes, but internal state
> changes are a logical conclusion.
>
> Alan DeKok.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>