Network Working Group                                         S. Hartman
Internet-Draft                                         Painless Security
Intended status: Experimental                                   D. Zhang
Expires: April 02, 25, 2014                                           Huawei
                                                            M. Wasserman
                                                       Painless Security
                                                      September 29,
                                                        October 22, 2013

                     Security Requirements of NVO3
                draft-ietf-nvo3-security-requirements-00
                draft-ietf-nvo3-security-requirements-01

Abstract

   This

   The draft discusses the provides a list of security requirements and several issues
   which need to be considered in securing a virtualized data center
   network for multiple tenants (a NVO3 network for short). benefit the
   design of NOV3 security mechanisms.  In addition, the this draft also attempts to discuss how such issues
   introduces the candidate techniques which could be
   addressed or mitigated. used to fulfill
   such security requirements.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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 http://datatracker.ietf.org/drafts/current/.

   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 April 02, 25, 2014.

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
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  NVO3 Overlay Architecture . . . . . . . . . . . . . . . . . .   4   3
   4.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Outsider Capabilities . . . . . . . . . . . . . . . . . .   5   4
     4.2.  Insider Capabilities  . . . . . . . . . . . . . . . . . .   5
     4.3.  Security Properties . . . . . . . . . . . Issues In Scope and Out of Scope . . . . . . . .   6   5
   5.  Basic  Security Requirements and Candidate Approaches  . . . . . . . . . . . . . . . . . .   7   6
     5.1.  Securing the Communications between NVEs and TSes  Control/Data Traffic within Overlay . . . .   7
     5.2.  Securing the Communications within Overlays . . . . . . .   8
       5.2.1.   6
       5.1.1.  Control Plane Security  . . . . . . . . . . . . . . .   8
       5.2.2.   6
       5.1.2.  Data Plan Security  . . . . . . . . . . . . . . . . .  10
   6.  Security Issues Imposed by the New Overlay Design
       Characteristics . . . . . . . . . . . . . Plane  . . . . . . . . . .  11
     6.1.  Scalability Issues . . . . . . . . . . .   9
     5.2.  Control/Data Traffic between NVEs and Hypervisors . . . .  10
       5.2.1.  Distributed Deployment of NVE and Hypervisor  . . . .  11
     6.2.  Influence on Security Devices . . . . .
     5.3.  Key Management  . . . . . . . . .  11
     6.3.  Security Issues with VM Migration . . . . . . . . . . . .  11
   7.  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  14
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10.  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     10.2.  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13  16

1.  Introduction

   Security is the a key issue which needs to be considered in the design of
   a data center network.  This document first lists discusses the security risks
   that a NVO3 network may encounter and the security requirements that
   a NVO3 network need needs to fulfill.  Then,  In addition, this draft discusses attempts to
   discuss the
   essential security approaches techniques which could be applied to fulfill
   such requirements.

   The remainder of this document is organized as follows.  (Section 4)  Section 2
   introduces the terms used in this memo.  Section 3 gives a briefly
   introduction of the NVO3 network architecture.  Section 4 discusses
   the attack model of this work and the properties that a
   NOV3 security mechanism needs to enforce. work.  Section 5 describes the essential
   security mechanisms requirements which should be provide fulfilled in the generation of
   a NVO3 network.  Then, in Section 6, we analyze the
   challenges brought by the new features mentioned
   in[I-D.ietf-nvo3-overlay-problem-statement].

2.  Terminology

   This document uses the same terminology as found in the NVO3
   Framework document [I-D.ietf-nvo3-framework] and
   [I-D.kreeger-nvo3-hypervisor-nve-cp].  Some of the terms defined in
   the framework document have been repeated in this section for the
   convenience of the reader, along with additional terminology that is
   used by this document.

   Tenant System (TS): A physical or virtual system that can play the
   role of a host, or a forwarding element such as a router, switch,
   firewall, etc.  It belongs to a single tenant and connects to one or
   more VNs of that tenant.

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

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

   Virtual Network (VN): This is a virtual L2 or L3 domain that belongs
   to a tenant.

   Information Mapping

   Network Virtualization Authority (IMA). (NVA).  A back-end system that is
   responsible for distributing and maintaining the mapping information
   for the entire overlay system.  Note that the WG never reached
   consensus on what to call this architectural entity within the
   overlay system, so this term is subject to change.

   NVO3 device: In [I-D.ietf-nvo3
   -overlay-problem-statement], such a back-end system is referred this memo, the devices (e.g., NVE and NVA) work
   cooperatively to provide NVO3 overlay functionalities are called as
   a "oracle".
   NOV3 devices.

