< draft-sajassi-bess-secure-evpn-01.txt   draft-sajassi-bess-secure-evpn-02.txt >
BESS Workgroup A. Sajassi, Ed. BESS Workgroup A. Sajassi, Ed.
INTERNET-DRAFT A. Banerjee INTERNET-DRAFT A. Banerjee
Intended Status: Standards Track S. Thoria Intended Status: Standards Track S. Thoria
D. Carrel D. Carrel
B. Weis
Cisco Cisco
B. Weis
Individual
J. Drake
Juniper
Expires: September 11, 2019 March 11, 2019 Expires: January 8, 2020 July 8, 2019
Secure EVPN Secure EVPN
draft-sajassi-bess-secure-evpn-01 draft-sajassi-bess-secure-evpn-02
Abstract Abstract
The applications of EVPN-based solutions ([RFC7432] and [RFC8365]) The applications of EVPN-based solutions ([RFC7432] and [RFC8365])
have become pervasive in Data Center, Service Provider, and have become pervasive in Data Center, Service Provider, and
Enterprise segments. It is being used for fabric overlays and inter- Enterprise segments. It is being used for fabric overlays and inter-
site connectivity in the Data Center market segment, for Layer-2, site connectivity in the Data Center market segment, for Layer-2,
Layer-3, and IRB VPN services in the Service Provider market segment, Layer-3, and IRB VPN services in the Service Provider market segment,
and for fabric overlay and WAN connectivity in Enterprise networks. and for fabric overlay and WAN connectivity in Enterprise networks.
For Data Center and Enterprise applications, there is a need to For Data Center and Enterprise applications, there is a need to
skipping to change at page 2, line 34 skipping to change at page 2, line 38
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Tenant's Layer-2 and Layer-3 data & control traffic . . . . 7 2.1 Tenant's Layer-2 and Layer-3 data & control traffic . . . . 7
2.2 Tenant's Unicast & Multicast Data Protection . . . . . . . . 7 2.2 Tenant's Unicast & Multicast Data Protection . . . . . . . . 7
2.3 P2MP Signaling for SA setup and Maintenance . . . . . . . . 7 2.3 P2MP Signaling for SA setup and Maintenance . . . . . . . . 7
2.4 Granularity of Security Association Tunnels . . . . . . . . 7 2.4 Granularity of Security Association Tunnels . . . . . . . . 7
2.5 Support for Policy and DH-Group List . . . . . . . . . . . . 8 2.5 Support for Policy and DH-Group List . . . . . . . . . . . . 8
3 Solution Description . . . . . . . . . . . . . . . . . . . . . 8 3 BGP Component . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Inheritance of Security Policies . . . . . . . . . . . . . . 9 3.1 Zero Touch Bring-up (ZTB) . . . . . . . . . . . . . . . . . 8
3.2 Distribution of Public Keys and Policies . . . . . . . . . 10 3.2 Configuration Management . . . . . . . . . . . . . . . . . . 8
3.2.1 Minimal DIM . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Orchestration . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Multiple Policies . . . . . . . . . . . . . . . . . . . 10 3.4 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2.1 Multiple DH-groups . . . . . . . . . . . . . . . . 11 4 Solution Description . . . . . . . . . . . . . . . . . . . . . 9
3.2.2.2 Multiple or Single ESP SA policies . . . . . . . . 11 4.1 Inheritance of Security Policies . . . . . . . . . . . . . . 10
3.3 Initial IPsec SAs Generation . . . . . . . . . . . . . . . 11 4.2 Distribution of Public Keys and Policies . . . . . . . . . 11
3.4 Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1 Minimal DIM . . . . . . . . . . . . . . . . . . . . . . 11
3.5 IPsec Databases . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2 Multiple Policies . . . . . . . . . . . . . . . . . . . 12
4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2.1 Multiple DH-groups . . . . . . . . . . . . . . . . 12
4.1 Standard ESP Encapsulation . . . . . . . . . . . . . . . . . 13 4.2.2.2 Multiple or Single ESP SA policies . . . . . . . . 12
4.2 ESP Encapsulation within UDP packet . . . . . . . . . . . . 13 4.3 Initial IPsec SAs Generation . . . . . . . . . . . . . . . 13
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 The Base (Minimal Set) DIM Sub-TLV . . . . . . . . . . . . . 15 4.5 IPsec Databases . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Key Exchange Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 5 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3 ESP SA Proposals Sub-TLV . . . . . . . . . . . . . . . . . . 17 5.1 Standard ESP Encapsulation . . . . . . . . . . . . . . . . . 14
5.3.1 Transform Substructure . . . . . . . . . . . . . . . . . 17 5.2 ESP Encapsulation within UDP packet . . . . . . . . . . . . 15
6 Applicability to other VPN types . . . . . . . . . . . . . . . 18 6 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 6.1 The Base (Minimal Set) DIM Sub-TLV . . . . . . . . . . . . . 16
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 6.2 Key Exchange Sub-TLV . . . . . . . . . . . . . . . . . . . . 17
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 6.3 ESP SA Proposals Sub-TLV . . . . . . . . . . . . . . . . . . 18
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3.1 Transform Substructure . . . . . . . . . . . . . . . . . 19
10.1 Normative References . . . . . . . . . . . . . . . . . . . 19 7 Applicability to other VPN types . . . . . . . . . . . . . . . 19
10.2 Informative References . . . . . . . . . . . . . . . . . . 20 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 20
10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1 Normative References . . . . . . . . . . . . . . . . . . . 20
11.2 Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AC: Attachment Circuit. AC: Attachment Circuit.
skipping to change at page 8, line 16 skipping to change at page 8, line 16
of a tenant on a pair of PEs. of a tenant on a pair of PEs.
6) Per Attachment Circuit: A single IPsec tunnel per pair of 6) Per Attachment Circuit: A single IPsec tunnel per pair of
Attachment Circuits between a pair of PEs. Attachment Circuits between a pair of PEs.
2.5 Support for Policy and DH-Group List 2.5 Support for Policy and DH-Group List
The solution must support a single policy and DH group for all SAs as The solution must support a single policy and DH group for all SAs as
well as supporting multiple policies and DH groups among the SAs. well as supporting multiple policies and DH groups among the SAs.
3 Solution Description 3 BGP Component
The architecture that encompasses device-to-controller trust model,
has several components among which is the signaling component. Secure
EVPN Signaling, as defined in this document, is the BGP signaling
component of the overall Architecture. We will briefly describe this
Architecture here to further facilitate understanding how Secure EVPN
fits into the overall architecture. The Architecture describes the
components needed to create BGP based SD-WANs and how these
components work together. Our intention is to list these components
here along with their brief description and to describe this
Architecture in details in a separate document where to specify the
details for other parts of this architecture besides the BGP
signaling component which is described in this document.
The Architecture consists of four components. These components are
Zero Touch Bring-up, Configuration Management, Orchestration, and
Signaling. In addition to these components, secure communications
must be provided between the edge nodes and all servers/devices
providing the architecture components.
3.1 Zero Touch Bring-up (ZTB)
The first component is a zero touch capability that allows an edge
device to find and join its SD-WAN with little to no assistance other
than power and network connectivity. The goal is to use existing
work in this area. The requirements are that an edge device can
locate its ZTB server/component of its SD-WAN controller in a secure
manner and to proceed to receive its configuration.
3.2 Configuration Management
After an edge device joins its SD-WAN, it needs to be configured.
Configuration covers all device configuration, not just the
configuration related to Secure EVPN. The previous Zero Touch Bring-
up component will have directed the edge device, either directly or
indirectly, to its configuration server/component. One example of a
configuration server is the I2NSF Controller. After a device has been
configured, it can engage in the next two components. Configuration
may include updates over time and is not a one time only component.
3.3 Orchestration
This component is optional. It allows for more dynamic updates of
configuration and statistics information. Orchestration can be more
dynamic than configuration.
3.4 Signaling
Signaling is the component described in this document. The
functionality of a Route Reflector is well understood. Here we
describe the signaling component of BGP SD-WAN Architecture and the
BGP extension/signaling for IPsec key management and policy.
4 Solution Description
This solution uses BGP P2MP signaling where an originating PE only This solution uses BGP P2MP signaling where an originating PE only
send a message to the Route Reflector (RR) and then the RR reflects send a message to the Route Reflector (RR) and then the RR reflects
that message to the interested recipient PEs. The framework for such that message to the interested recipient PEs. The framework for such
signaling is described in [CONTROLLER-IKE] and it is referred to as signaling is described in [CONTROLLER-IKE] and it is referred to as
device-to-controller trust model. This trust model is significantly device-to-controller trust model. This trust model is significantly
different than the traditional peer-to-peer trust model where a P2P different than the traditional peer-to-peer trust model where a P2P
signaling protocol such as IKEv2 [RFC7296] is used in which the PE signaling protocol such as IKEv2 [RFC7296] is used in which the PE
devices directly authenticate each other and agree upon security devices directly authenticate each other and agree upon security
policy and keying material to protect communications between policy and keying material to protect communications between
skipping to change at page 9, line 29 skipping to change at page 10, line 42
route. route.
If a SA is required between a pair of tenant's devices represented by If a SA is required between a pair of tenant's devices represented by
a pair of MAC addresses, then IPsec tunnel TLV is advertised along a pair of MAC addresses, then IPsec tunnel TLV is advertised along
with EVPN MAC/IP Advertisement route. with EVPN MAC/IP Advertisement route.
If a SA is required between a pair of Attachment Circuits (ACs) on If a SA is required between a pair of Attachment Circuits (ACs) on
two PE devices (where an AC can be represented by <VLAN, port>), then two PE devices (where an AC can be represented by <VLAN, port>), then
IPsec tunnel TLV is advertised along with EVPN Ethernet AD route. IPsec tunnel TLV is advertised along with EVPN Ethernet AD route.
3.1 Inheritance of Security Policies 4.1 Inheritance of Security Policies
Operationally, it is easy to configure a security association between Operationally, it is easy to configure a security association between
a pair of PEs using BGP signaling. This is the default security a pair of PEs using BGP signaling. This is the default security
association that is used for traffic that flows between peers. association that is used for traffic that flows between peers.
However, in the event more finer granularity of security association However, in the event more finer granularity of security association
is desired on the traffic flows, it is possible to set up SAs between is desired on the traffic flows, it is possible to set up SAs between
a pair of tenants, a pair of subnets within a tenant, a pair of IPs a pair of tenants, a pair of subnets within a tenant, a pair of IPs
between a subnet, and a pair of MACs between a subnet using the between a subnet, and a pair of MACs between a subnet using the
appropriate EVPN routes as described above. In the event, there are appropriate EVPN routes as described above. In the event, there are
no security TLVs associated with an EVPN route, there is a strict no security TLVs associated with an EVPN route, there is a strict
skipping to change at page 10, line 23 skipping to change at page 11, line 35
associations between a pair of entities creates a single secure associations between a pair of entities creates a single secure
tunnel. It is thus possible to classify the incoming traffic in the tunnel. It is thus possible to classify the incoming traffic in the
most granular sense {IP/MAC, subnet, tenant, peer} to a particular most granular sense {IP/MAC, subnet, tenant, peer} to a particular
secure tunnel that falls within its route hierarchy. The policy that secure tunnel that falls within its route hierarchy. The policy that
is applied to such traffic is independent from its use of an existing is applied to such traffic is independent from its use of an existing
or a new secure tunnel. It is clear that since any number of or a new secure tunnel. It is clear that since any number of
classified traffic flows can use a security association, such a classified traffic flows can use a security association, such a
security association will not be torn down, if at least there is one security association will not be torn down, if at least there is one
policy using such a secure tunnel. policy using such a secure tunnel.
3.2 Distribution of Public Keys and Policies 4.2 Distribution of Public Keys and Policies
One of the requirements for this solution is to support a single DH One of the requirements for this solution is to support a single DH
group and a single policy for all SAs as well as to support multiple group and a single policy for all SAs as well as to support multiple
DH groups and policies among the SAs. The following subsections DH groups and policies among the SAs. The following subsections
describe what pieces of information (what Sub-TLVs) are needed to be describe what pieces of information (what Sub-TLVs) are needed to be
exchanged to support a single DH group and a single policy versus exchanged to support a single DH group and a single policy versus
multiple DH groups and multiple policies. multiple DH groups and multiple policies.
3.2.1 Minimal DIM 4.2.1 Minimal DIM
For SA establishment, at the minimum, a PE needs to advertise to For SA establishment, at the minimum, a PE needs to advertise to
other PEs, its DIM values as specified in [CONTROLLER-IKE]. These other PEs, its DIM values as specified in [CONTROLLER-IKE]. These
include: include:
ID Tunnel ID ID Tunnel ID
N Nonce N Nonce
RC Rekey Counter RC Rekey Counter
I Indication of initial policy distribution I Indication of initial policy distribution
KE DH public value. KE DH public value.
When this minimal set of DIM values is sent, then it is assumed that When this minimal set of DIM values is sent, then it is assumed that
all peer PEs share the same policy for which DH group to use, as well all peer PEs share the same policy for which DH group to use, as well
as which IPSec SA policy to employ. Section 5.1 defines the Minimal as which IPSec SA policy to employ. Section 5.1 defines the Minimal
DIM sub-TLV as part of IPsec tunnel TLV in BGP Tunnel Encapsulation DIM sub-TLV as part of IPsec tunnel TLV in BGP Tunnel Encapsulation
Attribute. Attribute.
3.2.2 Multiple Policies 4.2.2 Multiple Policies
There can be scenarios for which there is a need to have multiple There can be scenarios for which there is a need to have multiple
policy options. This can happen when there is a need for policy policy options. This can happen when there is a need for policy
change and smooth migration among all PE devices to the new policy is change and smooth migration among all PE devices to the new policy is
required. It can also happen if different PE devices have different required. It can also happen if different PE devices have different
capabilities within the network. In these scenarios, PE devices need capabilities within the network. In these scenarios, PE devices need
to be able to choose the correct policy to use for each other. This to be able to choose the correct policy to use for each other. This
multi-policy scheme is described in section 6 of [CONTROLLER-IKE]. In multi-policy scheme is described in section 6 of [CONTROLLER-IKE]. In
order to support this multi-policy feature, a PE device MUST order to support this multi-policy feature, a PE device MUST
distribute a policy list. This list consists of multiple distinct distribute a policy list. This list consists of multiple distinct
policies in order of preference, where the first policy is the most policies in order of preference, where the first policy is the most
preferred one. The receiving PE selects the policy by taking the preferred one. The receiving PE selects the policy by taking the
received list (starting with the first policy) and comparing that received list (starting with the first policy) and comparing that
against its own list and choosing the first one found in common. If against its own list and choosing the first one found in common. If
there is no match, this indicates a configuration error and the PEs there is no match, this indicates a configuration error and the PEs
MUST NOT establish new SAs until a message is received that does MUST NOT establish new SAs until a message is received that does
produce a match. produce a match.
3.2.2.1 Multiple DH-groups 4.2.2.1 Multiple DH-groups
It can be the case that not all peers use the same DH group. When It can be the case that not all peers use the same DH group. When
multiple DH groups are supported, the peer may include multiple KE multiple DH groups are supported, the peer may include multiple KE
Sub-TLVs. The order of the KE Sub-TLVs determines the preference. Sub-TLVs. The order of the KE Sub-TLVs determines the preference.
The preference and selection methods are specified in Section 6 of The preference and selection methods are specified in Section 6 of
[CONTROLLER-IKE]. [CONTROLLER-IKE].
3.2.2.2 Multiple or Single ESP SA policies 4.2.2.2 Multiple or Single ESP SA policies
In order to specify an ESP SA Policy, a DIM may include one or more In order to specify an ESP SA Policy, a DIM may include one or more
SA Sub-TLVs. When all peers are configured by a controller with the SA Sub-TLVs. When all peers are configured by a controller with the
same ESP SA policy, they MAY leave the SA out of the DIM. This same ESP SA policy, they MAY leave the SA out of the DIM. This
minimizes messaging when group configuration is static and known. minimizes messaging when group configuration is static and known.
However, it may also be desirable to include the SA. If a single SA However, it may also be desirable to include the SA. If a single SA
is included, the peer is indicating what ESP SA policy it uses, but is included, the peer is indicating what ESP SA policy it uses, but
is not willing to negotiate. If multiple SA Sub-TLVs are included, is not willing to negotiate. If multiple SA Sub-TLVs are included,
the peer is indicating that it is willing to negotiate. The order of the peer is indicating that it is willing to negotiate. The order of
the SA Sub-TLVs determines the preference. The preference and the SA Sub-TLVs determines the preference. The preference and
selection methods are specified in Section 6 of [CONTROLLER-IKE]. selection methods are specified in Section 6 of [CONTROLLER-IKE].
3.3 Initial IPsec SAs Generation 4.3 Initial IPsec SAs Generation
The procedure for generation of initial IPsec SAs is described in The procedure for generation of initial IPsec SAs is described in
section 3 of [CONTROLLER-IKE]. This section gives a summary of it in section 3 of [CONTROLLER-IKE]. This section gives a summary of it in
context of BGP signaling. When a PE device first comes up and wants context of BGP signaling. When a PE device first comes up and wants
to setup an IPsec SA between itself and each of the interested remote to setup an IPsec SA between itself and each of the interested remote
PEs, it generates a DH pair along for each [what word here? PEs, it generates a DH pair along for each [what word here?
"tennant"?] using an algorithm defined in the IKEv2 Diffie-Hellman "tennant"?] using an algorithm defined in the IKEv2 Diffie-Hellman
Group Transform IDs [IKEv2-IANA]. The originating PE distributes the Group Transform IDs [IKEv2-IANA]. The originating PE distributes the
DH public value along with the other values in the DIM (using IPsec DH public value along with the other values in the DIM (using IPsec
Tunnel TLV in Tunnel Encapsulation Attribute) to other remote PEs via Tunnel TLV in Tunnel Encapsulation Attribute) to other remote PEs via
the RR. Each receiving PE uses this DH public number and the the RR. Each receiving PE uses this DH public number and the
corresponding nonce in creation of IPsec SA pair to the originating corresponding nonce in creation of IPsec SA pair to the originating
PE - i.e., an outbound SA and an inbound SA. The detail procedures PE - i.e., an outbound SA and an inbound SA. The detail procedures
are described in section 5.2 of [CONTROLLER-IKE]. are described in section 5.2 of [CONTROLLER-IKE].
3.4 Re-Keying 4.4 Re-Keying
A PE can initiate re-keying at any time due to local time or volume A PE can initiate re-keying at any time due to local time or volume
based policy or due to the result of cipher counter nearing its final based policy or due to the result of cipher counter nearing its final
value. The rekey process is performed individually for each remote value. The rekey process is performed individually for each remote
PE. If rekeying is performed with multiple PEs simultaneously, then PE. If rekeying is performed with multiple PEs simultaneously, then
the decision process and rules described in this rekey are performed the decision process and rules described in this rekey are performed
independently for each PE. Section 4 of [CONTROLLER-IKE] describes independently for each PE. Section 4 of [CONTROLLER-IKE] describes
this rekeying process in details and gives examples for a single this rekeying process in details and gives examples for a single
IPsec device (e.g., a single PE) rekey versus multiple PE devices IPsec device (e.g., a single PE) rekey versus multiple PE devices
rekey simultaneously. rekey simultaneously.
3.5 IPsec Databases 4.5 IPsec Databases
The Peer Authorization Database (PAD), the Security Policy Database The Peer Authorization Database (PAD), the Security Policy Database
(SPD), and the Security Association Database (SAD) all need to be (SPD), and the Security Association Database (SAD) all need to be
setup as defined in the IPsec Security Architecture [RFC4301]. setup as defined in the IPsec Security Architecture [RFC4301].
Section 5 of [CONTROLLER-IKE] gives a summary description of how Section 5 of [CONTROLLER-IKE] gives a summary description of how
these databases are setup for the controller-based model where key is these databases are setup for the controller-based model where key is
exchanged via P2MP signaling via the controller (i.e., the RR) and exchanged via P2MP signaling via the controller (i.e., the RR) and
the policy can be either signaled via the RR (in case of multiple the policy can be either signaled via the RR (in case of multiple
policies) or configured by the management station (in case of single policies) or configured by the management station (in case of single
policy). policy).
4 Encapsulation 5 Encapsulation
Vast majority of Encapsulation for Network Virtualization Overlay Vast majority of Encapsulation for Network Virtualization Overlay
(NVO) networks in deployment are based on UDP/IP with UDP destination (NVO) networks in deployment are based on UDP/IP with UDP destination
port ID indicating the type of NVO encapsulation (e.g., VxLAN, GPE, port ID indicating the type of NVO encapsulation (e.g., VxLAN, GPE,
GENEVE, GUE) and UDP source port ID representing flow entropy for GENEVE, GUE) and UDP source port ID representing flow entropy for
load-balancing of the traffic within the fabric based on n-tuple that load-balancing of the traffic within the fabric based on n-tuple that
includes UDP header. When encrypting NVO encapsulated packets using includes UDP header. When encrypting NVO encapsulated packets using
IP Encapsulating Security Payload (ESP), the following two options IP Encapsulating Security Payload (ESP), the following two options
can be used: a) adding a UDP header before ESP header (e.g., UDP can be used: a) adding a UDP header before ESP header (e.g., UDP
header in clear) and b) no UDP header before ESP header (e.g., header in clear) and b) no UDP header before ESP header (e.g.,
standard ESP encapsulation). The following subsection describe these standard ESP encapsulation). The following subsection describe these
encapsulation in further details. encapsulation in further details.
4.1 Standard ESP Encapsulation 5.1 Standard ESP Encapsulation
When standard IP Encapsulating Security Payload (ESP) is used When standard IP Encapsulating Security Payload (ESP) is used
(without outer UDP header) for encryption of NVO packets, it is used (without outer UDP header) for encryption of NVO packets, it is used
in transport mode as depicted below. When such encapsulation is used, in transport mode as depicted below. When such encapsulation is used,
for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV is set for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV is set
to ESP-Transport and the Tunnel Type of Encapsulation Extended to ESP-Transport and the Tunnel Type of Encapsulation Extended
Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE, Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,
etc.). This implies that the customer packets are first encapsulated etc.). This implies that the customer packets are first encapsulated
using NVO encapsulation type and then it is further encapsulated & using NVO encapsulation type and then it is further encapsulated &
encrypted using ESP-Transport mode. encrypted using ESP-Transport mode.
skipping to change at page 13, line 43 skipping to change at page 15, line 31
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| CRC | | Inner Eth Payload | | CRC | | Inner Eth Payload |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| ESP Trailer (NP=UDP) | | ESP Trailer (NP=UDP) |
+-----------------------+ +-----------------------+
| CRC | | CRC |
+-----------------------+ +-----------------------+
Figure 3: VxLAN Encapsulation within ESP Figure 3: VxLAN Encapsulation within ESP
4.2 ESP Encapsulation within UDP packet 5.2 ESP Encapsulation within UDP packet
In scenarios where NAT traversal is required ([RFC3948]) or where In scenarios where NAT traversal is required ([RFC3948]) or where
load balancing using UDP header is required, then ESP encapsulation load balancing using UDP header is required, then ESP encapsulation
within UDP packet as depicted in the following figure is used. The within UDP packet as depicted in the following figure is used. The
ESP for NVO applications is in transport mode. The outer UDP header ESP for NVO applications is in transport mode. The outer UDP header
(before the ESP header) has its source port set to flow entropy and (before the ESP header) has its source port set to flow entropy and
its destination port set to 4500 (indicating ESP header follows). A its destination port set to 4500 (indicating ESP header follows). A
non-zero SPI value in ESP header implies that this is a data packet non-zero SPI value in ESP header implies that this is a data packet
(i.e., it is not an IKE packet). The Next Protocol field in the ESP (i.e., it is not an IKE packet). The Next Protocol field in the ESP
trailer indicates what follows the ESP header, is a UDP header. This trailer indicates what follows the ESP header, is a UDP header. This
skipping to change at page 15, line 32 skipping to change at page 16, line 39
+-----------------------+ | Inner MAC Header | +-----------------------+ | Inner MAC Header |
+-----------------------+ +-----------------------+
| Inner Eth Payload | | Inner Eth Payload |
+-----------------------+ +-----------------------+
| ESP Trailer (NP=UDP) | | ESP Trailer (NP=UDP) |
+-----------------------+ +-----------------------+
| CRC | | CRC |
+-----------------------+ +-----------------------+
Figure 4: VxLAN Encapsulation within ESP Within UDP Figure 4: VxLAN Encapsulation within ESP Within UDP
5 BGP Encoding 6 BGP Encoding
This document defines two new Tunnel Types along with its associated This document defines two new Tunnel Types along with its associated
sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP]. These sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP]. These
tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as
described in section 4. The following sub-TLVs apply to both tunnel described in section 4. The following sub-TLVs apply to both tunnel
types unless stated otherwise. types unless stated otherwise.
5.1 The Base (Minimal Set) DIM Sub-TLV 6.1 The Base (Minimal Set) DIM Sub-TLV
The Base DIM is described in 3.2.1. One and only one Base DIM may be The Base DIM is described in 3.2.1. One and only one Base DIM may be
sent in the IPSec Tunnel TLV. sent in the IPSec Tunnel TLV.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Length | Nonce Length |I| Flags | | ID Length | Nonce Length |I| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rekey | | Rekey |
| Counter | | Counter |
skipping to change at page 16, line 47 skipping to change at page 17, line 49
The Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) is The Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) is
the tunnel identifier and uniquely identifies the tunnel. Depending the tunnel identifier and uniquely identifies the tunnel. Depending
on the granularity of the tunnel, the fields in () may not be used - on the granularity of the tunnel, the fields in () may not be used -
i.e., for a tunnel at the PE level of granularity, only Originator ID i.e., for a tunnel at the PE level of granularity, only Originator ID
is required. is required.
The Nonce Data is the nonce described in [CONTROLLER-IKE]. Its The Nonce Data is the nonce described in [CONTROLLER-IKE]. Its
length is a multiple of 32 bits. Nonce lengths should be chosen to length is a multiple of 32 bits. Nonce lengths should be chosen to
meet minimum requirements described in IKEv2 [RFC7296]. meet minimum requirements described in IKEv2 [RFC7296].
5.2 Key Exchange Sub-TLV 6.2 Key Exchange Sub-TLV
The KE Sub-TLV is described in 3.2.1 and 3.2.2.1. A KE is always The KE Sub-TLV is described in 3.2.1 and 3.2.2.1. A KE is always
required. One or more KE Sub-TLVs may be included in the IPSec required. One or more KE Sub-TLVs may be included in the IPSec
Tunnel TLV. Tunnel TLV.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | Reserved | | Diffie-Hellman Group Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 17, line 26 skipping to change at page 18, line 29
Diffie-Hellman Group Num 916 bits) identifies the Diffie-Hellman Diffie-Hellman Group Num 916 bits) identifies the Diffie-Hellman
group in the Key Exchange Data was computed. Diffie-Hellman group group in the Key Exchange Data was computed. Diffie-Hellman group
numbers are discussed in IKEv2 [RFC7296] Appendix B and [RFC5114]. numbers are discussed in IKEv2 [RFC7296] Appendix B and [RFC5114].
The Key Exchange payload is constructed by copying one's Diffie- The Key Exchange payload is constructed by copying one's Diffie-
Hellman public value into the "Key Exchange Data" portion of the Hellman public value into the "Key Exchange Data" portion of the
payload. The length of the Diffie-Hellman public value is described payload. The length of the Diffie-Hellman public value is described
for MOPD groups in [RFC7296] and for ECP groups in [RFC4753]. for MOPD groups in [RFC7296] and for ECP groups in [RFC4753].
5.3 ESP SA Proposals Sub-TLV 6.3 ESP SA Proposals Sub-TLV
The SA Sub-TLV is described in 3.2.2.2. Zero or more SA Sub-TLVs may The SA Sub-TLV is described in 3.2.2.2. Zero or more SA Sub-TLVs may
be included in the IPSec Tunnel TLV. be included in the IPSec Tunnel TLV.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||Num Transforms| Reserved | ||Num Transforms| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 17, line 48 skipping to change at page 19, line 5
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 8: ESP SA Proposals Sub-TLV Figure 8: ESP SA Proposals Sub-TLV
Num Transforms is the number of transforms included. Num Transforms is the number of transforms included.
Reserved is not used and MUST be set to zero on transmit and MUST be Reserved is not used and MUST be set to zero on transmit and MUST be
ignored on receipt. ignored on receipt.
5.3.1 Transform Substructure 6.3.1 Transform Substructure
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform Attr Length |Transform Type | Reserved. | | Transform Attr Length |Transform Type | Reserved. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID | Reserved | | Transform ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Transform Attributes ~ ~ Transform Attributes ~
| | | |
skipping to change at page 18, line 32 skipping to change at page 19, line 35
[IKEV2IANA]. Only the values ENCR, INTEG, and ESN are allowed. [IKEV2IANA]. Only the values ENCR, INTEG, and ESN are allowed.
The Transform ID specifies the transform identification value from The Transform ID specifies the transform identification value from
[IKEV2IANA]. [IKEV2IANA].
Reserved is unused and MUST be zero on transmit and MUST be ignored Reserved is unused and MUST be zero on transmit and MUST be ignored
on receipt. on receipt.
The Transform Attributes are taken directly from 3.3.5 of [RFC7296]. The Transform Attributes are taken directly from 3.3.5 of [RFC7296].
6 Applicability to other VPN types 7 Applicability to other VPN types
Although P2MP BGP signaling for establishment and maintenance of SAs Although P2MP BGP signaling for establishment and maintenance of SAs
among PE devices is described in this document in context of EVPN, among PE devices is described in this document in context of EVPN,
there is no reason why it cannot be extended to other VPN there is no reason why it cannot be extended to other VPN
technologies such as IP-VPN [RFC4364], VPLS [RFC4761] & [RFC4762], technologies such as IP-VPN [RFC4364], VPLS [RFC4761] & [RFC4762],
and MVPN [RFC6513] & [RFC6514] with ingress replication. The reason and MVPN [RFC6513] & [RFC6514] with ingress replication. The reason
EVPN has been chosen is because of its pervasiveness in DC, SP, and EVPN has been chosen is because of its pervasiveness in DC, SP, and
Enterprise applications and because of its ability to support SA Enterprise applications and because of its ability to support SA
establishment at different granularity levels such as: per PE, Per establishment at different granularity levels such as: per PE, Per
tenant, per subnet, per Ethernet Segment, per IP address, and per tenant, per subnet, per Ethernet Segment, per IP address, and per
skipping to change at page 19, line 23 skipping to change at page 20, line 25
+---------------+-------------+-------------+-----------+---------+ +---------------+-------------+-------------+-----------+---------+
| per tenant |IMET (or new)|lpbk (or new)| I-PMSI | N/A | | per tenant |IMET (or new)|lpbk (or new)| I-PMSI | N/A |
+---------------+-------------+-------------+-----------+---------+ +---------------+-------------+-------------+-----------+---------+
| per subnet | IMET | N/A | N/A | VPLS AD | | per subnet | IMET | N/A | N/A | VPLS AD |
+---------------+-------------+-------------+-----------+---------+ +---------------+-------------+-------------+-----------+---------+
| per IP |EVPN RT2/RT5 | VPN IP rt | *,G or S,G| N/A | | per IP |EVPN RT2/RT5 | VPN IP rt | *,G or S,G| N/A |
+---------------+-------------+-------------+-----------+---------+ +---------------+-------------+-------------+-----------+---------+
| per MAC | EVPN RT2 | N/A | N/A | N/A | | per MAC | EVPN RT2 | N/A | N/A | N/A |
+---------------+-------------+-------------+-----------+---------+ +---------------+-------------+-------------+-----------+---------+
7 Acknowledgements 8 Acknowledgements
8 Security Considerations 9 Security Considerations
9 IANA Considerations 10 IANA Considerations
A new transitive extended community Type of 0x06 and Sub-Type of TBD A new transitive extended community Type of 0x06 and Sub-Type of TBD
for EVPN Attachment Circuit Extended Community needs to be allocated for EVPN Attachment Circuit Extended Community needs to be allocated
by IANA. by IANA.
10 References 10 References
10.1 Normative References 11.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017. 2017.
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
February, 2015. February, 2015.
skipping to change at page 20, line 35 skipping to change at page 21, line 37
[IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) [IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", February 2016, Parameters", February 2016,
www.iana.org/assignments/ikev2-parameters/ikev2- www.iana.org/assignments/ikev2-parameters/ikev2-
parameters.xhtml. parameters.xhtml.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005. December 2005.
10.2 Informative References 11.2 Informative References
[RFC4364] Rosen, E., et. al., "BGP/MPLS IP Virtual Private Networks [RFC4364] Rosen, E., et. al., "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006. (VPNs)", RFC 4364, February 2006.
[RFC4761] Kompella, K., et. al., "Virtual Private LAN Service (VPLS) [RFC4761] Kompella, K., et. al., "Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4762] Kompella, K., et. al., "Virtual Private LAN Service (VPLS) [RFC4762] Kompella, K., et. al., "Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January
2007. 2007.
skipping to change at page 21, line 42 skipping to change at page 22, line 45
Samir Thoria Samir Thoria
Cisco Cisco
Email: sthoria@cisco.com Email: sthoria@cisco.com
David Carrel David Carrel
Cisco Cisco
Email: carrel@cisco.com Email: carrel@cisco.com
Brian Weis Brian Weis
Cisco Individual
Email: bew@cisco.com Email: bew.stds@gmail.com
John Drake
Juniper
Email: jdrake@juniper.net
 End of changes. 30 change blocks. 
56 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/