Subject: Inconsistencies between RFCs and implementations

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Oct 2009 18:28:25 -0400

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Oct 2009 20:44:32 -0700

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

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. 

[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?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 28 Oct 2009 09:54:43 -0400

> document lies outside the appropriate role of a BCP.

  Creating a RADIUS data model could arguably be outside of the role of
a BCP.  However, pointing out that one exists would likely be within the
role of a BCP.

> be within the scope of the Extended Attributes document.  

  I would suggest codifying the data model, rather than remaking it.
The data model has already largely been codified in the implementations.
 If these are wrong, then we could say that no RADIUS implementations
exist.  If they are right, then documenting what the implementations
have done would remake nothing.

> changes do we need to make? 

  We need to change integer64 -> ifid, or something similar.  We need to
achieve WG consensus that the current document reflects current
practice, and that the current practice is acceptable.

  I suggest also adding a sentence or two describing the implicit versus
explicit nature of the RADIUS data model, and the failure of RFC 3162
et. al. to follow the "data type definition" framework shown in RFC 2865.

  Alan DeKok.