For now, let's assume that Bob is told A but Bob doesn't know if who sent it to him is on the level. I.e. he doesn't know if A is correct and he doesn't know if A has been modified by a third party en-route.
Bob also doesn't know if someone between the topologically correct routing infrastructure of A has been compromised either. For instance, someone on A's true network is pretending to be the mobile's HA or just snooping. I guess another scenario is someone on Bob's network is pretending to be a router along the path or snooping, etc.. i.e. any MITM.
There is another case of MITM where two nodes could be in collusion, posing as A and its home network, as well, but they have pretty much given up on that as the same affects could occur for non mobile nodes, already, if the routing infrastructure was somehow compromised.
They are also concerned about DDoS attack such as pounding the CN with such requests to generate public keys etc.. for this SA establishment process. The "keep it simple" approach is simply RR, return routability i.e. trust that there is no MiTM. But it doesn't protect as well against some MITM attacks and so this has been labeled as weak vs. strong.
Note that A would also benefit from knowing that he actually contacted Bob and someone wasn't impersonating Bob due to a MITM situation.
Overall, I find this amusing as they are both not bullet proof against MITM due to existing security holes in IP itself - not that the fixes would be acceptable as anything more than a BCP. So a few folks are pushing a "better" encumbered solution with the hopes that at least this BCP for IP holes will be created as well at some point to close the other holes.
Then we have the credentials and infrastructure proponents i.e. trust an application trust network, AAA; however, this simply transfers the MITM problem to another route and everyone keeps arguing about just what the AAA is or should be.
Then we have to "trust the routers themselves proponents" that assume that the routers close to A both in A's home network and in the visited network somehow know that A is doing the right thing. But this would involve these routers being involved in the signaling and require some sort of infrastructureless and scalable edge to edge SAs. This relies on a great deal of trust for these route updates as you mention but it really would rely on the same trust that the networks are built with today. The ways to set up and cache these SAs without more infrastructure is a contentious issue that results in a battle between the people who make servers vs. people who make routers. Much of the same arguments against RSVP are used to thwart such concepts. Also with Monet and Manet, the question of trusting routers is being portrayed as unprofitable and not necessarily trustworthy. We are also a long way away from this IMHO. The infrstucture solution investors would fight such a thing tooth and nail.
Then we have the let's do something completely different folks i.e. the Per-host DNS with no caching, IIP, 8+8ers and HIPpies - not that I would want to stop any research on these topics. I still think we are just getting started on this Internet thing.
I have a sneaking suspicion that equivalent strong security mechanisms exist and are comparable end to end - "better" solutions yet do not require these interface changes; however, this may seem to be a rather non-productive task to some for something that is optional anyway. I suspect that these solutions might be encumbered as well and these folks don't really want to try to impose some sort of encumbered solution in the IETF.
Keep in mind that for the solution to be effective it should also have hooks to work with infrastructure-based solutions as well. This is the "the key generation operations can be offloaded" statements you might run into when scanning mail archives or related documentation.
Anyway, this might end up to be the same state of affairs with IP-based VPN security technology with different vendors having different solutions and variants of the ESP protection etc.. Seems like some sort of broken history record.
Then again, people might just say that RR is fine given the weaknesses of IP already and that the infrastructure solutions can be used if you want something stronger. This would be passing the buck to the AAA war, though. I.e. deployment would still be a major issue.
Thanks for trying to understand the variables of the problem set - both technical and business oriented. I hope this pretty much sums up the conundrum for all. I think it serves to put this concept of reserving an interface bit in perspective - not the mention issues within the whole IETF.
Glenn
> -----Original Message-----
> From: gabriel montenegro [mailto:[EMAIL PROTECTED]]
>
> So the trick is to convince Bob to insert into its route
> table a host route entry for
> A at some_address. If Bob doesn't know A, I think we're
> talking about a very
> different problem. What are you asking Bob to insert into its
> routing table?
>
> -gabriel
>
>
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
