Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08

<mohamed.boucadair@orange.com> Tue, 09 July 2019 13:49 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 5518D12007C; Tue, 9 Jul 2019 06:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 sHec42ecx07n; Tue, 9 Jul 2019 06:49:49 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E2A120139; Tue, 9 Jul 2019 06:49:49 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 45jkG409Rlz8t00; Tue, 9 Jul 2019 15:49:48 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 45jkG368Ykz2xCg; Tue, 9 Jul 2019 15:49:47 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 15:49:47 +0200
From: <mohamed.boucadair@orange.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "Michael.Scharf@hs-esslingen.de" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org" <tcpm@ietf.org>
CC: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Thread-Topic: WGLC for draft-ietf-tcpm-converters-08
Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACioYfACL1MtoAAE0urA
Date: Tue, 9 Jul 2019 13:49:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAC7701@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <6EC6417807D9754DA64F3087E2E2E03E2D35AB8E@rznt8114.rznt.rzdir.fht-esslingen.de> <LNXP123MB258781EFAC897351EDB153E2EBFD0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <787AE7BB302AE849A7480A190F8B93302EAAF3AA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <LNXP123MB25875A76F9E90134441667F7EBF10@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LNXP123MB25875A76F9E90134441667F7EBF10@LNXP123MB2587.GBRP123.PROD.OUTLOOK.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/sX-6fbub0G3zeSn1ydCF_8jKWZA>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
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: Tue, 09 Jul 2019 13:49:53 -0000

Hi Phil,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> Envoyé : mardi 9 juillet 2019 12:08
> À : BOUCADAIR Mohamed TGI/OLN; Michael.Scharf@hs-esslingen.de;
> tcpm@ietf.org
> Cc : tcpm-chairs@ietf.org
> Objet : RE: WGLC for draft-ietf-tcpm-converters-08
> 
> Med,
> Thanks, just following up a couple of points.
> >
> > S4.1 title
> > "fixed header" - is "fixed" needed?
> 
> [Med] It is fixed because it is present in all convert messages. Do you
> prefer "common" ?
> 
> [phil] I'd prefer if you explicitly stated that all Convert messages have
> this header.
> In fact, I think you could start Section 4 with text to capture the key
> points:
> "This section describes the messages that are exchanged between a Client
> and a Transport Converter. All Convert protocol messages MUST be sent on a
> SYN, ACK or SYN-ACK, to port [tba]. All Convert protocol messages MUST be
> sent as the first bytes of the bytestream and MUST use the header shown in
> Figure 9 and described in Section 4.1, followed by the message itself
> using the generic TLV format shown in Figure 10 and described in Section
> 4.2. "

[Med] Thanks. Some of this proposed text is redundant with existing text, e.g.,

   The Client and the Transport Converter MUST send the fixed-sized
   header, shown in Figure 9, as the first four bytes of the bytestream.

While other part of the text may not be accurate for incoming connections (MUST be sent ...to port (TBA)).

Now that I see more your point, I made some tweaking to address your comment as shown in:
https://github.com/obonaventure/draft-tcp-converters/pull/63/files 

> 
> >
> > " Transport Converter SHOULD include in this
> >    list the TCP options that it accepts from Clients and that it
> >    includes the SYN packets that it sends to initiate connections."
> > I couldn't parse the second part of the sentence ("and that it...")
> >
> 
> [Med] Changed to:
> 
> " A Transport Converter SHOULD include in
> this list the TCP options that it accepts from Clients; these options are
> included by the Transport Converter in the SYN packets that it sends to
> initiate connections."
> 
> Better?
> 
> [phil] Yes. Instead of "are included" you could say MUST /SHOULD /MAY

[Med] This would be redundant with the "SHOULD" in that text. 

> 
> 
> > Section 6
> > This section actually only discusses one type of middlebox (removes
> SYN).
> > Can the discussion be widened slightly
> 
> [Med] This section only focuses on SYN/SYN-ACK because these are used by
> the Convert protocol.
> 
> Do you have in mind a particular case (specific to the Convert protocol)
> that may be problematic?
> 
> [phil] the section only discusses removal of SYN, and not other ways a
> middlebox could interfere with the SYN/ACK.

[Med] The following cases can be considered for SYN/ACKs: 

(1) a middlebox that drops SYN/ACKs having a payload is straightforward. The client won't naturally be able to establish the connection via the converter.  

(2) a middlebox that removes the payload of SYN/ACKs:
 2-a. If that middlebox removes also the payload of SYNs (which is likely), this would have been detected by the client as per the text already in the draft. 
 2-b. If that middlebox lets pass SYNs with their payload but removes the payload of SYN/ACKs (for some mysterious reasons): This can be easily handled by the client because it expects an Error or Extended TCP Header TLV in the response. If an Error TLV was included, a message to terminate the connection would be sent by the Converter. Otherwise, there is no reason to close the connection.  

Do you think that "2-b" is likely and is worth to be documented in the text? Thank you.  

> 
> Thanks
> phil