Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt

From: "Jon Shallow" <[email-masked]>
Date: Thu, 8 Mar 2018 16:16:24 -0000

Hi there,

To close the loop (as I raised the initial questions), GEN-004 and GEN-005 give me (and the WG) the flexibility to add in additional information to the signal/data specs should it be needed.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 08 February 2018 05:37
To: Mortensen, Andrew
Cc: dots
Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt

From: Mortensen, Andrew [mailto:[email-masked]] 
Sent: Thursday, February 8, 2018 10:34 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: dots <[email-masked]>
Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt

On Feb 7, 2018, at 10:26 PM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:

1)

  GEN-005  Loop Handling: In specific scenarios, it may be possible for

      communication between DOTS agents to loop, for example as a result

      of misconfiguration or aggressive caching.

comment> The looping attack Jon discussed in the mailing list is because of misconfiguration

and DNS cache poisoning. What do you mean by "aggressive caching” ?

Sorry, I had meant to provide a specific example of misconfiguration, and didn’t finish the thought. I’m skeptical of the DNS cache poisoning example for the same reason you cited on the list.

Let’s remove “aggressive caching”.  

 2)  Mitigation hints MAY be transmitted across either signal or data channel.

comment> I don't think the DOTS client will know the mitigation hints during peace time to convey the hints in the data channel !

I had in mind always-on mitigation. I wanted to leave open the possibility that the DOTS client operators might provide hints to inform the shape of that always-on mitigation. Since the conversation leading to this requirement addition concluded with what seemed to be an agreement that we wanted to create space for undefined forms of hinting, it seemed reasonable to assume a DOTS operator could have some form of threat intelligence which could be provided in such a scenario.

Got it, thanks.

Cheers,

-Tiru

andrew

From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: Wednesday, February 7, 2018 10:39 PM
To: dots <[email-masked]>
Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt

Not wanting to lose momentum from today’s interim meeting, I’ve updated the requirements draft to address the remaining issues. Please take a close look at GEN-004 and -005, which add the mitigation hinting and loop handling general requirements, respectively. As discussed during today’s meeting, the bidirectionality requirement (formerly GEN-003) has been moved under the signal channel requirements as SIG-003.

andrew

Begin forwarded message:

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

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

Date: February 7, 2018 at 12:05:38 PM EST

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

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

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 WG of the IETF.

       Title           : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
       Authors         : Andrew Mortensen
                         Robert Moskowitz
                         Tirumaleswar Reddy
Filename        : draft-ietf-dots-requirements-13.txt
Pages           : 20
Date            : 2018-02-07

Abstract:
  This document defines the requirements for the Distributed Denial of
  Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
  coordinated response to DDoS attacks.