Subject: [Dots] Some queries and comments on DOTS requirements draft "draft-ietf-dots-requirements-06"

From: Mayank Bhatnagar <[email-masked]>
Date: Fri, 8 Sep 2017 09:35:41 +0530

Hi group,

Completed study on requirements document draft.

Some of my views and notes are provided below. Request your time to provide
your remarks and clarifications, if those considerations may have already
been discussed, adv/disadv if any.

*Signal Channel TCP or UDP*
1. I think we should make a signal channel also MANDATORY using a reliable
channel. What if a signal to start DOTS mitigationis itself lost?

On Page 6, 3rd pra we see
*"Operators of peer DOTS-enabled domains may enable quality- or classof-*
*service traffic tagging to increase the probability of successful*
*DOTS signal delivery, but DOTS requires no such policies be in place."*

If thats the reqirement from a DOTS enabled domain, then how will DOTS
honor it, unless we have a reliable transport in place. So its mandatory to
have transport protocol to be used for signal channel.

2. What are the *preconditions/thresholds* over which a DOTS client need to
start communicating with DOTS server? Can we define some examples of
attacks and pre-conditions exisiting. This will serve as a guideline for
new attacks and way we need to classify and handle.

Or if we can define different stages of a possibe DDOS attack and then
identify metrics for these, it will be beneficial to both DOTS client and
server to understand the state of the network.

*3. DOTS Dictionary of attack types*
Can we define a dictionary or classification of types of DDOS which is
arrived at  and which is currently being handled.
Since DOTS client and servers are inteligent DDOS agents, they can share
after some considerations and after arriving at observing the kind of
traffic, that this DDOS attack is a particular kind and the manner to be
mitigated decided is so and so.
In effect, the DOTS communicatin logs can also be looked at by a DOTS
admin, so it will be helpful if any manual intervention may be needed.

3. *DOTS Logs*. What kind of logging will a DOTS server and client be doing?

5.* SIG-004 Channel Redirection:*
What if the load mitigation effectiveness of a DOTS server begins to reduce
during an ongoing attack. In that case shouldnt a mltihomed DOTS client can
be asked to also share the load of attack with another DOTS server?

As I study in DOTS architecture, this has been taken care by a recursive
signalling mechanism hidden from client. Then is client TRUSTING the new
server?
Are we modelling it in same way as recursive DNS and recursive certificate
chain of trust.

6.* Page 9, while discussing DOTS metrics*
"Once a DOTS client requests mitigation, the client MAY withdraw
that request at any time, regardless of whether mitigation is
currently active. The DOTS server MUST immediately acknowledge a
DOTS client’s request to stop mitigation."

I beleive DOTS server should be intelligent enough. Based on the conditions
existing, server can advice DOTS client not to stop mitigation as of now.

*7. Default values*
The active-but-terminating period is initially 30 seconds and mximum value
as 240 seconds
Is it a proposed default or can it be negotiated?

*8. Section 3 : Congestion Control Considerations*
"Signal channel implementations using TCP may rely on built-in TCP
congestion control support."

So are we open to signal channel imlementations over TCP. Is it left upto
the software developers to use TCP or UDP for signal channel.

thanks & regards,
Mayank

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 8 Sep 2017 07:27:00 +0000

Hi,

Thanks for the review and questions!

Briefly addressing some of these:

#8 and #1 - the signal channel is transport agnostic and could be over tcp or udp.  In certain conditions tcp will be fine where reliable OOB connections are available, however, if the inbound links are congested then maintaining tcp may be an issue and therefore udp is preferable.

The signal channel works on the idea that a client will keep sending requests for help like a beacon until it sees a suitable ack from the server.

#2 preconditions, thresholds or triggers will depend upon the client and the assets being protected.  E.g volumes exceeds n% of available link, sessions exceed n% of web server capacity or it could be that the operator has a policy to swing everything regardless to a path of greater scrutiny as soon as it shows up as suspicious.

#3 falls into telemetry and later work but there's scope to include this.

#4 it will be implementation specific and should follow best practices.

#6 the server can advise but the client is assumed to own or have suitable authority over their assets to control the mitigation.  The client may  have triggered a mitigation for a low level annoyance attack but once swung traffic is messed up badly or there's some collateral damage or w/e... not allowing the client to recover their traffic could be nasty.

#7!I think most parameters should be negotiable where it makes sense.

Thanks,

-Nik

