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