> I think we need to consider the issue that the underlying network is unsecure
> and an attacker can inject bogus messages with fake addresses into the
> communication between NVEs and the NVA.
>
> So, the steps for a NVA in processing a incoming packets may look like:
>
> 1) use ACL to process the packet, discard the packet if it is from an unknown
> address.
> 2) find a proper key to verify the integrity, authenticity, and freshness of
> the packet through the information transported in the packet header (e.g.,
> key ID).
> 3) find out whether the sender of the packet is authorized to send out this
> packet.
For clarity, step 2 applies *if* the underlying network is insecure.
It's not needed if one is prepared to trust the underlying network's
security (e.g., integrity, confidentiality, no replay).
> David has pointed out that I should not use TS in REQ11. So, the REQ11b
> should actually look like
> "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 have corrected this problem.
I strongly disagree with that rewording. The sort of security
implementation that I expect to see is a single TLS connection between
hypervisor and outboard NVE (e.g., in a top-of-rack switch) - both
entities are multi-VN and multi-tenant in scope. That appears to be
excluded by the rewording.
Picking up on Melinda's subsequent comment:
> Here's the
> question: in a scenario like the one under discussion, is it
> reasonable to assume that if you're sharing encryption/decryption/
> authentication keys with a peer, are operations requested by
> that peer then authorized? In other contexts we've used group
> keys/key groups as authorization groups (that is to say, if
> a given node is a member of a keying group, requests
> from it to other members of the group are authorized, and
> groups may be overlapping depending on authorization
> requirements). That said, it may be the case that you can
> share keys with a node of whom you are *not* authorized
> to make requests (or rather, the node is not authorized to
> honor your requests).
IMHO, it absolutely will be, especially if I restate that last
parenthetical comment for emphasis as "or rather the node is not
authorized to honor *all* of the requests that you could possibly
make.
My overriding concern with REQ5 and REQ11 is that they effectively
require some sort of key per authorization target design, and while
I don't object to such designs (although I question its scalability
in practice), I strongly object to mandating that design approach
to the exclusion of alternatives (e.g., ACLs), and REQ5 and REQ11
do exclude such alternatives as currently written.
One of the things that may be going on here is that there are two
sorts of control/signaling traffic involved when the data plane
between the NVEs requires security:
- NVO3 control traffic: hypervisors, NVEs and NVAs dealing
with VN configuration, attachment/detachment, etc.
- Data plane security signaling when the underlying network
is insecure. If IPsec is used between NVEs, IKE and
IKEv2 are examples.
The key management requirements in REQ5 make somewhat more sense for
the latter sort of traffic (reasoning from impact of session key
compromise), but even for that usage, the fact that the NVEs are
inherently multi-VN and multi-tenant (and probably don't have tenant
security credentials) suggests that REQ5 is probably still
overstated even for just data plane security signaling.
Thanks,
--David
> -----Original Message-----
> From: Zhangdacheng (Dacheng) [mailto:[email protected]]
> Sent: Thursday, October 24, 2013 2:38 AM
> To: Zu Qiang; Black, David; [email protected]
> Cc: Sam Hartman; Margaret Wasserman
> Subject: RE: Security requirements draft -01: REQ5 - Key Management
>
> Hi, Zu:
>
> Thanks a lot for your comments. They are very positive to improve the work.
>
> David's comments are very useful, I am thinking how to update the document
> according to his comments.
>
> See the inline please.
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of Zu
> > Qiang
> > Sent: Thursday, October 24, 2013 3:20 AM
> > To: Black, David; [email protected]
> > Subject: Re: [nvo3] Security requirements draft -01: REQ5 - Key Management
> >
> > 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. "
> [Dacheng Zhang:]
> In the current draft, we do mention NVE and NVA, and give some comments about
> using authorization mechanism to enforce the security of NVA. But I agree that
> it is a good advice to give a more detailed discussion about the security
> requirements of NVA. I believe we should pay more attention on protecting NVA
> since it is the critical component in the architecture.
>
> > 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.
> [Dacheng Zhang:]
> This approach has been indicated in the authentication and authorization
> requirements. I will try to present this idea more clearly.
>
> I have some concerns about the address filtering based authorization. Let's
> discuss this here.
>
> I think we need to consider the issue that the underlying network is unsecure
> and an attacker can inject bogus messages with fake addresses into the
> communication between NVEs and the NVA.
>
> So, the steps for a NVA in processing a incoming packets may look like:
>
> 1) use ACL to process the packet, discard the packet if it is from an unknown
> address.
> 2) find a proper key to verify the integrity, authenticity, and freshness of
> the packet through the information transported in the packet header (e.g.,
> key ID).
> 3) find out whether the sender of the packet is authorized to send out this
> packet.
>
> So, if your "address filtering based authorization" is performed in step 1,
> then I think it is not sufficient since we cannot jump over step 3.
>
> If the "address filtering based authorization" happens instep 3. Then we are
> thinking in the similar ways. Sure, if the address is stable, the address can
> also be used as the identifier of the network devices and then be used to
> locate the security policies. However, in a security mechanism, it is possible
> to use other IDs instead of address to identify a device and then find out the
> associated security policies. So, that is why we didn't claim that the
> authorization should be based on "address".
>
> So, in REQ2, there are the statements.
>
> " In addition, authorization is important for enforcing the VN isolation, a
> device only can distribute control packets within the VNs it is involved
> within. If a control packet about a VN is sent from a NVE which is not
> authorized to support the VN, the packet will not be accepted. "
>
> " Normally, it is assumed that the access control operations are based on the
> authentication results. The simple authorization mechanisms (such as ACLs
> which filters packets based on the packet addresses) can be used as auxiliary
> approaches since they are relatively easy to bypass if attackers can access to
> the network and modify packets. "
>
> Please let me know if you are happy with it. And please let me know if I
> understand your points correctly.
>
> > 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.
> [Dacheng Zhang:]
>
> Yes, if a NVE has compromised, it can send out bogus packets within the VNs
> which it has already involved within.
>
> I guess you mean " When a NVE is compromised, the address filtering based
> authorization may be enough to prevent the NVE on sending something which it
> is NOT supposed to send."
>
> Again, I assume the "address filtering based authorization" here is performed
> in step 3 rather than in step 1.
>
> I think this is dependent on how the keys are deployed to prevent an attacker
> to generated bogus packets.
>
> If group key management is used and all the NVEs use the same key in
> transporting control packets, then the attacker compromising a NVE can get the
> chance to impersonate other NVEs and sending out packets.
>
> That is why we think it may be worthwhile to give some discussion about the
> key management issues.
>
>
> > 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.
> [Dacheng Zhang:]
> David has pointed out that I should not use TS in REQ11. So, the REQ11b
> should actually look like
> "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 have corrected this problem.
>
> Thanks a lot again for your comments.
>
> Dacheng
>
> >
> > 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
