際際滷

際際滷Share a Scribd company logo

Naming in content_oriented_architectures [repaired]

Download as PPTX, PDF
H
haroonrashidlone

This document summarizes a paper about naming in content-oriented architectures. It discusses two main naming types: self-certifying flat naming using cryptography, and user-friendly hierarchical naming. Key issues discussed are scalability, security, and flexibility. The document also covers how each naming type establishes security through integrity, confidentiality, provenance and availability. It compares the two approaches on usability, binding relationships, scalability through aggregation, and flexibility.

1 of 11
Download to read offline
Naming in Content-Oriented Architectures Paper by: Ali Ghodsi et al. Pressented by: Haroon Rashid
Naming Types Self certifying, flat naming (Cryptographic based). User friendly, hierarchical naming. Issues Scalability Security Flexibility
Scalability Issues identified with Self-certifying names. Not scalable as these are not hierarchical Need a third party for translation purpose (like DNS) Claims: Better scalability than hierarchical by using flexible aggregation ! Have better security than human readable names. Both naming architectures can be combined.
Network security components Integrity Confidentiality Provenance Availability
Entities for establishing security Real world Identity (RWI) principal for data. Name Used for fetching the data Provided by principal Public key Each principal associated with private/public key Used for authentication purposes
Bindings RWI Name: Helps in identifying the principal. RWI Public key: Only intended principal could claim to be the principal of data. Public key Name: Associating key helps in verifying the provenance of data. Bindings are transitive proving any two of them implies third one.
Bindings in Human readable, Hierarchical names Intrinsic binding:- RWI Name Extrinsic binding:- Name - key by using certificate authority (third party - PKI) Bindings in self-certifying names (P:L) Intrinsic binding (Name key):- Take hash of key at any node and check whether it hashes to P. Extrinsic binding:- RWI- key (external authority)
Comparison Human readable, Hierarchical (CCN) More useful. Remain unchanged as cryptographic algos evolve. Name - RWI binding not tight, e.g., acronym ICSI. Tiny URLs obliterate Name RWI binding Self-certifying, Flat (DONA) Usability - Difficult to remember such names Require careful engineering to retain names as algos. evolve.
Name Scalability Hierarchical names help scalability Reduce size of routing table Reduce update rate of routing table Flat Naming Common Assumption Aggregation impossible No hierarchy found but still supports greater flexibility* in aggregation. * Explicit aggregation is more flexible than inherent aggregation
Explicit aggregation Deepest match working ?? Fetch Terms: -Principal creates various fetch terms corresponding to different third party aggregates. - Like outsourcing of content dissemination. - Seems much like of CDN.
Naming and Flexibility Human friendly naming require PKI for binding keys to names. Require universal agreement on the root trust authority. self certifying naming require external authority for binding of keys to RWI.

More Related Content

Naming in content_oriented_architectures [repaired]

  • 1. Naming in Content-Oriented Architectures Paper by: Ali Ghodsi et al. Pressented by: Haroon Rashid
  • 2. Naming Types Self certifying, flat naming (Cryptographic based). User friendly, hierarchical naming. Issues Scalability Security Flexibility
  • 3. Scalability Issues identified with Self-certifying names. Not scalable as these are not hierarchical Need a third party for translation purpose (like DNS) Claims: Better scalability than hierarchical by using flexible aggregation ! Have better security than human readable names. Both naming architectures can be combined.
  • 5. Entities for establishing security Real world Identity (RWI) principal for data. Name Used for fetching the data Provided by principal Public key Each principal associated with private/public key Used for authentication purposes
  • 6. Bindings RWI Name: Helps in identifying the principal. RWI Public key: Only intended principal could claim to be the principal of data. Public key Name: Associating key helps in verifying the provenance of data. Bindings are transitive proving any two of them implies third one.
  • 7. Bindings in Human readable, Hierarchical names Intrinsic binding:- RWI Name Extrinsic binding:- Name - key by using certificate authority (third party - PKI) Bindings in self-certifying names (P:L) Intrinsic binding (Name key):- Take hash of key at any node and check whether it hashes to P. Extrinsic binding:- RWI- key (external authority)
  • 8. Comparison Human readable, Hierarchical (CCN) More useful. Remain unchanged as cryptographic algos evolve. Name - RWI binding not tight, e.g., acronym ICSI. Tiny URLs obliterate Name RWI binding Self-certifying, Flat (DONA) Usability - Difficult to remember such names Require careful engineering to retain names as algos. evolve.
  • 9. Name Scalability Hierarchical names help scalability Reduce size of routing table Reduce update rate of routing table Flat Naming Common Assumption Aggregation impossible No hierarchy found but still supports greater flexibility* in aggregation. * Explicit aggregation is more flexible than inherent aggregation
  • 10. Explicit aggregation Deepest match working ?? Fetch Terms: -Principal creates various fetch terms corresponding to different third party aggregates. - Like outsourcing of content dissemination. - Seems much like of CDN.
  • 11. Naming and Flexibility Human friendly naming require PKI for binding keys to names. Require universal agreement on the root trust authority. self certifying naming require external authority for binding of keys to RWI.