Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt

From: [email-masked]
Date: Mon, 19 Oct 2015 10:27:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DDoS Open Threat Signaling Working Group of the IETF.

        Title           : DDoS Open Threat Signaling Requirements
        Authors         : Andrew Mortensen
                          Robert Moskowitz
                          Tirumaleswar Reddy
	Filename        : draft-ietf-dots-requirements-00.txt
	Pages           : 12
	Date            : 2015-10-19

Abstract:
   This document defines the requirements for the DDoS Open Threat
   Signaling (DOTS) protocols coordinating attack response against
   Distributed Denial of Service (DDoS) attacks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dots-requirements-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dave Dolson <[email-masked]>
Date: Mon, 2 Nov 2015 19:38:51 +0000

Regarding draft-ietf-dots-requirements-00,

Is OP-006 intended to refer to source or destination IP addresses, or both?
It could also be clarified for port range.

"OP-006 Mitigation Scope: DOTS clients MUST indicate the desired
address space coverage of any mitigation, for example by using
Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519]
prefixes, [RFC2373] for IPv6 prefixes, the length/prefix
convention established in the Border Gateway Protocol (BGP)
[RFC4271], or by a prefix group alias agreed upon with the server
through the data channel. If there is additional information
available narrowing the scope of any requested attack response,
such as targeted port range, protocol, or service, clients SHOULD
include that information in client signals."

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 20, 2015 2:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: Dave Dolson <[email-masked]>
Date: Mon, 2 Nov 2015 19:38:57 +0000

Regarding the dots-requirements-00,

Another type of Security Consideration should be mentioned in the document:

Knowing (or guessing) the criteria for automatically triggering mitigation, an attacker could set up traffic patterns to cause mitigation to be enacted. Since a mitigation can deny service to legitimate traffic, an attacker could therefore trick the system into creating mitigations and denying service.
Furthermore, an attacker could create multiple mitigations, and without protection could overload the dots protocol itself, attacking dots session state, dots protocol bandwidth and dots CPU utilization.
An "attack" might even be accidental, such as with a new release of an application that creates unexpected traffic patterns.

This isn't mentioned in the use-cases doc either.
I don't think it's purely theoretical; it could occur with threshold settings that are too low (naïve or mistakes).

So, perhaps something like this:
DOTS must define protections against attacks on the DOTS infrastructure by an attacker who creates false-positive attack detections.
DOTS must define mechanisms for a client or server to function robustly under high messaging load from its peer(s).
DOTS must define back-off mechanisms so that neither client nor server will overload the peer with messaging.

A method of back-off may include adapting the threshold settings.

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 20, 2015 2:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt

Abstract:

---

From: Andrew Mortensen <[email-masked]>
Date: Mon, 2 Nov 2015 20:47:21 -0500

> On Nov 2, 2015, at 2:38 PM, Dave Dolson <[email-masked]> wrote:
> 

Thanks for your comments. As written, OP-006 refesr to protected resources only, so that the client can help shape the scope of a particular mitigation. A client is authoritative in the scope of protection for address space it owns, but may not be authoritative or accurate with respect to the sources of attack. I will clarify.

As a separate but related point, a client may also request mitigation in the absence of attack (e.g., always on, or in anticipation of an impending attack), which is something I should make explicit.

> It could also be clarified for port range.

Marked for addition.

andrew

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 01:56:08 +0000

Andrew,
I think you are saying that only destination address filtering can be specified?

If a client detects an attack coming from a particular source, wouldn't it make sense to make a more precise filter?

-Dave

-----Original Message-----
From: Andrew Mortensen [mailto:[email-masked]] 
Sent: Tuesday, November 03, 2015 10:47 AM
To: Dave Dolson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt

Marked for addition.

andrew

> Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] prefixes, 
> [RFC2373] for IPv6 prefixes, the length/prefix convention established 
> in the Border Gateway Protocol (BGP) [RFC4271], or by a prefix group 
> alias agreed upon with the server through the data channel. If there 
> is additional information available narrowing the scope of any 
> requested attack response, such as targeted port range, protocol, or 
> service, clients SHOULD include that information in client signals."
> 
> -Dave
>

---

From: Andrew Mortensen <[email-masked]>
Date: Mon, 2 Nov 2015 21:00:39 -0500

> On Nov 2, 2015, at 8:56 PM, Dave Dolson <[email-masked]> wrote:
> 
> Andrew,

Specifying mitigation scope—that is, the client restricting a mitigation to address space/services it owns—and blacklisting sources of bad traffic are distinct. It’s not feasible or effective for a DOTS client to try to narrow mitigation scope by source address when the services under attack are being hit by a botnet comprised of thousands of hosts.

andrew

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 03 Nov 2015 19:11:38 +0900

On 3 Nov 2015, at 4:38, Dave Dolson wrote:

> I don't think it's purely theoretical; it could occur with threshold 
> settings that are too low (naïve or mistakes).

This isn't a DOTS-specific issue; it's the realm of the 
detection/classification/traceback/mitigation systems which may be 
DOTS-enabled.

So, this is really out of bounds for DOTS, which is merely a messaging 
system.

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

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 19:37:17 +0000

As I understand the purpose of ‎the security section, you should nonetheless document the issue.

But I'm not sure that rate-limiting DOTS events should be out of the question.
E.g. Dime WG added rate feedback and control to Diameter protocol even though one could point to the problem of "too many users joining the network at once" as out of scope.

  Original Message
