Hello,
First of all, I agree with David's comment. Just want to add one more
on top of it.
We cannot have a generic security requirement discussion without the
considerations of what kind NVO3 architecture is going to be supported. I have
given this comment weeks ago. And no response has been received.
So far there are only two alternatives are supported by the 01 version
of the architecture draft. The first one is that a NVE may "obtain necessary
information entirely through the hypervisor-facing side of the NVE." In this
case, "it is a natural extension to leverage the existing orchestration
protocol as a sort of proxy protocol for handling the interactions between an
NVE and the NVA." The second alternative is that " an NVE can obtain needed
information by interacting directly with an NVA via a protocol operating over
the data center underlay network. "
The NVO3 control plane security may be needed on a NVA-NVE control
signalling in the second alternative case. In this case, if we can assume that
the NVA has a participating NVEs list of a give VN configured (which is
required in section 7.3 of the architecture draft), this participating NVEs
list can be used for address filtering based authorization. So a node level
authentication plus address filtering based authorization may be enough to
secure the NVO3 control plane. This approach shall be allowed.
When a NVA is compromised, is there a way to mitigate the security
damage? Maybe not. When a NVE is compromised, the address filtering based
authorization may be enough to prevent the NVE on sending something which it is
supposed to send. But it is hard to prevent the compromised NVE when sending
control signalling of the attached VNs.
The NVO3 control plane security may be needed on a hypervisor-NVE
control signalling in the first alternative case when split-NVE case. Same
comments apply on the hypervisor-NVE interface.
I see the per TS or per VN based key management is overkilling. If
there is a benefit from the per TS or per VN based key management, which is not
described clearly in the draft, please clarify it.
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
