Open Stack

You have a fundamental misunderstanding of my fundamental understanding of how inter-zone communication works. :)  I understand how it works.  I'm asking about an admin API that has privileges for actions for all VMs.  As an ISP, I want to disable a particular VM because it's being 'bad'.  If someone has injected a collision, I would be sending an action to more than 1 VM, not only the intended target.  I don't see how collisions can be made to work at all.

And yes, we're talking about spoofing (or really, purposefully colliding a known UUID).  I haven't seen any mention to anything else (although I may have missed it).  I'm certainly really not worried about machine generated UUIDs colliding, myself.

But what we're also talking about here is efficient routing.  Is it necessary?  No.  Would it scale?  Yes.  A zone name or ID needs to be part of the identifier.  I prefer the DNS name idea, although prefixing UUIDs or reserving bits in a UUID could also work.

- Chris

On Mar 23, 2011, at 9:01 AM, Ed Leafe wrote:

> On Mar 23, 2011, at 11:28 AM, Chris Behrens wrote:
> 
>> How would the admin API know which ID to work with if there are collisions?  Eric's point is that we'd not know where to route the request.
> 
> 
> 	This reflects a fundamental misunderstanding of the way inter-zone communication works. There is no direct routing. Instead, a zone "knows" about its instances and its child zones. If the zone receives a request for some action involving a particular instance, it checks if it has that instance among its compute nodes; if not, it forwards the request to each of its child zones. That is repeated until the leaf zones are reached, and most of those will respond with something akin to a 404, indicating that they didn't handle the request. The zone that does have the requested instance, though, will carry out the action and return the result of that action.
> 
> 	The child zone responses are then aggregated. If all indicate 404, the zone returns the same. If one child responds that it has handled the request, that response is returned. This repeats back up the zone tree until the zone that originally received the request has heard from all of its child zones (or they timed out). 
> 
> 	If there were to be a collision (i.e., two leaf nodes handling the request), there are only two possibilities: either the authenticated user has rights to those nodes, or they do not. If they do not, nothing will happen beyond an authorization failure message. If they do have rights to both instances, then the action will happen to both instances. Since the context of this discussion is deliberate spoofing, my response would be "serves them right". :)
> 
> 	So it seems that spoofing should have no effect, assuming that our authentication/authorization system is sound. If it isn't, then we have bigger issues than just ID spoofing, since I could write a program to send API delete requests for random instance IDs - no spoofing required.
> 
> 	Without spoofing, let's be realistic: the chance of duplicate uuid values colliding is much, much smaller than the chance of a meteorite smashing into our data centers. From Wikipedia: "In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%". I believe that that is well beyond our scalability goals, so we can effectively ignore the impact of non-spoofed collisions.
> 
> 
> -- Ed Leafe
> 
> 
>