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 > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Zhangdacheng (Dacheng) > Sent: Thursday, October 24, 2013 10:40 PM > To: Zu Qiang; Black, David; [email protected] > Cc: Sam Hartman; Margaret Wasserman > Subject: Re: [nvo3] 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
