Opened 8 years ago

Closed 7 years ago

#4960 closed project (implemented)

Investigate NAT-piercing approaches for relays and bridges

Reported by: karsten Owned by: ioerror
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: SponsorF20121101 tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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.

Child Tickets

Attachments (1)

tor-nat-plan.pdf (78.3 KB) - added by ioerror 7 years ago.
Tor-NAT plan draft

Download all attachments as: .zip

Change History (20)

comment:1 Changed 8 years ago by karsten

Milestone: Sponsor F: March 15, 2012Sponsor F: July 15, 2012

Moving to the July milestone. We might want move it to the November milestone when discussing this deliverable in two weeks. Or we stick with July. That decision should be final then.

comment:2 Changed 7 years ago by ioerror

I have an early draft and I'll be updating it after feedback from Steven.

comment:3 Changed 7 years ago by karsten

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.

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by cypherpunks

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.

comment:6 in reply to:  4 Changed 7 years ago by intrigeri

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/

comment:7 Changed 7 years ago by cypherpunks

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/

comment:8 Changed 7 years ago by cypherpunks

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.

comment:9 Changed 7 years ago by ioerror

I will update the paper to reflect these suggestions - thank you!

comment:10 Changed 7 years ago by karsten

Milestone: Sponsor F: July 1, 2012Sponsor F: November 1, 2012

July 1 has passed, so moving this ticket to November 1.

comment:11 Changed 7 years ago by karsten

Keywords: SponsorF20121101 added
Milestone: Sponsor F: November 1, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

Changed 7 years ago by ioerror

Attachment: tor-nat-plan.pdf added

Tor-NAT plan draft

comment:12 Changed 7 years ago by ioerror

I've updated the final draft - I'm going to call this ready for becoming a Tor Tech Report.

comment:13 Changed 7 years ago by karsten

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?

comment:14 Changed 7 years ago by ioerror

Status: newneeds_information

That seems like a fine summary, yes. We can't close the ticket until we finish the child ticket's discussion.

comment:15 Changed 7 years ago by karsten

Makes sense. I added the summary above to the wiki page and called the deliverable partly done. Once the discussion in #4959 is done we should add another summary sentence or two to the wiki page.

comment:16 Changed 7 years ago by nickm

Milestone: Tor: unspecified

comment:17 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:18 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:19 Changed 7 years ago by karsten

Resolution: implemented
Status: needs_informationclosed

I didn't see any further discussion of this topic, and now that November 1 has passed, I'm going to call this sponsor deliverable done. Closing.

Note: See TracTickets for help on using tickets.