--- 1/draft-ietf-dhc-dhcpv6-privacy-02.txt 2016-01-20 15:15:26.303905047 -0800 +++ 2/draft-ietf-dhc-dhcpv6-privacy-03.txt 2016-01-20 15:15:26.339905933 -0800 @@ -1,21 +1,21 @@ dhc S. Krishnan Internet-Draft Ericsson Intended status: Informational T. Mrugalski -Expires: June 29, 2016 ISC +Expires: July 23, 2016 ISC S. Jiang Huawei Technologies Co., Ltd - December 27, 2015 + January 20, 2016 Privacy considerations for DHCPv6 - draft-ietf-dhc-dhcpv6-privacy-02 + draft-ietf-dhc-dhcpv6-privacy-03 Abstract DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document described the privacy issues associated with the use of DHCPv6 by the Internet users. It is intended to be an analysis of the present situation and doe not propose any solutions. Status of This Memo @@ -26,25 +26,25 @@ 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 June 29, 2016. + This Internet-Draft will expire on July 23, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 @@ -73,25 +73,25 @@ 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 8 4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 8 4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 9 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Device type discovery (fingerprinting) . . . . . . . . . 10 5.2. Operating system discovery (fingerprinting) . . . . . . . 11 5.3. Finding location information . . . . . . . . . . . . . . 11 5.4. Finding previously visited networks . . . . . . . . . . . 11 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 11 - 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 12 + 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 11 5.7. Finding client's IP address or hostname . . . . . . . . . 12 5.8. Correlation of activities over time . . . . . . . . . . . 12 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 12 - 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 13 + 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction @@ -142,21 +142,22 @@ its client-id stored in stable storage while other may generate it on the fly and use a different one after each boot. Stable identifier may or may not be globally unique. 3. DHCPv6 options carrying identifiers In DHCPv6, there are many options which include identification information or can be used to extract the identification information about the client. This section enumerates various options and identifiers conveyed in them, which can be used to disclose client - identification. + identification. The attacks that are enabled by such disclosures are + detailed in Section 5. 3.1. DUID Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID) [RFC3315]. The DUID is designed to be unique across all DHCPv6 clients and servers, and to remain stable after it has been initially generated. The DUID can be of different forms. Commonly used forms are based on the link-layer address of one of the device's network interfaces (with or without a timestamp), on the Universally Unique IDentifier (UUID) [RFC6355]. The default type, defined in @@ -485,26 +486,25 @@ Client System Architecture Type option, or by using fingerprinting techniques on the combination of options requested using the Option Request option. See Section 3.4 of [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion about this type of attack. 5.3. Finding location information The location information can be obtained by the attacker by many means. The most direct way to obtain this information is by looking - into a message originating from the server server that contains the - Civic Location or GeoLoc option. It can also be indirectly inferred - using the Remote ID Option, the Interface ID option (e.g. if an - access circuit on an Access Node corresponds to a civic location), or - the Subscriber ID Option (if the attacker has access to subscriber - info). + into a message originating from the server that contains the Civic + Location or GeoLoc option. It can also be indirectly inferred using + the Remote ID Option, the Interface ID option (e.g. if an access + circuit on an Access Node corresponds to a civic location), or the + Subscriber ID Option (if the attacker has access to subscriber info). 5.4. Finding previously visited networks When DHCPv6 clients connect to a network, they attempt to obtain the same address they had used before they attached to the network. They do this by putting the previously assigned address(es) in the IA Address Option(s). [RFC3315] does not exclude IA_TA in such a case, so it is possible that a client implementation includes an address contained in an IA_TA for the Confirm message. By observing these addresses, an attacker can identify the network the client had @@ -562,23 +562,24 @@ can send ICMPv6 echo requests or other probe packets to networks of suspected client locations) can be used. To give specific example, by accessing a social portal from tomek- laptop.coffee.somecity.com.example, tomek- laptop.mycompany.com.example and tomek-laptop.myisp.example.com, the portal administrator can draw conclusions about tomek-laptop's owner current location and his habits. 5.10. Leasequery & bulk leasequery - Attackers may pretend as an access concentrator, either DHCPv6 relay - agent or DHCPv6 client, to obtain location information directly from - the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] mechanism. + Attackers may masquerade as an access concentrator, either DHCPv6 + relay agent or DHCPv6 client, to obtain location information directly + from the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] + mechanism. Location information is information needed by the access concentrator to forward traffic to a broadband-accessible host. This information includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem. Furthermore, the attackers may use DHCPv6 bulk leasequery [RFC5460] mechanism to obtain bulk information about DHCPv6 bindings, even without knowing the target bindings. @@ -604,22 +605,22 @@ DHCPv6. As such, no dedicated discussion is needed. 8. IANA Considerations This draft does not request any IANA action. 9. Acknowledgements The authors would like to thank Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian Schaefer, Jinmei Tatuya, Bernie Volz, - Marcin Siodelski, Christian Huitema and other members of DHC WG for - their valuable comments. + Marcin Siodelski, Christian Huitema, Brian Haberman and other members + of DHC WG for their valuable comments. This document was produced using the xml2rfc tool [RFC2629]. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,