B.G. Bruce wrote:
Mike,
Thanks for your input, it helped a lot, as did getting a box up and
actually running it. I think I have a better grasp of what it does, and
how it does it (for the basics). I guess at first I was hoping it would
be more like one large virtual switch with solid VLAN capabilities. I
see now that it is more like a normal bridge internally, but like having
one or more switches with IPSEC/*S/wan controlling your physical nics.
Actually I'd say the vnet internals are more like a VLAN switch - they
route packets to vnet interfaces by vnet id. Vnet packets on the wire
are labeled with vnet id just as VLAN packets are labeled with
vlan id. Vnet packets coming off the wire are unwrapped and
switched to the relevant vnet interface based on their vnet id.
It's just the connection of virtual interfaces to the vnet ports
that uses bridging. I believe linux VLAN support does something similar -
each VLAN appears as a virtual network interface.
Some new questions: (I can hear the <groan> from here) :-)
1) for auth and conf security, how is keying handled?
I use IPSEC ESP for the message transform, and at the moment
the key and cipher suite are hard-coded.
I can hear the <groan> about that from here too!
The idea is to hook onto kernel IPSEC and its interface
to the IKE key daemon to do this properly. Ideally I'd
also like to remove my own version of the ESP transform
and use the kernel IPSEC one. I only use my own transform
because originally this code worked in xen 1.0, when it
was inside the xen kernel and there was therefore no access
to linux kernel IPSEC (and xen was still using 2.4 which
didn't have it anyway).
The wrinkles are
1) kernel IPSEC has a security association DB (SADB) that is
driven off remote IP and protocol - and ideally
I'd like security to be a function of vnet id too.
2) vnets use multicast, and IKE negotiates keys point-to-point.
We might be able to statically key an SA for multicast,
or go to some server to get the multicast key.
2) how do you set this up other than defining the security model?
At the moment the only security modes are: none, auth, conf.
Mode none has no security, auth uses HMAC and conf uses ESP+HMAC,
cipher is AES-CBC-128 and keys are hard-coded.
If IPSEC was set up properly the idea would be that the keys
and cipher suite would be set by the IPSEC key daemon, and the
vnet stuff would just check that the relevant security level was being used.
It also might be possible to convince kernel IPSEC to
apply some security policy - but only at the granularity of
IP addr and protocol, not individual vnet id.
3) How can you differentiate between a valid second xend host that is
running vnets, and a rogue xend box (unlikely at this time, but ...)
that got lucky in guessing your vnetid, and security setting.
Because we're using hard-coded keys, we can't.
If we used IPSEC properly that would fix the problem:
either the other host has the same static SA (and knows the shared secret),
or we use IKE to negotiate the SA and use certificates.
If you use vnets with no security there's no way to stop spoofing.
Regards,
Mike
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
| 
Home