[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hartman-nvo3-security-requirements) 00 01 02 03 04 05 06 07

Network Working Group                                        S. Hartman
Internet Draft                                        Painless Security
Intended status: Informational                                 D. Zhang
Expires: December 14, 2016
                                                           M. Wasserman
                                                      Painless Security
                                                               Z. Qiang
                                                               Ericsson
                                                               M. Zhang
                                                                 Huawei
                                                          June 14, 2016



                       Security Requirements of NVO3
                 draft-ietf-nvo3-security-requirements-07


Abstract

   The draft describes a list of essential requirements in order to
   benefit the design of 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 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 December 14, 2016.




Hartman, et al.       Expires December 14, 2016                [Page 1]


Internet-Draft              NVO3 security                     June 2016


Copyright Notice

   Copyright (c) 2016 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...................................................3
   2. Terminology....................................................3
   3. NVO3 Overlay Architecture......................................4
   4. Threat Model...................................................5
      4.1. Capabilities of Outsiders.................................5
      4.2. Capabilities of Insiders..................................5
      4.3. Capabilities of Malicious TSes............................6
   5. Scope..........................................................6
   6. Security Requirements..........................................7
      6.1. Control Plane of NVO3 Overlay.............................7
      6.2. NVE-NVE Data Plane.......................................11
      6.3. NVE-Hypervisor Data Plane................................13
   7. Candidate Techniques..........................................14
      7.1. Entity Authentication....................................15
      7.2. Packet Level Security....................................15
      7.3. Authorization............................................15
      7.4. Automated Key Management.................................16
   8. IANA Considerations...........................................16
   9. Security Considerations.......................................16
   10. Acknowledgements.............................................17
   11. References...................................................17
      11.1. Normative References....................................17
      11.2. Informative References..................................17
   Authors' Addresses...............................................19







Hartman, et al.       Expires December 14, 2016                [Page 2]


Internet-Draft              NVO3 security                     June 2016


1. Introduction

   As described in [RFC7365], the NVO3 framework is intended to aid in
   standardizing protocols and mechanisms to support large-scale multi-
   tenancy data centers. In such kind data center, security is a key
   issue which needs to be considered during the network design. This
   document discusses the security risks that a NVO3 network may
   encounter and tries to provide a list of essential security
   requirements that needs to be fulfilled. In addition, this document
   introduces the candidate techniques which could be potentially used
   to construct a security solution fulfilling the NVO3 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 document. Section 5 lists the
   scope of the security considerations of this document. Section 6
   provides a list of security requirements as well as the associated
   justifications. In Section 7, the candidate techniques are
   introduced.

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 the additional terminologies that are used by this document.

   Hypervisor: This memo uses the term "hypervisor" throughout when
   describing requirements at the Split-NVE scenario where part of the
   NVE functionality is off-loaded to a separate device from the
   "hypervisor" that contains a VM connected to a VN. In this context,
   the term "hypervisor" is meant to cover any device type where part of
   the NVE functionality is off-loaded in this fashion, e.g. a Network
   Service Appliance, Linux Container.

   NVO3 device: In this memo, the devices (e.g., NVE and NVA) work
   cooperatively to provide NVO3 overlay functionalities are referred as
   NVO3 devices.









Hartman, et al.       Expires December 14, 2016                [Page 3]


Internet-Draft              NVO3 security                     June 2016


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 overlay
   where NVEs provide a logical L2/L3 interconnect for the TSes that
   belong to a specific tenant network over a L3 networks. A packet
   received from a tenant system is encapsulated by 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 mappings and other related information are distributed to the
   NVEs by a logically centralized Network Virtualization Authority
   (NVA).



Hartman, et al.       Expires December 14, 2016                [Page 4]


Internet-Draft              NVO3 security                     June 2016


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 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 in changing
   the configuration or software of tenant systems 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 the outside attack since adversaries do not have to obtain any
   privilege on the NVO3 devices or tenant systems in advance in order
   to perform this type attack, and thus the 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
   successful outside attack, an attacker may be able to:

  A)          Analyze the traffic pattern within the network by performing
     passive attacks;

  B)          Disrupt the network connectivity or degrade the network service
     quality (e.g., by performing DoS attacks); or

  C)          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,

  A)          Interfere with the normal operations of the overlay as a legal NVO3
     device, by sending packets containing invalid information or with
     improper frequencies;


Hartman, et al.       Expires December 14, 2016                [Page 5]


Internet-Draft              NVO3 security                     June 2016


  B)          Perform spoofing attacks and impersonate another legal NVO3 device
     to communicate with victims using the cryptographic information it
     obtained; and

  C)          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:

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

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

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

5. Scope

   The following security issues are in the scope of the NVO3 security
   requirement consideration of this document:

  A)          The NVO3 connections may be considered as secured if there is a
     security solution supported by the underlying network. However such
     kind security solution normally only can protect the NVO3 network
     from outsider attacker.

  B)          During the design of a security solution for a NVO3 network, the
     attacks raised from compromised NVEs and hypervisors needs to be
     considered.

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

   The following security issues are out of scope of the NVO3 security
   requirement consideration of this document:

  A)          In this document, it is assumed that security protocols,
     algorithms, and implementations provide the security properties for


Hartman, et al.       Expires December 14, 2016                [Page 6]


Internet-Draft              NVO3 security                     June 2016


     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 to use confidentiality when
     confidentiality is a security requirement is in scope.

  B)          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. The security
     consideration to prevent this type of attack is out of scope of
     this document.

  C)          NVAs are centralized servers and play a critical role in NVO3
     overlay network. 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. The security requirements discussed in this document is to
     protect a NVA from any security risk. And if a NVA is attacked, it
     should be detected. However, this document does not consider how to
     deal with the problem after a NVA is compromised.

  D)          Because this document only tries to provide the most essential high
     level requirements, some important issues in designing concept
     security mechanisms are not covered in the requirements. Such
     issues include:

       - How to manage keys/credentials during their life periods

       - How to support algorithm agility

       - How to provide accountability

       - How to secure the management interfaces

       - Use underlying security protocols versus design integrated
          security extensions

6. Security Requirements

6.1. Control Plane of NVO3 Overlay

   In this section, the security requirements associated with following
   control plane are described:

   -  The NVE-NVA control plane: allows a NVE to obtain information
     about the location and status of other TSs with which it needs to
     communicate; to provide updates to the NVA about the attached TSs;


Hartman, et al.       Expires December 14, 2016                [Page 7]


Internet-Draft              NVO3 security                     June 2016


     and to report any communication errors. In this case, the term
     "NVO3 device" is referring to a NVA or a NVE.

   -  The 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 within the control plane. In this case, the term "NVO3
     device" is referring to a NVA.

   -  The NVE-NVE control plane: As specified in [RFC7365], in order to
     obtain reachability information, NVEs may exchange information
     directly between themselves via a control-plane protocol. In this
     case, the term "NVO3 device" is referring to a NVE.

   -  The NVE-Hypervisor control plane: In the Split-NVE scenario, the
     NVE and 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 term "NVO3 device" is
     referring to a Hypervisor or a NVE.

     REQ 1. The security solution for NVO3 MUST enable the two NVO3
       devices to mutually authenticate each other before exchanging
       any control packets.

   Entity authentication can protect a NVO3 device against imposter
   attacks and then reduce the risk of DoS / DDoS attacks and man-in-
   the-middle attacks. In addition, a successful authentication normally
   results in the distribution key materials for the security protection
   for subsequent communications. More detailed discussions are provided
   in Section 6.1.

     REQ 2. The security solution of NVO3 MUST be able to provide
       integrity protection, replay protection, and packet origin
       authentication for the control packets exchanged between two
       NVO3 devices.

   Message authentication is performed on each incoming packet. Packet
   level security protection can prevent an attacker 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 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


Hartman, et al.       Expires December 14, 2016                [Page 8]


