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

Yuchung Cheng <ycheng@google.com> Wed, 05 June 2019 18:00 UTC

Return-Path: <ycheng@google.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 E5C7312021F for <tcpm@ietfa.amsl.com>; Wed, 5 Jun 2019 11:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level:
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 rVqoilqKQh32 for <tcpm@ietfa.amsl.com>; Wed, 5 Jun 2019 11:00:24 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB951201D6 for <tcpm@ietf.org>; Wed, 5 Jun 2019 11:00:08 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id m3so4588730wrv.2 for <tcpm@ietf.org>; Wed, 05 Jun 2019 11:00:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wS2CgW3IvrjuHajm3TfBO97+9KJTG2qrVmjq7P3FOzc=; b=p6a5C1/ORduDnUTf3tn04qnlZVclsg3IJ4chA27MzXczG+OE/1cIYFfIyJjhbsky8L EbREMlvuTGfjMotz6JLf2ZJAQS45MAHLPz6IytU3/g5h5uBcH0wvZpjdqHP4GCLli54G 888oAVLDY/qAhPvSJ46/Iw3yS+FSBjAsxb1eBXPdPHskqIq71v8OLxPTIpKkSsmfbyB1 emUs49l6DdwIq6UI3xrnqtSQrHyEHh1QlkwDgZYHqEW/tTeCyP4WVfA25sT75sxcjucl aWQAHrXAtt2qgI5bGL8HwxvkX3UVyM7vqWVlFtvF40AP5jmyScns5VnEFezYHE2ktLCe 5SeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wS2CgW3IvrjuHajm3TfBO97+9KJTG2qrVmjq7P3FOzc=; b=SHkDSZY7nn6/NzjnY7MLu57FCyMDY/h+jSqN9XqxXCK2nRTXyygCkV9EWt8QeWJdwB OMYCXnfH/7f8Gq1Cedr1klOj5zBOEp5W0yQRhkz6wcaJBgY7jMMO0tHUGscfGJ3VAxUP /Qwd8ePWNqG7mut5NNMAV+4WouPFgpXfPv3NFFjbCa/xgXRZKFFZaloQvKPd0ElLUDUB YiHVWRAHTXPj+mNiFc4Ks0AFh2M+XEWxxr3+zNIrxBnWx/FWGIZCTEX3TLhq7P59cFum HOdjMVmxaTxJ3Ap60/+lGiqJK1XYY8qnrGHDElaDCjyoOCIDvlA1K7FBqeo5q5MIRTYv Depg==
X-Gm-Message-State: APjAAAUMRd38WhMUyg07EEebNDBIw4TK1c0teqmmNGIdOTmOZEk4EHIh eZhrv8IqzMmBBjeFfq32CzazHui/C4/mRSIBNpzx3w==
X-Google-Smtp-Source: APXvYqzXNroXLWeib2WnFNynBhuPh2AHPlGFyIS9czkOQg82iFpvJc8SUj/AhigpQKpbymS4HQiDf+C9lXCotyAvv/E=
X-Received: by 2002:adf:e485:: with SMTP id i5mr13038737wrm.75.1559757606101; Wed, 05 Jun 2019 11:00:06 -0700 (PDT)
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
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 18:00:27 -0000

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.