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

[<[e-mail]>]

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

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : lundi 6 mai 2019 17:57
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Suresh Krishnan; The IESG; [e-mail];
> Liang Xia; [e-mail]; [e-mail]
> Objet : Re: Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> 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
> 
> On Fri, May 03, 2019 at 09:25:30AM +0000, [e-mail] wrote:
> > 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
> >
> > > -----Message d'origine-----
> > > De : [e-mail] [mailto:[e-mail]]
> > > Envoyé : jeudi 2 mai 2019 08:36
> > > À : Suresh Krishnan; The IESG
> > > Cc : [e-mail]; Liang Xia; dots-
> > > [e-mail]; [e-mail]
> > > Objet : RE: Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-
> 31:
> > > (with DISCUSS and COMMENT)
> > >
> > > Re-,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Suresh Krishnan via Datatracker [mailto:[e-mail]]
> > > > Envoyé : mercredi 1 mai 2019 05:07
> > > > À : The IESG
> > > > Cc : [e-mail]; Liang Xia; dots-
> > > > [e-mail]; [e-mail]; [e-mail]
> > > > 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.