Subject: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 Oct 2009 17:48:31 +0700

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Thursday, October 22, 2009 4:41 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and
unjustified

Description of issue: The definition of RADIUS IPv6 "data types" arbitrary
and unjustified

Submitter name: Glen Zorn

Submitter email address: [email-masked]

Date first submitted: 22 October 2009

Document: draft-ietf-radext-design-09

Comment type: T

Priority: S

Section: 2.1.1

Rationale/Explanation of issue:
The section in question states:
   In addition to these data types, follow-on RADIUS specifications
   define attributes using the following additional types:

   IPv6 address   128 bit value, in network byte order.
   IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
                  128 bits of value, in network byte order.
   integer64      64 bit unsigned value, in network byte order
                  This type has also been used to represent an IPv6
                  interface identifier.

   Examples of the IPv6 address type include NAS-IPv6-Address defined in
   [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   Section 2.4.  The IPv6 prefix type is used in [RFC3162] Section 2.3,
   and in [RFC4818] Section 3.  The integer64 type is used for the ARAP-
   Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
   the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
   [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
   length, but denotes it as type String.

   Given that attributes of type IPv6 address, IPv6 prefix, and
   integer64 are already in use, it is RECOMMENDED that RADIUS server
   implementations include support for these additional basic types, in
   addition to the types defined in [RFC2865].

However, simply examining the references shows that none of the RFCs cited
define _any_ "data types".  The claim made is arbitrary and unjustified;
essentially, the author is inventing the "data types" out of thin air.

Requested change:
Either delete the entire section or modify it to be a more reasonable and
justified _description_ of formats that have been previously used in RADIUS
to carry quantities related to IPv6, rather than using irrelevant references
to attempt to justify the  _prescription_ of future behavior.  

--
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: Alan DeKok <[email-masked]>
Date: Thu, 22 Oct 2009 14:46:36 +0200

Glen Zorn wrote:
> define _any_ "data types".

  Unfortunately, I know how to use "grep".

$ grep "data type" rfc2865.txt
...
      The format of the value field is one of five data types.  Note
                standard Attributes do not use this data type but it is
...

  That was difficult.  Now let's read the document in more detail to see
what it says.  From RFC 2865 Section 5, Page 25:

      The format of the value field is one of five data types.  Note
      that type "text" is a subset of type "string".

  It goes on to name the five data types, and give definitions for each
one.  These data types are then used in the attribute definitions in RFC
2865, and in other RADIUS RFCs.

  In addition, this text is taken from RFC 2058, which was written over
a decade ago, and says:

	The format of the value field is one of four data types.

  Of course, that isn't the whole story.  To highlight the irony (or
hypocrisy), these data types are used by you in RFCs that you either
authored or co-authored:

	RFC 2548
	RFC 2867
	RFC 2868
	RFC 3162

> to attempt to justify the  _prescription_ of future behavior.  

  This issue should be rejected out of hand.  The concept of "data
types" goes back to the beginning of RADIUS, and was part of the
original protocol specification.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Oct 2009 15:00:41 +0200

>> define _any_ "data types".

  And to fore-stall any discussion about IPv6... the RFCs referenced
*do* define RADIUS "value" fields that carry IPv6 addresses.

  Since RFC 2865 defines the "value" field of attributes to carry "data
types", and the IPv6 RFC you co-authored lists the "value" field as
carrying an IPv6 address, the only possible conclusion is that you have
personally created and defined the "ipv6 address" data type.

  The alternative is to conclude that the document you wrote specifying
the "value" field as an "IPv6 Address" does not, in fact, specify any
data type for that field.

  i.e. The statement that the field is an "Ipv6 address", and the
definition of it as "Address of 16 octets" should instead be interpreted
to mean "string of undistinguished octets with no obvious meaning".

  The only possible way to conclude that IPv6 data types don't exist in
RADIUS is to disown the documents that you wrote.  I expect that you
will therefore shortly file errata for those RFCs, withdrawing all
statements that the "value" field of IPv6 attributes have any meaning.

  I expect that you will, of course, also re-name the attributes at the
same time.  For example, "NAS-IPv6-Address" should be renamed as
"NAS-String-Of-No-Meaning".

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 Oct 2009 20:49:39 +0700

>   Unfortunately, I know how to use "grep".

Even more unfortunately, you don't seem to know how to read.  The original
message read "However, simply examining the references shows that none of
the RFCs cited define _any_ "data types", the "RFCs cited" being 3162, 2869,
4818 & 4675 but not 2865.  Please start making sense.

> 2865, and in other RADIUS RFCs.

Show us.  I've already given multiple counter-examples from RFC 2865; can
you just show one?

> original protocol specification.

The data types in question are "IPv6 address", "IPv6 prefix" and
"integer64".  These do not exist as "data types" in any existing RFC.  If
you can't make sense, at least pay attention.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 Oct 2009 21:21:11 +0700

Alan DeKok [mailto:[email-masked]] writes:

>   And to fore-stall any discussion about IPv6... 

By all means, since that was the subject of the comment.

> the RFCs referenced
> types", 

Indeed it does, in section 5.  More specifically, it says "The format of the
value field is one of five data types."  Which of the five is "IPv6
Address"?  (It also ignores this statement almost entirely, as do the
majority of RADIUS RFCs.)

