Managing Routing Policy

Even if a routing update is authenticated, a configuration error in a customer or peer's network could cause them to send you invalid routes. A classic and disastrous example is the dual-homed ISP customer who does not filter BGP routes and offers transit for the entire Internet to their upstream ISP.

Ingress route filtering is the responsibility of the customer and the network service provider. However, the onus is really on the provider, who will generally be blamed by the Internet community if things go wrong.

Generally, two categories of route filtering exist:

• Filtering other providers or peer networks

• Filtering customers

In an ideal world, the filtering process for both categories would be identical. However, at the global Internet routing level, filtering of other providers traditionally has been almost nonexistent. An ISP responsible for the Internet backbone relies on a trust model. This trust makes the filtering of customer routes that much more critical.

The trust model evolved because there was no complete registry describing which provider was routing which networks, and because of the technological challenge of per-prefix route filtering. Given 50,000 routes in the Internet at the time of this writing, per-prefix filtering would require very large route filters, which consume both memory and processor cycles.

The traditional Cisco route-filtering mechanism based on access lists had problems scaling to 50,000 routes, and was missing a number of more sophisticated elements associated with matching prefix information. This is hardly surprising because the original access-list scheme was as much aimed at packet filtering as route filtering. However, prefix-lists, which are optimized for IP route filtering, now make interprovider filtering possible. Now all that remains is to invent a well-coordinated, secure, Internet routing registry.

In the meantime, many providers at large Internet NAPs perform "sanity" filtering only via the following prefix-list:

ip prefix-list martian-etc seq 5 deny 0.0.0.0/32 ! deny the default route ip prefix-list martian-etc seq 10 deny 0.0.0.0/8 le 32

! deny anything beginning with 0

ip prefix-list martian-etc seq 15 deny 0.0.0.0/1 ge 20

ip prefix-list martian-etc seq 20 deny 10.0.0.0/8 le 32 ! deny 10/8 per RFC1918

ip prefix-list martian-etc seq 25 deny 127.0.0.0/8 le 32

! reserved by IANA - loopback address ip prefix-list martian-etc seq 30 deny 128.0.0.0/2 ge 17 deny masks >= 17 for all class B nets (129-191) ip prefix-list martian-etc seq 35 deny 128.0.0.0/16 le 32 ! deny net 12 8.0 - reserved by IANA

ip prefix-list martian-etc seq 40 deny 172.16.0.0/12 le 32 ! deny 172.16 as RFC1918

ip prefix-list martian-etc seq 45 deny 192.0.2.0/24 le 32 ! class C 192.0.20.0 reserved by IANA

ip prefix-list martian-etc seq 50 deny 192.0.0.0/24 le 32 ! class C 192.0.0.0 reserved by IANA

ip prefix-list martian-etc seq 55 deny 192.168.0.0/16 le 32 ! deny 192.168/16 per RFC1918

ip prefix-list martian-etc seq 60 deny 191.255.0.0/16 le 32 ! deny 191.255.0.0 - IANA reserved ip prefix-list martian-etc seq 65 deny 192.0.0.0/3 ge 25 ! deny masks > 25 for class C (192-222)

ip prefix-list martian-etc seq 70 deny 223.255.255.0/24 le 32 ! deny anything in net 223 - IANA reserved ip prefix-list martian-etc seq 75 deny 224.0.0.0/3 le 32 ! deny class D/Experimental

Was this article helpful?

0 0

Post a comment