RIPE Anti-Spoofing Task Force. HOW-TO Document Editors: Fernando García (Tecnocom) and Juan P. Cerezo (BT GS) 1. Introduction 2 2. Overview 2 3. Definitions 2 4. Common aspects related to IP networking 2 4.1. IP mechanisms involved 2 4.1.1. Filtering prefixes 2 4.1.2. Unicast Reverse Path Forwarding (uRPF) mechanism(s) 2 4.1.3. Other filters: BOGON networks filtering 3 4.1.4. Unassigned addressing 4 5. Vendor specifics 4 5.1. Cisco features 4 5.2. Juniper features 4 6. Scenarios 4 6.1. Customer/provider scenarios 4 6.1.1. Single router, single provider 4 6.1.1.1. Cisco version 5 6.1.1.2. Juniper Version 6 6.1.2. Multiple routers, single provider with one router, redundant solution 8 6.1.2.1. Cisco version 9 6.1.2.2. Juniper version 10 6.1.3. Multiple routers, single provider with multiple routers, redundant solution 15 6.1.3.1. Cisco version 16 6.1.3.2. Juniper version 17 6.1.4. Single Router, multiple providers, Load balancing 19 6.1.4.1. Transit interfaces of the CPE router 20 6.1.5. CPE inner-networks interfaces 20 6.1.5.1. Single internal interface 20 6.1.6. Multiple internal interfaces 21 6.1.7. Customers access networks 21 6.1.7.1. Customer links 22 6.2. Core networks 22 6.2.1. Cisco routers 22 6.2.2. Juniper routers 23 7. IPv6 24 7.1. uRPF 24 7.1.1. Cisco routers 24 7.2. Routes from customers 25 7.2.1. Cisco routers 25 7.2.2. Juniper routers 25 7.3. Routes from peers 25 7.3.1. Cisco routers 25 7.3.2. Juniper routers 26 8. Conclusion 26 9. References 27 1. Introduction This document presents some 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 also on previous existing work, like the best common practices set as standards[1]. 2. 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 counter measures that can be used to avoid or, at least, reduce the impact of these attacks. Finally, a set of recipes implementing these counter measures in mainstream routers is presented in a way that it is easy to deploy in any operator network. 3. Definitions CEF: Cisco Express Forwarding. A packet switching mode used in Cisco routers that speed up the transmission while reducing CPU load. CPE: Customer Premises Equipment. A router placed in an end user office and 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 at the provider network that connects directly with one or several CPEs. 4. Common aspects related to IP networking 4.1. IP mechanisms involved 4.1.1. Filtering prefixes - Why to filter: The increasing number and severeness of security incidents involving spoofed IP addresses suggests that performing some level of control over the correctness of the source IP address of the traffic packets can mitigate the impact of the attacks on the infrastructure. Also the blocking of spoofed address would help to find the origin of the 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 On the IP hosts (if their TCP/IP stack implements this option), on the customer (CPE) routers or on the ISP infrastructure equipment (access routers and concentrators, DFZ routers). 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. 4.1.2. Unicast Reverse Path Forwarding (uRPF) mechanism(s) - Strict uRPF [3]: It is a mechanism by means of which the source address of a packet received on an interface is looked up in the forwarding table of the router. If the source address is reachable through the same interface on which the packet was received, the packet will be processed by the router. Otherwise, the packet is dropped. - Feasible Path uRPF [3]: A variant of the strict uRPF in which not only the interface offering the best route, but also those of alternative paths (e.g., other router advertisements that are kept in the BGP FIB) are accepted as correct paths to the source address of the packet. The feasible path set is a superset of the active paths, and it works also in asymmetric and multihomed scenarios. Loose uRPF [3]: A variant of uRPF in which the plain existence of a route to the source address in the forwarding table (even if it is a default route) is checked so as to forward or drop the packet. (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 will keep directionality on his network announcements, so asymmetric routing will not work. The mechanism can be problematic in peering routers that exchange routes with other ISPs (“hot potato” routing, BGP filtering in both directions of the peering due to different routing policies) or in data centers where hosts are connected to redundant networks. - Loose uRPF applied to interfaces in border routers will allow asymmetric routing, but will limit the automatic “pseudo-filtering” benefits of uRPF to private (RFC 1918) and unroutable (“bogon”) IP addresses [4]. 4.1.3. Other filters: BOGON networks filtering - What are BOGONs 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 HowTo, a BOGON in an interface of a router is any source address of a packet that enters the router through that interface and that legally shouldn’t do sois not routable through it. As the same source indicates, this definition of BOGON includes “martian” addresses (cf RFC1918 and RFC3330) and unassigned addresses as explained in the next section. Also in this case are included the address that topologically ares located always and in any situation in networks connected to other ports interfaces of the router. - Why to filter them The Cymru document states that, according to some measurements, up to 60% of the IP addresses used in attacks stem from BOGON addressing. Filtering these addresses will reduce the impact of said attacks at a great level. - How to build the filters There are two basic approaches: In interfaces open to Internet, the simplest way is to create a list of denied networks and filter them out. In interfaces open to internal networks –a reduced set of networks with public and/or private addressing– it usually is easier to create a list of allowed networks and filter them in, rejecting those networks that do not match. In the first case, the networks list has a static part and a dynamic part: the static part is the martian addresses list (previously defined) together with the list of static networks inside the organisation. The dynamic part comprehends, at least, the list of valid addresses that have not been allocated from the IANA to the RIRs yet (see next section). 4.1.4. Unassigned addressing One special case of bogon networks is the unassigned addressing. Unassigned addresses are netblocks of public address space that have not been allocated from 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 whenever they are assigned in the future. If you do not remove them, you will risk blocking out some portions of the Internet to your customers. If you are a transit provider the problem can be bigger and more difficult to debug. So you need to keep up to date with this list. You can do it manually, although it is better to use some automation. To get links to tools and information on both of them how to do it, consult the Team Cymru Bogon Reference Page[2]. 5. Vendor specifics 5.1. Cisco features - Cisco routers support uRPF (both strict and loose) in their interfaces. CEF is necessary for uRPF, thus the latter is incompatible with solutions that disable CEF. On the other hand, but it doesn’t load the CPU too much. - Source routing is disabled by default in Cisco routers (though you can enable it). - It is possible to filter packets based on source IP address without loading too much the router CPU. 5.2. Juniper features - Juniper routers support uRPF (both strict and loose) if equipped with the (relatively) new Internet Processor II ASIC. - Source routing is enabled by default in Juniper routers. This can presume a threat for the networks connected, so our recommendation is to disable it. - It is possible to filter packets based on source IP address without loading too much the router CPU. 6. Scenarios All the scenarios described here focus on the functionality of each router. This determines what the generic filtering configuration to be applied on each router will be. 6.1. Customer/provider scenarios In these cases, there will be a clear separation between recommendations for customer routers, and for provider routers. 6.1.1. Single router, single provider There will always be a single link between customer and provider’s access router, normally using a /30 or /31 range from the provider’s PA range. In many cases, there will be a public addressing subnet (from the PA range allocated to the provider) assigned to the client, but some solutions employ NAT and an all private addressing schema. Routing between customer and provider in this scenario is static and manually coded in the router configuration. In both cases this scenario you can manually filter with an access list and/or let the router do it automatically by using uRPF. The first method can be more precise, but it requires more time to maintain (a big burden on the provider side) and is a significant load for the router. It is not recommended if the link speed is over one megabit/second. But if you implement the access list, the user of uRPF is mostly redundant. 6.1.1.1. Cisco version - Customer router (CPE) ip cef interface ATM0/1.1 point-to-point description Interface to provider ip address 89.107.53.2 255.255.255.252 ! We filter packets based on a static list ip access-group bogons in ! We also can use strict uRPF ! Though it is redundant in this case ip verify unicast reachable-via rx allow-default ... ! Route to Internet ip route 0.0.0.0 0.0.0.0 ATM0/1.1 ... ! Static networks to filter ! private and reserved networks are rejected ip 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 we have a public range assigned, we can’t receive ! those addresses from the outside deny ip 89.107.52.0 0.0.0.255 any ! our router external address deny ip 89.107.53.2 0.0.0.0 any permit ip any any - Provider router (PE) ip cef interface ATM0/1.1 point-to-point description Interface to customer ip address 89.107.53.1 255.255.255.252 ! static filter based on customer public addresing. ! This is a simple filter ip access-group customer-routes in ! Here we can also use strict uRPF. ! We don’t use the allow-default option of uprf ! because customer link shouldn’t be the default route ip verify unicast reachable-via rx ... ! Static networks to filter ! ip access-list extended customer-routes ! Here we do the opposite of the CPE ! we deny everything except customer public address ! Public address of the CPE 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 ip any any 6.1.1.2. Juniper Version Customer router (CPE) interfaces { e3-0/0/0 { description "Interface to provider"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input bogons; } address 89.107.53.2/30; /* We also can use strict uRPF though it is redundant */ rpf-check; } } } } chassis { no-source-route; } routing-options { static { route 0.0.0.0/0 next-hop e3-0/0/0; } } policy-options { prefix-list bogon-list { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; 127.0.0.0/8; 169.254.0.0/16; 192.0.2.0/24; 198.18.0.0/15; 240.0.0.0/4; } } firewall { family inet { filter bogons { term bogons { from { prefix-list { bogon-list; } } then { discard; } } term our-own { from { source-address { 89.107.52.0/24; } } then { discard; } } term the-router { from { source-address { 89.107.53.2/32; } } then { discard; } } term default { then { accept; } } } } Provider router (PE) interfaces { e3-0/0/0 { description "Interface to customer"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input customer; } address 89.107.53.1/30; /* We also can use strict uRPF though it is redundant */ rpf-check; } } } } chassis { no-source-route; } routing-options { static { route 89.107.52.0/24 next-hop e3-0/0/0; } } firewall { family inet { filter customer { term network { from { source-address { 89.107.52.0/24; } } then { accept; } } term router { from { source-address { 89.107.53.2/32; } } then { accept; } } } } 6.1.2. Multiple routers, single provider with one router, redundant solution Scenario with 2+ routers connected to a single access router: each route between the customer’s and the provider’s routers will be static and will have different metrics in 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 in both sides is important: If one side uses one path as “best” and the other side uses the other one, filters using uRPF won’t work and there will be no traffic routed between them. - Each router has a link between customer and provider’s access router, normally using /30 or /31 range from the provider PA range. The customer will have a public range from the PA range allocated to the provider. The CPEs usually have VRRP between them, with more weight in the CPE with the best link and linked to the physical interface to the provider. The CPEs have two default routes, one through its link to the customer and another through the other router with a worse weight. In the PE, there are routes to the customer network through both links, with a better weight in the preferred link. +----------+ | Provider | | router | ++--------++ | | +---------++ ++---------+ | Customer | | Customer | | router A | | router B | +--------+-+ +---+------+ | | | | | -------- | |// \\| /| \\ || || | customer | | network | || || \\ // \\ // -------- In each customer router we can implement the same filtering that was described for the single router, single provider scenario. We setup the filter list only in the input from the other network, we don’t filter in the input from our network. uRPF is also used in strict mode. 6.1.2.1. Cisco version - Filters on customer router (CPE) ! ROUTER CUSTOMER A ! CEF is needed for uRPF ip cef interface ATM0/1.1 point-to-point description Interface to provider ip address 89.107.53.2 255.255.255.252 ! static filtering ip access-group bogons in ! strict uRPF through this link ip verify unicast reachable-via rx allow-default [...] ip route 0.0.0.0 0.0.0.0 ATM0/1.1 10 ip route 0.0.0.0 0.0.0.0 89.107.52.3 20 [...] ! Static networks to filter ip 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 ! router external interface deny ip 89.107.53.2 0.0.0.0 any ! Public addresing range of customer deny ip 89.107.52.0 0.0.0.255 any permit ip any any ... interface FastEthernet0/0 ip address 89.107.52.2 255.255.255.0 standby 1 ip 89.107.52.1 standby 1 preempt standby 1 priority 150 standby 1 track ATM0/1.1 ! ROUTER CUSTOMER B ! CEF is needed for uRPF ip cef interface ATM0/1.1 point-to-point description Interface to provider ip address 89.107.53.6 255.255.255.252 ! static filtering ip access-group bogons in ! strict uRPF through this link ip verify unicast reachable-via rx allow-default [...] ip route 0.0.0.0 0.0.0.0 ATM0/1.1 [...] ! Static networks to filter ip 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 ! router external interface deny ip 89.107.53.6 0.0.0.0 any ! Public addresing range of customer deny ip 89.107.52.0 0.0.0.255 any permit ip any any [...] interface FastEthernet0/0 ip address 89.107.52.3 255.255.255.0 standby 1 ip 89.107.52.1 standby 1 preempt standby 1 priority 75 standby 1 track ATM0/1.1 - Filters on provider router (PE). We filter only in each input from the customer. ! cef is needed for uRPF ip cef interface ATM0/1.1 point-to-point description Interface to customer ip address 89.107.53.1 255.255.255.252 ! static filtering ip access-group customer-routes in ! uRPF filtering ip verify unicast reachable-via rx [...] interface ATM0/2.1 point-to-point description Interface to customer ip address 89.107.53.5 255.255.255.252 ! static filtering ip access-group customer-routes in ! uRPF filtering ip verify unicast reachable-via rx [...] ip route 89.107.52.0 255.255.255.0 ATM0/1.1 10 ip route 89.107.52.0 255.255.255.0 ATM0/2.1 20 ! Static networks to filter ! Public address of the CPE router ip access-list extended customer-routes permit ip 89.107.53.2 0.0.0.0 any permit ip 89.107.53.6 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 ip any any 6.1.2.2. Juniper version - Filters on customer router (CPE) - Router A interfaces { e3-0/0/0 { description "Interface to provider"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input bogons; } address 89.107.53.2/30; /* We use strict uRPF */ rpf-check; } } } fe-1/3/0 { unit 0 { family inet { filter { input voip; } address 89.107.52.2/24 { vrrp-group 1 { virtual-address 89.107.52.1; priority 150; track { interface e3-0/0/0.0 { priority-cost 100; } } } } } } } } chassis { no-source-route; } routing-options { static { route 0.0.0.0/0 next-hop e3-0/0/0 preference 10; route 0.0.0.0/0 next-hop 89.107.52.3 preference 20; } } policy-options { prefix-list bogon-list { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; 127.0.0.0/8; 169.254.0.0/16; 192.0.2.0/24; 198.18.0.0/15; 240.0.0.0/4; } } firewall { family inet { filter bogons { term bogons { from { prefix-list { bogon-list; } } then { discard; } } term our-own { from { source-address { 89.107.52.0/24; } } then { discard; } } term the-router { from { source-address { 89.107.53.2/32; } } then { discard; } } term default { then { accept; } } } } - Router B interfaces { e3-0/0/0 { description "Interface to provider"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input bogons; } address 89.107.53.6/30; /* We use strict uRPF */ rpf-check; } } } fe-1/3/0 { unit 0 { family inet { filter { input voip; } address 89.107.52.3/24 { vrrp-group 1 { virtual-address 89.107.52.1; priority 125; track { interface e3-0/0/0.0 { priority-cost 100; } } } } } } } } chassis { no-source-route; } routing-options { static { route 0.0.0.0/0 next-hop e3-0/0/0 preference 10; route 0.0.0.0/0 next-hop 89.107.52.2 preference 20; } } policy-options { prefix-list bogon-list { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; 127.0.0.0/8; 169.254.0.0/16; 192.0.2.0/24; 198.18.0.0/15; 240.0.0.0/4; } } firewall { family inet { filter bogons { term bogons { from { prefix-list { bogon-list; } } then { discard; } } term our-own { from { source-address { 89.107.52.0/24; } } then { discard; } } term the-router { from { source-address { 89.107.53.6/32; } } then { discard; } } term default { then { accept; } } } } - Filters on provider router (PE). We filter only in each input from the customer. - interfaces { e3-0/0/0 { description "Interface to customer"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input customer; } address 89.107.53.1/30; /* We also can use strict uRPF though it is redundant */ rpf-check; } } } e3-0/0/1 { description "Interface to customer"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input customer; } address 89.107.53.5/30; /* We also can use strict uRPF though it is redundant */ rpf-check; } } } } chassis { no-source-route; } routing-options { static { route 89.107.52.0/24 next-hop e3-0/0/0 preference 10; route 89.107.52.0/24 next-hop e3-0/0/1 preference 20; } } firewall { family inet { filter customer { term network { from { source-address { 89.107.52.0/24; } } then { accept; } } term router { from { source-address { 89.107.53.2/32; } } then { accept; } } term router { from { source-address { 89.107.53.6/32; } } then { accept; } } } } 6.1.3. Multiple routers, single provider with multiple routers, redundant solution --------- /// \\\ // \\ // \\ | | | Provider | | network | | | | | \| // |\ // | \\\ ///| | --------- | | | | | +---------+-+ +-+---------+ |Provider | |Provider | |router A | |router B | | | | | +-----+-----+ +----+------+ | | | | +-----+-----+ +----+------+ |Customer | |Customer | |router A | |router B | | | | | +----------++ +--+--------+ | | | | | --------- | |// \ | /| \| | Customer | | network | | | \\ // \\ // --------- This scenario is similar to the previous one on the customer side and we won’t repeat it here. On the provider side you can use some floating IP mechanism like the one described for the customer in the previous scenario (HSRP, VRRP). A more common scenario for the provider is the use of a dynamic routing protocol inside its network and use it to announce the customer networks internally. Two weights are used: one higher through the preferred link and the second lower through the other link. Though both scenarios are different at a routing level, they are similar as seen from the spoofing security level; similar static filters and strict uRPF can be used. But you must take one word of caution: for the uRPF configuration to work, both sides (customer and provider) must select the same link as “active”. If each side selects a different link as active, uRPF will block all traffic. The configuration for the provider using a dynamic routing protocol is the following. 6.1.3.1. Cisco version - - Filters on provider routers (PE). We filter only in each input from the customer - Provider router A ! cef is needed for uRPF ip cef router ospf 10 network 89.107.54.0 0.0.0.255 area 1 redistribute static interface ATM0/1.1 point-to-point description Interface to customer ip address 89.107.53.1 255.255.255.252 ! static filtering ip access-group customer-routes in ! strict uPRF filtering ip verify unicast reachable-via rx ... interface FastEthernet0/0 ip address 89.107.54.2 255.255.255.0 standby 1 ip 89.107.54.1 standby 1 preempt standby 1 priority 150 standby 1 track ATM0/1.1 ... ip route 89.107.52.0 255.255.255.0 ATM0/1.1 10 ip route 89.107.52.0 255.255.255.0 89.107.54.3 20 ! Static networks to filter ! Public address of the CPE router ip access-list extended customer-routes 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 ip any any - Provider router B ! cef is needed for uRPF ip cef router ospf 10 network 89.107.54.0 0.0.0.255 area 1 redistribute static interface ATM0/1.1 point-to-point description Interface to customer ip address 89.107.53.5 255.255.255.252 ! static filtering ip access-group customer-routes in ! strict uRPF filtering ip verify unicast reachable-via rx ... interface FastEthernet0/0 ip address 89.107.54.3 255.255.255.0 standby 1 ip 89.107.54.1 standby 1 preempt standby 1 priority 75 standby 1 track ATM0/1.1 ... ip route 89.107.52.0 255.255.255.0 ATM0/1.1 10 ip route 89.107.52.0 255.255.255.0 89.107.54.2 20 ! Static networks to filter ! Public address of the CPE router ip access-list extended customer-routes permit ip 89.107.53.6 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 ip any any 6.1.3.2. Juniper version - Provider router A interfaces { e3-0/0/0 { description "Interface to customer"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input customer; } address 89.107.53.1/30; /* We also can use strict uRPF though it is redundant */ rpf-check; } } fe-0/3/0 { description “Provider network”; unit 0 { family inet { address 89.107.54.2/24; } } } protocols { ospf { import statics; area 0.0.0.1 { interface fe-0/3/0.0; } } } chassis { no-source-route; } routing-options { static { route 89.107.52.0/24 next-hop e3-0/0/0; } } firewall { family inet { filter customer { term network { from { source-address { 89.107.52.0/24; } } then { accept; } } term router { from { source-address { 89.107.53.2/32; } } then { accept; } } } } policy-options { policy-statement statics { from protocol static; then accept; } } - Provider router B interfaces { e3-0/0/0 { description "Interface to customer"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input customer; } address 89.107.53.5/30; /* We also can use strict uRPF though it is redundant */ rpf-check; } } fe-0/3/0 { description “Provider network”; unit 0 { family inet { address 89.107.54.3/24; } } } protocols { ospf { import statics; area 0.0.0.1 { interface fe-0/3/0.0; } } } chassis { no-source-route; } routing-options { static { route 89.107.52.0/24 next-hop e3-0/0/0; } } firewall { family inet { filter customer { term network { from { source-address { 89.107.52.0/24; } } then { accept; } } term router { from { source-address { 89.107.53.6/32; } } then { accept; } } } } policy-options { policy-statement statics { from protocol static; then accept; } } 6.1.4. Single Router, multiple providers, Load balancing The most usual multihoming scenario: a single router (CPE) that can reach the Internet through separate links to other transit providers, selecting the best route path through a variety of mechanisms (static routing, BGP best path selection, etc.) The CPE can run BGP against each ISP, announce his own PI addresses, or PA addresses assigned by his own or another LIR, or combinations of these. The next diagram illustrates the setup: +--------+ | | 1 | isp A +---------------------+ | | | | | | | | +--------+ | 3 | +----+----+ | | |5 | | cust +-----+ | | | | | | +----+----+ | | 4 | +--------+ | | | | | | | 2 | | isp B +---------------------+ | | +--------+ Figure 6.1-1 6.1.4.1. Transit interfaces of the CPE router The CPE will accept from their transit providers a set of routes to be reached through them. In some cases, the default route could be assigned to one or more of the ISP interfaces (resilient links of the preferred one). In the other cases in which no default route is configured, the BGP process will select the best available path and insert it in the FIB for each interface. At these transit interfaces, antispoofing measures can include: - Anti-BOGON filtering via Access-Lists (see section 5.1.1) - Loose uRPF mechanism, or if available, feasible-path uRPF mechanism. It is activated at each interface that provides transit to the Internet (interfaces 3 and 4 of the Figure 5.1-1) by using the following commands. 6.1.4.1.1. Cisco routers ip cef ! and configure the interface with (IOS versions 12.2T+): interface FastEthernet0/0 ip verify unicast source reachable-via any 6.1.4.1.2. Juniper routers [edit routing-options forwarding-table] unicast-reverse-path feasible-paths; and [edit interfaces fe-0/0/0] unit 0 { family inet { rpf-check; { mode loose; } } } 6.1.5. CPE inner-networks interfaces When the router (CPE) has interfaces that connect to customer’s domain networks with public addresses, anti-spoofing measures can be: 6.1.5.1. Single internal interface If there is a single interface to the customer networks, or multiple interfaces connecting different networks (with separate prefixes), then Strict uRPF applied at each customer interface can help to drop illegal (spoofed) traffic generated by compromised hosts inside these networks, e.g. running botnets or other malware during DDoS attacks. So, on interface 5 of figure 5.1-1 one can apply: - Anti-BOGON filtering via Access-Lists (see section 5.1.1) Loose uRPF mechanism, or if available, feasible-path uRPF mechanism. It is activated at each interface that provides transit to the Internet (interfaces 3 and 4 of the Figure 5.1-1) by using the following commands. - 6.1.5.1.1. Cisco routers ip cef interface FastEthernet0/0 ip verify unicast source reachable-via rx 6.1.5.1.2. Juniper routers [edit routing-options forwarding-table] unicast-reverse-path feasible-paths; and [edit interfaces fe-0/0/0] unit 0 { family inet { rpf-check; } } If there are multiple interfaces connecting to the customer domain networks, and multiple paths are possible to reach the customer addresses so asymmetric routing to the customer networks is possible, then Strict uRPF would drop “good traffic” that arrives to the router via diverse interfaces, so feasible-path uRPF has to be configured on the “inner” interfaces or, if not available, Loose uRPF. 6.1.6. Multiple internal interfaces As in the previous section, if asymmetric routing is possible (and indispensable), and there is no default route present, the most effective configuration implies the configuration of feasible-path mode (or, if not available, loose mode) uRPF in the inner interfaces of the CPE routers. In the figure 5.1-2, all the interfaces will operate in Loose or feasible-path uRPF mode. In case “cust” routers have a default route configured, then only interfaces 9 and 10 will have Loose or feasible-path uRPF configured +--------+ | |1 | | isp A +-----------------------+ | | | | | | | | 5 | +-----+--+ +----+---+ | |2 | | | | 6| cust +------+ +------------------------+ |9 | | | +--------+ | | | | | | +--------+ | | | 7| | | | +---------------------+ cust +------+ | | |10 | |3 +----+---+ | +--+-----+ |8 | | | | | | |4 | | | isp B +-----------------------+ | | | Figure 5.1-2 6.1.7. Customers access networks This kind of networks includes the equipment deployed by ISPs and carriers to aggregate a large number of customers (e.g. broadband concentrators, dial-up RAS, etc.) The generic characterization of these equipments includes multiple point-to-point interfaces (to customers) with prefixes assigned to each customer interface, and an egress/transit interface to the rest of the Internet. There are no redundant/multiple paths to customer destinations, although the transit interfaces can be multiple. In this case, strict mode uRPF can be configured in the customer links. These customer links are one of the best situations to use uRPF. IP address for the customer is assigned usually in a dynamic way (with a RADIUS server or similar), making the use of static filters impossible. 6.1.7.1. Customer links For a Cisco AS5300 the configuration would be as follows: ! for uRPF we need cef activated ip cef ! Dial-in group interface Group-Async1 ip unnumbered Loopback0 no ip directed-broadcast ! This is a dynamic assigned ip address ! so we can’t use static filters, just strict uRPF ip verify unicast source reachable-via rx encapsulation ppp async mode interactive peer default ip address pool dialin_pool no cdp enable ppp authentication chap pap group-range 1 96 6.2. Core networks Addressing in the core networks by the own nature of the core is not as clearly split as it happens in the customer/provider scenarios. In fact, in most cases, any valid route can arrive by any interface. So the recommendation is filter only the illegal addressing –bogons– and work with customers to help them implement more strict rules in their access networks. The configuration for this core router is as follows 6.2.1. Cisco routers ip cef interface ATM0/1.1 point-to-point description Interface to core A ip address 89.107.53.2 255.255.255.252 ! We filter packets based on a static list ip access-group bogons in interface ATM0/2.1 point-to-point description Interface to core B ip address 89.107.54.2 255.255.255.252 ! We filter packets based on a static list ip access-group bogons in ... ! Static networks to filter ! private and reserved networks are rejected ip 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 ! our router external address deny ip 89.107.53.2 0.0.0.0 any deny ip 89.107.54.2 0.0.0.0 any permit ip any any 6.2.2. Juniper routers interfaces { e3-0/0/0 { description "Interface to provider"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input bogons; } address 89.107.53.2/30; } } } e3-0/1/0 { description "Interface to provider"; hold-time up 200 down 200; clocking internal; encapsulation ppp; e3-options { compatibility-mode kentrox; payload-scrambler; fcs 32; } unit 0 { family inet { filter { input bogons; } address 89.107.54.2/30; } } } } chassis { no-source-route; } routing-options { static { route 0.0.0.0/0 next-hop e3-0/0/0; } } policy-options { prefix-list bogon-list { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; 127.0.0.0/8; 169.254.0.0/16; 192.0.2.0/24; 198.18.0.0/15; 240.0.0.0/4; } } firewall { family inet { filter bogons { term bogons { from { prefix-list { bogon-list; } } then { discard; } } term default { then { accept; } } } } 7. IPv6 Though Ipv6 is still in their early years, our recommendation is to implement anti-spoofing filters based, if possible, on uRPF filters. If not, static filters based on martians addresses and bogons lists. A large part of the content of this chapter is extracted from the excellent page created by Gert Doering[5]. Many of the recommendations for IPv6 are similar to those stated for the same type of network in IPv4. 7.1. uRPF 7.1.1. Cisco routers uRPF is available for IPv6 on Cisco high end series (12000, 7600 and so on) since release 12.0(31)S. To use it, simply replace ip by ipv6 in the previous instructions. Of course to use uRPF in IPv4 and IPv6, you need to include both lines: ip verify unicast source reachable-via rx to be replaced by ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rx Juniper routers uRPF can be applied with the same instructions explained previously, replacing, or adding, family inet with family inet6: [edit interfaces fe-0/0/0] unit 0 { family inet { rpf-check; } } with: [edit interfaces fe-0/0/0] unit 0 { family inet { rpf-check; } } family inet6 { rpf-check; } } 7.2. Routes from customers The static routes in this scenary are very simple. Allow customer routes and deny everything else 7.2.1. Cisco routers ipv6 prefix-list ipv6-from-customer permit 2001:db8::/32 ipv6 prefix-list ipv6-from-customer deny 0::/0 le 128 7.2.2. Juniper routers policy-statement ipv6-from-customer { from { family inet6; route-filter 2001:db8::/32 exact next policy; } then reject; } 7.3. Routes from peers If we use static filters, we must apply for a strategy similar to the one stated in IPv4. These are fairly relaxed rules designed to avoid bogon addresses, but not to deal with other issues. 7.3.1. Cisco routers This first list only denies the martians addresses and won’t need to be updated in the near future. 3FFE::/16 are explicit denied - this /16 is not in use anymore according to 6bone and ICANN rules 2001:db8::/32 is explicitely denied because is reserved for documentation purposes 0000::/8 is denied (loopback, unspecified, v4-mapped) FE00::/9 and FF00::/8 are denied Our own internal range (2001:4030:f::0/48 in this example, replace by your own range) ipv6 prefix-list ibv6-ebgp deny 2001:4030:f::0/48 le 128 ipv6 prefix-list ipv6-ebgp deny 3ffe::/16 le 128 ipv6 prefix-list ipv6-ebgp deny 2001:db8::/32 le 128 ipv6 prefix-list ipv6-ebgp deny 0000::/8 le 128 ipv6 prefix-list ipv6-ebgp deny fe00::/9 le 128 ipv6 prefix-list ipv6-ebgp deny ff00::/8 le 128 ipv6 prefix-list ipv6-ebgp permit any This second list also take into account the bogon list, i.e. the pool of address not assigned by the IANA. If you use this list, you must remember that this list needs to be updated regularly. ipv6 prefix-list ibv6-ebgp deny 2001:4030:f::0/48 le 128 ipv6 prefix-list ipv6-ebgp deny 3ffe::/16 le 128 ipv6 prefix-list ipv6-ebgp deny 2001:db8::/32 le 128 ipv6 prefix-list ipv6-ebgp permit 2001::/32 ipv6 prefix-list ipv6-ebgp permit 2002::/16 ipv6 prefix-list ipv6-ebgp permit 2003::/16 ipv6 prefix-list ipv6-ebgp permit 2400::/12 ipv6 prefix-list ipv6-ebgp permit 2600::/12 ipv6 prefix-list ipv6-ebgp permit 2610::/23 ipv6 prefix-list ipv6-ebgp permit 2620::/23 ipv6 prefix-list ipv6-ebgp permit 2800::/12 ipv6 prefix-list ipv6-ebgp permit 2a00::/12 ipv6 prefix-list ipv6-ebgp permit 2c00::/12 ipv6 prefix-list ipv6-ebgp deny 0000::/8 le 128 ipv6 prefix-list ipv6-ebgp deny fe00::/9 le 128 ipv6 prefix-list ipv6-ebgp deny ff00::/8 le 128 ipv6 prefix-list ipv6-ebgp deny 0::/0 le 128 7.3.2. Juniper routers The same apply for Juniper routers. We show two access lists. One relaxed that doesn’t need changes in the near future because only use martian addresses and a second one more precise but that need to be updated periodically because use the unassigned address pool from IANA. The relaxed one: policy-statement ipv6-ebgp { from { family inet6; route-filter 3ffe::/16 orlonger; route-filter ::/8 orlonger; route-filter 2001:db8::/32 orlonger; route-filter fe00::/9 orlonger; route-filter ff00::/8 orlonger; route-filter ::/0 upto /48 next policy; } then reject; } The strict one: policy-statement ipv6-ebgp { term pass-some { from { family inet6; route-filter 3ffe::/16 orlonger reject; route-filter 2001:500::/30 prefix-length-range /48-/48; route-filter 2001:db8::/32 orlonger reject; route-filter 2001::/32 longer; route-filter 2002::/16 longer; route-filter 2003::/16 longer; route-filter 2400::/12 longer; route-filter 2600::/12 longer; route-filter 2610::/23 longer; route-filter 2620::/23 longer; route-filter 2800::/12 longer; route-filter 2a00::/12 longer; route-filter 2c00::/12 longer; } then next policy; } term reject-rest { from family inet6; then reject; } } 7.8. Conclusion The utilization of one or more of these guidelines won’t assure you that all attacks will be stopped, not even all attacks that use spoofed addresses. As an example, if the attack comes from an external unprotected network, the computers that generate the attacks can use any address from internet and we won’t detect it. But if all ISPs implemented these measures, the use of spoofed IP addresses for attacks would be dramatically limited and the origin of malicious packets would be a lot easier to discover. And even if not all ISPs implement these rules, their use can avoid some attacks, including some of the most dangerous kind: attacks that use spoofed addresses from your internal networks. 8.9. References [1] Savola & Baker, RFC 3704 [2] http://www.cymru.com/Bogons/index.html [3] http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fothersf/scfrpf.htm [4] Savola, draft-savola-bcp84-urpf-experiences-03.txt (updated version) [5] http://www.space.net/~gert/RIPE/ipv6-filters.html --