Re: [multipathtcp] Comments on draft-bagnulo-mptcp-privacy-00

marcelo bagnulo braun <> Thu, 18 July 2019 09:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 101D012019B for <>; Thu, 18 Jul 2019 02:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BiuytxRyjtRb for <>; Thu, 18 Jul 2019 02:44:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45B0F12017C for <>; Thu, 18 Jul 2019 02:44:54 -0700 (PDT)
Received: by with SMTP id n9so28003141wru.0 for <>; Thu, 18 Jul 2019 02:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=IFY0EnvQAjw1WTnk34lrFey1P046pH/2TKh+TNusELA=; b=k/HIRYYHNu1dhuCOcAYh1BBWMRFXa3G2U5K6wt6jHQ+ltDvWf6bvkaUpzlmu8BepPg UYk/bwuTzZ3bzodhW6tDPvCSqzru1r7kJYSJjLxTu/sfSyWy6Ar2hWe2n+aXdaj5bs77 FvcuqN4c0k5AlAXWvTMq8oId7VqyfT84Y2nt7Cq9qg/03FxkrnoH4UQtmIoj9aww1I3W f+XrZRkV1T/oJWLdL2znLf7TGlpkSoO1aRnb8WdTq5ei/4WloNVbBxrDmz4d03eCGBOQ Gdlp5yhpbzHGdwYl5yESUBAdyACn2Yy4gcY5gu14a4Exk/ZiRwcs8lCHcoM4VldZIwAR +1dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=IFY0EnvQAjw1WTnk34lrFey1P046pH/2TKh+TNusELA=; b=HmRH1nuEnDSBOj9jBXQte8ScvMuxoceAJL7lfTZvD94GaoCZaHAn5vf04oc6aOwvff nZczzDFjqvwHQtiO7t8CCdrWv9RVgMgrul8QweOMNGsbI1AGQPKLaMS7azfI1LW+Q0cp znaAFlb/2BaRyph5ilNKJq+sRX/bi2ukGrxWRLYOOzcCkljnjOwj3g3ihoPyhBRw5qVh PbRp0WVCG9uONTGzARACMMzbZFUGCcyBuDK+uqRE127bzUST/+xOTb4q3CWwrrw1mDNc DBoXzpGeCEh7JZhxv7n/ds26wJ3Z0uy6wL9uym/HtmL1PcF+Umz9raWY/Rw+ElGd2lRH HfSg==
X-Gm-Message-State: APjAAAVqCU+rC5jBIcIwtaoyM8lcHR7zzNToiRjZwQNRBhMj6ELlTjue kgXkMtXFUEMNpVXxT8rchrobWmFu028=
X-Google-Smtp-Source: APXvYqzVqKMGYT3lyAtlii4EMLh/N5iQTmBSbrzkQobNz5g7iY6AyMveniH1VMRBs3RHreb+X90Puw==
X-Received: by 2002:adf:f246:: with SMTP id b6mr20651035wrp.92.1563443092420; Thu, 18 Jul 2019 02:44:52 -0700 (PDT)
Received: from Macintosh-6.local ( []) by with ESMTPSA id y6sm20800739wrp.12.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 02:44:51 -0700 (PDT)
References: <>
From: marcelo bagnulo braun <>
Message-ID: <>
Date: Thu, 18 Jul 2019 11:44:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [multipathtcp] Comments on draft-bagnulo-mptcp-privacy-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jul 2019 09:44:58 -0000

Hi Olivier,
Thanks for your comments, replies below...

El 16/07/19 a las 16:40, Olivier Bonaventure escribió:
> Marcelo, Amelia, Christoph,
> Thanks for having initiated the above draft. As I will not be able to
> participate to the discussion in Montreal, here are some suggestions and
> comments.
> Generic comments
> First, I think that it would be useful to compare the privacy features
> of QUIC (or a forthcoming Multipath QUIC) with those of MPTCP.
> Obvisouly, given that MPTCP does not encrypt anything, it suffers from
> more types of privacy attacks than QUIC.

I am uncertain about this.

I mean, so far, the security analysis we have done for MPTCP we used TCP 
as a baseline. I think this was a useful approach as it has allowed us 
to progress with realistic expectations and using the rule of not making 
things worse than currently are (i.e. TCP). I think the same approach is 
useful and reasonable for privacy.

Also, what we currently have standardized is MPTCP (not MPQUIC). So, it 
is possible to perform a comparative analysis of two protocols we have 
(MPTCP and TCP). It is much harder to make the analysis of a protocol 
that has not been standardized yet (MPQUIC) as it is a moving target.

That being said, I do agree that there is a value in defining what would 
be the goals and requirements in terms of privacy for MPQUIC or for a 
more secure version of MPTCP that encrypts the payload, but this would a 
different analysis.

In summary, i think there is room for two analysis:

- a analysis the privacy of MPTCP as currently defined and using TCP as 
a baseline. This document would identify the privacy threats that MPTCP 
as currently defined introduces with respect to TCP.

- the definition of goals in terms of privacy (and probably in terms of 
security) for a more secure version of MPTCP and also MPQUIC.

This draft aims to do the first bullet. I am happy to also work on 
another document for the second bullet but i believe are different 
documents as one is an analysis of the residual threats of an existent 
protocol (and proposes minor changes to fix them) and the other one is 
an ex-ante protocol defining the privacy requirements of a new protocol 
(by new i mean major changes than current MPTCP)

> Second, beyond looking at the issues with the current version of MPTCP,
> we could consider whether an hypothetical MPTCP version x could solve
> some of these issues. In the draft, you mention the possibility of
> encrypting some of the MPTCP options. If this is done with the keys
> exchanged in clear during the handshake, it would probably not help.

Well, this depends on the goal we set.

So far, the goal has been to be no more vulnerable to TCP and we are 
essentially vulnerable to an attacker on the path when the key is 
exchanged. The proposed approach would make provide a similar level of 
protection for privacy threats, which i would guess is aligned with the 
current security features of MPTCP.

Agree we could define more ambitious goals, but this would be both for 
privacy and security. See the two analysis that i suggest above.

> However, since a privacy sensitive application would anyway use TLS, why
> not consider a solution like
> that basically extracts the MPTCP keys from the TLS exchange. The above
> draft has experied, but could probably be updated to support TLS 1.3 and
> the latest version of MPTCP.
> If we had this extension inside MPTCP, which options would need to be
> encrypted/authenticated :
> - MP_CAPABLE(no)	
> - MP_JOIN (maybe)
> - DSS (but TCP sequence number would not be encyrpted)
> - MP_PRIO	
> - MP_FAIL	
> Another possible design point is MPTCPSec, see
> A third design point would be to explore the integration of TCPINC and
> MPTCP, if this is possible.

I agree with all these possible approaches for a security/privacy 
enhanced version of MPTCP. I also think there is value in having a minor 
modification that remediates the privacy threats compared to plain TCP.

> Detailed comments
> I think that it would be useful to provide a discussion on privacy
> considerations in the configuration of MPTCP and when add_addr and
> mp_join should be sent. A client that always sends add_addr and creates
> a full mesh of subflows is more vulnerable from this viewpoint than a
> client that does not send add_addr and only sends mp_join when the
> primary path fails. Of course, this increases the reaction time in case
> of failures.

Agree, this is something we wanted to include in the document, but it 
was not clear to me what guidelines to include in there. any suggestions?

> Changing the token in mp_join is something that looks interesting. We
> could imagine a server that provides to its client the next token to be
> used (possibly encrypted). This allows the server to control the
> numberof subflows that a client can establish, and also improves
> privacy. I would encourage you to explore this direction and also
> consider the implementation cost on servers.

Great, we can do that.

Also, I guess we need some mechanism for endpoints to detect if the 
other endpoint supports this mechanism. Fortunately, i dont think this 
is needed to be done in the SYN.

> Considering the benefits of spreading data over multiple paths, there
> are benefits from the viewpoint of countering an attacker willing to
> capture the entire bytestream. On the other hand, an attacker who wishes
> to simply collect metadata about who talks with who would get more data
> from mptcp than from regular tcp...

Not sure what more metadata the attacker would obtain.

I mean, with the current version, it can extract metadata from the ADD 
ADDR and from the MPJOINs, as the draft identifies. You mean that or 
something else beyond what is identified in the draft?

(I am not sure the other options provide any form of useful information 
to the attacker)

> Overal, I think that there are many tradeoffs between privacy, reaction
> to failures, protocol/implementation complexity that would be worth to
> discuss in the draft.

Agree, the idea would be to identify those missing and include them in 
future versions of the document.

Thanks again,

Regards, marcelo

> Best regards,
> Olivier
> _______________________________________________
> multipathtcp mailing list