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, . [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]