Subject: [nvo3] Security requirements draft -01: REQ5 - Key Management

From: "Black, David" <[email-masked]>
Date: Tue, 22 Oct 2013 16:41:49 -0400

I should first say that there is a lot to like in the security requirements
draft (draft-ietf-nvo3-security-requirements-01), and I particularly
appreciate the distinction that it makes between secure vs. insecure underlay
networks as well as secure vs. insecure connectivity on the non-NVO3 side of
NVEs - that distinction will be valuable in ensuring that the requirements
are useful in practice.

OTOH, REQ5 under Control Plane Security (section 5.1.1, p.9) looks rather
problematic to me.

I saw an earlier note that effectively said that key management is not
required by the security draft.  I think that would be a good approach,
but, unfortunately, requirement 5 is not consistent with that statement:

   REQ5:  The key management solution MUST be able to confine the scope
      of key distribution and provide different keys to isolate the
      control traffic according to different security requirements.

      a: It SHOULD be guaranteed that different keys are used to secure
      the control packets exchanged within different tenant networks.

      b: It SHOULD be guaranteed that different keys are used to secure
      the control packets exchanges with different VNs.

Moreover, I think requirement 5 is flawed in its current form. I do
understand the underlying motivation to limit the impact of NVE compromise,
and agree that this is an important security goal for NVO3.  OTOH,
requirement 5 does not look like a good way to achieve it:

1) REQ5-a is meaningless as stated.  The NVA and its associated NVEs are
not "within" any tenant network, and the draft's rationale for REQ5-a,
namely that a single NVE is scoped to a single tenant, is definitely
wrong in general.

2) Moreover I don't think the concept of "tenant network" is useful for
imposing security boundaries within the control plane for a single NVO3
domain.  Rather I'd suggest that the recommendation (at end of requirement
1) for use of individual NVE identities for authentication rather than
identities shared among NVEs is a better place to start.  In practice, if
an attacker compromises an NVE, the attacker has access to all of the VNs
that are authorized to that NVE, including those currently configured on
it.  The goal should be to contain the compromise to that NVE and the VNs
that it can affect - in particular, it would be very bad if NVE compromise
could be escalated to NVA compromise (and one would also not want to see
the compromise spread to other NVEs).  That's an authorization challenge
among NVEs and the NVA (and possibly among NVA components if the NVA is not
realized as a single component), not among tenants or VNs.

3) REQ5-b recommends different keying material for each VN's control traffic.
If one thinks about likely VN density in data centers, this is a serious
scaling problem.  Keep in mind that among the motivations for NVO3 is that
a 12-bit .1Q VLAN tag isn't large enough.  An NVE in a hypervisor can
reasonably expect to be involved in hundreds of VNs (or more), and the number
for an NVE in a  top-of rack switch could be thousands of VNs (or more).

If someone really wants to build that scale of key management, fine, but
this draft needs to allow authorization solutions (e.g., access control
lists at the NVA that limit which VNs can be used by each NVE) that don't
require a key per VN.  REQ5 currently implicitly forbids such approaches
(and I think this is what Zu Qiang may have been trying to call attention
to earlier).

On a related note, I think REQ11 (5.2.1.1, pp.12-13) has missed something
significant about where the control plane traffic originates from:

   REQ11:  The key management solution MUST be able to confine the scope
      of key distribution and provide different keys to isolate the
      control traffic according to different security requirements.

      a: If assuming TSes (hypervisors) will not be compromised, the
      TSes belonging to different Tenants MUST use different keys to
      secure the control packet exchanges with their NVE.

      b: If assuming the hypervisors can be compromised, the TSes
      belonging to different VNs MUST use different keys to secure the
      control packets exchanges with their NVE.

The TS is the VM, which has no idea that NVO3 is being used, so the TS
is not originating control plane traffic.  This requirement should also
be rethought in light of my above comment that I don't think tenants are
a useful way to think about putting security boundaries within the NVO3
control plane.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Zu Qiang <[email-masked]>
Date: Wed, 23 Oct 2013 19:20:15 +0000

Hello,
	First of all, I agree with David's comment. Just want to add one more on top of it.
	We cannot have a generic security requirement discussion without the considerations of what kind NVO3 architecture is going to be supported. I have given this comment weeks ago. And no response has been received. 
	So far there are only two alternatives are supported by the 01 version of the architecture draft. The first one is that a NVE may "obtain necessary information entirely through the hypervisor-facing side of the NVE." In this case, "it is a natural extension to leverage the existing orchestration protocol as a sort of proxy protocol for handling the interactions between an NVE and the NVA." The second alternative is that " an NVE can obtain needed information by interacting directly with an NVA via a protocol operating over the data center underlay network. " 
	The NVO3 control plane security may be needed on a NVA-NVE control signalling in the second alternative case. In this case, if we can assume that the NVA has a participating NVEs list of a give VN configured (which is required in section 7.3 of the architecture draft), this participating NVEs list can be used for address filtering based authorization. So a node level authentication plus address filtering based authorization may be enough to secure the NVO3 control plane. This approach shall be allowed. 
	When a NVA is compromised, is there a way to mitigate the security damage? Maybe not. When a NVE is compromised, the address filtering based authorization may be enough to prevent the NVE on sending something which it is supposed to send. But it is hard to prevent the compromised NVE when sending control signalling of the attached VNs.  
	The NVO3 control plane security may be needed on a hypervisor-NVE control signalling in the first alternative case when split-NVE case. Same comments apply on the hypervisor-NVE interface. 
	I see the per TS or per VN based key management is overkilling. If there is a benefit from the per TS or per VN based key management, which is not described clearly in the draft, please clarify it.

