> -----Original Message----- > From: Black, David [mailto:[email protected]] > Sent: Friday, October 25, 2013 9:40 PM > To: Zhangdacheng (Dacheng); Zu Qiang; [email protected] > Cc: Sam Hartman; Margaret Wasserman > Subject: RE: Security requirements draft -01: REQ5 - Key Management > > 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). > [Dacheng Zhang:]
Fully agreed. The current discussion in the draft is not comprehensive enough. Will try to do that in the next version. > 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". [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 > > 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
