 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Semantic fluff? If you like. I was trying to be precise in definitions – such things are
important in understanding the decisions that people make with respect to
policy. Being able to recognize that you are making a policy decision is the
first part in then understanding the implications of that decision. If the LIS can determine that the requester and target are the
same – to its satisfaction, and I wont define what that means ;) – then it can
use LCP policy; otherwise the security of the system demands that it operate on
another policy. That is the crux of Cullen’s complaint. However, if no such alternative
policy exists, then it cannot provide location. That’s what the draft says. --Martin From: Dawson, Martin Well sure – which is to say “it’s all semantic fluff”. The device is asking for its own location – and providing an
identity value that will help with that process. I haven’t seen the actual
mathematical proof that says that isn’t LCP but… sure… I’ll take your word for
it. There are certainly rule makers at play somewhere. Cheers, Martin From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On Behalf Of Thomson, Martin That is, these scenarios really are third party request
scenarios and each require explicit policy. What that conclusion, I see
no issue. Martin, your scenario is simply not “LCP”. If the
enterprise decides that all hosts in the network can access location
information for all other hosts, then they act as Rule Maker when allowing
this. While some of us may disagree with this policy, that is their
prerogative as Rule Maker (as long another more powerful Rule Maker prevents
it, like a legislator). --Martin From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On Behalf Of Bernard Aboba Is it really necessary to require that
"trust extend to all hosts" in order to use a MAC address as an
identifier? If that is really the requirement (personally, I don't think
it needs to be), then I'd agree with Cullen that this work is outside the
charter of GEOPRIV WG. From: Bernard Aboba
[mailto:bernard_aboba at hotmail.com] In the scenario given, is it really true that “anybody cares or
is in any way at risk if a client offers a MAC address that isn’t its
own”? [[MCD]] It is – and that’s up to the owner and
users of the network to decide. If it wasn’t – i.e. trust does not extend to
all hosts – then it would not be appropriate for a LIS serving such an
environment to provide location based on proffered MAC address alone. I can
consider the events you mention; and conclude that you’re describing a
different scenario. My understanding is that providing blanket access to the
geographic location of any employee without authorization would violate privacy
laws within some nations (I am thinking about Germany in particular).
So I’m aware of a number of enterprise Privacy officers who care quite a
bit about this. As to whether someone is at risk, consider recent violent
stalking incidents at the University of Washington and other
places. Can we really say that no one would be put at risk by allowing
their location to be tracked in real time by an unauthorized person?
I’m aware of quite a few people whose lives could be put at risk by
something like this. Marc Linsner said: “I find it very interesting that the IT department
embraces the new functionality of providing location to network clients but
refuses to implement the tools to get the job done. Maybe they should
look at a LLDP-MED solution.” I know quite a few IT departments that have no plans to
implement either DHCP or LLDP-MED. Most endpoints in the
enterprise do not support DHCP location today, so even if IT has a DHCP server
that would support this, this solution will typically not be applicable.
While most switches support LLDP today, access points typically do not and
therefore a solution may be desired which applies to both wired and
wireless. In contrast, HELD offers the potential for use on both wired and
wireless media without any required changes to system-level
components. From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On Behalf Of Dawson, Martin I was thinking of a simple practical example. I have a closed private/enterprise network with a bunch of location
client devices to my LIS. My LIS has access to the bridge MIBs on all the
switches in the building(s) and it has the wiremap that relates each switch
port to the location of the wall jack or area of coverage of the wireless
access point to which that port is connected. So – given a MAC address, the LIS
can determine the associated switch/port and corresponding location by
performing the bridge MIB query on the switches followed by a wiremap look up. In this network the DHCP implementation is limited; it doesn’t
support the DHCP lease query for example… and the IT department refuses to
change or permit it to be patched to support the functionality. So, I’m stuck,
not being able to translate the IP address of my requesting clients into the
corresponding MAC address that allows me to provide them with location. Now there are absolutely no interesting scenarios in this
environment where anybody cares or is in any way at risk if a client offers a
MAC address that isn’t its own. It’s simply not a problem. In this particular trust arrangement, it’s acceptable for the LIS
to return the location to the requester. This is a real situation; not just a
hypothetical one. Trust always involves nominating where risk is considered
acceptable. Even if the DHCP server wasn’t so “challenged”, the LIS still has
to trust the information acquired from it. In principle the DHCP server could
be compromised… or have devious intent. In order to obviate this concern, the
trust arrangement has to encompass the DHCP server as well. Cheers, Martin From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On Behalf Of Bernard Aboba We've
had some discussion on this topic before. The answer probably
involves |