Subject: RE: DRAFT-IETF-GEOPRIV-RADIUS-LO-23

From: Anthony Leibovitz <[email-masked]>
Date: Tue, 7 Apr 2009 21:56:01 -0700

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 08 Apr 2009 08:49:00 +0200

Anthony Leibovitz wrote:
>   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

  NAS-Identifier / NAS-IP-Address can only be "location attributes" in
certain limited situations.  Those situations are networks that are
small, and under a common administrative control.

  In a proxying scenario, or global roaming, the NAS identification
attributes have little meaning.  They identify a provider (possibly),
and if you're lucky, a city.

  They identify physical location only as a side effect of (possibly)
identifying a network location.

>   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. 

  The new attributes define location based on physical identifiers
(lat/long).  They are independent of the network.  i.e. If the network
topology changes, the lat/long identifiers will not change.  In
contrast, network topology changes have large impact on NAS-IP-Address
"location" identification.

>   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.

  Most RADIUS servers and proxy scenarios already implement filtering
rules.  These rules can be updated to filter out the geopriv attributes.

>   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.

  I would disagree.  RADIUS *network* location is available.  Sometimes.
 The value of that information is small.

>  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. 

  I disagree.  The geo-location attributes are not used today, so *not*
having them in the future imposes no change on the network.

  In addition, many of these issues affect inter-country, and
inter-company requirements.  If I'm buying network access from a
provider, I can (a) require that they supply geo-location information,
or (b) go elsewhere, or (c), make them state that they will not supply
the information.

  i.e.  The existence (or not) of geo-location information is likely a
contractual issue, and not a technical issue.  We need to provide the
participants with the ability to supply the data, or to filter it out of
a traffic stream.  Any requirements past that mean that we are forcing
the legal requirements of one jurisdiction on every other jurisdiction.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 Apr 2009 08:49:00 +0200

Alan DeKok.