Subject: Re: Tsvart last call review of draft-ietf-dots-signal-channel-31

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 2 Apr 2019 15:01:34 -0700

HI Med,

Thanks for the reply. I put my comments in lines.

On Sun, Mar 31, 2019 at 11:55 PM <[email-masked]> wrote:

> Hi Yoshi,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Yoshifumi Nishida via Datatracker [mailto:[email-masked]]
> > Envoyé : dimanche 31 mars 2019 10:53
> > À : [email-masked]
> > Cc : [email-masked]; [email-masked];
> > [email-masked]
> > Objet : Tsvart last call review of draft-ietf-dots-signal-channel-31
> >
> > Reviewer: Yoshifumi Nishida
> > Review result: Almost Ready
> >
> > This document has been reviewed as part of the transport area review
> team's
> > ongoing effort to review key IETF documents. These comments were written
> > primarily for the transport area directors, but are copied to the
> document's
> > authors and WG to allow them to address any issues raised and also to the
> > IETF
> > discussion list for information.
> >
> > When done at the time of IETF Last Call, the authors should consider this
> > review as part of the last-call comments they receive. Please always CC
> > [email-masked] if you reply to or forward this review.
> >
> > Summary: This document is almost ready for publication, but it will be
> better
> > to clarify the following points.
> >
> > 1:   "it is out of scope of this document to specify the behavior to be
> > followed by a DOTS client to send DOTS requests when multiple
> >         DOTS servers are provisioned."
> >
> >       I'm not sure why it is out of scope. Does it bring a certain
> > complexities
> >       to the protocol?
> >      Or, does it simply mean it is up to implementations?
>
> [Med] This is because of specific considerations such as those discussed
> in draft-ietf-dots-multihoming. We don't want to overload the base spec
> with such considerations (discussed in separate documents). The same
> approach is followed for server discovery
> (draft-ietf-dots-server-discovery).
>

Got it. I think it would be useful for readers to mention it in the draft.

> > 2:   "The DOTS client periodically repeats the mechanism to discover
> whether
> > DOTS signal
> >         channel messages with DTLS over UDP becomes available from the
> DOTS
> >         server.."
> >
> >        -> Does this mean DOTS clients will not repeat this when it
> already
> > has
> >        DTLS over UDP connection?
> >            What about if the client has DTLS over UDPv4? Does it try to
> check
> >            DTLS over UDPv6? Also, is this logic MAY or SHOULD or don't
> want
> > to
> >            specify?
>
> [Med] The client will retry when the cache flushes out:

>    Note that the DOTS client after successfully establishing a
>    connection MUST cache information regarding the outcome of each
>    connection attempt for a specific time period, and it uses that
>    information to avoid thrashing the network with subsequent attempts.
>

OK, but if you retry anyway after a certain time, why do you need to cache
the results?

> 3:   "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."
> >
> >       ->  How about TCP connections?
>
> [Med] TCP does not have the issue with non-confirmable messages. FWIW,
> RFC8323 states the following:
>
>    The request/response interaction model of CoAP over TCP is the same
>    as CoAP over UDP.  The primary differences are in the message layer.
>    The message layer of CoAP over UDP supports optional reliability by
>    defining four types of messages: Confirmable, Non-confirmable,
>    Acknowledgment, and Reset.
>
>    ...
>
>    Since TCP eliminates the need for the message layer to support
>    reliability, CoAP over reliable transports does not support
>    Confirmable or Non-confirmable message types.
>

I see. Thanks for the clarification.
--
Yoshi

---

From: <[email-masked]>
Date: Wed, 3 Apr 2019 06:35:51 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : mercredi 3 avril 2019 00:02
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: Tsvart last call review of draft-ietf-dots-signal-channel-31

HI Med,

On Sun, Mar 31, 2019 at 11:55 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Please see inline.

Cheers,
Med

> De : Yoshifumi Nishida via Datatracker [mailto:[email-masked]<mailto:[email-masked]>]
> À : [email-masked]<mailto:[email-masked]>
> Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> This document has been reviewed as part of the transport area review team's
> primarily for the transport area directors, but are copied to the document's
> [email-masked]<mailto:[email-masked]> if you reply to or forward this review.
>
> Summary: This document is almost ready for publication, but it will be better

[Med] This is because of specific considerations such as those discussed in draft-ietf-dots-multihoming. We don't want to overload the base spec with such considerations (discussed in separate documents). The same approach is followed for server discovery (draft-ietf-dots-server-discovery).

[Med] I updated the text as follows :

   Likewise, it is out of scope of this document to specify the behavior
   to be followed by a DOTS client to send DOTS requests when multiple
   DOTS servers are provisioned (e.g., contact all DOTS servers, select
   one DOTS server among the list).  Such behavior is specified in other
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   documents (e.g.,  [I-D.ietf-dots-multihoming]).
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> 2:   "The DOTS client periodically repeats the mechanism to discover whether
> DOTS signal
>         channel messages with DTLS over UDP becomes available from the DOTS
>         server.."
>
>        -> Does this mean DOTS clients will not repeat this when it already
> has
>            What about if the client has DTLS over UDPv4? Does it try to check
>            DTLS over UDPv6? Also, is this logic MAY or SHOULD or don't want
> to
>            specify?

OK, but if you retry anyway after a certain time, why do you need to cache the results?

[Med] “to avoid thrashing the network with subsequent attempts” as the text says. Also, caching avoids the inconvenience of selection during attack times. Typically, the client executes the HE procedure when it initializes and uses the outcome of the procedure for subsequent DOTS signal exchanges during a certain period. Please refer to this text in the draft:

   To overcome these connection setup problems, the DOTS client attempts

   to connect to its DOTS server(s) using both IPv6 and IPv4, and tries

   both DTLS over UDP and TLS over TCP in a manner similar to the Happy

   Eyeballs mechanism [RFC8305].  These connection attempts are

   performed by the DOTS client when it initializes, or in general when

   it has to select an address family and transport to contact its DOTS

   server.  The results of the Happy Eyeballs procedure are used by the

   DOTS client for sending its subsequent messages to the DOTS server.

>         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

[Med] TCP does not have the issue with non-confirmable messages. FWIW, RFC8323 states the following:

   ...

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 4 Apr 2019 09:38:02 -0700

Hi Med,

On Tue, Apr 2, 2019 at 11:35 PM <[email-masked]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* mercredi 3 avril 2019 00:02
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Yoshifumi Nishida; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Objet :* Re: Tsvart last call review of draft-ietf-dots-signal-channel-31
>
>
>
> HI Med,
>
>
>

WFM. Thanks for the updates!

> [Med] “to avoid thrashing the network with subsequent attempts” as the
> text says. Also, caching avoids the inconvenience of selection during
> attack times. Typically, the client executes the HE procedure when it
> initializes and uses the outcome of the procedure for subsequent DOTS
> signal exchanges during a certain period. Please refer to this text in the
> draft:
>

Hmm. let's say the results of the happy eyeballs was TCP over IPv4 (just
like the figure 4) and the client cache the info.
After certain period of time, the client will do happy eyeball again
because other better connections might be available . But, in this case,
how the cached info will be used?

It seems that an implementation that doesn't cache the info at all and does
happy eyeballs at every 10 hours won't be allowed in this draft.

Thanks,
--
Yoshi

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 5 Apr 2019 05:46:19 +0000

Hmm. let's say the results of the happy eyeballs was TCP over IPv4 (just like the figure 4) and the client cache the info.
After certain period of time, the client will do happy eyeball again because other better connections might be available . But, in this case, how the cached info will be used?

[TR] The cache expires after a specific time period. If the cache has not expired, the client uses the information from the cache. If cache has expired, the client performs happy eyeball again.

It seems that an implementation that doesn't cache the info at all and does happy eyeballs at every 10 hours won't be allowed in this draft.

[TR] No, but if the subsequent attempt is within few seconds after the first attempt of happy eyeball, it would trash the network. The endpoint may have to re-establish the (D)TLS session within few seconds for several reasons (e.g. TLS session got terminated, DOTS server rebooted NAT rebooted etc.).

-Tiru

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 7 Apr 2019 23:53:32 -0700

Hi Tiru,

On Thu, Apr 4, 2019 at 10:46 PM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> [TR] The cache expires after a specific time period. If the cache has not
> expired, the client uses the information from the cache. If cache has
> expired, the client performs happy eyeball again.
>
>
>
> It seems that an implementation that doesn't cache the info at all and
> does happy eyeballs at every 10 hours won't be allowed in this draft.
>
>
>
> [TR] No, but if the subsequent attempt is within few seconds after the
> first attempt of happy eyeball, it would trash the network. The endpoint
> may have to re-establish the (D)TLS session within few seconds for several
> reasons (e.g. TLS session got terminated, DOTS server rebooted NAT rebooted
> etc.).
>

Thanks for the explanation. The logic makes sense to me.
I think it would be good to articulate this a bit more in the draft.
For example, the figure 4 example explains the probing period, but doesn't
mention about the cache period.

Thanks,
--
Yoshi

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Apr 2019 08:39:40 +0000

Hi Yoshi,

Please see inline [TR2]

From: Yoshifumi Nishida <[email-masked]>
Sent: Monday, April 8, 2019 12:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Yoshifumi Nishida <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Yoshifumi Nishida <[email-masked]>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Tiru,

On Thu, Apr 4, 2019 at 10:46 PM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hmm. let's say the results of the happy eyeballs was TCP over IPv4 (just like the figure 4) and the client cache the info.
After certain period of time, the client will do happy eyeball again because other better connections might be available . But, in this case, how the cached info will be used?

Thanks for the explanation. The logic makes sense to me.
I think it would be good to articulate this a bit more in the draft.
For example, the figure 4 example explains the probing period, but doesn't mention about the cache period.

[TR2]
Sure, we can update the text as follows:

Note that the DOTS client after successfully establishing a connection MUST cache information regarding the outcome of each
connection attempt and the cached information should be flushed when its age exceeds a system-defined maximum on the order of few minutes (e.g. 2 minutes).
If the DOTS client has to re-establish the connection with the DOTS server within few seconds after the Happy Eyeballs mechanism is complete,
  caching avoids trashing the network in the presence of DDoS attack traffic.

-Tiru

Thanks,
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 8 Apr 2019 23:56:24 -0700

Hi Tiru,

I put my comments in lines.

On Mon, Apr 8, 2019 at 1:40 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline [TR2]
>
>
>
> *From:* Yoshifumi Nishida <[email-masked]>
> *Sent:* Monday, April 8, 2019 12:24 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>
> *Cc:* Yoshifumi Nishida <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; Yoshifumi Nishida <[email-masked]>
> *Subject:* Re: [Dots] Tsvart last call review of
> draft-ietf-dots-signal-channel-31
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi Tiru,
>
>
>
> Note that the DOTS client after successfully establishing a connection
> MUST cache information regarding the outcome of each
>
> connection attempt and the cached information should be flushed when its
> age exceeds a system-defined maximum on the order of few minutes (e.g. 2
> minutes).
>
> If the DOTS client has to re-establish the connection with the DOTS server
> within few seconds after the Happy Eyeballs mechanism is complete,
>

Thanks for the updates. But, one thing.. The text suggests cache period
would be the order of few minutes.
But, this value seems to be much smaller compared to "probing SHOULD NOT be
done more than every 24 hours".
--
Yoshi

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 9 Apr 2019 08:26:10 +0000

Please see inline [TR3]

From: Dots <[email-masked]> On Behalf Of Yoshifumi Nishida
Sent: Tuesday, April 9, 2019 12:26 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; Yoshifumi Nishida <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Yoshifumi Nishida <[email-masked]>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31

On Mon, Apr 8, 2019 at 1:40 AM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Please see inline [TR2]

From: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
Sent: Monday, April 8, 2019 12:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Cc: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:tsv-art@ietf..org>; Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31

[TR2]

Thanks for the updates. But, one thing.. The text suggests cache period would be the order of few minutes.
But, this value seems to be much smaller compared to "probing SHOULD NOT be done more than every 24 hours".

[TR3] The probing is for a scenario where the client is using TLS (over TCP) for the signal channel and probes to check if DTLS (over UDP) becomes available. If the probing finds DTLS over UDP is available, the client disconnects the TLS over TCP and re-connects to the server using DTLS over UDP transport.

-Tiru

--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 10 Apr 2019 23:06:07 -0700

Hi Tiru,

On Tue, Apr 9, 2019 at 1:26 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> Please see inline [TR3]
>
>
>
> *From:* Dots <[email-masked]> *On Behalf Of * Yoshifumi Nishida
> *Sent:* Tuesday, April 9, 2019 12:26 PM
> *Cc:* [email-masked]; Yoshifumi Nishida <[email-masked]>;
> [email-masked]; [email-masked]; Yoshifumi Nishida <
> [email-masked]>
> [email-masked] <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked] <tsv-art@ietf..org>; Yoshifumi Nishida <
> [email-masked]>
> [TR3] The probing is for a scenario where the client is using TLS (over
> TCP) for the signal channel and probes to check if DTLS (over UDP) becomes
> available. If the probing finds DTLS over UDP is available, the client
> disconnects the TLS over TCP and re-connects to the server using DTLS over
> UDP transport.
>

Thanks for explanation.
OK. so, probing and cache is irrelevant. I have thought about if this is
confusing or not for a bit. But, I think it's ok after I re-read the text.
I don't have any more comments.
Thanks,
--
Yoshi