EVPN First Hop Security

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) 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 presense of EVPN multi-homing and host mobility by distributing DHCP Snoop bindings among EVPN PEs participating in that EVPN instance (EVI). These bindings not only need 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 another 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 Source Guard and DAI/NDI would start dropping packets originated from that host resulting in FHS failure which in turn results in service failure. 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. ("") of this document discusses the requirements for supporting FHS on EVPN PEs. ("") discusses xxx.

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 when, and only when, they appear in all capitals, as shown here.

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.
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.
DHCP Snoop Route (DSR):: EVPN Route to sync DHCP Snoop binding.
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 described in
IRB:: Integrated Routing and Bridging interface, with EVPN procedures described in
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 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.
UTC:: Coordinated Universal Time.
EPOCH:: The epoch is 1st January 1970 at 00:00 UTC.

This section lists the requirements xxx.

DHCP Snoop Database synchronization between multihomed PEs
DHCP Snoop Database synchronization across EVPN PEs

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.

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

| | | 2. Offer | | | | <------------------------- | | | | | 3. Request | | | | | | ---------------------> | | | | | | | 4. Ack | | | | | | | | <----------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --------------------------------------------- | SW1 | | SW2 | --------- --------- | | | | | | DHCP Client (Host) DHCP Server Figure 1: DHCP DORA Exchange over EVPN Fabric ]]>

Discover (DHCPDISCOVER): Initial DHCP message sent by the host (or the DHCP client) to discover DHCP server(s) in the network.
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.
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.
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 receives all the DORA messages in proper sequence, it can build and validate its state for DHCP snoop for that host. If SW1 relies 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 analogous 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.

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

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 don't 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 DSR Route and detailed in . 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.

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 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 exchange 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 DSR 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 DSR 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.

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 which responds with DHCPACK. If PE2 is the anchor PE then after receiving the DHCPACK, lease time will be updated and DSR 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 DSR 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 DSR update and claims itself as anchor.

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

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

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 DSR 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 DSR 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 DSR update and claims itself as anchor.

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

A PE advertising given DHCP Snoop route for the first time advertises it with no MAC Mobility extended community attribute.
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.
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.
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, 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 locally then it will increment the sequence number by 1 than the received sequence number.

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.

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.

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.

We propose a new EVPN route type called DHCP Snoop Route with the following format:

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 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. Create-Time is the value when DHCP entry is created, it also gets updated when DHCP Lease renewal happens. The value is calculated from EPOCH time -1st January 1970 UTC I,e how many seconds elapsed from EPOCH. Lease-Time is the value of lease ime 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.

Anchor PE originates the DHCP Snoop route when DORA exchange is completed. DHCP Snoop DB entry will maintain the create time and lease time. When DHCP Lease renew completed then also create time and and lease time are updated. The Create time will be in seconds. For example the Create time January 1, 2022 12:00:01 A.M will be represented in seconds a 1640995201. All EVPN peers will be expected to synchronize the timestamp using NTP such that Create time will be interpreted correctly. PE router will calculate the lease time as re follows. Lease Time = Received Lease time - (Current time - Create time) There are no lease time calculation in transit BGP EVPN peers like route reflectors.

Security considerations discussed in and apply to this document as well.

This document defines a new EVPN route type called DHCP Snoop Route and request the the following registration in the EVPN Route Type registry: