Scoped Sync for EVPN First-Hop-Security DHCP Snoop Routes
draft-dikshit-bess-evpn-fhs-scoped-sync-01

Network Working Group                                         S. Dikshit
Internet-Draft                                                       HPE
Intended status: Standards Track                            27 July 2026
Expires: 27 January 2027

       Scoped Sync for EVPN First-Hop-Security DHCP Snoop Routes
               draft-dikshit-bess-evpn-fhs-scoped-sync-01

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 27 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-10, 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