Mitigating DDoS in decentralized Peer-to-Peer networks ====================================================== Protecting against DoS as a part of Peer-to-Peer security may not be an entirely new idea, but it's currently a very neglected, under-applied security strategy that deserves more attention. Today, most popular systems basing on P2P protocols have a high susceptibility to distributed bandwidth exhaustion. Distributed bandwidth overloading from multiple entry points is the biggest common weakness of decentralized P2P. Some existing file-sharing and communication networks have been 'successfully' disrupted via request- and reply- flood DDoS in the past (e.g., gnutella). The origin of this weakness is that there is no single point in P2P networks where detection and protection against attacks can be applied, so simple client/server security approaches are doomed to fail, and the only method is to avoid single points of failure as well, and not count on them. This means that the reliability and security models of decentralized P2P networks must be modeled after the Internet in order to be effective. Modelled after Internet routing, such a P2P network must not count on reliable transfer to be reliable itself. TCP offers those features, but only on the routing level of Internet packets. Because decentralized networks need a second, independent routing level, their error handling of that routing needs to be independent, too. I.e., the basic requirement for further availability assuring routing are the possibility to deal with transmission failures of single packets, and to issue and handle re-requests for partial data and timeouts well (due to remote disconnects and changes in the network structure, single malicious peers that deny forwarding data over a specific route, or bandwidth overload at single points). Generic protocol enhancement steps for P2P availability Step 1: Unreliability. Drop all excess traffic that overloads a node's own bandwidth or would overlink uplink bandwidth. Implies being able to handle and re-request loss. Step 2: A bandwidth metric for remote peers. Each peer must know what the other can handle in order to prevent overloading its uplinks. Step 3: Miniature reputation model. Introduce a neighbor-reputation model, whereby peers are blacklisted or downgraded for direct connections if they knowingly overload us, that is, exceed our specified direct-peer uplink bandwidth, including with excess traffic originating from other, third-party nodes. In turn, keep a good reputation list of direct peers that never overloaded our specified maximum bandwidth. In summary, this simple scenario assures availability in decentralized networks by making them rely on self-control, happening by whoever sends data upstream, which achieves scalable many-to-many protection, as it covers each point of failure (each direct connection) in a network. It doesn't matter anymore whether we have malicious 'clients' issuing mass requests or malicious 'servers' flooding a network with bogus oversized replies in this scenario. Our only basic assumption is that the majority of peers are not hostile, and will neither all try to cause DoS, nor cause accidental bandwidth problems, once the maximum capacity of their direct peers is directly advertised to them. This strategy is the most basic for mitigating DDoS in any kind of semi- or truely decentralized network, theoretically including protocols for edge routing (BGP, EIGRP, ...), Ad-Hoc WiFi, Bluetooth, but not e.g., cellphones, as the cells have a centralized client/server structure. Discussion Contrary to other attack countermeasures in large distributed networks, no heuristic analysis is necessary for this 'dumb' protocol-enhancement method, since all traffic can still be treated as equal. Caveats include that very fast peers, peering with other fast peers (ad-hoc 'backbones' in decentralized networks) might inject very fast, hostile traffic, while still respecting the fast uplink's capacity limit, to worsen the overall signal/noise ratios of the other fast/core peers of an ad-hoc 'backbone'. The next countermeasure would have to be a bigger protocol enhancement than the proposed 3 steps, probably necessarily introducing a reciprocal Quality Of Service system, which, in turn, would need crypto-based pseudonymous identities to be secure. Recommended reading ------------------- [1] Peer-To-Peer: Harnessing the power of disruptive technologies http://www.oreilly.com/catalog/peertopeer/ [2] Brahm Cohen - Security in P2P File Distribution http://www.blackhat.com/presentations/bh-europe-03/bh-europe-03-cohen.pdf [3] Future and Security of Decentralized applications http://mixter.void.ru/p2p.tgz ----------------------------------------------------------------------- 2004, Mixter - http://mixter.void.ru/papers.html