This document discusses route leaks between autonomous systems and proposes a solution using BGP communities. It defines different types of route leaks based on RFC 7908 and provides a real-world example. Analyzing the problem, it finds challenges with using AS path filters alone. The proposed solution tags routes received from different peers with BGP communities and filters based on the tags to prevent unintended route advertisements. This is demonstrated in a lab topology where route leaks are shown before and after applying the BGP community configurations.

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

2. 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

3. 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)

4. Types of
Route Leaks

5. Real-Life
Example

6. 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 …

7. 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.

8. 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

9. 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

10. 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

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

12. 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.

13. LAB
Topology
Output Analysis
Configurations

14. LAB
Topology

15. Confiugration Logic

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

17. 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

18. 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)

19. 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)

20. 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

21. 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

22. 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

23. 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

24. Solution
Adding BGP Community based Filters

25. 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)

26. 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)

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

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

37. Questions & Answers

38. Thank You