[multipathtcp] MPTCP backup flag attack via MP_PRIO message
"Zhiyun Qian" <zhiyunq@cs.ucr.edu> Thu, 20 July 2017 07:28 UTC
Return-Path: <zhiyunq@cs.ucr.edu>
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 268E1126B72 for <multipathtcp@ietfa.amsl.com>; Thu, 20 Jul 2017 00:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DrNDGvRbrfQ0 for <multipathtcp@ietfa.amsl.com>; Thu, 20 Jul 2017 00:28:52 -0700 (PDT)
Received: from lists.cs.ucr.edu (fenris.cs.ucr.edu [169.235.30.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17FA126557 for <multipathtcp@ietf.org>; Thu, 20 Jul 2017 00:28:52 -0700 (PDT)
Received: from webmail.cs.ucr.edu (localhost [127.0.0.1]) by lists.cs.ucr.edu (Postfix) with ESMTP id 0E06A2C0592; Thu, 20 Jul 2017 00:28:52 -0700 (PDT)
Received: from 66.215.234.244 (SquirrelMail authenticated user zhiyunq) by webmail.cs.ucr.edu with HTTP; Thu, 20 Jul 2017 00:28:52 -0700
Message-ID: <800c331f808d608354fc00be24283cb6.squirrel@webmail.cs.ucr.edu>
Date: Thu, 20 Jul 2017 00:28:52 -0700
From: Zhiyun Qian <zhiyunq@cs.ucr.edu>
To: multipathtcp@ietf.org
Cc: Ali Munir <munirali@msu.edu>, Zubair <zubair-shafiq@uiowa.edu>, Alex Liu <alexliu@cse.msu.edu>, Franck Le <fle@us.ibm.com>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
User-Agent: SquirrelMail/1.4.22-16.el7
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/WWWaQ3AKWEMgsBSPKc_R9Ct_YoI>
Subject: [multipathtcp] MPTCP backup flag attack via MP_PRIO message
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: Thu, 20 Jul 2017 07:28:54 -0000
Dear all, We are a group of researchers (cc:ed on the email) who recently discovered a security flaw in the MP_PRIO messge that allows a man-in-the-middle attacker on a single path to divert all traffic to its own path, effectively hijacking the entire MPTCP connection. Below we describe the problem in brief (more details will be found in our upcoming ICNP paper. We also hope to submit an Internet draft soon). We thank Olivier Bonaventure for his valuable feedback. --------------------------------------------------------------- MPTCP supports using sub-connections as backup i.e., using a sub-connection to send data only if there is no other sub-connection available. Specifically, an MPTCP host can send a request to the other host to set any sub-connection as a backup by using the MPTCP MP_PRIO option. Hosts can request change in the priority to use a subconnection as regular or backup. To set a sub-connection as backup, a host can request a change in the sub-connection priority by sending MPTCP MP_PRIO option to the other host with the corresponding address identifier. The key property of MP_PRIO messages is that they can be sent on any sub-connection. The reason is that if a sub-connection is already congested, it may not be possible to deliver the message to pause itself. After receiving such a control packet, the sender will stop sending data and the corresponding sub-connections throughput will drop to zero. Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no authentication required by the specification whatsoever, allowing an attacker controlling only one path to set any sub-connection as backup and launch traffic divergence and connection hijack attacks. The backup flag vulnerability allows an attacker to divert traffic among MPTCP sub-connections. An attacker can offload traffic from the eavesdropped sub-connection to other MPTCP sub-connections by sending forged packets with the MP_PRIO option to set the eavesdropped sub-connection as a backup. An attacker can also onload traffic from non-eavesdropped sub-connections to the eavesdropped sub-connection by sending forged packets with the MP_PRIO option to set all other sub-connections as backup. This attack is similar to connection hijack attack, where an attacker diverts all the traffic to pass through the sub-connection on the eavesdropped path. Connection Hijack Example: Consider a scenario where two sub-connections of an MPTCP connection pass through paths p1 and p2. An attacker can hijack the non-eavesdropped subconnection on p2 by dynamically changing the priority of a sub-connection and declaring it as backup. To launch this attack an attacker only needs to know the address identifier of the host , which can be obtained by eavesdropping other paths or easily guessed as they are set incrementally in current Linux implementation of MPTCP. Since the identifier has only 8 bits, it can even be brute forced. To set a non-eavesdropped sub-connection as backup between hosts A and B, an attacker can request a change in the sub-connection priority by sending MPTCP MP_PRIO option to host B with the address identifier of host A. Since by design the MP_PRIO messages can be sent on any sub-connection, the attacker eavesdropping on any path capable of sending such a forged backup message can pause any other path. Note that a backup MPTCP sub-connection may still be used for data transmission later, which can be detected by the attacker by observing the overall MPTCP throughput. Effectively, this attack degrades an MPTCP connection to a regular TCP connection as all traffic will be routed through the attacker-controlled path. We argue that this vulnerability makes MPTCP less secure than TCP, because the entire MPTCP connection can be compromised (fully controlled by an attacker) as long as any one of the communication paths is compromised. Unfortunately, MPTCP specification does not include any authentication mechanism whatsoever regarding the MP_PRIO message. We discuss several solutions in a forthcoming paper [ICNP2017], but a simple approach to cope with this attack would be to reconsider the utilisation of the address identifier in the MP_PRIO option. This option allows a host to set/change the priority of all the subflows associated to a given address identifier on another subflow. It could have use cases, such as sending MP_PRIO over a WiFi subflow to put the cellular subflow in backup mode without sending a packet over the cellular interface, but this looks like an edge case. Looking at the attack that we have identified, the working group should evaluate the removal of the address identifier in rfc6824bis. If the MP_PRIO option does not include an address identifier, then it becomes impossible for an attacker who is on-path of a given subflow to change the priority of the other subflows. Best, -Zhiyun
- [multipathtcp] MPTCP backup flag attack via MP_PR… Zhiyun Qian
- Re: [multipathtcp] MPTCP backup flag attack via M… Alan Ford
- Re: [multipathtcp] MPTCP backup flag attack via M… Olivier Bonaventure
- Re: [multipathtcp] MPTCP backup flag attack via M… Christoph Paasch
- Re: [multipathtcp] MPTCP backup flag attack via M… Alan Ford
- Re: [multipathtcp] MPTCP backup flag attack via M… Zhiyun Qian
- Re: [multipathtcp] MPTCP backup flag attack via M… Zhiyun Qian
- Re: [multipathtcp] MPTCP backup flag attack via M… Christoph Paasch
- Re: [multipathtcp] MPTCP backup flag attack via M… Yoshifumi Nishida
- Re: [multipathtcp] MPTCP backup flag attack via M… Alan Ford
- Re: [multipathtcp] MPTCP backup flag attack via M… Yoshifumi Nishida
- Re: [multipathtcp] MPTCP backup flag attack via M… Alan Ford
- Re: [multipathtcp] MPTCP backup flag attack via M… Yoshifumi Nishida
- Re: [multipathtcp] MPTCP backup flag attack via M… Olivier Bonaventure
- Re: [multipathtcp] MPTCP backup flag attack via M… Yoshifumi Nishida