Route Leak Prevension
with BGP Community
Q S Tahmeed
AGM, Network Operations
Level3 Carrier Ltd.

Table of
Contents
• Introduction: Route Leaks
• Types of Route Leaks – RFC 7908
• Real-Life Examples
• Findings
• Solution
• Key: BGP Community
• Benefits
• Important Notes
• Overview
• LAB: Topology, Output Analysis & Configs
• Q&A

Introduction:
Route Leaks
Defined in RFC: 7908
Type 1: Hairpin Turn with Full Prefix
Type 2: Lateral ISP-ISP-ISP Leak
Type 3: Leak of Transit Provider Prefixes to Peer
Type 4: Leak of Peer Prefixes to Transit Provider
Type 5: Prefix Re-Origination with Data Path to Legitimate Origin
Type 6: Accidental Leak of Internal Prefixes and More-Specific Prefixes
Notes:
Types 1 – 4: related with AS-PATH validation problem (not covered in RPKI)
Types 5 – 6: related with Route Object validation (covered in RPKI)

Types of
Route Leaks

Real-Life
Example

Real Life
Example
Here in Bangladesh, we faced such leaks due to human errors
back in 2018 when one of the prominent IIGs got connected
with Equinix, SG. They leaked their customer prefixes learned
from Equinix towards their Transit. One of the prominent ISPs
lost at least 10G transit traffic for almost an hour, till the IIG
applied INGRESS filter to drop the ISPs ASN from Equinix.
Later, we also faced several cases where customer prefixes
were leaked (un-intentionally) to Transit. And those
adevertisements were winning at the Global Routing Table.
The affiliated ISPs then resolved the problem by filtering each
others ASNs in their Transit Filters.
More on this in findings section …

Findings
Challenges with ISPs AS-PATH based INGRESS Filter for Customer ASNs at IX/Transit Interface(s):
• Scenario:
• ISPs not receiving client prefixes from Transit, IX, etc.
• Clients not advertising full sets of prefixes directly towards the ISPs (Multihoming & Load-Balancing)
• Challenges:
• IXes are mostly L2 based – No IX-ASN in the learned AS-PATH
• No-common AS-PATH filter can be applied
• Possibility of a very complex configuration (too many logics, very large config etc.)
• Outcome:
• If direct Customer ASNs are filtered using INGRESS AS-PATH-Filters at IX/Transit Interface(s) then the
ISP will loose shortest/best routes and end up diverting the traffic to more expensive Transit or will
direct traffic based on default route only (sub-optimal performance)
Challenges with ISPs AS-PATH based EGRESS Filter for Customer ASNs at IX/Transit Interface(s):
• ISPs implementing only AS-PATH based EGRESS filters leaks Customer routes learned from other PEERs (eg.
IX) due to macth is AS-PATH-List.

Findings (contd.)
Why we need to be concerned about it?
- Many Tier-1 carriers set higher Local-Preference for Customer Routes. This will eventually win the unintended
(leaked) prefix.
- Many/Almost all Tier-1 carriers allows their customers to set higher local-preference for their own routes (via
bgp community). If any provider changes the parameter, chances of winning the unintended (leaked) prefix is
present.
Notes:
- This is more likely a regional/localized scenario
- Further study is required to assess the overall impact at global scale

Solution Key: BGP Community
BGP Community is a very powerful Attribute for effective route policy implementation
• It offers a wide variety of Route TAG-ing which subsequently can be used for route
policy
• Route TAGs have wide range of implications
– ranging from Simple to Very Complex deployment

Solution Benfits
• Route Leak Prevension
• Preventing “unwanted trasit” situations (RFC7908: Types 1 – 4)
• Scalability & Operational Scopes:
• Gain more Granular Control on BGP Advertisement Policy (both iBGP & eBGP)
• Reduce Operational overhead for ASN/Prefix Add/Remove activities (time savings)
• Reduce Operational Risks for human errors

Solution Overview - Important Notes
The proposed solution is in addition to already implemented Routing Security Methods:
- RPKI/ROA validation
- INGRESS Filters
- EGRESS Filters

Soultion Overview
INGRESS Policy
• TAG all received routes based on PEER Types
• Transit
• IX
• PNI
• Customer
EGRESS (Transit/IX/PNI) Policy
• Filter all TAGs matching Transit/IX/PNI
• Allow Customer ASNs/Prefixes based on organization business policy
Customer EGRESS Policy
• Advertise towards clients as per Agreement
Notes:
The proposed solution is a very simple approach to implement BGP community based filtering (in addition to existing route filters/validations) to
prevent Route Leaks (Types 1 – 4). Extensive detailing is possible for larger and complex network topology.

LAB
Topology
Output Analysis
Configurations

LAB
Topology

Confiugration Logic

01 – BGP Table Analysis
As per configuration logic (without BGP community TAGs)

LAB Outputs
ASN: 1000
CE BGP Advertisement to ISP-A
o 192.168.0.0/24
o 192.168.0.0/23
CE BGP Advertisement to ISP-B
o 192.168.1.0/24
o 192.168.0.0/23

LAB Outputs – ISP-A
ASN: 100
BGP Advertisement output from ISP-A
Router:
- Advertisement to ISP-01
- Advertisement to ISP-02
- Advertisement to IX-LAB
Analysis:
- Problematic prefix 192.168.1.0/24 is
being learned from IX-LAB and not Client
- The same prefix is then advertised
towards Transit (ISP-01 & ISP-02)

LAB Outputs – ISP-B
ASN: 200
BGP Advertisement output from ISP-A
Router:
- Advertisement to ISP-01
- Advertisement to ISP-02
- Advertisement to IX-LAB
Analysis:
- Problematic prefix 192.168.0.0/24 is
being learned from IX-LAB and not Client
- The same prefix is then advertised
towards Transit (ISP-01 & ISP-02)

LAB Outputs – ISP-01
ASN: 10
BGP Table Output
192.168.0.0/24
- One of the entry shows path via IX-LAB
192.168.1.0/24
- One of the entry shows path via IX-LAB

LAB Outputs – ISP-01
ASN: 10
BGP Route Lookup
192.168.0.0/24
- One of the entry shows path via IX-LAB
192.168.1.0/24
- One of the entry shows path via IX-LAB

LAB Outputs – ISP-02
ASN: 20
BGP Table Output
192.168.0.0/24
- One of the entry shows path via IX-LAB
192.168.1.0/24
- One of the entry shows path via IX-LAB

LAB Outputs – ISP-02
ASN: 20
BGP Route Lookup
192.168.0.0/24
- One of the entry shows path via IX-LAB
192.168.1.0/24
- One of the entry shows path via IX-LAB

Solution
Adding BGP Community based Filters

Configuration Logic – ISP-A (ASN100)
INGRESS Policy:
• Apply BGP Community TAG 100:9
• Peering types: IX & Transit (ASN150, ASN10, ASN20)
EGRESS Policy:
• Apply Filter towards IX/Transit to discard all Prefixes with TAG 100:9
• Peering types: IX & Transit (ASN150, ASN10, ASN20)
• Also may remove existing AS-PATH filters (applicable for the LAB, may not be a
viable option in real-life scenario)

Configuration Logic – ISP-B (ASN200)
INGRESS Policy:
• Apply BGP Community TAG 200:9
• Peering types: IX & Transit (ASN150, ASN10, ASN20)
EGRESS Policy:
• Apply Filter towards IX/Transit to discard all Prefixes with TAG 200:9
• Peering types: IX & Transit (ASN150, ASN10, ASN20)
• Also may remove existing AS-PATH filters (applicable for the LAB, may not be a
viable option in real-life scenario)

02 – BGP Table Analysis
As per configuration logic (with BGP community TAGs)

LAB Configs (ISP-A & ISP-B)
Pre vs. Post BGP Community implementation

Questions & Answers

Thank You