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

[Yuchung Cheng <[e-mail]>]

On Wed, Jun 5, 2019 at 5:18 AM <[e-mail]> wrote:
>
> Hi Yuchung,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Yuchung Cheng [mailto:[e-mail]]
> > Envoyé : lundi 3 juin 2019 20:01
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : [e-mail]
> > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> >
> > On Fri, May 31, 2019 at 5:17 AM <[e-mail]> wrote:
> > >
> > > 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.
> > Sorry for the late reply. How about adding to the last sentence:
> >
> > "When TFO is not used, the transport converter needs a corresponding
> > change to RFC793 to allow posting data in SYN to application upon
> > receiving the SYN packet".
> >
>
> [Med] I'm afraid that the proposed sentence can be misinterpreted as if the use of TFO would not require that change to 793. The first paragraph of the proposed text already indicate that a change is needed.
Sure that works for me.

>
> > Thanks for the improved wording.
> > >
> > >
> > > 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.