[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.
- [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-ar… Benjamin Kaduk via Datatracker
- Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dot… mohamed.boucadair
- Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dot… Konda, Tirumaleswar Reddy
- Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dot… Konda, Tirumaleswar Reddy
- Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dot… Benjamin Kaduk