A signaling system operates within a collaborative context to advertise peers of events and you probably will not need one, but your favourite Internet/Content Service Provider (ISP and CSP) could mostly benefit from it.
While an ISP is the company that provides Internet connection to companies and invidivuals, a CSP provides application-oriented services to those companies and individuals via a "Content Delivery Network".
For example, YouTube and Netflix are major content providers that require multiple CDNs to provide content in a global scale. Unavailability (either due to poor "reliability" or to cyber-attacks) on those services would directly imply in financial and reputation losses.
The idea of this system aroused within the context of the increasing number of Distributed Denial-of-Service (DDoS) attacks, which, empowered by the increasing number of "things" connected to the Internet, are capable to reach Terabytes in terms of traffic volume at a single target (i.e., your ISP/CSP) as it was seen in multiple cases since 2016 (e.g., DynDNS, OVS).
In this context a signaling system would act to advertise peers across the Internet about ongoing DDoS attacks pretty much like a peer-to-peer scrubbing center, but without dictating how each peer should do the mitigation of an advertised list of IP addresses to be blocked.
Once a DDoS attacks behaves in a widely distributed manner, an equally distributed defense would be ideal to counter large-scale attacks (typically involving millions of devices).
Major benefits of a distributed defense in contrast to a centralized DDoS defense are:
Exploit the heterogeneity on the underlying networking infrastructure of different domains to expand detection/mitigation capabilities.
Distribute the burden of detecting and mitigating DDoS attacks across multiple domains deployed at edge/access networks.
Block malicious traffic near the source.
However, there are relevant challenges of different dimensions that hinders the existence of an effective cooperation between different domains on the Internet.
Trust is hardly established between different organizations due to multiple reasons that could impact the public image of an ISP/CSP (perhaps the most important asset). For instance, data related to availability could be leaked by direct competitors to create market advantage.
Technical aspects arising from the heterogeneity of underlying networking systems are also a challenge. For example, how to establish signaling protocols for attacks as well as to communicate available mitigation actions that are compatible with those different underlying systems.
Cooperative detection and mitigation actions generally incur operating costs, a fact that discourages third parties from participating in a cooperative defense. Therefore, there is a "financial-related" challenge related to how to provide the necessary incentives to promote the participation of third parties in a cooperative defense.
Legal aspects are another dimension of challenge that, despite being simple to be technically contemplated, represent major challenges in a "governance sphere" due to the different legislations to which organizations belonging to the cooperative defense may be subjected to.
Random picture of me talking about Smart Contracts code failures during the ICBC 2019 tutorial (Seoul, South Korea)
A short answer is that "Blockchain" (BC) has no role within a cooperative defense, and a long answer tells that a particular type of BC may be helpful.
It is important at first to distinguish between a "BC" and a "Distributed Ledger" (DLC).
In a broader sense a BC is a DL Technology (DLT) that determines a very particular type of ledger in which the participation on the consensus mechanism is open to anyone. Conversely, a DL restricts participation in the consensus mechanism to selected participants.
This difference is determinant in the context of a cooperative defense due to intrinsic need to maintain the equilibrium between transparency and confidentiality of the information signaled. While transparency is a key factor toward increasing (pre-existing) levels of trust, confidenciality is needed to minimize the amount of sensitive (e.g., list of IP addresses) information exchanged within the cooperative network.
Ok, then why not to use a distributed database?
Ultimately this question relies on the level of trust between cooperative members (and how do you measure - if possible - trust).
A distributed database allows entities maintaining the database to update or delete entries, which implies in an existing and full level of trust between members of the cooperative defense.
However, in case of an existing level of trust without "full trust", the addition of a DL could make sense to increase levels of trust based on repeated and verifiable interactions among members of the cooperative defense.
In addition to a DL allowing full replication of signaled events without alterations or deletions, it enables the possibility of exchanging financial incentives as an inherent characteristic as well as the participation of all members in the consensus.
The choice of which underlying technology to use relies on how much an organization trusts another organization within the cooperative defense.
Ultimately, it also relies on the fundamental problem of "how to measure trust" in a decentralized setting, which is not something straightforward to be determined once "trust" is relative to an individual perception or level of confidence/expectation of an outcome for a given circumstance.
One of the main arguments in favor of DL's is the increase in transparency between cooperative members, whether they are from a supply chain or from a cooperative defense. Therefore, based on repeated verifiable interactions in which there must be a balance between public information on-chain and off-chain, it becomes possible to increase the trust between its members if there is a pre-existing trust level.
Another aspect that cannot be neglected in this context is the fact that the mere use of a system or technology cannot create trust between unknown organizations. This is due to repeated interactions whose results correspond to the expectations of both, and this fact is not due to the mere use of a technology.
In this sense, the claim that the use of BC or DL automatically imply in a "trusted system" is false, and it is important to be highlighted in any given BC- or DL-based application advertising a "trustless application".
I will mostly focus on the description of the prototype (as seen in the first figure) since the concept has been detailed in many publications.
While Blockchain simplifies existing cooperative approaches with an out-of-the-box distributed infrastructure to broadcast addresses without the need to build specialized registries or other distribution mechanisms/protocols, software-defined networks (SDN) can optimize the management of flows in response to attacks.
The BloSS prototype
After an initial prototype implementing different network domains on the same host (that is, a laptop), the second step was to extend the prototype to a truly distributed approach. At this point came the idea of using System on a Chip boards to develop the project (ASUS Tinkerboard was the choice). Although remaining on a smaller scale, the prototype allows evaluating with a more practical view different aspects of the system (mainly related to performance and correctness of the proposed protocols).
The figure below depicts the BloSS system in during a test the night before the demonstration in LCN 2017 (held in Singapore, which was awarded the best demonstration of the event).
BloSS in the (successfull) Singapore Mission - One of the biggest threats was the airport security "no sir, this is not a bomb."
The first BloSS prototype had three Autonomous Systems (ASes), AS100, AS200 and AS300 (in fact these 3 independent ASes were used to showcase the system in all "evolutions" of the system). Each AS had its own network configured on its own router and there was a management router in order to provide easy WiFi access and an isolated management network (i.e., the BloSS network).
Based on a Distributed Ledger rather than a Blockchain
BloSS was deployed based on a Proof-of-Authority Ethereum whereas each AS is an authority responsible to "stamp" blocks in a round-robin fashion (using the Clique protocol). Hence, the "Blockchain" Signaling System is rather based on a Distributed Ledger with a permissioned consensus rather than a Blockchain with a permissionless consensus (such as Proof-of-Work as deployed in Bitcoin).
In fact the first two versions of the prototype were based on a Proof-of-Work consensus which required 3 laptops for mining at a lowest possible difficulty. The first version was based on Mininet using a Ryu SDN controller to advertise the following string in a very simple smart contract:
Upon retrieving the block, other domains would parse the string and automatically block IP addresses belonging to their network.
It was straightforward to see that the initial approach was unfeasible due to the many restrictions of running PoW on local instances, the need for confidenciality within a cooperative defense setting, and the impossibility to execute more elaborate smart contracts (than advertising a simple string).
Experimenting SDN in hardware - Yey!
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.
BloSS also took part in its final form at the SIGCOMM 2019 (held in Beijing, China) where airport security was still a major issue - "no sir, this is still not a bomb."
Lastly, there is also a video of the demonstration that showcase an attack in AS300 by Bots deployed on AS100 and A200. The network was based on a Proof-of-Authority (PoA) consensus whereas all cooperative domains participated on the consensus considering a reduced block time of 5 seconds (so the demonstration could happen in a fast manner).
Also, it was deployed a script to make signaling and mitigation processes cyclic for demonstration purposes. A "cooldown" period was configured in which all blocked hosts had their flows deployed once again until a new mitigation request arrives.
Four key challenges were mentioned concerning (and summarized into) the following scopes: technical, social, economical, and legal.
"Simplicity is a key for wide applicability"
Technical. While BloSS is able to provide a reactive software-based approach which is decoupled from mitigation functions, it also can be combined with different existing protection systems such as firewalls, IDS/IPS.
A reactive approach is important since independent domains may react to a mitigation request based on the current status of their infrastructure, and a software-based approach is equally important to avoid imposing extra hardware requirements on different underlying networking infrastructures.
"Fostering trust is key within a cooperative defense"
Social. Although a DL approach is able to foster trust within repeated successful interections between players, there is no single approach able to create trust from "zero".
BloSS strikes a balance between transparency and confidentiality by performing an "on-chain" signaling whereas relevant data is sent "off-chain" via an encrypted IPFS channel. Henceforth, the cooperative logic is distributed and transparent among all members.
"Financial incentives are often neglected"
Economical. It is important to highlight that performing a mitigation service to a third-party incurs in capital and operational expensens. Thus, BloSS provides a means how a target (the one under attack) can provide incentives required by a mitigator (the one that will provide a mitigation service).
Henceforth, BloSS also enables a marketplace for cooperative DDoS mitigation services.
"Legal issues are relatively simple to be solved on a technical-basis but complex on a social-basis"
Legal. BloSS tackles legal issues by allowing the creation of "circles" or different BloSS networks among selected partners.
While the legal scope is a relatively easy problem to be solved on a technical-basis, it remains complex on a legal basis to determine which type of information can be disclosed with partners, in which region, whether internal compliances are reflected by external partners, and so on.