One document matched: draft-rafiee-6man-ra-privacy-07.txt
Differences from draft-rafiee-6man-ra-privacy-06.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: March 9, 2014 September 9, 2013
Router Advertisement based privacy extension in IPv6 autoconfiguration
<draft-rafiee-6man-ra-privacy-07.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: March 9, 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 March 9, 2014 [Page 1]
INTERNET DRAFT RA-base Privacy Extension September 9, 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. Modification for the use of stable storage . . . . . . . . . 5
5. Interface ID (IID) generation based on the MAC address . . . 6
6. Lifetime of Interface ID (IID) . . . . . . . . . . . . . . . 6
7. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7
11.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Rafiee, et al. Expires March 9, 2014 [Page 2]
INTERNET DRAFT RA-base Privacy Extension September 9, 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 promotes the use of IIDs generated by a MAC address as a
public address for the node
- The node might not generate a new IID when it receives a new Router
Advertisement (RA) message if the option in the router advertisement
message tells the node to extend the lifetime of its address. If the
maximum lifetime of that address has not been reached, then the node
will keep its current IID without generating a new one.
- A node may determine 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.
When there is no stable storage available, the node may not 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.
- 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
Rafiee, et al. Expires March 9, 2014 [Page 3]
INTERNET DRAFT RA-base Privacy Extension September 9, 2013
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. This is due to the fact that, in section
3.2.2 of RFC 4941, the word "might" is used in explaining the proper
randomization approach to be used. The approach should be specified.
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. This section is to address the other randomization
approach by using DHCPv6 or CGA. Instead one can use this algorithm.
This approach is RECOMMENDED, and 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 iIID 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
randomization of this number.
2. Obtain the router prefix from the Router Advertisement message
Rafiee, et al. Expires March 9, 2014 [Page 4]
INTERNET DRAFT RA-base Privacy Extension September 9, 2013
3. Obtain the nodes' current time and convert it to a 100 nanoseconds
(10^-7 seconds) 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.
4. Concatenate the modifier with the timestamp and the router prefix.
R1=(modifier(16 bytes)||timestamp(8 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
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. 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,
Rafiee, et al. Expires March 9, 2014 [Page 5]
INTERNET DRAFT RA-base Privacy Extension September 9, 2013
already used, IIDs. This modification is made to eliminate the need
for large stable storage. For the randomization approach, if the node
cannot pick the best algorithm from among the ones already explained
in RFC 4086, then it MUST also include a timestamp (the same meaning
as used in this document) in order to preclude the generation of an
already used IID.
5. 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. It is RECOMMENDED that the node 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.
6. 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
receives a new router prefix, regardless of the option in the Router
Advertisement message to extend this lifetime.
7. 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].
8. 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.
Rafiee, et al. Expires March 9, 2014 [Page 6]
INTERNET DRAFT RA-base Privacy Extension September 9, 2013
9. 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
10. Conclusions
Privacy has become a very important issue in recent years. There is
one solution to privacy issues, but the current solution is deficient
in some respects. The purpose of this current document is to address
and solve the problem which exists with the Privacy Extension
document [RFC4941].
11. References
11.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.
11.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,
Rafiee, et al. Expires March 9, 2014 [Page 7]
INTERNET DRAFT RA-base Privacy Extension September 9, 2013
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 March 9, 2014 [Page 8]
INTERNET DRAFT RA-base Privacy Extension September 9, 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 March 9, 2014 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:33:21 |