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. 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.

4. Network security components
•Integrity
•Confidentiality
•Provenance
•Availability

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.