Internet-Draft              NVO3 security                     June 2016


   protection can prevent an attacker locating in the middle between the
   NVO3 devices and modifying the 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 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 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 in the NVO3 device

   When receiving a control packet, besides authentication,
   authorization needs to be carried out by the 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 detected and rejected.
   For instance, a compromised NVO3 device may use its credentials to
   communicate with other NVEs as a NVA, or attempting to access or
   update the mapping information of the VNs which it is not authorized
   to serve.

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

   During the exchange of control packets, keys are critical in
   authenticating the packet senders. The purpose of this requirement is
   to provide a basic capability to confine the damage caused by inside
   attacks.  After compromising a 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 be able to use the keys it obtained to
   breach the security of the control traffics exchanged between other
   NVO3 devices.




Hartman, et al.       Expires December 14, 2016                [Page 9]


Internet-Draft              NVO3 security                     June 2016


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

     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 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 involve sending forged
   requests of some type to a very large number of NVO3 devices that
   will reply to the requests. If in certain conditions, the responses
   generated by a NVO3 device are a much longer process than the
   received requests. An attacker may take advantage of this
   amplification effect procedure, which the NVO3 device is used as a
   reflector to carry out DoS / DDoS attacks towards a victim NVO3
   device.

   For instance, the attacker may send request messages to a NVO3 device
   with a spoofed source address set to the targeted victim. In that
   case, all the replies generated by the NVO3 device will be sent (and
   flooded) to the target. Another example is that as discussed in [I-


Hartman, et al.       Expires December 14, 2016               [Page 10]


Internet-Draft              NVO3 security                     June 2016


   D.ietf-nvo3-arch], a NVE may wish to query the NVA about individual
   mapping when receiving a packet with unknown destination address.
   This query procedure may also be triggered at ARP / ND message
   handling or when NVE-NVE interaction message is received. An attacker
   may take advantage of this query procedure which the NVE is 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 multiple NVO3 devices which the
   amplification effect can be enlarged which may overwhelm the victim's
   processing capability quickly.

     REQ 8. The security solution of a NVO3 SHOULD be able to provide
       different security levels of protections for the control
       traffics and data traffics exchanged between NVO3 devices.

   In NVE-NVE interface and NVE-Hypervisor interface, the same security
   solution may be used to protect both the control plane and data plane
   traffic. In many cases, the control and data traffics between NVO3
   devices may be transported over the same path or even within the same
   security channel. However, the control traffics and data traffics may
   have different levels of security sensitivity. Therefore, the
   protection on the traffic needs be distinguished. In this case, the
   security solution may need to provide different security channels for
   control traffics and data 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 forward it to the destination egress NVE through a
   proper tunnel.

     REQ 9. The security solution for NVO3 MAY enable two NVEs to
       mutually authenticate each other before establishing a tunnel
       for data transportation.

   This entity authentication requirement is used to protect a NVE
   against imposter attacks. Also, this requirement can help guarantee a
   data tunnel is generated between two proper NVEs and reduce the 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


Hartman, et al.       Expires December 14, 2016               [Page 11]


Internet-Draft              NVO3 security                     June 2016


   overlay needs to provide essential security protection for data
   packets.

     REQ 10.   The security solution of NVO3 SHOULD be able to provide
       integrity protection, replay protection, and packet origin
       authentication for data traffics exchanged between NVEs.

   This requirement is used to prevent an attacker who has compromised
   underlying network devices on the path from replaying antique packets
   or injecting bogus data packets without being detected.

   Such protection must be deployed if there is any possibility that the
   data packets could be accessed by outside attackers. This protection
   can prevent an attacker locating in the middle between 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 leaking is a concern.

   If TS data traffic privacy is required, the TS data traffic needs to
   be encrypted when being transported within the overlay. In practice,
   tenants may select end-to-end security solutions to encrypt their
   sensitive data during transportation. Therefore this confidentiality
   requirement for data plane is an optional requirement.

     REQ 12.   The security solution of NVO3 SHOULD be able to assign
       different cryptographic keys to protect the unicast tunnels
       between NVEs respectively.

   This requirement is used to confine the damage caused by inside
   attacks. When different tunnels secured with different keys, the
   compromise of a key in a tunnel will not affect the security of 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 among the NVEs within
       different multicast groups.

   In NVO3, a NVE may need to support data plane multicast capability.
   In order to provide an essential packet level security protection
   (including authentication, integrity, confidentiality) for the


Hartman, et al.       Expires December 14, 2016               [Page 12]


Internet-Draft              NVO3 security                     June 2016


   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 14.   Upon receiving a data packet, an egress NVE MUST be able
       to verify whether the packet is sent from a proper ingress NVE
       which is authorized to forward that packet.

   In cooperation with authentication, authorization enables an egress
   NVE to detect the 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 forward data packet
   of a given VN, the packet needs to be detected and discarded without
   processing. Note that the detection of an invalid packet may not
   indicate that the system is under a malicious attack. Mis-
   configuration or byzantine failure of a 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 simple L2
   Ethernet link. A more complicated scenario may have the server and
   NVE separated by a bridged access network, such as when the NVE
   resides on a ToR, with an embedded switch residing between servers
   and the ToR.

   In any of above deployment scenarios, the data link between NVE and
   hypervisor may be potentially accessible to attackers, e.g. with a
   shared link. In that case, security solutions, including integrity
   protection and confidentiality protection, may be needed to secure
   the data link.

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

   Packet level security protection can prevent an attacker from
   illegally interfere with the normal operations of NVEs and
   hypervisors by injecting bogus packets into the network. Because it
   is assumed that 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



Hartman, et al.       Expires December 14, 2016               [Page 13]


Internet-Draft              NVO3 security                     June 2016


   hypervisor from modifying the information in the data packet headers
   so as to redirect the traffic as wished.

     REQ 16.   The security solution of a NVO3 network MAY provide
       confidentiality protection for the data traffics exchanged
       between a NVE and a hypervisor.

   If TS data packet privacy is required, the data packet needs to be
   encrypted. The security solution of a NVE network 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.

     REQ 17.   The security solution of a NVO3 network MAY be able to
       provide different cryptographic keys to secure the unicast data
       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. In that case, the compromise of
   a hypervisor or a NVE will not be able to affect the security of data
   traffics exchanged between different hypervisors and their NVEs.

     REQ 18.   The security solution of 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 an essential packet level security
   protection (including authentication, integrity, confidentiality) for
   the multicast packets transferred within the multicast group, at
   least one group key may need to be shared among the hypervisors and
   their NVE of the same multicast group. It is recommended to deploy
   different keys for different multicast groups, in order to confine
   the insider attacks on the hypervisors and their NVE.

7. Candidate Techniques

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







Hartman, et al.       Expires December 14, 2016               [Page 14]


Internet-Draft              NVO3 security                     June 2016


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 [RFC5996], 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.

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., IPsec AH [RFC4302], IPsec
   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]). 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.

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


Hartman, et al.       Expires December 14, 2016               [Page 15]


Internet-Draft              NVO3 security                     June 2016


   attacks and increasing the difficulties of DoS / DDoS attacks
   targeting at the security protocol implementations.

   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.

7.4. Automated Key Management

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

   This document makes no request of IANA.

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

9. Security Considerations

   This is a requirement document which provides security requirements
   for the NVO3 network and in itself does not introduce any new
   security concerns.



Hartman, et al.       Expires December 14, 2016               [Page 16]


Internet-Draft              NVO3 security                     June 2016


10. Acknowledgements

   Many people have contributed to the development of this document and
   many more will probably do so before we are 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 Makan Pourzandi.

11. References

11.1. Normative References

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

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 (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-01 (work in
             progress), November 2014.

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


Hartman, et al.       Expires December 14, 2016               [Page 17]


Internet-Draft              NVO3 security                     June 2016


   [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



























Hartman, et al.       Expires December 14, 2016               [Page 18]


Internet-Draft              NVO3 security                     June 2016


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
   Chaoyang Dist. Beijing
   P.R. China

   Email: dacheng.zhang@gmail

   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






Hartman, et al.       Expires December 14, 2016               [Page 19]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/