Internet DRAFT - draft-hoehrmann-nomap
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
draft-hoehrmann-nomap-00
Abstract
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 http://datatracker.ietf.org/drafts/current/.
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
(http://trustee.ietf.org/license-info) 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
identifiers.
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
document.
4. IANA Considerations
None.
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, <http://googleblog.blogspot.com/
2011/11/greater-choice-for-wireless-access.html>.
[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
Germany
EMail: mailto:bjoern@hoehrmann.de
URI: http://bjoern.hoehrmann.de
Hoehrmann Expires May 29, 2012 [Page 3]
