Other additional vnet questions

Other additional vnet questions

[B.G. Bruce]

Some other questions I have about vnets.

1)	Can one vif belong to more than one vnet at the same time?
2)	Can you run more than one vnet on the same bridge?

ex. bridge=mgmt
	vnetid=1 mac=aa:00:00:00:00:01
	vnetid=2 mac=aa:00:00:00:00:01

	vnetid=1 mac=aa:00:00:00:00:02
	vnetid=3 mac=aa:00:00:00:00:02

	vnetid=1 mac=aa:00:00:00:00:03

	vnetid=3 mac=aa:00:00:00:00:04

domU1 mac=aa:00:00:00:00:01 bridge=mgmt

domU2 mac=aa:00:00:00:00:02 bridge=mgmt

domU3 mac=aa:00:00:00:00:03 bridge=mgmt

domU4 mac=aa:00:00:00:00:04 bridge=mgmt

all four hosts have an unique ip assigned from 192.168.1.0/24

domU1 can see domU2 and domU3
 
domU2 can see domU1 and domU4

dom3 can see domU1

dom4 can see domU2


Will this work?  I would try it out myself, but being that I can't
compile the code just yet, I thought I'd pick someone else's brain on
this while I work on the build issues.

B.


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

Re: Other additional vnet questions

[Mike Wray]

B.G. Bruce wrote:
> Some other questions I have about vnets.
> 
> 1)	Can one vif belong to more than one vnet at the same time?

Think of a vnet as a virtual lan.
Just as an interface can only be connected to one lan,
a virtual interface can only be connected to one vnet.

If you want a domain to have more than one vnet it needs
more than one virtual interface - just like you need
multiple real nics to have access to multiple lans.

> 2)	Can you run more than one vnet on the same bridge?

A vnet is implemented by a vnet interface that does the multipoint
tunneling for it. The vnet interface is connected to virtual
interfaces via a bridge. The idea is to have one bridge per vnet.
If you put more than one vnet interface on the same bridge
I'm not sure whether it would work or not. Not something I've tried.
If it did work it would be like bridging lans together via  hub.

> 
> ex. bridge=mgmt
> 	vnetid=1 mac=aa:00:00:00:00:01
> 	vnetid=2 mac=aa:00:00:00:00:01
> 
> 	vnetid=1 mac=aa:00:00:00:00:02
> 	vnetid=3 mac=aa:00:00:00:00:02
> 
> 	vnetid=1 mac=aa:00:00:00:00:03
> 
> 	vnetid=3 mac=aa:00:00:00:00:04
> 
> domU1 mac=aa:00:00:00:00:01 bridge=mgmt
> 
> domU2 mac=aa:00:00:00:00:02 bridge=mgmt
> 
> domU3 mac=aa:00:00:00:00:03 bridge=mgmt
> 
> domU4 mac=aa:00:00:00:00:04 bridge=mgmt
> 
> all four hosts have an unique ip assigned from 192.168.1.0/24
> 
> domU1 can see domU2 and domU3
>  
> domU2 can see domU1 and domU4
> 
> dom3 can see domU1
> 
> dom4 can see domU2
> 
> 
> Will this work?  I would try it out myself, but being that I can't
> compile the code just yet, I thought I'd pick someone else's brain on
> this while I work on the build issues.

Not as it stands - see above.

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

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

Re: Other additional vnet questions

[B.G. Bruce]

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.

Some new questions: (I can hear the <groan> from here)  :-)

1)	for auth and conf security, how is keying handled?  

2)	how do you set this up other than defining the security model?

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.

Regards,
Brian.




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

Re: Other additional vnet questions

[Mike Wray]

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

Re: Other additional vnet questions

[B.G. Bruce]

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

Re: Other additional vnet questions

[B.G. Bruce]

Mark,

I tracked down what's biting me .... it the static DEFINE for DEVICE set
to "xen-br0" in varp.c.  What exactly is the purpose of this?

Brian.


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

Re: Other additional vnet questions

[Felipe Alfaro Solana]

On Thu, 10 Feb 2005 13:21:30 +0000, Mike Wray <mike.wray@hpl.hp.com> wrote:
> 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!

You are fine using manually-keyed SA with IPSec, as long as you
remember to rekey soon enough to prevent the ESP counter to overflow.
For an IPSec ESP SA so be considered secure, the counter used in CTR
mode must never get reused and the keys used safely stored.


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