Re: [multipathtcp] explicit mode for smartphone scenario

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Tue, 28 March 2017 07:32 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFB2127876 for <multipathtcp@ietfa.amsl.com>; Tue, 28 Mar 2017 00:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 z5E1jpkk8--w for <multipathtcp@ietfa.amsl.com>; Tue, 28 Mar 2017 00:32:53 -0700 (PDT)
Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF82129413 for <multipathtcp@ietf.org>; Tue, 28 Mar 2017 00:32:53 -0700 (PDT)
Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 88B7467DC84; Tue, 28 Mar 2017 09:32:34 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 88B7467DC84
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1490686354; bh=sVoxVNXkFa6wEOGmhibxYxQ/SntKRERVJp2wkajEyS8=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=rOuWQXYZD5aQ000idT6FwTY0cUmegIxyFHTX7SImTheLAXb6lnWQHHAkju0AAlmBb BntsCKyfG0P2jezIivspda9FFZbkzVIaQijb7dnejZZqEx/SD8Jasm/uF/unzuEnJl WQa+FBWahjk1Oj/Gwe081Jhob0TzPs8IjbFWWOno=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3
Reply-To: Olivier.Bonaventure@uclouvain.be
References: <11215e1e3fdf4500958a24524d123bf0@rew09926dag03b.domain1.systemhost.net>
To: philip.eardley@bt.com, multipathtcp@ietf.org
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <c3832e09-3c71-2b42-6ad6-620a51eb3eea@uclouvain.be>
Date: Tue, 28 Mar 2017 09:32:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <11215e1e3fdf4500958a24524d123bf0@rew09926dag03b.domain1.systemhost.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: 88B7467DC84.A4568
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/uAkqFjXwnYIfcqGAcrtEtpjPMu0>
Subject: Re: [multipathtcp] explicit mode for smartphone scenario
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 07:32:56 -0000

Phil,
>
> So continuing to concentrate first **specifically** on the solution for
> this use case:
>
> <<. The other scenario involves an MPTCP-enabled smartphone, with LTE
> and WiFi, plus a proxy in the operator’s network.>>
>
> And now looking at “explicit” solutions – meaning the smartphone is
> configured to know about the proxy.
>
>
>
> I’d like to understand better the pros and cons of the solution proposed
> in the plain-mode draft and the solution that uses SOCKS protocol
> between smartphone and the proxy.  (I’m not sure where /if the latter is
> fully defined, described in
> https://www.ietf.org/proceedings/93/slides/slides-93-mptcp-3.pdf  and
>  https://dial.uclouvain.be/downloader/downloader.php?pid=thesis%3A366&datastream=PDF_01

There are different variants of SOCKS that can be used. They mainly 
depend on the number of messages that are used to authenticate the 
smartphone. In
https://inl.info.ucl.ac.be/system/files/PAM2016_54-deconinck.pdf
we used a SOCKS proxy that was configured with very weak authentication 
to minimise the additional delay for the establishment of the TCP 
connections. I don't know which type of authentication has been deployed 
in Korea.

There are two issues that need to be considered when deploying proxies 
for the smartphone use case :

a- minimise the end-to-end connection establishment time. Ideally, it 
should be possible to create an end-to-end connection with a single 
handshake and thus a single end-to-end rtt. When we analysed real 
smartphone traffic, we found that many connections were very short. 
SOCKS requires additional rtts between the smartphone and the proxy to 
establish eash connection. The plain-mode minimises the end-to-end 
connection establishment delay compared to SOCKS proxies.

b- authenticate the client (resp. the proxy) on the proxy (resp. the 
client) and possibly encrypt the traffic. SOCKS supports several 
mechanisms to authenticate the client and some implementation of SOCKS, 
such as the popular shadowsocks that was used in the PAM paper mentioned 
above, support proprietary authentication scheme. Encrypting wireless 
traffic makes a lot of sense in the smartphone scenario since it will 
likely hop from one WiFi network to another. Note that some operators 
could want to restrict the utilisation of the proxies on cellular and 
WiFi networks that they operate. On such networks, the IP addresses 
assigned by the operator could be sufficient to authenticate the 
client/proxy.




Olivier