[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of draft-ietf-radext-rfc3576bis
Section 1.3 Terminology
RFC 3576bis uses different terminology than the RFC 3576 MIBs.
Should we change the terminology in RFC 3576bis to utilize the terms defined
in the RFC 3576 MIB documents? This would involve changing uses of the term
"RADIUS client"/"NAS" to "Dynamic Authorization Server (DAS)" and "RADIUS
server" to "Dynamic Authorization Client (DAC)". Here are the definitions
of these terms from RFC 4673 Section 1.2:
Dynamic Authorization Server (DAS)
The component that resides on the NAS that processes the Disconnect
and Change-of-Authorization (CoA) Request packets [RFC3576] sent by
the Dynamic Authorization Client.
Dynamic Authorization Client (DAC)
The component that sends Disconnect and CoA-Request packets to the
Dynamic Authorization Server. Although this component often resides
on the RADIUS server, it is also possible for it to be located on a
separate host, such as a Rating Engine.
Dynamic Authorization Server Port
The UDP port on which the Dynamic Authorization Server listens for
the Disconnect and CoA requests sent by the Dynamic Authorization
Client.
Section 2.2
The following attributes MAY be sent in a CoA-Request:
Filter-ID (11) - Indicates the name of a data filter list
to be applied for the session that the
identification attributes map to.
NAS-Filter-Rule (TBD) - Provides a filter list to be applied
for the session that the identification
attributes map to.
Maybe we should include a reference to the NAS-Filter-Rule RFC? Also, the
TBD should be filled in when an attribute number is assigned.
Section 2.3
Packets received with an invalid Code field MUST be
silently discarded. RADIUS codes (decimal) for this extension are
assigned as follows:
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
Rather than citing RFC 2882 for the command allocation, RFC 3575 should be
cited instead. The reference to RFC 2882 can be removed.
Section 2.3
In Disconnect and CoA-Request packets, all Attributes are treated
as mandatory. A NAS MUST respond to a CoA-Request containing one
or more unsupported Attributes or Attribute values with a CoA-NAK;
a Disconnect-Request containing one or more unsupported Attributes
or Attribute values MUST be answered with a Disconnect-NAK.
RFC 3576 suggests use of the Event-Timestamp for replay protection. This
requires synchronized clocks, but even when that it is available, the replay
window is quite large. The solution (discussed in Issue 139) was to add a
Nonce attribute. However, the text above suggests that implementations
sending a Nonce attribute to a legacy implementation in a
CoA-Request/Disconnect-Request will receive a CoA-NAK or Disconnect-NAK in
return. Unfortunately, the Error-Cause attribute value Unsupported
Attribute (401) doesn't provide a hint of what the offending attribute was.
Maybe we should add text suggesting that a Nonce attribute should only be
sent by a RADIUS server to a NAS that is known to support it?
As a result, attributes
beyond those specified in Section 3.5 SHOULD NOT be included
within Disconnect or CoA packets, since this could produce
unpredictable results.
Actually, the results are not unpredictable -- the NAS will send a
Disconnect-NAK/CoA-NAK, right? I would suggest that this sentence be
replaced with "As a result, if attributes beyond those specified in Section
3.5 are included with Disconnect-Request or CoA-Request packets, the RADIUS
server may receive a Disconnect-NAK/CoA-NAK in response, possibly containing
an Error-Cause attribute with value Unsupported Attribute (401)."
Section 3.3
A summary of the Nonce 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Is a 32-bit value large enough? Shouldn't this be at least 64-bits and
probably more like 128-bits?
Section 3.5
[Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or
Disconnect-Request packet that is not protected by IPsec or does not
contain an Event-Timestamp Attribute, so as to prevent replay
attacks. A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK,
Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets.
It seems like a bad idea for a NAS to include a Nonce attribute in a
CoA-ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK if a Nonce attribue
wasn't included in the corresponding CoA-Request or Disconnect-Request.
Section 4
# Error-Cause Attribute Value Result-Code AVP
--- --------------------------- ------------------------
201 Residual Session Context DIAMETER_SUCCESS
Removed
202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
(Ignored)
401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
402 Missing Attribute DIAMETER_MISSING_AVP
403 NAS Identification DIAMETER_REALM_NOT_SERVED
Mismatch
404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
501 Administratively DIAMETER_AUTHORIZATION_REJECTED
Prohibited
502 Request Not Routable DIAMETER_UNABLE_TO_DELIVER
(Proxy)
503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
Removable
505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
Error
506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
507 Request Initiated DIAMETER_SUCCESS
Is this mapping of Error-Cause attribute values to Result-Code AVPs correct?
Section 5 IANA Considerations
Much of this section can be deleted since the values were already allocated
in RFC 3576. The only text that seems necessary relates to an allocation
for the Nonce attribute:
This specification does not create any new registries.
This document uses the RADIUS [RFC2865] namespace, see
<http://www.iana.org/assignments/radius-types>. Allocation of one
update for the section "RADIUS Attribute Types" is requested. The
RADIUS attribute for which a value is requested is:
TBD - Nonce
Section 6.1
Alan DeKok has pointed out that the RPF check suggested in this section is
somewhat cumbersome. Do we have an alternative to suggest?
--
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/>