Roles of DefCOM nodes

DefCOM provides added functionality to existing defenses so they can collaborate in DDoS detection and response. The nodes in the DefCOM overlay are classified into three categories, based on the functionality they provide during the attack:

  1. Alert generator. The functionality is deployed on a native node (router) close to the victim, which may have any sophisticated attack detection mechanism, such as [1]. It receives an attack detection signal from its native node and sends the alert message to all other DefCOM nodes through the overlay. It is Alert generator knows the limits of the victim's resources
  2. Classifier. The functionality is deployed on a native node close to the source, which can perform traffic differentiation such as [2]. A classifier receives packets from its native node, stamped with the legitimate or suspicious mark it negotiated with this node. It restamps the packets with stamps it negotiated with its peers, which ensures priority handling for stamped traffic downstream.
  3. Rate-limiter. The functionality is deployed in a native node (router), which performs a weighted fair share algorithm (such as [3]) for prioritization between legitimate and suspicious traffic class, and to drop unstamped traffic. The rate limiter reclassifies traffic it receives based on incoming traffic stamps and the amount of traffic received from each peer. Traffic is reclassified as legitimate, suspicious or unstamped and it is given to the weighted fair share algorighm.

Each native node can deploy one or more functionalities, depending on its resources and the authorization within the overlay, but the placement of nodes facilitates some functionalities better than others.

Operation

  1. Packet Stamping. DefCOM uses packet stamping to prioritize traffic and to ensure safe delivery of legitimate traffic to a victim of a flooding attack. Every node has a legitimate and a suspicious stamp, which is a number to be placed in a packet's IP header. The node communicates these stamps to all its peers over the secure channel. All node's peers must choose locally unique stamps so that no two peers of a given node have the same stamp.
    During an attack, every packet that goes to the victim is intercepted by a DefCOM node and stamped with a legitimate or suspicious stamp (according to traffic classification rules in Section 2.4), or it is dropped due to rate limiting. The stamp is placed in the ID field of the IPv4 header (IPID field), which is normally used for fragmented packet identification. While it is undesirable to compromise reassembly of fragmented packets, the damage from this will be minimal for these reasons: (1) fragmented packets represent a very small portion (0.25%) of the Internet's traffic as discussed in [4], and (2) DefCOM only stamps traffic going to the victim during the attack, so the unwanted fragmented traffic loss is limited only to the victim
  2. Alarm propagation. The native node of alert generator detects the attack. The alert generator generates an alarm message (ALRM) containing the victim's IP address and resource limits (denoted by RLM).The alarm message is flooded to all DefCOM nodes in a controlled manner to avoid large message duplication. The alert generator sends ALRM message to all its peers in a control manner. When a DefCOM node receives an ALRM for the first time, it starts monitoring and policing traffic according to its functionality (classifier or rate-limiter). We say that this DefCOM node is now active. Only traffic going to the victim will be policed and all other traffic is not affected by DefCOM.
  3. Traffic tree construction. Every active DefCOM node stamps packets it forwards to the victim with its legitimate or suspicious stamp. A node that observes traffic stamped with its peer's stamp designates this peer as a “child” and informs it through a PARENT message that it has acquired a parent. A node that receives a PARENT message designates its originator as a “parent”. Parent-child relationships are recorded in the PeerTable.
  4. Traffic policing. Excess traffic to the victim is shaped and controlled by rate-limiter nodes that learn the victim's resource limits (RLM) from alarm messages and enforce them. A rate-limiter reclassifies each packet based on its incoming stamp and the perceived aggressiveness of the DefCOM child who forwarded it using the following approach:
    1. If this child sends traffic (with any stamp) that exceeds RLM in last T seconds, it will be considered aggressive and all its packets will be reclassified as unstamped during the current second. Note that this can only happen if the child is malicious, since every DefCOM node applies rate limiting to traffic going to the victim and should send below RLM. Otherwise, legitimate and suspicious classifications are preserved.
    2. If the total unstamped traffic does not exceed RLM in last Tseconds, it will be considered nonaggressive and reclassified as suspicious. Otherwise DefCOM preserves the unstamped classification.
    After reclassification, packets are either marked with the legitimate or suspicious stamp, or their stamp is removed, and they are passed to the native node. The native node should drop unstamped traffic and apply weighted fair sharing to prioritize marked-legitimate over marked-suspicious traffic.
  5. End of attack detection. Each node detects the end of the attack locally when it drops no traffic
    due to rate limiting in the last Tend seconds. Global end of the attack is detected when all DefCOM nodes have detected the end of the attack locally. An active node which drops any traffic during the last Tend seconds generates an ATTCKCONT message and floods it in the overlay. A node that receives an ATTCKCONT message suppresses it if it has itself generated a similar message in the last Tend . This optimization prevents a flood of ATTCKCONT messages in the overlay. Nodes that have detected the local end of the attack stop generating ATTCKCONT messages but still forward these messages sent by other nodes. Global end of the attack is detected when a node does not receive or generate an ATTCKCONT message in the last Tend seconds.

References

1. X. Yang, D. Wetherall, and T. Anderson. “A DoS-limiting network architecture,” In Proceedings of ACM SIGCOMM 2005.

2. J. Mirkovic, G. Prier, and P. Reiher, ”Attacking DDoS at the Source”, in Proceedings of the ICNP 2002, November 2002.

3. I. Stoica, S. Shenker, and H. Zhang, ”Core-stateless fair queueing: Achieving approximately fair bandwidth allocations in high speed networks”, Carnegie Mellon Univ., Pittsburgh, PA, Tech. Rep. CMUCS- 98-136, 1998.