Re: [Dots] clarification questions from the hackathon

<mohamed.boucadair@orange.com> Thu, 28 March 2019 13:38 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 CEF721204D0 for <dots@ietfa.amsl.com>; Thu, 28 Mar 2019 06:38:57 -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, 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 PGZrwbUCcT97 for <dots@ietfa.amsl.com>; Thu, 28 Mar 2019 06:38:55 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A4A1204B9 for <dots@ietf.org>; Thu, 28 Mar 2019 06:38:55 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 44VQv12R0vz7tn1; Thu, 28 Mar 2019 14:38:53 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 44VQv11dLGz1xns; Thu, 28 Mar 2019 14:38:53 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0439.000; Thu, 28 Mar 2019 14:38:53 +0100
From: mohamed.boucadair@orange.com
To: kaname nishizuka <kaname@nttv6.jp>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] clarification questions from the hackathon
Thread-Index: AQHU5VJSCfVXhciSq0+ZqKxGOtsoYqYhCgDA
Date: Thu, 28 Mar 2019 13:38:52 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA4ED61@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <946bcc8c-2e3e-3b09-b8d1-631475ea0ea0@nttv6.jp>
In-Reply-To: <946bcc8c-2e3e-3b09-b8d1-631475ea0ea0@nttv6.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/iLxy_6yiWkP7pYWtlzwE5S58M4E>
Subject: Re: [Dots] clarification questions from the hackathon
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, 28 Mar 2019 13:39:06 -0000

Re-, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka
> Envoyé : jeudi 28 mars 2019 11:38
> À : dots@ietf.org
> Objet : [Dots] clarification questions from the hackathon
> 
> Hi,
> 
> I'd like to continue discussion of these topics in the ML.
> 
> #1: Questions about signal-control-filtering
>   1. Should a mitigation request create a mitigation before doing a PUT +
> acl-list [{acl-name, activation-type}] against the active mitigation, or is a
> ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> mitigation?

[Med] Both are currently allowed in the draft. I don't still a valid reason to restrict this. 

>   2. Should the response to a GET (or Observed GET) include the acl-list
> [{acl-name, activation-type}] if the PUT included it?

[Med] The current spec says "no". That's said, what would be the value in returning it? Then, why not allowing to return the references to all ACLs that are enabled during the mitigation time?

>   3. Does the response to the PUT (the echoed back response payload of the
> PUT representation https://tools.ietf.org/html/rfc7252#section-5.9.1.1 )
> include the acl-list (if defined) or not?

[Med] It doesn't as we don't change the behavior of the base spec.

>   4. Is the activation change to the ACL a permanent change to the ACL (so a
> GET on the data channel returns the new type)?

[Med] Yes. The draft will be updated to make this clearer. 

>   5. Does the activation change to the ACL count as an ACL refresh (pending-
> lifetime update)?

[Med] Yes. Some text will be added to clarify the refresh point. That's said, as discussed in the data-channel, the dots client may need to send a GET after an attack for sync purposes.

>   6. Is CBOR activation –type comprehension-required or comprehension-
> optional?
> 

[Med] This is a comprehension-required attribute (already discussed in the draft).

> Regarding with the 1st point, we got feedbacks from Med and Tiru that both
> should be allowed.
> If ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> mitigation, it should be treated as this is a request in "attack-time".

[Med] I confirm.

> 
> (#2: Data Channel Implicit protocol number was addressed clearly by Med's
> comment.)
> 
> #3: (D)TLS session lifetime
>  From the view point of DOTS server, when to expire the old (D)TLS session is
> implementation specific though, I'd like to hear from experts about
> preferable setting (timer or something else...?)
> 

[Med] For me, this is implementation-specific.  

> thanks,

[Med] Many thanks for sharing the feedback from the hackathon. Much appreciated. 

> Kaname
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots