RIPE Anti-Spoofing Task Force HOW-TOripe-431: This document presents practical recommendations for the implementation of anti-spoofing mechanisms at the critical points of the network infrastructure of carriers and/or ISPs.https://www.ripe.net/publications/docs/ripe-431https://www.ripe.net/logo.png

RIPE Anti-Spoofing Task Force HOW-TO

Publication date: 09 May 2008

Introduction

This document presents practical recommendations for the implementation of anti-spoofing mechanisms at the critical points of the network infrastructure of carriers and/or ISPs.

These practical recommendations are based on the experience of the editors and collaborators and on previous existing work, like existing best common practices [1].

Overview

This document starts with an enumeration of the most common attacks that networks connected to the Internet suffer today, followed by a brief description of the countermeasures that can be used to avoid or, at least, reduce the impact of these attacks.

Finally, a set of recipes implementing these countermeasures in mainstream routers is presented in a way that is easy to deploy in a network.

Definitions

CPE: Customer Premises Equipment: a router placed in an end-user office that connects to both the end-user network and the provider network, usually through a point-to-point link.

DFZ: Default Free Zone: the set of routers in the Internet that do not use a default route and that need to keep the full routing table in their memory.

PE: Provider Edge: a router located in the provider network that connects directly with one or more CPEs.

Common aspects related to IP networking

Filtering prefixes

Why to filter

The amount and severity of security incidents involving spoofed IP addresses is increasing. This suggests that applying some level of control over the correctness of the source IP address of packets can mitigate the impact of the attacks on the infrastructure. Also, the blocking of spoofed address would help to find the origin of such attacks.

What to filter

IP traffic with a source address belonging to prefixes that should not be on the routing table of routers connected to (or that forward traffic from/to) the public Internet should be filtered. The most common list of these prefixes is the so-called bogon list [2].

Where to filter

The nearer the filters are applied to the origination of the spoofed traffic, the better the effects on the security and reliability of the hosts and the network will be.

Unicast Reverse Path Forwarding (uRPF) Mechanism(s)

uRPF [3] is a mechanism where routers check whether the source address of a received packet exists in the routing table. If it does not appear in the routing table, the packet is blocked. Various options exist regarding the strictness:

Strict uRPF will drop the packet unless the best route to the source address is through the interface on which the packet was received

Feasible path uRPF will drop the packet unless a route (not necessarily the best) to the source address is through the interface on which the packet was received. Feasible path uRPF prevents issues in asymmetric and multihomed scenarios

Loose uRPF will drop the packet unless a route to the source address exists. The interface is irrelevant for this type. A variation of this mechanism allows ignoring the existence of default routes in the forwarding table.

The exact conditions for choosing one of these mechanisms are hard to describe, but the following rules of thumb apply:

Networks that apply strict uRPF must keep their routing symmetric. Strict uRPF can be problematic on peering routers that exchange routes with other ISPs (“hot potato“ routing, BGP filtering in both directions of the peering due to different routing policies). It can also cause problems in networks that have different links to other networks

Other filters: bogon prefix filtering

What are bogon prefixes?

A bogon prefix as defined by Cymru [1] is “a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks”.

For the purpose of this how-to, a packet received on an interface of a router is considered bogon if it's source address should not be routable through that interface. This definition of bogon includes “martian” addresses (as listed in RFC 1918 and RFC 3330) and unallocated addresses as explained in the next subsection. Also included are addresses from networks that are always connected to other interfaces of the router.

Why filter bogons?

The Cymru document states that, according to some measurements, up to 60% of the IP addresses used in attacks are bogon. Filtering these addresses will greatly reduce the impact of such attacks.

How to build the filters

There are two basic methods:

On interfaces connected to the Internet, the easiest way is to create a list of denied networks and block these

On interfaces connected to a reduced set of networks, or only internal networks, it is usually easier create a list of allowed networks and allowing only these networks

In the first case, the filters have a static part and a dynamic part. The static part contains the martian addresses and the static networks inside the organisation. The dynamic part contains, at least, the list of otherwise valid addresses that have not been allocated from the IANA to the RIRs yet (see next section).

Unallocated addresses

One special case of bogon networks is unallocated address space. Unallocated addresses are blocks of public address space that have not been allocated by the IANA to the RIRs yet, but that could be allocated in the future. This means that some of the networks that make up this list today should be removed once they have been assigned. If they are not removed after being allocated, there is a risk that portions of the Internet will be blocked to customers. For transit providers, this problem can be very difficult to debug.

Therefore, it is important to keep these lists up-to-date. Manual maintenance often comes with problems, so it is strongly recommended to use some kind of automation. The Team Cymru Bogon Reference Page [2] provides more information on automatic generation of these filters.

Vendor specifics

Cisco features

Cisco routers support both strict and loose uRPF. CEF is necessary for uRPF. Therefore, uRPF is incompatible with solutions that disable CEF.

Source routing is disabled by default in Cisco routers, although it can be enabled in the configuration.

On Cisco routers, it is possible to filter packets based on source IP address without loading the router CPU too much.

Juniper features

Juniper routers support both strict and loose uRPF, if they are equipped with the (relatively) new Internet Processor II ASIC.

Source routing is enabled by default in Juniper routers. This can be a threat for connected networks. Therefore, it is recommended to disable this feature.

On Juniper routers, it is possible to filter packets based on source IP address without loading the router CPU too much.

Scenarios

Several different scenarios are examined, each with examples of how the filtering can be configured.

Customer/provider scenarios

The scenarios in this section all focus on a clear separation between router(s) at the customer's side (CPE) and the connected router(s) on the provider side (PE).

One customer router, single provider with one router

In this scenario, there is a single link between the customer and the provider's access router. This would often be done with a /30 or /31 from the provider's PA range.

In many cases, the link will use public addresses, but in some cases, NAT is used with private addresses.

The routing between the customer and the provider in this scenario is static.

On both routers in this scenario, filters can either be maintained manually and/or uRPF can be used to filter automatically. The former can be more accurate, but it is harder to maintain. It will also put a bigger load on the router. Manual lists are recommended over uRPF when the traffic exceeds 1 Mbit/s. If access lists are implemented, uRPF is mostly redundant.

Cisco version

Configuration on the customer router (CPE)

! CEF is needed for uRPFip cefinterface ATM0/1.1 point-to-point description Interface to provider ip address 89.107.53.2 255.255.255.252 ! Packets are filtered based on a static list ip access-group bogons in ! Strict uRPF can also be used, although ! it is redundant in this case ! Note that allow-default is set, to permit ! uRPF to allow a packet based on a default route ip verify unicast reachable-via rx allow-default... ! Default route to the providerip route 0.0.0.0 0.0.0.0 ATM0/1.1...! Manually maintained list of networks to be filtered! These are the private and reserved networksip access-list extended bogons deny ip 10.0.0.0 0.255.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 127.0.0.0 0.255.255.255 any deny ip 169.254.0.0 0.0.255.255 any deny ip 192.0.2.0 0.0.0.255 any deny ip 198.18.0.0 0.1.255.255 any deny ip 240.0.0.0 15.255.255.255 any ! If a public range was assigned to this network, ! these addresses can't be received from the outside deny ip 89.107.52.0 0.0.0.255 any ! External address of this router deny ip 89.107.53.2 0.0.0.0 any permit ip any any

Configuration on the provider router (PE)

! CEF is needed for uRPFip cefinterface ATM0/1.1 point-to-point description Interface to customer ip address 89.107.53.1 255.255.255.252 ! Static filter based on the public addresses ! of the customer ip access-group customer-routes in ! Strict uRPF can also be used here ! allow-default is not used, because a customer link ! should not be a default route ip verify unicast reachable-via rx...! Static networks to filterip access-list extended customer-routes ! Allow the IP address of the customer's router permit ip 89.107.53.2 0.0.0.0 any ! If the customer has a public range assigned, allow it permit ip 89.107.52.0 0.0.0.255 any ! Deny anything else deny ip any any

Multiple customer routers, single provider with one router

In this scenario, multiple routers at the customer's side are connected to one router at the provider's side. Each route between the customer's and the provider's routers will be static and will have different metrics for each path, with one path being the default active in both ways and the other path the default passive in both ways. Using the same kind of metrics on both sides is important: If one side would use one path as “best“ and the other side would use the other one, strict uRPF would block the traffic.

Each router has a link between customer's and provider's router, commonly using /30 or /31 range from the provider's PA range. The customer will have a public range from the PA space allocated to the provider.

The CPEs would often use VRRP or a similar mechanism to provide automatic failover. More weight would be on the CPE with the best link. The CPEs each have two default routes: one through its link to the provider and another through the other router with a lower weight.

On the PE, routes are set to the customer's network through both links. The preferred link has a higher weight.

The customer's routers can implement the same filtering that was described for the previous scenario. Filtering is only applied to the incoming routes from the provider network; no filtering is applied to the routes coming from the customer network itself. uRPF is enabled, in strict mode.

Multiple routers, single provider with multiple routers

In this scenario, multiple routers at the customer's side connect to multiple routers on the provider's side. On the customer's side, this scenario is almost the same as the previous scenario.

On the provider's side, a system like HSRP or VRRP can be used. However, the use of a dynamic routing protocol inside the provider's network is more common. This would then be used to announce the customer's networks into the provider's network. A higher weight is used for the preferred link.

Even though both scenarios are different at a routing level, they are similar when seen from the spoofing security level; strict uRPF and similar static filters can be used.

It is important to keep in mind that, for the uRPF configuration to work, both sides (customer and provider) must select the same link as “active”. If they select a different link as active, uRPF will block all traffic.

Single customer outer, multiple providers, load balancing

In this scenario, a single router (CPE) has links to separate links to different providers. This is one of the most common multihoming scenarios. The CPE selects the best route through various mechanisms, like static routing or BGP. The CPE can peer with each ISP over BGP, announcing the customer's PI space, PA space assigned to the customer or a combination of these.

CPE interfaces to the transit providers

The CPE will accept a set of routes from the transit providers. In some cases, default routes can be assigned to one or more (in case of resilient links) of the provider interfaces. In other cases, BGP will select the best available route.

At these transit interfaces, anti-spoofing measures can include:

Bogon filtering via access-lists (see section 4.1.4 )

Loose uRPF, or if available, feasible path uRPF. This can be activated for each interface that is connected to one of the providers (interfaces 3 and 4 of the Figure 5.1-1) by using the following commands:

CPE interfaces to the customer's network

If the CPE has interfaces that connect to the customer's network, using public addressing, various anti-spoofing measures can be used.

Which measures fit best, depend on whether there is more than one CPE interface per network. In this context, two networks are seen as separate when they use different addresses.

Single interface per network

When no more than one interface per network is used, strict uRPF can be applied to each of the CPE interfaces that are connected to the customer's networks. This will help drop spoofed traffic from hosts inside the customer's networks, generated by, for example, botnets.

Multiple interfaces per network

Where more than one interface per network is used, asymmetric routing may occur. Therefore, strict uRPF may drop legitimate traffic in situations where no default route is present. Feasible-path uRPF will have to be used or, if feasible-path is unavailable, loose uRPF.

In the figure 5.1-2, all the interfaces will operate in loose or feasible-path uRPF mode. In case the customer's routers have a default route configured, only interfaces 9 and 10 will have loose or feasible-path uRPF configured.

Customer access networks

Customer access networks are the equipment deployed by ISPs and carriers to aggregate a large number of customers (e.g. broadband concentrators, dial-up RAS, etc.)

This equipment generally has:

Point-to-point interfaces to customers, one interface per customer, with a prefix assigned to each customer interface

One or more transit interfaces connected to the Internet

In this case, strict uRPF can be configured on the interfaces facing customers. These interfaces are one of the best-suited uses for uRPF, as IP addresses are often assigned dynamically (for example, with a RADIUS server). This makes the use of static filters impossible.

IPv6

Although IPv6 is not very widely deployed yet, the recommendation is to implement anti-spoofing filters for it. The preferred solution is uRPF, but static filters based on martian addresses and bogon lists are also possible. A large part of the content of this chapter is extracted from the excellent page created by Gert Döring [5]. A complete list of bogon addresses in IPv6 can be obtained from Team Cymru [6].

Many of the recommendations for IPv6 are similar to those stated for IPv4.

uRPF

Cisco routers

uRPF is available for IPv6 on Cisco high end series (12000, 7600 and so on) as of release 12.0(31)S.

The commands to configure uRPF for IPv6 are almost exactly the same as for IPv4. The only difference is that “ip” should be replaced by “ipv6”. For example, to use uRPF for IPv4 and IPv6, replace:

Juniper routers

Routes From Peers

If static filters are used for routes received from peers, a strategy similar to that for IPv4 must be applied. These filters block packets using bogon addresses, but do not take possible other issues into account.

Blocking Martians

In the simplest case, all known martians are blocked. The martians are:

3FFE::/16 - used for 6bone in the past

2001:db8::/32 – reserved for documentation

0000::/8 – used for loopback, IPv4 mapping, etc.

FE00::/9 and FF00::/8

2001:4030:f::/48 – example range for the internal network in this example

Conclusion

The application of one or more of these guidelines will not assure that all attacks can be stopped. Even some attacks that use spoofed addresses will not be stopped. For example, if the attack comes from a different network, that did not apply the recommendations as stated in this document, the computers in that network can use any address on the Internet without being detected.

However, if all ISPs would implement these measures, the usability of spoofed IP addresses for attacks would be dramatically limited and the origin of malicious packets would be a lot easier to discover. Even if not all ISPs implement these guidelines, their use can still prevent some attacks. This includes one of the most dangerous attacks: those that use spoofed addresses from your own networks

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacy policy. You can accept our cookies either by clicking here or by continuing to use the site.