|
TO
WHOM IT MAY CONCERN: I have read draft-ietf-geopriv-radius-lo-23 and have the
following concerns about it:
a.
Confusion with existing functionality. As
defined in RFC 2865, the RADIUS protocol REQUIRES that NAS identification
attributes be present in a RADIUS Access-Request. When combined with a
wiremap, these attributes (such as NAS-Identifier, NAS-IP-Address and
NAS-IPv6-Address) provide information on the NAS location, which can be used to
infer the user location in a number of common scenarios (e.g. IEEE 802 network
access as envisaged in RFC 3580). Given this pre-existing support
for location, it was surprising for me to read Section 1, which presents the
functionality of this document as though it were new (e.g. “This document
defines attributes… that can be used to convey location-related
information…”). At a minimum, Section 1 needs to describe the
existing RADIUS location functionality, and clearly delineate the additional
value provided by the attributes described in the document.
b.
Confusion about privacy requirements. Given that
RADIUS has always supported transmission of information relating to user
location, and indeed, the transmission of this information is REQUIRED in every
access request, there are a number of statements in the document which appear
to represent major changes to RFC 2865, even though this document does not
indicate that it updates RFC 2865. As an example, Section 1 states that
“location information needs to be protected against unauthorized access and
distribution”, yet nowhere in the document are the implications of this
statement for the RADIUS protocol laid out. Does this statement apply only
to the attributes defined in the document, or does it apply to the NAS
Identification attributes defined in RFC 2865? Do the security
requirements outlined in Section 7 apply to any use of RADIUS, or just to the
attributes in this document? The document is unclear on this point; it
needs to state clearly whether the privacy requirements and rules functionality
applies only to uses of the attributes defined in this document, or to any use
of RADIUS.
c.
Confusion about the meaning of “retransmission
allowed”. As noted in draft-ietf-geopriv-sip-lo-retransmission as
well as in recent discussions on the GEOPRIV WG mailing list, there is
confusion about the meaning of “retransmission allowed”. Since RFC
2865 requires the inclusion of NAS identification in a RADIUS Access-Request,
re-transmission of information related to user-location is an integral part of
the network access authentication and authorization process. As a
result, restrictions on the ability of a RADIUS proxy to retransmit location
information to a RADIUS server are inherently non-deployable. In addition,
many RADIUS proxies will treat attributes they do not understand as opaque
blobs, and so are inherently unable to parse or act upon privacy
policies. However, on reading this document, I had many of the same
questions as were raised in draft-ietf-geopriv-lo-retransmission with respect
to SIP conveyance, as to whether privacy policies applied to RADIUS
conveyance. Some of this confusion was enhanced by Section A.2,
entitled “Distribution of location information at the Visited Network”. Is
the issue really distribution of location information within the RADIUS realms
on the roaming relationship path, or is it retransmission of location
information outside those entities? This is a critical point – but
one that the document leaves unclear.
d.
Consistency with RADIUS architecture. With respect to
privacy policies, it is unclear whether draft-ietf-geopriv-radius-lo-23
requires RADIUS proxies to inspect RADIUS attributes prior to re-transmission,
to understand that certain RADIUS attributes contain location information and
to implement policies encoded within those attributes. If so, this would be an
ominous and undesirable requirement to place on RADIUS implementations because
RADIUS servers need not have explicit knowledge of the all attributes they transmit
or re-transmit. Such a requirement would be even more undesirable in
multi-vendor deployments where RADIUS interoperability is required.
e.
Implications for RADIUS accounting and billing.
RADIUS accounting data – which includes location-related information - is
commonly made available to RADIUS proxies and servers today. In some
cases, RADIUS accounting data is stored on the visited network proxy and in
other cases, the RADIUS accounting data is forwarded to an intermediate or home
realm for storage in a database. When ‘re-transmission allowed’ is set to
0 (the default), does this mean that RADIUS accounting data that includes
location information cannot be re-transmitted to another realm? If so,
then this document would disrupt the transmission of accounting data which is
legally required to be maintained by statues such as Sarbanes Oxley.
Thanks, Anthony
Leibovitz Principal
Program Manager Microsoft
Corporation |