What?

Enjoy MPTCP capabilities without an MPTCP kernel on the client side.

How?

• Build an MPTCP kernel from sources
• Build a basic image to run with the kernel (debian debootsrap)
• Build and install socks related tools in the vm (dante + redsocks)
• Configure networking for MPTCP (guest + host) to use physical interfaces from the guest

Quick start:

Build vm (First time only)

source mpsocks_lib

# build a debian image base
build_image

# build mptcp kernel
build_kernel

# install dante sock server (https://www.inet.no/dante/)
# install redsock server (https://darkk.net.ru/redsocks/)
# boot vm and dl/compile dante/redsocks inside the vm then shut it down
install_vm_extra

Run a socks server on the vm

# Comma-separated list of interface to use for mptcp subflows
# Could be the same if your system does not have multiple itf
boot_socks wlp1s0,wlp1s0,wlp1s0

# Configure your app to use 10.66.6.2 as a sock proxy
# ^C to finish the socks server and the vm.

# If you don't have an option to add a socks proxy on your application, the vm
# runs a "socksifier", you just need to route traffic through the vm and it will
# be "socksified"
sudo ip route add 130.104.228.140 via 10.66.6.2 # multipath-tcp.org
wget -4 -O- -U curl -q multipath-tcp.org
# Yay, you are MPTCP-capable! You can now rest in peace.

Bonus

Observations

The internet is sometimes funny.

From the vms i tested the following scenarii, traces are present in traces/net_neutrality/

• mptcp off / ttl = 10

  • Commands

    # sysctl net.mptcp.mptcp_enabled=0
    net.mptcp.mptcp_enabled = 0
    # sysctl net.ipv4.ip_default_ttl=10
    net.ipv4.ip_default_ttl = 10
    # wget -O- -U curl -q --bind-address 10.66.7.2 multipath-tcp.org
    Nay, Nay, Nay, your have an old computer that does not speak MPTCP. Shame on you!
    

  • Observations

    Even using a low ttl we are able to join the server.

• mptcp on / ttl = 10

  • Commands

    # sysctl net.mptcp.mptcp_enabled=1
    net.mptcp.mptcp_enabled = 1
    # sysctl net.ipv4.ip_default_ttl=10
    net.ipv4.ip_default_ttl = 10
    # wget -O- -U curl -q --bind-address 10.66.7.2 multipath-tcp.org
    ^C
    

  • Observations

    Using the same low TTL but with mptcp enabled, we can't reach it anymore :-/

• mptcp on / ttl = 64

  • Commands

    # sysctl net.mptcp.mptcp_enabled=1
    net.mptcp.mptcp_enabled = 1
    # sysctl net.ipv4.ip_default_ttl=64
    net.ipv4.ip_default_ttl = 64
    # wget -O- -U curl -q --bind-address 10.66.7.2 multipath-tcp.org
    Yay, you are MPTCP-capable! You can now rest in peace.
    

  • Observations

    Using a high enough TTL we can reach it again using mptcp and the server confirms the usage of MTPCP.

Analysis:

Let's focus on TTL (Thanks Yves Vanaubel for the idea! https://dl.acm.org/doi/abs/10.1145/2504730.2504761 )

$ tshark -Y 'tcp.flags.syn == 1' -T fields -e tcp.flags.syn -e tcp.flags.ack -e ip.ttl -E header=yes -r traces/net_neutrality/nomptcp_ttl10
tcp.flags.syn   tcp.flags.ack   ip.ttl
1       0       9
1       1       124
$ tshark -Y 'tcp.flags.syn == 1' -T fields -e tcp.flags.syn -e tcp.flags.ack -e ip.ttl -E header=yes -r traces/net_neutrality/mptcp_ttl10
tcp.flags.syn   tcp.flags.ack   ip.ttl
1       0       9
1       0       9
1       0       9
1       0       9
1       0       9
$ tshark -Y 'tcp.flags.syn == 1' -T fields -e tcp.flags.syn -e tcp.flags.ack -e ip.ttl -E header=yes -r traces/net_neutrality/mptcp_ttl64
tcp.flags.syn   tcp.flags.ack   ip.ttl
1       0       63
1       1       51

