Subject: [nvo3] draft-hartman-nvo3-security-requirements

From: Zu Qiang <[email-masked]>
Date: Wed, 14 Aug 2013 12:00:58 +0000

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 14 Aug 2013 11:18:50 -0800

On 8/14/13 4:00 AM, Zu Qiang wrote:
>                 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.  

I think group keys/group keying ought to be used more often, but
it only makes sense in those cases where it would be "correct"
to pool group members.  I don't think that's always the case in
a large data center in which you've got multiple tenants or
multiple administrative domains within one tenant, or at
least you'd need one or more group per tenant or administrative
entity.  I think it would be worth writing this up and looking
more closely at the question of where it makes sense to share
a group key and where it does not.

Melinda

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 23 Aug 2013 02:05:14 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Zu Qiang
Sent: Wednesday, August 14, 2013 8:01 PM
To: NVO3
Subject: [nvo3] draft-hartman-nvo3-security-requirements

Hi, Authors

Best Regards
Zu Qiang

---

From: Melinda Shore <[email-masked]>
Date: Thu, 22 Aug 2013 18:56:31 -0800

On 8/22/13 6:05 PM, Zhangdacheng (Dacheng) wrote:
> 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.

I'm generally a fan of group keying but I think it's important to
understand that it's not just a plug-and-play replacement for
pairwise keying, and that in particular you'll need to pay more
attention to authorization issues, as well as give some thought
to the implications of sharing certain pieces of data among all
members of a group.

It may or may not be the right technology to solve a given problem,
and any text proposing the use of group keys should be tightly scoped
and constrained.  I'm somewhat concerned that there's an "ooh, shiny!"
thing going on here.

Melinda

---

From: Truman Boyes <[email-masked]>
Date: Fri, 23 Aug 2013 13:38:43 -0400

Keying for network resources is highly complicated and will likely have
little adoption. While I see the reasons why we would be interested in
providing a useful framework to accomplish the said task; remember how far
we got with secure origin BGP and related protocols.

We could do it, but today's trust boundaries typically live on the
NVE/PE/ToR/etc, and are not truly multi-org, but rather multiple projects
that can be authorized at the application level.

Truman

On Thu, Aug 22, 2013 at 10:56 PM, Melinda Shore <[email-masked]>wrote:

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 23 Aug 2013 09:48:27 -0800

On 8/23/13 9:38 AM, Truman Boyes wrote:
> Keying for network resources is highly complicated and will likely
> have little adoption. 

There have been problems with adoption of security technologies
for routing, but I'm not sure it's because of difficulty around
keying - we see plenty of other instances of key provisioning
for things like VPN tunnels, management consoles, etc.  Granted
that they're almost always done badly.

And of course that's not a reason not to try to secure an
nvo3 tunnel - if nothing else you've got to protect the control
plane from things like spoofing, replays, etc.  That almost
always requires cryptographic protections (pace people who
run everything through an ssh tunnel).

> NVE/PE/ToR/etc, and are not truly multi-org, but rather multiple 
> projects that can be authorized at the application level.

I think there's a proper middle ground here.  The control plane
cannot go unprotected, period, and ssh tunnels don't provide
the kind of granularity or key management facilities that are
needed.  I'm always (well, almost always) happy to see group keys
being considered but there are some relatively subtle issues
that they introduce that need discussion.

Melinda

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 31 Aug 2013 03:24:33 +0000

Dear Zu:

See my reply inline please. ^_^

From: Zu Qiang [mailto:[email-masked]]
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-masked]]
Sent: Thursday, August 22, 2013 10:05 PM
To: Zu Qiang; NVO3
Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements

Cheers

Dacheng

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Zu Qiang
Sent: Wednesday, August 14, 2013 8:01 PM
To: NVO3
Subject: [nvo3] draft-hartman-nvo3-security-requirements

Hi, Authors

Best Regards
Zu Qiang