[tor-bugs] #3374 [Torouter]: Torouter OS and configuration

[Tor Bug Tracker & Wiki]

#3374: Torouter OS and configuration
----------------------+-----------------------------------------------------
 Reporter:  runa      |          Owner:  runa
     Type:  task      |         Status:  new 
 Priority:  normal    |      Milestone:      
Component:  Torouter  |        Version:      
 Keywords:            |         Parent:      
   Points:            |   Actualpoints:      
----------------------+-----------------------------------------------------

Comment(by ioerror):

 Replying to [comment:32 rransom]:
 > Replying to [comment:30 cypherpunks]:
 > > Replying to [comment:29 runa]:
 >
 > > > I wonder if we should wait with shipping 0.2.3.x until it can be
 considered stable. The purpose of the Torouter is to provide a (cheap)
 consumer-level Internet router that is a tor bridge. Shipping with
 software that cannot be considered stable and/or hasn't been tested in the
 wild may not be a good idea.
 > >
 > > I think we've waited long enough and testing with 0.2.3.x should be
 fine. We're doing releases of it, we should consider it experimental which
 is of course the goal of the Torouter; it is an experiment. If we find it
 non-functional or that it is breaking, we should fix it. We need a UPnP
 and NATPMP client for these devices to work easily.
 >
 > Why do these devices need UPnP and NAT-PMP ''client'' support?  It is
 very unlikely that any ISP which does not allow its customers to listen
 for TCP connections without a UPnP or NAT-PMP request would allow its
 customers to listen for them ''with'' such a request.
 >

 Huh? Every home router on the planet seems to have either NAT-PMP or UPnP
 support. Every Apple device has NAT-PMP on by default and it's the *only*
 way to map a port through their NAT devices. This is about punching holes
 in a NAT, it's not about binding to a port when you have a public IP
 address. I really doubt these boxes will have a public IP very often.

 > An UPnP or NAT-PMP ''server'' is more likely to be useful, but would
 need to be turned off by default.

 Huh? Why?

 >
 > We might need to deploy Tor 0.2.3.x on these devices anyway, if we go
 ahead with the plan in proposal 180 of requiring protocol obfuscators to
 interact with Tor, but deploying obfuscators on Torouter would require a
 software update anyway -- we currently have no protocol obfuscators that
 would remain unblocked for more than a day against a slightly competent
 attacker.
 >

 Indeed.

 > (By ‘slightly competent attacker’, I mean someone capable of checking a
 single box on the configuration panel of a typical censoring proxy
 device.)

 Yeah, the bar is really low...

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3374#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online