Navigation auf uzh.ch
Navigation auf uzh.ch
The exponential increase of the traffic volume makes Distributed Denial-of-Service (DDoS) attacks a top security threat to service providers. Existing DDoS defense mechanisms lack resources and flexibility to cope with attacks by themselves and by utilizing other's companies resources, the burden of the mitigation can be shared. Technologies as blockchain and smart contracts allow distributing attack information across multiple domains, while SDN (Software-Defined Networking) and NFV (Network Function Virtualization) enables to scale the defense capabilities on demand. This proposal presents the design of an architecture combining these elements and introducing novel opportunities for flexible and efficient DDoS mitigation solutions across multiple domains.
If you have questions contact Bruno Rodrigues
The proposed protocol for signaling DDoS attacks is presented in Figure 4. The protocol foresees the rating of both the mitigation service performed by an M entity that accepts a mitigation request and a T entity that is the target of the attack. In the first step, T requests the cooperative defense by signaling the request to M, which in the sequence, can be accepted or denied by M. If the request is accepted, a service deadline (denoted by t0) starts. This deadline is the service deadline for M to upload a proof of completion of the requested mitigation task. At this point (start of t0), M can act in a rational way and upload a proof or miss the upload. However, it is not possible to verify the truthfulness or the quality of the (proof of) service performed by M. Even if the Blockchain technology can preserve a transparent audit trail for all transactions, it cannot compensate for a lack of ground-truth. This holds for the uploaded proof of service as well as for user-defined, subjective ratings, in which there is no automated way to fully determine the truthfulness of proof or rating.
In the sequence, the target T need to rate the service (or the lack thereof) of M within a validation deadline. Case a proof has been uploaded, the target T can be satisfied or dissatisfied and rate accordingly. In this sense, T cannot be malicious, only satisfied or dissatisfied. If T is honest, it can either rate positively and acknowledge the service (satisfied) or rate negatively and reject the service (dissatisfied). Then, a rational M can rate according to the expectation of T. This rational M responds to a rejected service by rating T negatively. However, if rational M receives positive feedback from T, it will also respond positively. When there is no feedback (i.e. T is selfish), a rational M is only allowed to rate negatively. Lastly, the last describes the consequence of the possible branches with either an incentive being rewarded to M or refunded to T, or with an escalation process, since M might want to reclaim the payout of a rejected service.
An overview of the entire BloSS architecture is provided below detailing the connections between all modules. The BloSS is the component where each service provider taking part in the cooperative defense and is running BloSS, is able to post information about an ongoing attack to the Ethereum Blockchain. It uses a REST interface to facilitate the isolation of the BloSS module, encapsulating the entire module together with Pollen Blockchain and Pollen data store inside a VNF.
Data exchange is accomplished with the "Pollen" set of modules and network-related tasks are handled by the "Stalk" module. Pollen is divided into dedicated modules for the individual data exchange duties of the BloSS which includes a Blockchain module for access to the Ethereum Blockchain, a data store module managing data on the Inter-Planetary File System (IPFS). Attack information posted to the Blockchain is not directly stored on the Blockchain due to limited block sizes and to maintain the information confidential. For this purpose, IPFS is used as a decentralized and highly scalable storage solution to hold attack information. Each service provider running the BloSS also maintains an IPFS node to enable the decentralized storage. Whenever a new set of attack information is posted to the Blockchain, the data is first stored in IPFS and only the hash as a unique identifier of the storage location within IPFS, is stored in a block on the Ethereum Blockchain. Pollen data store also includes an encryption component since it is an inherent part of the entire module. The encryption of attack information posted to IPFS ensures the confidentiality as well as the integrity of the attack information based on a per-message signature bundled with the attack information.
Verifying the integrity of the attack information allows to hold each service provider accountable for the information posted to the Blockchain and makes the forgery of attack information impossible. The integrity-check is enabled through a public key published by each service provider to the Blockchain and therefore available to all providers participating in the BloSS defense alliance. Without this measure in place, forgery of attack information could allow a malevolent party to indicate specific IP addresses as being the source of an ongoing attack and in effect, blocking flows from these addresses to the target address specified in the attack information.
The OpenFlow-enabled Zodiac FX switches provide an inexpensive alternative to experiment SDN prototypes in hardware. They are connected to a host running a Ryu SDN controller, and the dApp is connected to the blockchain. Each AS is connected to five hosts deployed in hardware with ASUS Tinker Board devices (Raspberry-Pi like devices). Each board has a Gigabit Ethernet port that is sufficient to overload Fast Ethernet (10/100 Mbits) ports of the Zodiac FX boards, and thus, simulate a DDoS attack.