> and the IPv6 RFC you co-authored lists the "value" field as

Let me see if I've got this straight: I, and my co-authors, were actually
_inventing_ new RADIUS data types but were just too stupid to know it;
further, it was OK back then to "invent" new RADIUS data types back then
(because you have given your stamp of approval) but now & forevermore it's
bad because you say so.  

> data type for that field.

There is another, less anal-retentive alternative: that the string of octets
does, in fact, represent an IPv6 address.  That's it, and that's pretty much
what the RFC says.

> definition of it as "Address of 16 octets" 

RFC 3126 does not contain those words.  

> should instead be
> interpreted

OK, so what is the "data type" of the Login-IPv6-Host Attribute?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Oct 2009 16:47:15 +0200

Glen Zorn wrote
> does, in fact, represent an IPv6 address.  That's it, and that's pretty much

a) fix RFC 3162 to use the RFC 2865 data types

  or

b) agree that IPv6 data types were defined by you in RADIUS.

  You seem to have chosen (b).

  Therefore, your objection that the "guidelines" document invents the
IPv6 address data type has been withdrawn.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 22 Oct 2009 07:47:06 -0700

Glen Zorn said:

"There is another, less anal-retentive alternative: that the string of
octets
does, in fact, represent an IPv6 address.  That's it, and that's pretty much
what the RFC says."

If that were the case, why didn't the document use the term "String" in
defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of
"Address"?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Oct 2009 16:51:45 +0200

> defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of

  I've filed an errata against RFC 3162 to clarify this point.

  Either RFC 3162 is wrong, and those attributes are of type "string",
OR Glen's objection to the guidelines document is wrong, and RFC 3162
defines an IPv6 address type.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 24 Oct 2009 17:03:45 -0700

Alan DeKok said:

"  This issue should be rejected out of hand.  The concept of "data
types" goes back to the beginning of RADIUS, and was part of the
original protocol specification."

Given that the Design Guidelines document has already been approved for
publication by the IESG, the bar for making changes is extremely high.  

In this case, that bar does not appear to have been reached. 
RFC 3162 defines several attributes as being of type "address". 
Since the addresses in question were IPv6 addresses, and RFC 2865
utilizes the IPv4 address type for similar attributes within IPv4,
it is not much of a stretch to conclude that RFC 3162 defines the
IPv6 address type.  

Therefore I would propose that Issue 320 be resolved as REJECT.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 10:56:13 +0700

