<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.10 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC4301 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC8221 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml">
<!ENTITY RFC8014 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8014.xml">
<!ENTITY RFC7365 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7365.xml">
<!ENTITY RFC7258 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY RFC8247 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml">
<!ENTITY RFC7525 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml">
<!ENTITY RFC7516 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY RFC4303 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4302 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY I-D.ietf-nvo3-geneve SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-geneve.xml">
<!ENTITY I-D.ietf-nvo3-security-requirements SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-security-requirements.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml">
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc docName="draft-mglt-nvo3-geneve-security-requirements-06" category="info">

  <front>
    <title abbrev="Geneve Security Requirements">Geneve Security Requirements</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>
    <author initials="S." surname="Boutros" fullname="Sami Boutros">
      <organization>VMware, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country></country>
        </postal>
        <email>boutros@vmware.com&lt;</email>
      </address>
    </author>
    <author initials="D." surname="Wings" fullname="Dan Wings">
      <organization>VMware, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country></country>
        </postal>
        <email>dwing@vmware.com</email>
      </address>
    </author>
    <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
      <organization>Kaloom</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country></country>
        </postal>
        <email>suresh@kaloom.com</email>
      </address>
    </author>

    <date year="2019" month="February" day="28"/>

    <area>Security</area>
    <workgroup>NVO3</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).</t>

<t>The document provides two sets of security requirements: 
1. requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to Geneve
overlay provider to evaluate a given deployment.<vspace />
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment</t>



    </abstract>


  </front>

  <middle>


<section anchor="requirements-notation" title="Requirements Notation">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>

</section>
<section anchor="introduction" title="Introduction">

<t>The network virtualization overlay over Layer 3 (NVO3)  as depicted in
Figure 1, allows an overlay cloud provider to provide a logical L2/L3
interconnect for the Tenant Systems TSes that belong to a specific
tenant network. A packet received from a TS is encapsulated by the
ingress Network Virtualization Edge (NVE). The encapsulated packet is
then sent to the remote NVE through a tunnel. When reaching the egress
NVE of the tunnel, the packet is decapsulated and forwarded to the
target TS. The L2/L3 address mappings to the remote NVE(s) are
distributed to the NVEs by a logically centralized Network
Virtualization Authority (NVA) or using a distributed control plane such
as Ethernet-VPN. In a datacenter, the NVO3 tunnels can be implemented
using Generic Network Virtualization Encapsulation (Geneve)
<xref target="I-D.ietf-nvo3-geneve"/>. Such Geneve tunnels establish NVE-to-NVE
communications, may transit within the data center via Transit device.
The Geneve tunnels overlay network enable multiple Virtual Networks to
coexist over a shared underlay infrastructure, and a Virtual Network may
span a single data center or multiple data centers.</t>

<t>The underlay infrastructure on which the multi-tenancy overlay networks
are hosted, can be owned and provided by an underlay provider who may be
different from the overlay cloud provider.</t>

<figure><artwork><![CDATA[
+--------+                                    +--------+
| 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 Network Virtualization Overlays
[RFC7365]
]]></artwork></figure>

<t>This document discusses the security risks that a Geneve based NVO3
network may encounter. In addition, this document lists the requirements
to protect the Geneve packet components defined in
<xref target="I-D.ietf-nvo3-geneve"/> that include the Geneve tunnel IP and UDP
header, the Geneve Header, Geneve options, and inner payload.</t>

<t>The document provides two sets of security requirements:</t>

<t><list style="numbers">
  <t>SEC-OP: requirements to evaluate a given deployment of Geneve
overlay. Such requirements are intended to Geneve overlay provider to
evaluate a given deployment. Security of the Geneve packet may be
achieved using various mechanisms.  Typically, some deployments may use
a limited subset of the capabilities provided by Geneve and rely on
specific assumptions. Given these specificities, the secure deployment
of a given Geneve deployment may be achieved reusing specific mechanisms
such as for example DTLS <xref target="RFC6347"/> or IPsec <xref target="RFC4301"/>. On the
other hand, the definition of a security mechanisms that enables to
secure any Geneve deployment requires the design of a Geneve specific
mechanism. Note that the security s limited to the security of the data
plane only. Additional requirements for the control plan MAY be
considered in <xref target="I-D.ietf-nvo3-security-requirements"/>. A given Geneve
deployment will be considered secured when matching with all SEC-OP
requirements does not raises any concern. As such the given deployment
will be considered passing SEC-OP requirements that are not applicable.</t>
  <t>SEC-GEN: requirements a security mechanism need to fulfill to secure
any deployment of Geneve overlay deployment. Such mechanism may require
the design of a specific solution. In the case new protocol needs to be
design, the document strongly recommend to re-use existing security
protocols like IP Security (IPsec) <xref target="RFC4301"/> and Datagram Transport Layer
Security (DTLS) <xref target="RFC6347"/>, and existing encryption algorithms (such
as <xref target="RFC8221"/>),  and authentication protocols. A given candidate for a
security mechanism will be considered as valid when matching with all
SEC-GEN requirements does not raise any concern. In other words,  at
least all MUST status are met.</t>
</list></t>

<t>This document assumes the following roles are involved:
- Tenant: designates the entity that connects various systems within a
single virtualized network. The various system can typically be
containers, VMs implementing a single or various functions.<vspace />
- Geneve Overlay Provider: provides the Geneve overlay that seamlessly
connect the various Tenant Systems over a given virtualized network. <vspace />
- Infrastructure Provider: provides the infrastructure that runs the
Geneve overlay network as well as the Tenant System. A given deployment
may consider different infrastructure provider with different level of
trust. Typically the Geneve overlay network may use a public cloud to
extend the resource of a private cloud. Similarly, a edge computing may
extend its resources using resource of the core network.</t>

<t>Tenant, Geneve Overlay Provider and Infrastructure Provider can be
implemented by a single or various different entities with different
level of trust between each other. The simplest deployment may consists
in a single entity running its systems in its data center and using
Geneve in order to manage its internal resources. A more complex use
case may consider that a Tenant subscribe to the Geneve Overlay Provider
which manage the virtualized network over various type of
infrastructure. The trust between the Tenant, Geneve Overlay Provider
and Infrastructure Provider may be limited.</t>

<t>Given the different relations between Tenant, Geneve Overlay Provider
and Infrastructure Provider, this document aims providing requirements
to ensure:
1. The Geneve Overlay Provider delivers tenant payload traffic (Geneve
inner payload) and ensuring privacy and integrity. 
2. The Geneve Overlay Provider provides the necessary means to prevent
injection or redirection of the Tenant traffic from a rogue node in the
Geneve overlay network or a rogue node from the infrastructure. 
3. The Geneve Overlay Provider can rely on the Geneve overlay in term of
robustness and reliability of the signaling associated to the Geneve
packets (Geneve tunnel header, Geneve header and Geneve options) in
order to appropriately manage its overlay.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>This document uses the terminology of <xref target="RFC8014"/>, <xref target="RFC7365"/> and
<xref target="I-D.ietf-nvo3-geneve"/>.</t>

</section>
<section anchor="security-threats" title="Security Threats">

<t>This section considers attacks performed by NVE, network devices or any
other devices using Geneve, that is when the attackers knowing the
details of the Geneve packets can perform their attacks by changing
fields in the Geneve tunnel header, base header, Geneve options and
Geneve inner payload. Attacks related to the control plane are outside
the scope of this document. The reader is encouraged to read
<xref target="I-D.ietf-nvo3-security-requirements"/> for a similar threat analysis
of NVO3 overlay networks.</t>

<t>Threats include traffic analysis, sniffing, injection, redirection, and
replay. Based on these threats, this document enumerates the security
requirements.</t>

<t>Threats are divided into two categories:  passive attack and active
attack.</t>

<t>Threats are always associated with risks and the evaluation of these
risks depend among other things on the environment.</t>

<section anchor="passive-attacks" title="Passive Attacks">

<t>Passive attacks include traffic analysis (noticing which workloads
are communicating with which other workloads, how much traffic, and when
those communications occur) and sniffing (examining traffic for useful
information such as personally-identifyable information or protocol
information (e.g., TLS certificate, overlay routing protocols).</t>

<t>Passive attacks may also consist in inferring information about a
virtualized network or some Tenant System from observing the Geneve
traffic. This could also involve the correlation between observed
traffic and additional information. For example, a passive network
observer can determine two virtual machines are communicating by
manipulating activity or network activity of other virtual machines on
that same host. For example, the attacker could control (or be otherwise
aware of) network activity of the other VMs running on the same host,
and deduce other network activity is due to a victim VM.</t>

<t>A rogue element of the overlay Geneve network under the control of an
attacker may leak and redirect the traffic from a virtual network to the
attacker for passive monitoring <xref target="RFC7258"/>.</t>

<t>Avoiding leaking information is hard to enforced. The security
requirements provided in section {{sniffing} expect to mitigate such
attacks by lowering the consequences, typically making leaked data
unusable to an attacker.</t>

</section>
<section anchor="active-attacks" title="Active Attacks">

<t>Active attacks involve modifying Geneve packets, injecting Geneve 
packets, or interfering with Geneve packet delivery (such as by
corrupting packet checksum). Active attack may target the Tenant System
or the Geneve overlay.</t>

<t>There are multiple motivations to inject illegitimate traffic into a
tenants network. When the rogue element is on the path of the TS
traffic, it may be able to inject and receive the corresponding messages
back. On the other hand, if the attacker is not on the path of the TS
traffic it may be limited to only inject traffic to a TS without
receiving any response back. When rogue element have access to the
traffic in both directions, the possibilities are only limited by the
capabilities of the other on path elements - Transit device, NVE or TS -
to detect and protect against the illegitimate traffic. On the other
hand, when the rogue element is not on path, the surface for such
attacks remains still quite large. For example, an attacker may target a
specific TS or application by crafting a specific packet that can either
generate load on the system or crash the system or application. TCP syn
flood typically overload the TS while not requiring the ability to
receive responses. Note that udp application are privileged target as
they do not require the establishment of a session and are expected to
treat any incoming packets.</t>

<t>Traffic injection may also be used to flood the virtual network to
disrupt the communications between the TS or to introduce additional
cost for the tenant, for example when pricing considers the traffic
inside the virtual network. The two latest attacks may also take
advantage of applications with a large factor of amplification for their
responses as well as applications that upon receiving a packet interact
with multiple TS. Similarly, applications running on top of UDP are
privileged targets.</t>

<t>Note also that an attacker that is not able to receive the response
traffic, may use other channels to evaluate or measure the impact of the
attack. Typically, in the case of a service, the attacker may have
access, for example, to a user interface that provides indication on the
level of disruption and the success of an attack, Such feed backs may
also be used by the attacker to discover or scan the network.</t>

<t>Preventing traffic to cross virtual networks, reduce the surface of
attack, but rogue element main still perform attacks within a
given virtual network by replaying a legitimate packet. Some variant of
such attack also includes modification of unprotected parts when
available in order for example to increase the payload size.</t>

</section>
</section>
<section anchor="requirements-for-security-mitigations" title="Requirements for Security Mitigations">

<t>The document assumes that Security protocols, algorithms, and
implementations provide the security properties for which they are
designed, an attack caused by a weakness in a cryptographic algorithm is
out of scope. The algorithm used MUST follow the cryptographic guidance
such as <xref target="RFC8247"/>, <xref target="RFC8221"/> or <xref target="RFC7525"/>. In this context,
when the document mentions encryption, it assumes authenticated
encryption.</t>

<t>Protecting network connecting TSes and NVEs which could be accessible
to outside attackers is out of scope.</t>

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

<t>Securing communication between NVAs and NVEs is out of scope.</t>

<t>Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This will
be the case if the Tenant Systems uses security protocol to protect its
communications.</t>

<section anchor="sniffing" title="Protection Against Traffic Sniffing">

<t>The inner payload, unless protection is provided by the Tenant System
reveals the content of the communication. This may be mitigate by the
Tenant using application level security such as, for example JSON Web
Encryption <xref target="RFC7516"/> or transport layer security such as DTLS
<xref target="RFC6347"/> or TLS <xref target="RFC8446"/> or IPsec/ESP <xref target="RFC4303"/>. However none
of these security protocols are sufficient to protect the entire inner
payload. IPsec/ESP still leave in clear the optional L2 layer
information as well as the IP addresses and some IP options. In addition
to these pieces of information, the use of TLS or DTLS reveals the
transport layer protocol as well as ports. As a result, the
confidentiality protection of the inner packet may be handled either
entirely by the Geneve Overlay Provider, or partially by the Tenant or
handled by both the Tenant and the Geneve Overlay Provider.</t>

<t>The Geneve Header contains information related to the Geneve
communications or metadata designated as Geneve Information.  Geneve
Information is carried on the Geneve Outer Header, the Geneve Header
(excluding Geneve Options) as well as in the Geneve Options. Geneve
Information needs to be accessed solely by a NVE or transit device while
other Geneve Information may need to be accessed by other transit
devices. More specifically, a subset of the information contained in the
Geneve Header (excluding Geneve Options) as well as a subset of (none,
one or multiple Geneve Option) may be accessed by a transit device or
the NVE while the others needs to be accessed by other transit devices.
The confidentiality protection of the Geneve Information is handled by
the Geneve Overlay Provider.</t>

<t>In addition to Geneve Information, the traffic generated for the Geneve
overlay may be exposed to traffic volumetry and pattern analysis within
a virtualized network.  Confidentiality protection against traffic
pattern recognition is handled by the Geneve Overlay Provider.</t>

<section anchor="operational-security-requirements" title="Operational Security Requirements">

<t>A secure deployment of a Geneve overlay must fulfill the requirement
below:</t>

<t><list style="symbols">
  <t>SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by default
encrypt the inner payload. A Geneve overlay provider MAY disable this
capability for example when encryption is performed by the Tenant System
and that level of confidentiality is believed to be sufficient. In order
to provide additional protection to traffic already encrypted by the
Tenant the Geneve network operator MAY partially encrypt the clear part
of the inner payload.</t>
  <t>SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate the
information associated to the leakage of Geneve Information carried by
the Geneve Packet.  When a risk analysis concludes that the risk of
leaking sensitive information is too high, such Geneve Information MUST
NOT be transmit in clear text.</t>
  <t>SEC-OP-3: A secure deployment of a Geneve overlay MUST evaluate the
risk associated to traffic pattern recognition. When a risk has been
identified, traffic pattern recognition MUST be addressed with padding
policies as well as generation of dummy packets.</t>
</list></t>

</section>
<section anchor="geneve-security-requirements" title="Geneve Security Requirements">

<t>A Geneve security mechanism must fulfill the requirements below:</t>

<t><list style="symbols">
  <t>SEC-GEN-1: Geneve security mechanism MUST provide the capability to
encrypt the inner payload.</t>
  <t>SEC-GEN-2: Geneve security mechanism SHOULD provide the capability to
partially encrypt the inner payload header.</t>
  <t>SEC-GEN-3: Geneve security mechanism MUST provide means to
encrypt a single or a set of zero, one or multiple Geneve Options while
leave other Geneve Options in clear. Reversely, a Geneve security
mechanism MUST be able to leave a Geneve option in clear, while
encrypting the others.</t>
  <t>SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header (excluding Geneve Options). Reversely,
a Geneve security mechanism MUST be able to leave in clear Geneve Header
information (Geneve Options excluded) while encrypting the other.</t>
  <t>SEC-GEN-5: Geneve security mechanisms MUST provide the ability to
provide confidentiality protection between multiple nodes, i.e. multiple
transit devices and a NVE.</t>
  <t>SEC-GEN-6: Geneve security mechanism MUST provide the ability to pad
a Geneve packet.</t>
  <t>SEC-GEN-7: Geneve security mechanism MUST provide the ability to send
dummy packets.</t>
</list></t>

</section>
</section>
<section anchor="injection" title="Protecting Against Traffic Injection">

<t>Traffic injection from a rogue non legitimate NVO3 Geneve overlay device
or a rogue underlay transit device can target an NVE, a transit underlay
device or a Tenant System. Targeting a Tenant's System requires a valid
MAC and IP addresses of the Tenant's System.</t>

<t>When traffic between tenants is not protected, the rogue device may
forward the modified packet over a valid (authenticated) Geneve Header.
The crafted packet may for example, include a specifically crafted
application payload for a specific Tenant Systems application, with the
intention to load the tenant specific application. Tenant's System may
provide integrity protection of the inner payload by protect their
communications using for example IPsec/ESP, IPsec/AH <xref target="RFC4302"/>, TLS
or DTLS. Such protection protects at various layers the Tenants from
receiving spoofed packets, as any injected packet is expected to be
discarded by the destination Tenant's System. Note IPsec/ESP with NULL
encryption may be used to authenticate-only the layers above IP in which
case the IP header remains unprotected. However IPsec/AH enables the
protection of the entire IP packet, including the IP header. As a
result, when Geneve encapsulates IP packets the Tenant has the ability
to integrity protect the IP packet on its own, without relying on the
Geneve overlay network.  On the other hand, L2 layers remains
unprotected. As encryption is using authenticated encryption,
authentication may also be provided via encryption. At the time of
writing the document DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/> is still a draft
document and TLS 1.3 does not yet provide the ability for authenticate
only the traffic. As such it is likely that the use of DTLS1.3 may not
involve authentication-only cipher suites. Similarly to confidentiality
protection, integrity protection may be handled either entirely by the
Geneve Overlay Provider, or partially by the Tenant or handled by both
the Tenant and the Geneve Overlay Provider.</t>

<t>In addition to confidentiality protection of the inner payload,
integrity protection also prevents the Tenant System from receiving
illegitimate packets that may disrupt the Tenant's System performance.
The Geneve overlay network need to prevent the overlay to be used as a
vector to spoof packets being steered to the Tenant's system. As a
result, the Overlay Network Provider needs to ensure that inner packets
steered to the Tenant's network are only originating from one Tenant
System and not from an outsider using the Geneve Overlay to inject
packets to one virtual network. As such, the destination NVE MUST be
able to authenticate the incoming Geneve packets from the source NVE.
This may be performed by the NVE authenticating the full Geneve Packet.
When the Geneve Overlay wants to take advantage of the authentication
performed by the Tenant System, the NVE shoudl be able to perform some
checks between the Geneve Header and the inner payload.  Suppose two
Geneve packets are composed of a Geneve Header (H1, and H2) and a inner
payload (P1 and P2). Suppose H1, H2, P1 and P2 are authenticated. The
replacement of P2 by P1 by an attacker will be detected by the NVE only
if there is a binding between H2 and P2. Such integrity protection is
handled by the Geneve Overlay Provider.</t>

<t>While traffic injection may target the Tenant's virtual network or a
specific Tenant System, traffic injection may also target the Geneve
Overlay Network by injecting Geneve Options that will affect the
processing of the Geneve Packet. Updating the Geneve header and option
parameters such as setting an OAM bit, adding bogus option TLVs, or
setting a critical bit, may result in different processing behavior,
that could greatly impact performance of the overlay network and the
underlay infrastructure and thus affect the tenants traffic delivery. As
such, the Geneve Overlay should provide integrity protection of the
Geneve Information present in the Geneve Header to guarantee Geneve
processing is not altered.</t>

<t>The Geneve architecture considers transit devices that may process some
Geneve Options. More specifically, a Geneve packet may have A subset of
Geneve Information of the Geneve Header (excluding Geneve Options) as
well as a set of zero, one or multiple of Geneve Options accessed by one
or more transit devices. This information needs to be authenticated by a
transit device while other options may be authenticated by other transit
devices or the tunnel endpoint. The integrity protection is handled by
the Geneve Overlay Provider and authentication MUST be performed prior
any processing.</t>

<section anchor="operational-security-requirements-1" title="Operational Security Requirements">

<t>A secure deployment of a Geneve overlay must fulfill the requirement
below:</t>

<t><list style="symbols">
  <t>SEC-OP-4: A secure deployment of a Geneve overlay MUST provide the
capability authenticate the inner payload when encryption is not
provided. A Geneve overlay provider MAY disable this capability for
example when this is performed by the Tenant System and that level of
integrity is believed to be sufficient. In order to provide additional
protection to traffic already protected by the Tenant the Geneve network
operator MAY partially protect the unprotected part of the inner
payload.</t>
  <t>SEC-OP-5: A secure deployment of a Geneve overlay MUST evaluate the
risk associated to a change of the Geneve Outer Header, Geneve Header
(excluding Geneve Options) and Geneve Option. When a risk analysis
concludes that the risk is too high, this piece of information MUST be
authenticated.</t>
  <t>SEC-OP-6: A secure deployment of a Geneve overlay SHOULD
authenticate communications between NVE to protect the Geneve Overlay
infrastructure as well as the Tenants System's communications (Geneve
Packet). A Geneve overlay provider MAY disable authentication of the
inner packet and delegates it to the Tenant Systems when communications
between Tenant's System is secured. This is NOT RECOMMENDED. Instead, it
is RECOMMENDED that mechanisms binds the inner payload to the Geneve
Header. To prevent injection between virtualized network, it is strongly
RECOMMENDED that at least the Geneve Header without Geneve Options is
authenticated.</t>
  <t>SEC-OP-7: A secure deployment of a Geneve overlay SHOULD NOT process
data prior authentication. If that is not possible, the Geneve overlay
provider SHOULD evaluate its impact.</t>
</list></t>

</section>
<section anchor="geneve-security-requirements-1" title="Geneve Security Requirements">

<t>A Geneve security mechanism must fulfill the requirements
below:</t>

<t><list style="symbols">
  <t>SEC-GEN-8: Geneve security mechanism MUST provide the capability to
authenticate the inner payload.</t>
  <t>SEC-GEN-9: Geneve security mechanism SHOULD provide the capability to
partially authenticate the inner payload header.</t>
  <t>SEC-GEN-10: Geneve security mechanism MUST provide the capability to
authenticate a single or a set of options while leave other Geneve
Option unauthenticated. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option unauthenticated, while encrypting the
others.</t>
  <t>SEC-GEN-11: Geneve security mechanism MUST provide means to
authenticate the information of Geneve Header (Geneve Option excluded).
Reversely, a Geneve security mechanism MUST be able to leave
unauthenticated Geneve header information (Geneve Options excluded)
while authenticating the other.</t>
  <t>SEC-GEN-12: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to  authenticate data prior it is being
processed.</t>
  <t>SEC-GEN-13: Geneve Security mechanism MUST provide means for a
transit device to  authenticate data prior it is being
processed.</t>
</list></t>

</section>
</section>
<section anchor="protecting-against-traffic-redirection" title="Protecting Against Traffic Redirection">

<t>A rogue device of the NVO3 overlay Geneve network or the underlay
network may redirect the traffic from a virtual network to the attacker
for passive or active attacks. If the rogue device is in charge of 
securing the Geneve packet, then Geneve security mechanisms are not
intended to address this threat. More specifically, a rogue source NVE
will still be able to redirect the traffic in clear text before
protecting ( and encrypting the packet). A rogue destination NVE will
still be able to redirect the traffic in clear text after decrypting the
Geneve packets. The same occurs with a rogue transit that is in charge
of encrypting and decrypting a Geneve Option,  Geneve Option or any
information. The security mechanisms are intended to protect a Geneve
information from any on path  node. Note that modern cryptography
recommend the use of authenticated encryption. This section assumes such
algorithms are used, and as such encrypted packets are also
authenticated.</t>

<t>To prevent an attacker located in the middle between the NVEs and
modifying the tunnel address information in the data packet header to
redirect the data traffic, the solution needs to provide confidentiality
protection for data traffic exchanged between NVEs.</t>

<t>Requirements are similar as those provided in section <xref target="sniffing"/> to
mitigate sniffing attacks and those provided in section <xref target="injection"/> to
mitigate traffic injection attacks.</t>

</section>
<section anchor="protecting-against-traffic-replay" title="Protecting Against Traffic Replay">

<t>A rogue device of the NVO3 overlay Geneve network or the underlay
network may replay a Geneve packet, to load the network and/or a
specific Tenant System with a modified Geneve payload. In some cases,
such attacks may target an increase of the tenants costs.</t>

<t>When traffic between Tenant System is not protected against anti-replay. A
packet even authenticated can be replayed. DTLS and IPsec provides anti
replay mechanisms, so it is unlikely that authenticated Tenant's traffic
is subject to replay attacks.</t>

<t>Similarly to integrity protection, the Geneve Overlay Provider should
prevent the overlay to be used to replay packet to the Tenant's System.
In addition, similarly to integrity protection, the Geneve Overlay
network may also be a target of a replay attack, and NVE as well as
transit devices should benefit from the same protection.</t>

<t>Given the proximity between authentication and anti-replay mechanisms
and that most authentication mechanisms integrates anti-replay attacks,
we RECOMMEND that authentication contains an anti-replay mechanisms.</t>

<section anchor="geneve-security-requirements-2" title="Geneve Security Requirements">

<t>A secure deployment of a Geneve overlay must fulfill the requirement
below:</t>

<t><list style="symbols">
  <t>SEC-OP-8: A secure deployment of a Geneve overlay MUST evaluate the 
communications subject to replay attacks. Communications that are 
subject to this attacks MUST be authenticated with an anti replay
mechanism. Note that when partial authentication is provided, the part
not covered by the authentication remains a surface of attack. It is
strongly RECOMMENDED that the Geneve Header is authenticated with
anti replay protection.</t>
</list></t>

</section>
<section anchor="geneve-security-requirements-3" title="Geneve Security Requirements">

<t>A Geneve security mechanism must fulfill the requirements
below:</t>

<t><list style="symbols">
  <t>SEC-GEN-14: Geneve Security mechanism MUST provide authentication with
anti-replay protection.</t>
</list></t>

</section>
</section>
<section anchor="security-management" title="Security Management">

<section anchor="operational-security-requirements-2" title="Operational Security Requirements">

<t>A secure deployment of a Geneve overlay must fulfill the requirement
below:</t>

<t><list style="symbols">
  <t>SEC-OP-9: A secure deployment of a Geneve overlay MUST define the
security policies that associates the encryption, and authentication
associated to each flow between NVEs.</t>
  <t>SEC-OP-10: A secure deployment of a Geneve overlay SHOULD define
distinct material for each flow. The cryptographic depends on the nature
of the flow (multicast, unicast) as well as on the security mechanism
enabled to protect the flow.</t>
</list></t>

</section>
<section anchor="geneve-security-requirements-4" title="Geneve Security Requirements">

<t>A Geneve security mechanism must fulfill the requirements
below:</t>

<t><list style="symbols">
  <t>SEC-GEN-15: A Geneve security mechanism MUST be managed via security
policies associated for each traffic flow to be protected.  Geneve
overlay provider MUST be able to configure NVEs with  different
security policies for different flows. A flow MUST be identified at
minimum by the Geneve virtual network identifier and the inner IP and
transport headers, and optionally additional fields which define a flow
(e.g., inner IP DSCP, IPv6 flow id, Geneve options).</t>
  <t>SEC-GEN-16: A Geneve security mechanism MUST be able to assign
different cryptographic keys to protect the unicast tunnels between NVEs
respectively.</t>
  <t>SEC-GEN-17: A Geneve security mechanisms, when multicast is used,
packets,MUST be able to assign distinct cryptographic group keys to
protect the multicast packets exchanged among the NVEs within different
multicast groups. Upon receiving a data packet, an egress Geneve NVE
MUST be able to verify whether the packet is sent from a proper ingress
NVE which is authorized to forward that packet.</t>
</list></t>

</section>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>There are no IANA consideration for this document.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The whole document is about security.</t>

<t>Limiting the coverage of the authentication / encryption provides
some means for an attack to craft special packets.</t>

<t>The current document details security requirements that are related to
the Geneve protocol. Instead, <xref target="I-D.ietf-nvo3-security-requirements"/>
provides generic architecture security requirement upon the deployment
of an NVO3 overlay network. It is strongly recommended to read that
document as architecture requirements also apply here. In addition,
architecture security requirements go beyond the scope of Geneve
communications, and as such are more likely to address the security
needs upon deploying an Geneve overlay network.</t>

</section>
<section anchor="appendix" title="Appendix">

<section anchor="dtls" title="DTLS">

<t>This section compares how NVE communications using DTLS meet the
security requirements for a secure Geneve overlay deployment. In this
example DTLS is used over the Geneve Outer Header and secures the Geneve
Header including the Geneve Options and the inner payload.</t>

<t>The use of DTLS MAY fill the security requirements for a secure Geneve
deployment. However DTLS cannot be considered as the Geneve security
mechanism enabling all Geneve deployments. To ease the reading of the
Requirements met by DTLS or IPsec, the requirements list indicates with
Y (Yes) when the requirement and N (No) when the requirement is not met.
In addition, an explanation is provided on the reasoning. This section
is not normative and its purpose is limited to illustrative purpose.</t>

<section anchor="operational-security-requirements-3" title="Operational Security Requirements">

<t>This section shows how  DTLS may secure some Geneve deployments. Some
Geneve deployments may not be secured by DTLS, but that does not exclude
DTLS from being used.</t>

<t><list style="symbols">
  <t>SEC-OP-1 (Y): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite will provide confidentiality to the full Geneve
Packet which contains the inner payload. As such the use of DTLS meets
SEC-OP-1. Note that DTLS does not provide partial encryption and as such
the Geneve Overlay Provider may not benefit from the encryption
performed by the Tenant if performed, which may result in some portion
of the payload being encrypted twice.</t>
  <t>SEC-OP-2 (Y): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite encrypt the Geneve Packet which includes the
Geneve Header and associated metadata. Only the UDP port is leaked which
could be acceptable. As such, the use of DTLS meets SEC-OP-2.</t>
  <t>SEC-OP-3 (Y/N): A deployment using DTLS between NVEs will not be able
to send dummy packets or pad Geneve Packet unless this is managed by the
Geneve packet itself. DTLS does not provide the ability to send dummy
traffic, nor to pad. As a result DTLS itself does not meet this
requirement. This requirement may be met if handled by the Geneve
protocol. As such SEC-OP-3 may not be met for some the deployment.
However, it is not a mandatory requirement and as such it is likely that
the use of DTLS SEC-OP-3 is met.</t>
  <t>SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using DTLS between NVEs
provides integrity protection to the full Geneve Packet which includes
the inner payload. As such the use of DTLS meets SEC-OP-4.  Note that
DTLS 1.2 provides integrity-only cipher suites while DTLS 1.3 does not
yet. As a result, the use of DTLS 1.3 may provide integrity protection
using authenticated encryption.</t>
  <t>SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using DTLS between
NVE authenticates the full Geneve Packet which includes the Geneve
Header.  Only the UDP port is left unauthenticated. As such, the use of
DTLS meets SEC-OP-5.</t>
  <t>SEC-OP-6 (Y): A deployment using DTLS between NVE authenticates
NVE-to-NVE communications and the use of DTLS meets SEC-OP-6.</t>
  <t>SEC-OP-7 (Y/N): A deployment using DTLS between NVEs is not compatible
with a Geneve architecture that includes transit devices. When the DTLS
session uses a non NULL encryption cipher suite, the transit device will
not be able to access it. When the NULL encryption cipher suite is used,
the transit device may be able to access the data, but will not be able
to authenticate it prior to processing the packet. As such the use of
DTLS only meets SEC-OP-7 for deployment that do not include any transit
devices.</t>
  <t>SEC-OP-8 (Y): A deployment using DTLS between NVEs provides
anti-replay protection and so, the use of DTLS meets SEC-OP-8.</t>
  <t>SEC-OP-9 (Y/N): DTLS does not define any policies. Instead DTLS
process is bound to an UDP socket. As such handling of flow policies is
handled outside the scope of DTLS. As such SEC-OP-9 is met outside the
scope of DTLS.</t>
  <t>SEC-OP-10 (N): DTLS session may be established with specific material,
as such it is possible to assign different material for each flow.
However, the binding between flow and session is performed outside the
scope of DTLS. In addition, DTLS does not support multicast. As such,
the use of DTLS may only meets SEC-OP-10 in the case of unicast
communications.</t>
</list></t>

</section>
<section anchor="geneve-security-requirements-5" title="Geneve Security Requirements">

<t>This section shows that DTLS cannot be used as a generic Geneve security
mechanism  to secure
Geneve deployments. A Geneve security mechanism woudl need to meet all
SEC-GEN requirements.</t>

<t><list style="symbols">
  <t>SEC-GEN-1 (Y): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite will provide confidentiality to the full Geneve
Packet which contains the inner payload. As such the use of DTLS meets
SEC-GEN-1.</t>
  <t>SEC-GEN-2 (Y): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite will not be able to partially encrypt the inner
payload header. However such requirement is not set a mandatory so the
use of DTLS meets SEC-GEN-2</t>
  <t>SEC-GEN-3 (N): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite encrypt the Geneve Packet which includes the
Geneve Header and all Geneve Options. However DTLS does not provides any
means to selectively encrypt or leave in clear text a subset of Geneve
Options. As a result the use of DTLS does not meet SEC-GEN-3.</t>
  <t>SEC-GEN-4 (N): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite encrypt the Geneve Packet which includes the
Geneve Header and all Geneve Options. However, DTLS does not provides
means to selectively encrypt some information of the Geneve Header. As
such the use of DTLS does not meet SEC-GEN-5.</t>
  <t>SEC-GEN-5 (N): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite provides end-to-end security between the NVEs
and as such does not permit the interaction of one or multiple on-path
transit devices. As such the use of DTLS does not meet SEC-GEN-5.</t>
  <t>SEC-GEN-6 (N):  A deployment using DTLS between NVEs with an non NULL
encryption cipher suite does not provide padding facilities. This
requirements is not met by DTLS itself and needs to be handled by Geneve
and specific options. As a result, the use of DTLS does not meet SEC-GEN-6</t>
  <t>SEC-GEN-7 (N):  A deployment using DTLS between NVEs with an non NULL
encryption cipher suite does not provide the ability to send dummy
packets. This requirements is not met by DTLS itself and needs to be
handled by Geneve and specific options. As a result, the use of DTLS
does not meet SEC-GEN-7.</t>
  <t>SEC-GEN-8 (Y): A deployment using DTLS between NVEs with an non NULL
encryption cipher suite or a NULL encryption cipher suite provide
authentication of the inner payload. As such the use of DTLS meets
SEC-GEN-8.</t>
  <t>SEC-GEN-9 (Y): A deployment using DTLS between NVEs does not provide
the ability to partially authenticate the inner
payload header. However such requirement is not set a mandatory so the
use of  DTLS meets SEC-GEN-9</t>
  <t>SEC-GEN-10 (N): A deployment using DTLS between NVEs authenticates the
Geneve Packet which includes the Geneve Header and all Geneve Options.
However, DTLS does not provides means to selectively encrypt some
information of the Geneve Header. As such the use of DTLS meets SEC-GEN-10.</t>
  <t>SEC-GEN-11 (N): A deployment using DTLS between NVEs authenticates the
Geneve Packet which includes the Geneve Header and all Geneve Options.
However, DTLS does not provides means to selectively authenticate some
information of the Geneve Header.  As such the use of DTLS does not meet
SEC-GEN-11.</t>
  <t>SEC-GEN-12 (Y): A deployment using DTLS between NVEs authenticates the
data prior the data is processed by the NVE. As such, the use of DTLS
meets SEC-GEN-12.</t>
  <t>SEC-GEN-13 (N): A deployment using DTLS between NVEs authenticates the
data when the tunnel reaches the NVE. As a result the transit device is
not able to authenticate the data prior accessing it and the use of DTLS
does not meet SEC-GEN-13.</t>
  <t>SEC-GEN-14 (Y): DTLS provides anti-replay mechanism as such, the use
of DTLS meets SEC-GEN-14.</t>
  <t>SEC-GEN-15 (N): DTLS itself does not have a policy base mechanism. As
a result, the classification of the flows needs to be handled by a
module outside DTLS. In order to meet SEC-GEN-15 further integration is
needed and DTLS in itself cannot be considered as  meeting SEC-GEN-15.</t>
  <t>SEC-GEN-16 (Y): DTLS is able to assign various material to each flows,
as such the use of DTLS meets SEC-GEN-16.</t>
  <t>SEC-GEN-17 (N): DTLS does not handle mutlicast communications. As such
the use of DTLS does not meet SEC-GEN-17.</t>
</list></t>

</section>
</section>
<section anchor="ipsec" title="IPsec">

<t>This section compares how NVE communications using IPsec/ESP or IPsec/AH
meet the security requirements for a secure Geneve overlay deployment.
In this example secures the Geneve IP packet including Outer IP header,
the Geneve Outer Header, the Geneve Header including Geneve Options and
the inner payload.</t>

<t>The use of IPsec/ESP or IPsec/AH share most of the analysis performed
for DTLS. The main advantages of using IPsec would be that IPsec
supports multicast communications and natively supports flow based
security policies. However, the use of these security policies in a
context of Geneve is not natively supported.</t>

<t>As a result, the use of IPsec MAY fill the security requirements for a
secure Geneve deployment. However IPsec cannot be considered as the
Geneve security mechanism enabling all Geneve deployments.</t>

<section anchor="operational-security-requirements-4" title="Operational Security Requirements">

<t>This section shows how  IPsec may secure some Geneve deployments. Some
Geneve deployments may not be secured by IPsec, but that does not exclude
IPsec from being used.</t>

<t><list style="symbols">
  <t>SEC-OP-1 (Y): A deployment using IPsec/ESP between NVEs with an non
NULL encryption will provide confidentiality to the full Outer IP
payload of the Geneve Packet which contains the inner payload. As a
result, such deployments meet SEC-OP-1. Note that IPsec/ESP does not
provide partial encryption and as such the Geneve Overlay Provider may
not benefit from the encryption performed by the Tenant if performed,
which may result in some portion of the payload being encrypted twice.</t>
  <t>SEC-OP-2 (Y): A deployment using IPsec/ESP between NVEs with an non
NULL encryption encrypts the Outer IP payload Geneve IP Packet which
includes the Geneve Header and associated information. As such SEC-OP-2 is
met.</t>
  <t>SEC-OP-3 (Y): A deployment using IPsec/ESP between NVEs will be able
to send dummy packets or pad Geneve Packet. As such OP-SEC-3 is met.</t>
  <t>SEC-OP-4 (Y): Similarly to SEC-OP-1, A deployment using IPsec/ESP or
IPsec/AH between NVEs provides integrity protection to the full Geneve
Packet which includes the inner payload. As such SEC-OP-4 is met.</t>
  <t>SEC-OP-5 (Y): Similarly to SEC-OP-2, A deployment using IPsec/ESP or
IPsec/AH between NVE authenticates the full Geneve Packet which includes
the Geneve Header.  As such SEC-OP-5 is met as well.</t>
  <t>SEC-OP-6 (Y): A deployment using IPsec/ESP or IPsec/AH between NVE
authenticates NVE-to-NVE communications and SEC-OP-6 is met.</t>
  <t>SEC-OP-7 (Y/N): A deployment using IPsec between NVEs is not
compatible with a Geneve architecture that includes transit devices.
When IPsec/ESP with a non NULL encryption is used, the transit device
will not be able to access it. When IPsec/AH or IPsec/ESP with the NULL
encryption is used, the transit device may be able to access the data,
but will not be able to authenticate it prior to processing the packet.
As SEC-OP-7 is only met for deployment that do not include any transit
devices.</t>
  <t>SEC-OP-8 (Y): A deployment using IPsec between NVEs provides anti-replay
protection and so meets SEC-OP-8.</t>
  <t>SEC-OP-9 (Y/N): IPsec enables the definition of security policies. As
such IPsec is likely to handle a per flow security. However the traffic
selector required for Geneve flows may not be provided natively by
IPsec. As such Sec-OP-9 is only partialy met.</t>
  <t>SEC-OP-10 (Y): IPsec session may be established with specific material, as
such it is possible to assign different material for each flow. In
addition IPsec supports multicats communications. As such SEC-OP-10 is
met.</t>
</list></t>

</section>
<section anchor="geneve-security-requirements-6" title="Geneve Security Requirements">

<t>This section shows that IPsec cannot be used as a generic Geneve security
mechanism  to secure
Geneve deployments. A Geneve security mechanism would need to meet all
SEC-GEN requirements.</t>

<t><list style="symbols">
  <t>SEC-GEN-1 (Y): A deployment using IPsec/ESP between NVEs with an non
NULL encryption provide confidentiality to the full Geneve Packet which
contains the inner payload. As such IPsec/ESP meets SEC-GEN-1.</t>
  <t>SEC-GEN-2 (Y): A deployment using IPsec/ESP between NVEs with an non
NULL encryption will not be able to partially encrypt the inner payload
header. However such requirement is not set a mandatory so IPsec/ESP
meets SEC-GEN-2</t>
  <t>SEC-GEN-3 (N): A deployment using IPsec between NVEs with an non NULL
encryption encrypts the Outer IP payload of the  Geneve Packet which
includes the Geneve Header and all Geneve Options. However IPsec/ESP
does not provides any means to selectively encrypt or leave in clear
text a subset of Geneve Options. As a result SEC-GEN-3 is not met.</t>
  <t>SEC-GEN-4 (N): A deployment using IPsec/ESP between NVEs with an non
NULL encryption encrypts the Geneve Packet which includes the Geneve
Header and all Geneve Options. However, IPsec/ESP does not provides
means to selectively encrypt some information of the Geneve Header. As
such SEC-GEN-5 is not met.</t>
  <t>SEC-GEN-5 (N): A deployment using IPsec between NVEs with an non NULL
encryption provides end-to-end security between the NVEs
and as such does not permit the interaction of one or multiple on-path
transit devices. As such IPsec/ESP does not meet SEC-GEN-5.</t>
  <t>SEC-GEN-6 (Y): A deployment using IPsec/ESP between NVEs with an non
NULL encryption provides padding facilities and as such IPsec/ESP meets
SEC-GEN-6.</t>
  <t>SEC-GEN-7 (Y): A deployment using IPsec between NVEs with an non NULL
encryption cipher provides the ability to send dummy
packets. As such IPsec/ESP meets SEC-GEN-7.</t>
  <t>SEC-GEN-8 (Y): A deployment using IPsec/ESP or IPsec/AH authenticates 
the inner payload. As such SEC-GEN-8 is met.</t>
  <t>SEC-GEN-9 (Y): A deployment using IPsec/AH or IPsec/ESP between NVEs
does not provide the ability to partially authenticate the inner payload
header. However such requirement is not set a mandatory so IPsec meets
SEC-GEN-9</t>
  <t>SEC-GEN-10 (N): A deployment using IPsec/ESP or IPsec/AH between NVEs
authenticates the Geneve Packet which includes the Geneve Header and all
Geneve Options.  However, IPsec does not provides means to selectively
encrypt some information of the Geneve Header. As such SEC-GEN-10 is not
met.</t>
  <t>SEC-GEN-11 (N): A deployment using IPsec/ESP or IPsec/AH between NVEs
authenticates the Geneve Packet which includes the Geneve Header and all
Geneve Options.  However, IPsec does not provides means to selectively
authenticate some information of the Geneve Header.  As such SEC-GEN-11
is not met.</t>
  <t>SEC-GEN-12 (Y): A deployment using IPsec/ESP or IPsec/AH between NVEs
authenticates the data prior the data is processed by the NVE. As such
SEC-GEN-12 is met.</t>
  <t>SEC-GEN-13 (N): A deployment using IPsec/ESP or IPsec/AH between NVEs
authenticates the data when the tunnel reaches the NVE. As a result the
transit device is not able to authenticate the data prior accessing it
and SEC-GEN-13 is not met.</t>
  <t>SEC-GEN-14 (Y): IPsec/ESP and IPsec/AH  provides anti-replay mechanism
as such SEC-GEN-14 is met.</t>
  <t>SEC-GEN-15 (N): IPsec is a policy base architecture. As
a result, the classification of the flows needs to be handled by IPsec.
However, the traffic selector available are probably not those required
by Geneve and further integration is needed. As such SEC-GEN-15 is not
met.</t>
  <t>SEC-GEN-16 (Y): IPsec is able to assign various material to each flows,
as such SEC-GEN-16 is met.</t>
  <t>SEC-GEN-17 (Y): IPsec handles mutlicast communications. As such
SEC-GEN-17 is met.</t>
</list></t>

</section>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>We would like to thank Ilango S Ganaga, Magnus Nystroem  for their useful
reviews and clarifications as well as Matthew Bocci, Sam Aldrin and
Ignas Bagdona for moving the work forward.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC8174;
&RFC6347;
&RFC4301;
&RFC8221;
&RFC8014;
&RFC7365;
&RFC7258;
&RFC8247;
&RFC7525;
&RFC7516;
&RFC8446;
&RFC4303;
&RFC4302;


    </references>

    <references title='Informative References'>

&I-D.ietf-nvo3-geneve;
&I-D.ietf-nvo3-security-requirements;
&I-D.ietf-tls-dtls13;


    </references>



  </back>

<!-- ##markdown-source:
H4sIAJubeFwAA919a5fbxrHg9/4V2PhDNBsO5Rm9bJ3dsxlLiq29el2P7Jyc
3T17QBIcIgIBXjQ4I8bW37p/4P6xrWe/AJCckZybrE5iiSTQXV1dXe+qPj09
NV3ZVcXT7PuiLq6L7LKYb9uy22U/Fv+2LdtiXdSdNfls1hbXBx5aNPM6X8NQ
izZfdqfrq6o7ra+bB6dX9NaplbdO2+Ct068fG2PytsifumHNzdXT7M3Pbx+Y
DzdPs5d1V7R10Z0+x2HNPO+eZmW9bIyZN4uyhke39jS387I0m/KpybJ2OS8W
ttvhqnaFhW+6Zh78s6wXMLN+YZu2a4uldZ936+hj15Zz9/C8WRPU+rmsq7J2
0wAC1vlmQzDhNybfdqumRZjwz6n8ja/BCM+n2evyKt9Wnfue0fc8r8ui6v3Y
tDDsC4DG2qZ23wJ8RQHwfXP+5FH2vs1rmz3L63yRZz82265wz80Br4DhvKy7
7FW+bWEVk+xfn/nfmwVM/fAy+/q7x8GX27pr4T0e0n1frPOygn0mQKdrBvSP
hcA2BSwNL/lymn0HULWNTZZ8ma/L3k+04J9f3wBxTIAK5tN00e7zabzMoe9x
eYPfywoHfpNVzhisP16vERJc3H/LRnf0z7D56eJgP5Pv/0FWtrgBqIJ1jW7a
v7SlXdV5ne4akJFd9X+l5f1LXjVuyL/zwiwB9scPBAKtzJjT09MsnwEY+bwz
5v2qwOO6xdOcLYolnGKbdfClMqksZFLANbJN23TFvMu6ApYK3K65Ltoq32Uw
4HJZzrP8Cs6W7fwA3QqYGry7bJs1DY0cLQNGdtO0H4B3rTdNzYOv8i6DLQB0
A6ebN3UN8xSL7KbsVlm3hY+Vzcr1piJg4IethX0zyIvhxGVveMTs57LttnlV
/i3vyqbOXtTzfGO3FX+6x5z7ZJola4dlXZcLXPxNA7ADOM1yGAmA8LNpDy3F
dV5t866gFS7yLs82VV4HeITh8uyqvC5qsyg2VbOjaeFbkSWCxylQ03wVD684
AX69wLn4DYd5Ab2NwJC5Mj/XNMvMeQQ4POTAWxfzFbAxu4ad4VmW22pZVhX+
k56CMevdXtiDyTImtHW5WFSFMV9FEjJ703S0HbwHH4pdBju3sNnvXv90+f53
E/47e/OW/v3ji3/96eWPL57jvy9/uHj1yv2DnzDw4e1Pr+R3/Jd/89nb169f
vHnOL8O3WfLV64u/wF95vTC/e/vu/cu3by5e/Q5QDZtYWk8biH/Awkwoc9MW
SH05PFHYeVvO4MN3z95lZw/NL7/8lx//9Oz87OzbT58y/vDN2ZOH8OFmVdQ0
U9bU1U4+Aq3sMpCURd7irHlVgVjflF1e2QmOb1fNTZ2tCmBLhs42IBLUgLZZ
bOdEzr98VQYfPzE+5Whl1/FB0E3Cv0H07eC/D7J7eBhPMl7MpqTzVtbmT+UV
bvjZBGFqboAE/fvzqtkuIqKTfwM5Vc1VOc+r7NX5/VcPTHiOs2XT0tl4T3wj
u9zZrljb7P1lISd/VlRNfYXjAVluinkJ3MQwl9ElTbOLbJPPPxQdkPG8AAJf
MFvJYZwMtqxwhx1+mSHvKQCKK+CCdpQ/LK4KRMML4AmIvWgImay0Bkaq4RwA
LAAgrgNoGRghMLMXyOGa7dUKoGAuBeIPnwa2N1+VuCQcloAw+DicG/yGnyUi
8PPALgTTI7kA3kAuycnH9XR5ewXPvr9keAnVWb5Y0CJF77J9KO/ZEyRksyhR
lZttOzci/moRW27/gEDnsNQWsQSPCeZMgrkL0uqQeQD6Lk5A3DFHhnHCSYAA
gEQr5YfA3QxQ2wuYmLTZn9+9mQJR40vANXHaop14OaF8fw4UiAfQs3/Dk92J
/cNB/R8vT59Py6Jbhrr5p0/Cf4Wx6eyF7fJZBeIdcXXaNafwF4qu9bYGfOHQ
cGDXLAVrW3Yks4iPiDDgdcGRzFk5LVHaXpdzONi4icl0etT0JMMhmFVFtgbt
soT16xp1zbjbAE3xEbDOxxtO0Ao2G0QkyAwaCiyFNodNAU6xRW0LSStPB8Il
GLvJcTcQuVUMPWywAyH43qJkoWWMzAYsDxheCWhFfNAQp3Sw57t0qRZNoGzV
AHNYTHTTgQnKYRBOQ2cbfnPzOW50s2poH2ZI6Mtlgfq91zyGWZjw1j+cyp8/
ZEf88U/Ty78qX/vDgffpPff0r/Iyc0P4B/5v9M+9359ET/fAppen6R9+F/5/
0gM7/PMr/xpC7z7f+78nvefhx1/hGPwqz+Cz+nlo+GC4X+X/fxh78H429UsT
gKYDD96HrwkOOJYXirqBB+/j17rAPSMy/np7sO9B4L1vhapw6+F/CYr7+0N/
6YnDL1Eo/NqjiYSgUrD4068JNYSkxLBn2f8O9/UwkPwa/qHtdGQ0tFGZG3R4
Iz20t/71vw/9GRwl3a7+aOny9p4C3Yb088CjMa6TrbgFAPQf1bmeOpH2Y0EM
bF5kr8EGrEiFGhFzQoNsWv8vUDufPHj86P8gVw4VWRDL8621PROvtB/U/FJR
NMstSn50PtVeOKB2hGYnME2S2YtFidNPEoUZJGVnRf8IHGOh9eiFnug+gSHI
digpoqNymsEt63m1XRThcCxDs5fvSGD89PydWRX5QnUKeegH+Urtl42IcHyl
hPdbgGpXNfli+jlmItqJly+enb5993TcXuwbat6wMrc2CrMBo9DsNQovAwO1
vysiS1GRLa7V5M6u87ZsttYbjagCvN9tWHecZLZZF8EklobZWhgHSGNdolZo
tzNAn04KOlo+KysgJkBtKOQFGtyXtgC1FGxGtQ3AZrHbNe/cNPueFgZj2cJZ
DzTcxNN6CJPx9rhOEuwALztzy24LXrib26/coEaL9hOezuJjjgpq9vz9q0ux
/x4/ePgEyBV+fPkOoJBvHz74+gyVzbcEs2lQG85gxAWDSyegZLNtOWimy3ll
zZAUQG+kDyxISMfK6La8kpHlUWdwuQmmaKUXPEvELazbQzEfbEJBqBoa1vbR
1gWjTdgEKJoRCatJGFoIGZjkSHHwnUX6JTaQ9djAoA8dEXoR7WnorrhBZ8aM
ZtORGWULssZhzzs218jfBIQsZ9dEMC8aQGLdAEbzEhkpohtGnIMxA5Nbsm9o
UelJMwPzb4CEcUaeKOER6g3DycCqq+BwwVajYmTQj4PvfP/iTcJZbufRMQj9
kR4d4UF+VDwjMrdJqcqdE9tUW9x6Ehd80i16KG5IEjRz2HWEzrJ/xfAYcgaU
54Id0YAtgrNx3IEW0xanwFEyMnroaGrQRAdGOv1QoCBwLO4eHcGT6AwSb3kO
JHvV5ms2zjZN27GHxPhX8UifRGeaxYUDAERjuyN2BMRzhYbxCk7pPTV4xRt0
fg5znkwyNsC26FboxIR0KLGejMECWpQL5N14WHIzsLsDdAXTAcsvxwjbCO1k
eyg7JmzYPGZR5KdD6DtTFWDh0Tkhbx1YyN2WxdK6IGcj/on1D+LYwoSWDXqW
ECw4+oXKs+umAn771JyK2vVUyAowwK8husipnKPKQK4l6+SRFaeSWN+ALjZi
nScMcONcSSjX4xfJ3uxUjAkX6nLQRVpY88+vA+8zuzlkeNgZHWi5recikTJY
hJwmtRDeiVB+GugRXuQ6TzquzRb5GtBiq51RD1oXAJx40cToZ5oZXC2B8zI2
y0fASYx3Aqfd1vSjSWBV3RAo7qYAUsht38nnqTnghsg9lGIzb6onc3u7HknX
P1YBDBWwGgNPWiA2p3sM4TPUX5Fl5NlmOwN2Km4AVJA+dsRVSGG1zbYFlZv4
2KYtr/Hw0ZPAAUHwVXmLKk6eFeg4RK11S9SArhMZpwSS1HGsqEzhuCzz2iLc
HTIDDONtMkY3xDRGNlGcJSYMkJBPr0+kHo90mlDnivFrFL8Z4ReG7W4K2D90
aDIj4ONjaTLbpaoTbSyYAKYMPElycoGSakQIIknPKzyGH0NfE67Ux3eukSph
CeJwXud1DsjHd8jHzJqFIBzJbY3Yxb2pio+keJLYiWhOzB2hVFRHyZWvSs3I
Dhj2YwkAdCL7p42Po2IbGAruuolJmxEYo9efnFEKMPsoQLRWUc+IBTu1ONh0
UKTZZekm/oxJU9MvL9eqwTPZx/ZfUWNM8ilaRu/HsQz0VAHgrZUoo1pjLsgo
flwT2WonLI9xBpyazu58JzZdV1yh3JxSDGzf1BErBL4LPDhvUd5iSgFZsPAa
HJGy/mvBQRg4WSB0YZVzVdgDFqgQS5iiba62qNItCg4zjTJUlPbh086HmZKR
ebB/PcgWxHQaYo4IRdGukUDbZgbUWGMYQeytko0yp9mTJK5I9lnbzMs8sAJk
R9hutLpDao6vYoObP9I0sQl+gka/O+eg9rYN7CPMAwsITr2zizG0+B7gL+um
aq52qcKxVV9H55/BxYgy9vXZQ1Tj+BN6TFgd3BcdMDij0wrfc2xbprVCAcpj
AI9dB/iAA1G0oL+tmSW/+fnFxO0zRwEs7Xe9E0NQv/QRjutiIh4Py0odLopH
x3k+1KxKIUEtClBZKjtoz3McRaDBn8vWwQiQoUp5hTx3WRbVwgqJZsNbiR6i
dF9lFwmJjm+H7pTsQmYjJuSpJw4SoS7YbDtEIpkWdt5sRHIGu8t03zIpcfAP
JACQiNgH+cBGjtiNrF2jPEP5LikLsIq82oEgQ18BBaPSYAV5hzi7wXmiNA1C
3p1ktgbOC0idZI5lTEKGwfHnFiQoEvR35Hdr1JUhyRMply1q+Lt1SrGzfcJV
BcAhPhclO1WAFTbkvQKjo0AzpbBPM7ZEr5Wk2DgB6OBA8zfJYHl1k+9syAVI
gWBHYi6qlLidPE8EOcxPgLqAelK+xoAvkzwq7FdWmVRRg1htat5lOHFfZe8E
QKEfY95FEI9vQHYPbJpyTvYPyW7cOaRFDjUFQTy1kPgxZ+/ww5Ns1dxka7Lu
eQY2//AwAo02NhoKz0Azh01hmaQkkN1DB1FJ+o8TDBQ2LcA2Rw0BjiVjTL1K
cFYtek6q3WmJ6XrlckexwPDZpnWmYzTGvWJ6NZ1k6IsCM65Dgxz2auLIuG1Y
dXV258m0j1dUKvLKNqrUkbJWgypBQjacLscMMTC6BjWilp2CkWHAQq2Z2aK9
1ji5iBHBDh5x2EI419WCoRATUXVo1WWcKsOjFQvj6WDh/NSgJgYAT7M/eZcd
avR6CDQ3ScZiGQpslWRIQYdH1gjYQdNazNeYlmY7MHLqckOxZxSZeJ5ImLbe
bHLfLYXgegM3SF5oEOZrDowmYIeCQBClzPQePIfhUxz4pkT36w1x1uXJIAAU
ISUg0NRVPV1OpJt+QtogcJLtXB/vDYasaltwKgdIsq5cw5B4kC9EpSnYRHGz
CkGKyNDxKLwbiQc0ymrjlou0WRX5B9FXmKWyvI/VLsWqjiypFG4gPIS6+8CU
yq4h6hbF4PzRNyD6AfrrhrVanDOlfljzKm9J9BT49Rw18PdjzNk7ucva6Q2/
/KKM4hPs74bWAsYOkO4VGqHsSfLSumpuilbPDZ5OGB+jRSgtnD28ZkgRYpiM
XLPbemuJh+D+1I54psRnL4jrezYrnz2X5eO3bsCe2HntRPULJ+T8L8b91LRs
ri0ZbGK2cbhB9P4du82Q/83Q/9G22w1zKokVrQoAZrs+mWYRfJyCwfkxPTeE
EW9zkm9HAZ6WdQ6X3bAGkXEtfLxrZE1ZWVXFFezGmvL8hMJInuaSqGS9Sf9n
1dJiii+djNvksHw1Fi6NkyqlDz/IJsn0TOSU9uTZn900NdHkGg2Vq8KaGYpr
CSxkYWChXMbMomR3315wAmgCrz+lsAlU+iAd9veXtKsgBwxDSoyvRtctAmox
rjhX5MSIWeW4jXO0t1ymk0NxNmvIPyEqkwR1Ng2cWBc2ItaGgCmgkv8VxZYi
NocuV1y1gGCz0yQ5Z0KheaAbWNcpmq8oBGQnNJKp+a5kmw0QSLwVhrfiZpQ4
ZEcQLolcbdtlPmf/b8QBWkzyBfq0HTqAgbXAnBXSfirX/BEPz0fuA2mwOlR/
OcbA0hRsAawyEDenPijHj52vMG5R0prQOkJlNCMbXQUGi3gYGEayq+S7YDLg
ks/ewU+1WVZNswh4Fx1RMvuJJlExqzgewqxUeZ9aqV1j9HwovdkwjLVdbKJV
5uRhBCKFXUPCFsRQst8OlO1gKj5xLg1MhReGW4AGcSxUM9pC+DYdE6BftiLw
rIBu4BmYpfRjR93qSHCqFpy2rZWYDePEO5oCGYa5fMgZhRtE2mfkU6L9JUbC
yaJFoBEBe7U+O7MTT1AYzCRiBTyRDu1t20DMgtaJXw6BKX4uUJnQ3sOAQapX
diCZTL64hnnRvEes+j0Sz2TOlJ3BSQDRTM8AaKzQIuYE/LI1buNDl3Q0IJMC
PJQFLMplYKJ8wsx4mtbJA0y2DJ2/4XihotRsELafnr+jVMsebaFNRuTICycP
ZHA61cCniJ/w/pDh69q8rFCXNvMzNN8pfzDML8CkvSK3WyHhcg0rVcVLjbsw
dl8GcTqh8JZ5YSQ8cGZk2YZZdkQxExYGAJgKfGRgtDrnXStBasnmMcPwPmeh
aj1VzARZMJD+J0BMOCC5xODmTEnKROeHJUCA4IZSYMg9i+yU4j0+YxqtH/bu
hQYavDRvQdKklG3Jit/Oi4hNN0uj4M3AGor5OzJs4dfqg9Hj4EJWUQzHHfYZ
ilD0EDC1BmKGCRfIE80r9DnnxJokLUHMebacyEC2rLs55C9BzRZZRhHptmMP
k8mvc6B3tjXF9R5yBWInc+BwthD9gV20Fuy+qeml/OOrzm32mlVaPD5Jfo2P
EAKxuOedgToJQqvsN3HhDjmNmoseJSagFxEN4ILhcLmoO86Ipggj5ps62gLy
VwLKgYvkH8grStEMCvI2V22+WaF1qeBgjjiav5gOhN4q5nv+ZxqOAqUc+ORD
Fo11tS0XOejvLqNEQ8YcbA4DyEi9Ypw8On+EfsmXUrSAllLxEaw0p2I43FLc
EnHkI9WkbSrOg2g02M/+IQokvGMSQfJTmpS4JH5FWfx4WCmVnPHLtuhMlboS
KAlVKPHrBc5LVIlDzIHRUYcmLZl+7HXWlN9dCAfraqymtmgNktYXisPEziTr
CRkB2GvEuSngwGeLMxnECsEA48r7TjVdQ/P9yy628Jxw5EmDYAFtjQSClMSS
Zffdm0ayD0jqhqtR2f7m54sA6300XgLfIfOo2gUhGRcLye4nCQgTXMCS3Uw5
aVT3AzIgHwXq15gewR6uoYyxks6JOwPorwZ+Z2aFFytlFCHRGDb56m165MOS
s7KzSdI926xKm1iTINq4KleX6nn75StnWzPLifzSE6ArjLbrVGLQh5lofXsS
9zavrHNQBA6NCEpBg5hRzpwX80TGlMqJQDtleejTrpgpxKrZ/7x8+yb7czEz
L/w2KV84e8x8onMpLRUV/aQjUrKaSZPVfALbNw8fPg4S2O6/uHznE2geIO/5
obkpUKTWTV0YdfX2t5JNNLvFjSmlkibMB0Wya2VjjAsY+ElZcFZFztHgeVXk
rLRy1IHKjniNkRc0SU3AxFAulhGWRX5J+LbRVMIgsdWwJQqr2ZTFnO3HYGzW
ibasKSHGAEmU+heQhknx7yg7AAx/tpQ/lqOWB2rnRLhYfB4D8hRKUzIOsjXJ
3K+AasU8Y7xiQkuUHpFGCsk/g/K/5OyXiOQbtlwrPgtkjQe/qpo2MjLnrAVB
Sk6/zSS7xkZ+tCQwJP7g1LeOSm2XU8KASxCivCeZ4WXo5tVBXsbuOmD/bemC
LQ74LaYf/DCWM2zuFR9RjwocXG81dBlsaBw5e+uyVPuABOlvIikxMbGpZMNy
dUF0kWeCbWEJF/bXTJSgaX/hwDCixFt4OCOhxmn2GlMm1NJnUyBPsnTDbdLM
qEUSx5atPQ5L4QT3kHtMTFMXUZ1R9PaJT8z168lT1ACtIrSIN/YYOO+LHcZ2
ihSNv3Jt1uEzOIB/8gbreTH7zoYxAb8JErlfpmxG7RH1tiyc0Z7UAwuOio+b
RpwI+up1U4Fq0bWcFLEBRaRoax8pYxvE5CMZZM/GEeGcYOIP0KExY/NKEpkj
lOxnFyjVv4I9F00KOPtwpw1z0U/sjtKaHUowzcalv66iugSDhac3T435r5KH
e3r2NDt2YCk4Rn2yWFKbClGYIuasse/RJH1MegaFlI1+UBa803LXd8UEKlmZ
pBb0lRRmzblPmevRc4nOoorz3PlgeBHNmZ9o+5mwzteH0wIaCOgsrzD6vlNI
vS9Wk2L85rsAIW12w6jwUijEJgt8/M0kwk/wG2zh+fFbSEZZWL6faA9poguG
UsRRNXDwVajEp/6dGOns+M4pUO7PHabZsmnusu3pATA/NNJkC2RM5XXMhNGo
aJpsVV6tJqzODUCE6zNY+z4rmMGBBhroT2AsooHnMPfgczDH64pRJjQxwBKm
ETpWGO0Bs8ZInLtEi3zP2zz9rHDqnCQhbJA86yuzaSok4sgRKLxTePdiu17v
Qpcscp29rX2MO8IDidj7mAydMeAyjka/f/Hm9OzpntFodaE3I2AJmLI6zmay
YIrzfVMI8xqfZPgcRtNJBtA0nPTB0evSrDq3nDBdFV2PRHh/K9oGtNN9moEV
hYitg0gt0geU5KewpZhbWLCKk0BqEkiDMByP7U+BsGAZdiIQKHcWXwLrHfGm
PLw1fhT/JlXDPBM6qHiF6za9dacQ9NbtOEasDkf5JgnGGZRicSJ62BBqIsJ5
tAcxtn8iQkqVr/coa+o1cQSEeZUYsJ4WU/elSVRAqZMHXZKMGA/q41udXQ8p
siePfXHeBuM+ueu4ICEWZoCjZYHnLvWOvHShJ2wkIv/+NBSaStJX69ADTalx
vbohRJ8JslhdrX6irZMPXiJvNedGeo1eXzJOtfcp21pc8J5eZr84//R7qwlG
ruwt54IY8/riGSfRh16AKGPXvQyaOcfwBRkuoiaRfgnUON/5JAjoepekkf4d
9CN73n1fESnb4Fqde5H/9SQ+Z2KKYEzWv46KfhR20Ry4PDLk9DUTepeUfUvi
owsFxz654I2J9GEi/ahjVzJxBw3QSqq2L8+MQrzJxiBmlJC9Q3LcvcHAznah
w6hsU7cAO9FChdl5jybyz4sfvPPqHN3q6PwSt42UuAVQyD8xkdfl85MXJyxz
4dZWQcKD3TTN0m0Tt/LhKPBfNcqirtIgXMw9K8gp7ZV54FBA2rxlKX1yZNv7
x2h/3vz06lXotBVjUMPJIY2dkjeXVFpeUj5rrskVVkq/Di6bEK+Z5Gxr2kEQ
NfIeQIdjV5e6Kkx/V8XTB4MyJpRyVTK42dglZtQlRuaPnIugT4/1I0XlRytx
+QmXNBwBj2lN59MTyZUozY3QO3rU0XfmM+FGEvZBPAyk3KhD0mVrmAhtFzYx
5sQLHDKCMFpjkoLBMGHA+aqxx0wYvLmQjLhyTdHJG1i9C3RoaIiclmfTB1Gh
bVfZ0wX85+zBp08IHPtfc25raXzIDtipvu5qCHdFNyioiN0EyzOOBl26jBbR
lnRAsIaz2nnDSJytCDBOSH6uBqsxOC8tRhBT+Lzc4I5YzJCxQRyfIruxvhDQ
6mSYLw26WLPExao0cksXa5a4WM0tXKw9N9LxrmOOgJjB5RJ1SRRroLSP9QLH
+UyUAOVPZM6yKkxXSQWCuDEw/hm1RErrYtSpKTCFYT3xXhCrQ45rrgvKFkHl
CDmyA2hWEJfuCiqWFbPeAWS1aDHkPPiE4lxbcLgSG+dU5OomyeMIHPPWjE3m
Umc1ea1pyyti+CjIKD261seNoApJAc8Y62S1RlS1+9YAlbgcQleeQ0l8A8k6
cvgmPeGD3lQxDIxLHg0OslCUpDklRSeueElqIFGdNmFQrOfEwunCsyzrAuu6
SnwqxiVaJou+yaXVBiYYZVGCEXGkiFOY/W60iQPKgkhYVKF5pJkcGEcynJka
ZV/F9pme49Rmv9xu0F2LmVImwZ6klrM3N/TDqMn3wxnXIvxwfiL2ShRDy+69
O6Pv352fTN1E+NIP55PM/caFHaHooeg2V6bMXb42PAgYgre4BZeL02sZOqdI
xjuJlG046osBPlTHZyWnrSqmfjgXMEQJG+RGpTXHupAz1N7J+T+YZtdLEv59
L78n44L7Qc14MjKsJLS5scUzn3KOmeqCfTOdmQchEyYQBQXFEuVQoBYSxRzU
sfjTZuFPSb/Ijn0V6M/J11jHYF3w1xZdJ6kVby9ew7YAs2MHGoigK1B3xc3x
/tXPlMFt3AtgVpQddXukl7gdBHJLVB99tWkA+qxY5ddl006MlO9jgsgVJkli
OjEnpgVyIK0OcLySj5AZ6zbHv2MvAodAZ7TptmmKB3I84zleQk542CvXKG6f
oaJnNnS8goiyXNM+wAeAcVxtYTtgSF876VGlWYBVh2JjmsRP83a+KhGAbVuE
GZmJ78IJXhmYWVQakxwM/PW7AFF+9oUP2A2tOKbNY0KBJggF7nP2eT+XnpMo
eleTq4GqvtMYHidflGMR10jVRpZmhgKtmjAuc2sUMn15MLSaaWotl08W9WLT
lFq9OMLmjgweDjURUe+dF2gbsFtbavXiCew/Pcb28JZhhsCYCINjAypI6DAY
iJehtaC20m1CclkckjNRSI4eOBiMy3rBuEDpPi4Mlw2G4UITeyAM59M7Y6j6
YTgzEoYLjeU0XTQyJ3zejt/qR184opRznXKRsJs4ceP4pA1fg/52049KuRrg
sSBdFIMjOqBUoSRTyOvOsYLlsfT4tkHnaKix9H9qTzzYdk94iUmF51AjF7XS
fm/TebQRA+shJ8ceqIRniQyNcpm4yhDMSXLwlF1sOjkPJR2/GCgTt7XwNmZp
teOXSgWbJU3B8aTBs5gRCBwcfg9+E3nqAxKow9oBrhOnLokDN3vvjVavNCqo
AxkXE/GAaPsr0wOFGEluuwGhq76rNAZmxwnwya2zHhB3IlIMt7xHSZNsLmB0
mYWVDVy1paWr8cjGUYtM4XgB9XohFfE3DtSagUDtN58RqN0voeLA4LdfKFp7
QCoOhGzPvv5SSxyM4DZhkDbrB2kNEyjIloQ894Vq+yFLsz9Um4w+GQxLmqGI
7dnxoXoX0h7YhH1x2+ik+tDp1NwOBXHU1iRLTkzDo4K3hrE04I3pB3DPzvt3
I+3FE3e1S1RjbsePi4gpOeAxzBrJkadmU8DNCJQHdwMl1v7vAsOhqOuPvveH
r4jXAOdSnCZBt5E0U6oVNUxCo2F7s9vXwDsHjglr4BEVUeG3cPEkvsm5/oDT
lrUxaU8YuyE0xNMFwZuh8L70ujRhU1u91oDrJ6gByYjBynB5/yK32+SQRXAq
BhEUJUPB04AJH7XCrh3SWCrKXth4jUdxEntLqezhLgBgsBYrUiKuFPsEpe4E
ezJQmxFXJsmgKBGr2HWbhIlzwTpYx/IfY3VhksWftUdR1EKD4BjZzXAnXbm0
cvyQ94gne+cqsik3IyzdXcPntg4LprCfgmsH6gNDY7Ez0fi01YLWPHFFtW/X
iWBjAEEuSBA/mc9jDH2y6OxL1CljAi0v9I5WDQMkviC+FydyE1MND1a0+dYK
gddAD0KU/RfcLyFK80qdSyaiM3rEFY2yI577snpnyEgGTWhaIocIh0IZQZbY
IrQ3sCjnx7RTtXZWIrMC3c8H+l98wjX4zhdaxaPVkmxIj4/jk1nigfpeW8ff
DnNtLL/88gwbR00dbpMosSLwe97f45NWFuCSTNyQWklTc60LBvXtJCwQtVFj
gNoXdupVNWIFYqm4HcuLiYFJs2Ncijg8U55qt6sLCUhleGKSsyuXf/CjKFgp
SM3JO9hI25US44jSPyvgQNiFXET0tg6jyPEszkZ0pex45md/leYruj+eSqLw
8ZD7btCT7Dx27FI2B8KXfmZtuZDEDTVFKWrCb+8CWkSOmkyQKzGQ9RchYaIV
h4GroJc1J47zGcy0LIMLWEhieXimUYdK+P4jtu7YOZJK3ATEkj35hE3YnWdt
jd0M0jQJL5YYK+RSCEeS/Z2Ym8Jb/D1yCepe6EasYVi42ukYC/W38Kt+8xnO
tizNp9pzEJ7FT7pu5SZ4h7Q25TDOPomOH/MsRqXMMdyCnptQsIWb7klQqanX
abWdQfZDpf5BI4D4PU1lyoPq/UxbIryka79c7/Ge86XvcyntwOJMsLKQ8v/u
Poyzh0fbQwma3DJOh5cR1PVTh04izP/c6MK3tzwFfOMIKdq+bFXrB5i21QWt
bch9CX0/CGNihzW1TV5i0X+sJvmCo69v7XtjiOk2N5DWGKIDowHPBmU/6oSs
n8dtBrj5omtDBRYL3gQgkp6gvEdhN1ATOqyLpn9EZXva4adHRobT/hapy5lB
MX9/mqfQw2GfCXeW5dQ5f4+Arx9xm+mQ62xrauWgCXia15dW5HkfeOKkIWWb
rv3hxgnIDYM23H1aJBXcX2yGdzOiBUpg6OC+fgbb9GO7yfV2nSRMpM4A906a
ocL36ARFzGxiyF05WnmNPkdfFCbdY7kNhBytnGA00pLSjf388hml5l4/5jWU
i7SX7EniiXt83Ja6HCWL1cHBZXDxYfhQ7GxKrULy7ja+8NBSfyFtqsCQedCe
7AXNSv6qO1yc8Akyy3XIGwY+c4c86RfSNtuNrsCEK/BTqL3qLTVuuuosTuk7
42nOv0vjW8wtSXolBRYn9Uzhuy115eh8SRcC5wBsWlw/R8hXYbsISpIQJxV3
asnkzk4jNbyYD8TCFez0v0ljLJdXn+syue3My4s3F1ir6jtx2LDHX93wE3Gv
Di6ljbpvuIu5wobPybjStx+Z7M2qqYKM2tJKP1QlBADuFWq3vmEjIGU0Hy27
H4at1dQxZL8F7krXr4aaFOVLSb/HwkxxFHHeCIBAxB9c9cxNokeueVZtzhfj
h2kI2sEgCJYd22jZOKuNSvEwSB3msgyBw726yI0R395UDzZlFs1t4NYY3xea
FhhkMNsYivhGHTSJsJZhxxfxRveemYPQw0JROuwa7WSlvV5ERKSXiIZuJ2pJ
ic5ONV9Dh2hQssY+HEITo0gSukYy1fGQXGxQCSg/kv5GDUDSFuZrUKJhm7Dr
MZ7CwUoLssjXBSe7meHlS4EJ6za9KiF/u5A0MDLRFVrCIblQZiTWz008aPzw
OhWjWnlUWZAmEQ1nY8ptpj7VnILXTu04eqEmXKDWSNB487xG+6R3bU8A40BF
IqlXtLk+DTa4Zo1izK4hFxK6TxiMXXJr2DJQCJ5LzxJyqEx6KhXd46ed2uSS
EPOX7N5fCnsStLAMLxRH10B2700z8rt4hfCCoNh1gVLkIzZ/71l0qm2iQ6qp
KXUppFQjQ9bsFr3m9D+MFm+2LSW6ltGFZbCHoEW2/Kg8MlWD/bDBksFjyVHB
S7r5nMh5wMRBpgJi10P7dBkk4qX35Ald6N1ksk3cTo4YsyuykBCdoWlJgHJm
+9ZKyqA3MGDTTlA7CYyL4AiHGo4zybHKL60mCkspOEl1rPBSHFZBwrbkiLju
YOJHGTh+4TVq4SFETmONLin0DtDPDi8Kk7oLwpu5PHvdm1jnNyLxYPmxRlPG
y6XPA5tkemFMmB1LdCFttNTycjVuRXCZGNLsDd4SHVbon/8WmxkWeEe5xap/
+eyntNcL49TZSNqYBxvfSm0PNsQk4wHPIneilvqysEfcpuML7qIahN7+OyzE
XQsAJ/ffHI8VoEo5Z7n0pcP62bgjABfrLBJ0SKMwzfhT0zEu/FHltrNFtZyO
kCdpfXEBLwPg+3vWXL6ykVOhzaFEONLoflwRxKUNO40LtwyZsDYiK4hUBxPq
jVfx9DA6RAc8CodYamv/WEObGpF3msZE6cyIrgXmF+56YiMfK/syKRk4SEqr
V835tFI+G5GTXhnG5Cji8BrqYG5un68NnxNzW77mVgDrcYzNSGHeedaHaqC4
TRJanqfleGaHaEq7i0UwaDHdvlx3s788cRoInEfj+3B+cB9MUv2jNwYewvlQ
1t0YE1p2/WSjAcZj+hv0KGo08/hoZhyvCNd42jWnA7p1Hke0+xA8jiB4civW
JyeR9PuOenJK2HCotCC8Y7lXXhC0uCcDQjthUx/H3EmcbETiuKZWUbI95kwE
jJlMHm79i8023YT7BvZulYEJks762m9eYuSsZA1JhygHqOwkA4gdR1qz4b0a
Q0edKYnObLSZT9in53dOdDyCwBX017u0rCCigW9uoRI4Z8KwS196Ih6Qvt9E
03+rJBgLOnX91d6B6VwGTDNamIJ5VM2WL3YFbQWPKugTESZJTok9Q65C5xMN
qsK0uWxkaXNpfyLHvhXpEb5ikldCBfprsGp0gUrp2mhNu8JrPMvfEi1O+YmJ
pZumwEY+PnVQjnjyvTzFxaXlc4QRNoQZtqgYYc8aIyss3j6LlYLAL51H0HPI
nkxGVPRpG7CWtBMX32raxvWokOmo7eVNAG9Wuypg52gaN6szfyHykLG2z918
Q9WgWpRMGtjYBbvTODTx/5lFRmuahiv8TcyUlDezdjzapcqkKc/qhKHVDHgm
MF851FIt30QyzAdpleGSHzCT+MeyzLzS5Er+IldUapdQrxLjOk/ZoIm0ggKM
KW3DS4mLQTvPKK87bm3bo6LYgnHIjKjp4T8XalNe6oTuXrySHVUeKKh0JatH
4vFRzHge/RaIdKQDNixqtYW6ZMNsHo05mdDc8xjC29X06PIlHKU2HU9qQetT
TBJNk47GudRReHnMePnCiBnwSXFx9TKfy51EbKHHt4N5P6lz04q1T80fggLW
wHyXI0dagGogzcD566t2wwh6HKLnyd8HPeM+kSDzOfZn3AJbpoet7PbYMsPY
ehKxq9so5EdjiwIMe00fQWPaJ2i4XepxQv2b+Jh8e4uFpbtrkt09VLD0haX3
kPj+NtLJvr4Fb+z5J8yRrokDEsQckCDZQQlijpEghzxRjI+Ips/O/mnRE9HX
kTg6Tpx45fcsUfBvo//2sRXUGal3QqJivu2BCNRxj7lJ9vM8AfE2+uoIiC7M
J4UKLVqssqEKW6T4JQ4ZkHzhdVc9RhDWlc5dd4xuyEk2wpjPHiSrFh8xLTFK
Iu/l8qqW4hBrRg7Kw2SKR4G3IHXT80WH7L7Y8S3aQcYr6Hax5JlX6CFYJqyc
Mr/GFIEca0i2lbtD25v6rodAjKFHYBW2lJmj+dHSbQcnQDu6Xshaal3OWACb
RsY98oMnuHkcoJ+yZCI/iHZZdF6QMH/SekfKAc71OJn0SbAhwU4gykCx7CrO
eEq9EhdBpPCwvnT2RKpIKJxu7pRR4bs5Nr6botEUi+MzD4ZSLIzeEaUpFv2k
iaATos+b4GQL15NxEgVO99+WEYzSz7wYCpFEmReDyMjsivNirOs84RqpO48X
FTMy1eN4dO+a6wBGDV8DdKMTh6OQ5Eji3RPnlw1y6Qbc9HUuAsY9zmm+eIl7
P3szsA4DiuqS23KcWxNvg5PrvIJ6Yc13SGaWiP+Y4soLPTaLxcS0NJTFwgPu
SWMx406zg2ksXyYbg0H88ukYki0zno/BE98xIcMT/ZiRYFIT4Gi3n55kp1gP
NRM7zh3oWyOyGR9iTZlimqXhl+YCk8elakSpWwOpGuZAqsZoX54oVcMcStVQ
dH2JVI07bLP8k3fEMWUFxjPwcBvNIQ3b521EZb1JtOQclYE01v7g9ovztdC3
SLnw0MCkOLeP/H9G4D8ULsYJl8FI2bGZAGbcthkxvR3w/QXdOoJ+cEF3Camb
HtkEhpGDVEJpUiJyZHx8WLoH8JoY3v0Bczedw+RxEXLm1QMhcuND5NmdQ+Rc
KZu06B6OjWvUesBIMkNRjzQs7jAYXdSnPdt7jqU90x0KkpuhIHnPeDscJEdl
xe0Q3l7J8cPutw2ID2z4kBFoehHxowLgPHrQ/ZyD4KWKjwGdUL35/GqQ+9So
gZKjkGLN0lUTOEVM9o9ql9nl0bSq0nHBkpAtm4yBSuMybJ0uOdsx4wgYVDF3
0XK+/JMF9a53yNB59heHgduHyLGM+DND5GDhGtcCW+BI1Pgu7WDW48UYsxZZ
d0TB2v6YdKok//2C0tXiywal76CuHB+HjjWWY+LQHpzE7j8yAn1XJfv4yLPC
bD7Dd+2gNHeKOQ9wun2hhv3qpai+gzt2ey9ucmEELnEwDL3f2d0LQ5uRMHQ2
GIb2GAzLEo6KOX+u9n67LMbDwea+ZfXbRJx9EDlA2ZHh5VuS4z9WSHkAwQeC
yV+ckdqB2HFkJCdM0UUmEl/ok9uoRkfEJh14R8RuD/HvJzGoB7S4nvEQGwz7
UrD9DKm9sD/IOaxlR/njh2Lax7Zp/GzJkZDBsaHOg3aZNX1D8m7BvV4v8oSj
HRneM7fmZjERkMpHNl8qAfaEPP8J0dSLgh6Bqz6yzswY798T8rwTtu4SAzUB
MENHe0/M8+4w3jYImnaZ1PKYWwZBjTo+ZGGj+/IwMM1oga6LFq7wQBDUhdyC
4QYxK6Lf2bFxjDP0mnyZMCebqnFetPblcJZwfp2XFfecbsnkncEHNoG5gZya
yibOCRoOiGYcEB1gIY9CFjIY8PR4uVvEMxhvEP1PwmkYTfaI2Gbwvh+WSsTn
H+rmBnB9Ja1Z/lyIZYkOCjbj8vpD9rLK66smu8y+x1K4fJK9zq9qWM+bne3a
//h3sGTlnvISbygqwO4zLZB9ccPaC2x86/Y9uqz3dd7BWzfZd818Xk6yy3yd
XVSLtiSHjHl5VcMz3+VXi6bOaYp1c60eJuppIh0igKH/P8HUJm3fvwAA

-->

</rfc>