Have a nice day
Zu Qiang

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Black, David
>Sent: Tuesday, October 22, 2013 4:42 PM
>To: [email-masked]
>Subject: [nvo3] Security requirements draft -01: REQ5 - Key Management
>
>I should first say that there is a lot to like in the security requirements draft
>(draft-ietf-nvo3-security-requirements-01), and I particularly appreciate the
>distinction that it makes between secure vs. insecure underlay networks as
>well as secure vs. insecure connectivity on the non-NVO3 side of NVEs - that
>distinction will be valuable in ensuring that the requirements are useful in
>practice.
>
>I saw an earlier note that effectively said that key management is not required
>by the security draft.  I think that would be a good approach, but,
>unfortunately, requirement 5 is not consistent with that statement:
>
>Moreover, I think requirement 5 is flawed in its current form. I do understand
>the underlying motivation to limit the impact of NVE compromise, and agree
>that this is an important security goal for NVO3.  OTOH, requirement 5 does
>not look like a good way to achieve it:
>
>1) REQ5-a is meaningless as stated.  The NVA and its associated NVEs are not
>"within" any tenant network, and the draft's rationale for REQ5-a, namely that
>a single NVE is scoped to a single tenant, is definitely wrong in general.
>
>1) for use of individual NVE identities for authentication rather than identities
>shared among NVEs is a better place to start.  In practice, if an attacker
>compromises an NVE, the attacker has access to all of the VNs that are
>authorized to that NVE, including those currently configured on it.  The goal
>should be to contain the compromise to that NVE and the VNs that it can
>affect - in particular, it would be very bad if NVE compromise could be
>escalated to NVA compromise (and one would also not want to see the
>compromise spread to other NVEs).  That's an authorization challenge among
>NVEs and the NVA (and possibly among NVA components if the NVA is not
>If one thinks about likely VN density in data centers, this is a serious scaling
>problem.  Keep in mind that among the motivations for NVO3 is that a 12-
>bit .1Q VLAN tag isn't large enough.  An NVE in a hypervisor can reasonably
>expect to be involved in hundreds of VNs (or more), and the number for an
>NVE in a  top-of rack switch could be thousands of VNs (or more).
>
>If someone really wants to build that scale of key management, fine, but this
>draft needs to allow authorization solutions (e.g., access control lists at the
>NVA that limit which VNs can be used by each NVE) that don't require a key
>per VN.  REQ5 currently implicitly forbids such approaches (and I think this is
>what Zu Qiang may have been trying to call attention to earlier).
>
>The TS is the VM, which has no idea that NVO3 is being used, so the TS is not
>originating control plane traffic.  This requirement should also be rethought in
>light of my above comment that I don't think tenants are a useful way to think
>about putting security boundaries within the NVO3 control plane.
>
>Thanks,
>--David
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 24 Oct 2013 06:38:04 +0000

Hi, Zu:

Thanks a lot for your comments. They are very positive to improve the work.  

David's comments are very useful, I am thinking how to update the document according to his comments.

See the inline please. 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Zu
> Qiang
> Sent: Thursday, October 24, 2013 3:20 AM
> To: Black, David; [email-masked]
> Subject: Re: [nvo3] Security requirements draft -01: REQ5 - Key Management
> 
> Hello,
> 	We cannot have a generic security requirement discussion without the
> considerations of what kind NVO3 architecture is going to be supported. I have
> given this comment weeks ago. And no response has been received.
> 	So far there are only two alternatives are supported by the 01 version of
> the architecture draft. The first one is that a NVE may "obtain necessary
> information entirely through the hypervisor-facing side of the NVE." In this case,
> "it is a natural extension to leverage the existing orchestration protocol as a
> sort of proxy protocol for handling the interactions between an NVE and the
> NVA." The second alternative is that " an NVE can obtain needed information
> by interacting directly with an NVA via a protocol operating over the data
> center underlay network. "
[Dacheng Zhang:] 
In the current draft, we do mention NVE and NVA, and give some comments about using authorization mechanism to enforce the security of NVA. But I agree that it is a good advice to give a more detailed discussion about the security requirements of NVA. I believe we should pay more attention on protecting NVA since it is the critical component in the architecture. 

> 	The NVO3 control plane security may be needed on a NVA-NVE control
> signalling in the second alternative case. In this case, if we can assume that the
> NVA has a participating NVEs list of a give VN configured (which is required in
> section 7.3 of the architecture draft), this participating NVEs list can be used
> for address filtering based authorization. So a node level authentication plus
> address filtering based authorization may be enough to secure the NVO3
> control plane. This approach shall be allowed.
[Dacheng Zhang:] 
This approach has been indicated in the authentication and authorization requirements. I will try to present this idea more clearly. 

I have some concerns about the address filtering based authorization. Let's discuss this here.

I think we need to consider the issue that the underlying network is unsecure and an attacker can inject bogus messages with fake addresses into the communication between NVEs and the NVA. 

So, the steps for a NVA in processing a incoming packets may look like:

1) use ACL to process the packet, discard the packet if it is from an unknown address. 
2) find a proper key to verify the integrity, authenticity, and freshness of the packet through the information transported in the packet header (e.g., key ID).
3) find out whether the sender of the packet is authorized to send out this packet. 

So, if your "address filtering based authorization" is performed in step 1, then I think it is not sufficient since we cannot jump over step 3. 

If the "address filtering based authorization" happens instep 3. Then we are thinking in the similar ways. Sure, if the address is stable, the address can also be used as the identifier of the network devices and then be used to locate the security policies. However, in a security mechanism, it is possible to use other IDs instead of address to identify a device and then find out the associated security policies. So, that is why we didn't claim that the authorization should be based on "address". 

So, in REQ2, there are the statements. 

" In addition, authorization is important for enforcing the VN isolation, a device only can distribute control packets within the VNs it is involved within. If a control packet about a VN is sent from a NVE which is not authorized to support the VN, the packet will not be accepted. "

" Normally, it is assumed that the access control operations are based on the authentication results. The simple authorization mechanisms (such as ACLs which filters packets based on the packet addresses) can be used as auxiliary approaches since they are relatively easy to bypass if attackers can access to the network and modify packets. " 

Please let me know if you are happy with it. And please let me know if I understand your points correctly. 

> 	When a NVA is compromised, is there a way to mitigate the security
> damage? Maybe not. When a NVE is compromised, the address filtering based
> authorization may be enough to prevent the NVE on sending something which
> it is supposed to send. But it is hard to prevent the compromised NVE when
> sending control signalling of the attached VNs.
[Dacheng Zhang:] 

Yes, if a NVE has compromised, it can send out bogus packets within the VNs which it has already involved within.

I guess you mean " When a NVE is compromised, the address filtering based authorization may be enough to prevent the NVE on sending something which it is NOT supposed to send."

Again, I assume the "address filtering based authorization" here is performed in step 3 rather than in step 1. 

I think this is dependent on how the keys are deployed to prevent an attacker to generated bogus packets. 

If group key management is used and all the NVEs use the same key in transporting control packets, then the attacker compromising a NVE can get the chance to impersonate other NVEs and sending out packets. 

That is why we think it may be worthwhile to give some discussion about the key management issues.

> 	The NVO3 control plane security may be needed on a hypervisor-NVE
> control signalling in the first alternative case when split-NVE case. Same
> comments apply on the hypervisor-NVE interface.
> 	I see the per TS or per VN based key management is overkilling. If there is
> a benefit from the per TS or per VN based key management, which is not
> described clearly in the draft, please clarify it.
[Dacheng Zhang:] 
David has pointed out that  I should not use TS in REQ11. So, the REQ11b should actually look like
"If assuming the hypervisors can be compromised, the hypervisors belonging to different VNs MUST use different keys to secure the control packets exchanges with their NVE."

I have corrected this problem.

Thanks a lot again for your comments.

Dacheng

> required
> not

---

From: Melinda Shore <[email-masked]>
Date: Wed, 23 Oct 2013 22:48:15 -0800

On 10/23/13 10:38 PM, Zhangdacheng (Dacheng) wrote:
> 1) use ACL to process the packet, discard the packet if it is from
> an
unknown address.
> 2) find a proper key to verify the integrity, authenticity, and
freshness of the packet through the information transported in the
packet header (e.g., key ID).
> 3) find out whether the sender of the packet is authorized to send
> out
this packet.
> 
> So, if your "address filtering based authorization" is performed in
step 1, then I think it is not sufficient since we cannot jump over step 3.

I think this is a really critical point, and one that merits
some careful consideration (and some text).  Here's the
question: in a scenario like the one under discussion, is it
reasonable to assume that if you're sharing encryption/decryption/
authentication keys with a peer, are operations requested by
that peer then authorized? In other contexts we've used group
keys/key groups as authorization groups (that is to say, if
a given node is a member of a keying group, requests
from it to other members of the group are authorized, and
groups may be overlapping depending on authorization
requirements).  That said, it may be the case that you can
share keys with a node of whom you are *not* authorized
to make requests (or rather, the node is not authorized to
honor your requests).

The questions about key management are, I think, central
to the question of security requirements, and probably merit
some fairly explicit discussion.

Melinda

---

From: "Black, David" <[email-masked]>
Date: Thu, 24 Oct 2013 09:21:54 -0400

> I think we need to consider the issue that the underlying network is unsecure
> and an attacker can inject bogus messages with fake addresses into the
> communication between NVEs and the NVA.
>
> 2) find a proper key to verify the integrity, authenticity, and freshness of
> the packet through the information transported in the packet header (e.g., key ID).

For clarity, step 2 applies *if* the underlying network is insecure.
It's not needed if one is prepared to trust the underlying network's
security (e.g., integrity, confidentiality, no replay).

