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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 06 February 2020 09:12 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
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 AFDE1120013 for <dots@ietfa.amsl.com>; Thu, 6 Feb 2020 01:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
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 TWDBx4Z27XUP for <dots@ietfa.amsl.com>; Thu, 6 Feb 2020 01:12:53 -0800 (PST)
Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678DF12011E for <dots@ietf.org>; Thu, 6 Feb 2020 01:12:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580980372; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KewdSESqLYdkgOR6Vf+07Z0sfy4oshjvf66DOH5U9ao=; b=gSbxgn/Rgp0EOmOrZLFeYYVYqdrbydBS+2muHaAwMjM+dPtN6MfuYgf7M39tIp26PYT6dH CTbu9jaGi9zagIOTa/zRPg4XGPvyYkgFeArXXBfoAd864QMD2AiSS7I4Aj4/JtjfRWRSHp Id4I29SdKKcwcQA7mw3FhD5eACcgRpc=
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2106.outbound.protection.outlook.com [104.47.58.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-306-IQShl4gDMmu7DJ92Cc7uBg-1; Thu, 06 Feb 2020 04:12:46 -0500
Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1273.namprd16.prod.outlook.com (10.172.86.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Thu, 6 Feb 2020 09:12:44 +0000
Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::5465:6a91:941f:36e0]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::5465:6a91:941f:36e0%10]) with mapi id 15.20.2707.023; Thu, 6 Feb 2020 09:12:44 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: 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>
Thread-Topic: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT)
Thread-Index: AQHV3LC0tvXwmfcRCEKmrHAz1U5ZWKgNuRiAgAAnpVA=
Date: Thu, 06 Feb 2020 09:12:44 +0000
Message-ID: <DM5PR1601MB1259ABB9B398F1F3BBD0E4ADEA1D0@DM5PR1601MB1259.namprd16.prod.outlook.com>
References: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303142F675@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93303142F675@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 922f160c-c4a6-4b10-f48e-08d7aae4b9ed
x-ms-traffictypediagnostic: DM5PR1601MB1273:
x-microsoft-antispam-prvs: <DM5PR1601MB1273A4991702B080E3A88C2EEA1D0@DM5PR1601MB1273.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(396003)(366004)(39860400002)(199004)(189003)(32952001)(4326008)(76116006)(7696005)(86362001)(8936002)(8676002)(81156014)(81166006)(9686003)(55016002)(478600001)(33656002)(66946007)(71200400001)(66574012)(54906003)(110136005)(316002)(66476007)(66446008)(2906002)(64756008)(66556008)(52536014)(5660300002)(966005)(6506007)(186003)(26005)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1273; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RTCS4kC9r6qXN0DCUD8NKaq0ChBEX5h4Vm5Zbzthd/X6v7skrdIs5WiQ64PpRU+k8Fz87OQplx7/FJkYucT7I+kDT0Cj+bVYkW1TC06IqK3nthhZqbRp332t9ogxVx4mjUL8EQmjwlfm7cLso3Dwvl+djKbu5hiZSheaUwfByymdFd3RMD3O/mqVQ0Eyc5PLARBJhM1j+EAf6to3pkBaJvkJ5CGvI7gvlfeX2Ipznn5RYTPa15RGKeJpSJOPYhE/lrdrIjJmw0lpdn33ZRDLtWuli7+AXiEpfoeceeyxcCOXx+CJPi4dMWi6y6A2yQnd3Ftisn3rLs388MJZgX0ygHSXqb4VzgKu7vA7vSuton+QNJTE0lauvxEbtP9ff4jiFw+Swv2XKprGp3M/3xgen7GQFzoVoGnhVZMG5railxGYQE4lCzkBLRUtUef5oCjSFqfJWeAJ2dD/Rd3vT2Tak2xHh0EJm8BSRte6jz4Ewmx8KLSJnfSUvkA5pgq1A9Crl3OONqY6KIFGDaYT6pjB9PhNUEVVXKTBW2LDlAUZcI+555HRe9mx3RErsEsEFhCUnvy0r+XjL9GOjbNXbdvkNEgOtYNJdeCcYc/3kU2K5rA=
x-ms-exchange-antispam-messagedata: KwJDJjRDSuTPjHllJXj9HpkqQtuX5jE0hJJWGJTjrDKpozWIiNCjSMvTcap4Qr05cABSQ2/2c1E4Zh6TX2lbIwkIeXQbXQvP8Bdv5NCpK/iwQXUcoGiimw9ysbdw7tPEPdqryaDT58l5djl9Z9zLFw==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: mcafee.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 922f160c-c4a6-4b10-f48e-08d7aae4b9ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 09:12:44.3660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eBCg7Zg56xtyvZnYXv7oG5FZijaVuakDcl28mRsUevINP2vDrUXFXFx3+c0QBDBdlj333MyzkeEv0hEgVK2sYSScXGi/8DGTQRRV2H1RMuM45BVv7HhTR9M1C7HxKKQs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1273
X-MC-Unique: IQShl4gDMmu7DJ92Cc7uBg-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: mcafee.com
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/N3IYx-Ku4gnDQ3ECABPtYkO8iLc>
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: Thu, 06 Feb 2020 09:12:58 -0000

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Thursday, February 6, 2020 12:17 PM
> To: Benjamin Kaduk <kaduk@mit.edu>; 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: Re: [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.
> 
> Hi Ben,
> 
> Please see one comment inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin Kaduk
> > via Datatracker Envoyé : jeudi 6 février 2020 06:46 À : The IESG Cc :
> > Roman Danyliw; dots-chairs@ietf.org; valery@smyslov.net;
> > dots@ietf.org; draft-ietf-dots-architecture@ietf.org
> > Objet : [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-
> > 16: (with COMMENT)
> >
> > 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"?
> 
> [Med] Good catch. I suggest to delete the last sentence of the above excerpt.

Works for me.

Cheers,
-Tiru

> (we don't specify how the client and server sides are glued but we do have
> feature to avoid loops when GWs are involved, enforce policies on a per
> client or domain basis, etc.).
> 
> >
> > 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 mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots