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

<mohamed.boucadair@orange.com> Wed, 05 June 2019 12:18 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 44A131200E9 for <tcpm@ietfa.amsl.com>; Wed, 5 Jun 2019 05:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 BhSdlav9RzpM for <tcpm@ietfa.amsl.com>; Wed, 5 Jun 2019 05:18:30 -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 684CB12006E for <tcpm@ietf.org>; Wed, 5 Jun 2019 05:18:30 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 45JnrN6h78zFr5f; Wed, 5 Jun 2019 14:18:28 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 45JnrN5MS3z5vMv; Wed, 5 Jun 2019 14:18:28 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0439.000; Wed, 5 Jun 2019 14:18:28 +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: AQHVGjZWv8JnQKhvd0WO/UEMDkxhS6aM+59A
Date: Wed, 5 Jun 2019 12:18:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA94D8D@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>
In-Reply-To: <CAK6E8=cp7DO0Zho58-SVX9xcZXo-BQ6WsmVkBGHMDm5kbW4NiQ@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.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/hOel2-PYQotoxvPnk6g3QL54i9A>
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: Wed, 05 Jun 2019 12:18:32 -0000

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. 

> 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.