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
