[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Review of draft-ietf-geopriv-radius-lo-04.txt
hi bernard,
please find my comments below:
> Review of draft-ietf-geopriv-radius-lo-04.txt
>
> The RADEXT WG Issues page discloses that 13 issues remain open against
> this document:
> http://www.drizzle.com/~aboba/RADEXT/
>
> Based on a preliminary review of the -04 version, it appears that some
> of these open issues still have not been addressed. Some
> notes below:
>
> Section 2
>
> " Furthermore, the authors believe that there is a relationship
> between the location of the network and the location of the entity
> that triggered the network access authentication. Knowing the
> location of a network (where the user or end host is attached to)
> might in many networks also reveal the location of the user or end
> host. In some networks it is even possible to provide a accurate
> location of the user or end host. A similar assumption is
> also made
> with regard to the location information obtained via DHCP (see for
> example [4]). This information might be used by applications in
> other protocols (such as SIP [12] with extensions [13]) to indicate
> the location of a particular user even though the location "only"
> refers to the location of the network or equipment within the
> network. The assumption here is also that the location of the
> network has some relationship to the location of the end host (and
> subsequently to a user). This assumption might not hold in all
> scenarios. Nevertheless, it seems to be reasonable."
>
> RADEXT Issue 27 points out that this assumption is
> not correct -- the location of the peer and the location of the
> NAS are not the same thing. There are APs today that are capable
> of providing the location of the user with a high degree of accuracy.
> Can those APs use this specification to provide the NAS and peer
> location information independently?
i guess this is an issue that we could potentially discuss forever.
in fact we discussed this issue for a long time and this particular
paragraph was added based on joel's comments.
technology exists to determine the location of the end host. the draft
allows to add this location information for transmission to the radius
server. if the location of the end host cannot be determined then all
you can do is to provide information about the nas (since you don't have
anything else).
>
> Section 3.2
>
> RADEXT Issue 74 points out problems with the way this document uses
> RFC 3576.
>
> The COA message may instruct the
> access network to generate an Authorize-Only
> Access-Request (Access-
> Request with Service-Type set to "Authorize-Only") in
> which case the
> NAS MUST include the location infromation in this Access-Request.
>
> This paragraph appears to retroactively update RFC 3576.
>
> Upon receiving the Authorize-Only message from the access network,
> the AAA server MUST respond with either an Access-Accept message or
> an Access-Reject message.
>
> This also sounds like an update of RFC 3576. Why should RFC 3576
> behavior be different when location attributes are included?
>
> More fundamentally, why does RFC 3576 need to be used to
> obtain location
> information in mid-session when the same info is available in
> Accounting
> packets? Or is the issue that location data may not be included in
> Interim accounting information? I didn't notice a way that the RADIUS
> server can configure the way the NAS sends location info
> (e.g. don't send
> in interims, send at a given interval different from the
> interim interval,
> etc.)
i need to forward this issue to avi since he wrote this paragraph.
>
> Section 4
>
> How the network obtains the user's
> location information is out of the scope of this document.
>
> See RADEXT Issue 27. Obtaining the peer location is one of the
> fundamental usage scenarios for RADIUS-based location information.
> If this is out of scope for this specification, a different
> specification will be needed to address that issue. Why not handle
> both issues within the same document?
the technology for location determination of the end hosts location
information depends on factors that are outside the scope of this
document. manual configuration, triangulation, usage of location
protocols developed in other standardization organization, etc. are
examples.
it is not uncommon to treat some topic as out-of-scope if they touch a
different area.
>
> Section 8
>
> The capability attribute allows the RADIUS client to
> indicate whether
> civic and/or geospatial location information can be provided to the
> RADIUS server. This is useful to avoid sending location
> information
> with every request if no further out-of-band arrangements are made
> with regard to the transport of location information. The
> AAA server
> uses the capability attribute to indicate that the AAA
> client has to
> provide civic and/or geospatial location information as
> part of this
> particular protocol exchange. If the AAA server does not send a
> capability attribute then the AAA client MUST NOT return location
> information. The user's authorization policies MUST be
> consulted by
> the AAA server before requesting location information delivery from
> the AAA client. If the AAA server encounters that the AAA client
> does not support the desired location information it might respond
> with an Access-Reject with the corresponding error cause attribute
> (with the Location-Info-Required error code).
>
> The above paragraph seems vague about the nature of the capability
> negotiation. Terms like "might respond" imply a range of
> acceptable behaviors, which could result in interoperability
> problems.
>
> Since Access-Requests are initiated by the NAS, there is no way
> for the NAS to know beforehand whether a given RADIUS server requires
> location information or not. However, a NAS might default to not
> sending location information and then if the AAA server sends back
> an Access-Reject with a Location-Info-Required error code, then it
> could enable it. This seems to handle the case where the RADIUS
> server requires location (e.g. won't grant access without it).
>
> Based on the rest of Section 8, it appears that there are other
> scenarios in which the RADIUS server might like location information
> if available, but does not require it. In these cases, the
> RADIUS server could send back an Access-Accept with a request for
> location information, specifying what kind of location it is
> asking for (NAS or peer). If the NAS does not understand
> the attribute it will ignore it.
>
> Overall, it is not clear to me why the Capability attribute
> is needed, or
> if so, what the goal is.
i have read your other mails about this subject as well and i appreciate
to receive feedback about it.
it is good to hear opinion from other people.
if people in general think that the capability exchange is not need and
other mechanisms provide similar characteristics (as discussed in other
mails) than i am happy to change it.
>
> Section 11
>
> Why is a capability attribute needed in an Access-Challenge? Why
> is "Location-Info-Required" a new attribute rather than a value
> of Error-Cause? Why are Basic-Policy-Rules, Extended-Policy-Rules,
> Capability and Location-Info-Required attributes allowed in an
> Access-Reject?
i incorporated this proposal based on the feedback i got. now, i get the
feedback i want and that's good.
unfortunately it turns out to be quite complicated to have two working
groups working on a single document. i wasn't even able to attend the
ietf#62 meeting where this particular issue was discussed (since it was
ironically conflicting with the geopriv meeting, if i remember it
correctly).
after reviewing all the mails regarding the review of
draft-ietf-geopriv-radius-lo-04.txt it appears that most issues are
refer to the capability exchange. i suspect that resolving the
capability exchange issue will resolve the main concerns.
ciao
hannes
>
> --
> 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/>
>
--
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/>