Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
draft-ietf-dots-signal-channel-41

[Ballot comment]
Thanks a lot for addressing my many discuss points and all the additional work that went into this spec!

-------------------
OLD COMMENTS (for the record as I didn't check anymore if they have been addressed or not):

1) I really recommend to add subsections to section 4.4.1.

2) section 4.4.1: "The lifetime of the
        deactivated mitigation request will be updated to (retry-timer
        + 45 seconds), so the DOTS client can refresh the deactivated
        mitigation request after retry-timer seconds before expiry of
        lifetime and check if the conflict is resolved."
This wording is not fully clear to me. If the life time of a deactivated request in updated, isn't it active again? And if it is active and another request is sent, isn't that request rejected again. Can you please further clarify.

3) section 4.4.2: "lifetime:  The remaining lifetime of the mitigation request, in
      seconds."
Shouldn't lifetime we rather a timestamp because there is some unknown transmission delay between the time when the reply is generated and the reply is received, and as such a lifetime in seconds is quite meaningless for the client.

4) section 4.4.2.1: " 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."
I'm not sure I understand this sentence. Can you please further explain?

5) section 4.4.4: "For example, if there is a financial
  relationship between the DOTS client and server domains, the DOTS
  client stops incurring cost at this point."
I find this sentence a bit problematic given the active-but-terminating period is defined by server. Wouldn't that mean the server can make me pay for undefined period of time? Also the max of 300 sec doesn't seem to be a MUST...?

6) In section Section 4.5 you talk about Caop Ping/Pong. However, these terms are not used in RFC7252. Maybe clarify that empty confirmable  messages are used and provide a pointer to section 4.2. of RFC7252 right here (instead of only later).

7) High-level question: Given this doc specifies a YANG model, why are configuration are not retrieved and changed using NETCONF or RESTCONF?

[Ballot comment]

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

[Ballot comment]
Full Disclosure.  I was the WG co-chair when this draft was developed.  Based on feedback, I'm changing my ballot from No Objection to Recuse to remove any perceived COI.

A few minor items:

(1) Typos:

Section 3: s/signalling/signaling/
Section 4.4.1: s/implictily/implicitly/

(2) Section 7.1, Per “The DOTS client additionally uses [RFC6125] validation techniques to compare the domain name with the certificate provided”, this sentence appears to be missing a RFC2119 word – should it read something like “Additionally, the DOTS client MUST use [RFC6125] validation …”?

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

Based on  I've updated my DISCUSS/comments:

1)-6) resolved

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.

8) In Section 3:

  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.

This reads like there are 2 possible encodings, both of which are mandatory to implement.
Firstly, I don't think that having 2 encodings is a good idea, but if the WG really needs this, I will remove this part of my DISCUSS.
Secondly, this means that [I-D.ietf-core-yang-cbor] must be Normative.

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

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?

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

[Ballot discuss]
Thanks for all the work everyone put into this document. I think it's great to
have a solution defined for automating these kinds of operations, and look
forward to widespread deployment of this technology. I do have a small number
of comments that I think we need to close on prior to publication, and a
handful of other suggestions of varying (but lesser) importance.

---------------------------------------------------------------------------

This is a discuss because the current document attempts to override normative
language in an external document.

§4.3:

>  In reference to Figure 4, the DOTS client sends two TCP SYNs and two
>  DTLS ClientHello messages at the same time over IPv6 and IPv4.

