[tor-talk] Tor VoIP PBX Architecture Discussion / Onioncat

[grarpamp]

Tor Metrics has some data on average latencies for client to Onion
service. This is your absolute minimum latency, with the only way to
reduce this being to have latency-aware path selection

Apps like VoIP, IRC, shell could all benefit from that selection.
Tor doesn't proffer path selection for valid reasons, so probably
won't anytime soon. Third parties might be able to develop
a controller plugin scheme for it, including as a byproduct,
even more metrics that one might wish to also choose nodes
based upon, trust, etc.

https://metrics.torproject.org/onionperf-latencies.html

These data might generated from already cached HS descriptors,
so initiating a call to uncached would take somewhat longer.
Typically under 2s init, which is fine for any use case.

Configuring your onion service to not be location hidden would
improve this.

See the config options to reduce the hop count
in the path controlled by the onion service side.
The client chooses their own side.

It would be interesting to see what kind of overheads are added by
OnionCat

Not much.

but I see that Onioncat is a project that has an end in sight

That's arbitrary.

Alternatively users can say, and Tor can listen... "Onioncat provides
good feature capabilities not provided by anything else, we're using
this, it works for us, or it's a nice feature capability that others can
use, we're aware of tradeoffs, we've evaluated our usage, needs,
and threat models, therefore support for it needs to continue, at
least until a replacement arrives".

That's fair.

IPv6 addresses are not long enough to encode keys into to make
them self-authenticating.

Referring explicitly to v3 HS desc... and without truncation,
generation, registration, mapping or other schemes... sure.

However, no... IPv6 address width is long enough for use cases where
it is long enough and not long enough for other use cases where
it is not.

Different use cases might select different strengths based on needs.

Bittorrent users don't need lifetime / PQC level authentication
between peers, they just need enough to prevent nuisance
collisions from degrading operations. Today even the less
than 32 bits of IPv4 (reality: users don't typically brute the ISPs)
are working just fine for that, and the 80 bits over Onioncat will
be sufficient for that for forseeable future. Where they need many
more equivalent bits of strength is likely in encryption, integrity,
and anonymity, not authentication.

Voice and video talkers also might not need lifetime / PQC
resistant authentication when they have additional bits
available to them through hearing and seeing and the
context of the conversation ratchet with their peer[s].
And they can repeat for integrity. But they might want
strong encryption and anonymity. Same for IRC.

Yes, strive to deploy the longest lengths and best accepted
algorithms universally wherever possible, just keep in mind
use cases exist that are quite happy to move all the sliders
around in order to meet their own overall needs.

IPv6 addresses

Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

Either we need IPv7

256 bit equivalent strength for all keys and algos including PQC,
represented into addressing... ok, push it through the IETF just
like .onion was.

While you're at it, don't forget to push both...
1) PFS per link encryption, with PQC option
2) chaff fill to the full link rate
... in all switch and router and MAC PHY hardware,
automatically on by default, on every interface, out of the box.

Add to that pushing #OpenFabs and #OpenHW , etc
so that you know what you're getting.

unless someone comes up with a way to make it work
with v3 Onion Services.
perhaps some Onion-native network layer or something else.

Lots of options and ideas here have been and can be
further solicited researched and developed. Search
the lists for Onioncat to find some of them, or generate
your own.

People would like IPv6 and UDP (even raw IP) transport because
their host stacks support it, the internet is moving to it,
many applications simply don't speak .onion or torify poorly,
and it's an interesting capability to plug into other things.

Whether in Tor or some other existing or new network,
try getting together to develop it, or white papering why it
cannot be done in any network ever. Whichever outcome,
any good research there would be a useful addition
to the set other projects might reference in developing
their own work.

[Iain Learmonth]

Hi,

Post by grarpamp
Bittorrent users don't need lifetime / PQC level authentication
between peers, they just need enough to prevent nuisance
collisions from degrading operations. Today even the less
than 32 bits of IPv4 (reality: users don't typically brute the ISPs)
are working just fine for that, and the 80 bits over Onioncat will
be sufficient for that for forseeable future. Where they need many
more equivalent bits of strength is likely in encryption, integrity,
and anonymity, not authentication.

This is an area with a lot of open research questions. I understand that
users have different requirements, but as I understand it, v2 Onion
services will not be around forever and 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.

Post by grarpamp
Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

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. The result of that discussion was basically get an allocation
from your RIR. You can get a /32 giving you 96 bits to play with. If you
want you can announce it via BGP and provide gateways to the Internet
but it's not required. This gives you collision-free space.

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?

Post by grarpamp
People would like IPv6 and UDP (even raw IP) transport because
their host stacks support it, the internet is moving to it,
many applications simply don't speak .onion or torify poorly,
and it's an interesting capability to plug into other things.

I think I see it more as a transition-mechanism than an end goal. If I
had the time, it's 50/50 right now whether I would work on v3 OnionCat
or some Onion-native version of a protocol (via some kind of AF_ONION
sockets). An interesting fact I learnt recently is that FTP predates TCP
and was actually "ported" after its original development.

Post by grarpamp
Whether in Tor or some other existing or new network,
try getting together to develop it, or white papering why it
cannot be done in any network ever. Whichever outcome,
any good research there would be a useful addition
to the set other projects might reference in developing
their own work.

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

Thanks,
Iain.

[Conrad Rockenhaus]

Signed PGP part
Hi,

<deletion>

Post by grarpamp
Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

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. The result of that discussion was basically get an allocation
from your RIR. You can get a /32 giving you 96 bits to play with. If you
want you can announce it via BGP and provide gateways to the Internet
but it's not required. This gives you collision-free space.
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?

This would be a cool area to research and development on. I think Tor announcing it’s address space and the correlation of users would be a cool area to research.

Post by grarpamp
People would like IPv6 and UDP (even raw IP) transport because
their host stacks support it, the internet is moving to it,
many applications simply don't speak .onion or torify poorly,
and it's an interesting capability to plug into other things.

I think I see it more as a transition-mechanism than an end goal. If I
had the time, it's 50/50 right now whether I would work on v3 OnionCat
or some Onion-native version of a protocol (via some kind of AF_ONION
sockets). An interesting fact I learnt recently is that FTP predates TCP
and was actually "ported" after its original development.

Post by grarpamp
Whether in Tor or some other existing or new network,
try getting together to develop it, or white papering why it
cannot be done in any network ever. Whichever outcome,
any good research there would be a useful addition
to the set other projects might reference in developing
their own work.

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

I gladly volunteer my time, research, hardware, and network for research in this area.

Thanks,

Conrad