Network Working Group                                        S. Hartman
Internet-Draft
Internet Draft                                        Painless Security
Intended status: Experimental Informational                                 D. Zhang
Expires: April 30, July 28,, 2015                                           Huawei                                         Alibaba
                                                           M. Wasserman
                                                      Painless Security
                                                        October 27, 2014
                                                               Z. Qiang
                                                               Ericsson
                                                           Mingui Zhang
                                                                 Huawei
                                                       January 28, 2015

                       Security Requirements of NVO3
                draft-ietf-nvo3-security-requirements-03
                 draft-ietf-nvo3-security-requirements-04

Abstract

   The draft describes a list of essential requirements in order to
   benefit the design of NOV3 NVO3 security solutions. In addition, this
   draft introduces the candidate techniques which could be used to
   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 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 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 30, July 28, 2015.

Copyright Notice

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

1.  Introduction

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

   The remainder of this document is organized as follows.  Section 2
   introduces several key terms used in this memo.  Section 3 gives a
   brief introduction of the NVO3 network architecture.  Section 4
   discusses the attack model of this work.  Section 5 provides a list
   of security requirements as well as the 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 [RFC7365] and [I-D.ietf-nvo3-hpvr2nve-cp-req].
   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.

   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 +--+--++--------+
                +--------+  |    . |   Network   | NVE || Tenant |
                | Tenant +--+    . |             |     || System |
                | System |       .  \ +---+      +--+--++--------+
                +--------+       .....|NVE|.........
                                      +---+
                                        |
                                        |
                              =====================
                                |               |
                            +--------+      +--------+
                            | Tenant |      | Tenant |
                            | System |      | System |
                            +--------+      +--------+

   Figure 1: Generic Reference Model for DC Network Virtualization
   Overlays [RFC7365]

   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 ingress NVE.  Then
   encapsulated packet is then sent to the remote NVE through a proper
   tunnel.  When reaching the egress NVE of the tunnel, the packet is
   decapsulated and forwarded to the target tenant system.  The address
   advertisements and tunnel mappings are distributed to the NVEs by a
   logically centralized server (i.e., NVA).

4.  Threat Model

   To benefit describing the threats a NVO3 network may have to face,
   the attacks considered in this document are classified into three
   categories: the attacks from compromised NVO3 devices (inside
   attacks), the attacks from compromised tenant systems, and the
   attacks from underlying networks (outside attacks).

   The adversaries performing the first type of attack are called as
   insiders or inside attackers because they need to get certain
   privileges NVE-Hypervisor Data Plane................................13
   7. Candidate Techniques..........................................15
      7.1. Entity Authentication....................................15
      7.2. Packet Level Security....................................15
      7.3. Authorization............................................15
   8. IANA Considerations...........................................16
   9. Security Considerations.......................................16
      9.1. Automated Key Management in changing the configuration or software of NVO3 devices
   beforehand and initiate the attacks within the overlay security
   perimeter.  In the second type of attack, an attacker (e.g., a
   malicious tenant, or an attacker who has compromised a virtual
   machine of an innocent tenant) has got certain privileges NVO3.........................16
   10. Acknowledgements.............................................17
   11. References...................................................17
      11.1. Normative References....................................17
      11.2. Informative References..................................17

1. Introduction

   As described in changing
   the configuration or software of tenant systems and attempts to
   manipulate the controlled tenant systems to interfere with the normal
   operations of [RFC7365], the NVO3 overlay.  The third type of attack framework is referred
   to as the outside attack since adversaries do not have intended to obtain any
   privilege on the NVO3 devices or tenant systems in advance aid in order
   to perform this type attack,
   standardizing protocols and thus the adversaries performing
   outside attacks are called as outside attackers or outsiders.

4.1.  Capabilities of Outsiders mechanisms to support large-scale multi-
   tenancy data centers. In practice, an outside attacker may perform attacks by intercepting
   packets, deleting packets, and/or inserting bogus packets.  With such kind data center, security is a
   successful outside attack, an attacker may key
   issue which needs to be able to:

   1.  Analyze the traffic pattern within the network by performing
       passive attacks,

   2.  Disrupt the network connectivity or degrade considered during the network service
       quality (e.g., by performing DoS attacks), or

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

4.2.  Capabilities of Insiders

   Besides intercepting packets, deleting packets, and/or inserting
   bogus packets, an inside attacker may use already obtained privilege
   to,

   1.  Interfere with the normal operations of design. This
   document discusses the overlay as security risks that a legal NVO3 device, by sending packets containing invalid information or
       with improper frequencies,

   2.  Perform spoofing attacks network may
   encounter and impersonate another legal NVO3
       device tries 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 provide a list of Malicious TSes

   It is assumed essential security
   requirements that the attacker performing attacks from compromised
   TSes is able needs to intercept packets, delete packets, and/or insert
   bogus packets. be fulfilled. In addition, after compromising a TS, an attacker may this document
   introduces the candidate techniques which could be able to:

   1.  Interfere with potentially used
   to construct a security solution fulfilling the normal operations security
   requirements.

   The remainder of the overlay this document is organized as follows. Section 2
   introduces several key terms used in this memo. Section 3 gives 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
   brief introduction of the
       cryptographic information it obtained, and

   3.  Access NVO3 network architecture. Section 4
   discusses the contents attack model of this work. Section 5 lists the scope of
   the data/control packets if they security considerations of this memo. Section 6 provides a list
   of security requirements as well as the associated justifications. In
   Section 7, the candidate techniques are introduced. Section 9
   discusses additional security considerations.

