Subject: Re: Status of Issue 225

From: Alan DeKok <[email-masked]>
Date: Thu, 13 Nov 2008 12:31:52 +0100

Bernard Aboba wrote:
> During the RADEXT WG last call on the RADIUS Extended Attributes draft,
> you filed Issue 225:
> http://www.drizzle.com/~aboba/RADEXT/
>  
> The editor of the document, Glen Zorn, has now listed Issue 225 as
> resolved.  However, before
> closing this issue, we wanted to get your consent.   Please send a note
> to the RADEXT WG
> mailing list indicating whether Issue 2225 is in fact resolved to your
> satisfaction, and if not,
> what portion of the issue remains outstanding.  The latest version of
> the Extended Attributes
> document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05

  The issue that still need addressing are:

--
Section 4:
...
 I suggest also noting that "Extended-Length = Length - 6".  Otherwise,
it becomes theoretically possible for them to have conflicting values
---

  It is not *ridiculously* clear from the current document that "Length"
and "Extended-Length" are strongly related.  I suggest a MUST:

--
   Ext-Len

      >= 3.  The length of the Type-Length-Value tuple in octets,
      including the Ext-Type, Ext-Len and Value fields.  The contents
      of the Ext-Len field MUST be 6 less than the contents of the
      Length field.  That is: Ext-Len = Length - 6.
--

  Experience shows that without this text, people will create attributes
that don't satisfy this criteria... and claim they're standards compliant.

--
  Also, attributes generated by a client or server MUST NOT be
fragmented at boundaries other than 246 octets.  Doing so would decrease
the efficiency of packing.  Robust implementations SHOULD support
receiving attributes fragmented at non-246 octet boundaries.
--

  The only reference to 246 octets in the document says that attributes
*can* be fragmented at 246 octets.  It doesn't forbid fragments smaller
than that.

  Experience shows that without this text, people will create short
fragments, causing problems for everyone else.

  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: "Glen Zorn" <[email-masked]>
Date: Thu, 13 Nov 2008 16:53:13 -0600

> and "Extended-Length" are strongly related.  

Maybe not to you...

> I suggest a MUST:

This would disallow the presence of multiple AVPs in a single attribute.
Are you claiming "WG Consensus" for this massive change?  

> that don't satisfy this criteria... and claim they're standards

This comment is fascinating.  What, exactly, is the "experience" you are
talking about?  Are there already multiple implementations of the extended
attributes?  Have you perfected time travel?  

More "experience".  Where does this "experience" come from?  The only
problems caused will be for those who wrote code that can't handle fragments
< 246 in length.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 13 Nov 2008 16:06:41 -0800

Glen Zorn said:

"This would disallow the presence of multiple AVPs in a single attribute.
Are you claiming "WG Consensus" for this massive change?"

Multiple AVPs can be included within a vendor-specific attribute today,
right?
Given that, it doesn't seem reasonable to change this.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 14 Nov 2008 08:14:33 +0100

>> and "Extended-Length" are strongly related.  

  Pretend I'm channeling the 100's of people who've read the specs, and
implemented broken NASes.

> Are you claiming "WG Consensus" for this massive change?  

  No.  If there *is* only one AVP in a single attribute, then that
relationship holds.

> attributes?  Have you perfected time travel?  

  I am, of course, not claiming experience with multiple implementations
of the extended attributes.  Pretending I'm making that claim is
disingenuous at best.  Instead, I'm claiming something much more
difficult to understand.

  The "experience" is with previous standards, and the people who've
implemented RADIUS software based on them.  It's called "learning from
experience", and "applying that experience to new situations".

  I've spent a lot of time talking with implementors of NASes and
servers about their software.  There are a number of styles of
misunderstanding that they have about existing specifications.  That
experience can be used to review new standards, to minimize the
potential for similar problems.

> problems caused will be for those who wrote code that can't handle fragments

  Inefficient packing should be discouraged.  On top of that, the size
limitation of RADIUS packets means that inefficient packing of
attributes can cause packets to fill quickly.  This means that the
packets can carry less information than they would otherwise have been
able to carry.

  This has implications for all networks that depend on implementations
of the standard.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 17 Nov 2008 10:05:00 -0600

> implemented broken NASes.

I'm not really interested in taking a walk on the psychic side just now, so
how about I just pretend that you are expressing your (necessarily biased)
opinion based upon your (necessarily limited) experience, just like
everybody else?

>   No.  If there *is* only one AVP in a single attribute, then that

But you didn't _say_ that; similarly, your suggestion that " attributes
generated by a client or server MUST NOT be fragmented at boundaries other
than 246 octets" says that values the length of which is not evenly
divisible by 246 are illegal.  I suspect that you actually _meant_ that all
but the final fragment must be 246 octets in length but again, that's not
what you _said_.  I suppose that it's possible that you spent hours
designing these "solutions" but giving you the benefit of the doubt, I'll
assume that it's more like 10 seconds.  Maybe you could take a little bit
more care in crafting your suggestions because as it is you are not offering
solutions so much as you are creating bugs for others to find and fix.

> potential for similar problems.

Amazingly enough, you're not the only person in the world to have talked
with (or been) a RADIUS developer; _my_ personal experience (which I suppose
must be less valid than the royal form that you seem to possess) suggests
that the vast majority of developers are highly intelligent & when questions
about standards arise they are about far more subtle things than this.

...

---

From: Alan DeKok <[email-masked]>
Date: Mon, 17 Nov 2008 10:13:02 -0600

> opinion based upon your (necessarily limited) experience, just like

  If it makes you happy.

> But you didn't _say_ that; 

  Yes, well, I am known to make mistakes from time to time.  Please
accept my apologies.

> about standards arise they are about far more subtle things than this.

  It pleases me to no end that your experience has been more positive
than mine has been.

  Alan DeKok.