3.  NVO3 Overlay Architecture

          Please view in a fixed-width font such as Courier.

          Please view in a fixed-width font such as Courier.
                      ..................................
                      .                                .
                      .                                .
                      .                                .
                    +-+--+                          +--+-++--------+
    +--------+      | NV |                          | NV || Tenant |
    | Tenant +------+Edge|       L3 Overlay         |Edge|| System |
    | System |      +-+--+        Network           +--+-++--------+
    +--------+        .                                .
                      .                                .
                      .                                .
                      ..................................

   This figure illustrates a simple nov3 overlay example where NVEs
   provide a logical L2/L3 interconnect for the TSes that belong to a
   specific tenant network over L3 networks.  A packet from a tenant
   system is encapsulated when they reach the egress NVE.  Then
   encapsulated packet is then sent to the remote NVE through a proper
   tunnel.  When reaching the ingress NVE, the packet is decapsulated
   and forwarded to the target tenant system.  The address
   advertisements and tunnel mappings are distributed amonge among the NVEs
   through either distributed control protocols or by certain
   centralized servers (called Information Mapping Authorities). NVAs).

4.  Threat Model

   To benefit the discussion, in this analysis work, attacks are
   classified into two categories: inside attacks and outside attacks.
   An attack is considered as an inside attack if the adversary
   performing the attack (inside attacker or insider) has got certain
   privileges in changing the configuration or software of a NVO3 device
   (or a network devices of the underlying network where the overlay is
   located upon)
   and initiates the attack within the overlay security perimeter.  In
   contrast, an attack is referred to as an outside attack if the
   adversary performing the attack (outside attacker or outsider) has no
   such privilege and can only initiate the attacks from compromised TSes.
   TSes (or the network devices of the underlying network which the
   overlay is located upon).  Note that in a complex attack inside and
   outside attacking operations may be performed in a well organized way
   to expand the damages caused by the attack.

   This analysis assumes that security protocols, algorithms, and
   implementations provide the security properties for which they are
   designed; attacks depending on a failure of this assumption are out
   of scope.  As an example, an attack caused by a weakness in a
   cryptographic algorithm is out of scope, while an attack caused by
   failure to use confidentiality when confidentiality is a security
   requirement is in scope.

4.1.  Outsider Capabilities

   The following capabilities of outside attackers MUST be considered in
   the design of a NOV3 security mechanism:

   1.  Eavesdropping on the packets,
   2.  Replaying the intercepted packets, and

   3.  Generating illegal packets and injecting them into the network.

   With a successful outside attack, an attacker may be able to:

   1.  Analyze the traffic pattern of a tenant or an end device, within the network,

   2.  Disrupt the network connectivity or degrade the network service
       quality, or

   3.  Access the contents of the data/control packets if they are not
       properly encrypted.

4.2.  Insider Capabilities

   It is assumed that an inside attacker can perform any types of
   outside attacks from the inside or outside of the overlay perimeter.
   In addition, in an inside attack, an attacker may use already
   obtained privilege to, for instance,

   1.  Interfere with the normal operations of the overlay as a legal
       entity, by sending packets containing invalid information or with
       improper frequencies,

   2.  Perform spoofing attacks and impersonate another legal device to
       communicate with victims using the cryptographic information it
       obtained, and

   3.  Access the contents of the data/control packets if they are
       encrypted with the keys held by the attacker.

   Note that in practice an insider controlling an underlying network
   device may break the communication of the overlays by discarding or
   delaying the delivery

4.3.  Security Issues In Scope and Out of Scope

   During the packets passing through it.  However,
   this type of attack is out specification of scope.

4.3.  Security Properties

   When encountering an attack, a virtual data center network MUST
   guarantee security requirements, the following
   security properties: issues needs to be considered:

   1.  Isolation of the VNs: In
       [I-D.ietf-nvo3-overlay-problem-statement], the data plane
       isolation requirement amongst different VNs has been discussed.
       The traffic within  Insecure underlying network.  It is normally assumed that a virtual
       underlying network can only connecting NOV3 devices (NVEs and NVAs) is
       secure if it is located within a data center and cannot be transited into
       another one
       directly accessed by tenants.  However, in a controlled fashion (e.g., via virtual data center
       scenario, a configured
       router and/or NVO3 overlay scatters across different sites which
       are connected through the public network.  Outside attacks may be
       raised from the underlying network.

   2.  Insider attacker.  During the design of a security gateway).  In addition, it MUST be
       ensured that an entity cannot make solution for a
       NVO3 network, the inside attacks raised from compromised NVO3
       devices (NVEs and NVAs) needs to be considered.

   3.  Insecure tenant network.  It is reasonable to consider the
       conditions where the network connecting TSes and NVEs is
       accessible to outside attackers.

   The following issues are out of scope of cosideration in this
   document:

   1.  In this memo it is assumed that security protocols, algorithms,
       and implementations provide the security properties for which
       they are designed; attacks depending on a failure of this
       assumption are out of scope.  As an example, an attack caused by
       a weakness in a cryptographic algorithm is out of scope, while an
       attack caused by failure to use confidentiality when
       confidentiality is a security requirement is in scope.

   2.  In practice an attacker controlling an underlying network device
       may break the communication of the overlays by discarding or
       delaying the delivery of the packets passing through it.
       However, this type of attack is out of scope.

5.  Security Requirements and Candidate Approaches

   This section introduces the security requirements and candidate
   solutions.

5.1.  Control/Data Traffic within Overlay

   This section analyzes the security issues in the control and data
   plans of a NVO3 overlay.

5.1.1.  Control Plane Security

   REQ1:  A NVO3 security solution MUST enable two NOV3 devices (NVE or
      NVA) to perform mutual authentication before exchanging control
      packets.

      This requirement is used to prevent an attacker from impersonating
      a legal NVO3 device and sending out bogus control packets without
      being detected.

      The authentication between devices can be performed as a part of
      automated key management protocols (e.g., IKEv2[RFC5996],
      EAP[RFC4137], etc.).  After such an authentication procedure, an
      device can find out whether its peer holds valid security
      credentials and is the one who it has claimed.  Additionally, the
      keys shared between the devices can be also used for the
      authentication purpose.  For instance, assumed a NVE and a NVA
      have shared a secret key without known by any other third parties.

      The NVE can ensure that a device that it is communicating with is
      the NVA if the device can prove that it possesses the shared key.

      a: The identity of the network devices SHOULD be verified during
      authentication.

      In some authentication mechanisms, instead of verifying the peers'
      identities, the authentication result can only prove that a device
      joining the authentication is a legal member of a group.  However,
      for a better damage confining capability to insider attacker, it
      is recommended to verify the devices' identities during
      authentication.  Therefore, an insider attacker cannot impersonate
      others, even when it holds legal credentials or keys.

   REQ2:  Before accepting a control packet, the device receiving the
      packet MUST verify whether the packet comes from one which has the
      privilege obtained to send that packet.

      This is an authorization requirement.  A device needs to clarify
      the roles (e.g., a NVE or a NVA) that its authentication peer acts
      as in the overlay.  Therefore, if a compromised NVE uses it
      credentials to impersonate a NVA to communicate with other NVEs,
      it will be detected.  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 manipulate 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.

   REQ3:  Integrity, confidentiality, and origin Authentication
      protection for Control traffics

      It is the responsibility of a NVO3 overlay to protect the control
      packets transported over the overlay against the attacks raised
      from the underlying network.

      a: The integrity and origin authentication of the packets MUST be
      guaranteed.

      With this requirement, the receiver can ensure that the packets
      are from the legitimate sender, not replayed, and not modified
      during the transportation.

      b: The signaling packets SHOULD be encrypted.

      On many occasions, the signaling packets can be transported in
      plaintext.  However, In the cases where the information contained
      within the signaling packets are sensitive or valuable to
      attackers , the signaling packets related with that tenant need be
      encrypted.

      To achieve such objectives, when the overlay network devices exchange
      control plane packets, integrated security mechanisms or
      underlying security protocols need to affect on
       the operations of other VNs.

   2.  Spoofing detection: Under the attacks performed by a privileged
       inside attacker, the attacker cannot use the obtained provided.  In addition,
      cryptographic materials keys need to impersonate another one.

   3.  Integrity protection and message origin authentication be deployed manually in advance or
      dynamically generated by using certain automatic key management
      protocols (e.g., TLS [RFC5246]).  The keys are used to generate
      digests for the or encrypt control packets: packets.

   REQ4:  The implementation toleration of an overlay DOS attacks

      a: Frequency in distributing control plane packets within in the overlay
      MUST support be limited.

      The issues within DOS attacks also need to be considered in
      designing the integrity protection on overlay control plane.  For instance, in the signaling packets.
       No entity VXLAN
      solution[I-D.mahalingam-dutt-dcops-vxlan], an attacker attached to
      a NVE can modify try to manipulate the NVE to keep multicasting control
      packets by sending a overlay large amount of ARP packets to query the
      inexistent VMs.  In order to mitigate this type of attack, the
      NVEs SHOULD be only allowed to send signaling packet during its
       transportation without being detected.  Also, an attacker cannot
       impersonate in the
      overlay with a legal victim limited frequency.  When there are centralized
      servers (e.g., a NVE the backend oracles providing mapping information
      for NVEs[I-D.ietf-nvo3-overlay-problem-statement], or another servers the SDN
      controllers) are located within the overlay) overlay, the potential
      security risks caused by DDOS attack on such servers can be more
      serious.

      b: Mitigation of amplification attacks SHOULD be provided.

      During the design of the control plane, it is important to
      consider the amplification effects.  For instance, if NVEs may
      generate a large response to a short request, an attacker may send signaling packets without detection.

   4.  Availability of
      spoofed requests to the NVEs with the control plane: The design source address of a victim.
      Then the control plan
       must consider NVEs will send the response to the DoS/DDoS victim and result in
      DDOS attacks.  Especially when there are
       centralized servers

      If the amplification effect cannot be avoided in the control plan
      protocol, the requirements 1,2,3, and 4a can all be used to
      benefit the mitigation of this type of attacks.

   REQ5:  The key management solution MUST be able to confine the overlay, scope
      of key distribution and provide different keys to isolate the
       servers need
      control traffic according to different security requirements.

      a: It SHOULD be well protected and make sure guaranteed that they different keys are used to secure
      the control packets exchanged within different tenant networks.

      This requirement can be used to provide a basic attack confinement
      capability.  The compromise of a NVE working within a tenant will
      not become result in the bottle neck key leakage of other tenant networks.

      b: It SHOULD be guaranteed that different keys are used to secure
      the control plane especially under
       DDOS attacks.

   The following properties SHOULD packets exchanges with different VNs.

      This requirement can be optionally provided:

   1.  Confidentiality and integrity of used to provide a better attack
      confinement capability for the data traffic control plane.  The compromise of TSes.  In
       some conditions, the cryptographic protection on the TS traffic
       is a
      NVE working within a VN will not necessary.  For example, if most of result in the ES data key leakage of
      other VNs.  However, since there is headed
       towards only a single key used for
      securing the Internet and nothing is confidential, encryption or
       integrity protection on such data traffic within a VN, an attacker which has
      compromised a NVE within the VN may be unnecessary. able to impersonate any
      other NVEs within the VN to send out bogus control packets.  In
      addition, in the cases where the underlay network is secure
       enough, no additional cryptographic protection key management overheads introduced by key
      revocation also need to be considered[RFC4046].  When a NVE stops
      severing a VN, the key used for the VN needs to be
       provided.

   2.  Confidentiality of the control plane.  On many occasions, the
       signaling messages can revoked, and a
      new key needs to be transported in plaintext.  However,
       when distributed for the information contained NVO3 devices still within
      the signaling messages are
       sensitive or valuable VN.

      If we expect to attackers (e.g., the location of provide a ES,
       when even stronger confinement capability and
      prevent a VM migration happens), compromised NVE from impersonating other NVEs even when
      they are in the same VN, different NVEs working inside a VN need
      to secure their signaling messages related packets with
       that tenant SHOULD be encrypted.

