dissertation-4-dissertation/References/references.bib

@inproceedings{donenfeld_wireguard_2017,
	address = {San Diego, CA},
	title = {{WireGuard}: {Next} {Generation} {Kernel} {Network} {Tunnel}},
	isbn = {978-1-891562-46-4},
	shorttitle = {{WireGuard}},
	url = {https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/wireguard-next-generation-kernel-network-tunnel/},
	doi = {10.14722/ndss.2017.23160},
	abstract = {WireGuard is a secure network tunnel, operating at layer 3, implemented as a kernel virtual network interface for Linux, which aims to replace both IPsec for most use cases, as well as popular user space and/or TLS-based solutions like OpenVPN, while being more secure, more performant, and easier to use. The virtual tunnel interface is based on a proposed fundamental principle of secure tunnels: an association between a peer public key and a tunnel source IP address. It uses a single round trip key exchange, based on NoiseIK, and handles all session creation transparently to the user using a novel timer state machine mechanism. Short pre-shared static keys—Curve25519 points—are used for mutual authentication in the style of OpenSSH. The protocol provides strong perfect forward secrecy in addition to a high degree of identity hiding. Transport speed is accomplished using ChaCha20Poly1305 authenticated-encryption for encapsulation of packets in UDP. An improved take on IP-binding cookies is used for mitigating denial of service attacks, improving greatly on IKEv2 and DTLS’s cookie mechanisms to add encryption and authentication. The overall design allows for allocating no resources in response to received packets, and from a systems perspective, there are multiple interesting Linux implementation techniques for queues and parallelism. Finally, WireGuard can be simply implemented for Linux in less than 4,000 lines of code, making it easily audited and verified.},
	language = {en},
	urldate = {2020-11-19},
	booktitle = {Proceedings 2017 {Network} and {Distributed} {System} {Security} {Symposium}},
	publisher = {Internet Society},
	author = {Donenfeld, Jason A.},
	year = {2017},
	file = {Donenfeld - 2017 - WireGuard Next Generation Kernel Network Tunnel.pdf:/home/jake/Zotero/storage/6MEQYC9J/Donenfeld - 2017 - WireGuard Next Generation Kernel Network Tunnel.pdf:application/pdf},
}

