idnits 2.17.1 draft-rafiee-6man-ssas-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note 1: 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. If in future, key size 192 bits is considered as a weak key size, the default key size value MUST be changed to the next strong key size. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'not RECOMMENDED' in this paragraph: It is not RECOMMENDED to use this algorithm in case IID is less than 64 bits [variableprefix]. A node MUST obtain the prefix length information form router advertisement messages. -- The document date (September 19, 2014) is 3500 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5213' is mentioned on line 444, but not defined == Unused Reference: 'RFC4291' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC6543' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RAgaurd' is defined on line 674, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Group H. Rafiee 3 INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH 4 Intended status: Experimental C. Meinel 5 Hasso Plattner Institute 6 Expires: March 19, 2015 September 19, 2014 8 A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS) 9 11 Abstract 13 Since performance and security are, both, two important criteria for 14 a mechanism to be widely used by different nodes with various 15 resources, the purpose of this document is to propose a mechanism for 16 local security and to prevent IP spoofing. This mechanism also 17 consider user's privacy. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute working 26 documents as Internet-Drafts. The list of current Internet-Drafts is 27 at http://datatracker.ietf.org/drafts/current. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 19, 2015. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. This document is subject to 40 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 41 Documents (http://trustee.ietf.org/license-info) in effect on the 42 date of publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Algorithms Overview . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Interface ID (IID) Generation . . . . . . . . . . . . . . 4 55 3.1.1. Signature Generation . . . . . . . . . . . . . . . . 5 56 3.1.2. Generation of NDP/SeND Messages . . . . . . . . . . . 6 57 3.1.2.1. SSAS signature data field . . . . . . . . . . . . 6 58 3.1.3. SSAS verification process . . . . . . . . . . . . . . 8 59 3.2. Resource Public key Infrastructure (RPKI) . . . . . . . . 9 60 4. SSAS Applications . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1. A solution for all nodes . . . . . . . . . . . . . . . . 9 62 4.2. Authentication in Network layer . . . . . . . . . . . . . 9 63 4.3. Authentication in Application Layer . . . . . . . . . . . 10 64 4.4. Other Applications . . . . . . . . . . . . . . . . . . . 10 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 7. Privacy Consideration . . . . . . . . . . . . . . . . . . . . 11 68 8. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Comparison of CGA and SSAS generation time . . . . . . . 11 70 9. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9.1. Network-based protection vs. Node-based protection . . . 12 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 In IPv6 networks, nodes can use two different mechanisms to configure 81 their IP addresses -- Neighbor Discovery Protocol (NDP) [RFC4861, 82 RFC4862] and Dynamic Host Configuration Protocol (DHCPv6) [RFC3315]. 83 Unfortunately none of these mechanisms are natively secure. So, they 84 open the nodes with so many local security problems. There are 85 several attacks possible in local network [RFC3756]. One example is 86 IP spoofing that enable an attacker to forge the identity of a victim 87 node, the other example is preventing the node from configuring its 88 IP address. 90 The reasons that local security is important are as follows 91 [localSecurity]: 93 - Not all the nodes on the local link are trusted: viruses or other 94 malware can infect a legitimate node in the local link and turn it to 95 an attacker. 97 - Attacker might be inside the network: The networks of big 98 enterprises might be harmed by one of the staff that was recently 99 fired. 101 There is currently a mechanism available to secure the NDP, i.e., 102 Secure Neighbor Discovery (SeND) [RFC3971]. SeND does this protection 103 by adding 4 options to NDP packets. Among these options, 104 Cryptographically Generated Addresses (CGA) [RFC3972] is a very 105 important option that provides the node with the proof of IP address 106 ownership by finding a binding between the node's public key and its 107 IP address. Unfortunately CGA has some problems that are listed as 108 follows: 110 - CGA sec value problem: This problem is explained in [cgaattack] and 111 addressed in [cgabis]. 113 - CGA increases complexity and decreases performance: CGA uses sec 114 value (the value between 0 to 7) and claims to complicate the brute 115 force attacks. (However it is not true based on [cgaattack]) If CGA 116 sec value higher than 0 is in use, then this will reduce the 117 performance because CGA algorithm needs to repeat some steps and it 118 needs the high attention of the CPU and makes the CPU busy. So, CGA 119 sec value higher than 0, consumes more energy than other nodes that 120 do not use CGA. Today, the demands on malti-functioning smaller 121 devices are increasing but unfortunately the battery technology is 122 not as advanced as expected. So, the use of CGA algorithm that needs 123 to use higher level of energy is not ideal for these types of nodes 124 and the use of CGA sec value zero does not protect the node as 125 expected. (Please refer to appendix A for more information) 127 - CGA might cause privacy issue: Since the generation of CGA higher 128 sec values might take time. The nodes might not be willing to change 129 its IP address and keep this address as long as the subnet prefix is 130 valid. If the node is a fixed node in the network, then it will be 131 vulnerable to node tracking. The node might also not change the CGA 132 address when it visits a new network or it might not generate any new 133 key pairs. In other word, it might use the same CGA parameters 134 (excluding prefix) as used in the old network and thus it will be 135 vulnerable to node tracking. 137 - Packet size 139 CGA uses RSA as a default key pair generation algorithm. This is why, 140 if SeND with CGA option is in use to secure NDP messages, the minimum 141 packet size needs to carry this public key for CGA nodes is 460 142 bytes. Packet size also reduces the performance and causes delays in 143 the network. 145 Since privacy and security are, both, very important issues in 146 everyday life, the purpose of this document is to offer an 147 alternative and simple addressing mechanism to generate an interface 148 ID (IID) which provides the node with both security and privacy while 149 does not sacrifice the performance, and tries to decrease the packet 150 size as much as possible. 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC-2119 [RFC2119]. 158 In this document, these words will appear with that interpretation 159 only when in ALL CAPS. Lower case uses of these words are not to be 160 interpreted as carrying RFC-2119 significance. 162 In this document the use of || indicates the concatenation of the 163 values on either side of the sign. 165 3. Algorithms Overview 167 As explained earlier, one of the problems with using the current IID 168 generation approach is the intensive computer processing that is 169 needed for the IID algorithm generation. Another concern is for the 170 lack of security (if CGA is not in use). This is what this document 171 intends to address. 173 3.1. Interface ID (IID) Generation 175 To generate the IID a node will need to execute the following steps. 177 1. Generate key pairs (public/private keys) using one of the latest 178 version of ECC algorithm [RFC6090] or other fastest short key size 179 algorithms. . The implementations SHOULD be updated with any new 180 version of ECC algorithm when ECC current version is no longer 181 secure. ECC is the default algorithm, but any algorithm capable of 182 generating a small key size in a short amount of time is viable. The 183 node then uses this new value for the generation of the IP address 184 and signature. Comparing the use of ECC to that of RSA shows that an 185 ECC with a 192 bit key is equivalent to a RSA with a 7680 bit key 186 (according to US National Security Agency) In this case the packet 187 size would be decreased by a factor 11 times smaller than that when 188 using RSA. 190 Note 1: The node MUST not generate the weak key. For ECC, the node 191 MUST not use ECC key size lower than 192 bits. If any nodes used a 192 weak key size, then the other nodes MUST discard receiving the 193 message from that node. If in future, key size 192 bits is considered 194 as a weak key size, the default key size value MUST be changed to the 195 next strong key size. 197 2. Execute a hash function on the public key. The default hash 198 function is SHA256. If in future, this hash function is no longer 199 secure, the node MUST use the next strong hash function. 201 3. Take the first 64bits of the digest and call it IID. In case 202 collision count is higher than 1, then depends on the number, takes 203 second 64 bits or third 64 bits of this hash value. 205 It is not RECOMMENDED to use this algorithm in case IID is less than 206 64 bits [variableprefix]. A node MUST obtain the prefix length 207 information form router advertisement messages. 209 4. Concatenate the IID with the local subnet prefix to set the link 210 local IP address. 212 5. Concatenate the IID with the router subnet prefix (Global subnet 213 prefix), obtained from the Router Advertisement (RA) message, and set 214 it as a tentative public IP address. This IP address will become 215 permanent after Duplicate Address Detection (DAD) processing. (For 216 more information about DAD refer to section 3.1.2.) 218 Note 1: In this document bits u and g does not have any particular 219 meaning and is used as a part of public key. This assumption is by 220 the clarification of using these bits in [RFC7136]. 222 3.1.1. Signature Generation 224 SSAS is not dependent to SeND but it can be used as a new option of 225 SeND. When SSAS is used as an option of SeND, SSAS signature can be 226 placed as a RSA signature in SeND. If SSAS is used alone, this 227 section MUST be included in SSAS data structure. This proves that 228 SSAS is compatible to use with SeND. 230 The SSAS signature is added to NDP messages in order to protect them 231 from IP spoofing and spoofing types of attack. SSAS will provide 232 proof of IP address ownership. To generate the SSAS signature, the 233 node needs to execute the following steps: 235 1. Concatenate the timestamp with the MAC address, collision count, 236 algorithm type and the global (public) IP address. (see figure 1) 238 +---------+-----------+---------------+--------------+ 239 |timestamp|Mac address|Collision Count|Algorithm type| 240 | 8 bytes | 6 bytes | 3 bits | 1 byte | 241 +---------------------+---------------+--------------+ 242 |Global IP address | Other Options | 243 | 16 bytes | variable | 244 +---------------------+---------------+ 245 Figure 1 SSAS Signature format 246 2. Sign the resulting value from step 1, using the ECC private key 247 (or any other short key size algorithm), and call the resulting 248 output the SSAS signature. 250 If NDP messages contain other data that must be protected, such as 251 important routing information, then this data SHOULD also be included 252 in the signature. The signature is designed for the inclusion of any 253 data needing protection. If there is no data that needs protection, 254 then the signature will only contain the timestamp, MAC address, 255 Collision count and Global IP address (Router subnet prefix plus 256 IID). 258 3.1.2. Generation of NDP/SeND Messages 260 After a node generates its IP address, it should then process 261 Duplicate Address Detection in order to avoid address collisions in 262 the network. In order to do this the node needs to generate a 263 Neighbor Solicitation (NS) message. The SSAS signature is added to 264 the ICMPv6 options of NS messages. The SSAS signature data field is 265 an extended version of the standard format of the RSA signature 266 option of SeND [RFC3971]. The timestamp option is the same as that 267 used with SeND. In the SSAS signature, the data field contains the 268 following items: type, length, reserved, Other Len, algorithm type, 269 collision count, subnet prefix, other option and padding. 271 3.1.2.1. SSAS signature data field 273 +------+-------+------------+---------+ 274 | Type |Length | Reserved |Other len| 275 |1 byte|1 byte | 2 bytes | 1 byte | 276 +----------+---------+------+---------+ 277 | Algorithm|Collision|Subnet| Other | 278 | type | count |prefix|Options | 279 | 1 byte | 3 bits |8bytes| | 280 +-------------------------------------+ 281 |Hash | Response| | 282 |Function | No. | SSAS Signature | 283 | 1 byte | 2 byte | | 284 +-------------------------------------+ 285 | padding | 286 +-------------------------------------+ 287 Figure 2 NDP Message Format with SSAS Signature Data Field 288 - Type: This option is set to 15. This is the sequential number used 289 in SeND to indicate a SSAS data field. 291 - Length: The length of the Signature Data field, including the Type, 292 Length, Reserved, Algorithm type, Signature and padding, must be a 293 multiple of eight. 295 - Reserved: A 2 byte field reserved for future use. The value must be 296 initialized to zero by the sender and should be ignored by the 297 receiver. 299 - Other Len: The length of other options in multiples of eight. The 300 length of this field is 1 byte. 302 - Algorithm type: The algorithm used to generate key pairs and sign 303 the message. The length of this field is 1 byte. For ECC, this value 304 is 0. Future algorithms will start at one and increase from there. 306 - Collision count: When a collision occurs during the DAD, the node 307 will increment this value and store it in a file to be included in 308 the sent packets for as long as the current IP address is valid. This 309 value indicates to the node where it needs to start its check from, 310 i.e., the first or second or third 64 bytes from the start of the 311 hash value (digest) array of the public key. 313 - Subnet Prefix: This is the router subnet prefix. 315 - Hash Function: A hash function used to generate IID. The length of 316 this field is 1 byte. For SHA256, this value is 0. Future algorithms 317 will start at one and increase from there. 319 - Response No: This is similar to nonce but by the use of different 320 mechanism. This value is not random and it is a copy of timestamp. In 321 sender?s message, this value MUST be set to zero and in response 322 message (sent from a receiver node), this value MUST be set to the 323 timestamp of the sender?s message. The length of this field is 2 324 bytes. The sender node should cache this value in order to compare it 325 with all responses sent by other nodes. This informs the sender node 326 that the message is the response to his message and protects the node 327 against replay attack. 329 - Other Options. This variable-length field contains important data 330 that needs to be protected in the packet. The padding is used to 331 insure that the field is a multiple of eight in length. 333 - Padding. A variable-length field containing padding to insure that 334 the entire signature field is a multiple of eight in length. It thus 335 contains the number of blanks needed to make the entire signature 336 field end on a multiple of eight. 338 All NDP messages (except RS messages) SHOULD contain the SSAS 339 signature data field which allows receivers to verify senders. If a 340 node receives a solicited NA message in response to its NS message 341 showing that another node claims to own this address, then, after a 342 successful verification process, this node increments the collision 343 count by one and this value is used as explained in the "Collision 344 count" item above. It will start from that section of the public key 345 for the generation of a new IP address. The node repeats this 3 times 346 and after 3 times generates a new public/private keys. Since the 347 likelihood of two nodes having the same value is 1/(2^63). This is 348 really a small value while we also considered the order of magnitude 349 relative to roughly 2 power 64 against sloppy implementations. 351 3.1.3. SSAS verification process 353 A node's verification process should start when it receives NDP 354 messages. Following are the steps used in the verification process: 356 1. Obtain Response No from the sender?s packet. Compare this value 357 with its own timestamp that used in its previous message. If it is 358 the same go to the next step, otherwise discard the message. (If SSAS 359 is a part of SeND, this step should be skipped.) 361 2. Obtain prefix information from its own cache or from a router 362 advertisement to make sure about the prefix sizes and number of bits 363 used for IID. 365 3. Obtain the timestamp from the NDP message and call this value t1. 367 4. Obtain the timestamp from the node's system, convert it to UTC, 368 and call this value t2. 370 5. If (t2- x) < = t1 < = (t2 + x) go to step 6. Otherwise, the 371 message SHOULD be discarded without further processing. The value of 372 x is dependent on network delays and network policy. The default 373 value would be the value of Round Trip Time (RTT). The 374 implementations SHOULD allow to set different values. 376 6. Obtain the public key from its own neighboring cache. If no 377 matches are found in the node cache and if there is a centralized 378 RPKI model available in the local network, then the node MIGHT obtain 379 this public key from that node. Otherwise go to the next step. 381 7. Compare this to its own public key. If it is not the same, go to 382 the next step. Otherwise, the message should be discarded without 383 further processing. (This step should be skipped when the node uses 384 the RPKI to obtain the other nodes' public key.) 386 8. Obtain the hash algorithm from the packet. By default it is 387 SHA256. 389 9. Execute hash function on the public key. Takes 64bits, depends on 390 collision count, from the hash function. Compare this value with the 391 node's IID source IP. If it is the same, go to the next step. 392 Otherwise, discard the message without further processing. 394 10. Concatenate the timestamp with the MAC address, algorithm type, 395 collision count, sender's Global IP address (subnet prefix and IID), 396 and other options (if any) and call this entity the plain message. 398 11. Obtain the SSAS signature from the SSAS signature data field. 399 Obtain the Algorithm type from the message. 401 12. Verify the Signature using the public key and then enter the 402 plain message and the SSAS signature as an input to the verification 403 function. If the verification process is successful, process the 404 message. Otherwise, the message should be discarded without further 405 processing. 407 After a successful verification, the node SHOULD store the public key 408 and MAC address of the sender node in its neighboring cache. By 409 default, the cache is valid for two days but the implementation 410 SHOULD consider a way to let the end users change this default value. 412 3.2. Resource Public key Infrastructure (RPKI) 414 To Authorize the Routers in the network and increase the security of 415 the nodes in this network, it is recommended to use an RPKI explained 416 in RFC 6494 and 6495. It is explained in more detail in 417 [SSASAnalysis] and local security deployment [localSecurity]. 419 4. SSAS Applications 421 4.1. A solution for all nodes 423 SSAS is capable to be used in standard nodes (standard computers) and 424 nodes where limited computational resources are available. One 425 example is the use of SSAS in sensor networks. Sensor networks are a 426 prime example of nodes with limited resources (such as battery, CPU, 427 and etc); see RFC 4919 [RFC4919] for use in IPv6 networks. Because 428 currently, as explained in section 4. RFC 6775, the generation of the 429 IID is based on EUI-64 which makes these nodes vulnerable to privacy 430 and security attacks. One of these types of attack can occur during 431 the Duplicate Address Detection (DAD) process. 433 4.2. Authentication in Network layer 435 Another example for the use of SSAS would be in mobile networks 436 during the generation of IP addresses, as explained in section 4.4 437 RFC 6275 [RFC6275]. The current problem with the addressing mechanism 438 in a mobile node is that no privacy is observed when a node moves to 439 another network while usually keeping its Home Address. If there were 440 a fast and secure mechanism available, then it would be possible to 441 set this Home Address and change it and re-register it to the Home 442 network. Another possible use for SSAS in mobile nodes could be as a 443 security mechanism during the configuration of Care of Address (CoA); 444 see section 3. RFC 5213 [RFC5213]. In that RFC, home proxy plays the 445 role of a home agent for mobile nodes and mobile nodes set their CoA 446 by the use of either stateful or stateless autoconfiguration. 447 Currently they MUST use IPsec in order to secure this process. 448 Section 4 of that RFC discusses the possibility of using another 449 algorithm in order to secure mobile nodes. 451 4.3. Authentication in Application Layer 453 SSAS can be used as a means of authentication for the nodes in 454 application layer. It is really important that the nodes know who 455 they are talking to. This is because a user uses an application to 456 connect to another node on the internet. This application either uses 457 a domain name of the destination node (that later translates to the 458 IP addresses) or directly uses the IP address of this node. This is 459 where the attacker can play a role and spoof this IP address and play 460 a MITM attack or other types of attacks. If the node uses this 461 approach, the attacker does not have a possibility to spoof the IP 462 address of the communicating node. So, this approach can mitigate IP 463 spoofing during the authentication of two nodes in application layer. 465 4.4. Other Applications 467 With the wide usage of IP addresses in different types of devices and 468 by the use of autoconfiguration mechanisms to configure these IP 469 addresses, the need for the use of a security algorithm is increased. 470 One type of application would be for use in vehicular networks or in 471 the car-to-car networks. There is currently some work in progress 472 that makes use of Neighbor Discovery. SSAS could also be a solution 473 for enabling fast protection against ND attacks. 475 5. Security Considerations 477 There are two security considerations: 479 Since SSAS cannot prevent the layer 2 attacks but can mitigate it 480 after the first verification, therefore one would need to use a 481 monitoring device to prevent MAC spoofing. The other possibility is 482 to have a dynamic MAC address. This means the SSAS node can use the 483 48 rightmost bits of the its public key as a MAC address. In this 484 case there is a binding between the IP address, MAC address and 485 public key. Since the verification process would have failed, it 486 cannot be spoofed. However, this approach might be problematic from 487 an operational view and might need to have some consideration before 488 being used. 490 Another security consideration is how to attack SSAS. One might ask 491 oneself that what are the odds of an attacker being able to generate 492 a public key having two four sequential bytes (from two different 493 halves of public key) that are the same as 64 bits of that in 494 Interface ID? If he could, he could then generate the signature using 495 his own private key and thus break SSAS. Mathematically it has been 496 shown that the likelihood of matching 64 bits in the public key 497 against 64bits in the IID is 1/(2^64). in [SSASAnalysis] the analysis 498 of SSAS is explained and compared to CGA. Since the nodes in the 499 network need to keep the public key and the MAC address of other 500 nodes in the cache, the attacker only has a few seconds to perform 501 this attack and then the attacker needs to perform this attack 502 against the whole public key. For CGA, this value is less. in 503 [cgaattack], the attack in CGA was explained. So, in general, SSAS is 504 faster and in a good security level. In other word, SSAS tried to 505 address the security and performance problem exists in CGA and offer 506 a fastest algorithm. 508 6. IANA Considerations 510 There is no IANA consideration 512 7. Privacy Consideration 514 When an attacker is inside a local link, he is enable to identify a 515 node. although, this target node changes its IP address. The reason 516 is because the target node does not change its MAC address. However, 517 if the public key needs to be used for verification in other 518 mechanisms and not in local link, then it is RECOMMENDED that the 519 public/private keys to be valid for a short period of time. The 520 default value would be a week. The implementations need to consider 521 the automatic key generation to avoid administrative requirements for 522 this process. 524 8. Appendix A 526 8.1. Comparison of CGA and SSAS generation time 528 The following information was retrieved from [cgatime]. It shows the 529 time required to generate CGA in different sec value. This is why, in 530 practice, only sec value 0 and 1 can be used. 532 sec value 1 => ~ 1 second 533 sec value 2 => ~ 3 hours 535 sec value 3 => ~ 24 years 537 sec value 4 => ~ 1.16*10^6 years 539 sec value 5 => ~ 1*10^11 years 541 sec value 6 => ~ 6.8*10^15 years 543 The above information is based on the fact that one uses RSA key 544 sizes less than 1280 bits. If one needs to use the higher security, 545 then it needs more time for the generation of CGA value. Using RSA 546 higher key sizes also increases the packet size needs to carry the 547 public key. Here is our evaluation of ECC and RSA key generation time 548 in a standard computer with 2.6 GHz CPU. 550 SSAS generation time is about the time needed to generate key pairs. 551 Since, by default, SSAS uses ECC 192 bits, the following values 552 compares ECC with RSA. RSA is the algorithm uses in CGA. As explained 553 earlier, the security of ECC 192 bits is equivalent to the security 554 of RSA 7680 bits. 556 ECC 192 bits: Average key generation time = 195011 microseconds 558 RSA 1280 bits: Average key generation time = 681039 microseconds 560 RSA 7680 bits: Average key generation time = 163473350 microseconds 562 9. Appendix B 564 9.1. Network-based protection vs. Node-based protection 566 Node-based protection is the ability of the node to protect against 567 some types of attacks such as IP spoofing, MITM attack. On the other 568 hand, network-based protection is the use of some devices in the 569 network edges to protect the nodes inside this network against router 570 advertisement spoofing attacks or other types of attack. Both of 571 these protection is required and both can complement each other. This 572 is because the attacker might be inside the network and play a role 573 of MITM, spoof the other nodes' IP address, prevent other nodes from 574 configuring their IP address and cause many delays and problems in 575 the local network (Not all the nodes in the network is ever trustee). 576 One important consideration about node-based protection is that, it 577 should support any node and apply to any nodes (Including nodes with 578 limited energy resources or limited memory resources). This is why 579 there is a need for a good mechanism to provide this protection with 580 less cost. The proposed mechanism in this document, i.e., SSAS can 581 provide the node with node-based protection. With only node-based 582 protection, the malicious node inside this network can claim to be a 583 router and the node does not have any means to authorize him. This is 584 why, the network-based protection is also the complement solution to 585 a node-based protection. There are some approaches to provide the 586 node with network-based protection. One such approach might be 587 RA-gaurd [RAgaurd]] which limits subnet prefixes. Unfortunately with 588 this approach, still the node inside this network can maliciously 589 claim to be a router and play the MITM attack inside the network by 590 sending unicast router advertisement messages. So, the attack is 591 still possible. The other approach is the use of RPKI as explained in 592 RFC 6494 and RFC 6495. Unfortunately these RFCs only explain the 593 possibility of using them but not the detail of implementation. The 594 detail implementation is explained in [SSASAnalysis]. The local RPKI 595 node also can play a role of monitoring device in the network. 597 10. Acknowledgements 599 The Authors would like to acknowledge Erik Nordmard and Joel M. 600 Halpern for their supports and assistance to improve this 601 document.The authors also would like to acknowledge Michael 602 Richardson, Dan Wing, Tim Chown, Christian Huitema, Joel M. Halpern 603 for their comments to improve this document 605 11. References 607 11.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to 610 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC4291] Hinden, R., Deering, S., "IP Version 6 Addressing 613 Architecture," RFC 4291, February 2006. 615 [RFC3972] Aura, T., "Cryptographically Generated Addresses 616 (CGA)", RFC 3972, March 2005. 618 [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy 619 Extensions for Stateless Address Autoconfiguration in 620 IPv6", RFC 4941, September 2007. 622 [RFC3971] Arkko, J., Kempf, J., Zill, B., and Nikander, P., 623 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 625 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., 626 Perkins, C., Carney, M. , " Dynamic Host Configuration 627 Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 629 [RFC3756] Nikander, P., Kempf, J., Nordmark, E., "IPv6 630 Neighbor Discovery (ND) Trust Models and Threats", RFC 631 3972, May 2004. 633 [RFC4919] Kushalnagar, N., Montenegro, G., Schumacher, C.," 634 IPv6 over Low-Power Wireless Personal Area Networks 635 (6LoWPANs): Overview, Assumptions, Problem Statement, and 636 Goals", RFC 4919, August 2007. 638 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., 639 Bormann, C. , " Neighbor Discovery Optimization for IPv6 640 over Low-Power Wireless Personal Area Networks (6LoWPANs)", 641 RFC 6775, November 2012. 643 [RFC6275] Perkins, C., Johnson, D., Arkko, J., "Mobility 644 Support in IPv6", RFC 6275, July 2011. 646 [RFC6543] Gundavell, S., "Reserved IPv6 Interface 647 Identifier for Proxy Mobile IPv6", RFC 6543, May 2012. 649 [RFC6090] McGrew, D., Igoe, K., Salter, M., "Fundamental 650 Elliptic Curve Cryptography Algorithms", RFC 6090, February 651 2012. 653 [RFC3756] Nikander, F., Kempf, J., Nordmark, E., "IPv6 654 Neighbor Discovery (ND) Trust Models and Threats", RFC 655 3756, May 2004. 657 [RFC7136] Carpenter, B., Jiang, S.,"Significance of IPv6 658 Interface Identifiers", RFC 7136, 2013 660 11.2. Informative References 662 [SSASAnalysis] Rafiee, H., Meinel, C., "'SSAS: a 663 Simple Secure Addressing Scheme for IPv6 664 AutoConfiguration". In Proceedings of the 11th IEEE 665 International conference on Privacy, Security and 666 Trust (PST), IEEE Catalog number: CFP1304F-ART, ISBN: 667 978-1-4673-5839-2. 669 [cgaattack] Rafiee,H., Meinel, C., "Possible Attack on 670 Cryptographically Generated Addresses (CGA)" 671 ,http://tools.ietf.org/html/draft-rafiee-6man-cga-attack, 672 2014 674 [RAgaurd] Gont, F., "Implementation Advice for IPv6 Router 675 Advertisement Guard (RA-Guard)", 676 http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation, 677 2012 679 [localSecurity] Rafiee,H., Meinel, C., 680 "Recommendations for Local Security Deployments" 681 ,http://tools.ietf.org/html/draft-rafiee-6man-local-security, 682 2013 684 [cgatime] Bos, J., Oezen, O., Hubaux, J., "Analysis and 685 Optimization of Cryptographically Generated Addresses", In 686 Proceedings of the 12th International conference on 687 Information Security (2009), ACM, pp. 17 ? 32. 689 [variableprefix] Carpenter, B., Chown, T, Gont, F., 690 Jiang, S., Petrescu, A., Yourtchenko, A.," Analysis 691 of the 64-bit Boundary in IPv6 Addressing", 692 http://tools.ietf.org/html/draft-ietf-6man-why64 , 693 April 2014 695 [cgabis] Rafiee,H., Zhang, D., "CGA Security Improvement" 696 ,http://tools.ietf.org/html/draft-rafiee-rfc3972-bis, 2014 698 Authors' Addresses 700 Hosnieh Rafiee 701 HUAWEI TECHNOLOGIES Duesseldorf GmbH 702 Riesstrasse 25, 80992, 703 Munich, Germany 704 Phone: +49 (0)162 204 74 58 705 Email: hosnieh.rafiee@huawei.com 707 Christoph Meinel 708 Hasso-Plattner-Institute 709 Prof.-Dr.-Helmert-Str. 2-3 710 Potsdam, Germany 711 Email: meinel@hpi.uni-potsdam.de