Network Working Group S. Dikshit Internet-Draft HPE Intended status: Standards Track 26 July 2026 Expires: 26 January 2027 Scoped Sync for EVPN First-Hop-Security DHCP Snoop Routes draft-dikshit-bess-evpn-fhs-scoped-sync-00 Abstract [I-D.ietf-bess-evpn-first-hop-security] defines a new EVPN Route Type, the DHCP Snoop Route (DSR), to synchronize DHCP snoop MAC/IP bindings across EVPN Provider Edge (PE) devices so that First Hop Security (FHS) functions such as Dynamic ARP Inspection, Neighbor Discovery Inspection, and IPv4/IPv6 Source Guard continue to operate correctly across EVPN multihoming and host mobility events. As specified, a DSR is distributed to every PE participating in the EVPN Broadcast Domain (BD) in which it was learned. In deployments where a single EVPN BD spans many geographically or administratively distinct fabrics interconnected over a WAN, this "flood to the whole BD" behavior distributes client IP/MAC binding information -- and therefore knowledge of which hosts exist behind which access switches -- well beyond the set of fabrics that actually need it for FHS purposes. This document defines a Sync-Scope Extended Community that an originating PE MAY attach to a DSR to restrict its distribution to an explicitly identified subset of participating fabrics, and specifies the associated PE processing rules. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 January 2027. Copyright Notice Copyright (c) 2026 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 2. Requirements Language 3. Problem: Unscoped DSR Flooding Across Disparate Fabrics 4. Sync-Scope Extended Community 4.1. Encoding 4.2. Originating PE Behavior 4.3. Receiving PE Behavior 4.4. Interoperation with PEs Not Supporting This Extension 5. Relationship to draft-saumthimma-evpn-ip-binding-sync 6. Security Considerations 7. IANA Considerations 8. Acknowledgements 9. References 9.1. Normative References 9.2. Informative References Author's Address 1. Introduction [I-D.ietf-bess-evpn-first-hop-security] (hereafter "the FHS document") introduces the DHCP Snoop Route (DSR), an EVPN route type used to synchronize DHCP-snoop-derived MAC/IP bindings among the PEs of an EVPN Broadcast Domain (BD), so that First Hop Security (FHS) functions keep working correctly when a client is EVPN-multihomed or moves between PEs. The DSR, once originated by a "DHCP Snoop Anchor PE", is distributed to every PE participating in that BD, including PEs that are not part of the originating client's multihoming redundancy group. This unconditional, BD-wide distribution is appropriate when a BD is confined to a single fabric or a small, trusted set of fabrics. It becomes a scaling and information-exposure concern when a single EVPN BD (or a stitched/interconnected set of EVPN domains sharing the same tenant addressing) spans a large number of geographically or administratively distinct fabrics connected over a WAN -- for example, many branch or campus fabrics of a single enterprise, each locally operated, connected back to a small number of hub/DC fabrics. In such topologies, most remote fabrics have no operational need to learn the DHCP snoop bindings of clients attached to a fabric they will never forward traffic for directly, yet the base FHS mechanism distributes that binding information to all of them regardless. [I-D.saumthimma-evpn-ip-binding-sync] identifies this same class of problem for client IP-binding synchronization carried alongside EVPN MAC/IP Advertisement (Route Type 2) routes, and defines a "Client IP Binding Sync ID" to scope distribution of that information to an explicitly configured set of fabrics. This document adapts the same scoping concept to the DSR route type defined by the FHS document, so that deployments adopting DSR-based FHS synchronization have the same control over the blast radius of binding-information distribution. 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. Problem: Unscoped DSR Flooding Across Disparate Fabrics Consider a DSR originated by a DHCP Snoop Anchor PE attached to fabric A. Per the FHS document, this DSR is imported by every PE in the same BD, including PEs in fabrics B, C, D, ... that may be geographically remote, operated by a different team, or connected only for the purpose of reaching a shared set of centralized services (e.g. a hub-and-spoke campus/branch design). None of those remote fabrics perform DAI/NDI/Source Guard for a host that will never egress through them, so the DSR they receive and retain is pure overhead -- and in some regulatory or multi-tenant contexts, undesirable exposure of client presence/binding information to fabrics outside the client's operational domain. This mirrors exactly the "Unwarranted and Insecure Information Leak" concern raised in [I-D.saumthimma-evpn-ip-binding-sync] for the RT-2-carried binding case, and the same style of solution -- an explicit, operator-configured scope identifier carried with the synchronization route -- applies here. 4. Sync-Scope Extended Community 4.1. Encoding This document defines a new BGP transitive extended community, the "DSR Sync-Scope Extended Community", of type and sub-type to be assigned by IANA from the "EVPN Extended Community Sub-Types" registry defined by [RFC7153]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type=TBD1 | Sync-Scope ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: DSR Sync-Scope Extended Community Sync-Scope ID is a 16-bit, operator-assigned identifier. PEs that are intended to receive a given set of DSRs are provisioned with the same Sync-Scope ID(s) for the relevant BD; PEs outside the intended scope are not provisioned with that ID. A Sync-Scope ID of 0 is reserved and MUST NOT be used to mean "all PEs" -- absence of the extended community already means unscoped (BD-wide) distribution, preserving compatibility with the base FHS document. 4.2. Originating PE Behavior A DHCP Snoop Anchor PE configured with a Sync-Scope ID for a given BD (or for a given ESI/EVI within that BD) MUST attach the DSR Sync-Scope Extended Community carrying that ID to every DSR it originates for hosts within that scope. A PE MAY be configured with more than one Sync-Scope ID if it anchors DSRs for multiple independently-scoped groups of fabrics within the same BD, in which case the appropriate ID is selected per DSR based on local policy (e.g. per-ESI or per-subnet configuration). 4.3. Receiving PE Behavior A PE that supports this extension and receives a DSR carrying a DSR Sync-Scope Extended Community: * MUST import and act on the DSR (i.e. install/refresh the DHCP snoop binding) only if the PE is locally configured with a matching Sync-Scope ID for that BD. * MUST otherwise treat the route as not applicable to local FHS state -- it MAY still be retained in the BGP RIB for re-advertisement to other iBGP peers (e.g. on a route reflector), but MUST NOT be used to populate local DHCP snoop state. * A route reflector or ASBR that does not itself perform FHS functions MUST reflect/propagate the route unmodified, regardless of its own Sync-Scope configuration (it has none), consistent with the FHS document's treatment of transit BGP EVPN peers. 4.4. Interoperation with PEs Not Supporting This Extension A PE that does not support this extension and receives a DSR carrying the Sync-Scope Extended Community MUST ignore the extended community (standard BGP extended-community handling) and process the DSR exactly as specified in the base FHS document -- i.e. unscoped behavior for that PE. Deployments that require the information-exposure benefit of scoping MUST therefore ensure all PEs in the BD that should NOT receive out-of-scope bindings support this extension; partial deployment provides scoping benefit only among the subset of PEs that support it. 5. Relationship to draft-saumthimma-evpn-ip-binding-sync [I-D.saumthimma-evpn-ip-binding-sync] defines an analogous "Client IP Binding Sync ID" concept carried with EVPN MAC/IP Advertisement (Route Type 2) routes, for deployments that synchronize client IP-binding state to a generic security application rather than specifically to a DHCP-snoop-based FHS pipeline. This document intentionally reuses the same "scope ID restricts distribution to a configured subset of PEs" model, applied instead to the DSR route type defined by the FHS document. Operators using both mechanisms in the same network SHOULD, where practical, align Sync-Scope ID and Client IP Binding Sync ID values that represent the same operational grouping of fabrics, though this document does not require the two identifier spaces to be numerically unified. 6. Security Considerations The Sync-Scope Extended Community does not change the trust model of BGP EVPN: it relies on the same iBGP/eBGP session security (e.g. TCP-AO, MD5, or transport security per [RFC7454]) as any other EVPN route. A misconfigured or malicious PE that emits a Sync-Scope ID it is not authorized to use could cause a receiving PE to install FHS state it should not have; this risk exists already for the unscoped case in the base FHS document, and is not increased in kind by this extension, only in the granularity at which misconfiguration could occur. Operators SHOULD provision Sync-Scope IDs consistently with route-target and import-policy configuration to avoid unintended cross-fabric leakage, and MAY use BGP import policy to hard-filter DSRs carrying unexpected Sync-Scope IDs at fabric boundaries as defense in depth. 7. IANA Considerations IANA is requested to allocate a new sub-type, TBD1, from the "EVPN Extended Community Sub-Types" registry defined by [RFC7153], for the "DSR Sync-Scope Extended Community" defined in Section 4.1 of this document. 8. Acknowledgements The Sync-Scope concept builds directly on the "Client IP Binding Sync ID" mechanism defined in [I-D.saumthimma-evpn-ip-binding-sync], co-authored with Thimma Reddy Gadekal. The author thanks the authors of [I-D.ietf-bess-evpn-first-hop-security] for the DSR mechanism this document extends. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, March 2014. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [I-D.ietf-bess-evpn-first-hop-security] Sajassi, A., Krattiger, L., Ananthamurthy, K., Rabadan, J., and W. Lin, "EVPN First Hop Security", Work in Progress, draft-ietf-bess-evpn-first-hop-security-01, 22 July 2026. 9.2. Informative References [I-D.saumthimma-evpn-ip-binding-sync] Dikshit, S. and T. Gadekal Reddy, "Client IP Binding Sync for EVPN", Work in Progress, draft-saumthimma-evpn-ip-binding-sync-09, July 2026. [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, February 2015. Author's Address Saumya Dikshit HPE Email: saumya.dikshit@hpe.com