A Simple Secure Address Generation Scheme for IPv6 AutoConfiguration (SSAS)
draft-rafiee-6man-ssas-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hosnieh Rafiee , Christoph Meinel | ||
| Last updated | 2013-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rafiee-6man-ssas-06
IPv6 maintenance Working Group (6man) H. Rafiee
INTERNET-DRAFT C. Meinel
Updates RFC 3971 Hasso Plattner Institute
(if approved)
Intended status: Proposed Standard
Expires: April 21, 2014 October 21, 2013
A Simple Secure Address Generation Scheme for IPv6 AutoConfiguration
(SSAS)
<draft-rafiee-6man-ssas-06.txt>
Abstract
The purpose of this document is to address the current problem
inherent with using of Cryptographically Generated Addresses (CGA)
[RFC3972] and introduces a new algorithm that can eliminate the cost
of CGA algorithm. This algorithm also responds to the security issues
(IP spoofing) exists in Privacy Extension [RFC4941] document by
integrating privacy with the security.
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 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 SSAS for Autoconfiguration 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 . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SSAS Applications . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Preventing Attacks . . . . . . . . . . . . . . . . . 5
3.1.1.1. Replay attack . . . . . . . . . . . . . . . . . . 5
3.1.1.2. IP spoofing . . . . . . . . . . . . . . . . . . . 5
3.1.1.3. Denial of Service (DoS) attacks . . . . . . . . . 6
3.1.1.4. Spoofed Redirect Message . . . . . . . . . . . . 6
3.1.2. Nodes with limited resources . . . . . . . . . . . . 6
3.1.3. Other Applications . . . . . . . . . . . . . . . . . 7
4. Algorithms Overview . . . . . . . . . . . . . . . . . . . . . 7
4.1. SSAS Algorithm . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Interface ID (IID) Generation . . . . . . . . . . . . 7
4.1.2. Signature Generation . . . . . . . . . . . . . . . . 8
4.1.3. Generation of NDP Messages . . . . . . . . . . . . . 9
4.1.3.1. SSAS signature data field . . . . . . . . . . . . 9
4.1.4. SSAS verification process . . . . . . . . . . . . . . 11
4.2. Resource Public key Infrastructure (RPKI) . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Rafiee, et al. Expires April 21, 2014 [Page 2]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
1. Introduction
IPv6 addresses consist of two parts; the subnet prefix, which is the
64 leftmost bits of the IPv6 address, and the Interface ID (IID),
which is the 64 rightmost bits of the IPv6 address. The IEEE
Standards Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered
a standard for the generation of IPv6 Interface IDs (IID) called the
Extended Unique Identifier (EUI-64). EUI-64s are generated by the
concatenation of an Organizationally Unique Identifier (OUI),
assigned by the IEEE Registration Authority (IEEE RA), with the
Extension Identifier assigned by the hardware manufacturer. If the
OUI is 24 bits and the extension identifier is also 24 bits (this
constitutes the MAC address), then to form the 64-bit EUI address,
the OUI portion of the MAC address is inserted into the leftmost 24
bits of the EUI-64 8 byte field and the Extension Identifier is
inserted into the rightmost 24 bits of the EUI-64 8 byte field. A
value of 0xFFFE is then inserted between these two 24-bit items. IEEE
has chosen 0xFFFE as a reserved value which can only appear in an
EUI-64 which is generated from an EUI-48 MAC address. If OUI is 36
bits, then OUI is concatinated with the Extension Identifier in order
to generate EUI-64. For example, if a manufacturer's OUI-36
hexadecimal value is 00-5A-D1-02-3, and the manufacture hexadecimal
value, for the Extension Identifier for a given component is
4-42-61-71, then the EUI-64 value generated from these two numbers
will be 00-5A-D1-02-34-42-61-71. Bit 7 (u bit) in the OUI portion of
the address is used to indicate either global or local uniqueness.
Globally unique addresses assigned by the IEEE set this bit to zero,
by default,indicating global uniqueness.The bit is set to 1 for
locally created addresses, such as those used for virtual interfaces
or a MAC address manually configured by an administrator.
There are currently some mechanisms used to generate a randomized IID
that do not make use of a MAC address; CGA [RFC3972], Privacy
Extension (generation of temporary addresses) [RFC4941], etc. In this
document we discuss the problem inherent with using the current
mechanisms and then we explain our solution to the problem, which is
to randomize the IID observing privacy, while, at the same time,
providing security to Neighbor Discovery Protocol (NDP) messages of
nodes in the IP layer. DHCPv6 [RFC3315] can also benefit from this
approach for the generation of a random IID or for authentication
purposes.
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
Rafiee, et al. Expires April 21, 2014 [Page 3]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
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. Problem Statement
The drawback to using IIDs that do not change over time is one of
privacy. The node will generate the same IID whenever it joins a new
network thus making it easy for an attacker to track that node when
it moves to different networks.
The main problem with the privacy extension mechanism, when using the
first approach as explained in section 3.2.1 RFC-4941 [RFC4941],
i.e., using stable storage, is the lack of a provision for the use of
a security mechanism and also the need to generate public addresses
based on MAC addresses. The Privacy Extension RFC partially prevents
attacks related to privacy issues, but it cannot prevent attacks
related to security issues. For example, it cannot prevent IP
spoofing attacks and it cannot provide proof of IP address ownership
for a node. If one wants to use a secure method, with the privacy
extension, then one needs to use CGA. The problem with using CGA is
in the computational overhead necessary to compute it when higher sec
values are used and the time that is needed to perform the
verification process. This time is based on the reverse of the steps
required for the CGA regeneration during the verification process
along with the additional time needed for signature verification.
The first problem with CGA is the apparent lack of a defense against
Denial of Service (DoS) types of attack that are performed against
verifier nodes. In the CGA RFC there is no explanation as to how to
prevent these types of attacks. This means that an attacker can
overwhelm the verifier node with false CGA values thus rendering it
unable to process further messages.This document also proposes a
solution to this type of attack. The other problem with CGA sec value
higher than 0 is unnecessary making busy the CPU and other resources
in a node for unlimited period of time. It is because there is no
guarantee that the 16 by sec value equal to zero condition will ever
be met. For CGA sec value 0, the attacker needs to do 2^59 brute
force attacks. So the use of the CGA algorithm, which is compute
intensive, is thus not ideal for use with nodes having limited
resources or with nodes wanting to change their IID frequently for
the purpose of protecting their privacy.
In order to overcome the problem with using the other mechanisms, the
time needed for IP address generation and verification needs to be
reduced and avoid unnecessary usage of CPU while at the same not
scarifying user's security. We propose the use of the SSAS algorithm,
along with the SSAS signature, to provide a node with the protection
it needs to protect it against IP spoofing and other spoofing types
Rafiee, et al. Expires April 21, 2014 [Page 4]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
of attack in the IP layer. Our experimental results [2] show that
SSAS is more secure and faster than CGA when using a sec value of 0
(Brute force attacks against 64 bits (when using first SSAS
algorithm) while in CGA this value is 59 bits) and much faster than
CGA when using a sec value of 1. Also the attacker has a few seconds
to attack 64 bits in SSAS. This is because of the neighboring nodes
keeps the public key of this node in their cache after first
successful verification. The security of SSAS, when using second
algorithm, is about the same as the security of the whole public key
even the first time use of this algorithm while in CGA it depends on
the sec value. It is not also ideal to use CGA with sec value higher
than 1 when using the current hardware resources. This is because it
will take hours to years to generate an IP address (see [2]).
3.1. SSAS Applications
3.1.1. Preventing Attacks
The following sections detail some types of attack that SSAS along
with SSAS signature can prevent. It provides the node with the
protection against the same attacks as does the CGA including RSA
signature option of SeND. A complete list of attacks can be find in
[RFC3756]
3.1.1.1. Replay attack
In this type of attack, an attacker will sniff the Neighbor Discovery
Protocol enabled network (NDP) messages to find, and then copy, a
legitimate signature and public key to his own NDP message which he
will then send to the original sender. But with the use of the SSAS
algorithm (Including the timestamp in the signature) and using RPKI,
this can be prevented. The use of a timestamp works because the
timestamp will be valid for only a short period of time. (this
accounts for clock skews.)
3.1.1.2. IP spoofing
This is a well-known type of attack in NDP. This type of attack is
used against the Duplicate Address Detection process. In this attack,
when a node joins the network and generates a new IP address, the
node sends a Neighbor Solicitation (NS) message to check for address
collisions in the network. The attacker, in this scenario, spoofs the
IP address and responds back to the node with a Neighbor
Advertisement (NA) message claiming ownership of this IP address.
While the SSAS algorithm does allow this node to verify other nodes
Rafiee, et al. Expires April 21, 2014 [Page 5]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
in the network, an attacker will not have the private key associated
with this node which is needed for SSAS signature generation, so the
verification process will fail.
3.1.1.3. Denial of Service (DoS) attacks
An attacker might send many NDP messages, using invalid signatures,
to a victim?s node which then forces the node to busy itself with the
verification process. To mitigate this attack, a node SHOULD set a
limit on the number of messages (x) that should be verified within a
certain period of time. Implementations MUST provide a conservative
default and SHOULD provide a means for detecting when this limit is
reached.
3.1.1.4. Spoofed Redirect Message
Redirect messages, imitating the end host needing redirection, can be
sent from any router on the same broadcast segment. The attacker uses
the link-local address of the current first-hop router in order to
send a Redirect message to a legitimate node. Since that node
identifies the message as coming from its first hop router, by use of
the link-local address, it accepts the Redirect. The Redirect will
remain in effect as long as the attacker responds to the Neighbor
Unreachability Detection probes sent to the link-layer address. To
preclude this from occurring, the address ownership of the first-hop
router should be verified. The use of the SSAS verification process
along with RPKI will prevent such an attack.
3.1.2. Nodes with limited resources
SSAS can be used in nodes where limited computational resources are
available. It can provide protection to these nodes against the types
of attack stated above. Sensor networks are a prime example of nodes
with limited resources (such as battery, CPU, and etc); see RFC-4919
[RFC4919] for use in IPv6 networks. Because currently, as explained
in section 4. RFC-6775, the generation of the IID is based on EUI-64
which makes these nodes vulnerable to privacy and security attacks.
One of these types of attack can occur during the Duplicate Address
Detection (DAD) process.
Another example for the use of SSAS would be in mobile networks
during the generation of IP addresses, as explained in section 4.4
RFC-6275 [RFC6275]. The current problem with the addressing mechanism
in a mobile node is that no privacy is observed when a node moves to
another network while usually keeping its Home Address. If there were
a fast and secure mechanism available, then it would be possible to
set this Home Address and change it and re-register it to the Home
Rafiee, et al. Expires April 21, 2014 [Page 6]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
network. Another possible use for SSAS in mobile nodes could be as a
security mechanism during the configuration of Care of Address (CoA);
see section 3. RFC-5213 [RFC5213]. In that RFC, home proxy plays the
role of a home agent for mobile nodes and mobile nodes set their CoA
by the use of either stateful or stateless autoconfiguration.
Currently they MUST use IPsec in order to secure this process.
Section 4 of that RFC discusses the possibility of using another
algorithm in order to secure mobile nodes.
3.1.3. Other Applications
With the wide usage of IP addresses in different types of devices and
by the use of autoconfiguration mechanisms to configure these IP
addresses, the need for the use of a security algorithm is increased.
One type of application would for use in vehicular networks or car by
car networks. There is currently some work in progress that makes use
of Neighbor Discovery. SSAS could also be a solution for enabling
fast protection against ND attacks.
4. Algorithms Overview
As explained earlier, one of the problems with using the current IID
generation approach is the compute intensive processing that is
needed for the IID algorithm generation. Another concern is for the
lack of security. Since we assume that a node will need to generate
and keep its address for a short period of time, we have tried to
keep the IID generation process to a minimum. We have also tried to
remain within the confines of NDP protocol. Here we offer two
algorithms. The first algorithm is used where the purpose is a faster
algorithm with the security higher than CGA sec value 0. The second
algorithm addresses the problem with the security level and tries to
use the security of the whole public key during the first time
verification.
4.1. SSAS Algorithm
4.1.1. Interface ID (IID) Generation
To generate the IID a node will need to execute the following steps.
1. Generate key pairs (public/private keys) using ECC (RFC 6090) or
other available algorithms. ECC is the default algorithm, but any
algorithm capable of generating a small key size in a short amount of
time is viable. It is best to have the key pairs generated, on the
fly, during the start-up phase of the algorithm generation. These
Rafiee, et al. Expires April 21, 2014 [Page 7]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
keys SHOULD be valid for only a certain period of time which depends
on network policy. When the time expires for the use of these key
pairs, the node will generate new key pairs. It then uses this new
value for the generation of the IP address and signature. Comparing
the use of ECC to that of RSA shows that an ECC with a 192 bit key is
equivalent to a RSA with a 7680 bit key (according to US National
Security Agency) In this case the packet size would be decreased by a
factor 11 times smaller than that when using RSA.
2. Divide the public key array of bytes into two half byte arrays
(see figure 1). Obtain the first 4 bytes from the first half byte
array and call it the partial IID1. Obtain the first 4 bytes of the
second half byte array and call this the partial IID2. (Dividing
public key is only for having randomization)
3. Concatenate partial IID1 with partial IID2 and call this the IID.
Set bits u and g to one.
4. Concatenate the IID with the local subnet prefix to set the local
IP address
5. Concatenate the IID with the router subnet prefix (Global subnet
prefix), obtained from the Router Advertisement (RA) message, and set
it as a tentative public IP address. This IP address will become
permanent after Duplicate Address Detection (DAD) processing. (for
more information about DAD refer to section 4.1.3. )
Note: In this document bits u and g does not have any particular
meaning and is used as a part of public key. This assumption is by
the clarification of using these bits in [3].
+-------------+---------+ +-------------+---------+
|partial IID1 | | |Partial IID2 | |
+-------------+ | +-------------+ |
| | | |
+-----------------------+ +-----------------------+
Figure 1 Public key divided into two halves
4.1.2. Signature Generation
The SSAS signature is added to NDP messages in order to protect them
from IP spoofing and spoofing types of attack. SSAS will provide
proof of IP address ownership, as does the CGA generation algorithm,
but by using fewer steps. To generate the SSAS signature, the node
needs to execute the following steps:
1. Concatenate the timestamp with the MAC address, collision count,
algorithm type and the global (public) IP address. (see figure 2)
Rafiee, et al. Expires April 21, 2014 [Page 8]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
+---------+-----------+---------------+--------------+
|timestamp|Mac address|Collision Count|Algorithm type|
| 8 bytes | 6 bytes | 3 bits | 1 byte |
+---------------------+---------------+--------------+
|Global IP address | Other Options |
| 16 bytes | variable |
+---------------------+---------------+
Figure 2 SSAS Signature format
2. Sign the resulting value from step 1, using the ECC private key,
and call the resulting output the SSAS signature.
If NDP messages contain other data that must be protected, such as
important routing information, then this data SHOULD also be included
in the signature. The signature is designed for the inclusion of any
data needing protection. If there is no data that needs protection,
then the signature will only contain the timestamp, MAC address,
Collision count and Global IP address (Router subnet prefix plus
IID).
4.1.3. Generation of NDP Messages
After a node generates its IP address, it should then process
Duplicate Address Detection in order to avoid address collisions in
the network. In order to do this the node needs to generate a
Neighbor Solicitation (NS) message. The SSAS signature is added to
the ICMPv6 options of NS messages. The SSAS signature data field is
an extended version of the standard format of the RSA signature
option of SeND [RFC3971]. The timestamp option is the same as that
used with SEND. In the SSAS signature, the data field contains the
following items: type, length, reserved, Other Len, algorithm type,
collision count, subnet prefix, other option and padding.
4.1.3.1. SSAS signature data field
+------+-------+------------+---------+
| Type |Length | Reserved |Other len|
|1 byte|1 byte | 2 bytes | 1 byte |
+----------+---------+------+---------+
| Algorithm|Collision|Subnet| Other |
| type | count |prefix|Options |
| 1 byte | 3 bits |8bytes| |
+-------------------------------------+
| |
| SSAS Signature |
Rafiee, et al. Expires April 21, 2014 [Page 9]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
| |
+-------------------------------------+
| padding |
+-------------------------------------+
Figure 3 NDP Message Format with SSAS Signature Data Field
- Type: This option is set to 15. This is the sequential number used
in SeND to indicate a SSAS data field.
- Length: The length of the Signature Data field, including the Type,
Length, Reserved, Algorithm type, Signature and padding, must be a
multiple of eight.
- Reserved: A 2 byte field reserved for future use. The value must be
initialized to zero by the sender and should be ignored by the
receiver.
- Other Len: The length of other options in multiples of eight. The
length of this field is 1 byte.
- algorithm type: The algorithm used to generate key pairs and sign
the message. The length of this field is 1 byte. For ECC, this value
is 0. Future algorithms will start at one and increase from there.
- Collision count: When a collision occurs during the DAD, the node
will increment this value and store it in a file to be included in
the sent packets for as long as the current IP address is valid. This
value indicates to the node where it needs to start its check from,
i.e., the first or second or third bytes from the start of the half
byte array of the public key.
- Subnet Prefix: This is the router subnet prefix.
- Other Options. This variable-length field contains important data
that needs to be protected in the packet. The padding is used to
insure that the field is a multiple of eight in length.
- Padding. A variable-length field containing padding to insure that
the entire signature field is a multiple of eight in length. It thus
contains the number of blanks needed to make the entire signature
field end on a multiple of eight.
All NDP messages (except RS messages) SHOULD contain the SSAS
signature data field which allows receivers to verify senders. If a
node receives a solicited NA message in response to its NS message
showing that another node claims to own this address, then, after a
successful verification process, this node increments the collision
count by one and this value is used as explained in the ?Collision
count? item above. It will start from that section of the public key
for the generation of a new IP address. If the node receives the same
claim three times in a row, then it will consider it as an attack and
it will use that IP address.
Rafiee, et al. Expires April 21, 2014 [Page 10]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
This document proposes an update to the RFC 3971 in order to include
the the SSAS signature data field as an additional field to SeND to
be used in place of RSA signature.
4.1.4. SSAS verification process
A node's verification process should start when it receives NDP
messages. Following are the steps used in the verification process:
1. Obtain the timestamp from the NDP message and call this value t1.
2. Obtain the timestamp from the node's system, convert it to UTC,
and call this value t2.
3. If (t2- x) < = t1 < = (t2 + x) go to step 4. Otherwise, the
message SHOULD be discarded without further processing. The value of
x is dependent on network delays and network policy. The
implementations MUST choose a flexible value for x based on the delay
in this network.
4. Obtain the public key from the RPKI node or by checking its own
neighboring cache. If no matches found in the node cache then
5. Compare this to its own public key. If it is not the same, go to
the next step. Otherwise, the message should be discarded without
further processing. (This step should be skipped when the node uses
the RPKI to obtain the other nodes? public key.)
6. Divide the public key into two arrays of byes. Based on the
collision count, start from the first, second or third bytes of
public key and select 4 bytes from each half byte array and call them
partial IID 1 and 2. Concatenate partial IID 1 with partial IID2.
Obtain the node?s source IP address. Compare this value with the
node's IID source IP. If it is the same, go to the next step.
Otherwise, discard the message without further processing.
7. Concatenate the timestamp with the MAC address, algorithm type,
collision count, sender?s Global IP address (subnet prefix and IID),
and other options (if any) and call this entity the plain message.
8. Obtain the SSAS signature from the SSAS signature data field.
Obtain the Algorithm type from the message.
9. Verify the Signature using the public key and then enter the plain
message and the SSAS signature as an input to the verification
function. If the verification process is successful, process the
message. Otherwise, the message should be discarded without further
processing.
Rafiee, et al. Expires April 21, 2014 [Page 11]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
After a successful verification, the node stores the public key and
MAC address of this node in its neighboring cache. The cache is valid
for a day.
4.2. Resource Public key Infrastructure (RPKI)
To Authorized the Routers in the network and increase the security of
the nodes in this network, it is recommended to use an RPKI explained
in RFC 6494 and 6495.
5. Security Considerations
As a security consideration what one might ask oneself is what are
the odds of an attacker being able to generate a public key having
two four sequential bytes (from two different halves of public key)
that are the same as 62 bits of that in public key? If he could, he
could then generate the signature using his own private key and thus
break SSAS.
Mathematically it has been shown that the probability of matching 48
bits in the public key against 62 bits in the IID is about
pow(1/2,62) where pow is the power function, 2 is a base and 64 is an
exponent. in [2] the analysis of SSAS is explained and compared to
CGA. For CGA sec value 0, the attacker needs to do brute force
attacks against 59 bits. So SSAS v1 is more secure than CGA sec value
0. For SSAS v2, the attacker needs to do brute force attacks against
the whole public key. So the security of that is depends on the
security of public key algorithm and the key size.
6. IANA Considerations
This document defines two new algorithm for the generation of an
Interface ID in IPv6 networks that provides IP layer privacy and
local link security.
7. Conclusions
This document introduced two fast secure algorithms that might be
used to also maintain the user's privacy. It eliminates the compute
intensive process of CGA.
Rafiee, et al. Expires April 21, 2014 [Page 12]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
8. Acknowledgements
The Authors would like to acknowledge Erik Nordmard for his supports
and assistance to improve this document.
9. References
9.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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and Nikander, P.,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T.,
Perkins, C., Carney, M. , " Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3756] Nikander, P., Kempf, J., Nordmark, E., "IPv6
Neighbor Discovery (ND) Trust Models and Threats", RFC
3972, May 2004.
[RFC4919] Kushalnagar, N., Montenegro, G., Schumacher, C.,"
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs): Overview, Assumptions, Problem Statement, and
Goals", RFC 4919, August 2007.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E.,
Bormann, C. , " Neighbor Discovery Optimization for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, November 2012.
[RFC6275] Perkins, C., Johnson, D., Arkko, J., "Mobility
Support in IPv6", RFC 6275, July 2011.
[RFC6543] Gundavell, S., "Reserved IPv6 Interface
Rafiee, et al. Expires April 21, 2014 [Page 13]
INTERNET DRAFT SSAS for Autoconfiguration October 21, 2013
Identifier for Proxy Mobile IPv6", RFC 6543, May 2012.
[RFC6090] McGrew, D., Igoe, K., Salter, M., "Fundamental
Elliptic Curve Cryptography Algorithms", RFC 6090, February
2012.
9.2. Informative References
[1] IEEE Standards Association,
http://standards.ieee.org/develop/regauth/tut/eui64.pdf, 2012
[2] Rafiee, H., Meinel, C., "'SSAS: a Simple Secure Addressing
Scheme for IPv6 AutoConfiguration". In Proceedings of the 11th
IEEE International Conference on Privacy, Security and Trust
(PST), IEEE Catalog number: CFP1304F-ART, ISBN:
978-1-4673-5839-2.
[3] Carpenter, B., Jiang, S., Work In Progress,
http://tools.ietf.org/html/draft-ietf-6man-ug, 2013
Rafiee, et al. Expires April 21, 2014 [Page 14]
INTERNET DRAFT SSAS for Autoconfiguration 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 15]