BGP Prefix filtering is one of the essentials glues which hold the Internet together. Yet, many SPs don’t put the level of detailed thinking needed to ensure all policies, security issues, and service requirements are met. Some things I see with BGP prefix filtering policies which are often forgotten are:
- Comments used in the policy. Never assume someone looking at the policy – being a route map, prefix filter, or another config rule – will understand what you are trying to achieve. All operating systems allow for comments to be inserted into offline policy files. These comments are ignored when the policy is loaded into the router.
An example of this are purposely demonstrated with the Bogon Project. Both the Juniper and Cisco templates have step by step explanations on what the policies are doing. This allows for engineers to walk through in detail and understand the logic to the filter.
Check out:
- One Dimensional Prefix Policies. BGP Prefix policies are not just checking prefixes. There are other BGP attributes which should have policies associated with them and the corresponding filters which enforce those policies. The most obvious BGP attribute which is not filtered is the BGP Community. Most SPs would agree with the following policy:
We will not accept an BGP update from our transit or peer SP whose Community matches our AS.
Enforcing this filter is a simple BGP policy to config and deploy, yet you do not see it done with most SPs. What are the risk if you do not filter our your own communities? Think of a hijacked BGP Router somewhere on the Internet behind a SP who does not filter BGP for their customers. Way too many exist. There is a feasible risk for that miscreant who owns that router to advertise a prefix with a community which is crafted to drop all traffic. That advertisement would move through the Internet, come into you network, and then trigger a community action (say drop all traffic to an important site).
- Max-AS Path. Through an operational fluke, the industry realized that BGP RIB memory has several vectors which take up memory in a router:
- Number of prefixes (the most obvious and most focused topic of conversations)
- Number of paths per prefix (multihoming of customer, SPs, and other critical infrastructure)
- Number of attributes per prefix – specific AS paths.
It is feasible that someone somewhere will either intentionally or (most likely) unintentionally inject prefixes with really long AS paths. AS Prepend is a tools which is easily deployed, but hard to see the impact. Which make is entirely feasible for a new engineer to keep on adding prefixes – thinking that they are not having an impact. The consiquence would be prefixes with really long AS paths – taking up memory.
When this happens on a small site – no big deal. We would just be talking about a few prefixes. But add the novice’s furstration and doing something like – deaggregating their /19 initial allocation to get a better multihoming impact – and you have a potential area for memory consumption. 🙁
This assumes innocence of a novice, not the deviant behavior of a miscreant.
MAX AS path filtering is now included in all the major vendor implementations.