This is problematic for the reason described in RFC 8305 §5 ("In order to
avoid unreasonable network load, connection attempts SHOULD NOT be made
simultaneously").

To be clear, my discuss is only on the fact that this document violates a
normative statement in RFC 8305. The following comments are merely my thoughts
on the best way to resolve this issue.

It's also worth noting that RFC 8305 is geared towards getting users the fastest
possible response to a user action, while the text in DOTS implies that the
selection of the "most preferred" connection is significantly more important
(e.g., it talks about migrating from TCP to UDP, and performing periodic checks
to enable such a migration). This factor, combined with the fact that this is
not a transaction that involves user interactivity requirements, would seem to
increase, rather than decrease, the desire to space out checks across the
various transport/address-family pairs.

My strong recommendation would be remove the specific description of
happy-eyeballs-like behavior from this document, and to instead defer all such
specification to the text in RFC 8305. I would further recommend specification
of a "Connection Attempt Delay" (as that term is defined in RFC 8305) that is
substantially larger than those used for interactive connections: something on
the order of 2 to 5 seconds would be my suggestion.

Of course, be sure to adjust the example to match the specified handling.


---------------------------------------------------------------------------

This is a discuss because it impacts interoperability.

§4.4.1:

>  target-uri:  A list of Uniform Resource Identifiers (URIs) [RFC3986]
>    identifying resources under attack.

This definition needs to be clearer about what parts of the URI are used for
what purposes. For example:

- The URI scheme can be taken to specify a 'target-protocol'
- The URI host can be taken to specify a 'target-fqdn' or 'target-prefix'
- The URI port (or scheme, if absent) can be taken to specify a
  'target-port-range'

It is unclear whether this specification intends the URI to impact one, two, or
all three of these. This can result in a client asking for one thing and the
server doing something else.

---------------------------------------------------------------------------

This is a discuss because it impacts interoperability.

§6:

The handling of 64-bit values in Table 4 seems problematic. Section 3
specifies:

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

However, if we consider, say, mitigation-start:

>  +----------------------+-------------+-----+---------------+--------+
>  | Parameter Name      | YANG        | CBOR| CBOR Major    | JSON  |
>  |                      | Type        | Key |    Type &    | Type  |
>  |                      |            |    | Information  |        |
>  +----------------------+-------------+-----+---------------+--------+
> ...
>  | mitigation-start    | uint64      |  15 | 0 unsigned    | String |


If an implementation follows the first path (draft-ietf-core-yang-cbor), then
this value is sent on the wire as a CBOR 64-bit unsigned integer type. If an
implementation instead uses RFC 7951 followed by RFC 7049 §4, the resulting
value is encoded on the wire as a CBOR string.

If this is the intention, then it represents a huge gotcha for implementors of
both clients and of servers, as all implementations must be ready to accept
both strings and 64-bit data types for these fields. If this is the
intention, please add strongly-worded text warning implementors of this
particular gotcha, since it's pretty non-obvious.

It's worth noting that, while some implementations may set limits on the
precision of JSON Numbers, and that such limits may be smaller than 64 bits,
nothing in the format defined by RFC 8259 has any such inherent limitations.

There is a similar (but subtly different) problem with the handling of
enumerations that may cause them to be encoded as either strings or as integers:

>  | status              | enumeration |  16 | 0 unsigned    | String |

If you choose to maintain the situation currently described in the document,
then the table in section 9.6.1.2 needs to be updated to allow both formats;
e.g.:

>  +----------------------+-------+-------+------------+---------------+
>  | Parameter Name      | CBOR  | CBOR  | Change    | Specification |
>  |                      | Key  | Major | Controller | Document(s)  |
>  |                      | Value | Type  |            |              |
>  +----------------------+-------+-------+------------+---------------+
...
>  | mitigation-start    |  15  | 0 or 3|    IESG    |  [RFCXXXX]  |

[Ballot comment]
§3:

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

Nit: "...structure as a..."

---------------------------------------------------------------------------

§4.4.1:

>    Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body
>                                Schema)

This seems to be a very informal sketch rather than a formal schema.
It's probably worth calling forward to Section 6 as the formal definition of
the schema, and being clearer that this figure (and other similar figures) are
non-normative sketches of the rough structure.

---------------------------------------------------------------------------

§4.4.1:

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

It's not clear how much of this is a recommendation and how much of it is
mandatory. For example: if I'm a server, would it be reasonable for me to expect
the CUID to be BASE-64 (e.g., to minimize the size of an index structure) and
error out if it contains characters other than those allowed in base64url?

It's also not clear that "SHOULD" is entirely called for here, especially since
the following paragraph's statement that 'cuid' can vary based on remote host
(which requires a variation from the normative algorithm). Consider the
definition of SHOULD:

  3. SHOULD  This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This seems potentially stronger than what is called for here. Consider
specifying this behavior non-normatively, and reserve the normative language for
the actual requirement (e.g., "MUST be globally unique")

---------------------------------------------------------------------------

§4.4.1:

>    As a reminder, the prefix length must be less than or equal to 32
>    (resp. 128) for IPv4 (resp.  IPv6).

This is a notation that I haven't seen before, and it may serve to confuse
implementors. Consider rephrasing as: "...less than or equal to 32 for IPv4, and
less than or equal to 128 for IPv6."

---------------------------------------------------------------------------

§4.4.1:

>  This PUT request MUST use the
>  same 'mid' value, and MUST repeat all the other parameters as sent in
>  the original mitigation request apart from a possible change to the
>  lifetime parameter value.

Is the server intended to detect violations of this? How would it react?
(Section 4.4.3 says to send a 4.00 if the request was an Efficacy Update; this
is probably the correct general answer, and should be specified here).

---------------------------------------------------------------------------

§4.4.2:

>  {
>    "ietf-dots-signal-channel:mitigation-scope": {
>      "scope": [
>        {
>          "mid": 12332,
>          "mitigation-start": "1507818434",
>          "target-prefix": [
>              "2001:db8:6401::1/128",
>              "2001:db8:6401::2/128"
>          ],
>          "target-protocol": [
>            17
>          ],
>          "lifetime": 1756,
>          "status": "attack-successfully-mitigated",
>          "bytes-dropped": "134334555",
>          "bps-dropped": "43344",
>          "pkts-dropped": "333334444",
>          "pps-dropped": "432432"
>        },
>        {
>          "mid": 12333,
>          "mitigation-start": "1507818393",
>          "target-prefix": [
>              "2001:db8:6401::1/128",
>              "2001:db8:6401::2/128"
>          ],
>          "target-protocol": [
>            6
>          ],
>          "lifetime": 1755,
>          "status": "attack-stopped",
>          "bytes-dropped": "0",
>          "bps-dropped": "0",
>          "pkts-dropped": "0",
>          "pps-dropped": "0"
>        }
>      ]
>    }
>  }

I get that this is intended to be an informal example, but the use of quotes
around values that are formally encoded as integers -- such as
"mitigation-start" -- may trip up users. I would strongly suggest removing
quotes from anything encoded as an integer.

This applies especially to "status". Since these figures have explicitly been
called out as JSON diagnostic notation (and *not* the JSON structure produced
by RFC 7951), the values need to be the CBOR values sent on the wire. (This
relies on an assumption on my part that may be incorrect, depending on the
resolution of the points I raise about section 6 in my DISCUSS).

This comment applies to several other examples, such as Figure 16.

For Figure 20 (and several subsequent figures), it also applies to those
values encoded as decimals, such as "max-value-decimal".

---------------------------------------------------------------------------

§4.4.2:

>  bps-dropped:  The average number of dropped bytes per second for the
>    mitigation request since the attack mitigation is triggered.  This
>    average SHOULD be over five-minute intervals.

The first sentence conflicts with the second:
- The first sentence says this is the average since mitigation was triggered.
- The second sentence says this is a five-minute (rolling?) average.

Please make them agree with each other.

If something more subtle is meant -- like measuring bytes into five-minute
buckets and then averaging these buckets over the time since the mitigation
was triggered -- then the text needs more detail to convey it.

This same comment applies to "pps-dropped," as well as the descriptions of both
properties in §5.3.

---------------------------------------------------------------------------

§5.1:

>  A DOTS signal
>  message can either be a mitigation or a configuration message.

This is at odds with both the tree and the text in the YANG module in §5.3,
both of which specify three message types rather than two (mitigation,
configuration, and redirect).

---------------------------------------------------------------------------

§5.1:

>          |    +--ro bps-dropped?            yang:zero-based-counter64
...
>          |    +--ro pps-dropped?            yang:zero-based-counter64

These aren't counters in the way that RFC 6021 defines counters. Both need to be
of type "yang:gauge64." This comment, of course, also bears on §5.3 as well as
Table 4.

---------------------------------------------------------------------------

§6:

>  | trigger-mitigation  | boolean    |  45 | 7 bits 20    | False  |
>  |                      |            |    | 7 bits 21    | True  |

You might consider cleaning up the JSON column here to just say "Boolean," as
"True" and "False" are values rather than any of the six types defined in RFC
8259.  Similarly, to be consistent with the rest of the table, perhaps the
CBOR column here should simply say "7 simple value". Failing that, consider at
least labeling the CBOR values as "False" and "True" rather than "bits 20" and
"bits 21".

[Ballot discuss]
= Section 3 =

"By default, a DOTS signal channel MUST run over port number TBD as
  defined in Section 9.1, for both UDP and TCP, unless the DOTS server
  has a mutual agreement with its DOTS clients to use a different port
  number.  DOTS clients MAY alternatively support means to dynamically
  discover the ports used by their DOTS servers (e.g.,
  [I-D.boucadair-dots-server-discovery])."

MUST implies an absolute requirement, so "MUST ... unless" is a problematic construction. Furthermore, it doesn't make sense together with "MAY alternatively," which indicates that port number discovery is an alternative to the fixed to-be-assigned port.

I didn't have time to get very far into draft-boucadair-dots-server-discovery, but it appears that it does not mandate support for any single discovery mechanism for clients and servers to support. If so, that "alternatively" seems like more of a problem, since it allows for there to be no interoperable mechanism for clients to discover server ports. I think maybe what was intended here was:

s/MUST/SHOULD/
s/MAY alternatively/MAY additionally/

= Section 4.4.1 =

(1)
"In deployments where server-domain DOTS gateways are enabled,
  identity information about the origin source client domain SHOULD be
  propagated to the DOTS server.  That information is meant to assist
  the DOTS server to enforce some policies such as grouping DOTS
  clients that belong to the same DOTS domain, limiting the number of
  DOTS requests, and identifying the mitigation scope.  These policies
  can be enforced per-client, per-client domain, or both.  Also, the
  identity information may be used for auditing and debugging purposes."

Does "identity information" just refer to cdid, or something else?

(2) The constructions "MUST ... (absent explicit policy/configuration otherwise)" are problematic. I'm assuming these are meant to be SHOULDs.

= Section 13.1 =

I don't understand why RFC 7951 is a normative reference but draft-ietf-core-yang-cbor is an informative reference.

[Ballot comment]
= Section 4.4.1 =

"The 'cuid' is intended to be stable when communicating with a
      given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD
      NOT change over time. "
   
Why is this the recommended behavior?

[Ballot discuss]
1) Port usage (see section 3):
The port request for DOTS was reviewed by the port expert team. Some members of the team were concerned about the assignment of a separate port number for DOTS as Coap is used and already has a designated port number. I believe that Coap is used as a transport in the case and DOTS provides a separate service compared to what Coap is usually used for, however, it is not clear why DOTS needs a designated port. Section 3 says that the port can either be preconfigured or dynamically detected, therefore it is not clear why a fixed port is needed (see also section 7.1. of RFC7605). In the port review process the authored argued that a port is needed to differentiate the DOTS service in the network. However, this is not an endorsed usage for port numbers (see section 6.2. of RFC7605). Further, I believe assigning a fixed port might actually add an attack vector for DOTS, either by DDoSing the respective port at the DOTS server, or any attempt to block DOTS traffic on the network from the DOTS client to the DOTS server.

2) Section 4.3 says:
"In reference to Figure 4, the DOTS client sends two TCP SYNs and two
  DTLS ClientHello messages at the same time over IPv6 and IPv4."
However, RFC8305 explicitly states that connection attempts SHOULD NOT be made simultaneously (see sec 5).

Further Figure 4 shows a different order of request as recommended in the text (text says: "UDP over IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4"). Also why are the UDP connection attempts repeated? I guess that is meant to be the retransmission of the DTLS Hello? However, usually you should receive the TCP SYNACK before you retransmit or in the best case even before you start the next connection attempt. Therefore that should be not displayed like this in the figure or needs further explanation.

