One document matched: draft-rafiee-6man-ra-privacy-04.txt
Differences from draft-rafiee-6man-ra-privacy-03.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: December 18, 2013 June 18, 2013
Router Advertisement based privacy extension in IPv6 autoconfiguration
<draft-rafiee-6man-ra-privacy-04.txt>
Abstract
Privacy is an important issue which concerns many governments and
users, with 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
to prevent the leakage of information by nodes. 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
which 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 is not ideal and can
cause some problems. Some of these problems are concerned with not
generating a new Interface ID (IID) after changing the router prefix.
Another concern would be 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 RFC gives no explanation as to how to make use of
CGA in its randomizing solution when stable storage is not available
or how to use the same approach for random value generation in all
implementations where there is a lack of stable storage. The purpose
of this document is to address these issues, to update the current
RFC and to introduce a new algorithm for the lifetime of IID.
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
Rafiee, et al. Expires December 18, 2013 [Page 1]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
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: December 18, 2013.
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 . . . . . . . . . . 6
5. Interface ID (IID) generation based on the MAC address . . . 6
6. Application Layer based Lifetime for the Interface ID (IID) . 6
6.1. Automate the process for setting the lifetime . . . . . . 8
7. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Location based tracking . . . . . . . . . . . . . . . . . 9
7.2. Obtaining confidential data . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Rafiee, et al. Expires December 18, 2013 [Page 2]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
1. Introduction
Privacy and security have a close relationship. Privacy, simply
stated, is the act of allowing a user to choose which data he wants
to make available to others or which data he wants to keep from
prying eyes. Security, on the other hand, is the ability to protect
data or to keep it confidential. There are times, however, where one
will have to be sacrificed for the sake of the other. The gathering
of location information, for security reasons, might prove
detrimental to privacy. But in many cases, when cryptography or other
approaches are used to protect the content of the data, it is not
only being secured but is also being provided privacy.
This document defines the meaning of privacy as it relates to methods
for maintaining data confidentiality so that it does not become
available to or exposed to unscrupulous people who would use it to
the detriment of the user or would use it for their ill gotten gains.
There is currently only one solution available in IPv6
autoconfiguration (RFC 4682):, Privacy Extension [RFC4941]. The
Privacy Extension document explains two different approaches for use
in 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 approaches as a mechanism for 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 cuts his connections with other nodes if the lifetime of
the temporary IIDs is expired.
- The node might not generate a new IID when it receives a new RA
message if the option in the router advertisement tells the node to
extend the lifetime of its address, and 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 RFC
4086.
Rafiee, et al. Expires December 18, 2013 [Page 3]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
The Updates pertain to the following sections and concepts in RFC
4941:
- Section 3.2.3 in order to explain the use of CGA when security is
not the issue.
- 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 key role is the lifetime of the IID. 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.
- There should be an update made to step 4, Section 3.2.1, clarifying
which IIDs should be kept in stable storage.
- If there is no stable storage available, and if the timestamp is
not used as a method for randomization, then the node may not choose
a good approach 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 use the modified version of the CGA
algorithm for higher randomization of the IID without a need for
stable storage. This approach is RECOMMENDED and preferable over the
first approach, where stable storage is needed.
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 December 18, 2013 [Page 4]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
randomization of this number.
2. Obtain the router prefix from the Router Advertisement
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
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 time for the
generation 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 times, it receives the same
result, it will consider this an attack and will start using that IP
address.
Rafiee, et al. Expires December 18, 2013 [Page 5]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
4. Modification to the use of stable storage
The stable storage (section 3.2.1 RFC 4941) MUST only contain the
last generated value of 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
in RFC 4088, 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 of Section 3.3 of RFC 4941 MUST be ignored. When a node uses
the mechanism explained in this document for IID generation, it MUST
not use any other IID generation approaches that are based on MAC
addresses ( RFC 4862). For nodes where privacy is an important issue
the use of public addresses is not RECOMMENDED unless security
approaches are employed in the higher layers such as using SSL, TLS,
etc where all data is encrypted. In cases where a public address must
be used,then the method for generating the public address SHOULD use
the approach explained in this document, or any other document, where
the MAC address is not used as a part of the public address.. Public
addresses are permanent addresses and MIGHT not expire. These
addresses are added to DNS records and are RECOMMENDED for use by
nodes that are servers or routers. For debugging and troubleshooting
purposes, the implementation MUST provide a way of partially
disabling the mechanism as explained in this document. Allowing for
manually setting and unsettling a flag, which would indicate the
debugging mode, is one way to accomplish this. This means that when
this flag is set, the node SHOULD not generate new IIDs and SHOULD
change the IID's lifetime to a large number. As soon as the trouble
shooting process ends, and the flag is set back to zero, then the
node MUST generate a new IID and start using it. The lifetime of the
old IID must also be set to an appropriate value at this time.
6. Application Layer based Lifetime for the Interface ID (IID)
Figure 1 depicts the algorithm used to determine the lifetime of an
IID. The use of this algorithm minimizes the chance of an attacker
obtaining a user's private information. It is RECOMMENDED that the
node uses encryption mechanisms if the IID is in use for more than a
week. This is because attackers might be able to watch this node and
thereby obtain a user's private information. This might negatively
impact a user's privacy.
start
Rafiee, et al. Expires December 18, 2013 [Page 6]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
+
v
+-------------------+ +--------+
|new Router prefix |Yes |c_IID=0 |+------------+
| received? +--->|L_i=0 | |
+---------+---------+ +--------+ |
|No |
v +--------------------+ |
+---------------+ | Find_largest(L_i) | |
|max_IID > c_IID+-->| t_app_i ++ | |
+-------+-------+ No| Assign(IID_i,app_i)| |
| Yes +--------------------+ |
+-------v----------+------------+ |
| n_i < t_app_i + No | |
+-------+----------+ +---------v----------+ |
Yes | | Generate_New(IID) | |
+-----------v--------+ | c_IID ++ <--+
| Find_largest(L_i) | | Assign(IID_i,app_i)|
| Assign(IID_i,app_i)| +--------------------+
| n_i ++ |
+--------------------+
One possible way of maintaining the lifetime of an IID is connection
based, although this way may prove problematic for ftp and other
applications. Another possible way of maintaining the lifetime of an
IID is application layer based. The application will open a
connection using an IID and this connection will remain active for as
long as the application uses it.
- app_i is new application started by the node
- t_app is the maximum number of applications per IID
- L is the maximum lifetime of an IID
- max_IID is the maximum number of valid IIDs
- c_IID is the current number of IIDs
- IID_i is a specific IID
- t_app_i is the total number of applications per specific IID
- n_i is the current number of applications for specific IID
- L_i is the current lifetime of a specific IID
When a node wants to use a new application, it first checks to see
whether or not it has also received a new router advertisement. In
the case where a new router advertisement is received, the node sets
the total lifetime of the current valid IID to zero and resets the
c_IID to zero. In this case all of the current IIDs associated with
Rafiee, et al. Expires December 18, 2013 [Page 7]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
this node MUST be expired and the node MUST generate, and use,new
IIDs for any upcoming applications. But the node can still use an
expired IID as long as the current applications using them are
active.
If the node does not receive a new router advertisement, then it
checks whether or not the current number of IIDs is less than the
maximum number of IIDs. If the condition is met, the node then checks
whether or not there are any IIDs where the current number of
applications, n_i , is less than the total number of applications,
t_app_i. If the condition is met the node SHOULD sort these IIDs
based on their current lifetime, L_i, in descending order, and then
assign app_i to the IID with higher L_i. The current number of
applications, n_i, for this specific IID is then incremented. If n_i
is equal to t_app_i, then the node generates a new IID and assigns
this application to this new IID.
In cases where the current number of IIDs is equal to max_IID, and
n_i is equal to t_app, the node is unable to generate a new IID for
the application nor is it able to assign a current IID to the
application. In this case the node SHOULD find the IID with the
longest lifetime and then increase the total number of applications,
t_app_i, that can be assigned to it. The node then assigns this IID
to the new application. The advantage to using this algorithm, with
regard to the IID lifetime, is that it allows for the control of the
number of valid IIDs, while at the same time allowing users to keep
their current application layer connections. This results in user
satisfaction.
6.1. Automate the process for setting the lifetime
The implementations MIGHT consider an option where, when RA messages
are being processed , the RA message can be used to update the
lifetime for all addresses generated by the use of this approach.
This will eliminate the need for the manual step, used during
installation, to set the default value for the lifetime (based on
network policy) for any future IIDs generated using this approach.
The format for this lifetime value will be the same as that explained
in section 5.3.1 RFC 3971. The "type" SHOULD be set to the next
sequential number available in the SeND options, i.e., 15. When use
is made of the lifetime option, this field SHOULD be added to the
ICMPv6 option for RA messages.
7. Threat Analysis
Privacy consists of personal data that contains any information
relating to an individual, whether it relates to his or her private,
professional or public life. It can be anything from a name, a photo,
an email address, bank details, his posts on social networking
Rafiee, et al. Expires December 18, 2013 [Page 8]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
websites, his medical information, or his computer's IP address. Any
unauthorized efforts to obtain this information are considered an
attack against a user's privacy. The following sections will explain
how the mechanism detailed in this document can protect a user's
privacy.
7.1. Location based tracking
As the node MUST only keep its IID for a short period of time, and
MUST also change it when the prefix changes, it is not very easy for
an attacker to track this node based on its IP address. This is also
the case when the node changes the IID within the same network. The
reason for this is because it is very difficult for the attacker to
realize that this node is the same node, only with a newly generated
IID. This is especially true when there is an unlimited number of
nodes on the same network.
7.2. Obtaining confidential data
When a node changes its IID frequently, within the network and among
networks, the attacker probably won't have enough time to obtain the
user's confidential data. It will also be difficult for the attacker
to correlate the information that he does obtain to a specific user's
IP address. This means that it will be difficult for the attacker to
obtain more information about this user based on any correlation of
data. An example would be when an attacker obtains a confidential
document from a user, but he is unsure about the location of this
user. If the attacker had the location the user, he would be able to
obtain much more information about this user. With this new
information he would then be able to start attacks against him. But
changing the IID prevents the attacker from finding the location of
this user and thus prevents further attacks.
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 December 18, 2013 [Page 9]
INTERNET DRAFT RA-base Privacy Extension June 18, 2013
-
10. Conclusions
Privacy has become a very important issue in recent years. There is
one solution to the privacy issues, but the current solution has some
deficiencies. The purpose of the 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.
Rafiee, et al. Expires December 18, 2013 [Page 10]
INTERNET DRAFT RA-base Privacy Extension June 18, 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 December 18, 2013 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:33:05 |