Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Fri, 07 February 2020 01:22 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B112011D; Thu, 6 Feb 2020 17:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2tQNuqeAYKd; Thu, 6 Feb 2020 17:22:36 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1FD12013B; Thu, 6 Feb 2020 17:22:35 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0171MTZs024446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Feb 2020 20:22:31 -0500
Date: Thu, 06 Feb 2020 17:22:28 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: The IESG <iesg@ietf.org>, Roman Danyliw <rdd@cert.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "valery@smyslov.net" <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>, "draft-ietf-dots-architecture@ietf.org" <draft-ietf-dots-architecture@ietf.org>
Message-ID: <20200207012228.GK14382@kduck.mit.edu>
References: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> <CY4PR1601MB12541179F49E2CFD70E29CC9EA1D0@CY4PR1601MB1254.namprd16.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CY4PR1601MB12541179F49E2CFD70E29CC9EA1D0@CY4PR1601MB1254.namprd16.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/eEoyOrlm-GfgRYoaVpANxArpmH0>
Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 07 Feb 2020 01:22:40 -0000
Hi Tiru, Thanks for the updates; these all look good. -Ben On Thu, Feb 06, 2020 at 11:08:40AM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Please see inline > > > -----Original Message----- > > From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk via > > Datatracker > > Sent: Thursday, February 6, 2020 11:16 AM > > To: The IESG <iesg@ietf.org> > > Cc: Roman Danyliw <rdd@cert.org>; dots-chairs@ietf.org; > > valery@smyslov.net; dots@ietf.org; draft-ietf-dots-architecture@ietf.org > > Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: > > (with COMMENT) > > > > CAUTION: External email. Do not click links or open attachments unless you > > recognize the sender and know the content is safe. > > > > 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. > > Good catch, removed "ephemeral". > > > > > 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"? > > Yes, removed the last line. > > > > > 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. > > Fixed. > > > > > 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). > > Good point, updated text as follows: > > Typically there is a contractual Service Level Agreement (SLA) negotiated among > the DOTS client domain, the recursed domain and the recursing domain > to meet the privacy requirements of the DOTS client domain and authorization for the > recursing domain to request mitigation for the resources controlled by the DOTS client domain. > > > > > 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. > > Sure, updated. > > > > > 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. > > Done. > > > > > 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. > > Fixed. > > > > > 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. > > Okay. > > > > > 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. > > Thanks, updated. > > > > > 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. > > Added the following lines: > > DOTS agents MUST perform mutual authentication to ensure authenticity > of each other and DOTS servers MUST verify that the requesting DOTS > client is authorized to request mitigation for specific target > resources (see Section 2.2.2). > > An MITM attacker can intercept and drop packets, preventing the DOTS > peers from receiving some or all of the DOTS messages, automated > mitigation on loss of signal can be used as a countermeasure but with > risks discussed in Section 3.3.3. > > > > > 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 [...]"). > > Moved. > > > > > There's a stronger case that RFC 4786 should be normative, as we use a BCP > > 14 keyword allowing its deployment. > > Done. > > Cheers, > -Tiru > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >
- [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