Denial-of-Service (DoS) flooding attacks have become an increasing threat to the reliability of the Internet. These attacks are capable of knocking any user, site, and server right off the Internet. The goal of this project is to design a network architecture that is resistant to DoS flooding attacks. Currently we are exploring two directions: one is capabilities combined with hierarchical fair queueing, and the other is packet filtering based on authentic source identifier.
TVA is built on capabilities, which are short-term authorizations that senders obtain from receivers and stamp on their packets. If a receiver does not want traffic from a sender, it can simply refuse to grant capabilities to the sender, and the traffic will have lower priority. This allows the receiver to control the traffic it receives and prevent attackers from congesting links by flooding.
With TVA, a typical session between a sender X and a receiver Y is:
All TVA-related messages are piggy-backed into normal traffic between senders and receivers. For instance, in the session described above, if X and Y use TCP to communicate, the request message would be embedded into the packet carrying TCP SYN from X to Y, and the capabilities-granting message would be embedded into the packet carrying TCP SYN/ACK from Y to X.
There are several challenges in designing TVA:
We made a prototype of TVA on Linux and benchmarked it. With a commodity PC we can achieve the forward speed of about 660k packet-per-second for small packets with capabilities (no caching on routers). We also made a prototype of TVA in ns2 simulator and compared with several other DoS prevention schemes. We out-performed others in all the simulations.
Packet filtering is another tool for mitigating DoS flooding attacks: when a receiver does not want traffic from a sender, it can request to block the traffic before it congests a link.
The first challenge for designing an effective packet filtering system is to identify attack sources and attack traffic. In the current Internet, it is easy for attackers to spoof source IP addresses, and there are no reliable source identifiers in IP packets. Due to lack of authentic source identifiers, it is very difficult to efficiently and precisely locate attack sources and filter attack traffic.
Our solution to reliable source identifier is "Packet Passport". A packet passport is a piece of authentication information embedded into an IP packet that authenticates the source IP address. Packet passports cannot be spoofed, and they can be verified by routers on the path at packet forwarding time. A naive way to implement packet passports is to use digital signatures: the sender signs each packet with its private key, and routers and the receiver verify the digital signature with the source's public key. This approach is infeasible with current hardware technology, because digital signature generation and verification are still too slow to support line-speed packet forwarding. To make packet passport generation and verification efficient, we use Message Authentication Codes (MACs) instead of digital signatures. MAC computation is light-weighted, and there are already hardware implementations for some MAC schemes.
|
| Figure 1: Packet Passport Overview |
Figure 1 provides an overview of our packet passport system. Some fields of the packet passport are omitted here for simplicity. Before normal data packets are sent, every two domains have established a key shared between them using Diffie-Hellman key exchange protocol. For instance, AS1 and AS2 share a key K(AS1, AS2). These pair-wise keys are used to generate and verify packet passports. The key exchange messages are piggy-backed in BGP prefix announcements.
Now suppose host A in AS1 sends a packet to host B in AS4. The border router R2 inserts into the packet a passport with three MACs, each computed using the key K(AS1,ASj), j = 2, 3, 4. When the packet arrives at AS2, the border router R3 uses K(AS1,AS2) to verify the first MAC to make sure that the packet comes from AS1. Similarly, R5 and R7 each uses the corresponding key shared with AS1 to verify the corresponding MAC.
One key feature of our design is that it requires minimum trust between domains. No transitive trust is required: if a domain is malicious or has its routers compromised, it cannot spoof packet passports of other domains, because it does not know the keys shared between other pairs of domains. This significantly limits the damage compromised routers or malicious domains can cause. It also gives domains the incentives to maintain good behavior and avoid having routers compromised. This requirement for minimum trust is our major advantage over ingress filtering, which tries to make source IP address reliable source identifier by requiring every domain drop packets with spoofed source IP addresses. With ingress filtering, each domain has to trust that all other domains have eliminated source IP address spoofing. If a single domain does not do ingress filtering, either because it has not deployed or because it has compromised routers, attackers in it can spoof anyone's source IP address, and other domains cannot treat source IP addresses of the packets they receive as reliable source identifiers.
We have implemented a prototype of the packet passport system on Linux. The benchmark result shows that on a commodity PC we can stamp packet passports and forward the packets at the speed of up to 600k packets per second. We also have run emulations on Deterlab to show the benifits of combining packet passport with several other DoS prevention schemes. The result shows that adding packet passport can greatly improve their performance.
Packet passport is a very convenient and promising building block for packet filtering systems. We have designed such a system and finished a prototype implementation on Linux, but we are still evaluating and tweaking it.
This work is supported by the National Science Foundation under Award 0627787.
We welcome any comment, question or feedback. Please send email to Xin Liu or Xiaowei Yang.
Last Updated: March 17th, 2008