5.  Basic Security Approaches

   This section introduces different keys.

      If there is automated key management deployed, the security mechanisms which could authentication
      and authorization can be used to provided in order to guarantee largely mitigate the security properties mentioned
   in section 4 when encountering attacks.

5.1.  Securing isolation
      issues.  When a NVE attempts to join a VN, the Communications between NVEs NVE needs to be
      authenticated and TSes

   Assume there is a VNE providing prove that it have sufficient privileges.  Then,
      a logical L2/L3 interconnect for new key (or a set of TSes.  Apart from keys) will be generated to secure its
      control packet exchanged with this VN.

5.1.2.  Data Plane

   [I-D.ietf-nvo3-framework] specifies a NVO3 overlay needs to generate
   tunnels between NVEs for data traffics, transportation.  When a data packet
   reaches the NVE boundary of a overlay, it will be encapsulated and the TSes also
   need to exchange signaling messages in order
   forwarded to facilitate, e.g., VM
   online detection, VM migration detection, or auto-provisioning/
   service discovery [I-D.ietf-nvo3-framework].

   The the destination NVE through a proper tunnel.

   REQ6:  Integrity, confidentiality, and its associated TSes can origin authentication
      protection for data traffics
      a: The integrity and origin authentication of data traffics MUST
      be deployed in a distributed way
   (e.g., a NVE guaranteed when the underlying network is implemented in not secure.

      During the transportation of data packets, it is the
      responsibility of the NVO3 overlay to deal with the attacks from
      the underlying network.  For instance, an individual device, and VMs are
   located on servers) or in inside attacker
      compromising a co-located way (e.g., underlying network device may intercept an
      encapsulated data packet transported within a NVE and tunnel, modify the TSes
      contents in the encapsulating tunnel packet and, transfer it serves are located on into
      another tunnel without being detected.  When the same server).

   In modified packet
      reaches a NVE, the former case, NVE may decapsulated the data packet and control traffic between the NVE and
   the TSes are exchanged over network.  If
      forward it into a VN according to the NVE supports multiple
   VNs concurrently, information within the data/control traffics in different VNs MUST be
   isolated physically or
      encapsulating header generated by using VPN technologies.  If the network
   connecting the attacker.  Similarly, a
      compromised NVE and may try to redirect the TSes is potentially accessible data packets within a VN
      into another VN by adding improper encapsulating tunnel headers to
   attackers,
      the security properties of data traffic (e.g., integrity,
   confidentiality, and message origin authenticity) SHOULD be provided.
   The security mechanisms packets.

      Under such as IPsec, SSL, and TCP-AO, can be used
   according to different security requirements.

   In circumstances, in order to guarantee enforce the integrity VN isolation
      property, underlying security protocols need to provided.
      Signatures or digests need to be generated for both data packets
      and the encapsulating tunnel headers in order to provide data
      origin authentication and integrity protection.

      b: The confidentiality protection of
   signaling messages, integrated security mechanisms or additional
   security protocols need to data traffics SHOULD be provided.  In order to secure
      provided, when the data/
   control traffic, cryptographic keys need underlying network is not secure.

      If the data traffics from the TSes is sensitive, they needs to be distributed to
   generate digests or signatures for
      encrypted during the control packets.  Such
   cryptographic keys can tunnels.  However, if the data traffics is
      not valuable and sensitive, the encryption is not necessary.

   REQ7:  Different tunnels SHOULD be manually deployed in advance or dynamically
   generated secured with certain automatic key management protocols (e.g., TLS
   [RFC5246]).  The TSes belonging to different VNs MUST use different
   keys to secure the control packets exchanges with their NVE.
   Therefore, an attacker cannot use the keys it obtained from a
   compromised TS

      This requirement can be used to generate bogus signaling messages and inject them
   into other VNs without being detected.  For provide a better damage basic attack confinement capability, different TSes SHOULD use
      capability.  When different keys to
   secure their control packet exchanges tunnels secured with NVEs, even if they belong
   to the same VN.

   In different keys,
      the co-located case, all compromise of a key in a tunnel will not affect the information exchanges security
      of others.

