Full Report
Technical report on best practice use of this fundamental data routing protocol.
Analysis Summary
# Best Practices: Border Gateway Protocol (BGP) for ISP Interworking
## Overview
Border Gateway Protocol (BGP) is the fundamental routing protocol that enables the exchange of reachability information between Autonomous Systems (AS) on the internet. Because BGP was built on trust, it is vulnerable to route hijacking, route leaks, and IP spoofing. These practices address the implementation of technical controls and registry-based validation to ensure predictable, secure, and resilient internet routing.
## Key Recommendations
### Immediate Actions
1. **Prefix Filtering:** Implement explicit filters on all BGP peering sessions to ensure only authorized IP prefixes are advertised or accepted.
2. **Route Object Creation:** Register all allocated IP address space in the appropriate Internet Routing Registry (IRR), such as RIPE NCC, to allow neighbors to validate your routes.
3. **Disable Unused Sessions:** Shut down any BGP peering sessions that are not actively in use to reduce the attack surface.
### Short-term Improvements (1-3 months)
1. **RPKI Implementation (ROA):** Create Route Origin Authorisations (ROAs) for all your prefixes. This cryptographically links your AS number to your IP prefixes.
2. **RPKI Route Origin Validation (ROV):** Configure routers to perform ROV on incoming updates and drop "Invalid" routes to prevent the acceptance of hijacked prefixes.
3. **BGP TTL Security (GTSM):** Enable the Generalized TTL Security Mechanism (RFC 5082) for direct peering sessions to protect the BGP control plane from remote spoofing attacks.
### Long-term Strategy (3+ months)
1. **Automation of Filters:** Integrate BGP filter generation with IRR/RPKI data sources to ensure filters stay updated without manual intervention.
2. **PeeringDB Maintenance:** Maintain an accurate and up-to-date profile on PeeringDB to streamline secure interworking with global ISPs.
3. **BGPsec Evaluation:** Monitor and plan for the transition to BGPsec (RFC 8205) to provide path-validation security beyond origin validation.
## Implementation Guidance
### For Small Organizations
- Focus on "customer-side" hygiene: ensure your upstream ISP is filtering your prefixes.
- Register your prefixes in the IRR and create ROAs to ensure your traffic isn't hijacked.
- Use simple prefix-list limits on your edge routers to prevent accidental leaks of the full internet routing table.
### For Medium Organizations
- Implement automated prefix-list updates based on downstream member/customer IRR data.
- Deploy BGP MD5 or Keychain authentication for all EBGP sessions to prevent session reset attacks.
- Establish a "default-deny" policy for all BGP neighbors, only permitting known valid routes.
### For Large Enterprises / ISPs
- Participate in the Mutually Agreed Norms for Routing Security (MANRS) initiative.
- Deploy redundant RPKI validators (e.g., Routinator or OctoRPKI) across multiple points of presence (PoPs).
- Implement Maximum Prefix Limits on all peering sessions to protect router resources from "route leaks" that could overwhelm memory (TCAM).
## Configuration Examples
*Note: Syntax varies by vendor (Cisco iOS, Juniper JunOS).*
**Enabling Maximum Prefix Limit (Cisco Example):**
bash
router bgp [Your_ASN]
neighbor [Neighbor_IP] maximum-prefix [Max_Number] [Threshold_Percentage] restart [Minutes]
**BGP MD5 Authentication:**
bash
router bgp [Your_ASN]
neighbor [Neighbor_IP] password [Secret_Key]
## Compliance Alignment
- **NIST SP 800-54:** Border Gateway Protocol Security.
- **MANRS:** Mutually Agreed Norms for Routing Security (industry-led standard).
- **ISO/IEC 27001:** Controls for network security and communications.
- **Cyber Essentials Plus (UK):** Network perimeter security requirements.
## Common Pitfalls to Avoid
- **Implicit Trust:** Assuming that a peering partner is only sending you legitimate routes without technical validation.
- **Stale Registry Data:** Failing to update IRR or RPKI records when IP space is moved or returned, leading to "Invalid" states and dropped traffic.
- **Lack of Monitoring:** Not setting up alerts for BGP session flaps or unauthorized prefix advertisements (hijacks) of your own space.
- **The "Any/Any" Leak:** Misconfiguring a router to re-advertise the entire global routing table back to an upstream provider.
## Resources
- **NCSC Guidance:** hXXps://www.ncsc.gov.uk/report/responsible-use-of-bgp-for-isp-interworking
- **MANRS Implementation Guide:** hXXps://www.manrs.org/isps/guide/
- **RIPE NCC RPKI Dashboard:** hXXps://rpki.ripe.net/
- **PeeringDB:** hXXps://www.peeringdb.com/