Opened 8 years ago

Last modified 17 months ago

#3982 reopened enhancement

MAPADDRESS for IP ranges (CIDR, etc)

Reported by: grarpamp Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.2.10
Severity: Normal Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The general idea is to have MAPADDRES match blocks of IP addresses with one rule:
MAPADDRESS 1.2.3.4/18 1.2.3.4/18.<fingerprint>.exit

Very useful for:
o Same as domain wildcarding...
o Constraining known destination ranges to an exit. VPN's, corporate/edu DMZ's, location aware services, location/IP restricted services, etc.
o Catchall for unexpected/unknown use of IP's. Such as websites that code them in html page elements, services such as multimedia farms, places that don't use FQDNS, etc. If you know one IP (manual resolve, or see one pop up), you can MAP out a good sized CIDR block without disturbing your other Tor traffic.
o Simplicity, fewer MAP rules.

Further rationale, examples and extensions...
DOMAINS:

http://archives.seul.org/or/dev/Jun-2009/msg00011.html
http://archives.seul.org/or/dev/Jun-2009/msg00023.html

CIDR:

http://archives.seul.org/or/talk/Oct-2009/msg00150.html
http://archives.seul.org/or/talk/Mar-2011/msg00154.html

MISC:

http://archives.seul.org/or/talk/Aug-2009/msg00295.html
http://archives.seul.org/or/talk/Dec-2010/msg00175.html
http://archives.seul.org/or/talk/Mar-2011/msg00144.html

Split from ticket - MAPADDRESS for Domains:
https://trac.torproject.org/projects/tor/ticket/933

"[We] need to figure out (or somebody else would figure out) how this would interact with DNS resolution. :)" --NickM

It's already figured out... DNS is just a user/app layer on top of Tor's network transport, and thus DNS is not involved :)

Tor just needs to grab whatever IP's the client ultimately requests to get to via SOCKS/TransPort (if and after any DNS [resolved via SOCKS, the host, or otherwise]), and route them through the MAPPED exit... if the user specified such a MAP for said IP's.

Child Tickets

Change History (18)

comment:1 Changed 8 years ago by nickm

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

Right now, if Tor gets a SOCKS request for "www.torproject.org:443", it tells its exit node "connect to www.torproject.org:443" -- that's the BEGIN cell. And the exit node says "okay, I did it -- I connected you to 38.229.70.16:443" -- that's the CONNECTED cell.

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.

So in order to use this feature, you would need to change how Tor behaves when its told to connect to a hostname over SOCKS. That's why I said "We would need to figure out how this would interact with DNS resolution".

comment:2 in reply to:  1 Changed 8 years ago 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.

comment:3 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:4 Changed 8 years ago by grarpamp

Cc: grarpamp@… added

comment:5 Changed 8 years ago by grarpamp

Version: Tor: 0.2.2.32Tor: 0.2.2.35

comment:6 Changed 7 years ago by grarpamp

Version: Tor: 0.2.2.35Tor: 0.2.2.36

This feature, and MapAddress implementation in general, will need to handle IPv6 addresses also.

comment:7 Changed 7 years ago by grarpamp

Cc: grarpamp@… removed

comment:8 Changed 7 years ago by nickm

Keywords: tor-client added

comment:9 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:10 Changed 6 years ago by grarpamp

Version: Tor: 0.2.2.36Tor: 0.2.3.25

comment:11 Changed 6 years ago by grarpamp

Milestone: Tor: unspecifiedTor: 0.2.5.x-final
Version: Tor: 0.2.3.25Tor: 0.2.4.19

Updating...
Unless it comes free as part of a parsing library, I'd suggest that skipping the work to create a fill notation [1] is fine, since that can be done by the user with multiple /[32|128] 'host' or /<small> entries to fill in any gaps between CIDR's. Single CIDR entries [IPv4|IPv6] from /0 to /[32|128] lengths should suffice.

Though covering the BEGIN context for the resultant IP does make sense in an absolute/flexible way, it's already covered if the user mapped the domain being passed to BEGIN in the first place... which is a map they are indeed likely to make... and it naturally covers whatever IP's come back from the resolve/circuit process.

Covering backend BEGIN context would fail when circuits/exits change and multiple DNS 'A' records or geo stuff is in play, and would thus require lots more discovery and work by the user. Seems better for user to simply map the supplied domain argument as is done today than play with split horizon backsides and new resolve models for Tor. You're not really supposed to manage results from CNAME/A/SRV/symlinks anyway.

This was intended to cover, with simple CIDR efficiency, any IP's supplied directly by the user such as [ssh|http]:/<IP>/, or those fed back to the user via html response for them to discover and map as needed.

[1] 'Fill' was described in email above using commas(,) hyphens(-) wilds(*) twodots(..) braces etc to create/manage a single mapaddress entry for whatever the user's higher level object was. That would be ugly/long for less than trivial objects. (Tagging mapaddress entries with user defined strings or reference counts might be better, ie: the 'ruleset' concept... these 5 are for 'foo', this overlapping 10 are for 'bar', remove either still leaves the other. It could interact with new SocksPort tag flags. Rule precedence might matter too. If anyone needs this, just run multiple Tor's for now.)

Last edited 6 years ago by grarpamp (previous) (diff)

comment:12 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:13 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:14 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:15 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:16 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: newclosed

Closing this as wontfix -- it's a cool idea, but i just haven't seen the demand for it over the last 6 years. Projects like tails and whonix are taking other approaches to firewalling, and theirs honestly seem more robust than this could be

comment:17 Changed 17 months ago by cypherpunks

Resolution: wontfix
Status: closedreopened
Version: Tor: 0.2.4.19Tor: 0.3.2.10

This would be good help as we want program certain exists around the world. We test security a lot. Is easiesy way to handled mixed mode webpages by mapping their domain and IPs too, an we often want to map only some IP's while leave rest of tor on autodefault for other things. All other ways are complex and weight problems to do, in controller is easier best, and fair match complement to work prior done with domains. Yes, for IPv6 too since those can exits. Most important use mode: This for direct connect like 'netcat <ip>' tells BEGIN <ip>, says CONNECTED <ip>, doman/dns is no part of that mode. Thx.

comment:18 Changed 17 months ago by cypherpunks

The less use mode you said about...

Situacion 1:
On internet, connect <ip> is force override and no use domain layer at all. So nearest anlogue is new option 'DomainYieldToIPMap' for "regardles if domain mapped or not, if 'BEGIN domain' say back to us 'CONNECTED ip' then go check that ip exist in the ip MAP's, if so go rearrange redo the circuit underneath the scene to match ip map before pass stream data". The one more circuit making as needed is ok cost. Default: on.

Situacion 2:
The remaining one is simply to documen that BEGIN domain, just like tor RESOLVE domain, can backed by many ip's in dns but tor use only one, this leading to obvious of some CONNECTED ip's maybe not being in any ip map, so that split is ok thing to caveat note to the user.

Note: See TracTickets for help on using tickets.