[Nix-dev] Google Summer of Code 2015

stewart mackenzie setori88 at gmail.com
Thu Feb 5 09:49:44 CET 2015


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)
* 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)
* 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 solves the above problems.

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.

Essentially the major problem NDN solves is building dissemination
into the protocol.

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.


On Thu, Feb 5, 2015 at 3:44 PM, Michael Raskin <7c6f434c at mail.ru> wrote:
>>No, NDN is so much more than solving the problem of self-signed certificates.
>
> If NDN considers existence of slef-signed certificates a problem to
> solve, nothing it does well would compensate it.
>
> NDN makes it very simple to break self-signed certificates; maybe even
> deliberately so.
>
> Also NDN means that if you have a high-latency link somewhere, you need
> not only the endpoints to have proper timeouts, but also all the routers
> in-between to support it.
>
>>This talk sums it up nicely: https://www.youtube.com/watch?v=oCZMoY3q2uM
>
>
>


More information about the nix-dev mailing list