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