> "If assuming the hypervisors can be compromised, the hypervisors belonging to
> different VNs MUST use different keys to secure the control packets exchanges
> with their NVE."
>

I strongly disagree with that rewording.  The sort of security
implementation that I expect to see is a single TLS connection between
hypervisor and outboard NVE (e.g., in a top-of-rack switch) - both
entities are multi-VN and multi-tenant in scope.  That appears to be
excluded by the rewording.

Picking up on Melinda's subsequent comment:

> Here's the

IMHO, it absolutely will be, especially if I restate that last
parenthetical comment for emphasis as "or rather the node is not
authorized to honor *all* of the requests that you could possibly
make.

My overriding concern with REQ5 and REQ11 is that they effectively
require some sort of key per authorization target design, and while
I don't object to such designs (although I question its scalability
in practice), I strongly object to mandating that design approach
to the exclusion of alternatives (e.g., ACLs), and REQ5 and REQ11
do exclude such alternatives as currently written.

One of the things that may be going on here is that there are two
sorts of control/signaling traffic involved when the data plane
between the NVEs requires security:

        - NVO3 control traffic: hypervisors, NVEs and NVAs dealing
                with VN configuration, attachment/detachment, etc.
        - Data plane security signaling when the underlying network
                is insecure.  If IPsec is used between NVEs, IKE and
                IKEv2 are examples.

The key management requirements in REQ5 make somewhat more sense for
the latter sort of traffic (reasoning from impact of session key
compromise), but even for that usage, the fact that the NVEs are
inherently multi-VN and multi-tenant (and probably don't have tenant
security credentials) suggests that REQ5 is probably still
overstated even for just data plane security signaling.

Thanks,
--David

> From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
> Sent: Thursday, October 24, 2013 2:38 AM
> To: Zu Qiang; Black, David; [email-masked]
> Cc: Sam Hartman; Margaret Wasserman
> Subject: RE: Security requirements draft -01: REQ5 - Key Management
>
> Hi, Zu:
>
> In the current draft, we do mention NVE and NVA, and give some comments about
> using authorization mechanism to enforce the security of NVA. But I agree that
> it is a good advice to give a more detailed discussion about the security
> requirements of NVA. I believe we should pay more attention on protecting NVA
> since it is the critical component in the architecture.
>
> This approach has been indicated in the authentication and authorization
> requirements. I will try to present this idea more clearly.
>
> I think we need to consider the issue that the underlying network is unsecure
> and an attacker can inject bogus messages with fake addresses into the
> communication between NVEs and the NVA.
>
> 2) find a proper key to verify the integrity, authenticity, and freshness of
> the packet through the information transported in the packet header (e.g., key ID).
> So, if your "address filtering based authorization" is performed in step 1,
> then I think it is not sufficient since we cannot jump over step 3.
>
> If the "address filtering based authorization" happens instep 3. Then we are
> thinking in the similar ways. Sure, if the address is stable, the address can
> also be used as the identifier of the network devices and then be used to
> locate the security policies. However, in a security mechanism, it is possible
> to use other IDs instead of address to identify a device and then find out the
> associated security policies. So, that is why we didn't claim that the
> authorization should be based on "address".
>
> " In addition, authorization is important for enforcing the VN isolation, a
> device only can distribute control packets within the VNs it is involved
> within. If a control packet about a VN is sent from a NVE which is not
> authorized to support the VN, the packet will not be accepted. "
>
> " Normally, it is assumed that the access control operations are based on the
> authentication results. The simple authorization mechanisms (such as ACLs
> which filters packets based on the packet addresses) can be used as auxiliary
> approaches since they are relatively easy to bypass if attackers can access to
> the network and modify packets. "
>
> I guess you mean " When a NVE is compromised, the address filtering based
> authorization may be enough to prevent the NVE on sending something which it
> is NOT supposed to send."
>
> If group key management is used and all the NVEs use the same key in
> transporting control packets, then the attacker compromising a NVE can get the
> chance to impersonate other NVEs and sending out packets.
>
> "If assuming the hypervisors can be compromised, the hypervisors belonging to
> different VNs MUST use different keys to secure the control packets exchanges
> with their NVE."
>
> draft
> understand
> identities
> scaling
> this
> > >originating control plane traffic.  This requirement should also be
> rethought
> > in

---

From: Zu Qiang <[email-masked]>
Date: Thu, 24 Oct 2013 14:07:12 +0000

Hello, Dachang
	I don't think we have the same understanding on the benefits and usage of the per-VN key. Can you give more explanations why you think it is needed for control plane? In my view one key per node is good enough. Even in data plane, if we use VxLAN as an example, one L3 security tunnel will protect all the NVE-NVE data traffic if the underlay network is considered as unsecured. A per VN key only make sense if the tenant has privacy concern. In another word it cannot be a must requirement. 
	More comments inline.
BR/Zu Qiang

>[Dacheng Zhang:]
>In the current draft, we do mention NVE and NVA, and give some comments
>about using authorization mechanism to enforce the security of NVA. But I
>agree that it is a good advice to give a more detailed discussion about the
>security requirements of NVA. I believe we should pay more attention on
>protecting NVA since it is the critical component in the architecture.

[Zu Qiang] the question I have is " When a NVA is compromised, is there a way to mitigate the security damage? Maybe not. " The only protection, that NVO3 WG can do, is to secure the NVA-NVE interface. 
>> signalling in the second alternative case. In this case, if we can
>> assume that the NVA has a participating NVEs list of a give VN
>> configured (which is required in section 7.3 of the architecture
>> draft), this participating NVEs list can be used for address filtering
>> based authorization. So a node level authentication plus address
>> filtering based authorization may be enough to secure the NVO3 control
>plane. This approach shall be allowed.
>[Dacheng Zhang:]

[Zu Qiang] Can you add the considerations of what kind NVO3 architecture is going to be supported? It is unclear that the requirements in your draft are for which NVO3 interface and which NVO3 node.

>2) find a proper key to verify the integrity, authenticity, and freshness of the
>packet through the information transported in the packet header (e.g., key
>ID).
>So, if your "address filtering based authorization" is performed in step 1, then
>I think it is not sufficient since we cannot jump over step 3.

[Zu Qiang] the "address filtering based authorization" is referring to both step 1 and step 3. Step 2 is optional if the underlay network is unsecured. For all the three steps, you may need a key, but not a per-VN based, right? 

>thinking in the similar ways. Sure, if the address is stable, the address can also
>be used as the identifier of the network devices and then be used to locate
>the security policies. However, in a security mechanism, it is possible to use
>other IDs instead of address to identify a device and then find out the
>device only can distribute control packets within the VNs it is involved within.
>If a control packet about a VN is sent from a NVE which is not authorized to
>support the VN, the packet will not be accepted. "
[Zu Qiang] wording: "the packet shall be discarded/rejected by the NVA." 

>the network and modify packets. "
[Zu Qiang] by the way, are you going to change R5?

>> damage? Maybe not. When a NVE is compromised, the address filtering
>> based authorization may be enough to prevent the NVE on sending
>> something which it is supposed to send. But it is hard to prevent the
>> compromised NVE when sending control signalling of the attached VNs.
>[Dacheng Zhang:]
>
>authorization may be enough to prevent the NVE on sending something
>which it is NOT supposed to send."
>
>transporting control packets, then the attacker compromising a NVE can get
>the chance to impersonate other NVEs and sending out packets.
>

[Zu Qiang] My point is that per-VN key is not needed. The NVE may need one key to secure the communication with NVA. Not sure what kind key deployment you are referring?

>> control signalling in the first alternative case when split-NVE case.
>> Same comments apply on the hypervisor-NVE interface.
>> 	I see the per TS or per VN based key management is overkilling. If
>> there is a benefit from the per TS or per VN based key management,
>> which is not described clearly in the draft, please clarify it.
>[Dacheng Zhang:]
>David has pointed out that  I should not use TS in REQ11. So, the REQ11b
>should actually look like "If assuming the hypervisors can be compromised,
>the hypervisors belonging to different VNs MUST use different keys to secure
>the control packets exchanges with their NVE."
[Zu Qiang] again, The hypervisor/NVE may need one key to secure the control plane communication with each other. Why you need per-VN key? I agree with David's comment " both entities are multi-VN and multi-tenant in scope.  " A per VN key is some kind overkilling.

 Have a nice day
 Zu Qiang
>> >From: [email-masked] [mailto:[email-masked]] On Behalf
>> >Of Black, David
>> >I should first say that there is a lot to like in the security
>> >requirements draft (draft-ietf-nvo3-security-requirements-01), and I
>> >particularly appreciate the distinction that it makes between secure
>> >vs. insecure underlay networks as well as secure vs. insecure
>> >connectivity on the non-NVO3 side of NVEs - that distinction will be
>> >valuable in ensuring that the requirements are useful in practice.
>> >
>> >OTOH, REQ5 under Control Plane Security (section 5.1.1, p.9) looks
>> >rather problematic to me.
>> >
>> >understand the underlying motivation to limit the impact of NVE
>> >compromise, and agree that this is an important security goal for
>> >NVO3.  OTOH, requirement 5 does not look like a good way to achieve it:
>> >
>> >"within" any tenant network, and the draft's rationale for REQ5-a,
>> >namely
>> that
>> >2) Moreover I don't think the concept of "tenant network" is useful
>> >for imposing security boundaries within the control plane for a
>> >single NVO3 domain.  Rather I'd suggest that the recommendation (at
>> >end of
>> requirement
>> >1) for use of individual NVE identities for authentication rather
>> >than identities shared among NVEs is a better place to start.  In
>> >practice, if an attacker compromises an NVE, the attacker has access
>> >to all of the VNs that are authorized to that NVE, including those
>> >currently configured on it.  The goal should be to contain the
>> >compromise to that NVE and the VNs that it can affect - in
>> >particular, it would be very bad if NVE compromise could be escalated
>> >to NVA compromise (and one would also not want to see the compromise
>> >spread to other NVEs).  That's an authorization challenge
>> among
>> >If one thinks about likely VN density in data centers, this is a
>> >serious scaling problem.  Keep in mind that among the motivations for
>> >NVO3 is that a 12- bit .1Q VLAN tag isn't large enough.  An NVE in a
>> >hypervisor can reasonably expect to be involved in hundreds of VNs
>> >(or more), and the number for an NVE in a  top-of rack switch could be
>thousands of VNs (or more).
>> >
>> >If someone really wants to build that scale of key management, fine,
>> >but this draft needs to allow authorization solutions (e.g., access
>> >control lists at the NVA that limit which VNs can be used by each
>> >NVE) that don't require a key per VN.  REQ5 currently implicitly
>> >forbids such approaches (and I think this is what Zu Qiang may have been
>trying to call attention to earlier).
>> >
>> >On a related note, I think REQ11 (5.2.1.1, pp.12-13) has missed
>> >something significant about where the control plane traffic originates from:
>> >
>> >The TS is the VM, which has no idea that NVO3 is being used, so the
>> >TS is not originating control plane traffic.  This requirement should
>> >also be rethought
>> in
>> >light of my above comment that I don't think tenants are a useful way
>> >to think about putting security boundaries within the NVO3 control plane.
>> >
>> >Thanks,
>> >--David
>> >David L. Black, Distinguished Engineer EMC Corporation, 176 South
>> >St., Hopkinton, MA  01748

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 25 Oct 2013 02:39:58 +0000

