![\"\"](\"http:\/\/puluka.com\/home\/wp-content\/uploads\/2018\/09\/DOTS1.png\")
<\/a><\/p>\nWhen the DOTS client is some server running in RFC1918 space and scope the gateway architecture looks like this.<\/p>\n
The protocol also allows for multiple clients signaling a single upstream or a single client signaling multiple multiple servers for assistance. Or the DOTS gateway can be used to consolidate multiple clients for the upstream signaling requests to either single or multiple servers. In short the communication combinations and permutations are well covered.<\/p>\n The idea is that detector clients can be deployed by any vendor and at any point that makes sense to detect the malicious DDoS attack. The vendor need not have any mitigation ability at all to be a detector. They can even be completely out of the traffic path itself and operating on data streams of any sort at all.<\/p>\n Likewise the DOTS server can be communicating to mitigation tools that have no detection ability at all. There is no need for the mitigator to detect the DDoS attack as the signal is requesting the mitigation.<\/p>\n Naturally there is a significant value in having both detection and mitigation working hand in hand but the standard allows for vendors to specialize in one or the other more easily.<\/p>\n There are two primary use cases for DOTS, communications between the target and the immediate upstream provider and from the target to 3rd party mitigation services outside the initial connection to the target.<\/p>\n When signaling the immediate transit provider the nature of the traffic path means they will already have the malicious packets on their network. So no route diversions are needed in the overall internet table for the transit provider to mitigate the issue. The DOTS server mitigation can use \/32 addressing and the built in infrastructure of the transit provider to provide mitigation service with no need for any other internet routing changes to occur.<\/p>\n With 3rd party DDoS Mitigation service they need to first divert the global internet table to receive the traffic before they can provide mitigation. So part of the process is to identify the \/24 route that will need to be inserted into the global internet routing table for this to occur. The other major difference is that the good traffic that is then sent to the target needs a delivery path. This is typically a tunnel of some sort created between the enterprise and the DDoS service.<\/p>\n Communications between DOTS nodes is separated into a signal channel and data channel. This allows the clean separation of data from communications infrastructure and more ability to simply ignore messages not understood and extend messages in the future. Security of communications is paramount as well. We don\u2019t want this channel of communications becoming a new method of DDoS attack.<\/p>\n Further the existing communications protocol coap is used as the foundation for the channel. This takes advantage of an existing mature communications standard that is also resilient by nature. The working group understands that when the DOTS client is under attack the channel of communications may also be impacted.<\/p>\n The standard also makes use of the existing standard of YANG to describe the data structure of messages passed in the system. By using a small set of required data elements and an extended set of optional ones that can be safely ignored by any DOTS element, the system becomes easily extendable and resilient for backwards compatibility.<\/p>\n The current drafts are now in the final stages of review and comment and should start to be implemented by vendors this year or early next year. I am encouraged that the framework seems to be a robust standard. It uses existing signaling mechanism where practical. It separates a basic message from detailed data that makes it easy for vendors to extend without breaking cross vendor signaling. And the structure allows for future feature extensions in a fully backward compatible way that won\u2019t break older nodes when new features are added.<\/p>\n I look forward to seeing the implementation details as they emerge from the major vendors in the space.<\/p>\n DOTS working group home DOTS Architecture Draft March 2018 DOTS Use Cases Draft July 2018 DOTS Threat Signaling Requirements Draft August 2018<\/a><\/p>\nUse Cases<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\nSignaling Standards<\/h2>\n
Conclusion<\/h2>\n
References:<\/h2>\n
\nhttps:\/\/datatracker.ietf.org\/wg\/dots\/documents\/<\/a><\/p>\n
\nhttps:\/\/datatracker.ietf.org\/doc\/draft-ietf-dots-architecture\/<\/a><\/p>\n
\nhttps:\/\/datatracker.ietf.org\/doc\/draft-ietf-dots-use-cases\/<\/a><\/p>\n
\nhttps:\/\/datatracker.ietf.org\/doc\/draft-ietf-dots-requirements\/<\/a><\/p>\n