[Nix-dev] [***SPAM***] Re: Google Summer of Code 2015

[Michael Raskin]

>>>* you can't make a viable security model - secure pipes vs secure
>>>data. (spam still gets through, network is blind to the data)
>>
>> You cannot solve spam problem just by switching protocols without
>> breaking a ton of communication models…
>
>NDN is a TCP/IP overlay. Now on the receiving end: You only accept
>traffic based on the certs you have and are looking for.
>Secondly as it's a pull model, spammers cannot push their spam into you inbox.
>
>Yes, I argue, you can kill spam with a switch to a pulling named based protocol.

This is called "breaking many use cases for email". This means I cannot
write email on a blackboard in the beginning of a talk.

>>>* huge plumbing operation to map data names to data locations. ( thus
>>>depending on DNS and all the security issues that come with it -
>>>Maintaining a global network of unique identities is an expensive
>>>job.)
>>
>> NDN route search is quite expensive either from this or the previous
>> point of view.
>
>Flooding is dirt cheap in this NDN. You can bomb the hell out of it.

For name resolution you either need a lot of address conversion 
infrastructure or to flood everyone at some points.

>> The problem with points is that NDN requires all intermediate routers to
>> cache your content for the entire time of round-trip.
>
>Not a huge problem, buffers were introduced into telephony networks
>and folks declared heresy.
>The NDN buffer is a Least Recently Used buffer. Meh no big deal.

It is a big deal once your content request becomes LRU-forgotten before
the reply arrives.

>> So they are likely to a) break systems with slow endpoint links, because
>> unlike current model (where they relay packets without caring whether
>> they are in the same session) routers may have timeouts lower than
>> the round-trip time; and b) only transfer your content if your signature
>> matches the certified list.
>
>NDN is a TCP/IP overlay.
>
>Each node maintains it's own certified list. Yes I only want the data
>I requested to come to me.
>Not Spammer Sam's Spam.

Routers are likely to have their own certified list and only allow you
to see things they have in their trust system.

>>>What are we doing? Disseminating binary chunks over a point-to-point
>>>network. Hence Hydra is sitting at a point in this network and we all
>>>have trust. Whereas in reality over this type of point-to-point
>>>network there really is no security. So by default we trust the
>>>custodians of Hydra. What if those custodians could trust others and
>>>allow them to contribute to this build pool and we all trust that
>>>those binaries are safe. It's terribly hard to trust another if we use
>>>a point-to-point network and if we do it'll be complex to achieve.
>>>This can be negated by using NDN which has provenance built into the
>>>protocol unlike using raw TCP/IP.
>>>
>>>This approach is orders of magnitude simpler than using IPFS.io.
>>
>> It also requires a ton of storage on all the routers. And makes it much
>> easier to do _and_ easier to justify to filter some content.
>
>Immutability with temporal bindings requires a large storage system in
>many cases. But with an LRU it isn't a problem.
>Besides, each Nix node has a massive /nix/store which is in essence
>could be the NDN LRU buffer.
>No big deal. Also, storage is cheap! Bandwidth is expensive! Every
>node may adjust the size of their LRU buffer.

None of NDN benefits happen unless you actually route something via 
caching routers.

When you use /nix/store/ as cache, it is cheaper to do properly 
checksummed P2P over TCP/IP and not help a technology likely to make
Internet filtering cheaper.

>Indeed, one could completely refactor the /nix/store to be a LRU, that
>way applications that were installed but aren't used that much get
>wiped.
>Though if there is a need to execute it, it'll transparently go over
>the network and pull down the binary again. No need for
>nix-collect-garbage.

Now, collecting unreferenced old paths may be a good idea. Removing 
rarely-used still-referenced-from-profile paths is malicious.

Some links are slow; some rarely used things are important when they
are used.