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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

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

[Med] Thank you. 

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

[Med] Done. 

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

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

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

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

> 
> 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?

[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]).

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

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


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

[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 |

> 
>            }
>          ]
>        }
>       }
> 
> 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.
> 

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

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

[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
> 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.)

[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:
> 
> Is DHCP option for this defined in another document?

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

> 
> 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?

[Med] This is deployment-specific. 

> 
> 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?

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

> 
> 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-
>       [e-mail] 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.
>