Security Evaluation of Multipath

Total Page:16

File Type:pdf, Size:1020Kb

Security Evaluation of Multipath EXAMENSARBETE INOM TEKNIKOMRÅDET INFORMATIONSTEKNIK OCH HUVUDOMRÅDET INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK, AVANCERAD NIVÅ, 30 HP STOCKHOLM, SVERIGE 2016 Security Evaluation of Multipath TCP Analyzing and fixing Multipath TCP vulnerabilities, contributing to the Linux Kernel implementation of the new version of the protocol FABRIZIO DEMARIA KTH SKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK KTH ROYAL INSTITUTE OF TECHNOLOGY Master of Science in Computer Engineering Master's Degree Thesis Security Evaluation of Multipath TCP Analyzing and fixing Multipath TCP vulnerabilities, contributing to the Linux Kernel implementation of the new version of the protocol Supervisor prof. Peter Sj¨odin Candidate Fabrizio Demaria Company tutors Intel Corporation Henrik Svensson Joakim Nordell Shujuan Chen March 2016 Summary Multipath TCP is a major extension for TCP that aims at unlocking multipath benefits in the network by splitting data transferring across multiple subflows, keeping into consideration funda- mental compatibility goals in order to achieve a seamless deployment of the new protocol on current systems and infrastructures. This thesis work is an extensive security evaluation of Multipath TCP, with an in-depth analysis of its major vulnerabilities: in particular, the ADD ADDR vulnerability affecting Multipath TCP version 0 is addressed in this document. After a preliminary partthat involves testing and studying the vulnerability itself, the core value of this thesis work concerns the development of a series of patches for the Linux Kernel implementation of Multipath TCP aimed at fixing the ADD ADDR vulnerability and marking the first step towards the new version of the protocol, Multipath TCP version 1. The paper contains an experimental evaluation of the various steps of the development phase, including a final performance analysis for the modified implemen- tation of Multipath TCP. In the process, contributions have been produced for the official RFC documentation containing the specifications for Multipath TCP, together with other minor code contributions for related open-source projects, like the famous packet analyzer Wireshark. The entire thesis work required strong interaction with important open-source communities, especially the Linux Kernel one. Multipath TCP is an ongoing project subjected to constant changes regard- ing the protocol and its implementations: this work is just a single step of the overall deployment process, with a main focus on security. iii Summary Multipath TCP ¨aren viktig ¨andringf¨orTCP, d¨arm˚alet¨aratt l˚asaupp f¨ordelarnamed mul- tipath in ett n¨atverk genom att dela upp data¨overf¨oring¨over subfl¨oden,och samtidigt f¨ors¨oka bibeh˚allabak˚atkompabilitet med nuvarande system och infrastruktur. Detta examensarbete ¨aren omfattande s¨akerhetsutv¨arderingav Multipath TCP med en djupg˚aendeanalys av dess fr¨amsta s˚arbarhetheter,speciellt s˚arbarhetenADD ADDR som p˚averkar version 0 av Multipath TCP. Efter en inledande fas best˚aendeav en unders¨okningoch testning av s˚arbarhetens˚abestod arbetet fr¨amst av utvecklingen av en rad fixar f¨ors˚arbarhetenADD ADDR. Dessa fixar gjordes f¨orLinuxk¨arnans implementation av Multipath TCP, i ett f¨orstasteg mot version 1 av protokollet. Denna rapport inneh˚alleren utv¨arderingbaserad p˚aexperiment f¨orvarje steg i utvecklingsfasen, samt en slutgiltig prestandaanalys f¨orden modifierade implementationen av Multipath TCP. I processen producer- ades dels ett f¨orb¨attringsf¨orslagtill det officiella RFC-dokumentet som inneh˚aller specifikationen f¨orMultipath TCP, och ¨aven mindre kod¨andningartill n¨arliggandeopen-source projekt, exem- pelvis packet-analyseraren Wireshark. Examensarbetet inneh¨ollmycket interaktion med viktiga open-source grupper, framf¨oralltgruppen f¨orLinuxk¨arnan. Multipath TCP ¨arett fortl¨opande projekt som ¨arunder st¨andigf¨or¨andring,b˚adekring protokollet och dess implementation. Detta arbete ¨arett steg i den ¨overgripande distributionsprocessen, med fokus p˚as¨akerhet. iv Acknowledgements This thesis work has been carried out at the Intel Corporation office of Lund (Sweden), during a period of six months from September 2015 to February 2016. Before starting this project I spent one year in Stockholm, studying at KTH Royal Institute of Technology as an Erasmus student originally from Torino, Italy. The first persons I would like to thank are my family and friends from Italy, who supported me from far away during my studies in Sweden and during the whole time dedicated to this thesis. I also would like to thank the people that supported me from a closer distance, in particular the Swedish family I have lived with during the six months of the thesis project, that was very friendly to me. I would like to thank all the people from the office, who integrated me very well despite my poor skills in speaking Swedish. I would like to thank my manager Henrik Svensson for giving me the possibility of working on such an valuable and interesting project. Special thanks go to the two Intel engineers that closely followed my work at the Lund office: Joakim Nordell and Shujuan Chen. The work involved other major stakeholders, passionate about the Multipath TCP project, who supported me in the development process: in these regards, I'd like to thank Doru Gucea, Vlad Dogaru and Octavian Purdila. A special thank you goes to Christoph Paasch from Apple California, who directed the whole development process from the other side of the world, helping me in the process and finally accepting my contribution to the official Multipath TCP source code for the Linux Kernel. This work has been supported by both the Politecnico di Torino and Stockholm's KTH Royal Institute of Technology and I want to thank all the professors I encountered during my academic career, especially the ones that followed this very project from the start until the final discussion: Antonio Lioy from Torino and Peter Sj¨odinfrom Stockholm. It is impossible to mention all the enriching people that I met during my months abroad and all the inspiring experiences lived in this last phase of my academic career, but they all define the fundamental context that made this thesis work possible. Thank you. v Contents Summary iii Summary iv 1 Introduction 1 1.1 Motivation........................................1 1.1.1 Benefits of MPTCP...............................3 1.1.2 Multipathing solutions..............................4 1.2 Problem statement....................................5 1.3 Methodology.......................................6 1.3.1 Daily workflow..................................8 1.3.2 Document structure...............................8 2 Multipath TCP 10 2.1 Transmission Control Protocol (TCP)......................... 10 2.2 MPTCP design...................................... 13 2.2.1 Control plane................................... 15 2.2.2 Data plane.................................... 20 2.3 MPTCP deployment................................... 21 2.3.1 Middleboxes compatibility............................ 21 2.3.2 Deployment status................................ 23 3 MPTCP security 25 3.1 Threats analysis..................................... 25 3.1.1 Threats classifications.............................. 26 3.2 Minor threats....................................... 27 3.2.1 DoS attack on MP JOIN............................ 27 3.2.2 Keys eavesdrop.................................. 27 3.2.3 SYN/ACK attack................................ 29 3.3 ADD ADDR attack................................... 29 3.3.1 Concept...................................... 29 3.3.2 Procedure..................................... 30 3.3.3 Requirements................................... 31 vi 4 ADD ADDR attack simulation 33 4.1 Environment setup.................................... 33 4.2 Attack script....................................... 35 4.3 Reproducing the attack................................. 37 4.4 Conclusions........................................ 38 5 Fixing ADD ADDR 39 5.1 The ADD ADDR2 format................................ 39 5.2 Implementing ADD ADDR2............................... 40 5.2.1 MPTCP in Linux................................. 40 5.2.2 The hashing function............................... 41 5.2.3 Version control.................................. 46 5.2.4 Truncated HMAC in ADD ADDR....................... 48 5.2.5 Port advertisement................................ 52 5.2.6 IPv6 considerations............................... 54 5.3 Overall contributions................................... 55 5.4 Experimental evaluation................................. 57 6 Conclusions 66 6.1 Ethical and sustainability aspects............................ 66 6.2 Related work....................................... 67 6.3 Future work........................................ 68 A ADD ADDR attack capture 69 B MPTCP version 1 capture 72 Bibliography 76 vii Chapter 1 Introduction 1.1 Motivation The last few decades have seen the most pronounced technology evolution in history, in many different research areas and consumer markets: from robotics to smartphones, from medicine to the automotive industry, etc. One of the pillars upon which all these advancements have been made possible is the Internet, or more generally the entire set of networking technologies that allow software to communicate. The process towards interconnected devices saw a big leap forward in the early 1960s with the first research into packet switching as an alternative to the old circuit switching. But itis1981 the year of standardization
Recommended publications
  • Microsoft DNS
    1 a. Domain Name Service (DNS) encompassing Microsoft DNS From Wikipedia, the free encyclopedia Jump to: navigation, search Microsoft DNS is the name given to the implementation of domain name system services provided in Microsoft Windows operating systems. Contents [hide] 1 Overview 2 DNS lookup client o 2.1 The effects of running the DNS Client service o 2.2 Differences from other systems 3 Dynamic DNS Update client 4 DNS server o 4.1 Common issues 5 See also 6 References 7 External links [edit] Overview The Domain Name System support in Microsoft Windows NT, and thus its derivatives Windows 2000, Windows XP, and Windows Server 2003, comprises two clients and a server. Every Microsoft Windows machine has a DNS lookup client, to perform ordinary DNS lookups. Some machines have a Dynamic DNS client, to perform Dynamic DNS Update transactions, registering the machines' names and IP addresses. Some machines run a DNS server, to publish DNS data, to service DNS lookup requests from DNS lookup clients, and to service DNS update requests from DNS update clients. The server software is only supplied with the server versions of Windows. [edit] DNS lookup client Applications perform DNS lookups with the aid of a DLL. They call library functions in the DLL, which in turn handle all communications with DNS servers (over UDP or TCP) and return the final results of the lookup back to the applications. 2 Microsoft's DNS client also has optional support for local caching, in the form of a DNS Client service (also known as DNSCACHE). Before they attempt to directly communicate with DNS servers, the library routines first attempt to make a local IPC connection to the DNS Client service on the machine.
    [Show full text]
  • A Measurement-Based Study of Multipath TCP Performance Over Wireless Networks
    A Measurement-based Study of MultiPath TCP Performance over Wireless Networks Yung-Chih Chen Yeon-sup Lim Richard J. Gibbens School of Computer Science School of Computer Science Computer Laboratory University of Massachusetts University of Massachusetts University of Cambridge Amherst, MA USA Amherst, MA USA Cambridge, UK [email protected] [email protected] [email protected] Erich M. Nahum Ramin Khalili Don Towsley IBM Thomas J. Watson T-Labs, Deutsche Telekom School of Computer Science Research Center Berlin, Germany University of Massachusetts Yorktown Heights, NY USA [email protected] Amherst, MA USA [email protected] berlin.de [email protected] ABSTRACT Keywords With the popularity of mobile devices and the pervasive use Multi-Path TCP; MPTCP; Congestion Control; Measure- of cellular technology, there is widespread interest in hybrid ments; Wireless; Cellular Networks; 4G; LTE; 3G; CDMA networks and on how to achieve robustness and good per- formance from them. As most smart phones and mobile de- 1. INTRODUCTION vices are equipped with dual interfaces (WiFi and 3G/4G), a promising approach is through the use of multi-path TCP, Many users with mobile devices can access the Internet which leverages path diversity to improve performance and through both WiFi and cellular networks. Typically, these provide robust data transfers. In this paper we explore the users only utilize one technology at a time: WiFi when it is performance of multi-path TCP in the wild, focusing on sim- available, and cellular otherwise. Research has also focused ple 2-path multi-path TCP scenarios.
    [Show full text]
  • The Effects of Different Congestion Control Algorithms Over Multipath Fast Ethernet Ipv4/Ipv6 Environments
    Proceedings of the 11th International Conference on Applied Informatics Eger, Hungary, January 29–31, 2020, published at http://ceur-ws.org The Effects of Different Congestion Control Algorithms over Multipath Fast Ethernet IPv4/IPv6 Environments Szabolcs Szilágyi, Imre Bordán Faculty of Informatics, University of Debrecen, Hungary [email protected] [email protected] Abstract The TCP has been in use since the seventies and has later become the predominant protocol of the internet for reliable data transfer. Numerous TCP versions has seen the light of day (e.g. TCP Cubic, Highspeed, Illinois, Reno, Scalable, Vegas, Veno, etc.), which in effect differ from each other in the algorithms used for detecting network congestion. On the other hand, the development of multipath communication tech- nologies is one today’s relevant research fields. What better proof of this, than that of the MPTCP (Multipath TCP) being integrated into multiple operating systems shortly after its standardization. The MPTCP proves to be very effective for multipath TCP-based data transfer; however, its main drawback is the lack of support for multipath com- munication over UDP, which can be important when forwarding multimedia traffic. The MPT-GRE software developed at the Faculty of Informatics, University of Debrecen, supports operation over both transfer protocols. In this paper, we examine the effects of different TCP congestion control mechanisms on the MPTCP and the MPT-GRE multipath communication technologies. Keywords: congestion control, multipath communication, MPTCP, MPT- GRE, transport protocols. 1. Introduction In 1974, the TCP was defined in RFC 675 under the Transmission Control Pro- gram name. Later, the Transmission Control Program was split into two modular Copyright © 2020 for this paper by its authors.
    [Show full text]
  • SMAPP : Towards Smart Multipath TCP-Enabled Applications
    SMAPP : Towards Smart Multipath TCP-enabled APPlications B. Hesmans ∗, G. Detal y, S. Barre y, R. Bauduin ∗, O. Bonaventure ∗ ∗ Université catholique de Louvain, Louvain-la-Neuve, Belgium y Tessares, Louvain-la-Neuve, Belgium ∗ [email protected] y [email protected] ABSTRACT applications running on a wide range of devices ranging Multipath TCP was designed and implemented as a from smartphones to datacenters. Despite or maybe due backward compatible replacement for TCP. For this rea- to its popularity, TCP continues to evolve. Multipath son, it exposes the standard socket API to the applica- TCP [7, 19] is one of the most recent TCP extensions. It tions that cannot control the utilisation of the different completely changes one of the basic design assumptions paths. This is a key feature for applications that are un- of the original TCP specification : a TCP connection aware of the multipath nature of the network. On the is always identified by a four-tuple (source and desti- contrary, this is a limitation for applications that could nation IP addresses and ports). All the packets that benefit from specific knowledge to use multiple paths are sent for such a connection always contain this four- in a way that fits their needs. As the specific knowl- tuple. An annoying consequence of this coupling is that edge of an application can not be known in advance, on a multihomed host, e.g. a smartphone with a cellular we propose a Multipath TCP path manager that dele- and a WiFi interface or a simple dual-stack PC having gates the management of the paths to the applications.
    [Show full text]
  • Multipath TCP Upstreaming
    Multipath TCP Upstreaming Mat Martineau (Intel) and Matthieu Baerts (Tessares) Plan ● Multipath TCP Overview ● First Patch Set Upstreaming Roadmap ● Advanced Features Roadmap ● Conclusion and links 2 What is MPTCP? 3 Multipath TCP (MPTCP) ● Exchange data for a single connection over different paths, simultaneously ● RFC-6824 and supported by IETF Multipath TCP (MPTCP) working group Smartphone and WiFi icons by Blurred203 and Antü Plasma under CC-by-sa, others from Tango project, public domain 4 Multipath TCP (MPTCP) ● Exchange data for a single connection over different paths, simultaneously ● RFC-6824 and supported by IETF Multipath TCP (MPTCP) working group ● More bandwidth: Smartphone and WiFi icons by Blurred203 and Antü Plasma under CC-by-sa, others from Tango project, public domain 5 Multipath TCP (MPTCP) ● Exchange data for a single connection over different paths, simultaneously ● RFC-6824 and supported by IETF Multipath TCP (MPTCP) working group ● More mobility (walk-out): Smartphone and WiFi icons by Blurred203 and Antü Plasma under CC-by-sa, others from Tango project, public domain 6 Multipath TCP (MPTCP) ● Exchange data for a single connection over different paths, simultaneously ● RFC-6824 and supported by IETF Multipath TCP (MPTCP) working group ● More mobility (walk-out): Smartphone and WiFi icons by Blurred203 and Antü Plasma under CC-by-sa, others from Tango project, public domain 7 Multipath TCP (MPTCP) ● Exchange data for a single connection over different paths, simultaneously ● RFC-6824 and supported by IETF Multipath TCP
    [Show full text]
  • Network Working Group T. Pauly Internet-Draft Apple Inc
    Network Working Group T. Pauly Internet-Draft Apple Inc. Intended status: Informational C. Perkins Expires: September 6, 2018 University of Glasgow K. Rose Akamai Technologies, Inc. C. Wood Apple Inc. March 05, 2018 A Survey of Transport Security Protocols draft-pauly-taps-transport-security-02 Abstract This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. This survey is not limited to protocols developed within the scope or context of the IETF. 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 September 6, 2018.
    [Show full text]
  • "Measuring and Extending Multipath TCP"
    "Measuring and extending multipath TCP" Tran, Viet Hoang ABSTRACT TCP has been one of the most important Internet protocols since the early days of this network. The initial version of TCP assumed that (1) each device has a single interface, and (2) its network address is permanent. Today's Internet attached devices have multiple interfaces with dynamic addresses. These deployments do not match anymore the design principles of TCP. By decoupling the transport layer from the underneath IP layer, Multipath TCP brings several key benefits in a variety of use cases. However, this major TCP extension is also significantly more complex than the legacy TCP. Despite growing interests in Multipath TCP, there are still many unknowns about its behaviours and performance in the real world. Moreover, most Multipath TCP implementations are based on existing TCP stacks which are part of operating systems kernels. Therefore, it is challenging to build Multipath TCP stacks that adapt to different network scenarios and user requirements. The purpose of this thesis i... CITE THIS VERSION Tran, Viet Hoang. Measuring and extending multipath TCP. Prom. : Bonaventure, Olivier http:// hdl.handle.net/2078.1/225610 Le dépôt institutionnel DIAL est destiné au dépôt DIAL is an institutional repository for the deposit et à la diffusion de documents scientifiques and dissemination of scientific documents from émanents des membres de l'UCLouvain. Toute UCLouvain members. Usage of this document utilisation de ce document à des fin lucratives for profit or commercial purposes is stricly ou commerciales est strictement interdite. prohibited. User agrees to respect copyright L'utilisateur s'engage à respecter les droits about this document, mainly text integrity and d'auteur lié à ce document, principalement le source mention.
    [Show full text]
  • Multipath TCP: from Theory to Practice
    MultiPath TCP: From Theory to Practice Sébastien Barré, Christoph Paasch, and Olivier Bonaventure ⋆ ICTEAM, Université catholique de Louvain B-1348 Louvain-la-Neuve, Belgium {firstname.lastname}@uclouvain.be Abstract. The IETF is developing a new transport layer solution, Mul- tiPath TCP (MPTCP), which allows to efficiently exploit several Internet paths between a pair of hosts, while presenting a single TCP connection to the application layer. From an implementation viewpoint, multiplex- ing flows at the transport layer raises several challenges. We first explain how this major TCP extension affects the Linux TCP/IP stack when considering the establishment of TCP connections and the transmission and reception of data over multiple paths. Then, based on our imple- mentation of MultiPath TCP in the Linux kernel, we explain how such an implementation can be optimized to achieve high performance and report measurements showing the performance of receive buffer tuning and coupled congestion control. Keywords: TCP, multipath, implementation, measurements 1 Introduction The Internet is changing. When TCP/IP was designed, hosts had a single in- terface and only routers were equipped with several physical interfaces. Today, most hosts have more than one interface and the proliferation of smart-phones equipped with both 3G and WiFi will bring a growing number of multihomed hosts on the Internet. End-users often expect that using multihomed hosts will increase both redundancy and performance. Unfortunately, in practice this is not always the case as more than 95% of the total Internet traffic is still driven by TCP and TCP binds each connection to a single interface. This implies that TCP by itself is not capable of efficiently and transparently using the interfaces available on a multihomed host.
    [Show full text]
  • Automatic Local Area Network Encryption
    Vula: automatic local area network encryption Abstract—This paper introduces Vula, a protocol and suite of will benefit from the use of Vula 2. With Vula’s ability to be Free Software tools for automatically protecting network traffic gradually deployed, every host has a notion of cryptographic between hosts in the same Local Area Network (LAN). Without identity, and we think that with this improvement it will be any configuration, or any user awareness, Vula automatically clearer how to solve the problem of Internet-wide end-to-end blinds passive adversaries. With user awareness and a small encryption without resorting to sending unecrypted IP packets, amount of interaction, it also protects connections using .local encrypted but unauthenticated IP packets, or any of the various hostnames, or any other user supplied domain, against active adversaries. The protocol additionally provides protection against Single Points of Failure (SPOFs) as described in SectionII. a passive adversary who is recording traffic today and who may have a quantum computer tomorrow. Vula’s protections A. Motivation persist with network topology changes which occur naturally over time, allowing users to maintain cryptographic assurances Public and private personal networks are commonly de- while roaming between different LANs. The software operates ployed using wired Ethernet (802.3) or wireless LAN (802.11) without requiring centralized administration, specialized network standards without comprehensive protection against surveil- equipment, or significant performance penalties. lance adversaries. Ethernet networks are commonly deployed in consumer and commercial contexts without encryption of any kind. Authentication [2] of end-user’s computers may be combined with a protocol such as MACsec [48] or WPA for I.
    [Show full text]
  • Building Secure Channels
    Building Secure Channels Kenny Paterson Information Security Group Overview • Why do we need secure channels? • What properties should they have? • Literature on secure channels • Extended Example: TLS 2 Why do we need secure channels? • Secure communications is the most common real- world application of cryptography today. • No, it’s not MPC for sugar beet auctions! • Secure channels are extremely widely-deployed in practice: • SSL/TLS, DTLS, IPsec, SSH, OpenVPN,… • WEP/WPA/WPA2 • GSM/UMTS/LTE • Cryptocat, OTR, SilentCircle,… • (QUIC, MinimalT, TCPcrypt) • Mostly, but not exclusively in the 2-party case. 3 What security properties should they have? • Confidentiality – privacy for data • Integrity – detection of data modification • Authenticity – assurance concerning the source of data • All in the face of active attackers who can modify, delete, inject, re-order network messages. • These three properties are relatively easy to achieve using Authenticated Encryption (AE) or AEAD. • Recall AE notion from Monday. • AEAD: some data encrypted and integrity protected, other data (the header) only integrity protected. • But AE/AEAD were not available at the time many of today’s systems were designed. • Note that authenticated key establishment (AKE) is out-of-scope for this talk. • We assume the keys are already in place. • A major assumption, but a different summer school! 4 What security properties should they have? Less obvious security properties: • Anti-replay – detection that messages have been repeated. • Drop-detection – detection that messages have been deleted by the adversary or dropped by the network. • Particularly acute for the last message on a channel. • Cookie cutter attack. • Prevention of re-0rdering attacks. • Preserving the relative order of messages in each direction.
    [Show full text]
  • Introduction
    Securing the Mobile Ecoomy – www.neohapsis.com MULTIPATH TCP, PWNIN G TODAY’S NETWORKS W ITH TOMORROW’S PROTOCOLS . Catherine Pearce – [email protected], twitter: @secvalve ABSTRACT: MultiPath TCP (MPTCP) is an extension to TCP that enables sessions to use multiple network endpoints and multiple network paths at the same time, and to change addresses in the middle of a connection. MPTCP works transparently over most existing network infrastructure, yet very few security and network management tools can correctly interpret MPTCP streams. With MPTCP network security is changed: how do you secure traffic when you can't see it all and when the endpoint addresses change in the middle of a connection? This paper briefly discusses how MPTCP breaks assumptions about how TCP works, and how this can be used to evade security controls. We will also discuss tools and strategies for understanding and mitigating the risk of MPTCP-capable devices on a network. INTRODUCTION Ubiquitous in modern networking, with much of the world's infrastructure depending upon it, but its single path nature is a significant shortcoming in many modern uses. Where there is a need to combine the bandwidth of multiple network connections, or to roam across different network locations while maintaining a connection, TCP falls short. This has motivated both research and proposed solutions. While many proposed solutions have been revolutionary (comprising complete replacements, notably Stream Control Transmission Control Protocol (SCTP)), recent proposals have been more evolutionary extensions of TCP itself. Multipath TCP (MPTCP) is one such expansion. It adds the ability to split TCP flows over multiple network endpoints, and to change network endpoints seamlessly without dropping the connection.
    [Show full text]
  • Exploring Alternative Routes Using Multipath TCP
    EXPLORING ALTERNATIVE ROUTES USING MULTIPATH TCP by STEPHEN BRENNAN Submitted in partial fulfillment of the requirements for the degree of Master of Science Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY August, 2017 CASE WESTERN RESERVE UNIVERSITY SCHOOL OF GRADUATE STUDIES We hereby approve the thesis of Stephen Brennan candidate for the degree of Master of Science*. Committee Chair Michael Rabinovich Committee Member Vincenzo Liberatore Committee Member Mark Allman Date of Defense June 5, 2017 *We also certify that written approval has been obtained for any proprietary material contained therein. Contents List of Tables iii List of Figures iii Abstract v 1 Introduction 1 1.1 Internet Routing Inefficiencies . .1 1.2 Access Link Underutilization . .2 1.3 Concept . .3 1.4 Contributions . .4 2 Background 6 2.1 Multipath TCP . .6 2.2 Mininet . 10 3 Related Work 13 3.1 Link Layer . 13 3.2 Network Layer . 14 3.3 Transport Layer . 19 3.4 Application Layer . 21 i CONTENTS CONTENTS 4 Implementation 24 4.1 Detour Daemon . 26 4.2 Path Manager . 33 4.3 Client Daemon . 37 4.4 Security Considerations . 38 5 Evaluation 40 5.1 Mininet Experiments . 41 5.2 AWS Experiment . 51 6 Future Work 53 6.1 Detour Collective . 53 6.2 Detour Traffic Attribution . 54 6.3 Dynamic Source Routing . 55 6.4 Data Scheduling . 56 6.5 0-RTT NAT Establishment . 56 7 Conclusion 58 Data 60 ii List of Tables 1 Mininet experiment throughput . 60 2 Bytes transmitted across subflows . 61 iii List of Figures 1.1 Conceptual overview of the mechanism .
    [Show full text]