Subject: Issue 272 resolution

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

Some time ago I suggested a solution for this problem in the form of
splitting the Ext-Type field in two, one octet being the actual Ext-Type &
the other becoming an "AVP-Type.  There has been almost no discussion of
this proposal; since there is other work waiting upon the disposition of
this problem, I will make the changes I described this week unless I hear
loud screams to the contrary.

--
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: Sun, 12 Oct 2008 09:02:22 +0200

> loud screams to the contrary.

  I won't scream, but I will ask politely: what the heck is an AVP type?

  We discussed this a while ago, and I'm still not clear on what it is,
or what it does.  Perhaps examples would help.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 12 Oct 2008 16:25:02 +0700

>   I won't scream, but I will ask politely: what the heck is an AVP

Sorry, I should have said "TLV".

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Oct 2008 07:53:58 +0200

> Sorry, I should have said "TLV".

  Which rather begs the question: what is it, and what does it do?

  The WG has already agreed to have 16-bit extended types.  What benefit
is there to splitting this into 8-bit "extended" type, and 8-bit "tlv" type?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 13 Oct 2008 13:01:31 +0700

>   Which rather begs the question: what is it, and what does it do?

With all due respect, have you read the draft & the issue?

> is there to splitting this into 8-bit "extended" type, and 8-bit "tlv"

With all due respect, have you read the draft & the issue?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Oct 2008 08:31:52 +0200

> With all due respect, have you read the draft & the issue?

  Yes.  The draft discusses 16-bit types.  Not 8 bit "extended" and
another 8-bit "tlv".  Issue 272 says that the attributes don't have an
"overall type".

  I don't know what an "overall type" is.  We already have "extended
types", so it can't be that.  Maybe data types?  But RADIUS doesn't
traditionally encode data types in the packet.  Maybe it's grouping...
but we already have tags for grouping.  Maybe it's sub-types, but I had
previously asked, and received a vague answer that could be interpreted
as "no".

  Maybe examples could help, rather than saying "type type type type" ?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 13 Oct 2008 14:14:13 +0700

>   Maybe examples could help, rather than saying "type type type type" ?

Look at RFC 2548, in particular the MS-CHAP*-Response, MS-CHAP-CPW-?, etc.
attributes.  Those are perfect examples of what cannot be done with Extended
Attributes as currently defined.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Oct 2008 10:44:58 +0200

> Attributes as currently defined.  

  They can be carried in legacy RADIUS.  The extended types are just
legacy RADIUS attributes with 16-bit types.

  Or do you mean de-capsulating the contents of the MS-CHAP-* attributes
into multiple attributes?  e.g. MS-CHAP(foo=1, bar=2, ...)  3GPP does
this, WiMAX does this.

  I was sure the idea was brought up on this list, too.  What was the
result of that discussion?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 13 Oct 2008 16:30:27 +0700

> legacy RADIUS attributes with 16-bit types.

No, they aren't, Extended Attributes are a slight extension of RFC 2865
VSAs.

...

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Oct 2008 11:44:34 +0200

> No, they aren't, Extended Attributes are a slight extension of RFC 2865

  Which again begs the question.

  I offered a number of possible descriptions of what the change could
be.  You haven't agreed with, or denied, any of them.

  If the proposed change has no clear definition, I don't see how it can
be used by anyone.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 13 Oct 2008 17:59:21 +0700

> be.  You haven't agreed with, or denied, any of them.

Actually, I did: VSAs have a fundamentally different structure from the rest
of the standard attributes (see below); therefore, your claim that "[t]he
extended types are just legacy RADIUS attributes with 16-bit types" is
patent nonsense.  

>   If the proposed change has no clear definition, I don't see how it

I could have sworn that 272 was pretty clear.  Oh, well.  As noted above,
the Extended Attributes use a format directly derived from RFC 2865 VSAs
(the only difference is the addition of the 'More' and 'Tag' fields.  RFC
2865 states:

5.26.  Vendor-Specific

   Description

      This Attribute is available to allow vendors to support their own
      extended Attributes not suitable for general usage.  It MUST not
      affect the operation of the RADIUS protocol.

      Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

   A summary of the Vendor-Specific Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      26 for Vendor-Specific.

   Length

      >= 7

   Vendor-Id

      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order, as defined in the "Assigned Numbers" RFC [6].

   String

      The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

Note the words "a sequence of vendor type / vendor length / value fields";
vendor Type/Length/Value == TLV, I'm not inventing any new terminology here.
There's just one problem with this definition, it doesn't allow the
assignment of a overall type (or name, if you like)  to a VSA that consists
of multiple TLVs.  This is understandable because IIRC the reason multiple
TLVs were allowed was just to conserve space in the packet.  It is that
problem that I'm attempting to solve with a simple 2 layer hierarchy of
grouping: tags group related Extended Attributes, while Extended Attributes
group related TLVs.  Both types of groupings are optional.  My suggestion is
to adopt an 8-bit type for both Extended Attributes and TLVs (I hope that
we've established the meaning of "TLV" now).  Actually, to do it right, one
would need a "More" flag in TLVs, too, however.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Oct 2008 14:01:44 +0200

> (the only difference is the addition of the 'More' and 'Tag' fields.  RFC

  Well, yes.  I have read that from time to time.

> of multiple TLVs.

  RADIUS has (historically) had a flat name-space.  VSA's have always
allowed multiple TLV's in them.  There hasn't been a naming issue.

  RADIUS has historically *not* allowed nested data types.  IIRC, the WG
has expressed concern about it.  You seem to be proposing exactly
this... a data type which allows attributes to be encoded in it.

>  This is understandable because IIRC the reason multiple
> group related TLVs.

  So the 'extended attribute type" is really an encapsulation for
*another* layer of TLV's.  Is that right?

>  Both types of groupings are optional.  My suggestion is

  I understand the acronym "TLV".  I wish to heck I understood *which*
TLV you're referring to, and *what* it does.

  Can you give examples?  Please?  Pointing to the MS-CHAP documents
doesn't help, as they have manifestly been transported through RADIUS
for over a decade.  Repeating that they're TLV's is obviously not
helping me.

  Examples?  If it's so obvious what they are, examples should be
trivial to create.  If the examples are difficult to create, then it
would seem that they have no real-world use.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 13 Oct 2008 18:21:52 -0700

> result of that discussion?

The result of that discussion was not to go forward with it.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 13 Oct 2008 18:26:35 -0700

Glen Zorn said:

"Some time ago I suggested a solution for this problem in the form of
splitting the Ext-Type field in two, one octet being the actual Ext-Type &
the other becoming an "AVP-Type.  There has been almost no discussion of
this proposal; since there is other work waiting upon the disposition of
this problem, I will make the changes I described this week unless I hear
loud screams to the contrary."

We have already had an extensive discussion on the list as to whether the
Ext-Type field should be one or two octets.  The WG verdict was to have it
be two octets. 

"Splitting" this field so as to make the AVP-Type one octet seems like it 
would be effectively reversing the (tortuously arrived at) WG consensus.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 14 Oct 2008 10:28:11 +0700

> The result of that discussion was not to go forward with it.

Just to refresh the memory, the idea in question was 'de-capsulating the
contents of the MS-CHAP-* attributes into multiple attributes...e.g.
MS-CHAP(foo=1, bar=2, ...)  3GPP does this, WiMAX does this'.  As I pointed
out in a previous message, both RFC 2865 VSAs and the current extended
attribute draft also allow this, just in a (perhaps predictably) half-assed
fashion: instead of (for example) defining & referring to an Extended
Attribute called MS-CHAP-CPW-2 which encapsulates various TLVs corresponding
to Old-NT-Hash, Old-LM-Hash, etc. one would either a) define a bunch of new
Extended Attributes corresponding to the fields in the MS-CAP-CPW-2
attribute and refer to it as the set of extended attributes containing the
same (unknown, run-time assigned) value in the Tag field or b) merely
replicate the RFC 2548 definition of MS-CHAP-CPW-2 with an Extended
Attribute header.  The latter approach, of course, forces the continued use
of the so-called "complex" Attributes that Alan (?!) so reviles in
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt, while
the former forces the receiver to grovel through the entire message to find
the tagged attributes, check that all are present and check the validity of
each instead of just checking the validity of a single attribute.  I love
this idea!  Certainly far better to accept it than tamper with WG Consensus
(which apparently has become as holy as "backward compatibility" in this WG.
In any case, I'm not married to this solution; I've repeatedly requested
suggestions for a solution to the problem but nobody else has brought any
forward.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Oct 2008 08:10:00 +0200

Glen Zorn wrote:
> MS-CHAP(foo=1, bar=2, ...)  3GPP does this, WiMAX does this'.

  That was the most recent recap of sub-TLV's.

>  As I pointed
> attribute draft also allow this, 

  No.

  There are multiple possible representations (TLV's, grouped
attributes, tags, etc) which can be semantically similar.  But the
representations are different, and are encapsulated differently.

> just in a (perhaps predictably) half-assed
> fashion:

  Which is what was agreed to after much discussion on this list.

> The latter approach, of course, forces the continued use
> of the so-called "complex" Attributes that Alan (?!) 

  The design guidelines document contains the results of WG consensus.

> while
> each instead of just checking the validity of a single attribute.

  I think everyone understands that.  And the consensus was to perform
the reviled grovelling.

>  I love

  Consensus was achieved after much discussion among people who
understood the consequences of their choices.  Deriding it as "holy"
implies that the decision was made either through blind faith, or by
people who didn't understand the consequences of their actions.

  I'm not an idiot, and I don't play one on TV.

> suggestions for a solution to the problem but nobody else has brought any

  Nonsense.  There were multiple suggestions offered, including the one
you are re-proposing.  They were all rejected.  Some were rejected by you.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Oct 2008 12:46:32 -0700

> > In any case, I'm not married to this solution; I've repeatedly requested> > suggestions for a solution to the problem but nobody else has brought any> > forward. > > Nonsense. There were multiple suggestions offered, including the one> you are re-proposing. They were all rejected. Some were rejected by you.
Indeed, it is difficult to see how the current proposed resolution is different from
a similar suggestion which was rejected after (laborious) WG
consensus calls at IETF 71 as well as on the WG mailing list.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 15 Oct 2008 12:51:34 +0700

> you are re-proposing. They were all rejected. Some were rejected by you.

Indeed, it is difficult to see how the current proposed resolution is
different from
a similar suggestion which was rejected after (laborious) WG
consensus calls at IETF 71 as well as on the WG mailing list. 

I'm confused!  Is this in the way of a recommendation for a solution or are
you just enjoying beating me with the "WG consensus" stick?  If the latter,
please have fun, but you might take a moment to redefine the problem as
non-existent by simply deleting the issue from the list.  In any case, I
don't really care anymore: I've solved the problem (in a very ugly way) by
defining the attributes for 802.16 PKMv1 support as (complex & redundant)
legacy attributes since I really don't have time for this.  You see, I'm
actually trying to do some engineering here; I don't know what you're trying
to do, but I'm pretty sure it's not that.