[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Request for Review: "Issues and Fixes" changes
Here is my review of the "Issues and Fixes" changes (taken from a diff of
-04 and -05):
< A State attribute is REQUIRED in Access-Request packets neither
< including an authentication attribute nor a Service-Type attribute
< with the value Call Check (10).
As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
contain a State attribute. We extend that definition here, to say
that Access-Request packets that contain an authentication attribute
or a Service-Type attribute with the value Call Check (10) MAY
contain a State attribute. Access-Request packets not matching the
above description MUST contain a State attribute.
Does it make sense to include a State attribute in an Access-Request with
a Service-Type attribute with value Call Check (10)? Typically in these
is no state to encode.
I'd rewrite this as follows:
As noted [RFC 2865] Table 5.44, Access-Request packets MAY
contain a State attribute. An Access-Request packet not containing
an authentication attribute or a Service-Type attribute with a value of
Call Check (10) MUST contain a State attribute. If an authentication
attribute is present, then a State Attribute MAY be included.
I think this section needs to note that the suggested algorithms apply not
only to a RADIUS client, but also to a Dynamic Authorization Client, defined
in RFC 3576bis. Either that, or the algorithm text needs to be transplanted
into RFC 3576bis.
Congestive backoff. While it is not necessary for RADIUS client
implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits
suggested by [RFC2865] Section 2.4.
RADIUS retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this
specification. RADIUS is a request/response-based protocol. The
message exchange terminates when the requester successfully
receives the answer or the message exchange is considered to have
failed according to the retransmission mechanism described below.
Is the retransmission algorithm OPTIONAL or RECOMMENDED? The first
paragraph seems to suggest that only congestive backoff is RECOMMENDED, and
that the rest of the text is non-normative. Is that what is intended? I'd
suggest that we say something like "A potential retransmission algorithm is
included below" to make that that clear, if that is what is meant.
MRD specifies an upper bound on the length of time a sender may
retransmit a message. The message exchange fails once MRD seconds
have elapsed since the client first transmitted the message. MRD
MUST be set, and SHOULD have a value between 5 and 30 seconds.
These values mirror the values for a servers duplicate detection
cache, as described in the next section.
MRC specifies an upper bound on the number of times a sender may
retransmit a message. if MRC is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted
the message. If MRC is non-zero, the message exchange fails when
the either the sender has transmitted the message MRC times, or
when MRD seconds have elapsed since the client first transmitted
This could have some unforseen (and potentially adverse) impacts on RADIUS
accounting. Today, some RADIUS accounting clients continue to retransmit
for long periods of time, intentionally, in order to improve reliability.
If there is an upper bound on the number of times a sender may retransmit an
accounting message, then accounting messages could be lost in situations
where today they would be delivered. So I think this needs to be changed.
The issue that this section is attempting to address is the seeming
[RFC2865] Section 1.1 which states:
A NAS that does not implement a given service MUST NOT implement
the RADIUS attributes for that service. For example, a NAS that
is unable to offer Apple Remote Access Protocol (ARAP) service
MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead.
and [RFC2865] Section 5 which states:
A RADIUS server MAY ignore Attributes with an unknown Type.
A RADIUS client MAY ignore Attributes with an unknown Type.
As I recall, the conclusion was that the advice of Section 1.1 applies to
known attributes, so that if a NAS receives an attribute that is known and
represents a service, but is not implemented, it is treated as an
Access-Reject. Whereas if the attribute is not known, then it MAY be
The question was then what the behavior is for a NAS encountering an unknown
attribute. Given the MAY in Section 5, behavior can only be recommended,
not mandated, because of backward compatibility.
It is possible for either a standard attribute or VSA to represent a
request for an unavailable service. However, where the Type or
Vendor-ID is unknown, a RADIUS client will not know whether the
attribute defines a service or not.
[BA] Actually the problem could also arise if the Vendor-ID is known, but
the Vendor Type is not, right?
In general, it is best for RADIUS clients to err on the side of
caution. On receiving an Access-Accept including an attribute of
unknown Type, a RADIUS client SHOULD assume that it is a potential
service definition, and treat it as an Access-Reject. Unknown VSAs
SHOULD be ignored by RADIUS clients.
[BA] My recommendation would be to add a clarification of the meaning of
In general, it is best for a RADIUS clients to err on the side of caution.
On receiving an
Access-Accept including an attribute of known Type for an unimplemented
service, a RADIUS client MUST treat it as an Access-Reject, as directed in
[RFC2865] Section 1.1. On receiving an Access-Accept including an attribute
of unknown Type, a RADIUS client SHOULD assume that it is a potential
service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD
be ignored by RADIUS clients.
As there may be interoperability issues with the above suggestion,
client implementations SHOULD make the suggested behavior
configurable. A configuration flag such as "treat unknown attributes
as reject" can be exposed to the system administrator. If the flag
is set to true, then Access-Accepts containing unknown attributes are
treated as Access-Rejects. If the flag is set to false, then unknown
attributes in Access-Accepts are be silently ignored. The default
value for the flag SHOULD be set to true.
I think what we are trying to say here is that existing implementations that
ignore unknown attributes should probably not change to treating them as an
Access-Reject by default, or else on upgrading the NAS, the users could see
an unexpected change in behavior. In this situation, configuration would be
helpful, but the legacy behavior should be the default, probably. However,
where the existing implementation already implements the recommended
behavior, there is no point in introducing configuration. Here is a
In order to avoid introducing changes in default behavior, existing
implementations that do not obey this recommendation should make the
behavior configurable, with the legacy behavior being enabled by default. A
configuration flag such as "treat unknown attributes as reject" can be
exposed to the system administrator. If the flag is set to true, then
Access-Accepts containing unknown attributes are treated as Access-Rejects.
If the flag is set to false, then unknown
attributes in Access-Accepts are be silently ignored.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.