Internet DRAFT - draft-hoehrmann-nomap


Network Working Group                                       B. Hoehrmann
Internet-Draft                                         November 26, 2011
Intended status: BCP
Expires: May 29, 2012

                 The "nomap" Network Identifier Suffix


   This memo defines a method for network operators to indicate that
   information about their network is broadcast only to allow legitimate
   participants in the network to connect or re-connect to them, and
   that other uses of such information are to be avoided.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 29, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Hoehrmann                 Expires May 29, 2012                  [Page 1]
Internet-Draft    The "nomap" Network Identifier Suffix    November 2011

1.  Introduction

   Some computer communication standards allow networks to broadcast
   information that allow legitimate participants in the network to
   discover and connect or re-connect to the network.  An example are
   the protocols of the IEEE 802.11 standard which allow identification
   of networks based on a combination of human-readable and other

   While originally only meant to support connecting to the networks,
   such information has since been repurposed for other uses.  For
   instance, when multiple stationary access points are visible from a
   certain point, and the geographical location of the access points is
   known, this knowledge can be used to determine the geographical
   position of such a point when other information like the approximate
   distance to the access points is available, even though the recipient
   of such information does not participate in any of the networks.

   This can have undesired consequences.  When the access points are
   falsely assumed to be stationary, using such data in this manner may
   lead to highly inaccurate triangulation results, and when many
   observations of an access point relative to others is collected by a
   single entity, that can amount to tracking the movements of a
   particular device, including an individual's movement during travel,
   who may use the device to provide connectivity to other devices,
   which may not be intended by the traveler.

2.  The `_nomap` Suffix

   This document defines a convention operators of networks that allow
   the operator to configure a custom name for their networks to
   indicate that information that identifies their networks is to be
   used only to connect to the network, and not for other purposes, like
   geolocation by third parties, to avoid adverse consequences, as
   discussed in this document.

   Specifically, if the configurable identifier ends with a string that
   equals `_nomap` under the i;ascii-casemap collation [RFC4790], that
   is to be understood as indication that information about the network
   is only to be used to connect legitimate participants in the network,
   to the network, as discussed in this document.

   Example: a network operator configures an access point to broadcast
   the name `example_nomap` so participants in the example_nomap network
   can discover and connect to this network.  Someone in the vicinity of
   the network wishes to know the coordinates of their current position
   and they have a device that can do so by scanning for nearby networks
   and submitting information about them to some service they connect

Hoehrmann                 Expires May 29, 2012                  [Page 2]
Internet-Draft    The "nomap" Network Identifier Suffix    November 2011

   to, which then correlates previously collected information to
   determine the coordinates.  If the device respects the convention
   defined in this document, it will not submit any information about
   the `example_nomap` to this service, as the device is not meant to
   connect to the network in this process, and because the network uses
   the `_nomap` convention.  If only the service the device contacts
   respects this convention, then the device itself does not do so; the
   device would be acting contrary to the intent of this memo.

3.  Security Considerations

   The mechanism defined in this document is not a security mechanism.
   Beyond possible confusion about that, it does not introduce any new
   security concerns, but network operators should be aware that marking
   their networks using the mechanism defined in this document might
   make them stand out among nearby networks, which may have
   implications that have not been analyzed for the purposes of this

4.  IANA Considerations


Appendix A.  Acknowledgements

   This convention has originally been proposed by Google Inc. [Google]

5.  References

   [Google]   Fleischer, P., "Greater choice for wireless access point
              owners", November 2011, <

   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
              Application Protocol Collation Registry", RFC 4790,
              March 2007.

Author's Address

   Bjoern Hoehrmann
   Mittelstrasse 50
   39114 Magdeburg


Hoehrmann                 Expires May 29, 2012                  [Page 3]