IETF Logo Mail Archive

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Joe Touch <touch@isi.edu> Wed, 19 July 2017 16:43 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCB131472; Wed, 19 Jul 2017 09:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 NtntyiVKVI94; Wed, 19 Jul 2017 09:43:40 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 3DDF9129482; Wed, 19 Jul 2017 09:43:40 -0700 (PDT)
Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JGh2Gb025051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:43:03 -0700 (PDT)
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>, Internet Area <int-area@ietf.org>, tsv-area@ietf.org
References: <fe384d2b-a0ba-9444-2ee9-cd0de6d24b7c@tessares.net> <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net>
From: Joe Touch <touch@isi.edu>
Message-ID: <aa347f86-6be0-57b4-cd84-628eeaab6261@isi.edu>
Date: Wed, 19 Jul 2017 09:43:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/R1KNWxw7p54iE85CukJEp7d6uUg>
Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 16:43:41 -0000


On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
> Joe,
>
>> - but I remain concerned with "injection piggybacking"
>
> To which section of the draft are you referring to ?
It starts in the arch discussion in Sec 2:

   As shown in Figure 3, the Converter places its supplied information
   inside the handshake packets. 

That's what I refer to as "injection piggybacking"

   With TCP, the Converter protocol places the destination address and
   port number of the final Server in the payload of the SYN.

And that is the part that violates RFC793 semantics when that SYN reaches the final destination rather than the server-side proxy.

To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things.

Joe

v2.23.0 | Report a Bug | By Email