Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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 220.127.116.11: "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 18.104.22.168: "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?
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 22.214.171.124: " 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?
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).
Thanks for addressing my DISCUSS and COMMENT.
Thanks for addressing my DISCUSS.
I support Mirja and Alexey's DISCUSS positions.
Alexey has this document well covered; nothing to add.
126.96.36.199. Registration Template Registration requests for the 0x4000 - 0x7FFF range are evaluated after a three-week review period on the dots-signal-reg- firstname.lastname@example.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.
Thanks for addressing my DISCUSS points.
No objection on my part but I support Suresh's DISCUSS (also shared by Mirja and Adam).
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 …”?