Internet DRAFT - draft-saumthimma-evpn-ip-binding-sync
draft-saumthimma-evpn-ip-binding-sync
BESS WG S. Dikshit
Internet-Draft T R. Gadekal
Intended status: Standards Track Aruba, HPE
Expires: 6 July 2024 3 January 2024
Secure IP Binding Synchronization via BGP EVPN
draft-saumthimma-evpn-ip-binding-sync-03
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 'Client IP Binding database' is last mile
solution, this information stays local to the end point switch, to
which clients are connected. When networks are extended across
geographies, that is, both layer2 and layer3, the 'Client IP Binding
Database' in end point of switches of remote fabrics should be in
sync. This literature intends to align the synchronization of
'Client IP Binding Database" through an extension to BGP control
plane constructs and as BGP is a typical control plane protocol
configured to communicate across network boundries.
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 6 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dikshit & Gadekal Expires 6 July 2024 [Page 1]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
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
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3
4.1. Broadcast Over WAN . . . . . . . . . . . . . . . . . . . 5
4.2. Same Subnet across fabrics over different Vlans . . . . . 6
4.3. Unwarranted and Insecure Information leak . . . . . . . . 6
5. Security of Fast Roaming Clients . . . . . . . . . . . . . . 7
6. Solution(s) . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Client IP Binding Sync Extended Communities . . . . . . . 8
6.1.1. Processing of Client IP Binding . . . . . . . . . . . 9
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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: Etherenet Virtual Private Network
Dikshit & Gadekal Expires 6 July 2024 [Page 2]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
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 last mile
solution, this information stays local to the end point switch, to
which clients are connected. When networks are extended across
geographies, that is, both layer2 and layer3, the 'Client IP Binding
Database' in end point of switches of remote fabrics should be in
sync. This literature intends to align the synchronization of
'Client IP Binding Database" through an extension to BGP control
plane constructs and as BGP is a typical control plane protocol
configured to communicate across network boundries.
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 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/application gauge the nature of access with
the telemetry information for the designated hosts. This information
help keeping 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
Dikshit & Gadekal Expires 6 July 2024 [Page 3]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
In Campus networks of Colleges, Branch office, Headquarters and
DataCenter DC networks, it is a very common deployment, for networks,
to extend Layer-2 across sites and geographies over WAN, Wide Area
Network, via 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 where as DCs are extended for load sharing, resiliency,
hierarchical availability of data across geographies and region. In
such deployments, the client database ends up being local to the
first-hop access switch or gateway, the client is connected to.
Client connected to the first hop access switch or gateway. The
other set of access switches within or remotely placed in the
extended fabric, treat the client as untruste or unauthorized on the
client VLAN. This would result in switches to deny services to
legitimate clients.
The following diagram shows the topology of disparate fabrics.
|(--------------FABRIC1 ----------------)|(--WAN------)|(----------FABRIC3---------------)|
+---------+ ________+-------+ +------+ +-----+
+----+ | +-------+ | |Border3|--|VTEP31|-[Vlan20]-|host3|
|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 1: Figure 2: Multifabric Overlay Topology
In the above mentioned topology diagram,
* the Client IP Binding Database is local to client connected to the
switches within the fabric. Without explicit solution in place,
these details are not known to other switches within and outside
the fabric, unless and until explicitly communicated. For
example, the Access Vtep11 and Access Vtep12, though in the same
fabric, can snoop in to 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
unicasted to and from the DHCP server located in a centralized
location. The packets are not leaked to remote fabrics as well.
Dikshit & Gadekal Expires 6 July 2024 [Page 4]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
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 in
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 extended
network, via an overlay network.
* Security policies that needs 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 the known
clients in the network. This is not possible if 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, DCHP Snooping will not help here, as DHCP
packets will not make it to remote fabrics. Even in DCHP Relay based
deployments, the Relay configuration is local to a fabric and cannot
be leaked to remote fabrics.
Dikshit & Gadekal Expires 6 July 2024 [Page 5]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
4.2. Same Subnet across fabrics over different Vlans
There is a possibility that same subnet allocation for ip address
happens across disparate Vlans within or across the fabrics. Vlan 10
in fabric1 and Vlan20 in fabric 2 are mapped to same subnet gateway,
lets 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, lets 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 same or different subnet, but across the Vlans in
disparate fabrics. This is not possible with following deployment
* 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 dataplane learnings.
4.3. Unwarranted and Insecure Information leak
With dataplane 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 its a flood in 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 Access
Switch and the server through unicast channel. This is a
predominant usecase 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.
Dikshit & Gadekal Expires 6 July 2024 [Page 6]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
For example, in 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, lets 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 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 BGP
Update message carrying the Route Type 2 NLRI (Network Layer
Reachability Information). As EVPN is the 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 Ethernet Segment).
BGP EVPN is a goto solution for Vxlan fabric extension across the
WAN, as its 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 the similar
validation is performed on all the access switches in a secure
network. The dynamic learnings are validated against the IP Binding
database (learnt via typically) 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.
Dikshit & Gadekal Expires 6 July 2024 [Page 7]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
6.1. Client IP Binding Sync Extended Communities
A new extended community Path attribute called Client-IP Binding Sync
Extended Communities 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 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 invention.
The following diagram shows the Client IP Binding Sync Extended
Communities
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.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field | Description
============================================================
Type | 1 Octet size, Type field can be newly defined as a proprietary one.
| Its a transitive Attribute, hence 1 bit in this octet is 0.
|
Sub-Type | 1 Octet size. The value of sub-type will be allocated as per IANA (TBD)
| For experimental purposes, it can be used as any unallocated value
| within the free range.
| This field when set to appropriate value indicates to the receiver
| about processing the NLRI for IP-Binding synchronization.
|
Client IP Binding | 6 Octets size, This field carries the Identifier configured
Sync ID | 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 value is implementation dependent.
Figure 2: Figure 2 Client-IP Binding Sync Extended Communities
Dikshit & Gadekal Expires 6 July 2024 [Page 8]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
the following section gives a detailed flow of the send and receive
side processing 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 communities, 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 Switch spread across
fabrics, that intend to share the IP Binding data as they might
be part of same client or group of clients. All, catering to IP
allocation of same tenant or group of tenants over 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 IDs'
scope within the 'Group of Access Switch'. If Vlan based, then
'CLIENT IP BINDING SYNC IDs' 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
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 communities 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.
Dikshit & Gadekal Expires 6 July 2024 [Page 9]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
(2) If the receiving BGP peer DOES NOT SUPPORTS the 'Client IP
Binding Sync' Extended Communities 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
respond to unsupported attribute as defined in [RFC4379].
(3) If the receiving BGP peer SUPPORTs the Client IP Binding Sync
Extended Communities in the received Route Type 2, It decodes
the Extended Communities and extracts the "Client IP SYNC ID"
value. It matches the value with the locally configured one.
* If match is through, 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 andi absorbs or drops after comparing it against the
local IP Binding database.
* If nomatch then it MUST NOT import the NLRIs into 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
Communities are also relayed without any updates in the values
as its a transitive attribute. For example, Border1 receives an
update message with the Client IP Binding Sync Extended
Communities from Vtep11. It processes it as mentioned in above
bullets and relays it to its eBGP (external BGP peers), Border2
and Border3 in remote fabrics fabric2 and fabric3 respectively
as its an optional transitive attribute. Note that the above
example quotes eBGP (different Autonomous System) across
fabrics, but same logic will apply when Route Reflector reflects
routes between two iBGP peers.
The augmented control plane feature, helps all Access swtiches 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-support nodes is as per the following
standards already defined in [RFC7606], that, BGP speaker should
discard the unsupported TLV types
Dikshit & Gadekal Expires 6 July 2024 [Page 10]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
8. Security Considerations
9. IANA Considerations
10. Acknowledgements
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., "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., "BGP MPLS-Based Ethernet VPN", RFC 7432,
February 2015,
<http://www.rfc-editor.org/rfc/rfc7432.txt>.
[RFC7606] Chen, E., "Revised Error Handling for BGP UPDATE
Messages", RFC 7606, August 2015,
<https://www.rfc-editor.org/rfc/rfc7606.html>.
[RFC9014] Rabadan, J., "Interconnect Solution for Ethernet VPN
(EVPN) Overlay Networks", RFC 9014, May 2021,
<http://www.rfc-editor.org/rfc/rfc9014.txt>.
Authors' Addresses
Dikshit & Gadekal Expires 6 July 2024 [Page 11]
Internet-Draft Secure IP Binding Synchronization via BG January 2024
Saumya Dikshit
Aruba Networks, HPE
Mahadevpura
Bangalore 560 048
Karnataka
India
Email: saumya.dikshit@hpe.com
Gadekal, Thimma Reddy
Aruba Networks, HPE
Mahadevpura
Bangalore 560 048
Karnataka
India
Email: tgadekal@hpe.com
Dikshit & Gadekal Expires 6 July 2024 [Page 12]