UCLA, Cisco and more join forces to replace TCP/IP • Hacker News Board

Re: UCLA, Cisco and more join forces to replace TCP/IP

#81

Post by j_burke » Sat, Sep 06, 2014, 6:57 AM UTC

bediger4000 wrote: post #59

shmerl wrote: post #29

I hope keeping it all patent free / disarmament patent style is a requirement for participation.

I note that patents/"Intellectual Property" wasn't mentioned in the article at all. I suspect, based on the participants mostly being corporations, that the whole thing will be covered by patents. I think TCP/IP as non-patented, slipped by the major corporations. A protocol anyone can implement, and where the "client" and "server" are pretty hard to tell apart, is disadvantageous to market encumbents, and to surveill…

The participants are actually mostly universities. IP is discussed on the project site:

http://named-data.net/project/ndn-copyright-and-patents/ http://named-data.net/consortium/

Re: UCLA, Cisco and more join forces to replace TCP/IP

#82

Post by j_burke » Sat, Sep 06, 2014, 7:00 AM UTC

tgflynn wrote: post #53

ivoras wrote: post #49

Nothing except efficiency is preventing us from using names as parts of network/subnet hierarchy instead of numbers, e.g. : steve.home.town.country instead of 192.168.5.6 (or the same thing on IPv6), and even efficiency could be improved by the smart use of hashing... BUT! The major problem I see here is that there simply are more numbers than words . In practice, especially at large companies, it will certainly with…

That's not what NDN is about. NDN assigns names (or addresses) to data contents, not physical machines/interfaces like IP does. So it's conceptually quite different from the way IP routing works. The issue you mention is already solved by DNS. This looks like a solution in search of a problem. NDN attempts to make content distribution more efficient through caching. Whether solving that problem justifies rewriting th…

While content distribution is a significant motivation, a fair amount of the current research is looking at benefits beyond caching: i.e., what do you get with web-style semantics at the lower layers, per-packet crypto, name--rather than host-based addressing, etc.

Re: UCLA, Cisco and more join forces to replace TCP/IP

#83

Post by j_burke » Sat, Sep 06, 2014, 7:03 AM UTC

allengeorge wrote: post #65

Isn't this identical in spirit to Content-Centric Networking (CCN) as espoused by Van Jacobsen? I distinctly remember watching his Google Tech Talk on the idea ( https://www.youtube.com/watch?v=oCZMoY3q2uM ) when I first joined AeroFS.

Yes - Van is involved in NDN: http://named-data.net/project/participants/

Re: UCLA, Cisco and more join forces to replace TCP/IP

#84

Post by takeda » Sun, Sep 07, 2014, 12:22 AM UTC

SudoNick wrote: post #79

takeda wrote: post #75

Earlier quoted context omitted.

The NDN was designed based on today's most common Internet use cases. If you think about it, most of the time we are requesting content from specific place, but we don't really care where the server is located, what address it has etc, all we care about is the content and whether it comes from intended (trusted) source. Assuming that the same name always references the same data, gives an edges, because now routers a…

Most of the time we do care about (not!) exposing information to third parties. This even applies to generally lower-importance scenarios such as watching YouTube and Netflix videos. ISPs are of special importance, because the exposures can be concentrated. We make use of end-to-end encryption with specific servers in order to reduce the information that ISPs (and others) acquire. How will we hide interest data from…

Oh this is not a big problem.

You simply encrypt the data, the protocol even has a support for marking encrypted data [1].

That said the NDN does not impose how you do it and it is left for the application.

Now if the data is only end-to-end you probably would do something similar to TLS. If the data supposed to be accessible by multiple users, then you encrypt it with generated key, and then encrypt the key using public keys of intended recipients.

[1] http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.html (Section 3.5.2.2.1. PayloadType)

Re: UCLA, Cisco and more join forces to replace TCP/IP

#85

Post by coldtea » Sun, Sep 07, 2014, 3:15 AM UTC

acdha wrote: post #54

noselasd wrote: post #47

Earlier quoted context omitted.

And when someone implements new code dealing with security, such bugs are not possible ?

He's going to write it, so it'll be better than everything in the past and unicorns will fly by when you use it. Hypothetical code is always better than the unpleasant kind we actually write…

I hope fighting that strawman you built was fun, but I really don't know where the BS snark came from.

I didn't say new code will be flawless. Just that OpenSSL code is bad and insecure.

>Hypothetical code is always better than the unpleasant kind we actually write…

Well written code is always better than the crap that OpenSSL was (crap as admitted by most of security experts and groups working with it).

People who cannot tell between code with inevitable bugs and flaws and crappy code that just welcomes them in, don't really belong in the profession.

Re: UCLA, Cisco and more join forces to replace TCP/IP

#86

Post by acdha » Mon, Sep 08, 2014, 1:46 PM UTC

coldtea wrote: post #85

acdha wrote: post #54

Earlier quoted context omitted.

He's going to write it, so it'll be better than everything in the past and unicorns will fly by when you use it. Hypothetical code is always better than the unpleasant kind we actually write…

I hope fighting that strawman you built was fun, but I really don't know where the BS snark came from. I didn't say new code will be flawless. Just that OpenSSL code is bad and insecure. > Hypothetical code is always better than the unpleasant kind we actually write… Well written code is always better than the crap that OpenSSL was (crap as admitted by most of security experts and groups working with it). People who…

> I hope fighting that strawman you built was fun, but I really don't know where the BS snark came from.

The BS snark which started it was your still-unsupported assertion that “SSL is a security joke”.

> Well written code is always better than the crap that OpenSSL was (crap as admitted by most of security experts and groups working with it).

It's easy to criticize OpenSSL and, well, every other SSL library which has had problems. It's a lot harder to replace it and actual security experts have thus far chosen to overhaul OpenSSL rather than trying to replace it from scratch. I trust the judgment of the OpenBSD and Google security teams over your assertion that it's so easy to replace.