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
- [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