On 8 Sep 2017, at 05:05, Mayank Bhatnagar <[email-masked]<mailto:[email-masked]>> wrote:

Hi group,

Some of my views and notes are provided below. Request your time to provide your remarks and clarifications, if those considerations may have already been discussed, adv/disadv if any.

Signal Channel TCP or UDP
1. I think we should make a signal channel also MANDATORY using a reliable channel. What if a signal to start DOTS mitigationis itself lost?

On Page 6, 3rd pra we see
"Operators of peer DOTS-enabled domains may enable quality- or classof-
service traffic tagging to increase the probability of successful
DOTS signal delivery, but DOTS requires no such policies be in place."

If thats the reqirement from a DOTS enabled domain, then how will DOTS honor it, unless we have a reliable transport in place. So its mandatory to have transport protocol to be used for signal channel.

2. What are the preconditions/thresholds over which a DOTS client need to start communicating with DOTS server? Can we define some examples of attacks and pre-conditions exisiting. This will serve as a guideline for new attacks and way we need to classify and handle.

Or if we can define different stages of a possibe DDOS attack and then identify metrics for these, it will be beneficial to both DOTS client and server to understand the state of the network.

3. DOTS Dictionary of attack types
Can we define a dictionary or classification of types of DDOS which is arrived at  and which is currently being handled.
Since DOTS client and servers are inteligent DDOS agents, they can share after some considerations and after arriving at observing the kind of traffic, that this DDOS attack is a particular kind and the manner to be mitigated decided is so and so.
In effect, the DOTS communicatin logs can also be looked at by a DOTS admin, so it will be helpful if any manual intervention may be needed.

3. DOTS Logs. What kind of logging will a DOTS server and client be doing?

5. SIG-004 Channel Redirection:
What if the load mitigation effectiveness of a DOTS server begins to reduce during an ongoing attack. In that case shouldnt a mltihomed DOTS client can be asked to also share the load of attack with another DOTS server?

As I study in DOTS architecture, this has been taken care by a recursive signalling mechanism hidden from client. Then is client TRUSTING the new server?
Are we modelling it in same way as recursive DNS and recursive certificate chain of trust.

6. Page 9, while discussing DOTS metrics

I beleive DOTS server should be intelligent enough. Based on the conditions existing, server can advice DOTS client not to stop mitigation as of now.

7. Default values
The active-but-terminating period is initially 30 seconds and mximum value as 240 seconds
Is it a proposed default or can it be negotiated?

8. Section 3 : Congestion Control Considerations
"Signal channel implementations using TCP may rely on built-in TCP
congestion control support."

So are we open to signal channel imlementations over TCP. Is it left upto the software developers to use TCP or UDP for signal channel.

thanks & regards,
Mayank
_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: Mayank Bhatnagar <[email-masked]>
Date: Mon, 11 Sep 2017 09:18:30 +0530

thanks Nik for your time and reading my queries and replying on to it.

1. As yu mentioned *"however, if the inbound links are congested then
maintaining tcp may be an issue and therefore udp is preferable."*

Beacon signals will certainly help as you mentioned.

Also, is there a mechanism to convey congestion and slip to UDP, while
maintaining TCP as a default signalling mechanism

2.  *#2 preconditions, thresholds or triggers will depend upon the client
and the assets being protected.  *
So, do we plan to make a draft of possible conditions faced and beest
practices of thresholds maintined as a guideline...may be we can get this
as an additional section or annexure. Just a guideline and best preferable
values, however dynamic conditions can determine the right metrics at that
time..

Thanks again for your answers..

I am continuing reading on other areas and will provide my views and
queries here...

thanks again,
regards,
Mayank

On Fri, Sep 8, 2017 at 12:57 PM, Teague, Nik <[email-masked]> wrote:

> #8 and #1 - the signal channel is transport agnostic and could be over tcp
> or udp.  In certain conditions tcp will be fine where reliable OOB
> connections are available, however, if the inbound links are congested then
> maintaining tcp may be an issue and therefore udp is preferable.
>
> The signal channel works on the idea that a client will keep sending
> requests for help like a beacon until it sees a suitable ack from the
> server.
>
> #2 preconditions, thresholds or triggers will depend upon the client and
> the assets being protected.  E.g volumes exceeds n% of available link,
> sessions exceed n% of web server capacity or it could be that the operator
> has a policy to swing everything regardless to a path of greater scrutiny
> as soon as it shows up as suspicious.
>
> #6 the server can advise but the client is assumed to own or have suitable
> authority over their assets to control the mitigation.  The client may
>  have triggered a mitigation for a low level annoyance attack but once
> swung traffic is messed up badly or there's some collateral damage or
> w/e... not allowing the client to recover their traffic could be nasty.
>
> On 8 Sep 2017, at 05:05, Mayank Bhatnagar <[email-masked]>
> wrote:
>
> Hi group,
>
> Some of my views and notes are provided below. Request your time to
> provide your remarks and clarifications, if those considerations may have
> already been discussed, adv/disadv if any.
>
> 2. What are the *preconditions/thresholds* over which a DOTS client need
> to start communicating with DOTS server? Can we define some examples of
> What if the load mitigation effectiveness of a DOTS server begins to
> reduce during an ongoing attack. In that case shouldnt a mltihomed DOTS
> client can be asked to also share the load of attack with another DOTS
> server?
>
> I beleive DOTS server should be intelligent enough. Based on the
> conditions existing, server can advice DOTS client not to stop mitigation
> as of now.
>
>
> *7. Default values*
> [email-masked]

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 11 Sep 2017 06:17:28 +0000

> On Sep 11, 2017, at 10:48, Mayank Bhatnagar <[email-masked]> wrote:
> 
> So, do we plan to make a draft of possible conditions faced and beest practices of thresholds maintined as a guideline.

No, because this is both obvious & at the same time entirely situationally-dependent.  There is no generalizable advice which can be given.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Teague, Nik" <[email-masked]>
Date: Mon, 11 Sep 2017 13:13:34 +0000

Mayank hi,

Please see inline -

On 11/09/2017, 04:48, "Mayank Bhatnagar" <[email-masked]<mailto:[email-masked]>> wrote:

1. As yu mentioned "however, if the inbound links are congested then maintaining tcp may be an issue and therefore udp is preferable."

Also, is there a mechanism to convey congestion and slip to UDP, while maintaining TCP as a default signalling mechanism

You could employ a “happy eyeballs” like mechanism if you prefer.  This has been called out a few times – as far as doing so dynamically as in flipping from one to the other mid stream – that seems excessively complex.

2.  #2 preconditions, thresholds or triggers will depend upon the client and the assets being protected.
So, do we plan to make a draft of possible conditions faced and beest practices of thresholds maintined as a guideline...may be we can get this as an additional section or annexure. Just a guideline and best preferable values, however dynamic conditions can determine the right metrics at that time..

I would agree with Roland’s comments that the breadth of the subject is situationally dependent upon a number of factors some of them related to out of band topics such as business logic.  The use cases draft alludes to these at a high level.  If you would like to see this kind subject documented more deeply then you could certainly create a draft and submit it to the working group.

Thanks,

-Nik

---

From: Mayank Bhatnagar <[email-masked]>
Date: Tue, 12 Sep 2017 09:43:20 +0530

thanks Roland.

regards,
Mayank

On Mon, Sep 11, 2017 at 11:47 AM, Dobbins, Roland <[email-masked]>
wrote:

> practices of thresholds maintined as a guideline.
>
> No, because this is both obvious & at the same time entirely
> situationally-dependent.  There is no generalizable advice which can be
> given.
>

---

From: Mayank Bhatnagar <[email-masked]>
Date: Tue, 12 Sep 2017 09:46:50 +0530

hi Nik,
thanks...I understand as you and Roland mentioned, "*preconditions,
thresholds or triggers"  is *dependent on many factors.
thanks for your suggestion on the draft....

regards,
Mayank

On Sep 11, 2017 6:43 PM, "Teague, Nik" <[email-masked]> wrote:

> Mayank hi,
>
>
>
> Please see inline -
>
>
>
> On 11/09/2017, 04:48, "Mayank Bhatnagar" <[email-masked]>
> wrote:
>
>
>
> You could employ a “happy eyeballs” like mechanism if you prefer.  This
> has been called out a few times – as far as doing so dynamically as in
> flipping from one to the other mid stream – that seems excessively complex.
>
>
>
>
>
> I would agree with Roland’s comments that the breadth of the subject is
> situationally dependent upon a number of factors some of them related to
> out of band topics such as business logic.  The use cases draft alludes to
> these at a high level.  If you would like to see this kind subject
> documented more deeply then you could certainly create a draft and submit
> it to the working group.
>
>
>
> Thanks,
>
>
>
> -Nik
>