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
>-----Original Message-----
>From: Zhangdacheng (Dacheng) [mailto:[email protected]]
>Sent: Thursday, October 24, 2013 10:40 PM
>To: Zu Qiang; Black, David; [email protected]
>Cc: Sam Hartman; Margaret Wasserman
>Subject: RE: Security requirements draft -01: REQ5 - Key Management
>
>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."
>
>
>
>>
>> Have a nice day
>> Zu Qiang
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >From: [email protected] [mailto:[email protected]] On
>> >> >Behalf Of Black, David
>> >> >Sent: Tuesday, October 22, 2013 4:42 PM
>> >> >To: [email protected]
>> >> >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.
>> >> >
>> >> >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 protected] Mobile: +1 (978) 394-7754
>> >> >----------------------------------------------------
>> >> >
>> >> >_______________________________________________
>> >> >nvo3 mailing list
>> >> >[email protected]
>> >> >https://www.ietf.org/mailman/listinfo/nvo3
>> >> _______________________________________________
>> >> nvo3 mailing list
>> >> [email protected]
>> >> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
