Jari, > What changes from RFC 3972 to your draft in this high-level analysis?
The difference between my draft and that of RFC 3972 is that I make use of the public key in the IP address directly. Doing it the way I have explained in my draft eliminates the need for the use of those SHAx steps because I believe the use of those steps does not lend itself to improved security. My reason for this opinion is that RFC 3972 can only prevent DAD attacks and not the other types of attacks. This attack can also be prevented by using CGA if we add this extra verification step (that of the node checking the public key of the sender to his own), otherwise RPKI would be used. This is the same procedure as outlined in my draft. So the security of both depends on the security of the public/ private keys. After a successful verification (which could have resulted from a fast relay attack) the attacker's link-layer address is included in a cache as a legitimate address, and if routing is based on the link-layer address, then the node has no way of knowing that it was just a replay attack. Otherwise, the use of RPKI, where the node that has this IP address/or link layer is specified, would contain this public key. This is why, in this case, the keys' security is very important. Thanks, Hosnieh -----Original Message----- From: Jari Arkko [mailto:jari.ar...@piuha.net] Sent: Thursday, March 21, 2013 10:56 PM To: Hosnieh Rafiee Cc: 'Jari Arkko'; 'Santosh Chokhani'; ipv6@ietf.org; s...@ietf.org; 'Ray Hunter'; 'Christian Huitema'; Erik Nordmark; zhou.suj...@zte.com.cn; 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hosnieh, > What is it that you don't understand. I will be happy to explain it to you. Thanks. I read the details, but I'm missing the big picture. I.e., some effort is required from the owner to create an address. By repeating that effort (2^59)/2 times, someone else is likely to hit the same key with a key pair that he or she controls, and an attack can be launched. What changes from RFC 3972 to your draft in this high-level analysis? > There has been no resolution to the topic of the thread. Ok. Well that clarifies at least the state of the discussion. Thanks. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
