Re: The "nomap" Network Identifier Suffix

Eric Burger <eburger@standardstrack.com> Wed, 27 November 2013 08:51 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8A71AD944 for <ietf@ietfa.amsl.com>; Wed, 27 Nov 2013 00:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level:
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbV07bNqa4yV for <ietf@ietfa.amsl.com>; Wed, 27 Nov 2013 00:51:30 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5511D1AE008 for <ietf@ietf.org>; Wed, 27 Nov 2013 00:51:20 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:53950 helo=[192.168.15.104]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1Vlapz-00073H-OF for ietf@ietf.org; Wed, 27 Nov 2013 00:51:20 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_81B9B279-72FF-47FC-95B7-8B942975AFC0"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <79B6D9EF-D7E7-45C9-A1C9-9CE602D87A16@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: The "nomap" Network Identifier Suffix
Date: Wed, 27 Nov 2013 03:51:10 -0500
References: <i9n799hrr1vfp4bobt9tc55rn1aip73rts@hive.bjoern.hoehrmann.de> <3D4E298A-FE87-4FD1-BCC2-EF33E7BD4D99@cs.georgetown.edu> <B15E89D0-3C72-4A5C-9838-BBF305D92A59@mnot.net> <CAL02cgT2LPy37d4EdYtMzCAtT9Q458+ZEfsC1xshVS6j_tVJFg@mail.gmail.com>
To: IETF-Discussion Discussion <ietf@ietf.org>
In-Reply-To: <CAL02cgT2LPy37d4EdYtMzCAtT9Q458+ZEfsC1xshVS6j_tVJFg@mail.gmail.com>
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-1.1
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2013 08:51:32 -0000

<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 <rlb@ipv.sx> wrote:

> 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 <mnot@mnot.net> 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.
> 
> 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,
> 
> 
> On 26 Nov 2013, at 11:04 pm, Eric Burger <eburger@cs.georgetown.edu> wrote:
> 
> > Tastes like the ‘evil’ bit, in reverse.
> >
> > On Nov 25, 2013, at 6:50 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> >
> >> 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:bjoern@hoehrmann.de · 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/
> 
> 
> 
>