Re: [tor-dev] Onioncat and Prop224

[grarpamp <grarpamp@xxxxxxxxx>]

On 4/30/16, str4d <str4d@xxxxxxxxxxx> wrote:
> On 27/04/16 22:31, grarpamp wrote:
>> 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 :)

Thanks str4d, I think I remember that one.

There''s certainly a difference between underlying cryptographic
addressing, and human "DNS style" naming. Onion addresses,
even at 16 char or 80 bit, were always beyond most human scope.
I'm not too concerned about human addressing since that can
always be a layer in userland (though not as strong as something
tracing back to the underlying crypto), of course if it comes along with
any side layer deemed necessary for getting the crypto addressing
working between nodes under IPv6, that's a good bonus.


>>> But the tor-onions mailing list is to discuss the technical details
>>> running onion services.

Fyi, I'm still waiting to hear back on the status of the onioncat list.


>> onioncat. It's a way to get non-TCP between TorHS onions, thus in
>> the thread "Hidden datagram service".
>>
>> I think there are a nontrivial number of users interested in, and
>> using, non-strictly-TCP transport over an IPv6 tunnel interface.
>> For example, look at users of CJDNS...
>>
>> For which we should try to continue a way, in v2, to do that over
>> anonymous overlay network Tor / I2P.
>>
>
> There is already some work on doing this in I2P:
>
> https://github.com/majestrate/i2p-tools/tree/master/i2tun
> https://github.com/majestrate/i2p-tools/tree/master/pyi2tun
>
> I2P also natively supports non-TCP protocols if that helps (only
> datagrams implemented thus far).

You mean just UDP? How would you move ICMP, GRE, raw IP/packets?
Do you have to implement each one? That seems more work
than implementing a generic data conduit, or an IPv6 conduit (as
a more specific, host stack oriented, interoperable form).
Though yes UDP would be the most useful for people after TCP.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev