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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

From: kaname nishizuka <[e-mail]>
Sent: Thursday, September 13, 2018 12:14 PM
To: Jon Shallow <[e-mail]>; Konda, Tirumaleswar Reddy <[e-mail]>; [e-mail]; [e-mail]
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 Jon,

Thanks a lot for the detailed explanation! I finally understood the logic.
I feel the context you explained is somehow missing in the draft. let me think about that.
As a final confirmation , GET with sid only reset the timer of the negotiated configuration. It doesn't change(override) the config, right?
[TR] Yes
-Tiru

thanks,
Kaname
On 2018/09/11 18:43, Jon Shallow wrote:
Hi Kaname,

I like to think of this as there being an initial set of defaults for the configuration which are used by the DOTS server for any new session.

It has to be assumed that both the DOTS client and DOTS server “remember” the current values, especially as there could be a change from peace time to mitigation and vice versa.

The DOTS client can then update the “current” values by using a PUT with a sid.  If the updated “current” are not refreshed by the DOTS client within the MAX_AGE time, then I see them as reverting back to the initial defaults.

To refresh the DOTS server’s notion of what should be current, this could just be done with a “PUT + sid”.  However, as Med points out, there needs to be a way of determining whether the session configuration parameters have been re-configured on the DOTS server by the DOTS client.  This means that a GET has to be executed prior to doing a PUT + sid to see if there have been any changes.   Using a “GET + sid” replaces (a traffic reduction) the need for the GET + “PUT + sid”.  At the time of the response of the “GET + sid”, both the DOTS client and DOTS server have the same configuration so is there really a need for the additional “PUT + sid” to cause the DOTS server to reset the timer for the current session?
- Just use the “GET + sid” to cause the server timer to get refreshed.

[If the DOTS client does not agree with the updated values, it can do another PUT with an incremented sid].

As Tiru says, doing a GET without sid will not cause the updated “current” values to get refreshed for another MAX_AGE.  So the DOTS server will revert back to the initial default values.  Only a GET + sid will do this refresh.

[I have noticed that I misunderstood the response of a GET + sid.  My code currently only returns the “current” values, not the min/max as well – maybe this was in a previous iteration of the draft – I will get it corrected to the current draft]

Regards

Jon


From: Dots [mailto: [e-mail]<mailto:[e-mail]>] On Behalf Of kaname nishizuka
Sent: 11 September 2018 09:59
To: Konda, Tirumaleswar Reddy; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Jon Shallow
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-23.txt

Hi Med, Tiru,

Thanks for the clarification. I can trace the way, but I feel it is going to implementation specific.
> 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.
What I've not been convinced of is why some (presumably Jon's) implementations requires it.
If it is useful, I'm happy to implement it, but currently the advantage is unclear for me. I want to hear from Jon.
As for the text in the draft, if "refresh" means override of the config, it should be said so. Otherwise, the first reader will have the same question as I had.

thanks,
Kaname


On 2018/09/11 17:19, Konda, Tirumaleswar Reddy wrote:
Further, ‘sid’ is a mandatory parameter to update the DOTS signal channel session config, hence it is a mandatory parameter to refresh the config.

-Tiru

From: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Sent: Tuesday, September 11, 2018 12:20 PM
To: kaname nishizuka <[e-mail]><mailto:[e-mail]>; Konda, Tirumaleswar Reddy <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Jon Shallow <[e-mail]><mailto:[e-mail]>
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 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:[e-mail]] De la part de kaname nishizuka
Envoyé : mardi 11 septembre 2018 03:43
À : Konda, Tirumaleswar Reddy; [e-mail]<mailto:[e-mail]>; 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 <[e-mail]><mailto:[e-mail]>
Sent: Tuesday, September 4, 2018 11:01 AM
To: Konda, Tirumaleswar Reddy <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]><mailto:[e-mail]>
Sent: Monday, September 3, 2018 12:46 PM
To: Konda, Tirumaleswar Reddy <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]><mailto:[e-mail]> On Behalf Of kaname nishizuka
Sent: Tuesday, August 28, 2018 1:58 PM
To: [e-mail]<mailto:[e-mail]>
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, [e-mail]<mailto:[e-mail]> 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:[e-mail]] De la part de

[e-mail]<mailto:[e-mail]>

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

À : [e-mail]<mailto:[e-mail]>

Cc : [e-mail]<mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

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









_______________________________________________

Dots mailing list

[e-mail]<mailto:[e-mail]>

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