Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

From: Dave Larson <[email-masked]>
Date: Wed, 8 Apr 2015 02:17:14 +0000

HI Frank,

I think you raise a few vary important points below:

On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" <[email-masked]<mailto:[email-masked]>> wrote:

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.

My thoughts are:

1.  I agree.  We want to be inclusive on what kinds of devices may signal.  And use cases are a great way to encapsulate the problem space.  Though I would not try to extend the problem space beyond DDoS.

2.  I agree.  I think this is really bidirectional – I can imagine both ends of the connection advertising capabilities.  I can see the edge systems (downstream) also advertising what they are capable of signaling and this would vary depending on the types of devices as you point out in point 1.

3.  Authentication is critical to avoid the fake signaling problem you have pointed out – I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce a new DDoS vector by failing to account for this.

4.  I believe all participants in the BOF would support openness for attack type definition.  But I also heard strong support for constraining the problem space initially to DDoS.  In fact, my opinion, as stated at the BOF, is that the most important component of this project is the schema.  A concise schema that can accommodate all currently known DDoS vectors and a schema that is also extensible should be a primary goal for us.

5.  I’m not sure I follow the suggestion of a mesh network here.  Similar to point 4, I believe it is important to get the downstream-to-upstream signaling correct before complicating with mesh topology considerations.  In fact, to further enforce my point above, I think schema is more important than topology considerations at first.  I think it is critical for us to offer something that can be tested and proven in the simplest networks that can show the benefit.  But your point about openness can not be understated – this must be open and extensible.

I have copied a colleague of mine, Scott Barvick.  Scott was unable to attend the BOF but has been working on these concepts with me and will likely have some opinions in these areas to share with the thread.

Regards,

Dave Larson

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 8 Apr 2015 03:36:51 +0000

Hi Dave,
I totally agree with you the point that focus DOTS's scope on DDoS in the first stage. It's a reasonable way we push the WG work.
Please see my response inline:

B.R.
Frank

From: Dave Larson [mailto:[email-masked]]
Sent: Wednesday, April 08, 2015 10:17 AM
To: Xialiang (Frank); Teague, Nik; Scott Barvick
Cc: [email-masked]
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

HI Frank,

My thoughts are:

2.  I agree.  I think this is really bidirectional - I can imagine both ends of the connection advertising capabilities.  I can see the edge systems (downstream) also advertising what they are capable of signaling and this would vary depending on the types of devices as you point out in point 1.
[Frank] : Agree with the bidirectional negotiation requirement!

3.  Authentication is critical to avoid the fake signaling problem you have pointed out - I believe this received some discussion during the BOF in Dallas.. Whatever we do with this project, It can not introduce a new DDoS vector by failing to account for this.

4.  I believe all participants in the BOF would support openness for attack type definition.  But I also heard strong support for constraining the problem space initially to DDoS.  In fact, my opinion, as stated at the BOF, is that the most important component of this project is the schema.  A concise schema that can accommodate all currently known DDoS vectors and a schema that is also extensible should be a primary goal for us.
[Frank] :yes, you raise the key point - a concise schema also with the extensibility! And I hope these two goals can be achieved all, by pre-consideration and good design.

5.  I'm not sure I follow the suggestion of a mesh network here.  Similar to point 4, I believe it is important to get the downstream-to-upstream signaling correct before complicating with mesh topology considerations.  In fact, to further enforce my point above, I think schema is more important than topology considerations at first.  I think it is critical for us to offer something that can be tested and proven in the simplest networks that can show the benefit.  But your point about openness can not be understated - this must be open and extensible.
[Frank] : Like you state here, what I propose here is about the topology and architecture aspects. I agree that this point is a little far than the scheme work. We can consider it later.

I have copied a colleague of mine, Scott Barvick.  Scott was unable to attend the BOF but has been working on these concepts with me and will likely have some opinions in these areas to share with the thread.
[Frank] : Welcome, Scott~~

Regards,

Dave Larson

---

From: Scott Barvick <[email-masked]>
Date: Wed, 8 Apr 2015 14:36:43 +0000

Thanks for the intro and welcome.     From the reading of the minutes and the thread, it seems that we can and should be using the words 'DDoS' and 'signaling'  along with not overlapping with other IETF work to help us check our activities against a focus that will allow us to get chartered as a WG and then make the required progress towards goals that we will have as one.   If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really should really not be spending any time on it.    As examples (for discussion, of course)

-          DDoS capabilities negotiation between the communicating parties -  in scope because it affects what can be signaled or needs to be done on either side

-          Configuration or provisioning of the devices for DDoS - not in scope because while it is DDoS, it is beyond what is necessary to signal.  And we have other protocols to define the operations and even schemas for this

-          Communication of signaling thresholds or conditions - in scope

-          Authentication of signaling channel - in scope

-          Specific flow stats and flow awareness - not in scope because it is not DDoS and there are other protocols that represent this kind of info

-          DDoS attack representation - in-scope because it is DDoS.  Of course, if a device can't classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate 'unknown'

Looking forward to good discussion and the development of a good RFC.

Regards,
Scott

From: Xialiang (Frank) [mailto:[email-masked]]
Sent: Tuesday, April 07, 2015 11:37 PM
To: Dave Larson; Teague, Nik; Scott Barvick
Cc: [email-masked]
Subject: RE: [Dots] DOTS work scope discussion: //RE: scope

Hi Dave,

B.R.
Frank

Cc: [email-masked]<mailto:[email-masked]>

HI Frank,

My thoughts are:

Regards,

Dave Larson

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 8 Apr 2015 15:15:05 +0000

Hi,

On 08/04/2015 15:36, "Scott Barvick" <[email-masked]> wrote:

>-          Configuration or provisioning of the devices for DDoS  not in
>scope because while it is DDoS, it is beyond what is necessary to signal.
> And we have other protocols to define the operations and even schemas
>for this

I agree that configuration/provisioning of the device itself is out of
scope - I would say that provisioning the service (auth, whitelist,
blacklist, crypto negotiations, collector addr etc.) are in scope.  These
are all elements that relate to the ephemeral service state as it pertains
to the relationship between the signaling element and the consuming
element.

Thanks,

-Nik

---

From: Daniel Migault <[email-masked]>
Date: Wed, 8 Apr 2015 11:20:32 -0400

Hi Scott,

It is not very clear to me what is in "Configuration or provisioning" and
what is in "Communication of signaling thresholds or conditions".

[BTW feel free to provide more appropriated terms]

Suppose I have a "DDoS Mitigation Device".
I would like to use DOTS to:
    1) Be aware of the device capabilities, that is to say what services
the device can provide. By capabilities I see the following categories of
capabilities:
        + a) Monitoring Capabilities
        + b) Mitigating Capabilities

Monitoring Capabilities consists in being able to look at specific traffic
characteristics or patterns. Examples could be Monitoring FQDNs of DNS
NXDOMAIN responses, IP source of DNS NXDOMAIN responses, IP destination of
TCP SYN....

[MGLT It is still not clear what should be the level of granularity a
capability should be associated to]
For each of these Monitoring Capabilities some Monitoring actions could be
associated. The two type of actions I see would be: trigger an alarm when a
define threshold has been reached or export the traffic to some directory.

[MGLT I seen these action associated to Monitoring Capabilities, but maybe
it could be as well itself a capability]

Mitigating Capabilities consists in blocking IP, applying white list black
lists of IP addresses FQDNs, redirecting traffic......

Once I am aware of the capabilities of the "DDoS Mitigation Device" I would
like to
    2)  be able to select these Monitoring Capabilities and set the
appropriated Monitoring Action. This to some extend could be seen a
configuration of the DDoS service, but I expect it to be part of DOTS.

Once an alarm is raised or I am informed an DDoS attacks occurs I would
like to
   3) be able to take the appropriated Mitigation Action.

BR,
Daniel

On Wed, Apr 8, 2015 at 10:36 AM, Scott Barvick <[email-masked]>
wrote:

>  Thanks for the intro and welcome.     From the reading of the minutes
> and the thread, it seems that we can and should be using the words ‘DDoS’
> and ‘signaling’  along with not overlapping with other IETF work to help us
> check our activities against a focus that will allow us to get chartered as
> a WG and then make the required progress towards goals that we will have as
> one.   If it is not directly contributing to the signaling of DDoS
> threats/conditions/capabilities then we really should really not be
> spending any time on it.    As examples (for discussion, of course)
>
>
>
> -          DDoS capabilities negotiation between the communicating
> parties -  in scope because it affects what can be signaled or needs to be
> done on either side
>
> -          Configuration or provisioning of the devices for DDoS – not in
> And we have other protocols to define the operations and even schemas for
> this
>
> -          Communication of signaling thresholds or conditions – in scope
>
> -          Authentication of signaling channel – in scope
>
> -          Specific flow stats and flow awareness – not in scope because
> it is not DDoS and there are other protocols that represent this kind of
> info
>
> -          DDoS attack representation – in-scope because it is DDoS.  Of
> course, if a device can’t classify the attack because it is either not that
> kind of device or it is a new attack, then we need a way for this to
> indicate ‘unknown’
>
>
>
> *From:* Xialiang (Frank) [mailto:[email-masked]]
> *Sent:* Tuesday, April 07, 2015 11:37 PM
> *To:* Dave Larson; Teague, Nik; Scott Barvick
> *Cc:* [email-masked]
> *Subject:* RE: [Dots] DOTS work scope discussion: //RE: scope
>
>
>
> Hi Dave,
>
> I totally agree with you the point that focus DOTS’s scope on DDoS in the
> first stage. It’s a reasonable way we push the WG work.
>
> *From:* Dave Larson [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, April 08, 2015 10:17 AM
> *To:* Xialiang (Frank); Teague, Nik; Scott Barvick
> *Cc:* [email-masked]
> *Subject:* Re: [Dots] DOTS work scope discussion: //RE: scope
>
>
>
> HI Frank,
>
>
>
> On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" <
> [email-masked]> wrote:
>
>
>
> 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.
>
>
>
> My thoughts are:
>
>
>
> 1.  I agree.  We want to be inclusive on what kinds of devices may
> signal.  And use cases are a great way to encapsulate the problem space.
> Though I would not try to extend the problem space beyond DDoS.
>
>
>
> 2.  I agree.  I think this is really bidirectional – I can imagine both
> ends of the connection advertising capabilities.  I can see the edge
> systems (downstream) also advertising what they are capable of signaling
> and this would vary depending on the types of devices as you point out in
> point 1.
>
> *[Frank] : Agree with the bidirectional negotiation requirement!*
>
>
>
> 3.  Authentication is critical to avoid the fake signaling problem you
> have pointed out – I believe this received some discussion during the BOF
> in Dallas.. Whatever we do with this project, It can not introduce a new
> DDoS vector by failing to account for this.
>
>
>
> 4.  I believe all participants in the BOF would support openness for
> attack type definition.  But I also heard strong support for constraining
> the problem space initially to DDoS.  In fact, my opinion, as stated at the
> BOF, is that the most important component of this project is the schema.  A
> concise schema that can accommodate all currently known DDoS vectors and a
> schema that is also extensible should be a primary goal for us.
>
> *[Frank] :yes, you raise the key point – a concise schema also with the
> extensibility! And I hope these two goals can be achieved all, by
> pre-consideration and good design.*
>
>
>
> 5.  I’m not sure I follow the suggestion of a mesh network here.  Similar
> to point 4, I believe it is important to get the downstream-to-upstream
> signaling correct before complicating with mesh topology considerations.
> In fact, to further enforce my point above, I think schema is more
> important than topology considerations at first.  I think it is critical
> for us to offer something that can be tested and proven in the simplest
> networks that can show the benefit.  But your point about openness can not
> be understated – this must be open and extensible.
>
> *[Frank] : Like you state here, what I propose here is about the topology
> and architecture aspects. I agree that this point is a little far than the
> scheme work. We can consider it later.*
>
>
>
> I have copied a colleague of mine, Scott Barvick.  Scott was unable to
> attend the BOF but has been working on these concepts with me and will
> likely have some opinions in these areas to share with the thread.
>
> *[Frank] : Welcome, Scott~~*
>
>
>
> Regards,
>
>
>
> Dave Larson
>
>
>
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>
>

-- 
Daniel Migault
Ericsson

---

From: John <[email-masked]>
Date: Wed, 08 Apr 2015 09:42:05 -0600

Hello,

     Sorry I'm late to this discussion but I've recently learned of this 
effort and I'm very interested in the topic. If my questions have 
already been addressed and I missed where this was previously discussed, 
I'm apologize for raising the issue again and I would appreciate being 
directed to where the question was answered or discussed.

Please see inline.

On 04/08/2015 08:36 AM, Scott Barvick wrote:
> and the thread, it seems that we can and should be using the words 
> ‘DDoS’ and ‘signaling’  along with not overlapping with other IETF 
> work to help us check our activities against a focus that will allow 
> us to get chartered as a WG and then make the required progress 
> towards goals that we will have as one.   If it is not directly 
> contributing to the signaling of DDoS threats/conditions/capabilities 
> then we really should really not be spending any time on it.    As 
> examples (for discussion, of course)
>
> -DDoS capabilities negotiation between the communicating parties -  in 
> scope because it affects what can be signaled or needs to be done on 
> either side
>
> -Configuration or provisioning of the devices for DDoS – not in scope 
> because while it is DDoS, it is beyond what is necessary to signal.  
> -Communication of signaling thresholds or conditions – in scope
>
> -Authentication of signaling channel – in scope
>
     Authentication is in scope, I would suggest it's required to 
participate.
>
> -Specific flow stats and flow awareness – not in scope because it is 
> not DDoS and there are other protocols that represent this kind of info
>
     I kind of see this item as going along with Communication of 
signaling thresholds mentioned above. How do you know you are not 
surpassing or taking full advantage of mitigation without knowing if you 
are at, near, or above the signaling thresholds?

     Could you share what current protocols you are referring to?

> -DDoS attack representation – in-scope because it is DDoS.  Of course, 
> if a device can’t classify the attack because it is either not that 
     Verification. This ,so far, is a two part issue.
             * As part of authentication, we need some way to verify the 
authenticating parties and agree upon authentication methods.
             * How do I verify the DDoS parameters defined downstream 
are applicable and valid? What's in place to prevent a CPE from sending 
invalid DDoS representation? The CPE could have been compromised or the 
owner of the CPE may try to send data that falsely blames a competitor 
and thus ends up allowing for a DoS of said competitor.

Thanks,

--John Schiel

> *From:*Xialiang (Frank) [mailto:[email-masked]]
> I totally agree with you the point that focus DOTS’s scope on DDoS in 
> the first stage. It’s a reasonable way we push the WG work.
>
> *From:*Dave Larson [mailto:[email-masked]]
> *Cc:* [email-masked] <mailto:[email-masked]>
> On Wednesday, April 1, 2015 at 1:55 AM, "Xialiang (Frank)" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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.
>
> My thoughts are:
>
> signal.  And use cases are a great way to encapsulate the problem 
> space.  Though I would not try to extend the problem space beyond DDoS.
>
> 2.  I agree.  I think this is really bidirectional – I can imagine 
> both ends of the connection advertising capabilities.  I can see the 
> edge systems (downstream) also advertising what they are capable of 
> signaling and this would vary depending on the types of devices as you 
> point out in point 1.
>
> */[Frank] : Agree with the bidirectional negotiation requirement!/*
>
> have pointed out – I believe this received some discussion during the 
> BOF in Dallas.. Whatever we do with this project, It can not introduce 
> a new DDoS vector by failing to account for this.
>
> attack type definition.  But I also heard strong support for 
> constraining the problem space initially to DDoS.  In fact, my 
> opinion, as stated at the BOF, is that the most important component of 
> this project is the schema.  A concise schema that can accommodate all 
> currently known DDoS vectors and a schema that is also extensible 
> should be a primary goal for us.
>
> */[Frank] :yes, you raise the key point – a concise schema also with 
> the extensibility! And I hope these two goals can be achieved all, by 
> pre-consideration and good design./*
>
> 5.  I’m not sure I follow the suggestion of a mesh network here. 
>  Similar to point 4, I believe it is important to get the 
> downstream-to-upstream signaling correct before complicating with mesh 
> topology considerations.  In fact, to further enforce my point above, 
> I think schema is more important than topology considerations at 
> first.  I think it is critical for us to offer something that can be 
> tested and proven in the simplest networks that can show the benefit. 
>  But your point about openness can not be understated – this must be 
> open and extensible.
>
> */[Frank] : Like you state here, what I propose here is about the 
> topology and architecture aspects. I agree that this point is a little 
> far than the scheme work. We can consider it later./*
>
> */[Frank] : Welcome, Scott~~/*
>
> Regards,
>
> Dave Larson
>
>
>

---

From: Andrew Mortensen <[email-masked]>
Date: Wed, 8 Apr 2015 13:56:27 -0400

> On Apr 8, 2015, at 10:36 AM, Scott Barvick <[email-masked]> wrote:
> 
> … If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really should really not be spending any time on it.    As examples (for discussion, of course)

Thanks for drawing up this list of examples as discussion points.

> -          DDoS capabilities negotiation between the communicating parties -  in scope because it affects what can be signaled or needs to be done on either side

I’m less sure about this. Trying to encode DDoS mitigation capabilities seems like an exercise in futility, as the state of the art is already racing to keep up with attack innovation. Any upstream services implementing DOTS are indicating mitigation capability. Not all upstream services will be equal, of course, but upstream capabilities seem out of scope: the goal of DOTS, as I understand it, is to provide a standard way for downstream mitigation/detection devices to request intervention upstream.

What upstream does—or even can do—on receipt of a distress call from downstream beyond DOTS. Upstream elements are of course under no obligation to mitigate the attack when it’s requested by the on-premise device, and the downstream on-premise mitigation/detection device is under no obligation to request upstream help when under attack. Given cost concerns—and upstream intervention is likely to have associated cost—a downstream network operator is going to want to have the option to control whether mitigation upstream is enabled for their network.

> -          Configuration or provisioning of the devices for DDoS – not in scope because while it is DDoS, it is beyond what is necessary to signal.  And we have other protocols to define the operations and even schemas for this

Agreed, this is far afield from DOTS. Far more in scope for NETCONF & co.

> -          Communication of signaling thresholds or conditions – in scope

The minimum requirement seems to me just the ability to signal whether the on-premise device wants help. This is currently encoded as the “SOS” field in the signal to the upstream element. In my view the need for downstream control over whether upstream mitigation is enabled means signaling thresholds for automitigation upstream should be optional.

> -          Authentication of signaling channel – in scope

Critical, and attack conditions—extremely congested link—are going help shape the form this takes.

> -          Specific flow stats and flow awareness – not in scope because it is not DDoS and there are other protocols that represent this kind of info

Maybe more importantly, they aren't going to get through a congested channel to any upstream element reliably.

> -          DDoS attack representation – in-scope because it is DDoS.  Of course, if a device can’t classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate ‘unknown’

In scope, but not required. It is undoubtedly useful information for the upstream service, but is not a requirement before upstream can begin mitigating. At a minimum, a downstream on-premise device should at need be able request mitigation and request mitigation deactivation.

andrew

---

From: Scott Barvick <[email-masked]>
Date: Thu, 9 Apr 2015 02:46:38 +0000

Lots of good discussion that I’m sure will continue.   Of course we’ll need to break each topic into different threads and drill into each.

Another topic that Andrew is surfacing is in the statement below
The minimum requirement seems to me just the ability to signal whether the on-premise device wants help. This is currently encoded as the “SOS” field in the signal to the upstream element.

I noticed a similar sentiment in the current draft:

These elements may
be required from time to time to signal to an upstream component or
provider that the capabilities of the device are exceeded and that an
offramping of attack traffic to a more capable element or
infrastructure is desired or required.

It might be assumed but I think it needs explicitly called out in the overview and goals that the on-premise device may not need help mitigating per se, but signaling may be necessary to potentially off-ramp traffic because the upstream link is saturated.   Even a box that can handle a full load of DDoS traffic cannot do anything to help good traffic if the upstream pipe to it is full.   In that case, signaling can cause rerouting of all or certain traffic to free the link to allow valid traffic to start to flow again.   This is, of course, another case where a channel and protocol that can get information out under stressful circumstances will be necessary.

Scott

On Apr 8, 2015, at 1:56 PM, Andrew Mortensen <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 8, 2015, at 10:36 AM, Scott Barvick <[email-masked]<mailto:[email-masked]>> wrote:

andrew

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 9 Apr 2015 02:51:00 +0000

Hi all,
My comments are inline:

Thanks!

B.R.
Frank

From: Andrew Mortensen [mailto:[email-masked]]
Sent: Thursday, April 09, 2015 1:56 AM
To: Scott Barvick
Cc: Xialiang (Frank); Dave Larson; Teague, Nik; [email-masked]
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

I’m less sure about this. Trying to encode DDoS mitigation capabilities seems like an exercise in futility, as the state of the art is already racing to keep up with attack innovation. Any upstream services implementing DOTS are indicating mitigation capability. Not all upstream services will be equal, of course, but upstream capabilities seem out of scope: the goal of DOTS, as I understand it, is to provide a standard way for downstream mitigation/detection devices to request intervention upstream.
[Frank] : At least, in the multiple upstreams condition, the awareness of every upstream’s capability by downstream can help it make the right choice. So, the bidirectional negotiation mechanism is useful for making the whole solution more smart and efficient. But how to represent the capability and in which granularity is indeed a question. I tend to choose a coarse-grained category for applicability.

What upstream does—or even can do—on receipt of a distress call from downstream beyond DOTS. Upstream elements are of course under no obligation to mitigate the attack when it’s requested by the on-premise device, and the downstream on-premise mitigation/detection device is under no obligation to request upstream help when under attack. Given cost concerns—and upstream intervention is likely to have associated cost—a downstream network operator is going to want to have the option to control whether mitigation upstream is enabled for their network.
[Frank] : Due to the upstream intervention is associated cost, the downstream device is more likely to depend on the negotiation mechanism to help it choose the suitable upstream.

Maybe more importantly, they aren't going to get through a congested channel to any upstream element reliably.
[Frank] : I cannot totally agree with this point. In addition to the precise attack info inspected by the DDoS mitigation device, the specific flow stats info inspected by the normal network devices (i.e., router, switch) are also very valuable for the upstream platform to be aware of what happen in network and what to do then. We should consider a general use case, and not exclude the network devices out of the scope.

In scope, but not required. It is undoubtedly useful information for the upstream service, but is not a requirement before upstream can begin mitigating. At a minimum, a downstream on-premise device should at need be able request mitigation and request mitigation deactivation.
[Frank] : By my understanding, an important goal of DOTS work is to improve the security intelligence sharing among the whole network security ecosystem. So, how to represent the DDoS attacks and sharing them is a very useful work. So, definitely, it should be in scope, and the DDoS attack info should be shared among the federal peers in time. For the new attack, to indicate ‘unknown’ is the default method, but it is also possible to better represent them by using some good design and extensible information scheme.

andrew

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 9 Apr 2015 02:54:14 +0000

Hi John,
Please see inline:
Thanks!

B.R.
Frank

From: Dots [mailto:[email-masked]] On Behalf Of John
Sent: Wednesday, April 08, 2015 11:42 PM
To: [email-masked]
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

Hello,

    Sorry I'm late to this discussion but I've recently learned of this effort and I'm very interested in the topic. If my questions have already been addressed and I missed where this was previously discussed, I'm apologize for raising the issue again and I would appreciate being directed to where the question was answered or discussed.

Please see inline.

-          Authentication of signaling channel - in scope
    Authentication is in scope, I would suggest it's required to participate.

-          Specific flow stats and flow awareness - not in scope because it is not DDoS and there are other protocols that represent this kind of info
    I kind of see this item as going along with Communication of signaling thresholds mentioned above. How do you know you are not surpassing or taking full advantage of mitigation without knowing if you are at, near, or above the signaling thresholds?

-          DDoS attack representation - in-scope because it is DDoS.  Of course, if a device can't classify the attack because it is either not that kind of device or it is a new attack, then we need a way for this to indicate 'unknown'
Verification. This ,so far, is a two part issue.
            * As part of authentication, we need some way to verify the authenticating parties and agree upon authentication methods.
            * How do I verify the DDoS parameters defined downstream are applicable and valid? What's in place to prevent a CPE from sending invalid DDoS representation? The CPE could have been compromised or the owner of the CPE may try to send data that falsely blames a competitor and thus ends up allowing for a DoS of said competitor.
[Frank] : I'd like to think the CPE is trusted if it's a authenticated peer. It's the traditional authentication way, isn't it?

Thanks,

--John Schiel

Regards,
Scott

Hi Dave,

B.R.
Frank

HI Frank,

My thoughts are:

Regards,

Dave Larson

Dots mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 9 Apr 2015 03:07:18 +0000

Hi Scott,
You are pointing out another condition that need to signal.
In this condition, the signaling is more about the flow info than the DDoS attack info.

B.R.
Frank

From: Scott Barvick [mailto:[email-masked]]
Sent: Thursday, April 09, 2015 10:47 AM
To: Andrew Mortensen
Cc: Xialiang (Frank); Dave Larson; Nik Teague; [email-masked]
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

Lots of good discussion that I'm sure will continue.   Of course we'll need to break each topic into different threads and drill into each.

Another topic that Andrew is surfacing is in the statement below
The minimum requirement seems to me just the ability to signal whether the on-premise device wants help. This is currently encoded as the "SOS" field in the signal to the upstream element.

These elements may

Scott

... If it is not directly contributing to the signaling of DDoS threats/conditions/capabilities then we really should really not be spending any time on it.    As examples (for discussion, of course)

I'm less sure about this. Trying to encode DDoS mitigation capabilities seems like an exercise in futility, as the state of the art is already racing to keep up with attack innovation. Any upstream services implementing DOTS are indicating mitigation capability. Not all upstream services will be equal, of course, but upstream capabilities seem out of scope: the goal of DOTS, as I understand it, is to provide a standard way for downstream mitigation/detection devices to request intervention upstream.

What upstream does-or even can do-on receipt of a distress call from downstream beyond DOTS. Upstream elements are of course under no obligation to mitigate the attack when it's requested by the on-premise device, and the downstream on-premise mitigation/detection device is under no obligation to request upstream help when under attack. Given cost concerns-and upstream intervention is likely to have associated cost-a downstream network operator is going to want to have the option to control whether mitigation upstream is enabled for their network.

The minimum requirement seems to me just the ability to signal whether the on-premise device wants help. This is currently encoded as the "SOS" field in the signal to the upstream element. In my view the need for downstream control over whether upstream mitigation is enabled means signaling thresholds for automitigation upstream should be optional.

Critical, and attack conditions-extremely congested link-are going help shape the form this takes.

andrew

---

From: Andrew Mortensen <[email-masked]>
Date: Thu, 9 Apr 2015 00:59:20 -0400

Thanks for the comments, Frank. See my notes inline.

>  From: Andrew Mortensen [mailto:[email-masked] <mailto:[email-masked]>] 
> <snip>

Even leaving aside the Sisyphean task of trying to negotiate with upstream elements when the target network’s links are congested, it seems misguided to base the decision of where to send a signal for help on uncertified and necessarily abstract capabilities advertised from upstream.

When to mitigate, and whom to ask for help mitigating, should be left up to network operators. (This can of course include automitigation, as the operator will just have made the decisions beforehand.)

> [Frank] : Due to the upstream intervention is associated cost, the downstream device is more likely to depend on the negotiation mechanism to help it choose the suitable upstream.

I’d very much like to avoid trying to standardize what amount to business negotiations on behalf of network owners.

When the target network is under attack, the measurable result of a request for help will be reduced load. The ultimate judge of the need for mitigation, its effectiveness, its duration, and its value will be the network owners who requested intervention in the first place.

> <snip>

There are plenty of devices out there designed to perform flow analysis and derive intelligence from it, including attack detection. Such devices would be natural DOTS clients, well-positioned to signal for upstream intervention when attacks are detected.

But it sounds like instead of using on-premise collectors, you’re suggesting sampled flow should be exported upstream during attack. Is that accurate?

> In scope, but not required. It is undoubtedly useful information for the upstream service, but is not a requirement before upstream can begin mitigating. At a minimum, a downstream on-premise device should at need be able to request mitigation and request mitigation deactivation.
> [Frank] : By my understanding, an important goal of DOTS work is to improve the security intelligence sharing among the whole network security ecosystem. So, how to represent the DDoS attacks and sharing them is a very useful work. So, definitely, it should be in scope, and the DDoS attack info should be shared among the federal peers in time. For the new attack, to indicate ‘unknown’ is the default method, but it is also possible to better represent them by using some good design and extensible information scheme

This sounds a lot like MILE, no?

https://datatracker.ietf.org/wg/mile/charter/

You’ll get no argument from me that representing and sharing DDoS attack profiles is useful work. The scope of that work is enormous, though, and DOTS is focused on the signaling aspect: providing (in my view) minimally necessary information to an upstream element to signal the need for aid fighting off an attack. What “minimally necessary” means remains a matter for debate, of course, but in my mind that excludes a great deal of the sort of rich information that would be fully in-scope for something like MILE.

andrew

---

From: Andrew Mortensen <[email-masked]>
Date: Thu, 9 Apr 2015 01:11:52 -0400

> On Apr 8, 2015, at 10:46 PM, Scott Barvick <[email-masked]> wrote:
> 

Agreed, there are lots of reasons why a network operator may want to request upstream intervention regardless of the current traffic conditions. We won’t be able to spell them all out, but that won’t matter as long as we leave control over when to mitigate in the hands of the downstream network owners.

andrew

---

From: John Schiel <[email-masked]>
Date: Thu, 09 Apr 2015 09:19:37 -0600

inline.

On 04/08/2015 08:54 PM, Xialiang (Frank) wrote:
>
> Hi John,
>
> Please see inline:
>
> Thanks!
>
> B.R.
>
> Frank
>
> *From:*Dots [mailto:[email-masked]] *On Behalf Of *John
> *Sent:* Wednesday, April 08, 2015 11:42 PM
> *To:* [email-masked]
>     Sorry I'm late to this discussion but I've recently learned of 
> this effort and I'm very interested in the topic. If my questions have 
> already been addressed and I missed where this was previously 
> discussed, I'm apologize for raising the issue again and I would 
> appreciate being directed to where the question was answered or discussed.
>
> Please see inline.
>
>     Thanks for the intro and welcome.     From the reading of the
>     minutes and the thread, it seems that we can and should be using
>     the words ‘DDoS’ and ‘signaling’  along with not overlapping with
>     other IETF work to help us check our activities against a focus
>     that will allow us to get chartered as a WG and then make the
>     required progress towards goals that we will have as one.   If it
>     is not directly contributing to the signaling of DDoS
>     threats/conditions/capabilities then we really should really not
>     be spending any time on it.    As examples (for discussion, of course)
>
>     -DDoS capabilities negotiation between the communicating parties -
>      in scope because it affects what can be signaled or needs to be
>     done on either side
>
>     -Configuration or provisioning of the devices for DDoS – not in
>     scope because while it is DDoS, it is beyond what is necessary to
>     signal.  And we have other protocols to define the operations and
>     even schemas for this
>
> surpassing or taking full advantage of mitigation without knowing if 
> you are at, near, or above the signaling thresholds?
>
>             * As part of authentication, we need some way to verify 
> the authenticating parties and agree upon authentication methods.
> are applicable and valid? What's in place to prevent a CPE from 
> sending invalid DDoS representation? The CPE could have been 
> compromised or the owner of the CPE may try to send data that falsely 
> blames a competitor and thus ends up allowing for a DoS of said 
> competitor.
>
> */[Frank] : I’d like to think the CPE is trusted if it’s a 
> authenticated peer. It’s the traditional authentication way, isn’t it?/*
>
Frank,
This still does not address the issue of a compromised CPE or a 
malicious CPE owner. The authentication could/would most likely be set 
up in a normal provisioning. The CPE owner is not at fault initially 
when setting up the authentication but when the device is compromised, 
it could be possible for the device to send notification when it should 
not by the adversary.

As for the malicious CPE owner comment, I've found the minutes from ietf 
92 and currently working my way through the data. If I have more 
questions or concerns about whether a customer could falsely initiate 
any malicious events to a competitor, I'll address those in another thread.

Thanks,

--John

> *//*
> [email-masked]  <mailto:[email-masked]>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 10 Apr 2015 09:11:43 +0000

Hi, Andrew:
Please see my comments inline.

From: Andrew Mortensen [mailto:[email-masked]]
Sent: Thursday, April 09, 2015 12:59 PM
To: Xialiang (Frank)
Cc: Scott Barvick; Dave Larson; Teague, Nik; [email-masked]
Subject: Re: [Dots] DOTS work scope discussion: //RE: scope

When to mitigate, and whom to ask for help mitigating, should be left up to network operators. (This can of course include automitigation, as the operator will just have made the decisions beforehand.)
[Frank] : I really think some good examples and real use cases can help us to see if the capability negotiation is needed. But in addition to capability info, there are possibly other parameters need to be negotiate.

<snip>

But it sounds like instead of using on-premise collectors, you’re suggesting sampled flow should be exported upstream during attack. Is that accurate?
[Frank] : No. what I suggest is the flow sampling information can be exported from the router, switch to the upstream anti-ddos platform. Of course, the on-premise collectors you mention here can do the same job.

You’ll get no argument from me that representing and sharing DDoS attack profiles is useful work. The scope of that work is enormous, though, and DOTS is focused on the signaling aspect: providing (in my view) minimally necessary information to an upstream element to signal the need for aid fighting off an attack. What “minimally necessary” means remains a matter for debate, of course, but in my mind that excludes a great deal of the sort of rich information that would be fully in-scope for something like MILE.
[Frank] : a clear gap analysis between DOTS and MILE is very useful for this point~~

andrew