> -----Original Message-----
> From: Zu Qiang [mailto:[email protected]]
> Sent: Friday, October 25, 2013 10:17 PM
> To: Zhangdacheng (Dacheng); Black, David; [email protected]
> Cc: Sam Hartman; Margaret Wasserman
> Subject: RE: Security requirements draft -01: REQ5 - Key Management
>
> 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.
[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 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.
[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
>
> 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