5.2.  Control/Data Traffic between NVEs and Hypervisors

   Assume there is a VNE providing a logical L2/L3 interconnect for a
   set of TSes.  Apart from data traffics, the NVE and the certain TSes are within the same device, and no standardized protocol
   (i.e., Hypervisors) also need to exchange signaling packets in order
   to facilitate, e.g., VM online detection, VM migration detection, or
   auto-provisioning/service discovery [I-D.ietf-nvo3-framework].

   The NVE and its associated TSes can be provided for transporting control/data packets.  It deployed in a distributed way
   (e.g., a NVE is
   also important to keep the isolation of the TS traffic implemented in different
   VNs.  In addition, an individual device, and VMs are
   located on servers) or in the co-location fashion, because the NVE, the
   hypervisor, a co-located way (e.g., a NVE and the VMs TSes
   it serves are deployed located on the same device, server).

5.2.1.  Distributed Deployment of NVE and Hypervisor

   In this case, the
   computing data and memory resources used by control traffic between the NVE , the hypervisor, and the
   TSes need to are exchanged over network.

5.2.1.1.  Control Plane

   REQ8:  Mutual authentication MUST be isolated to prevents performed between a NVE and a malicious or compromised TS from, e.g., accessing
      at the memory beginning of their communication, if the network connecting
      them is not secure.

      Mutual authentication is used to guarantee that an attacker cannot
      impersonate a legal NVE or affecting the
   performance of a hypervisor without being detected.

      There are various ways to perform mutual authentication.  If there
      are auto key management mechanism (e.g., IKEv2, EAP), the NVE by occupying large amounts of computing
   resources.

5.2.  Securing the Communications within Overlays

   This section analyzes the security issues in the control and data
   plans of a NVO3 overlay.

