Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-rfc8782-bis-08

[S3] [comment]

* I don't know if it's really necessary to dredge up RFC 6296, but I
  understand the desire for completeness.

[S4.4.1.1] [question]

* For "lifetime" in the case where a "target-fqdn" was given, should the
  resolution library's knowledge of the DNS RR TTL value(s) be factored in?

  For example, what does lifetime=3600s mean for a hostname whose A/AAAA
  RRs have only 5 minute lifetimes?  Is the DOTS server/enforcer expected
  to continuously re-resolve every ${DNS_RR_TTL} and apply the policy for
  up to the full 3600 seconds, or is the DNS RR TTL ignored once the
  resolution has been confirmed to have succeeded or failed?

I also only reviewed the diff to RFC 8782.  (I really love that feature.)

The shepherd writeup omits an answer to the question "Why is this the proper type of RFC?"  Fortunately it's obvious here, but it would be better to be clear about it generally.

In Section 3.1:

   The main changes to [RFC8782] are listed in Appendix A.  These	
   modifications are made with the constraint to avoid changes to the	
   mapping table defined in Table 5 of [RFC8782] (see also Section 6).

Section 6 of which document?

In Section 10.1: s/docuement/document/

Thanks to Donald Eastlake for the SECDIR review.

Thank you for the work put into this document. 

As I already reviewed the original RFC 8782, I have only review the diffs (thanks to RFCDIFF!).

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3.1 --
In "that follow the present specification", the use of "present" is ambiguous: does it mean current implementations of RFC 8782? or this specification (i.e., this I-D) ?

-- Section 4.4.1.3 --
I wonder why a port number can be used if the case of common/shared URI ? In "A list of port numbers may also be included if there is a common IP address, IP prefix, FQDN, URI, or alias."
         
-- Section 5.3 --
I am not a YANG module expert but using a union for 'lifetime' just to allow a -1 value to signal infinity looks a little weird to me. Could the value 0x7fffffff be used for 'infinity' and keeping a uint32 ?

In probing-rate.current-value, there is a default value of 5 byte/second. Is it useful to recommend such a default value ?

More generically, I wonder whether measuring in octets/second is more suitable than in bits/second.

The 'alt-server' is now better typed as 'inet:domain-name' but I now wonder whether relying solely on DNS in a case of DoS is sensible.

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.3, paragraph 2, nit:
-    connectionless and connection-oriented protocols.  As such, the DOTS
+    connection-less and connection-oriented protocols.  As such, the DOTS
+              +

Section 4.4.1.1, paragraph 39, nit:
-       The use of FQDNs may be suboptimal because:
+       The use of FQDNs may be suboptimal, because:
+                                         +

Section 5.3, paragraph 26, nit:
-                 Ths is is a mandatory attribute when a client
-                   --
+                 This is a mandatory attribute when a client

Section 10.1, paragraph 3, nit:
-    assigned to this docuement:
-                         -
+    assigned to this document:

Section 1, paragraph 5, nit:
> lient. The DOTS server may or may not not be co-located with the DOTS mitiga
>                                   ^^^^^^^
Double negatives are discouraged in standard English. Can you reformulate this
phrase or is a comma missing?

Section 4.4.1.1, paragraph 3, nit:
> ys MUST handle 'cuid' collision directly and it is RECOMMENDED that 'cuid' c
>                                 ^^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.4.3, paragraph 6, nit:
> DOTS client will send a Reset | message so it does not receive any more retra
>                                 ^^^^^^^^^^
Use a comma before 'so' if it connects two independent clauses (unless they are
closely connected and short).

Section 4.5.1, paragraph 22, nit:
> rtbeat frequency. It is NOT RECOMMENDED to return a Max-Age Option set to 0.
>                             ^^^^^^^^^^^^^^^^^^^^^
The verb 'RECOMMENDED' is used with the gerund form: "RECOMMENDED returning".

Section 6, paragraph 5, nit:
> S server when the Content-Format is used but the request is not formatted as
>                                     ^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 6, paragraph 5, nit:
> ' URI IANA is requested to update the the 'dots' well-known URI (Table 6) en
>                                   ^^^^^^^
Possible typo: you repeated a word

Obsolete reference to RFC5246, obsoleted by RFC8446.

Document references draft-ietf-dots-multihoming-05, but -06 is the latest
available revision.

Document references draft-ietf-dots-telemetry-15, but -16 is the latest
available revision.

Document references draft-ietf-dots-use-cases, but that has been published as
RFC8903.

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
 * http://www.iana.org/assignments/media-types
 * http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
 * http://www.iana.org/assignments/protocol-numbers

Thank you for addressing Michael Tuexen's TSVART review.

As I did not review RFC8782, I'm taking this opportunity to review the entire document, rather than just the bis. I found numerous clarity issues:

(4.4.1.1) How do DOTS servers detect a CUID collision? I believe Sec. 7 explains this is based on client authentication, but mentioning it here would be helpful.

In the "mid" definition: s/no attack is detected/no attack is underway

In the "target_fqdn" definition. The text appears to assume a DNS resolution; is there a not a use case where the DOTS server would rely on e.g. SNI inspection and not defend an entire IP address that had multiple domains?

"lifetime" definition: The text says the DOTS server MAY reject unlimited lifetime, which implies that it MUST accept any finite lifetime. I presume you mean to say that DOTS servers are free to set a policy limit on the maximum allowable lifetime?

(4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that matches the cuid. The text indicates that these might not match if a client-side gateway added the cdid, but then later says that "only the first on-path server-domain DOTS gateway can  insert a 'cdid' value." After reading this a few times, I think what you are saying is (a) clients MUST NOT add cdid; (b) client-side gateways SHOULD add them; (c) the first server-side gateway MUST strip them and then add their own; and (d) subsequent server side gateways MUST NOT change the cdid. Is this correct? Either way, it could be expressed less confusingly.

(4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by the server on behalf of the client? If so, I recommend s/a new request with a new 'cuid'/a new request with a new, server-provided 'cuid'

When extending the lifetime, does the new lifetime field measure from the initial trigger or from the moment of extension? If the former, a change in the lifetime value is mandatory, not "potential." If the latter, how does the server distinguish this from a duplicate request?

(4.4.2) Fig. 14 uses a string to represent the status instead of one of the values in Table 3.

(4.4.3) Same with Fig. 16 and Table 4.

(4.4.2.1) If updates are non-confirmable, how does the client know if it's gotten out of sync on state updates?

(4.5.1) What is the unit of probing rate?

(8) s/should/SHOULD, s/must/MUST throughout.

Hi,

I only reviewed the delta from RFC 8782.  Just a couple of minor comments.

I think that the revision description in the ietf-dots-signal-channel YANG module should clearly indicate that it is a non-backwards compatible replacement of the previous module revision. 

The description of the "dots-signal" structure and "message-type" choice makes no mention of the "heartbeat" case.  Is that intentional?

Thanks,
Rob