Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (3rd Part)

From: <[email-masked]>
Date: Wed, 16 Jan 2019 13:26:16 +0000

Re-,

Please see inline. 

Cheers,	
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mercredi 16 janvier 2019 01:14
> À : [email-masked]
> Cc : [email-masked]
> Objet : AD review of draft-ietf-dots-signal-channel-25
> 
> 
>                                                   To avoid maintaining a
>    long list of overlapping mitigation requests (i.e., requests with the
>    same 'trigger-mitigation' type and overlapping scopes) from a DOTS
>    client and avoid error-prone provisioning of mitigation requests from
>    a DOTS client, the overlapped lower numeric 'mid' MUST be
>    automatically deleted and no longer available at the DOTS server.
>    For example, if the DOTS server receives a mitigation request which
>    overlaps with an existing mitigation with a higher numeric 'mid', the
>    DOTS server rejects the request by returning 4.09 (Conflict) to the
>    DOTS client.  [...]
> 
> This seems to be internally inconsistent -- first we hear that the
> overlapped mitigation request with lower 'mid' MUST be deleted (BTW,
> note my rewording), but at the end we are hearing that a request to
> create an overlapping mitgiation must be rejected

[Med] It is rejected because it has a lower numeric 'mid'. 

.  (A couple pages
> later we also say "can be achieved by sending a PUT request [...] that
> will override the existing one with overlapping mitigation scopes"

[Med] Yes, the new one will have a higher 'mid'. 

,
> which suggests a resolution of the conflict.

[Med] I don't see any inconsistency. Please clarify if I missed your point. 

> 
>                  The response includes enough information for a DOTS
>    client to recognize the source of the conflict as described below:
> 
>    conflict-information:  Indicates that a mitigation request is
>    [...]
> 
> I'm not entirely sure what encoding to infer from just this description
> -- conflict-information/-cause/-scope are in the YANG model, but do we
> need to say that the response contains a CBOR representation of the
> subtree starting at conflict-information (or something like that), or is
> this implicitly specified elsewhere in the document?  For example,
> Figure 9 has an explicit JSON diagnostic notation for a message
> response.

[Med] This is covered by this text: 

   Thhis document specifies a YANG module for
   representing DOTS mitigation scopes, DOTS signal channel session
   configuration data, and DOTS redirected signalling (Section 5).
   Representing these data as CBOR data is assumed to follow the rules
   in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with
   JSON/CBOR conversion rules in [RFC7049].  All parameters in the
                                             ^^^^^^^^^^^^^^^^^^^^^^
   payload of the DOTS signal channel are mapped to CBOR types as
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   specified in Section 6.
   ^^^^^^^^^^^^^^^^^^^^^^

> 
>       conflict-scope:  Indicates the conflict scope.  It may include a
>          list of IP addresses, a list of prefixes, a list of port
>          numbers, a list of target protocols, a list of FQDNs, a list of
>          URIs, a list of alias-names, or a 'mid'.
> 
> This feels a little under-specified -- do we need to include exactly the
> conflicting entries?  Or would we just say something like "this
> conflicts with 'mid' 8; figure it out"?

[Med] This clause indicates the exact conflict scope. It may be for example:
- a conflict of IP addresses. Then, the target addresses in conflict are returned.
- a conflict with another request, then the mid of that request is returned
- etc.

We can update the text as follows: 

      conflict-scope:  Characterizes the exact conflict scope.  It may include a
                       ^^^^^^^^^^^^^^^^^^^^^^^^     
          list of IP addresses, a list of prefixes, a list of port
          numbers, a list of target protocols, a list of FQDNs, a list of
          URIs, a list of alias-names, or a 'mid'.

> 
>          3:  CUID Collision.  This code is returned when a DOTS client
>              uses a 'cuid' that is already used by another DOTS client.
>              This code is an indication that the request has been
>              rejected and a new request with a new 'cuid' is to be re-
>              sent by the DOTS client.  Note that 'conflict-status',
>              'conflict-scope', and 'retry-timer' are not returned in the
>              error response.
> 
> (Do we want "MUST NOT" 2119 language to prevent their inclusion or is
> the current descriptive language sufficient?)
> 

[Med] OK.

>       conflict-scope:  Indicates the conflict scope.  It may include a
>          list of IP addresses, a list of prefixes, a list of port
>          numbers, a list of target protocols, a list of FQDNs, a list of
>          URIs, a list of alias-names, or references to conflicting ACLs.
> 
> How do I reference an ACL?

[Med] By an acl-name. I updated the text to hint this: 

"(by an 'acl-name', typically [I-D.ietf-dots-data-channel])"

> 
>                           This can be achieved by sending a PUT request
>    with a new 'mid' value that will override the existing one with
>    overlapping mitigation scopes.
> 
> Do we want to reiterate that the existing one will be deleted?

[Med] The text you quoted reminds that the new request will delete the existing one. 

> 
>    For a mitigation request to continue beyond the initial negotiated
>    lifetime, the DOTS client has to refresh the current mitigation
>    request by sending a new PUT request.  This PUT request MUST use the
>    same 'mid' value, and MUST repeat all the other parameters as sent in
>    the original mitigation request apart from a possible change to the
>    lifetime parameter value.
> 
> If the server did not have a check that the other parameters match, what
> would happen?

[Med] A request may be for example inadvertently transitioned from pre-configured to immediate and vice versa. To avoid such issues, the spec mandates the following: 

* a client can adjust its mitigation scope by sending a new one that will override an existing one. 
* a client can update an existing mitigation by echoing the same parameters as those in the initial mitigation request. 

But leave it to the server to decide how to handle the refresh:

   If the DOTS server finds the 'mid' parameter value conveyed in the
   PUT request in its configuration data bound to that DOTS client, it
   MAY update the mitigation request, and a 2.04 (Changed) response is
   returned to indicate a successful update of the mitigation request.

  (Do we need normative language that the server MUST
> verify the other parameters when the 'mid' matches?)
> 
> Section 4.4.2
> 
>                           If the representation of all the active
>    mitigation requests associated with the DOTS client does not fit
>    within a single datagram, the DOTS server MUST use the Block2 Option
>    with NUM = 0 in the GET response.  [...]
> 
> I'm not very familiar with CoAP blockwise transfers; is this in conflict
> with some normal feature-negotiation scheme or is it okay to assume that
> the client will be able to handle this even if the client has not
> explictly indicated support?

[Med] RFC7959 indicates the following: 

   A CoAP implementation that does not support these options generally
   is limited in the size of the representations that can be exchanged,
   see Section 4.6 of [RFC7252].  Even though the options are Critical,
   a server may decide to start using them in an unsolicited way in a
   response.  No effort was expended to provide a capability indication
   mechanism supporting that decision: since the block-wise transfer
   mechanisms are so fundamental to the use of CoAP for representations
   larger than about a kilobyte, there is an expectation that they are
   very widely implemented.

> 
>       This is a mandatory attribute when an attack mitigation is
>       triggered.  Particularly, 'mitigation-start' is not returned for a
>       mitigation with 'status' code set to 8.
> 
> Is this better as "triggered" or as "active"?

[Med] Changed the text to "when an immediate attack mitigation is triggered".

> 
> bps-dropped and pps-dropped "SHOULD be a five-minute average", but that
> does not seem quite well-defined.  Is it a rolling five-minute average
> over bins of one second, or a binned five-minute average for the last
> five-minute interval that ends on a multiple of '5', or something else?

[Med] What is meant in an average over 5-minute intervals. Updated the text accordingly. 

> 
>    Upon receipt of a conflict notification message indicating that a
>    mitigation request is deactivated because of a conflict, a DOTS
>    client MUST NOT resend the same mitigation request before the expiry
>    of 'retry-timer'.  It is also recommended that DOTS clients support
>    means to alert administrators about mitigation conflicts.
> 
> Do we need to say anything regarding the server behavior when a
> retransmit or similar was in flight already when the conflict
> notification was generated?  (That is, the server's enforcement of the
> MUST NOT may need to be restrained.)

[Med] The MUST NOT is intended to avoid overloading the server, because: 

         "Any retransmission of the same
         mitigation request before the expiry of this timer is likely to
         be rejected by the DOTS server for the same reasons."
  
The text leave it to the server to decide which action to take when MUST NOT is not followed by a client. The server may decide the silently ignore those, etc. 

We can add some text if needed. 

> 
>    Alternatively, the DOTS client can explicitly deregister itself by
>    issuing a GET request that has the Token field set to the token of
>    the observation to be cancelled and includes an Observe Option with
>    the value set to '1' (deregister).
> 
> This seems like the more "polite" behavior (as opposed to just
> "forgetting" -- why is the polite behavior not the default behavior?

[Med] Done in my local copy. 

> 
> Does the GET in  Figure 13 need to have a ".well-known" and other path
> components?
> 

[Med] Don't think so. Actually, we are mimicking figure 2 in RFC7641.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 16 Jan 2019 13:50:22 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Wednesday, January 16, 2019 6:56 PM
> To: Benjamin Kaduk <[email-masked]>; draft-ietf-dots-signal-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (3rd Part)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : mercredi 16
> > janvier 2019 01:14 À : [email-masked]
> > Cc : [email-masked]
> ..  (A couple pages
> > subtree starting at conflict-information (or something like that), or
> > is this implicitly specified elsewhere in the document?  For example,
> > This feels a little under-specified -- do we need to include exactly
> > the conflicting entries?  Or would we just say something like "this
> > If the server did not have a check that the other parameters match,
> > what would happen?
> 
> [Med] A request may be for example inadvertently transitioned from pre-
> configured to immediate and vice versa. To avoid such issues, the spec
> mandates the following:
> 
> * a client can update an existing mitigation by echoing the same parameters
> as those in the initial mitigation request.
> 
> > I'm not very familiar with CoAP blockwise transfers; is this in
> > conflict with some normal feature-negotiation scheme or is it okay to
> > assume that the client will be able to handle this even if the client
> > has not explictly indicated support?
> 

mitigation-start is also a mandatory attribute when a pre-configured mitigation request is triggered.

> 
> >
> > bps-dropped and pps-dropped "SHOULD be a five-minute average", but
> > that does not seem quite well-defined.  Is it a rolling five-minute
> > average over bins of one second, or a binned five-minute average for
> > the last five-minute interval that ends on a multiple of '5', or something
> else?
> 
> The text leave it to the server to decide which action to take when MUST
> NOT is not followed by a client. The server may decide the silently ignore
> those, etc.
> 

Please note that https://tools.ietf.org/html/rfc7641#section-3.6 did not choose the explicit deregister as default behavior.

Cheers,
-Tiru

> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 16 Jan 2019 13:58:30 +0000

> > create an overlapping mitgiation must be rejected

The example is discussing out of order delivery of mitigation requests (DOTS client sends lower numeric 'mid' followed by higher numeric 'mid' but the DOTS server receives the 
higher numeric 'mid' first and accepts the request. At a later point of time, when the server receives the lower numeric 'mid', the request is rejected by the server with 4.09 error response.

-Tiru

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Jan 2019 18:19:53 -0600

> higher numeric 'mid' first and accepts the request. At a later point of time, when the server receives the lower numeric 'mid', the request is rejected by the server with 4.09 error response.

Ah, I guess I was reading too fast; this is already clearly spelled out.

> > [Med] I don't see any inconsistency. Please clarify if I missed your point.

Tiru got it -- error on my part.

> >    JSON/CBOR conversion rules in [RFC7049].  All parameters in the

I would still prefer to see something like "as described below in the
'conflict-information' subtree with only the relevant nodes listed", to try
to forestall any other comments from directorate reviews.

> >       conflict-scope:  Characterizes the exact conflict scope.  It may include a

That's probably a clarification worth making, thanks.

> > "(by an 'acl-name', typically [I-D.ietf-dots-data-channel])"

Ah, thanks.

> > [Med] The text you quoted reminds that the new request will delete the

I was thinking that sometimes the word "override" means that two items are
both present, but one takes precedence over the other during processing;
"deleted" would then mean that only one of the items is present.

> >    returned to indicate a successful update of the mitigation request.

That seems consistent with what we do elsewhere, so sounds good.

> >    larger than about a kilobyte, there is an expectation that they are

Ah, that's quite decisive.  Thanks for pointing me to the reference.

> > [Med] Changed the text to "when an immediate attack mitigation is

That takes care of the disambiguation I was hoping for -- thanks :)

> > We can add some text if needed.

Let's leave it alone for now.

> > [Med] Don't think so. Actually, we are mimicking figure 2 in RFC7641.

Ah, thanks for the reference.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 07:20:40 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Thursday, January 17, 2019 5:50 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; draft-ietf-dots-signal-
> [email-masked]; [email-masked]
> Subject: Re: AD review of draft-ietf-dots-signal-channel-25 (3rd Part)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> > > > overlapped mitigation request with lower 'mid' MUST be deleted
> > > > (BTW, note my rewording), but at the end we are hearing that a
> > > > request to create an overlapping mitgiation must be rejected
> >
> >
> > The example is discussing out of order delivery of mitigation requests
> > (DOTS client sends lower numeric 'mid' followed by higher numeric 'mid'
> but the DOTS server receives the higher numeric 'mid' first and accepts the
> request. At a later point of time, when the server receives the lower numeric
> 'mid', the request is rejected by the server with 4.09 error response.
> 
> > > > later we also say "can be achieved by sending a PUT request [...]
> > > > that will override the existing one with overlapping mitigation scopes"
> > >
> > > > -- conflict-information/-cause/-scope are in the YANG model, but
> > > > do we need to say that the response contains a CBOR representation
> > > > of the subtree starting at conflict-information (or something like
> > > > that), or is this implicitly specified elsewhere in the document?
> > > > For example, Figure 9 has an explicit JSON diagnostic notation for
> > > > a message response.
> > >
> I would still prefer to see something like "as described below in the 'conflict-
> information' subtree with only the relevant nodes listed", to try to forestall
> any other comments from directorate reviews.
> 
> > > >
> > > > This feels a little under-specified -- do we need to include
> > > > exactly the conflicting entries?  Or would we just say something
> > > > like "this conflicts with 'mid' 8; figure it out"?
> > >
> > > > (Do we want "MUST NOT" 2119 language to prevent their inclusion or
> > > > is the current descriptive language sufficient?)
> > > >
> > >
> > > [Med] OK.
> > >
> > > > If the server did not have a check that the other parameters
> > > > match, what would happen?
> > >
> > > [Med] A request may be for example inadvertently transitioned from
> > > pre- configured to immediate and vice versa. To avoid such issues,
> > > the spec mandates the following:
> > >
> > > * a client can update an existing mitigation by echoing the same
> > > parameters as those in the initial mitigation request.
> > >
> > > > conflict with some normal feature-negotiation scheme or is it okay
> > > > to assume that the client will be able to handle this even if the
> > > > client has not explictly indicated support?
> > >

The above change does not look complete, mitigation-start is also a mandatory attribute when a pre-configured mitigation request is triggered after 
the DOTS signal channel session is lost.

Cheers,
-Tiru

> > > > that does not seem quite well-defined.  Is it a rolling
> > > > five-minute average over bins of one second, or a binned
> > > > five-minute average for the last five-minute interval that ends on
> > > > a multiple of '5', or something
> > > else?
> > >
> > > > notification was generated?  (That is, the server's enforcement of
> > > > the MUST NOT may need to be restrained.)
> > >
> > > The text leave it to the server to decide which action to take when
> > > MUST NOT is not followed by a client. The server may decide the
> > > silently ignore those, etc.
> > >
> > > > Does the GET in  Figure 13 need to have a ".well-known" and other
> > > > path components?
> > > >
> > >

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 09:10:05 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 17 janvier 2019 08:21
> À : Benjamin Kaduk
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked];
> [email-masked]
> Objet : RE: AD review of draft-ietf-dots-signal-channel-25 (3rd Part)
> 
> > > > >                                                   To avoid
> maintaining a
> 'conflict-

[Med] Done. 

> > > >       conflict-scope:  Characterizes the exact conflict scope.  It may
> include
> > a
> > > >                        ^^^^^^^^^^^^^^^^^^^^^^^^

[Med] You are right. Even if both are maintained, we do already have this text: 

To avoid maintaining a

No need to repeat it again, IMO.

> The above change does not look complete, mitigation-start is also a mandatory
> attribute when a pre-configured mitigation request is triggered after

[Med] I changed the text to "an attack mitigation is active." to avoid any confusion.