5.2.1.  Control Plane Security

   It is
      the responsibility of the NVO3 network TS can use their credential to protect the control
   plane packets transported over the underlay network against the
   attacks from the underlying network.  The integrity perform authentication.  If
      there a key pre-distributed between a NVE and origin
   authentication of the messages MUST be guaranteed.  The signaling
   packets SHOULD be encrypted when a TS, an entity can
      also use the signaling messages are
   confidential.  To achieve such objectives, when key verify the network devices
   exchange control plane packets, integrated security mechanisms identity of is remote peer.

      If practice, a NVE and a TS may simply use IP or
   security protocols need to provided.  In addition, cryptographic keys
   need MAC addresses to
      identify each other.  This type of technique can be deployed manually in advance or dynamically generated by
   using certain automatic key management protocols (e.g., TLS
   [RFC5246]).

   In order to enforce used as a
      complementary approach although it may becomes vulnerable if
      attackers can inject bogus control packets the security boundary of different VNs in network and modify
      the
   existence of inside adversaries, packets transported between the signaling messages belonging to
   different VNs need NVE and TS.

   REQ9:  Before accepting a control packet, the receiver device MUST
      verify whether the packet comes from one which has the privilege
      to be secured by different keys.  Otherwise, send that packet.

      This is an
   inside attacker may try authorization requirement.  A device needs to use clarify
      the keys obtained within roles (e.g., a VN to
   impersonate the NVEs in other VNs and generate illegal signaling
   messages without being detected.  If we expect to provide TS or a better
   attack confinement capability and prevent NVE) of the device that it is
      communicating with.  Therefore, if a compromised NVE TS attempts to
      use it credentials to impersonate other NVEs in the same VN, different NVEs working inside a VN need NVE to secure their signaling messages communicate with different keys.
   When there are centralized servers providing mapping information
   (IMAs) within the overlay, other
      TSes, it will be detected.

      Authorization is very important to prevent guarantee the isolation
      property.  For instance, if a compromised NVE from impersonating the centralized servers to
   communicate with other NVEs.  A straightforward solution is hypervisor tries to
   associate different NVEs with different keys when they exchange
   information with the centralized servers.

   In
      elevate its privilege and interfere the cases where there are a large amount of NVEs working within a
   NVO3 overlay, manual key management may become infeasible.  First, VNs that it
   could be burdensome to deploy pre-shared keys for thousands of NVEs, is not to mention that multiple keys may need
      supposed to be deployed involved within, its attempt will be detected and
      rejected.

      Normally, it is assumed that the access control operations are
      based on a single
   device for different purposes.  Key derivation the authentication results.  The simple authorization
      mechanisms (such as ACLs which filters packets based on the packet
      addresses) can be used to
   mitigate this problem.  Using key derivation functions, multiple keys as complementary solutions.

   REQ10:  Integrity, Confidentiality, and Origin Authentication for different usages can be derived from
      Control Packets

      a:The security solution of a pre-shared master key.
   However, key derivation cannot protect against NVE network MUST be able to provide
      integrity protection and origin authentication for the situation where control
      packets exchanged between a
   system was incorrectly trusted to NVE and a TS if they have the key used to perform use an
      insecure network to transport their packet.

      This requirement can prevent an attacker from illegally interfere
      with the
   derivation.  If normal operations of NVEs and TSes by injecting bogus
      control packets into the master key were somehow compromised, all network.

      b:The confidentiality protection for the
   resulting keys would need to control packet exchange
      SHOULD be changed.  In addition, VM migration
   will introduce challenges to manual key management.  The migration of
   a VM in a VN may cause provided.

      When the change contents of the NVEs which are involved
   within control packets (e.g., the NV.  When location of a NVE is newly involved within
      ES, when a VN, it needs to
   get the key VM migration happens) are sensitive to join the operations within the VN.  If a NVE stops
   supporting a VN, it should not keep tenant, the keys associated with that VN.
   All those key updates need
      control packet needs to be performed at run time, encrypted.

      There are various security protocols (such as IPsec, SSL, and difficult
   to TCP-
      AO) can be handled by human beings.  As a result, used for transport control packets.  In addition, it is reasonable
      possible to
   introduce automated define integrated security solutions for the control
      packets.

      In order to secure the control traffic, cryptographic keys need to
      be distributed to generate digests or signatures for the control
      packets.  Such cryptographic keys can be manually deployed in
      advance or dynamically generated with certain automatic key
      management solutions such as EAP [RFC4137]
   for NVO3 overlays.

   When an automated protocols (e.g., TLS [RFC5246]).

   REQ11:  The key management solution for NVO3 overlays is
   deployed, as a part of MUST be able to confine the scope
      of key management protocol, mutual
   authentication needs distribution and provide different keys to be performed before two network devices in
   the overlay (NVEs or IMAs) start exchanging isolate the
      control packets.
   After an authentication, an device can find out whether its peer
   holds valid traffic according to different security credentials is is requirements.

      a: If assuming TSes (hypervisors) will not be compromised, the one who it has claimed.
   The authentication results is also necessary for authorization; it is
   important for a device
      TSes belonging to clarify the roles (e.g., a NVE or a IMA)
   that its authentication peer acts as in the overlay.  Therefore, a
   compromised NVE cannot different Tenants MUST use it credential to impersonate an IMA different keys to
   communicate with other NVEs.  Only
      secure the control messages from packet exchanges with their NVE.

      This requirement is used to enforce the
   authenticated entity will be adopted.  In addition, authorization MAY
   need security boundaries of
      different tenant networks.  Since different tenants belong to
      different security domains and may be performed.  For instance, before accepting a control
   message, the receiver NVE needs competitive to verify whether each other,
      the message comes
   from one which is authorized control plane traffics need to send be carefully isolated so that message.
      an attacker from a tenant cannot affect the operations of another
      tenant network.

      b: If assuming the
   authorization fail, hypervisors can be compromised, the TSes
      belonging to different VNs MUST use different keys to secure the
      control message will be discarded.  For
   instance, packets exchanges with their NVE.

      Therefore, if a control packet about a VN is sent from key used for a NVE which VN is compromised, other VNs will
      not authorized be affected.  This requirement is used to support ensure the VN, the packet will be discarded. VN
      isolation property.

5.2.1.2.  Data Plane

   REQ12:  The issues data traffic isolation of DDOS attacks also need to different VNs MUST be considered in designing
   the overlay control plane.  For instance, in
      guaranteed.

      In [I-D.ietf-nvo3-overlay-problem-statement], the VXLAN
   solution[I-D.mahalingam-dutt-dcops-vxlan], an attacker attached to data plane
      isolation requirement amongst different VNs has been discussed.
      The traffic within a
   NVE virtual network can try to manipulate the NVE to keep multicasting control
   messages by sending a large amount of ARP packets to query the
   inexistent VMs.  In order to mitigate this type of attack, the NVEs
   SHOULD be only allowed to send signaling message be transited into
      another one in the overlay with a limited frequency.  When there are centralized servers controlled fashion (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 via a configured router
      and/or a security
   risks caused by DDOS attack on such servers can be more serious.

   In addition, during the design of gateway).  Therefore, if the control plane, it is important
   to consider NVE supports
      multiple VNs concurrently, the amplification effects which may potential data traffic in different VNs MUST
      be used by
   attackers to carry out reflection attacks.

5.2.2.  Data Plan Security

   [I-D.ietf-nvo3-framework] specifies isolated.

      a:The security solution of a NVO3 overlay needs NVE network MUST be able to generate
   tunnels between NVEs provide
      integrity protection and origin authentication for data transportation.  When a data packet
   reaches the boundary of data
      packets exchanged between a overlay, it will be encapsulated NVE and
   forwarded a TS if they have to use an
      insecure network to transport their data packet.

      In practice, the destination NVE through a proper tunnel.  It is
   normally assume that data traffics in different VNs can be isolated
      physically or by using VPN technologies.  If the underlying network
      connecting NVEs are
   secure to outside attacks since it is under the management of DC
   vendor NVE and cannot be directly accessed by tenants.  However, when
   facing inside attacks, conditions could the TSes is potentially accessible to
      attackers, security solutions need to be complex.  For instance, considered to prevent an
   inside
      attacker compromising a underlying network device may
   intercept an encapsulated data packet transported a tunnel, modify
   the contents locating in the encapsulating tunnel packet and, transfer it into
   another tunnel without being detected.  When the modified packet
   reaches a NVE, middle between the NVE may decapsulated the data packet and forward
   it into a VN according to TS from
      modifying the VN identification information within in the encapsulating
   header generated by packet headers
      so as to manipulate the attacker.  Similarly, a compromised NVE may
   try to redirect transport the data packets within a
      VN into another VN by
   adding improper encapsulating tunnel headers to the data packets.
   Under another.  The security protocols such circumstances, in order as IPsec and TCP-AO,
      can be used to enforce the VN isolation
   property, signatures or digests need to property if necessary.

   The key management requirement R11 can be generated applied here for both data
   packets and the encapsulating tunnel headers in order to provide data
   origin authentication and integrity protection.  In addition, NVEs
   SHOULD use different keys to secure the packets transported in
   different tunnels.

6.  Security Issues Imposed by the New Overlay Design Characteristics

6.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 (VNs).  Therefore,
   the scalability issues should be considered.
   traffic

5.3.  Key Management
   REQ13:  A security solution for NVO3 SHOULD provide automated key
      management mechanisms.

      In the cases where there are a
   NVE only has a limited number of NVEs to communicate with, the
   scalability problem brought by the overhead large amount of generating and
   maintaining the security channels with the remote NVEs is not
   serious.  However, if a NVE needs to communicate with working within
      a large number
   of peers, the scalability issue NVO3 overlay, manual key management may become infeasible.
      First, it could be serious.  For instance,
   in[I-D.ietf-ipsecme-ad-vpn-problem], it has been demonstrated it is
   not trivial burdensome to enabling a large number deploy pre-shared keys for
      thousands of systems NVEs, not to communicate
   directly using IPsec mention that multiple keys may need to protect the traffic between them.

