 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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. In some of the architectures discussed in IEEE 802 Emergency Services study group, the LIS is located on the emergency services VLAN, as are the emergency callers. So the LIS can compare the source MAC address of the requester to the MAC address identifier in the request. There are also scenarios where the client can infer its own location based on receiving information on the location of landmarks such as switch ports or access points. This already supported with LLDP-MED or IEEE 802.11k. Why shouldn't it also be possible with HELD? Here requests are only answered if the MAC address being requested corresponds to a landmark; unauthenticated queries for the MAC addresses of other hosts are denied. If one of the above scenarios doesn't hold, then the query needs to be authenticated, so that the LIS can decide whether the requester is authorized to receive a response.
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 |