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

<mohamed.boucadair@orange.com> Thu, 06 June 2019 05:10 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96271120155 for <tcpm@ietfa.amsl.com>; Wed, 5 Jun 2019 22:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNpgCRw-ZTq0 for <tcpm@ietfa.amsl.com>; Wed, 5 Jun 2019 22:10:31 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A8812001A for <tcpm@ietf.org>; Wed, 5 Jun 2019 22:10:31 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45KDJ54PQQz7xDs; Thu, 6 Jun 2019 07:10:29 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 45KDJ53XQZz3wbV; Thu, 6 Jun 2019 07:10:29 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0439.000; Thu, 6 Jun 2019 07:10:29 +0200
From: <mohamed.boucadair@orange.com>
To: Yuchung Cheng <ycheng@google.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters
Thread-Index: AQHVG8iDmtUDPMaDPkybIR3w2SVBOqaOFAkQ
Date: Thu, 6 Jun 2019 05:10:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA9D704@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <CAK6E8=f14gTkh34RTckXm9zupk4J3NFqZiODQ2a4oY2CPkScMQ@mail.gmail.com>
In-Reply-To: <CAK6E8=f14gTkh34RTckXm9zupk4J3NFqZiODQ2a4oY2CPkScMQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/G39V0U6q-Rw6XbnyhYMkxehd1RU>
Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2019 05:10:34 -0000

Hi Yuchung, 

Thank you. 

We will release an updated version with this NEW text.

Cheers,
Med

> -----Message d'origine-----
> De : Yuchung Cheng [mailto:ycheng@google.com]
> Envoyé : mercredi 5 juin 2019 19:59
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : tcpm@ietf.org
> Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> 
> 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é : lundi 3 juin 2019 20:01
> > > À : 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
> 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:ycheng@google.com]
> > > > > Envoyé : mercredi 29 mai 2019 23:46
> > > > > À : 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>;
> 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.