Thanks for clarifying what pwned is :-) The problem remains whether you run a hypervisor or a non-virtualized OS image that you control.
Trusting the hypervisor or any other entity - (including the switch or gateways - who programmed the switch dynamically?) - is an going to be an issue that needs to be addressed. BTW, why is a Linux based storage appliance e.g. (or running some other trusted application under the control of the same administrator) - more risky than a hypervisor? As I said, if you don't trust the OS (or the person loading the OS) or the application, it will likely be isolated physically or by VLAN and connect through gateways. > -----Original Message----- > From: Ivan Pepelnjak [mailto:[email protected]] > Sent: Tuesday, August 28, 2012 10:31 AM > To: Somesh Gupta > Cc: Stiliadis, Dimitrios (Dimitri); Black, David; [email protected]; Linda > Dunbar > Subject: Re: [nvo3] Let's refocus on real world > > So you think your server (in case #1 or #2) will never be pwned? Good > luck! > > On 8/28/12 7:27 PM, Somesh Gupta wrote: > > The trust boundaries will certainly be important. If a tenant is > > allowed to load their own OS on bare metal, it will probably be > outside > > the trust zone of the provider's overlay network. > > > > 1. Consider a case of an enterprise where it has full control over > > what is loaded onto a server - in this case regardless of whether > > a hypervisor is on the bare-metal or a non-virtualized OS, it > > makes sense to have the NVE in the OS > > > > 2. Similarly a cloud sp may use non-virtualized servers to offer > > certain services such as storage, hadoop, queuing etc. It makes > > sense to have the NVE in the OS > > > > 3. Lastly a case where a service provide lets a tenant load their > > own OS onto the server - i.e. some sort of managed hosting. In > > that case the servers dedicated to the tenant will be in > > a separate trust zone. They will most likely be on a different > > VLAN altogether - they may even be physically located in > > a different rack in a data center. > > > > In this case you are looking at more than beyond simple > encap/decap > > to provide connectivity between the two trust zones. > > > > regarding the point about using untagged interfaces today, I think > > having two different sets of admins - server admins and network > > admins - and who owns setting up VLANs - may have a lot to do with > > that as well. Which set of admins will own encap/decap? I think the > roles will change. > > > > Somesh > > > >> -----Original Message----- > >> From: Ivan Pepelnjak [mailto:[email protected]] > >> Sent: Tuesday, August 28, 2012 9:51 AM > >> To: Stiliadis, Dimitrios (Dimitri) > >> Cc: Somesh Gupta; Black, David; [email protected]; Linda Dunbar > >> Subject: Re: [nvo3] Let's refocus on real world > >> > >> Exactly right. There are good reasons we're using VLANs and untagged > >> server interfaces today. > >> > >> I wouldn't trust my servers to choose which virtual network they > want > >> to > >> participate in, let alone my customers' servers. > >> > >> Ivan > >> > >> On 8/28/12 5:13 PM, Stiliadis, Dimitrios (Dimitri) wrote: > >> [...] > >> > >>>> This is certainly only today's restriction. If nov3 takes off, > >> there > >>>> certainly could be a pseudo-driver in Linux that could > implement > >> the > >>>> NVE (like a VLAN driver) without much additional overhead. > >>> > >>> That doesn't work if you assume that tenants and DC operators > are > >>> different > >>> entities. The DC operator cannot rely on the tenant to do the > right > >>> encapsulation. Different administrative and trust domains. > That's > >> why > >>> in my original email I was talking about "trust boundaries". > >>> > >>> Dimitri > >>>> > >>> _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
