Subject: [radext] RADIUS case study

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Feb 2012 08:52:22 -0800

The IAB is working on a document entitled
<http://tools.ietf.org/html/draft-iab-extension-recs> "Design Considerations
for Protocol Extensions", 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].

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Feb 2012 13:42:56 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 PM
To: [email-masked]
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. 

 

A.2.  RADIUS Extensions

   [RFC2058].

   problems.

   following caution:

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Feb 2012 13:42:56 +0100

Bernard,

Dan

 

A.2.  RADIUS Extensions

   [RFC2058].

   problems.

   following caution:

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Feb 2012 20:57:19 -0800

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 [email-masked] 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: [email-masked]
To: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, February 21, 2012 6:52 PM
To: [email-masked]
Subject: [radext] RADIUS case study The IAB is working on a document entitled  "Design Considerations for Protocol Extensions", 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
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Feb 2012 20:57:19 -0800

the issue on.   

seizes you.   

of the editor.   

  

as required

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Feb 2012 12:15:50 +0100

Thanks for the clarification. I believe that the RADEXT WG folks should
review this document, maybe the chairs can designate one or two
reviewers. 

Regards,

Dan

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, February 23, 2012 6:57 AM
To: Romascanu, Dan (Dan); [email-masked]
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. 

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

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  

 

 
 
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. 

Click on the ticket # you want to update, and then modify the ticket
fields 
as required  

________________________________

Bernard,

Dan

 

A.2.  RADIUS Extensions

   [RFC2058].

   problems.

   following caution:

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Feb 2012 12:15:50 +0100

Regards,

Dan

 

 

 

 

Bernard,

Dan

 

A.2.  RADIUS Extensions

   [RFC2058].

   problems.

   following caution: