Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas

["Sujing Zhou"<[e-mail]>]

Christian Huitema <[e-mail]> 写于 2013-03-22 07:56:20:

> 
> 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.
What is the pointing of adding sec since the ratio of effor required by 
attacker and user is always 2^59, as Jari argued.


> 
> 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:[e-mail]] 
> Sent: Thursday, March 21, 2013 4:08 PM
> To: 'Jari Arkko'
> Cc: 'Santosh Chokhani'; [e-mail]; [e-mail]; 'Ray Hunter'; 
> Christian Huitema; 'Erik Nordmark'; [e-mail]; 
'JeffreyHutzelman'
> 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:[e-mail]]
> Sent: Thursday, March 21, 2013 10:56 PM
> To: Hosnieh Rafiee
> Cc: 'Jari Arkko'; 'Santosh Chokhani'; [e-mail]; [e-mail]; 
> 'Ray Hunter'; 'Christian Huitema'; Erik Nordmark; zhou.sujing@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
> 
>