[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue 298

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

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.