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

From: [email-masked]
Date: Thu, 25 Jan 2018 12:58:05 -0800

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-12.txt
	Pages           : 20
	Date            : 2018-01-25

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

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-requirements-12
https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-12

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: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 25 Jan 2018 21:01:21 +0000

This revision addresses recent feedback from Tiru and Med on the -11 draft. At this point I do not see agreement on either point Jon raised following publication of the previous revision.

andrew

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: [Dots] I-D Action: draft-ietf-dots-requirements-12.txt
Date: January 25, 2018 at 3:58:05 PM EST
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 26 Jan 2018 15:28:43 -0000

Hi Andrew / WG,

Signal/Data path loop detection protection.

I can think of 2 scenarios where hop-limit mechanism can prevent an infinite
loop taking down DOTS clients / servers.  They are triggered by
misconfiguration, but the misconfiguration may not be detected for some time
- until another event occurs.

I believe that it would be prudent to have this sort of loop detection
protection mechanism in place when DOTS gateways are deployed.  Med's
suggested text works for me.

Background to the configuration set up for the scenarios

The DOTS server component of the GW has all DOTS client identities (e.g.
DNS-ID) configured, so they not only mutually authenticate, but are
authorized to be valid DOTS clients.  In error, the client identity of the
DOTS client component of the GW is also included in the DOTS server list
(i.e. someone simply did a push of all the valid client identities to the
server component).  The issuer of all the certificates/private keys is the
same for the DOTS gateway and the upstream DOTS server, so any client cert
will mutually authenticate with a server cert.

Under normal operations, this 'push all client identities' error would not
be spotted as it was not causing any issues, which could be the case for
months/years.

Scenario 1

DNS poisoning.  I know DNSSEC is recommended in the drafts, but it is not
universally adopted.  Someone poisons (or is misconfigured in error) the
upstream DOTS server FQDN so that it points back to the IP address of the
client-facing-side of the DOTS gateway.  You then have a forwarding loop. 

Scenario 2

The DOTS gateway server-facing-side receives a server redirection (SIG-004).
There was an error in the redirected FQDN / IP address, and the DOTS gateway
server-facing-side is redirected to the DOTS gateway client-facing-side IP.
You then have a forwarding loop.

It could be said that you should detect that the DOTS gateway is sending to
itself by checking src/dest IPs, but if there is a chain of DOTS gateways,
the end of the chain could in error loop back to the beginning of the chain
which is more difficult to detect.

There potentially are other loop scenarios that have not yet been
discovered.

Should loop detection be included (for both signal and data channels) -
comments?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Mortensen, Andrew
Sent: 25 January 2018 21:01
To: [email-masked]
Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-12.txt

This revision addresses recent feedback from Tiru and Med on the -11 draft.
At this point I do not see agreement on either point Jon raised following
publication of the previous revision. 

andrew

Begin forwarded message:

From: [email-masked]

To: <[email-masked]>

Cc: [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-12.txt
Pages           : 20
Date            : 2018-01-25

Abstract: