Subject: [Dots] scope

From: "Teague, Nik" <[email-masked]>
Date: Tue, 31 Mar 2015 14:51:21 +0000

Hi,

I hope everyone had good journeys home or onward to wherever you may be.

I wanted to follow up on the BOF and the outcomes – in particular I wanted to discuss scope, requirements and some thoughts.  Please feedback your thoughts/opinions…

Firstly applicability – as was clear from the BOF we were defining DDoS mitigation devices/applications or devices which may have other functions but contain a DDoS mitigation element.  The devices/applications may have either inline or out of band detection/mitigation capabilities and may be deployed as part of a larger mitigation strategy.  Its signaling between these elements and an upstream or service provider that we’re concerned with.  The term CPE was used which we will clarify to the term ‘on-premise’ to remove any confusion as to what we’re discussing.

These devices/applications already provide a degree of sophisticated analytics based on the traffic they observe.  The upstream element may, therefore, only require data relevant to its needs in identifying that an offramp is desired and telemetry in order for situational awareness in providing the correct mitigation strategy.  As was discussed feedback from the upstream/service provider is desirable relating to ongoing attack statistics and also its conclusion.

Characteristics

Signaling:
>From discussions its clear that the signaling element should include a level of encryption/obfuscation to negate the need for additional vpns, infrastructure etc.  Signaling should be lightweight and transport should not be session oriented in the classical sense.  It may be assumed likely that the ingress path to the on-premise device may be congested and loss should be expected and tolerated.  The ability to optimise as much information as possible into discrete packets is a definite advantage based upon the high probability of link/path congestion.

Provisioning:
A peacetime provisioning channel has proven effective in various vendor implementations for authentication, key exchange, configuration exchange etc. and it seems a good way to proceed since the information exchanged is usually weightier and doesn’t have restrictions relating to a congested network.  From discussions it was suggested the on-premise device would be in the best position to communicate thresholds as to when a traffic swing should be triggered.  The ability to simply signal (without additional qualification) that an upstream mitigation is requested is also desirable.  This may be a potential in-road to enabling this on less sophisticated (re DDoS) device types – e.g. If link >=80% then call for help.

Thanks,

-Nik

“This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 1 Apr 2015 05:55:39 +0000

Hi Nik,
Thank you for initiate the work scope discussion! We are walking on the right way now~~
Here are my thoughts about DOTS works:

1.       The devices can be either DDoS mitigation devices, or normal network devices (router, switch). This will make the whole DOTS solution more general for different scenarios. For example, current two drafts within DOTS can represent this difference. Maybe, we need an use case draft to elaborate their respective values;

2.       I agree that upstream systems need to negotiate its requirements or capabilities to reporting devices. This feature can save the signaling traffics. It means an initialized negotiation mechanism may be needed;

3.       A mutual authentication mechanism is needed to protect the communications between the legal senders and receivers, to avoid the faked signaling, fault peers, or creating new DDoS attacks, etc;

4.       To cope with the rapid evolution and change of the attack types, the DOTS solution should consider the capability of openness. Which means the specified information model should have the capability in semantic to define and express the new attack information;

5.       The whole architecture should not be constrained in our proposed scenarios, it can be more general, more comprehensive. For example, more devices construct a mesh network to support the DOTS functions.

A suggestion: when our work scope discussion has achieved some agreement and consensus, we should begin the charter work.

B.R.
Frank

From: Dots [mailto:[email-masked]] On Behalf Of Teague, Nik
Sent: Tuesday, March 31, 2015 10:51 PM
To: [email-masked]
Subject: [Dots] scope

Hi,

I wanted to follow up on the BOF and the outcomes - in particular I wanted to discuss scope, requirements and some thoughts.  Please feedback your thoughts/opinions...

Firstly applicability - as was clear from the BOF we were defining DDoS mitigation devices/applications or devices which may have other functions but contain a DDoS mitigation element.  The devices/applications may have either inline or out of band detection/mitigation capabilities and may be deployed as part of a larger mitigation strategy.  Its signaling between these elements and an upstream or service provider that we're concerned with.  The term CPE was used which we will clarify to the term 'on-premise' to remove any confusion as to what we're discussing.

Characteristics

>From discussions its clear that the signaling element should include a level of encryption/obfuscation to negate the need for additional vpns, infrastructure etc.  Signaling should be lightweight an…

Provisioning:
A peacetime provisioning channel has proven effective in various vendor implementations for authentication, key exchange, configuration exchange etc. and it seems a good way to proceed since the information exchanged is usually weightier and doesn't have restrictions relating to a congested network.  From discussions it was suggested the on-premise device would be in the best position to communicate thresholds as to when a traffic swing should be triggered.  The ability to simply signal (without additional qualification) that an upstream mitigation is requested is also desirable.  This may be a potential in-road to enabling this on less sophisticated (re DDoS) device types - e.g. If link >=80% then call for help.

Thanks,

-Nik

"This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately."