Subject: Re: Issue 298

From: Alan DeKok <[email-masked]>
Date: Fri, 02 Jan 2009 16:13:59 +0100

Bernard Aboba wrote:
>> So one question is whether this implies that a NAS should signal its
>> support for Extended Attributes in the Access-Request in some way -- 
>> so as to make it clear to the RADIUS server how those attributes would
>> be interpreted.  
> 
> I think we should make that feature a MUST.
> 
> [BA] That seems sensible to me.  The question is how to do it.  Maybe
> include
> an Extended Attribute of Type 1 with a NUL in it within an Access-Request?

  This gets dangerously close to the old "capabilities" argument.  But I
do agree it would seem to be necessary here.

  Q: What impact does this advertisement have on intermediary proxies?

  i.e. Does it signal that the NAS understands Extended-Attributes, or
that the proxy understands them?  Should the proxy filter out the
advertisement if it doesn't understand Extended-Attributes?

  To answer my own question a bit... it's easier to upgrade proxies than
NASes.  I think it's safe to assume (or require) that proxies be
upgraded before NASes.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 2 Jan 2009 10:53:11 -0500

Alan DeKok writes...

>  This gets dangerously close to the old "capabilities" argument.

We've not seen fit to standardize "capabilities" in a general way, but there
is precedent for advertising support for a single attribute, as is the case
with Chargeable-User-Identity (CUI). 

>  i.e. Does it signal that the NAS understands Extended-Attributes,
> or that the proxy understands them?  Should the proxy filter out the

Ultimately, it's the NAS that has to provision services based on the content
of the Extended Attributes, so the fact that the NAS understands them is of
prime importance.  The fact the proxies understand them is only of
importance if the proxies are expected to be "editing" the attributes passed
to and from the NAS.  If a particular proxy is know to indiscriminately
discard VSAs, then knowing it supports Extended Attributes may be of greater
importance that otherwise might be the case.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Jan 2009 14:22:38 -0800

> NASes.  I think it's safe to assume (or require) that proxies be

How about this?

<text kyped from RFC 5080 section 2.5 and modified>

   To avoid misinterpretation of service requests encoded within Extended
   Attributes, RADIUS servers SHOULD NOT send Extended Attributes containing 
   service requests to RADIUS clients that are not known to understand them.  
   For example, a RADIUS server should not send an Extended Attribute encoding 
   a filter without knowledge that the RADIUS client supports Extended Attributes
   in general, and the filter Extended Attribute in particular.

A NAS supporting the Extended Attribute format MUST include at
 least one Extended Attribute within an Access-Request.  In order
to  be eligible to include at least one Extended Attribute in an
Access-Request, a NAS MUST be capable of parsing the Extended 
Attribute format  (e.g. 2-octet Type-Code, grouping,  etc.).  
A RADIUS server that does not receive an Extended Attribute
within an Access-Request SHOULD NOT send Extended Attributes
within an Access-Accept or Access-Challenge packet unless it is 
prepared for the Extended Attributes to be ignored as described 
in RFC 2865 Section 5.26.  

Similarly, a Dynamic Authorization Client SHOULD only include 
Extended Attributes within a CoA-Request or Disconnect-Request
if Extended Attributes were included within an Access-Request
within the referenced session, or if the DAC is prepared for the
Extended Attributes to be ignored. 

As noted in RFC 2865 Section 5.26, a robust implementation SHOULD 
support Extended Attributes as undistinguished octets.  As a result,
a RADIUS proxy SHOULD by default pass Extended Attributes unmodified.  
However, if configured to do so, a RADIUS proxy MAY add, modify or 
remove Extended Attributes sent within RADIUS packets.  

RADIUS clients and servers supporting this specification 
treat Extended Attributes similarly to RADIUS standard attributes as 
described in RFC 5080 Section 2.5, rather than as a VSA.  As
noted in RFC 5080 Section 2.5: 
   On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject...

   On receiving a packet including an attribute of unknown Type, RADIUS
   authentication server implementations SHOULD ignore such attributes.
   However, RADIUS accounting server implementations typically do not
   need to understand attributes in order to write them to stable
   storage or pass them to the billing engine.  Therefore, accounting
   server implementations SHOULD be equipped to handle unknown
   attributes.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Jan 2009 14:44:10 -0800

> prime importance.  

I agree. 

> The fact the proxies understand them is only of

RFC 2865 Section 5.26 states that robust implementation should treat the 
values of VSAs as opaque text.  So a proxy complying with that recommendation 
should be able to pass Extended Attributes in either direction without 
corrupting them. 

Such an existing proxy should also be able to remove or add VSAs by treating them 
as opaque blobs.  However, this wouldn't necessarily allow proxies to remove or add 
individual Extended Attributes, just to selectively add or remove VSAs 
within which Extended Attributes are encapsulated. 

For a proxy to be able to add, remove or modify specific Extended Attributes would 
require parsing the Extended Attribute format.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 08 Jan 2009 11:43:43 +0100

> How about this?

  ... it looks pretty good to me.

  Alan DeKok.