[Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 06 February 2020 05:45 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F78120120; Wed, 5 Feb 2020 21:45:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw <rdd@cert.org>, Valery Smyslov <valery@smyslov.net>, dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com>
Date: Wed, 05 Feb 2020 21:45:46 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ZVjHZTUgTa8gGDjEFQCYMiUiJ4E>
Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 05:45:47 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dots-architecture-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well-written document!  It's a great high-level summary of
DOTS and I just have some fairly minor comments.

There might be a bit of mismatch between describing the signal channel
session as associated with "an ephemeral security association" in Section
3.1 and as "expected to be long-lived" in Section 3.2.4.1.

Section 2.2.3

   The DOTS gateway MUST perform full stack DOTS session termination and
   reorigination between its client and server side.  The details of how
   this is achieved are implementation specific.  The DOTS protocol does
   not include any special features related to DOTS gateways, and hence
   from a DOTS perspective, whenever a DOTS gateway is present, the DOTS
   session simply terminates/originates there.

Does the 'cdid' count as a "special feature"?

Section 2.3.1

   An example is a DOTS gateway at the network client's side, and
   another one at the server side.  The first gateway can be located at
   a CPE to aggregate requests from multiple DOTS clients enabled in an

nit: "CPE" does not appear as "well known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and should be
expanded on first use.

Section 3.2.3

We could mention that the recursing gateway (e.g., Cn in Figure 12) must
still be authorized to request mitigation for the resources (also)
controlled by client Cc (though perhaps the closing discussion about there
typically being a SLA among client, recursed, and recursing domain suffices).

Section 3.2.4.1

   DOTS client to initialize a new DOTS session.  This challenge might
   in part be mitigated by use of resumption via a PSK in TLS 1.3
   [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in
   TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must
   be available to all DOTS servers sharing the anycast Service Address
   in that case.

"which has operational challenges of its own", perhaps.

   session may involve diverting traffic to a scrubbing center.  If the
   DOTS session flaps due to anycast changes as described above,
   mitigation may also flap as the DOTS servers sharing the anycast DOTS
   service address toggles mitigation on detecting DOTS session loss,
   depending on whether the client has configured mitigation on loss of
   signal.

I am not sure if we've mentioned configuring mitigation on loss of signal,
yet.  A forward reference to Section 3.3.3 might help.

Section 3.2.5

   Network address translators (NATs) are expected to be a common
   feature of DOTS deployments.  The Middlebox Traversal Guidelines in
   [RFC8085] include general NAT considerations for DOTS deployments
   when the signal channel is established over UDP.

nit: the guidelines in 8085 are not specifically about DOTS deployments, so
probably we should say "that are applicable to" DOTS deployments.

Section 3.2.5.1

   request accurate mitigation scopes.  To that aim, the DOTS client can
   rely on mechanisms, such as [RFC8512] to retrieve static explicit
   mappings.  This document does not prescribe the method by which

nit: no comma.

Section 3.3.3

   The impact of mitigating due to loss of signal in either direction
   must be considered carefully before enabling it.  Signal loss is not
   caused by links congested with attack traffic alone, and as such
   mitigation requests triggered by signal channel degradation in either

nit: I think this could be parsed as "links are congested by attack traffic
and other traffic", whereas we intend to say that "attack traffic is not the
only possible cause of link congestion".  Perhaps "Attack traffic congesting
links is not the only reason why signal could be lost" is more clear.

Section 5

   DOTS is at risk from three primary attack vectors: agent
   impersonation, traffic injection and signal blocking.  These vectors

We seem to only partially discuss countermeasures for these attacks in the
rest of the section; one piece that seems noteworthy in its absence is the
requirement (already described in the body text) to authenticate the peer
and perform authorization checks on client requests.  Mitigating against
signal blocking is in general hard, but we could consider mentioning again
that the automated mitigation on loss of signal discussed in Section 3.3.3
is an option, albeit one with risks of its own.

Section 8.2

One could perhaps argue that RFC 4033 and RFC 6887 should be normative
("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]").

There's a stronger case that RFC 4786 should be normative, as we use a BCP
14 keyword allowing its deployment.