Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <> Fri, 04 November 2016 11:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 882D112999E for <>; Fri, 4 Nov 2016 04:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ucxYAq-ftMgk for <>; Fri, 4 Nov 2016 04:23:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEFE5129454 for <>; Fri, 4 Nov 2016 04:23:31 -0700 (PDT)
Received: by with SMTP id p190so44232759wmp.1 for <>; Fri, 04 Nov 2016 04:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SlImGDArVOFGfjXNCOoH5tasX0pLJQ3PgNw0vUIUuk8=; b=OR2QaH59HpGJ3I9oAWMXZu9x/eIOShzFwG0Rf7oNQHhaRVIsjZJkrUvjOL8PMVm1fR GH3klwInIpdO6/rX4duhcWz7XDHNXjTewNu/l2KnCAmvvO72Zy+d0l8D5VMhSv+r2Zb5 SzM0K3DfshMNGSNTquT9B1xjxiL0x44KGCyWu4/jQroTDiDnQ/RQ72b+A+hsrppaptFX 2kSVlqcY0pKxg2BqFARad8XtUEbcYakNd5EkQNsqSprnLBSAFqY3uo1lhuSTzgObdUQT SeaooFz+wuFSYmnpoAWZa8PB7JIzRMgPcoWzzOXHhs4oGUwvJAxzMQOCQC0bPL0RF9i2 xaDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SlImGDArVOFGfjXNCOoH5tasX0pLJQ3PgNw0vUIUuk8=; b=KZOXRMBKaJ4/7ct+rCjJSwL0IGrPowiE8u4rBh3772BOeS0Dqjo9gW3BjH5WdGpdyx yUI85Xd39npcOfDcZiFV+K6aUACamfwdUhPKPF8GiEgFjKOKQuAPQk47dI2YxgyY5dib KDwPF2UtInlRH/15nnk0cAgC+Z3LLFtywjs2jZZ7HwwGj3mO6mQU/3aVSZTJ4+lxzKvZ kalL9QAUUBSY/+uU8VB6Cu46s6m5m/egvgBURxzVmRNdFrA4USUFPAVdeXZ32/1nTJ7Z F0hiBgpfjActzUQxYx+y+kRXcN5XDUsU+V6QIxXHmzRSKWElNsNkOsaCj61dl8MzRzJA pkBg==
X-Gm-Message-State: ABUngvdiHI/+atQTJvs/9cpJaJWYdPhiauR4UqVPan8eQwzi4Y2ohcG5i1TI2D4WjyE4TQ==
X-Received: by with SMTP id w187mr3159287wmg.10.1478258610298; Fri, 04 Nov 2016 04:23:30 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id wn5sm13705384wjb.42.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Nov 2016 04:23:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Fri, 04 Nov 2016 11:23:28 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Nov 2016 11:23:34 -0000

Thanks for the comments, Olivier. If the working group thinks it would be a good idea, I would not be opposed to embedding some extended options support in MPTCP - as you say it seems a good chance to do so. I haven’t thought deeply yet about the various options below, all have their merits, but the flag sounds possibly easiest. Whatever extension was used, it could be particularly useful in the future for improved cryptographic handshakes.

This does not change my view, however, that MPTCP options should not be used for application-layer purposes, and that’s my main issue with MP_CONVERT as written - it’s a non-MPTCP-specific application-layer signal masquerading as a MPTCP option.


> On 4 Nov 2016, at 11:07, Olivier Bonaventure <> wrote:
> Alan,
>> Thank you for updating these drafts, I have been awaiting these with great interest!
> ...
>> To be clear - again - I have no issue with this work being done in MPTCP WG, it is “how to use proxies to increase deployment of MPTCP”. But this particular document is not MPTCP-specific; whether it is published here or elsewhere I don’t care, but it really shouldn’t’ be written as if it’s extending the MPTCP spec when there is no reason for it to be.
>> Finally, you earlier mentioned the possible effect on the base spec regarding a flag, but I see no mention of it in these docs.
> Sorry for the late reply. The main problem with the current MPTCP draft is the length of the TCP options in the SYN segment. With network assisted MPTCP, we could need to encode one or two IP addresses inside TCP options in the SYN segment. With IPv4, this might be possible depending on the other options that are used. With IPv6, this becomes quickly a problem.
> As we redefine MP_CAPABLE when moving to RFC6824bis, I think that we should try to design a generic solution to allow a SYN segment to carry long TCP options. This should be part of the Multipath TCP standard specification to ensure that it is future-proof and can be extended later.
> Different designs are possible and some have been discussed in the TCPM working group. Instead of defining a specific option to allow longer options, I would suggest to include this feature directly inside Multipath TCP. This would be cleaner and Multipath TCP is anyway the TCP variant that mostly requires this feature. Here are a few possible designs to start the discussion :
> - always force the TCP SYN segment containing MP_CAPABLE to contain options in the SYN payload. If all options can fit in the extended TCP header, then the payload only contains the TCP EOL option. If there are TCP options in the payload, then the last option is always the EOL option.
> - add a flag to MP_CAPABLE option to indicate whether the SYN payload contains TCP options (terminated by EOL) or not. Same as above for encoding the options in the SYN payload
> - add a length field to MP_CAPABLE option to indicate the number of bytes (or words) of the SYN payload that contain TCP options. In this case, we do not need to terminate the options in the payload with EOL.
> If RFC6824bis could include a reasonable solution that allows to place TCP options in the SYN payload, we would make a huge step to ensure that MPTCP is future-proof and that it will be possible to extend it in the future. In the short term, the solution could be limited to networks where it is known that there are no middleboxes that interfere with TCP options, but this would be a strong message to middlebox vendors that they will need to support TCP options in the SYN payload in the future.
> I won't unfortunately be able to attend the next IETF meeting in Seoul but I'd be happy to discuss this by email
> Olivier