Prefix Filter Background
An important Border Gateway Protocol (BGP) protection mechanism is the filtering of routing prefixes received from eBGP peers to prevent the BGP process from inadvertently installing unwanted or illegal prefixes in the routing table, whether due to malicious intent or simple misconfiguration. Prefix filtering allows a network administrator to permit or deny specific prefixes that are sent to or received from each eBGP peer, and ensures that network traffic is sent over the intended paths.A real-life example of what can happen when proper prefix filtering is not implemented was generously provided to us by those ISPs peering with Pakistan Telecom (AS17557) back in February 2008. RIPE NCC published an excellent case study on the event.Everything was going well and YouTube (AS36561) was announcing 188.8.131.52/22, that is until Sunday, 24 February 2008 when the longest prefix match game began. On Sunday, 24 February 2008 at 18:47 (UTC), Pakistan Telecom (PT) announced a more specific route (184.108.40.206/24), also known as longest prefix match rule for YouTube, a route which should have been filtered, and then PCCW Global (AS3491) subsequently propagated the announcement, resulting in traffic to YouTube being redirected to Pakistan Telecom. In a nutshell, this was a prefix hijack as a result of the BGP announcement by PT. This, of course, was not exactly what PT envisioned when they invited YouTube to their BGP Party, nor was it the type of party invite that PCCW Global wanted to propagate. Prefix Filters to the rescue!Prefix lists can be configured to specifically allow only those prefixes that are permitted by the routing policy of the network, which is an example of whitelist-based filtering. If this configuration is not feasible due to the large number of prefixes that are received, a blacklist filter can be configured to specifically block illegal prefixes, also known as Bogon routes, and known undesirable prefixes. Bogon prefixes include unallocated IP address space and networks that are reserved by RFC 3330 for special use, such as for internal or testing purposes.For additional information on the use of filtering with Prefix Lists and BGP, please reference the Protecting Border Gateway Protocol for the Enterprise white paper.
ISP Ingress Prefix Filter Templates
Cisco initially created and published ISP Ingress Prefix Filters in 2002 and has been maintaining them ever since. The use of ISP Ingress Prefix Filters is not mandated by Standards Bodies, nor is it required. However, it is considered an industry best security practice and one that Cisco advocates. Cisco continues to provide updates to the ISP Ingress Prefix Filters as changes in IANA prefix allocations and other changes dictate. This ensures that ISPs are able to properly and successfully filter Bogon prefixes.Cisco maintains two types of Ingress Prefix Filters: one that provides “strict” filtering and one that provides “loose” filtering. The strict filter policy restricts prefixes according to the minimum allocations, as specified by the Regional Internet Registries (RIRs), typically allocated to a /20 or larger. The loose filter policy is less restrictive and generally enforces a minimum prefix length of /24.Strict and Loose Ingress Prefix Filter policy templates are both organized into logical filter groups, called phases, as follows:
- Phase 1 -- Deny Special Prefixes (1 -- 99)
- Phase 2 -- Deny Your Own Prefixes (100 -- 199)
- Phase 3 -- Deny IXP Prefixes (200 -- 299)
- Phase 4 -- Deny Bogon Prefixes (300 -- 399)
- Phase 5 -- Permit Critical Infrastructure Prefixes (400 -- 699)
- Phase 6 -- Permit RIR Prefixes On The Minimum Allocation That Is Advertised by the RIR for the ‘Strict Filter’ or Permit RIR Prefixes On The Minimum Allocation To A /24 for the ‘Loose Filter’ (4000 -- 8999)
- Phase 7 -- Permit The Rest Between /8 and /24 (10000 -- 10999)
Prefix Filter Modifications
The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 prefixes (175/8 and 182/8) to Asia Pacific Network Information Centre (APNIC) in August 2009. For these prefixes, APNIC will allocate a minimum assignment of a /22 prefix. Please see the minimum allocations and assignments page for the size of minimum IPv4 portable allocation or portable assignment from the list of APNIC prefixes.In accordance with these allocations, the Strict and Loose Ingress Prefix Filter templates have been updated to Version 24 (v24).Note: ftp-eng.cisco.com requires a passive FTP connection sourced internally from the Cisco network.
Update Notifications and Mailing List
An externally available mailing list has been created that allows any interested party to subscribe and receive notifications each time the Strict and Loose Ingress Prefix Filter templates have been updated to reflect a prefix allocation to an RIR, prefix deallocation from an RIR, or a prefix change in the IANA IPv4 registry.To join to the Strict and Loose Ingress Prefix Filter templates announce mailing list, subscribers must send an email to firstname.lastname@example.org using their favorite mail application. Once the subscription request has been received by the mailing list, a confirmation email message will be sent to the subscriber ensuring that they want to be subscribed to the mailing list. When you have received this message, you will need to respond to it confirming that you want to receive the announcement notifications. Once you have been successfully subscribed to the mailing list, you will receive another message welcoming you to the list. This email message contains your subscription information and should be saved for later reference if you need to unsubscribe yourself.N.B. As this was a technical post, we decided to maintain some fun in the geeky title that adopted some similarities with a Internet phenomenon phrase from ‘back in the day’ (well, make that 2000-2002).