Subject: Re: [Dots] Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

From: <[email-masked]>
Date: Thu, 2 May 2019 06:35:39 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 1 mai 2019 05:07
> À : The IESG
> Cc : [email-masked]; Liang Xia; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31: (with
> DISCUSS and COMMENT)
> 
> Suresh Krishnan 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:
> ----------------------------------------------------------------------
> 
> 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

[Med] We adopted this elaborated approach because there are specifics to the DOTS case that are called out in the text, e.g.,
* probing to migrate the connection
* caching (used to be in HE v1)

Also, unlike RFC8305:
* we don't cancel all other connections upon establishment of one connection.
* we don't forbid all attempts to be sent simultaneously. 

All these details are described in the text. 

 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)

[Med] The text says the following: 

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

Ben suggested in his review to add annotations to Figure 4 but we didn't because we though this is redundant with the above text.

Will add annotations to Figure 4.

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

[Med] Done.

---

From: <[email-masked]>
Date: Fri, 3 May 2019 09:25:30 +0000

Suresh, 

We rearranged the text to better indicate where DOTS HE differs from 8305. You can check the changes at:

Txt: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draft-ietf-dots-signal-channel-31.txt 
Diff: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel-31.pdf 

If any further change/clarification is needed, please let me know. 

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : jeudi 2 mai 2019 08:36
> À : Suresh Krishnan; The IESG
> [email-masked]; [email-masked]
> Objet : RE: Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> [Med] We adopted this elaborated approach because there are specifics to the
> DOTS case that are called out in the text, e.g.,
> Ben suggested in his review to add annotations to Figure 4 but we didn't
> because we though this is redundant with the above text.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 10:56:38 -0500

Hi Med,

I'm not sure that's fully responsive to Suresh's point.  Yes, we need to
document clearly what we are doing (and how it differs from RFC 8305 is a
good rhetorical mechanism for doing so), but I think the point was that we
also need to justify why the existing solution does not work for our use
case.  That justification may or may not need to be in the resulting RFC,
but it does need to exist in order for the document to pass IESG
evaluation.

Thanks,

Ben

---

From: <[email-masked]>
Date: Tue, 7 May 2019 09:13:19 +0000

Re-,

Thank you Ben for sharing your thoughts. 

Please find below the rationale/justification as currently included in the version shared with Suresh. Will be more than happy to update the text if further change/clarification is needed. 

(1) 

The "happiness" as targeted by RFC8305 is to select the faster connection among a mix IPv4 and IPv6 addresses. RFC8305 does not deal with transport selection matters. The sorting procedure in RFC8305 can't thus be reused as-is in DOTS, hence this text in the draft: 

   o  The order of preference of the DOTS signal channel address family
      and transport protocol (most preferred first) is: UDP over IPv6,
      UDP over IPv4, TCP over IPv6, and finally TCP over IPv4.  This
      order adheres to the address preference order specified in
      [RFC6724] and the DOTS signal channel preference which privileges
      the use of UDP over TCP (to avoid TCP's head of line blocking).

(2)

For DOTS, a (permanent) connection is established between the client and the same server. Caching the results allows for an optimized behavior. RFC8305 does not specify how caching is done while it was part of RFC6555 (HEv1). We inspired from the text in 6555 for DOTS, hence this text:    

   o  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.  The cached
      information is flushed when its age exceeds a specific time period
      on the order of few minutes (e.g., 10 mn).  Typically, if the DOTS
      client has to re-establish the connection with the same DOTS
      server within few seconds after the Happy Eyeballs mechanism is
      completed, caching avoids trashing the network especially in the
      presence of DDoS attack traffic.

(3)

During the lifetime of a DOTS connection, DTLS may be available while it wasn't during the connection initialization. RFC8305 cannot detect this nor allow to migrate a connection to a DTLS-capable path. The intended behavior and justification are covered with the following text:  

   o  If DOTS signal channel session is established with TLS (but DTLS
      failed), the DOTS client periodically repeats the mechanism to
      discover whether DOTS signal channel messages with DTLS over UDP
      becomes available from the DOTS server, so the DOTS client can
      migrate the DOTS signal channel from TCP to UDP.  Such probing
      SHOULD NOT be done more frequently than every 24 hours and MUST
      NOT be done more frequently than every 5 minutes.

(4) 

When connections attempts are made when an attack is ongoing, there is a tension between the load and success to place a mitigation request. The document allows to relax the "SHOULD NOT be made simultaneously" constraint to hopefully trigger a mitigation asap:     

   o  If the DOTS signal channel session is established during an attack
      time, the DOTS client SHOULD send the TCP SYNs and DTLS
      ClientHello messages at the same time over IPv6 and IPv4 so that
      the mitigation request can be sent as soon as the connection is
      established on one of the transports and one of the address
      families.

If you think that the justification for this one is not strong, we can consider replacing it with this NEW text:   

   When connection attempts are made during an attack, the DOTS client
   SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms.

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : lundi 6 mai 2019 17:57
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Suresh Krishnan; The IESG; [email-masked];
> Liang Xia; [email-masked]; [email-masked]
> Objet : Re: Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31:
> > Txt: https://github.com/boucadair/draft-ietf-dots-signal-
> channel/blob/master/draft-ietf-dots-signal-channel-31.txt
> > Diff: https://github.com/boucadair/draft-ietf-dots-signal-
> channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-
> ietf-dots-signal-channel-31.pdf
> >
> > > > specify that UDP must be tried before TCP in each of the address
> families.
> > > If

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 May 2019 10:53:02 -0500

Hi Med,

> Please find below the rationale/justification as currently included in the version shared with Suresh. Will be more than happy to update the text if further change/clarification is needed. 

Thanks for these, I think they will help Suresh get a clear picture of what
we're trying to do (and decide if further text changes are needed).

-Ben

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 7 May 2019 16:05:06 +0000

Hi Med/Ben,

> On May 7, 2019, at 11:53 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Med,
> 

I agree too. Thanks for making these clarifications. I will clear as soon the new revision hits.

Regards
Suresh