Internet DRAFT - draft-rafiee-v6ops-iid-lifetime
draft-rafiee-v6ops-iid-lifetime
IPv6 Operations Working Group (v6ops) H. Rafiee
INTERNET-DRAFT C. Meinel
Intended status: Proposed Informational Hasso Plattner Institute
E. Nordmark
Arista Networks
Expires: April 21, 2014 October 21, 2013
Interface ID lifetime Algorithms
<draft-rafiee-v6ops-iid-lifetime-00.txt>
Abstract
This document introduces a framework, i.e., an application layer
based lifetime [applicationiid] to enable applications maintaining
their users' privacy as well as controlling the number of Interface
IDs (IIDs) per network adapter. It will also explain different
approaches that can be used for maintaining the lifetime of an IID.
We also compare this framework to the other available mechanisms.
This document also explains when to remove deprecated IP addresses
from the a network interface.
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: February 10, 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
Rafiee, et al. Expires April 21, 2014 [Page 1]
INTERNET DRAFT IID lifetime October 21, 2013
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
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Generation of an Interface ID . . . . . . . . . . . . . . . . 4
5. Lifetime Explained in RFC 4941 . . . . . . . . . . . . . . . 4
6. Connection Based Lifetime (layer-4) . . . . . . . . . . . . . 4
7. Application Layer based Lifetime for the Interface ID (IID) . 5
7.1. Configuring the Default values . . . . . . . . . . . . . 6
7.1.1. Deprecated Interface ID . . . . . . . . . . . . . . . 7
7.1.2. Configuring Default values . . . . . . . . . . . . . 7
7.2. Receiving more than one RA message . . . . . . . . . . . 7
7.3. Automate the process for setting the lifetime . . . . . . 7
8. Threat Analysis of Application Layer based lifetime . . . . . 8
8.1. Location based tracking . . . . . . . . . . . . . . . . . 8
8.2. Obtaining confidential data . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 9
12.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Rafiee, et al. Expires April 21, 2014 [Page 2]
INTERNET DRAFT IID lifetime October 21, 2013
1. Introduction
The primary use of Network Address Translation (NAT) (RFC 4787), in
IPv4, is to address IPv4 exhaustion address space. NAT made the
companies and places to use other approaches in order to collect more
information about their users for advertisement or other purposes.
Browsers' cookie is one example of these mechanisms. To address this
problem and protect user's privacy, some Internet browsers offer the
use of "incognito mode" or "private browsing". In this mode, the
browser does not store any cookies or it will remove all user's
information as soon as the user closes its browser.
Today, IPv6 large address space, reduces the need of using NAT. IPv6
also solves the problem of end-to-end communication. This is because
the IP addresses used by nodes are globally valid and can be used to
directly connect to other nodes via the Internet. This means that it
is easier for advertisement companies to distinguish their users only
by their unique IP addresses. This is also gives this ability to
attackers to obtain user's information by using simple approaches
such as creating a fake website and use it as trap to find the user's
IP addresses.
One possible solution might be the use of temporary Interface ID
(IID). It might be the future capability of the browsers, in
"incognito mode", not only to prevent storing user's information but
also generate a new IID for user's connection. However, this might be
a good solution to maintain user's privacy but it might be
problematic, especially, if many applications wants to generate their
IIDs themselves and start a connection. There will be no control over
the number of valid IIDs. To address this issue, we introduce a
framework, i.e., an application layer based privacy that can enable
the applications to request for IIDs without involving in detail of
IID generation (network layer). This document also introduces
different mechanisms that may be used in order to maintain the
lifetime of an Interface ID (IID) used in IPv6 networks. It then
explain the deficiencies exist in these mechanisms.
1.1. Problem Statement
Increase the difficulty of correlating a user's activities by using
different IIDs for different applications, without negatively
impacting the robustness of the applications. Since there is some
network overhead associated with each host having lots of IIDs at the
same time, the mechanism needs to limit the number of IIDs that are
in use at any given time.
2. Conventions used in this document
Rafiee, et al. Expires April 21, 2014 [Page 3]
INTERNET DRAFT IID lifetime October 21, 2013
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. Terminology
- application : An application is a process in a system, which
includes all other dependent processes. Usually when an application,
such as a Firefox browser, is opened in a system, there are many
other processes that are called into play by this application. The
meaning of application, as used in this document, is to consider the
application, itself, including all of its dependent processes.
4. Generation of an Interface ID
This document assumes that the node generates its temporary IID by
using any available algorithm as explained in [RFC4941],
[StableAddresses], [RFC3972], [ra-privacy], [ssas], etc.
5. Lifetime Explained in RFC 4941
There are some variables in play for maintaining the lifetime of an
IID. There should be no more than one valid IID per network
interface, at any one time. The preferred lifetime for this IID is
one day and the maximum lifetime is one week. One drawback to using
this lifetime IID is that the length of time the IIDs remain in use
after expiration of the lifetime ( deprecated IIDs) is left solely up
to the implementers. This means that it is possible for a node to cut
its connections to other nodes after the expiration of the maximum
lifetime for that IID. This act could possibly cause problems for any
applications that are still using that ID.
6. Connection Based Lifetime (layer-4)
One possible way of maintaining the lifetime of an IID is connection
based, i.e., as long as the connection is active, the node keeps this
IID. The drawback to using this approach is that this may prove
Rafiee, et al. Expires April 21, 2014 [Page 4]
INTERNET DRAFT IID lifetime October 21, 2013
problematic for ftp and other applications that use different layers
and open different connections.
7. Application Layer based Lifetime for the Interface ID (IID)
Another possible way of maintaining the lifetime of an IID is
application layer based. Figure 1 depicts the algorithm used to
determine the lifetime of an IID. The use of this algorithm minimizes
the chance of an attacker being able to obtain a user's private
information.
start
+
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 ++ |
+--------------------+
An IID is assigned to a group of applications and this IID is valid
for the length of time that its lifetime is valid. After that time
expires the state of this IID is changed to deprecated. This
deprecated IID can not be assigned to new applications, but it will
remain valid for as long as any application is using it. The lifetime
that the deprecated IID should have is explained in section 6.2.
- app_i is a new application that has been initiated 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
Rafiee, et al. Expires April 21, 2014 [Page 5]
INTERNET DRAFT IID lifetime October 21, 2013
- c_IID is the current number of IIDs
- IID_i is a specific IID
- t_app_i is the total number of applications allowed per specific
IID
- n_i is the current number of applications for a specific IID
- L_i is the current lifetime of a specific IID
When a node wants to start a new application, it first checks to see
whether or not it has also received a new router advertisement
message. In the case where a new router advertisement message is
received, the node sets the total lifetime for the current valid IID
to zero and resets the c_IID to zero. In this case, all of the
current IIDs associated with this node MUST have 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. (Please refer to section 7.1.1
for more detail)
If the node does not receive a new router advertisement message, then
it checks to see whether or not the current number of IIDs is less
than the maximum number of IIDs allowed. If the condition is met, the
node then checks to see 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 the 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 the max_IID,
and n_i is equal to t_app, then the node will be unable to generate a
new IID for the application nor will it be 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.
7.1. Configuring the Default values
If the implementation wants to implement this mechanism, they SHOULD
consider a mechanism to allow applications send their IID request to
Rafiee, et al. Expires April 21, 2014 [Page 6]
INTERNET DRAFT IID lifetime October 21, 2013
the framework.
7.1.1. Deprecated Interface ID
A Deprecated IID is an IID that is no longer valid but can still be
used by any current applications that are running. It is RECOMMENDED
to remove deprecated IIDs when the node's Operating System (OS)
reboots or when there is no application using it for 5 minutes (no
sockets). The maximum period of time that a deprecated IID can be
valid is one month. Implementers should consider a way of giving
users a means of setting a new default value.
7.1.2. Configuring Default values
- t_app =20
- L= 10 days
- max_IID = 10
- t_app_i = t_app at the start of the application layer lifetime IID
and SHOULD incremented this if the maximum number of IIDs is equal to
current number of IIDs, as explained in the algorithm.
7.2. Receiving more than one RA message
If a node receives an RA message it will assign an IID to the
application or to the group of applications as described above. If,
after a short period of time, another RA message is received, but
with a different prefix ,and if this router prefix is not in his list
of the routers in his cache, then the node SHOULD send a Router
Solicitation (RS) message. If it received more than one RA message
with different prefixes then it SHOULD assume that these routers are
in the same network. The maximum number of valid IIDs per router
prefix is calculated using the following formula:
Max IID per router prefix=max_IID/(number of routers). This mitigates
the problem of multicast groups in the network as the maximum number
of IIDs will never increase, regardless of number of routers in the
network.
7.3. 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
Rafiee, et al. Expires April 21, 2014 [Page 7]
INTERNET DRAFT IID lifetime October 21, 2013
lifetime for all the addresses that are generated using 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.
8. Threat Analysis of Application Layer based lifetime
8.1. Location based tracking
Similar to the mechanism explained in RFC 4941 and [Ra-privacy], the
attacker might not have enough time to track the node. This is
because the IID is valid for only a short period of time and will
change when a new RA message is received. Since the IIDs are valid
for a short period of time, storing them using trap websites also
will not help the attackers because it will be changed after a while.
8.2. Obtaining confidential data
If for any reason one of the applications in use on this node exposed
the users' real IP address to an attacker, the attacker might not be
able to obtain other confidential information related to other user
applications on this node. This is because this IID is only used for
certain purposes and for certain applications. This IID is also valid
for only a short period of time, and so, the attacker might not have
enough time to obtain confidential information about this node.%h2
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
Rafiee, et al. Expires April 21, 2014 [Page 8]
INTERNET DRAFT IID lifetime October 21, 2013
No IANA actions are needed for this document.
11. Conclusions
This document explained different mechanisms used for maintaining the
lifetime of an IID. It introduced an application layer based lifetime
as a solution for the lifetime used for temporary IIDs in order to
satisfy users needs and to not force them to cut their connections or
to not open a new connection with an application using a new IID that
could prove problematic for the application.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)", RFC 3972, March 2005.
12.2. Informative References
[ssas] Rafiee, H., Meinel, C., "A Simple Secure Addressing
Scheme for IPv6 AutoConfiguration", Work In Progress,
http://tools.ietf.org/html/draft-rafiee-6man-ssas, July, 2013
[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,
August 2013
[ra-privacy] Rafiee, H., Meinel, C., "Router
Advertisement based privacy extension in IPv6
autoconfiguration", Work In
Progress,http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy,
July, 2013
[applicationiid] Rafiee, H., Meinel, C., "Privacy
and Security in IPv6 Networks: Challenges and
Possible Solution". The 6th International Conference
on Security of Information and Networks, ACM,
November 2013
Rafiee, et al. Expires April 21, 2014 [Page 9]
INTERNET DRAFT IID lifetime October 21, 2013
Rafiee, et al. Expires April 21, 2014 [Page 10]
INTERNET DRAFT IID lifetime 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
Erik Nordmark
Arista Networks
Santa Clara, CA
USA
Email: nordmark@acm.org
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 11]
