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
>