RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Glen Zorn writes...

> I'm quite aware of that & if, in fact, the attributes were opaque
> data that passage would certainly cover it.  However, it doesn't
> appear that either the Location-Information nor the Location-Data
> Attribute is actually "opaque".

I've offered similar comments early on in the review of this document.  The
authors explained to me that the attributes used in this document are based
upon the PDUs of other protocols.  Unfortunately, the PDUs of those other
protocols are not suitable for direct encapsulation as "opaque" RADIUS
Attributes.  Instead, they required slight modifications in order to be
suitable for the current purpose.  For that reason, the document under
review outlines the format and layout of the attributes as if they were not
opaque.  In fact, they are only partially opaque.

Strictly speaking, for a RADIUS Attribute to be "opaque" in the way that the
RADIUS Design Guidelines anticipates, it should be merely an encapsulation
of a data element defined in another (typically non-RADIUS) document.  What
we have here is as example of re-use (with minor adaptation) rather than
simple encapsulation.  I think this fails to meet the spirit, if not the
letter, of the RADIUS Design Guidelines.  However, after substantial
discussion on this point, it became clear that there were no better
alternatives that met the needs of the authors of this document.  This may
be as good as its going to get.

> OK.  As you noted above, the Design Guidelines say
> 
>    If the RADIUS Server simply passes the contents of an attribute to
>    some non-RADIUS portion of the network, then the data is opaque, and
>    SHOULD be defined to be of type String.  A concrete way of judging
>    this requirement is whether or not the attribute definition in the
>    RADIUS document contains delineated fields for sub-parts of the data.
>    If those fields need to be delineated in RADIUS, then the data is not
>    opaque, and it SHOULD be separated into individual RADIUS attributes.

Strictly speaking, since the attribute contents are framed by field
delimiters defined only in the attribute definition, and not in another
protocol document, these attributes don't meet the definition of "opaque" as
currently used in the RADIUS Design Guidelines.
 
> But section 4.7 of the draft under review says
> 
>    o  If the RADIUS server requires location information for computing
>       the authorization decision and the RADIUS client does not provide
>       it with the Access-Request message then the Requested-Location-
>       Info Attribute is attached to the Access-Challenge with a hint
>       about what is required.  Two cases can be differentiated:
> 
>       1.  If the RADIUS client sends the requested information then the
>           RADIUS server can process the location-based attributes.
> 
>       2.  If the RADIUS server does not receive the requested
>           information in response to the Access-Challenge (including the
>           Requested-Location-Info Attribute) then the RADIUS server may
>           respond with an Access-Reject message with an Error-Cause
>           Attribute (including the "Location-Info-Required" value).
> 
> The RADIUS server "requires location information for computing the
> authorization decision".  How can it make a decision based upon data
> that it cannot understand?

This is where the delineation gets fuzzy.  We presume that any information
carried in RADIUS messages is related to authentication or authorization.
Yes, RADIUS can be (ab)used as a generic transport or all sorts of unrelated
information, but that isn't the case in this instance.  The use of a
"back-end" or "plug-in" module to parse opaque data in a RADIUS Attribute
and provide the results back to the RADIUS Server for use in the
authentication and authorization decision making process is well
established.  Certainly that's what the EAP server does for RADIUS
EAP-Message Attributes.

> Of course, "process" can mean many things and if these attributes are
> opaque then "process" might mean just writing the data to a file or 
> forwarding it over some unspecified interface to another entity.

It could mean that.

> AFAICT, the only way that the RADIUS server can tell if it has 
> actually received the information it requested is to examine the
> Code and Entity sub-fields of the returned Location-Information 
> Attribute and check that there is an associated instance of the 
> Location-Data Attribute by matching the Index fields of the Attributes.

Something has to do this work.  It could be the RADIUS Server, or it could
be the Location Policy Server, acting as a back-end service to the RADIUS
Server.  This is all a matter of implementation, and has nothing to do with
the on-the-wire protocol.

> Remember that this check for the requested information takes place
> before the RADIUS server processes the data; this suggests to me that
> these fields "need to be delineated in RADIUS" and therefore
> "the data is not opaque, and it SHOULD be separated into individual
> RADIUS attributes".

I think that is a very reasonable design choice, and one that would be in
compliance with the RADIUS Design Guidelines.   However, we've had that
discussion and the consensus seemed to be that it was too much of a change,
too late in the development cycle for this document.

> Further, section A.2.2 of the Design Guidelines
> asks the (how I wish it was a musical ;-) question:
> 
>    Does the attribute define a complex data type for purposes other than
>    authentication or security?  If so, this data type SHOULD be replaced
>    with simpler types, as discussed above in Section A.2.1.
> 
> Neither the Location-Information nor the Location-Data Attributes seem
> to be used for authentication (authorization != authentication) or
> security. 

Yes, but I believe that this section of text was arrived at after the
document under review had completed its WGLC.  There is an issue of timing
here.  If the RADIUS Design Guidelines document had matured more quickly, it
may have had a greater impact on the RADIUS Location Attributes document.  I
had argued along similar lines, but there was resistance to change late on
in the development cycle.

> Section A.1.3 of the same document says (WRT Attributes
> encapsulating complex data types):
> 
>    Does the attribute encapsulate an existing data structure defined
>    outside of the RADIUS specifications?  Can the attribute be treated
>    as opaque data by RADIUS servers (including proxies?)  If both
>    questions can be answered affirmatively, a complex structure MAY be
>    used in a RADIUS specification.
> 
>    The specification of the attribute SHOULD define the encapsulating
>    attribute to be of type String.  The specification SHOULD refer to an
>    external document defining the structure.  The specification SHOULD
>    NOT define or describe the structure[...]
> 
> However, section 4.2 of draft-ietf-geopriv-radius-lo describes the
> structure of the Location-Information Attribute in detail; the question
> of opacity was dealt with above.
> 
> WRT the Index fields of the Location-Information and Location-Data
> Attributes, the fact that they are both mandatory and large avoids many
> of the drawbacks mentioned WRT tags in the Design Guidelines document,
> nevertheless that document does state 'new attributes SHOULD use the
> grouping method described in http://www.ietf.org/internet-drafts/draft-
> ietf-radext-extended-attributes-03.txt'.

Yes, if this work were to be started today, one would expect a much greater
level of compliance with the RADIUS Design Guidelines document.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>