The Border Gateway Protocol (BGP) is the protocol networks use to exchange routing information with each other across the internet. Each network announces which IP address ranges it can reach, and neighbors pass that on. BGP largely trusts what it is told, so operators add filters and limits to keep mistakes and attacks from spreading.
How does BGP work?
RFC 4271 defines BGP version 4 as an inter-Autonomous System routing protocol. An Autonomous System (AS) is a set of routers under a single technical administration that presents a consistent picture of the destinations reachable through it. The primary function of a BGP system is to exchange network reachability information with other BGP systems, including the list of ASes that the information passes through. That list is enough to build a graph of AS connectivity, prune routing loops, and enforce some policy decisions.
BGP runs over TCP, and a BGP speaker listens on TCP port 179. Two systems form a TCP connection and exchange messages to open and confirm parameters. Then they send the part of the routing table that their export policy allows, followed by incremental updates when things change. BGP-4 supports advertising destinations as IP prefixes and aggregating routes, which came with Classless Inter-Domain Routing.
In plain terms: every network says "I can reach these prefixes, through this path of networks," and its neighbors decide whether to believe it and pass it on.
What can go wrong?
RFC 7454, the BGP operations and security best current practice, starts from this point. It says BGP does not directly include mechanisms that control whether the routes exchanged conform to the guidelines defined by the Internet community. So a neighbor can announce a prefix it does not own, by mistake or on purpose, and without filters other networks may accept it. Traffic then flows toward the wrong network.
A constructed example: a small hosting company has a customer who also uses a second provider. A router change by mistake leaks the second provider's routes to the first. The first provider has no limit on how many routes it will accept from the hosting company. Suddenly, a small network is advertising thousands of prefixes, and traffic for them begins to flow through a link that cannot carry it. Sites are slow for hours until someone removes the announcement.
Which controls does RFC 7454 recommend?
The RFC groups the practices:
- Protect the BGP speaker. It should use an access control list that discards packets to TCP port 179 from addresses that are not permitted neighbors. Without it, a speaker can be attacked just by flooding it with connection requests.
- Protect the session. Use TTL security (GTSM, from RFC 5082): peers send packets with a TTL of 255 and the receiver checks that value, which makes spoofing from distant sources ineffective because such packets cannot arrive with that value.
- Filter prefixes. Define filters for special-purpose prefixes, unallocated prefixes, prefixes that are too specific, and your own prefixes, with different rules for peers, customers and upstream providers.
- Limit the number of prefixes accepted on each peering. From peers, set a limit lower than the number of routes in the Internet, so the session shuts down if the peer suddenly announces a full table. From upstreams, set a limit that protects router memory.
- Filter AS paths and next hops, and scrub BGP communities.
The document also covers route flap dampening as a topic.
What about origin validation?
RFC 7454 is about operational hygiene. Beyond it, there are mechanisms to cryptographically validate that an AS is allowed to announce a prefix. This article did not fetch those specifications, so check the current IETF documents and your provider's capabilities before planning them.
How to check or apply this
- List your BGP neighbors, their roles (peer, customer, upstream) and the maximum prefix limit on each.
- Confirm an ACL protects TCP port 179 on every BGP router, allowing only known neighbor addresses.
- Enable TTL security on sessions where the peer is directly connected.
- Write inbound and outbound prefix filters per neighbor role, and review them when a customer adds a prefix.
- Alert on session resets, large changes in received prefix counts, and announcements of prefixes you do not own.
- Rehearse the call: who do you contact at your upstream when you see a bad announcement?
Quick check
Does BGP verify that a network owns the prefix it announces?
Not by itself. RFC 7454 says BGP does not directly include mechanisms to check that exchanged routes conform to community guidelines, which is why filters are needed.
Why limit the prefixes accepted from a peer?
So a mistake on their side cannot flood your routers. RFC 7454 recommends a maximum prefix limit so the session shuts down if the peer announces far more routes than expected.
Sources
Last reviewed: 18 October 2026.
