IETF Logo Mail Archive

Re: [Dots] draft-ietf-dots-signal-channel-33: trigger-mitigation

<mohamed.boucadair@orange.com> Wed, 15 May 2019 11:30 UTC

Return-Path: <mohamed.boucadair@orange.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 19B27120049 for <dots@ietfa.amsl.com>; Wed, 15 May 2019 04:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 B84hhxAkzEhA for <dots@ietfa.amsl.com>; Wed, 15 May 2019 04:30:09 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C77120043 for <dots@ietf.org>; Wed, 15 May 2019 04:30:09 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 453smH46YSzCt1d; Wed, 15 May 2019 13:30:07 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 453smH3vM7zDqDV; Wed, 15 May 2019 13:30:07 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 15 May 2019 13:30:07 +0200
From: mohamed.boucadair@orange.com
To: MeiLing Chen <chenmeiling@chinamobile.com>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
CC: dots <dots@ietf.org>
Thread-Topic: draft-ietf-dots-signal-channel-33: trigger-mitigation
Thread-Index: AQHVCwdfsGZfYpgrl0OCQZp3i1N6tqZsCuFA
Date: Wed, 15 May 2019 11:30:06 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA7E396@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <2019051517083625930510@chinamobile.com> <2019051518171308785722@chinamobile.com>
In-Reply-To: <2019051518171308785722@chinamobile.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA7E396OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/eLr5YosIOCZ9u6VwG4Zzj5ettMw>
Subject: Re: [Dots] draft-ietf-dots-signal-channel-33: trigger-mitigation
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, 15 May 2019 11:30:11 -0000

Hi Meiling,

Please see inline.

Cheers,
Med

De : MeiLing Chen [mailto:chenmeiling@chinamobile.com]
Envoyé : mercredi 15 mai 2019 12:17
À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN
Cc : dots
Objet : draft-ietf-dots-signal-channel-33: trigger-mitigation



Hi Tiru, Med;

I read draft-ietf-dots-signal-channel-33, I have a question about the parameter of trigger-mitigation,


 trigger-mitigation:   If the parameter value is set to 'false', DDoS

      mitigation will not be triggered for the mitigation request unless

      the DOTS signal channel session is lost.

      If the DOTS client ceases to respond to heartbeat messages, the

      DOTS server can detect that the DOTS signal channel session is

      lost.  More details are discussed in Section 4.7.

Reddy, et al.           Expires November 11, 2019              [Page 18]

Internet-Draft        DOTS Signal Channel Protocol              May 2019

      The default value of the parameter is 'true' (that is, the

      mitigation starts immediately).  If 'trigger-mitigation' is not

      present in a request, this is equivalent to receiving a request

      with 'trigger-mitigation' set to 'true'.
question1: When send mitigation request first time, trigger-mitigation is set true; when session is lost, trigger-mitigation set false will work, so how to know session is lost?
[Med] the absence of traffic or replies to server-initiated heartbeats are used to that aim. This covered by this text in the spec:

      If the DOTS server does not receive any traffic from the peer DOTS
      client, then the DOTS server sends heartbeat requests to the DOTS
      client and after maximum 'missing-hb-allowed' threshold is
      reached, the DOTS server concludes the session is disconnected.
      The DOTS server can then trigger pre-configured mitigation
        requests for this DOTS client (if any).

question2: Why need this parameter and What was the initial requirements scenario?
[Med] Please check: https://tools.ietf.org/html/draft-ietf-dots-architecture-13#section-3.3.3

v2.23.0 | Report a Bug | By Email