Re: Other additional vnet questions

["B.G. Bruce" <bgb@nt-nv.com>]

Mike,

GREAT INFO ... thank you very much.  Now for the problem that I have
encountered.  I can't reliably get the vnet_module to load.  About 1 in
30-50 tries works, the rest give [WRN] VNET err=-5.  I've removed all
the kernel IPSEC/IP xx tranform and VLAN options, tried with and without
tuntap, pf_keys, llc headers, and the encryption algorithms as both
modules and compiled into the kernel, but I still can't improve on the
reliability.  Is there anything I can send you or tell you that might
help nail this quickly?  Can you spare the time?  It started off great
for the first 4-5 hours, then I rebooted ... :-(

Brian.


On Thu, 2005-02-10 at 09:21, Mike Wray wrote:
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
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