Network Working Group S. Dikshit
Internet-Draft T.R. Gadekal
Intended status: Standards Track Aruba Networks, HPE
Expires: 26 January 2027 26 July 2026
Secure IP Binding Synchronization via BGP EVPN
draft-saumthimma-evpn-ip-binding-sync-10
Abstract
The distribution of clients of L2 domain across extended networks
leveraging overlay fabric needs to deal with synchronizing the
Client Binding Database. The 'Client IP Binding' indicates the IP,
MAC and VLAN details of the clients that are learnt by security
protocols. Since learning the 'Client IP Binding database' is a
last mile solution, this information stays local to the end point
switch to which clients are connected. When networks are extended
across geographies, both at layer 2 and layer 3, the 'Client IP
Binding Database' in end point switches of remote fabrics should be
in sync. This document aligns the synchronization of the 'Client
IP Binding Database' through an extension to BGP control plane
constructs, as BGP is a typical control plane protocol configured
to communicate across network boundaries.
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."
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. Important Terms
2. Introduction
3. Requirements Language
4. Problem Description
4.1. Broadcast Over WAN
4.2. Same Subnet across fabrics over different Vlans
4.3. Unwarranted and Insecure Information leak
5. Security of Fast Roaming Clients
6. Solution(s)
6.1. Client IP Binding Sync Extended Communities
6.1.1. Processing of Client IP Binding
7. Backward Compatibility
8. Security Considerations
9. IANA Considerations
10. Acknowledgements
11. References
11.1. Normative References
11.2. Informative References
Authors' Addresses
1. Important Terms
BGP: Border Gateway Protocol
VTEP: Virtual Tunnel End Point or Vxlan Tunnel End Point
RD: Route Distinguisher
RT: Route Target
NLRI: Network Layer Reachability Information
EVPN: Ethernet Virtual Private Network
2. Introduction
The distribution of clients of L2 domain across extended networks
leveraging overlay fabric needs to deal with synchronizing the
Client Binding Database. The 'Client IP Binding' indicates the IP,
MAC and VLAN details of the clients that are learnt by security
protocols. Since learning 'Client IP Binding database' is a last
mile solution, this information stays local to the end point switch
to which clients are connected. When networks are extended across
geographies, both layer 2 and layer 3, the 'Client IP Binding
Database' in end point switches of remote fabrics should be in
sync. This document aligns the synchronization of the 'Client IP
Binding Database' through an extension to BGP control plane
constructs, as BGP is a typical control plane protocol configured
to communicate across network boundaries.
[I-D.ietf-bess-evpn-first-hop-security] defines a related mechanism,
the DHCP Snoop Route (DSR), for synchronizing DHCP-snoop-derived
bindings specifically for First Hop Security functions (DAI/NDI/
Source Guard) across an EVPN Broadcast Domain. This document's
Client IP Binding Sync mechanism is intentionally more general (not
tied to DHCP snooping) and reuses Route Type 2 rather than defining
a new route type; the two approaches are complementary rather than
competing, and this document's Client IP Binding Sync ID scoping
concept has also been proposed as a companion extension to DSR in
[I-D.dikshit-bess-evpn-fhs-scoped-sync].
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
When used in lowercase, these words convey their typical use in
common language, and they are not to be interpreted as described in
[RFC2119].
4. Problem Description
Access Switches build a trusted database of L3 clients by snooping
into DHCP/ND packets in the client VLAN. This database can be
leveraged by security and analytical features. Security features
help in protecting the network from unauthorized/untrusted users,
while analytical features/applications gauge the nature of access
with the telemetry information for the designated hosts. This
information helps keep the network health in a secure and informed
way:
* Prevent ARP cache depletion attacks
* Allow traffic only from known clients on access ports
* Denial of service and Man in the middle attacks
In Campus networks of Colleges, Branch offices, Headquarters and
Data Center (DC) networks, it is a very common deployment for
networks to extend Layer-2 across sites and geographies over WAN
(Wide Area Network), via a well defined overlay fabric solution
like EVPN and constructs like VXLAN, GPE, GUE, NVGRE, with VXLAN
being the most deployed. The solution for Campus and DC can be
combined for enterprise solutions as well.
The campus networks are extended between headquarter and branch
offices, whereas DCs are extended for load sharing, resiliency, and
hierarchical availability of data across geographies and regions.
In such deployments, the client database ends up being local to the
first-hop access switch or gateway the client is connected to. The
other set of access switches within or remotely placed in the
extended fabric treat the client as untrusted or unauthorized on
the client VLAN. This would result in switches denying services to
legitimate clients.
The following diagram shows the topology of disparate fabrics.
|(--------------FABRIC1----------------)|(--WAN------)|(----------FABRIC3---------------)|
+---------+ ________+-------+ +------+ +-----+
+----+ | +------+ | | +-------+ +------+ +-----+
|host1|-[vlan10]-|VTEP11 |--+ | +-------+ +------+ +-----+
|----+ | +-------+ | +-------+ | FABRIC-3
|----|Border1|----| WAN ===================================
| FABRIC-1 | +-------+ | FABRIC-2
+----+ | +------+ | | +-------+ +------+ +----------+
|host2|- [vlan20]-|VTEP12|--+ |________|Border2|--|VTEP21|-[Vlan10]-|Wireless |--Clients1..n
+----+ +------+ +-------+ +------+ |Controller|
|(--------------FABRIC1----------------)|(--WAN-----)|(------------------FABRIC2----------------------------)|
Figure 2: Multifabric Overlay Topology
In the above mentioned topology diagram,
* the Client IP Binding Database is local to the client connected
to the switches within the fabric. Without an explicit
solution in place, these details are not known to other switches
within and outside the fabric, unless explicitly communicated.
For example, the Access VTEP11 and Access VTEP12, though in the
same fabric, can snoop into DHCP packets originating or destined
from the locally attached hosts, that is, Host1 and Host2
respectively, but not into the other Access hosts. These
packets are typically unicast to and from the DHCP server
located in a centralized location. The packets are not leaked
to remote fabrics as well. The DHCP packets generated from
Host1 or Host2 are typically not leaked to remote fabrics,
Fabric2 or Fabric3 in the above example. Hence this information
about host1 and host2 cannot be snooped by remote Access devices
VTEP12 and VTEP13 in the remote fabrics.
* The typical example shown in the above diagram elaborates on the
problem.
* There are no known standard techniques to achieve this
synchronization between switches, within or across an extended
network, via an overlay network.
* Security policies that need knowledge about the connected
clients in a VLAN across fabrics will not work as expected in
this model.
For example, to protect from neighbor cache depletion attacks, a
switch can be configured to perform resolution only for known
clients in the network. This is not possible if the Client IP
Binding Database is not synced. NOTE: the above diagram leverages
BGP EVPN provisioned overlays over VXLAN fabric as the network
extension instrument. Though the example can be generalized for
any BGP provisioned overlay network like VPLS, VPWS, L3VPN, etc.
One possible option is to build the client database by sniffing
into data plane packets. This class of solution is ingrained with
problems.
4.1. Broadcast Over WAN
This solution requires learnings over broadcast packets like ND and
ARP. The bridge-domain extension over fabrics will require the
broadcasts to travel over the WAN pipe, and needs to be refreshed
periodically as and when there is a request for host discovery.
With reference to the above diagram, Gratuitous ARP (GARP),
generated by Host2, will be required to be flooded to remote
fabrics (fabric 2 and 3), in a typical data plane learning. But
with EVPN control plane and arp-suppression techniques, there is
minimal leak of ARP broadcasts in the EVPN fabric, and thus the WAN.
Hosts attached to access switches may GARP frequently (too many and
too often), thus aggravating the broadcast leaks over WAN. As
mentioned in the topology description, DHCP Snooping will not help
here, as DHCP packets will not make it to remote fabrics. Even in
DHCP Relay based deployments, the Relay configuration is local to a
fabric and cannot be leaked to remote fabrics.
4.2. Same Subnet across fabrics over different Vlans
There is a possibility that the same subnet allocation for IP
address happens across disparate VLANs within or across the
fabrics. VLAN 10 in fabric1 and VLAN 20 in fabric 2 are mapped to
the same subnet gateway, let's say, 10.0.0.0/24. The IP binding
database learnt via DHCP or ND snooping (hosted on access VTEP11
and VTEP13) needs to be synchronized as the broadcast domain is
extended over a different VNI, let's say, 100 and 200 (mapped to
VLAN 10 and 20 respectively). Thus the problem at hand is that the
allocations (IP bindings) are to be synchronized for the same or
different subnet, but across the VLANs in disparate fabrics. This
is not possible with the following deployments:
* Native VLAN extension and VLAN translation based fabric
extensions
* Static VXLAN based network extensions.
Note that, in BGP control plane, Route Targets help go around this
anomaly with data plane learnings.
4.3. Unwarranted and Insecure Information leak
With a data plane solution (via GARP or ND), the flooding over WAN
to all remote fabrics will lead to unwarranted learning in fabrics
over which there is no operator control.
* Thus potentially leaking client subnet specific information to
the untargeted fabrics, creating an information leak and
security risk.
* The source fabrics do not have control over the flooding in WAN
(as it is a flood in the VLAN bridge domain).
* Hence there is a necessity to selectively leak or restrict the
synchronization between specific fabrics.
In cases where DHCP Relay is configured,
* DHCP exchange happens between the client connected to the Access
Switch and the server through a unicast channel. This is a
predominant use case but inherently prohibits other Access
Switches snooping into the client DHCP packets.
* In the reference example, the Access Switches are also overlay
tunnel end points, VTEP.
For example, in the above diagram, the host1 GARP is flooded over
WAN to both fabric2 and fabric3, even though the intention is to
sync the information to fabric2 only.
5. Security of Fast Roaming Clients
If a wireless client, let's say host1, moves in a lift or elevator
across floors and hence across gateways, the security policy
synchronization is a must between the VTEPs sitting behind the
wireless controllers. Rather than waiting for the client to speak
up behind every wireless controller, the first controller and
corresponding VTEP can publish the security clearance or security
risk of the host to all remote VTEPs.
6. Solution(s)
This document proposes a solution for synchronizing the IP Bindings
between the Access Switches by leveraging the BGP EVPN control
plane constructs called Route Type 2 NLRIs (EVPN NLRI, MAC
Advertisement Route). The proposal defines a new extended
community, which indicates the IP Binding synchronization, to be
carried in a BGP Update message carrying the Route Type 2 NLRI
(Network Layer Reachability Information). As EVPN is at the core
of fabric deployments to support multihoming and multitenancy, this
control plane extension alleviates the synchronization of IPs which
is specific to tenants and applicable to all or selective hosts
attached to the Access VTEPs. The host can be attached to more
than one VTEP (indicating multihoming) over a segment (called an
Ethernet Segment). BGP EVPN is a go-to solution for VXLAN fabric
extension across the WAN, as it is also easy to realize the native
transport (underlay) encapsulation as IP based.
For example, in the above diagram, VTEP11 (also hosting the IP
Binding database) publishes BGP update messages, carrying EVPN
Route Type 2 for all the local MAC, IP learnings, to the remote BGP
peers (within or across the fabrics). These MAC, IP learnings are
typically learnt via local dynamic learnings, that is, host1 sends
a GARP towards VTEP11 and is received on VTEP11 over the client
(tenant) facing gateway interface (interface VLAN 10). This
interface can be a VLAN interface mapped to the subnet, for
example, interface VLAN 10 on VTEP11. All hosts attached over VLAN
10 to VTEP11 are allocated the same subnet IP address and monitored
by the IP Binding (or security validation) application hosted on
VTEP11. Note that similar validation is performed on all the
access switches in a secure network. The dynamic learnings are
validated against the IP Binding database (typically learnt via
snooping) as indicated in the EVPN Route Type 2. Note that the
process of learning the IP Bindings (via snooping of DHCP or ARP)
is outside the purview of this document.
6.1. Client IP Binding Sync Extended Communities
A new extended community Path attribute called Client-IP Binding
Sync Extended Community is defined. This attribute is an optional
attribute and also transitive in nature and can be relayed in the
control plane path. This attribute, if carried along with a BGP
update message with MAC, IP bindings (with EVPN NLRI, MAC
Advertisement Route), indicates the following to the receiving BGP
peer:
* MAC, IP data can ALSO be leveraged for Client IP Binding
synchronization.
* The data is to be handed over to the Security entity or
application for validating the IP allocation.
* The handover procedure is implementation specific and outside
the purview of this document.
The following diagram shows the Client IP Binding Sync Extended
Community:
0 1 2 3 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type | Sub-Type | Client IP Binding Sync ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client IP Binding Sync ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Client-IP Binding Sync Extended Community
Field | Description
============================================================
Type | 1 Octet size. Type field can be newly
| defined as a proprietary one. It is a
| transitive attribute, hence bit 0 in this
| octet is 0.
Sub-Type | 1 Octet size. The value of sub-type will
| be allocated as per IANA (TBD2 -- see
| Section 9). For experimental purposes,
| it can be used as any unallocated value
| within the free range. This field, when
| set to the appropriate value, indicates to
| the receiver about processing the NLRI
| for IP-Binding synchronization.
Client IP Binding | 6 Octets size. This field carries the
Sync ID | Identifier configured to categorize the
| IP Binding instance. The field is
| applicable to all data carried in MAC IP
| NLRIs in the same update message. The
| instance is configurable and the value is
| implementation dependent.
The following section gives a detailed flow of the send and receive
side processing of the new PDU.
6.1.1. Processing of Client IP Binding
The following set of bullets describe the 'Send Side Processing'
flow:
(1) The Access VTEP hosting the Client IP Binding Database can be
triggered to carry the new extended community, via a knob.
(2) The configuration can be an explicit 'CLIENT IP BINDING SYNC
ID' and carried inside the Path attribute which can be
configured on Access VTEPs. The guidance for configuration of
this ID is that it indicates a Group of Access Switches spread
across fabrics, that intend to share the IP Binding data as
they might be part of the same client or group of clients.
All, catering to IP allocation of the same tenant or group of
tenants over the same or disparate VLANs and subnets. The
configured value is ALSO leveraged to match the received value
in the Route Type 2 Update message.
(3) The configuration scope of the 'CLIENT IP BINDING SYNC ID' can
be global for all BGP updates or specific to VLANs for which
MAC, IP is being published in the UPDATE message. This is
implementation specific and based on the 'IP BINDING SYNC ID'
scope within the 'Group of Access Switches'. If VLAN based,
then 'CLIENT IP BINDING SYNC ID's can be inherited or derived
from 'Route Target' extended communities, configured on the
'Group of Access Switches'.
(4) The Withdraw of routes, Route Type 2, MAY also carry the
extended community to indicate to the BGP peers configured on
the Group of Access Switches to convey the INVALIDITY of the
MAC, IP bindings, published earlier.
(5) The Access VTEPs (or BGP peer) on the send side MUST NOT
insert the new extended community in the withdraw message, if
the corresponding IP Bindings are still valid.
The following bullets describe the 'Receive Side Processing':
(1) The same 'CLIENT IP SYNC ID' should be configured on the
receiving Access Switch (BGP peer) to process or absorb the
MAC, IP information within the IP Binding Context. For
example, it can be a security application, which validates the
IP Bindings.
(2) If the receiving BGP peer DOES NOT SUPPORT the 'Client IP
Binding Sync' Extended Community in the received Route Type 2,
it ignores the processing of this extended community while
processing other attributes. Thus, no implication on any
'Client IP Binding' application, if hosted on this BGP Peer.
It MUST discard the unsupported attribute as defined in
[RFC7606].
(3) If the receiving BGP peer SUPPORTS the Client IP Binding Sync
Extended Community in the received Route Type 2, it decodes
the Extended Community and extracts the "Client IP SYNC ID"
value. It matches the value with the locally configured one.
* If a match is found, then it imports the MAC, IP NLRIs
carried in the same update message to the Security
application, which validates the MAC, IP against the
security policies and absorbs or drops after comparing it
against the local IP Binding database.
* If no match is found, then it MUST NOT import the NLRIs
into the local IP Binding Database.
(4) In case there are other BGP peers to whom the Update message
is to be relayed, then the Client IP Binding Sync Extended
Community is also relayed without any updates in the values as
it is a transitive attribute. For example, Border1 receives
an update message with the Client IP Binding Sync Extended
Community from VTEP11. It processes it as mentioned in the
above bullets and relays it to its eBGP (external BGP peers),
Border2 and Border3 in remote fabrics fabric2 and fabric3
respectively, as it is an optional transitive attribute. Note
that the above example quotes eBGP (different Autonomous
System) across fabrics, but the same logic will apply when a
Route Reflector reflects routes between two iBGP peers.
The augmented control plane feature helps all Access switches to be
synchronized with respect to allowed or validated client
credentials, thus preventing rogue traffic or DoS attacks
'originating in' or 'destined to' the local network.
7. Backward Compatibility
Backward Compatibility for non-supporting nodes is as per the
following standard already defined in [RFC7606], that a BGP speaker
should discard the unsupported attribute.
8. Security Considerations
This document defines a new BGP transitive extended community (the
Client IP Binding Sync Extended Community) carried alongside EVPN
MAC/IP Advertisement (Route Type 2) routes. The extended community
itself carries no binding data -- it only signals, to a receiving
PE, that the accompanying MAC/IP binding SHOULD be handed to the
local security application (e.g. for ARP/ND spoofing protection or
fast-roaming continuity checks) and, via the Client IP Binding Sync
ID, which configured group of fabrics that binding is relevant to.
As such:
* A compromised or misconfigured BGP speaker that attaches this
extended community to a route it should not could cause a
receiving PE's security application to consider an incorrect
binding as valid. This risk is bounded by the same iBGP/eBGP
session security mechanisms already required to protect any EVPN
route (see [RFC7454] for general BGP operational security
guidance, and [RFC8365] Section 10 for EVPN-specific
considerations) -- this document does not introduce a new
attack surface beyond what exists for other EVPN Route Type 2
attributes, since the receiving security application is still
expected to perform its own independent validation of the
binding (e.g. cross-checking against locally observed DHCP/ND
snoop state) rather than trusting the extended community alone
as an authorization signal.
* Because the Client IP Binding Sync ID controls which fabrics
receive a given binding, incorrect provisioning of Sync IDs
(e.g. reusing the same ID across fabrics that should be
isolated) can lead to the unintended cross-fabric leak this
mechanism was designed to prevent (see Section 4.3). Operators
SHOULD manage Sync ID assignment with the same rigor as
Route-Target assignment, and MAY apply BGP import policy at
fabric/site boundaries to hard-filter routes carrying
unexpected Sync ID values as defense in depth.
* This document does not alter the BGP UPDATE processing model,
route resolution, or best-path selection defined in [RFC7432]
and [RFC8365]; it only adds an advisory extended community, so
it introduces no new denial-of-service surface beyond ordinary
EVPN route churn.
9. IANA Considerations
IANA is requested to allocate a new sub-type, TBD2, from the "EVPN
Extended Community Sub-Types" registry defined by [RFC7153], for
the Client IP Binding Sync Extended Community defined in Section 6
of this document.
Sub-Type Name Reference
-------- --------------------------------- -------------
TBD2 Client IP Binding Sync This document
No other IANA actions are required.
10. Acknowledgements
TBD.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/rfc/rfc2119.txt>.
11.2. Informative References
[RFC4379] Kompella, K., "Detecting Multi-Protocol Label Switched
(MPLS) Data Plane Failures", RFC 4379, February 2006,
<https://www.rfc-editor.org/rfc/rfc4379.html>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, March 2014,
<https://www.rfc-editor.org/rfc/rfc7153.html>.
[RFC7348] Mahalingam, M., "Virtual eXtensible Local Area Network
(VXLAN): A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks", RFC 7348, August 2014,
<http://www.rfc-editor.org/rfc/rfc7348.txt>.
[RFC7432] Sajassi, A., Ed., "BGP MPLS-Based Ethernet VPN",
RFC 7432, February 2015,
<http://www.rfc-editor.org/rfc/rfc7432.txt>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP
Operations and Security", BCP 194, RFC 7454,
February 2015.
[RFC7606] Chen, E., Ed., "Revised Error Handling for BGP UPDATE
Messages", RFC 7606, August 2015,
<https://www.rfc-editor.org/rfc/rfc7606.html>.
[RFC9014] Rabadan, J., Ed., "Interconnect Solution for Ethernet
VPN (EVPN) Overlay Networks", RFC 9014, May 2021,
<http://www.rfc-editor.org/rfc/rfc9014.txt>.
[I-D.ietf-bess-evpn-first-hop-security]
Sajassi, A., et al., "First-Hop Security for EVPN",
Work in Progress, draft-ietf-bess-evpn-first-hop-
security-01.
[I-D.dikshit-bess-evpn-fhs-scoped-sync]
Dikshit, S., "Scoped Synchronization for the EVPN
First-Hop-Security DHCP Snoop Route", Work in Progress,
draft-dikshit-bess-evpn-fhs-scoped-sync-00.
Authors' Addresses
Saumya Dikshit
Aruba Networks, HPE
Mahadevpura
Bangalore 560 048
Karnataka
India
Email: saumya.dikshit@hpe.com
Thimma Reddy Gadekal
Aruba Networks, HPE
Mahadevpura
Bangalore 560 048
Karnataka
India
Email: tgadekal@hpe.com