Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt

<mohamed.boucadair@orange.com> Tue, 11 September 2018 06:50 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 7097C1310FC for <dots@ietfa.amsl.com>; Mon, 10 Sep 2018 23:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Hu3McUSw7qpI for <dots@ietfa.amsl.com>; Mon, 10 Sep 2018 23:50:03 -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 645391310EF for <dots@ietf.org>; Mon, 10 Sep 2018 23:50:02 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 428bBd0XbYz8tkt; Tue, 11 Sep 2018 08:50:01 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 428bBc69lDzCqkY; Tue, 11 Sep 2018 08:50:00 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 08:50:00 +0200
From: <mohamed.boucadair@orange.com>
To: kaname nishizuka <kaname@nttv6.jp>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "dots@ietf.org" <dots@ietf.org>, "Jon Shallow" <supjps-ietf@jpshallow.com>
Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt
Thread-Index: AQHUSXDdHyJgQQ4GeUyFW8HKCtdTyaTqn2cA
Date: Tue, 11 Sep 2018 06:50:00 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DFDDACD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <153450832098.18132.7342824614297335945@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DFAB5EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <63f96d7b-77f0-e5c4-6759-1225079f84f6@nttv6.jp> <BN6PR16MB14250EB96CE34C0846F73B10EA0A0@BN6PR16MB1425.namprd16.prod.outlook.com> <5407aeab-0712-7c78-83eb-cb4078f1fabe@nttv6.jp> <BN6PR16MB1425F8408EE866874368C39DEA0C0@BN6PR16MB1425.namprd16.prod.outlook.com> <2c4a0f54-fbcd-7479-44c5-6e4480387642@nttv6.jp> <BN6PR16MB14255CE5FFC87137449808BAEA030@BN6PR16MB1425.namprd16.prod.outlook.com> <7903e0ee-628b-cb9a-f1a2-d9675d433093@nttv6.jp>
In-Reply-To: <7903e0ee-628b-cb9a-f1a2-d9675d433093@nttv6.jp>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DFDDACDOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/psA64MCl0uBXqcInhikic1889k8>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt
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: Tue, 11 Sep 2018 06:50:13 -0000

Hi Kaname,

As a reminder, the functionality we wanted to achieve is to inform a client about a configuration change occurred at the DOTS server. An initial version of the configuration was agreed as a result of a PUT. The natural way to achieve the functionality is to use a PUT, but some implementations may override the config hence the decision to go with GET + sid to mimic the behavior of sending a GET and then a PUT.

The presence of sid is an indicator that an initial configuration was first agreed between the client/server; but then get updated by the server. The client is aware of that.

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka
Envoyé : mardi 11 septembre 2018 03:43
À : Konda, Tirumaleswar Reddy; dots@ietf.org; Jon Shallow
Objet : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt

Hi Tiru, Jon,

I read the thread again and would like to raise the same question to Jon.

Here is a statement from Jon in the thread.
```
How will the GET request (I presume with SID) refresh the DOTS signal channel configuration parameters ?
Jon> By doing the GET, both ends are in agreement (at that point in time), so the current configuration is “fresh” and so no need to do a “refresh”.
```

My question is, what behavior of the DOTS server represents that they are in the "agreement".
The DOTS server need not to have a counter for age of the configuration freshness because it only sends Max-Age, so it is stateless.
The second question is that why only GET request with SID can take effect.
For example,  GET request without 'sid' also returns the current and acceptable configuration.
If it is not treated as an agreement on the DOTS server, what different behavior the DOTS server would have?

Again, for me, not mentioning 'sid' in this case is sufficient (it will allow both with and without sid).
```
   If a non-zero value of Max-Age Option is received by a DOTS client,
   it MUST issue a GET request  to retrieve
   the current and acceptable configuration before the expiry of the
   value enclosed in the Max-Age option.
```

thanks,
Kaname

On 2018/09/04 15:55, Konda, Tirumaleswar Reddy wrote:
Hi Kaname,

Please see inline [TR3]

From: kaname nishizuka <kaname@nttv6.jp><mailto:kaname@nttv6.jp>
Sent: Tuesday, September 4, 2018 11:01 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com><mailto:TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org<mailto:dots@ietf.org>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,

Please see inline [kaname2]
On 2018/09/03 16:32, Konda, Tirumaleswar Reddy wrote:
Hi Kaname,

Please see inline [TR2]

From: kaname nishizuka <kaname@nttv6.jp><mailto:kaname@nttv6.jp>
Sent: Monday, September 3, 2018 12:46 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com><mailto:TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org<mailto:dots@ietf.org>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,

Please see inline.
On 2018/08/28 22:42, Konda, Tirumaleswar Reddy wrote:
Hi Kaname,

Please see inline.

From: Dots <dots-bounces@ietf.org><mailto:dots-bounces@ietf.org> On Behalf Of kaname nishizuka
Sent: Tuesday, August 28, 2018 1:58 PM
To: dots@ietf.org<mailto:dots@ietf.org>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi,

I did a review on -23 of the signal channel draft:






1. [correction] GET request can be without 'sid' Uri-Path parameter.

<

   If a non-zero value of Max-Age Option is received by a DOTS client,

   it MUST issue a GET request with 'sid' Uri-Path parameter to retrieve

   the current and acceptable configuration before the expiry of the

   value enclosed in the Max-Age option.

>

   If a non-zero value of Max-Age Option is received by a DOTS client,

   it MUST issue a GET request to retrieve

   the current and acceptable configuration before the expiry of the

   value enclosed in the Max-Age option.



[TR] The proposed line is not correct. The client has to use GET request with ‘sid’ to refresh the configuration parameters it had previously negotiated.

[kaname]The client can get current values by GET request without 'sid' (4.5.1).



[TR2] Yes.



It seems that it hasn't been specified in the draft that previously negotiated configuration parameters are returned only by GET request with ‘sid’.



[TR2] No, GET request without ‘sid’ will not refresh the previously negotiated configuration parameters but will return the current, min and max values.

[kaname2] I'm still confused. GET request with and without ‘sid’ can get the current, min and max values.



[TR3] Yes.



 Why the draft exclude GET request without ‘sid’. In this case, what does "refresh" exactly mean? What will happen on the DOTS server side in both with and without 'sid' cases?



[TR3] Refresh is way for the client to learn the confirmation parameters updated by the server and for the server refresh the configuration after the validity time of the configuration. ‘sid’ is a mandatory parameter to create and refresh the configuration (please see the discussion we had with Jon and you https://mailarchive.ietf.org/arch/msg/dots/GJnWZTiiREjxZ_4SZEmRJVRI51M)



2. [proposal] Adding trigger-mitigation to several example figures about mitigation request



[TR] The default value of trigger-mitigation is ‘true’, I don’t see the need to explicitly convey the attribute in the mitigation request.

 [kaname] yes, but I've thought it makes the example more helpful because "trigger-mitigation" is important concept in mitigation request. To feed examples with "trigger-mitigation": false is also fine for me.



[TR2] Agree it’s a critical parameter and is discussed in detail in the specification but don’t want to confuse readers by adding the default value of “trigger-mitigation”: true to the example.

[kaname2] OK, we are on the same page and I understood.



[TR3] Thanks.



-Tiru



-Tiru


regards,
kaname




-Tiru



Figure 7.

{

 "ietf-dots-signal-channel:mitigation-scope": {

   "scope": [

     {

       "target-prefix": [

          "2001:db8:6401::1/128",

          "2001:db8:6401::2/128"

        ],

       "target-port-range": [

         {

           "lower-port": 80

         },

         {

           "lower-port": 443

         },

         {

            "lower-port": 8080

         }

        ],

        "target-protocol": [

          6

        ],

       "lifetime": 3600,

       "trigger-mitigation": true

     }

   ]

 }

}



Figure 8.

A1                                      # map(1)

   01                                   # unsigned(1)

   A1                                   # map(1)

      02                                # unsigned(2)

      81                                # array(1)

         A5                             # map(5)

            06                          # unsigned(6)

            82                          # array(2)

               74                       # text(20)

                  323030313A6462383A363430313A3A312F313238 # "2001:db8:6401::1/128"

               74                       # text(20)

                  323030313A6462383A363430313A3A322F313238 # "2001:db8:6401::2/128"

            07                          # unsigned(7)

            83                          # array(3)

               A1                       # map(1)

                  08                    # unsigned(8)

                  18 50                 # unsigned(80)

               A1                       # map(1)

                  08                    # unsigned(8)

                  19 01BB               # unsigned(443)

               A1                       # map(1)

                  08                    # unsigned(8)

                  19 1F90               # unsigned(8080)

            0A                          # unsigned(10)

            81                          # array(1)

               06                       # unsigned(6)

            0E                          # unsigned(14)

            19 0E10                     # unsigned(3600)

            18 2D                       # unsigned(45)

            F5                          # primitive(21)





thanks,

Kaname


On 2018/08/17 21:28, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

Hi all,



This version follows the recommendations from the core WG:

* Move Hop-Limit text to a separate I-D: I-D.boucadair-core-hop-limit.

* Abandon the use of 3.00, but use 5.03 instead.



The good news is that these changes are straightforward and do not hold publication because I-D.boucadair-core-hop-limit is not a normative reference.



We also updated the text to reflect the recent publication of RFC8446 (TLS 1.3). Changes are tweaked to be aligned with the discussion with Benjamin (thanks).



Chairs, the token is yours now :)



Cheers,

Med



-----Message d'origine-----

De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de

internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

Envoyé : vendredi 17 août 2018 14:19

À : i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>

Cc : dots@ietf.org<mailto:dots@ietf.org>

Objet : I-D Action: draft-ietf-dots-signal-channel-23.txt





A New Internet-Draft is available from the on-line Internet-Drafts

directories.

This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.



        Title           : Distributed Denial-of-Service Open Threat Signaling

(DOTS) Signal Channel Specification

        Authors         : Tirumaleswar Reddy

                          Mohamed Boucadair

                          Prashanth Patil

                          Andrew Mortensen

                          Nik Teague

  Filename        : draft-ietf-dots-signal-channel-23.txt

  Pages           : 87

  Date            : 2018-08-17



Abstract:

   This document specifies the DOTS signal channel, a protocol for

   signaling the need for protection against Distributed Denial-of-

   Service (DDoS) attacks to a server capable of enabling network

   traffic mitigation on behalf of the requesting client.



   A companion document defines the DOTS data channel, a separate

   reliable communication layer for DOTS management and configuration

   purposes.



Editorial Note (To be removed by RFC Editor)



   Please update these statements within the document with the RFC

   number to be assigned to this document:



   o  "This version of this YANG module is part of RFC XXXX;"



   o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling

      (DOTS) Signal Channel Specification";



   o  "| [RFCXXXX] |"



   o  reference: RFC XXXX



   Please update TBD statements with the port number to be assigned to

   DOTS Signal Channel Protocol.



   Also, please update the "revision" date of the YANG module.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-dots-signal-channel-23

https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-23



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-23





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________________________________________

Dots mailing list

Dots@ietf.org<mailto:Dots@ietf.org>

https://www.ietf.org/mailman/listinfo/dots