architectures”web.eecs.umich.edu/~sugih/courses/eecs589/f13/15-CCN.pdf · On name-based inter-domain routing Content Centric Internet Drew Springall October 3, 2013 Drew Springall

Naming in content-oriented architecturesOn name-based inter-domain routing

Content Centric Internet

Drew Springall

October 3, 2013

Drew Springall Content Centric Internet


Papers

Ghodsi et al., ”Naming in Content-Oriented Architectures,”Proc. of the ACM SIGCOMM Workshop on ICN ’11, pp. 1-6,2011.

Rajahalme et al., ”On Name-Based Inter-Domain Routing,”Computer Networks, 55(4):975-986, Mar. 2011



“Naming in content-orientedarchitectures” [1]



Domain Naming Service (DNS)

DNS Query

DNS Response

Figure: [2]



Main Points

Only concerned with exploring flat, self-certifying vs.hierarchical, human-readable names

Compare with regard to Security, Scalability, and Flexibility

Authors claim that self-certifying names are better choicebecause they are :

Better at protecting AvailabilityMore Scalable due to Flexible aggregation



Security Requirements

Confidentiality - content can’t be accessed by unauthorizedpeople

Integrity - content has not been changed

Availability - content can be accessed by authorized people

Provenance - content can be linked to a specific publisher

How to secure?



[3]



With Encryption

Secured easily with encryption :

Confidentiality - can’t decrypt without key

Integrity - can’t change without key

Availability - ?????

Provenance - key control

Availability is responsibility of the network

PKI requires trusting the key bindings through external source



Basic Bindings

Bound objects :

Real-World Identity (RWI) - the person publishing content

Name - the identifier of the content

Public Key - Pk of Pk-Sk pair used to handle securityrequirements

* transitive property allows two bindings to imply the third



Labels

• Pk = Public Key • Sk = Private/Secret Key• h(x) = cryptographic hash of x

Human-readable = headlines.CNN.comEasy to remember and useRWI-Name binding is intuitive (but not concrete)Pk-Name binding is abstractedRWI-Pk binding is abstracted

Self-certifying = h(Pk):Name(e.g. d131dd02c5e6eec4:SnowdenFiles)

Hard to remember and useRWI-Name binding is concretePk-Name binding is concreteRWI-Pk binding is abstracted



Availability

Network responsible for getting bits physically there on timeCan use standard methods (CRC/parity/DoS Defenses/. . . )

Network responsible for ensuring the content being transferedis truthful

Can be validated when publishedRequires external Pk-Name binding mechanism for

human-readable names

Can be validated at fetch timeRequires Pk-Name binding even for human-readable names



Name Scalability for Self-Certifying

A.B.C.D where A, B, C, and D are flat, unique names :

Hierarchical names allow searching by “longest-prefix-match”due to lack of fragment uniqueness

“Aggregation Invariant” allows flat names to be searched“deepest match”

Can allow mapping of human-readable names to self-certifying



Flexibility

Human-readable names don’t have concrete Pk-RWI orRWI-Name bindings

Would require external trust

Self-certifying names are able to bind Pk-Name concretelyStill require external trust for Pk-RWI binding



Review

What did I think?



Pretty Good

StrengthsUse of cascading securityVery good explanation of bindings and analysis of what eachrequires

WeaknessesObvious misunderstanding of PKI

Should be using Pk signing not hashing

Completely missed Bittorent’s solution to false data being sent



Questions?Comments?Concerns?

Rude/Crude/Obnoxious Remarks?



“On name-based inter-domainrouting” [4]



Main Points

Propose a design for name-based routing architecture

Propose a routing sequence for such an architecture

Experimental Setup

Experimental Results



Architecture

ObjectivesFlat, self-certifyingnamespace

Enterprise domains asendpoints only

Formed by only willingparticipants

Locality is preserved whenpossible

Unpopular objects notdistributed globally

StructureHierarchy

ClientsRendezvous NodesRendezvous NetworksRendezvous ServiceProvidersInterconnection Overlay

Canonical Chord DHToverlay[5]

Incrementally deployable

Separation of namespaceresponsibility





Proposed Routing Sequence

Forward the information up the overlay tree such that a destinationis attempted to be found in the order of :

1 Same domain

2 Local rendezvous network

3 Local overlay branch

4 Top-tier of the overlay

Requests continue until an object pointer is found. Erroneousroutings are sent back through the path to inform of stale data.



Setup

Use CAIDA network relationship set to form network[6]Supplement known missing data with additional links

Use combination of business, web hosting, and residentialaccess tra�c

Test five di↵erent architecture structuresOverlay, rendezvous networks, local hierarchyRendezvous networks, local hierarchyOverlay, local heirachyOverlay, rendezvous networksOverlay only



Latency

Without the Canon overlay,latency decreased due to thefewer hops required to traversrendezvous network boundaries.

Negative latencies caused by“shortcuts to otherwisepolicy-constrained end-to-endpaths”



Stretch

Stretch = path in proposed architecture

path in normal architecture



Hop Count



Review

What did I think?



[7]



Layout

1 Motivation

2 Introduction

3 Analysis

4 Experimental Setup

5 Motivation (part 2)

6 Proposed Architecture

7 Experimental Setup (part 2)

8 Proposed Architecture (part 2)

9 Results/Analysis

10 Experimental Setup (part 3)

11 Results/Analysis (part 2)

12 Related Work

13 Conclusion

No Background Section



Naming Requirement

Obviously hierarchicalstructure

No requirement for humanreadable names

Would make routingextremely easy withaggregation described inprevious paper



Other Weaknesses

Removes all network, routing, and advertisement overheadfrom model when testing

Overly complicated word choice

Mnemonic names are URLs by a di↵erent name

Security issue in trusting links implicitly

Invented 90% of their dataset

Blatantly recreating AOL Keywords

Users can’t agree on a CA for security, but can agree on amnemonic issuer?

Run on sentences

Tra�c explicitly wraps through the Overlay

Invalidating cached entries based on returned searches

Evil nodes can cause extreme replication of data

Fail to su�ciently explain why there are negative latencies



References I

A. Ghodsi, T. Koponen, J. Rajahalme, P. Sarolahti, andS. Shenker, “Naming in content-oriented architectures,” inProceedings of the ACM SIGCOMM workshop onInformation-centric networking, ser. ICN ’11. New York, NY,USA: ACM, 2011, pp. 1–6. [Online]. Available:http://doi.acm.org/10.1145/2018584.2018586

[Online]. Available:https://upload.wikimedia.org/wikibooks/en/6/68/Iterative.jpg

[Online]. Available: http://memedad.com/meme/45984



References II

K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis,C. Tsilopoulos, G. Xylomenos, and G. C. Polyzos, “Oninter-domain name resolution for information-centricnetworks,” in Proceedings of the 11th international IFIP TC 6conference on Networking - Volume Part I, ser. IFIP’12.Berlin, Heidelberg: Springer-Verlag, 2012, pp. 13–26. [Online].Available: http://dx.doi.org/10.1007/978-3-642-30045-5 2

P. Ganesan, K. Gummadi, and H. Garcia-Molina, “Canon in gmajor: designing dhts with hierarchical structure,” inDistributed Computing Systems, 2004. Proceedings. 24thInternational Conference on, 2004, pp. 263–272.

[Online]. Available:http://www.caida.org/data/active/as-relationships/



References III

[Online]. Available: http://makeameme.org/meme/-s6w88w


architectures”web.eecs.umich.edu/~sugih/courses/eecs589/f13/15-CCN.pdf · On name-based inter-domain routing Content Centric Internet Drew Springall October 3, 2013 Drew Springall

Documents