Anti-Spoofing


MANRS Implementation Guide


4.3. Anti-Spoofing – Preventing traffic with spoofed source IP addresses

Relevant MANRS expected actions:

  • Network operator implements a system that enables source address validation for at least single-homed stub customer networks, their own end-users and infrastructure. Network operator implements anti-spoofing filtering to prevent packets with incorrect source IP address from entering and leaving the network.

IP source address spoofing is the practice of originating IP datagrams with source addresses other than those assigned to the host of origin. In simple terms, the host pretends to be some other host. This can be exploited in various ways, most notably to execute Denial of Service (DoS) reflection-amplification attacks that cause a reflector host to send traffic to the spoofed address.

There are many recommendations to prevent IP spoofing by ingress filtering, e.g. checking source addresses of IP datagrams close to the network edge. Most equipment vendors support ingress filtering in some form. Since 2005, deployment of anti-spoofing techniques has not been a limitation of the equipment performance. It has been a limitation of desire and willingness to deploy and maintain the anti-spoofing configuration.

Ironically, significant DoS amplification attacks can be expensive for Service Providers. The costs hurt the brand, damage customer operations, and have collateral operational/cost impact on other customers. These DoS amplification attacks are preventable. They would be impossible without spoofing.

This demonstrates that ingress filtering is definitely not sufficiently deployed. Unfortunately, there are no benefits to a Service provider (SP) that deploys ingress filtering. There is also a widely held belief that ingress filtering only helps when it is universally deployed.

Common approaches to this problem have involved software features such as SAV (Source- Address Validation) on cable-modem networks or strict uRPF (unicast Reverse-Path Forwarding) validation on router networks. These methods can ease the overhead of administration in cases where routing and topology is relatively dynamic. Another approach could be to use inbound prefix filter information to create a packet-filter, which would only allow packets with source IP addresses for which the network could legitimately advertise reachability.

For most smaller and simpler network architectures the easiest way to prevent spoofing is by using Unicast RPF (uRPF) in Strict Mode. For filtering source addresses used by devices on a layer-2 domain the Source Address Validation Improvements (SAVI) can be used. On equipment where automatic filtering features are not available you can use Access Control Lists (ACLs) to manually implement equivalent filtering. All of these technologies are explained below.

4.3.1. Guiding Principles for Anti-Spoofing Architectures

To be as effective as possible anti-spoofing techniques should be applied as close to the source as possible. In enterprise networks, the source addresses used by every device are often controlled and enforced so that security audits can pinpoint exactly which device sent which packet.

For a successful implementation of MANRS, such fine granularity at the device level is not necessary as MANRS focuses on routing security and anti-spoofing on a network level. Therefore common anti-spoofing architectures focus on making sure that customers don’t send packets with the wrong source addresses.

Enforcing the use of valid source addresses on a customer level has the benefit that customers can’t spoof each other’s addresses, which prevents them from causing problems for each other that are hard to debug.

If for some reason it is not possible to enforce source address usage per customer, then an alternative is to enforce it at aggregation points so that customers are at least limited in which addresses they can spoof. At a minimum there should be anti-spoofing at the ISP level so that customers can’t spoof addresses of other organisations and cause trouble on an Internet-wide scale.

4.3.2. Unicast RPF

BCP38 uRPF Strict Mode with RFC1998++ style of multihoming (a BCP for multihoming) is an approach that works in symmetrical (single homed) and asymmetrical (multihomed BGP) configurations, and was first operationally deployed in 2002. Yes, there are many who think that “uRPF doesn’t work because of routing asymmetry”, but this is not true. Documentation from 2001, the ISP Essentials whitepaper (Google for version 2.9) and the ISP Essentials book (ISBN 1587050412) along with deployments in several major SPs have demonstrated that uRPF strict mode is a viable technique.

There are four algorithms for uRPF – Strict Mode (check source IP and adjacency), Loose Mode (check only source IP), Feasible Path (check source IP with the FIB’s alternatives), and VRF Mode (permit/deny check on source in a separate table from the FIB). Each of these urPF options are designed for specific “anti-spoofing” functions in different parts of the network.

  • uRPF Strict Mode – BCP38 on the customer-SP edge. Each incoming packet is tested against the FIB and if the incoming interface is not the best reverse path, the packet is dropped.
  • uRPF Loose Mode – sRTBH anywhere in the network – but only check if the route is in the FIB. If not in the FIB, then drop. If it is in the FIB, then pass. Good for sRTBH and mitigating some spoofed traffic on the peering edge.
  • uRPF Feasible Path – sRTBH anywhere in the network and BCP38 for multihomed customers and asymmetrical routes. In the feasible mode the FIB maintains alternate routes to a given IP address. If the incoming interface matches with any of the routes associated with the IP address, then the packet is forwarded. Otherwise the packet is dropped.
  • uRPF VRF Mode – BGP based Peering Policy Enforcement or more granular sRTBH (NOTE VRF Mode might be used as BCP38, but is has not been operationally proven)

uRPF can be useful in many places in the network. It is most often used on the edges of the networks where customers, servers and/or clients are connected because Strict Mode works well there. Network operators are hesitant to use uRPF in the core of their networks because of the fear of accidentally dropping valid traffic that has taken an unexpected path through their network. uRPF Feasible Path mode should solve such problems.

Both Cisco and Juniper implement both strict mode and loose mode. We show how to use strict mode. Configure uRPF Strict Mode on interfaces towards customers with:

Cisco:


    ip verify unicast source reachable-via rx
    ipv6 verify unicast source reachable-via rx

Juniper:


    family inet {
        rpf-check;
    }
    family inet6 {
        rpf-check;
    }

That will make sure that the customer can only use IP addresses that you route to them. In situations where you are the customer of another ISP where you have a default route pointing to that ISP you should use:

Cisco:


    ip verify unicast source reachable-via rx allow-default
    ipv6 verify unicast source reachable-via rx allow-default

Juniper:

Juniper routers automatically adapt their uRPF filtering based on where any default routes are pointing towards. Just use the same commands as above.

The allow-default option is necessary because by default the source addresses will be matched only against specific routes, ignoring the default route. While matching against the default route seems to be the same as allowing anything, it isn’t. It makes sure that your upstream doesn’t send you traffic for which you have other more-specific routes pointing in a different direction, such as your own networks and your customers’ networks. This will protect you against spoofed traffic from others.

4.3.3. Dynamic Access List (Radius & Diameter)

The standard way to set access lists for Radius-authenticated users is through Radius attribute 11 (Filter-Id). With this attribute you can tell the router to apply a pre-existing access list to the user’s connection. This does require an out-of-band method to provision all routers with the correct access lists though.

Some vendors have extra Radius options that can be used to dynamically provision the access list itself through Radius. Cisco for example provides extra functionality through cisco-avpair attributes:


     cisco-avpair = "ip:inacl#5=permit ip 192.0.2.0 0.0.0.255 any"
     cisco-avpair = "ip:inacl#99=deny ip any any"

This would only allow packets from the customer that have a source address in the 192.0.2.0/24 range.

4.3.4. SAVI

SAVI is the name of the IETF working group that works on Source Address Validation Improvements. For the validation of a customer’s source address, the SAVI for DHCP solution in RFC 7513 is commonly used. This version of SAVI keeps track of all the IP addresses that have been assigned to each device by snooping on the DHCPv4 and DHCPv6 message exchanges on the network switch that the customer is connected to. If a customer uses an unauthorised source address the switch will drop the packet.

Vendors often use their own terminology to describe SAVI features. On Cisco devices these features are referred to as DHCP Snooping, Source Guard and Prefix Guard.

4.3.5. IP Verify Source

Ethernet networks are broadcast domains, and by default there is no validation of who is allowed to send packets with which addresses. To configure Cisco switches to verify the source addresses used by the connected devices the “ip verify source” setting can be used.

There are three variants of this feature:
ip verify source
ip verify source port-security
ip verify source tracking port-security

The first variant verifies the source IP address, the second variant also verifies the source MAC address and the third variant tracks the bindings between IP address and MAC address. To prevent customers from using another customer’s MAC address the last variant is recommended. All of these base their decision on snooped DHCP data.

Before being able to verify source addresses the switch must be configured to snoop DHCP traffic to collect data to base its decisions on with ip dhcp snooping. To keep track of which ethernet port connects to each DHCP client use DHCP option 82 with ip dhcp snooping information option. This is necessary because with verify port-security the switch will not learn MAC addresses until the DHCP server has assigned an IP address to the connected device. Option 82 is therefore necessary to remind the switch where the client was connected.

There are several steps necessary to enable secure tracking of devices and verify their source addresses. The first step is to enable “ip device tracking” globally on the switch. This makes sure that the switch can track which IP address belongs to which MAC address. Then on each interface, define the number of devices that are allowed to connect with ip device tracking maximum num where num can be a number from 1 to 10. Now enable switchport port-security on each interface to ensure that only allowed MAC addresses are used. And finally enable the verification feature that links all these together with ip verify source tracking port-security.

Now the switch has all the information it needs to snoop DHCP traffic, link the IP addresses to MAC addresses and verify that all packets sent through the switch conform to the collected state which is based on responses from the DHCP server. Packets that do not conform to what the DHCP server has assigned will be dropped.

4.3.6. Cable Source-Verify

Cable modem networks are in many ways similar to ethernet networks. Unless configured otherwise, users can spoof source addresses or steal the addresses of other users on the cable network. The Cisco cable source-verify feature allows the CMTS operator to limit which source addresses a user is allowed to use.

There are two variants of this feature:

cable source-verify
cable source-verify dhcp

Both variants affect which addresses from the cable network’s subnet are allowed to be used. The first variant only prevents users from stealing each other’s addresses and is therefore not sufficient for MANRS. We will look at the second variant.

Configuring cable source-verify dhcp tells the CMTS that all source addresses must be verified against DHCP leases that the CMTS has seen. If a packet is sent with a different source the CMTS will drop it. This will prevent users from using addresses not assigned to them via DHCP .

Problems can occur when the CMTS is reloaded. In such a case the CMTS won’t know all the DHCP leases from its users and might drop legitimate traffic. To solve this the CMTS can be configured to use the DHCP LeaseQuery protocol. This allows the CMTS to ask the DHCP server about leases for traffic it is seeing. Once the DHCP server confirms that there is a legitimate lease for that address the CMTS will add it to its cache and allow the traffic through.

To configure the CMTS to not trust ARP on the cable network configure it with no cable arp. This will make sure that only information learned from DHCP and LeaseQuery is trusted when verifying source addresses.

The cable source-verify feature only protects the subnet of the cable network itself. To prevent users from spoofing other addresses, and to allow traffic from customers that have a routed subnet which they are allowed to use, also configure ip verify unicast source reachable-via rx to enable uRPF Strict Mode on the cable network. That will check all source addresses that are not directly on the cable network and allow validating against for example static routes for routed subnets towards customers.

4.3.7. Access Control List (ACLs)

ACLs are commonly deployed on the Provider Edge (PE) – Customer Edge (CE) boundary, but are also very useful in other places like towards the provider’s own server, client and infrastructure networks to prevent devices there from misbehaving. Optimized ACL strategy would be to place an explicit permit filter on the customer interface. Explicit permit filters permit specific address ranges and then deny all else. For example, if a Operator’s customer is allocated 192.0.2.0/24, the BCP 38 ACL would permit all source addresses from 192.0.2.0/24 and then deny all packets whose source address is not 192.0.2.0/24.

Fig 2. Ingress filtering on a PE router
BCP 38 Filter = Allow only packets with source IP addresses from the customer’s networks (2001:db8:1001::/48, 2001:db8:2002::/48, 192.0.2.0/24, 198.51.100.0/24)

On the downstream interfaces of the ISP, there should be filters that verify the source addresses used by its customers. If uRPF cannot be used then manual ACLs are necessary. Let’s take the first customer from the example diagram above:

Cisco:


    ip access-list extended customer1-in-ipv4 
      permit ip 192.0.2.0 0.0.0.255 any
    !
    ipv6 access-list customer1-in-ipv6
      permit ipv6 2001:db8:1001::/48 any 
    !
    interface x
      ip access-group customer1-in-ipv4 in ipv6 
      traffic-filter customer1-in-ipv6 in

Juniper:


    firewall {
        family inet {
            filter customer1 - in -ipv4 {
                term allowed - sources {
                    from {
                        source - address {
                            192.0 .2 .0 / 24;
                        }
                    }
                    then accept;
                }
            }
        }
        family inet6 {
            filter customer1 - in -ipv6 {
                term allowed - sources {
                    from {
                        source - address {
                            2001: db8: 1001::/48;
                        }
                    }
                    then accept;
                }
            }
        }
    }
    interfaces x {
        unit 0 {
            family inet {
                filter {
                    input customer1 - in -ipv4;
                }
            }
            family inet6 {
                filter {
                    input customer1 - in -ipv6;
                }
            }
        }
    }

4.3.7.1. Aggregation Points

When ACLs at the PE-CE boundary are not possible, for example because multiple customers are connected to a single layer-2 network and the layer-2 devices do not have the features to filter on layer-3 information, then filtering at an aggregation point is the second-best solution.

Fig 3. Ingress filtering on the aggregation router
BCP 38 Filter = Allow only packets with source IP addresses from the customer’s networks, aggregated (2001:db8:1000::/44, 2001:db8:2000::/44, 192.0.2.0/23, 198.51.100.0/23)

In this example it is (for some unspecified reason) not possible to filter on the /24 for each customer. In that case filtering on 192.0.2.0/23 and 198.51.100.0/23 (and similarly for IPv6) at an aggregation point close to the customer connections would at least limit the spoofing possibilities for that group of customers to a small range of addresses.

Configuration is done in the same way as shown in the previous section, except now it is done on a different router in a more central location in the network.

4.3.8. Carrier Grade NAT – Is NAT an Anti-Spoof Tool?

By default many NAT implementations do not filter the source address of the clients. Take for example a simple NAT configuration on a Cisco router like:

  ip nat inside source list INSIDE pool OUTSIDE overload

This NAT rule will translate packets with a source address in access list INSIDE and change the source address to an address in the pool OUTSIDE. However, packets that have a spoofed source address that is not included in the INSIDE access list will be forwarded without any translation, resulting in spoofed packets on the Internet. When a spoofed packet does match the access list it will be translated using the specified pool, so the outside world does not see a spoofed source address, but it will be impossible for the NAT operator to trace the spoofed packets back to their originator.

This shows that NAT is not an anti-spoofing tool. Even when using NAT the source addresses used by customers must be checked as close to the customer as possible, just like in the cases without NAT shown earlier in this chapter. Only then can spoofed and/or untraceable packets be prevented to reach the Internet.

4.3.9. Additional reading