Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 08 May 2019 08:14 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 6E446120041; Wed, 8 May 2019 01:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 71s-ISmTXueW; Wed, 8 May 2019 01:14:05 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 E6EE112002F; Wed, 8 May 2019 01:14:04 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1557302832; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=a mplYLYalYuQOzpyXSI/VL/0Ehjy46C6bjruS9UdfN 4=; b=HdrySD1JIj6MALqvcOAyvOgS8bQ0JkJ2wgmDe1vho2yp XzYvAHDrEwqueltdpQC0ILYZY4MHBX74q6BN0zzQjNCqgkJr+6 PokGa4lyUyPsvU2osrkToWb6fY+sR0eWpZ17vOphjdLETWAzVX Wzgb93nd+YP9cVJVorhwzeGTILM=
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1780_52da_38547fb5_bde3_498b_8518_369abb70db81; Wed, 08 May 2019 02:07:10 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 02:13:24 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 8 May 2019 02:13:24 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 02:13:23 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2661.namprd16.prod.outlook.com (20.177.224.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.14; Wed, 8 May 2019 08:13:22 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379%2]) with mapi id 15.20.1856.012; Wed, 8 May 2019 08:13:22 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Adam Roach <adam@nostrum.com>, "dots@ietf.org" <dots@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, "The IESG" <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
Thread-Index: AQHVAMcyf3g1859iiUOeeJIx2grdhaZeVjAAgAEudbCAAFuxAIAA/8MA
Date: Wed, 8 May 2019 08:13:22 +0000
Message-ID: <BYAPR16MB27905133B2D6BA42DD9151C9EA320@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155677323500.2690.13635225040710635105.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68BB3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190506165056.GI19509@kduck.mit.edu> <BYAPR16MB2790F2A13E90ED0A4DBDC0FAEA310@BYAPR16MB2790.namprd16.prod.outlook.com> <20190507162137.GG19509@kduck.mit.edu>
In-Reply-To: <20190507162137.GG19509@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7b03eaa8-41bc-456c-4e45-08d6d38d09e8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2661;
x-ms-traffictypediagnostic: BYAPR16MB2661:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR16MB26618758EBB0AB780A1713DFEA320@BYAPR16MB2661.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(346002)(366004)(396003)(32952001)(13464003)(199004)(189003)(51914003)(6116002)(966005)(86362001)(26005)(68736007)(81156014)(81166006)(6246003)(8676002)(2171002)(8936002)(186003)(229853002)(80792005)(55016002)(6916009)(53936002)(3846002)(25786009)(4326008)(478600001)(14454004)(33656002)(72206003)(2906002)(74316002)(6306002)(316002)(9686003)(6506007)(53546011)(6436002)(71190400001)(66946007)(73956011)(76116006)(102836004)(66066001)(99286004)(7696005)(76176011)(446003)(11346002)(54906003)(5660300002)(476003)(66556008)(256004)(14444005)(5024004)(52536014)(71200400001)(7736002)(66446008)(66476007)(64756008)(305945005)(486006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2661; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3dqhCAjB4+0rYTFdSADVvGYk/YvRgV53EUL2C6plHk87YrshK5eyeidhJ5m4LQpJxF0Tsfse0AOT8g+bs0APbJS/MBzMGX/Sfb0DCwWy3njHqj49CkveNGhXxFVWGu2ep3x7xbFYOTbeSyGoMuMnsDqH0cCerA5BPngqAWf7EGaA6c+W5qEn8yadlM4oRwzVPlbq1Irv5kIRskuEGpHfyzH7EV/Llwhvcdzxr3eWFM4Rduw6uWM3AnnVGMBuEpzRPpw/mT8sO0Z9MuB1MOvhxxrx/Qg5cS98Ln2eHUk0AStV/nGBKJmehIagFVa/IFBJLa2mTLpFbPfbJCihv+aRXr7Z1a7JE+4D6P6ZZ3aGmQ/BrSoc+/4un/Esb8pw82z71qQZuiq592So3eGfg5XdsLeTHLCToPRTrvEdL9uKH/w=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b03eaa8-41bc-456c-4e45-08d6d38d09e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 08:13:22.8271 (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-Transport-CrossTenantHeadersStamped: BYAPR16MB2661
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6541> : inlines <7074> : streams <1820910> : uri <2841873>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/uw14MKsHWdUYSwbQ7vYQdPnQTJA>
Subject: Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and 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: Wed, 08 May 2019 08:14:08 -0000

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: Tuesday, May 7, 2019 9:52 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> Cc: mohamed.boucadair@orange.com; draft-ietf-dots-signal-
> channel@ietf.org; Adam Roach <adam@nostrum.com>om>; dots@ietf.org; Liang
> Xia <frank.xialiang@huawei.com>om>; The IESG <iesg@ietf.org>rg>; dots-
> chairs@ietf.org
> Subject: Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> 
> 
> On Tue, May 07, 2019 at 12:42:45PM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > > -----Original Message-----
> > > From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> > > Sent: Monday, May 6, 2019 10:21 PM
> > > To: mohamed.boucadair@orange.com
> > > Cc: draft-ietf-dots-signal-channel@ietf.org; Adam Roach
> > > <adam@nostrum.com>om>; dots@ietf.org; Liang Xia
> > > <frank.xialiang@huawei.com>om>; The IESG <iesg@ietf.org>rg>; dots-
> > > chairs@ietf.org
> > > Subject: Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-
> channel-31:
> > > (with DISCUSS and COMMENT)
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > On Thu, May 02, 2019 at 09:12:01AM +0000,
> > > mohamed.boucadair@orange.com wrote:
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Adam Roach via Datatracker [mailto:noreply@ietf.org] Envoyé :
> > > > > jeudi 2 mai 2019 07:01 À : The IESG Cc :
> > > > > draft-ietf-dots-signal-channel@ietf.org; Liang Xia; dots-
> > > > > chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org Objet :
> > > > > Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with
> > > > > DISCUSS and COMMENT)
> > > > >
> > > > > Adam Roach has entered the following ballot position for
> > > > > draft-ietf-dots-signal-channel-31: Discuss
> > > > >
> > > > > 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-signal-channel/
> > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > DISCUSS:
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > >
> > > > > Thanks for all the work everyone put into this document. I think
> > > > > it's great to have a solution defined for automating these kinds
> > > > > of operations, and look forward to widespread deployment of this
> > > > > technology. I do have a small number of comments that I think we
> > > > > need to close on prior to publication, and a handful of other
> > > > > suggestions of varying (but lesser) importance.
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > -------
> > > > >
> > > > > This is a discuss because the current document attempts to
> > > > > override normative language in an external document.
> > > > >
> > > > > §4.3:
> > > > >
> > > > > >  In reference to Figure 4, the DOTS client sends two TCP SYNs
> > > > > > and two  DTLS ClientHello messages at the same time over IPv6 and
> IPv4.
> > > > >
> > > > > This is problematic for the reason described in RFC 8305 §5 ("In
> > > > > order to avoid unreasonable network load, connection attempts
> > > > > SHOULD NOT be made simultaneously").
> > > > >
> > > >
> > > > [Med] I would agree with you if the text in 8305 is using MUST NOT.
> > > >
> > > > It is completely fine to send requests sequentially when not
> > > > attack is
> > > ongoing, but if a connection is to be established during attack time
> > > (e.g., redirect), sending the requests simultaneously would be
> > > appropriate so that an attack mitigation is placed as ASAP.
> > >
> > > Violating a SHOULD NOT still requires some analysis and justification.
> > > Blatantly violating it (i.e., a 4x factor rather than 2x) probably
> > > requires a stronger justification still.
> >
> > My understanding is RFC 8305 suggests SHOULD NOT because it will be
> used by endpoints, and if every endpoint initiates connection attempts
> simultaneously to every domain the end user visits, it would introduce
> network load. However for DOTS signal channel, connection attempts will
> only be initiated by DOTS client (typically co-located on the network security
> services like DDoS mitigator, firewall, IPS). I don't think unreasonable
> network load would be introduced by a really small number of DOTS clients
> making connection attempts to the DOTS server.
> 
> Perhaps, but if everyone thinks that their protocol is a "special exception",
> we still end up in a bad place.  

I don't get the problem. For example, https://tools.ietf.org/html/rfc8421 does not use the timing recommendations in RFC8305, instead ICE pacing is used (default value of Ta is 5ms).

> So I'd like to hear more from Adam/Mirja/etc.
> on this.  (Well, or maybe on Suresh's ballot thread, where Med already put
> some good discussion in.)
> 
> > >
> > > >
> > > > > To be clear, my discuss is only on the fact that this document
> > > > > violates a normative statement in RFC 8305. The following
> > > > > comments are merely my thoughts on the best way to resolve this
> issue.
> > > > >
> > > > > It's also worth noting that RFC 8305 is geared towards getting
> > > > > users the fastest possible response to a user action, while the
> > > > > text in DOTS implies that the selection of the "most preferred"
> > > > > connection is significantly more important
> > > >
> > > > [Med] Yes.
> > > >
> > > > > (e.g., it talks about migrating from TCP to UDP, and performing
> > > > > periodic checks to enable such a migration). This factor,
> > > > > combined with the fact that this is not a transaction that
> > > > > involves user interactivity requirements, would seem to
> > > > > increase, rather than decrease, the desire to space out checks
> > > > > across the various transport/address-family pairs.
> > > > >
> > > > > My strong recommendation would be remove the specific
> > > > > description of
> > > >
> > > > [Med] This is not that straightforward because of specifics to the
> > > > DOTS case,
> > > e.g., probing, caching, no need to cancel other connections if a
> > > first one wins, etc.
> > > >
> > > > > happy-eyeballs-like behavior from this document, and to instead
> > > > > defer all such specification to the text in RFC 8305. I would
> > > > > further recommend specification of a "Connection Attempt Delay"
> > > > > (as that term is defined in RFC 8305) that is substantially
> > > > > larger than those used for interactive connections: something on
> > > > > the order of 2 to 5 seconds would be my suggestion.
> > > > >
> > > > > Of course, be sure to adjust the example to match the specified
> handling.
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > -------
> > > > >
> > > > > This is a discuss because it impacts interoperability.
> > > > >
> > > > > §4.4.1:
> > > > >
> > > > > >  target-uri:   A list of Uniform Resource Identifiers (URIs) [RFC3986]
> > > > > >     identifying resources under attack.
> > > > >
> > > > > This definition needs to be clearer about what parts of the URI
> > > > > are used for what purposes.
> > > >
> > > > [Med] The text does not define any restriction. All parts may be
> included..
> > > >
> > > > The text focuses on the host part as this is sensitive:
> > > >
> > > >       The same validation checks used for 'target-fqdn' MUST be followed
> > > >       by DOTS servers to validate a target URI.
> > > >
> > > > How other parts are used is trivial, IMO.
> > >
> > > If we call out one part for special handling, we should at least
> > > mention that the other parts can still be used.
> >
> > We can add the following the line:
> > The IP addresses to which DNS domain name portion of URI resolves
> represent the scope of the mitigation. The mitigation technique used by the
> DDoS mitigation provider based on the URI is implementation specific (e.g.
> Puzzles, Reverse Turning tests etc.).
> 
> I don't think this is really helping.  Recall that the URI has five
> components: scheme, authority (user/host/port), path, query, and fragment.
> The current (-31) text is talking about the host part of the authority
> component, but I think Adam is noting that the scheme (both in the form of
> the target-protocol and the scheme's default port), and the port part of the
> authority component, are also potentially of use in identifying the attack
> target we're trying to mitigate.  In this sense, we could consider target-uri as
> a shorthand for all three of target-protocol, target-fqdn, and target-port-
> range, but since the -31 text only makes a connection to target-fqdn, the
> reader is left unclear about whether we should or should not be able to use
> target-uri to cover the target-protocol and target-port-range attributes.

Thanks for the clarification, will update text as follows:

The IP addresses to which DNS domain name portion of URI resolves represent the 'target-prefix', URI scheme represents the 'target-protocol', the port subcomponent of authority component represents the 'target-port'. If the optional port 
information is not present in the authority component,  the default port defined for the URI scheme represents the 'target-port'.

Cheers,
-Tiru

> 
> -Ben