Privacy Considerations for IPv6 Adaptation-Layer Mechanisms
RFC 8065
Document | Type | RFC - Informational (February 2017; No errata) | |
---|---|---|---|
Author | Dave Thaler | ||
Last updated | 2017-02-22 | ||
Replaces | draft-thaler-6lo-privacy-considerations | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Gabriel Montenegro | ||
Shepherd write-up | Show (last changed 2016-09-13) | ||
IESG | IESG state | RFC 8065 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Suresh Krishnan | ||
Send notices to | "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) D. Thaler Request for Comments: 8065 Microsoft Category: Informational February 2017 ISSN: 2070-1721 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms Abstract This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8065. Copyright Notice Copyright (c) 2017 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. Thaler Informational [Page 1] RFC 8065 IPv6-over-foo Privacy Considerations February 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Amount of Entropy Needed in Global Addresses . . . . . . . . 3 3. Potential Approaches . . . . . . . . . . . . . . . . . . . . 4 3.1. IEEE-Identifier-Based Addresses . . . . . . . . . . . . . 5 3.2. Short Addresses . . . . . . . . . . . . . . . . . . . . . 5 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction RFC 6973 [RFC6973] discusses privacy considerations for Internet protocols, and Section 5.2 of that document covers a number of privacy-specific threats. In the context of IPv6 addresses, Section 3 of [RFC7721] provides further elaboration on the applicability of the privacy threats. When interface identifiers (IIDs) are generated without sufficient entropy compared to the link lifetime, devices and users can become vulnerable to the various threats discussed there, including: o Correlation of activities over time, if the same identifier is used for traffic over period of time o Location tracking, if the same interface identifier is used with different prefixes as a device moves between different networks o Device-specific vulnerability exploitation, if the identifier helps identify a vendor or version or protocol and hence suggests what types of attacks to try o Address scanning, which enables all of the above attacks by off-link attackers. (On some Non-Broadcast Multi-Access (NBMA) links where all nodes aren't already privy to all on-link addresses, address scans might also be done by on-link attackers; however, in most cases, address scans are not an interesting threat from on-link attackers and thus address scans generally apply only to routable addresses.) For example, for links that may last for years, "enough" bits of entropy means at least 46 or so bits (see Section 2 for why) in a routable address; ideally all 64 bits of the IID should be used, although historically some bits have been excluded for reasons Thaler Informational [Page 2] RFC 8065 IPv6-over-foo Privacy Considerations February 2017 discussed in [RFC7421]. Link-local addresses can also be susceptible to the same privacy threats from off-link attackers, since experience shows they are often leaked by upper-layer protocols such as SMTP, SIP, or DNS. For these reasons, [RFC8064] recommends using an address generation scheme in [RFC7217], rather than addresses generated from a fixedShow full document text