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

"MeiLing Chen" <chenmeiling@chinamobile.com> Thu, 16 May 2019 02:36 UTC

Return-Path: <chenmeiling@chinamobile.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 9B1871200E6 for <dots@ietfa.amsl.com>; Wed, 15 May 2019 19:36:00 -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, URIBL_BLOCKED=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 5lqOPkrymomN for <dots@ietfa.amsl.com>; Wed, 15 May 2019 19:35:57 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id C1D891200B4 for <dots@ietf.org>; Wed, 15 May 2019 19:35:56 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee95cdccc844ed-c6602; Thu, 16 May 2019 10:35:49 +0800 (CST)
X-RM-TRANSID: 2ee95cdccc844ed-c6602
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[10.2.51.72]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35cdccc83a61-65332; Thu, 16 May 2019 10:35:48 +0800 (CST)
X-RM-TRANSID: 2ee35cdccc83a61-65332
Date: Thu, 16 May 2019 10:35:50 +0800
From: MeiLing Chen <chenmeiling@chinamobile.com>
To: "mohamed.boucadair" <mohamed.boucadair@orange.com>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
Cc: dots <dots@ietf.org>
References: <2019051517083625930510@chinamobile.com>, <2019051518171308785722@chinamobile.com>, <787AE7BB302AE849A7480A190F8B93302EA7E396@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.115[cn]
Mime-Version: 1.0
Message-ID: <2019051610354984340514@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart727877744857_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/-adnHbz7KGnpyQJ4AxOrv97S-kE>
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: Thu, 16 May 2019 02:36:01 -0000

Hi Med,
It looks like that trigger-mitigation set to false almost never used unless session is lost and then the DOTS client initiate another mitigation request with the trigger-mitigation value of false.

 
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