3) Why are these statements SHOULDs and not MUSTs (see section 4.4)?
  "DOTS agents SHOULD follow the data transmission guidelines discussed
  in Section 3.1.3 of [RFC8085] and control transmission behavior by
  not sending more than one UDP datagram per round-trip time (RTT) to
  the peer DOTS agent on average."
and
  "If the DOTS client cannot maintain an RTT estimate, it
  SHOULD NOT send more than one Non-confirmable request every 3
  seconds"
as well as in section 4.4.2.1:
  "If the DOTS server cannot maintain an RTT
  estimate, it SHOULD NOT send more than one asynchronous notification
  every 3 seconds"
and again in section 4.4.2.2:
"The frequency of polling the DOTS server to get the
  mitigation status SHOULD follow the transmission guidelines in
  Section 3.1.3 of [RFC8085].
However, most of the communication pattern used by DOTS rely on a request/reply pattern and Coap specifies for this case that only one request can be outstanding at a time (until the reply is received or message is assumed to be lost) (see section 4.7 and 4.2 of RFC7252) which therefore will be used in this case. Only migration updates are send without reply, and here a MUST would be more appropriate.

Please also note that if there can only be one request outstanding (before a reply is received) it is also not possible that requests are received out of order (see e.g. 4.4.3: "If UDP is used as transport, CoAP requests may arrive out-of-order.").

4) draft-ietf-core-hop-limit is used in section 10:
"The presence of DOTS gateways may lead to infinite forwarding loops,
  which is undesirable.  To prevent and detect such loops, this
  document uses the Hop-Limit Option."
This sounds like it should be required (and normative language should be used) and therefore draft-ietf-core-hop-limit should also be a normative reference.
Also draft-ietf-core-comi should probably another normative reference.

5)Section 4.5.2: You give recommendations for min and max in a note, however, these values should be specified normatively and in best with a MUST.

6) Section 4.7: "the DOTS
  agent sends a heartbeat over the signal channel to maintain its half
  of the channel.  The DOTS agent similarly expects a heartbeat from
  its peer DOTS agent"
and
"DOTS servers MAY trigger their heartbeat requests immediately after
  receiving heartbeat probes from peer DOTS clients."
Actually heartbeat should only be send in one direction (as the other end will send an ack) and the protocol should clearly specify which endpoint is responsible for triggering the ping.

7) sec 7.3:"To avoid DOTS signal message fragmentation and the subsequent
  decreased probability of message delivery, DOTS agents MUST ensure
  that the DTLS record MUST fit within a single datagram."
This should be handled by the DTLS record layer and not by DOTS that works on top of DTLS (actually Coap), therefor it seems straight to have a normative requirement here in the DOTS spec. Also note that the calculation provided is not valid for early data (0-RTT) as the hello messages could be transmitted in the same datagram.

8) Also sec 7.3: "If the path
  MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
  be assumed."
  Actually this is only true for IPv6. The later note mentions that the situation is different from IPV4, however, it should probably be made clear from the beginning that 1280 can only be assumed for IPv6.

9) sec 9.6: What's the registration policy for the newly created registries?

10) The document should more explicitly provide more guidance about when a client should start a session and what should be done (from the client side) if a session is detected as inactive (other than during migration which is discussed a bit in 4.7). Is the assumption to have basically permanently an active session or connect for migration and configuration requests separately at a time?

[Ballot comment]
1) I really recommend to add subsections to section 4.4.1.

2) section 4.4.1: "The lifetime of the
        deactivated mitigation request will be updated to (retry-timer
        + 45 seconds), so the DOTS client can refresh the deactivated
        mitigation request after retry-timer seconds before expiry of
        lifetime and check if the conflict is resolved."
This wording is not fully clear to me. If the life time of a deactivated request in updated, isn't it active again? And if it is active and another request is sent, isn't that request rejected again. Can you please further clarify.

3) section 4.4.2: "lifetime:  The remaining lifetime of the mitigation request, in
      seconds."
Shouldn't lifetime we rather a timestamp because there is some unknown transmission delay between the time when the reply is generated and the reply is received, and as such a lifetime in seconds is quite meaningless for the client.

4) section 4.4.2.1: " 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."
I'm not sure I understand this sentence. Can you please further explain?

5) section 4.4.4: "For example, if there is a financial
  relationship between the DOTS client and server domains, the DOTS
  client stops incurring cost at this point."
I find this sentence a bit problematic given the active-but-terminating period is defined by server. Wouldn't that mean the server can make me pay for undefined period of time? Also the max of 300 sec doesn't seem to be a MUST...?

6) In section Section 4.5 you talk about Caop Ping/Pong. However, these terms are not used in RFC7252. Maybe clarify that empty confirmable  messages are used and provide a pointer to section 4.2. of RFC7252 right here (instead of only later).

7) High-level question: Given this doc specifies a YANG model, why are configuration are not retrieved and changed using NETCONF or RESTCONF?

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

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

[Ballot discuss]
This should be easy to clear up, but I would like to understand why this document needs to restate the motivation and describe the algorithm for happy eyeballs instead of simply stating that hosts should use RFC8305 and then specify that UDP must be tried before TCP in each of the address families. If you do want to specify the whole algorithm here it needs to be more specific than "in a manner similar to the Happy Eyeballs mechanism" as it is not clear where it is similar (and where it will differ). It also looks like the example flow in Figure 4 is not consistent with the description before (TCP+IPv6 before UDP+IPv4)

