[Dots] Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 01 May 2019 14:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C99120186; Wed, 1 May 2019 07:32:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-signal-channel@ietf.org, Liang Xia <frank.xialiang@huawei.com>, dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155672115649.991.301467308616633255.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 07:32:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/fXU11oGIe9e35nHlujf6o26QPUI>
Subject: [Dots] Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 01 May 2019 14:32:37 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-dots-signal-channel-31: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thank you for a well written document. Despite its length, it was a pleasure to

I have a list of small issues/questions to discuss before I can recommend
approval of this document.

1) RFC 3986 must be Normative as you use URI syntax in the document.

2) In 4.4.1: base64url needs a Normative reference. Please point to section 5
of RFC 4648.

3) Also in the same section:

   A DOTS gateway MAY add the CoAP Hop-Limit Option

Use of RFC 2119 language makes this reference Normative. Which means that this
document can't be published as an RFC until [I-D.ietf-core-hop-limit] is
published as an RFC.

4) Later in the same section:

   If the request is missing a mandatory attribute, does not include
   'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
   parameters, or contains invalid or unknown parameters, the DOTS
   server MUST reply with 4.00 (Bad Request).  DOTS agents can safely
   ignore comprehension-optional parameters they don't understand.

How can DOTS agents know which parameters are comprehension-optional?

5) In 4.4.2:

   The 'c' (content) parameter and its permitted values defined in
   [I-D.ietf-core-comi] can be used to retrieve non-configuration data

Because you define syntax of the parameter by reference, this makes
[I-D.ietf-core-comi] Normative. (It doesn't matter that the feature is
optional. Implementors still need to look at [I-D.ietf-core-comi] to implement
this aspect of your document.)

If you don't want Normative dependency, you should fully specify syntax in your
draft and keep the reference Informative.

   (attack mitigation status), configuration data, or both.  The DOTS
   server MAY support this optional filtering capability.  It can safely
   ignore it if not supported.  If the DOTS client supports the optional
   filtering capability, it SHOULD use "c=n" query (to get back only the
   dynamically changing data) or "c=c" query (to get back the static
   configuration values) when the DDoS attack is active to limit the
   size of the response.

6) In 4.4.3:

       "ietf-dots-signal-channel:mitigation-scope": {
         "scope": [
             "target-prefix": [
             "target-port-range": [
                 "lower-port": 80
                 "lower-port": 443
                  "lower-port": 8080
             "target-protocol": [
             "attack-status": "under-attack"

This value is invalid, as you define this attribute as numeric on the next page.


7) In 7.1:

   When a DOTS client is configured with a domain name of the DOTS
   server, and connects to its configured DOTS server, the server may
   present it with a PKIX certificate.  In order to ensure proper
   authentication, a DOTS client MUST verify the entire certification
   path per [RFC5280].  The DOTS client additionally uses [RFC6125]
   validation techniques to compare the domain name with the certificate

I am glad that you are referencing RFC 6125 here, but the description is not
complete. Do you allow for wildcards in certificate subjectAltNames? Do you
support CN-ID, DNS-ID, SRV-ID, URI-ID? I think you only want to support DNS-ID
and possibly SRV-ID and CN-ID. This needs to be explicitly stated in the


In Section 3:

   DOTS agents primarily determine that a CBOR data structure is a DOTS
   signal channel object from the application context, such as from the
   port number assigned to the DOTS signal channel.

I don't think this is a good idea, because CORE allows for conveying of
Content-Format. Besides knowledge of a port number doesn't guaranty that valid
CBOR over COAP data is flowing on it.

   The other method
   DOTS agents use to indicate that a CBOR data structure is a DOTS
   signal channel object is the use of the "application/dots+cbor"
   content type (Section 9.3).

Also in the same section:

   This 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 can either follow the rules in [I-D.ietf-core-yang-cbor]
   or those in [RFC7951] combined with JSON/CBOR conversion rules in
   [RFC7049]; both approaches produce a valid encoding.

Does this mean that both approaches are normative to implement? (I assume they
don't procuce identical encoding.)

In 4.1:

Is DHCP option for this defined in another document?

In 4.4.1:


      A lifetime of negative one (-1) indicates indefinite lifetime for
      the mitigation request.  The DOTS server MAY refuse indefinite
      lifetime, for policy reasons; the granted lifetime value is
      returned in the response.  DOTS clients MUST be prepared to not be
      granted mitigations with indefinite lifetimes.

      The DOTS server MUST always indicate the actual lifetime in the
      response and the remaining lifetime in status messages sent to the
      DOTS client.

Can you provide any advice to the server what to return for the “indefinite
lifetime” requests?

In 4.6:

   If the DOTS client has been redirected to a DOTS server to which it
   has already communicated with within the last five (5) minutes, it
   MUST ignore the redirection and try to contact other DOTS servers
   listed in the local configuration or discovered using dynamic means
   such as DHCP or SRV procedures.

You don't define DHCP or SRV based procedures in the document. Is there a
suitable informative reference to be inserted here?  Registration Template

      Registration requests for the 0x4000 - 0x7FFF range are evaluated
      after a three-week review period on the dots-signal-reg-
      review@ietf.org mailing list,

Responsible AD should make sure that the mailing list exists before this
document is published.

      on the advice of one or more
      Designated Experts.