"Interface" sure. But the dangers of replacing actual /addresses/ with things which are not is sufficiently well understood that even Van Jacobson ought to know about 'em, right? :-) On September 5, 2014 10:27:18 AM EDT, Paul Ferguson <fergdawgster@mykolab.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 9/5/2014 7:16 AM, Jay Ashworth wrote:

...

How many Youtube subject tags will fit in *your* routers' TCAM?

http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-conso...

...

[ Can someone convince me this isn't the biggest troll in the history of the internet? Cause it sounds like shoehorning DNS /and Google/ into IP in place of, y'know, IP addresses. ]

I didn't read it that way exactly, especially in light of this not in the Wikipedia article:

"Application-layer designs have also been proposed for deploying a content-centric interface. This has benefits such as easier deployment, backwards compatibility and more flexible delivery support."

https://en.wikipedia.org/wiki/Named_data_networking

It's an interesting concept, but it ain't gonna replace TCP/IP, DNS, or IP addresses anytime soon. :-)

- - ferg

- -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQJyEYACgkQKJasdVTchbIF0QD9FFwhgIKz7ssn9olaQHhIO6rO 8JzN5RZoF1itLe4LSgEBANvgyc8qbZp5QhsTQBLxpPpoLF0JVLsgzbEs3xCqgQ76 =kUKE -----END PGP SIGNATURE-----

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

On 09/05/2014 08:40 AM, Paul Ferguson wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 9/5/2014 7:35 AM, Jay Ashworth wrote:

...

"Interface" sure.

But the dangers of replacing actual /addresses/ with things which are not is sufficiently well understood that even Van Jacobson ought to know about 'em, right? :-)

Compare & contrast: There is still large-scale resistance (for lack of a better term) to IPv6 deployment, so what chance does deployment of Named Data-Networking stand? :-)

- - ferg

This idea needs more simmer time. https://en.wikipedia.org/wiki/Named_data_networking " Juno also introduces the concept of a delivery-centric interface, which extends the traditional content-centric interface to allow applications to stipulate multiple diverse delivery requirements that place certain constraints on how the content should be provided. For instance, these constraints can deal with such things as performance, resilience, security, monetary cost and anonymity." Almost sounds like the perfect protocol to allow the combination Internet/content provider to keep all content coming from where they want the content to come from instead of the freedom to choose where the content comes from. --John Schiel

...

On September 5, 2014 10:27:18 AM EDT, Paul Ferguson <fergdawgster@mykolab.com> wrote:

On 9/5/2014 7:16 AM, Jay Ashworth wrote:

How many Youtube subject tags will fit in *your* routers' TCAM?

http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-conso...

[ Can someone convince me this isn't the biggest troll in the history of the internet? Cause it sounds like shoehorning DNS /and Google/ into IP in place of, y'know, IP addresses. ]

I didn't read it that way exactly, especially in light of this not in the Wikipedia article:

"Application-layer designs have also been proposed for deploying a content-centric interface. This has benefits such as easier deployment, backwards compatibility and more flexible delivery support."

https://en.wikipedia.org/wiki/Named_data_networking

It's an interesting concept, but it ain't gonna replace TCP/IP, DNS, or IP addresses anytime soon. :-)

- ferg

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQJy0gACgkQKJasdVTchbIVGQEAmPM5XTV9er8vtivwsPncz8x4 rDxyKiXDvD08CeqRN/cBANKT4Da86IryizcPp7UTknguI6N3yrAdBYYhmzVInZH8 =wVf9 -----END PGP SIGNATURE-----

...

How many Youtube subject tags will fit in *your* routers' TCAM?

http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch -consortium-to-replace-tcpip

[ Can someone convince me this isn't the biggest troll in the history of the internet? Cause it sounds like shoehorning DNS /and Google/ into IP in place of, y'know, IP addresses. ]

I didn't read it that way exactly, especially in light of this not in the Wikipedia article:

"Application-layer designs have also been proposed for deploying a content-centric interface. This has benefits such as easier deployment, backwards compatibility >and more flexible delivery support."

https://en.wikipedia.org/wiki/Named_data_networking

It's an interesting concept, but it ain't gonna replace TCP/IP, DNS, or IP addresses anytime soon. :-)

- - ferg

Given how long the process has been to go from IPv4 to IPv6, I would imagine something like this taking much longer to take root and spread out to the masses. It is a curious concept though and the papers written on the consortium site may be work a quick read. -gary _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ Please make note of our new e-mail domain name: TEAMHGS.COM. Request you to update your address book accordingly. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Hinduja Global Solutions or postmaster@teamhgs.com immediately and destroy all copies of this message and any attachments. 9284f6a0-bf16-11e3-b1b6-0800200c9a66

Interesting, here are my speaking notes from a talk I gave at Hackerspace/SG in June 2011. Slightly different but in a similar spirit depending on your sense of "similar": THE END OF DNS A Quick History The internet uses host names but routing is done based on numeric IP addresses usually. For example world.std.com is 192.74.137.5 in dotted notation or 0xC04A8905 hex or 1100000001001010100010010000000101 binary or 3,226,110,213. world.std.com can be looked at as: w o r l d . s t d . c o m 073557 071154 062056 071564 062056 061557 066400 So, we need to go from the host name to the ip address and back reliably. Originally we used a hosttable which was simply a text file, on unix-like systems you see a remnant of it with entries like 127.0.0.1 localhost 192.74.137.5 world.std.com world with other information spread across /etc/nets and /etc/gateways, a snippet of the distributed format from RFC810 is: NET : 18.0.0.0 : LCSNET : GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW : HOST : 10.0.0.73 : SRI-NIC,NIC : FOONLY-F3 : TENEX : NCP/TELNET,NCP/FTP, TCP/TELNET, TCP/FTP : HOST: 10.2.0.11 : SU-TIP,FELT-TIP ::: This was downloaded from a single host, often at midnight, and there was a unix program (hosttable) to reformat the information for Unix. Yes, every host on the internet downloaded a common file, often every night. This wouldn't scale well so Paul Mockapetris devised "DNS" or Domain Naming Service. The idea is very simple, each site would be responsible for their own domain and to respond to simple remote requests for name to ip address mappings or back again. There would be a root, or multiple roots, which would respond to requests to locate who should be asked about a domain, for example if you want to know the ip address for world.std.com the conversation goes roughly: (To Root Server): Where is the COM server? (From Root Server): SOMEHOST (TO SOMEHOST): Where is the STD.COM server? (From SOMEHOST): 192.137.74.112 (TO 192.74.137.112): WHAT IS WORLD.STD.COM's IP ADDRESS (A RECORD)? (FROM 192.74.137.112): 192.74.137.5 It's amazing. to me, that it works let alone so quickly! But let's examine this, WHY do this mapping? 1. Computationally / Memory efficient 2. Sometimes IP changes, host name can be more stable. One reason to change IP is change of ISP, or LAN re-organization. 3. DNS Tricks! load balancing (e.g., round-robin), failover, content caching and distribution. 4. Multiple interfaces 5. Aliases We also overload some other functions on DNS such as who is this host's mail server or their SPF information. But let's stick to host to ip address mapping. THE BIG IDEA: Why not just use the host names as ip addresses? They're integers. In IPv6 they're rather long integers, 16 bytes. Looking thru hundreds of millions of web server log records I found host names to be about 32 bytes long, including dots. So sending the host name as the ip address is not an enormous expansion over current plans for IPv6, about double on average though variable length must be accomdated for long host names, up to 1K or thereabouts. Routing by ip addresses is really very simple: A router looks at some number of bits of an IP address, the "network" portion, and either knows where to hand this packet next, either another router or the actual host and we're done, or only knows that any network which isn't in its table needs to be handed to a "default" router neighbor and with luck the packet will eventually find a router which knows what to do with the packet. There might use varying number of bits to determine the best router to send a packet to next. At the "center" there are these routers which have NO default, they either know how to get your packet on its way or it has no route and is discarded. Really very simple, all the complexity is in keeping the information in each router current. This turns out to be not only an information distribution problem but also an information distribution STABILITY problem. But it's not our problem today. All we need concern ourself with is that there is a host name to ip addr mapping and these ip addresses are used in routing packets, that's the point. But why not just use the host name and skip the mapping? FQDNs are hierarchical, we can pick them apart and start routing a packet looking to go to world.std.com by routing to (or towards) a COM router, then a STD.COM router, and finally hand it off to WORLD.STD.COM. No doubt the devil is in the details, but tonight we're interested in whether it's worthwhile working out those details. Are there fatal flaws? One complaint might be computational complexity. Integers are easy to put into tables and use as indexes. Most real routers even have specially built memory to speed this up. Then again the 70s are over, the 80s are over, the 90s are over, the 2000s are over, computers are fast and getting faster and parallelism (such as multiple cores and threads) is commodity as are relatively large memories. If the average host name is about 32 characters and there are about a billion hosts then it takes around 32GB to hold all that information, maybe twice that with table overhead, 64GB. I can buy 64GB flash drives for around $100! They're too slow but I hope you get my point. And, besides, you only need to hold each network portion once in a router's memory, not for every host: COM THEWORLD 192.74.137.0 SHELL01 71 DNS 112 that's simple. To search the table the router could use a perfect hash function or as close to that as we really need. It would probably be better if we all agreed on one or a few hash functions but it's not necessary, it's only used inside a router, but it might make debugging easier. Bazinga! No DNS! But what about our list of uses of host to ip mappings? 1. Computationally / Memory efficient Who cares? 2. IP changes? Build it into ICMP and BGP infrastructure, that's a routing problem. We already have another system, ARP, which deals with similar problems to map IP to MAC addresses. 3. DNS Tricks! Trix are for kids. But, again, a routing problem. 4. Multiple interfaces Same sort of problem, mostly a last hop problem. 5. Aliases Still a last hop problem What are the problems? What do we gain? We get rid of this huge, noisy, complex infrastructure. We still need registries and registrars because we still need to file who "owns" a host name. But we can get rid of the entire RIR structure, the five regional organizations which hand out IP block, usually for $1000 or more per year depending on the number of bits in the network part (less is more expensive.) Well, they could still coordinate some routing functions, ASNs, etc. No DNS, no DNS attacks! To me this seems more secure tho that's a dangerous conjecture to make. But we have removed a rather public, distributed target and put most of the function in the routing infrastructure directly which tends to be more secure. For example, you don't accept routing updates from anyone, only trusted hosts. And in the near future we can expect even that to be "signed". Speaking of signed, no DNNSSEC! DNSSEC is a fairly simple concept, sign DNS information exchanges using public key cryptography, with a rather complex operational overhead such as key updates and revocations. Gone! I've discussed this on very technical (private) mailing lists with the sort of people who built the MSN infrastructure, Morgan-Stanley (no more than 100msecs downtime PER YEAR!), Google, Vonage, etc. Worst complaint: We're so accustomed to thinking in terms of DNS that there must be SOMETHING wrong with your idea!! A few thought it was great and made reference to other discussions over the years which were somewhat similar tho not quite as sweeping. SO WHAT IS WRONG? -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