Hi, Zu:

In the last email, I tried to say maybe we have the same understanding on the usage of authorization system. ^_^ Yes, I am re-writing REQ5 according to the comments from David and you, but not finish it yet. Let me write down what I am thinking.

About the key management issues. Our original consideration is to prevent a compromised NVE from affect the VNs that the NVE is involved within. 

So, In the case of securing communication between a NVE and a NVA, different key should be used for the communication between different NVEs and NVA. Therefore, the compromise of a NVE will not affect the communication between other NVEs and the NVA. I has agreed with that and didn't try to argue with you on this point. So, we are on the same page about this.

What I am still thinking is how to present key management issues with the NVE and NVE communication. Note there are multicast packets.

In order to secure the communication between NVE-NVE control traffic. We can provide at least two options. 

1) Use pair-wise keys to secure the communications between NVEs. When distributing multicast packets, a NVE needs to generate a copy of the packets for each target NVE. In this case the requirement may look like " When using pair-wise keys to secure NVE-NVE communication, each NVE SHOULD use different keys in securing its communication with different remote NVEs" This indicate each pair of NV will use a different to secure their communication. So, if a NVE has been compromised, it cannot impersonate other NVEs.

2) To make use of the multicast capability of underlying networks, it is also possible to deploy group keys for all the NVEs in a VN to secure multicast packets. In this case, the multicast packets in different VN should be secured with different keys. In this case the requirement may look like" When using group keys to secure NVE-NVE communication, control packets within different VNs SHOULD be secured with different keys " Therefore, if a NVE is compromised, it can only affect the VNs it works for.

That is my current thoughts about the new REQ5. Comments?

Dacheng 

> [Zu Qiang] again, The hypervisor/NVE may need one key to secure the control
> plane communication with each other. Why you need per-VN key? I agree with
> David's comment " both entities are multi-VN and multi-tenant in scope.  " A
> per VN key is some kind overkilling.
[Dacheng Zhang:] 
About this "If assuming the hypervisors can be compromised,
the hypervisors belonging to different VNs MUST use different keys to secure
the control packets exchanges with their NVE."

I would like to rewrite it to "If assuming the hypervisors can be compromised,
each hypervisor MUST use different keys to secure
its control packet exchanges with their NVE."

---

From: "Black, David" <[email-masked]>
Date: Fri, 25 Oct 2013 09:39:48 -0400

Hi Dacheng,

This is a significant improvement over where this discussion started, as most of
the latest thinking below expresses key usage scope in terms of NVEs, NVAs and
hypervisors, as opposed to VNs or tenants.  I think "End Device" may be the more
general term for the role filled by the hypervisor.

I would strongly suggest that the draft express the difference between securing
NVO3 control functionality (VN configuration, attach, detach - NVE-NVA and
NVE-server/hypervisor/end-device communication) and securing VN traffic among
NVEs (security signaling in/for the data plane).  

