Re: [tcpm] Progressing draft-ietf-tcpm-converters

[<[e-mail]>]

Hi Yuchung, 

Thank you for clarifying your concern. Below a text proposal to address this comment:

> I merely pointed out, if TFO is not used, as the draft and the
> original email refer to, the draft should be explicit this requires a
> change in RFC793. It's rather vague.
 
UPDATED:

   Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry
   data inside its payload but forbids the receiver from delivering it
   to the application until completion of the three-way-handshake.  To
   enable applications to exchange data in a TCP handshake, this
   specification follows an approach similar to TCP Fast Open [RFC7413]
   and thus removes the constraint by allowing data in SYN packets to be
   delivered to the application.

   As discussed in [RFC7413], such change to TCP semantic raises two
   issues.  First, duplicate SYNs can cause problems for some
   applications that rely on TCP.  Second, TCP suffers from SYN flooding
   attacks [RFC4987].  TFO solves these two problems for applications
   that can tolerate replays by using the TCP Fast Open option that
   includes a cookie.  However, the utilization of this option consumes
   space in the limited TCP extended header.  Furthermore, there are
   situations, as noted in Section 7.3 of [RFC7413] where it is possible
   to accept the payload of SYN packets without creating additional
   security risks such as a network where addresses cannot be spoofed
   and the Transport Converter only serves a set of hosts that are
   identified by these addresses.

   For these reasons, this specification does not mandate the use of the
   TCP Fast Open option when the Client sends a connection establishment
   packet towards a Transport Converter.  The Convert protocol includes
   an optional Cookie TLV that provides similar protection as the TCP
   Fast Open option without consuming space in the extended TCP header.


Better?

Cheers,
Med

> -----Message d'origine-----
> De : Yuchung Cheng [mailto:[e-mail]]
> Envoyé : mercredi 29 mai 2019 23:46
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]
> Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> 
> On Tue, May 28, 2019 at 11:10 PM <[e-mail]> wrote:
> >
> > Hi Yuchung,
> >
> > This spec is an Experiment which relaxes a constraint in RFC793 in the *
> SAME *  way the TFO Experiment relaxes that * SAME * constraint.
> >
> > Given that RFC7413 isn't tagged as updating RFC793, we are assuming that
> the same conclusion applies for our spec.
> >
> > I don't think an Experimental RFC can be tagged as updating RFC793,
> anyway.
> ?Which of my emails asks to tag this draft as RFC793-update?
> 
> I merely pointed out, if TFO is not used, as the draft and the
> original email refer to, the draft should be explicit this requires a
> change in RFC793. It's rather vague.