[AAA-DOCTORS] FW: [radext] RADIUS case study

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

I do not believe that there are too many aaa-doctors who are not
subscribed to the radext mail list, but there may be a few. 

 

In any case, I believe that  aaa-doctors review is of this document is
desirable - for the RADIUS specific annex and the document as a whole. 

 

Thanks and Regards,

 

Dan

 

 

 

From: Bernard Aboba [mailto:[e-mail]] 
Sent: Thursday, February 23, 2012 6:57 AM
To: Romascanu, Dan (Dan); [e-mail]
Subject: RE: [radext] RADIUS case study

 

The document that has completed a 4-week IETF "Call for Comment", and
the IAB has now initiated a two-week "last call" concluding on March 7,
2012, after which the document will be considered for approval. 

Since some questions arose about the RADIUS case study, feedback is
being requested from RADEXT WG on that. 

However, comments are also welcome on any other portion of the document.


Comments on the RADIUS case study can be sent to this list. 

Comments on other aspects can be sent to [e-mail] or filed in TRAC
(see below). 

=================================  
Submitting Comments via TRAC  
 
1. To submit an issue in TRAC, you first need to login on the tools
server: http://tools.ietf.org/wg/iab/  
<http://tools.ietf.org/wg/iab/trac/login> trac/login  
 
2. If you don't already have a login ID, you can obtain one by  
navigating to this site: http:// <http://trac.tools.ietf.org/newlogin>  
trac.tools.ietf.org/newlogin  
 
3. Once you have obtained an account, and have logged in, you can file  
an issue by navigating to the ticket entry form: http://  
<http://trac.tools.ietf.org/wg/iab/trac/newticket>  
trac.tools.ietf.org/wg/iab/trac/newticket  
 
4. When opening an issue:  
 
a. The Type: field should be set to "defect" for an issue with the  
current document text, or "enhancement" for a proposed addition of  
functionality (such as an additional requirement).  
b. The Priority: field is set based on the severity of the Issue. For  
example, editorial issues are typically "minor" or "trivial".  
c. The Milestone: field should be set to milestone1 (useless, I know).  
 
d. The Component: field should be set to the document you are filing  
the issue on.  
e. The Version: field should be set to "1.0".  
f. The Severity: field should be set to based on the status of the  
document (e.g. "In WG Last Call" for a document in IAB last call)  
g. The Keywords: and CC: fields can be left blank unless inspiration  
seizes you.  
h. The Assign To: field is generally filled in with the email address  
of the editor.  
 
5. Typically it won't be necessary to enclose a file with the ticket,  
but if you need to, select "I have files to attach to this ticket".  
 
6. If you want to preview your Issue, click on the "Preview" button.  
When you're ready to submit the issue, click on the "Create Ticket"
button. 
 
 
7. If you want to update an issue, go to the "View Tickets" page:  
http:// <http://trac.tools.ietf.org/wg/iab/trac/report/1>  
trac.tools.ietf.org/wg/iab/trac/report/1  
 
Click on the ticket # you want to update, and then modify the ticket
fields 
as required  

 

________________________________

Date: Wed, 22 Feb 2012 13:42:56 +0100
From: [e-mail]
To: [e-mail]; [e-mail]
Subject: Re: [radext] RADIUS case study

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