Undernet IPv6 Interop [was: Enigmabox/cjdns]

[grarpamp]

Forwarded with permission.

----------
On 10/24/2013 02:35 PM, grarpamp wrote:
> On Thu, Oct 24, 2013 at 6:53 AM, Eugen Leitl <eugen at leitl.org> wrote:
>> ----- Forwarded message from Caleb James DeLisle <cjd at hyperboria.ca> -----
>
>> I'm not really worried about what the IETF has to say
>
> Nor am I really, even to the point of stealing an unused external
> IPv6/3 since it is unlikely all of them will ever be allocated. My
> thoughts are more about what I outlined in the last two paragraphs...
> that things like the userbase draw of existing applications, inclusive
> multihosting and participation in more than one net easily at the
> same time (whether general purpose IP transport, or specfic like
> file storage [1])... can and do matter. The simplest way I've seen
> yet that covers those areas is an internal IPv6 layer presented on
> the host's tunnel interfaces. So what are some means we can make
> to fit a world's population worth of users, out of much larger
> crypto keyspaces, into about 115 bits?
>
> [1] Imagine a link in a web page, file://<IPv6>/<internal_file_key>,
> where <IPv6> is just a point-to-point tunnel bound to a particular
> filestore like GNUnet, ed2k, tahoe, etc.
>
>> at some point I'll probably add an option to use IPv4 for cjdns too.
>> Applications won't even have to support IPv6 to support cjdns.
>
> Keeping in mind that people need to be clear when/what they are referring to:
> - external addressing, used by the host/net on the public internet (IPv6, IPv4)
> - internal addressing, the user facing overlay addresses (IPv6, onion, i2p, etc)
> - maplayer addressing, map between crypto widths to narrower internal addressing
>
> Why would anyone want to use IPv4 internally? It's only 32 bits,
> easy to generate/spoof a crypto based address collision. And only
> a handful of its tiny /8's (ie: 10/8, 16M users/nodes) could be
> used on a host's tunnel interface that would not conflict with
> external addressing. Further, every OS, and most applications users
> want to use, are already IPv6 enabled, such that using them with
> internal IPv6 addressing via the host's tunnel interface to that
> is not a problem.
>
>> When you do a DNS lookup for a site it will allocate an address
>> for that machine out of whatever block you choose.
>
> Please rephrase.
> What allocation method, from what address space (v6, v4), and for
> residence on the external or internal network? Via what interface?
> DNS lookup to external or internal DNS server? And for an internal
> or external site?


IPv4 in cjdns is actually really easy, you just need a mapping table
inside of the node. Say you put in your configuration that 11.0.0.0/8
is for mapping. Cjdns will assign 11.0.0.1/8 to your TUN device then
whenever you do a DNS lookup, it grabs the next number in the sequence
and maps that to the key which is returned by the lookup. It could
also map addresses to incoming connections from previously unseen keys
allowing you to be a server too.
It just breaks p2p stuff which shares IP addresses.

This same idea could be used to map any number of different networks
into a common IPv6 (or IPv4) address space.


> I do see FC00::/8 addresses returned from queries to external
> nameservers. Leaking that activity externally can be unwise, so if
> a DNS for internal addresses is needed it should be run internally.


It's on the todo list. Not because we're trying to keep secrets or
prevent web crawlers from firing syn packets off into ISP null routes
but because the public domain system is expensive and an SPOF.


>
>> As far as address generation speed, the address is a double-sha-512
>> of your public key so it's extremely fast.
>
> Ok, so a few seconds to generate 8 matching bits (into FC00::/8)?

On small hardware yes, on my laptop it feels instantanious.

>
>> Anything less than 128
>> bits (you're forced to collide the last 8 bits) would be dangerous.
>> I'm sure we could have decided to limit valid keys to a fixed 16
>> bits or maybe even 24 but 48 bits would be quite unreasonable to
>> expect of small devices.
>
> I think this is in reply to one of the possible means to fit within
> a compatible IPv6 bit width. I think Eugens' forwarding style may
> have lost me some context there :) Not sure where to place this or
> how to read it.
>
> We're used to disliking anything less than 128 bits for symmetric
> (streams, message encryption, etc). But for network ID's there's
> probably a reasonable case to be made for using somewhat less than
> that... you should use TLS, message encryption, fingerprints and
> other means over any network anyways, just in case something breaks.


The IPv6 address is effectively the key fingerprint because x509 is
a mistake the world should never make again and colliding an IPv6
gives you spoofing ability as well as MiTM.


>
> For reference, the five nets I referred to are:
>  cjdns, i2p (garlicat), tor (onioncat), anonet, phantom
> Maybe there's a GNUnet interface in the works but I've not seen it
> yet.


I'm going to sound like an asshole here, probably because I am.. but
every one of those systems with the exception of cjdns is heavily
geared toward anonymity, privacy, freedom and individualism. Cjdns is
designed to facilitate community and I've found the most divisive,
manipulative and egomaniacal people ever to grace the Hyperboria
community subscribed to just those values. At this point when I hear
TOR user, I think "oh shit another one" so while it's not really my
right to intentionally break valid use cases, I'm not feeling like
putting a lot of effort into making interop work.

Thanks,
Caleb

BTW: it looks like the IPv4 mapping idea I proposed might come sooner
than I thought because Apple seems to have broken IPv6 support in Mavericks
update.
----------