[tor-bugs] #3982 [Tor Client]: MAPADDRESS for IP ranges (CIDR, etc)

[Tor Bug Tracker & Wiki]

#3982: MAPADDRESS for IP ranges (CIDR, etc)
-------------------------+--------------------------------------------------
 Reporter:  grarpamp     |          Owner:                    
     Type:  enhancement  |         Status:  new               
 Priority:  normal       |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Client   |        Version:  Tor: 0.2.2.32     
 Keywords:               |         Parent:                    
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------

Comment(by grarpamp):

 > So, if somebody configured this, they couldn't use any BEGIN cells
 > with a hostname in them?

 Couldn't? They could, but the result might be unexpected.

 > But if you've set things up so that 38.229.70.0/8 gets remapped
 > to something else, then now it's too late: you already made a
 > connection to 38.299.70.16 when you connected to www.torproject.org.

 If your only connection requests are for tpo, yes.

 0) And, also today, if I have only a map for the IP, the first
 connect to the FQDN appears not to check that map :( Of course due
 to the responsibilities of the exit and these cells as you mentioned.
 Future connects do check it, presumably since the IP returned from
 CONNECTED is now loaded into the local client state.


 Looks like I'm wrong in thinking Tor operates like standard DNS...
 ie: client requests connect to www, wait while path opens for DNS
 and some exit resolves it, client receives reply of 38, client sends
 packet to 38, buffer as some (possibly new) path opens up for that
 too, packet moves on through.

 Underlying the proposal, I figured...

 1) *.domain maps would be independant from CIDR maps:
 map tpo a.exit
 map 38 b.exit
 telnet tpo (uses a)
 telnet 38 (uses b)

 I can't think of a case where splitting traffic this way is common
 user desire. But as far as following rules go, that would be the
 correct way to handle it.

 2) And not be chained, with CIDR maps backing *.domain maps (uck,
 because it's horrible breakage on expectation for tpo path).
 map tpo a.exit
 map 38 b.exit
 telnet tpo (uses b)
 telnet 38 (uses b)


 3) Note today, there is also that IP automap backing thing in place:
 map tpo a.exit
 telnet tpo (uses a)
 telnet 38 (uses a, via IP automap)
 I'm guessing that was done for efficiency. If I drop in a further
 (map 38 b), that seems to take precedence such that a future telnet
 38 now uses b.


 I don't have a problem with making the process of what I think
 you're describing as 'BEGIN' hold just an IP... effectively using
 Tor as a standard DNS cloud beforehand, then firing off the data
 stream with BEGIN. CONNECTED would just be a 'ok, send more, no
 need to find another circuit.'

 It would normalize all the different ways IP and FQDN maps are
 handled today (as above in 0, 1, 3).

 The drawbacks I see (again, I'm lay) to that are:

 1) Bad DNS exits are now possibly more frequently separate from the
 traffic exit. So the stream events stuff would need to emit that
 data to allow tracking bad DNS. That's not too bad. I think today
 both DNS and traffic are forced over the same exit. Well, unless
 maybe the exit dies halfway through or has no path?

 2) Maybe a round trip slower to wait for explicit DNS? Given that
 a request to *.53 may not wind up with the same router open (via
 accept/reject) to *.port anyways... there's some average number of
 circuit failures inherent in the current way, so maybe moving to
 explicitly separate DNS and traffic stages, all client managed,
 isn't that bad after all. And there might be some benefit to being
 able to say, 'use only country code DNS exits, but let data go
 wherever'.

 Maybe it's some work, I don't know. Doesn't a pure DNS cell type
 already exist (for resolving DNS forwarded via packet filters)?

 I think the payoff for the (IP's present in HTML different than its
 FQDN) and (map my entire VPN provider range to an exit in one rule)
 type cases would be worth it.

 I dont think there'd be any anonymity issues with this. Maybe a
 little win if plaintext DNS doesn't appear so often anymore out the
 same just before the traffic does.

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