Bernard Aboba [mailto://[email-masked]] writes:

> publication by the IESG, 

In actual point of fact, this assertion is incorrect: the Issue Tracker
shows that the draft in question is in the state "IESG Evaluation",
sub-state "AD Followup"; this does not translate to "approved for
publication".  In fact, the description of the "AD Followup" sub-state
suggests that the resolution of issues is no longer up to the WG Chairs: "A
generic substate indicating that the shepherding AD has the action item to
determine appropriate next steps. In particular, the appropriate steps (and
the corresponding next state or substate) depend entirely on the nature of
the issues that were raised and can only be decided with active involvement
of the shepherding AD."

> the bar for making changes is extremely high.

I'm sorry, I would have thought that the bar for publication of a document
as an RFC would have been considerably higher.

> RFC 3162 defines several attributes as being of type "address".

Where?  The expected phrase would be "is of type address" or something
similar, which doesn't appear in the document.  It does, however, _name_ a
single attribute as "NAS-IPv6-Address but that is stated simp0ly to be "16
octets".  Furthermore, the description of the Login-IPv6-Host attribute (one
of the attributes which draft-ietf-radext-design-09 cites as justification
for an "IPv6 Address" data type) specifies special meanings for 2 values of
the "Address" field.  Do all "IPv6 Address" data types have the same
semantics?  If not, then draft-ietf-radext-design-09 is in error.

> utilizes the IPv4 address type for similar attributes within IPv4,

Hmm.  The practice of making bald assertions of opinion without basis in
fact seems to be contagious ;-).  As many people have noted over the years,
although RFC2865 defines the "address" data type, no attributes are defined
to be of type "address" in that document.

> it is not much of a stretch to conclude that RFC 3162 defines the

One can conclude virtually anything if one begins with a false premise...

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 25 Oct 2009 00:57:06 -0700

Alan DeKok said:

"  It goes on to name the five data types, and give definitions for each
one.  These data types are then used in the attribute definitions in RFC
2865, and in other RADIUS RFCs."

Section 5 is unambiguous on this point:

"     The format of the value field is one of five data types.  Note
      that type "text" is a subset of type "string".

      text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

      address   32 bit value, most significant octet first.

      integer   32 bit unsigned value, most significant octet first.

      time      32 bit unsigned value, most significant octet first --
                seconds since 00:00:00 UTC, January 1, 1970.  The
                standard Attributes do not use this data type but it is
                presented here for possible use in future attributes.
"

Moreover, within the value field of each attribute, RFC 2865 includes the
data type:

a. "String" for type string.
b. "Address" for type address
c. "Value" for type integer
d. "Text" for type text

No attributes of type time are defined in RFC 2865 or 2866. 

Looking at other RADIUS RFCs, the inclusion of the data type within the
value field is less consistent. 

For example, RFC 2867, includes a type of "Lost" in Section 4.2 for
Acct-Tunnel-Packets-Lost (4 octets).  It seems likely that this attribute
was intended as type integer, rather than a "lost" data type. 

In RFC 2869, the term "Value" is used in the value field for attributes that
are not integers (e.g. ARAP-Challenge-Response in Section 5.15). 

RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although the
"Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4).

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 22:03:23 +0700

> b. "Address" for type address

Is a netmask considered an address?

> c. "Value" for type integer

Wow, I am really amazed!  I don't know how many times I've read that RFC &
never noticed the apparently 1-1 correlation between naming the "Value"
field of an attribute "Value" and the contents of that field being an
integer (though with special "flag" values sometimes).  I'm really very
impressed, but does that really qualify as "unambiguous"?

> was intended as type integer, rather than a "lost" data type.

Actually, it seems much more likely to me that the field was named
descriptively (I know it's insane, but then Alan DeKok wasn't around to show
us the True Way ;-).  Additionally, in 2866, the "Value" field of the
Acct-Multi-Session-Id attribute is named "String", but its contents are
specified as UTF-8 encoded 10646 characters (the definition of the "text"
type).

> "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4).

