Re: [Dots] additional remaining items for draft-ietf-dots-signal-channel-31

[<[e-mail]>]

Hi Ben, 

Please see inline. 

Cheers,
Tiru & Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : samedi 29 juin 2019 06:06
> À : [e-mail]
> Cc : The IESG; [e-mail]; [e-mail]; dots-
> [e-mail]
> Objet : Re: additional remaining items for draft-ietf-dots-signal-channel-
> 31
> 
> On Fri, Jun 28, 2019 at 05:21:24PM -0500, Benjamin Kaduk wrote:
> > Hi Mirja,
> >
> > I wanted to check in with the status of the remaining Discuss points for
> > this document.  I tried to go through the previous discussions and have
> > made my own analysis of where things stand, so hopefully we can compare
> > notes.
> 
> In addition to Mirja's pending Discuss position, there are some other
> points that we should probably update in the document from other IESG
> review comments.
> 
> I still need to ensure that the [e-mail] list
> exists
> in time for it to be used for registration requests.
> 
> The order of the If-Match: and Content-Format: header fields changed
> between the -31 and the -34; is that order important?

[Med] No, that change was made for the reader's convenience (place the content format near the payload). (PS: because a delta option number is used, the coap library will sort the options in ascending order of their option number).  

> 
> Section 4.7 added text:
> 
>    If the DOTS server receives traffic from the peer DOTS client (e.g.,
>    peer DOTS client initiated heartbeats) but maximum 'missing-hb-
>    allowed' threshold is reached, the DOTS server MUST NOT consider the
>    DOTS signal channel session disconnected.  The DOTS server MUST keep
>    on using the current DOTS signal channel session so that the DOTS
>    client can send mitigation requests over the current DOTS signal
>    channel session.  In this case, the DOTS server can identify the DOTS
>    client is under attack and the inbound link to the DOTS client
>    (domain) is saturated.  Furthermore, if the DOTS server does not
>    receive a mitigation request from the DOTS client, it implies the
>    DOTS client has not detected the attack or, if an attack mitigation
>    is in progress, it implies the applied DDoS mitigation actions are
>    not yet effective to handle the DDoS attack volume.
> 
> Is the server supposed to start mitigation when it identifies that the
> client is under attack but the client has not requested mitigation?

[Med] No, an explicit mitigation is still required from the client (the signal channel is not lost). 

> 
> RFC 8305 needs to be normative since we use its rules for connection
> attempts.

[Med] OK. 