For multicast in the underlay, the ingress NVE is sourcing the multicast packets.
If the goal is to limit the ability of a compromised NVE to impact other NVEs that
it should not otherwise be interacting with, I'd suggest scoping keys to multicast
"trees" (in quotes because that word's probably not sufficient on its own).  If
there's an underlay multicast address per VN involved, this approach is likely to
reduce to the key per VN approach described below.  OTOH, if the NVEs manage to
aggregate VN BUM traffic onto fewer multicast "trees" (an in particular to share
an underlay multicast address among multiple VNs), there's almost no point in
using multiple keys for the same "tree".

Thanks,
--David

> Zhangdacheng (Dacheng)
> Sent: Thursday, October 24, 2013 10:40 PM
> In the last email, I tried to say maybe we have the same understanding on the
> usage of authorization system. ^_^ Yes, I am re-writing REQ5 according to the
> comments from David and you, but not finish it yet. Let me write down what I
> am thinking.
> 
> About the key management issues. Our original consideration is to prevent a
> compromised NVE from affect the VNs that the NVE is involved within.
> 
> So, In the case of securing communication between a NVE and a NVA, different
> key should be used for the communication between different NVEs and NVA.
> Therefore, the compromise of a NVE will not affect the communication between
> other NVEs and the NVA. I has agreed with that and didn't try to argue with
> you on this point. So, we are on the same page about this.
> 
> What I am still thinking is how to present key management issues with the NVE
> and NVE communication. Note there are multicast packets.
> 
> 1) Use pair-wise keys to secure the communications between NVEs. When
> distributing multicast packets, a NVE needs to generate a copy of the packets
> for each target NVE. In this case the requirement may look like " When using
> pair-wise keys to secure NVE-NVE communication, each NVE SHOULD use different
> keys in securing its communication with different remote NVEs" This indicate
> each pair of NV will use a different to secure their communication. So, if a
> NVE has been compromised, it cannot impersonate other NVEs.
> 
> 2) To make use of the multicast capability of underlying networks, it is also
> possible to deploy group keys for all the NVEs in a VN to secure multicast
> packets. In this case, the multicast packets in different VN should be secured
> with different keys. In this case the requirement may look like" When using
> group keys to secure NVE-NVE communication, control packets within different
> VNs SHOULD be secured with different keys " Therefore, if a NVE is
> compromised, it can only affect the VNs it works for.
>

---

From: Zu Qiang <[email-masked]>
Date: Fri, 25 Oct 2013 14:17:26 +0000

