Re: [Dots] Question: SignalChannel Mitigation using Mitigator with asynchronous
<mohamed.boucadair@orange.com> Mon, 11 February 2019 08:07 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 786EA131023 for <dots@ietfa.amsl.com>; Mon, 11 Feb 2019 00:07:51 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LBGe2YQSbsPb for <dots@ietfa.amsl.com>; Mon, 11 Feb 2019 00:07:49 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD39128BCC for <dots@ietf.org>; Mon, 11 Feb 2019 00:07:49 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 43ydgl4QJkzFq7Z; Mon, 11 Feb 2019 09:07:47 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 43ydgl3kBGzCqkq; Mon, 11 Feb 2019 09:07:47 +0100 (CET)
Received: from OPEXCAUBMA1.corporate.adroot.infra.ftgroup (10.114.13.20) by OPEXCLILM41.corporate.adroot.infra.ftgroup (10.114.31.42) with Microsoft SMTP Server (TLS) id 14.3.435.0; Mon, 11 Feb 2019 09:07:47 +0100
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0435.000; Mon, 11 Feb 2019 09:07:47 +0100
From: mohamed.boucadair@orange.com
To: Takahiko Nagata <nagata@lepidum.co.jp>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Question: SignalChannel Mitigation using Mitigator with asynchronous
Thread-Index: AQHUwRKOsXPmo84zYU+SgC7IhR2h1aXaOoGA
Date: Mon, 11 Feb 2019 08:07:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1D1ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <1842c1bf-96b2-8757-f8b1-8a8efd84a491@lepidum.co.jp>
In-Reply-To: <1842c1bf-96b2-8757-f8b1-8a8efd84a491@lepidum.co.jp>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/hiiB8kp4TI6IW2bEueCsTQwu0j0>
Subject: Re: [Dots] Question: SignalChannel Mitigation using Mitigator with asynchronous
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, 11 Feb 2019 08:07:52 -0000
Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De : Dots [mailto:dots-bounces@ietf.org] De la part de Takahiko Nagata > Envoyé : dimanche 10 février 2019 08:31 > À : dots@ietf.org > Objet : [Dots] Question: SignalChannel Mitigation using Mitigator with > asynchronous > > Hi all, > > I confirmed latest(-28 version) SignalChannel and I have questions. > I would like to use Mitigator with asynchronous request/response. > > In success case is OK: > 1. DOTS Server recieve Mitigation request. > 2. DOTS Server response with status=1 > (Attack mitigation setup is in progress) > 3. Call Mitigator with asynchronous > 4. If success mitigation, DOTS Server response(via observe) > with status=2 > (2: Attack is being successfully mitigated) > > But in failure case: > 1. DOTS Server recieve Mitigation request. > 2. DOTS Server response with status=1 > (Attack mitigation setup is in progress) > 3. Call Mitigator with asynchronous > 4. If failure mitigation, DOTS Server response(via observe) > with status=7? > (7: Attack mitigation is withdrawn (by the DOTS server)) > > > (Question1) status=7(withdrawn) is correct in this case? [Med] If the failure is not due to an exceed capacity (which supposes likely a status transition to 2 and then 4), returning 7 is correct here. > (Question2) How to notify reason of withdrawn to DOTS client? [Med] Transitioning from 1 to 7 is clear enough that the problem is related to the completion of the mitigation setup. Isn't it? We have defined the signal channel model so that it can be fed automatically with new values that can be registered in the "Status Codes Sub-Registry". > > > Best Regards, > Takahiko Nagata > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots
- [Dots] Question: SignalChannel Mitigation using M… Takahiko Nagata
- Re: [Dots] Question: SignalChannel Mitigation usi… mohamed.boucadair