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, 03 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 >
- [multipathtcp] Stephen Farrell's No Objection on … Stephen Farrell
- Re: [multipathtcp] Stephen Farrell's No Objection… Mirja Kühlewind
- Re: [multipathtcp] Stephen Farrell's No Objection… Stephen Farrell
- Re: [multipathtcp] Stephen Farrell's No Objection… Mirja Kühlewind
- Re: [multipathtcp] Stephen Farrell's No Objection… Olivier Bonaventure
- Re: [multipathtcp] Stephen Farrell's No Objection… Anna Brunstrom
- Re: [multipathtcp] Stephen Farrell's No Objection… Stephen Farrell
- Re: [multipathtcp] Stephen Farrell's No Objection… Olivier Bonaventure
- Re: [multipathtcp] Stephen Farrell's No Objection… philip.eardley
- Re: [multipathtcp] Stephen Farrell's No Objection… Stephen Farrell
- Re: [multipathtcp] Stephen Farrell's No Objection… Olivier Bonaventure