2. Terminology

   This document uses the same terminology as defined in the NVO3
   Framework document [RFC7365] and the Hypervisor to NVE Control Plane
   Requirements document [I-D.ietf-nvo3-hpvr2nve-cp-req]. The Followings
   are
       encrypted with the keys held additional terminologies that are used by this document.

   Hypervisor: This memo uses the attacker.

4.4.  Security Issues In Scope and Out of Scope

   During term "hypervisor" throughout when
   describing requirements at the specification Split-NVE scenario where part of security requirements, the following
   security issues needs to be considered:

   1.  A underlying network connecting NOV3 devices (NVEs and NVAs) is
       relatively secure if it
   NVE functionality is located within off-loaded to a data center and
       cannot be directly accessed by any tenants or outsiders.
       However, separate device from the
   "hypervisor" that contains a NVO3 overlay for virtual data center may scatter
       across different geographically distributed sites which are VM connected through to a VN. In this context,
   the term "hypervisor" is meant to cover any device type where part of
   the public Internet. NVE functionality is off-loaded in this fashion, e.g. a Network
   Service Appliance, Linux Container.

   NVO3 device: In this case, outside
       attacks may be raised from memo, the underlying network connecting devices (e.g., NVE and NVA) work
   cooperatively to provide NVO3 overlay functionalities are referred as
   NVO3 devices.

   2.  During the design of a security solution

3. NVO3 Overlay Architecture

                +--------+                                    +--------+
                | Tenant +--+                            +----| Tenant |
                | System |  |                           (')   | System |
                +--------+  |    .................     (   )  +--------+
                            |  +---+           +---+    (_)
                            +--|NVE|---+   +---|NVE|-----+
                               +---+   |   |   +---+
                               / .    +-----+      .
                              /  . +--| NVA |      .
                             /   . |  +-----+      .
                            |    . |               .
                            |    . |  L3 Overlay +--+--++--------+
                +--------+  |    . |   Network   | NVE || Tenant |
                | Tenant +--+    . |             |     || System |
                | System |       .  \ +---+      +--+--++--------+
                +--------+       .....|NVE|.........
                                      +---+
                                        |
                                        |
                              =====================
                                |               |
                            +--------+      +--------+
                            | Tenant |      | Tenant |
                            | System |      | System |
                            +--------+      +--------+
     Figure 1 : Generic Reference Model for DC Network Virtualization
                            Overlays [RFC7365]

   This figure illustrates a generic reference model for NVO3 network, the
       attacks raised from compromised NVEs and hypervisors needs to be
       considered.

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

   The following issues are out of scope of 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.  For instance, an attack caused by a
       weakness in a cryptographic algorithm is out of scope, while an
       attack caused by failure logical L2/L3 interconnect for the TSes that
   belong to use confidentiality when
       confidentiality is a security requirement is in scope.

   2.  An attacker controlling an underlying specific tenant network device may break
       the communication of the overlays by discarding or delaying the
       delivery of the packets passing through it.  This type of attack
       is out of scope of this memo.

   3.  NVAs are centralized servers and play over a critical role in NVO3
       overlays. L3 networks. A NVE will believe in the mapping information obtained packet
   received from its NVA.  After compromising a NVA, tenant system is encapsulated by the attacker can
       distribute bogus mapping information ingress NVE.
   Then encapsulated packet is then sent to NVEs under the management
       of NVA.  This work does not consider how to deal with this
       problem.

5.  Security Requirements

5.1.  Control/Data Plane of NVO3 Overlay

   In this section, remote NVE through a
   proper tunnel. When reaching the security requirements associated with egress NVE of the NVE-
   NVA control plane, tunnel, the NVA-NVA control plane, packet
   is decapsulated and forwarded to the NVE-NVE data
   plane target tenant system. The
   address mappings and other related information are proposed.

5.1.1.  NVE-NVA Control Plane

   In distributed to the
   NVEs by a NVE-NVA control plane, it is assumed that logically centralized Network Virtualization Authority
   (NVA).

4. Threat Model

   To benefit describing the threats a NVE only exchanges
   control traffics with its NVA using unicast.

   REQ 1:  The security solution for NVO3 SHOULD enable two network may have to face,
   the attacks considered in this document are classified into three
   categories: the attacks from compromised NVO3 devices
      to mutually authenticate each other.

      Entity authentication can protect a network device against
      imposter (inside
   attacks), the attacks from compromised tenant systems, and then reduce the risk of DoS
   attacks and man-
      in-the-middle attacks.  In addition, a successful authentication
      normally results from underlying networks (outside attacks).

   The adversaries performing the first type of attack are called as
   insiders or inside attackers because they need to get certain
   privileges in changing the distribution key materials for configuration or software of NVO3 devices
   beforehand and initiate the attacks within the overlay security protection for subsequent communications.  Note that
   perimeter. In the second type of attack, an attacker (e.g., a
   malicious tenant, or an attacker who has compromised a virtual
   machine of an innocent tenant) has got certain privileges in changing
   the circumstance where no authentication protocols are applied
      there could be no entity authentication configuration or software of tenant systems and communicating NOV3
      devices use message authentication mechanisms attempts to verify each
      other's identity.  More detailed discussions are provided in
      Section 8.1.

   REQ 2:  The security solution
   manipulate the controlled tenant systems to interfere with the normal
   operations of the NVO3 MUST be able overlay.  The third type of attack is referred
   to provide
      integrity protection, replay protection, and packet origin
      authentication for as the control packets.

      Unlike entity authentication mentioned in REQ 1, message
      authentication is performed outside attack since adversaries do not have to obtain any
   privilege on each incoming packet.  Through
      message authentication, the NOV3 device receiving a control packet
      can verify whether NVO3 devices or tenant systems in advance in order
   to perform this type attack, and thus the packet is generated adversaries performing
   outside attacks are called as outside attackers or outsiders.

4.1. Capabilities of Outsiders

   In practice, an outside attacker may perform attacks by intercepting
   packets, deleting packets, and/or inserting bogus packets. With a legitimate NVO3
      device, is not antique, and is not tampered during transportation.
      Such protection
   successful outside attack, an attacker may be deployed when able to:

  1. Analyze the control packets could be
      accessed traffic pattern within the network by outside attackers.  In addition, with performing
     passive attacks;

  2. Disrupt the support of
      properly distributed keys, these level protection can also benefit network connectivity or degrade the detection of spoofing attacks raised from insiders.

   REQ 3:  The security solution of a NVO3 network MAY provide
      confidentiality protection for service
     quality (e.g., by performing DoS attacks); or

  3. Access the control packets.

      On many occasions, contents of the control data/control packets can be transported in
      plaintext.  However, under which are not
     properly encrypted.

4.2. Capabilities of Insiders

   Besides intercepting packets, deleting packets, and/or inserting
   bogus packets, an inside attacker may use already obtained privilege
   to,

  1. Interfere with the circumstances where some
      information contained within normal operations of the control overlay as a legal
     NVO3 device, by sending packets is considered to
      be sensitive containing invalid information or valuable,
     with improper frequencies;

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

  3. Access the contents of the data/control packets if they are
     encrypted in
      order to prevent outsiders from accessing with the sensitive data. when keys held by the underlying network attacker.

4.3. Capabilities of Malicious TSes

   It is not secure.  Note assumed that encryption will
      impose additional overhead in processing control packets and make
      NVAs more vulnerable to DoS/DDoS attacks.

   REQ 4:  Before adopting the information within a control packet, attacker performing attacks from compromised
   TSes is able to intercept packets, delete packets, and/or insert
   bogus packets. In addition, after compromising a
      NOV3 device receiving the packet MUST TS, an attacker may
   be able to verify whether to:

   1. Interfere with the packet comes from one who has normal operations of the privilege to send that
      packet.

      When receiving overlay as a control packet, besides authentication,
      authorization needs to be carried out legal
     TS, by the receiver sending packets containing invalid information or with
     improper frequencies to identify
      the role that the packet sender acts as in the overlay NVEs;

   2. Perform spoofing attacks and then
      assess the sender's privileges.  If a compromised impersonate another legal TS or NVE tries to
      illegally elevate its privilege (e.g., using its credentials
     to communicate with other victims (other legal NVEs as a NVA, or attempting to access TSes) using the
      mapping
     cryptographic information of the VNs which it is not authorized to
      serve), it will be detected obtained; and rejected.

   REQ 5:  The security solution

   3. Access the contents of NVO3 SHOULD be able to provide
      distinct the data/control packets if they are
     encrypted with the keys to protect held by the unicast control traffics exchanged
      between a NVA and different NVEs respectively. attacker.

5. Scope

   During the exchange specification of control packets, keys are critical in
      authenticating security requirements, the packet senders. following
   security issues needs to be considered:

   1. The purpose of this
      requirement NVO3 connections may be considered as secured if there is to provide a basic capability to confine the damage
      caused
     security solution supported by inside attacks.  After compromising a NVE, an attacker
      will not be able to use the keys it obtained to breach the underlying network. However
     such kind security of solution normally only can protect the control traffics exchanged between NVO3
     network from outsider attacker.

   2. During the NVA and
      other NVEs.

   In design of a security solution for a NVO3 overlay, NVAs can be network, the valuable targets of DoS/DDoS
   attacks, and large amount of
     attacks raised from compromised NVEs can be potentially used as
   reflectors in reflection attacks.  Therefore, the DoS/DDoS risks and hypervisors needs to be considered during designing
     considered.

   3. It is reasonable to consider the control planes for NOV3. conditions where the network
     connecting TSes and NVEs is accessible to outside attackers.

   The following two requirements issues are used to benefit out of scope of consideration in this
   document:

   1. In this memo it is assumed that security protocols, algorithms,
     and implementations provide the migration security properties for which they
     are designed; attacks depending on a failure of
   DoS/DDoS issue.

   REQ 6:  A NVO3 device MUST send its control packets with limited
      frequencies.

      Without this limitation, assumption
     are out of scope. For instance, an attack caused by a weakness in
     a cryptographic algorithm is out of scope, while an attacker can attempt to perform DDoS
      attacks attack caused
     by failure to exhaust use confidentiality when confidentiality is a
     security requirement is in scope.

   2. An attacker controlling an underlying network device may break the limited computing and memory resources
     communication of a
      NVA the overlays by manipulating discarding or delaying the NVEs attached to
     delivery of the NVA packets passing through it. The security
     consideration to generate a
      significant member prevent this type of mapping queries in attack is out of scope of
     this memo.

   3. NVAs are centralized servers and play a short period.

   REQ 7:  The amplification effect SHOULD be avoided

      If critical role in certain conditions the responses generated by a NVO3
     overlay network. A NVE are much
      longer than the received requests, will believe in the NVE may be taken advantage
      of by an attacker as mapping information
     obtained from its NVA. After compromising a reflector to carry out DDoS attacks.
      Specifically, NVA, the attacker can concurrently send out a large
      amount of spoofed short requests
     distribute bogus mapping information to multiple NVEs with under the source
      address management
     of a victim (e.g., a NVA).  The responses generated by the
      NVEs will be forwarded to 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. NVA. The NVAs may use unicast
   and/or multicast to exchange signaling packets within the control
   plane.

   Except the key deployment requirement (REQ 5), all the other security requirements discussed in the NVE-NVA control plane (REQs 1,2,3,4, 6, and 7)
   are applicable in the NVA-NVA control plane as well.  Before two this document is to
     protect a NVA
   communicate with each other, they from any security risk. And if a NVA is attacked, it
     should be able detected. However, this work does not consider how to mutually
   authenticated.  In addition, message authentication can help
     deal with the problem after a NVO3
   device NVA is compromised.

   4. Because this memo only tries to verify the authenticity of the received packets, and provide the
   sensitive information most essential high
     level requirements, some important issues in designing concept
     security mechanisms are not covered in the control packets need requirements. Such
     issues include:

     -  How to be encrypted.
   Authorization is important manage keys/credentials during their life periods

     -  How to filter the invalid control packets and
   any un-privileged requests.  Moreover, the approach support algorithm agility

     -  How to mitigating
   DoS/DDoS attacks needs provide accountability

     -  How to be considered in the control plane
   protocols.

   The key deployment requirements for secure the NVA-NVA control plane are
   described as follows:

   REQ 8:  The management interfaces

     -  Use underlying security solution protocols versus design integrated
        security extensions

6. Security Requirements

6.1. Control Plane of NVO3 SHOULD be able to provide
      different keys to protect Overlay

   In this section, the unicast security requirements associated with following
   control traffics exchanged
      between different NVO3 devices respectively. plane are described:

   -  The purpose of this requirement is to provide NVE-NVA control plane: allows a basic capability NVE to confine obtain information
     about the damage caused by compromised key.  The compromise location and status of a key will not affect the traffics protected by other keys.

   REQ 9:  If there are multicast packets, the security solution of NVO3
      SHOULD be able TSs with which it needs to assign distinct cryptographic group keys
     communicate; to provide updates to
      protect the multicast packets exchanged among NVA about the NVO3 devices
      within different multicast groups.

      In order to provide an essential packet level security protection
      specified in REQs 2 attached TSs;
     and 3, at least to report any communication errors. In this case, the term
     "NVO3 device" is referring to a group key NVA or a NVE.

   -  The NVA-NVA control plane: Multiple NVAs may need to be
      shared among the NVEs deployed in a same mutlicast group.  It NVO3
     overlay for better scalability and fault tolerance capability. The
     NVAs may use unicast and/or multicast to exchange signaling
     packets within the control plane. In this case, the term "NVO3
     device" is
      recommended referring to use different keys for different mutlicast groups.

5.1.3. a NVA.

   -  The NVE-NVE Control Plane control plane: As specified in [RFC7365], in order to
     obtain reachability information, NVEs may exchange information
     directly between themselves via a control-plane protocol.

   The requirements in the NVA-NVA control plane (REQs 1,2,3,4, 6, 7,8,
   and 9) are applicable in In this
     case, the NVE-NVE control plane as well.

5.1.4.  NVE-NVE Data Plane

   As specified in [RFC7365], a NVO3 overlay needs term "NVO3 device" is referring to generate tunnels
   between NVEs for data packet transportation.  When a data packet
   reaches NVE.

   -  The NVE-Hypervisor control plane: In the boundary of a overlay, Split-NVE scenario, the ingress
     NVE will encapsulate
   the packet and forward it hypervisors may also need to exchange signaling packets
     over network in order to facilitate, e.g., VM online detection, VM
     migration detection, or auto-provisioning/service discovery as
     described in [RFC7365]. In this case, the destination egress NVE through term "NVO3 device" is
     referring to a
   proper tunnel. Hypervisor or a NVE.

     REQ 10: 1. The security solution for NVO3 SHOULD MUST enable the two NVEs NVO3
       devices to mutually authenticate each other before establishing a tunnel
      connecting them for data transportation.

      This entity exchanging
       any control packets.

   Entity authentication requirement is used to can protect a NVE NVO3 device against imposter attacks.  Also, this requirement can help
      guarantee a data tunnel is generated between two proper NVEs
   attacks and then reduce the risk of man-in-the-middle DoS/DDoS attacks and man-in-the-
   middle attacks. In order to protect the data packets transported over the overlay
   against the attacks raised from addition, a successful authentication normally
   results in the underlying network, distribution key materials for the NVO3
   overlay needs to provide essential security protection
   for data
   packets. subsequent communications. More detailed discussions are provided
   in Section 6.1.

     REQ 11: 2. The security solution of NVO3 MUST be able to provide
       integrity protection, replay protection, and packet origin
       authentication for data traffics the control packets exchanged between NVEs.

      This requirement two
       NVO3 devices.

   Message authentication is used to performed on each incoming packet. Packet
   level security protection can prevent an attacker who has
      compromised from illegally
   interfere with the normal operations of NVO3 device by injecting
   bogus control packets into the network. Through message
   authentication, the NVO3 device receiving a underlying network control packet can verify
   whether the packet is generated by a legitimate NVO3 device, is not
   antique, and is not tampered during transportation.

   Such protection must be deployed if there is any possibility that the
   control packets could be accessed by outside attackers. This
   protection can prevent an attacker locating in the middle between the
   NVO3 devices on and modifying the path information in the control packet so
   as to redirect the traffic as wished. In addition, with the support
   of properly distributed keys, these level protections can also
   benefit the detection of spoofing attacks raised from
      replaying antique insiders.

     REQ 3. The security solution of a NVO3 network SHOULD provide
       confidentiality protection for the control packets exchanged
       between two NVO3 devices.

   On many occasions, the control packets can be transported in
   plaintext. However, if the information contained within the control
   packets is considered to be sensitive or injecting bogus data valuable, it is recommended
   to encrypt the packets in order to prevent outsiders from accessing
   the sensitive data, especially when the underlying network is not
   secured enough. Note that encryption will impose additional overhead
   in processing control packets and make NVO3 devices more vulnerable
   to DoS / DDoS attacks.

     REQ 4. Node authorization procedure MUST be supported before
       processing any received control packets without
      being detected.

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

      If the data traffics from in the TSes are sensitive, they NVO3 device

   When receiving a control packet, besides authentication,
   authorization needs to be
      encrypted when being transported within carried out by the overlay.  Otherwise,
      encryption receiver to identify the
   role that the packet sender acts as in the overlay and then assess
   the sender's privileges. If a compromised NVO3 device tries to
   illegally elevate its privilege, it will be unnecessary.  In addition, in practice, tenants detected and rejected.
   For instance, a compromised NVO3 device may also select use its credentials to encrypt their sensitive data during
      transportation.  Therefore this confidentiality requirement for
      data plane is then not as crucial
   communicate with other NVEs as a NVA, or attempting to access or
   update the integrity requirement. mapping information of the VNs which it is not authorized
   to serve.

     REQ 13: 5. The security solution of NVO3 SHOULD be able to assign
      different provide
       distinct cryptographic keys for each NVO3 device to protect the
       unicast tunnels control traffics exchanged between NVEs different NVO3
       devices respectively.

      This

   During the exchange of control packets, keys are critical in
   authenticating the packet senders. The purpose of this requirement is used
   to provide a basic capability to confine the damage caused by inside
   attacks.  When different tunnels secured with different keys, the
      compromise of a key in  After compromising a tunnel NVO3 device, an attacker may be able
   to use the keys it obtained to exchange control traffics with other
   NVO3 devices. But it will not affect the security of
      others.  In addition, if the key used be able to protect a tunnel is only
      shared by the NVEs on the both sides, use the egress NVE receiving a
      data packet is able keys it obtained to distinctively prove
   breach the identity security of the
      ingress NVE encapsulating the data packet during the message
      authentication. control traffics exchanged between other
   NVO3 devices.

     REQ 14:  If there are multicast packets, the 6. The security solution of NVO3 SHOULD be able to assign
       distinct cryptographic group keys for each multicast group to
       protect the multicast packets exchanged among the NVEs NVO3 devices
       within the group.

   In order to provide an essential packet level security protection
   specified for integrity and confidentiality, at least one group key
   may need to be shared among the NVO3 devices in a same multicast
   group. It is recommended to use different keys for different
   multicast groups.

      In practice,

     REQ 7. The resistance at DOS/DDOS attack MUST be considered in the
       design of NVO3 control plane

   Any NVO3 devices may be used by an attacker to initiate a NVE DOS/DDOS.
   One example is that in a NVO3 overlay, NVAs can be the valuable
   targets of DoS/DDoS attacks, and large amount of NVEs can be
   potentially used as reflectors in reflection attacks.  Therefore, the
   DoS/DDoS risks needs be considered during designing the control
   planes for NVO3. The following requirements, but not limited to this
   listed, are used to benefit the migration of DoS/DDoS issue.

          REQ 7.a.  A NVO3 device MUST have a frequency limitation at
             sending its control packets and processing any received
             control packets.

   Without this limitation, an attacker can attempt to perform DoS/DDoS
   attacks to exhaust the limited computing and memory resources of a
   target NVO3 device by manipulating a compromised NVO3 device to
   generate a significant amount of control plane packets in a short
   period.

          REQ 7.b.  The amplification effect MUST be avoided

   A distributed denial-of-service attack may need involve sending forged
   requests of some type to a very large number of NVO3 devices that
   will reply to use the multicast capability
      provided requests. If in certain conditions, the responses
   generated by a NVO3 device are a much longer process than the underlying network to transfer multicast packets
      to other NVEs.  In
   received requests. An attacker may take advantage of this case, in order
   amplification effect procedure, which the NVO3 device is used as a
   reflector to provide an essential
      packet level security protection specified in requirements 11 and
      12, at least carry out DoS / DDoS attacks towards a group key victim NVO3
   device.

   For instance, the attacker may need send request messages to be shared among the NVEs in a
      same mutlicast group, in order NVO3 device
   with a spoofed source address set to provide packet level
      authentication or optionally confidentiality protection for the
      multicast packets transferred within targeted victim. In that
   case, all the group.  It is recommended
      to deploy different keys for different mutlicast groups, in order
      to confine replies generated by the insider attacks on NVEs.

   REQ 15:  Upon receiving a data packet, an egress NVE must NVO3 device will be able sent (and
   flooded) to
      verify whether the packet is from a proper ingress NVE which target. Another example is
      authorized to forward that packet.

      In cooperation with authentication, authorization enables as discussed in [I-
   D.ietf-nvo3-arch], a egress NVE may wish to detect query the data packets which violate certain security
      policies, even NVA about individual
   mapping when they are forwarded from a legal NVE.  For
      instance, if receiving a data packet belonging to a VN with unknown destination address.
   This query procedure may also be triggered at ARP / ND message
   handling or when NVE-NVE interaction message is forwarded from an
      ingress NVE received. An attacker
   may take advantage of this query procedure which the NVE is not supposed used as a
   reflector to carry out DoS / DDoS attacks towards the NVA.

   Specifically, the attacker can concurrently send out a large amount
   of spoofed short request messages to support that VN, multiple NVO3 devices which the packet
      needs to
   amplification effect can be detected and discarded.  Note that the detection of a
      invalid packet enlarged which may not indicate that overwhelm the system is under a
      malicious attack.  Mis-configuration or byzantine failure victim's
   processing capability quickly.

     REQ 8. The security solution of a NVE
      may also result in such invalid packets.

5.2.  Control/Data Plane between NVEs NVO3 SHOULD be able to provide
       different security levels of protections for the control
       traffics and Hypervisors

   Apart from data traffics, the NVE traffics exchanged between NVO3 devices.

   In NVE-NVE interface and hypervisors NVE-Hypervisor interface, the same security
   solution may also need to
   exchange signaling packets in order be used to facilitate, e.g., VM online
   detection, VM migration detection, or auto-provisioning/service
   discovery [RFC7365].

   A NVE and protect both the hypervisors working with it can be deployed in a
   distributed way (e.g., control plane and data plane
   traffic. In many cases, the NVE is implemented in an individual
   device, control and data traffics between NVO3
   devices may be transported over the hypervisors are located on servers) same path or in a co-
   located way (e.g., even within the NVE same
   security channel. However, the control traffics and data traffics may
   have different levels of security sensitivity. Therefore, the hypervisors are located
   protection on the
   same server). traffic needs be distinguished. In the former this case, the data and control traffic
   between the NVE and the hypervisors are exchanged over network.

5.2.1.  Distributed Deployment of NVE and Hypervisor

   Five
   security requirements appliabled solution may need to provide different security channels for both
   control traffics and data
   packets traffics respectively and protect the data
   traffics and control traffics exchanged between NVO3 devices with
   different keys and ciphers.

6.2. NVE-NVE Data Plane

   As specified in [RFC7365], a NVO3 overlay needs to generate tunnels
   between NVEs for data packet transportation. When a data packet
   reaches the boundary of an overlay, the ingress NVE will encapsulate
   the packet and hypervisors are listed as follows: forward it to the destination egress NVE through a
   proper tunnel.

     REQ 16: 9. The security solution for NVO3 SHOULD MAY enable the
      communicating NVE and hypervisor two NVEs to
       mutually authenticate each other before exchanging any control/ establishing a tunnel
       for data packets.

      Mutual transportation.

   This entity authentication requirement is used to prevent an attacker from
      impersonating protect a legal NVE or
   against imposter attacks. Also, this requirement can help guarantee a hypervisor without being detected
   data tunnel is generated between two proper NVEs and then reduce the risks risk
   of man-in-the-middle attacks.  A
      successful authentication normally results in the distribution key
      materials

   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 of subsequent communications. protection for data
   packets.

     REQ 17: 10.   The security solution of NVO3 MUST SHOULD be able to provide
       integrity protection, replay protection protection, and packet origin
       authentication for the control/ data packets traffics exchanged between a NVE and a
      hypervisor.

      Packet level security protection can NVEs.

   This requirement is used to prevent an attacker from
      illegally interfere with who has compromised
   underlying network devices on the normal operations of NVEs and
      hypervisors by path from replaying antique packets
   or injecting bogus control data packets into the network.
      In addition, because it without being detected.

   Such protection must be deployed if there is assumed the network connecting the NVE
      and any possibility that the hypervisor is potentially accessible to attackers,
      security solutions need to
   data packets could be accessed by outside attackers. This protection
   can prevent an attacker locating in the middle between the NVE and the hypervisor from modifying the VN
      identification the NVEs and
   modifying the tunnel address information in the data packet header so
   as to redirect the data traffic as wished.

     REQ 11.   The security solution of NVO3 MAY be able to provide
       confidentiality protection for data traffics exchanged between
       NVEs, if information in leaking is a concern.

   If TS data traffic privacy is required, the packet headers so as TS data traffic needs to
      manipulate
   be encrypted when being transported within the NVE overlay. In practice,
   tenants may select end-to-end security solutions to transport the encrypt their
   sensitive data packets within a VN to
      another. during transportation. Therefore this confidentiality
   requirement for data plane is an optional requirement.

     REQ 18:  If a NVE needs to communicate with multiple hypervisors, the 12.   The security solution of a NVO3 network SHOULD be able to provide assign
       different cryptographic keys and ciphers to secure protect the control /data packets
      exchanged unicast tunnels
       between different hypervisors and their NVEs respectively.

   This requirement is used to benefit confine the damage confinement of caused by inside
   attacks.  For instance, When different tunnels secured with different keys, the
   compromise of a hypervisor key in a tunnel will not affect the security of control/data traffics other
   tunnels. In addition, if the key used to protect a 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
   encapsulating the data packet during the message authentication.

     REQ 13.   If there are multicast packets, the security solution of
       NVO3 SHOULD be able to assign distinct cryptographic group keys
       to protect the multicast packets exchanged between among the NVEs within
       different multicast groups.

   In NVO3, a NVE and other hypervisors. may need to support data plane multicast capability.
   In order to provide an essential packet level security protection
   (including authentication, integrity, confidentiality) for the
   multicast packets transferred within the group, at least one group
   key may need to be shared among the NVEs of the same multicast group.
   It is recommended to deploy different keys for different multicast
   groups, in order to confine the insider attacks on NVEs.

     REQ 19:  Before accepting 14.   Upon receiving a control/data data packet, a an egress NVE or a
      hypervisor receiving the packet MUST be able
       to verify that the device
      sending whether the packet is sent from a proper ingress NVE
       which is authorized to do so.

      This is an authorization requirement.  When receiving a control/
      data packet, besides forward that packet.

   In cooperation with authentication, authorization needs to be
      carried out by a enables an egress
   NVE or a hypervisor to identify the role that the
      packet sender acts as and then assess detect the sender's privileges.
      Therefore, if a compromised hypervisor attempts to use it
      credentials to impersonate data packets which violate certain security
   policies, even when they are forwarded from a legal NVE. For
   instance, if  the remote NVE is not authorized to communicate with other
      hypervisors, it will be detected.

   REQ 20:  The security solution forward data packet
   of a NVO3 SHOULD be able given VN, the packet needs to provide
      different security levels be detected and discarded without
   processing. Note that the detection of protections for an invalid packet may not
   indicate that the control/data
      traffics exchanged between system is under a NVE malicious attack. Mis-
   configuration or byzantine failure of a hypervisor.

      The control and data traffics between NVE may also result in such
   invalid packets.

6.3. NVE-Hypervisor Data Plane

   As described in the NVO3 architecture draft [I-D.ietf-nvo3-arch], in
   split-NVE scenario, a number of link types are possible between NVE
   and hypervisor. One simple deployment scenario may have a hypervisor simple L2
   Ethernet link. A more complicated scenario may
      be transported over the same path or even within have the same security
      channel.  However, server and
   NVE separated by a bridged access network, such as when the control traffics NVE
   resides on a ToR, with an embedded switch residing between servers
   and data traffics
      have different levels of sensitivity, the protection on them needs ToR.

   In any of above deployment scenarios, the data link between NVE and
   hypervisor may be different. potentially accessible to attackers, e.g. with a
   shared link. In this that case, the security solution solutions, including integrity
   protection and confidentiality protection, may need be needed to
      different security channels for control and data traffics
      respectively and so protect secure
   the data and control traffics
      exchanged between a hypervisor and a NVE with different keys and
      ciphers.

5.2.1.1.  Control Plane link.

     REQ 21: 15.   The security solution of a NVO3 network MAY SHOULD be able to provide
      confidentiality
       integrity protection, replay protection and origin
       authentication for the control traffics data packets exchanged between a NVE and
       a hypervisor.

      The contents of the control/data packets need to be encrypted when
      they are considered to be sensitive.

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

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

      This is a common

   Packet level security requirement that protection can effectively avoid prevent an attacker from
   illegally interfere with the capability normal operations of a device in processing control packets to be
      overwhelmed NVEs and
   hypervisors by the high frequent control injecting bogus packets generated by into the
      devices attached to it.

   REQ 23:  Amplification effect SHOULD be Addressed.

      If network. Because it
   is assumed that the responses generated by a NVE or a hypervisor are much
      longer than network connecting the received requests, an attacker may take advantage
      of NVE and the device as a reflector hypervisor is
   potentially accessible to perform DDoS attacks.
      Specifically, the attacker sends a large amount of spoofed short
      requests attackers, security solutions need to NVEs or hypervisors with
   prevent an attacker locating in the source address of a
      victim.  The responses will then be generated by middle between the NVEs NVE and
      forwarded to the victim and overwhelm its process capability.
      This issues should be considered
   hypervisor from modifying the information in the design of data packet headers
   so as to redirect the control
      protocols.

5.2.1.2.  Data Plane traffic as wished.

     REQ 24: 16.   The security solution of a NVO3 network MUST MAY provide
      security gateways to control
       confidentiality protection for the data traffics across the
      boundaries of different VNs according to specified security
      policies.

      In [RFC7364], exchanged
       between a NVE and a hypervisor.

   If TS data packet privacy is required, the data plane isolation requirement amongst
      different VNs has been discussed. packet needs to be
   encrypted. The traffic within security solution of a virtual NVE network can only be transited into another one in a controlled
      fashion (e.g., via may need to provide
   confidentiality for the data packets exchanged between a configured router and/or NVE and a security gateway).
   hypervisor if they have to use an insecure network to transport their
   data packet.

     REQ 25: 17.   The security solution of a NVO3 network MAY be able to
       provide
      confidentiality protection for different cryptographic keys to secure the unicast data traffics
       traffic exchanged between different hypervisors and their NVEs
       respectively.

   This requirement is used to benefit the damage confinement of inside
   attacks. For instance, data traffic may be forwarded over a shared
   link between a NVE and a hypervisor.

      When In that case, the contents compromise of the data packets are sensitive to
   a tenant, hypervisor or a NVE will not be able to affect the security of data packet needs to be encrypted.
   traffics exchanged between different hypervisors and their NVEs.

     REQ 18.   The security solution of a
      NVE network may need NVO3 MAY be able to assign
       distinct cryptographic group keys to protect the multicast
       traffic exchanged between different hypervisors and their NVEs
       respectively within different multicast groups.

   If there are multicast data traffic between hypervisors and their
   NVE, in order to provide confidentiality an essential packet level security
   protection (including authentication, integrity, confidentiality) for
   the data
      packets exchanged between a NVE multicast packets transferred within the multicast group, at
   least one group key may need to be shared among the hypervisors and a hypervisor if they have
   their NVE of the same multicast group. It is recommended to
      use an insecure network deploy
   different keys for different multicast groups, in order to transport their data packet and confine
   the
      tenants cannot encrypt insider attacks on the hypervisors and their sensitive data themselves.

6. NVE.

7. Candidate Techniques

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

6.1.

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

   In the circumstance where no authentication protocols are applied,
   the communicating entities could use message authentication
   mechanisms to verify each other's identity.

   The widely adopted protocols supporting entity authentication
   include: IKE[RFC2409], IKEv2[RFC4306], EAP[RFC4137], 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 impersonate
   other victims.

6.2.

7.2. Packet Level Security

   There are requirements about protecting the integrity,
   confidentiality, and provide packet origin authentication for
   control/ data packets. Such functions can be provided through using
   the underlying security protocols (e.g., protocols, e.g., IPsec AH[RFC4302], AH [RFC4302], IPsec
   ESP[RFC4303], TLS[RFC5246]).
   ESP [RFC4303], TLS [RFC5246], or MACsec [802.1AE]. Also, when
   designing the control protocols people can select to provide embedded
   security approaches (just like the packet level security mechanism
   provided in
   OSPFv2[RFC2328]). OSPFv2 [RFC2328]). The cryptographic keys can be manually
   deployed or dynamically generated by using certain automatic key
   management protocols. Note that when using manual key management, the
   replay protection mechanism of IPsec will be switched off.

6.3.

7.3. Authorization

   Without any cryptographic supports, the authorization mechanisms
   (e.g., packet filters) could be much easier to be bypassed by
   attackers, and thus the authorization mechanisms deployed on NOV3 NVO3
   devices should interoperate with entity authentication and other
   packet level security mechanisms, and be able to make the access
   control decisions based on the cryptographically proved results.

   An exception is packet filtering. Because packet filters are
   efficient and can effectively drop some un-authorized packets before
   they have to be cryptographically verified, it is worthwhile to use
   packet filters as an auxiliary approach to dealing with some simple
   attacks and increasing the difficulties of DoS/DDoS attacks
   targeting at the security protocol implementations.

7.

   For instance, a NVE may maintain an authorization NVE table. This
   table may be distributed by a trusted entity, e.g. NVA, in
   combination with the inner-outer address mapping table. And NVE may
   use this table to filter the received control / data packets over
   NVE-NVE interface. The NVE may effectively drop any packets received
   from an unauthorized NVE before processing it, e.g.
   cryptographically verification procedure.

8. IANA Considerations

   This document makes no request of IANA.

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

8.

9. Security Considerations

8.1.

9.1. Automated Key Management in NVO3

   Because entity authentication and automated key distribution are
   normally performed in the same process, the requirements of entity
   authentication have already implied that it is recommended to use
   automated key management in the security solutions for NVO3 networks.
   In the cases where there are a large amount of NVEs working within a
   NVO3 overlay, manual key management becomes infeasible. First, it
   could be 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]. Moreover, some
   security protocols need the support of automated key management in
   order to perform certain security functions properly. As mentioned
   above, the replay protecting mechanism of IPsec will be turned off
   without the support of automated key management mechanisms.

8.2.  Issues not Discussed

   Because this memo only tries

10. Acknowledgements

   Many people have contributed to provide the most essential high level
   requirements, some important issues in designing concret security
   mechanisms development of this document and
   many more will probably do so before we are not covered in the requirements.  Such issues include:

   o  How to 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 done with it. While we
   cannot thank all contributors, some have played an especially
   prominent role. The followings have provided essential input:
   Melinda Shore and Zu Qiang.

10. Makan Pourzandi.

11. References

10.1.

11.1. Normative References

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

10.2.

11.2. Informative References

   [I-D.ietf-nvo3-arch] Black, D., Narten, T., et al, "An Architecture
             for Overlay Networks (NVO3)", draft-narten-nvo3-arch, work
             in progress.

   [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 draft-
             ietf-ipsecme-ad-vpn-problem-09 (work in progress), July
             2013.

   [I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L.,
             Narten, T., and D. Black, "Hypervisor to NVE Control Plane
             Requirements",
              draft-ietf-nvo3-hpvr2nve-cp-req-00 draft-ietf-nvo3-hpvr2nve-cp-req-01 (work in
             progress),
              July November 2014.

   [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-09 draft-mahalingam-
             dutt-dcops-vxlan-09, (work in progress), April 2014.

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

   [RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and
             M. Napierala, "Problem Statement: Overlays for Network
             Virtualization", RFC 7364, October 2014.

   [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
             Rekhter, "Framework for Data Center (DC) Network
             Virtualization", RFC 7365, October 2014.

   [802.1AE] 802.1AE - Media Access Control (MAC) Security

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
   Alibaba
   Chaoyang Dist. Beijing

   P.R. China
   Email: zhangdacheng@huawei.com Dacheng.zdc@alibaba-inc.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

   Zu Qiang
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC, H4P 2N2
   Canada

   Phone: +1 514 345 7900 x47370
   Email: Zu.Qiang@ericsson.com

   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District,
   Beijing 100095

   P.R. China
   Email: zhangmingui@huawei.com