[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                               Hasso Plattner Institute
(if approved)
Intended status: Proposed Standard
Expires: June 15, 2014                                 December 15, 2013

   A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)


   The purpose of this document is to address the current problem
   inherent with using 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] or any other
   documents that does not focus on local security 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 June 2, 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 June 15, 2014                     [Page 1]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 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  . . . . . . . . . . . . . .  4
   3.  Algorithms Overview  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Interface ID (IID) Generation  . . . . . . . . . . . . . .  4
       3.1.1.  Signature Generation   . . . . . . . . . . . . . . . .  5
       3.1.2.  Generation of NDP/SeND Messages  . . . . . . . . . . .  6  SSAS signature data field  . . . . . . . . . . . .  6
       3.1.3.  SSAS verification process  . . . . . . . . . . . . . .  8
     3.2.  Resource Public key Infrastructure (RPKI)  . . . . . . . .  9
   4.  SSAS Applications  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  A solution for all nodes   . . . . . . . . . . . . . . . .  9
     4.2.  Authentication in Network layer  . . . . . . . . . . . . .  9
     4.3.  Authentication in Application Layer  . . . . . . . . . . . 10
     4.4.  Other Applications   . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Appendix   . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Network-based protection vs. Node-based protection   . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Rafiee, et al.        Expires June 15, 2014                     [Page 2]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

1.  Introduction

   In IPv6 networks, nodes can use two different mechanisms to configure
   their IP addresses -- Neighbor Discovery Protocol (NDP) [RFC4861,
   RFC4862] and Dynamic Host Configuration Protocol (DHCPv6) [RFC3315].
   Unfortunately none of these mechanisms are natively secure. So, they
   open the nodes with so many local security problems. There are
   several attacks possible iin local network [RFC3756]. One example is
   IP spoofing that forges the identity of the other node, the other
   example is preventing the node from configuring his IP address.

   The reasons that local security is important are as follows [5]:

   - Not all the nodes on the local link are trusted: viruses or other
   malware can infect the legitimate node in the local link and turn it
   to an attacker.

   - Attacker might be inside the network: The networks of big
   enterprises might be harmed by one of the staff that was recently

   There is currently a mechanism available to secure the NDP, i.e.,
   Secure Neighbor Discovery (SeND) [RFC3971]. SeND does this protection
   by adding 4 options to NDP packets. Among these options,
   Cryptographically Generated Addresses (CGA) [RFC3972] is a very
   important option that provides the node with the proof of IP address
   ownership by finding a binding between the node's public key and his
   IP address. Unfortunately CGA has some problems that are listed as

   - CGA sec value problem: This problem is explained in [3].

   - CGA increase complexity and decrease performance: CGA uses sec
   value (the value between 0 to 7) and claims to complicate the brute
   force attacks. (However it is not true based on [3]) If CGA sec value
   higher than 0 is in use, then this will reduce the performance
   because CGA algorithm needs to repeat some steps and it needs the
   high attention of the CPU and makes the CPU busy. So, CGA sec value
   higher than 0, consumes more energy than other nodes that do not use
   CGA. Today, the demands on multi-functioning smaller devices are
   increasing but unfortunately the battery technology is not as
   advanced as expected. So, the use of CGA algorithm that needs to use
   higher level of energy is not ideal for these types of nodes and the
   use of CGA sec value zero does not protect the node as expected.

   - CGA might cause privacy issue: Since the generation of CGA higher
   sec values might take time. The nodes might not be willing to change
   its IP address and keep this address as long as the subnet prefix is
   valid. If the node is a fixed node in the network, then it will be
   vulnerable to node tracking. The node might also not change the CGA
   address when it visits a new network. Since in Hash2 process

Rafiee, et al.        Expires June 15, 2014                     [Page 3]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

   - Packet size

   CGA uses RSA as a default key size algorithm and there is no
   definition of the use of other public key cryptography algorithms.
   This is why the minimum packet size for CGA nodes is 460 bytes.
   Packet size also reduces the performance and causes delays in the

   Since privacy and security are, both, very important issues in
   everyday life, the purpose of this document is to offer an
   alternative and simple addressing mechanism to generate an interface
   ID (IID) which provides the node with both security and privacy while
   does not sacrifice the performance, and tries to decrease the packet
   size as much as possible

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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.  Algorithms Overview

   As explained earlier, one of the problems with using the current IID
   generation approach is the intensive computer processing that is
   needed for the IID algorithm generation. Another concern is for the
   lack of security (if CGA is not in use). 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.

3.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 [RFC6090] 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

Rafiee, et al.        Expires June 15, 2014                     [Page 4]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

   fly, during the start-up phase of the algorithm generation. These
   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.

   Note: The node MUST not generate the weak key. For ECC, the node MUST
   not use ECC key size lower than 192 bits. If any nodes used a weak
   key size, then the other nodes MUST discard receiving the message
   from that node.

   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 the
   public key is only for randomization)

   3. Concatenate partial IID1 with partial IID2 and call this the IID.

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

   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

3.1.1.  Signature Generation

   If SSAS is used as an option of SeND, SSAS signature can be placed as
   a RSA signature in SeND. If SSAS is used alone, this section MUST be
   included in SSAS data structure.

Rafiee, et al.        Expires June 15, 2014                     [Page 5]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

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

|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
   (or any other short key size algorithm), 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

3.1.2.  Generation of NDP/SeND 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.  SSAS signature data field

Rafiee, et al.        Expires June 15, 2014                     [Page 6]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

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

   - 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

Rafiee, et al.        Expires June 15, 2014                     [Page 7]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

   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.

   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.

3.1.3.  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 default
   value would be the value of RTT. The implementations SHOULD allow to
   set different values.

   4. Obtain the public key from its own neighboring cache. If no
   matches are found in the node cache and if there is a centralized
   RPKI model available in the local network, then the node MIGHT obtain
   this public key from that node. Otherwise go to the next step.

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

Rafiee, et al.        Expires June 15, 2014                     [Page 8]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

   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

   After a successful verification, the node SHOULD store the public key
   and MAC address of the sender node in its neighboring cache. By
   default, the cache is valid for two days but the implementation
   SHOULD consider a way to let the end users change this default value.

3.2.  Resource Public key Infrastructure (RPKI)

   To Authorize 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. It is explained in more detail in [1] and local
   security deployment [5].

4.  SSAS Applications

4.1.  A solution for all nodes

   SSAS is capable to be used in standard nodes (standard computers) and
   nodes where limited computational resources are available. One
   example is the use of SSAS in sensor networks. 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.

4.2.  Authentication in Network layer

   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 June 15, 2014                     [Page 9]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 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.

4.3.  Authentication in Application Layer

   SSAS can be used as a means of authentication for the nodes in
   application layer. It is really important that the nodes know who
   they are talking to. So, application can make use of this approach as
   a way to authenticate the other nodes in the network. It can have an
   access list based on the IP address and verify the node by processing
   SSAS verification.

4.4.  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 be for use in vehicular networks or in
   the car-to-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.

5.  Security Considerations

   There are two security considerations

   Since SSAS cannot prevent the layer 2 attacks but can mitigate it
   after the first verification, therefore one would need to use a
   monitoring device to prevent MAC spoofing. The other possibility is
   to have a dynamic MAC address. This means the SSAS node can use the
   48 rightmost bits of the its public key as a MAC address. In this
   case there is a binding between the IP address, MAC address and
   public key. Since the verification process would have failed, it
   cannot be spoofed. However, this approach might be problematic from
   an operational view and might need to have some consideration before
   being used.

Rafiee, et al.        Expires June 15, 2014                    [Page 10]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

   Another security consideration is how to attack SSAS. One might ask
   oneself that 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 64 bits of that in
   Interface ID? 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 64
   bits in the public key against 64bits in the IID is about pow(1/2,64)
   where pow is the power function, 2 is a base and 64 is an exponent.
   in [1] the analysis of SSAS is explained and compared to CGA. Since
   the nodes in the network need to keep the public key and the MAC
   address of other nodes in the cache, the attacker only has a few
   seconds to perform this attack and then the attacker needs to perform
   this attack against the whole public key. For CGA, this value is
   less. in [3], the attack in CGA was explained. So, in general, SSAS
   is faster and more secure than CGA.

