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

[Benjamin Kaduk <[e-mail]>]

Hi Mirja,

I wanted to check in with the status of the remaining Discuss points for
this document.  I tried to go through the previous discussions and have
made my own analysis of where things stand, so hopefully we can compare
notes.

On Wed, May 01, 2019 at 07:42:31AM -0700, Mirja Kühlewind via Datatracker wrote:
> 
> 
> ----------------------------------------------------------------------
> 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.

If I understand correctly you were supporting a port allocation, but wanted
the document to be more clear about its usage and necessity.

There were some text changes, so that we now have:

   In some cases, a DOTS client and server may have mutual agreement to
   use a specific port number, such as by explicit configuration or
   dynamic discovery [I-D.ietf-dots-server-discovery].  Absent such
   mutual agreement, the DOTS signal channel MUST run over port number
   TBD as defined in Section 9.1, for both UDP and TCP.  In order to use
   a distinct port number (as opposed to TBD), DOTS clients and servers
   SHOULD support a configurable parameter to supply the port number to
   use.  The rationale for not using the default port number 5684
   ((D)TLS CoAP) is to allow for differentiated behaviors in
   environments where both a DOTS gateway and an IoT gateway (e.g.,
   Figure 3 of [RFC7452]) are present.

Does that address your concerns?

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

We changed this behavior to be sequential and adhere to 8305 most of the
time, but allow dropping the connection attempt delay to 100ms during
(congestive) attacks.

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

These changes made, except for the last one, IIUC.

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

We did get some pointers to cases in which requests may well 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.

hop-limit is now normative, and per Alexey's suggestion the comi usage has
been described inline.

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

It got changed to RECOMMENDED.  (I do see you asked why there was a need
for a maximum at all, which I don't remember seeing an answer to.)

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

I'm not sure I see resolution on this; do the authors still need to
answer why the "pong" reply cannot serve as a reverse-path heartbeat?

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

There was some clarifying discussion here; do you still see an issue?

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

Currently we're at a MAY-level limit of 576 bytes when it's known that IPv4
systems are present.

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

Standards Action, as indicated.

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

I think there was some clarifying text added, but please confirm if you
think it is sufficient.

Thanks,

Ben