On Fri, Sep 13, 2013 at 9:45 AM, Pat Thaler <[email protected]> wrote: > Hi Zu, > > > > I don’t think that hypervisor attacks and how to protect hypervisors from > internal attackers should be covered in this draft or by this group. It is > the job of a hypervisor to keep system resources and data for the VMs > separate and to not allow a user of the VMs to get access control the > hypervisor but that isn’t an NVO issue.
Agree. --dmm > > > > Pat > > > > From: Zhangdacheng (Dacheng) [mailto:[email protected]] > Sent: Friday, August 30, 2013 11:25 PM > To: Zu Qiang > Cc: [email protected] > Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements > > > > Dear Zu: > > > > See my reply inline please. ^_^ > > > > From: Zu Qiang [mailto:[email protected]] > Sent: Friday, August 30, 2013 10:51 PM > To: Zhangdacheng (Dacheng) > Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements > > > > Hello, Dacheng > > Thanks for taking care of my comments. I do have more > comments on your draft. > > First of all, as I said early, I do support this draft. It > is very good starting point. However, the draft is far away from perfect. > Many aspects are missing in the draft. For instance, the draft proposes key > management and encryption. But is key management and encryption good enough > any DC? Maybe not. For a small DC with very few TSs and low-level security > requirements, does it need the encryption? With a huge DC with multi > tenancy, is the key management and encryption enough? > > One example is that in a hypervisor attack, the attacker may try to obtain > the administrative-level rights in the hypervisor. If the hypervisor can be > compromised, the attacker may run arbitrary code or access any account of > their choosing. The VMs running in the same hypervisor, the host > configurations, the hypervisor vSwitch, the host network, and the embedded > NVE are all exposed to the attacker, which all may be compromised by the > attacker. In such kind attacking, can the key management and encryption > protect the host network at all? > > [Dacheng Zhang:] > > If an attacker has compromised the credentials or key materials, of course > key management and encryption cannot prevent the attacker from doing certain > damages. But in this case, we can expect key management and encryption can > help us mitigate the damage caused by the attacker. > > > > As what I have mentioned in the previous emails with Melinda in the list, we > are trying to specify the security baseline (the most essential security > requirements) for the NVO3 networks. To do so, we have to make the > trade-off between the security benefit we can get and the efforts we have to > spend. We have to decide which types of attacks we have to prevent, which > types of attacks we need to mitigate, and even which types of attacks which > we don’t consider in our work. When dealing with the attackers who have > obtained certain credentials, our current strategy is to use fine-grained > authentication and authorization mechanisms to confine the damage caused by > the attacker. Of course, in practice we can do try to something more > sophisticated if our security requirements are stricter than the baseline, > and we would like to spend more money and energy. > > > > One may say the hypervisor/NVE attack is very difficult. Ok, > if the hypervisor/NVE cannot be broken, do we really need the security on > the NVE-to-NVE traffic? The key management and encryption will protect the > network from whom, if no attacker can get any access? > > [Dacheng Zhang:] > > I think there are some discussions in the draft. Also, I remember I heard > some comments during the last meeting that our consideration should cover > the scenarios where different NVEs are geographically distributed. > Therefore, we cannot just simply assume the underlay network of the NVO3 > overlay is fully secure. > > > > In addition, note that the authentication and integrity protection can also > be used to mitigate the damages caused by the inside attackers. Otherwise, a > compromised NVE could easily distribute bogus control and data packets to > seriously interfere with the normal operation of the whole NVO3 overlay. > > So what is missing in the draft is the linkage between the > security requirement and the DC architecture. Different network > architecture may have different security requirements. An embedded NVE may > have different security requirement compare to a standalone NVE. I hope you > agree. > > [Dacheng Zhang:] > > I will discuss this with other co-authors. Thanks > > Anyway, as I said early in this email, I do support this > draft. So, if you think my comments make sense, I would like to contribute > to the draft. > > [Dacheng Zhang:] > > Thanks a lot for your supports. All the comments and contributions from the > WG are really appreciated. ^_^ > > > > Have a nice day > > Zu Qiang > > > > From: Zhangdacheng (Dacheng) [mailto:[email protected]] > Sent: Thursday, August 22, 2013 10:05 PM > To: Zu Qiang; NVO3 > Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements > > > > Hi, thanks a lot for the comments. I agree that it is reasonable to allow > the VNs of a same tenant to share a group key in order to secure their > communication. I will add this into the new version of the draft. > > > > Cheers > > > > Dacheng > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Zu > Qiang > Sent: Wednesday, August 14, 2013 8:01 PM > To: NVO3 > Subject: [nvo3] draft-hartman-nvo3-security-requirements > > > > Hi, Authors > > First of all, I do support this draft. A comment on the CP > security section. > > In order to enforce the security boundary of different VNs in the > > existence of inside adversaries, the signaling messages belonging to > > different VNs need to be secured by different keys. > > This has a requirement that each VN must have a different > keys. In a large data center, the number of VN can be huge. Therefore it may > be a problem at key management. Of cause there is no technology issue when > generating that amount of security keys. However, it is going to be hard for > key management. So my proposal is that we shall allow a group key to be used > for a group of VNs, in order to optimize the key management function. > > > > Best Regards > > Zu Qiang > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