6.  IANA Considerations

   This document defines an algorithm for the generation of an Interface
   ID in IPv6 networks that provides IP layer privacy and local link
   security. It is needed to assign a number for this option in NDP and
   SeND packet so that the nodes can detect SSAS value by checking the
   "TYPE" field.

7.  Appendix

7.1.  Network-based protection vs. Node-based protection

   Node-based protection is the ability of the node to protect against
   some types of attacks such as IP spoofing, MITM attack. On the other
   hand, network-based protection is the use of some devices in the
   network edges to protect the nodes inside this network against router
   advertisement spoofing attacks or other types of attack. Both of
   these protection is required and both can complement each other. This
   is because the attacker might be inside the network and play a role
   of MITM, spoof the other nodes' IP address, prevent other nodes from
   configuring their IP address and cause many delays and problems in
   the local network (Not all the nodes in the network is ever trustee).
   One important consideration about node-based protection is that, it
   should support any node and apply to any nodes (Including nodes with
   limited energy resources or limited memory resources). This is why
   there is a need for a good mechanism to provide this protection with
   less cost. The proposed mechanism in this document, i.e., SSAS can

Rafiee, et al.        Expires June 15, 2014                    [Page 11]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

   provide the node with node-based protection. With only node-based
   protection, the malicious node inside this network can claim to be a
   router and the node does not have any means to authorize him. This is
   why, the network-based protection is also the complement solution to
   a node-based protection. There are some approaches to provide the
   node with network-based protection. One such approach might be
   RA-gaurd [4] which limits subnet prefixes. Unfortunately with this
   approach, still the node inside this network can maliciously claim to
   be a router and play the MITM attack inside the network by sending
   unicast router advertisement messages. So, the attack is still
   possible. The other approach is the use of RPKI as explained in RFC
   6494 and RFC 6495. Unfortunately these RFCs only explain the
   possibility of using them but not the detail of implementation. The
   detail implementation is explained in [1]. The local RPKI node also
   can play a role of monitoring device in the network.

8.  Acknowledgements

   The Authors would like to acknowledge Erik Nordmard for his supports
   and assistance to improve this document.The authors also would like
   to acknowledge Michael Richardson, Dan Wing, Tim Chown, Christian
   Huitema for their comments 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.

Rafiee, et al.        Expires June 15, 2014                    [Page 12]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

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

   [RFC6090] McGrew, D., Igoe, K., Salter, M., "Fundamental
             Elliptic Curve Cryptography Algorithms", RFC 6090, February

   [RFC3756] Nikander, F., Kempf, J., Nordmark, E., "IPv6
             Neighbor Discovery (ND) Trust Models and Threats", RFC
             3756, May 2004.

9.2.  Informative References

   [1] 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:

   [2] Carpenter, B., Jiang, S., Work In Progress,
       http://tools.ietf.org/html/draft-ietf-6man-ug, 2013

   [3] Rafiee,H., Meinel, C., "Possible Attack on Cryptographically
       Generated Addresses (CGA)"
       ,http://tools.ietf.org/html/draft-rafiee-6man-cga-attack, 2013

   [4] Gont, F,"Implementation Advice for IPv6 Router Advertisement

   [5] Rafiee,H., Meinel, C., "Recommendations for Local Security

Rafiee, et al.        Expires June 15, 2014                    [Page 13]

INTERNET DRAFT       SSAS for Autoconfiguration        December 15, 2013

Authors' Addresses

      Hosnieh Rafiee
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Phone: +49 (0)331-5509-546
      Email: ietf@rozanak.com

      Dr. Christoph Meinel
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Email: meinel@hpi.uni-potsdam.de

Rafiee, et al.        Expires June 15, 2014                    [Page 14]

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