MIME-Version: 1.0
References: <F92BF1E2-60EB-4E48-84A4-1C82589A056A@tessares.net>
 <CAK6E8=f-TAUWs3x4P9XHUHbvRhOqBhH9GU910Yoy5v_0vzUxAQ@mail.gmail.com>
 <A0496204-331F-4D8E-A1C1-83D3E1CE759B@tessares.net>
 <CAK6E8=e0RVzfRA0j=y8EZK0HonH6vaMBL6m-U3L+8cNO-zpqqw@mail.gmail.com>
 <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
 <CAK6E8=cDrLB0Oop2act7jCe_CYnNd2gJZU06ZHg_zJXXh_VOXg@mail.gmail.com>
 <MW2PR2101MB1049E8330D990998817F1A82B6020@MW2PR2101MB1049.namprd21.prod.outlook.com>
 <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
 <MW2PR2101MB10493385260DA9D53B92B1A4B61E0@MW2PR2101MB1049.namprd21.prod.outlook.com>
 <CAK6E8=cMEPW9Qv_tTuCW42uZOPLBVr2qNutC7EjbRTtWMRr8kA@mail.gmail.com>
 <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
 <CAK6E8=d+w9dTTJLNdgzBrpPt=jp=Z+g_jqi1kJo+mEerMzvEqA@mail.gmail.com>
 <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
 <CAK6E8=cp7DO0Zho58-SVX9xcZXo-BQ6WsmVkBGHMDm5kbW4NiQ@mail.gmail.com>
 <787AE7BB302AE849A7480A190F8B93302EA94D8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA94D8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 5 Jun 2019 10:59:27 -0700
Message-ID: <CAK6E8=f14gTkh34RTckXm9zupk4J3NFqZiODQ2a4oY2CPkScMQ@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/kgHGCgsV2lbaBB6CftbhPRmBjdM>
Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters
Precedence: list

On Wed, Jun 5, 2019 at 5:18 AM <mohamed.boucadair@orange.com> wrote:
>
> Hi Yuchung,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Yuchung Cheng [mailto:ycheng@google.com]
> > Envoy=C3=A9 : lundi 3 juin 2019 20:01
> > =C3=80 : BOUCADAIR Mohamed TGI/OLN
> > Cc : tcpm@ietf.org
> > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> >
> > On Fri, May 31, 2019 at 5:17 AM <mohamed.boucadair@orange.com> wrote:
> > >
> > > Hi Yuchung,
> > >
> > > Thank you for clarifying your concern. Below a text proposal to addre=
ss
> > 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 i=
t
> > >    to the application until completion of the three-way-handshake.  T=
o
> > >    enable applications to exchange data in a TCP handshake, this
> > >    specification follows an approach similar to TCP Fast Open [RFC741=
3]
> > >    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 flood=
ing
> > >    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 consum=
es
> > >    space in the limited TCP extended header.  Furthermore, there are
> > >    situations, as noted in Section 7.3 of [RFC7413] where it is possi=
ble
> > >    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 establishm=
ent
> > >    packet towards a Transport Converter.  The Convert protocol includ=
es
> > >    an optional Cookie TLV that provides similar protection as the TCP
> > >    Fast Open option without consuming space in the extended TCP heade=
r.
> > 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 t=
he 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:ycheng@google.com]
> > > > Envoy=C3=A9 : mercredi 29 mai 2019 23:46
> > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN
> > > > Cc : tcpm@ietf.org
> > > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> > > >
> > > > On Tue, May 28, 2019 at 11:10 PM <mohamed.boucadair@orange.com> wro=
te:
> > > > >
> > > > > Hi Yuchung,
> > > > >
> > > > > This spec is an Experiment which relaxes a constraint in RFC793 i=
n
> > the *
> > > > SAME *  way the TFO Experiment relaxes that * SAME * constraint.
> > > > >
> > > > > Given that RFC7413 isn't tagged as updating RFC793, we are assumi=
ng
> > that
> > > > the same conclusion applies for our spec.
> > > > >
> > > > > I don't think an Experimental RFC can be tagged as updating RFC79=
3,
> > > > 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.