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

From: <[email-masked]>
Date: Mon, 8 Jan 2018 08:29:48 +0000

Hi Jon, all,

Apologies for the delay to answer this message (I was out of office).

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : jeudi 21 décembre 2017 17:49
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> Hi Med,
> 
> See inline [Jon].
> 
> Regards
> 
> Jon
> 
> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of
> [email-masked]
> Sent: 21 December 2017 14:55
> To: Jon Shallow; [email-masked]
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> Re-,
> 
> Thank you for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Jon Shallow [mailto:[email-masked]]
> > Envoyé : jeudi 21 décembre 2017 15:05
> > À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet : RE: [Dots] I-D
> > Action: draft-ietf-dots-signal-channel-14.txt
> >
> > Hi Med,
> >
> > Comments in my first pass through the -14 version
> >
> > 3. Design Overview
> >
> > "in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. ."
> >
> > Second trailing period not needed.
> 
> [Med] Already fixed in my local copy. Thanks.
> 
> >
> > 4.4.1. Request Mitigation
> >
> > "Attributes with emty values" should read " Attributes with empty
> values"
> 
> [Med] Idem as above.
> 
> >
> > 4.5 DOTS Channel Session Configuration
> >
> > Replace
> >
> > If distinct configuration are
> >    used, DOTS agents MUST follow the appropriate configuration set as
> > a
> >
> > with (plural)
> >
> > If distinct configurations are
> >    used, DOTS agents MUST follow the appropriate configuration set as
> > a
> >
> 
> [Med] Fixed.
> 
> >
> > 4.5.2 Convey DOTS Signal Channel Session Configuration
> >
> > I think config-interval should be defined in seconds - to be
> > consistent with lifetime, heartbeat-interval etc.
> 
> [Med] Works for me.
> 
> >
> > Replace
> >
> >       If a non-null value of 'config-interval' is received by a DOTS
> >       agent, it has to issue a PUT request to refresh the
> > configuration
> >
> > with
> >
> >       If a non-zero value of 'config-interval' is received by a DOTS
> >       client, it has to issue a PUT request to refresh the
> > configuration
> >
> 
> [Med] OK.
> [Jon] Not yet updated

[Med] Fixed.

> 
> > Replace (peace-time may now be idle-config, and attack-time-config may
> > now be mitigating-config)
> >
> >    peace-time-config:   Set of configuration parameters to use during
> >       peacetime.  This attribute has the same structure as 'attack-time-
> >       config'.
> >
> > With
> >
> >    idle-config:   Set of configuration parameters to use during
> >       peacetime.  This attribute has the same structure as 'mitigating-
> >       config'.  If this parameter is not defined, then the peacetime
> > configuration 'idle-config' is assumed to be the same as
> > 'mitigating-config'.
> >
> 
> [Med] We do already have a default behavior:
> 
> The DOTS agents MUST use the negotiated
>    values for message transmission parameters and default values for
>    non-negotiated message transmission parameters.
> 
> This means that the default values will be used if not specified.
> 
> If the same config is to be used for both idle-mitigation, both should be
> returned.
> 
> Actually, this is what I meant in this discussion:
> 
> ==
> [Jon]  A minor comment - is the following more logical and more
> descriptive?
> [Med] I considered this but favored the other one because it is more
> compact. For example, when the same config is to be used for both
> peace/attack times, you just need to omit "peace-time-config", while you
> need to include the same value twice for the other proposal. Do you have a
> strong preference?
> ====
> [Jon] OK - having both is fine by me - and if something is not defined
> then
> it takes on the default values.
> 
> > Figure 18: config-interval should have a current-value
> >
> > Should Figure 19 include config-interval ?
> 
> [Med] This is on purpose to indicate that config-interval can be omitted.
> [Jon] OK
> 
> >
> > 5.1 Tree structure
> >
> > Should
> >
> >           |     |        +--ro acl-name    ->
> > /ietf-acl:access-lists/acl/acl-name
> >           |     |        +--ro acl-type    ->
> > /ietf-acl:access-lists/acl/acl-type
> >
> > Be (data channel definition is OK - other than perhaps 'set-name'
> > really should be name', and 'type' should be 'type' due to netmod-acl
> > potential
> > changes)
> >
> >           |     |        +--ro acl-name    ->
> > /ietf-dots-data-channel:access-lists/acl/name
> >           |     |        +--ro acl-type    -> /
> > ietf-dots-data-channel:access-lists/acl/type
> >
> 
> [Med] No, the initial one is correct.
> [Jon] OK
> 
> > 'config-interval' also needs a current/min/max -value setting (as you
> > have in Figure 17) unless the DOTS server is going to control this
> absolutely.
> > Figure 18 will need updating as well.
> 
> [Med] Good catch. Figure 17 is wrong.
> 
> There is no value for having this for config-interval, because it is
> always
> up to the server to decide which value to put.
> 
> I will update figures 17/18 accordingly.
> [Jon] You currently have in your local copy draft config-interval only for
> PUT, not GET, so config-interval is not under the control of the server.
> 
> 
> >
> > yang:zero-based-counter64 is not supported by JSON (a JavaScript
> > limitation as I understand it)
> > RFC7159 6. Numbers
> >    Note that when such software is used, numbers that are integers and
> >    are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
> >    sense that implementations will agree exactly on their numeric
> >    values.
> 
> [Med] I guess we need to encode them as strings. RFC7493#section-2.2 says
> the following:
> 
>    An I-JSON sender cannot expect a receiver to treat an integer whose
>    absolute value is greater than 9007199254740991 (i.e., that is
>    outside the range [-(2**53)+1, (2**53)-1]) as an exact value.
> 
>    For applications that require the exact interchange of numbers with
>    greater magnitude or precision, it is RECOMMENDED to encode them in
>    JSON string values.  This requires that the receiving program
>    understand the intended semantic of the value.  An example would be
>    64-bit integers, even though modern hardware can deal with them,
>    because of the limited scope of JavaScript numbers.
> 
> [Jon] Oh - yuk - this means that there will be bloat in the COAP packet in
> the 5 places where int64 (or uint64) are used.
> [Jon] In all cases, I think that decimal64 will give us sufficient
> precision, as well as handle the numbers getting very large (e.g. bytes
> dropped).
> [Jon] If we do go with the string version, then there has to be extra
> logic
> (and context knowledge) to convert any JSON into 64bit numbers to do any
> math on.

