[Nix-dev] Google Summer of Code 2015

[Michael Raskin]

>The main problems NDN solves are:
>
>TCP is inherently a conversational point-to-point network. We now do
>content dissemination over a point-to-point network as a side effect.
>It doesn't work well in 3 ways:
>
>* 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…

>* extremely inefficient network when doing data dissemination (as the
>network can't see the data, only the pipes. If 1 million people ask
>for the same data you'll get 1 million pipe setups. The point-to-point
>network hates flooding protocols)

That part is true, but…

>* 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.

>In NDN you sign your own data, that is built into the protocol, in
>contrast to the problem of relying on a corruptible CA to sign your
>website certificate. When you mentioned the problem of self signing I
>assumed you meant in relation to trusting a CA to sign your website's
>cert.
>
>Regarding timeouts, yes you can have a staleness factor built into the
>protocol. Each node (being a nix installation is _also_ a NDN router
>of nix packages and other data)
>Data is copied wherever there is demand. A copy of the data is
>breadcrumb'ed in LRU buffers across the network as named data is
>pulled to demand. So network bandwidth is at a theoretical global
>minimum. This is a pull model, not a push model.

he problem with points is that NDN requires all intermediate routers to
cache your content for the entire time of round-trip.

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.

>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.