Some Examples

The first policy decision that an ISP will need to make is what to do with the packets when an attack is identified. When DDoS attacks are identified and classified, the ISP must make a decision. Classification will provide the DDoS flow's source IP addresses—hence, a target for filtering. However, do you filter all the packets from that source address, filter some of the packets from that source address, or just rate-limit the attack from that address?

The source IP addresses from DDoS attacks can have one of four characteristics. The characteristic of the source will be a factor in the decision on coarse packet drops, detailed packet drops, rate limiting, or no action at all.

• Spoofed RFC 1918 and special-use addresses— These are the easiest addresses to spot and drop. They are well known, are not in the global Internet Route Table, and easily can be dropped with passive packet-filtering tools. Many networks have ingress/egress packet filters that block these packets from propagating through the Internet. Unfortunately, these passive packet filters are not ubiquitous. So sometimes an ISP will see DDoS attacks with these addresses. The reaction decision is easy: Drop these.

• Spoofed addresses that are not in the global Internet Route Table — Cyberpunks have found ways to get around the well-known packet filters that drop well-known RFC 1918 and special-use addresses. The most common technique is to use addresses that have not been allocated to any ISP or added to the global Internet Route Table. RIRs allocate blocks of IP addresses to ISPs and subregistries. These RIR allocations come from delegations of authority from the Internet Assigned Numbers Authority (IANA). The list of IPv4 address blocks that have not been activated is easily accessible at This makes it easy for someone to create an attack with spoofed addresses based on this list. Because these addresses are not in the global Internet Route Table, a simple check in the forwarding table easily can aid in their identification. Some tools, such as uRPF, make this check straightforward, making it harder for these attacks to be successful. The reaction when faced with these sorts of attacks is to drop the packets.

• Valid address from a DDoS agent— Some attackers will sacrifice the DDoS agent that they have penetrated to achieve their objectives. In this case, the source address will be the actual address of the penetrated system. For some attacks (such as TCP SYN and ACK attacks), these are easy to identify and classify. Other attacks, designed to overwhelm the target with valid traffic, are not as easy to identify and classify, especially when the attacks are based on simple HTTP GET request. When a particular source address has been classified as a DDoS agent, the ISP needs to decide whether to drop all the packets from that penetrated machine, drop only the attacking traffic flow, or just rate-limit the attack. This is a valid computer with a person behind it. Hence, dropping all packets from this source address might seem extreme. Yet it is a penetrated machine, making it a threat that needs to be resolved. The reaction decision for these sorts of attacks is mixed: Most can be dropped; a few can just be rate-limited.

• Spoofed address using a valid address from somewhere else on the Internet— The most difficult source addresses to react to are those that are valid addresses but that are spoofing another site. This is a case in which you will get a reverse DDoS attack. The attacker's actual target is not the target that the DDoS agents send packets to, but the real target is the one whose addresses are being spoofed. For example, the real target is an enterprise with several connections to the Internet. The attacker knows that several connections, redundancy, IDS tools, firewalls, and other tricks make the enterprise a tough target to take down. So, instead of trying to take down the enterprise's network, the attacker works to get others to isolate it from the net. DDoS attacks spoofing the enterprise's source IP range frequently are attempted.

These are just a few examples of techniques used by cyberpunks to implement DoS attacks—there are others based on similar ideas. The more the ISP is aware of the capabilities and opportunities available to these people, the better prepared and protected it will be if any problem occurs on its network.


This chapter covered router security, routing protocol security, and general network security. It then went into some of the techniques and configuration concepts that ISPs should be considering and implementing in their backbones, especially the significance of BCP 38/RFC 2827. It discussed in depth the great importance of uRPF and gave configuration examples of the different applications and scenarios in which uRPF can be applied. The chapter concluded by discussing the use of CAR as an anti-DoS tool.

The "Technical References and Recommended Reading" section at the end of this book has many references and pointers to further technical documents discussing ISP security issues. This is a very large subject that quite easily could justify a whole book in itself. We hope that this chapter has given you an overview of what is available in IOS Software so that ISPs can protect themselves, their customers, and the Internet.


1. The Telnet server is disabled on any VTY port that does not have a password or some other authentication configured.

2. Section enhancements are compliments of Chris M. Lonvick ([email protected]).

3. SSH client and server also was included in IOS Software from 12.1T (and in the mainline 12.2 release).

4. Experiments with multicast BGP (MBGP) now have begun on some ISP sites. Deployment of MBGP requires a rethink and redesign of the egress and ingress route filters.

5. Currently, the minimal allocation block for the RIRs consists of /20s.

6. Because Internet drafts expire six months after publication, it is worth checking whether there is a revised draft or whether an RFC document has replaced the draft before implementing this list.

7. Thanks to Patrick W. Gilmore of Priori Networks for supplying the list.

8. NANOG Mailing List—Subject: Re: too many routes. From: Sean M. Doran < [email protected] > Date: 10 Sep 1997 20:33:09 -0400 (see for mailing list archives).

9. Based on work done by Rakesh Dubey ([email protected]) and Steve LeGault ([email protected]).

10. Original documentation on uRPF was performed by Bruce R. Babcock ([email protected]).

11. This technique is used in some multihoming configurations.

12. This section was taken from the release notes of CSCdp76668 by the engineer who coded this function, Neil Jarvis ([email protected]).

13. There was a bug in IOS Software Release 12.0(10)S. The Help option in IOS Software displays only the standard and extended standard access lists as options. Standard/expanded and extended/expanded ACLs both work.

14. For multihomed customers, see the section on uRPF limitations.

15. The customer's assigned IP block (that is, routing prefixes) usually is inserted into the ISP's network in one of several ways. Any of these ways will work as the information is passed to the CEF tables.

16. At the time of this publication, work has started in the IETF to consider some new options for one ISP to influence the best-path decision of another ISP.

17. Because local preference is a nontransitive attribute working only inside one AS, many customers are encouraged to include the BGP community no-export with their split advertisements along with the advertisement of their entire blocks. That way, they receive the benefits of traffic-engineered multihoming with the ISP while keeping the more specific prefixes from the split-advertisement technique off the rest of the Internet.

18. Policy-based routing could be used, but it is neither efficient (because of the performance penalty) nor scalable (consider how this would be implemented for thousands of leased-line customers).

19. RFC 1998, "An Application of the BGP Community Attribute in Multi-home Routing," now is used widely in the ISP community.

21. This section is an edited version of Craig Huegen's work on smurf and frag protection. For the latest information, refer to Craig's page at Craig can be contacted at [email protected]

Was this article helpful?

0 0

Post a comment