> 
> I still think that section 6 (in addition to the current "Note:
> implementors must check" text) should specifically call out that the CBOR
> and JSON types for enumerateds and the 64-bit quantities can differ in
> surprising ways depending on the encoder used, as a potential hazard to
> use
> caution with.

[Med] Will add a note. 

> 
> Section 4.4.1 lists a recommended procedure for 'cuid' generation:
> 
>          For the reasons discussed in Appendix A, implementations SHOULD
>          set 'cuid' to the output of a cryptographic hash algorithm
>          whose input is the Distinguished Encoding Rules (DER)-encoded
>          Abstract Syntax Notation One (ASN.1) representation of the
>          Subject Public Key Info (SPKI) of the DOTS client X.509
>          certificate [RFC5280], the DOTS client raw public key
>          [RFC7250], or the "Pre-Shared Key (PSK) identity" used by the
>          DOTS client in the TLS ClientKeyExchange message.  In this
>          version of the specification, the cryptographic hash algorithm
>          used is SHA-256 [RFC6234].  The output of the cryptographic
>          hash algorithm is truncated to 16 bytes; truncation is done by
>          stripping off the final 16 bytes.  The truncated output is
>          base64url encoded (Section 5 of [RFC4648]) with the trailing
>          "=" removed from the encoding.
> 
> In the ballot discussion we heard that all parts of this are just
> recommendations (i.e., there is no requirement to base64 or strip padding
> or use SHA-256, etc.).  This could perhaps be clarified by changing to:
> 
>     For the reasons discussed in Appendix A, implementations SHOULD set
> 'cuid'
>     using the following procedure: first, the Distinguished Encoding Rules
>     (DER)-encoded Abstract Syntax Notation One (ASN.1) representation of
> the
>     Subject Public Key Info (SPKI) of the DOTS client X.509 certificate
>     [RFC5280], the DOTS client raw public key [RFC7250], or the "Pre-
> Shared Key
>     (PSK) identity" used by the DOTS client in the TLS ClientKeyExchange
>     message is input to the SHA-256 [RFC6234] cryptographic hash.  Then,
>     the output of the cryptographic hash algorithm is truncated to 16
>     bytes; truncation is done by stripping off the final 16 bytes.  The
>     truncated output is base64url encoded (Section 5 of [RFC4648]) with
> the
>     trailing "=" removed from the encoding, and the resulting value used
> as
>     the 'cuid'.
> 
> which makes very clear that the "SHOULD" applies to the entire procedure,
> and not just to the "output of a cryptographic hash algorithm" with the
> normativity of the other steps being less well specified.  (This also
> inlines the use of SHA-256, since this is the only specification we're
> talking about.)

[Med] OK.

> 
> Mirja had a note about the retry-timer and the 45-second addition.  IIUC
> the mitgation remains deactivated for the entire retry-timer plus 45
> seconds and then is deleted afterwards,

[Med] Yes. 

         If the DOTS server decides to maintain a state for the
         deactivated mitigation request, the DOTS server updates the
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         lifetime of the deactivated mitigation request to (retry-timer
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         + 45 seconds) so that the DOTS client can refresh the
         ^^^^^^^^^^^^
         deactivated mitigation request after 'retry-timer' seconds, but
         before the expiry of the lifetime, and check if the conflict is
         resolved.

We can add this NEW text to be more explicit (but IMHO, this will be redundant):

NEW:
   Note that the mitigation request remains deactivated
   for the entire duration of (retry-timer + 45 seconds).


 but I think Mirja would still like
> that behavior clarified in the text.
> 
> The ballot discussions indicated that we needed some text about using
> Non-Confirmable messages because that overrides behavior in RFC 7641; we
> should be more explicit that we are overriding that behavior.

[Med] We do have this text: 

   Unidirectional mitigation notifications within the bidirectional
   signal channel enables asynchronous notifications between the agents.
   [RFC7641] indicates that (1) a notification can be sent in a
   ^^^^^^^^
   Confirmable or a Non-confirmable message, and (2) the message type
   used is typically application-dependent and may be determined by the
   server for each notification individually.  For DOTS server
   application, the message type MUST always be set to Non-confirmable
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^     
   even if the underlying COAP library elects a notification to be sent
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   in a Confirmable message.

We can add this NEW text:  

   This overrides the behavior defined in
   Section 4.5 of [RFC7641] to send a Confirmable message instead of a
   Non-confirmable message at least every 24 hour for the following
   reasons: First, the DOTS signal channel uses a heartbeat mechanism to
   determine if the DOTS client is alive.  Second, Confirmable messages
   are not suitable during an attack.

> 
> The question of whether the active-but-terminating period is hard-capped
> at
> 300 seconds seems to remain unanswered.

[Med] It is. The text says the following:

   "... the active-but-terminating
   period up to a maximum of 300 seconds (5 minutes)."


> 
> In section 4.5 the mention of CoAP ping/pong was removed but no
> clarification or pointer to 7252 section 4.2 was added (which was
> requested
> by one of the reviews).

[Med] That comment was addressed by this text in Section 4.5.2:

   Section 4.2 of [RFC7252] defines a "CoAP Ping" mechanism.
   Concretely, the DOTS agent sends an Empty Confirmable message and the
   peer DOTS agent will respond by sending a Reset message. 

> 
> There's also a couple typos left:
> 
> s/implictily/implicitly/
> 
> s/10 mn/10 min/
> 

[Med] Fixed in my local copy.  

> Thanks for all the great work getting this document over the finish line!
> 
> -Ben