Tony, Brian, and others, Sorry about this volume, but let me try to simplify once more. I am now shifting quite far away from the immediate need, MIPv6, whose issues *may*, perhaps, be solved otherwise, and argue more for the other thing, Secure ND, and other related zero-conf security protocols.
---------------- Firstly, assume that there is no external infrastructure that we may rely on. That is, we are playing zero-conf game. Now, what we want to do is to create two playgrounds: 1. The current non-secure playground 2. A new zero-conf-secure playground We can make these completely distinct. The nodes (childs?) in the new playground only communicate there, and the nodes in the current one only here. In this case there is no problem the "zero-conf nodes" refuse to talk to the "non-secure nodes", and that's it. What we want to achieve, though, is a situation where the zero-conf nodes can also talk to the non-secure nodes. If a zero-conf node initiates the communication, this is probably not a problem, since it needs to look up some properties of the recipient anyway, and these properties can include credentials that identify the recipient as a zero-conf node. (Maybe these credentials can also be secured with a zero-conf method, and if so, naming seems to *help* there, too. But it certainly does not solve all problems.) The problematic case is when some stranger contacts a zero-conf node. It must be able to tell if that new node is a zero-conf node or a non-secure node. And this becomes tricky due to the possibility of man-in-the-middle and masquerade attacks. Relying on looking up credentials each and every time is one possibility. But that is inefficient; large servers are unlikely to do that. Naming the nodes in the playgrounds differently, as suggested, seems to provide *some* help. It is definitely not a panacea, MitM and masquarading attacks can still play *some* nasty games. However, the cannot "steal" zero-conf addresses, because zero-conf addresses are explicitly named as zero-conf addresses and because the attackers cannot provide the cryptographic credentials required from zero-conf addresses. (The latter is an intrinsic property that defines zero-conf security addresses.) ---------------- Maybe that approaches the essense of the issue. The issue was initially about MIPv6 RR vs. other MIPv6 security methods. However, the issue seems to be more and more shifting towards this zero-conf (secure ND) vs. current situation issue. Or so at least in my mind, I don't know about others. I hope that this helps, or that it at least leads us to collectively learn something. --Pekka Nikander -------------------------------------------------------------------- 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] --------------------------------------------------------------------