Hello, Dacheng
	I see big improvement in the new text. I had one more comment which I have given long time ago and repeat a few time during the email discussion. " We cannot have a generic security requirement discussion without the considerations of what kind NVO3 architecture is going to be supported. " I did have the separation between each control plane interfaces and data plane in my draft (http://tools.ietf.org/html/draft-zu-nvo3-security-requirements-00). And I think this is the way the document shall be.
	For NVA-NVE control plane security, I think we are in the same page. Thanks God! 
	For the key management on NVE-NVE, I hope you mean NVE-NVE data plane security. There is no NVE-NVE control plane specified in the current version of the architecture draft. Personally I also believe a NVE-NVE control plane may be needed. But from the discussion I had with Thomas Narten, my understanding is that it is not in the scope of the current NVO3 architecture discussion. So we may have to take the NVE-NVE control plane security requirement out from the security requirement draft for now.  

Have a nice day
Zu Qiang

>So, In the case of securing communication between a NVE and a NVA,
>different key should be used for the communication between different NVEs
>and NVA. Therefore, the compromise of a NVE will not affect the
>communication between other NVEs and the NVA. I has agreed with that and
>didn't try to argue with you on this point. So, we are on the same page about
>this.
>
>What I am still thinking is how to present key management issues with the
>NVE and NVE communication. Note there are multicast packets.
>
>pair-wise keys to secure NVE-NVE communication, each NVE SHOULD use
>different keys in securing its communication with different remote NVEs" This
>indicate each pair of NV will use a different to secure their communication. So,
>if a NVE has been compromised, it cannot impersonate other NVEs.
>
>group keys to secure NVE-NVE communication, control packets within
>different VNs SHOULD be secured with different keys " Therefore, if a NVE is
>> [Zu Qiang] again, The hypervisor/NVE may need one key to secure the
>> control plane communication with each other. Why you need per-VN key?
>> I agree with David's comment " both entities are multi-VN and
>> multi-tenant in scope.  " A per VN key is some kind overkilling.
>[Dacheng Zhang:]
>About this "If assuming the hypervisors can be compromised, the hypervisors
>belonging to different VNs MUST use different keys to secure the control
>packets exchanges with their NVE."
>
>each hypervisor MUST use different keys to secure its control packet
>exchanges with their NVE."
>
>
>
>>
>>  Have a nice day
>>  Zu Qiang
>> >>
>> >>
>> >> >From: [email-masked] [mailto:[email-masked]] On
>> >> >Behalf Of Black, David
>> >> >requirements draft (draft-ietf-nvo3-security-requirements-01), and
>> >> >I particularly appreciate the distinction that it makes between
>> >> >secure vs. insecure underlay networks as well as secure vs.
>> >> >insecure connectivity on the non-NVO3 side of NVEs - that
>> >> >distinction will be valuable in ensuring that the requirements are useful
>in practice.
>> >> >
>> >> >by the security draft.  I think that would be a good approach,
>> >> >Moreover, I think requirement 5 is flawed in its current form. I
>> >> >do understand the underlying motivation to limit the impact of NVE
>> >> >2) Moreover I don't think the concept of "tenant network" is
>> >> >useful for imposing security boundaries within the control plane
>> >> >for a single NVO3 domain.  Rather I'd suggest that the
>> >> >recommendation (at end of
>> >> requirement
>> >> >practice, if an attacker compromises an NVE, the attacker has
>> >> >access to all of the VNs that are authorized to that NVE,
>> >> >including those currently configured on it.  The goal should be to
>> >> >contain the compromise to that NVE and the VNs that it can affect
>> >> >- in particular, it would be very bad if NVE compromise could be
>> >> >escalated to NVA compromise (and one would also not want to see
>> >> >NVEs and the NVA (and possibly among NVA components if the NVA is
>> >> >not realized as a single component), not among tenants or VNs.
>> >> >
>> >> >3) REQ5-b recommends different keying material for each VN's
>> >> >control
>> >traffic.
>> >> >NVO3 is that a 12- bit .1Q VLAN tag isn't large enough.  An NVE in
>> >> >a hypervisor can reasonably expect to be involved in hundreds of
>> >> >VNs (or more), and the number for an NVE in a  top-of rack switch
>> >> >could be
>> >> >If someone really wants to build that scale of key management,
>> >> >fine, but this draft needs to allow authorization solutions (e.g.,
>> >> >access control lists at the NVA that limit which VNs can be used
>> >> >by each
>> >> >something significant about where the control plane traffic
>> >> >originates
>> from:
>> >> >
>> >> >The TS is the VM, which has no idea that NVO3 is being used, so
>> >> >the TS is not originating control plane traffic.  This requirement
>> >> >should also be rethought
>> >> in
>> >> >light of my above comment that I don't think tenants are a useful
>> >> >way to think about putting security boundaries within the NVO3 control
>plane.
>> >> >
>> >> >Thanks,
>> >> >--David

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 26 Oct 2013 02:30:36 +0000

> From: Zu Qiang [mailto:[email-masked]]
> Sent: Friday, October 25, 2013 10:17 PM
> To: Zhangdacheng (Dacheng); Black, David; [email-masked]
> 	I see big improvement in the new text. I had one more comment which I
> have given long time ago and repeat a few time during the email discussion. "
> considerations of what kind NVO3 architecture is going to be supported. " I did
> have the separation between each control plane interfaces and data plane in
> my draft (http://tools.ietf.org/html/draft-zu-nvo3-security-requirements-00).
> And I think this is the way the document shall be.
[Dacheng Zhang:] 
Sure, this is a very good idea. We will re-organize the contents in the next version according to this comment. Thanks a lot for you and David to point out the problems in the drafts. 

> 	For the key management on NVE-NVE, I hope you mean NVE-NVE data
> plane security. There is no NVE-NVE control plane specified in the current
> version of the architecture draft. Personally I also believe a NVE-NVE control
> plane may be needed. But from the discussion I had with Thomas Narten, my
> understanding is that it is not in the scope of the current NVO3 architecture
> discussion. So we may have to take the NVE-NVE control plane security
> requirement out from the security requirement draft for now.
[Dacheng Zhang:] 
That is very interesting. ^_^  According to Narten's instruction in Section 7.2 of the architecture draft ("Requirements for a direct NVE-NVA protocol can be found in
   [I-D.ietf-nvo3-nve-nva-cp-req]"), I had a look at the draft-ietf-nvo3-nve-nva-cp-req. There are some discussions about supporting multicast in section 3.2 of the cp requirement draft.-- " Each NVE needs a way to deliver multi-destination packets (i.e. tenant broadcast/multicast) within a given VN to each remote NVE which has a destination Tenant System for these packets. " So, I thought multicast should be a function required in the control plan protocol. 

Hope Narten can give us some more instructions. If there is no NVE-NVE control packet delivery, we can try to move this part of contents into the data plane security requirements. 

Cheers

Dacheng

> >> >> >   REQ11:  The key management solution MUST be able to confine
> the
> >> >> scope

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sat, 26 Oct 2013 03:01:44 +0000

> From: Black, David [mailto:[email-masked]]
> Sent: Friday, October 25, 2013 9:40 PM
> To: Zhangdacheng (Dacheng); Zu Qiang; [email-masked]
[Dacheng Zhang:] 

Fully agreed. The current discussion in the draft is not comprehensive enough. Will try to do that in the next version.

> using multiple keys for the same "tree".
[Dacheng Zhang:] 
This makes a lot of sense. I will integrate this into the discussion of the draft.

Thanks a lot for your comments. ^_^

Dacheng
> different
> NVE
> > In order to secure the communication between NVE-NVE control traffic. We
> can
> > provide at least two options.
> >
> different
> different
> Behalf

---

From: Sam Hartman <[email-masked]>
Date: Fri, 25 Oct 2013 09:44:28 -0400

>>>>> "Black," == Black, David <[email-masked]> writes:

    Black,> I would strongly suggest that the draft express the
    Black,> difference between securing NVO3 control functionality (VN
    Black,> configuration, attach, detach - NVE-NVA and
    Black,> NVE-server/hypervisor/end-device communication) and securing
    Black,> VN traffic among NVEs (security signaling in/for the data
    Black,> plane).

I agree.
We've been trying to separate data plane from control plane security,
and getting to a point where this is complete is desirable.

That said, I think it's important that our solution provide
comprehensive security for both.
The reason I think separation is important is that the tradeoffs in
deployment are different.
It may be the case that there end up being lower implementation
requirements for the data plane security, although in this world of
passive attacks, I actully think even data plane security ought to be
MUST implement.

However, more people will deploy control plane security, and that's a
reasonable deployment choice we should support.

--Sam