Internet DRAFT - draft-sajassi-bess-evpn-first-hop-security
draft-sajassi-bess-evpn-first-hop-security
BESS Working Group A. Sajassi
Internet-Draft L. Krattiger
Intended status: Standards Track K. Ananthamurthy
Expires: 25 August 2024 Cisco
J. Rabadan
Nokia
W. Lin
Juniper Networks, Inc.
22 February 2024
EVPN First Hop Security
draft-sajassi-bess-evpn-first-hop-security-02
Abstract
The Dynamic Host Configuration Protocol (DHCP) snoop database stores
valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP
messages. These bindings are used by security functions like Dynamic
Address Resolution Protocol 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 for Ethernet
VPN (EVPN) will distribute and synchronize the 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/.
Sajassi, et al. Expires 25 August 2024 [Page 1]
Internet-Draft EVPN First Hop Security February 2024
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 25 August 2024.
Copyright Notice
Copyright (c) 2024 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. DHCP Snoop Primer . . . . . . . . . . . . . . . . . . . . . . 6
4.1. DHCP Snoop binding entry . . . . . . . . . . . . . . . . 8
5. Synchronizing DHCP Snoop Database . . . . . . . . . . . . . . 8
5.1. DHCP Snoop Anchor PE . . . . . . . . . . . . . . . . . . 9
5.2. DHCP Message Synchronization . . . . . . . . . . . . . . 10
5.3. Bridged Service . . . . . . . . . . . . . . . . . . . . . 10
5.3.1. DHCP IP Address Allocation and Lease for Bridged
Service . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. DHCP IP Address Renewal for Bridged Service . . . . . 12
5.4. IRB Service . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. DHCP IP Address Allocation and Lease for IRB
Service . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.2. DHCP IP Address Renewal for IRB Service . . . . . . . 14
5.5. DSR handling on non-ESI PEs . . . . . . . . . . . . . . . 15
6. DHCP Snoop Anchor Mobility . . . . . . . . . . . . . . . . . 15
7. Host Mobility and Age-Out . . . . . . . . . . . . . . . . . . 17
8. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Inter-ES Mobility . . . . . . . . . . . . . . . . . . . . 17
8.2. Intra-ES Synchronization . . . . . . . . . . . . . . . . 17
9. BGP EVPN DSR Route . . . . . . . . . . . . . . . . . . . . . 18
9.1. Create and Lease Time Handling . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Sajassi, et al. Expires 25 August 2024 [Page 2]
Internet-Draft EVPN First Hop Security February 2024
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 may be leveraged by Ethernet VPN (EVPN) [RFC7432] PEs operating
in bridge mode or in IRB mode (with distributed anycast default
gateway functionality [RFC9135]) in Data Center (DC), Enterprise,
and/or Service Provider (SP) networks to enhance the security of such
networks. This document proposes BGP extensions and new procedures
for EVPN to support FHS in the presence of EVPN multi-homing and host
mobility by distributing DHCP snoop bindings among EVPN PEs
participating in that EVPN Broadcast Domain. These bindings not only
need to be distributed among multi-homing PEs to ensure the
synchronization of these PEs are for DHCP messages but also need to
be distributed among the PEs participating in that EVPN Broadcast
Domain to provide a host mobility procedures can operate adequately.
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 use the DHCP snoop database to validate received ARP
messages and ND messages, respectively. Likewise, IPv4 Source Guard
and IPv6 Source Guard uses 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 multi-homing or host mobility),
there is a need to extend the application of FHS on EVPN PEs
supporting Network Virtualization Overlay (NVO) and running multi-
homing (All-Active or Single-Active) with host mobility.
Unfortunately, the 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
Sajassi, et al. Expires 25 August 2024 [Page 3]
Internet-Draft EVPN First Hop Security February 2024
messages can arrive on different multi-homing PEs without a single PE
(in the multi-homing/redundancy group) seeing DHCP exchanges needed
to build DHCP snoop database as described in Section 5. Since there
is a possibility of none of the PEs in the redundancy group see the
complete DHCP message exchanges needed to build DHCP snoop database,
then none of the 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 does 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 originating 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
probabilistic solution. Our approach provides a deterministic
solution by proactively sending DHCP snoop updates from one PE to
another so that the new PE would have the information it needs before
the host moves 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 offers an extension to EVPN
protocol to distribute the DHCP snoop bindings.
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
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.
ASBR: Autonomous System Boundary Router.
Backup-DF (BDF): Backup-Designated Forwarder.
BD: Broadcast Domain.
DC: Data Center.
Sajassi, et al. Expires 25 August 2024 [Page 4]
Internet-Draft EVPN First Hop Security February 2024
DF: Designated Forwarder. A DF is a PE device that is selected from
among a group of PE devices that participate in EVPN multi-homing.
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.
DHCP: Dynamic Host Configuration Protocol.
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.
DORA : Discover, Offer, Request, Acknowledge.
EPOCH: The epoch is 1st January 1970 at 00:00 UTC.
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'.
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.
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).
Sajassi, et al. Expires 25 August 2024 [Page 5]
Internet-Draft EVPN First Hop Security February 2024
IRB: Integrated Routing and Bridging interface, with EVPN procedures
described in [RFC9135]
MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE.
Non-DF (NDF): Non-Designated Forwarder.
NVO: Network Virtualization Overlay as described in [RFC8365]
PE: Provider Edge device.
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.
SP: Service Provider.
UTC: Coordinated Universal Time.
VID: VLAN Identifier.
4. DHCP Snoop Primer
DHCP basic operation understanding is paramount to understnd the DHCP
snooping operation 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. The handshake
sequence has four steps, sometimes known as the DORA exchange
(Figure 1) which is described in [RFC2131].
Sajassi, et al. Expires 25 August 2024 [Page 6]
Internet-Draft EVPN First Hop Security February 2024
---------------------------------------------
| |
| |
| |
| 1. Discover |
| -----------------------------> |
| | 2. Offer | |
| | <------------------------- | |
| | | 3. Request | | |
| | | ---------------------> | | |
| | | | 4. Ack | | | |
| | | | <----------------- | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
---------------------------------------------
| SW1 | | SW2 |
--------- ---------
| |
| |
| |
DHCP Client (Host) DHCP Server
Figure 1: Typical DHCP DORA Exchange
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 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 a request to one of the DHCP servers
confirming that it has accepted its offer.
4. Acknowledge (DHCPACK): The DHCP server sends the last DHCP
message for which the Request message was sent. The message is
sent to indicate the completion of the IP assignment mechanism.
Sajassi, et al. Expires 25 August 2024 [Page 7]
Internet-Draft EVPN First Hop Security February 2024
4.1. DHCP Snoop binding entry
DHCP snoop binding is created using DHCPREQUEST and DHCPACK messages.
Section 2 of [RFC2131] defines the DHCP message fields and the
following are some of the key fields to understand the exchange of
DHCPREQUEST and DHCPACK messages.
* 'ciaddr': Client IP address; only filled in if client is in BOUND,
RENEW or REBINDING state and can respond to ARP requests.
* 'giaddr': Relay agent IP address, used in booting via a relay
agent.
* 'yiaddr': 'your' (client) IP address.
DHCP client-server interaction is defined in section 3 of [RFC2131],
which are
1. Client-server interaction - allocating a network address.
2. Client-server interaction - reusing a previously allocated
network address
When a host is connected to a single switch (e.g., SW1), both
DHCPREQUEST and DHCPACK messages pass through the same switch. Thus,
the switch (SW1 in this case) 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 both DHCPREQUEST and DHCPACK to build its DHCP snoop state, then
it exposes itself to security risks and hijacking MAC/IP binding when
a rouge DHCPACK is received.
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, and/or SP network, the synchronization challenges of
providing FHS over such a distributed system needs to be addressed.
The two main challenges are the synchronization of the 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.
Sajassi, et al. Expires 25 August 2024 [Page 8]
Internet-Draft EVPN First Hop Security February 2024
EVPN single-homing is analogous to the scenario described in
Section 4, 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 will be
described in the following subsections.
The solution described here addresses both the multi-homing and the
host mobility issues of FHS by distributing DHCP snoop bindings among
the EVPN peers. A new EVPN route is proposed DHCP Snoop Route (DSR)
to carry the DHCP snoop binding information and detailed in
Section 9.
5.1. DHCP Snoop Anchor PE
The PE where the host is attached sees completion of DHCPREQUEST and
DHCPACK exchange between a DHCP Client (host) and a DHCP server, we
refer to this PE as the DHCP Snoop Anchor PE.
--------------------------------------------------------
| EVPN Network |
| |
| |
--------------------------------------------------------
| PE1 | | PE2 | | PE3 | | PE4 |
------- ------- ------- -------
| \\ /
| \\ /
| \\ /
| |
DHCP Server DHCP Client
Figure 2: Single-Homed and Multi-Homed hosts.
DHCP Snoop Anchor PE (e.g., PE2) originates the DSR. When a remote
BGP peer receives the DSR (e.g., PE4), it imports locally and updates
its DHCP Snoop Database. With this information, if the host moved to
a new PE (e.g., PE4), the new PE would already have the DSR update
from the old PE. As a result, the DHCP Snoop procedure running on
the new PE would successfully validate the host and immediately start
accepting that host's messages.
* For initial IP address assignment, both DHCPREQUEST and DHCPACK
needs to be received by the same multi-homing PE in order for that
PE to become DHCP Snoop Anchor PE and to originate DSR
Sajassi, et al. Expires 25 August 2024 [Page 9]
Internet-Draft EVPN First Hop Security February 2024
* For subsequent IP address renewal, ONLY DHCPACK needs to be
received by one of the multi-homing PEs in order for that PE to
become DHCP Snoop Anchor PE and to originate DSR
5.2. DHCP Message Synchronization
The synchronization procedure for DHCP snoop bindings avoid
synchronization of DHCPREQUEST and DHCPACK message among the PEs and
instead for the most part relies on a single PE to receive
DHCPREQUEST and DHCPACK message exchanges for initial IP address
assignment and ONLY DHCPACK for subsequent IP address renewal. After
the completion of such exchange, it will distribute the DHCP snoop
binding to the PEs participating in that EVPN Broadcast Domain.
The following sections describe the DHCP snoop procedures and
associated synchronization needed for EVPN All-Active multi-homing
and host mobility for DHCP initial IP address allocation/lease and IP
address renewal when EVPN PEs participate in a bridged and IRB
service.
5.3. 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
then 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.4.
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.
5.3.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
BD. Furthermore, we explain why we don't need synchronization for
individual DHCPREQUEST and DHCPACK messages among these multi-homing
PEs for anchor PE selection, but rather we need to synchronize the
final DHCP snoop state among the PEs participating in that EVI after
verification of DHCPREQUEST and DHCPACK exchange and the anchor PE
selection. The synchronization of the final DHCP snoop state is
achieved when the anchor PE distributes this information is via DSR.
Sajassi, et al. Expires 25 August 2024 [Page 10]
Internet-Draft EVPN First Hop Security February 2024
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, only one PE in the multi-homing
redundancy group receives both DHCPREQUEST and DHCPACK messages and
thus designates itself as DHCP Snoop Anchor PE. The behavior in the
case of Single-Active multi-homing applies to other multi-homing
modes, such as port-active [I-D.ietf-bess-evpn-mh-pa] or single-flow
active [I-D.ietf-bess-evpn-l2gw-proto] multi-homing, DHCPREQUEST and
DHCPACK messages can only arrive at a single PE in the redundancy
group, which is the active PE for that ESI/EVI, hence and thus the
anchor PE for DHCP snoop.
1. A DHCP client initiates a DORA exchange by sending a DHCPDISCOVER
broadcast message. Because of All-Active multi-homing, this
broadcast message arrives at only one PE in the redundancy group
(e.g., PE2), which forwards it to all the other participating PEs
for that BD, including PE1, PE3 and PE4.
2. Each DHCP server for that subnet replies with a DHCPOFFER, while
DHCPOFFER may be broadcast or unicast in the following cases.
* Broadcast: If DHCPDISCOVER has 'ciaddr' and 'giaddr' set to
ZERO with Broadcast bit option.
* Unicast: If DHCPDISCOVER has 'ciaddr' and 'giaddr' set to ZERO
without the Broadcast bit option, then the client's hardware
address and 'yiaddr' address are used.
Since client MAC is not learned in the EVPN network before the
client obtains the IP address, even if DHCPOFFER is unicast, it
will be sent as an unknown unicast (from PE1's perspective).
Effectively, PE (e.g., PE1) attached to the DHCP server sends
this broadcast/unknown unicast message to all other PEs in that
BD/EVI and thus all the multi-homing PEs for that DHCP client
(e.g., PE2 and PE3) receive the DHCPOFFER broadcast/unknown
unicast message and the DF PE (e.g., PE3) forwards the message to
the DHCP client.
3. The DHCP client responds with a DHCPREQUEST message of type
broadcast and gets hashed to PE2 again. PE2 will create
incomplete DHCP snoop binding entry and forwards this broadcast
message to all other PEs in that BD, including PE1. PE1 delivers
this broadcast message to the DHCP server.
4. DHCP server responds with DHCPACK. Since 'ciaddr' and 'giaddr'
are ZERO during initial setup, the client does not yet have the
'yiaddr' address. DHCPACK will be sent as broadcast PE (e.g.,
PE1) attached to the DHCP server sends this broadcast message to
Sajassi, et al. Expires 25 August 2024 [Page 11]
Internet-Draft EVPN First Hop Security February 2024
all other PEs in that BD/EVI and thus all the multi-homing PEs
for that DHCP client (e.g., PE2 and PE3) receive the DHCPACK
broadcast message and the DF PE (e.g., PE3) forwards the message
to the DHCP client. PE2 received the DHCPREQUEST earlier on its
local attachment circuit, and with DHCPACK, it creates the
complete DHCP snoop binding, claims the Anchor, and originates
the DSR.
As the above example illustrates, only one PE in the redundancy group
(e.g., PE2) receives DHCPREQUEST on its local attachment circuit and
DHCPACK messages. 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 with the snooped MAC/
IP binding, lease time, and other pertinent information to all PEs in
that BD, 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/ND message (or data traffic) is received from that
host, the host MAC address is learned and advertised in EVPN MAC/IP
RT-2 is in the EVPN network and the traffic is forwarded accordingly.
5.3.2. DHCP IP Address Renewal for Bridged Service
A DHCP client will send DHCPREQUEST to renew the lease, which can be
unicast or broadcast. Client will set 'yiaddr' address as it already
knows the address. If DHCPREQUEST is a broadcast message then the
procedure defined in Section 5.3.1 will apply. If DHCPREQUEST is a
unicast, because of All-Active multi-homing, DHCPREQUEST unicast
message arrives at only one of the PEs in the redundancy group (e.g.,
PE2), which forwards it to DHCP server.
DHCP server responds with DHCPACK. Since Client had set 'yiaddr'
address in DHCPREQUEST, DHCPACK will be a unicast and either PE2 or
PE3 will receive the DHCPACK.
* If PE2 receives the DHCPACK which is the anchor PE then, 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 the previous DSR update.
* If PE3 receives the DHCPACK which is not the anchor PE and
determines that it has received the snoop entry from the
multihomed PE ( e.g., PE2), which is the anchor then it claims
itself as an anchor and advertises DSR updates with a MAC Mobility
extended community attribute with a sequence number one greater
Sajassi, et al. Expires 25 August 2024 [Page 12]
Internet-Draft EVPN First Hop Security February 2024
than the sequence number in the MAC Mobility extended community
attribute of the received DSR. Suppose the snoop entry does not
have the MAC Mobility extended community attribute; the value of
the sequence number in the received DSR is assumed to be 0 for the
purpose of this processing.
* PE2, which is the previous anchor, receives DSR with a higher
sequence number from its ESI peer PE3, determines that ESI peer
has claimed the anchor and withdraws the previously advertised
DSR. Note that when MAC/IP routes are received from the same ESI,
no mobility event is triggered irrespective of the sequence
number. But for MAC/IP routes, the ES peer will not withdraw its
own MAC/IP route, so the case for the DSR is different indeed.
5.4. 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 the procedure defined in Section 5.3 will apply. If DHCP
servers reside in a subnet different than one of the DHCP clients,
then EVPN IRB service and DHCP relay function MUST be deployed. The
solution described here addresses the multi-homing and host mobility
issues by distributing DHCP snoop bindings among the EVPN peers.
5.4.1. DHCP IP Address Allocation and Lease for IRB Service
A DHCP client initiates a DORA exchange by sending a DHCPDISCOVER
broadcast message. Because of All-Active multi-homing, this
broadcast message arrives at only one PE in the redundancy group
(e.g., PE2), which forwards it to the DHCP server defined in the
relay config. The source IP address used in the relay message will
be a unique IP configured on multihomed PEs such that the DHCP server
response comes to the PE, which initiates the DHCP relay message.
There could be multiple DHCP relays configured with different
servers. Each DHCP server can reply with a DHCPOFFER broadcast
message and will be unicasted to the PE, which originated the
DHCPDISCOVER relay message, which broadcasts on its local interfaces.
The DHCP client responds with a DHCPREQUEST message of type broadcast
and gets hashed to PE2 again. PE2 will create an incomplete DHCP
snoop binding entry and forward this broadcast message via the DHCP
relay.
DHCP server responds with a DHCPACK message, which will be unicasted
to the PE (e.g., PE2), which originated the DHCPREQUEST relay
message. PE will broadcast this message on its local interfaces.
Sajassi, et al. Expires 25 August 2024 [Page 13]
Internet-Draft EVPN First Hop Security February 2024
As the above example illustrates, only one PE in the redundancy group
(e.g., PE2) receives DHCPREQUEST on its local attachment circuit and
DHCPACK messages. 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 with the snooped MAC/
IP binding, lease time, and other pertinent information to all PEs in
that BD, 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 an ARP/ND 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.
5.4.2. DHCP IP Address Renewal for IRB Service
A DHCP client will send a DHCPREQUEST to renew the lease. Because of
All-Active multi-homing, the DHCPREQUEST unicast message arrives at
only one of the PEs in the redundancy group, which forwards it to the
DHCP server defined in the relay config.
Suppose DHCPREQUEST arrives on PE2, which forwards it to the DHCP
server defined in the relay config. If PE2 is the anchor PE, then
after receiving the DHCPACK, the DHCP snoop entry lease time will be
updated, and a 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 created with the previous DSR update.
Suppose DHCPREQUEST arrives on PE3, which forwards it to the DHCP
server defined in the relay config. If PE3 is not the anchor PE,
then after receiving the DHCPACK, it determines that it has received
the snoop entry from the multihomed PE, which is the anchor ( e.g.,
PE2), then it claims itself as an anchor.
* DHCP snoop entry lease time will be updated.
* DSR update will be sent with the new lease time 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 DSR. Suppose the snoop entry
does not have the MAC Mobility extended community attribute; the
value of the sequence number in the received DSR is assumed to be
0 for the purpose of this processing.
Sajassi, et al. Expires 25 August 2024 [Page 14]
Internet-Draft EVPN First Hop Security February 2024
* PE2, the previous anchor, receives DSR with a higher sequence
number from its multihomed PE3, determines that multihomed PE3 has
claimed the anchor, and withdraws the previously advertised DSR.
Note that no mobility event is triggered when MAC/IP routes are
received from the same ESI, irrespective of the sequence number.
But for MAC/IP routes, the ES peer will not withdraw its own MAC/
IP route, so the case for the DSR route is different indeed.
* All other PEs will receive and update the lease time in the snoop
entry that they have created with the previous DSR update.
5.5. DSR handling on non-ESI PEs
When other PEs ( e.g., PE4) in the same BD 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.
Contrary to EVPN MAC/IP Advertisement Routes (RT-2), EVPN DSR (RT-x)
does not need to use EVPN Ethernet AD per ES Route (RT-1) for route
resolution as described in section 9.2.2 of
[I-D.ietf-bess-rfc7432bis] because DSR is only used for DHCP snoop
state and not traffic forwarding. It is better to maintain the last
state of DHCP snoop for a given MAC/IP binding than to have no state
at all. Furthermore, there is no impact on traffic forwarding in the
case of DSR, whereas if route resolution based on RT-1 is not
performed for RT-2, traffic destined to that MAC can be blackholed
till it is learned again at the remote PEs.
6. DHCP Snoop Anchor Mobility
The host move will be detected via the data plane or GARP/RARP when
the host moves from Anchor PE to remote PE. Since DHCP snoop entry
was synced via the DSR from Anchor on remote PE, the EVPN mobility
procedure will be initiated as defined in [RFC7432]. After
completion of the mobility procedure, the anchor will be moved to the
remote PE, where the host is moved. A duplicate-wait-timer with a
default value of 30 sec will be started to identify the duplicate
case. After the duplicate-wait-timer expires, the anchor will be
moved if MAC/IP in the DSR is learned locally. If not, then Anchor
will not be moved. Subsequent Host mobility will again start the
duplicate-wait-timer.
If Anchor is moved from a remote location to a local one, the MAC
Mobility extended community attribute defined [RFC7432] will be used
for the DSR. Every Anchor mobility event for a given DSR will
contain a sequence number that is set using the following rules:
Sajassi, et al. Expires 25 August 2024 [Page 15]
Internet-Draft EVPN First Hop Security February 2024
1. A PE advertising given DSR for the first time advertises it with
no MAC Mobility extended community attribute.
2. A PE detecting a locally attached DSR for which it had previously
received a DSR with a different Ethernet segment identifier
advertises the DSR 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 DSR. In the case of the first mobility event for a
given DSR, where the received DSR does not carry a MAC Mobility
extended community attribute, the value of the sequence number in
the received DSR is assumed to be 0 for the purpose of this
processing.
3. A PE detecting a locally attached DSR for which it had previously
received a DSR with the same non-zero Ethernet segment identifier
advertises it with the following:
* No MAC Mobility extended community attribute if the received
DSR did not carry said attribute.
* 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 DSR for which it had previously
received a DSR with the same zero Ethernet segment identifier
(single-homed scenarios) advertises it with a MAC Mobility
extended community attribute with the sequence number
appropriately set. In the case of single-homed scenarios, there
is no need for an ESI comparison. ESI comparison is made for
multi-homing to prevent false detection of DSR moves among the
PEs attached to the same multihomed site.
A PE receiving a DSR 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 DSR. If two (or more) PEs
advertise the same DSR 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, which is
the best route. If the PE is the originator of the DSR and it
receives the same DSR with the same sequence number that it
generated, it will compare its IP address with the IP address of the
remote PE and will select the lowest IP. If its route is not the
best one, it will withdraw the route.
Sajassi, et al. Expires 25 August 2024 [Page 16]
Internet-Draft EVPN First Hop Security February 2024
Previous Anchor PE receiving DSR from remote check whether the MAC/IP
is learned remotely; if so, it will withdraw the local DSR and use
the remote DSR. If MAC/IP is learned locally, then it will increment
the sequence number by ONE, then the received sequence number.
7. Host Mobility and Age-Out
When using the DSR, the baseline host mobility procedures in EVPN are
not affected. When the host moves from one PE to another and both
PEs have the same BD, 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 send a new
MAC/IP update.
When the host ages out, the PE would withdraw the EVPN MAC/IP
advertisement route without bothering about the DSR. If the DHCP
Lease expiration timer is running on the PE, then the PE does not
send a withdrawal of the DSR. Once the Lease expires, the PE can
withdraw the DSR 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
DHCPREQUEST is validated on PE1 and PE1 advertises the DSR to other
PE devices. The host moves from PE1 to PE2. Upon moving, the host
generates a GARP (Gratuitous ARP) message. The GARP message MAY
arrive sooner on PE2 than the DSR. 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 and a flag indicating that we should
keep the entry for T seconds. If DSR arrives within T, then the flag
is removed and ARP entry is made permanent. Otherwise, we delete the
ARP entry after the expiration of T seconds. In other words, the ARP
entry is created, but it stays inactive until the DSR arrives and
activates the ARP entry.
8.2. Intra-ES Synchronization
A similar race-condition can occur when multiple PEs are connected to
the same Ethernet-Segment. Let us say, that upon successfully
getting the DHCP handshake done, the host generates an ARP message.
The ARP message MAY reach PE2, which is different from PE1, which has
the Snoop DB binding. However, they are in the same Ethernet
Segment. In other words, PE2 receives the GARP before it has
Sajassi, et al. Expires 25 August 2024 [Page 17]
Internet-Draft EVPN First Hop Security February 2024
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 and a flag indicating that it
will be kept for T seconds. If DSR arrives within T, the flag is
removed and ARP entry is made permanent. Otherwise, the ARP entry is
deleted after the expiration of T seconds.
9. BGP EVPN DSR Route
The BGP EVPN NLRI as defined in [RFC7432] is shown below:
+-----------------------------------+
| Route Type (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
Figure 3: BGP EVPN NLRI
We propose a new EVPN route type called DHCP Snoop Route with the
following format:
Sajassi, et al. Expires 25 August 2024 [Page 18]
Internet-Draft EVPN First Hop Security February 2024
+---------------------------------------+
| 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) |
+---------------------------------------+
| Create Lease Time in sec (8 octets) |
+---------------------------------------+
| Lease Time in sec (4 octets) |
+---------------------------------------+
Figure 4: EVPN DSR Route
* The Route Distinguisher (RD) and Ethernet Tag ID MUST be used as
defined in [RFC7432] and [RFC8365]. In particular, the RD is
unique per MAC-VRF.
* Ethernet Segment Identifier (ESI) is a unique non-zero identifier
that identifies an Ethernet segment. The ESI format is described
in [RFC7432].
* 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 host's MAC address length. The IP
address Length (in bits) field specifies the host's IP address
length.
* 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 time remaining for the DHCP snoop
entry in seconds.
Sajassi, et al. Expires 25 August 2024 [Page 19]
Internet-Draft EVPN First Hop Security February 2024
* 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.
* The BGP advertisement for the DSR MUST also carry the Route Target
(RT) associated with the BD.
9.1. Create and Lease Time Handling
Anchor PE originates the DSR when the DORA exchange is complete.
DHCP Snoop DB entry will maintain the create time and lease time.
When DHCP lease renewal is complete, the create time and lease time
are updated. The Create time will be in seconds. For example, the
Create time on 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.
The PE router will calculate the lease time as follows.
Lease Time = Received Lease time - (Current time - Create time)
There are no lease time calculations in transit BGP EVPN peers like
route reflectors of ASBRs.
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 following registration in the EVPN Route Type
registry:
Value : 12
Description: DHCP Snoop Route
12. References
12.1. Normative References
Sajassi, et al. Expires 25 August 2024 [Page 20]
Internet-Draft EVPN First Hop Security February 2024
[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>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[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-l2gw-proto]
Brissette, P., Sajassi, A., Burdet, L. A., and D. Voyer,
"EVPN Multi-Homing Mechanism for Layer-2 Gateway
Protocols", Work in Progress, Internet-Draft, draft-ietf-
bess-evpn-l2gw-proto-04, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-l2gw-proto-04>.
[I-D.ietf-bess-evpn-mh-pa]
Brissette, P., Burdet, L. A., Wen, B., Leyton, E., and J.
Rabadan, "EVPN Port-Active Redundancy Mode", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-mh-pa-09,
18 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bess-evpn-mh-pa-09>.
[I-D.ietf-bess-rfc7432bis]
Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan,
"BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-
Draft, draft-ietf-bess-rfc7432bis-08, 13 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
rfc7432bis-08>.
Sajassi, et al. Expires 25 August 2024 [Page 21]
Internet-Draft EVPN First Hop Security February 2024
[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>.
Contributors
In addition to the authors listed on the front page, the following
coauthors have also contributed to this document:
Samir Thoria
Authors' Addresses
Ali Sajassi
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
Lukas Krattiger
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: lkrattig@cisco.com
Krishnaswamy Ananthamurthy
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: kriswamy@cisco.com
Sajassi, et al. Expires 25 August 2024 [Page 22]
Internet-Draft EVPN First Hop Security February 2024
Jorge Rabadan
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Wen Lin
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States of America
Email: wlin@juniper.net
Sajassi, et al. Expires 25 August 2024 [Page 23]
