Subject: The "nomap" Network Identifier Suffix

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 26 Nov 2013 00:50:41 +0100

Hi,

  My smartphone can turn into a Wifi access point so I can easily use
its Internet connection from my netbook. Problem is that nearby devices
I do not control might report my whereabouts to third parties that map
network equipment to geographic locations. A naming convention for net-
works has been proposed to address this, append "_nomap" to the network
name and "good actors" will ignore it. I thought it would be a good idea
to document this convention in a better place than a single vendor's
blog post, so two years ago today I published

  http://tools.ietf.org/html/draft-hoehrmann-nomap-00

I think this is a "better than nothing" mechanism and I am not the most
qualified person to document it, and there was pretty much no interest
in the document when I announced it. Still, especially considering more
and more organisations are collecting such data, I think this needs good
documentation. I am looking for volunteers, suggestions, whatever helps
getting that done without a lot of effort on my part...

Thanks!
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Burger <[email-masked]>
Date: Tue, 26 Nov 2013 07:04:00 -0500

Tastes like the ‘evil’ bit, in reverse.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Nov 2013 15:13:38 -0500

I think that's a little facile.

The evil bit is ridiculous because evil people have no incentive to set it
(thus nobody would ever look for it to be set).  With the _nomap suffix,
the people who would need to set it have an incentive to do so, and at
least in certain cases, the entities that might consume it have incentives
to obey it as well.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Nov 2013 15:15:38 -0500

On Nov 26, 2013, at 3:13 PM, Richard Barnes <[email-masked]> wrote:
> The evil bit is ridiculous because evil people have no incentive to set it (thus nobody would ever look for it to be set).  With the _nomap suffix, the people who would need to set it have an incentive to do so, and at least in certain cases, the entities that might consume it have incentives to obey it as well.

Yup.   Google certainly paid a high price recently for doing something analogous to ignoring this suffix.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Nov 2013 08:27:24 +1100

In message <[email-masked]>, Ted Lemon writes:
> > The evil bit is ridiculous because evil people have no incentive to set
> > it (thus nobody would ever look for it to be set).  With the _nomap
> > suffix, the people who would need to set it have an incentive to do so,
> > and at least in certain cases, the entities that might consume it have
> > incentives to obey it as well.
>

No Google paid a high price for storing more than what every box
uses when it displays a list of available WiFi networks.  If they
had just done that I suspect that they would have been fine.

As for this proposal.  I think it is a waste of time.  If you need
this information then it needs to be built into the signaling
elsewhere and that is a job for IEEE not IETF.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Nov 2013 22:16:42 +0000

> I think that's a little facile.

Ok, how's this then....

This reminds me of DNT which was one we passed on when it
was brought to the IETF and I think we should be glad we
did that.

Now I *think* there are fewer adversaries in this case and
those are maybe less adversarial but this has the same
property that there's no technical enforcement mechanism
at all, which makes me wonder.

That said, this might be an ok thing, I guess.

I'd prefer if IEEE provided me a way to have my (E)SSIDs
etc. look random every time to non-authenticated devices
or something. Or to have a way to have us all easily be
able to share a few SSIDs and MAC addresses. There are
probably loads of reasons why that'd not work, but if it
did at least then we'd not just be depending solely on
the kindness of strangers.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Nov 2013 09:27:37 +1100

Separate from the issues surrounding enforcing declared policy, putting metadata into identifiers seems like a bad practice. 

Besides the issue of scalability — do we really want a SSID that looks like “mnot_nomap_guestsallowed_privacyguaranteed_prettyplease” — this proposal is squatting on ALL suffixes; someone who wants to define the “_guestsallowed” suffix, for example, now can’t do so because it’s in contention with _nomap. 

Never mind that it’s retroactively assigning semantics to potentially existing identifiers.

These issues seem very similar to those raised in the draft-nottingham-uri-get-off-my-lawn. It’s very tempting for us as standards bodies to encroach upon user-visible identifier space, but doing so brings a number of concrete technical problems, as well as a higher concern; that these name spaces are explicitly defined to be under user (or administrator) control, and taking that control away retroactively shouldn’t be something we do.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Nov 2013 02:34:28 +0000

> Separate from the issues surrounding enforcing declared policy, putting metadata into identifiers seems like a bad practice. 

True. And it is also a very ineffective way to get privacy. If you want to not be tracked, you should at a minimum randomize the SSID, and probably the Wi-Fi MAC address as well. Of course, that's a bit inconvenient today, because the user is in the loop, and has to agree to connect to the SSID, and enter the security key. But it can in theory be solved. For example, if the SSID encrypts something like "MyRealSSID+someRandomNumber" with a known key, the modified WiFi client could automatically decrypt it. Needs work, but seems more robust than relying on the good will of strangers.

-- Christian Huitema

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Nov 2013 22:51:13 -0500

I think we mostly agree here, Mark, but just playing devil's advocate...

If we want things to deploy with any speed, we need the people who want to
deploy them to be able to.  The people who would deploy this sort of policy
mechanism cannot change the 802.11 protocols their WiFi chipsets use, but
they *can* change an SSID or parse an SSID.  If you wait IEEE to make a
standard, and vendors to build it, and ... well, I'll see you in a few
years.

