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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf