Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 23 July 2019 06:41 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 07D381200DF for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 23:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, 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=neutral reason="invalid (public key: not available)" 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 EbpRCmRn-ga9 for <dots@ietfa.amsl.com>; Mon, 22 Jul 2019 23:41:21 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B1F1200D6 for <dots@ietf.org>; Mon, 22 Jul 2019 23:41:21 -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=1563863399; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: 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-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=+ aAdB2frP5xDfC1If4PM4+bmk9ltB9exfAUkBHHCi+ 4=; b=HfZkNl4qll8TqM/WpEj091XFcYCe7QMRzhIN3dsUCMMO otByfiUHVhhNqrcPMpvsJO50HRepys0h0pd87cOmlYiGnvkRQS p9sFJWtp5CsjA//Vp80TCf2wJoFX2zaVThaGX57mfo3OTk1Kli rZDnVc5Z1a3DHP208maHJS9t3mI=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-100-ZqeFwG_MON6e_qQ1Fr-nkA-1; Tue, 23 Jul 2019 02:41:15 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6c11_187b_e8d9633f_7233_487b_92a8_ed7849a536c6; Tue, 23 Jul 2019 00:29:58 -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; Tue, 23 Jul 2019 00:41:08 -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; Tue, 23 Jul 2019 00:41:08 -0600
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 00:41:07 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nPExUrXenK3osxQUd3kkK5cPcB7k2GUYXBnbQf35CD6vdzgw28u0BN91v58+Lb394vKXDMbigRu8hJ2AvJOgqyklq/K175S/At2g5LnGX0bpo/Cmpn4l6mJNRZIO7cGWiVa/ejpHWj71UcLqTurTk8ZNacu+pafAykEoHAL/guWUFGLcz393HODPwszRsUGGGrFGHe4MITA+nRczXs+Ypv3O1pe1D5XRt5F50pbIn/SVfgIcccAI62NB1bF06OgFBnMtxOw5zIcbGkkr78WYwDnige838DGiXf4AtSk89cLOAQh2cJlsTTt5V4YBR095ZyTN/QJ7OFK3fIr0u6i82Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+aAdB2frP5xDfC1If4PM4+bmk9ltB9exfAUkBHHCi+4=; b=gEsqQQFmeQ056xOMNXIJ59eGYIa+IdJdt88IZu/oUDA2RQPhH0hwQ243y0vyyrFM9WLZCdGltvriLw+k1QZ6YaxOtND+d++bDrZCtdI7uwuDKxAaV2nEIwkhrWMllQc1VoMEHO62reHYuFo3K7Rgu9OVmjH1ECdBWeCFDCJhZtfxYMURpiprdAcsolNq6qwNRDB8M1xBRa+SkIFvR8F2f0z3TVvH0HdAL7yYAj5lGu/uKzMVY0/GOsLqR6qHCPDb9dlfd3wWa1MR9ILfu/SWi9mKJ7/LyXZICoWjQM6ePRQwWT5VZsN54GbdeOJwbPHdE0XkO/hvls962ByKROey4Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from MWHPR16MB1711.namprd16.prod.outlook.com (10.174.162.17) by MWHPR16MB1487.namprd16.prod.outlook.com (10.175.4.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Tue, 23 Jul 2019 06:41:07 +0000
Received: from MWHPR16MB1711.namprd16.prod.outlook.com ([fe80::f42d:2a20:253f:a3da]) by MWHPR16MB1711.namprd16.prod.outlook.com ([fe80::f42d:2a20:253f:a3da%3]) with mapi id 15.20.2094.017; Tue, 23 Jul 2019 06:41:07 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Benjamin Kaduk <kaduk@mit.edu>, Valery Smyslov <valery@smyslov.net>
CC: "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
Thread-Index: AdU9/zWZw7DhsbF6RNCA2PYrEJMCCAAJ+IgAAFSa1gAAAzHm8ABkbgsAAAIWUGA=
Date: Tue, 23 Jul 2019 06:41:07 +0000
Message-ID: <MWHPR16MB17119026CED493164A85FDDBEAC70@MWHPR16MB1711.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00c201d53e27$194cfc20$4be6f460$@smyslov.net> <20190721040520.GS23137@kduck.mit.edu> <DM5PR16MB1705B068DCF6AB20658EF826EAC50@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E57CA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312E57CA@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.3.0.16
dlp-reaction: no-action
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 55da6190-b06c-4784-cd65-08d70f38bdd1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR16MB1487;
x-ms-traffictypediagnostic: MWHPR16MB1487:
x-ms-exchange-purlcount: 12
x-microsoft-antispam-prvs: <MWHPR16MB1487EE27DE9D0A0DF89A4F2DEAC70@MWHPR16MB1487.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0107098B6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(199004)(189003)(32952001)(13464003)(51444003)(110136005)(54906003)(2906002)(80792005)(14454004)(30864003)(2501003)(71190400001)(71200400001)(316002)(68736007)(8676002)(6116002)(3846002)(74316002)(7736002)(33656002)(7696005)(99286004)(66066001)(476003)(305945005)(11346002)(446003)(6506007)(53546011)(186003)(76176011)(486006)(55016002)(26005)(76116006)(6436002)(966005)(66476007)(52536014)(66446008)(25786009)(6246003)(66556008)(64756008)(2171002)(5660300002)(102836004)(229853002)(66946007)(6306002)(9686003)(53936002)(256004)(478600001)(5024004)(8936002)(14444005)(4326008)(81156014)(81166006)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1487; H:MWHPR16MB1711.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fozheYQhGdGKMCyyuO01E0osOpZXsl9ecl1f0cF93aGGrTiw4W8UzUPZXNNZgtmPzIcp0fQSquDxsY6PogLa6T7I3cna0SG+eq9u4LxPSqvRVIWkvm8df1upBCS0W989LHiS2RozHs5qgBpNx0tJO81vspMwzxStrkH03mMtOj1LFs5o5zNaf3GYTdtaA8zQMPDlq9ZXA2bVq5DLY9TKPmp7HsQkYRTRrHHf3I/KK48VCrAQTJYoCD+4RQbO6YCK/dFd5xDeplrnHNl2dy+WOnTEtkFWlg9XBT/p4vbWGHa4n30TMpKk3uONGHVj0nlfqRI2CSyJltNWWRv1fxHlakdNewSIBmMBpA1tRrwhEOhmv7M2oRlHxfxq7J9vLUoF02ow/+rICM1J+34dLCIddTYDU+81UoeTLcF5IBx0X7A=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 55da6190-b06c-4784-cd65-08d70f38bdd1
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 06:41:07.1231 (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: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1487
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 <6595> : inlines <7122> : streams <1828164> : uri <2871197>
X-MC-Unique: ZqeFwG_MON6e_qQ1Fr-nkA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/4I4nul_8umIzYz1PfrgU04dkivg>
Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
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: Tue, 23 Jul 2019 06:41:26 -0000

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> Sent: Tuesday, July 23, 2019 11:02 AM
> To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>; Benjamin Kaduk
> <kaduk@mit.edu>; Valery Smyslov <valery@smyslov.net>
> Cc: dots-chairs@ietf.org; dots@ietf.org
> Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> 
> 
> Hi Tiru, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > Envoyé : dimanche 21 juillet 2019 08:52 À : Benjamin Kaduk; Valery
> > Smyslov Cc : dots-chairs@ietf.org; BOUCADAIR Mohamed TGI/OLN;
> > dots@ietf.org Objet : RE: [Dots] Mirja's DISCUSS: Pending Point (AD
> > Help Needed)
> >
> > Hi Ben,
> >
> > There seems to several confusions regarding the heartbeat mechanism, I
> > will try to address all the comments/Discuss from you, Mirja and
> > Valery
> > below:
> >
> > [1] https://tools.ietf.org/html/rfc7252 is specific to UDP transport
> > (and does not deal with TCP). Please see the first paragraph in
> > https://tools.ietf.org/html/rfc7252#section-3. The message
> > transmission parameters (max-retransmit, ack-timeout and
> > ack-random-factor) and missing-hb-allowed discussed in DOTS signal
> > channel are specific to UDP transport.
> >
> > [2] CoAP over TCP is discussed in https://tools.ietf.org/html/rfc8323.
> > Please see the following differences b/w CoAP-over UDP and
> > CoAP-over-TCP relevant to our discussion:
> >
> > a) CoAP ping/pong defined in RFC7252 (uses Empty confirmable message
> > and
> > reset) will not work for CoAP-over-TCP. As per
> > https://tools.ietf.org/html/rfc8323#section-3.4, Empty messages (Code
> > 0.00) can always be sent and MUST be ignored by the recipient.
> > CoAP-over- TCP defines its own CoAP ping/pong for connection health
> > (see https://tools.ietf.org/html/rfc8323#section-5.4).
> >
> > b)Confirmable  and Non-confirmable message types are specific to UDP,
> > and are not supported in CoAP-over-TCP.
> >
> > [3] For TCP, if no ack is received for CoAP ping for specific
> > duration, TCP will close the connection, and the DOTS client will have
> > to re- establish the TCP connection. missing-hb-allowed is of no use
> > for TCP. We are all in the same page for TCP, and the draft can probably
> >       be updated for better clarity.
> >
> > [4] Now coming to UDP, please see my responses below:
> >
> > a) As you already know, DOTS signal channel uses heartbeat exchange in
> > both directions, and hence CoAP ping is sent by both DOTS client and
> > server.
> > b) CoAP ping is a confirmable message and hence the exponential
> > back-off with the default value of MAX_RETRANSMIT is 4
> > (https://tools.ietf.org/html/rfc7252#section-4.8).
> > c) CoAP ping is the only confirmable message exchanged during attack
> > (all other messages exchanged during an attack are non-confirmable).
> > The specification allows distinct values for message transmission
> > parameters and missing-hb-allowed to be used during attack and peace
> times.
> >
> > To handle congestion conditions during an attack, the specification
> > allows two options:
> >
> > [Option a] By setting MAX_RETRANSMIT to 1, exponential-back off is
> > avoided and missing-hb-allowed set to a very higher value (e.g. 20) to
> > handle congestion (high packet loss). The draft can be updated to
> > explain [Option a] in more detail.
> > [Option b] The CoAP MAX_RETRANSMIT default value of 4 is not modified,
> > and for example, missing-hb-allowed can be set to 5 (since 4 transmits
> > are not sufficient to detect the peer is not alive during congestion).
> >
> 
> [Med] We can add this text to illustrate the configuration flexibility:
> 
>    The specification allows for a flexible retry configuration when an
>    unreliable transport is in use.  For example, a server may be tweaked
>    to return a lower 'missing-hb-allowed' (e.g., 5) value but delegate
>    the retransmission to the underlying CoAP library by setting 'max-
>    retransmit' to a high value (e.g., 3).  The server may also be
>    configured to return a 'max-retransmit' set to '1' together with a
>    higher 'missing-hb-allowed' value (e.g., 15).

