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

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

Abstract

   The draft provides describes a list of security essential requirements in order to
   benefit the design of NOV3 security mechanisms. solutions.  In addition, this
   draft introduces the candidate techniques which could be used to fulfill
   such
   construct a security solution fulfilling these 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 25, July 28, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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 . . . . . . . . . . . . . . . . . .   3   4
   4.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Outsider  Capabilities of Outsiders . . . . . . . . . . . . . . . . . .   4   5
     4.2.  Insider  Capabilities of Insiders  . . . . . . . . . . . . . . . .   5
     4.3.  Capabilities of Malicious TSes  . . . . . . . . . . . . .   5
     4.3.
     4.4.  Security Issues In Scope and Out of Scope . . . . . . . .   5   6
   5.  Security Requirements and Candidate Approaches . . . . . . .   6 . . . . . . . . . . . . .   7
     5.1.  Control/Data Traffic within Plane of NVO3 Overlay  . . . . . . . . . . .   6   7
       5.1.1.  NVE-NVA Control Plane Security . . . . . . . . . . . . . . .   6 .   7
       5.1.2.  Data  NVA-NVA Control Plane . . . . . . . . . . . . . . . .   9
       5.1.3.  NVE-NVE Data Plane  . . . . . . . .   9 . . . . . . . . .  10
     5.2.  Control/Data Traffic Plane between NVEs and Hypervisors . . . .  10 .  11
       5.2.1.  Distributed Deployment of NVE and Hypervisor  . . . .  11
     5.3.  Key Management  12
   6.  Candidate Techniques  . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Entity Authentication . .  13
   6. . . . . . . . . . . . . . . . .  14
     6.2.  Packet Level Security . . . . . . . . . . . . . . . . . .  15
     6.3.  Authorization . . . . . . . . . . . . . . . . . . . . . .  15
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  Acknowledgements  15
     8.1.  Automated Key Management in NVO3  . . . . . . . . . . . .  15
     8.2.  Issues not Discussed  . . . . . . . . . . . . .  14 . . . . .  16
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     9.2.  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16  18

1.  Introduction

   Security is a key issue which needs to be considered in during the
   design of a data center network.  This document discusses the
   security risks that a NVO3 network may encounter and the tries to provide
   a list of essential security requirements that a NVO3 network needs
   to fulfill.  In addition, this draft attempts to
   discuss introduces the security candidate
   techniques which could be applied potentially used to fulfill
   such construct a security
   solution fulfilling the security requirements.

   The remainder of this document is organized as follows.  Section 2
   introduces the several key terms used in this memo.  Section 3 gives a briefly
   brief introduction of the NVO3 network architecture.  Section 4
   discusses the attack model of this work.  Section 5 describes the essential provides a list
   of security requirements which should be fulfilled in as well as the generation of
   a NVO3 network. associated justifications.
   In Section 6, the candidate techniques are introduced.

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.

   Network Virtualization Authority (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 this memo, the devices (e.g., NVE and NVA) work
   cooperatively to provide NVO3 overlay functionalities are called as
   NOV3 devices.

3.  NVO3 Overlay Architecture
                      ..................................

                +--------+                                    +--------+
                | Tenant +--+                            +----| Tenant |
                | System |  |                           (')   | System |
                +--------+  |    .................     (   )  +--------+
                            |  +---+           +---+    (_)
                            +--|NVE|---+   +---|NVE|-----+
                               +---+   |   |   +---+
                               / .    +-----+      .
                              /  . +--| NVA |      .
                             /   . |  +-----+      .
                            |    . |               .
                            |    .
                    +-+--+                          +--+-++--------+ |  L3 Overlay +--+--++--------+
                +--------+  | NV    . |   Network   | NVE || Tenant |
                | Tenant +--+    . |             | NV     || System |
                | System |       .  \ +---+      +--+--++--------+
                +--------+       .....|NVE|.........
                                      +---+
                                        |
                                        |
                              =====================
                                |               |
                            +--------+      +--------+
                            | 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 ingress NVE.  Then
   encapsulated packet is then sent to the remote NVE through a proper
   tunnel.  When reaching the ingress NVE, egress NVE of the tunnel, the packet is
   decapsulated and forwarded to the target tenant system.  The address
   advertisements and tunnel mappings are distributed among to the NVEs
   through either distributed control protocols or by certain a
   logically centralized servers (called NVAs). server (i.e., NVA).

4.  Threat Model

   To benefit describing the discussion, threats a NVO3 network may have to face, in
   this analysis work, attacks are classified into two three categories: inside the attacks
   from compromised NVO3 devices (inside attacks), the attacks from
   compromised tenant systems, and outside attacks.
   An attack is considered as an inside attack if the adversary attacks from underlying networks
   (outside attacks).

   The adversaries performing the first type of attack (inside attacker are called as
   insiders or insider) has got inside attackers because they need to get certain
   privileges in changing the configuration or software of a NVO3 device devices
   beforehand and initiates initiate the attack attacks within the overlay security
   perimeter.  In
   contrast, the second type of attack, an attacker has got certain
   privileges in changing the configuration or software of tenant
   systems (e.g., hypervisors or virtual machines) and attempts to
   manipulate the controlled tenant systems to interfere with the normal
   operations of the NVO3 overlay.  The third type of attack is referred
   to as an the outside attack if the
   adversary performing since adversaries do not have to obtain any
   privilege on the attack (outside attacker NVO3 devices or outsider) has no
   such privilege tenant systems in advance in order
   to perform this type attack, and can only initiate thus the adversaries performing
   outside attacks from compromised
   TSes (or the network devices of the underlying network which the
   overlay is located upon).  Note that in a complex attack inside and are called as outside attacking operations may be performed in a well organized way
   to expand the damages caused by the attack. attackers or outsiders.

4.1.  Outsider  Capabilities

   The following capabilities of Outsiders

   In practice, an outside attackers MUST be considered in
   the design of a NOV3 security mechanism:

   1.  Eavesdropping on the attacker may perform attacks by intercepting
   packets,
   2.  Replaying the intercepted deleting packets, and

   3.  Generating illegal packets and injecting them into the network. and/or inserting bogus packets.  With a
   successful outside attack, an attacker may be able to:

   1.  Analyze the traffic pattern 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 which 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 Insiders

   Besides intercepting packets, deleting packets, and/or inserting
   bogus packets, 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,
       NVO3 device, by sending packets containing invalid information or
       with improper frequencies,

   2.  Perform spoofing attacks and impersonate another legal NVO3
       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.

4.3.  Capabilities of Malicious TSes

   It is assumed that the attacker performing attacks from compromised
   TSes is able to intercept packets, delete packets, and/or insert
   bogus packets.  In addition, after compromising a TS, an attacker may
   be able to:

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

   2.  Perform spoofing attacks and impersonate another legal TS or NVE
       to communicate with victims (other legal NVEs or TSes) 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.

4.4.  Security Issues In Scope and Out of Scope

   During the specification of security requirements, the following
   security issues needs to be considered:

   1.  Insecure underlying network.  It is normally assumed that a  A underlying network connecting NOV3 devices (NVEs and NVAs) is
       relatively secure if it is located within a data center and
       cannot be directly accessed by tenants. any tenants or outsiders.
       However, in a NVO3 overlay for virtual data center
       scenario, a NVO3 overlay scatters may scatter
       across different geographically distributed sites which are
       connected through the public network.  Outside Internet.  In this case, outside
       attacks may be raised from the underlying network. network connecting NVO3
       devices.

   2.  Insider attacker.  During the design of a security solution for a NVO3 network, the inside
       attacks raised from compromised NVO3
       devices (NVEs NVEs and NVAs) hypervisors 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 consideration 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,  For instance, 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  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  This type of attack
       is out of scope. scope of this memo.

   3.  NVAs are centralized servers and play a critical role in NVO3
       overlays.  A NVE will believe in the mapping information obtained
       from its NVA.  After compromising a NVA, the attacker can
       distribute bogus mapping information to NVEs under the management
       of NVA.  This work does not consider how to deal with this
       problem.

5.  Security Requirements and Candidate Approaches

   This section introduces the security requirements and candidate
   solutions.

5.1.  Control/Data Traffic within Plane of NVO3 Overlay

   This section analyzes

   In this section, the security issues in requirements associated with the NVE-
   NVA control plane, the NVA-NVA control plane, and the NVE-NVE data
   plans of a NVO3 overlay.
   plane are proposed.

5.1.1.  NVE-NVA Control Plane Security

   REQ1:  A NVO3

   In a NVE-NVA control plane, it is assumed that a NVE only exchanges
   control traffics with its NVA using unicast.

   REQ 1:  The security solution MUST for NVO3 SHOULD enable two NOV3 NVO3 devices (NVE or
      NVA)
      to perform mutual authentication mutually authenticate each other before exchanging they exchange any
      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

      Entity authentication between devices can be performed as protect a part of
      automated key management protocols (e.g., IKEv2[RFC5996],
      EAP[RFC4137], etc.).  After such an authentication procedure, an network device can find out whether its peer holds valid security
      credentials against
      imposter attacks and is then reduce the one who it has claimed.  Additionally, risk of DoS attacks and man-
      in-the-middle attacks.  In addition, a successful authentication
      normally results in the
      keys shared between distribution key materials for the devices can
      security protection for subsequent communications.

   REQ 2:  The security solution of NVO3 MUST be also used able to provide
      integrity protection, replay protection, and packet origin
      authentication for the control packets.

      Unlike entity authentication, message authentication purpose.  For instance, assumed a NVE and is performed
      on each incoming packet.  Through message authentication, the NOV3
      device receiving a NVA
      have shared a secret key without known by any other third parties.

      The NVE control packet can ensure that verify whether the packet is
      generated by a device that it legitimate NVO3 device, is communicating with not antique, and is not
      tampered during transportation.  In addition, with the NVA if support of
      properly distributed keys, the device packet level protection can prove that it possesses also
      benefit the shared key.

      a: detection of spoofing attacks raised from insiders.

   REQ 3:  The identity security solution of the a NVO3 network devices SHOULD be verified during
      authentication.

      In some authentication mechanisms, instead of verifying MAY provide
      confidentiality protection for the peers'
      identities, control packets.

      On many occasions, the authentication result control packets can only prove that a device
      joining the authentication is a legal member of a group. be transported in
      plaintext.  However,
      for a better damage confining capability to insider attacker, it under the circumstances where some
      information contained within the control packets is recommended considered to verify
      be sensitive or valuable, the devices' identities during
      authentication.  Therefore, an insider attacker cannot impersonate
      others, even information needs to be encrypted
      especially when it holds legal credentials or keys.

   REQ2: the underlying network is not secure.  Note that
      encryption will impose additional overhead in processing control
      packets and make NVAs more vulnerable to DoS/DDoS attacks.

   REQ 4:  Before accepting a control packet, the a NOV3 device receiving
      the packet MUST be able to verify whether the packet comes from
      one which who has the privilege to send that packet.

      This is an

      When receiving a control packet, besides authentication,
      authorization requirement.  A device needs to clarify be carried out by the roles (e.g., a NVE or a NVA) receiver to identify
      the role that its authentication peer the packet sender acts as in the overlay.  Therefore, if overlay and then
      assess the sender's privileges.  If a compromised NVE uses it
      credentials tries to impersonate a NVA
      illegally elevate its privilege (e.g., using its credentials to
      communicate with other NVEs, NVEs as a NVA, or attempting to access the
      mapping information of the VNs which it is not authorized to
      serve), it will be detected.  In addition, authorization is important for
      enforcing the VN isolation, a device only can distribute control
      packets within detected and rejected.

   REQ 5:  The security solution of NVO3 SHOULD be able to provide
      distinct keys to protect the VNs it is involved within.  If control traffics exchanged between a
      NVA and different NVEs respectively.

      During the exchange of control packets, keys are critical in
      authenticating the packet
      about a VN senders.  The purpose of this
      requirement is sent from to provide a NVE which is not authorized basic capability to support
      the VN, confine the packet damage
      caused by inside attacks.  After compromising a NVE, an attacker
      will not be accepted

      Normally, able to use the keys it is assumed that obtained to breach the
      security of the access control operations are
      based on traffics exchanged between the authentication results.  The simple authorization
      mechanisms (such as ACLs which filters packets based on NVA and
      other NVEs.

   In a NVO3 overlay, NVAs can be the packet
      addresses) valuable targets of DoS/DDoS
   attacks, and large amount of NVEs can be potentially used as auxiliary approaches since they are
      relatively easy to bypass if attackers can access to
   reflectors in reflection attacks.  Therefore, the network
      and modify packets.

   REQ3:  Integrity, confidentiality, and origin Authentication
      protection DoS/DDoS risks
   needs be considered during designing the control planes for Control traffics

      It is NOV3.
   The following two requirements are used to benefit the responsibility migration of a
   DoS/DDoS issue.

   REQ 6:  A NVO3 overlay to protect the device MUST send its control packets transported over the overlay against the with limited
      frequencies.

      Without this limitation, an attacker can attempt to perform DDoS
      attacks raised
      from to exhaust the underlying network.

      a: The integrity limited computing and origin authentication memory resources of a
      NVA by manipulating the packets MUST be
      guaranteed.

      With this requirement, NVEs attached to the receiver can ensure that NVA to generate a
      significant member of mapping queries in a short period.

   REQ 7:  The amplification effect SHOULD be avoided

      If in certain conditions the packets responses generated by a NVE are from much
      longer than the legitimate sender, not replayed, and not modified
      during received requests, the transportation.

      b: The signaling packets SHOULD NVE may be encrypted.

      On many occasions, taken advantage
      of by an attacker as a reflector to carry out DDoS attacks.
      Specifically, the signaling packets attacker can be transported in
      plaintext.  However, In the cases where concurrently send out a large
      amount of spoofed short requests to multiple NVEs with the information contained
      within source
      address of a victim (e.g., a NVA).  The responses generated by the signaling packets are sensitive or valuable
      NVEs will be forwarded to
      attackers , the victim and overwhelm the victim's
      processing capability.

5.1.2.  NVA-NVA Control Plane

   Multiple NVAs may be deployed in a NVO3 overlay for better
   scalability and fault tolerance capability.  The NVAs may use unicast
   and/or multicast to exchange signaling packets related with that tenant need be
      encrypted.

      To achieve such objectives, when within the network devices exchange control
   plane.

   Except the key deployment requirement (REQ 5), all the other
   requirements in the NVE-NVA control plane packets, integrated security mechanisms or
      underlying security protocols need (REQs 1,2,3,4, 6, and 7)
   are applicable in the NVA-NVA control plane as well.  Before two NVA
   communicate with each other, they should be able to provided. mutually
   authenticated.  In addition,
      cryptographic keys message authentication can help a NVO3
   device to verify the authenticity of the received packets, and the
   sensitive information in the control packets need to be deployed manually in advance or
      dynamically generated by using certain automatic key management
      protocols (e.g., TLS [RFC5246]).  The keys are used encrypted.
   Authorization is important to generate
      digests for or encrypt control packets.

   REQ4:  The toleration of DOS attacks

      a: Frequency in distributing filter the invalid control packets within in and
   any un-priviledged requests.  Moreover, the overlay
      MUST be limited.

      The issues within DOS approach to mitigating
   DoS/DDoS attacks also need needs to be considered in
      designing the overlay control plane.  For instance, in plane
   protocols.

   The key deployment requirements for the VXLAN
      solution[I-D.mahalingam-dutt-dcops-vxlan], an attacker attached NVA-NVA control plane are
   described as follows:

   REQ 8:  The security solution of NVO3 SHOULD be able to
      a NVE can try provide
      different keys to manipulate protect the NVE to keep multicasting unicast control
      packets by sending a large amount traffics exchanged
      between different NVAs respectively.

      The purpose of ARP packets to query the
      inexistent VMs.  In order to mitigate this type of attack, the
      NVEs SHOULD be only allowed requirement is to send signaling packet in the
      overlay with provide a limited frequency.  When there are centralized
      servers (e.g., basic capability
      to confine the backend oracles providing mapping information
      for NVEs[I-D.ietf-nvo3-overlay-problem-statement], or damage caused by compromised key.  The compromise
      of a key will not affect the SDN
      controllers) traffics protected by other keys.

   REQ 9:  If there are located within the overlay, multicast packets, the potential security risks caused by DDOS attack on such servers can be more
      serious.

      b: Mitigation solution of amplification attacks NVO3
      SHOULD be provided.

      During able to assign distinct cryptographic group keys to
      protect the design of multicast packets exchanged among the control plane, it is important NVAs within
      different multicast groups.

      In order to
      consider provide an essential packet level security protection
      specified in REQs 2 and 3, at least a group key may need to be
      shared among the amplification effects.  For instance, if NVEs may
      generate in a large response same mutlicast group.  It is
      recommended to user different keys for different mutlicast groups.

5.1.3.  NVE-NVE Data Plane

   As specified in [I-D.ietf-nvo3-framework], a short request, an attacker may send
      spoofed requests NVO3 overlay needs to the
   generate tunnels between NVEs with for data packet transportation.  When a
   data packet reaches the source address boundary of a victim.
      Then overlay, the NVEs ingress NVE will send the response to the victim and result in
      DDOS attacks.

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

   REQ5: destination egress NVE
   through a proper tunnel.

   REQ 10:  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 solution for NVO3 SHOULD be guaranteed that different keys are enable two NVEs to
      mutually authenticate each other before establishing a tunnel
      connecting them for data transportation.

      This entity authentication requirement is used to secure protect a NVE
      against imposter attacks.  Also, this requirement can help
      guarantee a data tunnel is generated between two proper NVEs and
      reduce the control risk of man-in-the-middle attacks.

   In order to protect the data packets transported over the overlay
   against the attacks raised from the underlying network, the NVO3
   overlay needs to provide essential security protection for data
   packets.

   REQ 11:  The security solution of NVO3 MUST be able to provide
      integrity protection, replay protection, and packet origin
      authentication for data traffics exchanged within different tenant networks. between NVEs.

      This requirement can be is used to provide prevent an attacker who has
      compromised a basic attack confinement
      capability. underlying network devices on the path from
      replaying antique packets or injecting bogus data packets without
      being detected.

   REQ 12:  The compromise security solution of a NVE working NVO3 MAY provide confidentiality
      protection for data traffics exchanged between NVEs.

      If the data traffics from the TSes are sensitive, they needs to be
      encrypted when being transported within a tenant the overlay.  Otherwise,
      encryption will
      not result be unnecessary.  In addition, in practice, tenants
      may also select to encrypt their sensitive data during
      transportation.  Therefore this confidentiality requirement for
      data plane is then not as crucial as the key leakage integrity requirement.

   REQ 13:  The security solution of other tenant networks.

      b: It NVO3 SHOULD be guaranteed that able to assign
      different cryptographic keys are used to secure protect the control packets exchanges with different VNs. unicast tunnels
      between NVEs respectively.

      This requirement can be is used to provide a better attack
      confinement capability for confine the damage caused by inside
      attacks.  When different tunnels secured with different keys, the control plane.  The
      compromise of a
      NVE working within key in a VN tunnel will not result in affect the key leakage security of
      other VNs.  However, since there is only a single
      others.  In addition, if the key used for
      securing the data traffic within to protect a VN, an attacker which has
      compromised tunnel is only
      shared by the NVEs on the both sides, the egress NVE receiving a
      data packet is able to distinctively prove the identity of the
      ingress NVE within encapsulating the VN may data packet during the message
      authentication.

   REQ 14:  If there are multicast packets, the security solution of
      NVO3 SHOULD be able to impersonate any
      other assign distinct cryptographic group keys to
      protect the multicast packets exchanged among the NVEs within the VN to send out bogus control packets.
      different multicast groups.

      In
      addition, the key management overheads introduced by key
      revocation also need to be considered[RFC4046].  When practice, a NVE stops
      severing a VN, may need to use the key used for multicast capability
      provided by the VN needs underlying network to be revoked, transfer multicast packets
      to other NVEs.  In this case, in order to provide an essential
      packet level security protection specified in requirements 11 and
      12, at least a
      new group key needs may need to be distributed for the NVO3 devices still within shared among the VN.

      If we expect to provide a even stronger confinement capability and
      prevent a compromised NVE from impersonating other NVEs even when
      they are in the same VN, different NVEs working inside a VN need
      same mutlicast group, in order to secure their signaling provide packet level
      authentication or optionally confidentiality protection for the
      multicast packets with different keys.

      If there is automated key management deployed, transferred within the authentication
      and authorization can be used group.  It is recommended
      to largely mitigate deploy different keys for different mutlicast groups, in order
      to confine the isolation
      issues.  When insider attacks on NVEs.

   REQ 15:  Upon receiving a data packet, an egress NVE attempts must be able to join a VN,
      verify whether the packet is from a proper ingress NVE needs which is
      authorized to be
      authenticated and prove forward that it have sufficient privileges.  Then,
      a new key (or a set of keys) will be generated to secure its
      control packet exchanged packet.

      In cooperation 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 transportation.  When a data packet
   reaches the boundary of authentication, authorization enables a overlay, it will be encapsulated and
   forwarded egress
      NVE to detect the destination NVE through a proper tunnel.

   REQ6:  Integrity, confidentiality, and origin authentication
      protection for data traffics
      a: The integrity and origin authentication of data traffics MUST
      be guaranteed packets which violate certain security
      policies, even when the underlying network is not secure.

      During the transportation of data packets, it is the
      responsibility of the NVO3 overlay to deal with the attacks they are forwarded from
      the underlying network. a legal NVE.  For
      instance, an inside attacker
      compromising a underlying network device may intercept an
      encapsulated data packet transported within a tunnel, modify the
      contents in the encapsulating tunnel packet and, transfer it into
      another tunnel without being detected.  When the modified packet
      reaches if a NVE, the NVE may decapsulated the data packet and
      forward it into a VN according to the information within the
      encapsulating header generated by the attacker.  Similarly, a
      compromised NVE may try belonging to redirect the data packets within a VN
      into another VN by adding improper encapsulating tunnel headers to
      the data packets.

      Under such circumstances, in order to enforce the 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 data traffics SHOULD be
      provided, when the underlying network is not secure.

      If the data traffics forwarded from the TSes an
      ingress NVE which is sensitive, they not supposed to support that VN, the packet
      needs to be
      encrypted during the tunnels.  However, if detected and discarded.  Note that the data traffics is detection of a
      invalid packet may not valuable and sensitive, indicate that the encryption system is not necessary.

   REQ7:  Different tunnels SHOULD be secured with different keys

      This requirement can be used to provide under a basic attack confinement
      capability.  When different tunnels secured with different keys,
      the compromise
      malicious attack.  Mis-configuration or byzantine failure of a key NVE
      may also result in a tunnel will not affect the security
      of others. such invalid packets.

5.2.  Control/Data Traffic Plane 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 certain TSes
   (i.e., Hypervisors) hypervisors may 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

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

5.2.1.  Distributed Deployment of NVE and Hypervisor  In this the former case, the data and control traffic
   between the NVE and the
   TSes hypervisors are exchanged over network.

5.2.1.1.  Control Plane

   REQ8:  Mutual authentication MUST be performed

5.2.1.  Distributed Deployment of NVE and Hypervisor

   Five security requirements appliabled for both control and data
   packets exchanged between a NVEs and hypervisors are listed as follows:

   REQ 16:  The security solution for NVO3 SHOULD enable the
      communicating NVE and a TS
      at the beginning of their communication, if the network connecting
      them is not secure. hypervisor to mutually authenticate each
      other before exchanging any control/ data packets.

      Mutual authentication is used to guarantee that prevent an attacker cannot
      impersonate from
      impersonating a legal NVE or a hypervisor without being detected.

      There are various ways to perform mutual authentication.  If there
      are auto detected
      and then reduce the risks of man-in-the-middle attacks.  A
      successful authentication normally results in the distribution key management mechanism (e.g., IKEv2, EAP),
      materials to protect the NVE security of subsequent communications.

   REQ 17:  The security solution of NVO3 MUST be able to provide
      integrity protection, replay protection and origin authentication
      for the TS can use their credential to perform authentication.  If
      there a key pre-distributed control/ data packets exchanged between a NVE and a TS, an entity
      hypervisor.

      Packet level security protection can
      also use the key verify prevent an attacker from
      illegally interfere with the identity normal operations of NVEs and
      hypervisors by injecting bogus control packets into the network.
      In addition, because it is remote peer.

      If practice, a assumed the network connecting the NVE
      and the hypervisor is potentially accessible to attackers,
      security solutions need to prevent an attacker locating in the
      middle between the NVE and the hypervisor from modifying the VN
      identification information in the packet headers so as to
      manipulate the NVE to transport the data packets within a TS may simply use IP or MAC addresses VN to
      identify each other.  This type
      another.

   REQ 18:  If a NVE needs to communicate with multiple hypervisors, the
      security solution of technique can be used as a
      complementary approach although it may becomes vulnerable if
      attackers can inject bogus NVO3 network SHOULD be able to provide
      different keys and ciphers to secure the control /data packets the network
      exchanged between different hypervisors and modify their NVEs
      respectively.

      This requirement is used to benefit the damage confinement of
      inside attacks.  For instance, the compromise of a hypervisor will
      not affect the packets transported security of control/data traffics exchanged between
      the NVE and TS.

   REQ9: other hypervisors.

   REQ 19:  Before accepting a control control/data packet, a NVE or a
      hypervisor receiving the receiver device packet MUST verify whether that the packet comes from one which has device
      sending the privilege packet is authorized to send that packet. do so.

      This is an authorization requirement.  A device  When receiving a control/
      data packet, besides authentication, authorization needs to clarify
      the roles (e.g., be
      carried out by a TS NVE or a NVE) of hypervisor to identify the device role that it is
      communicating with. the
      packet sender acts as and then assess the sender's privileges.
      Therefore, if a compromised TS hypervisor attempts to use it
      credentials to impersonate a NVE to communicate with other
      TSes,
      hypervisors, it will be detected.

      Authorization is very important to guarantee the isolation
      property.  For instance, if a compromised hypervisor tries to
      elevate its privilege and interfere the VNs that it is not
      supposed to be involved within, its attempt will be detected and
      rejected.

      Normally, it is assumed that the access control operations are
      based on the authentication results.

   REQ 20:  The simple authorization
      mechanisms (such as ACLs which filters packets based on the packet
      addresses) can be used as complementary solutions.

   REQ10:  Integrity, Confidentiality, and Origin Authentication for
      Control Packets

      a:The security solution of a NVE NVO3 network MUST SHOULD be able to
      provide
      integrity protection and origin authentication different security levels of protections for the control
      packets control/
      data traffics exchanged between a NVE and a TS if they have to use an
      insecure network to transport their packet.

      This requirement can prevent an attacker from illegally interfere
      with the normal operations of NVEs and TSes by injecting bogus
      control packets into the network.

      b:The confidentiality protection for the control packet exchange
      SHOULD be provided.

      When the contents of the control packets (e.g., the location of a
      ES, when a VM migration happens) are sensitive to or a tenant, the hypervisor.

      The control packet needs to be encrypted.

      There are various security protocols (such as IPsec, SSL, and TCP-
      AO) can be used for transport control packets.  In addition, it is
      possible to define integrated data traffics between a NVE and a hypervisor may
      be transported over the same path or even within the same security solutions for
      channel.  However, when the control
      packets. traffics and data traffics
      have different levels of sensitivity, the protection on them needs
      be different.  In order to secure this case, the control traffic, cryptographic keys security solution may need to
      be distributed to generate digests or signatures
      different security channels for control and data traffics
      respectively and so protect the data and control
      packets.  Such cryptographic keys can be manually deployed in
      advance or dynamically generated traffics
      exchanged between a hypervisor and a NVE with certain automatic key
      management protocols (e.g., TLS [RFC5246]).

   REQ11: different keys and
      ciphers.

5.2.1.1.  Control Plane

   REQ 21:  The key management security solution MUST be able to confine the scope of key distribution and a NVO3 network MAY provide different keys to isolate
      confidentiality protection for the control traffic according traffics exchanged
      between a NVE and a hypervisor.

      The contents of the control/data packets need to different security requirements.

      a: If assuming TSes (hypervisors) will not be compromised, the
      TSes belonging encrypted when
      they are considered to different Tenants MUST use different keys be sensitive.

   Similar to
      secure REQs 6 and 7, the following two requirements are used to
   mitigate potential DDoS risks.

   REQ 22:  The frequency in forwarding control packet exchanges with their NVE. packets from a NVE or a
      hypervisors MUST be limited.

      This requirement is used to enforce the a common security boundaries requirement that can effectively avoid
      the capability of
      different tenant networks.  Since different tenants belong a device in processing control packets to
      different security domains and may be competitive to each other,
      overwhelmed by the high frequent control plane traffics need packets generated by the
      devices attached to it.

   REQ 23:  Amplification effect SHOULD be carefully isolated so that
      an attacker from Addressed.

      If the responses generated by a tenant cannot affect NVE or a hypervisor are much
      longer than the operations received requests, an attacker may take advantage
      of another
      tenant network.

      b: If assuming the hypervisors can be compromised, the TSes
      belonging to different VNs MUST use different keys device as a reflector to secure perform DDoS attacks.
      Specifically, the
      control packets exchanges with their NVE.

      Therefore, if attacker sends a key used for large amount of spoofed short
      requests to NVEs or hypervisors with the source address of a VN is compromised, other VNs
      victim.  The responses will
      not then be affected.  This requirement is used generated by the NVEs and
      forwarded to ensure the VN
      isolation property. victim and overwhelm its process capability.
      This issues should be considered in the design of the control
      protocols.

5.2.1.2.  Data Plane

   REQ12:

   REQ 24:  The security solution of a NVO3 network MUST provide
      security gateways to control the data traffic isolation traffics across the
      boundaries of different VNs MUST be
      guaranteed. according to specified security
      policies.

      In [I-D.ietf-nvo3-overlay-problem-statement], the data plane
      isolation requirement amongst different VNs 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).  Therefore, if

   REQ 25:  The security solution of a NVO3 network MAY provide
      confidentiality protection for the data traffics exchanged between
      a NVE supports
      multiple VNs concurrently, and a hypervisor.

      When the contents of the data traffic in different VNs MUST packets are sensitive to a tenant,
      the data packet needs to be isolated.

      a:The encrypted.  The security solution of a
      NVE network MUST may need to provide confidentiality for the data
      packets exchanged between a NVE and a hypervisor if they have to
      use an insecure network to transport their data packet and the
      tenants cannot encrypt their sensitive data themselves.

6.  Candidate Techniques

   This section introduces the techniques which can potentially be able used
   to fulfill the security requirements introduced in Section 5.

6.1.  Entity Authentication

   Entity authentication is normally performed as a part of automated
   key management, and a successful authentication may result in the key
   materials used in subsequent communications.

   The widely adopted protocols supporting entity authentication
   include: IKE[RFC2409], IKEv2[RFC4306], EAP[RFC4137], TLS [RFC5246]
   and etc.

   It is recommended to cryptographically verify the devices' identities
   during authentication.  Therefore, an inside attacker cannot use the
   keys or credentials got from the compromised device to provide
      integrity protection impersonate
   other victims.

6.2.  Packet Level Security

   There are requirements about protecting the integrity,
   confidentiality, and provide packet origin authentication for the control
   / data
      packets exchanged between a NVE and a TS if they have to use an
      insecure network packets.  Such functions can be provided through using the
   underlying security protocols (e.g., IPsec AH[RFC4302], IPsec
   ESP[RFC4303], TLS[RFC5246]).  Also, when designing the control
   protocols people can select to transport their data packet.

      In practice, provide embedded security approaches
   (just like the data traffics packet level security mechanism provided in different VNs
   OSPFv2[RFC2328]).  The cryptographic keys can be isolated
      physically manually deployed or
   dynamically generated by using VPN technologies.  If the network
      connecting certain automatic key management
   protocols.  Note that when using manual key management, the NVE and replay
   protection mechanism of IPsec will be switched off.

6.3.  Authorization

   Without any cryptographic supports, the TSes is potentially accessible authorization mechanisms
   (e.g., packet filters) could be much easier to be bypassed by
   attackers, and thus the authorization mechanisms deployed on NOV3
   devices should interoperate with entity authentication and other
   packet level security solutions need to mechanisms, and be considered able to prevent an
      attacker locating in make the middle between access
   control decisions based on the NVE cryptographically proved results.  An
   exception is packet filtering.  Because packet filters are efficient
   and TS from
      modifying the VN identification information in the can effectively drop some un-authorized packets before they have
   to be cryptographically verified, it is worthwhile to use packet headers
      so
   filters as an auxiliary approach to manipulate dealing with some simple attacks
   and increasing the NVE to transport difficulties of DoS/DDoS attacks targeting at the data packets within a
      VN to another.  The
   security protocols such protocol implementations.

7.  IANA Considerations

   This document makes no request of IANA.

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

8.  Security Considerations

8.1.  Automated Key Management in NVO3

   Because entity authentication and TCP-AO,
      can be used to enforce automated key distribution are
   normally performed in the same process, the isolation property if necessary.

   The requirements of entity
   authentication have already implied that it is recommended to use
   automated key management requirement R11 can be applied here for data
   traffic

5.3.  Key Management
   REQ13:  A in the security solution solutions for NVO3 SHOULD provide automated key
      management mechanisms. networks.
   In the cases where there are a large amount of NVEs working within a
   NVO3 overlay, manual key management may become becomes infeasible.  First, it
   could be burdensome tedious 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.  Using key derivation functions, multiple keys
   for different usages can be derived from a pre-shared master key.
   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 [RFC4301].  In addition,
      VM migration will introduce challenges to manual key management.
      The migration of a VM in a VN may cause the change of the NVEs
      which are involved within the NV.  When a NVE is newly involved
      within a VN, it needs to get the key to join the operations within
      the VN.  If a NVE stops supporting a VN, it should not keep the
      keys associated with that VN.  All those key updates  Moreover, some
   security protocols need to be
      performed at run time, and difficult to be handled by human
      beings.  As a result, it is reasonable to introduce automated key
      management solutions such as EAP [RFC4137] for NVO3 overlays.

      Without the support of automated key management mechanisms, some
      security functions of in
   order to perform certain security protocols cannot work functions properly.  For instance,  As mentioned
   above, the anti-replay replay protecting mechanism of IPsec is will be turned off
   without the support of automated key management mechanisms.  Therefore, if IPsec is selected to protect the
      control packets.  In

8.2.  Issues not Discussed

   Because this case, memo only tries to provide the system may suffer from most essential high level
   requirements, some important issues in designing concret security
   mechanisms are not covered in the
      replay attacks.

6.  IANA Considerations

   This document makes no request of IANA.

   Note requirements.  Such issues include:

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

7.  Security Considerations

   TBD

8. manage keys/credentials during their life periods

   o  How to support algorithm agility

   o  How to provide accountability

   o  How to secure the management interfaces

   o  Use underlying security protocols versus design integrated
      security extensions

9.  Acknowledgements

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

9.

10.  References

9.1.

10.1.  Normative References

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

9.2.

10.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
              ietf-nvo3-framework-04 (work in progress), July November 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-05 draft-mahalingam-dutt-dcops-vxlan-06
              (work in progress), October November 2013.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

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

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
              4306, 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