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

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 07:32:36 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

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
   [I-D.ietf-core-hop-limit].

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": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
              ],
             "target-port-range": [
               {
                 "lower-port": 80
               },
               {
                 "lower-port": 443
               },
               {
                  "lower-port": 8080
               }
             ],
             "target-protocol": [
                6
             ],
             "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
   provided.

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
document.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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:

   lifetime:

      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?

9.6.1.1.  Registration Template

      Registration requests for the 0x4000 - 0x7FFF range are evaluated
      after a three-week review period on the dots-signal-reg-
      [email-masked] 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.

---

From: <[email-masked]>
Date: Thu, 2 May 2019 06:54:15 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alexey Melnikov via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 1 mai 2019 16:33
> À : The IESG
> Cc : [email-masked]; Liang Xia; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with
> DISCUSS and COMMENT)
> 

[Med] Thank you. 

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

[Med] Done. 

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

[Med] Ben did also raised this point. Already fixed in my local copy.

> document can't be published as an RFC until [I-D.ietf-core-hop-limit] is

[Med] I'm comfortable to move this one to the normative reverences given that I-D.ietf-core-hop-limit is ready for the WGLC since at least two months.

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

[Med] This is done by looking at the key value:

      Key value for the parameter.  The key value MUST be an integer in
      the 1-65535 range.  The key values of the comprehension-required
      range (0x0001 - 0x3FFF) and of the comprehension-optional range
      (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of
      [RFC8126]).  The key values of the comprehension-optional range
      (0x4000 - 0x7FFF) are assigned by Specification Required
      (Section 4.6 of [RFC8126]) and of the comprehension-optional range
      (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of
      [RFC8126]).

> draft and keep the reference Informative.

[Med] I went with the second approach. Thanks. 

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

[Med] The example is correct because the JSON encoding is as follows:  

   +----------------------+-------------+-----+---------------+--------+
   | Parameter Name       | YANG        | CBOR| CBOR Major    | JSON   |
   |                      | Type        | Key |    Type &     | Type   |
   |                      |             |     | Information   |        |
   +----------------------+-------------+-----+---------------+--------+
   | attack-status        | enumeration |  29 | 0 unsigned    | String |

> and possibly SRV-ID and CN-ID. This needs to be explicitly stated in the

[Med] Fair enough. Will consider updating the text. 

> Content-Format.

[Med] Agree. We are not recommending it. FWIW, this is why we are defining "application/dots+cbor" content type.

 Besides knowledge of a port number doesn't guaranty that
> valid

[Med] No, they are not normative. What is really key is the mapping table included in the spec. Implementers do only need to look at Table 4. We are providing to them the rationale for building such table.

> Is DHCP option for this defined in another document?

[Med] Yes. I added a pointer to I-D.ietf-dots-server-discovery.

> Can you provide any advice to the server what to return for the “indefinite

[Med] This is deployment-specific. 

> suitable informative reference to be inserted here?

[Med] I added a pointer to I-D.ietf-dots-server-discovery.

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 May 2019 01:59:17 -0500

> [Med] The example is correct because the JSON encoding is as follows:

The example is incorrect because it is, as described at the end of 
section 4.4, the "JSON diagnostic notation" of CBOR, not JSON.

/a

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 2 May 2019 09:13:55 +0100

Hi,
Thank you for detailed replies. Quick answer to one of them:

>      (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of

I suggest you either add the above text or a pointer to where this is discussed.

Best Regards,
Alexey

---

From: <[email-masked]>
Date: Thu, 2 May 2019 08:25:01 +0000

Re-,

Updated my local copy with a pointer to that text. Thanks.

Cheers,
Med

> De : Alexey Melnikov [mailto:[email-masked]]
> Envoyé : jeudi 2 mai 2019 10:14
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : The IESG; [email-masked]; Liang Xia; dots-
> [email-masked]; [email-masked]
> Objet : Re: Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> Hi,

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 May 2019 12:47:08 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, May 2, 2019 12:24 PM
> To: Alexey Melnikov <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Liang Xia
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Dots] Alexey Melnikov's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Alexey Melnikov via Datatracker [mailto:[email-masked]] Envoyé
> > : mercredi 1 mai 2019 16:33 À : The IESG Cc :
> > [email-masked]; Liang Xia; dots-
> > [email-masked]; [email-masked]; [email-masked] Objet :
> > Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with
> > DISCUSS and COMMENT)
> >
> > 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
> > Thank you for a well written document. Despite its length, it was a
> > pleasure to read.
> >
> 
> [Med] Thank you.
> 
> > Use of RFC 2119 language makes this reference Normative. Which means
> that
> > this
> [Med] I'm comfortable to move this one to the normative reverences given
> that I-D.ietf-core-hop-limit is ready for the WGLC since at least two months.
> 
> >
> > support CN-ID, DNS-ID, SRV-ID, URI-ID? I think you only want to support
> DNS-
> > ID

We will add the following text to address the above comment:

      Certification authorities that issue DOTS server certificates
      SHOULD support the DNS-ID and SRV-ID identifier types. 
      DOTS server SHOULD prefer the use of DNS-ID  and SRV-ID 
      over CN-ID identifier types in certificate requests 
      (as described in Section 2.3 from [RFC6125]) and the
      wildcard character '*' SHOULD NOT be included in the presented
      identifier.

Cheers,
-Tiru

> [Med] Agree. We are not recommending it. FWIW, this is why we are
> defining "application/dots+cbor" content type.
> 
> > Does this mean that both approaches are normative to implement? (I
> assume
> > they
> [Med] No, they are not normative. What is really key is the mapping table
> included in the spec. Implementers do only need to look at Table 4. We are
> providing to them the rationale for building such table.
> 
> >
> > In 4.1:
> >
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 02 May 2019 08:55:49 -0400

Hi,

On Thu, May 2, 2019, at 1:47 PM, Konda, Tirumaleswar Reddy wrote:

> > > DNS-ID

This still doesn't say whether URI-ID is allowed. May I suggest that you add the following sentence at the beginning of this paragraph:

       DOTS protocol doesn't use URI-IDs for server identity verification.

Also, I would like to understand how SRV-IDs are to be used by DOTS. The document doesn't register any new service name for DOTS protcol, so it is not clear how SRV-IDs can be used.

Thank you,
Alexey

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 May 2019 13:02:34 +0000

> From: Alexey Melnikov <[email-masked]>
> Sent: Thursday, May 2, 2019 6:26 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>;
> [email-masked]; The IESG <[email-masked]>
> Cc: [email-masked]; Xialiang
> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31:
> 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.
> 
> Hi,
> 
> > > > 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
> > > > document.
> > > >
> > >
> This still doesn't say whether URI-ID is allowed. May I suggest that you add
> the following sentence at the beginning of this paragraph:
> 

Thanks, will update. 

> 
> Also, I would like to understand how SRV-IDs are to be used by DOTS. The
> document doesn't register any new service name for DOTS protcol, so it is
> not clear how SRV-IDs can be used.

SRV-ID is discussed in https://tools.ietf.org/html/draft-ietf-dots-server-discovery-01 

-Tiru

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 12:15:05 -0500

> [Med] Agree. We are not recommending it. FWIW, this is why we are defining "application/dots+cbor" content type.

Perhaps the word "primarily" is not quite right, then?

-Ben