Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #30986

Closed (moved)
Open
Opened Jun 25, 2019 by Philipp Winter@phw

Understand the "long tail" of unclassifiable network traffic

The obfs family of obfuscation protocols strives to "look like nothing" and falls into the long tail of network traffic that is meant to be unclassifiable. That is, if an ISP is monitoring its uplink, it shouldn't be able to figure out that one of its users is talking obfs4 to a Tor bridge. Instead, the obfs4 connection should show up as "unknown" in the log files.

We know next to nothing about this long tail that the obfs family hides in. What fraction of flows does it constitute? What fraction of bytes? What kind of protocols and implementations are difficult to classify? How does the long tail differ across uplinks?

Over at #30716 (moved) we're brainstorming features for obfs4's successor but before moving forward with obfs5, we should get a better understanding of this long tail because it allows us to make informed design decisions. Packet traces from the WIDE backbone is one of the data sets that may be helpful here.

Let's use this ticket to track progress and collect insights.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#30986