[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#3982: MAPADDRESS for IP ranges (CIDR, etc)
-----------------------------+--------------------------------
     Reporter:  grarpamp     |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:  Tor: 0.2.4.19
   Resolution:               |   Keywords:  tor-client
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------
Changes (by grarpamp):

 * version:  Tor: 0.2.3.25 => Tor: 0.2.4.19
 * milestone:  Tor: unspecified => Tor: 0.2.5.x-final


Comment:

 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 probably described in email above using commas(,)
 hyphens(-) wilds(*) to create/manage a single mapaddress entry for
 whatever the user's higher level object was. That would be ugly 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.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3982#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs