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

From: Zu Qiang <[email-masked]>
Date: Wed, 11 Sep 2013 18:14:49 +0000

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-masked]]
Sent: Friday, August 30, 2013 11:25 PM
To: Zu Qiang
Cc: [email-masked]
Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements

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

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]> [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
                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, 11 Sep 2013 16:16:23 -0800

On 9/11/2013 10:14 AM, Zu Qiang wrote:
> 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.

I don't think that a separate security requirements draft
is a good idea, for reasons I've touched upon before.
That said, I also find your criteria for draft adoption
overly stringent and not particularly consistent with
how the IETF does business.  It is typically not the
case that a draft needs to be publication-ready, or even
very mature, for it to be adopted by a working group.
It should be in the right general ballpark and have an
editor who can be relied upon to record working group
consensus in the document.

I think it would be fantastic if you and Dacheng got
together and drew up some security requirements for
inclusion in the requirements documents.  Security requirements
should not be considered outside the context of other
protocol or operational requirements.

Melinda

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 12 Sep 2013 02:37:18 +0000

Hi, Melinda:

We would be happy to do the work of security requirements under the instruction of the WG. We also would like to cooperate other experts from the WG to push this work forward. 

Cheers

Dacheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Melinda Shore
> Sent: Thursday, September 12, 2013 8:16 AM
> To: [email-masked]
> Subject: Re: [nvo3] draft-hartman-nvo3-security-requirements
> 
> > draft. But I don't think this draft is ready for WG adoption. At
> > to expand it on in a draft which I'm working on.
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Pat Thaler" <[email-masked]>
Date: Thu, 12 Sep 2013 23:35:36 +0000

In the requirements phase, a separate security requirements draft is useful. I agree with Dacheng that it is important to consider the requirements for the whole system. If security requirements were dispersed, I'd be concerned that something would be missed. 

That doesn't mean that security should be covered separately when we get to solutions documents. 

Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, September 11, 2013 5:16 PM
To: [email-masked]
Subject: Re: [nvo3] draft-hartman-nvo3-security-requirements

Melinda

---

From: "Pat Thaler" <[email-masked]>
Date: Thu, 12 Sep 2013 23:45:17 +0000

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.

Pat

From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
Sent: Friday, August 30, 2013 11:25 PM
To: Zu Qiang
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements

Dear Zu:

Hello, Dacheng

Have a nice day
Zu Qiang

Cheers

Dacheng

Hi, Authors

Best Regards
Zu Qiang

---

From: David Meyer <[email-masked]>
Date: Fri, 13 Sep 2013 11:33:33 +1000

On Fri, Sep 13, 2013 at 9:45 AM, Pat Thaler <[email-masked]> 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

>                 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:]
>
>                 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:]
>
> 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
>                 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: "Pat Thaler" <[email-masked]>
Date: Fri, 13 Sep 2013 01:55:03 +0000

A comment on the security draft that came up during discussion of draft-kreeger-nvo3-hypervisor-nve-cp-01. Resending with this subject so those interested in the security draft don't miss it.

In 5.1, the signaling to the NVE to help it follow VM state and migration shouldn't be from the TS. It should be from the hypervisor. The key therefore should be a hypervisor key, not a tenant or TS key. See an excerpt from the other email below.

<snip>
LK> Our goal is the make the implementation of the VN completely hidden from the TS (VM).  There should be no requirement to modify the TS to participate in address advertisement.  There is also an issue of trust, we should try to avoid trusting a TS to advertise its address.
 
<PAT> Larry, I agree, but the NVO3 Security draft which has the following in 5.1 isn't consistent with this:
"Apart from data traffics, the NVE and the TSes also
  need to exchange signaling messages in order to facilitate, e.g., VM
   online detection, VM migration detection, or auto-provisioning/
   service discovery [I-D.ietf-nvo3-framework]."
The messages for these purposes should be between the NVE and the hypervisor, not the NVE and the TS.

LK> I agree with you, Pat (and disagree with this statement in the security draft).  We should avoid trusting Tenant Systems.  Furthermore, I don't see how a TS implemented as a VM would have any idea whether it was being migrated.  Maybe this is just a terminology issue because it seems like the signaling mentioned would be performed by a hypervisor, not a VM.

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 13 Sep 2013 02:08:31 +0000

Ok, I think you are right. The description in the security draft is not clear and may cause confusions.  I will re-write this part according to your comments.

Thanks a lot for your advice. 

Dacheng 

> From: Pat Thaler [mailto:[email-masked]]
> Sent: Friday, September 13, 2013 9:55 AM
> To: David Meyer
> Cc: Zu Qiang; Zhangdacheng (Dacheng); [email-masked]
> A comment on the security draft that came up during discussion of
> draft-kreeger-nvo3-hypervisor-nve-cp-01. Resending with this subject so those
> interested in the security draft don't miss it.
> 
> In 5.1, the signaling to the NVE to help it follow VM state and migration
> shouldn't be from the TS. It should be from the hypervisor. The key therefore
> should be a hypervisor key, not a tenant or TS key. See an excerpt from the
> other email below.
> 
> <snip>
> LK> Our goal is the make the implementation of the VN completely hidden from
> the TS (VM).  There should be no requirement to modify the TS to participate
> in address advertisement.  There is also an issue of trust, we should try to
> avoid trusting a TS to advertise its address.
> 
> LK> I agree with you, Pat (and disagree with this statement in the security
> draft).  We should avoid trusting Tenant Systems.  Furthermore, I don't see
> how a TS implemented as a VM would have any idea whether it was being
> migrated.  Maybe this is just a terminology issue because it seems like the
> signaling mentioned would be performed by a hypervisor, not a VM.
>

---

From: Zu Qiang <[email-masked]>
Date: Fri, 13 Sep 2013 17:39:52 +0000

Hello, Pat
                Thanks for your email.
                I agree with you that how to protect the hypervisor is not in the scope of this group. The point I try to make in my email is that the hypervisor-NVE traffic shall be protected in the split-NVE case. In the embedded case, it cannot be assumed that the  embedded NVE is always safe. Therefore we may need protection on the NVE-NVE and NVE-NVA interface.

Have a nice day
Zu Qiang

From: Pat Thaler [mailto:[email-masked]]
Sent: Thursday, September 12, 2013 7:45 PM
To: Zu Qiang; Zhangdacheng (Dacheng); [email-masked]
Subject: RE: [nvo3] draft-hartman-nvo3-security-requirements

Hi Zu,

Pat

Dear Zu:

Hello, Dacheng

Have a nice day
Zu Qiang

Cheers

Dacheng

Hi, Authors

Best Regards
Zu Qiang