[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of draft-ietf-geopriv-radius-lo-04.txt
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?
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.)
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?
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.
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?
--
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/>