Hello, Authors
I like the way you have the requirements in bullets which is easier
for discussion. Some comments below:
- Section 4.3, it seems that "Insecure underlying network" concern is due
to the connection through the public network. So if there is no connection
through the public network or if the connection through the public network is
secured, the underlying network is considered as secured? If yes, there shall
be an requirement to protect the cross DC traffic.
- Is an insider attacker in NVA is in the scope of the security
consideration? Which requirements can help to prevent an insider NVA attacker?
Please make it clear.
- Insecure tenant network: why we assume the NVE is accessible to outside
attackers? Or this is only for some specific use cases? Please make it clear.
- Section 4.3, is compromised hypervisor in the scope of the security
consideration?
- Section 5.1 is for the NVA-NVE interface only? Otherwise there is
overlapping with section 5.2.
- R1 has a mutual authentication requirement on NVO3 devices. But it is
unclear that this mutual authentication requirement is on both sides or just
one side? I assume you mean both sides. Please make it clear.
- R2, are you proposing any authorization mechanisms other than address
filtering?
- R4b, it is better to explain how the NVEs may generate a large number
of responses if 1,2,3 and 4a are all a "MUST" requirements.
- R5, not clear if this is a requirement on NVE only or both NVA and NVE.
Is this a requirement on NVA-NVE control plane only? Please make it clear.
- R5a, per TS key is too much. Do you mean per VN key? Even with per VN
key, not sure if it is doable. You need key distribution in the NVE before a
new VN is configured. This is going to add many complicities in the control
plane signalling. In the current NVA-NVE control plane discussion, there are
two alternatives. If the NVE is configured by the NVA directly, per VN key does
not provide mush additional benefits. The NVE authentication and authorization
shall be good enough. The per-VN key may be needed if NVE-NVE control plane is
used. However the NVE-NVE control plane is not in the scope of the NVO3
architecture yet.
- R6a, it is better to use "should". Data plane has less security risk
compare to control plane. And this requirement is more important if the tenant
has a privacy concern.
- Section 5.1.2: Ingress filtering shall also apply on data plane, not
only control plane.
- Section 5.2, assuming you mean the control plane is between the
hypervisor and the NVE, not the TS-NVE.
- Both R8 and R9 are proposing using the address filtering for
authentication and authorization. Any other authorization mechanisms?
- R11, again, per TS key is too much. If R8/R9/R10 is implemented, the
control signalling between the hypervisor and the NVE is secured, a compromised
hypervisor will not be able to impersonate as other hypervisors or NVEs, what
is the goal to have per TS?
- R12, this is "should"
- Any needs to filter the tenant traffic?
Have a nice day
Zu Qiang
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On Behalf Of
>[email protected]
>Sent: Tuesday, October 22, 2013 11:11 AM
>To: [email protected]
>Cc: [email protected]
>Subject: [nvo3] I-D ACTION:draft-ietf-nvo3-security-requirements-01.txt
>
>A new Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Network Virtualization Overlays Working Group
>of the IETF.
>
> Title : Security Requirements of NVO3
> Author(s) : S. Hartman, et al
> Filename : draft-ietf-nvo3-security-requirements
> Pages : 16
> Date : 2013-10-22
>
> The draft provides a list of security requirements to benefit the
> design of NOV3 security mechanisms. In addition, this draft
> introduces the candidate techniques which could be used to fulfill
> such security requirements.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-nvo3-security-requirements-<http://www.ietf.org/internet-drafts/draft-ietf-nvo3-security-requirements-01.txt>
>01.txt<http://www.ietf.org/internet-drafts/draft-ietf-nvo3-security-requirements-01.txt>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the Internet-
>Draft.
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
