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

Stephen Farrell <> Mon, 03 October 2016 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C37C21295D3; Mon, 3 Oct 2016 08:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.297
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Noy37Ry8A4-r; Mon, 3 Oct 2016 08:42:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73B7D1295D9; Mon, 3 Oct 2016 08:42:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B165BE50; Mon, 3 Oct 2016 16:42:56 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pRVgzzpJp7mn; Mon, 3 Oct 2016 16:42:56 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id B5FB6BE2C; Mon, 3 Oct 2016 16:42:55 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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=
References: <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090008040600090703090504"
Archived-At: <>
Subject: Re: [multipathtcp] Stephen Farrell's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)
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: Mon, 03 Oct 2016 15:43:10 -0000


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,


On 03/10/16 16:36, 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
> [] Sent: 14 September 2016
> 18:55 To: Stephen Farrell <>;; The IESG
> <>; Cc:;
> Eardley,PL,Philip,TUB8 R <>; Subject: Re: Stephen
> Farrell's No Objection on draft-ietf-mptcp-experience-06: (with
> 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.
>>> 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