Christian Huitema <huit...@microsoft.com> 写于 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: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; '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: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.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 > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
