Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Towards Flexible Anonymous Networks

Florentin Rochet, Jules Dejaeghere, Tariq Elahi

TL;DR

This work proposes Flexible Anonymous Network (FAN), a new software architecture for volunteer-based distributed networks that shifts the dependence away from protocol tolerance without losing the ability for developers to ensure the continuous evolution of their software.

Abstract

Anonymous Communication designs such as Tor build their security on distributed trust over many volunteers running relays in diverse global locations. In practice, this distribution leads to a heterogeneous network in which many versions of the Tor software co-exist, each with differing sets of protocol features. Because of this heterogeneity, Tor developers employ forward-compatible protocol design as a strategy to maintain network extensibility. This strategy aims to guarantee that different versions of the Tor software interact without unrecoverable errors. In this work, we cast protocol tolerance that is enabled by forward-compatible protocol considerations as a fundamental security issue. We argue that, while being beneficial for the developers, protocol tolerance has resulted in a number of strong attacks against Tor in the past fifteen years. To address this issue, we propose Flexible Anonymous Network (FAN), a new software architecture for volunteer-based distributed networks that shifts the dependence away from protocol tolerance without losing the ability for developers to ensure the continuous evolution of their software. We i) instantiate an implementation, ii) evaluate its overheads and, iii) experiment with several of FAN's benefits to defend against a severe attack still applicable to Tor today.

Towards Flexible Anonymous Networks

TL;DR

This work proposes Flexible Anonymous Network (FAN), a new software architecture for volunteer-based distributed networks that shifts the dependence away from protocol tolerance without losing the ability for developers to ensure the continuous evolution of their software.

Abstract

Anonymous Communication designs such as Tor build their security on distributed trust over many volunteers running relays in diverse global locations. In practice, this distribution leads to a heterogeneous network in which many versions of the Tor software co-exist, each with differing sets of protocol features. Because of this heterogeneity, Tor developers employ forward-compatible protocol design as a strategy to maintain network extensibility. This strategy aims to guarantee that different versions of the Tor software interact without unrecoverable errors. In this work, we cast protocol tolerance that is enabled by forward-compatible protocol considerations as a fundamental security issue. We argue that, while being beneficial for the developers, protocol tolerance has resulted in a number of strong attacks against Tor in the past fifteen years. To address this issue, we propose Flexible Anonymous Network (FAN), a new software architecture for volunteer-based distributed networks that shifts the dependence away from protocol tolerance without losing the ability for developers to ensure the continuous evolution of their software. We i) instantiate an implementation, ii) evaluate its overheads and, iii) experiment with several of FAN's benefits to defend against a severe attack still applicable to Tor today.
Paper Structure (36 sections, 3 theorems, 2 equations, 12 figures, 2 tables)

This paper contains 36 sections, 3 theorems, 2 equations, 12 figures, 2 tables.

Table of Contents

  1. Introduction
  2. Motivation
  3. Threat Model
  4. Robustness: A Blessing and a Curse
  5. Tor Project's Direction & Our Vision
  6. Background on eBPF, LLVM and JIT Compilation
  7. FAN Architecture
  8. FAN Design Features
  9. FAN Plugin Design
  10. FAN Transparency Design
  11. Design Implementation
  12. Engineering Hooks' location
  13. Performance Evaluation
  14. Methodology
  15. Time to propagate within the full network
  16. ...and 21 more sections

Key Result

Theorem 1

Under the assumption that $H:\{0, 1 \}^* \rightarrow \{0, 1\}^n$ behaves as a random oracle, a name maps to a unique authentication path in the Name-Structured Merkle Tree List with probability $1-\negl$.

Figures (12)

  • Figure 1: Flexible Anonymous Network generic architecture. The hooked plugins can be global or connection specific. That is, multiple different plugins can potentially be called from a same hook. PM. stands for Plugin Manager.
  • Figure 2: (Left) Shows plugin propagation within a simulated network using the FAN architecture (automated and unattended "push" of new code). (Right) Shows Tor's situation based on historical metrics (a fraction of volunteers perform automated "pull" of new code). Note the units.
  • Figure 3: (left) Measurement setup for FAN overheads estimation over the fast path. Each client is configured to send a 20MB stream of data. (right) Throughput of the slowest Tor client within the measurements. Each boxplot covers 500 runs with a plugin being hooked at 1, 2 or 3 different places. We use plugins sendme_1, sendme_2 and sendme_3 from Table \ref{['table:overhead']}.
  • Figure 4: Used in Tor relays to make the cell pattern of a rendezvous circuit construction similar to regular exit circuits.
  • Figure 5: Dropmark Defense padding machine negotiated on the middle relay when the circuit opens. Events "Activate" and "Be Silent" are client-triggered events fired through a protocol extension enabled with FAN. State Length is a counter decreasing at each padding cell sent.
  • ...and 7 more figures

Theorems & Definitions (3)

  • Theorem 1
  • Theorem 2
  • Theorem 3