Attribute Design Guidelines and RADIUS layering (was:[RADIUS FIXES] Authorize Only / RADIUS layering criteria)

["Nelson, David" <dnelson@enterasys.com>]

Emile van Bergen writes...

> Some standards violations are much more serious than others. If a
proxy
> does not properly forward certain characters, characters which clients
> and servers are allowed to use according to the standard, then that's
> extremely serious.
> 
> If a service provider and a proxy operator agree to attach meaning to
an
> attribute that the standard says must not be interpreted, then that
has
> no consequence for any code or anyone else in the chain.

I think this thread has wound it way onto the turf on another WG charter
item, the RADIUS Design Guidelines document.  There are also
implications for RFC 3575 "IANA Considerations for RADIUS".

The problem with a particular vendor and particular customer privately
agreeing to over-load the semantics of a standard RADIUS attribute (or
command, for that matter) is that it becomes a proprietary protocol,
based on a standard one.  I'm sure there are lots of customers that are
perfectly happy to deploy proprietary protocols, and goodness knows that
vendors have reason to be happy about that.

When I use the words "multi-vendor interoperability" I mean that my
implementation of the protocol is fully interchangeable with your
implementation of the protocol, enabling me to respond to an RFP from
your customer base.  When all we have is a base level of "transport"
standardization, but much of the detailed protocol element semantics and
the system level behavior is divergent from one implementation to
another, its only a "vanity" standard, or in fact a collection of
partially interoperable proprietary protocols.

Before you cry foul, and point out that vendors need to be able to
differentiate their products to compete, let me say that I fully agree.
Where my opinion may differ is in where the product differentiation
exists.  If there are complete feature sets, use cases and solutions
that rely on private agreements over the *meaning* of the protocol
elements, then that's my definition of a proprietary protocol.

We've had some discussions in this thread about the RADIUS architecture
and it's lack of separation of "transport", i.e. PDU framing and
formats, from the abstract concept of its service-provisioning service,
and from the interface to other protocols that provide the services
being provisioned.  Back when RADIUS was first developed, its scope of
applicability was fairly narrow -- those services provided by
asynchronous dial-up access servers (terminal servers). I've been
involved since the second RADIUS BOF, so I have first hand knowledge of
much of the history.  It was excusable, I think, for RADIUS to take this
"simplified", non-layered approach based on the problem it was
attempting to solve.

All of the original RADIUS attributes needed very little in the way of
formal definition. They all represented very well-known and
unambiguously defined data objects, protocols and services, understood
by almost anyone with a reasonable exposure to the Internet.  Host
names, IP addresses, Telnet, Rlogin, SLIP, PPP, and such are all well
defined services.  Their inclusion in attributes was pretty much
self-describing.  No one ever thought to re-use the IP-Address attribute
to contain an IPX address (at least to my knowledge).

I would like to reiterate that I think re-definition, over-loading or
private agreements to modify the semantics of any IETF standard RADIUS
attribute is harmful to the integrity and multi-vendor interoperability
of the protocol.  RADIUS can easily be [mis]used as an application
agnostic transport protocol.  Because RADIUS *has* defined the transport
issues so inextricably with the protocol semantics issues, it is not
reasonable to attempt to retrofit RADIUS with that level of "layering"
today, and to turn it into an application agnostic transport, no matter
how convenient that might be for vendors attempting to innovate rapidly
outside of the standards arena.

It *is* important that vendors be able to use VSAs for proprietary
features that do not have wider applicability.  It is also important
that vendors, other WGs, or other SDOs be able to create and properly
document fully interoperable IETF standard attributes, when appropriate.
That is why we have RFC 3575 "IANA Considerations for RADIUS" and why
the RADIUS Design Guidelines document is a RADEXT WG charter item.


--
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/>