One document matched: draft-rafiee-6man-ra-privacy-08.txt
Differences from draft-rafiee-6man-ra-privacy-07.txt
IPv6 maintenance Working Group (6man) H. Rafiee
INTERNET-DRAFT C. Meinel
Updates RFC 4941 (if approved) Hasso Plattner Institute
Intended status: Proposed Standard
Expires: April 21, 2014 October 21, 2013
Router Advertisement based privacy extension in IPv6 autoconfiguration
<draft-rafiee-6man-ra-privacy-08.txt>
Abstract
The purpose of this document is to address the privacy issues that
exist within the Privacy Extension (RFC 44941) document so that the
Privacy Extension document can then be updated to correct these
shortcomings. These issues include the generation of public addresses
based on EUI-64, not choosing a good randomized function, not
changing the Interface ID (IID) when receiving a new router
advertisement, and some wording issues that might be ambiguous in
their interpretation.
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: April 21, 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
Rafiee, et al. Expires April 21, 2014 [Page 1]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 4
3.1. Duplicate Address Detection (DAD) Process . . . . . . . . 5
4. Advantages of ra-privacy over CGA and DHCPv6 . . . . . . . . 6
5. Modification for the use of stable storage . . . . . . . . . 6
6. Interface ID (IID) generation based on the MAC address . . . 6
7. Lifetime of Interface ID (IID) . . . . . . . . . . . . . . . 7
8. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Appendex . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 8
13.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Rafiee, et al. Expires April 21, 2014 [Page 2]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
1. Introduction
Today, privacy is an important concern to everyone in their everyday
life. 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 privacy. This document tries to address the
deficiency that exists in the current privacy solution as it relates
to the network layer. In other words, how an IP address can affect
user privacy. The current solution 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
addresses the following problems:
- RFC 4941 specifies the use of EUI-64 to generate the public address
of node
- 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.
- This document is also plan to clarify the interpretation of some
words used in RFC 4941. One example is a node might nterpret a need
for the use of a large, stable storage area in which to store each
newly generated IID. This needs to be done to prevent the generation
of another currently "in use" value.
- 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.
The Updates pertain to the following sections and concepts in RFC
4941:
- Section 3.2.3: in order to explain the use of a new randomization
algorithm when stable storage is not available, and when implementers
are not willing to use RFC 4086. This algorithm can provide the same
randomization as does CGA by eliminating the complexity of CGA
algorithm. DHCPv6 server might be configured to assign a sequential
Rafiee, et al. Expires April 21, 2014 [Page 3]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
IID to the nodes. This is why, there might be no randomization at all
and the node's IID is easily detectable.
- An additional update to this RFC will explain how to maintain the
lifetime of the IP address when the router prefix changes or the
lifetime of the IID, in general, changes. This is needed because, in
this RFC, the lifetime of the IID plays a key role. This means that
the node might not change its IID when it moves to another network
unless the node is rebooted. This can afford an attacker the ability
to track this node, and in doing so, to obtain enough confidential
information about this node to assist in further attacks.
- Step 4, Section 3.2.1: update to clarify which IIDs should be kept
in stable storage.
If there is no stable storage available, and if none of the methods
explained in RFC 4086 [RFC4086] for randomization are used, then it
is possible for the node to make a bad choice of what approach to use
for the randomization process, and, thus, may not be able to make use
of a good randomized IID.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC 2119 significance.
In this document the use of || indicates the concatenation of the
values on either side of the sign.
3. 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
stable storage. The use of this algorithm is RECOMMENDED 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 preferable over the
first approach where stable storage is needed, because this approach
is easier to use than the stable storage approach. In the case where
the node wants to use stable storage, this algorithm can be used for
the first time generation of the IID which can then be used to
populate the history value.
1. Generate a 16 byte random number called modifier. To generate this
modifier, implementations SHOULD use a random seed to aid in the
Rafiee, et al. Expires April 21, 2014 [Page 4]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
randomization of this number.
2. Obtain the router prefix from the Router Advertisement message
3. Obtain the nodes' current time in nanoseconds and call it
timestamp. This field consists of a 64-bit, unsigned integer
containing a the number of 100 nano seconds 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 it
SHOULD be used. It is RECOMMENDED that the implementation be able to
support any new algorithms.
6. Take the 64 leftmost bits from the resulting output of step 5
(SHA2 digest). Bits u and g do not have any special meaning as in
[ugbits].
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. This constitutes
another update to RFC 4941. The status of the IP addresses defined in
RFC 4941 are temporary, while they SHOULD be permanent with a
lifetime as explained in section 4.
3.1. Duplicate Address Detection (DAD) Process
After the DAD process has completed, if the node finds collisions in
the network, then the modifier will be incremented and the DAD
Rafiee, et al. Expires April 21, 2014 [Page 5]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
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.
4. 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 release 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).
5. Modification for the use of stable storage
The stable storage (section 3.2.1 RFC 4941) MUST only contain the
last value generated by the node. The node MUST not keep older,
already used, IIDs. This modification is made to eliminate poor
interpretations of wording used in the document.
6. Interface ID (IID) generation based on the MAC address
Step 3 in Section 3.3 of RFC 4941 MUST be ignored. 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
[StableAddresses] 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.
Rafiee, et al. Expires April 21, 2014 [Page 6]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
7. Lifetime of 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. 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.
8. Threat Analysis
By updating RFC 4941, a node will be able to prevent many attacks on
users' privacy. A list of these attacks are explained in
[privacyConsideration].
9. 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.
10. IANA Considerations
This document is updating RFC 4941 in order to prevent nodes from
using addresses that were generated based on a MAC address and also
some of the other deficiencies that exist in RFC 4941
11. Appendex
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/
12. Acknowledgements
The author would like to thank all those people who directly helped
in improving this draft especially Andrew Yourtchenko
Rafiee, et al. Expires April 21, 2014 [Page 7]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
13. References
13.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,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
13.2. Informative References
[StableAddresses] Gont, F., "A method for
Generating Stable Privacy-Enhanced Addresses with
IPv6 Stateless Address Autoconfiguration (SLAAC)",
Work In Progress,
http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses,
2013
[privacyConsideration] Cooper, A., Gont, F.,
Thaler, D., "Privacy Considerations for IPv6
Address Generation Mechanisms",
http://tools.ietf.org/html/draft-cooper-6man-ipv6-address-generation-privacy,
2013
[ugbits] Carpenter B., "Significance of IPv6 Interface
Identifiers", http://tools.ietf.org/html/draft-ietf-6man-ug,
2013
Rafiee, et al. Expires April 21, 2014 [Page 8]
INTERNET DRAFT RA-base Privacy Extension October 21, 2013
Authors' Addresses
Hosnieh Rafiee
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Phone: +49 (0)331-5509-546
Email: ietf@rozanak.com
Dr. Christoph Meinel
(Professor)
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Email: meinel@hpi.uni-potsdam.de
Rafiee, et al. Expires April 21, 2014 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:33:21 |