Subject: [nvo3] I-D ACTION:draft-ietf-nvo3-security-requirements-01.txt

From: [email-masked]
Date: Tue, 22 Oct 2013 08:11:20 -0700

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-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.

---

From: Zu Qiang <[email-masked]>
Date: Wed, 23 Oct 2013 13:31:57 +0000

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-masked] [mailto:[email-masked]] On Behalf Of

>[email-masked]

>Sent: Tuesday, October 22, 2013 11:11 AM

>To: [email-masked]

>Cc: [email-masked]

>Subject: [nvo3] I-D ACTION:draft-ietf-nvo3-security-requirements-01.txt

>This draft is a work item of the Network Virtualization Overlays Working Group

>of the IETF.

>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>

>implementation to automatically retrieve the ASCII version of the Internet-

>Draft.