[Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind 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:
----------------------------------------------------------------------

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?


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