From CT3

By Ivan Pepelnjak

An autonomous system (AS) is a collection of IP networks and routers under the control of an entity that presents a common routing policy to the Internet ([1], see also [2]). In the Internet [3], an AS is usually a network of a Service Provider (SP), including all customers without their own AS, or a multi-homed end customer connected to multiple SPs.

A transit autonomous system is a network that is passing transit traffic (traffic not originated nor terminated in the network) between remote autonomous systems. A non-transit AS is a network that transports only traffic originating or terminating on an IP host (or server) within the network.

Non-Transit AS Design

End-customers having multiple connections to the Internet usually use Border Gateway Protocol (BGP, [4]) to exchange routing information with their Service Providers.

Unless agreed otherwise, ISPs provide full Internet routing to the end customers; the end customers then select the best routes and decide whether to send outbound traffic to one ISP or another. If the customer has multiple Internet-facing routers, these routers have to exchange the best paths (usually across an Internal BGP session) to build a consistent picture of their local Internet topology.

If an end-customer implements no output filters on the BGP-speaking routers, the best paths selected by the end-customer's routers will be advertised back to the ISPs due to the default BGP route propagation mechanisms. Most ISPs use inbound route filters on the BGP connections with their customers, so you might not be able to observe the results of transit route propagation across an end-user network. However, when faced with a lax ISP, the end users might inadvertently become a transit AS.

If you're an end customer, you should always take the necessary precautions to prevent route leakage across your autonomous system; the proper means of doing that is to implement outbound BGP filters that pass only local routes (prefixes assigned to you by an Regional Internet Registry [5] and originated in your AS). If your AS system does not advertise transit routes, the routers in neighboring AS (using solely BGP information to make their routing decisions) will not propagate transit traffic toward your AS.

Implementing Non-Transit Autonomous System

A non-transit AS is usually implemented with route filters on all external BGP (EBGP) connections. At the very minimum, as described in the design section, these filters should pass the routes originated in the non-transit AS and drop all other routes. A more complete implementation would also filter outbound IP prefixes to ensure that your AS is advertising only those prefixes that were assigned to you by your RIR.

Simple AS-path filters

On a router running Cisco IOS, use the following commands to implement the desired route filters:

• Define an AS-path access list (a filter acting on the contents of the AS path attribute of BGP routes) that permits only routes originated in local AS (routes with empty AS path):

ip as-path access-list 1 permit ^$

• Apply the AS-path access list as an outbound filter on all external BGP connections with the neighbor filter-list out command:

router bgp 65000
 neighbor 10.1.1.1 description ISP-A
 neighbor 10.1.1.1 filter-list 1 out
 neighbor 10.2.2.2 description ISP-B
 neighbor 10.2.2.2 filter-list 1 out

Outbound prefix filters

Every autonomous system in the Internet should originate only those prefixes that were assigned to it by a RIR. A failure to implement proper filters on the end-user and/or the ISP side can lead to unintentional accidents with global reach or even malicious attacks like the one launched on YouTube in February 2008.

On Cisco IOS, IP prefixes can be filtered in outbound BGP advertisements with the prefix-list feature:

• Create an ip prefix-list that exactly matches those prefixes you want to advertise (there should be no range matches with ge or le keywords). For example, if you want to advertise 10.0.8.0/22 and 10.0.10.0/24, your prefix list should look like this:

ip prefix-list MyPublicPrefixes seq 5 permit 10.0.8.0/22
ip prefix-list MyPublicPrefixes seq 10 permit 10.0.10.0/24

• Apply the ip prefix-list to outbound EBGP updates with the prefix-list out router configuration command, for example:

router bgp 65000
 neighbor 10.1.1.1 prefix-list MyPublicPrefixes out
 neighbor 10.2.2.2 prefix-list MyPublicPrefixes out

Inbound prefix filters

An autonomous system should actively protect its address space from outside spoofing attempts. For example, if your AS accepts a very specific BGP route (for example, a host route) for an IP address in your own address space, the intruder can redirect all the traffic for that specific host (or server) from your own AS to an external IP host.

Like with the outbound prefix filters, the ip prefix-list should be used on a router running Cisco IOS to protect the address space of the AS. When used in the public Internet, the same prefix-list should also drop all prefixes from the private IP address space. The inbound prefix-list should drop all prefixes belonging to the specified address space regardless of their subnet mask (using the le 32 keyword).

For example, if your AS has been assigned IP prefixes 10.0.8.0/22 and 10.0.10.0/24, the inbound ip prefix-list should start with the following deny statements:

ip prefix-list ProtectMyPrefixes seq 5 deny 10.0.8.0/22 le 32
ip prefix-list ProtectMyPrefixes seq 10 deny 10.0.10.0/24 le 32

Optionally, you could add entries that would drop all private IP addresses:

ip prefix-list ProtectMyPrefixes seq 20 deny 10.0.0.0/8 le 32
ip prefix-list ProtectMyPrefixes seq 21 deny 172.16.0.0/12 le 32
ip prefix-list ProtectMyPrefixes seq 22 deny 192.168.0.0/16 le 32

The last entry in the prefix-list should permit all other IP prefixes (like an access-list a prefix-list has an implicit deny all at the end):

ip prefix-list ProtectMyPrefixes seq 30 permit 0.0.0.0/0 le 32

The ip prefix-list is applied to inbound BGP updates with the neighbor prefix-list in router configuration command.

router bgp 65000
 neighbor 10.1.1.1 prefix-list ProtectMyPrefixes in 
 neighbor 10.2.2.2 prefix-list ProtectMyPrefixes in