Subject: [Dots] Feedback on draft-ietf-dots-requirements

From: Roman Danyliw <[email-masked]>
Date: Wed, 3 Jan 2018 22:32:55 +0000

Hello!
(chair hat off)

The following is feedback for the WGLC on -09 of draft-ietf-dots-requirements.  Even with the -10 update, these should apply.  Other than the feedback below, I believe the draft is ready to proceed.

(1) Abstract.  Editorial.

- "This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks."
+ "This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols that enable the coordination of and  response to DDoS attacks."

(2) Section 1.1, paragraph 1, Editorial.

-   Distributed Denial of Service (DDoS) attacks continue to plague
   network operators around the globe, from Tier-1 service providers on
   down to enterprises and small businesses.  Attack scale and frequency
   similarly have continued to increase, in part as a result of software
   vulnerabilities leading to reflection and amplification attacks.
   High-volume attacks saturating inbound links are now common, and the
   impact of larger-scale attacks attract the attention of international
   press agencies.

+   Distributed Denial of Service (DDoS) attacks plague
   network operators at service providers and
   down to enterprises of all sizes.  
   High-volume attacks saturating inbound links are now common.  
   Similarly, attack scale and frequency have continued to increase.

(3) Section 1.1, paragraph 2, Editorial.

-   The greater impact of contemporary DDoS attacks has led to increased
   focus on coordinated attack response.  Many institutions and
   enterprises lack the resources or expertise to operate on-premises
   attack mitigation solutions themselves, or simply find themselves
   constrained by local bandwidth limitations.  To address such gaps,
   security service providers have begun to offer on-demand traffic
   scrubbing services, which aim to separate the DDoS traffic from
   legitimate traffic and forward only the latter.  Today each such
   service offers a proprietary invocation interface for subscribers to
   request attack mitigation, tying subscribers to proprietary signaling
   implementations while also limiting the subset of network elements
   capable of participating in the attack mitigation.  As a result of
   signaling interface incompatibility, attack responses may be
   fragmentary or otherwise incomplete, leaving key players in the
   attack path unable to assist in the defense.

+  The prevalence and impact of these DDoS attacks has led to an increased
   focus on coordinated attack response.  However, many enterprises 
   lack the resources or expertise to operate on-premises
   attack mitigation solutions themselves, or are
   constrained by local bandwidth limitations.  To address such gaps,
   service providers have begun to offer on-demand traffic
   scrubbing services, which aim to separate the DDoS attack traffic from
   legitimate traffic and forward only the latter.  

   Today, these services offers a proprietary interface for subscribers to
   request attack mitigation.  Such proprietary interfaces tie a subscriber 
    to a service while also limiting the network elements
   capable of participating in the attack mitigation.  As a result of
   signaling interface incompatibility, attack responses may be
   fragmented or otherwise incomplete, leaving operators in the
   attack path unable to assist in the defense.

(4) Section 1.1, paragraph 3, Editorial (simplification)

-   The lack of a common method to coordinate a real-time response among
   involved actors and network domains inhibits the speed and
   effectiveness of DDoS attack mitigation.  This document describes the
   required characteristics of protocols enabling requests for DDoS
   attack mitigation, reducing attack impact and leading to more
   efficient defensive strategies.

+ A standardized method to coordinate a real-time response among involved operators will increase the speed and effectiveness of DDoS attack mitigation, and reduce the impact of these attacks.  This document describes the required characteristics of protocols that enable attack coordination and mitigation of DDoS attacks.

(5) Section 1.1, paragraph 4, Editorial (simplification)

   - DDoS Open Threat Signaling (DOTS) communicates the need for defensive
   action in anticipation of or in response to an attack, but does not
   dictate the form any defensive action takes.  DOTS supplements calls
   for help with pertinent details about the detected attack, allowing
   entities participating in DOTS to form ad hoc, adaptive alliances
   against DDoS attacks as described in the DOTS use cases
   [I-D.ietf-dots-use-cases].  The requirements in this document are
   derived from those use cases and [I-D.ietf-dots-architecture].

+  DDoS Open Threat Signaling (DOTS) communicates the need for defensive action in anticipation of or in response to an attack, but does not dictate the implementation of these actions.  The requirements in this document are derived from [I-D.ietf-dots-use-cases] and [I-D.ietf-dots-architecture].

(6) Section 1.2, Terminology, DDoS.  Editorial (subject-verb agreement):

- A distributed denial-of-service attack, in which traffic originating from multiple sources are ...  
+ A distributed denial-of-service attack, in which traffic originating from multiple sources is ...   

(7) Section 1.2, Terminology, DDoS.  Editorial (don't redefine attack target):

- DDoS attacks are intended to cause a negative impact on the availability of servers, services, applications, and/or other  functionality of an attack target.  
+ DDoS attacks are intended to cause a negative impact on the availability and/or other  functionality of an attack target.  

(8) Section 1.2, Terminology, Mitigation.  The difference between countermeasure and mitigation isn't clear to me given the current text.

(9) Section 1.2, Terminology, Mitigator. Editorial (clarity)

- ...  For
      the purposes of this document, this entity is a black box capable
      of mitigation, making no assumptions about availability or design
      of countermeasures, nor about the programmable interface(s)
      between this entity and other network elements.  

+ The means by which this entity performs these mitigations and how they are requested of it are out of scope.

(10) Section 1.2, Terminology, Mitigator.  In the sentence "The mitigator and invoked DOTS server are assumed to belong to the same administrative entity", what is an "invoked server" isn't clear in the text.

(11) Section 1.2, Terminology, DOTS server.  Editorial.

- A DOTS server may also be colocated  with a mitigator.
+ A DOTS server may be colocated  with a mitigator.

(12) Section 1.2, Terminology, DOTS server.  In the sentence, " A DOTS server may also be colocated  with a mitigator", what does "collocated" mean in this context?

(13) Section 1.2, Terminology, DOTS gateway.  Editorial (clarity)

- A DOTS-aware software module resulting from the
      logical concatenation of a DOTS server and a DOTS client,
      analogous to a Session Initiation Protocol (SIP) [RFC3261] Back-
      to-Back User Agent (B2BUA) [RFC7092].

+ A DOTS-aware software module resulting from the logical concatenation of the functionality of a DOTS server and a DOTS client into a single DOTS agent.  This functionality is analogous to a Session Initiation Protocol (SIP) [RFC3261] Back-to-Back User Agent (B2BUA) [RFC7092].

(14) Section 1.2 Terminology, signal channel.  Editorial

- A bidirectional, mutually authenticated
      communication channel between two DOTS agents characterized by
      resilience even in conditions leading to severe packet loss, such
      as a volumetric DDoS attack causing network congestion.

+ A bidirectional, mutually authenticated communication channel between DOTS agents that is resilient even in conditions leading to severe packet loss, such as a volumetric DDoS attack causing network congestion.

(15) Section 1.2, Terminology, DOTS signal.  From this definition, it isn't clear if a DOTS signal is part of the signal channel.

(16) Section 1.2, Terminology, Data channel.  Why is the terminology "secure communication layer" used here when the definition of the signal channel uses "...bidirectional, mutually authenticated communication channel"?  I would recommend using the same language in both places.

(17) Section 1.2, Terminology, Blacklist.  The sentence " A filter list of addresses, prefixes, and/or other identifiers ..." seems to redefine filter.  I recommend:

- A filter list of addresses, prefixes, and/or other
      identifiers  indicating ...
+ A list of filters indicating  ...

(18) Section 1.2, Terminology, Whitelist.  Unlike the definition of a blacklist, this definition doesn't used the word filter at all.  Perhaps these definitions should be consistent.

- A list of addresses, prefixes , and/or other identifiers indicating ...
+ A list of filters indicating ...

(19) Section 2, Requirements.  In "The DOTS protocol must at a minimum make it possible for a DOTS client to request a mitigator's aid mounting a defense, coordinated
   by a DOTS server, against a suspected attack, signaling within or between domains as requested by local operators.", it seems odd to say that a DOTS client is requesting a mitigators aid.  Isn't the interface used by a client a DOTS server?  The rest is opaque to the client.  

(20) Section 2, Requirements.  Per the last sentence of the second paragraph, "Furthermore, multi-homing considerations  are out of scope."  Does that mean that the technique for selecting the appropriate server in a multi-homed environment is out of scope.  If so, I'd recommend being more explicit.

(21) Section 2, Requirements.  Editorial.

- Regular feedback between DOTS clients and DOTS servers supplement the
   defensive alliance by maintaining a common understanding of the DOTS
   agents' health and activity.  Bidirectional communication between
   DOTS clients and DOTS servers is therefore critical.

+   Regular communication between DOTS clients and servers enable a common understanding of the DOTS agents' health and activity.  

(22) Section 2, Requirements. Editorial.

-   Operators of peer DOTS-enabled domains may enable quality- or class-
   of-service traffic tagging to increase the probability of successful
   DOTS signal delivery, but DOTS does not require such policies be in
   place.  The DOTS solution indeed must be viable especially in their
   absence.

+   Operators of peer DOTS-enabled domains may enable quality- or class-of-service traffic tagging to increase the probability of successful DOTS signal delivery, but DOTS does not require such policies be in place and should be viable in their absence

(23) Section 2, Requirements.  Per the paragraph, "On the other hand, DOTS must include protections ensuring message confidentiality, integrity and authenticity to keep the protocol from ...", isn't the majority of this content already covered in SEC-001, SEC-002, SEC-003?

(24) Section 2, Requirements.  Editorial.

-   The DOTS server and client must also have some common method of
   defining the scope of any mitigation performed by a mitigator, as
   well as making adjustments to other commonly configurable features,
   such as targeted port numbers, exchanging black- and white-lists, and
   so on. 

+ The DOTS server and client must also have some standardized  method of defining the scope of any mitigation; and negotiating related mitigation communication and actions and communications.

(25) Section 2.1, GEN-001.  Editorial.

- Protocols and data models developed as part
      of DOTS MUST be extensible in order to keep DOTS adaptable to
      future operational and proprietary DDoS defenses.

+ Protocols and data models developed as part
      of DOTS MUST be extensible in order to keep DOTS adaptable to
      future operational and proprietary DDoS practices.

(26) Section 2.1, GEN-002.  Editorial.

- The signaling protocol MUST be
      designed to maximize the probability of signal delivery even under
      the severely constrained network conditions imposed by ...
+ The signaling protocol MUST be
      designed to maximize the probability of signal delivery even under
      the severely constrained network conditions caused by ...

(27) Section 2.1, GEN-003.  Editorial.

- To support peer health detection, to
      maintain an open  signal channel, and to increase the probability
      of signal delivery during an attack, ...

+ To support peer health detection, 
      maintain an open  signal channel, and increase the probability
      of signal delivery during an attack, ...

(28) Section 2.1, GEN-003.  Is it an "open signal channel" or an "active signal channel"?

(29) Section 2.2, SIG-003.  "The heartbeat interval during active mitigation is not specified ..."  Does that mean in this draft, or that is isn't specified in the protocol drafts?  I ask be cause a default value is specified in the protocol draft.

(30) Section 2.2, SIG-003.  Per "DOTS servers SHOULD monitor the attack, using feedback from the mitigator and other available sources, and MAY use the absence of attack traffic and lack of client heartbeats as an indication the signal channel is defunct.",  I have some concern that this is a "SHOULD".  This indicates that a protocol mechanism needs to be specified for interacting with the mitigator -- isn't that out of scope for DOTS?

(31) Section 2.2, SIG-004.  Per "DOTS clients MAY attempt abbreviated security negotiation methods supported by the protocol, such as DTLS session resumption, but MUST be prepared to negotiate new security state with the redirection target DOTS server.", I have some concerns that abbreviated security negotiation is a "MAY" without even knowing what the chosen protocol might be (and the assumption in the abbreviated negotiation of this unknown protocol).  I recommend removing or softening this language.

(32) Section 2.2, SIG-004.  Editorial.

- Due to the increased likelihood of packet loss caused by link
      congestion during an attack, DOTS servers SHOULD NOT redirect
      while mitigation is enabled during an active attack against a
      target in the DOTS client's domain.

+ Due to the increased likelihood of packet loss caused by link congestion during an attack, DOTS servers SHOULD NOT redirect active attack against a target in the DOTS client's domain while a mitigation is enabled.

(33) Section 2.2, SIG-005.  Editorial (clarity)

- DOTS
      servers MUST send mitigation request status in response to granted
      DOTS clients requests for mitigation.

+ DOTS servers MUST send status to the DOTS clients about mitigation requests 

(34) Section 2.2., SIG-005.  Per, "For example, if there is a financial relationship between the DOTS client and server domains, the DOTS client ceases incurring cost at this point.", I feel that this crosses too much into operational matters.  I recommend removal.

(35) Section 2.2, SIG-006.  Editorial.

- DOTS servers MUST support mitigation
      lifetimes, ...
+ DOTS servers MUST support mitigations for a negotiated time interval or lifetime, ...

(36) Section 2.2, SIG-009.  Per "Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources  as a result of misconfiguration, ...", what are "pools of protected resources"?

(37) Section 2.2, SIG-010.  Per "Regardless of transport, DOTS protocols MUST follow established best common practices (BCPs) for NAT traversal.", which BCPs to follow as a "MUST" aren't clear (unless you just meant RFC8085?).

(38) Section 2.3, Data Channel Requirement.  As a style note, this section, unlike the signal channel section has a list of un-numbered requirements in the introduction.

(39) Section 2.3, Data Channel Requirement.  Editorial.

- Unlike the signal channel, which must operate
   nominally even when confronted with signal degradation due to
   significant packet loss, the data channel is not expected to be
   constructed to deal with attack conditions.

+ Unlike the signal channel, the data channel is not expected to operate under with attack conditions.

(40) Section 2.3, Data Channel Requirement.  Per "The DOTS data channel protocol MUST be extensible.", isn't this thinking already stated in GEN-001?

(41) Section 2.3, Data Channel Requirement.  Per "We anticipate the data channel will be used for such purposes as configuration or resource discovery. ...", isn't this statement mostly covered in GEN-004?  Could it be merged there instead?

(42) Section 2.3, Data Channel Requirement.  Per "The transactional nature of such data exchanges suggests a separate set of requirements for the data channel, while the potentially sensitive content sent between DOTS agents requires extra precautions to ensure data privacy and authenticity.", isn't this statement the same as DATA-002?

(43) Section 2.3, DATA-002.  Concur with the requirement.  Does the signal channel need an analogous requirement?

(44) Section 2.3, DATA-002.  Some of these statements seem to overlap with SEC-001 and SEC-002, especially with regard to the need for confidentiality and authentication.

(45) Section 2.3, DATA-003.  Editorial.

- To help meet the general and signal
      channel requirements in Sections 2.2, DOTS server ...
+ To help meet the general and signal channel requirements in Sections 2.1 and 2.2, DOTS server ...

(46) Section 2.4, SEC-001 and SEC-002.  Editorial.

s/industry best practices/IETF best practices/

(47) Section 2.5, Data Model Requirements.

-  The value of DOTS is in standardizing a mechanism to permit elements,
   networks or domains under threat of DDoS attack to request aid
   mitigating the effects of any such attack.  A well-structured DOTS
   data model is therefore critical to the development of successful
   DOTS protocols.

+ A well-structured DOTS data model is critical to the development of successful
   DOTS protocols.

(48) Section 2.5, DM-001: Per " The data model structure for the DOTS protocol may  be described by a single module, or be divided into related collections of hierarchical modules and sub-modules.", should this be a "MAY" (not a "may")?

(49) Section 4, Security considerations.  I'd recommend (a) explicitly say that this draft doesn't have its own security considerations but is used to inform future protocols under development; and (b) discuss the bulleted attacks in a bit more detail.

Regards,
Roman

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 4 Jan 2018 19:30:36 +0000

Thanks for the very close reading, Roman. In general the editorial changes look fine. A few comments and questions inline below.

andrew

> On Jan 3, 2018, at 5:32 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hello!
> (chair hat off)
> 
> + "This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols that enable the coordination of and  response to DDoS attacks.”

I think we just want “…enable coordination of response to…”, since we’re otherwise left with “…coordination of…DDoS attacks”, which is clearly not the meaning we’re shooting for.

> …snip...

Maybe “…how they are configured and managed [or maintained]…” instead? The term “mitigation request” has a very specific meaning in DOTS.

> …snip...

The original concluding sentence was “A DOTS server MAY also be a mitigator” (with unnecessary RFC 2119 term). After thinking about it a bit, I’m not sure that either the current phrasing or the original are necessary to the draft. Does anyone object to removing it?

> …snip…

I think “…DDoS defensive practices” or something similar emphasizing defensive measures, no? Otherwise we’re confusing the disease with the cure.

> …snip…
> 
> (28) Section 2.1, GEN-003.  Is it an "open signal channel" or an "active signal channel”?

I think “active", thanks for pointing this one out.

> …snip...

Yes, good point. Does changing from SHOULD to MAY monitor seem acceptable to the WG?

> (31) Section 2.2, SIG-004.  Per "DOTS clients MAY attempt abbreviated security negotiation methods supported by the protocol, such as DTLS session resumption, but MUST be prepared to negotiate new…

If we remove the RFC2119 language and change to “DOTS clients can attempt abbreviated…” (or “...are free to…”), does that soften the language sufficiently?

> + Due to the increased likelihood of packet loss caused by link congestion during an attack, DOTS servers SHOULD NOT redirect active attack against a target in the DOTS client's domain while a miti…

I find this one confusing. Are you hoping to emphasize the importance of not redirecting while a mitigation is actively fending off an attack? I think that’s a potentially useful point, since an always-on mitigation may not always be filtering attack traffic, but I don’t think the modification helps make that case. Maybe something like “…SHOULD NOT redirect while a mitigation is actively filtering attack traffic”?

> …snip...
> 
> (36) Section 2.2, SIG-009.  Per "Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources  as a result of misconfiguration, ...", what are "pools of protected resources”?

I think we can safely remove that phrase and retain the intended meaning.

> (37) Section 2.2, SIG-010.  Per "Regardless of transport, DOTS protocols MUST follow established best common practices (BCPs) for NAT traversal.", which BCPs to follow as a "MUST" aren't clear (unl…

Indeed, just RFC8085.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 5 Jan 2018 17:30:55 +0000

Hi Andrew!

> -----Original Message-----
> From: Mortensen, Andrew [mailto:[email-masked]]
> Sent: Thursday, January 04, 2018 2:31 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Dots] Feedback on draft-ietf-dots-requirements
> 
> Thanks for the very close reading, Roman. In general the editorial changes
> look fine. A few comments and questions inline below.
> 
> andrew
> 
> 
> > The following is feedback for the WGLC on -09 of draft-ietf-dots-
> requirements.  Even with the -10 update, these should apply.  Other than the
> feedback below, I believe the draft is ready to proceed.
> >
> > (1) Abstract.  Editorial.
> >
> > - "This document defines the requirements for the Distributed Denial of
> Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack
> response against DDoS attacks."
> > + "This document defines the requirements for the Distributed Denial of
> Service (DDoS) Open Threat Signaling (DOTS) protocols that enable the
> coordination of and  response to DDoS attacks.”
> 
> I think we just want “…enable coordination of response to…”, since we’re
> otherwise left with “…coordination of…DDoS attacks”, which is clearly not the
> meaning we’re shooting for.

OK.  I understand now.
 
> Maybe “…how they are configured and managed [or maintained]…” instead?
> The term “mitigation request” has a very specific meaning in DOTS.

OK.  This proposed text works for me.

> > …snip...
> >
> > (12) Section 1.2, Terminology, DOTS server.  In the sentence, " A DOTS
> server may also be colocated  with a mitigator", what does "collocated" mean
> in this context?
> 
> The original concluding sentence was “A DOTS server MAY also be a
> mitigator” (with unnecessary RFC 2119 term). After thinking about it a bit, I’m
> not sure that either the current phrasing or the original are necessary to the
> draft. Does anyone object to removing it?

I endorse removing the text.
 
> I think “…DDoS defensive practices” or something similar emphasizing
> defensive measures, no? Otherwise we’re confusing the disease with the
> cure.

This was very style-specific feedback.  On reflection, just keep the original text.  
 
> > …snip…
> > (30) Section 2.2, SIG-003.  Per "DOTS servers SHOULD monitor the attack,
> using feedback from the mitigator and other available sources, and MAY use
> the absence of attack traffic and lack of client heartbeats as an indication the
> signal channel is defunct.",  I have some concern that this is a "SHOULD".  This
> indicates that a protocol mechanism needs to be specified for interacting
> with the mitigator -- isn't that out of scope for DOTS?
> 

I'd propose something weaker like "could" (no RFC2119 language) to keep the boundaries clear.  I'm interested to hear how other feel.

 > > (31) Section 2.2, SIG-004.  Per "DOTS clients MAY attempt abbreviated
> security negotiation methods supported by the protocol, such as DTLS
> session resumption, but MUST be prepared to negotiate new security state
> with the redirection target DOTS server.", I have some concerns that
> abbreviated security negotiation is a "MAY" without even knowing what the
> chosen protocol might be (and the assumption in the abbreviated
> negotiation of this unknown protocol).  I recommend removing or softening
> this language.
> 
> If we remove the RFC2119 language and change to “DOTS clients can attempt
> abbreviated…” (or “...are free to…”), does that soften the language
> sufficiently?

Yes.  I like your proposed softer language.

> > + Due to the increased likelihood of packet loss caused by link congestion
> during an attack, DOTS servers SHOULD NOT redirect active attack against a
> target in the DOTS client's domain while a mitigation is enabled.
> 
> I find this one confusing. Are you hoping to emphasize the importance of not
> redirecting while a mitigation is actively fending off an attack? I think that’s a
> potentially useful point, since an always-on mitigation may not always be
> filtering attack traffic, but I don’t think the modification helps make that case.
> Maybe something like “…SHOULD NOT redirect while a mitigation is actively
> filtering attack traffic”?

Oops.  I transposed words in my suggestion.  I meant to say:

"Due to the increased likelihood of packet loss caused by link congestion during an attack, DOTS servers SHOULD NOT redirect during an active attack against a target in the DOTS client's domain while a mitigation is enabled."

This was very style-specific feedback.  On reflection, just keep the original text

Roman