Re: Rationalizing the RADIUS data model

[Barney Wolff <barney@databus.com>]

On Wed, Jun 09, 2004 at 10:52:58PM +0300, john.loughney@nokia.com wrote:
> 
> > I would strongly protest any move to make arbitrarily-formatted vendor-
> > specific attributes retroactively prohibited.  There is absolutely no
> > justification for any such move.  If you wish to contrain future
> > vendor-specific attributes, you MUST define a new Type code for that
> > and confine the restriction to users of the new code.
> 
> Knowing the enforcemant part of the IETF is rather weak, I don't
> think you need to worry about this.  If the IETF defines a standard
> content, and insists upon its use for standard / interoperable usage,
> would this be a problem?  

I have no problem with this if T!=26.

> > As for "extended RADIUS in 'non-interoperable' ways" the RFCs have
> > always said that a robust implementation SHOULD support the content
> > of a VSA as undistinguished octets.
> > 
> > The suggested VSA content format has never been more than a SHOULD.
> > Are you really proposing to make it retroactively a MUST?
> 
> I don't have a problem for making it a MUST for standard, interoperable
> usage.  For non-standard usage, arbatrary format could still be used, IMO.

The problem is exactly interoperability.  A RADIUS peer receiving a VSA
with unknown OID today has no choice but to ignore it or treat it as
undistinguished octets.  What it then decides to do is a matter of policy.
If we now decide that attributes with T=26 MUST be parsable as subattrs,
a new implementation talking to an old implementation may complain of
an invalidly formatted attribute and likely reject.  That's not good.

There's also the branding issue:  What does it mean to say on the outside
of the box "supports RADIUS"?  We don't have version numbers in
this protocol, do we?  I'm worried about finger-pointing, when one
vendor claims that another is sending invalid attribute formats.

One more issue:  What is a vendor to do who sends arbitrary VSA format
today but wants to be a good citizen and comply with the new standard?
How would the peer of such a vendor be able to tell a new-format VSA26
from an old one?  Would you make everybody go get new OIDs?

In hindsight, we should have bitten the bullet years ago and migrated to
ASN.1 - if not for RADIUS, at least for Diameter.  Yes, it is much too
late, but we're going to regret it for a long time.

Regards,
Barney


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>