@misc{noauthor_2018_2018,
	title = {2018 {United} {Kingdom} {Speedtest} {Market} {Snapshot}},
	shorttitle = {Ookla {Speedtest} {Market} {Snapshot}},
	url = {http://www.speedtest.net/reports/united-kingdom/},
	abstract = {Based on millions of Speedtest results, the 2018 United Kingdom Market Snapshot is the comprehensive guide to fixed broadband and mobile internet speeds in the UK.},
	urldate = {2020-11-19},
	journal = {Ookla},
	year = {2018},
	file = {Snapshot:/home/jake/Zotero/storage/49UCNVCV/united-kingdom.html:text/html},
}

@incollection{hutchison_blake2_2013,
	address = {Berlin, Heidelberg},
	title = {{BLAKE2}: {Simpler}, {Smaller}, {Fast} as {MD5}},
	volume = {7954},
	isbn = {978-3-642-38979-5 978-3-642-38980-1},
	shorttitle = {{BLAKE2}},
	url = {http://link.springer.com/10.1007/978-3-642-38980-1_8},
	abstract = {We present the hash function BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed in software. Target applications include cloud storage, intrusion detection, or version control systems. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms, and BLAKE2s for smaller architectures. On 64bit platforms, BLAKE2 is often faster than MD5, yet provides security similar to that of SHA-3: up to 256-bit collision resistance, immunity to length extension, indifferentiability from a random oracle, etc. We specify parallel versions BLAKE2bp and BLAKE2sp that are up to 4 and 8 times faster, by taking advantage of SIMD and/or multiple cores. BLAKE2 reduces the RAM requirements of BLAKE down to 168 bytes, making it smaller than any of the five SHA-3 finalists, and 32\% smaller than BLAKE. Finally, BLAKE2 provides a comprehensive support for tree-hashing as well as keyed hashing (be it in sequential or tree mode).},
	language = {en},
	urldate = {2020-11-28},
	booktitle = {Applied {Cryptography} and {Network} {Security}},
	publisher = {Springer Berlin Heidelberg},
	author = {Aumasson, Jean-Philippe and Neves, Samuel and Wilcox-O’Hearn, Zooko and Winnerlein, Christian},
	editor = {Hutchison, David and Kanade, Takeo and Kittler, Josef and Kleinberg, Jon M. and Mattern, Friedemann and Mitchell, John C. and Naor, Moni and Nierstrasz, Oscar and Pandu Rangan, C. and Steffen, Bernhard and Sudan, Madhu and Terzopoulos, Demetri and Tygar, Doug and Vardi, Moshe Y. and Weikum, Gerhard and Jacobson, Michael and Locasto, Michael and Mohassel, Payman and Safavi-Naini, Reihaneh},
	year = {2013},
	doi = {10.1007/978-3-642-38980-1_8},
	note = {Series Title: Lecture Notes in Computer Science},
	pages = {119--135},
	file = {Aumasson et al. - 2013 - BLAKE2 Simpler, Smaller, Fast as MD5.pdf:/home/jake/Zotero/storage/ZG25MG4B/Aumasson et al. - 2013 - BLAKE2 Simpler, Smaller, Fast as MD5.pdf:application/pdf},
}

@article{peng_multipath_2016,
	title = {Multipath {TCP}: {Analysis}, {Design}, and {Implementation}},
	volume = {24},
	issn = {1558-2566},
	shorttitle = {Multipath {TCP}},
	doi = {10.1109/TNET.2014.2379698},
	abstract = {Multipath TCP (MP-TCP) has the potential to greatly improve application performance by using multiple paths transparently. We propose a fluid model for a large class of MP-TCP algorithms and identify design criteria that guarantee the existence, uniqueness, and stability of system equilibrium. We clarify how algorithm parameters impact TCP-friendliness, responsiveness, and window oscillation and demonstrate an inevitable tradeoff among these properties. We discuss the implications of these properties on the behavior of existing algorithms and motivate our algorithm Balia (balanced linked adaptation), which generalizes existing algorithms and strikes a good balance among TCP-friendliness, responsiveness, and window oscillation. We have implemented Balia in the Linux kernel. We use our prototype to compare the new algorithm to existing MP-TCP algorithms.},
	number = {1},
	journal = {IEEE/ACM Transactions on Networking},
	author = {Peng, Q. and Walid, A. and Hwang, J. and Low, S. H.},
	month = feb,
	year = {2016},
	note = {Conference Name: IEEE/ACM Transactions on Networking},
	keywords = {Aggregates, Algorithm design and analysis, Asymptotic stability, balanced linked adaptation, Balia algorithm, Computer networks, convergence, Heuristic algorithms, Linux kernel, MP-TCP algorithms, multipath TCP, nonlinear dynamical systems, Oscillators, Stability analysis, TCPIP, transport protocols, Vectors, window oscillation},
	pages = {596--609},
	file = {IEEE Xplore Abstract Record:/home/jake/Zotero/storage/S2L269MS/7000573.html:text/html;IEEE Xplore Full Text PDF:/home/jake/Zotero/storage/9QTMKA3G/Peng et al. - 2016 - Multipath TCP Analysis, Design, and Implementatio.pdf:application/pdf},
}

@article{wischik_design_2011,
	title = {Design, implementation and evaluation of congestion control for multipath {TCP}},
	abstract = {Multipath TCP, as proposed by the IETF working group mptcp, allows a single data stream to be split across multiple paths. This has obvious benefits for reliability, and it can also lead to more efficient use of networked resources. We describe the design of a multipath congestion control algorithm, we implement it in Linux, and we evaluate it for multihomed servers, data centers and mobile clients. We show that some ‘obvious’ solutions for multipath congestion control can be harmful, but that our algorithm improves throughput and fairness compared to single-path TCP. Our algorithm is a drop-in replacement for TCP, and we believe it is safe to deploy.},
	language = {en},
	author = {Wischik, Damon and Raiciu, Costin and Greenhalgh, Adam and Handley, Mark},
	year = {2011},
	pages = {14},
	file = {Wischik et al. - Design, implementation and evaluation of congestio.pdf:/home/jake/Zotero/storage/5EIJG455/Wischik et al. - Design, implementation and evaluation of congestio.pdf:application/pdf},
}

@misc{ofcom_performance_2020,
	title = {The performance of fixed-line broadband delivered to {UK} residential customers},
	shorttitle = {{UK} {Home} {Broadband} {Performance}},
	url = {https://www.ofcom.org.uk/research-and-data/telecoms-research/broadband-research/home-broadband-performance-2019},
	abstract = {Our annual home broadband performance report compares how different broadband packages perform, using data from monitors installed on people's broadband routers.},
	language = {en},
	urldate = {2020-11-21},
	journal = {Ofcom},
	author = {Ofcom},
	month = may,
	year = {2020},
	file = {2020 - UK home broadband performance, measurement period .pdf:/home/jake/Zotero/storage/HPR3TALB/2020 - UK home broadband performance, measurement period .pdf:application/pdf;Snapshot:/home/jake/Zotero/storage/437YQTVF/home-broadband-performance-2019.html:text/html},
}

@inproceedings{hacker_effects_2002,
	title = {The {Effects} of {Systemic} {Packet} {Loss} on {Aggregate} {TCP} {Flows}},
	doi = {10.1109/SC.2002.10029},
	abstract = {The use of parallel TCP connections to increase throughput for bulk transfers is common practice within the high performance computing community. However, the effectiveness, fairness, and efficiency of data transfers across parallel connections is unclear. This paper considers the impact of systemic non-congestion related packet loss on the effectiveness, fairness, and efficiency of parallel TCP transmissions. The results indicate that parallel connections are effective at increasing aggregate throughput, and increase the overall efficiency of the network bottleneck. In the presence of congestion related losses, parallel flows steal bandwidth from other single stream flows. A simple modification is presented that reduces the fairness problems when congestion is present, but retains effectiveness and efficiency.},
	booktitle = {{SC} '02: {Proceedings} of the 2002 {ACM}/{IEEE} {Conference} on {Supercomputing}},
	author = {Hacker, T. J. and Noble, B. D. and Athey, B. D.},
	month = nov,
	year = {2002},
	note = {ISSN: 1063-9535},
	keywords = {Aggregates, Bandwidth, Biology computing, Computer hacking, Concurrent computing, High performance computing, Internet, Loss measurement, Robustness, Throughput},
	pages = {7--7},
	file = {IEEE Xplore Abstract Record:/home/jake/Zotero/storage/F9XVJNZS/1592843.html:text/html;IEEE Xplore Full Text PDF:/home/jake/Zotero/storage/GGX3FAK6/Hacker et al. - 2002 - The Effects of Systemic Packet Loss on Aggregate T.pdf:application/pdf},
}

@article{sharma_road_2020,
	title = {The {Road} {Not} {Taken}: {Re}-thinking the {Feasibility} of {Voice} {Calling} {Over} {Tor}},
	volume = {2020},
	shorttitle = {The {Road} {Not} {Taken}},
	url = {https://content.sciendo.com/view/journals/popets/2020/4/article-p69.xml},
	doi = {10.2478/popets-2020-0063},
	abstract = {{\textless}section class="abstract"{\textgreater}{\textless}h2 class="abstractTitle text-title my-1" id="d516e2"{\textgreater}Abstract{\textless}/h2{\textgreater}{\textless}p{\textgreater}Anonymous VoIP calls over the Internet holds great significance for privacy-conscious users, whistle-blowers and political activists alike. Prior research deems popular anonymization systems like Tor unsuitable for providing the requisite performance guarantees that real-time applications like VoIP need. Their claims are backed by studies that may no longer be valid due to constant advancements in Tor. Moreover, we believe that these studies lacked the requisite diversity and comprehensiveness. Thus, conclusions from these studies, led them to propose novel and tailored solutions. However, no such system is available for immediate use. Additionally, operating such new systems would incur significant costs for recruiting users and volunteered relays, to provide the necessary anonymity guarantees.{\textless}/p{\textgreater}{\textless}p{\textgreater}It thus becomes an imperative that the exact performance of VoIP over Tor be quantified and analyzed, so that the potential performance bottlenecks can be amended. We thus conducted an extensive empirical study across various in-lab and real world scenarios to shed light on VoIP performance over Tor. In over half a million calls spanning 12 months, across seven countries and covering about 6650 Tor relays, we observed that {\textless}em{\textgreater}Tor supports good voice quality (Perceptual Evaluation of Speech Quality (PESQ) \>{\textless}/em{\textgreater}3 {\textless}em{\textgreater}and one-way delay \<{\textless}/em{\textgreater}400 {\textless}em{\textgreater}ms) in more than 85\% of cases{\textless}/em{\textgreater}. Further analysis indicates that in general for most Tor relays, the contentions due to cross-traffic were low enough to support VoIP calls, that are anyways transmitted at low rates (\<120 Kbps). Our findings are supported by concordant measurements using iperf that show more than the adequate available bandwidth for most cases. Hence, unlike prior efforts, our research reveals that Tor is suitable for supporting anonymous VoIP calls.{\textless}/p{\textgreater}{\textless}/section{\textgreater}},
	language = {en},
	number = {4},
	urldate = {2020-12-03},
	journal = {Proceedings on Privacy Enhancing Technologies},
	author = {Sharma, Piyush Kumar and Chaudhary, Shashwat and Hassija, Nikhil and Maity, Mukulika and Chakravarty, Sambuddho},
	month = oct,
	year = {2020},
	note = {Publisher: Sciendo
Section: Proceedings on Privacy Enhancing Technologies},
	pages = {69--88},
	file = {Full Text PDF:/home/jake/Zotero/storage/H59PHVNZ/Sharma et al. - 2020 - The Road Not Taken Re-thinking the Feasibility of.pdf:application/pdf;Snapshot:/home/jake/Zotero/storage/IMQSR22L/journals\$002fpopets\$002f2020\$002f4\$002farticle-p69.html:text/html},
}

@inproceedings{wischik_control_2009,
	address = {Berlin, Heidelberg},
	series = {Lecture {Notes} in {Computer} {Science}},
	title = {Control of {Multipath} {TCP} and {Optimization} of {Multipath} {Routing} in the {Internet}},
	isbn = {978-3-642-10406-0},
	doi = {10.1007/978-3-642-10406-0_14},
	abstract = {There are moves in the Internet architecture community to add multipath capabilities to TCP, so that end-systems will be able to shift their traffic away from congested parts of the network. We study two problems relating to the design of multipath TCP. (i) We investigate stochastic packet-level behaviour of some proposed multipath congestion control algorithms, and find that they do not behave how we might expect from fluid modeling: they tend to flap randomly between their available paths. We explain why, and propose a congestion control algorithm that does not flap. (ii) We consider how the path choice offered by the network affects the ability of end-systems to shift their traffic between a pool of resources. We define a ‘resource poolability’ metric, which measures for each resource how easy it is for traffic to be shifted away from that resource e.g. in the event of a traffic surge or link failure.},
	language = {en},
	booktitle = {Network {Control} and {Optimization}},
	publisher = {Springer},
	author = {Wischik, Damon and Handley, Mark and Raiciu, Costin},
	editor = {Núñez-Queija, Rudesindo and Resing, Jacques},
	year = {2009},
	keywords = {congestion control, fluid model, load balancing, multipath TCP, resource pooling},
	pages = {204--218},
	file = {Springer Full Text PDF:/home/jake/Zotero/storage/3Y23DZS8/Wischik et al. - 2009 - Control of Multipath TCP and Optimization of Multi.pdf:application/pdf},
}

@misc{handley_tcp_nodate,
	title = {{TCP} {Extensions} for {Multipath} {Operation} with {Multiple} {Addresses}},
	url = {https://tools.ietf.org/html/rfc8684},
	language = {en},
	urldate = {2020-12-22},
	author = {Handley, Mark and Bonaventure, Olivier and Raiciu, Costin and Ford, Alan and Paasch, Christoph},
	file = {Snapshot:/home/jake/Zotero/storage/ATRML74P/rfc8684.html:text/html},
}