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@xxxxxxxxxxxxxxxxxxxxx
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home