Hello, Dacheng
Thanks for your reply. My apologies for the delay in responding
to this message.
First of all, I do agree that we may need a security
requirement draft. But I don't think this draft is ready for WG adoption. At
least my comments in this mail have not been addressed yet. I feel that there
are subtle issues that have not been considered and I plan to expand it on in a
draft which I'm working on.
Have a nice day
Zu Qiang
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]>
[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