Yes, it's a hack, but the Internet lives on hacks.  And people are using
it, so what's the harm in documenting it?  To make an analogy, how many
RFCs for v4/v6 transition schemes do we have that slam an IPv4 address into
an IPv6 address?

--Richard (who really doesn't have a dog in this fight, but generally likes
the fast path instead of the long, slow, painful, expensive path)

On Tue, Nov 26, 2013 at 5:27 PM, Mark Nottingham <[email-masked]> wrote:

> Separate from the issues surrounding enforcing declared policy, putting
> metadata into identifiers seems like a bad practice.
>
> Besides the issue of scalability — do we really want a SSID that looks
> like “mnot_nomap_guestsallowed_privacyguaranteed_prettyplease” — this
> proposal is squatting on ALL suffixes; someone who wants to define the
> “_guestsallowed” suffix, for example, now can’t do so because it’s in
> contention with _nomap.
>
> These issues seem very similar to those raised in the
> draft-nottingham-uri-get-off-my-lawn. It’s very tempting for us as
> standards bodies to encroach upon user-visible identifier space, but doing
> so brings a number of concrete technical problems, as well as a higher
> concern; that these name spaces are explicitly defined to be under user (or
> administrator) control, and taking that control away retroactively
> shouldn’t be something we do.
>
> Cheers,
>
>

---

From: "John Levine" <[email-masked]>
Date: 27 Nov 2013 04:52:26 -0000

>Tastes like the ‘evil’ bit, in reverse.

And it has the same problem as do-not-track, there's no way to tell
whether people you don't trust are following it.

Do-not-track is sort of modeled on do-not-call, which is self
documenting in the sense that if someone ignores it, you can tell
because your phone rings and it's a telemarketer.  But if they ignore
do not track or do not map, you can tell, how?  Suspiciously relevant
ads on your device?

This is worse than nothing because it gives naive people a false sense
of control.  Real control is fine, knowing you don't have control is
tolerable, thinking you do when you don't is bad.

R's,
John

---

From: joel jaeggli <[email-masked]>
Date: Tue, 26 Nov 2013 21:08:59 -0800

On 11/26/13, 2:27 PM, Mark Nottingham wrote:
> Separate from the issues surrounding enforcing declared policy,
> putting metadata into identifiers seems like a bad practice.
> 
> Besides the issue of scalability — do we really want a SSID that
> looks like “mnot_nomap_guestsallowed_privacyguaranteed_prettyplease”
> — this proposal is squatting on ALL suffixes; someone who wants to
> define the “_guestsallowed” suffix, for example, now can’t do so
> because it’s in contention with _nomap.

32 octets is not a lot when you're trying to overload semantic meaning
on top of identifer, you'll run out fast.

> standards bodies to encroach upon user-visible identifier space, but
> doing so brings a number of concrete technical problems, as well as a
> higher concern; that these name spaces are explicitly defined to be
> under user (or administrator) control, and taking that control away
> retroactively shouldn’t be something we do.
> 
> Cheers,
> 
> 
>>> My smartphone can turn into a Wifi access point so I can easily
>>> use its Internet connection from my netbook. Problem is that
>>> nearby devices I do not control might report my whereabouts to
>>> third parties that map network equipment to geographic locations.
>>> A naming convention for net- works has been proposed to address
>>> this, append "_nomap" to the network name and "good actors" will
>>> ignore it. I thought it would be a good idea to document this
>>> convention in a better place than a single vendor's blog post, so
>>> two years ago today I published
>>> 
>>> I think this is a "better than nothing" mechanism and I am not
>>> the most qualified person to document it, and there was pretty
>>> much no interest in the document when I announced it. Still,
>>> especially considering more and more organisations are collecting
>>> such data, I think this needs good documentation. I am looking
>>> for volunteers, suggestions, whatever helps getting that done
>>> without a lot of effort on my part...
>>> 
>>> Thanks! -- Björn Höhrmann · mailto:[email-masked] ·
>>> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon:
>>> +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll ·
>>> PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>> 
> 
> -- Mark Nottingham   http://www.mnot.net/
> 
> 
> 
>

---

From: SM <[email-masked]>
Date: Tue, 26 Nov 2013 22:55:20 -0800

At 19:51 26-11-2013, Richard Barnes wrote:
>be able to.  The people who would deploy this sort of policy 
>mechanism cannot change the 802.11 protocols their WiFi chipsets 
>use, but they *can* change an SSID or parse an SSID.  If you wait 
>IEEE to make a standard, and vendors to build it, and ... well, I'll 
>see you in a few years.

The proposal has been implemented in the Securifi Almond WiFi 
Router.  It is also supported by Mozilla and Google.

draft-hoehrmann-nomap-00 does not contain any occurrence of the word 
"privacy".  According to the Dutch Data Protection Authority, "Google 
has complied with the requirement to inform those involved, both 
online and off-line, about the processing of WiFi data and about the 
possibility of registering their refusal by means of an opt-out 
possibility".  I suggest having some text to discuss the privacy 
angle.  The draft could discuss the pros and cons of the identifier convention.

>Yes, it's a hack, but the Internet lives on hacks.  And people are 
>using it, so what's the harm in documenting it?  To make an analogy, 
>how many RFCs for v4/v6 transition schemes do we have that slam an 
>IPv4 address into an IPv6 address?

A lot. :-)

Regards,
-sm

---

From: Eric Burger <[email-masked]>
Date: Wed, 27 Nov 2013 03:51:10 -0500

<university level parsing>
So instead of taking this to IEEE where in three years the chipsets will have burned into them such a privacy mechanism, meaning that only state actors or well-financed bad folks will break the convention, we will do the work in the IETF where in three years the open source routers might sometimes honor such a convention and users get nothing?
</university level parsing>

<Joe Sixpack parsing>
Take to IEEE. Wait three years. Manufacturers make devices that do best efforts at handling user’s requests. User’s requests go into 802.11 negotiation. User’s requests are not obvious for all sniffers to see. Only sophisticated attacks need apply.
-- or --
Take to IETF. Wait three years. Most manufacturers ignore RFC. Those that do, do not count. Google gets to wrap itself in a very thin layer of legal protection. User’s requests broadcast “look at me. I do not want to be tracked. Please target me.” Maybe the security is that since this is so close to not doing anything, the bad guys will feel it is below their dignity to bother to track people. <ha ha ha!>
</Joe Sixpack parsing>

On Nov 26, 2013, at 10:51 PM, Richard Barnes <[email-masked]> wrote:

> If we want things to deploy with any speed, we need the people who want to deploy them to be able to.  The people who would deploy this sort of policy mechanism cannot change the 802.11 protocols their WiFi chipsets use, but they *can* change an SSID or parse an SSID.  If you wait IEEE to make a standard, and vendors to build it, and ... well, I'll see you in a few years.
> 
> Yes, it's a hack, but the Internet lives on hacks.  And people are using it, so what's the harm in documenting it?  To make an analogy, how many RFCs for v4/v6 transition schemes do we have that slam an IPv4 address into an IPv6 address?
> 
> --Richard (who really doesn't have a dog in this fight, but generally likes the fast path instead of the long, slow, painful, expensive path)
> 
> 
> 
> 
> 
>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 27 Nov 2013 13:14:24 +0000

I'm not a fan of the suffixes, but I appreciate the goal.

FWIW, every time I run up certain mobile hotspots, my online presence is
instantly translated through space (sadly not time) to various hotels and
places around the UK. Sadly, my offline presence cannot be so translated,
otherwise I would save a small fortune in air fares, not to mention the
convenience.

This isn't, though, a security issue. If I have geoloc info going out, I'm
entirely happy for it to say where I am. I'm just not happy when it tells
everyone I'm in a Travelodge in Kingston - not because I'm ashamed of ever
having been there (although perhaps I should be) but because it's simply
inconvenient.

I'd be happy if either geoloc knew to ignore the access point as a location
beacon, or else it actually teleported me. The latter is actually
preferable, but the former's good as well.

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Nov 2013 09:42:32 -0500

> whether people you don't trust are following it.

I thought the point was for it to advise network geolocation survey bots that the hotspot with this ssid is mobile and can't be used for geolocation.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Nov 2013 07:21:46 +1100

In message <[email-masked]>, Ted Lemon writes
:
> I thought the point was for it to advise network geolocation survey bots
> that the hotspot with this ssid is mobile and can't be used for
> geolocation.
>

The point was for it to advise network survey bots that the hotspot
with this ssid can't/shouldn't be recorded in any database.

There are reasons to set this other than the ap is mobile.

---

From: Eric Burger <[email-masked]>
Date: Wed, 27 Nov 2013 15:27:17 -0500

More of a reason for it to be at the 802.11 level, not SSID. Say what we mean, not just a hint.

---

From: David Farmer <[email-masked]>
Date: Wed, 27 Nov 2013 15:40:47 -0600

On 11/27/13, 14:21 , Mark Andrews wrote:
> In message <[email-masked]>, Ted Lemon writes:
>

While it is possible to set it for other reasons like privacy, I'm not 
sure the motivations/interests fully align for all parties for these 
other reasons.

Where as, with mobile APs and geolocation the motivations/interests of 
the parties fully align.  If you have a mobile AP and it is mapped in a 
location and then you move, your location will be inaccurate, therefore 
you should set the "_nomap" suffix.  And, if you are a geolocation 
provider and are mapping APs, you will create inaccurate information if 
you map mobile APs, and therefore it is in your interest to not map the 
location of APs with the "_nomap" suffix.

Opt in or out mechanisms only work when the parties interests are 
aligned.  So in reality I think both Mark and Ted are correct.

I'd support this being documented in an informational RFC, I'd like to 
see a full discussion of the advantages and disadvantages, as well as a 
call for a more formal solutions to this and some of the related issues 
in the thread.  Does Hotspot 2.0 or other Wifi Alliance stuff cover 
this?  Or at least there may be useful references there.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================