7.10. SIFF: An End-Host Capability Mechanism to Mitigate DDoS Flooding Attacks

Yaar et al. [YPS04] propose to mitigate DDoS flooding attacks using an end-host capability mechanism that splits Internet traffic into two classes: privileged and unprivileged. End hosts can exchange capabilities that will be used in privileged traffic. Routers will then verify these capabilities statelessly. These capabilities are assigned in a dynamic fashion, so misbehaving (that is, attacking) hosts can have their capabilities revoked. Contrary to other approaches (e.g., in Section 7.5), this scheme does not require an overlay mechanism, but it does require a modification of the clients and servers, and also routers.

The end hosts would use a handshake protocol to exchange capabilities, and then that privileged traffic would be expedited by the network, in contrast to the unprivileged traffic which does not get precedence. There are provisions in place to prevent flooding with privileged traffic by an unauthorized user, e.g., by someone who tries to forge the capabilities (implemented by markings in each packet). Should an end host with capabilities start flooding, then the credentials for privileged traffic can be revoked for that end host.

The authors of this mechanism propose two avenues: a next-generation Internet incorporating these techniques and a retrofit for the current network protocols in IPv4. It is unclear that these avenues will prove fruitful.

In summary, this technique makes several assumptions, including the assumption that client and server update the TCP/IP protocol software to incorporate modifications necessary for the new capabilities. The advantage is that no inter-ISP or intra-ISP cooperation is necessary. However, it is also assumed that spoofing is limited, and processing and state maintenance are required at each router. The new network protocol requires marking space in the IP header, cooperation of clients and servers, that each router marks packets,^[4] and that routes between hosts on the network remain stable. These assumptions are quite restrictive, compared to what can happen in a real network.

^[4] As mentioned when discussing traceback schemes, packet-marking approaches are not interoperable as they all place their marks in the same field in the IP header.