Hello, Dachang
I don't think we have the same understanding on the benefits and usage
of the per-VN key. Can you give more explanations why you think it is needed
for control plane? In my view one key per node is good enough. Even in data
plane, if we use VxLAN as an example, one L3 security tunnel will protect all
the NVE-NVE data traffic if the underlay network is considered as unsecured. A
per VN key only make sense if the tenant has privacy concern. In another word
it cannot be a must requirement.
More comments inline.
BR/Zu Qiang
>[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.
[Zu Qiang] the question I have is " When a NVA is compromised, is there a way
to mitigate the security damage? Maybe not. " The only protection, that NVO3 WG
can do, is to secure the NVA-NVE interface.
>
>> 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.
[Zu Qiang] Can you add the considerations of what kind NVO3 architecture is
going to be supported? It is unclear that the requirements in your draft are
for which NVO3 interface and which NVO3 node.
>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.
[Zu Qiang] the "address filtering based authorization" is referring to both
step 1 and step 3. Step 2 is optional if the underlay network is unsecured. For
all the three steps, you may need a key, but not a per-VN based, right?
>
>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. "
[Zu Qiang] wording: "the packet shall be discarded/rejected by the NVA."
>
>" 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. "
>
[Zu Qiang] by the way, are you going to change R5?
>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.
[Zu Qiang] My point is that per-VN key is not needed. The NVE may need one key
to secure the communication with NVA. Not sure what kind key deployment you are
referring?
>
>
>> 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."
[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.
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