6.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
      be deployed on the path connecting two NVEs to inspect the
   contents of the packets.  The firewall can only know which VN the
   packets belong to through the VN ID transported in the outer header.
   If a firewall would like to identify which end device sends a packets
   or which end single device a packet is sent to, the firewall for different purposes.  Key
      derivation can be deployed
   in some place where it used to mitigate this problem.  Using key
      derivation functions, multiple keys for different usages can access the packet before it is
   encapsulated or un-encapsulated by NVEs. be
      derived from a pre-shared master key.  However, in this case, the
   firewall key derivation
      cannot get VN ID from protect against the packet.  If situation where a system was
      incorrectly trusted to have the firewall is key used to process two VNs concurrently and there are IP or MAC addresses of
   the end devices in perform the two VNs overlapped, confusion will be caused.
      derivation.  If a firewall can generate multiple firewalls instances for different
   tenants respectively, this issue can the master key were somehow compromised, all the
      resulting keys would need to be largely addressed.

6.3.  Security Issues with changed [RFC4301].  In addition,
      VM Migration migration will introduce challenges to manual key management.
      The support migration of a VM migration is an important issue considered in NVO3
   WG.  The migration a VN may also cause security risks.  Because the VMs change of the NVEs
      which are involved within the NV.  When a VN may move from one server NVE is newly involved
      within a VN, it needs to another which connects get the key to join the operations within
      the VN.  If a
   different NVE, NVE stops supporting a VN, it should not keep the packets exchanging between two VMs may
      keys associated with that VN.  All those key updates need to be
   transferred in
      performed at run time, and difficult to be handled by human
      beings.  As a new path.  If result, it is reasonable to introduce automated key
      management solutions such as EAP [RFC4137] for NVO3 overlays.

      Without the support automated key management mechanisms, some
      security policies deployed on the
   firewalls functions of certain security protocols cannot work
      properly.  For instance, 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 anti-replay mechanism of IPsec is to enable
      turned off without the state migration and policy confliction detection
   between firewalls.  The other one support of automated key management
      mechanisms.  Therefore, if IPsec is selected to force all protect the traffic within
   a VN be processed by a single firewall.  However
      control packets.  In this solution case, the system may
   cause traffic optimization issues.

7. suffer from the
      replay attacks.

6.  IANA Considerations

   This document makes no request of IANA.

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

8.

7.  Security Considerations

   TBD

9.

8.  Acknowledgements

10.

   Thanks a lot for the comments from Melinda Shore, and Zu Qiang.

9.  References

10.1.

9.1.  Normative References

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

10.2.

9.2.  Informative References

   [I-D.ietf-ipsecme-ad-vpn-problem]
              Manral, V. and S. Hanna, "Auto Discovery VPN Problem
              Statement and Requirements", draft-ietf-ipsecme-ad-vpn-
              problem-09 (work in progress), July 2013.

   [I-D.ietf-nvo3-framework]
              Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for DC Network Virtualization", draft-
              ietf-nvo3-framework-03 (work in progress), July 2013.

   [I-D.ietf-nvo3-overlay-problem-statement]
              Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
              and M. Napierala, "Problem Statement: Overlays for Network
              Virtualization", draft-ietf-nvo3-overlay-problem-
              statement-04 (work in progress), July 2013.

   [I-D.kreeger-nvo3-hypervisor-nve-cp]
              Kreeger, L., Narten, T., and D. Black, "Network
              Virtualization Hypervisor-to-NVE Overlay Control Protocol
              Requirements", draft-kreeger-nvo3-hypervisor-nve-cp-01
              (work in progress), February 2013.

   [I-D.mahalingam-dutt-dcops-vxlan]
              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-04 draft-mahalingam-dutt-dcops-vxlan-05
              (work in progress), May October 2013.

   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
              "Multicast Security (MSEC) Group Key Management
              Architecture", RFC 4046, April 2005.

   [RFC4137]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
              "State Machines for Extensible Authentication Protocol
              (EAP) Peer and Authenticator", RFC 4137, August 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010.

Authors' Addresses

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

   Email: hartmans@painless-security.com
   URI:   http://www.painless-security.com

   Dacheng Zhang
   Huawei
   Beijing
   China

   Email: zhangdacheng@huawei.com

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

   Phone: +1 781 405 7464
   Email: mrw@painless-security.com
   URI:   http://www.painless-security.com