EVPN First Hop Security
draft-sajassi-bess-evpn-first-hop-security-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ali Sajassi , Lukas Krattiger , krishnaswamy ananthamurthy , Samir Thoria | ||
| Last updated | 2023-03-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sajassi-bess-evpn-first-hop-security-00
BESS Working Group A. Sajassi
Internet-Draft L. Krattiger
Intended status: Standards Track K. Ananthamurthy
Expires: 14 September 2023 S. Thoria
Cisco
13 March 2023
EVPN First Hop Security
draft-sajassi-bess-evpn-first-hop-security-00
Abstract
DHCP Snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings
by snooping on Dynamic Host Configuration Protocol (DHCP) messages.
These bindings are used by security functions like Dynamic ARP
Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source
Guard, and IPv6 Source Guard to safeguard against traffic received
with a spoofed address. These functions are collectively referred to
as First Hop Security (FHS). This document proposes BGP extensions
and new procedures to Ethernet VPN (EVPN) [RFC7432] for distribution
and synchronization of DHCP snoop database to support FHS. Such
synchronization is needed to support EVPN host mobility and multi-
homing.
Requirements Language
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 in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Sajassi, et al. Expires 14 September 2023 [Page 1]
Internet-Draft EVPN First Hop Security March 2023
This Internet-Draft will expire on 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Synchronizing DHCP Snoop Database . . . . . . . . . . . . . . 6
5.1. DHCP Snoop Primer . . . . . . . . . . . . . . . . . . . . 6
5.2. Bridged Service . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. DHCP IP Address Allocation and Lease for Bridged
Service . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. DHCP IP Address Renewal for Bridged Service . . . . . 10
5.3. IRB Service . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. DHCP IP Address Allocation and Lease for IRB
Service . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.2. DHCP IP Address Renewal for IRB Service . . . . . . . 12
6. DHCP Snoop Anchor Mobility . . . . . . . . . . . . . . . . . 12
7. Host Mobility and Age-Out . . . . . . . . . . . . . . . . . . 14
8. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Inter-ES Mobility . . . . . . . . . . . . . . . . . . . . 14
8.2. Intra-ES Synchronization . . . . . . . . . . . . . . . . 15
9. BGP EVPN Message . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Remaining Lease Time Handling . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments for This Document (2022) . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Sajassi, et al. Expires 14 September 2023 [Page 2]
Internet-Draft EVPN First Hop Security March 2023
1. Introduction
DHCP Snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings
by snooping on Dynamic Host Configuration Protocol (DHCP) messages.
These bindings are used by security functions like Dynamic ARP
Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source
Guard, and IPv6 Source Guard to safeguard against traffic received
with a spoofed address. These functions are collectively referred to
as First Hop Security (FHS).
FHS can be leveraged by Ethernet VPN (EVPN) [RFC7432] PEs operating
in bridge mode or in IRB mode (with distributed host gateway
functionality) in DC, Enterprise, and/or Service Provider (SP)
networks to enhances the security for such networks. This document
proposes BGP extensions and new procedures for EVPN to support FHS in
persense of EVPN multi-homing and host mobility by distributing DHCP
Snoop bindings among EVPN PEs participating in that EVPN instnce
(EVI). These bindings not only need to to distributed among multi-
homing PEs to ensure synchronization of these PEs for DHCP messages,
but also need to be distributed among the PEs participating in that
EVPN instance to ensure host mobility procedures can operate
properly. I.e., when a host moves from the current EVPN peer to a
new EVPN peer, then the new EVPN peer shall have the bindings so that
it can continue to do FHS without any interruption.
DAI and NDI uses DHCP Snoop database to validate received ARP
messages and ND messages respectively. Likewise, IPv4 Source Guard
and IPv6 Source Guard use this database to validate source IPv4 and
IPv6 addresses respectively before forwarding traffic. While FHS
running on top of DHCP Snoop database are widely deployed on access
switches (without standard-based multihoming or host mobility), there
is a need to extend the application of FHS on EVPN PEs supporting
Network Virtualization Overlay (NOV) and running multi-homing (All-
Active or Single-Active) with host mobility.
Unfortunately, lack of DHCP snoop binding on EVPN PEs would lead to
failure of FHS (i.e., IP Source Guard, DAI, and NDI) when a host is
multi-homed to multiple PEs (e.g., All-Active or Single-Active) and/
or when a host moves from one PE to antoher PE. This is because when
the host is All-Active multi-homed among multiple PEs, DHCP messages
can arrive on different multihoming PEs without a single PE (in the
multihoming/redundancy group) seeing all of the DHCP exchanges.
Since there is the possibility of none of the PEs in the redundancy
group see the complete DHCP message exchanges, then none of PEs in
the group can establish the DHCP snoop binding which in turn causes
failure of FHS. Furthermore, when a host moves from an old PE to a
new PE, the new PE would not have the DHCP binding for that host.
Since the new PE would not have the DHCP snoop binding, both IP
Sajassi, et al. Expires 14 September 2023 [Page 3]
Internet-Draft EVPN First Hop Security March 2023
Source Guard and DAI/NDI would start dropping packets originated from
that host resulting in FHS failure which in turn results in service
failure.
[RFC7513] proposes procedures that enable adding source address
validation on a device based on DHCP exchanges. Their approach
differs from that of ours in two ways. First, when the host moves
from one PE to another PE, [RFC7513 Section 7.1] offers a solution
that is probabilistic. Our approach offers a deterministic solution
by proactively sending DHCP Snoop update from one PE to another so
that the new PE would have the information that it needs prior to the
host moving to it. Second, [RFC7513 Section 5] identifies the need
to distribute the DHCP Snoop bindings but does not provide a
procedure for distribution. Our approach provides an extension to
EVPN protocol to distribute the DHCP Snoop bindings.
Section 4 ("Requirements") of this document discusses the
requirements for supporting FHS on EVPN PEs. Section 5
("Synchronizing DHCP Snoop Database") discusses xxx.
2. Requirements Language
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 in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN. An EVI may be comprised of one BD
(VLAN-based, VLAN Bundle, or Port-based services) or multiple BDs
(VLAN-aware Bundle or Port-based VLAN-Aware services).
MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE.
Ethernet Segment (ES): When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links, then
that set of links is referred to as an 'Ethernet segment'.
Ethernet Segment Identifier (ESI): A unique non-zero identifier that
identifies an Ethernet segment is called an 'Ethernet Segment
Identifier'.
VID: VLAN Identifier.
Sajassi, et al. Expires 14 September 2023 [Page 4]
Internet-Draft EVPN First Hop Security March 2023
Ethernet Tag: Used to represent a BD that is configured on a given
ES for the purposes of DF election and <EVI, BD> identification
for frames received from the CE. Note that any of the following
may be used to represent a BD: VIDs (including Q-in-Q tags),
configured IDs, VNIs (Virtual Extensible Local Area Network
(VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service
Instance Identifiers), etc., as long as the representation of the
BDs is configured consistently across the multihomed PEs attached
to that ES.
Ethernet Tag ID: Normalized network wide ID that is used to identify
a BD within an EVI and carried in EVPN routes.
PE: Provider Edge device.
DHCP Client: A DHCP client is a host that gets an address assignment
from a DHCP server.
DHCP Server: A server that assigns network addresses to its clients.
DHCP Snoop Anchor: A PE device that originates a DHCP Snoop Route.
It is this device that uses the DHCP Snoop bindings to do source
address validation for hosts that sit behind it.
DF: Designated Forwarder. A DF is a PE device that is selected from
among a group of PE devices that participate in EVPN multihoming.
It is the role of DF PE to forward Broadcast, Unicast, and
Multicast (BUM) Layer 2 messages to the host that is multi-homed
to all the PEs. DF PE is selected on a per-EVI basis.
Backup-DF (BDF): Backup-Designated Forwarder.
Non-DF (NDF): Non-Designated Forwarder.
NVO: Network Virtualization Overlay as decribed in [RFC8365]
IRB: Integrated Routing and Bridging interface, with EVPN procedures
described in [RFC9135]
Single-Active Redundancy Mode: When only a single PE, among all the
PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet segment for a given VLAN, then the Ethernet
segment is defined to be operating in Single-Active redundancy
mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet
Sajassi, et al. Expires 14 September 2023 [Page 5]
Internet-Draft EVPN First Hop Security March 2023
segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode.
4. Requirements
This section lists the requirements xxx.
* xxx
* xxx
5. Synchronizing DHCP Snoop Database
Considering the distributed nature of EVPN application in providing
distributed bridge and distributed host gateway functions over a DC,
Enterprise, or SP network, the synchronization challenges of
providing FHS over such distributed system need to be addressed. The
two main challenges are synchronization of DHCP snoop database (used
in FHS) for both EVPN multi-homing and EVPN host mobility.
The synchronization procedure needed in EVPN to address these two
challenges are dependent on the type of EVPN service being provided -
i.e., bridge service vs. Integrated Routing and Bridging (IRB)
service. Therefore, we organize the synchronization procedures
needed based on the EVPN services in the following subsections.
Before describing the synchronization procedures for different EVPN
services, we first start with a primer on DHCP snooping on a non-
distributed switch where no synchronization is needed.
5.1. DHCP Snoop Primer
DHCP Snooping is based on snooping of DHCP handshake between the host
and the DHCP server [RFC2131]. The sequence of the handshake has
four steps, sometimes known as the DORA exchange (Figure 1).
Sajassi, et al. Expires 14 September 2023 [Page 6]
Internet-Draft EVPN First Hop Security March 2023
---------------------------------------------
| MPLS/VxLAN EVPN |
| |
| |
| 1. Discover |
| -----------------------------> |
| | 2. Offer | |
| | <------------------------- | |
| | | 3. Request | | |
| | | ---------------------> | | |
| | | | 4. Ack | | | |
| | | | <----------------- | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
---------------------------------------------
| SW1 | | SW2 |
--------- ---------
| |
| |
| |
DHCP Client (Host) DHCP Server
Figure 1: DHCP DORA Exchange over EVPN Fabric
1. Discover (DHCPDISCOVER): Initial DHCP message sent by the host
(or the DHCP client) to discover DHCP server(s) in the network.
2. Offer (DHCPOFFER): Once a DHCP server receives the Discover
message, it responds back with an offer of an IP address that can
be assigned to the host. There can be multiple DHCP servers in
the network and hence multiple servers can respond to the
Discover message by sending their own Offer message.
3. Request (DHCPREQUEST): Once the host receives one or more of the
above offers, it sends request to one of the DHCP servers
confirming that it has accepted its offer.
4. Acknowledge (DHCPACK): The last DHCP message is sent by the DHCP
server, for which the Request message was sent to. The message
is sent to indicate the completion of the IP assignment
mechanism.
When we have a host connected to a single switch (e.g., SW1), all of
the DHCP messages pass through the same switch. Thus, the switch
(SW1 in this case) is aware of the entire exchange sequence. Since
SW1 recevies all the DORA messages in proper sequence, it can build
and validate its state for DHCP snoop for that host. If SW1 relies
Sajassi, et al. Expires 14 September 2023 [Page 7]
Internet-Draft EVPN First Hop Security March 2023
on just a single DHCP message (such as DHCPACK that contains all the
needed info) instead of the handshake to build its DHCP snoop state,
then it exposes itself to security risks and hijacking MAC/IP binding
when a rouge DHCPACK is received.
EVPN single-homing is analogus to this scenario where a host is
connected to a single switch. If it wasn't for EVPN host mobility,
then the existing DHCP snoop procedures could be leveraged as is.
However, additional extensions are needed for EVPN host mobility and
EVPN multi-homing as will be described in the following subsections.
5.2. Bridged Service
When EVPN bridged service is used with DHCP snooping, it is assumed
that both DHCP clients and servers reside in the same subnet (same
bridge domain and EVI). If DHCP servers reside in a subnet different
than the one of the DHCP clients, then EVPN IRB service along with
DHCP relay function needs to be deployed which will be described in
Section 5.3
The solution described here addresses both the multi-homing and the
host mobility issues by distributing DHCP Snoop bindings among the
EVPN peers. A new EVPN route is proposed to carry the DHCP Snoop
binding information. The PE where the host is attached sends this
new route when the PE sees completion of DHCP exchange between a DHCP
Client (host) and a DHCP server. We refer to this PE as the DHCP
Snoop Anchor PE. When a remote BGP peer receives the DHCP Snoop
route, it imports it locally and updates its DHCP Snoop Database.
With this information, if the host were to move to a new PE, the new
PE would already have the DHCP Snoop route update from the old PE.
As a result, the DHCP Snoop procedure running on new PE would
successfully validate the host and would immediately start accepting
messages from that host.
Just as in the use-case of FHS application in traditional switches,
we assume that the PE interfaces on which DHCP information is
exchanged with the DHCP server is secure and the DHCP server itself
is not compromised.
As it will be seen later, this synchronization procedure for DHCP
Snoop bindings avoids synchronization of every DHCP message among the
PEs and instead for most part relies on a single PE to receive all
the message exchanges and then after the completion of such exchange,
it will distribute the DHCP Snoop binding to the PEs participating in
that EVPN Instance (EVI).
Sajassi, et al. Expires 14 September 2023 [Page 8]
Internet-Draft EVPN First Hop Security March 2023
The following sections describe the DHCP snoop procedures and
associated synchronization needed for EVPN All-Active multihoming and
host mobility for DHCP initial IP address allocation/lease and IP
address renewal when EVPN PEs participate in a bridged service.
5.2.1. DHCP IP Address Allocation and Lease for Bridged Service
In this section, we describe how an anchor PE for DHCP snoop is
selected among PEs participating in an EVPN multi-homing for a given
EVI. Furthermore, we describe why we dont' need synchronization for
individual DORA messages among these multi-homing PEs for anchor PE
selection but rather we need to synchronize final DHCP snoop state
among the PEs participating in that EVI after verification of DORA
exchange and the anchor PE selection. The synchronization of final
DHCP snoop state is achieved when the anchor PE distributes this
information via a new BGP EVPN route called FHS Route and detailed in
Section 9.
When a DHCP client is multi-homed to two or more PEs on the same
Ethernet Segment operating in All-Active mode, DORA messages can
arrive at different PEs. However, one of the PEs in the multi-homing
redundancy group receives all the DORA messages and thus designates
itself as an anchor PE for DHCP snoop. In case of Single-Active
multi-homing, DORA messages can only arrive at a single PE (in the
redundancy group) which is the active PE for that ESI/EVI and thus
the anchor PE for DHCP snoop.
-------------------------------------------
| MPLS/VxLAN EVPN |
| |
| |
------------------------------------------
| PE1 | | PE2 | | PE3 |
------- ------- -------
| \\ /
| \\ /
| \\ /
| |
DHCP Server DHCP Client
Figure 2: Single-Homed and Multi-Homed hosts.
A DHCP client initiates DORA exchange by sending a DHCPDISCOVER
broadcast message. Because of All-Active multi-homing, this
broadcast message arrives on one of the PEs in the redundancy group
Sajassi, et al. Expires 14 September 2023 [Page 9]
Internet-Draft EVPN First Hop Security March 2023
(e.g., PE2). which forwards it to all the other participating PEs for
that EVI, including PE1 and PE3. Each of the DHCP servers for that
subnet reply with a DHCPOFFER broadcast message. The PE attached to
the DHCP server (e.g., PE1) sends this broadcast messages to all
other PEs in that BD/EVI and thus all the multi-homing PEs for that
DHCP clients (e.g., PE2 and PE3) receive the DHCPOFFER broadcast
message and the DF PE (e.g., PE3) forwards the message to the DHCP
client. The DHCP client responds with a DHCPREQUEST message which is
of type broadcast and gets hashed to PE2 again. PE2 forwards this
broadcast message to all other PEs in that EVI including PE1. PE1
delivers this broadcast message to the DHCP server which responds
with a DHCPACK message. The DHCPACK message is unicast; however,
when PE1 receives this message, it sends it as a BUM message because
it hasn't learned the DHCP client MAC address from PE2. PE2 does not
advertise the MAC address of its attached DHCP client till DHCP snoop
process has been verified and completed. Since DHCPACK is sent as
BUM traffic, both PE2 and PE3 receive this message and PE3 passes it
to the DHCP client.
As it was illustrated in the above example, one of the PEs in the
redundancy group (e.g., PE2) receives all the messages of DORA
exchage and after verification of this exchange, it creates a DHCP
snoop state and designates itself as the DHCP anchor for that client.
Next, the anchor PE sends an EVPN FHS route with the snooped MAC/IP
binding, lease timer and other pertinent information to all PEs in
that EVI, including multi-homing PEs in the same redundancy group.
When multi-homing PEs in the same redundancy group, receive this FHS
message from the anchor PE, they register the DHCP snoop state for
that host sitting behind that ESI. Therefore, from this time
forward, when ARP message (or data traffic) is received from that
host, the host MAC address is learned and advertised in EVPN MAC/IP
RT-2 in the EVPN network and the traffic is forwarded accordingly.
When other PEs in the same EVI, receive this FHS message advertised
by the anchor PE, they also register and synchronize the DHCP snoop
state for that host with that of the anchor PE. This DHCP state will
be used when the host moves from its existing ESI to a new ESI.
5.2.2. DHCP IP Address Renewal for Bridged Service
Sajassi, et al. Expires 14 September 2023 [Page 10]
Internet-Draft EVPN First Hop Security March 2023
5.3. IRB Service
When EVPN IRB service is used with DHCP snooping, if both DHCP
clients and servers reside in the same subnet (same bridge domain and
EVI), then procedure defined in Section 5.2 will apply. If DHCP
servers reside in a subnet different than the one of the DHCP
clients, then EVPN IRB service along with DHCP relay function needs
to be deployed. The solution described here addresses both the
multi-homing and the host mobility issues by distributing DHCP Snoop
bindings among the EVPN peers.
The following sections describe the DHCP snoop procedures and
associated synchronization needed for EVPN All-Active multihoming and
host mobility for DHCP initial IP address allocation/lease and IP
address renewal when EVPN PEs participating in an IRB service.
5.3.1. DHCP IP Address Allocation and Lease for IRB Service
In this section, we describe how anchor PE for DHCP snoop is selected
among PEs participating in an EVPN All-Active multi-homing for a
given EVI. When a DHCP client is multi-homed to two or more PEs on
the same Ethernet Segment operating in All-Active mode, DORA messages
can arrive at different PEs. However, one of the PEs in the multi-
homing redundancy group receives all the DORA messages and thus
designates itself as an anchor PE for DHCP snoop.
A DHCP client initiates DORA exchange by sending a DHCPDISCOVER
broadcast message. Because of All-Active multi-homing, this
broadcast message arrives on one of the PEs in the redundancy group
(e.g., PE2). which forwards it to DHCP server defined in the relay
config. Source IP address used in the relay message will be of
unique IP configured on multihomed PEs, so that when DHCP server
response come to the PE which initiated DHCP relay message.
There could be multiple DHCP relay configured with different servers.
Each of the DHCP servers for that can reply with a DHCPOFFER
broadcast message and will be unicasted to the PE which originated
the relay message, which intern broadcasts on its local interfaces.
The DHCP client responds with a DHCPREQUEST message which is of type
broadcast and gets hashed to PE2 again. PE2 forwards this broadcast
message via DHCP relay. DHCP server sends DHCPACK message to PE2.
PE2 will broadcast this message on its local interfaces.
Sajassi, et al. Expires 14 September 2023 [Page 11]
Internet-Draft EVPN First Hop Security March 2023
As it was illustrated in the above example, one of the PEs in the
redundancy group (e.g., PE2) receives DHCPREQ and DHCPACK. After
verification of this exchange, it creates a DHCP snoop state and
designates itself as the DHCP anchor for that client. Next, the
anchor PE sends an EVPN FHS route with the snooped MAC/IP binding,
lease timer and other pertinent information to all PEs in that EVI
including multi-homing PEs in the same redundancy group.
When multi-homing PEs in the same redundancy group, receive this FHS
message from the anchor PE, they register the DHCP snoop state for
that host sitting behind that ESI. Therefore, from this time
forward, when traffic is received from that host, the host MAC
address is learned and advertised in EVPN MAC/IP RT-2 in the EVPN
network and the traffic is forwarded accordingly.
When other PEs in the same EVI, receive this FHS message advertised
by the anchor PE, they also register and synchronize the DHCP snoop
state for that host with that of the anchor PE. This DHCP state will
be used when the host moves from its existing ESI to a new ESI.
5.3.2. DHCP IP Address Renewal for IRB Service
Client will send DHCP request to renew the lease. Because of All-
Active multi-homing, DHCPREQUEST unicast message arrives on one of
the PEs in the redundancy group (e.g., PE2) which forwards it to DHCP
server defined in the relay config. If PE2 is the anchor PE then
after receiving the DHCPACK, lease time will be updated and FHS
update will be sent with the new lease time. All other PEs including
the multihomed PEs will receive and update the lease time in the
snoop entry that they have created with previous FHS update. If PE2
is not the anchor PE and determines that it has received the snoop
entry from the multihomed PE which is the anchor( e.g., PE3) then it
advertises FHS update and claims itself as anchor.
6. DHCP Snoop Anchor Mobility
When Host moves from Anchor PE, host move will be detected via data
plane or via GARP/RARP. Since DHCP snoop entry was synced via DHCP
Snoop route from Anchor, EVPN mobility procedure will be initiated as
defected in rfc7432. After completion of mobility procedure, anchor
will be moved to the PE where host is moved. In order to identify
the duplicate case, a duplicate-wait-timer with default value of 30
sec will be started. After the expiry of duplicate-wait-timer,
anchor will be moved if MAC/IP in the DHCP snoop route is pointing
local. If not then Anchor will not be moved. Subsequent Host
mobility will again start the duplicate-wait-timer.
Sajassi, et al. Expires 14 September 2023 [Page 12]
Internet-Draft EVPN First Hop Security March 2023
If Anchor is moved from remote local, MAC Mobility extended community
attribute defined rfc7432 will be used for DHCP snoop route. Every
Anchor mobility event for a given DHCP Snoop route will contain a
sequence number that is set using the following rules:
1. A PE advertising given DHCP Snoop route for the first time
advertises it with no MAC Mobility extended community attribute.
2. A PE detecting a locally attached DHCP Snoop route for which it
had previously received a DHCP Snoop route with a different
Ethernet segment identifier advertises the DHCP Snoop route
tagged with a MAC Mobility extended community attribute with a
sequence number one greater than the sequence number in the MAC
Mobility extended community attribute of the received DHCP Snoop
route. In the case of the first mobility event for a given DHCP
Snoop route, where the received DHCP Snoop route does not carry a
MAC Mobility extended community attribute, the value of the
sequence number in the received route is assumed to be 0 for the
purpose of this processing.
3. A PE detecting a locally attached DHCP Snoop route for which it
had previously received a DHCP Snoop route with the same non-zero
Ethernet segment identifier advertises it with:
1. no MAC Mobility extended community attribute, if the received
route did not carry said attribute.
2. a MAC Mobility extended community attribute with the sequence
number equal to the highest of the sequence number(s) in the
received DHCP Snoop route (s), if the received route(s) is
(are) tagged with a MAC Mobility extended community
attribute.
4. A PE detecting a locally attached DHCP Snoop route for which it
had previously received a DHCP Snoop route with the same zero
Ethernet segment identifier (single-homed scenarios) advertises
it with a MAC Mobility extended community attribute with the
sequence number set properly. In the case of single-homed
scenarios, there is no need for ESI comparison. ESI comparison
is done for multihoming in order to prevent false detection of
DHCP Snoop route moves among the PEs attached to the same
multihomed site.
A PE receiving a DHCP Snoop route for a MAC/IP address with a
different Ethernet segment identifier and a higher sequence number
than that which it had previously advertised withdraws its DHCP Snoop
route. If two (or more) PEs advertise the same DHCP Snoop route with
the same sequence number but different Ethernet segment identifiers,
Sajassi, et al. Expires 14 September 2023 [Page 13]
Internet-Draft EVPN First Hop Security March 2023
a PE that receives these routes selects the route advertised by the
PE with the lowest IP address as the best route. If the PE is the
originator of the DHCP Snoop route and it receives the same DHCP
Snoop route with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP. If its own route is not the best one, it
will withdraw the route.
Previous Anchor PE receiving DHCP Snoop route from remote check
whether the MAC/IP is learned remote,If so it will withdraw the local
DHCP Snoop route and will use remote DHCP snoop route. If MAC/IP is
learned locallyThen it will increment the sequence number by 1 than
the received sequence number.
7. Host Mobility and Age-Out
When using DHCP Snoop route, the baseline host mobility procedures in
EVPN is not affected. When host moves from one PE to another and
both PEs have the same EVI, the new PE would already have the remote
DHCP Snoop Entry. As a result, it would accept the incoming ARP/ND
messages. Once it learns the new host, the new PE can continue to
send a new MAC/IP update.
When the host ages out, the PE would withdraw the EVPN MAC/IP
advertisement route without having to bother about the DHCP Snoop
route. If the DHCP Lease expiration timer is running on the PE, then
the PE does not send a withdraw of the DHCP Snoop route. Once the
Lease expires, the PE can withdraw the DHCP Snoop Route as well.
8. Race Conditions
8.1. Inter-ES Mobility
A race-condition can happen when the host moves from one PE device
(say PE1) to another PE device (say PE2). Let us say that as soon as
DHCP request is validated on PE1 and PE1 advertises DHCP Snoop route
to other PE devices, the host moves from PE1 to PE2. Upon move, the
host generates a GARP (Gratuitous ARP) message. It MAY happen that
the GARP message can arrive sooner on PE2 than the DHCP Snoop route.
In other words, PE2 receives the GARP before it has populated its
DHCP binding and thus discards GARP.
We can address the above race-condition by storing an ARP entry
associated with the GARP message along with a flag indicating that we
should keep the entry for T seconds. If DHCP Snoop route arrives
within T, then the flag is removed and ARP entry is made permanent.
Else, we delete the ARP entry after expiration of T seconds.
Sajassi, et al. Expires 14 September 2023 [Page 14]
Internet-Draft EVPN First Hop Security March 2023
8.2. Intra-ES Synchronization
A similar race-condition can occur when we we have multiple PEs
connected to the same Ethernet-Segment. Let us say, upon
successfully getting the DHCP handshake done, the host generates an
ARP message. It MAY happen that the ARP message can reach PE2 that
is different from PE1 that has the Snoop DB binding. However, they
are in the same Ethernet Segment. In other words, PE2 receives the
GARP before it has populated its DHCP binding and thus discards the
ARP.
Once again, we can address the above race-condition by storing an ARP
entry associated with the ARP message along with a flag indicating to
keep it for T seconds. If DHCP Snoop route arrives within T, then
the flag is removed and ARP entry is made permanent. Else, the ARP
entry is deleted after expiration of T seconds.
9. BGP EVPN Message
We propose a new EVPN route type called DHCP Snoop Route with the
following format:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| MAC Address Length (1 octet) |
+---------------------------------------+
| MAC Address (6 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| IP Address (4 or 16 octets) |
+---------------------------------------+
| Remaining Lease Time in sec (4 octets)|
+---------------------------------------+
The RD field carries the Route Distinguisher (RD) associated with the
route. The Ethernet Tag ID identifies a particular broadcast domain,
e.g., a VLAN. An EVPN instance consists of one or more broadcast
domains. The MAC Address and the IP Address fields are the MAC
Sajassi, et al. Expires 14 September 2023 [Page 15]
Internet-Draft EVPN First Hop Security March 2023
address and IP address of the host respectively. The MAC Address
length (in bits) field specifies the length of the host's MAC
address. The IP address Length (in bits) field specifies the length
of the host's IP address. Remaining-Lease-Time is the value of lease
time remaining for the DHCP snoop entry and it is in seconds
For the purpose of BGP route key processing, only the Ethernet Tag
ID, MAC Address Length, MAC Address, IP Address Length, and IP
Address fields are considered to be part of the prefix in the NLRI.
9.1. Remaining Lease Time Handling
Anchor PE originates the DHCP Snoop route when DORA exchange is
completed. When the first time this route is is originated it will
contain the lease time sent by the DHCP server.
After receiving the DHCP Snoop route the PE, a DHCP snoop entry will
be created with lease time as the timeout value received in the
message.
BGP must maintain a create/update timestamp for the local DHCP Snoop
route and while advertising the DHCP Snoop route to its peer, it gets
the current time and subtracts with the create/update time and which
should be subtracted from the received lease timeout value, which
will be sent out in DHCP Snoop route.
When a BGP speaker session is established or route-refresh message is
received or any other event which triggers BGP to send an update,
then it will send the remaining lease time in the same method as
mentioned above.
10. Security Considerations
Security considerations discussed in [RFC7432] and [RFC8365] apply to
this document as well.
11. IANA Considerations
This document defines a new EVPN route type called DHCP Snoop Route
and request the the following registration in the EVPN Route Type
registry:
12 DHCP Snoop Route [this document]
12. References
Sajassi, et al. Expires 14 September 2023 [Page 16]
Internet-Draft EVPN First Hop Security March 2023
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.ietf-bess-evpn-mh-split-horizon]
Rabadan, J., Nagaraj, K., Lin, W., and A. Sajassi, "EVPN
Multi-Homing Extensions for Split Horizon Filtering", Work
in Progress, Internet-Draft, draft-ietf-bess-evpn-mh-
split-horizon-02, 15 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-mh-split-horizon-02>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
Appendix A. Acknowledgments for This Document (2022)
TBD.
Authors' Addresses
Sajassi, et al. Expires 14 September 2023 [Page 17]
Internet-Draft EVPN First Hop Security March 2023
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Lukas Krattiger
Cisco
Email: lkrattig@cisco.com
Krishna Ananthamurthy
Cisco
Email: kriswamy@cisco.com
Samir Thoria
Cisco
Email: sthoria@cisco.com
Sajassi, et al. Expires 14 September 2023 [Page 18]