[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Inconsistencies between RFCs and implementations
Alan DeKok said:
" As has been noted recently, RADIUS implementations are largely
inconsistent with the RFCs."
[BA] Actually, I think that it would be more accurate to say that
RADIUS RFCs after RFC 2865-2869 did not consistently utilize the
same conventions to describe data typing, namely to include the
data type in the value field.
" RFC 2865 defines an "address" data type for IPv4 addresses. Going
back to the original Livingston server, pretty much every implementation
calls this data type "ipv4addr". Even within RFC 2865, the upper-case
"Address" name is used to define attributes, instead of using the
"address" name given earlier in the document.
RFC 3162 uses the "Address" data type for IPv6 address. This
contradicts the definition of "address" in RFC 2865. Most
implementations have chose to resolve the ambiguity by calling this data
type "ipv6addr"."
[BA] Neither of these cases seems particularly difficult.
" RFC 3162 uses the name "Interface-Id" to describe interface Id's.
This data type (if it is a data type) is not otherwise described
anywhere in that document. Many implementations have chosen to resolve
the ambiguity by calling this data type "ifid".
[BA] I could see Interface-ID being implemented as a special type
(if IPv6 address notation were used), or alternatively as an octet
string. However, I do agree with Glen that integer64 is unlikely.
" RFC 2867 uses the name "Lost" to describe the data type of
Acct-Tunnel-Packets-Lost. This data type (if it is a data type) is not
otherwise described anywhere in that document. Many implementations
have chosen to resolve the ambiguity by defining the attribute as an
"integer" data type."
[BA] That seems reasonable to me. The value in question is in fact
an unsigned number of 32-bits.
RFC 2868 defines "tags". However, for non-integer attributes, the
type "String" is used, rather than "text", even when the data is clearly
meant to be textual (e.g. Tunnel-Server-Endpoint). Some implementations
have chosen to arbitrarily classify these attributes using the RFC 2865
definitions "text" and "string", independent of the RFC 2868
definitions. Some implementations have instead created new data types
such as "tagged-string", and "tagged-integer".
[BA] Either way, the RFC 2868 tagging scheme is what it is, and this is
now widely implemented.
" The goal of the guidelines document is to clarify these issues, as
part of recommending best practices for RADIUS specifications. However,
it would seem that updating a RADIUS data model would be inappropriate
for a BCP document."
[BA] The goal of the guidelines document is just to provide guidelines
for RADIUS attribute design. Early on, WG consensus was that the
document should not advocate major changes in existing practice, but
merely describe what has been done in the past. As long as the
description of past practice is accurate and the guidelines are
sensible and representative of WG consensus, then the guidelines
document has done its job. It is not necessary for the guidelines
document to address every potential inconsistency in the RADIUS
specifications. For example, in situations where a reasonable person
might interpret the documents differently, it is acceptable
to point out the ambiguity and leave it at that.
" As such, I suggest splitting the document into two. One will define
the RADIUS data model, be standards track, and explicitly update the
previous RFCs to clarify the above contradictions. The other will be
the remainder of the guidelines document, which gives only guidelines."
[BA] Since the guidelines document is just a BCP, it shouldn't be
updating existing standards. So when you say the "remainder of the
guidelines document" this makes me wonder what part of the guidelines
document lies outside the appropriate role of a BCP.
"It will define *new* types, where this WG believes that existing types
are contradictory or inadequate."
[BA] During prior WG discussion, there was a general aversion to a large
scale remake of the RADIUS data model (e.g. attempts to converge the model
with Diameter). However, the addition of some modest enhancements might
be within the scope of the Extended Attributes document.
"It will contain a detailed review of each and every RADIUS attribute
defined in any specification. It will specify the new types for each
attribute."
[BA] As you have noted, in many cases implementers have come to the
same conclusion about the data types intended for use with attributes.
There are a few isolated cases (which we have been discussing) where
implementations may differ, but I'm not sure that this is widespread
enough to justify such a major effort.
" Or, we can perform minor updates to the existing guidelines document
(e.g. replacing integer64 with interface-id), and publish it."
[BA] My preference would be for minor updates, with the goal of
addressing the outstanding issues. Where the specifications are
genuinely ambiguous about the types being defined, the document can
state that, but can leave resolution to the future.
Assuming we restrict additional work to that scope, what remaining
changes do we need to make?
--
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/>