Minimalt: Minimal-Latency Networking Through Better Security W
Total Page：16
File Type：pdf, Size：1020Kb
MinimaLT: Minimal-latency Networking Through Better Security W. Michael Petullo Xu Zhang Jon A. Solworth United States Military Academy University of Illinois at Chicago University of Illinois at Chicago West Point, New York USA Chicago, Illinois USA Chicago, Illinois USA mike@flyn.org [email protected] [email protected] Daniel J. Bernstein Tanja Lange University of Illinois at Chicago TU Eindhoven TU Eindhoven Chicago, Illinois USA Eindhoven, Netherlands Eindhoven, Netherlands [email protected] [email protected] ABSTRACT users [55]. For example, Google found that a latency in- crease of 500ms resulted in a 25% dropoff in page searches, Minimal Latency Tunneling ( ) is a new net- MinimaLT and studies have shown that user experience degrades at la- work protocol that provides ubiquitous encryption for max- tencies as low as 100ms [12]. In response, there have been imal confidentiality, including protecting packet headers. several efforts to reduce latency for both TCP and encrypted provides server and user authentication, exten- MinimaLT networking [14, 41, 37, 10, 48, 56]. sive Denial-of-Service protections, privacy-preserving IP mo- bility, and fast key erasure. We describe the protocol, We describe here MinimaLT, a secure network protocol demonstrate its performance relative to TLS and unen- which delivers protected data on the first packet of a typical crypted TCP/IP, and analyze its protections, including its client-server connection. MinimaLT provides cryptographic resilience against DoS attacks. By exploiting the proper- authentication of servers and users; encryption of communi- ties of its cryptographic protections, MinimaLT is able to cation; simplicity of protocol, implementation, and configu- eliminate three-way handshakes and thus create connections ration; clean IP-address mobility; and DoS protections. faster than unencrypted TCP/IP. MinimaLT’s design intentionally crosses network layers Categories and Subject Descriptors for two reasons. First, security problems often occur in the seams between layers. For example, Transport Layer Secu- C.2.2 [Network Protocols]: Protocol architecture rity (TLS) is vulnerable to attacks on TCP/IP headers due to its layering; connection-reset (RST) and sequence-number Keywords attacks interrupt TLS connections in a way that is difficult Network security; protocol; encryption; authentication to correct or even detect [18, 3, 59]. Second, multi-layer design enables MinimaLT to improve performance. 1 Introduction Particularly challenging has been to provide key erasure Our goal is to protect all networking against eavesdropping, (“forward secrecy”) at low latency. Key erasure means modification, and, to the extent possible, Denial of Ser- that even an attacker who captures network traffic and later vice (DoS). To achieve this goal, networking must protect obtains all long-term private keys cannot decrypt past pack- privacy, provide strong (i.e., cryptographic) authentication ets or identify the parties involved in communication. Tra- of both servers and users, be easy to configure, and perform ditionally, key erasure is implemented with Diffie-Hellman well. These needs are not met by existing protocols. key exchange (DH) in a way that imposes a round trip be- Hardware and software improvements have eliminated his- fore sending any sensitive data. MinimaLT eliminates this torical cryptographic performance bottlenecks. Now, strong round trip, instead obtaining the server’s ephemeral key dur- symmetric encryption can be performed on a single CPU ing a directory service lookup (§3.4 and §5.2). Further- core at Gb/s rates [40], even on resource-constrained mobile more, MinimaLT inverts the normal mandatory start-of- devices [8]. Public-key cryptography, once so agonizingly connection handshake, instead ensuring connection liveness slow that systems would try to simulate it with symmetric using a server-initiated handshake only when a host’s re- key cryptography [36], is now performed at tens of thou- sources become low (§5.7). Eliminating these round trips sands of operations per second on commodity CPUs. Due makes MinimaLT faster than unencrypted TCP/IP at es- to these advances, along with the threats found on the In- tablishing connections. ternet, researchers are increasingly calling for the protection A second challenge is to make connections portable of all network traffic [10, 51, 20, 13]. across IP addresses to better support mobile computing. However, one performance metric is a fundamental MinimaLT allows the user to start a connection from home, limitation—network latency [28]. Latency is critical for travel to work, and continue to use that connection. This Public domain. This work was supported by the US National Science Foundation avoids application recovery overhead and lost work for op- under grants CNS-0964575 and 1018836, the European Commission under Contract erations which would otherwise be interrupted by a move. ICT-2007-216676 ECRYPT II and INFSO-ICT-284833 PUFFIN, and by the Nether- MinimaLT IP mobility does not require intermediary hosts lands Organisation for Scientific Research (NWO) under grant 639.073.005. Perma- or redirects, enabling it to integrate cleanly into protocol nent ID of this document: 4613afc97aa0c7b8c45bc08f46c2e120. Date: October 31, processing (§5.6). To provide better privacy, MinimaLT 2013. CCS’13, November 4–8, 2013, Berlin, Germany. blinds third parties to IP-address portability, preventing ACM 978-1-4503-2477-9/13/11. http://dx.doi.org/10.1145/2508859.2516737. them from linking a connection across different IP addresses. A third challenge is DoS prevention. A single host cannot connection0 (control) thwart an attacker with overwhelming resources [30], but Q1 connection1 P1 MinimaLT protects against attackers with fewer resources. In particular, MinimaLT dynamically increases the ratio of Q2 connection2 P2 client (i.e., attacker) to server resources needed for a suc- Q3 connection3 P3 cessful attack. MinimaLT employs a variety of defenses to Client host C tunnel C → S Server host S protect against DoS attacks (§7.6). Qn / Pn : Client/server program n; : MinimaLT system software A fourth challenge is authentication and authorization. Experience indicates that network-based password authen- Figure 1: A tunnel encapsulates all of the connections be- tication is fraught with security problems [29, 54, 42, 11], tween a given pair of hosts; connections are user-process-to- and thus cryptographic authentication is needed. Our service and the server cryptographically authenticates each authentication framework supports both identified and client user (the control connection does not involve applica- non-identified (pseudonym) users (§3.1). We designed tion programs) MinimaLT to integrate into systems with strong authoriza- we attempt to drive up his costs by making his attack at tion controls. least as expensive as the cost to defend against it. Here To meet these challenges, we have produced a clean-slate the ability to spoof the source IP address of a packet and design, starting from User Datagram Protocol (UDP), by capture a reply should not allow much easier attacks. concurrently considering multiple network layers. We found We are also want to make it difficult for an attacker to an unexpected synergy between speed and security. The rea- link a user’s connection across different IP addresses. For son that the Internet uses higher-latency protocols is that, example, if a user suspends his laptop at home and wakes historically, low-latency protocols such as T/TCP have al- it up at a wireless café, a network eavesdropper should not lowed such severe attacks [14] as to make them undeployable. be able to infer from the protocol that these belong to the It turns out that providing strong authentication elsewhere same user. We do not address the linking of flows associated in the protocol stops all such attacks without adding latency. with the same IP address, as this type of protection is better MinimaLT was designed for, and implemented in, Ethos, afforded by techniques such as onion routing [16]. an experimental Operating System (OS) [52]. Ethos’s pri- mary goal is to make it easier to write robust applications, 3 MinimaLT objects i.e., applications able to withstand attacks. MinimaLT This section introduces the central objects that interact in serves as Ethos’ native network protocol; it is part of Ethos’ the MinimaLT architecture. MinimaLT uses public keys authentication suite which includes a Public Key Infrastruc- to identify servers and users; creates encrypted tunnels be- ture (PKI) named sayI [53] and a networking API [47, 46]. tween hosts, through which authenticated user-to-service We have also ported MinimaLT to Linux. connections are multiplexed; and publishes ephemeral server MinimaLT provides the features of TCP/IP (reliability, keys in a directory service to reduce latency by eliminat- flow control, and congestion control), and adds encryption, ing setup handshakes. To provide a complete picture for a authentication, clean IP mobility, and DoS protections, all MinimaLT deployment, this section concludes by describing while providing key erasure and reducing latency. how to integrate MinimaLT’s directory service with DNS §2 summarizes the threats for which MinimaLT pro- and the X.509 PKI (used by web browsers). This is not part vides countermeasures. The next four sections explain how of the protocol; it is merely one possible way to combine a MinimaLT works and how fast it is: §3 describes the central directory service with the existing Internet