Barry Shein wrote:

The idea is very simple, each site would be responsible for their own domain and to respond to simple remote requests for name to ip address mappings or back again.

Wrong. DNS is not that simple. Domains and sites have, in general, independent topology that sites can not be responsible for domains. Perhaps, your misunderstanding is commonly shared by those who believe in NDN, though they might think there are negligible number of exceptions. Then, data, mostly, could be routed based on name hierarchy, which scales well. The reality, however, is that exceptions are everywhere and we need something like DNS to translate names into something scalably routable, that is, hierarchical addresses. Masataka Ohta

Barry Shein wrote:

Understand these were speaking notes and it was safe to assume the audience basically understood DNS so it wasn't my intention to give an exhaustive introduction to how DNS works.

Surprisingly many people who basically understand DNS have the same misunderstanding as you, which is why some people believe in NDN.

There also seems to be some splitting of hairs over the meaning of "site" in your response. That is, some sort of physical boundary vs an authoritative boundary.

Then, "site" based FQDN can not be used for scalable routing.

At any rate my proposal doesn't eliminate hierarchical addresses,

See above.

One could use the FQDNs themselves as hierarchical addresses at least as an external representation.

You are trying to define something not usable for scalable routing a hierarchical address, which is as bad as your attempt to distort the definition of "site". Masataka Ohta

As far as I understand, NDN's basic premise is to install "names" into the network layer. I don't think they (the NDN inventors) consider it as a new "app" at this point, even tough eventually it may merely stay as a new app. I think the final thing that will determine the success of NDN is whether or not pushing names into the network layer rather than handling it at the app layer is going to return significant enough benefits. On the positive side, we will get rid of name -> address -> name mapping we are doing with DNS, we will enjoy content caching in routers themselves without relying on content servers to do it for us, and the story of upgrading to IPv6 will be over. :) On the negative side, we will have to deal with a whole new set of security and privacy issues (I can see a new wave of funding for cyber-security folks), we will need to revamp our routers (arguably which seems to attract Cisco so far) to handle names rather than IP addresses, and most importantly re-educate our practitioners to configure these "revamped" routers! The key question is that do we really need to push the names into the network layer? I personally don't see this will happen, particularly as a replacement to TCP/IP as was laid down in the slashdot article. The best bet, IMHO, for NDN is to establish software-based NDN routers that maintain content tagged with names. One way to imagine I guess is to consider each router as a NAT box for this. I just can't see it replacing IP-based forwarding. We all wish things were so easy to change, but simply they are not. Best, -Murat On Sep 5, 2014, at 11:51 AM, Field, Brian <Brian_Field@cable.comcast.com> wrote:

Here¹s my $0.02. I¹m only going to touch on a small part of what I understand NDN to be‹ namely making caching a first class citizen of the network. When you think about the types of traffic currently carried over our collective networks, there might be value if the network eco system more natively supported caching.

Van¹s first paper proposing this NDN concept (afaik) was in 2009.

If we were to get into the ³way-back² machine to say 2003, when peer-2-peer was a big app, one might have then decided that we really need to make ³peer-2-peer² a first class citizen of the network. In fact the IETF tried [at some level] to do this with the DECADE WG. The app space evolved, p2p is no longer as prevalent, and DECADE saw/got little traction.

In 1998, we might have been thinking about making NNTP a first class citizen of the network.

Maybe we need to think about making *software* [instead of a specific service] a first class citizen of the network. What do I mean by this?

If software were a first class citizen of our networks in 2003, we might have hopped onto our routers and done a ³yum install decade²‹ which would install software that would make the network eco system more efficient at supporting p2p traffic.

Today, on our network eco system we might do a ³yum uninstall decade² and then do a ³yum install caching²‹ which might embed caching functionality into our routing eco system‹ hopefully making the delivery of cacheable content more efficient.

In N years, when there is yet another new app pushing the network eco system, we might then be doing a ³yum uninstall caching² and instead doing a ³yum install new-app² which would make the network eco system more efficient at supporting this new-app.

Brian

On 9/5/14, 8:16 AM, "Jay Ashworth" <jra@baylink.com> wrote:

...

How many Youtube subject tags will fit in *your* routers' TCAM?

http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-con sortium-to-replace-tcpip

[ Can someone convince me this isn't the biggest troll in the history of the internet? Cause it sounds like shoehorning DNS /and Google/ into IP in place of, y'know, IP addresses. ]

Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

======================================== Murat Yuksel Associate Professor Graduate Director Department of Computer Science and Engineering University of Nevada - Reno 1664 N. Virginia Street, MS 171, Reno, NV 89557. Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877 E-mail: yuksem@cse.unr.edu Web: http://www.cse.unr.edu/~yuksem ========================================

On Fri, 05 Sep 2014 12:38:13 -0700, Paul Ferguson said:

The principle questions still stand unanswered:

What is the motivation for this? What do you gain? Does it create some large architectural and performance in efficiency?

How often do the copyright owners on content give a flying fig in a rolling donut about efficiency if it interferes with being able to control who accesses the content, and how? Look at the legislative history of attempts to fix the anti-circumvention clause of the DMCA so it's not illegal to do technical tricks to access content you have a legal right to access. That should tell you all you need to know about the motivation for this....

On Fri, Sep 5, 2014 at 3:27 PM, Murat Yuksel <yuksem@cse.unr.edu> wrote:

As far as I understand, NDN's basic premise is to install "names" into the network layer.

Hi Murat, If they think names belong at layer 4 instead of layer 7 I can offer a couple insights on how this might be used to make layer 3 cheaper and more effective. If they think names belong at layer 3 everyone in this forum can rattle off a dozen reasons why that's totally wacko. On Fri, Sep 5, 2014 at 2:51 PM, Field, Brian <Brian_Field@cable.comcast.com> wrote:

I'm only going to touch on a small part of what I understand NDN to be‹ namely making caching a first class citizen of the network.

Anycast can allow a supporting client to find the nearest device of type X. And it can allow the local device of type X to find the nearest regional device of type X. Making caching a first class network element is positively needless. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> Can I solve your unusual networking challenges?

----- Original Message -----

From: "Sander Steffann" <sander@steffann.nl>

...

How many Youtube subject tags will fit in *your* routers' TCAM?

http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-conso...

[ Can someone convince me this isn't the biggest troll in the history of the internet? Cause it sounds like shoehorning DNS /and Google/ into IP in place of, y'know, IP addresses. ]

Well, you don't need addresses for clients, just for content... From the architecture page at http://named-data.net/project/archoverview/:

"Note that neither Interest nor Data packets carry any host or interface addresses (such as IP addresses); Interest packets are routed towards data producers based on the names carried in the Interest packets, and Data packets are returned based on the state information set up by the Interests at each router hop."

So it's basically suggesting a NAT-like table in every single router. And we all know how well NAT boxes scale...

Well, as I suggested, I didn't think it was nearly that easy to do. It sounds to me like they want to put *Google* in every router. Cause no one who posits this stuff has, apparently, ever had to do network diagnosis. You put too much distributed state in the network and it comes apart. We're nearly there now with IPv4. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274