Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 May 2009 11:11:29 -0700

Thanks for your comments. 

Design Guidelines has a normative dependency on the Extended Attributes document, which currently uses a 16-bit vendor type field.  Given that Extended Attributes will require that RADIUS servers support a 16-bit vendor-type field for IETF-defined extended attributes, it isn't much of a stretch to recommend that RADIUS servers support a 16-bit type field for vendor and SDO-specific attributes as well, since Extended Attributes is based on the VSA format. 

The question is whether that recommendation belongs in this document, which is a BCP, or whether it should go into the Extended Attributes document (Proposed Standard) instead, and just be referred to in Design Guidelines.  Consolidating protocol changes into the Extended Attribute document might be cleaner, particularly since it is Extended Attributes that will provide much of the motivation for vendors to add 16-bit vendor type support.

With respect to "replacement" of the 8-bit vendor-type field with a 16-bit vendor type recommendation, my take on the text in 2.3 is that while it recommends RADIUS server support for 16-bit vendor type fields, it doesn't make a blanket recommendation that vendors adopt a 16-bit vendor type field in all situations, but rather points out situations in which use of a 16-bit vendor type field would be appropriate:
   Note that the Vendor type field in the recommended VSA format is only
   a single octet, like the RADIUS type field.  While this limitation
   results in an efficient encoding, there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.  In such a situation, a 16-bit Vendor type field
   would be more appropriate:

> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Date: Thu, 7 May 2009 07:08:20 -0700
> Subject: DISCUSS and COMMENT: draft-ietf-radext-design 
> 
> Discuss:
> Great doc! I will vote Yes on it, but I wanted to discuss two issues
> first, one is a Discuss-level problem and the other one a Comment that
> I'd like you to consider.
> 
> The first issue is that Section 2.3 suggests 16-bit vendor space
> attribute number fields to replace the existing 8-bit recommendation.
> 
> There are a couple of problems with this. First, if you really mean
> to change the recommendation, then Updates: RFC 2865 header in the
> beginning of the document would have been appropriate.
> 
> Secondly, while I agree with the advice of going for 16 bits, the
> document is silent on some of the issues involved in such a change,
> such as:
> 
> - Does RADIUS dictionary software support the VSA format for 16 bits, 8
>   bits, or both?
> 
> - How do you cleanly print or report VSAs when you do not know if the
>   field size is 8 or 16 bits? I realize that this situation already
>   exists since the format was never required to be followed, but
>   your new recommendation makes a potential problem much more likely
>   to appear. Previously, you could print something like Vendor = ACME,
>   Code = 17, Contents = ABCDEF0011... Now you couldn't do that.
> 
> - Can a vendor who moved from 8 bits to 16 bits deal with this?
> 
> Comment:
> I do agree that for functionality FOO, both the functionality itself
> and the MIB, RADIUS, etc. work should take place in the same standards
> body. However, Section 3.1 could have said a couple of additional things
> as well:
> 
> The issues of attribute space and choice of forum are distinct; there
> is no reason why IETF couldn't use its own vendor code, for instance.
> 
> The section also does not mention one of the potential drawbacks of
> SDO-driven development model: it is easy to come up with a number of
> different solutions to the same generic problem, as opposed to finding
> a common solution.
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 May 2009 21:54:51 +0300

Bernard Aboba wrote:
> Design Guidelines has a normative dependency on the Extended 
> Attributes document, which currently uses a 16-bit vendor type field.  
> Given that Extended Attributes will require that RADIUS servers 
> support a 16-bit vendor-type field for IETF-defined extended 
> attributes, it isn't much of a stretch to recommend that RADIUS 
> servers support a 16-bit type field for vendor and SDO-specific 
> attributes as well, since Extended Attributes is based on the VSA format.
>
> The question is whether that recommendation belongs in this document, 
> which is a BCP, or whether it should go into the Extended Attributes 
> document (Proposed Standard) instead, and just be referred to in 
> Design Guidelines.  Consolidating protocol changes into the Extended 
> Attribute document might be cleaner, particularly since it is Extended 
> Attributes that will provide much of the motivation for vendors to add 
> 16-bit vendor type support.

Seems reasonable.

> With respect to "replacement" of the 8-bit vendor-type field with a 
> 16-bit vendor type recommendation, my take on the text in 2.3 is that 
> while it recommends RADIUS server support for 16-bit vendor type 
> fields, it doesn't make a blanket recommendation that vendors adopt a 
> 16-bit vendor type field in all situations, but rather points out 
> situations in which use of a 16-bit vendor type field would be 
> appropriate:

Yeah. We talked about this on the call. I think it is reasonable to go 
to the 16 bit space, but I was only looking for guidance for, say, an 
SDO that has been using 8 bits before and now has to or wants to go 16 
bits. Obviously this can be done, but requires care in how the 
allocations are done and what dictionaries say.

Jari

>
> <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
>
>
>
> > CC: [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]

--
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: "Dave Nelson" <[email-masked]>
Date: Fri, 8 May 2009 08:49:20 -0400

>   We could add that, but I don't think it's critical.

Hmmm.  I have doubts about a BCP updating a Draft Standard.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 May 2009 16:06:15 +0300

Alan,

>   In *addition* to 8-bit spaces.  Not to replace it.
>   

Well... there was a previous SHOULD recommendation. Now there is a new 
one (use the old the new).

>   We could add that, but I don't think it's critical.

Not very, but I think if we change an earlier requirement it would be 
helpful to add the Updates pointer so that people who review older RFCs 
are more likely to remember to check the new one, too.

>   All major products already support many non-RFC VSA formats, including
> 16 bits.
>   

This is very good! Can you say something along these lines in the 
document, too, because it goes a long way towards resolving any issues 
the change has.

>   The *current* implementations have the same problem.  If they receive
> a VSA from an unknown vendor, and it's not in the RFC format, they have
> *no* idea what format to use.
>   

Are you saying that no implementation is capable of by default printing 
out text like I had in my example above?

>   Vendors cannot create VSAs of both 8 and 16 bits with the same
> Vendor-Id.  Some have tried, and have quickly fixed their product when
> *everyone* complained.
>
>   If vendors want to "switch" to using 16-bit types, they need to use a
> new vendor-id.
>   

Ok. I didn't think that was the case but clearly you have the 
operational experience on this.

I think it would be essential to spell this out in the draft -- its 
important information!

Jari

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 8 May 2009 09:24:37 -0400

> I think it would be essential to spell this out in the draft -- its

Quite frankly, this line of reasoning disturbs me.  It's well known that
there have been all sorts of non-standard behaviors (and a few ugly hacks)
implemented in RADIUS clients and servers over the years.  Dave Mitton
documented some of these in RFC 2882.  This document is a BCP.  That means
it should document the *best* current practices and not the more dubious
ones.  Not all hacks are created equal.

This document should aim to bring order out of chaos.

I think it would be fine if the Extended Attributes have 16-bit IDs and the
traditional RFC 2865 format VSAs kept their 8-bit IDs.  Anything else, e.g.
non-standard VSA formats, is simply "off the reservation" and outside the
scope of this document.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 9 May 2009 11:48:04 +0900

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

...
 
> non-standard VSA formats, is simply "off the reservation" and outside

The problem is that, first of all, there is no "standard VSA format: the
format given in RFC 2865 is recommended, not required.  Next, the format
recommended was widely and immediately recognized (except, perhaps, by the
guardians of orthodoxy in the IETF) as being woefully inadequate and
therefore ignored by many large vendors.  Last, and perhaps most important,
the scope of this document is not (or shouldn't be, IMHO), the preservation
of past mistakes but the prevention of future ones.  If it is too
uncomfortable to admit & fix the VSA fiasco in a BCP, then the WG needs to
adopt as a work item a standards-track draft that updates section 5.26 of
RFC 2865.  In any case, we need to pull our collective head out of the sand.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 9 May 2009 12:48:14 +0300

Hi all, 

The document assumes a certain implementation and processing model. This
model is not explicitly documented in the draft and unfortunately has
implications on the design of attributes particularly when it comes to data
types used by RADIUS attributes and for the claimed problems that arise from
adding new code to the RADIUS server. 

In previous mail exchanges on the list I did not agree with certain aspects
of the implicitly assumed progressing model. I am, however, OK with
documenting the model and to thereby make it explicit to the reader. The
understanding of some of the claimed limitations might also be clearer.

Ciao
Hannes

PS: FYI, I stated my concerns previously on the RADEXT list.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 10 May 2009 11:49:07 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan T DeKok
> 
>   Vendors cannot create VSAs of both 8 and 16 bits with the 
> same Vendor-Id.  Some have tried, and have quickly fixed 
> their product when
> *everyone* complained.
> 
>   If vendors want to "switch" to using 16-bit types, they 
> need to use a new vendor-id.
> 

Hmmmm ... There is nothing in the guidelines that says this. Should
there be text on this respect if this is the consensus of the editor and
WG? 

Dan

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 May 2009 10:21:08 +0900

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

> Cullen Jennings wrote:
> >
> > On May 8, 2009, at 20:48 , Glen Zorn wrote:
> >
> >>   Next, the format
> >> recommended was widely and immediately recognized (except, perhaps,
> by
> >> the
> >> therefore ignored by many large vendors.
> >
> > Folks, is this statement is true - I am very concerned about this
> being
> > ready to be a BCP. Was there a consensus call on this? Does the WG
> have
> > consensus on this?
> 
>   Based on the vendor files I have:
> 
> ~100 vendors
> ~4 use non-RFC format
> 
>   Lucent
>   Starent
>   USR (going back to 1994 or so)
>   WiMAX
> 
>   i.e. the overwhelming majority (> 95%) of the major and minor vendors
> find the RFC VSA format acceptable.

I wonder, does your survey include only actual vendors or just distinct
vendor IDs?  I suspect the latter, since 3COM (not on your list) bought USR,
inheriting that type space.  It also appears that the same weight is given
to vendors like Cisco & Lucent as to "Bob's NAS Factory".  Is this
important?  It certainly seems important to me, since small vendors are
unlikely to put RADIUS to the number and variety of uses that would push the
envelope of the type space.  It also ignores the internal structure of those
"RFC format" VSAs, in many cases chosen to avoid exhausting the VSA type
space (see below).

> 
>   This includes Cisco, who uses the RFC format, and then extends it to
> encapsulate (almost) free-form text.

Perhaps you are unaware of the fact that a major purpose of the
encapsulation of "(almost) free-form text" was to extend the inadequate VSA
type space.

> 
>   I doubt very much that any other RADIUS server will have different
> statistics.

So do I, which would be damning indeed if these statistics had any meaning
at all.   

>   Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 May 2009 09:19:03 -0700

> > Folks, is this statement is true - I am very concerned about this being
> > ready to be a BCP. Was there a consensus call on this? Does the WG have
> > consensus on this?

>From what I can tell, Section 3.2 does not make a recommendation on switching from
an 8-bit to a 16-bit vendor-type format.   It does describe situations in which an 8-bit
vendor type field would be inadequate. 

As noted by Jari, there is a normative recommendation that RADIUS servers support a 16-bit
vendor-type (presumably in addition to the 8-bit vendor type).  IMHO, that normative 
recommendation would be more appropriate in the Extended Attributes document, which 
actually utilizes the 16-bit vendor type. 

>   i.e. the overwhelming majority (> 95%) of the major and minor vendors find the RFC VSA format acceptable.

Right.  Almost all vendors use the 8-bit vendor-type.   This should not be surprising since the
issues described in Section 3.2 will typically apply more to SDOs than to vendors.  

But since the document doesn't recommend against use of the 8-bit vendor-type, this isn't an issue.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 11 May 2009 19:26:21 +0300

I can compile some text but this is not saying that I agree with the assumed
model, i.e. one where essentially no improvement in implementations was made
over the last 10 years. 

>From: Alan T DeKok [mailto:[email-masked]] 
>Sent: 11 May, 2009 16:15
>To: Hannes Tschofenig
>Cc: 'Glen Zorn'; 'Dave Nelson'; 'Jari Arkko'; 
>[email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; 'radext mailing list'
>Subject: Re: My problem with draft-ietf-radext-design
>
>Hannes Tschofenig wrote:
>> The document assumes a certain implementation and processing model.
>
>  Yes.  This model goes back to the original Livingston 
>server, and is at least consistent with all existing RADIUS 
>servers.  i.e. the use of static dictionary files.
>
>  Some RADIUS servers offer *additional* functionality, but 
>this practice is not ubiquitous.
>
>> This
>> implications on the design of attributes particularly when 
>it comes to 
>> data types used by RADIUS attributes and for the claimed 
>problems that 
>> arise from adding new code to the RADIUS server.
>
>  The goal of the document is to describe recommended 
>practices that will result in wide adoption of any proposal.  
>Using the lowest common denominator for RADIUS dictionary 
>capabilities gives the wides possible adoption.
>
>  Other capabilities can be added with new code such as 
>scripting languages (Perl, Python), C / C++, or Java.  Many 
>implementations also support simple programmatic capabilities 
>to describe new data types.
>
>  But these capabilities are not *ubiquitous*.
>
>> In previous mail exchanges on the list I did not agree with certain 
>> aspects of the implicitly assumed progressing model. I am, 
>however, OK 
>> with documenting the model and to thereby make it explicit to the 
>> reader. The understanding of some of the claimed limitations 
>might also be clearer.
>
>  Do you have suggested text for the document?
>
>  Alan DeKok.
>

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 11 May 2009 12:52:08 -0400

Hannes Tschofenig writes...

> ...but this is not saying that I agree with the
> assumed model, i.e. one where essentially no improvement
> in implementations was made over the last 10 years.

Perhaps, but this seems to presume that data-dictionary-driven server
implementations are a liability which requires improvement.  Like a network
management application for SNMP which has the ability to "enroll" a MIB
module without code changes, a RADIUS server that can simply add new
attributes to its dictionary is a boon to users.

We can split hairs about what types of user-added executable scripts are or
are not "coding".  I still think that the data dictionary architecture is a
very powerful concept.  Not to mention a very widely deployed one.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 12 May 2009 12:48:59 +0700

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

> Glen Zorn wrote:
> > vendor IDs?
>   The data is freely available, you are welcome to do your own analysis
> on it.
> 
> >  I suspect the latter, since 3COM (not on your list) bought USR,
> > inheriting that type space.
> 
>   Ah.  So a vendor doesn't count if they've "sold out" to a bigger one?

You didn't count 3COM in you "nonstandard".  Far from saying that USR
doesn't count, I'm saying that _both_ USR and 3COM count.

> 
> >  It also appears that the same weight is given
> > envelope of the type space.
> 
>   So small vendors don't count because the design of RADIUS is
> sufficient for them?

I didn't say that they don't count, and the fact that they may not have
needed to define huge numbers of VSAs doesn't say anything about the design
of RADIUS.  Another important thing that was left out of your simple count
was the question of how many vendors, when needing a particular piece of
functionality, simply chose to support a VSA already defined by another
vendor (the Microsoft MS-MPPE-*-Key Attributes are poster children for this,
but there are others).

> 
> >  It also ignores the internal structure of those
>   It also ignores the many vendors (large ones) who have poached on the
> standard attribute space... without coming close to exhausting the VSA
> space assigned to them.

What's your point?

>  In an ad-hoc and inefficient way.  If Cisco had simply asked for a new
> vendor-Id, and then used the USR style format in that space, there
> would
> have been no need to extend the VSA space with VSAs formatted as text
> strings.  Since USR had been a major player, all RADIUS servers support
> the format.

Again what's your point?  My point was that the size of the VSA type size
was inadequate, so people had to work around it.  Does it really matter what
forms the work-around took?  It's also a little bizarre that you are
suggesting that Cisco go from a (superficially) "standard" VSA format to one
you list as "non-standard" (although it seems at least as "standard" as the
Cisco format...

> 
>   I would think that 2^32 VSAs is sufficient space, even for Cisco.

The Type field in the Vendor-Specific Attribute is one octet long; where did
2^32 come from?

>   Then by all means, let's ignore the data we have at hand.  

The problem isn't with the data at hand, it's with the analysis.

> In it's place we might use appeals to authority, dismissal of "minor"
playors, suggestions to move to protocols that the "major" vendors don't
support, etc.

If you like; I don't recall suggesting any such things, however.  An
alternative might be to use reason and logic, as opposed to relying solely
upon primary school counting skills.

> 
>   Since Cisco is such a large player, and has a blatant need for more
> VSA space, let's just ignore the IETF review process, and standardize
> on
> whatever Cisco comes up with.  

If you want to pick one, I much prefer the USR method; there is IPR
attached, though.

> But I recall some objection to that idea.

I don't remember your being involved in the discussions at the time, maybe
lurking?  In any case, IIRC, the Cisco engineers participating in the radius
WG attempted to argue for a 16-bit (at least) Type field in the
Vendor-Specific Attribute but were shut down.  Since the very existence of
VSAs was highly controversial, they gave up & took what the could get (along
w/USR).  I'm not really sure what we're arguing about, anyway: I thought
that you were defending the suggestion in the Guidelines draft that 16-bit
Types be supported & I'm agreeing.  Did you change your position?