[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 04 05 06 07 08 09 10 11

IPv6 maintenance Working Group (6man)                         H. Rafiee
INTERNET-DRAFT                                                C. Meinel
Updates RFC 3971 , RFC 3972, RFC 4941          Hasso Plattner Institute
(if approved)
Intended status: Proposed Standard
Expires: September 12, 2013                               March 12, 2013


A Simple Secure Address Generation Scheme for IPv6 AutoConfiguration
                                 (SSAS)
                     <draft-rafiee-6man-ssas-04.txt>

Abstract

   The default method for IPv6 address generation uses an
   Organizationally Unique Identifier (OUI) assigned by the IEEE
   Standards Association and an Extension Identifier assigned to the
   hardware manufacturer [1] (section 2.5.1 RFC-4291) [RFC4291]. This
   fact thus means that a node will always have the same Interface ID
   (IID) whenever it connects to a new network. Because the node's IP
   address does not change, the node will be vulnerable to privacy
   related attacks. Currently this problem is addressed by the use of
   two mechanisms that do not make use of the MAC address, or other
   unique values that can be used for ID generation, for randomizing the
   IID; Cryptographically Generated Addresses (CGA) [RFC3972] and
   Privacy Extension [RFC4941]. The problem with the former approach is
   the computational cost involved for the IID generation and in the
   verification process. The problem with the latter approach is that it
   lacks necessary security mechanisms and provides the node with only
   partial protection against privacy related attacks. This document
   proposes the use of a new algorithm for use in the generation of the
   IID while, at the same time, securing the node against some types of
   attack, like IP spoofing. These attacks are prevented by the addition
   of a signature to messages sent over the network and by direct use of
   a public key in the IP address.



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


Rafiee, et al.   Expires September 12, 2013                     [Page 1]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   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 September 12, 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   . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  SSAS Applications  . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Preventing Attacks   . . . . . . . . . . . . . . . . .  6
         3.1.1.1.  Replay attack  . . . . . . . . . . . . . . . . . .  6
         3.1.1.2.  IP spoofing  . . . . . . . . . . . . . . . . . . .  6
         3.1.1.3.  Denial of Service (DoS) attacks  . . . . . . . . .  6
         3.1.1.4.  Spoofed Redirect Message   . . . . . . . . . . . .  7
       3.1.2.  Nodes with limited resources   . . . . . . . . . . . .  7
       3.1.3.  Other Applications   . . . . . . . . . . . . . . . . .  8
   4.  Algorithms Overview  . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Observe Privacy and Security   . . . . . . . . . . . . . .  8
       4.1.1.  Interface ID (IID) Generation  . . . . . . . . . . . .  8
       4.1.2.  Signature Generation   . . . . . . . . . . . . . . . . 10
       4.1.3.  Generation of NDP Messages   . . . . . . . . . . . . . 10
         4.1.3.1.  SSAS signature data field  . . . . . . . . . . . . 11
       4.1.4.  SSAS verification process  . . . . . . . . . . . . . . 12
       4.1.5.  PKI for Router Authorization . . . . . . . . . . . . . 14
     4.2.  Observe Privacy without Security Consideration   . . . . . 14
       4.2.1.  Interface ID (IID) Generation  . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 17


Rafiee, et al.   Expires September 12, 2013                     [Page 2]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19






















































Rafiee, et al.   Expires September 12, 2013                     [Page 3]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 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. 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. 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. 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 two mechanisms used to generate a randomized IID that do
   not make use of a MAC address; CGA [RFC3972] and Privacy Extension
   [RFC4941]. 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
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.


Rafiee, et al.   Expires September 12, 2013                     [Page 4]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013


   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. 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.

   What is clear here is that it is not possible to generate the CGA
   offline or before hand. This is because the subnet prefix (router
   prefix) is one of the inputs to the SHA1 algorithm. The other 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.

   In order to overcome the problem with using the other mechanisms, the
   time needed for IP address generation and verification needs to be
   reduced. 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 of attack in
   the IP layer. Our experimental results [2] show that SSAS is much
   faster than CGA when using a sec value of 0, and 600 times faster
   than CGA when using a sec value of 1. This result will remain the
   same in the future when there are faster CPUs because SSAS will also
   benefit from the use of faster CPUs. Currently the generation time
   for SSAS is less than 100 nanoseconds so when future new technologies
   come into play it will be even less.

   Note: It is not the intent of this document to obsolete CGA but to


Rafiee, et al.   Expires September 12, 2013                     [Page 5]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   propose a simpler and a faster addressing mechanism for use in
   providing nodes with network layer privacy and security. This is
   accomplished by providing a node with an algorithm to be used to
   randomize the IID while at the same time providing nodes protection
   against the types of attack explained below.



3.1.  SSAS Applications



3.1.1.  Preventing Attacks

   The following sections detail some types of attack that SSAS can
   prevent.



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 this can be prevented. With the addition of a timestamp and
   by making a comparison of the public key to his own (the node's)
   public key to that in the NDP message and also by the inclusion of
   this timestamp in the signature. 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
   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,


Rafiee, et al.   Expires September 12, 2013                     [Page 6]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   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
   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 forthe 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
   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.



Rafiee, et al.   Expires September 12, 2013                     [Page 7]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013



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 both security and
   privacy are a concern and the second algorithm is used where only
   privacy is concern. The second algorithm addresses the problem with
   the Privacy Extension RFC where the IID might not be fully
   randomized. But the use of a timestamp and a randomly generated
   number, as an input to SHA2, can solve this problem. But the use of
   the first algorithm, where both network layer privacy and security
   are observed, is RECOMMENDED.



4.1.  Observe Privacy and Security



4.1.1.  Interface ID (IID) Generation

   To generate the IID a node will need to execute the following steps.

   1. Generate a 2 byte (unsigned) random number called modifier. In the
   generation of this modifier, implementations SHOULD use a random seed
   in order to help in the randomization process of this number. Use of
   a timestamp is OPTIONAL when a seed is used to generate the modifier.
   The modifier MUST be greater than 128 (decimal). Set bits u and g
   (bits 7 and 8) in the first byte of the modifier to zero.

   2. Generate key pairs (public/private keys) using RSA or other
   available algorithms. The default algorithm is RSA. Implementations
   SHOULD store these keys in a safe place. It is RECOMMENDED that the
   public key be generated, on the fly, during the start-up phase of the


Rafiee, et al.   Expires September 12, 2013                     [Page 8]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   algorithm generation. The keys MUST be valid over a certain period of
   time. The implementation SHOULD consider this time based on the
   network policy and privacy considerations. When the time expires for
   the use of these key pairs, the node SHOULD generate new key pairs.
   It SHOULD then use this new value for IP address and signature
   generation. Implementation use of algorithms other that RSA is
   OPTIONAL. Another algorithm that is RECOMMENDED for use in place of
   RSA is ECC [3]. Comparing the use of ECC to that of RSA shows that
   ECC with a 192 bit keys equivalent to a 1280 bit RSA key size. In
   this case the packet size would be decreased by a factor 5 times
   smaller than when RSA is used. However, with key sizes of 1024 bits
   and 1280 bits, RSA generation and verification times are much faster
   than when ECC is used. The other problem with the use of ECC is that
   it might hold a patent and might not be royalty free.

   3. Obtain the second byte of the modifier and call it the start field
   pubkey. If the value of the start field pubkey is between 0 and the
   size of public key length, in bytes, minus 6, then use this number as
   an index for the public key array of bytes. Otherwise choose that
   byte and shift its contents 2 bits to the right (the first two bits
   will be zero) and set the start field pubkey to this number. This
   ensures that the value of the start field pubkey will be less than
   the size of the public key array of bytes, minus 6. This value helps
   randomize the IID and minimizes the chance for a collision in the
   network. For example, if the second byte of the modifier is 110, then
   the start field pubkey value will be 110.

   - If ECC is used for key generation the content of the start field
   pubkey SHOULD be shifted 3 bits to the right. This insures that its
   value will be less than the size of public key array of bytes, minus
   6.

   - If any future algorithms are used where the number of bytes in the
   public key array of bytes is less than six bytes, then step 3 SHOULD
   be skipped and the whole public key MUST used in concatenation with
   the modifier for next step.

   +-------------------------------------+
   |           |     Pubkey    |         |
   |           |   (48 bits)   |         |
   +           +---------------+         +
   |             Public key              |
   |            (1024 bits)              |
   +-------------------------------------+
    Figure  1  Public key part of Interface ID


   4. Concatenate the modifier with the six bytes from the public key
   (starting at the start field pubkey) and call this the IID.


   +---------------+----------------------+
   |    Modifier   |        Pubkey        |


Rafiee, et al.   Expires September 12, 2013                     [Page 9]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   |    (16 bits)  |       (48 bits)      |
   +---------------+----------------------+
    Figure  2  Interface ID


   5. Concatenate the IID with the local subnet prefix to set the local
   IP address

   6. Concatenate the IID with the router subnet prefix (Global subnet
   prefix), obtained from the RA message, and set it as a tentative
   global IP address. (This IP will become permanent after Duplicate
   Address Detection (DAD) processing. (for more information about DAD
   refer to section 4.1.3. )



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 16 byte public key (that starts
   at the start field pubkey) (see figure 3) and the global IP address.
   The start field pubkey is one of the numbers that was introduced in
   step 3 of section 4.1.1.

   2. Sign the resulting value from step 1, using the RSA private key,
   unless ECC or another available algorithm is used, and call the
   resulting output the SSAS signature.


  +---------+----------+-----------------+-------------+
  |timestamp|Public key|Global IP Address|Other Options|
  |(8 bytes)|(16 bytes)|   (16 bytes)    |  (variable) |
  +---------+----------+-----------------+-------------+
    Figure  3 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, 16 byte public
   key 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


Rafiee, et al.   Expires September 12, 2013                    [Page 10]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   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 format of a NS message is
   shown in figure 4. 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, pubkey len, public key, SSAS signature, and
   padding.




   +----------------+-------------+----------------------------+
   |   IPv6 Header  |ICMPv6 header|  ND message Specific Data  |
   | Next header= 58|             |         (variable)         |
   +--------------+-+-----------+-+----------------------------+
   |   Type = 13  |    length   |           Reserved           |
   |   (1 byte)   |   (1 byte)  |           (6 bytes)          |
   +--------------+-------------+------------------------------+
   |                       timestamp                           |
   |                                                           |
   +----------+--------+---------+-----------+-----------------+
   | Type = 15| length |Reserved | Other Len |  algorithm type |
   | (1 byte) |(1 byte)|(2 bytes)|  (1 byte) |     (1 byte)    |
   +----------+-----+--+--------------+------+-----------------+
   | Subnet Prefix  |    Pubkey Len   |   Public Key in base64 |
   |   (8 byte)     |     (1 byte)    |        format          |
   +----------------+-----------------+------------------------+
   |                       Other Options                       |
   |                                                           |
   +-----------------------------------------------------------+
   |                      SSAS Signature                       |
   |                                                           |
   +-----------------------------------------------------------+
   |                       padding                             |
   |                                                           |
   +-----------------------------------------------------------+
   Figure 4  NDP Message Format with SSAS Signature Data Field


   This document proposes an update to the SEND RFC in order to replace
   the RSA signature field with the SSAS signature data field and to add
   SSAS, as a new option, to SEND messages.



4.1.3.1.  SSAS signature data field

   - Type: This option should be set to 15. This number is a sequential
   number in SEND options and represent the SSAS data field.



Rafiee, et al.   Expires September 12, 2013                    [Page 11]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   - Length: The length of the Signature Data field, including the Type,
   Length, Reserved, pubkey Len, public key, Signature and padding,
   should 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 MUST 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 in generating key pairs and
   signing the message. The length of this field is 1 byte. For RSA,
   this value MUST be 0 and for ECC 1. For any other future algorithm it
   MUST start from 2.

   - Subnet Prefix: This is the router subnet prefix.

   - PubKey Len. The length of the public key in multiples of eight.

   - Public key. Base64 format of the public key

   - 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 need to make the entire signature field
   end on a multiple of eight.

   All NDP 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 modifier by one and again repeats
   steps 2 thru 6 of section 4.1.1 . It repeats this process 3 times. If
   after the third try the node receives the same claim, then it
   considers it as an attack and will use that IP address.



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.


Rafiee, et al.   Expires September 12, 2013                    [Page 12]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013


   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 SSAS signature data field.

   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, along with the timestamp, can prevent
   replay attacks.

   6. Obtain the second byte of the modifier and call it the start field
   pubkey. If the value of the start field pubkey is between 0 and the
   size of public key length, in bytes, minus 6, then use this number as
   an index for the public key array of bytes. Otherwise choose that
   byte and shift its contents 2 bits to the right (the first two bits
   will be zero) and consider this number the starting index of the
   public key array of bytes. This ensures that the value of that byte
   will be less than the size of the public key array of bytes, minus 6.
   Set the start field pubkey to this number.

   If ECC is used for key generation, then the content of the start
   field pubkey SHOULD be shifted 3 bits to the right. This insures that
   its value is less than the size of public key array of bytes, minus
   6.

   7. Obtain the IID from the sender's source IP address. (64 rightmost
   bits of the IPv6 address)

   8. Compare the 48 leftmost bits, starting at the start field pubkey
   of the public key, to the 48 rightmost bits of the IID of the
   sender's IP address. If they are the same, go to the next step.
   Otherwise, the message should be discarded without further processing

   9. Obtain the subnet prefix from the SSAS signature data field.

   10. Concatenate the timestamp with the 16 bytes of the public key,
   (starting from start field pubkey), the subnet prefix, the sender's
   IID, and other options (if any) and call this entity the plain
   message.

   11. Obtain the SSAS signature from the SSAS signature data field.
   Obtain the Algorithm type from the message.

   12. 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 September 12, 2013                    [Page 13]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013



4.1.5.  Public key Infrastructure (PKI) for Router Authorization

   RFC-6494 explains two different models to use for certificate
   authority; centralized and decentralized. Here we use the centralized
   model in local networks by using DNSSEC (RFC-4034) for key
   authorization purposes. The routers' keys can be manually stored in
   the DNS server database. The clients then need to use the DNSKEY
   Resource Record (RR) to obtain the data necessary to generate a DNS
   query message in order to validate the router public key. The
   implementation SHOULD be able to support the DNS query messages. The
   advantage to this approach is that the nodes already know the IP
   address of DNS server so there is no need to preconfiguration them.



4.2.  Observe Privacy without Security Consideration



4.2.1.  Interface ID (IID) Generation

   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 nodes' current time and convert it to timestamp. The
   timestamp is a 64-bit unsigned integer field containing a timestamp.
   The value indicates the number of seconds since January 1, 1970,
   00:00 UTC, by using a fixed point format.

   3. Concatenate the modifier with the timestamp.

   R1=(modifier(16 bytes)||timestamp(8 bytes))

   4. Execute SHA2 (256) on the result from step 3.

   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). If, in the future,
   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.

   5. Generate a random number between 0 and 24 and call it the start
   index. This number is used as an index for the SHA2 array of bytes.
   This value helps randomize the IID and to minimize the chances for a
   collision in the network. The length of this number is one byte.

   If the output digest of future algorithms are less than 32, then the


Rafiee, et al.   Expires September 12, 2013                    [Page 14]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   random number must be the size of that digest, minus 8. This allows
   the random number to be generated within the index of the digest
   array of bytes.

   6. Take the 64 leftmost bits (starting at the start index) from the
   resulting output from step 5 (SHA2 digest) and set bits u and g (bits
   7 and 8) to zero and call this the IID.


   +-------------------------------------+
   |           |  IID          |         |
   |           |   (64 bits)   |         |
   +           +---------------+         +
   |             SHA2 digest             |
   |             (256 bits)              |
   +-------------------------------------+
    Figure  5  Interface ID


   7. Concatenate the IID with the local subnet prefix to set the local
   IP address

   8. Concatenate the IID with the router subnet prefix (Global subnet
   prefix), obtained from the RA message, and set it as a tentative
   global IP address. This IP address will become permanent after
   Duplicate Address Detection (DAD) processing.











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
   four sequential bytes that are the same as the last rightmost 48 bits
   of the IID; 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 48 bits in the IID is about
   pow(1/2,48) where pow is the power function, 2 is a base and 48 is an
   exponent. Since the use of a public key and IP address with a maximum
   lifetime of 30 days is RECOMMENDED, the probability of an attacker
   finding the same value is 0.00000003, a very small value. When one
   also considers the probability of an attacker being able to generate
   a public key whose 48 bits, starting from an arbitrary point, matches


Rafiee, et al.   Expires September 12, 2013                    [Page 15]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013

   the 48 bits of the public key generated using the SSAS algorithm,
   then the probability of his success is diminished even further. This
   shows the strength of this algorithm against brute force attacks
   while, at the same time, by using the signature and finding a binding
   between the IP address and the public key, it provides proof of IP
   address ownership at a speed that is about 600 times faster than that
   of the CGA algorithm [2] (based on the implementation results, the
   average time to generate SSAS including key generation is 250
   microseconds).

   Another consideration concerns routers wanting to use this algorithm
   in place of CGA. As explained in RFC SEND, for routers, the use of a
   Trusted Authority is RECOMMENDED along with the process of verifying
   router certificates using other third party authorities (RFC-6494 and
   RFC-6487) This will prevent a node from claiming to be a router. For
   nodes then, rather than routers, SSAS can provide protection against
   the types of attacks explained above. This document also propose the
   use of DNSSEC for key authorization as is explained in section 4.1.5.




6.  IANA Considerations

   This document defines a new algorithm for the generation of an
   Interface ID in IPv6 networks that provides IP layer privacy and
   local link security



7.  Conclusions

   Privacy has become a very important issue in recent years. A solution
   for preventing a node from being tracked by an attacker is to change
   the node's IP address frequently and by generating a random IID each
   time a node wants to generate a new IP address. There are two
   solutions available for randomizing the IID; CGA and Privacy
   Extension. The former algorithm is compute intensive and the latter
   algorithm is lacking in security. This document introduced a new
   algorithm as a solution for providing privacy by randomizing the IID
   and for providing security with the addition of a SSAS signature to
   the NDP message and finding a binding between the public key and the
   IP address. Our experimental results [2] show a definite improvement
   in the computation time for the SSAS algorithm as compared to that
   for the CGA algorithm. We also note that the probability of having
   collisions with IP addresses, when using the SHA2 digest and the
   public key, with a randomized 62 bit selection, approximates
   pow(1/2,62) where pow is the power function, 2 is a base and 62 is a
   exponent (u and g bits are ignored) . Moreover, the probability of an
   attacker finding the public key which matches 48 rightmost bits of
   the IID within 60 days approximates 0.00001 . This means this
   algorithm is secure enough for wide usage.



Rafiee, et al.   Expires September 12, 2013                    [Page 16]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013



8.  References

8.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.

   [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
             Identifier for Proxy Mobile IPv6", RFC 6543, May 2012.

8.2.  Informative References

   [1] IEEE Standards Association,
       http://standards.ieee.org/develop/regauth/tut/eui64.pdf, 2012

   [2] Rafiee, H., "Research Results",
       http://ipv6sra.rozanak.com/Jan2013_CGA_SSAS_Comparison.pdf, 2013

   [3] Brown, R., L., D. : SEC 1: Elliptic Curve Cryptography,
       Certicom Research,
       http://www.secg.org/download/aid-780/sec1-v2.pdf, 2009


Rafiee, et al.   Expires September 12, 2013                    [Page 17]


INTERNET DRAFT       SSAS for Autoconfiguration           March 12, 2013
























































Rafiee, et al.   Expires September 12, 2013                    [Page 18]


INTERNET DRAFT       SSAS for Autoconfiguration           March 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 September 12, 2013                    [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/