Re: [multipathtcp] Stephen Farrell's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)
Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Wed, 14 September 2016 17:54 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 B5CEB12B3F7; Wed, 14 Sep 2016 10:54:50 -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 LNLisOLhhYaC; Wed, 14 Sep 2016 10:54:49 -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 B936E12B3EF; Wed, 14 Sep 2016 10:54:48 -0700 (PDT)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (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 CBBA967DBB8; Wed, 14 Sep 2016 19:54:40 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be CBBA967DBB8
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1473875681; bh=IFAZUX69dhr+/A4+LKhF8tU4WYuHDZ7M9vvwLDpbzMg=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=MfXAuB4+Bgxg6DrhK7JWYROsIlALwzW3kw8REQwqSu79rY9Thn6LkVDvk/Fq8v2ZO +DdRERiMBI1QjJJbTYrqhhS/zUdZNKbdWOdySuAsRmk3oXYxJiaEpmTpXsq4WyaNi0 bocU0bV8Me0ivXq5uO4ShvyuwyeoHK0hp1wU31Sw=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-3
References: <147385003530.1966.83385935910172454.idtracker@ietfa.amsl.com> <d8376f59-1fc5-7ba8-8223-e47dd0518381@uclouvain.be> <6847d79e-d40d-3e8f-1800-5a2beeb3a53f@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <c2f7cc19-98cd-3b83-3114-8da4d9027fce@uclouvain.be>
Date: Wed, 14 Sep 2016 19:54:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <6847d79e-d40d-3e8f-1800-5a2beeb3a53f@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: CBBA967DBB8.A7B31
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/uxOmc3SxCiLDR7uJvcXfHcANmWY>
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
Reply-To: Olivier.Bonaventure@uclouvain.be
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: Wed, 14 Sep 2016 17:54:51 -0000
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