Looks good, Both these techniques are used by protocols today, I see DTLS heartbeat uses retransmit and exponential back-off (see https://tools.ietf.org/html/rfc6347#section-4.2.4.1) for liveness check and in STUN usage for consent freshness (https://tools.ietf.org/html/rfc7675) STUN binding requests are sent periodically. 

Cheers,
-Tiru

> 
> 
> > The Discuss from Mirja is not to rely on the CoAP ping/pong but to
> > define it in the DOTS layer itself (please see
> > https://mailarchive.ietf.org/arch/msg/dots/V6vv28zDpdY5eR_kaB7L-
> 60bhkk
> > ) and suggested to go with an alternate design using non-confirmable
> > messages. The alternate design won't work is our assessment, please
> > see my response
> >
> https://mailarchive.ietf.org/arch/msg/dots/QRMfsmhPTFksN6a_nBBKimVx-
> lM
> >
> > Cheers,
> > -Tiru
> >
> > > -----Original Message-----
> > > From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> > > Sent: Sunday, July 21, 2019 9:35 AM
> > > To: Valery Smyslov <valery@smyslov.net>
> > > Cc: dots-chairs@ietf.org; mohamed.boucadair@orange.com;
> > > dots@ietf.org
> > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > >
> > > 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.
> > >
> > > Hi Valery,
> > >
> > > On Fri, Jul 19, 2019 at 02:42:50PM +0300, Valery Smyslov wrote:
> > > > Hi Med,
> > > >
> > > > I believe Mirja's main point was that if you use liveness check
> > > > mechanism in the transport layer, then if it reports that liveness
> > check fails,
> > > then it _also_ closes the transport session.
> > > >
> > > > Quotes from her emails:
> > > > "Yes, as Coap Ping is used, the agent should not only conclude
> > > > that
> > the
> > > DOTS signal session is disconnected but also the Coap session and
> > > not
> > send
> > > any further Coap messages anymore."
> > > >
> > > > and
> > > >
> > > > "Actually to my understanding this will not work. Both TCP
> > > > heartbeat
> > and
> > > Coap Ping are transmitted reliably. If you don’t receive an ack for
> > these
> > > transmissions you are not able to send any additional messages and
> > > can
> > only
> > > close the connection."
> > > >
> > > > I'm not familiar with CoAP, but I suspect she's right about TCP -
> > > > if TCP layer itself doesn't receive ACK for the sent data after
> > > > several
> > > retransmissions, the connection is closed.
> > >
> > > Thanks for this crisp summary (and thanks Med for the detailed
> > > writeup
> > as
> > > well)!
> > >
> > > > As far as I understand the current draft allows underlying
> > > > liveness check to fail and has a parameter to restart this check
> > > > several times if this happens. It seems that a new transport
> > > > session will be created in this case (at least if TCP is used). In
> > > > my reading of the draft this seems not been assumed, it is assumed
> > > > that the session remains
> > the
> > > same. So, I think that main Mirja's concern is that it won't work
> > > (at
> > least with
> > > TCP).
> > >
> > > My sense is similar; if I could attempt to summarize Mirja's stance,
> > it's that
> > > we're invoking a transport-level feature that does its own
> > > retransmit
> > and
> > > backoff, but then if the transport comes back and says "the peer is
> > gone", we
> > > say "but we're under attack, so I don't believe you; try again".
> > > This kicks of another independent set of "retransmits" (I know it's
> > > not technically the right word) with a fresh exponential backoff.
> > > There's
> > two
> > > complaints about this: (1) we're changing the transport, since if
> > > the
> > transport
> > > concludes the peer is gone then the transport "normally" tears down
> > > the connection (*) entirely, and (2) the assembly of (exponential
> > > backoff
> > 1),
> > > (exponential backoff 2), (exponential backoff 2) is strange pacing,
> > > and
> > might
> > > be better served by a similar number of "retransmits" but with
> > > different pacing, since the long delay at the end of each backoff
> > > period is not
> > expected
> > > to add a huge amount of value in terms of letting congestion ease
> > > during attack time, and we would be just as well served by capping
> > > the delay between retransmits and having more retransmits.
> > >
> > > The asterisk on (1) is of course because, as is noted later in the
> > thread, only
> > > TCP tears down the association when it concludes the peer is gone
> > (assuming
> > > I'm reading the right parts of 7252).  Quoting 7252:
> > >
> > >                                                         If the
> > >    retransmission counter reaches MAX_RETRANSMIT on a timeout, or if
> the
> > >    endpoint receives a Reset message, then the attempt to transmit the
> > >    message is canceled and the application process informed of failure.
> > >    On the other hand, if the endpoint receives an acknowledgement in
> > >    time, transmission is considered successful.
> > >
> > > So all CoAP does is to tell the application "that request didn't
> > > work",
> > but CoAP
> > > is happy to try additional requests on the connection; the teardown
> > logic is
> > > indeed left up to the application.
> > >
> > > I'm not sure that we've seen much discussion about (2), though
> > > (sorry if
> > I
> > > missed it) -- why is the repeated backoff-and-restart the right
> > > pacing
> > for this
> > > purpose?
> > >
> > > -Ben
> > >
> > > > I didn't participate in the WG discussion on this, so I don't know
> > > > what was discussed regarding this issue. If it was discussed and
> > > > the WG has come to conclusion that this is not an issue, then I
> > > > believe more text should be added to the draft so, that people
> > > > like Mirja, who
> > > didn't participate in the discussion, don't have any concerns while
> > reading the
> > > draft.
> > > >
> > > > Regards,
> > > > Valery.
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: mohamed.boucadair@orange.com
> > > > > <mohamed.boucadair@orange.com>
> > > > > Sent: Friday, July 19, 2019 9:57 AM
> > > > > To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>; dots-
> > > > > chairs@ietf.org; dots@ietf.org
> > > > > Subject: Mirja's DISCUSS: Pending Point (AD Help Needed)
> > > > >
> > > > > Hi Ben, chairs, all,
> > > > >
> > > > > (restricting the discussion to the AD/chairs/WG)
> > > > >
> > > > > * Status:
> > > > >
> > > > > All DISCUSS points from Mirja's review were fixed, except the
> > > > > one discussed in this message.
> > > > >
> > > > > * Pending Point:
> > > > >
> > > > > Rather than going into much details, I consider the following as
> > > > > the summary of the remaining DISCUSS point from Mirja:
> > > > >
> > > > > > I believe there are flaws in the design. First it’s a layer
> > > > > > violation, but if more an idealistic concern but usually
> > > > > > designing in layers is a good approach. But more importantly,
> > > > > > you end up with un-frequent messages which may still terminate
> > > > > > the connection at some point, while what you want is to simply
> > > > > > send messages frequently in an unreliable fashion but a low
> > > > > > rate until the
> > attack is over.
> > > > >
> > > > > * Discussion:
> > > > >
> > > > > (1) First of all, let's remind that RFC7252 does not define how
> > > > > CoAP ping must be used. It does only say:
> > > > >
> > > > > ==
> > > > >       Provoking a Reset
> > > > >       message (e.g., by sending an Empty Confirmable message) is
> > also
> > > > >       useful as an inexpensive check of the liveness of an endpoint
> > > > >       ("CoAP ping").
> > > > > ==
> > > > >
> > > > > How the liveness is assessed is left to applications. So, there
> > > > > is
> > > > > ** no layer violation **.
> > > > >
> > > > > (2) What we need isn't (text from Mirja):
> > > > >
> > > > > > to simply send messages frequently in an unreliable fashion
> > > > > > but a low rate until the attack is over "
> > > > >
> > > > > It is actually the other way around. The spec says:
> > > > >
> > > > >   "... This is particularly useful for DOTS
> > > > >    servers that might want to reduce heartbeat frequency or cease
> > > > >    heartbeat exchanges when an active DOTS client has not requested
> > > > >    mitigation."
> > > > >
> > > > > What we want can be formalized as:
> > > > >  - Taking into account DDoS traffic conditions, a check to
> > > > > assess the liveness of the peer DOTS agent + maintain NAT/FW
> > > > > state on on-
> > path
> > > devices.
> > > > >
> > > > > An much more elaborated version is documented in SIG-004 of RFC
> > 8612.
> > > > >
> > > > > * My analysis:
> > > > >
> > > > > - The intended functionality is naturally provided by existing
> > > > > CoAP
> > > messages.
> > > > > - Informed WG decision: The WG spent a lot of cycles when
> > > > > specifying the current behavior to be meet the requirements set in
> RFC8612.
> > > > > - Why not an alternative design: We can always define messages
> > > > > with duplicated functionality, but that is not a good design
> > > > > approach especially when there is no evident benefit.
> > > > > - The specification is not broken: it was implemented and tested.
> > > > >
> > > > > And a logistic comment: this issue fits IMHO under the
> > > > > non-discuss criteria in
> > > > > https://www.ietf.org/blog/discuss-criteria-iesg-
> > review/#stand-
> > > undisc.
> > > > >
> > > > > * What's Next?
> > > > >
> > > > > As an editor, I don't think a change is needed but I'd like to
> > > > > hear from Ben, chairs, and the WG.
> > > > >
> > > > > Please share your thoughts and whether you agree/disagree with
> > > > > the above analysis.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > >
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > Dots@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dots