Ingress/Egress Filtering
One of the important aspects of perimeter security is filtering at an organization's borders. If you are a service provider, your network borders are customers and other service providers. If you are an enterprise, your network borders are ISPs and other business partner organizations. There are commonalities in the filtering of route advertisements done by service providers and the route filtering done by their customers. One key difference involves the way IPv6 routes are filtered at the Internet's edge. One commonality is the filtering of bogus addresses that should not be used in either the source address or the destination address header field. The following sections describe the different methods of filtering routes and give example of how to filter allocated and bogus IPv6 address prefixes.
Filtering IPv6 Traffic
Service providers typically do not filter individual customer packets traversing their networks based on the packet's contents. However, they should help protect the Internet and their own infrastructure by performing filtering at their perimeters. BCP 84/RFC 3704, "Ingress Filtering for Multihomed Networks," (Best Current Practice [BCP] 84) covers the practice for IPv4 networks. Now these same principles can be extended to IPv6 networks.
Performing IPv6 traffic filtering for high-speed links would require systems that can perform filtering in hardware. Service providers could also filter packets that do not conform to the IPv6 specifications. The points where a service provider network touches customers and other providers are locations where the filtering should occur. This type of filtering is not done by firewalls on the traffic itself but rather on the routing update exchanges.
Filtering on Allocated Addresses
With IPv4, customers can get address allocations from their provider and also obtain their own address space. In IPv6, the intent is to require all customers to get their allocations from their service provider. The service providers receive their addresses from the Regional Internet Registries (RIR), who in turn receive their allocations from the Internet Assigned Numbers Authority (IANA). This creates a fully hierarchical addressing structure that maximizes the use of aggregation and is sure to reduce the size of the Internet routing table. RIRs can also assign provider independent (PI) address blocks to customers. However, these blocks might not be allowed to be routed on the Internet, even if it can be expected that more and more ISPs will have to allow the transit traffic destined to PI addresses.
ISPs need to be careful about the address space that they are using and assigning to customers. Filtering what you are advertising and what you are receiving over peers also helps prevent many types of BGP threats. Receiving more-specific routes, less specific routes, routes for unallocated space, and malicious routes are threats that can all be prevented through careful filtering of routes. Receiving many of these different types of routes can either be accidental or malicious on the customer's part, and you might not know which. Being overly permissive on the types of routes allowed to be advertised to the ISP from customers is not wise. Distribute lists, prefix lists, and route maps can all be used to control what routes are being sent and received.
You might not want to accept more specific routes from customers or peers because that could be one way that an attack takes place. Because the minimum allocation size is a /48, service providers might also want to simply reject any /49 or longer prefix. Therefore, you might not want to accept a BGP advertisement with anything smaller than a /48, regardless of the prefix. BGP also makes the assumption that a peer has the authority to advertise the prefix and autonomous system (AS) paths. If these are falsified, all types of routing instability can occur.
ISPs have the responsibility to perform careful filtering of customer routes. There are many address blocks that a service provider should not receive from a customer or a peer. The ISP must also allow the customer to be able to route its traffic to and from the Internet. These customer routes must be filtered at the point where the two networks meet. It is also a good practice for the service provider to check the regional registry to make sure that the customer is the rightful owner of the prefix. This can be done with whois information from the Shared WHOIS Project (SWIP). For example, if a customer is assigned the address block 2001:db8:100::/48, the inbound prefix list permitting this advertised route would look like the configuration shown in Example 3-3. This example shows a prefix list that would allow only the customer's block and nothing else.
Example 3-3. Filtering Customer Address Assignment
ipv6 prefix-list v6-cust-routes permit 2001:db8:100:100::/48 ipv6 prefix-list v6-cust-routes deny ::/0 le 128 ! route-map CUSTROUTES permit 10 match ipv6 address prefix-list v6-cust-routes ! router bgp 100 neighbor 2001:db8:100:100::1 remote-as 200 neighbor 2001:db8:100:100::1 route-map CUSTROUTES in
You should disallow overly specific prefixes and disallow any prefix greater than /48. The more-specific /64 route for the customer network is quelled while the aggregate /48 is advertised. Some ISPs can elect to allow more-specific routes from customers, but they should not be smaller than a /48.
Bogon Filtering
Bogons are the IP address ranges that either have not been allocated or are reserved. The word bogon is a derivative of the word bogus, which means illegitimate or fake and is similar to terms for subatomic particles used in quantum mechanics. The bogons list originated from RFC 3330's list of "Special-Use IPv4 Addresses," and now a similar list of "Special-Use IPv6 Addresses" is documented in RFC 5156. Packets with these addresses, either used as source addresses or destination addresses, should not be routed on the Internet. These are often blocked at IPv4 routers explicitly because there are a finite number of these. Lists are maintained that contain the IPv4 address space, and service providers and other organizations use these bogon lists. The bogon lists help to craft filters to prevent these packets from traversing network perimeters.
The list of valid IPv6 address blocks is maintained by the IANA. This list shows the address space allocations and the organizations responsible for maintaining that address space. At the time that this book is written, the current allocations are listed at the following URL:
The IANA has also made special registrations of address spaces for specific purposes. This is done because there are times when addresses are required for a specific purpose, but these addresses will not be allocated to an organization. The IANA Special Purpose Address Registry is defined by RFC 4773, "Administration of the IANA Special Purpose IPv6 Address Block," and is available at http://www.iana.org/assignments/iana-ipv6-special-registry.
In general, you should always filter packets coming to you that are sourced from bogon addresses. This is a good goal, but it also means that you need to stay on top of the allocations as they are made and adjust the filter lists accordingly. These bogon lists can change several times each year.
You should also take into consideration the address space that you have been allocated as a service provider. Service providers have out-of-band management networks. Filtering these internal addresses at the borders of the service provider can help prevent attacks against the back-office/internal systems (that is, billing, management, and so on). You should filter the infrastructure addresses that are used by your network equipment and router interfaces. Therefore, you must filter packets coming to you from your own allocated address space. This can be done at your network perimeters with the use of Unicast Reverse Path Forwarding (Unicast RPF) checks. You should also deny your own allocated address space from being advertised to you from a customer or any peer. You know about your addresses, and you should not let anyone tell you any differently. That should protect anyone from trying to destabilize your routing.
Many other prefixes should be denied inbound and outbound at your network perimeters. Table 3-1 gives the list of the routes that should be filtered from entering or leaving your network. These should not be advertised to you from any customer or peer, and you should also prevent yourself from advertising these.
Table 3-1. Prefixes That Should Be Blocked
|
Routes to Block |
Prefixes |
|
Default route |
::/0 |
|
Unspecified address |
::/128 |
|
Loopback address |
::1/128 |
|
IPv4-compatible addresses |
::/96 |
|
IPv4-mapped addresses |
::ffff:0.0.0.0/96 |
|
Link-local addresses |
fe80::/10 or longer |
|
Site-local addresses (deprecated) |
fec0::/10 or longer |
|
Unique-local addresses |
fc00::/7 or longer |
|
Multicast addresses |
ff00::/8 or longer |
|
Documentation addresses |
2001:db8::/32 or longer |
|
6Bone addresses (deprecated) |
3ffe::/16 |
Some of the entries in Table 3-1 can be covered with a single prefix. For example, unspecified routes, loopbacks, and IPv4-mapped addresses can all be matched with 0000::/8 or longer.
Because so little of the IPv6 address space has been allocated, it is easier to permit the legitimate route addresses than to try to deny all the routes that should be blocked. Therefore, route filters have permit statements for the legitimate prefixes, and all other routes are blocked by the implicit deny-all at the end of the list. Therefore, the list of allocated IPv6 addresses can be specified within an IOS prefix list and applied to the external interface of an Internet router. Example 3-4 shows an example of this prefix list and indicates how it can be applied to a BGP peer. This filter list comes from the Team Cymru IPv6 bogon filter list for Cisco IOS routers: http://www.cymru.com/Bogons/v6ios.html.
Example 3-4. Bogon Prefix Filter List
ipv6 prefix-list ipv6-global-route deny 2001:0DB8::/32 le 128 IPv6 prefix-list IPv6-global-route deny <your own allocated addresses>/32 ipv6 prefix-list ipv6-global-route permit 2001:0000::/32 ipv6 prefix-list ipv6-global-route permit 2001:0200::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:0400::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:0600::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:0800::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:0A00::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:0C00::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:0E00::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:1200::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:1400::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:1600::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:1800::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:1A00::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:1C00::/22 ge 22 le 64 ipv6 prefix-list ipv6-global-route permit 2001:2000::/20 ge 20 le 64 ipv6 prefix-list ipv6-global-route permit 2001:3000::/21 ge 21 le 64 ipv6 prefix-list ipv6-global-route permit 2001:3800::/22 ge 22 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4000::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4200::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4400::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4600::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4800::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4A00::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:4C00::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2001:5000::/20 ge 20 le 64 ipv6 prefix-list ipv6-global-route permit 2001:8000::/19 ge 19 le 64 ipv6 prefix-list ipv6-global-route permit 2001:A000::/20 ge 20 le 64 ipv6 prefix-list ipv6-global-route permit 2001:B000::/20 ge 20 le 64 ipv6 prefix-list ipv6-global-route permit 2002:0000::/16 ge 16 le 64 ipv6 prefix-list ipv6-global-route permit 2003:0000::/18 ge 18 le 64 ipv6 prefix-list ipv6-global-route permit 2400:0000::/12 ge 12 le 64 ipv6 prefix-list ipv6-global-route permit 2600:0000::/12 ge 12 le 64 ipv6 prefix-list ipv6-global-route permit 2610:0000::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2620:0000::/23 ge 23 le 64 ipv6 prefix-list ipv6-global-route permit 2800:0000::/12 ge 12 le 64 ipv6 prefix-list ipv6-global-route permit 2A00:0000::/12 ge 12 le 64 ipv6 prefix-list ipv6-global-route permit 2C00:0000::/12 ge 12 le 64 ! router bgp 64500 neighbor 2001:db8:1::2 route-map ACCEPT-ROUTES in ! route-map ACCEPT-ROUTES permit 10 match ip address prefix-list ipv6-global-route
Bogon Filtering Challenges and Automation
Filtering what prefixes are advertised by an end-user organization is a best practice. It is also a best practice to filter prefixes from a service provider's other service provider peers. Most peers just permit the /32s that other peers have been allocated. Many service providers trust the peers they connect to and do not perform the necessary filtering to protect the Internet from dramatic problems. These service providers know that filtering bogons from being advertised to them is the right thing to do. However, many service providers cite the fact that bogon filtering can be hard to maintain because it is likely to change. Some service providers manually configure bogon filters, but the updating of the configurations can be automated with some form of script. In fact, when new address space is allocated by the IANA or the registries, the address space is usually given to Tier 1 ISPs because they will start to route the traffic appropriately for their customers.
There are techniques that service providers can use to help alleviate the burden of maintaining peer filters. It is easy to set up an automated method of updating the bogon list on all peering routers. After the filter is updated, you do not need to reset the peer to have the filter activate. When the peers are reset softly or the route flaps, the updates show up in the routing table.
Another technique for filtering routes to a peer is to leverage an Internet Routing Registry (IRR). These databases contain the registered address allocations for other ISPs, and they can help you create the prefix list applied to that peer. Routing Policy Specification Language (RPSL) is defined in RFC 2622 as a language to send and receive information from a registry. Recently, RPSLng (RFC 4012) added IPv6 and multicast support to its set of classes of objects. For example, one of the RPSL classes is called the ROUTE6 object, which contains the identification of the /32 addresses that service providers have been allocated. With objects like this, an IRR can be used to create a specific import or export route filter for the prefixes that should be sent or received from a peer. This would add to the security of IPv6 because filters could be automated and based on accurate sources of allocated and assigned prefixes. For these reasons, the IRRs must be secured, and the validity of the data must be regularly checked.
The historical challenges with IRRs were that the information was not accurate. Because the IPv6 Internet is in its early stages and the current Internet IPv6 routing table has few entries, the data will be easy to validate. Currently the set of IPv6 information in the IRRs would be small and easy to start a clean slate and maintain it. IRRs can help avoid mistakes made by humans and speed deployment through automation. Automation tools exist for IRRs (IRRToolSet, IRR Power Tools) to help create filters for peers and customer connections.