Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • S Snowflake
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 70
    • Issues 70
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • Pluggable Transports
  • Snowflake
  • Issues
  • #40022

Closed
Open
Created Nov 18, 2020 by Cecylia Bocovich@cohoshOwner0 of 2 tasks completed0/2 tasks

Redefine restricted NAT designation to include only symmetric NATs

See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching for an overview of NAT types and compatibility.

Right now we classify a client NAT as "restricted" if it is symmetrically NAT'd (i.e., has an (AO,X) or (AP,X) NAT mapping and filtering behaviour) and also if it has an aggressive filter (AI, AP).

As mentioned as a footnote on the NAT matching wiki page, most (AI,AP) clients will actually work with most (> 80% of) restricted proxies. It's also the case, judging by recent snowflake CollecTor stats, that the majority of clients are (AI,AP). Right now these clients are drawing from the very small unrestricted proxies bucket and depleting this resource. I'd like to reclassify these clients as unrestricted so they can pull from the restricted proxy pool. Getting a failed proxy ~20% of the time shouldn't be an issue, especially with the future plans to multiplex in #25723.

This also means that "restricted" is defined differently for clients vs. proxies. (AI,AP) is a restricted proxy, but an unrestricted client.

To do this, I'd like to make the following changes:

  • Have standalone proxies do the probe test instead of using the RFC 5780 method to determine NAT behaviour
  • Redefine (AI,AP) to be an unrestricted NAT type
Edited Nov 19, 2020 by David Fifield
Assignee
Assign to
Time tracking