[occi-wg] Instance runtime API

Michael Richardson mcr at sandelman.ca
Wed Apr 22 15:31:34 CDT 2009


>>>>> "Randy" == Randy Bias <randyb at gogrid.com> writes:
    Randy> Will have to be MAC.  URL example is fine.  Passing MAC up
    Randy> from networking stack will be painful requiring a custom
    Randy> low-level listener.  Implementation will be susceptible to
    Randy> hacking if providers do not enforce MAC addresses at
    Randy> switch/vswitch ports.

  I partly agree.
  An intermediate hack of dubious security is to do it all over IPv6,
using autoconfigured (fe80:: or other) addresses... they naturally have
the MAC built-in, and you don't have to be so concerned about
overlapping IPs in the different private parts of the cloud....
  Now you just need a filter that checks layer-2 MAC == layer-3 source
IP, and the application way up can just check layer-3.

    Randy> Alternative is to say that Œmachine-id¹ is always deposited
    Randy> in / or C:\ and has UUID.

  That's even more problematic, I think.

  VMware's instances have these guest variables accessible via the
VMware tools utilities, and you can stick a uuid in there (and vmware
already does that).   

  However, I'd like to see this part standardized, perhaps through
either DMI or ACPI. 

  There are other larger bits I'd like to be able to pass in that way,
such as a kerberos ticket, or an IPsec private key that would permit a
diskless host to NFSv4 mount it's /. 

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [



More information about the occi-wg mailing list