[tor-talk] Onionland: Bittorrent, VoIP, Gaming, P2P, Biz, Mosh, IRC, Mail, News, Social, Apps... and UDP IPv6 OnionCat

[grarpamp <grarpamp@xxxxxxxxx>]

On 10/23/18, Iain Learmonth <irl@xxxxxxxxxxxxxx> wrote:
>> [from other threads]

>> Bittorrent users

> This is an area with a lot of open research questions.

As to width, not really. As before, for the forseeable future regarding
the cost to generate collisions into 2^80 compared to the planet's
population, Bittorrent, over otherwise acceptably resistant overlay
networks, simply has no need for stronger authentication of
nodes than that. Worst case any bad blocks and bad talkers
will be rejected by existing torrent protocols. That's for the
public network. Private BT nets (corp, gov, friends, whatever)
have other means of restriction, PSK, VPN, etc.
And if someone does waste 80 bits of their time colliding
your bittorrent address, just generate another onion on
the fly and you're back on in seconds leaving them with
a nasty electric bill and nothing to show for it.

For purely "non exit" use, as with I2P, tor + Onioncat is
perfectly suitable to needs of today's bittorrent users
regarding node authentication bit width.

> as I understand it, v2 Onion
> services will not be around forever

Again, that's a completely arbitrary talking point based
on Tor's mommy coddling of the end user initiative.
That's certainly ok, go ahead, push v3 and all the latest
advances everywhere, no problem, that's actually a good
and noble thing.
However it is also *not* a valid excuse to drop v2,
which currently backs UDP IPv6 transport,
for those users and groups that have done the
analysis regarding their own use cases for v2.
In fact, given a v2 mode is sustainable not to the detriment
of v3 or future vX, such arbitrary statements against v2
end up looking silly. Even if it were detrimental to future
architecture it could be refactored to cohabitate with it
and for easier longer term support.

> while I don't have data on this
> I don't believe that there would be enough users to have the momentum to
> fork the Tor network.

Hard to say the strength. Looking at the numbers of
torrenters worldwide, their need for continued operations,
the big indexes and trackers now residing in overlay
networks, the constant crackdowns against the nonfree
copyright subsector on clearnet... if any significant fraction
of them woke up, the influx would be more than enough to
fork the net for the purpose of a new free haven for
torrenting alone.


> One thing I have discussed with the IETF Internet Architecture Board
> (IAB) in the past is some sort of scheme for IPv6 addressing for overlay
> networks.

Related RFC: ORCHIDv2

> The direct mapping between the IP address and an Onion service though is
> the problem. How do you discover the Onion service public key when you
> only have 96-bits of data?

That assumes that greater than any given width (from
the plausible range of 80 to 125) is needed for all use cases.
As before, for bittorrent, and human convo, it's probably not.

And for the applications where it is, well, people have been
musing solutions on the lists for years, but not devoting time
to developing a working solution as a project.

> work on v3 OnionCat
> or some Onion-native version of a protocol (via some kind of AF_ONION
> sockets).

"AF_ONION" has been suggested among many other potential
solutions. However as said, you're talking major 3rd party work...
libraries, compilation, and runtime options added to all software,
whereas essentially all software is IPv6 today, or there in near term.
Unlike torify and packet redirection, that AF is not a trivial solution.
And everyone knows that tor is not and will not be the only overlay.
Thus the software world will not accept all that work just for your
own little AF_ONION pet. Any AF_* effort would work *only* if it
was done as a wide and generic AF_OVERLAY... a library shim
that can talk to whatever overlay transports of the day, even
concurrently.. And such AF_OVERLAY work, being larger than tor,
would rightly likely be homed in independant working group elsewhere.

> An interesting fact I learnt recently is that FTP predates TCP
> and was actually "ported" after its original development.

NCP was dropped as a comms protocol in the early 80's.
Perhaps protocol and fundamental design elements of both
tor and that of other overlay networks will be dropped for
new ones in the near future as well. Nothing lasts forever,
and most today's networks aren't very resistant to today's
AI GPA. Three hops circuit extension seems dated to
defeating other primary attack classes of their day. And
today it is very unlikely that advanced GPA is the
laughable conjecture of yesteryear.

https://en.wikipedia.org/wiki/Packet_Radio_Van
https://en.wikipedia.org/wiki/Delay_line_memory

> +1 would encourage anyone that wanted to do research in this area.

Yes please.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk