Network Working Group                                         S. Hartman
Internet-Draft                                         Painless Security
Intended status: Experimental                                   D. Zhang
Expires: August 22, 2013                                          Huawei
                                                            M. Wasserman
                                                       Painless Security
                                                       February 18, 2013

                     Security Requirements of NVO3


   This draft discusses the security requirements and several issues
   which need to be considered in securing a virtualized data center
   network for multiple tenants.  In addition, the draft also attempts
   to discuss how such issues could be addressed or mitigated.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 22, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Hartman, et al.          Expires August 22, 2013                [Page 1]

Internet-Draft                NVO3 security                February 2013

   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Basic Security Requirements . . . . . . . . . . . . . . . . . . 5
     4.1.  Security Requirements Between NVEs and TESes  . . . . . . . 5
     4.2.  Security Requirements within Overlays . . . . . . . . . . . 6
       4.2.1.  Control Plan Security . . . . . . . . . . . . . . . . . 6
       4.2.2.  Data Plan Security  . . . . . . . . . . . . . . . . . . 7
   5.  Security Issues Imposed by the New Overlay Design
       Characteristics . . . . . . . . . . . . . . . . . . . . . . . . 7
     5.1.  Scalability Issues  . . . . . . . . . . . . . . . . . . . . 7
     5.2.  Influence on Security Devices . . . . . . . . . . . . . . . 8
     5.3.  Security Issues with VM Migration . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Hartman, et al.          Expires August 22, 2013                [Page 2]

Internet-Draft                NVO3 security                February 2013

1.  Introduction

   In [I-D.ietf-nvo3-overlay-problem-statement], it is indicated that
   there multiple properties that a virtualized data center network for
   multiple tenants may need to provide ( e.g., large amounts of tenant
   end devices (TESes), the support of TES (e.g., VM) migration, and
   dynamic network provisioning).  This draft introduces the basic
   security requirements for such a data center network and introduce
   several security issues brought by the new features.

   The remainder of this document is organized as follows.  (Section 3)
   introduces the the attack model of this work and the properties that
   a NOV3 security mechanism needs to enforce.  Section 4 describes the
   essential security requirements which should be fulfilled in the
   generation of a virtual data center network supporting multiple
   tenants.  Then, in Section 5, we analyze the challenges brought by
   the new features mentioned

2.  Terminologies

   Tenant End System (TES): An end system of a tenant, which can be,
   e.g., a virtual machine(VM), a non-virtualized server, or a physical
   appliance.  A TES is attached to a Network Virtualization Edge(NVE)

   Network Virtualization Edge(NVE): An NVE implements network
   virtualization functions that allow for L2/L3 tenant separation,
   tenant-related control plane activity.  An NVE contains one or more
   tenant service instances whereby a TES interfaces with its associated
   instance.  The NVE also provides tunneling overlay functions.

   Virtual Network Instance (VNI): This is one instance of a virtual
   overlay network.  Two Virtual Networks are isolated from one another
   and may use overlapping addresses.

3.  Threat Model

   In the analysis, it is assumed that an attacker has the capability of

   1.  intercepting the packets transported through a virtual data
       center network,

   2.  replaying the intercepted packets, and

Hartman, et al.          Expires August 22, 2013                [Page 3]

Internet-Draft                NVO3 security                February 2013

   3.  generating fake packets and injecting them into the network.

   When using the above capability to perform a successful attack on a
   virtual data center network, an attacker may be able to

   1.  obtain the data which it is un-authorized to access,

   2.  analyze the traffic pattern of a tenant or a end device, or

   3.  disrupt and degrade the service quality of the network.

   Under the attacks performed by an attacker, a virtual data center
   network MUST guarantee the following security properties:

   1.  Isolation of the VNIs.  Isolation benefits not only in
       simplifying managemt operations but also in confining the damages
       of attacks.In [I-D.ietf-nvo3-overlay-problem-statement], the data
       plane isolation amongst different VNIs has been discussed.  The
       traffic within a virtual network can only be transited into
       another one in a controlled fashion (e.g., via a configured
       router and/or a security gateway).  Apart from that, the control
       plane isolation in the overlay is also very important.  That is,
       an entity cannot make use of its privilege obtained within a VNI
       to manipulate the overlay control plane to affect on the
       operations of other VNIs.

   2.  Integrity and origin authentication of the control plane: All the
       control panel implementations of the overlay MUST support the
       integrity protection on the signaling packets.  No entity can
       modify a overlay signaling packet during its transportation
       without being detected.  Also, an attacker cannot impersonate a
       legal victim (e.g., a NVE or another servers within the overlay)
       to send signaling packets without detection.

   3.  Availability of the control plane: The design of the control plan
       must consider the DDOS attacks.  Especially, when there are
       centralized servers in the control plan of the overlay, the
       servers must be well protected and make sure that they will not
       become the bottle neck of the control plane especially under DDOS

   And the following properties SHOULD be optionally provided:

   1.  Confidentiality and integrity of the TES traffic.  In some
       conditions, the cryptographic protection on the TES traffic is
       not necessary.  For example, if most of the TES data is headed
       towards the Internet and nothing is confidential, encryption is
       redundant.  In addition, in the cases where the underlay network

Hartman, et al.          Expires August 22, 2013                [Page 4]

Internet-Draft                NVO3 security                February 2013

       is secure enough, no additional cryptographic protection needs to
       be provided.

   2.  Confidentiality of the control plane.  On many occasions, the the
       signaling messages can be transported in plaintext.  However,
       when some information contained within the signaling messages are
       sensitive to a tenant (e.g., the location of a TES, when a TES
       migration happens), the signaling messages related with that
       tenant should be encrypted.

   Note that the following two types of attacks is out of the scope of
   this draft: the attacks taking advantage of social engineering, and
   the attacks taking advantage of the weak security algorithms, the
   drawbacks of security protocols, or the loopholes of security
   implementations.  In addition, NOV3 assumes all the NVO3 overlay is
   within a administration domain, and so there is no issue with
   federated authentication and authorization.

4.  Basic Security Requirements

4.1.  Security Requirements Between NVEs and TESes

   A NVE and the TESes it supports can be deployed in a distributed way
   (e.g., a NVE is implemented in an individual device, and VMs are
   located on servers) or in a co-located way (e.g., a NVE and the VMs
   it serves are located on the same server).

   In the former case, the packets between the NVE and the TESes are
   exchanged over a network.  If the network connecting the NVE and the
   TESes is potentially accessible to attackers, the protection on the
   the security properties including the integrity, the confidentiality,
   and the message origin authenticity of the data traffic of TESes
   SHOULD be provided, e.g., by IPsec, SSL, and etc., according to
   different security requirements.  In addition, in the conditions
   where there are signaling messages exchanged between the NVE and the
   end devices (e.g., VMs or hypervisors) for the purposes of, e.g., VM
   online detection or VM migration detection, the integrity of the
   those packets MUST be ensured since such messages may be used to the
   state of the NVE and then be distributed across the overlay.  The end
   devices sending the signaling messages SHOULD be authenticated, and
   only the signaling messages from the authorized TESes will be
   accepted.  In addition, it is important to guarantee the isolation
   between different VNIs.  If a NVE supports multiple NVIs
   concurrently, the traffic of the TESes in different VNIs must be
   separated physically or by e.g., VLAN.  In addition, to confine the
   damage caused by a compromised TES, A TES in a VNI is not allowed to
   distribute the information about other VNIs.  For instance, When a

Hartman, et al.          Expires August 22, 2013                [Page 5]

Internet-Draft                NVO3 security                February 2013

   NVE receives an address mapping information, the NVE must guarantee
   the information is from an authorized entity before updating its
   mapping table.

   In the latter case, all the communication between the NVE and the
   TESes are located within the same device.  It is also important to
   keep the isolation of the TES traffic in different VNIs.  In
   addition, in the co-location fashion, because the NVE, the
   hypervisor, and the VMs are deployed on the same device, the
   computing and memory resources of the NVE , the hypervisor, and the
   TESes need to be isolated to prevents a malicious or compromised TES
   from accessing the memory of the NVE or affecting the performance of
   the NVE by occupying large amounts of computing resources.

4.2.  Security Requirements within Overlays

   This section discusses the security issues within a virtual data
   center overlay in the control plan and the data plan respectively.

4.2.1.  Control Plan Security

   In an overlay, the signaling messages must be transported over the
   underlay network in a secure way, the integrity and origin
   authentication of the messages must be guaranteed.  The signaling
   packets should also be encrypted if the signaling messages are

   The issues of DDOS attacks also need to be considered in designing
   the overlay control plane.  For instance, in the VXLAN
   solution[I-D.mahalingam-dutt-dcops-vxlan], an attacker attached to a
   NVE can try to manipulate the NVE to keep multicasting messages by
   sending ARP packets to query the VMs which does not exist.  In order
   to mitigate this type of attack, the NVEs SHOULD be only allowed to
   send signaling message in the overlay with a limited frequency.  When
   there are centralized servers (e.g., the backend oracles providing
   mapping information for
   NVEs[I-D.ietf-nvo3-overlay-problem-statement], or the SDN
   controllers) are located within the overlay, the potential security
   risks caused by DDOS attack on such servers can be more serious.

   When considering inside attacks where one or more NVEes are
   compromised, authentication between the communicating entities within
   the overlay (NVEs, the centralized servers) is important.  Only the
   control messages from the authenticated entity will be adopted.  In
   addition, authorization MAY need to be performed.  For instance, when
   a NVE receives a control message about the operations in a VNI, the
   NVE needs to verify whether the message comes from one which is
   authorized to work for that VNI.  If the authentication or the

Hartman, et al.          Expires August 22, 2013                [Page 6]

Internet-Draft                NVO3 security                February 2013

   authorization fail, the control message will be discarded.  In order
   enforce the security boundary of different VNIs, the signaling
   messages of different VNIs need be protected by different keys.
   Otherwise, a compromised NVE could use the key it got within a VNI to
   impersonate the NVEs in other VNIs which it is not involved within
   and generate fake signaling messages without being detected.  If we
   expect to provide a better attack confinement capability and prevent
   a compromised NVE to impersonate other NVEs in the same VNI,
   different NVEs working inside a NVI need to secure their signaling
   messages with different keys.  When there are centralized servers
   providing mapping information within the overlay, it will be
   important to prevent a compromised NVE from impersonating the
   centralized servers to communicate with other NVEs.  A
   straightforward solution is to associate different NVEs with
   different keys when they exchange information with the centralized
   servers.  Since the NVO3 overlay is expected to consist of a large
   amount of NVEs, manual key management could be infeasible.  First, it
   becomes burdensome to deploy pre-shared keys for thousands of NVEs,
   not to mention that multiple keys may need to be deployed on a single
   device for different purposes.  Key derivation can be used to
   mitigate this problem.  That is, multiple keys are derived from a
   pre-shared master key for different usuages.  However, key derivation
   cannot protect against the situation where a system was incorrectly
   trusted to have the key used to perform the derivation.  If the
   master key were somehow compromised, all the resulting keys would
   need to be changed.  In addition, TES migration will also introduce
   challenges to manual key management.  The migration of a VM in a VNI
   may cause the change of the NVEs which are involved within the NVI.
   A NVE newly involved within a VNI needs to get the key to join the
   operations within the VNI.  A NVE no longer supporting a VNI should
   not keep the key associated with that VNI.  All those updates of the
   key are performed at run time and difficult to be performed by human
   beings.  As a result, it is feasible to introduce an auto key
   management solution for NVO3 overlays.

4.2.2.  Data Plan Security

   As illustrated in Section 3, the security of data plan is optionally

5.  Security Issues Imposed by the New Overlay Design Characteristics

5.1.  Scalability Issues

   NOV3 WG requires an overlay be able to work in an environment where
   there are many thousands of NVEs (e.g. residing within the
   hypervisors) and large amounts of trust domains (VNIs).  Therefore,

Hartman, et al.          Expires August 22, 2013                [Page 7]

Internet-Draft                NVO3 security                February 2013

   the scalability issues should be considered.  In the cases where a
   NVE only has a limited number of NVEs to communicate with, the
   scalability problem brought by the overhead of generating and
   maintaining the security channels with the remote NVEs is not
   serious.  However, if a NVE needs to communicate with a large number
   of peers, the scalability issue could be serious.  For instance,
   in[I-D.ietf-ipsecme-ad-vpn-problem], it has been demonstrated it is
   not trivial to enabling a large number of systems to communicate
   directly using IPsec to protect the traffic between them.

5.2.  Influence on Security Devices

   If the data packets transported through out an overlay are encrypted
   (e.g., by NVEs), it is difficult for a security device, e,g., a
   firewall deployed on the path to intercept the contents of the
   packets.  The firewall can only know which VNI the packets belong to
   through the VNID transported in the outer header.  If a firewall
   would like to identify which end device sends a packets or which end
   device a packet is sent to, the firewall can be deployed in some
   place where it can access the packet before it is encapsulated or un-
   encapsulated by NVEs.  However, in this case, the firewall cannot get
   VN ID from the packet.  If the firewall is used to process two VNIs
   concurrently and there are IP or MAC addresses of the end devices in
   the two VNIs overlapped, confusion will be caused.  If a firewall can
   generate multiple firewalls instances for different tenants
   respectively, this issue can be largely addressed.

5.3.  Security Issues with VM Migration

   The support of VM migration is an important issue considered in NVO3
   WG.  The migration may also cause security risks.  Because the VMs
   within a VNI may move from one server to another which connects to a
   different NVE, the packets exchanging between two VMs may be
   transferred in a new path.  If the security policies deployed on the
   firewalls of the two paths are conflict or the firewalls on the new
   path lack essential state to process the packets.  The communication
   between the VMs may be broken.  To address this problem, one option
   is to enable the state migration and policy confliction detection
   between firewalls.  The other one is to force all the traffic within
   a VNI be processed by a single firewall.  However this solution may
   cause traffic optimization issues.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

Hartman, et al.          Expires August 22, 2013                [Page 8]

Internet-Draft                NVO3 security                February 2013


7.  Security Considerations


8.  Acknowledgements

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

              Hanna, S. and V. Manral, "Auto Discovery VPN Problem
              Statement and Requirements",
              draft-ietf-ipsecme-ad-vpn-problem-03 (work in progress),
              December 2012.

              Narten, T., Gray, E., Black, D., Dutt, D., Fang, L.,
              Kreeger, L., Napierala, M., and M. Sridharan, "Problem
              Statement: Overlays for Network Virtualization",
              draft-ietf-nvo3-overlay-problem-statement-02 (work in
              progress), February 2013.

              Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
              Framework for Overlaying Virtualized Layer 2 Networks over
              Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02
              (work in progress), August 2012.

Hartman, et al.          Expires August 22, 2013                [Page 9]

Internet-Draft                NVO3 security                February 2013

Authors' Addresses

   Sam Hartman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845


   Dacheng Zhang


   Margaret Wasserman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845

   Phone: +1 781 405 7464

Hartman, et al.          Expires August 22, 2013               [Page 10]