| Internet-Draft | EVPN First Hop Security | March 2023 |
| Sajassi, et al. | Expires 14 September 2023 | [Page] |
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.¶
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.¶
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."¶
This Internet-Draft will expire on 14 September 2023.¶
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.¶
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 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.¶
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.¶
This section lists the requirements xxx.¶
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).¶
---------------------------------------------
| 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
¶
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 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.¶
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).¶
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 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 (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.¶
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.¶
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 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.¶
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.¶
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 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:¶
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 locallyThen 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:¶
+---------------------------------------+
| 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 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.¶
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.¶
Security considerations discussed in [RFC7432] and [RFC8365] 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:¶
12 DHCP Snoop Route [this document]
¶
TBD.¶