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

<mohamed.boucadair@orange.com> Tue, 02 July 2019 08:28 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6921712001E; Tue, 2 Jul 2019 01:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GllBgdfDAGUG; Tue, 2 Jul 2019 01:28:56 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E68B12001B; Tue, 2 Jul 2019 01:28:56 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45dHT24wQCz2yJW; Tue, 2 Jul 2019 10:28:54 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 45dHT23QBSzCqkM; Tue, 2 Jul 2019 10:28:54 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([fe80::d9:d3cd:85bd:d331%21]) with mapi id 14.03.0439.000; Tue, 2 Jul 2019 10:28:54 +0200
From: <mohamed.boucadair@orange.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>
Thread-Topic: additional remaining items for draft-ietf-dots-signal-channel-31
Thread-Index: AQHVLjALcPOxQ2v8VkC8/aP/z5+7kKa27pPQ
Date: Tue, 2 Jul 2019 08:28:54 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAB0DC2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <20190629040618.GJ10013@kduck.mit.edu>
In-Reply-To: <20190629040618.GJ10013@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/CeNsBDwobV8_V-DIMt1lJePl-vs>
Subject: Re: [Dots] additional remaining items for draft-ietf-dots-signal-channel-31
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2019 08:28:59 -0000

Hi Ben, 

Please see inline. 

Cheers,
Tiru & Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoyé : samedi 29 juin 2019 06:06
> À : draft-ietf-dots-signal-channel@ietf.org
> Cc : The IESG; frank.xialiang@huawei.com; dots@ietf.org; dots-
> chairs@ietf.org
> 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 dots-signal-reg-review@ietf.org 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