Re: [radext] RADIUS case study

["Romascanu, Dan (Dan)" <[e-mail]>]

Bernard,

 

This is an IAB document - what is its status? Was it approved by the
IAB? Is it still work-in-progress and you / the IAB are soliciting
comments? 

 

Dan

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 PM
To: [e-mail]
Subject: [radext] RADIUS case study

 

The IAB is working on a document entitled  "Design Considerations for
Protocol Extensions"
<http://tools.ietf.org/html/draft-iab-extension-recs> , which includes a
RADIUS case study in Appendix A.2. 

The text of the RADIUS case study is included below.   Comments welcome.


 

A.2.  RADIUS Extensions

 

   The RADIUS [RFC2865] protocol was designed to be extensible via

   addition of Attributes to a Data Dictionary on the server, without

   requiring code changes.  However, this extensibility model assumed

   that Attributes would conform to a limited set of data types and that

   vendor extensions would be limited to use by vendors, in situations

   in which interoperability was not required.  Subsequent developments

   have stretched those assumptions.

 

   From the beginning, uses of the RADIUS protocol extended beyond the

   scope of the original protocol definition (and beyond the scope of

   the RADIUS Working Group charter).  In addition to rampant self-

   allocation within the limited RADIUS standard attribute space,

   vendors defined their own RADIUS commands.  This lead to the rapid

   proliferation of vendor-specific protocol variants.  To this day,

   many common implementation practices have not been documented.  As

   noted in "Extended RADIUS Practices" [RFC2882] Section 1:

 

      The RADIUS Working Group was formed in 1995 to document the

      protocol of the same name, and was chartered to stay within a set

      of bounds for dial-in terminal servers.  Unfortunately the real

      world of Network Access Servers (NASes) hasn't stayed that small

      and simple, and continues to evolve at an amazing rate.

 

      This document shows some of the current implementations on the

      market have already outstripped the capabilities of the RADIUS

      protocol.  A quite a few features have been developed completely

      outside the protocol.  These features use the RADIUS protocol

      structure and format, but employ operations and semantics well

      beyond the RFC documents.

 

   The limited set of data types defined in [RFC2865] has lead to

   subsequent documents defining new data types.  Since new data types

   are typically defined implicitly as part of defining a new attribute,

   and because RADIUS client and server implementations differ in their

   support of these additional specifications, there is no definitive

   registry of RADIUS data types and data type support has been

   inconsistent.  To catalog commonly implemented data types as well as

   to provide guidance for implementers as well as attribute designers,

   "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on

   basic and complex data types.  Unfortunately, these guidelines were

   published 14 years after the RADIUS protocol was first documented in

   [RFC2058].

 

   Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism

   for Vendor-Specific extensions (Attribute 26), and states that use of

   Vendor-Specific extensions:

 

      should be encouraged instead of allocation of global attribute

      types, for functions specific only to one vendor's implementation

      of RADIUS, where no interoperability is deemed useful.

 

   However, in practice usage of Vendor-Specific Attributes (VSAs) has

   been considerably broader than this.  In particular, VSAs have been

   used by Standards Development Organizations (SDOs) to define their

   own extensions to the RADIUS protocol.  This has caused a number of

   problems.

 

   One issue concerns the data model for VSAs.  Since it was not

   envisaged that multi-vendor VSA implementations would need to

   interoperate, the RADIUS specification [RFC2865] does not define the

   data model for VSAs, and allows multiple sub- attributes to be

   included within a single Attribute of type 26.  Since this enables

   VSAs to be defined which would not be supportable by current

   implementations if placed within the standard RADIUS attribute space,

   this has caused problems in standardizing widely deployed VSAs, as

   discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158].

 

   Another issue is how implementations should handle unknown VSAs.

   [RFC2865] Section 5.26 states:

 

      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.

 

   However, since VSAs do not contain a "mandatory" bit, RADIUS clients

   and servers may not know whether it is safe to ignore unknown VSAs.

   For example, in the case where VSAs pertain to security (e.g.

   Filters), it may not be safe to ignore them.  As a result, "Common

   Remote Authentication Dial In User Service (RADIUS) Implementation

   Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the

   following caution:

 

      To avoid misinterpretation of service requests encoded within

      VSAs, RADIUS servers SHOULD NOT send VSAs containing service

      requests to RADIUS clients that are not known to understand them.

      For example, a RADIUS server should not send a VSA encoding a

      filter without knowledge that the RADIUS client supports the VSA.

 

   In addition to extending RADIUS by use of VSAs, SDOs have also

   defined new values of the Service-Type attribute in order to create

   new RADIUS commands.  Since the RADIUS specification [RFC2865]

   defined Service-Type values as being allocated First Come, First

   Served (FCFS), this permitted new RADIUS commands to be allocated

   without IETF review.  This oversight has since been fixed in "IANA

   Considerations for RADIUS" [RFC3575].

_______________________________________________
radext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/radext