[Geopriv] FW: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying LocationObjects in RADIUS and Diameter) to Proposed Standard

Glen Zorn <> scribbled on :

> LocationObjects in RADIUS and Diameter) to Proposed Standard
> 
> In the description of the Operator-Name Attribute (section
> 3.1), the discussion of the encoding of a name in the "REALM"
> namespace is incomplete, at best.  First, there is no
> discussion of the steps (if
> any) to be taken if the toASCII conversion fails in  the case
> of a realm name containing non-ASCII characters.  In any case,
> however, it is not possible to encapsulate a maximum-length
> FQDN in a RADIUS attribute because the maximum length of a
> RADIUS Attribute data payload is 253 octets, while the maximum
> length of an ASCII FQDN is 255 octets.
> Furthermore, due to the addition of the ACE prefix(es) as a
> result of the toASCII conversion process, the actual length of
> a converted realm name may be considerably less than 253
> octets.  The conventional way to deal with type of problem in
> RADIUS would be to split the offending string up into multiple
> attributes; however, the formatting of the Operator-Name
> attribute into distinct sub-fields would seem to preclude the
> use of that technique.  I suggest that (in order of preference)
> 	a) the Operator-Name Attribute be split into separate
> Operator-Namespace and Operator-Name Attributes with
> instructions included on handling too-long FQDNs
> 	b) the attribute be redefined in terms of the new
> Extended RADIUS Attributes
> (http://www.ietf.org/internet-drafts/draft-ietf-radext-extended
> -attribut es-03.txt) or at the least
> 	c) text be added noting the actual restrictions on
> realm name length
> 
> Section 3.3, paragraph 2 doesn't make a lot of sense to me:
> suggest rewriting it in less florid if more precise language.
> For example, something like this: "In order to enable the
> on-demand mid-session location delivery method, the RADIUS
> server MUST return an instance of the Requested-Location-Info
> Attribute with the 'FUTURE_REQUESTS' flag set and instances of
> the Basic-Location-Policy-Rules and
> Extended-Location-Policy-Rules Attributes in the Access-Accept
> message for the session.  Upon receipt of a CoA-Request
> message containing a Service-Type Attribute with value
> "Authorize Only" for the same session, the NAS MUST include
> location information and echo the previously received
> Basic-Location-Policy-Rules and Extended-Location-Policy-Rules
> Attributes in the subsequent Access-Request message."
> 
> 
> Section 4.2 says:
> 
>    Length:
> 
>      >= 21
> 
>    String:
> 
>      This field is at least two octets in length, and the format
>      is shown below. The data type of this field is string.
> 
> Suggestion: change "at least two" to "at least 19".  Later in
> the same section, it says:
> 
>    Method (variable):
> 
>      Describes the way that the location information was
>      determined. The values are registered with the 'method' Tokens
>      registry by RFC 4119. The data type of this
>      field is a string.
> 
> Does "registered with the 'method' tokens" mean "along with
> the token values in the same registry" or something else?  I
> _think_ that what the authors are trying to say is "This field
> MUST contain the value of exactly one IANA-registered 'method'
> token [RFC4119]."  If so, maybe they should.
> 
> 
> Section 4.2.1 says "The location format is based on the
> encoding format defined in Section 3.1 of [RFC4776] whereby
> the first 3 octets (i.e., the code for this DHCP option, the
> length of the DHCP option, and the 'what' element are not
> included) are not put into the Location field of the
> above-described RADIUS Location-Data Attribute."  I don't really
> understand: does this mean that 'the location format is
> identical to that defined in RFC 4776 with the exception that
> the first three octets are omitted'?  In any case, RFC 4776
> say in the last paragraph of section 1:
> 
>   The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be
>   used if the civic address option exceeds the maximum DHCPv4 option 
> size of 255 octets. 
> 
> My comments on are similar to those on the Operator-Name
> Attribute above; this case is a little more complicated, due
> to the use of the Index field to associate this attribute with
> the corresponding Location-Information attribute (there seems
> to be an implicit assumption that these always come in pairs).
> 
> 
> Section 4.3 says: "Implementations SHOULD treat this attribute
> as undistinguished octets."  In context, this statement
> doesn't make sense in at least two ways.  First, I have no
> idea how any implementation can treat an entire attribute as
> undistinguished octets, since at least the Type and Length
> fields have to be distinguished.  Maybe the authors mean that
> the String field of the attribute should be treated in this
> way, but that doesn't seem reasonable, either, because that
> field is itself formatted into two distinct fields.
> 
> 
> Section 4.4 says "The Basic-Location-Policy-Rules Attribute
> MAY be sent in an Access-Request, Access-Accept, an
> Access-Challenge, an Access-Reject, a Change-of-Authorization
> and in an Accounting-Request message." but RFC 2865 says
> (section 2, paragraph 7) "If any condition is not met, the
> RADIUS server sends an "Access-Reject" response indicating
> that this user request is invalid.  If desired, the server MAY
> include a text message in the Access-Reject which MAY be
> displayed by the client to the user.  No other Attributes
> (except Proxy-State) are permitted in an Access-Reject."  This
> being the case, it seems like there should be an "Updates:
> 2865" in the first page header of the draft.
> 
> 
> The Location-Capable (section 4.6) attribute can take only a "True"
> value (presumably the lack of client ability would be
> signified by the absence of the Location-Capable Attribute in
> the Access-Request).  This puzzles me a bit: isn't it possible
> that a NAS might be capable of discovering (& therefore,
> communicating) one or a few type of location data and not
> others?  For example, it seems rather likely that a dial-up
> NAS might be capable of conveying its own civic location but
> not the geospatial location of the remote node.  I guess what
> I'm asking is if there isn't a need for a little greater
> granularity here.
> 
> 
> The discussion of the Requested-Location-Info Attribute in
> section 4.7 is remarkably soft and fluffy, attributing such
> things as "wants" and "desires" to servers and clients.  To
> the best of my knowledge, software does not (yet) display
> needs, let alone desires.  This would just be a little
> annoying except that the warm fuzziness spills over into the
> actual specification of what are presumably requirements.  For
> example: 
> 
>   If the RADIUS server wants to dynamically decide on a per-request
>   basis to ask for location information from the RADIUS
> client then the
>   following cases need to be differentiated.  If the RADIUS client and
>   the RADIUS server have agreed out-of-band to mandate the transfer of
>   location information for every network access authentication request
>   then the processing listed below is not applicable.
> 
>   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). 
> 
> In the case of #1, "the RADIUS server can process the
> location-based attributes".  This seems fairly obvious, but
> just because it _can_ doesn't mean that it _will_; it might
> not (presumably based upon its "desires" ;-).  Must the server
> process the location information?  If so, the document should
> say so.  Similarly in case #2, "the RADIUS server may respond
> with an Access-Reject message with an Error-Cause Attribute
> (including the "Location-Info-Required" value)."  If it "may"
> then it may also not; just guessing (since there are
> supposedly only two cases and the information is stated to be
> required in order to process the authorization request) it
> seems to me that the authors really mean "MUST" in both cases
> but that is not clear at all.
> 
>   o  If the RADIUS server would like location information in the
>      Accounting-Request message but does not require it for computing
>      an authorization decision then the Access-Accept message MUST
>      include a Required-Info Attribute.  This is typically the case
>      when location information is used only for billing.  The RADIUS
>      client SHOULD attach location information, if available, to the
>      Accounting-Request (unless authorization policies dictate     
> something different). 
> 
> Once again the server exhibits desire, but this paragraph begs another
> question: if the data referred to by the
> Requested-Location-Info Attribute is actually required and the
> Required-Info Attribute signifies data that is optional, why
> are they named the way they are?
> 
> 
> Change "8.3.  New Registry: Location Capable Attribute" to "8.3.  New
> Registry: Location-Capable Attribute".
> 
> 
> Many references are out of date or incorrect.
> Given that Bernard is a co-author, it may be a bit excessive
> to mention him (thrice!) in the Acknowledgements section _and_
> in the Contributors section as well ;-).
> 
> 
> In section A.1, paragraph 1 change "This section discusses the
> privacy implication for making location information available
> to other entities." to "This section discusses the privacy
> implications of making location information available to other
> entities." 
> 
> Last but not least, this draft fairly universally violates
> several of the guidelines given in
> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02
.txt, in particular those regarding the use of tags to associate
>different attributes (called "Index" in this document) and the 
> creation of "complex" attributes.  I realize that the RADIUS
> design guidelines document is just an Internet-Draft, but it
> is a radext WG document & has been under construction for some
> period of time.  More important than the standardization
> status of the document is the question of whether the
> guidelines make sense; if so, then it may not be such a good
> idea to so completely ignore them; if not, then maybe radext
> should rethink this work item (especially since a co-chair of
> that WG is also a co-author of the document under review).
> 
> 
> 
> 
> _______________________________________________
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv