Re: [multipathtcp] Stephen Farrell's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 03 October 2016 15:43 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C37C21295D3; Mon, 3 Oct 2016 08:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.297
X-Spam-Level:
X-Spam-Status: No, score=-7.297 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, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Noy37Ry8A4-r; Mon, 3 Oct 2016 08:42:58 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B7D1295D9; Mon, 3 Oct 2016 08:42:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B165BE50; Mon, 3 Oct 2016 16:42:56 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRVgzzpJp7mn; Mon, 3 Oct 2016 16:42:56 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B5FB6BE2C; Mon, 3 Oct 2016 16:42:55 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475509376; bh=ifmnE0Y/dxfdZZwO5jb6XozgmFGVyejFez0a03mwLxA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ox3GwMpmTMuB2CIpRgkFntK1eQgoUH4kk4WCy7dl+uDRJ1dWFucld2XnCX8jhnFN6 4YqpITxYXP4grTX+MOvNRLK9gyTYBSHz3ufj7QD/CHOi35QkVjz0woEGyLGagjU1ms KY7sbhP5V7JqFw3seNxX07NLTleJHZ0XCxNkbGs8=
To: philip.eardley@bt.com, Olivier.Bonaventure@uclouvain.be, iesg@ietf.org
References: <147385003530.1966.83385935910172454.idtracker@ietfa.amsl.com> <d8376f59-1fc5-7ba8-8223-e47dd0518381@uclouvain.be> <6847d79e-d40d-3e8f-1800-5a2beeb3a53f@cs.tcd.ie> <c2f7cc19-98cd-3b83-3114-8da4d9027fce@uclouvain.be> <2c171f734083442db9cc60695de9767d@rew09926dag03b.domain1.systemhost.net>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <ce89dd6a-0730-deb0-fb04-93f3c9d64318@cs.tcd.ie>
Date: Mon, 3 Oct 2016 16:42:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <2c171f734083442db9cc60695de9767d@rew09926dag03b.domain1.systemhost.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090008040600090703090504"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/l2HkbOJ2fphyLCR_WFdbqHrbOzc>
Cc: multipathtcp@ietf.org, draft-ietf-mptcp-experience@ietf.org, mptcp-chairs@ietf.org
Subject: Re: [multipathtcp] Stephen Farrell's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 03 Oct 2016 15:43:10 -0000

Hiya,

Sorry, didn't think you were waiting on me. My comment
was non-blocking so going ahead as you consider best is
the right thing to do,

Cheers,
S.

On 03/10/16 16:36, philip.eardley@bt.com wrote:
> I didn’t see any more emails in this thread. Stephen, are you happy
> with the proposed text?
> 
> The proposed text works for me and I think is an interesting point to
> add - but I'm not sure it directly answers your point (I guess the
> answer is something like 'No information about MPTCP-tailored
> attacks' or 'no information that can be shared')
> 
> Olivier & authors - is it possible to do a new version of the
> document please - I think the Discuss and the other comments are
> quite easy to resolve, and it would be good to publish the document
> (finally!)
> 
> Thanks! phil
> 
> 
> -----Original Message----- From: Olivier Bonaventure
> [mailto:Olivier.Bonaventure@uclouvain.be] Sent: 14 September 2016
> 18:55 To: Stephen Farrell <stephen.farrell@cs.tcd.ie>;; The IESG
> <iesg@ietf.org>; Cc: multipathtcp@ietf.org;
> draft-ietf-mptcp-experience@ietf.org; mptcp-chairs@ietf.org;
> Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>; Subject: Re: Stephen
> Farrell's No Objection on draft-ietf-mptcp-experience-06: (with
> COMMENT)
> 
> Hello,
> 
>>> 
>>> Another point is the impact of MPTCP on existing IDS, firewalls
>>> and other types middleboxes that could only see a portion of the
>>> traffic. There have been blackhat presentations on this, e.g.
>>> 
>>> https://www.blackhat.com/docs/us-14/materials/us-14-Pearce-Multipath-
>>>
>>> 
TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf
>>> 
>>> 
>>> I haven't seen deployment of those attacks, but could extend
>>> section 3.5 or discuss this in a bit more details if you think
>>> that this would be useful.
>> 
>> If such text would be considered useful in the RFC, then I'd be for
>>  it. I'm happy that the AD/chairs/editors and WG figure that out.
>> I'm equally happy to review if someone proposes text.
> 
> Here is a proposed text
> 
> 5.  Security Considerations
> 
> The security considerations for Multipath TCP have already been 
> documented in [RFC6181], [RFC6182], [RFC6824] and [RFC7430].
> 
> From a security viewpoint, it is important to note that Multipath 
> TCP, like other multipath solutions such as SCTP, has the ability to 
> send packets belonging to a single connection over different paths. 
> This design feature of Multipath TCP implies that middleboxes that 
> have been deployed on-path assuming that they would observe all the 
> packets exchanged for a given connection in both directions may not 
> function correctly anymore.  A typical example are firewalls, IDS or 
> DPIs deployed in enterprise networks.  Those devices expect to 
> observe all the packets from all TCP connections.  With Multipath 
> TCP, those middleboxes may not observe anymore all packets since
> some of them may follow a different path.  The two examples below 
> illustrate typical deployments of such middleboxes.  The first 
> example, Figure 8, shows a Multipath TCP enabled smartphone attached 
> to both an enterprise and a cellular network.  If a Multipath TCP 
> connection is established by the smartphone towards a server, some
> of the packets sent by the smartphone or the server may be
> transmitted over the cellular network and thus be invisible for the
> enterprise middlebox.
> 
> smartphone +----- entreprise net --- MBox----+------ server |
> | +----- cellular net  -------------+
> 
> 
> Figure 8: Enteprise Middlebox may not observe all packets from 
> multihomed host
> 
> The second example, Figure 9, shows a possible issue when multiple 
> middleboxes are deployed inside a network.  For simplicity, we
> assume that network1 is the default IPv4 path while network2 is the
> default IPv6 path.  A similar issue could occur with per-flow load
> balancing such as ECMP [RFC2992].  With regular TCP, all packets from
> each connection would either pass through Mbox1 or Mbox2.  With
> Multipath TCP, the client can easily establish a subflow over
> network1 and another over network2 and each middlebox would only
> observe a part of the traffic of the end-to-end Multipath TCP
> connection.
> 
> client ----R-- network1  --- MBox1 -----R------------- server |
> | +-- network2  --- MBox2 -----+
> 
> 
> Figure 9: Interactions between load balancing and security 
> Middleboxes
> 
> In these two cases, it is possible for an attacker to evade some 
> security measures operating on the TCP bytestream and implemented on 
> the middleboxes by controlling the bytes that are actually sent over 
> each subflow and there are tools that ease those kinds of evasion 
> [PZ15] [PT14].  This is not a security issue for Multipath TCP
> itself since Multipath TCP behaves correctly.  However, this
> demonstrates the difficulty of enforcing security policies by relying
> only on on- path middleboxes instead of enforcing them directly on
> the endpoints.
> 
> Olivier
>