Each line shows SYN SYN+ACK TTL. We can see the TTL for the SYN are 9, 9 and 63. This is the TTL that we set, because I did the trace on my host, -1. What seems to be suspicious is the TTL difference in SYN+ACK whether MPTCP is enabled or not. When MPTCP is not enabled the SYN+ACK has a TTL of 124. But when MPTCP is enabled we have 51. It suggests that the connection is handled differently based on the presence of MPTCP. The connections is probably intercepted before reaching the end server when MPTCP is not present which means a lower TTL is acceptable because the connection will be terminated earlier by an intermediate hop and a new SYN with a new initial TTL will be generated. Since here I'm testing on a 4G connection I would bet on some kind of network optimizer that is not capable of handling MPTCP correctly.

At this point we've guest that MTPCP option in the SYN is probably the only thing that our ISP is lookin at, so it does not matter if the server actually speaks MPTCP or not. Let's try to talk to a server that is not mptcp enabled and see if there is a difference if we use the MPTCP option in the SYN or not :

(traces are available in the trace directory)

root@bhesmans-Precision-7520:~# sysctl net.mptcp.mptcp_enabled=1
net.mptcp.mptcp_enabled = 1
root@bhesmans-Precision-7520:~# wget -O /dev/null -U curl --bind-address 10.66.7.2 http://ipv4.download1.thinkbroadband.com/100MB.zip
--2020-04-16 11:30:02--  http://ipv4.download1.thinkbroadband.com/100MB.zip
Resolving ipv4.download1.thinkbroadband.com (ipv4.download1.thinkbroadband.com)... 80.249.99.148
Connecting to ipv4.download1.thinkbroadband.com (ipv4.download1.thinkbroadband.com)|80.249.99.148|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/zip]
Saving to: '/dev/null'

/dev/null                  100%[=====================================>] 100.00M  4.78MB/s    in 33s

2020-04-16 11:30:36 (3.00 MB/s) - '/dev/null' saved [104857600/104857600]

root@bhesmans-Precision-7520:~# sysctl net.mptcp.mptcp_enabled=0
net.mptcp.mptcp_enabled = 0
root@bhesmans-Precision-7520:~# wget -O /dev/null -U curl --bind-address 10.66.7.2 http://ipv4.download1.thinkbroadband.com/100MB.zip
--2020-04-16 11:31:00--  http://ipv4.download1.thinkbroadband.com/100MB.zip
Resolving ipv4.download1.thinkbroadband.com (ipv4.download1.thinkbroadband.com)... 80.249.99.148
Connecting to ipv4.download1.thinkbroadband.com (ipv4.download1.thinkbroadband.com)|80.249.99.148|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/zip]
Saving to: '/dev/null'

/dev/null                  100%[=====================================>] 100.00M  8.66MB/s    in 12s

2020-04-16 11:31:12 (8.56 MB/s) - '/dev/null' saved [104857600/104857600]

redoing our TTL check:

$ tshark -Y 'tcp.flags.syn == 1' -T fields -e tcp.flags.syn -e tcp.flags.ack -e
ip.ttl -E header=yes -r traces/net_neutrality/mptcp_100MB
tcp.flags.syn   tcp.flags.ack   ip.ttl
1       0       63
1       1       49
$ tshark -Y 'tcp.flags.syn == 1' -T fields -e tcp.flags.syn -e tcp.flags.ack -e
ip.ttl -E header=yes -r traces/net_neutrality/nomptcp_100MB
tcp.flags.syn   tcp.flags.ack   ip.ttl
1       0       63
1       1       124

We also note a difference in speed :/ I did a few tests and it seems that it was consistently slower when MPTCP is present in the SYN.

(This might be a good time to call the net neutrality police.)

There is a possible consequence for all the devices that use MPTCP. Because they seem to be treated differently. In particular some Apple devices are known to use MPTCP for some of their services.