One document matched: draft-rafiee-6man-ra-privacy-06.txt
Differences from draft-rafiee-6man-ra-privacy-05.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: February 12, 2014 August 12, 2013
Router Advertisement based privacy extension in IPv6 autoconfiguration
<draft-rafiee-6man-ra-privacy-06.txt>
Abstract
Privacy is an important issue that concerns many governments and
users and its importance becoming more evident every day. Nodes
change their IP addresses frequently in order to avoid being tracked
by attackers. The act of frequently changing IP addresses also helps
in preventing nodes from leaking information. In IPv6 networks there
is currently one solution for maintaining the privacy of nodes when
IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is used.
Unfortunately there are some problems associated with this solution
which entails the use of the Privacy Extension (RFC 4941). One of the
issues with this RFC concerns the wording that is used that allows
the implementation to make the choice as to what approach to use, and
in so doing, in some cases, the choice made is not the most prudent
or best approach, and this thus is not ideal and can lead to some
problems. Some of these problems are related to not generating a new
Interface ID (IID) after changing the router prefix. Another concern
is the fact that nodes may use an IID that was generated based on a
MAC address as a public address, and then use this in their response.
The act of cutting the current connections to other nodes, if the max
lifetime of the old IID has elapsed, is also not clearly explained
nor is whether or not the already used IID should be kept in stable
storage, There is also a concern about the need to have stable
storage available for the generation of a randomized IID. The
document also did not clearly explain how to use the same approach,
for the random value generation in all implementations, when there is
a lack of available stable storage. The purpose of this document is
to address these issues; to update the current RFC.
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.
Rafiee, et al. Expires February 12, 2014 [Page 1]
INTERNET DRAFT RA-base Privacy Extension August 12, 2013
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: February 12, 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
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 to 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 . . . . . . . . . . . . . . . . . . . . . 6
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7
11.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Rafiee, et al. Expires February 12, 2014 [Page 2]
INTERNET DRAFT RA-base Privacy Extension August 12, 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 for the
network layer. In other words, how an IP address can affect user
privacy. The current solution for IPv6 autoconfiguration (RFC 4682)
is 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 names 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 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 February 12, 2014 [Page 3]
INTERNET DRAFT RA-base Privacy Extension August 12, 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 as to the approach to
use for the randomization process, and, thus, may not be able to make
use of a highly 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 higher randomization of the IID without the need for
stable storage. 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.
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 and convert it to a timestamp. The
timestamp field consists of a 64-bit, unsigned integer field
containing a timestamp whose value is computed from the number of
seconds since January 1, 1970, 00:00 UTC, by using a fixed point
Rafiee, et al. Expires February 12, 2014 [Page 4]
INTERNET DRAFT RA-base Privacy Extension August 12, 2013
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) and set bits u and g (bits 7 and 8) to one and call
this the IID.
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 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 to 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 the need
for large stable storage. For the randomization approach, if the node
cannot pick the best algorithm from among the ones already explained
Rafiee, et al. Expires February 12, 2014 [Page 5]
INTERNET DRAFT RA-base Privacy Extension August 12, 2013
in RFC 4086, then it MUST also include a timestamp 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. The node SHOULD 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.
9. IANA Considerations
Rafiee, et al. Expires February 12, 2014 [Page 6]
INTERNET DRAFT RA-base Privacy Extension August 12, 2013
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,
2013
[privacyConsideration] Cooper, A., Gont, F.,
Thaler, D., "Privacy Considerations for IPv6
Rafiee, et al. Expires February 12, 2014 [Page 7]
INTERNET DRAFT RA-base Privacy Extension August 12, 2013
Address Generation Mechanisms",
http://tools.ietf.org/html/draft-cooper-6man-ipv6-address-generation-privacy,
2013
Rafiee, et al. Expires February 12, 2014 [Page 8]
INTERNET DRAFT RA-base Privacy Extension August 12, 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 February 12, 2014 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:33:04 |