So am I to understand that, despite the multitude of counterexamples and the
lack of any explicit text even suggesting such in any RADIUS-related RFC,
you are claiming that the name of the V field in the TLV construct denotes a
formal data type (a thing apparently known only to some secret society
holding the same "internally consistent belief system" (thought police,
anyone? ;-)?

...

---

From: "Dave Nelson" <[email-masked]>
Date: Sun, 25 Oct 2009 11:49:59 -0400

Glen Zorn writes...

> So am I to understand that, despite the multitude of counterexamples
> and the lack of any explicit text even suggesting such in any RADIUS-
> related RFC, you are claiming that the name of the V field in the TLV
> construct denotes a formal data type (a thing apparently known only to
> some secret society holding the same "internally consistent belief 
> system" (thought police, anyone? ;-)?

Well, your previous posting claiming to be able to implement an advanced
server implementation that intuits the syntax of a data model from the data
stream itself notwithstanding, RADIUS *has* a formal, written data model.
Many implementations rely on it.  It's a very simple data model.

I think this extended discussion of what constitutes a "formal" definition
of a new data type in the data model constitutes "protocol lawyering", a
debate about form without any substance.

In seeking to debunk some of these data model additions, you are apparently
attempting to build a case for the precedence of using the RADIUS String
data type to contain non-self-describing data structures.  This has been a
point of debate in the RADEXT WG for several years.  The WG consensus is
captured in the Design Guidelines draft.  The String data type should be
used for actual strings, or for opaque blobs of binary data, for use in some
other protocol component, e.g. EAP.  There are specific exemptions to this
recommendation that are spelled out in the draft.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Oct 2009 00:31:05 +0700

Dave Nelson [mailto://[email-masked]] writes:

> server implementation 

Actually, I didn't claim to be able to implement it myself, nor to have done
so,  The server I have was done by people a _lot_ smarter than me.

> that intuits the syntax of a data model from the
> data
> stream itself notwithstanding, 

Isn't that the definition of a data-driven parser?  

> RADIUS *has* a formal, written data
> model.

So simple and so unnecessary (probably why it is so rarely used).  One of
the beauties of the TLV format is that the type completely defines the
value.

> debate about form without any substance.

OK, then how do you know the data type of a new attribute?  Is the Value
field of the Login-IPv6-Host attribute of type "IPv6 address"?  If so, do
_all_ attributes of type "IPv6 address" assign special meaning to the values
0 & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF?  If not, then it's mot of type "IPv6
address" is it?  A set of formal data types without any way to distinguish
between them is useless, except for use as a bludgeon.  If you really want
to develop a real data model for RADIUS, shouldn't it clarify the protocol
operation instead of muddying it?

> data type to contain non-self-describing data structures.  

Not at all.  As I mentioned above, RADIUS attributes are completely defined
by the Type and the description.  

> This has
> been a
> captured in the Design Guidelines draft.  

"Consensus" in this WG is, quite frankly, a joke.

> The String data type should
> be

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 25 Oct 2009 14:11:16 -0700

> recommendation that are spelled out in the draft.

In many ways, this argument has long been Overtaken By Events (OBE).  RADIUS
is what it is, and very widely deployed protocol.  The Design Guidelines only
attempts to describe RADIUS as it is, not what it should become. 

The job of defining what RADIUS could become is the task of the Extended
Attributes document.  Given that all IESG DISCUSSes have been cleared,
it's now time for the WG to get past these (largely irrelevant) arguments
and move on.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Oct 2009 13:06:00 +0700

Bernard Aboba  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

In many ways, this argument has long been Overtaken By Events (OBE).  RADIUS
is what it is, and very widely deployed protocol.  The Design Guidelines
only
attempts to describe RADIUS as it is, not what it should become. 

OK, so now I'm completely confused.  If the purpose of the document isn't to
give guidance regarding the design of future attributes, what is it?  Aside
from that, even as a description of RADIUS "as it is" the document fails,
since it denigrates without justification (aside from the spurious "code
change" argument) the so-called "complex" attributes that have been part of
RADIUS for almost a decade.

.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Oct 2009 07:23:38 -0700

Glen said:

"Aside from that, even as a description of RADIUS “as
it is” the document fails, since it denigrates without justification
(aside from the spurious “code change” argument) the so-called “complex”
attributes that have been part of RADIUS for almost a decade."

The original goal was just to describe the complex attributes, not to denigrate them.  What specific text is problematic? 
…

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Oct 2009 18:09:23 -0400

Glen Zorn wrote:
> address" is it?

  We can solve this problem by noting how it was solved in RFC 2865.  As
Glen keeps pointing out, the RFCs are definitive, and much better than
anything anyone can come up with today.

  RFC 2865 defines an "address" type of 4 octets.  This address type is
used for NAS-IP-Address, which has no values of special meaning.  The
*exact same* address type is used for Framed-IP-Address, which *does*
have values with special meaning.

  We can conclude:

a) The Elder Gods were wrong: NAS-IP-Address and Framed-IP-Address
   are really of different types

b) the Elder Gods were right: NAS-IP-Address and Framed-IP-Address
   are of the same type.

  If (a), then we need to issue an update to RFC 2865, correcting its
flaws.  (And possibly burning the Elder Gods at the stake for being wrong.)

  If (b), then we can follow the example of the Elder Gods, and believe
that NAS-IPv6-Address, and Login-IPv6-Host are of the same type: IPv6
address.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Oct 2009 18:50:37 -0400

Bernard Aboba wrote:
...
> c. "Value" for type integer

  These are issues of inconsistency and terminology in the RFCs.  The
RFCs have always used "address" for IPv4 addresses.  Pretty much every
implementation I've seen uses "ipaddr" as the name of that data type.

  Similarly with other data types.  Where they are simple and often
re-used, implementations define names that are *different* from the
RFCs.  e.g. "ipv6addr", and "ifid" for IPv6 address, and Interface Id.

> value field is less consistent. 

  Which is the source of the current discussion.  If the documents had
followed the practice of RFC 2865, they could have contained a section
describing the data types that they were defining.  They failed to do
that, so we now have curious claims about addresses being IPv6... and
not IPv6, all at the same time.  (Depending on which argument best suits
the current message, consistency be damned.)

> was intended as type integer, rather than a "lost" data type. 

  The implementations I know of use the type "integer" for this attribute.

> are not integers (e.g. ARAP-Challenge-Response in Section 5.15). 

  Agreed.

> "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). 

  Which is to even the most naive reader, not the same as the "address"
field defined in RFC 2865.  Hence my recent errata.

  However, everyone "knows" that the Address type in RFC 3162 refers to
IPv6 address.  The only disagreement is the message-by-message reasoning
of Glen, where it *is* an IPv6 address in one message, and
simultaneously *not* a new IPv6 address in another.

  Personally, it matters less to me whether we call it "Address", or
"IPv6 address", or "magic fairy dust".  All I want is a consistent
definition, so that I can talk about it without someone accusing me of
inventing the definition.

  I would ask for a definition from Glen, but it's clear that his
definitions are contradictory.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Oct 2009 10:33:08 -0400

> to be of type "address" in that document.

  This statement is a bald-faced lie.

  From RFC 2865:

...

5.4.  NAS-IP-Address
...
   Address

      The Address field is four octets.

  Other attributes use the "Address" type, too.

  The only way to make your statement true is to claim that the
"address" data type define on page 25 is not, in fact, the "Address"
data type used in Section 5.4.

  When you make statements that can be refuted by reading the RFCs, it's
as much as admitting that your opinions have no basis in reality.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Oct 2009 14:06:29 -0700

Given the tone of recent conversation, putting "Civility" and "RADEXT WG" in the same sentence, let alone next to each other, may seem incongruous. 

Yet, civility within the IETF is an essential ingredient that allows the organization to continue to function. 

This does not represent a constraint on the technical arguments that can be made.   If you have an opinion on a technical matter that you'd like to share with WG participants, by all means speak up. 

Personalizing the arguments is where we draw the line.  

"I disagree with your line of reasoning because..."  is fundamentally different from "If you don't agree with me, you are a moron." 

The former is acceptable behavior among WG participants.  The latter is not. 

To quote from Wikipedia:

"Incivility consists of personal attacks, rudeness, and aggressive behaviours that disrupt the project and lead to unproductive stress and conflict... a few, minor, isolated incidents of incivility are not in themselves a
major concern. A behavioral pattern of incivility is disruptive and
unacceptable...  if it rises to the level of harassment or egregious personal attacks. A single act of incivility can also cross the line if it is severe enough: for instance, extreme verbal abuse or profanity directed at another contributor, or a threat against another person...

In general, be understanding and non-retaliatory in dealing with incivility.
If others are uncivil, be understanding (people do say things when they
get upset) rather than judgemental, and do not respond in kind. If
necessary, point out gently that you think the comment might be
considered uncivil, and make it clear that you want to move on and
focus on the content issue. Bear in mind that... standards vary. Consider too the option of
ignoring isolated examples of incivility, and simply moving forward ... Only take things to dispute resolution (see below) if there is an ongoing problem you can't resolve.

This policy is not a weapon to use against other contributors."