 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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 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 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 As to whether
someone is at risk, consider recent violent stalking incidents at the “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 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 |