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

Hi Kaname,

Please see inline [TR3]

From: kaname nishizuka <kaname@nttv6.jp>
Sent: Tuesday, September 4, 2018 11:01 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; 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