Internet DRAFT - draft-bagnulo-mptcp-privacy
draft-bagnulo-mptcp-privacy
Network Working Group M. Bagnulo
Internet-Draft UC3M
Intended status: Experimental A. Andersdotter
Expires: January 9, 2020 Article 19
C. Paasch
Apple
July 8, 2019
Privacy threats and possible countermeasures for Multipath-TCP (MPTCP)
draft-bagnulo-mptcp-privacy-00.txt
Abstract
This note performs a differential analysis of the threats regarding
privacy of the Multipath TCP protocol compared to regular TCP and
proposes a set of countermeasures for the threats identified.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Bagnulo, et al. Expires January 9, 2020 [Page 1]
Internet-Draft MPTCP privacy July 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Types of attackers . . . . . . . . . . . . . . . . . . . 3
2.2. Detailed attack mechanics. . . . . . . . . . . . . . . . 4
2.2.1. Attacks using MP_CAPABLE and MP_JOIN. . . . . . . . . 4
2.2.2. Attacks using ADD_ADDR. . . . . . . . . . . . . . . . 4
3. Countermeasures. . . . . . . . . . . . . . . . . . . . . . . 4
4. MPTCP privacy features. . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Multipath-TCP (MPTCP) [RFC6824] [I-D.ietf-mptcp-rfc6824bis] is a set
of extensions to TCP that enable the use of multiple IP addresses
throughout the lifetime of a (MP)TCP connection. The use of multiple
addresses in a connection allows two main uses cases, namely mobility
and multihoming. In the case of multihoming, if an endpoint is
connected to the Internet through multiple interfaces simultaneously
(each ones having a different IP address), the use of MPTCP allow
additional fault tolerance as the connection can be preserved by
using an alternative IP address even if the IP address originally
used to establish the connection is rendered unavailable. In the
case of mobility, as an endpoint changes is attachment to the
Internet, it acquires a new IP address associated to its new
attachment point. By using MPTCP, connections can be preserved
throughout the changes of attachment points and their respective IP
addresses by adding the new IP addresses to the ongoing MPTCP
connections.
Because of its very nature, the operation of MPTCP presents privacy
implications, as other protocols that bind multiple IP addresses to a
given endpoint [I-D.nordmark-id-loc-privacy]. Because MPTCP
explicitly associated multiple IP addresses to a given connection and
hence to a given endpoint, it discloses information about the node
whereabouts to third parties. In this note, we perform an analysis
of the privacy implications of the operation of the MPTCP compared to
regular TCP and we provide a set of countermeasures to address the
identified threats. It is out of the scope of this document to
identify privacy threats that equally affect both MPTCP and TCP, such
Bagnulo, et al. Expires January 9, 2020 [Page 2]
Internet-Draft MPTCP privacy July 2019
as the ones resulting from exchanging unencrypted data that can be
observed by eavesdroppers along the path. As mentioned earlier, we
only identify threats against privacy introduced by MPTCP which are
not present in TCP.
2. Threat Analysis
The threats concerning privacy of the use of MPTCP are essentially
two:
Movement tracking: In the case that MPTCP is used for mobility,
the use of multiple addresses in the same MPTCP connection can be
used by an attacker to track the movement of the victim. Since IP
addresses can be related to location (in a more or less accurate
manner), by observing the different addresses used in a MPTCP
connection, the attacker can track the itinerary of the victim.
More accurate positioning. If multiple address are used
simultaneously in a MPTCP connection, this implies that the
endpoint is connected at the multiple attachment points at the
same time, potentially providing the means for a more accurate
positioning of the endpoint (e.g. if an endpoint is exposing the
IP address of the cellular access it is providing less information
than when it also exposes the IP address of an Internet coffee
wifi access).
2.1. Types of attackers
We classify the types of attackers based on their topological
location, which determines the amount of information they have access
to. the different types of attackers are:
Partially on-path attacker. This attacker is located along one or
more, but not all the paths used to exchange MPTCP signaling
information. As such, it is able to see some but not all the
MPTCP packets.
Full On-path attacker. This attacker is able to eavesdrop all the
MPTCP signaling message exchange, but it is not the other endpoint
of the information.
Endpoint: in this case, the other endpoint of the MPTCP connection
is the attacker (in the sense that it will use the information
revealed through MPTCP for other purposes beyond the MPTCP
operation e.g. the endpoint may decide to sell the location and
tracking information of the MPTCP endpoints to third parties).
Bagnulo, et al. Expires January 9, 2020 [Page 3]
Internet-Draft MPTCP privacy July 2019
2.2. Detailed attack mechanics.
2.2.1. Attacks using MP_CAPABLE and MP_JOIN.
A MPTCP endpoint initiates a MPTCP connection by including the
MP_CAPABLE option in the SYN message. After that, it uses the
MP_JOIN option to add subsequent subflows using other IP address to
the existent connection. The MP_JOIN message include a token that is
used by the MPTCP receiver to identify which of the ongoing MPTCP
connections this particular subflow is being added to. In order for
an attacker to bind the different address together, it must be able
to observe at least two messages carrying two different addresses.
In particular, by observing the initial MP_CAPABLE SYN and a
following MP_JOIN message, the attacker can relate these two IP
addresses. Also, by observing two MP_JOIN messages carrying
different IP addresses but the same toke, the attacker can also
relate the two IP addresses together.
This attack can be executed by any attacker that is capable of
observing the different MP_CAPABLE and MP_JOIN messages. So, for a
partially on-path attacker, the attack will be as effective as the
number of used path the attacker has access to. If it only has
access to one path, the attacker would not gather any information.
Both full on-path attackers and the endpoint would have access to all
the information, so the attack effectiveness is complete.
Both versions of MPTCP, i.e. [RFC6824] [I-D.ietf-mptcp-rfc6824bis]
are equally affected by this attack.
2.2.2. Attacks using ADD_ADDR.
The ADD_ADDR option allows the sender of the message to add an IP
address to the existing connection. From a privacy perspective, the
packet containing the ADD_ADDR information already discloses a
binding between two addresses, the address used a source address of
the packet and the address included in the ADD_ADDR option. This
attack can be performed by any attacker who is able to observe the
message, including partial and full on-path attackers and the
endpoint itself. This attack can be combined with the attack done
using MP_CAPABLE AND MP_JOIN messages described in the previous
section, to retrieve a larger set of addresses. This attack affects
both version [RFC6824] [I-D.ietf-mptcp-rfc6824bis] of MPTCP.
3. Countermeasures.
It is possible to design countermeasures to prevent the described
attacks.
Bagnulo, et al. Expires January 9, 2020 [Page 4]
Internet-Draft MPTCP privacy July 2019
ADD_ADDR attack.
In order to prevent the ADD_ADDR based attack, it would be possible
to encrypt the address carried in the ADD_ADDR message, for example
with the key exchanged in the MP_CAPABLE exchange. By doing this,
only the attackers who have observed the initial MP_CAPABLE message
would be able to decrypt the content of the ADD_ADDR message,
significantly limiting the attack surface.
MP_CAPABLE and MP_JOIN.
In order to prevent the MP_CAPABLE/MP_JOIN attack, it would necessary
to change the token in every MP_JOIN message. the difficulty with
this of course is that the token is used a key to identify which
MPTCP connection this new subflow belongs to. Using different tokens
would be possible as long as the receiver would be able to decrypt it
and find the ongoing connection that this new subflow belongs to.
For instance, the token could be the hash of the concatenation of a
trail of n zeros, the key and the new IP address of the flow. This
token would change with every new subflow, since the IP address would
change (we could also add the source port, to support the case of
multiple subflows with the same source IP address). Upon the
reception of an MP_JOIN message, the receiver would need to try with
all the keys of ongoing connections. It will know it has succeeded,
because the correct one will result in a trail of n zeros. The
problem with this mechanism is that it imposes an additional cost in
terms of computation upon the establishment of a new subflow.
Additional countermeasures could be int he form of a recommendation
about when to establish a new subflow or when to announce new
addresses using ADD_ADDR. Generating awareness that doing so
discloses private information of the endpoint would make
implementations more conservative when advertising IP addresses.
4. MPTCP privacy features.
MPTCP also provides some positive side effects with regard to
privacy. In particular, because the information is spread across
multiple paths, in order to be able to eavesdrop all the content of a
MPTCP connection, the attacker needs to be present in all used paths,
making more challenging for the attacker to fulfill its goal.
5. Security Considerations
Bagnulo, et al. Expires January 9, 2020 [Page 5]
Internet-Draft MPTCP privacy July 2019
6. IANA Considerations
7. Acknowledgements
This work was supported by the Spanish Ministry of Economy and
Competitiveness through the 5G-City project (TEC2016-76795-C6-3-R).
8. Informative References
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work
in progress), June 2019.
[I-D.nordmark-id-loc-privacy]
Nordmark, E., "Privacy issues in ID/locator separation
systems", draft-nordmark-id-loc-privacy-00 (work in
progress), July 2018.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>.
Authors' Addresses
Marcelo Bagnulo
UC3M
Email: marcelo@it.uc3m.es
Amelia Andersdotter
Article 19
Email: amelia@article19.org
Christoph Paasch
Apple
Email: cpaasch@apple.com
Bagnulo, et al. Expires January 9, 2020 [Page 6]
