Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Mon, 15 July 2019 12:42 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 BF4F812008B for <dots@ietfa.amsl.com>; Mon, 15 Jul 2019 05:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 d6FGHnfm7ZJa for <dots@ietfa.amsl.com>; Mon, 15 Jul 2019 05:42:07 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.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 793A01200F4 for <dots@ietf.org>; Mon, 15 Jul 2019 05:42:07 -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=1563193812; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To: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-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=k8Yqv5GXkV0aSbKGXTPpAgx8N3+P/4T/olYaXk kghvM=; b=pt4ACq7C8OpuYzZ9J4HfjLpvbNrPiBVwamUYBL/I f2mEEvYG6sAr9IoIh0SzXQAxoV03B84rTVMF5gNlqhiIcP8lsD 3GYvNPJSMU7bU3OAje97R63StKO5SOs178vsVtAi+k5j9PUdYT e9xp+1sibrwpVY58h3a69S42fCkbenE=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-48-lElpyg_nPQukTOuOczuCaQ-1; Mon, 15 Jul 2019 08:41:00 -0400
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6804_0316_1e6c9ce0_a03c_4cb2_aef3_1ed5cc671b53; Mon, 15 Jul 2019 06:30:11 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 06:40:55 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 15 Jul 2019 06:40:55 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 06:40:54 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YoDrahQE2IEc4Uyd+m3DcrUQJO1DwnmJeJPfjVIHLDoK91eqju5Ts5SCcq3cq07PgCVx4IZybNpsJqYmJHGhYmvrn/3gJBIF8mcFftHYqbXIxTt5Dt4bYACvWo3fVbXVgoD64Rq/m+hg4fMDhjV5HyQovdSVRVXHtFj/EYihqwZZnR9Ki61MSuZqg/F3MhROUB0SoiCH7jn6HkuWqi9dqO57DmXmJsWDWuXLVhMpt/vf03F2nstrvhr6TedvR806IMzTINSwk8p32zK7P07aNkbmVrCUzLJ4nzzaXXs7Hex3kI9V1gwxQ3Y3Vj8izfAkLxRd7hjNUJx0KOWANySVSQ==
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=k8Yqv5GXkV0aSbKGXTPpAgx8N3+P/4T/olYaXkkghvM=; b=UJGeDgW6m7e23M2pqIwYQw4bQH0ge2hRQTrJByEtLUu5pJIegyjAJh+kMF0XxHv72Vl1L1FCUAPlUD3WUB0earBB/8scCxVyBjKBK+QqbWud7+XRVY9LmfvdBJqAckSnGVP+70nCa0CLuL63m9hNvSCS5+UrOf6HRrq3RzdrNKsOBdEIlIRwxjyZN5noOk726jhl6WAGzhj0Wj0Vy/2xlUQpXGrX17kmVtCgI7cvHvEyqKD2hhSQjGd9o0P2fFNv4NZv7jGrEPd1DFlR4jXexkkoEhFBO/QX112mvddwllllH8IacLIUya7Neb6A/j06vIaG8maTtLizSOUYUQc+Yw==
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 DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB0028.namprd16.prod.outlook.com (10.172.87.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 12:40:54 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 12:40:54 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, 'Mirja Kuehlewind' <ietf@kuehlewind.net>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, 'The IESG' <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "'Benjamin Kaduk'" <kaduk@mit.edu>
Thread-Topic: =?utf-8?B?W0RvdHNdICBCZWhhdmlvciB3aGVuIGtlZXAtYWxpdmVzIGZhaWwgKFJFOiAg?= =?utf-8?B?IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-channel-31:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHVMahPL0rGRiTdj0OvBFGcFsXbOqa5IZiAgAAijoCAEmzegA==
Date: Mon, 15 Jul 2019 12:40:53 +0000
Message-ID: <DM5PR16MB170501C0B9CF2A8BB2177C78EACF0@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302EAB2ABA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F0E0BDCF-9D56-4547-86E3-FEBABD77A6EB@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB2CC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <AA91C255-9CF2-4016-8538-E634C09C27EE@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB2F77@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <06e901d531a8$38f38d90$aadaa8b0$@jpshallow.com> <2B716406-0554-4DC6-B6F9-057A9D4D85C4@kuehlewind.net> <072901d531d3$bdd39c00$397ad400$@jpshallow.com>
In-Reply-To: <072901d531d3$bdd39c00$397ad400$@jpshallow.com>
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: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13179298-7f64-4f77-6951-08d70921ad38
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB0028;
x-ms-traffictypediagnostic: DM5PR16MB0028:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM5PR16MB0028183D4CB93254B90E3110EACF0@DM5PR16MB0028.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(76274002)(32952001)(189003)(199004)(13464003)(30864003)(99286004)(224303003)(966005)(186003)(2906002)(446003)(476003)(11346002)(71200400001)(71190400001)(26005)(76116006)(52536014)(5660300002)(66446008)(64756008)(66556008)(66476007)(66946007)(14454004)(66574012)(76176011)(102836004)(53546011)(6506007)(7696005)(74316002)(86362001)(305945005)(25786009)(7736002)(81156014)(81166006)(8936002)(68736007)(2501003)(229853002)(2201001)(5024004)(316002)(110136005)(66066001)(486006)(33656002)(14444005)(256004)(478600001)(53946003)(6306002)(53936002)(9686003)(6436002)(55016002)(80792005)(6116002)(6246003)(2171002)(3846002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB0028; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AQyItyLWR0piI0w/XU2D884rhzBeaqmq7kTtKc8AiW8KGQIGQx8VEldLqmoorB7Xj7EcGeg9YHJS9jFAptpRrTen7trYrWRJBQCaQZV5irEtdFQhmZT6rgDEnlGHRV6OeRIgJIwVUjM2XzD7697eNL8Z08/rKLSoVwMXSrEEiUAcB90/gzuaBCR7+lSlZgkKP2E6phCCgB5LR/ChzeSGZIQkTCSFqSy/umZlcd0ToBWlkSpM1rYbDoNBstyrri53/Rk3GQmmZbyT7uMnQYGbghMxRe2sS4NBAdBQwiLDA2FNeOzHp5VTozC8w3ulWqDjOAv5ffn/4BD3EJwB6gSBMSW2GO1TrdWd7MprZmx9yd2zUo6MAxjhFUIgoTg+SOXCUVkAGVu0xR1rQhgf6Z1eSZjIMib2An9buql87NmEfHs=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 13179298-7f64-4f77-6951-08d70921ad38
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 12:40:53.9019 (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: DM5PR16MB0028
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.2
X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827424> : uri <2867826>
X-MC-Unique: lElpyg_nPQukTOuOczuCaQ-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/5hs5Fl1vxqvJ1CPoXWlgzrAQ3nQ>
Subject: Re: [Dots] =?utf-8?q?Behavior_when_keep-alives_fail_=28RE=3A___Mirja?= =?utf-8?q?_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dots-signal-channel-3?= =?utf-8?q?1=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Mon, 15 Jul 2019 12:42:11 -0000

Hi Mirja,

We have updated the draft to address your Discuss and comments (https://tools.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-35.txt).  Please have a look and approve the draft. 

Best Regards,
-Tiru

> -----Original Message-----
> From: Jon Shallow <supjps-ietf@jpshallow.com>;
> Sent: Thursday, July 4, 2019 12:46 AM
> To: mohamed.boucadair@orange.com; 'Mirja Kuehlewind'
> <ietf@kuehlewind.net>;; draft-ietf-dots-signal-channel@ietf.org; Konda,
> Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;;
> dots@ietf.org; frank.xialiang@huawei.com; 'The IESG' <iesg@ietf.org>;; dots-
> chairs@ietf.org; 'Benjamin Kaduk' <kaduk@mit.edu>;
> Subject: RE: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind'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.
> 
> Hi Mirja,
> 
> In one sense Med has answered your queries below separately, but I will try
> to expand on them from my implementation perspective.
> 
> Regards
> 
> Jon
> 
> > -----Original Message-----
> > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Mirja
> > Kuehlewind
> > Sent: 03 July 2019 18:12
> > To: Jon Shallow
> > Cc: draft-ietf-dots-signal-channel@ietf.org; Konda, Tirumaleswar
> > Reddy; dots@ietf.org; frank.xialiang@huawei.com; The IESG;
> > dots-chairs@ietf.org; mohamed.boucadair@orange.com; Benjamin Kaduk
> > Subject: Re: [Dots] Behavior when keep-alives fail (RE: Mirja
> > Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with
> > DISCUSS and COMMENT)
> >
> > Hi Jon,
> >
> > Thanks for extended explanation. Please see questions inline.c
> >
> > > On 3. Jul 2019, at 16:04, Jon Shallow <supjps-ietf@jpshallow.com>; wrote:
> > >
> > > Hi Mirja,
> > >
> > > As an implementer of DOTS I have the following comments to make to
> > > try
> > and help understand what is going on with the Heartbeats
> > >
> > > In the peace time scenario, it is assumed that the heartbeats
> > > function
> > through the network in both directions and that it is possible to
> > disable one or both of the heartbeat directions.
> > >
> > > Heartbeats can use UDP or TCP depending on the session set up based
> > > on
> > the initial connection (UDP is preferred over TCP).  With UDP, there
> > is a CoAP Ping (Empty request CON 0.00) and a CoAP RST response.  With
> > TCP, there is a Coap Ping (7.02) and a Coap Pong (7.03) response.
> > > For UDP, https://tools.ietf.org/html/rfc7252#section-4.8.2 defines
> > > the
> > ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT which
> map onto the
> > DOTS heartbeat parameters ack-timeout, ack-random-factor and
> > max-retransmit.  These 3 parameters determine the elapsed time when
> > there has been transmission failure.   There is an additional DOTS
> parameter
> > missing-hb-allowed to support more than one heartbeat loss should it
> > be needed before determining that a DOTS agent has really gone away
> > (instead of, say, going through a reboot or a restart cycle).
> >
> > Why do you need this additional parameter? Why is max-retransmit not
> > enough? Isn’t the results the same, you send more ping frames before
> > you finally give up?
> 
> Well no - we are running in a failing network environment due to the DDoS
> attacks and need to be as robust as possible before finally giving up.
> 
> In RFC7252 ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT
> have the suggested values of 2, 1.5 and 4 respectively.  Following
> https://tools.ietf.org/html/rfc7252#section-4.8.2, the time between the first
> and last retransmit with these values is 45 seconds - which means that the
> request times out after 93 seconds (MAX_TRANSMIT_WAIT) at the point
> when the MAX_RETRANSMIT+1 is retried.
> 
> This final time of 48 seconds (93sec - 45sec) is bigger than a NAT refresh
> timeout that we are comfortable with, so the recommended DOTS value  for
> max-retransmit is 3.  We have added in this additional missing-hb-allowed to
> increase the timeout before failure is determined.
> 
> However, as mentioned below, this determined failure may not be sufficient
> to cause a session to be closed down as there could be network losses due to
> the DDoS attacks.
> 
> >
> > >
> > > When handling an attack scenario, there is a good chance that the
> > > inbound
> > (DOTS server to DOTS client) data path is flooded /overloaded and
> > hence packet loss (but not the case with all DDoS type scenarios).
> > >
> > > A significant purpose of the DOTS client generating a heartbeat is
> > > to make
> > sure that any NAT devices in the path maintain their NAT associations
> > and allow any returning responses (which could be unsolicited if the
> > observe of a mitigation is active).
> > >
> > > Even in the attack scenario, the DOTS server will see these
> > > heartbeat
> > messages, but can only deduce that the connection from the DOTS client
> > to the DOTS server is good - but cannot make any assumptions about
> > traffic flowing in the other direction.
> >
> > However, if the client does never receive a Coap RST or Coap pong, it
> > will sooner or later give up and not send any ping messages anymore.
> > In this case the server will receive no ping anymore and can decide to send
> own pings.
> > Important is the idle time out is known to both ends.
> 
> Agreed, but as mentioned below the DOTS client must continue to transmit if
> there has been a mitigation request (i.e. running in under attack mode and
> networks could be flaky).
> 
> The retransmission parameters are negotiated between the DOTS agents at
> client session startup ( https://tools.ietf.org/html/draft-ietf-dots-signal-
> channel-34#section-4.5.2 ) so both ends know what the timeouts are.
> 
> >
> > Further if your really want to be sure if the RST was received or not,
> > I’d recommend you to use an own application ping that indicated if the
> > ping is a retransmission or not.
> 
> Well actually, while  the CoAP layer handles the transmission of the
> Empty/RST, the ping is initiated by the DOTS layer (and is told either a RST or
> timeout occurred), not the CoAP layer and so the DOTS application is in
> control of what is going on here.
> 
> The Ping is not handled in the same as, say, TCP keep-alive packets which are
> handled completely by the TCP layer.
> 
> >
> > Detection one-way congestion is a different function than keep-alive
> > testing and it is better to use an explicit mechanism for that then
> > trying to infer something from a mechanism that was designed for a
> different purpose.
> >
> 
> Agreed, but the DOTS layer is triggering the CoAP ping to do this work for the
> one-way congestion testing.
> 
> > >
> > > However, the DOTS client may not get a ping response due to the
> > > flooded
> > inbound pipe.  If the DOTS client has initiated a mitigation request,
> > then it is unsafe for the DOTS client to close down the session - it
> > will need to refresh the mitigation requests / create new ones even if
> > the mitigation is not being that effective as traffic can still flow
> > to the server.  It is possible that the DOTS server has just restarted
> > - hence the requirement to try and open up a new session in parallel.
> > >
> > > If the DOTS server also initiates heartbeat messages, sees the DOTS
> > > client
> > pings, but does not see any response to the DOTS server ping, the DOTS
> > server can now deduce that the outbound pipe is good, but the inbound
> > pipe to the DOTS client is failing.  The DOTS server then does not
> > need to close down the session as it will be expecting additional
> > mitigation requests from the DOTS client - even though the DOTS server
> Coap Ping is failing.
> > >
> > > Furthermore, if the DOTS server initiates its CoAP ping on receipt
> > > of the
> > DOTS client Coap Ping, then there is a good chance that the NAT
> > sessions are "warm" on any intervening NAT devices.  If the DOTS
> > server initiates the Coap Ping on its own cycle, there is a chance
> > that it may not get through and confuse the logic.
> >
> > This also sounds to me that you should rather design your own testing
> > during mitigation in the dots layer, e.g. don’t use the Coap Ping, but
> > send a non-confirmable Coap message which contains a dots layer “ping"
> > and an indication if a dots-layer “pong" has been received or not.
> 
> As stated above, the CoAP ping is not initiated by the CoAP layer like TCP
> keep-alives, but is triggered by the DOTS application by sending the Coap
> Ping packet - which in effect is what you are suggesting (apart from the non-
> confirmable aspect).  If using TCP, then what you describe is correct (except
> Confirmable/Non-Confirmable are out of the picture).
> 
> The CoAP Empty packet must be confirmable to solicit a RST response (Table
> 1: RFC7252).  I would rather not move away from RFC7252 here.
> 
> >
> > However, note that this still might not work with TCP as messages
> > cannot be transmitted unreliably and not-transmitted/no-acked
> > application layer data will block all other traffic on the same
> > connection at some point because TCP will try to retransmit and shrink the
> congestion window to the minimum.
> 
> TCP CoAP Ping/Pong does work as we are initiating it from the DOTS layer.
> 
> ~Jon
> 
> >
> > Mirja
> >
> >
> > >
> > > Regards
> > >
> > > Jon
> > >
> > >> -----Original Message-----
> > >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of supjps-
> > mohamed.boucadair@orange.com
> > >> Sent: 03 July 2019 14:46
> > >> To: Mirja Kuehlewind
> > >> Cc: draft-ietf-dots-signal-channel@ietf.org; Konda, Tirumaleswar
> > >> Reddy; dots@ietf.org; frank.xialiang@huawei.com; The IESG; dots-
> > chairs@ietf.org;
> > >> Benjamin Kaduk
> > >> Subject: Re: [Dots] Behavior when keep-alives fail (RE: Mirja
> > >> Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with
> > >> DISCUSS and
> > COMMENT)
> > >>
> > >> Re-,
> > >>
> > >> Please see inline.
> > >>
> > >> Cheers,
> > >> Med
> > >>
> > >>> -----Message d'origine-----
> > >>> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net] Envoyé :
> > >>> mercredi 3 juillet 2019 14:46 À : BOUCADAIR Mohamed TGI/OLN Cc :
> > >>> Konda, Tirumaleswar Reddy; Benjamin Kaduk; draft-ietf-dots-signal-
> > >>> channel@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; The
> > >>> IESG; dots-chairs@ietf.org Objet : Re: Behavior when keep-alives
> > >>> fail (RE: [Dots] Mirja Kühlewind's Discuss on
> > >>> draft-ietf-dots-signal-channel-31: (with DISCUSS and
> > >> COMMENT)
> > >>>
> > >>> Hi Med,
> > >>>
> > >>> See below.
> > >>>
> > >>>> On 3. Jul 2019, at 12:48, <mohamed.boucadair@orange.com>;
> > >>> <mohamed.boucadair@orange.com>; wrote:
> > >>>>
> > >>>> Mirja,
> > >>>>
> > >>>>> 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 choose the connection.
> > >>>>
> > >>>> This behavior is implemented and tested between two
> > implementations.
> > >> The
> > >>> exact procedure is described in the draft, fwiw:
> > >>>>
> > >>>> ==
> > >>>>  When a Confirmable "CoAP Ping" is sent, and if there is no
> > >>>> response,  the "CoAP Ping" is retransmitted max-retransmit number
> > >>>> of times by  the CoAP layer using an initial timeout set to a
> > >>>> random duration  between ack-timeout and
> > >>>> (ack-timeout*ack-random-factor) and  exponential back-off between
> > >>>> retransmissions.  By choosing the  recommended transmission
> > >>>> parameters, the "CoAP Ping" will timeout  after 45 seconds.  If
> > >>>> the DOTS agent does not receive any response  from the peer DOTS
> > >>>> agent for 'missing-hb-allowed' number of  consecutive "CoAP Ping"
> > >>>> Confirmable messages, it concludes that the  DOTS signal channel
> > >>>> session is disconnected.  A DOTS client MUST NOT  transmit a "CoAP
> Ping" while waiting for the previous "CoAP Ping"
> > >>>>  response from the same DOTS server.
> > >>>> ==
> > >>>
> > >>> First, can you explain why you need 'missing-hb-allowed’?
> > >>
> > >> [Med] because we need to make sure this a "real/durable" session
> > defunct,
> > >> not a false positive. For example, this would have implications on
> > >> the
> > server
> > >> as it may erroneously start automated mitigations (because it
> > >> concludes
> > the
> > >> session is lost).
> > >>
> > >> If the ping is
> > >>> transmitted reliably, one “missed” should be enough to conclude
> > >>> that
> > the
> > >>> session is disconnected.
> > >>
> > >> [Med] Hmm, under some DDoS attacks, both endpoints may be
> > >> sending/replying to confirmable ping messages, but the reply may
> > >> get dropped. The session is not disconnected in such case.
> > >>
> > >>>
> > >>> 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.
> > >>>
> > >>> If you want to send further UDP datagram you should it
> > >>> unreliability and not more often then one per 3 seconds.
> > >>>
> > >>> Mirja
> > >>>
> > >>>
> > >>>>
> > >>>> Cheers,
> > >>>> Med
> > >>>>
> > >>>>> -----Message d'origine-----
> > >>>>> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net] Envoyé :
> > >>>>> mercredi 3 juillet 2019 12:26 À : BOUCADAIR Mohamed TGI/OLN Cc :
> > >>>>> Konda, Tirumaleswar Reddy; Benjamin Kaduk; draft-ietf-dots-
> > signal-
> > >>>>> channel@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; The
> > IESG;
> > >>>>> dots-chairs@ietf.org
> > >>>>> Objet : Re: Behavior when keep-alives fail (RE: [Dots] Mirja
> > >>> Kühlewind's
> > >>>>> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and
> > >>> COMMENT)
> > >>>>>
> > >>>>> Hi Med,
> > >>>>>
> > >>>>> See below.
> > >>>>>
> > >>>>>> On 3. Jul 2019, at 09:53, mohamed.boucadair@orange.com wrote:
> > >>>>>>
> > >>>>>> Hi Mirja,
> > >>>>>>
> > >>>>>> (Focusing on individual issues)
> > >>>>>>
> > >>>>>> Please see inline.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Med
> > >>>>>>
> > >>>>>>> -----Message d'origine-----
> > >>>>>>> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net] Envoyé :
> > >>>>>>> mardi 2 juillet 2019 16:00 À : BOUCADAIR Mohamed TGI/OLN Cc :
> > >>>>>>> Konda, Tirumaleswar Reddy; Benjamin Kaduk; draft-ietf-dots-
> > >>> signal-
> > >>>>>>> channel@ietf.org; frank.xialiang@huawei.com; dots@ietf.org;
> > >>>>>>> The
> > >> IESG;
> > >>>>>>> dots-chairs@ietf.org
> > >>>>>>> Objet : Re: [Dots] Mirja Kühlewind's Discuss on
> > >>>>>>> draft-ietf-dots-
> > >>> signal-
> > >>>>>>> channel-31: (with DISCUSS and COMMENT)
> > >>>>>>>
> > >>>>>> ...
> > >>>>>>>>>>>> 10) The document should more explicitly provide more
> > >> guidance
> > >>>>> about
> > >>>>>>>>>>>> when a client should start a session and what should be
> > >>>>>>>>>>>> done
> > >>> (from
> > >>>>>>> the
> > >>>>>>>>>>>> client side) if a session is detected as inactive (other
> > >>>>>>>>>>>> than
> > >>>>> during
> > >>>>>>>>>>>> migration which is discussed a bit in 4.7). Is the
> > >>>>>>>>>>>> assumption to
> > >>>>>>> have
> > >>>>>>>>>>>> basically permanently an active session or connect for
> > >> migration
> > >>>>> and
> > >>>>>>>>>>>> configuration requests separately at a time?
> > >>>>>>>>>>>
> > >>>>>>>>>>> I think there was some clarifying text added, but please
> > confirm
> > >>> if
> > >>>>>>> you
> > >>>>>>>>> think it
> > >>>>>>>>>>> is sufficient.
> > >>>>>>>>>
> > >>>>>>>>> Sorry, don’t see where text was added. Can you provide a
> > pointer?
> > >>>>>>>>
> > >>>>>>>> [Med] We do have this text, for example:
> > >>>>>>>>
> > >>>>>>>> The DOTS signal channel can be established between two DOTS
> > >> agents
> > >>>>>>>> prior or during an attack.  The DOTS signal channel is
> > >>>>>>>> initiated by the DOTS client.  The DOTS client can then
> > >>>>>>>> negotiate, configure,
> > and
> > >>>>>>>> retrieve the DOTS signal channel session behavior with its
> > >>>>>>>> DOTS
> > peer
> > >>>>>>>> (Section 4.5).  Once the signal channel is established, the
> > >>>>>>>> DOTS agents periodically send heartbeats to keep the channel
> > >>>>>>>> active (Section 4.7).  At any time, the DOTS client may send
> > >>>>>>>> a mitigation request message (Section 4.4) to a DOTS server
> > >>>>>>>> over the active
> > >>> signal
> > >>>>>>>> channel.  While mitigation is active (because of the higher
> > >>>>>>>> likelihood of packet loss during a DDoS attack), the DOTS
> > >>>>>>>> server periodically sends status messages to the client,
> > >>>>>>>> including basic mitigation feedback details.  Mitigation
> > >>>>>>>> remains active until the DOTS client explicitly terminates
> > >>>>>>>> mitigation, or the mitigation lifetime expires.  Also, the
> > >>>>>>>> DOTS server may rely on the signal channel session loss to
> > >>>>>>>> trigger mitigation for pre-configured mitigation requests (if any).
> > >>>>>>>
> > >>>>>>> Okay thanks for for the pointer. What I think is missing are
> > >>>>>>> some sentences about what the client (or server) should do if
> > >>>>>>> the keep-
> > >>> alive
> > >>>>>>> fails. Try to reconnect directly or just with the next request
> > >>>>>>> or whatever. Basically who should reconnect and when?
> > >>>>>>
> > >>>>>> [Med] This is discussed in details in Section 4.7, in particular.
> > >>>>>>
> > >>>>>> As a generic rule, it is always the client who connects (see
> > >>>>>> the
> > >>> excerpt
> > >>>>> above).
> > >>>>>>
> > >>>>>> The server may use the failure to initiate automated mitigation
> > >>>>>> (see
> > >>> the
> > >>>>> excerpt above). More details are provided in other sections.
> > >>>>>>
> > >>>>>> There are several heartbeat failure cases to handle by the client.
> > >>>>> Examples from 4.7 are provided below, fwiw:
> > >>>>>>
> > >>>>>>    The DOTS client MUST NOT consider the DOTS signal channel
> > session
> > >>>>>>    terminated even after a maximum 'missing-hb-allowed'
> threshold is
> > >>>>>>    reached.  The DOTS client SHOULD keep on using the current
> DOTS
> > >>>>>>    signal channel session to send heartbeat requests over it, so that
> > >>>>>>    the DOTS server knows the DOTS client has not disconnected the
> > >>>>>>    DOTS signal channel session.
> > >>>>>>
> > >>>>>>    After the maximum 'missing-hb-allowed' threshold is reached,
> the
> > >>>>>>    DOTS client SHOULD try to resume the (D)TLS session.  The DOTS
> > >>>>>>    client SHOULD send mitigation requests over the current DOTS
> > >>>>>>    signal channel session, and in parallel, for example, try to
> > >>>>>>    resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to
> > >>>>>>    piggyback the mitigation request in the ClientHello message.
> > >>>>>>
> > >>>>>>    As soon as the link is no longer saturated, if traffic from the
> > >>>>>>    DOTS server reaches the DOTS client over the current DOTS signal
> > >>>>>>    channel session, the DOTS client can stop (D)TLS session
> > >>>>>>    resumption or if (D)TLS session resumption is successful then
> > >>>>>>    disconnect the current DOTS signal channel session.
> > >>>>>>
> > >>>>>> Do you think additional text is needed?
> > >>>>>
> > >>>>> 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 choose the connection.
> > >>>>>
> > >>>>> Mirja
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> > >> _______________________________________________
> > >> 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