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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : jeudi 17 janvier 2019 08:21
> À : Benjamin Kaduk
> Cc : BOUCADAIR Mohamed TGI/OLN; [e-mail];
> [e-mail]
> Objet : RE: AD review of draft-ietf-dots-signal-channel-25 (3rd Part)
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <[e-mail]>
> > Sent: Thursday, January 17, 2019 5:50 AM
> > To: Konda, Tirumaleswar Reddy <[e-mail]>
> > Cc: [e-mail]; draft-ietf-dots-signal-
> > [e-mail]; [e-mail]
> > 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.
> >
> > On Wed, Jan 16, 2019 at 01:58:30PM +0000, Konda, Tirumaleswar Reddy
> > wrote:
> > > > -----Original Message-----
> > > > From: Dots <[e-mail]> On Behalf Of
> > > > [e-mail]
> > > > Sent: Wednesday, January 16, 2019 6:56 PM
> > > > To: Benjamin Kaduk <[e-mail]>; draft-ietf-dots-signal-
> > > > [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > > > (3rd Part)
> > > >
> > > >
> > > >
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Benjamin Kaduk [mailto:[e-mail]] Envoyé : mercredi 16
> > > > > janvier 2019 01:14 À : [e-mail]
> > > > > Cc : [e-mail]
> > > > > 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
> > >
> > >
> > > 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.
> >
> > Ah, I guess I was reading too fast; this is already clearly spelled out.
> >
> > > -Tiru
> > >
> > > >
> > > > [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.
> >
> > Tiru got it -- error on my part.
> >
> > > > >
> > > > >                  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.
> > > >    ^^^^^^^^^^^^^^^^^^^^^^
> >
> > 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.

[Med] Done. 

> >
> > > > >
> > > > >       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'.
> >
> > That's probably a clarification worth making, thanks.
> >
> > > >
> > > > >
> > > > >          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])"
> >
> > Ah, thanks.
> >
> > > > >
> > > > >                           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.
> >
> > 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.

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

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.

No need to repeat it again, IMO.

> >
> > > > >
> > > > >    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.
> >
> > That seems consistent with what we do elsewhere, so sounds good.
> >
> > > >   (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.
> >
> > Ah, that's quite decisive.  Thanks for pointing me to the reference.
> >
> > > > >
> > > > >       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".
> >
> > That takes care of the disambiguation I was hoping for -- thanks :)
> 
> 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.

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

> 
> >
> > > > >
> > > > > 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.
> >
> > Let's leave it alone for now.
> >
> > > > >
> > > > >    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.
> >
> > Ah, thanks for the reference.
> >
> > -Ben