Internet DRAFT - draft-rafiee-6man-ra-privacy
draft-rafiee-6man-ra-privacy
Network Working Group H. Rafiee
INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH
C. Meinel
Intended status: Informational Hasso Plattner Institute
Expires: April 1, 2015 October 1, 2014
Router Advertisement based privacy extension in IPv6 autoconfiguration
<draft-rafiee-6man-ra-privacy-09.txt>
Abstract
The purpose of this document is to address the privacy issues that
exist within the Privacy Extension specification and offer an
alternative privacy aware solution to correct these shortcomings and
also offer an alternative random number generator.
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 Expires: October 1, 2014.
Copyright Notice
Copyright (c) 2013 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
Rafiee, et al. Expires April 1, 2015 [Page 1]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 3
2.1. Duplicate Address Detection (DAD) Process . . . . . . . . 4
3. Advantages of ra-privacy over CGA and DHCPv6 . . . . . . . . 5
4. Interface ID (IID) generation based on the MAC address . . . 5
5. Lifetime of an Interface ID (IID) . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 6
9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Rafiee, et al. Expires April 1, 2015 [Page 2]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
The purpose of this document is to address the privacy issues that
exist within the Privacy Extension specification and offer an
alternative privacy aware solution for a random number generator to
correct these shortcomings.
1. Introduction
Today, privacy is an important concern to everyone in their everyday
life. In Internet, Privacy is not bound to any particular layer in
the Open Systems Interconnection (OSI) model, but some layers do have
a greater impact on user?s privacy. This document tries to address
the deficiency that exists in the privacy extension specification
[RFC4941] as it relates to the network layer. In other words, how an
IP address can affect user's privacy. One of the solutions for IPv6
autoconfiguration (RFC 4682) is the use of the Privacy Extension
[RFC4941]. The Privacy Extension document explains two different
approaches that can be used for IID generation. In the first
approach, the use of stable storage enables a node to find which IIDs
are currently in use and which are in reserve. In the second
approach, where stable storage is not available, it suggests the use
of some randomizing approaches and also comments about other
available randomizing mechanisms such as Cryptographically Generated
Addresses (CGA) [RFC3972] or Dynamic Host Configuration Protocol
(DHCPv6). The Privacy Extension document also refers to the use of a
named approach as an approach to be used in a mechanism for
generating greater randomization. This document aims to introduce a
new alternative randomized algorithm to RFC 4941 that can be used in
any systems to generate IID not based on the hardware Identifier.
This document addresses the following problems:
- If the node is changing the physical link, it may keep the IID
already used on the link it is leaving, to form an IPv6 address on
the new link using SLAAC. Therefore, it negatively impacts user?s
privacy and enable tracking a node over the networks.
- This document also clarifies the use of other algorithm and compare
it with CGA and DHCPv6 when there is no stable storage available. So
that the node may be able to make use of a greatly randomized IID
because, according to section 3.2.2 of RFC 4941, there is nothing to
force the use of RFC 4086.
2. Algorithm Overview
This section explains how to make use of a new algorithm that will
provide for a higher randomization of the IID without the need for
any extra memory or stable storage. This algorithm can be used when
there is no stable storage available in the node or the node does not
want to store any value in memory. This approach is easy to implement
while at the same time provide a good randomization level.
Rafiee, et al. Expires April 1, 2015 [Page 3]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
1. Generate a 16 byte random number called modifier. To generate this
modifier, implementations should use a random seed to aid in the
randomization of this number.
2. Obtain the router prefix from the Router Advertisement message
3. Obtain the nodes' current time in microseconds and call it
timestamp. This field consists of a 64-bit, unsigned integer
containing the number of milliseconds since January 1, 1970, 00:00
UTC, by using a fixed point format. (Please refer to section 11 for
more detail)
4. Concatenate the modifier with the timestamp and the router prefix.
R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix)
Note: Implementations MIGHT skip step 3 and use this timestamp as a
seed to PRND function to generate modifier. So, R1 is as follow
R1=(modifier(16 bytes)|| router prefix)
5. Execute SHA2 (256) against the result from step 4.
digest=SHA256(R1)
The use of SHA2 (256) is recommended because the chances of finding a
collision are less than when using SHA1 and the generation time is
acceptable (in microseconds using a standard CPU). In the future, if
a faster and collision free algorithm becomes available, then
Implementations need to support it.
6. Take the x bits (leftmost bits or rightmost bits, does not matter
and either way is correct) from the resulting output of step 5 (SHA2
digest). x depends on the number of bits that is needed for an IID.
Bits u and g do not have any special meaning as in [ugbits].
Note: in case this algorithm is used for only the generation of
random number, the next steps should be skipped.
7. Concatenate the IID with the local subnet prefix in order to set
the local IP address. If the lifetime of the old local address has
not expired, then the node MIGHT skip this step. Otherwise it will
receive a new router prefix.
8. Concatenate the IID with the router subnet prefix (Global subnet
prefix), obtained from the RA message, and set it as a tentative
privacy IP address. This IP address will become permanent after
Duplicate Address Detection (DAD) processing.
2.1. Duplicate Address Detection (DAD) Process
Rafiee, et al. Expires April 1, 2015 [Page 4]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
After the DAD process has completed, if the node finds collisions in
the network, then the modifier will be incremented and the DAD
process will be repeated. If, after 3 tries, it receives the same
result, it will consider this an attack and will start using that IP
address.
3. Advantages of ra-privacy over CGA and DHCPv6
This algorithm has some advantages over the use of CGA and DHCPv6.
- CGA generates a highly randomized IID but CGA algorithm is compute
intensive. This is the primary reason that CGA algorithm has been
only implemented as an experiment but rarely enabled or used in
practice.
- DHCPv6 server might generates the IIDs sequentially and assign
these IIDs to the nodes. This sequential assignment is according to a
range of IP addresses and might allow an attacker to scan the nodes
in this network and harm their privacy. This is also true, if the
node releases an IP address and set new IP address. It is again from
the same range.
- An administrator needs to configure and maintain DHCPv6 server.
This is not needed if a node uses Neighbor Discovery Protocol (NDP).
4. Interface ID (IID) generation based on the MAC address
When a node uses the mechanism explained in this document to generate
an IID, it must not use any other IID generation approaches that are
based on MAC addresses (RFC 4862) for either temporary or non
temporary IID generation. The node might use the algorithm explained
in [RFC7217] for the generation of a public address that does not
make use of EUI-64 or the MAC address for public (global) addresses.
The choice of whether or not to list a node's address in the DNS,
undisguised, depends on many factors, including the set of
applications to be run on the host. Not listing a node's address in
the public DNS may afford the node greater privacy, but, at the same
time, it may also impair its ability to support certain applications.
5. Lifetime of an Interface ID (IID)
The node might make use of the same algorithm and the same lifetime
as is explained in RFC 4941, or the node might choose a lifetime
based on some other algorithms or policies [LifeTime]. If it uses the
lifetime explained in RFC 4941, then it should generate a new IID
whenever it is in different network, regardless of the option in the
Router Advertisement message to extend this lifetime. This is
because, based on Privacy Extension specification, the node does not
Rafiee, et al. Expires April 1, 2015 [Page 5]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
change its IID if the option in the router advertisement in new
network extend the lifetime of IID.
6. Security Considerations
As is explained in the Privacy Extension document. the same
approaches are used to maintain security, such as using Secure
Neighbor Discovery (SeND)(RFC 3971) or using a monitoring system
which would inform the administrator of the status of the network and
of any suspended activities in the network.
7. IANA Considerations
There is no IANA consideration
C++ source code for the comparison of ra-privacy and privacy
extension can be found in the following address
http://sourceforge.net/u/hrafiee/raprivacy/ci/master/tree/
8. Acknowledgements
The author would like to thank all those people who directly helped
in improving this draft especially Andrew Yourtchenko
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture," RFC 4291, February 2006.
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)," RFC 3972, March 2005.
[RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T.,
Perkins, C., Carney, M. , " Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
Rafiee, et al. Expires April 1, 2015 [Page 6]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC7217] Gont, F., " A Method for Generating Semantically
Opaque Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC7217, April 2014
9.2. Informative References
[ugbits] Carpenter B., "Significance of IPv6 Interface
Identifiers", RFC 7136, February 2014
[LifeTime] Rafiee, H., Meinel, C., Nordmark, E.,
"Interface ID lifetime Algorithms",
https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime,
2013
Rafiee, et al. Expires April 1, 2015 [Page 7]
INTERNET DRAFT RA-base Privacy Extension October 1, 2014
Authors' Addresses
Hosnieh Rafiee
HUAWEI TECHNOLOGIES Duesseldorf GmbH
Riesstrasse 25, 80992,
Munich, Germany
Phone: +49 (0)162 204 74 58
Email: hosnieh.rafiee@huawei.com
Christoph Meinel
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Email: meinel@hpi.uni-potsdam.de
Rafiee, et al. Expires April 1, 2015 [Page 8]
