Search for: All records

Cybersecurity companies routinely rely on telemetry from inside customer networks to collect intelligence about new online threats. However, the mechanism by which such intelligence is gathered can itself create new security risks. In this paper, we explore one such subtle situation that arises from an intelligence gathering feature present in FireEye's widely-deployed passive deep-packet inspection appliances. In particular, FireEye's systems will report back to the company Web requests containing particular content strings of interest. Based on these reports, the company then schedules independent requests for the same content using distributed Internet proxies. By broadly scanning the Internet using a known trigger string we are able to reverse engineer how these measurements work. We show that these side-effects provide a means to empirically establish which networks and network links are protected by such appliances. Further, we also show how to influence the associated proxies to issue requests to any URL. 

Scale-out datacenter network fabrics enable network operators to translate improved link and switch speeds directly into end-host throughput. Unfortunately, limits in the underlying CMOS packet switch chip manufacturing roadmap mean that NICs, links, and switches are not getting faster fast enough to meet demand. As a result, operators have introduced alternative, parallel fabric designs in the core of the network that deliver N-times the bandwidth by simply forwarding traffic over any of N parallel network fabrics. In this work, we consider extending this parallel network idea all the way to the end host. Our initial impressions found that direct application of existing path selection and forwarding techniques resulted in poor performance. Instead, we show that appropriate path selection and forwarding protocols can not only improve the performance of existing, homogeneous parallel fabrics, but enable the development of heterogeneous parallel network fabrics that can deliver even higher bandwidth, lower latency, and improved resiliency than traditional designs constructed from the same constituent components. 

Mutually Agreed Norms on Routing Security (MANRS) is an industry-led initiative to improve Internet routing security by encouraging participating networks to implement a series of mandatory or recommended actions. MANRS members must register their IP prefixes in a trusted routing database and use such information to prevent propagation of invalid routing information. MANRS membership has increased significantly in recent years, but the impact of the MANRS initiative on the overall Internet routing security remains unclear. In this paper, we provide the first independent look into the MANRS ecosystem by using publicly available data to analyze the routing behavior of participant networks. We quantify MANRS participants' level of conformance with the stated requirements, and compare the behavior of MANRS and non-MANRS networks. While not all MANRS members fully comply with all required actions, we find that they are more likely to implement routing security practices described in MANRS actions. We assess the relevance of the MANRS effort in securing the overall routing ecosystem. We found that as of May 2022, over 83% of MANRS networks were conformant to the route filtering requirement by dropping BGP messages with invalid information according to authoritative records, and over 95% were conformant to the routing information facilitation requirement, registering their resources in authoritative databases. 

Recent proposals for reconfigurable data center networks have shown that providing multiple time-varying paths can improve network capacity and lower physical latency. However, existing TCP variants are ill-suited to utilize available capacity because their congestion control cannot react quickly enough to drastic variations in bandwidth and latency. We present Time-division TCP (TDTCP), a new TCP variant designed for reconfigurable data center networks. TDTCP recognizes that communication in these fabrics happens over a set of paths, each having its own physical characteristics and cross traffic. TDTCP multiplexes each connection across multiple independent congestion states---one for each distinct path---while managing connection-wide tasks in a shared fashion. It leverages network support to receive timely notification of path changes and promptly matches its local view to the current path. We implement TDTCP in the Linux kernel. Results on an emulated network show that TDTCP improves throughput over both traditional TCP variants, such as DCTCP and CUBIC, and multipath TCP by 24--41% without requiring significant in-network buffering to hide path variations. 

The Border Gateway Protocol (BGP) is the protocol that networks use to exchange (announce) routing information across the Internet. Unfortunately, BGP has no mechanism to prevent unauthorized announcement of network addresses, also known as prefix hijacks. Since the 1990s, the primary means of protecting against unauthorized origin announcements has been the use of routing information databases, so that networks can verify prefix origin information they receive from their neighbors in BGP messages. In the 1990s, operators deployed databases now collectively known as the Internet Routing Registry (IRR), which depend on voluntary (although sometimes contractually required) contribution of routing information without strict (or sometimes any) validation. Coverage, accuracy, and use of these databases remains inconsistent across ISPs and over time. In 2012, after years of debate over approaches to improving routing security, the operator community deployed an alternative known as the Resource Public Key Infrastructure (RPKI). The RPKI includes cryptographic attestation of records, including expiration dates, with each Regional Internet Registry (RIR) operating as a "root" of trust. Similar to the IRR, operators can use the RPKI to discard routing messages that do not pass origin validation checks. But the additional integrity comes with complexity and cost. Furthermore, operational and legal implications of potential malfunctions have limited registration in and use of the RPKI. In response, some networks have redoubled their efforts to improve the accuracy of IRR registration data. These two technologies are now operating in parallel, along with the option of doing nothing at all to validate routes. Although RPKI use is growing, its limited coverage means that security-conscious operators may query both IRR and RPKI databases to maximize routing security. However, IRR information may be inaccurate due to improper hygiene, such as not updating the origin information after changes in routing policy or prefix ownership. Since RPKI uses a stricter registration and validation process, we use it as a baseline against which to compare the trends in accuracy and coverage of IRR data. 

The Internet Route Registry (IRR) and Resource Public Key Infrastructure (RPKI) both emerged as different solutions to improve routing security in the Border Gateway Protocol (BGP) by allowing networks to register information and develop route filters based on information other networks have registered. RPKI is a crypto system, with associated complexity and policy challenges; it has seen substantial but slowing adoption. IRR databases often contain inaccurate records due to lack of validation standards. Given the widespread use of IRR for routing security purposes, this inaccuracy merits further study. We study IRR accuracy by quantifying the consistency between IRR and RPKI records, analyze the causes of inconsistency, and examine which ASes are contributing correct IRR information. In October 2021, we found ROAs for around 20% of RADB IRR records, and a consistency of 38% and 60% in v4 and v6. For RIPE IRR, we found ROAs for 47% records and a consistency of 73% and 82% in v4 and v6. For APNIC IRR, we found ROAs for 76% records and a high consistency of 98% and 99% in v4 and v6. For AFRINIC IRR, we found ROAs for only 4% records and a consistency of 93% and 97% in v4 and v6. 

Passive remote memory remains the holy grail of disaggregation. Most existing systems for disaggregated memory either use remote memory simply as a backing store, or design special-purpose data structures that require some amount of processing co-resident with the remote memory to manage and apply updates. The few proposals for truly passive remote memory perform well only with read-mostly workloads, rapidly deteriorating in the face of even low levels of write contention. We propose to leverage in-network devices (specifically, a programmable top-of-rack switch) to serialize remote memory accesses and resolve any write conflicts in flight. Our prototype is able to completely avoid write contention in the recently published Clover disaggregated key/value store, delivering a performance boost of almost 50% on our testbed under a mixed read/write workload.