[Ballot comment]
* Section 7.3

This text is wrong and needs to be removed

"IP packets whose size does not exceed 576 bytes should never need to be fragmented"

RFC791 only requires all hosts to be prepared to accept datagrams of up to 576 octets.

[Ballot comment]
A few minor items:

(1) Typos:

Section 3: s/signalling/signaling/
Section 4.4.1: s/implictily/implicitly/

(2) Section 7.1, Per “The DOTS client additionally uses [RFC6125] validation techniques to compare the domain name with the certificate provided”, this sentence appears to be missing a RFC2119 word – should it read something like “Additionally, the DOTS client MUST use [RFC6125] validation …”?

[Ballot discuss]
1) Port usage (see section 3):
The port request for DOTS was reviewed by the port expert team. Some members of the team where concerned about the assignment of a separate port number for DOTS as Coap is used and already has a designated port number. I believe that Coap is used as a transport in the case and DOTS provides a separate service compared to what Coap is usually used for, however, it is not clear why DOTS needs a designated port. Section 3 says that the port can either be preconfigured or dynamically detected, therefore it is not clear why a fixed port in needed (see also section 7.1. of RFC7605). In the port review process the authored argued that a port is needed to differentiate the DOTS service in the network. However, this is not an endorsed usage for port numbers (see section 6.2. of RFC7605). Further, I believe assigning a fixed port might actually add an attack vector for DOTS, either by DDoSing the respective port at the DOTS server, or any attempt to block DOTS traffic on the network from the DOTS client to the DOTS server.

2) Section 4.3 says:
"In reference to Figure 4, the DOTS client sends two TCP SYNs and two
  DTLS ClientHello messages at the same time over IPv6 and IPv4."
However, RFC8305 explicitly states that connection attempts SHOULD NOT be made simultaneously (see sec 5).

Further Figure 4 shows a different order of request as recommended in the text (text says: "UDP over IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4"). Also why are the UDP connection attempts repeated? I guess that is meant to be the retransmission of the DTLS Hello? However, usually you should receive the TCP SYNACK before you retransmit or in the best case even before you start the next connection attempt. Therefore that should be not displayed like this in the figure or needs further explanation.

3) Why are these statements SHOULDs and not MUSTs (see section 4.4)?
  "DOTS agents SHOULD follow the data transmission guidelines discussed
  in Section 3.1.3 of [RFC8085] and control transmission behavior by
  not sending more than one UDP datagram per round-trip time (RTT) to
  the peer DOTS agent on average."
and
  "If the DOTS client cannot maintain an RTT estimate, it
  SHOULD NOT send more than one Non-confirmable request every 3
  seconds"
However, all communication pattern used by DOTS rely on a request/reply pattern and Coap specifies for this case that only one request can be outstanding at a time with an exponential backoff pattern for retransmission (see section 4.7 and 4.2 of RFC7252) which therefore will be used in this case.

[Ballot comment]
I am balloting YES but noticed a few things in the -31 that can get addressed with
the rest of the IESG comments.

