1. BGP Security Features Security on ISP networks can be very difficult because of the networks public nature.

No firewalls protect routers, and device addressing is typically visible externally. This provides attackers with significant information about network devices and the ability to send packets unobstructed to those devices. The subject of ISP security is examined in this section from two angles. The first angle is protecting the BGP infrastructure itself. The BGP infrastructure is the actual BGP peering sessions. The next section explains BGP MD5 and justifies its use. The second angle is protecting against malicious BGP advertisements or advertisement patterns. Proper filtering and route dampening guidelines are provided in the following sections. The security issues surrounding public peering are covered, and three specific scenarios are explained that have been encountered in the field. 2. TCP MD5 Signatures for BGP Sessions The BGP infrastructure can be directly attacked by attacking a BGP sessions TCP layer. A TCP Reset that is accepted by the router for a BGP session results in a session reset. The source and destination addresses for an eBGP session can be determined through the use of trace route. The trace route results provide the link address of one side of the peering connection. It is standard practice for eBGP sessions to peer using directly connected IP addresses in the same IP subnet. The IP address for both sides of the BGP session can be derived from one link address. A TCP packet is considered valid for the session if the source address, destination address, source port, destination port, and TCP sequence numbers are correct. The attacker already knows the source and destination addresses and one of the ports, because BGP uses TCP port 179. Figure 9-5 shows the attack scenario. 3. Peer Filtering Routing information should not be accepted indiscriminately from customers or peers. Two classifications of prefixes should not be advertised on the Internet: Prefixes reserved for special use, such as RFC 1918 space. Unallocated address space. These prefixes are called Martian addresses or bogons. The initial classification of prefixes (those that are reserved and should not be publicly routed) can be configured for every peering session. The prefix list for these networks is provided in Example 9-11. Example 9-11 Prefix List to Filter Reserved Addresses
ip prefix-list MARTIAN seq 5 deny 0.0.0.0/8 ip prefix-list MARTIAN seq 10 deny 10.0.0.0/8 ip prefix-list MARTIAN seq 15 deny 127.0.0.0/8 ip prefix-list MARTIAN seq 20 deny 168.254.0.0/16 ip prefix-list MARTIAN seq 25 deny 172.16.0.0/12 ip prefix-list MARTIAN seq 30 deny 192.0.2.0/24 ip prefix-list MARTIAN seq 35 deny 192.168.0.0/16 ip prefix-list MARTIAN seq 40 deny 224.0.0.0/4 ip prefix-list MARTIAN seq 45 deny 240.0.0.0/4

This prefix list is also provided in Chapter 6, with a detailed explanation of each prefix. The second classification is prefix blocks that IANA has not yet allocated to a registry for assignment. It is very common to see these prefixes advertised into the global BGP table; however, they are invalid. This list changes periodically as IANA allocates blocks to ARIN, APNIC, and RIPE. The current allocation status for the IPv4 address space is available at www.iana.org. A sample bogon list is not presented here because of the lists dynamic nature. If an ISP will filter bogon prefixes, which is recommended, the appropriate prefix list should be built based on the allocation status from the IANA website

4. Public Peering Security Concerns Public peering points are a potential area of abuse by unethical network administrators. By manipulating routing information, it is possible to redirect traffic over other providers networks. It is also possible to build tunnels over another providers network, creating a virtual backbone circuit that offloads traffic from the offending ISPs network onto the unsuspecting peer. This section describes the three most common abuses and the measures an ISP can take to prevent the theft of network resources: Pointing default Third-party next hop GRE tunneling >Pointing Default The simplest method of peering point abuse is originating a default route into the ISP network from the peering router at the NAP. The default route at the NAP is pointed to another ISP. Traffic is then sent to the ISPs NAP router and to the unsuspecting ISP. ISP1 points its default route at ISP2 on the NAP router. Traffic sent to the NAP router at ISP2 is unwittingly treated as transit traffic by ISP2. ISP1 can receive free transit over Fast Ethernet. This scenario is most common when ISP1 is much smaller than ISP2. The cost of the link to the NAP is cheaper than the transit connection. The solution is not to carry full BGP routes on the NAP router. If ISP2 carries only customer routes on the NAP router, the traffic sent from ISP1 to ISP2 is black-holed, because ISP2 has no route for those destinations. A default route on the NAP router to null0 should also be configured to prevent any routing loops. However, traffic destined for ISP2s customers is still delivered. >GRE Tunneling The scenario in this section involves the use of GRE tunneling between peering routers. If ISP1 and ISP2 are at multiple NAPs, not necessarily peering, the unethical ISP1 can build a GRE tunnel across ISP2s network and use that tunnel as another virtual backbone link. This is shown in Figure 9-8.

In Figure 9-8, ISP1 has built a GRE tunnel between its interface at NAP1 and its interface at NAP2, where both ISP1 and ISP2 are located. The NAP router for ISP1 has a static route configured as a /32 to the other end of the tunnel pointing to the interface on ISP2s router. This builds the tunnel over ISP2s network, on which ISP1 can run its IGP, treating that tunnel as a pseudowire.

The solution to this scenario goes back to how next hop for BGP prefixes is handled. The NAP router for ISP2 should reset the next hop for all BGP prefixes received on the NAP router from external peers. This removes any need to carry the NAP link addressing in the IGP. If ISP2 does not carry the NAP interface network in its IGP, the GRE tunnel does not form. 5. Case Study: Distributed Denial-of-Service Attack Mitigation Distributed Denial-of-Service (DDoS) attacks have become an increasingly popular Internet attack mechanism because of the volume of traffic they can generate. The ISP providing connectivity to the victim host finds them difficult to deal with. The traffic enters the ISP from every upstream transit connection and peering point, making it very difficult to discard. A popular solution for the ISP is to null-route the victim host on all the edge routers. This requires the ISP to touch every edge router to configure the null route. The null routes must later be removed from all routers to restore service to the victim host. If this is not done correctly, connectivity problems will result. This case study explains a dynamic method for null-routing DDoS traffic on all the edge routers, with minimal configuration required during the actual attack. This DDoS mitigation design also provides the ability to redirect the DDoS traffic to a sink router, where it can be analyzed if needed. The key to quickly mitigating the impact of a DDoS is to have the infrastructure and process in place before the attack happens. Unfortunately, as is the case with volume-based denial of service attacks, currently it is not possible to discard the attack traffic and leave valid traffic intact for the victim host. 6. Dynamic Black Hole Routing The proposed solution to combating DDoS attacks is a dynamic black hole routing system. This system must be put in place before the actual DDoS attack. This system has two major design goals: Quickly initiate network-wide null routing for a prefix or network with minimal configuration Quickly initiate network-wide redirection of traffic for a prefix or network to a sink router with minimal configuration The dynamic black hole system is based on the concept of advertising a BGP prefix and setting the next-hop attribute to an address that is covered by a null route, which is a route pointing toward null0. The null route is configured on every router. The victims prefix or address is then advertised into BGP with the next hop set to the static null route. iBGP advertises the route to all the edge routers, and then the route is installed into the CEF table with a next hop of Null0. This effectively stops the DDoS traffic at the network edge. You can extend this system to support a sink router by setting the prefixs next hop to the sink router instead of the prefix directed at Null0. The victim address or network should be injected on a special sinkhole router. If the route is configured on an edge router, the next hop is reset because of the next-hop-self setting on the BGP sessions to the aggregation routers, and all traffic is drawn to that edge router. It is inadvisable to make unnecessary configuration changes on core or aggregation routers or to inject routing information on these