Remotely Triggered Black Hole with uRPF

When you get to know about malicious IPs, how do you control traffic to or from there?
Apply an ACL or a firewall policy at your internet gateway... Easy one. 
But what if you have multiple gateways... Login to each one of them and apply policies or maybe use an automation server to do that... Okay.
How about, if that IP belongs to one of your internal machines? Or multiple machines in different subnets or from remote sites? Or an internal machine spoofing as an external IP?
You may take significant time locating the hosts or blocking those IPs using ALC. Complicated?
And in case of DDoS, DoS or security events, an action at slight delay may be catastrophic. Isn't it?

In such situations, especially when you are managing a large network, with multiple gateways, spread across different regions, with remote and hub offices, you may need an intelligent way to block malicious IPs. Also, it's desirable to block them closest to their origin in your network, so it doesn't consume network bandwidth and have less scope for further infections.

Remote Triggered Black Hole (RTBH)is a way to advertise bad IPs from one central node to the rest of the network. Other nodes, who learn through BGP about Bad IP, take local measurement to block it. It's really that simple. If you are running BGP for most of your route advertisements, RTBH may work as a great defense. Let's see how it work.

Consider a router which is acting as an announcement unit in network, call it Bogon. Bogon means Bogus, and bogon actually refers to a group of IPs which are unallocated by IANA and should not exist on the internet. The Bogon router, running BGP, will communicate with all your BGP aware routes either via full mesh or via a Route Reflector. Whenever you learn about a bad IP, you simply add it in Bogon, and Bogon will advertise it to all BGP peers.

All BGP active routers in the network will have a static route for a common auxiliary IP ( eg. 192.0.2.1/32), with next-hop black-hole (Null0 or Discard). There may be multiple ways to match Bogon routes and then set next hop to this auxiliary IP (I will discuss more on it at the end of this section). This will result in pointing Bogon routes to Null0 or Discard after recursive lookup. 
Running RTBH, you empower your internal routers, to identify and discard malicious traffic. Thus, malicious traffic will now be dropped at the initial or intermediate level. 

Now, if you are running URPF (Unicast Reverse Path Forward) in your network, you can enhance the security capability of your devices at the next level. Running URPF along with RTBH, your routers will not only drop traffic destined to Bogon IPs, but they will also scan traffic sourced from them and drop instantly. This way, the malicious payload will not even reach to the targeted device. For more detail about uRPF, refer to my previous blog.
If you are not comfortable with uRPF and don't want to implement uRPF with full capacity, still if you want to get the benefit of both, refer to subsection "uRPF with Default Route" under "Implementing URPF". :)

Okay, now let's discuss the strategy to implement RTBH. You can actually implement it in many different ways, based on your network architecture. I am discussing here, my two preferred styles. Although, real configurations may differ with different vendors, however, the concept is going to be 

Option-1: When your network is simple and running only on a single AS. You need to add bad IPs in Bogon as a static route with a TAG or Community value attached to it. Set next hop to null0 or discard. Then advertise these routes through BGP, by redistributing static and matching that TAG/Community value.
While advertising these routes, use a policy or route-map to set next-hop to the auxiliary IP (eg. 192.0.2.1, which need be present in all BGP aware routers with next-hop Null0/ Discard). In an iBGP advertisement (either via full mesh or via Route Reflector) next hop value will remain unchanged (192.0.2.1). This will end-up installing Bogon routes with Black-Hole in all BGP active routers.

Option-2: If you are running sub-ASs (Private AS for different regions, or Confederation, for easy administration), you might be having eBGP peering at different stages in different segments. Since, next-hop behavior will change with eBGP peering, with option-1, you may end-up fine tuning next-hop value at all those eBGP peers. In these scenarios, simply attach a community value, while advertising it to BGP peers. All BGP aware routers will receive Bogon routes with this community value. Configure all BGP aware routers, with an import policy/route-map matching this community value and set next-hop black-hole.

Someone may be wondering why only BGP for this setup. well, only BGP can advertise routes over non-connected peers and also has the capability to manipulate next-hop value from remote. While IGPs, advertise routes only to their directly connected peers, and they always set the next-hop value to advertising neighbor. 

Caution: 
RTBH, with uRPF (RFC-5635 can be referred for more details), is going to add an extra layer of defense in your network. However, it's really important to understand your network and plan well before you deploy it. 
When you setup RTBH, make sure in any situation, you don't advertise blocked IPs to your external peers. Else, you may end up poisoning your neighbor's network and may also attract traffic for those blocked IPs from your external peers... :P (You can match communities at egress routes and do manual filtering, or use community No-Export).
In some vendors, Auxiliary IPs like 192.0.2.0/24 are treated as Martian or Special Use IPs (Kind of Bogon IP and defined in RFC-3330). If you are having trouble installing them in the routing table. You can either add an exception in Martian list or pick another free private IP. 

OSPF Link State Advertisement (LSA)

I have spoken many folks getting confused about OSPF LSAs. It’s not that confusing if you know the database architecture of OSPF. LSAs (Link State Advertisements) are some sort of routing information about a specific category of routes.  Unlike other routing protocols OSPF stores routing information in a very structured and detailed way in its database. Every LSA contains a unique information about a route advertized in OSPF domain and based on this information OSPF builds its database and stores LSA in an appropriate category. During convergence every router in an area exchange their LSAs and form same database so they end up by plotting the same topology map. Finally, they run Dijkstra's SPF algorithm to calculate the cost to reach other routes advertised by other routers, and best route gets installed in the routing table. (Although, database of every router in an area is exactly same, but their reachability to any particular route differs than the other so they end up with different routing results).

Lets discuss in detail about individual LSA types. There are 11 types of LSAs in OSPF database, however, only LSA 1 to LSA 5 and LSA 7 are used in normal OSPF convergence, other types are used in IPv6 and traffic engineering. Have a look on topology below. Router R1 and R4 are acting as an ABR to Area 2 while R3 acting as an ABR to Area 1. R6 is connected to a RIP network and redistributing RIP routes (172.16.1.0/24, 172.16.2.0/24 and 172.16.3.0/24) into OSPF. Examine the database and individual LSA entries from the router R2 (since database remains same at every router in an area so the same outputs can be found at any router in Area 0).

 R2#show ip ospf database 

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID     ADV Router    Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         711         0x8000000B 0x002DB1 2

2.2.2.2         2.2.2.2         899         0x8000000E 0x00D2CF 4

3.3.3.3         3.3.3.3         1915        0x80000008 0x0013B4 2

4.4.4.4         4.4.4.4         913         0x8000000A 0x00527E 3

                Net Link States (Area 0)

Link ID         ADV Router   Age         Seq#       Checksum

10.10.123.3     3.3.3.3         169         0x80000006 0x00F881

                Summary Net Link States (Area 0)

Link ID       ADV Router   Age         Seq#       Checksum

5.5.5.5         1.1.1.1         960         0x80000005 0x00EA2B

5.5.5.5         4.4.4.4         913         0x80000005 0x00AE25

6.6.6.6         3.3.3.3         955         0x80000001 0x00A631

10.10.15.0      1.1.1.1         1467        0x80000005 0x0027E0

10.10.15.0      4.4.4.4         913         0x80000005 0x004F6C

10.10.36.0      3.3.3.3         170         0x80000003 0x002591

10.10.45.0      1.1.1.1         961         0x80000005 0x005E4B

10.10.45.0      4.4.4.4         914         0x80000005 0x009F08

10.10.67.0      3.3.3.3         957         0x80000001 0x003758

               
              Summary ASB Link States (Area 0)
Link ID       ADV Router    Age         Seq#       Checksum
6.6.6.6         3.3.3.3          957         0x80000001 0x008E49 

                Type-5 AS External Link States

Link ID         ADV Router   Age         Seq#       Checksum Tag

172.16.1.0      6.6.6.6         970         0x80000001 0x005616 0

172.16.2.0      6.6.6.6         970         0x80000001 0x004B20 0

172.16.3.0      6.6.6.6         970         0x80000001 0x00402A 0

LSA Type 1 (Router LSA) is generated by every router and it doesn’t cross the area boundary. LSA 1 contains the detailed  information about advertizing router and OSPF enabled its all interfaces, network type and associated prefixes.

Now check in detail an individual Router LSA (eg. R1).

   

R2# show ip ospf database rouer  1.1.1.1

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

  Routing Bit Set on this LSA

  LS age: 810

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 1.1.1.1

  Advertising Router: 1.1.1.1

  LS Seq Number: 80000011

  Checksum: 0x21B7

  Length: 48

  Area Border Router

  Number of Links: 2

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 1.1.1.1

     (Link Data) Network Mask: 255.255.255.255

      Number of TOS metrics: 0 
       TOS 0 Metrics: 1

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.10.123.3

     (Link Data) Router Interface address: 10.10.123.1

      Number of TOS metrics: 0

       TOS 0 Metrics: 10

Now every router in Area 0 know via router LSA of R1 (Router ID 1.1.1.1) about following properties of R1

                It is an ABR and has two links in Area 0. First link is a stub network (Loopback 0) and is reachable at metric of 1 and other link connects to a transit network where DR router address is 10.10.123.3 and this network has a cost of 10 from R1.

LSA Type 2 (Network LSA) is generated only by a DR (Designated Router). DR/BDR is elected in a shared or broadcast segment (Since full adjacency is formed only with DR in that segment, so only DR advertises the information about any change to all routers in that segment).

If you see the router LSA of R1 you will see that it was associated with a transit network and router didn’t have further idea that what are other routers connected to that link. To solve this problem we got LSA type-2. Pick DR address of previous example and check Network LSA for this segment.

R2#show ip ospf database network 10.10.123.3

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Net Link States (Area 0)

  Routing Bit Set on this LSA

  LS age: 547

  Options: (No TOS-capability, DC)

  LS Type: Network Links

  Link State ID: 10.10.123.3 (address of Designated Router)

  Advertising Router: 3.3.3.3

  LS Seq Number: 8000000D

  Checksum: 0xEA88

  Length: 36

  Network Mask: /24

        Attached Router: 3.3.3.3

        Attached Router: 1.1.1.1

        Attached Router: 2.2.2.2

Now you may have following conclusions from the above output about shared segment

DR is advertising router 3.3.3.3, and broadcast segment address is 10.10.123.3. This segment has a network mask of /24 and there are three routers associated in this segment 1.1.1.1, 2.2.2.2 and 3.3.3.3

LSA Type 3 (Summary LSA) are generated by all ABRs (Area Border Routers). So ABRs are responsible for exchanging all prefixes from one area into another (ABRs are connected to area0 so LSA3 are exchanged between backbone area and a non backbone area). If an area has multiple ABRs, there will be duplicate entries of all LSA3 advertised by all ABRs to that Area. However, only one entry is a candidate to be installed in routing table based upon lowest end to end cost (total cost from router to ABR and ABR to prefix).

R2#show ip ospf database summary 5.5.5.5

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA

  LS age: 787

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 5.5.5.5 (summary Network Number)

  Advertising Router: 1.1.1.1

  LS Seq Number: 80000001

  Checksum: 0xF227

  Length: 28

  Network Mask: /32

        TOS: 0  Metric: 11

   
  LS age: 787

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 5.5.5.5 (summary Network Number)

  Advertising Router: 4.4.4.4

  LS Seq Number: 80000001

  Checksum: 0xB621

  Length: 28

  Network Mask: /32

        TOS: 0  Metric: 65

From the above output it is clear that Summary LSA of network 5.5.5.5 is advertised by two ABRs R1 (Router ID-1.1.1.1) and R4 (Router ID-4.4.4.4). This network has a mask of /32 and advertised cast from ABRs R1 and R4 to this network are 11 and 65 respectively. So if a router is at equal distance from both the ABRs, effective prefix installed in the routing table will have the forwarding address of R1 and R1 will be in the data plane of actual data flow.

LSA Type 4 (ASBR Summary LSA)- Will discuss this this LSA type after LSA -5.

LSA Type 5 (External LSA) contains the information of Non-OSPF domain routes. The most confusing thing is that its name says external AS routes and router doing so is called ASBR (Autonomous System Boundary Router). However, it has nothing to deal with actual AS Number assigned by IANA or existing  AS  boundary but with the OSPF domain. Any prefix which is generated and advertised by non-OSPF routing protocol are considered as External Prefix and they are maintained as LSA 5 after redistributing them into OSPF domain.  So any route redistributed from Non-OSPF routing protocol to OSPF domain are managed under the category of LSA-5 and installed in the routing table as External type-1 (E1) or External type 2 (E2).

R2#show ip ospf database external 172.16.1.0

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA

  LS age: 83

  Options: (No TOS-capability, DC)

  LS Type: AS External Link

  Link State ID: 172.16.1.0 (External Network Number )

  Advertising Router: 6.6.6.6

  LS Seq Number: 80000006

  Checksum: 0x982D

  Length: 36

  Network Mask: /24

        Metric Type: 2 (Larger than any link state path)

        TOS: 0

        Metric: 20

        Forward Address: 0.0.0.0

        External Route Tag: 0

Information of Advertising Router (ASBR) is maintained end to end, but next hop information is left to default which is later manipulated by LSA 4 when prefix is installed in the routing table.

From LSA 5 you get to know about external routes and its advertising router. But a router in some other area may not know much about ASBR and information about the reachability of it, because Router LSA (Type 1) is not propagated to other Area so link information of ASBR is also missed. That's why OSPF need an additional LSA (Type-4) telling about reachability information of ASBR.

LSA Type 4 (ASBR Summary LSA) is generated by an ABR along with LSA-5, when propagating LSA-5 to other Area. Based on the LSA-4 information router in different area fetch reachability information of ASBR and redistributed routes. Similar to Summary LSA we get multiple entries of Type-4 LSA in presence of multiple ABRs.

R2#sh ip os da asbr-summary 6.6.6.6

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA

  LS age: 359

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(AS Boundary Router)

  Link State ID: 6.6.6.6 (AS Boundary Router address)

  Advertising Router: 3.3.3.3

  LS Seq Number: 80000004

  Checksum: 0x884C

  Length: 28

  Network Mask: /0

        TOS: 0  Metric: 64

LSA Type 7 (NSSA External LSA) is generated in NSSA (Not So Stubby Area), where redistributed routes from other areas (LSA  -5 and LSA-4) are not permitted to get installed in OSPF database. In order to achieve redistribution of external routes in a Stub area are we need to change it to an NSSA. In an NSSA external routes are directly installed as a special LSA Type-7 but any external routes from other areas are still not permitted to get installed in NSSA. However LSA-7 is translated back to LSA-5 by ABR when LSA-7 is injected into a normal area.
In given topology we converted Area-1 to NSSA by running following command on R3 and R6,

R3(config)#router ospf 1
R3(config-router)#area 1 nssa

As a result of that Type-4 and Type-5 got removed an a new LSA Type-7 appeared as below, which is almost similar to LSA-5.

                Type-7 AS External Link States (Area 1)

Link ID         ADV Router    Age         Seq#       Checksum Tag
172.16.1.0      6.6.6.6         59          0x80000001 0x00C1A0 0
172.16.2.0      6.6.6.6         62          0x80000001 0x00B6AA 0
172.16.3.0      6.6.6.6         62          0x80000001 0x00ABB4 0

Now lets check the output of nssa-external LSA of 172.16.1.0 in the NSSA at router R6.

R6#sh ip os database nssa-external 172.16.1.0

            OSPF Router with ID (6.6.6.6) (Process ID 1)

                Type-7 AS External Link States (Area 1)

  LS age: 278

  Options: (No TOS-capability, Type 7/5 translation, DC)

  LS Type: AS External Link

  Link State ID: 172.16.1.0 (External Network Number )

  Advertising Router: 6.6.6.6

  LS Seq Number: 80000002

  Checksum: 0x396E

  Length: 36

  Network Mask: /24

        Metric Type: 2 (Larger than any link state path)

        TOS: 0

        Metric: 20

        Forward Address: 6.6.6.6

        External Route Tag: 0

Now check the same LSA from the R2 (in R2 this prefix is managed under LSA-5, since it got translated from from LSA-7 to LSA-5 by ABR R3 so advertizing router address also appears as R3's Router ID ).

R2#sh ip os database external 172.16.1.0

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA

  LS age: 1079

  Options: (No TOS-capability, DC)

  LS Type: AS External Link

  Link State ID: 172.16.1.0 (External Network Number) 
  Advertising Router: 3.3.3.3

  LS Seq Number: 80000002

  Checksum: 0x2895

  Length: 36

  Network Mask: /24

        Metric Type: 2 (Larger than any link state path)

        TOS: 0

        Metric: 20

        Forward Address: 6.6.6.6

        External Route Tag: 0

Now you can see that forwarding address is still same as ASBR’s address, however advertising router address got changed as ABR’s address. Also, you will notice that no LSA-4 will be generated in this case, because we already have a forwarding router address with this LSA. Also, you will see that metric type is represented as N1 or N2 in the routing table of  a router in NSSA, and same route again converts back to E1 or E2 respectively when reaches to a router in normal area.

I hope you enjoyed and learnt something helpful from this post. Please do comment if you have any suggestion or correction about this post.