Pekka Nikander wrote: > ... > > the proposed bit cleared. THE BIT PROVIDES NO VALUE TO THIS PROCESS. > > Here I have to *strongly* disagree. > > The "bit" is one method for providing protection against the > bidding down attack. It effectively creates two IP address spaces, > those for which the receiver *requires* CGA, and those for which it > does not.
The point we are violently disagreeing on here is only the value of using a distinct address format as the flag. The receiving application either requires a CGA address for validation or it doesn't. There is no inbetween here. If the receiver requires CGA for validation and does not have a matching PK, the connection will be rejected. > > If we do *not* do this distinction, a Man-in-the-Middle can claim, > for *any* IP address, that CGA (or something similar) is not used. > That reduces the security of all addresses to the same base line, > effectively creating a situation where CGA (or similar) does not > provide any additional value at all. Ergo, *something* that divides > the IP address set into two distinct sets *is* needed, or otherwise > CGA and related methods bring no additional value. The man-in-the-middle can't do anything if there are no bits to manipulate. Either the reciever has a matching PK or it doesn't. All it has to do is check, and there is nothing that an attacker can do to invalidate the process. > > If everybody agrees that CGA (and any security that is *not* based > on an external infrastructure but on "intrinsic cryptography") > is a bad idea, then fine with me. Let's forget this discussion. > But then we are effectively saying that zero-configuration security > is a bad idea and we don't want it. I am not saying that CGA is a bad idea. On the contrary it is a great idea. All I am pointing out is that we don't need anything more than RFC3041 to accomplish it. > > Thus, this all is really about zero-configuration security. Such > security, by nature, is never "strong" by the strict definition of > strong, but it can be *much* stronger than the current no-security > situation. Basically, such security can provide quite a lot of > defence against various DoS attacks. > > This two-address-space thing is only required for those recipients > that support both the current nodes with no understanding about > zero-conf security and the future nodes that do care about zero-conf > security. As I noted before, it requires that the initiator commits > a priori either to the "weak" method or the "strong" method. I am sorry, but this is misguided. Current nodes will never care about CGA, so they won't try to verify them. New nodes can verify the addresses, so they know the originator either cared because the CGA matched, or didn't care or was incapable of generating a CGA. In either case it has the appropriate info to decide to accept or reject. > > The details differ, quite a lot in fact, depending on whether > we speak about MIPv6 or something else, e.g. secure Neighbor > Discovery. > But the same need: dividing the address space into two distinct sets, > is there. Or at least that is my current understanding. Maybe I am > wrong. > > Personally, I do not believe that any bold statements help here. > At least to me, this whole zero-conf security business is so new > that at least I need to have very humble attitude here. I learn > new issues all the time. On the other hand, IMHO we really want > to go towards zero-conf security. And if we do, we need some kind > of transition mechanism. Dividing the IPv6 address space seems to > serve as an important piece of such a transition mechanisms. > > Of course, there are different ways of dividing the IPv6 address > space. If everybody thinks that using a bit in the IID is a bad > idea, then maybe we should consider distinct routing prefixes for > mobile hosts, and distinct link local addresses for secure ND. All that is doing is asking for a set of bits. Bits are not the problem here. The receiver has to check for CGA validation if it cares, so adding bits does not help. Tony > > --Pekka > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
