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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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-develMike ------------------------------------------------------- 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, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Felipe Alfaro Solana
2005-Feb-11 23:31 UTC
Re: [Xen-devel] Other additional vnet questions
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel