< draft-sajassi-bess-secure-evpn-00.txt   draft-sajassi-bess-secure-evpn-01.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 B. Weis
Cisco Cisco
Expires: May 20, 2019 October 20, 2018 Expires: September 11, 2019 March 11, 2019
Secure EVPN Secure EVPN
draft-sajassi-bess-secure-evpn-00 draft-sajassi-bess-secure-evpn-01
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 32 skipping to change at page 2, line 32
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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.3 Granularity of Security Association Tunnels . . . . . . . . 7 2.4 Granularity of Security Association Tunnels . . . . . . . . 7
2.4 Support for Policy and DH-Group List . . . . . . . . . . . . 8 2.5 Support for Policy and DH-Group List . . . . . . . . . . . . 8
3 Solution Description . . . . . . . . . . . . . . . . . . . . . 8 3 Solution Description . . . . . . . . . . . . . . . . . . . . . 8
3.1 Distribution of Public Keys and Policies . . . . . . . . . 9 3.1 Inheritance of Security Policies . . . . . . . . . . . . . . 9
3.1.1 Minimum Set . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Distribution of Public Keys and Policies . . . . . . . . . 10
3.1.2 Single Policy . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 Minimal DIM . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Policy-list & DH-group-list . . . . . . . . . . . . . . 10 3.2.2 Multiple Policies . . . . . . . . . . . . . . . . . . . 10
3.2 Initial IPsec SAs Generation . . . . . . . . . . . . . . . 11 3.2.2.1 Multiple DH-groups . . . . . . . . . . . . . . . . 11
3.3 Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2.2 Multiple or Single ESP SA policies . . . . . . . . 11
3.4 IPsec Databases . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Initial IPsec SAs Generation . . . . . . . . . . . . . . . 11
3.4 Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 IPsec Databases . . . . . . . . . . . . . . . . . . . . . . 12
4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Standard ESP Encapsulation . . . . . . . . . . . . . . . . . 12 4.1 Standard ESP Encapsulation . . . . . . . . . . . . . . . . . 13
4.2 ESP Encapsulation within UDP packet . . . . . . . . . . . . 13 4.2 ESP Encapsulation within UDP packet . . . . . . . . . . . . 13
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 ESP Notify Sub-TLV . . . . . . . . . . . . . . . . . . . . . 14 5.1 The Base (Minimal Set) DIM Sub-TLV . . . . . . . . . . . . . 15
5.2 ESP Key Exchange Sub-TLV . . . . . . . . . . . . . . . . . . 15 5.2 Key Exchange Sub-TLV . . . . . . . . . . . . . . . . . . . . 16
5.3 ESP Nonce Sub-TLV . . . . . . . . . . . . . . . . . . . . . 15 5.3 ESP SA Proposals Sub-TLV . . . . . . . . . . . . . . . . . . 17
5.3 ESP Proposals Sub-TLV . . . . . . . . . . . . . . . . . . . 16 5.3.1 Transform Substructure . . . . . . . . . . . . . . . . . 17
6 Applicability to other VPN types . . . . . . . . . . . . . . . 17 6 Applicability to other VPN types . . . . . . . . . . . . . . . 18
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 18 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 19
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1 Normative References . . . . . . . . . . . . . . . . . . . 18 10.1 Normative References . . . . . . . . . . . . . . . . . . . 19
10.2 Informative References . . . . . . . . . . . . . . . . . . 19 10.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 6, line 51 skipping to change at page 6, line 51
only distributed to the PEs participating in that VPN. only distributed to the PEs participating in that VPN.
For setting up point-to-point security association (i.e., IPsec For setting up point-to-point security association (i.e., IPsec
tunnel) between a pair of EVPN PEs, it is important to leverage BGP tunnel) between a pair of EVPN PEs, it is important to leverage BGP
point-to-multipoint singling architecture using the RR along with its point-to-multipoint singling architecture using the RR along with its
route filtering and constrain mechanisms to achieve the performance route filtering and constrain mechanisms to achieve the performance
and the scale needed for large number of security associations (IPsec and the scale needed for large number of security associations (IPsec
tunnels) along with their frequent re-keying requirements. Using BGP tunnels) along with their frequent re-keying requirements. Using BGP
signaling along with the RR (instead of peer-to-peer protocol such as signaling along with the RR (instead of peer-to-peer protocol such as
IKEv2) reduces number of message exchanges needed for SAs IKEv2) reduces number of message exchanges needed for SAs
establishment and maintenance from O(N^2) to O(N) in the network. be establishment and maintenance from O(N^2) to O(N) in the network.
increased from O(N) to O(N^2).
2 Requirements 2 Requirements
The requirements for secured EVPN are captured in the following The requirements for secured EVPN are captured in the following
subsections. subsections.
2.1 Tenant's Layer-2 and Layer-3 data & control traffic 2.1 Tenant's Layer-2 and Layer-3 data & control traffic
Tenant's layer-2 and layer-3 data and control traffic SHALL be Tenant's layer-2 and layer-3 data and control traffic must be
protected by IPsec cryptographic methods. This implies not only protected by IPsec cryptographic methods. This implies not only
tenant's data traffic SHALL be protected by IPsec but also tenant's tenant's data traffic must be protected by IPsec but also tenant's
control and routing information that are advertised in BGP SHALL also control and routing information that are advertised in BGP must also
be protected by IPsec. This in turn implies that BGP session SHALL be be protected by IPsec. This in turn implies that BGP session must be
protected by IPsec. protected by IPsec.
2.2 Tenant's Unicast & Multicast Data Protection 2.2 Tenant's Unicast & Multicast Data Protection
Tenant's layer-2 and layer-3 unicast traffic SHALL be protected by Tenant's layer-2 and layer-3 unicast traffic must be protected by
IPsec. In addition to that, tenant's layer-2 broadcast, unknown IPsec. In addition to that, tenant's layer-2 broadcast, unknown
unicast, and multicast traffic as well as tenant's layer-3 multicast unicast, and multicast traffic as well as tenant's layer-3 multicast
traffic SHALL be protected by IPsec when ingress replication or traffic must be protected by IPsec when ingress replication or
assisted replication are used. The use of BGP P2MP signaling for assisted replication are used. The use of BGP P2MP signaling for
setting up P2MP SAs in P2MP multicast tunnels is for future study. setting up P2MP SAs in P2MP multicast tunnels is for future study.
2.3 P2MP Signaling for SA setup and Maintenance 2.3 P2MP Signaling for SA setup and Maintenance
BGP P2MP signaling SHALL be used for IPsec SAs setup and maintenance. BGP P2MP signaling must be used for IPsec SAs setup and maintenance.
The BGP signaling SHALL follow P2MP signaling framework per The BGP signaling must follow P2MP signaling framework per
[CONTROLLER-IKE] for IPsec SAs setup and maintenance in order to [CONTROLLER-IKE] for IPsec SAs setup and maintenance in order to
reduce the number of message exchanges from O(N^2) to O(N) among the reduce the number of message exchanges from O(N^2) to O(N) among the
participant PE devices. participant PE devices.
2.3 Granularity of Security Association Tunnels 2.4 Granularity of Security Association Tunnels
The solution SHALL support the setup and maintenance of IPsec SAs at The solution must support the setup and maintenance of IPsec SAs at
the following level of granularities: the following level of granularities:
1) Per pair of PEs: A single IPsec tunnel between a pair of PEs to be 1) Per PE: A single IPsec tunnel between a pair of PEs to be used for
used for all tenants' traffic supported by the pair of PEs. all tenants' traffic supported by the pair of PEs.
2) Per tenant: A single IPsec tunnel per tenant per pair of PEs. For 2) Per tenant: A single IPsec tunnel per tenant per pair of PEs. For
example, if there are 1000 tenants supported on a pair of PEs, then example, if there are 1000 tenants supported on a pair of PEs, then
1000 IPsec tunnels are required between that pair of PEs. 1000 IPsec tunnels are required between that pair of PEs.
3) Per subnet: A single IPsec tunnel per subnet (e.g., per VLAN/EVI) 3) Per subnet: A single IPsec tunnel per subnet (e.g., per VLAN/EVI)
of a tenant on a pair of PEs. of a tenant on a pair of PEs.
4) Per pair of IP addresses: A single IPsec tunnel per pair of IP 4) Per IP address: A single IPsec tunnel per pair of IP addresses of
addresses of a tenant on a pair of PEs. a tenant on a pair of PEs.
5) Per pair of MAC addresses: A single IPsec tunnel per pair of MAC 5) Per MAC address: A single IPsec tunnel per pair of MAC addresses
addresses of a tenant on a pair of PEs. of a tenant on a pair of PEs.
2.4 Support for Policy and DH-Group List 6) Per Attachment Circuit: A single IPsec tunnel per pair of
Attachment Circuits between a pair of PEs.
The solution SHALL support a single policy and DH group for all SAs 2.5 Support for Policy and DH-Group List
as well as supporting multiple policies and DH groups among the SAs.
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.
3 Solution Description 3 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 Route Reflector (RR) and then the RR reflects that send a message to the Route Reflector (RR) and then the RR reflects
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
themselves. The device-to-controller trust model leverages P2MP themselves. The device-to-controller trust model leverages P2MP
signaling via the controller (e.g., the RR) to achieve much better signaling via the controller (e.g., the RR) to achieve much better
scale and performance for establishment and maintenance of large scale and performance for establishment and maintenance of large
number of pairwise Security Associations (SAs) among the PEs. number of pair-wise Security Associations (SAs) among the PEs.
This device-to-controller trust model first secures the control This device-to-controller trust model first secures the control
channel between each device and the controller using peer-to-peer channel between each device and the controller using peer-to-peer
protocol such as IKEv2 [RFC7296] to establish P2P SAs between each PE protocol such as IKEv2 [RFC7296] to establish P2P SAs between each PE
and the RR. It then uses this secured control channel for P2MP and the RR. It then uses this secured control channel for P2MP
signaling in establishment of P2P SAs between a pair of PE devices. signaling in establishment of P2P SAs between each pair of PE
devices.
Each PE advertised to other PEs via the RR the information needed in Each PE advertises to other PEs via the RR the information needed in
establishment of pair-wise SAs between itself an every other remote establishment of pair-wise SAs between itself an every other remote
PEs. These pieces of information are sent as Sub-TLVs of IPSec tunnel PEs. These pieces of information are sent as Sub-TLVs of IPSec tunnel
type in BGP Tunnel Encapsulation attribute. These Sub-TLVs are type in BGP Tunnel Encapsulation attribute. These Sub-TLVs are
detailed in section 5 and they are based on IKEv2 specification detailed in section 5 and are based on the DIM message components
[RFC7296]. The IPsec tunnel TLVs along with its Sub-TLVs are sent from [CONTROLLER-IKE] and the IKEv2 specification [RFC7296]. The
along with the BGP route (NLRI) for a given level of granularity. IPsec tunnel TLVs along with its Sub-TLVs are sent along with the BGP
route (NLRI) for a given level of granularity.
If only a single SA is required per pair of PE devices to multiplex If only a single SA is required per pair of PE devices to multiplex
user traffic for all tenants, then IPsec tunnel TLV is advertised user traffic for all tenants, then IPsec tunnel TLV is advertised
along with IPv4 or IPv6 NLRI representing loopback address of the along with IPv4 or IPv6 NLRI representing loopback address of the
originating PE. It should be noted that this is not a VPN route but originating PE. It should be noted that this is not a VPN route but
rather an IPv4 or IPv6 route. rather an IPv4 or IPv6 route.
If a SA is required per tenant between a pair of PE devices, then If a SA is required per tenant between a pair of PE devices, then
IPsec tunnel TLV can be advertised along with EVPN IMET route IPsec tunnel TLV can be advertised along with EVPN IMET route
representing the tenant or can be advertised along with a new EVPN representing the tenant or can be advertised along with a new EVPN
skipping to change at page 9, line 20 skipping to change at page 9, line 25
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 IP addresses, then IPsec tunnel TLV is advertised along a pair of IP addresses, then IPsec tunnel TLV is advertised along
with EVPN IP Prefix Advertisement Route or EVPN MAC/IP Advertisement with EVPN IP Prefix Advertisement Route or EVPN MAC/IP Advertisement
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 tenant's devices represented by If a SA is required between a pair of Attachment Circuits (ACs) on
a VLAN or a port, then IPsec tunnel TLV is advertised along with EVPN two PE devices (where an AC can be represented by <VLAN, port>), then
Ethernet AD route. IPsec tunnel TLV is advertised along with EVPN Ethernet AD route.
3.1 Distribution of Public Keys and Policies 3.1 Inheritance of Security Policies
Operationally, it is easy to configure a security association between
a pair of PEs using BGP signaling. This is the default security
association that is used for traffic that flows between peers.
However, in the event more finer granularity of security association
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
between a subnet, and a pair of MACs between a subnet using the
appropriate EVPN routes as described above. In the event, there are
no security TLVs associated with an EVPN route, there is a strict
order in the manner security associations are inherited for such a
route. This results in an EVPN route inheriting the security
associations of the parent in a hierarchical fashion. For example,
traffic between an IP pair is protected using security TLVs announced
along with the EVPN IP Prefix Advertisement Route or EVPN MAC/IP
Advertisement route as a first choice. If such TLVs are missing with
the associated route, then one checks to see if the subnets the IPs
are associated with has security TLVs with the EVPN IMET route. If
they are present, those associations are used in securing the
traffic. In the absence of them, the peer security associations are
used. The order in which security associations are inherited are from
the granular to the coarser, namely, IP/MAC associated TLVs with the
EVPN route being the first preference, and the subnet, the tenant,
and the peer associations preferred in that fashion.
It should be noted that when a security association is made it is
possible for it to be re-used by a large number of traffic flows. For
example, a tenant security association may be associated with a
number of child subnet routes. Clearly it is mandatory to keep a
tenant security association alive, if there are one or more subnet
routes that want to use that association. Logically, the security
associations between a pair of entities creates a single secure
tunnel. It is thus possible to classify the incoming traffic in the
most granular sense {IP/MAC, subnet, tenant, peer} to a particular
secure tunnel that falls within its route hierarchy. The policy that
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
classified traffic flows can use a security association, such a
security association will not be torn down, if at least there is one
policy using such a secure tunnel.
3.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.1.1 Minimum Set 3.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 ID, a notification to indicate if this is its initial other PEs, its DIM values as specified in [CONTROLLER-IKE]. These
contact, key exchange including DH public number and DH group, and include:
Nonce. When a single policy is used among all SAs, it is assumed that
this single policy is configured by the management system in all the
PE devices and thus there is no need to signal it. The information
that need to be signaled (using RFC7296 notations) are:
ID, [N(INITIAL_CONTACT),] KE, Ni; where
ID payload is defined in section 3.5 of [RFC7296] ID Tunnel ID
N (Notify) Payload in section 3.10 of [RFC7296] N Nonce
KE (Key Exchange) payload in section 3.4 of [RFC7296] RC Rekey Counter
Ni (Nonce) payload in section 3.9 of [RFC7296] I Indication of initial policy distribution
KE DH public value.
KE payload contains the DH public number and also identifies which DH When this minimal set of DIM values is sent, then it is assumed that
group to use. ID sub-TLV would not be needed in BGP because tunnel all peer PEs share the same policy for which DH group to use, as well
attribute already carries originator ID. Section 5 details these sub- as which IPSec SA policy to employ. Section 5.1 defines the Minimal
TLVs 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.1.2 Single Policy 3.2.2 Multiple Policies
If a single policy needs to be signaled among per tenant or per
subnet among a set of PEs, then in addition to the information
described in section 3.1.1, Security Association sub-TLV needs to be
signaled as well. The payload for this sub-TLV is defined in section
3.3 of [RFC7296] and detailed in section 5.3.
ID, [N(INITIAL_CONTACT),SA, KE, Ni
SA (Security Association) payload in section 3.3 of [RFC7296]
A single SA payload identifies a single IPsec policy. One important
restriction on the SA Payload is that an standard IKE SA payload can
contain multiple transform; however, [CONTROLLER-IKE] restricts the
SA payload to only a single transform for each transform type as
described in section A.3.1 of [CONTROLLER-IKE].
3.1.3 Policy-list & DH-group-list
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 scenairos, 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.
Furthermore, when a device supports more than one DH group, then a 3.2.2.1 Multiple DH-groups
unique DH public number MUST be specified for each in order of
preference. The selection of which DH group to use follows the same
logic as Policy selection, using the receiver's list order until a
match is found in the initiator's list.
In order to support multi-policy a policy list is signaled in It can be the case that not all peers use the same DH group. When
addition to the information described in section 3.1.1. Furthermore, multiple DH groups are supported, the peer may include multiple KE
in order to support multi-DH-groups, a DH group list along with its Sub-TLVs. The order of the KE Sub-TLVs determines the preference.
nonce list are signaled instead of a single DH group and a single The preference and selection methods are specified in Section 6 of
nonce as described in section 3.1.1. [CONTROLLER-IKE].
ID, [N(INITIAL_CONTACT), [SA], [KE], [Ni] 3.2.2.2 Multiple or Single ESP SA policies
[SA] list of IPsec policies (i.e., list of SA payloads) In order to specify an ESP SA Policy, a DIM may include one or more
[KE] list of KE payloads 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
minimizes messaging when group configuration is static and known.
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 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 SA Sub-TLVs determines the preference. The preference and
selection methods are specified in Section 6 of [CONTROLLER-IKE].
3.2 Initial IPsec SAs Generation 3.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 of its intended IPsec SA PEs, it generates a DH pair along for each [what word here?
using an algorithm defined in the IKEv2 Diffie-Hellman Group "tennant"?] using an algorithm defined in the IKEv2 Diffie-Hellman
Transform IDs [IKEv2-IANA]. The originating PE distributes DH public Group Transform IDs [IKEv2-IANA]. The originating PE distributes the
value along with a nonce (using IPsec Tunnel TLV in Tunnel DH public value along with the other values in the DIM (using IPsec
Encapsulation Attribute) to other remote PEs via the RR. Each Tunnel TLV in Tunnel Encapsulation Attribute) to other remote PEs via
receiving PE uses this DH public number and the corresponding nonce the RR. Each receiving PE uses this DH public number and the
in creation of IPsec SA pair to the originating PE - i.e., an corresponding nonce in creation of IPsec SA pair to the originating
outbound SA and an inbound SA. The detail procedures are described in PE - i.e., an outbound SA and an inbound SA. The detail procedures
section 5.2 of [CONTROLLER-IKE]. are described in section 5.2 of [CONTROLLER-IKE].
3.3 Re-Keying 3.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.4 IPsec Databases 3.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 (e.g., 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 4 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
skipping to change at page 12, line 31 skipping to change at page 13, line 10
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 4.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,
the Tunnel Type of Tunnel Encapsulation TLV is set to ESP-Transport for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV is set
and the Tunnel Type of Encapsulation Extended Community is set to NVO to ESP-Transport and the Tunnel Type of Encapsulation Extended
encapsulation type (e.g., VxLAN, GENEVE, GPE, etc.). This implies Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,
that the customer packets are first encapsulated using NVO etc.). This implies that the customer packets are first encapsulated
encapsulation type and then it is further encapsulated & encrypted using NVO encapsulation type and then it is further encapsulated &
using ESP-Transport mode. encrypted using ESP-Transport mode.
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Header | | MAC Header | | MAC Header | | MAC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header | | IP Header | | IP Header | | IP Header |
| Protocol = UDP | | Protocol = ESP | | Protocol = UDP | | Protocol = ESP |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| UDP Header | | ESP Header | | UDP Header | | ESP Header |
skipping to change at page 13, line 47 skipping to change at page 14, line 14
(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
inner UDP header has a destination port ID that identifies NVO inner UDP header has a destination port ID that identifies NVO
encapsulation type (e.g., VxLAN). Optimization of this packet format encapsulation type (e.g., VxLAN). Optimization of this packet format
where only a single UDP header is used (only the outer UDP header) is where only a single UDP header is used (only the outer UDP header) is
for future study. for future study.
When such encapsulation is used, the Tunnel Type of Tunnel When such encapsulation is used, for BGP signaling, the Tunnel Type
Encapsulation TLV is set to ESP-in-UDP-Transport and the Tunnel Type of Tunnel Encapsulation TLV is set to ESP-in-UDP-Transport and the
of Encapsulation Extended Community is set to NVO encapsulation type Tunnel Type of Encapsulation Extended Community is set to NVO
(e.g., VxLAN, GENEVE, GPE, etc.). This implies that the customer encapsulation type (e.g., VxLAN, GENEVE, GPE, etc.). This implies
packets are first encapsulated using NVO encapsulation type and then that the customer packets are first encapsulated using NVO
it is further encapsulated & encrypted using ESP-in-UDP with encapsulation type and then it is further encapsulated & encrypted
Transport mode. using ESP-in-UDP with Transport mode.
[RFC3948] [RFC3948]
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Header | | MAC Header | | MAC Header | | MAC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 | | Eth Type = IPv4/IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header | | IP Header | | IP Header | | IP Header |
| Protocol = UDP | | Protocol = UDP | | Protocol = UDP | | Protocol = UDP |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| UDP Header | | UDP Header | | UDP Header | | UDP Header |
| Dest Port = VxLAN | | Dest Port = 4500(ESP) | | Dest Port = VxLAN | | Dest Port = 4500(ESP) |
skipping to change at page 14, line 47 skipping to change at page 15, line 40
Figure 4: VxLAN Encapsulation within ESP Within UDP Figure 4: VxLAN Encapsulation within ESP Within UDP
5 BGP Encoding 5 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 ESP Notify Sub-TLV 5.1 The Base (Minimal Set) DIM Sub-TLV
This sub-TLV corresponds to Notify payload of IPsec Encapsulation
Security Payload protocol as defined in IKEv2 [RFC7296]. This payload The Base DIM is described in 3.2.1. One and only one Base DIM may be
is defined and described in section 3.10 of [RFC7296]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| Reserved | Payload Length | | ID Length | Nonce Length |I| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rekey |
| Counter |
+---------------------------------------------------------------+
| | | |
~ Security Parameter Index (SPI) ~ ~ Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| | | |
~ Notification Data ~ ~ Nonce Data ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 5: Notify Payload Format Figure 5: The Base DIM Sub-TLV
5.2 ESP Key Exchange Sub-TLV ID Length (16 bits) is the length of the Originator ID + (Tenant ID)
+ (Subnet ID) + (Tenant Address) in bytes.
This sub-TLV corresponds to Key Exchange payload of IPsec Nonce Length (8 bits) is the length of the Nonce Data in bytes
Encapsulation Security Payload protocol as defined in IKEv2
[RFC7296]. This payload is defined and described in section 3.4 of
[RFC7296].
0 1 2 3 I (1 bit) is the initial contact flag from [CONTROLLER-IKE]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| Reserved | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+---------------------------------------------------------------+
Figure 6: Key Exchange Payload Format Flags (7 bits) are reserved and MUST be set to zero on transmit and
ignored on receipt.
5.3 ESP Nonce Sub-TLV The Rekey Counter is a 64 bit rekey counter as specified in
[CONTROLLER-IKE]
This sub-TLV corresponds to Nonce payload of IPsec Encapsulation The Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) is
Security Payload protocol as defined in IKEv2 [RFC7296]. This payload the tunnel identifier and uniquely identifies the tunnel. Depending
is defined and described in section 3.9 of [RFC7296]. 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
is required.
The Nonce Data is the nonce described in [CONTROLLER-IKE]. Its
length is a multiple of 32 bits. Nonce lengths should be chosen to
meet minimum requirements described in IKEv2 [RFC7296].
5.2 Key Exchange Sub-TLV
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| Reserved | Payload Length | | Diffie-Hellman Group Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Nonce Data ~ ~ Key Exchange Data ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 7: Nonce Payload Format Figure 6: Key Exchange Sub-TLV
5.3 ESP Proposals Sub-TLV Diffie-Hellman Group Num 916 bits) identifies the Diffie-Hellman
group in the Key Exchange Data was computed. Diffie-Hellman group
numbers are discussed in IKEv2 [RFC7296] Appendix B and [RFC5114].
This sub-TLV corresponds to Proposal payload of IPsec Encapsulation The Key Exchange payload is constructed by copying one's Diffie-
Security Payload protocol as defined in IKEv2 [RFC7296]. This payload Hellman public value into the "Key Exchange Data" portion of the
is defined and described in section 3.3 of [RFC7296]. payload. The length of the Diffie-Hellman public value is described
for MOPD groups in [RFC7296] and for ECP groups in [RFC4753].
5.3 ESP SA Proposals Sub-TLV
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| Reserved | Payload Length | ||Num Transforms| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Proposals> ~ ~ Transforms ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 8: Security Association Payload Figure 8: ESP SA Proposals Sub-TLV
Proposals (Variable) - one or more proposal substructures Num Transforms is the number of transforms included.
Reserved is not used and MUST be set to zero on transmit and MUST be
ignored on receipt.
5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Substruc | Reserved | Proposal Length | | Transform Attr Length |Transform Type | Reserved. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size | Num Transforms| | Transform ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ SPI (Variable) ~ ~ Transform Attributes ~
| |
+---------------------------------------------------------------+
| |
~ <Transforms> ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 9: Proposal Substructure Figure 9: Transform Substructure Sub-TLV
The Transform Attr Length is the length of the Transform Attributes
field.
The Transform Type is from Section 3.3.2 of [RFC7296] and
[IKEV2IANA]. Only the values ENCR, INTEG, and ESN are allowed.
The Transform ID specifies the transform identification value from
[IKEV2IANA].
Reserved is unused and MUST be zero on transmit and MUST be ignored
on receipt.
The Transform Attributes are taken directly from 3.3.5 of [RFC7296].
6 Applicability to other VPN types 6 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
skipping to change at page 19, line 14 skipping to change at page 20, line 19
Using Ethernet VPN (EVPN)", RFC 8365, March, 2018. Using Ethernet VPN (EVPN)", RFC 8365, March, 2018.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-03, November Attribute", draft-ietf-idr-tunnel-encaps-03, November
2016. 2016.
[CONTROLLER-IKE] Carrel et al., "IPsec Key Exchange using a [CONTROLLER-IKE] Carrel et al., "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-00, July, Controller", draft-carrel-ipsecme-controller-ike-00, July,
2018. 2018.
[IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <http://www.iana.org/assignments/ikev2-
parameters/>.
[RFC3948] Huttunen et al., "UDP Encapsulation of IPsec ESP Packets", [RFC3948] Huttunen et al., "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[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,
 End of changes. 70 change blocks. 
186 lines changed or deleted 243 lines changed or added

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