Hosnieh, You should probably split your proposal in two parts: the proposal to replace CGA by just checking an extract of the address; and potential improvements to SEND that are independent of whether we use CGA or your direct comparison alternative.
Your replacement of CGA works by copying some bits of the public key in the IID field, instead of using bits from a hash function. I think this is a really bad idea, since the number of bits that you can copy is limited. Your initial design copied just 48 bits; you could change that to 56 bits or maybe 62 bits in an improved design. Cracking the 48 bit version is trivial. Cracking the 62 bit version will take longer, but with Moore's law there will come a point in the future where this too will be easy to crack. In contrast, CGA implementations can simply in the future increment the SEC value for added robustness. Your draft is making other contributions, such as added verification steps, or caching o results to prevent DOS attacks. These contributions could be used to improve SEND. It would be better to separate them from the debate about hash functions. -- Christian -----Original Message----- From: Hosnieh Rafiee [mailto:i...@rozanak.com] Sent: Thursday, March 21, 2013 4:08 PM To: 'Jari Arkko' Cc: '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 - I-D action : draft-rafiee-6man-ssas 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 --------------------------------------------------------------------