Section 4.4.1

      Implementations SHOULD set 'cuid' to the output of a cryptographic
      [...]
      [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.

      [...]

      If a DOTS client has to change its 'cuid' for some reason, it MUST
      NOT do so when mitigations are still active for the old 'cuid'.
      The 'cuid' SHOULD be 22 characters to avoid DOTS signal message
      fragmentation over UDP.  [...]

We need to cite RFC 4648, Section 5, for base64url.  Also,
getting a 22-character base64url-encoded cuid requires stripping the
trailing '=' from the encoding, and we should explicitly say to do that.

  A similar attack can be achieved by a compromised DOTS client which
  can sniff the TLS 1.2 handshake, use the client certificate to
  identify the 'cuid' used by another DOTS client.  This attack is not
  possible if algorithms such as [RFC4122] are used to generate the
  'cuid'.  [...]

I think the key part of RFC4122 cuid generation (w.r.t. preventing
sniffing) is that it's non-deterministic (and thus non-guessable), so we
should say something like "because such UUIDs are not a deterministic
function of the client certificate".


Figure 11 needs to show the response that indicates a conflicting cuid that
triggers the second request.

Section 10
                       
  When FQDNs are used as targets, the DOTS server MUST rely upon DNS
  privacy enabling protocols (e.g., DNS over TLS [RFC7858], DoH     
  [RFC8484]) to prevent eavesdroppers from possibly identifying the
  target resources protected by the DDoS mitigation service and means
  to ensure the target FQDN resolution is authentic (e.g., DNSSEC
  [RFC4034]). 

nits: "DNS over TLS or DoH" ("or" instead of comma, but keep the
references as-is); comma before "and means to ensure", since the DOTS
server has to do both of those (as opposed to the DOTS server using DoT/DoH
which provides both eavesdropping protection and data authenticity, which
is what the current text says).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dots-signal-channel-30. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are thirteen actions which we must complete.

First, the authors request a port assignment, for both TCP and UDP, for DOTS.

IANA Question --> Can we ask that you fill out the form below and we can have the experts review them now for permanent registrations?

https://www.iana.org/form/ports-services

Second, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a single assignment is to be made as follows:

URI Suffix: dots
Change Controller: IETF
Reference: [ RFC-to-be ]
Related Information:
Date Registered: [ TBD-at-Registration ]

As this requests registration in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the application subregistry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration will be made as follows:

Name: dots+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fourth, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single, new registration is to be made as follows:

Media Type: application/dots+cbor
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> Which of the available ranges in this registry is to be used for this registration? If the range 0-255 is to be used, Expert Review will be required for this registration. If needed, we will initiate the required Expert Review via a separate request. Expert review would need to be completed before your document can be approved for publication as an RFC.

Fifth, in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

https://www.iana.org/assignments/cbor-tags/

a single, new registration is to be made as follows:

Tag: [ TBD-at-Registration ]
Data Item: DDoS Open Threat Signaling (DOTS) signal channel object
Semantics: DDoS Open Threat Signaling (DOTS) signal channel object, as defined in [ RFC-to-be ]
Reference: [ RFC-to-be ]

IANA understands that this value will come from the 24-255 range of the registry. IANA also understands that the authors request that the value used for the ID in step four, above, is also used for the Tag in this registration.

As this also requests a registration in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Sixth, a new registry is to be created called the DOTS Signal Channel Registry. IANA understands this to be a new registry page on the IANA matrix located at:

https://www.iana.org/protocols

IANA also understands that five new registries will be created on this new registry page. The content and policies for those five, new registries are in the following steps.

Seventh, on the new registry page created in step six above, a new registry is to be created called the DOTS Signal Channel CBOR Key Values registry. The registration policy for the new registry is as follows:

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

There are initial registrations in the new registry as follows:

+----------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+----------------------+-------+-------+------------+---------------+
| ietf-dots-signal-chan| 1 | 5 | IESG | [ RFC-to-be ] |
| nel:mitigation-scope | | | | |
| scope | 2 | 4 | IESG | [ RFC-to-be ] |
| cdid | 3 | 3 | IESG | [ RFC-to-be ] |
| cuid | 4 | 3 | IESG | [ RFC-to-be ] |
| mid | 5 | 0 | IESG | [ RFC-to-be ] |
| target-prefix | 6 | 4 | IESG | [ RFC-to-be ] |
| target-port-range | 7 | 4 | IESG | [ RFC-to-be ] |
| lower-port | 8 | 0 | IESG | [ RFC-to-be ] |
| upper-port | 9 | 0 | IESG | [ RFC-to-be ] |
| target-protocol | 10 | 4 | IESG | [ RFC-to-be ] |
| target-fqdn | 11 | 4 | IESG | [ RFC-to-be ] |
| target-uri | 12 | 4 | IESG | [ RFC-to-be ] |
| alias-name | 13 | 4 | IESG | [ RFC-to-be ] |
| lifetime | 14 | 0/1 | IESG | [ RFC-to-be ] |
| mitigation-start | 15 | 0 | IESG | [ RFC-to-be ] |
| status | 16 | 0 | IESG | [ RFC-to-be ] |
| conflict-information | 17 | 5 | IESG | [ RFC-to-be ] |
| conflict-status | 18 | 0 | IESG | [ RFC-to-be ] |
| conflict-cause | 19 | 0 | IESG | [ RFC-to-be ] |
| retry-timer | 20 | 0 | IESG | [ RFC-to-be ] |
| conflict-scope | 21 | 5 | IESG | [ RFC-to-be ] |
| acl-list | 22 | 4 | IESG | [ RFC-to-be ] |
| acl-name | 23 | 3 | IESG | [ RFC-to-be ] |
| acl-type | 24 | 3 | IESG | [ RFC-to-be ] |
| bytes-dropped | 25 | 0 | IESG | [ RFC-to-be ] |
| bps-dropped | 26 | 0 | IESG | [ RFC-to-be ] |
| pkts-dropped | 27 | 0 | IESG | [ RFC-to-be ] |
| pps-dropped | 28 | 0 | IESG | [ RFC-to-be ] |
| attack-status | 29 | 0 | IESG | [ RFC-to-be ] |
| ietf-dots-signal- | 30 | 5 | IESG | [ RFC-to-be ] |
| channel:signal-config| | | | |
| sid | 31 | 0 | IESG | [ RFC-to-be ] |
| mitigating-config | 32 | 5 | IESG | [ RFC-to-be ] |
| heartbeat-interval | 33 | 5 | IESG | [ RFC-to-be ] |
| min-value | 34 | 0 | IESG | [ RFC-to-be ] |
| max-value | 35 | 0 | IESG | [ RFC-to-be ] |
| current-value | 36 | 0 | IESG | [ RFC-to-be ] |
| missing-hb-allowed | 37 | 5 | IESG | [ RFC-to-be ] |
| max-retransmit | 38 | 5 | IESG | [ RFC-to-be ] |
| ack-timeout | 39 | 5 | IESG | [ RFC-to-be ] |
| ack-random-factor | 40 | 5 | IESG | [ RFC-to-be ] |
| min-value-decimal | 41 | 6tag4 | IESG | [ RFC-to-be ] |
| max-value-decimal | 42 | 6tag4 | IESG | [ RFC-to-be ] |
| current-value- | 43 | 6tag4 | IESG | [ RFC-to-be ] |
| decimal | | | | |
| idle-config | 44 | 5 | IESG | [ RFC-to-be ] |
| trigger-mitigation | 45 | 7 | IESG | [ RFC-to-be ] |
| ietf-dots-signal-chan| 46 | 5 | IESG | [ RFC-to-be ] |
| nel:redirected-signal| | | | |
| alt-server | 47 | 3 | IESG | [ RFC-to-be ] |
| alt-server-record | 48 | 4 | IESG | [ RFC-to-be ] |
+----------------------+-------+-------+------------+---------------+

Eighth, also on the new registry page created in step six above, a new registry is to be created called the DOTS Signal Channel Status Codes registry. The registration policy for the new registry is Standards Action as defined by RFC 8126.

There are initial registrations in the new registry as follows:

+------+----------------------------------+--------------+-------------+
| Code | Label | Description | Reference |
| | | | |
+------+----------------------------------+--------------+-------------+
| 1 | attack-mitigation-in-progress | Attack |[ RFC-to-be ]|
| | | mitigation | |
| | | setup is in | |
| | | progress | |
| | | (e.g., | |
| | | changing the | |
| | | network path | |
| | | to redirect | |
| | | the inbound | |
| | | traffic to a | |
| | | DOTS | |
| | | mitigator). | |
| 2 | attack-successfully-mitigated | Attack is |[ RFC-to-be ]|
| | | being | |
| | | successfully | |
| | | mitigated | |
| | | (e.g., | |
| | | traffic is | |
| | | redirected | |
| | | to a DDoS | |
| | | mitigator | |
| | | and attack | |
| | | traffic is | |
| | | dropped). | |
| 3 | attack-stopped | Attack has |[ RFC-to-be ]|
| | | stopped and | |
| | | the DOTS | |
| | | client can | |
| | | withdraw the | |
| | | mitigation | |
| | | request. | |
| 4 | attack-exceeded-capability | Attack has |[ RFC-to-be ]|
| | | exceeded the | |
| | | mitigation | |
| | | provider | |
| | | capability. | |
| 5 | dots-client-withdrawn-mitigation | DOTS client |[ RFC-to-be ]|
| | | has | |
| | | withdrawn | |
| | | the | |
| | | mitigation | |
| | | request and | |
| | | the | |
| | | mitigation | |
| | | is active | |
| | | but | |
| | | terminating. | |
| 6 | attack-mitigation-terminated | Attack |[ RFC-to-be ]|
| | | mitigation | |
| | | is now | |
| | | terminated. | |
| 7 | attack-mitigation-withdrawn | Attack |[ RFC-to-be ]|
| | | mitigation | |
| | | is | |
| | | withdrawn. | |
| 8 | attack-mitigation-signal-loss | Attack |[ RFC-to-be ]|
| | | mitigation | |
| | | will be | |
| | | triggered | |
| | | for the | |
| | | mitigation | |
| | | request only | |
| | | when the | |
| | | DOTS signal | |
| | | channel | |
| | | session is | |
| | | lost. | |
+------+----------------------------------+--------------+-------------+

IANA Question --> Does the code 0 (zero) have any special or reserved meaning for these status codes? What is the range of available status codes?

IANA will add the following note to the newly created registry:

When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [ RFC-to-be ].

Ninth, also on the new registry page created in step six above, a new registry is to be created called the DOTS Signal Channel Conflict Status Codes registry. The registration policy for the new registry is Standards Action as defined by RFC 8126.

There are initial registrations in the new registry as follows:

+------+-------------------------------+----------------+-------------+
| Code | Label | Description | Reference |
+------+-------------------------------+----------------+-------------+
| 1 | request-inactive-other-active | DOTS server |[ RFC-to-be ]|
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. This | |
| | | mitigation | |
| | | request is | |
| | | currently | |
| | | inactive until | |
| | | the conflicts | |
| | | are resolved. | |
| | | Another | |
| | | mitigation | |
| | | request is | |
| | | active. | |
| 2 | request-active | DOTS server |[ RFC-to-be ]|
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. This | |
| | | mitigation | |
| | | request is | |
| | | currently | |
| | | active. | |
| 3 | all-requests-inactive | DOTS server |[ RFC-to-be ]|
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. All | |
| | | conflicting | |
| | | mitigation | |
| | | requests are | |
| | | inactive. | |
+------+-------------------------------+----------------+-------------+

IANA Question --> Does the code 0 (zero) have any special or reserved meaning for these status codes? What is the range of available status codes?

IANA will add the following note to the newly created registry:

When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [ RFC-to-be ].

Tenth, also on the new registry page created in step six above, a new registry is to be created called the DOTS Signal Channel Conflict Cause Codes registry. The registration policy for the new registry is Standards Action as defined by RFC 8126.

There are initial registrations in the new registry as follows:

+------+--------------------------+---------------------+-------------+
| Code | Label | Description | Reference |
+------+--------------------------+---------------------+-------------+
| 1 | overlapping-targets | Overlapping |[ RFC-to-be ]|
| | | targets. | |
| 2 | conflict-with-acceptlist | Conflicts with an |[ RFC-to-be ]|
| | | existing accept- | |
| | | list. This code is | |
| | | returned when the | |
| | | DDoS mitigation | |
| | | detects source | |
| | | addresses/prefixes | |
| | | in the accept- | |
| | | listed ACLs are | |
| | | attacking the | |
| | | target. | |
| 3 | cuid-collision | CUID Collision. |[ RFC-to-be ]|
| | | This code is | |
| | | returned when a | |
| | | DOTS client uses a | |
| | | 'cuid' that is | |
| | | already used by | |
| | | another DOTS | |
| | | client. | |
+------+--------------------------+---------------------+-------------+

IANA Question --> Does the code 0 (zero) have any special or reserved meaning for these status codes? What is the range of available status codes?

IANA will add the following note to the newly created registry:

When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [ RFC-to-be ].

Eleventh, also on the new registry page created in step six above, a new registry is to be created called the DOTS Signal Channel Attack Status Codes registry. The registration policy for the new registry is Standards Action as defined by RFC 8126.

There are initial registrations in the new registry as follows:

+------+-------------------------------+----------------+-------------+
| Code | Label | Description | Reference |
+------+-------------------------------+----------------+-------------+
| 1 | under-attack | The DOTS |[ RFC-to-be ]|
| | | client | |
| | | determines | |
| | | that it is | |
| | | still under | |
| | | attack. | |
| 2 | attack-successfully-mitigated | The DOTS |[ RFC-to-be ]|
| | | client | |
| | | determines | |
| | | that the | |
| | | attack is | |
| | | successfully | |
| | | mitigated. | |
+------+-------------------------------+----------------+-------------+

IANA Question --> Does the code 0 (zero) have any special or reserved meaning for these status codes? What is the range of available status codes?

IANA will add the following note to the newly created registry:

When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [ RFC-to-be ].

Twelveth, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

two, new namespaces will be registered as follows:

ID: yang:ietf-dots-signal-channel
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-dots-signal-channel
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Thirteenth, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two, new YANG modules will be registered as follows:

Name: ietf-signal
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
Prefix: signal
Module:
Reference: [ RFC-to-be ]

Name: iana-signal
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
Prefix: iana-signal
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-03-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dots-signal-channel@ietf.org, dots@ietf.org, frank.xialiang@huawei.com, kaduk@mit.edu, dots-chairs@ietf.org, Liang Xia
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification) to Proposed Standard


The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal
  Channel Specification'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-03-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies the DOTS signal channel, a protocol for
  signaling the need for protection against Distributed Denial-of-
  Service (DDoS) attacks to a server capable of enabling network
  traffic mitigation on behalf of the requesting client.

  A companion document defines the DOTS data channel, a separate
  reliable communication layer for DOTS management and configuration
  purposes.

Editorial Note (To be removed by RFC Editor)

  Please update these statements within the document with the RFC
  number to be assigned to this document:

  o  "This version of this YANG module is part of RFC XXXX;"

  o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Signal Channel Specification";

  o  "| [RFCXXXX] |"

  o  reference: RFC XXXX

  Please update this statement with the RFC number to be assigned to
  the following documents:

  o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data-
      channel)

  Please update TBD/TBD1/TBD2 statements with the assignments made by
  IANA to DOTS Signal Channel Protocol.

  Also, please update the "revision" date of the YANG modules.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7918: Transport Layer Security (TLS) False Start (Informational - IETF stream)

1. Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk.
This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. The working group has the consensus to publish it as a Proposed Standard since it is a protocol draft, which is stable in technical aspect and enjoy enough community interest to be considered valuable.

2. Review and Consensus
The -00 version of this WG draft has been submitted in 2017-04, and it has fast evolved into its -25 version now. The co-authors are from some of the leading vendors and operators in DDoS protection industry with extensive experience with the related technologies and implementations, they are also the core authors of the DOTS requirements WG drafts which guarantee their consistency. Until now, there are three demo implementations for it (open source go-dots from NTT, two proprietary demos from NCC and Huawei) and several rounds of interop test during IETF hackathon activities. All the technical issues identified by these demos and the finished tests have been addressed and reflected into the latest draft, which are very helpful for the completeness and quality improvement of the draft.

This draft firstly specifies the DOTS signal channel messages and the related behaviors (e.g., DOTS mitigation management messages: request, status exchange, withdraw, DOTS signal channel session configuration messages, redirection and heartbeat messages), then defines all the signal channel messages format with YANG data model and their mapping CBOR scheme. Besides, other related issues are also discussed (e.g., (D)TLS protocol profile and AA). Among them, several topics may need further review because of the complexity or importance:
* The definition of 'cuid', 'cdid' and 'mid' parameters for DOTS client/client domain identity and mitigation session, as well as various means of using them together;
* the conflict resolution mechanisms for the mitigation request messages with the overlapping mitigation scope, which can be sent from the same DOTS client or different DOTS clients;
* DOTS heartbeat mechanism and the related NAT traversal consideration;
* DOTS messages YANG data model, and the corresponding CBOR schema mapping.

In summary, this draft has been extensively reviewed and discussed within the working group by mailing list and github, and I believe all technical issues raised have been resolved till this version (-25). So, the latest document is well written and reaches a broad consensus in WG.


3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79.  There are no IPR disclosures on the document.

4. Other Points
By performing the idnits check, there are just one minor problem (the referenced WG draft has been updated to next version).

In general, I believe the IANA Considerations are clear and ready. There are totally 4 IANA requests:
1) a service port number (4646);
2) a new Well-Known URIs registry (dots);
3) a new URI in "IETF XML Registry" (urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel) for a new "YANG Module Names" registry (ietf-signal);
4) the initial DOTS signal channel CBOR mappings registry and the registration template for new CBOR mapping

No early expert review has been requested for the above IANA allocation.