[Med] I'm afraid that we need to go with string, refer to 6.1 of RFC7951 which endorses the above recommendation.

> >
> > 5.2 YANG module
> >
> > ack-random-factor was a float - and so current-value etc. subtypes of
> > ack-random-factor  should be floats, not int16.  I suggest that we use
> > a different name - i.e. current-value-decimal.
> >
> 
> [Med] I guess you are referring to section 6.
> 
> It seems that we will need *-value for major type 7.
> [Jon] Correct - I see that you have updated this in your local copy draft.
> 
> > Regards
> >
> > Jon
> >
> > -----Original Message-----
> > From: Dots [mailto: [email-masked]] On Behalf Of
> > [email-masked]
> > Sent: 19 December 2017 15:35
> > To: [email-masked]
> > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> >
> > Re-,
> >
> > This version integrates the outcomes of the mailing list discussion,
> > in
> > particular:
> > - Multiple client-id values does not mean anymore that multiple GWs
> > have injected a value each.
> > - Introduce attack-time-config and peace-time-config
> > - Add some text to suggest dots servers to send heartbeats immediately
> > after receiving the one from the peer dots client.
> > - Refreshing the configuration must not occur during attack times.
> >
> > The document is still using client-side and server-side DOTS GW terms.
> > The text will be aligned with the requirements I-D.
> >
> > Jon, please double check.
> >
> > All, please review and share your comments.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Dots [mailto:[email-masked]] De la part de internet-
> > > [email-masked] Envoyé : mardi 19 décembre 2017 16:19 À :
> > > [email-masked] Cc : [email-masked] Objet : [Dots] I-D Action:
> > > draft-ietf-dots-signal-channel-14.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
> > >         Authors         : Tirumaleswar Reddy
> > >                           Mohamed Boucadair
> > >                           Prashanth Patil
> > >                           Andrew Mortensen
> > >                           Nik Teague
> > > 	Filename        : draft-ietf-dots-signal-channel-14.txt
> > > 	Pages           : 84
> > > 	Date            : 2017-12-19
> > >
> > > 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 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";
> > >
> > >    o  "| 3.00 | Alternate server | [RFCXXXX] |"
> > >
> > >    o  reference: RFC XXXX
> > >
> > >    o  This RFC
> > >
> > >    Please update TBD statements with the port number to be assigned to
> > >    DOTS Signal Channel Protocol.
> > >
> > >
> > > 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-14
> > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel
> > > -1
> > > 4
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-14
> > >
> > >
> > > 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/
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dots
> >
> > _______________________________________________
> > Dots mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Tue, 9 Jan 2018 09:38:23 +0000

Hi Kaname, 

Thank you for the careful reading. 

Fixed in my local copy. 

Cheers,
Med

> De : kaname nishizuka [mailto:[email-masked]]
> Envoyé : vendredi 22 décembre 2017 05:35
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> small nits in the CBOR mapping example were found:
> 
> Figure 7: PUT for DOTS signal (CBOR)
> 
> line 4: client identifier
>   18 20                             # unsigned(32)
>   it must be:
>   18 24                             # unsigned(36)
> 
> line 13: target-prefix
>       04                          # unsigned(4)
>   it must be:
>      18 23                       # unsigned(35)
> 
> regards,
> Kaname
> 
> On 2017/12/20 0:34, [email-masked] wrote:
> > Re-,
> >
> > This version integrates the outcomes of the mailing list discussion, in
> particular:
> > - Multiple client-id values does not mean anymore that multiple GWs have
> injected a value each.
> >> [email-masked]
> >> Envoyé : mardi 19 décembre 2017 16:19
> >> À : [email-masked]
> >> Cc : [email-masked]
> >> Objet : [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> >>
> >>
> >> This draft is a work item of the DDoS Open Threat Signaling WG of the
> >> IETF.
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-14
> >>
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>