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

<mohamed.boucadair@orange.com> Fri, 31 May 2019 12:17 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 2355E12009C for <tcpm@ietfa.amsl.com>; Fri, 31 May 2019 05:17:12 -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 xzKnjxFfak-G for <tcpm@ietfa.amsl.com>; Fri, 31 May 2019 05:17:09 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F2312008F for <tcpm@ietf.org>; Fri, 31 May 2019 05:17:09 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45Fk373lHlz7w7C; Fri, 31 May 2019 14:17:07 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 45Fk3732FczCqkj; Fri, 31 May 2019 14:17:07 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([fe80::b43f:9973:861e:42af%21]) with mapi id 14.03.0439.000; Fri, 31 May 2019 14:17:07 +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: AQHVFmfwiaNp2b0xbUChdFcAEBfRmqaFJeMw
Date: Fri, 31 May 2019 12:17:06 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA9301E@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>
In-Reply-To: <CAK6E8=d+w9dTTJLNdgzBrpPt=jp=Z+g_jqi1kJo+mEerMzvEqA@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/YdsBzdxztjFufXj-pGrpSQ6iV9U>
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: Fri, 31 May 2019 12:17:12 -0000

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