[tor-dev] Onioncat and Prop224

[Bernhard R. Fischer]

On 2016-05-26 13:37, George Kadianakis wrote:
> str4d <str4d at i2pmail.org> writes:
> 
>> [ text/plain ]
>> On 27/04/16 22:31, grarpamp wrote:
>>> On 4/25/16, Tim Wilson-Brown - teor <teor2345 at gmail.com> wrote:
>>>>
>>>>> On 22 Apr 2016, at 17:03, grarpamp <grarpamp at gmail.com> wrote:
>>>>>
>>>>> FYI: The onioncat folks are interested in collaborating
>>>>> with tor folks regarding prop224.
>>>>>
>>>>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
>>>>
>>>> I'm interested in what kind of collaboration onioncat would like to do on
>>>> prop224, next-generation hidden services.
>>>> It would be great to work this out in the next few weeks, as we're coding
>>>> parts of the proposal right now.
>>>
>>> Yep :) And I know Bernhard was hoping to get in touch with Roger
>>> on this before long.
>>>
>>> Basically, prop224 HS being wider than 80 bits will break onioncat's
>>> current HS onion <---> IPv6 addressing mechanism.
>>>
>>> They're looking at various backward compatibility options, as well
>>> as possibly making side use of the HSDir DHT, or even integrating
>>> more directly with the tor client.
>>>
>>
>> Just FYI, I recently migrated all of I2P's spec proposals to the
>> website, and came across a seven-year-old proposal that Bernhard wrote
>> about improving I2P support in GarliCat:
>>
>> https://geti2p.net/spec/proposals/105-garlicat-name-translation
>>
>> I don't know how well it has aged, but given that Tor is now facing the
>> same issues that I2P has, perhaps it can be of some use if resurrected
>> from the dead :)
>>
> 
> Hello,
> 
> disclaimer: I've never used onioncat and I'm not even sure what are the use
> cases for it. I just read the docs on its webpage in an attempt to understand
> the system and maybe contribute to this thread. I probably don't understand the
> system sufficiently yet.

Hi!

In the following there is a fundamental explanation of OC and the
problems with prop224.


OnionCat simply does 2 things:

1) It is a VPN adapter based on the Tor (or I2P) network (on its hidden
services). There is no central VPN server, instead OnionCat connects
peer-to-peer to the other participants. Because it is based on layer 3
(as most other VPNs) all packets (not just TCP) may be routed through
it. OnionCat uses IPv6 as L3 protocol.

2) OnionCat generates an end point IP address which is based on the
hidden service ID (e.g. iuddxo47v5mhoqyz.onion <->
fd87:d87e:eb43:4506:3bbb:9faf:5877:4319). This has 3 major advantages:
a) every end point automatically gets a unique IP thus the user does not
have to care about it and b) they are cryptographically tied together,
thus one cannot simply spoof an address, c) there is almost no
configuration necessary because OC can "automatically find" its way
through Tor because of its ability to translate between hidden service
ID and IP address.


> Starting with a question wrt the "Scalable Solution" for I2P, I did not exactly
> understand how the DNS approach would work for garlicat.  Would GC do the DNS
> request? Or the application? And to which DNS server? Some GC-specific DNS
> server?  The solution seems plausible, but it requires the extra DNS protocol
> round trip.
> 
> BTW, if the application-layer protocol supports DNS, can't we just fake the DNS
> protocol part and resolve the DNS query inside onioncat? So, Alice is in
> onioncat as "aliceonioncathiddenservice.onion" and she passes her onion to Bob
> who wants to torrent with her through onioncat. Alice gives
> "aliceonioncathiddenservice.onion" to her friend Bbo, and Bob tries to connect
> to it through his application (e.g. a torrent client). Bob's application will
> probably do a DNS query for the onion address, which onioncat can intercept (?).
> At that point, onioncat can register the onion address as the destination,
> and pass back a fake IPv6 address to the torrent client. From that point and
> on, the torrent client will use the fake IPv6 address, and onioncat will
> reroute the connection through the onion circuit to
> "aliceonioncathiddenservice.onion".
> 
> I'm not sure if the above idea will work, but even if it does, it's worse than
> the current onioncat, since it requires the application-layer protocol to
> support DNS.


For Alice and Bob to communicate together they need to know the IPv6
address of each other (as in any other IP-based network).


What happens technically within OnionCat?
1) OnionCat receives an IPv6 packet, decodes the header and retrieves
the destination IPv6.
2) OC converts the IPv6 address to an .onion-id
3) OC request a circuit from the Tor client with this destination .onion-id
4) Tor connects
5) OC forwards the IP packets through the circuit.
6) At the other end packets "drop out" of the Tor circuit into OC which
in turn forwards the packets to the local kernel.



Whats the problem know with Prop224?
For OC to work properly it needs to be able to convert .onion-ids to
IPv6 addresses back and forth.
This works well with the current 80-bit hashes but it does not work with
hashes greater than 80bits.


So what's the solution?
The solution is to use some kind of database to do lookups, i.e. find
the proper .onion-id given a specific IPv6 address.

Actually, it doesn't matter what kind of database this is but it should
obviously NOT break anonymity. Because of that Internet DNS may be
problematic although it would be very easy to implement.

IMO a better place would be the HS directory :)


Bernhard