Investigate NAT-piercing approaches for relays and bridges
For sponsor F deliverable 20 we promised to "investigate nat piercing approaches for relays / bridges."
Roger says we have UPnP and NAT-PMP, but it would be great to let relays and bridges function behind NATs without doing port forwarding, e.g., by UDP tricks or TCP tricks or third-party tricks or something. There are NAT-piercing libraries out there, but most of them are poorly written. There are also a bunch of NAT-piercing techniques, some of them are probably even good ideas.
Jake and I agreed that a good first step would be to write a tech report that compares the different NAT-piercing options we have. It could be titled "Overview of NAT-piercing approaches for Tor relays and bridges" and include UPnP, NAT-PMP, and whatever we come up with. Jake says he's going to write such a tech report.
Activity
changed milestone to %Tor: unspecified
Here's the plan from talking to Jake, Steven, and Roger yesterday:
- Jake has sent a paper draft to Steven who's going to review it soon.
- Jake plans to send the revised and then final paper to tor-dev to kick off a discussion. Jake expects this to happen in April; it should happen before June to have some time for the discussion. People who should be made aware of the tor-dev discussion to allocate time for it are: Roger, Nick, and package-building people.
- The deliverable result will be the paper, a summary of discussion results, and a plan what we decided to do next and when we'll do it.
- The actual coding work would turn into either a sponsor Z or a sponsor F year 3 deliverable.
People who have enabled IPv6 may also have added a rule to block incoming IPv6 connections to machines on their LAN for the NAT like "security" of blocking rest-of-the-world connections to local machines.
This is a relatively common setup in my experience, so something that works on dual stack networks configured like this is probably important.
Replying to ioerror:
I've uploaded a draft paper that discusses these issues - if anyone has feedback, I'd be happy to incorporate it into the final document.
Being a non-native speaker, I'm shy on potential spelling typos, but let's give it a try anyway:
- s/reducable/reducible/
- s/programatic/programmatic/
- in "monitoring of the third party may reveal every bridge that wishes it were reachable", it's not clear that "it" refers to the bridge itself. I suggest s/it were/to be/
- I like section 3. Quite clearly shows most of the anonymity/privacy arguments against "trusted" 3rd-party -based solutions migrate gracefully to the reachability problem. "the UPnP forum managed standard UPnP" is a bit unclear for me. I think I understand it on second read, but it's unclear still.
- 4.1 lands in a bit brutally. I suggest creating "4.1 Current state of NAT traversal protocols in the Tor ecosystem", with a few introduction word, and moving 4.1->4.1.1 + 4.2->4.1.2.
- s/requsite/requisite/
- in "and manually configure the required port forwarding correctly", I'm not sure what value is added by "correctly", and it looks to me it could be misunderstood.
- s/might might/might
- "as users will have to positively affirm their desire to enable such a feature" --> it's not clear to me how they will have to do this.
- s/should be sent the the/should be sent to the/
- s/signifigant/significant/
From the desk of the language pedant:
Introduction, second sentence is slightly clumsy, one sentence that could be two to read a bit easier.
Page 3, section 2, paragraph 2, final word: s/simplicty/simplicity/ and one too many full stops. Page 3, Section 2, s/programatic/programmatic/ (and also programmatically - although both may no be considered correct) Capitalization of Local Area Network and Wide Area Network being consistent (in section 2, WAN is but LAN isn't) Page 4, Paragraph 2, s/reducable/reducible/ Page 5, Section 6, paragraph 2, requisite is missing an i (it's requsite) Page 5, Section 7, paragraph 2, s/might might/might/ Page 5, Section 8, second last line: "the the" -> "via the" ? Page 6, Section 9, second last line: s/signifigant/significant/
You may have already corrected some (or all) of these, but just in case:
-
In section 2, first paragraph, the last sentence, it may be more clear if the second dash is replaced with a comma.
-
Second para, last word, single period?
-
Third para, In general should be followed by a comma
-
Third para, last sentence, in "NAT devices allow for services to reachable behind the NAT device" s/services to reachable/services to be reachable/
-
Fifth para, the use of former and latter seems unclear. Does former refer to STUN, TURN,... and latter refer to UPnP and NAT-PMP?
-
In section 3, s/Autonomous NAT traversal/Autonomous NAT Traversal/
-
In section 4, s/UPnP forum/UPnP Forum
-
Also in sect 4, add commas around clarifying phrase, s/the second but still extremely common protocol is the Apple standard NAT-PMP/the second, but still extremely common protocol, is the Apple standard NAT-PMP
-
Sect 4, second para, back-to-back sentences start with While
-
In section 5, second para, s/tor/Tor -- actually it just caught my eye that the use of Tor is non-uniform, should it be italicized and capitalized?
-
Section 6: Do any distros (Debian, Red Hat) compile in UPnP support by default? If so, should this be mentioned?
-
Section 8: This may be tangential, but what if the user is running dual stack IPv4/IPv6? If a Tor bridge is compiled with tor-fw-helper, will it realize there is a v4 interface and pierce the firewall or will it check for v6 and automatically not run?
-
In References, s/Autonomous nat traversal/Autonomous NAT Traversal/
-
General critique: You mention that you assume the reader is familiar with the Grothoff et al. paper, but should you also say that it would be beneficial for the user to be familiar with the general ideas used by UPnP and/or NAT-PMP?
Nice paper overall. Thanks for writing it.
-
-
Switching from using milestones to keywords for sponsor deliverables. See #6365 (moved) for details.
Trac:
Milestone: Sponsor F: November 1, 2012 to N/A
Keywords: N/A deleted, SponsorF20121101 added Trac:
tor-nat-plan.pdf-
The report is now available here.
How's this summary for the sponsor page, stolen from your abstract? "We wrote a tech report that discusses the current methods for enabling and enhancing Tor bridge and Tor relay reachability when behind a consumer grade NAT device. Such reachability improvements are extremely important for embedded devices that provide Tor relaying or Tor bridging services. We propose the use of NAT-PMP and/or UPnP protocol(s) to ensure that inbound connectivity is possible."
I assume, once the summary is up, we can close this ticket?
-
Makes sense. I added the summary above to the wiki page and called the deliverable partly done. Once the discussion in #4959 (moved) is done we should add another summary sentence or two to the wiki page.
moved to tpo/core/tor#4960 (closed)
