Inconsistencies between RFCs and implementations

[Alan DeKok <aland@deployingradius.com>]

  As has been noted recently, RADIUS implementations are largely
inconsistent with the RFCs.  To summarize:

  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".

   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".

  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.

  RFC 2058 and RFC 2138 did not differentiate between textual and binary
data.  This clarification was made in RFC 2865, by creating the "text"
type.  Some implementations made this clarification prior to RFC 2865
being published, and may not have chosen the same names.

  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".

  These inconsistencies and ambiguities were not addressed in RFC 5080
(Issues and fixes).  That document would arguably have been a good place
to resolve these issues.

  The fact that the implementations disagree so clearly with the RFCs,
and so consistently with the RFCs, show that there are major ambiguities
that need to be resolved.  Either the RFCs are wrong, or the
implementations are wrong.  They can't both be correct.

  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.

  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.

 The "data model" document will define the RADIUS data model.  It will
give names and definitions for RADIUS data types, in line with the names
and definitions given in RFC 2865.   It will define *new* types, where
this WG believes that existing types are contradictory or inadequate.
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.

  This document will take 3-4 years to finish, of course.  We will
likely have to delay the design guidelines document, as it will use the
data model document as a normative reference.

  Or, we can perform minor updates to the existing guidelines document
(e.g. replacing integer64 with interface-id), and publish it.

  If the WG decides to split the guidelines document, then I would
suggest finding another editor for the data type document.  I am willing
to finish the guidelines document, but it may be best if I avoided the
data type document.

  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/>