Re: DRAFT-IETF-GEOPRIV-RADIUS-LO-23

[Alan DeKok <aland@deployingradius.com>]

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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>