Blockchain Signaling System (BloSS)
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
Cooperative Signaling Protocol
The proposed protocol for signaling DDoS attacks is presented in Figure 4 [IM19]. 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 (an issue discussed in [CyberSci18]). 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 [AIMS17, LCN17]. 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.
- A study case built on hardware represents three Autonomous Systems (ASes), AS100, AS200 and AS300. These ASes are connected to the blockchain via a management network 188.8.131.52/24 to ensure a congestion-free channel. Besides of mining the blockchain. The inter-domain network is configured with the AS 100 connected to the AS 200 using network 10.0.1.0/24, which is connected to AS 300 through the 10.0.2.0/24 network. Hosts are configured with static addresses at each AS.
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.
- Bruno Rodrigues, Lukas Eisenring, Eder Scheid, Thomas Bocek, Burkhard Stiller. Evaluating a Blockchain-based Cooperative Defense. 16th IFIP/IEEE International Symposium on Integrated Network Management (IM 2019). 8-12 April. Washington DC, USA
- Stephan Mannhart, Bruno Rodrigues, Eder Scheid, Salil S. Kanhere, Burkhard Stiller. Towards Mitigation-as-a-Service in Cooperative Network Defenses .. The 3rd IEEE Cyber-Science and Technology Congress. Link.
- Bruno Rodrigues, Thomas Bocek, Burkhard Stiller. Blockchain Signaling System (BloSS): Enabling a Cooperative and Multi-domain DDoS Defense. Demonstrations of the 42nd Annual IEEE Conference on Local Computer Networks (LCN-Demos 2017). Singapore, 8-12 October. Link
- Bruno Rodrigues, Thomas Bocek, Burkhard Stiller. Multi-domain DDoS Mitigation Based on Blockchains. 11th International Conference on Autonomous Infrastructure, Management and Security (AIMS 2017). "Security of Networks and Services in an All-Connected World", Zürich, Switzerland, July 2017, ISBN 978-3-319-60773-3, pp 159–164. Link
- Bruno Rodrigues, Thomas Bocek, David Hausheer, Andri Lareida, Sina Rafati, Burkhard Stiller. A Blockchain-based Architecture for Collaborative DDoS Mitigation with Smart Contracts and SDN. 11th International Conference on Autonomous Infrastructure, Management and Security (AIMS 2017). "Security of Networks and Services in an All-Connected World", Zürich, Switzerland, July 2017, ISBN 978-3-319-60773-3, pp 16–29. Link