From: Roland Dobbins
Sent: Tuesday, November 3, 2015 7:11 PM
To: [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt

---

From: Gilbert Clark <[email-masked]>
Date: Tue, 3 Nov 2015 16:11:18 -0500

I really don't like the idea of including anything in DOTS that has 
already been implemented elsewhere without having a good reason to do 
so.  I see a DOTS message as a simple, no-nonsense way to convey a 
request for help from point A to point B.

Additional thoughts inline:

> As I understand the purpose of ‎the security section, you should nonetheless document the issue.

Could be wrong, but ... I don't believe the security section of a 
requirements draft is necessarily the same as the security 
considerations section of an eventual protocol draft.  In my head, I see 
security items included in the requirements draft as being the 
principles that most influence the eventual design of the DOTS 
protocol.  The security considerations of a DOTS protocol draft would 
define items that should be considered when deploying or using the protocol.

> But I'm not sure that rate-limiting DOTS events should be out of the question.

I'm not convinced that the DOTS protocol is the *right place* to include 
said rate-limiting.  Why should we re-invent that particular function here?

> DOTS must define protections against attacks on the DOTS infrastructure by an attacker who creates false-positive attack detections.

In my mind, DOTS is simply a request for help with some context 
attached.  It doesn't know what a false positive is.  Why should *DOTS* 
be responsible for this?

> DOTS must define mechanisms for a client or server to function robustly under high messaging load from its peer(s).

Disagree with inclusion in the requirements as stated.  Different 
failure modes can make sense in different cases, and "high messaging 
load" and "robustly" are both relative.  Also, I doubt a network could 
support updates to mitigation configurations at anything resembling high 
messaging load: many mitigation strategies will take discrete time to 
propagate (especially inter-domain) and will consume resources.  
Flooding a DOTS server with messages for help (or even updates to 
previous help requests, for that matter) won't make the help come any 
faster.  Thus, I don't see a reason to even bother to try to process 
these messages at high rate: instead, I'd imagine that someone would 
apply aggressive rate limits to messages sourced by each individual 
supplicant, and only worry about supporting high messaging load in the 
cases it was actually necessary (read: a handful of large providers).

> DOTS must define back-off mechanisms so that neither client nor server will overload the peer with messaging.

Disagree with inclusion in the requirements as stated.  See note about 
rate-limiting above.

Believe this would make a good note in the security considerations 
section of an eventual protocol draft, however.

-Gilbert

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 21:25:56 +0000

Gilbert,

> I'd imagine that someone would apply aggressive rate limits to messages sourced by each individual supplicant, and only worry about supporting high messaging load in the cases it was actually necessary

This is precisely an example of a mechanism for functioning under high message load!

I'm not saying the concerns are insurmountable. I think most of the dots participants are intuitively working towards robust design.

Anyhow, take it or leave it. I'm trying to ensure that I'm understood, but I'm not a security reviewer.

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Wednesday, November 04, 2015 6:11 AM
To: [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt

I really don't like the idea of including anything in DOTS that has already been implemented elsewhere without having a good reason to do so.  I see a DOTS message as a simple, no-nonsense way to convey a request for help from point A to point B.

> As I understand the purpose of ‎the security section, you should nonetheless document the issue.

Could be wrong, but ... I don't believe the security section of a requirements draft is necessarily the same as the security considerations section of an eventual protocol draft.  In my head, I see security items included in the requirements draft as being the principles that most influence the eventual design of the DOTS protocol.  The security considerations of a DOTS protocol draft would define items that should be considered when deploying or using the protocol.

> But I'm not sure that rate-limiting DOTS events should be out of the question.

I'm not convinced that the DOTS protocol is the *right place* to include said rate-limiting.  Why should we re-invent that particular function here?

> DOTS must define protections against attacks on the DOTS infrastructure by an attacker who creates false-positive attack detections.

In my mind, DOTS is simply a request for help with some context attached.  It doesn't know what a false positive is.  Why should *DOTS* be responsible for this?

> DOTS must define mechanisms for a client or server to function robustly under high messaging load from its peer(s).

Disagree with inclusion in the requirements as stated.  Different failure modes can make sense in different cases, and "high messaging load" and "robustly" are both relative.  Also, I doubt a network could support updates to mitigation configurations at anything resembling high messaging load: many mitigation strategies will take discrete time to propagate (especially inter-domain) and will consume resources.  
Flooding a DOTS server with messages for help (or even updates to previous help requests, for that matter) won't make the help come any faster.  Thus, I don't see a reason to even bother to try to process these messages at high rate: instead, I'd imagine that someone would apply aggressive rate limits to messages sourced by each individual supplicant, and only worry about supporting high messaging load in the cases it was actually necessary (read: a handful of large providers).

> DOTS must define back-off mechanisms so that neither client nor server will overload the peer with messaging.

Disagree with inclusion in the requirements as stated.  See note about rate-limiting above.

Believe this would make a good note in the security considerations section of an eventual protocol draft, however.

-Gilbert

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 10:09:02 +0900

> nonetheless document the issue.

I'm not sure I agree with this.  It has nothing to do with DOTS itself.

> But I'm not sure that rate-limiting DOTS events should be out of the 

That's a different issue, and a valid one, IMHO.  DOTS clients, servers, 
and relays should have this capability, IMHO.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 10:11:10 +0900

> Disagree with inclusion in the requirements as stated.  See note about 

I concur with all your points, except I do see utility in the ability to 
rate-limit DOTS message generation/forwarding/parsing as an 
implementation requirement for all DOTS agents.