Naming in Content-Oriented Architectures 1

select produce Data publishing RWINameKey Data own certify 2

“If not, then the receiver doesn’t know which public key to use to verify the provenance of the data” “If not, then it is impossible to identify the principal of the object” “If not, then anyone could claim to be the principal associated with the data” “Basic bindings” RWINameKey 3 The ICN paper argued that RWI, Name, and Key should be bound together

Binding between RW and cyberspace 4 RWINameKey Data Real world Cyberspace Who should take care of the bindings associated with RWI? Network or users?

The paper argued “The purpose of human-readability is to establish an intrinsic binding between the name and the RWI” The paper argued “The binding (between the name and key) can be established using an external authority.” “NDN bindings” in the ICN paper RWINameKey 5

The true story about NDN security Security of NDN does not rely on human-readability –human-readability just provides contexts for consumers to understand and remember names NDN secure the binding between name and data –decision on which key is legitimate to certify the binding is left to consumers –consumers define their own trust management policies –the key can be derived from consumers’ own policies 6 NameKey Data certify

The paper argued that “The use of cryptographic hash … provides the binding between the name and the key, enabling the receiver to check the key” The paper said “the binding between the RWI and key must be established by an external authority” SCN bindings RWIKey 7 Label “Name”

Unresolved security issues in SCN It is more difficult to make SCN name correct –SCN name consist of two parts: producers’ key and data label. –both parts must be correct –NDN name is data name only, no requirement on producer’s key The ICN paper suggested several methods of getting the right key –search engine based trust –social network based trust –the ICN paper did not elaborate how to achieve the goal using these methods 8

DoS In content-oriented network, DoS means “consumer cannot get the requested data” The ICN paper argued that –DoS can be prevented if routers can reject false data –“content-oriented routing must be done on a name-key basis, not just on the name” –“this makes the key an essential part of the name” 9

Different views SCN trusts the network as a whole to return the correct data –in fact, given a name, network may not always return the correct data –consumer has no choice when receiving the false data NDN assumes it is possible to receive false data from the network –intelligent forwarding is used to avoid “bad” routers or hosts in the network –when receiving false data, consumer can notify routers to try some other paths 10

Scalability of SCN routing In order to fetch data C, concatenation of the form A.B.C is used A, B, and C are all self- certifying names Upon receiving a request for A.B.C, look up A, B, and C in routing table Take the deepest match 11 A B F nameout-if Router 1 ✔ B C F nameout-if Router 2 ✔ A.B.C

back to hierarchical name Concatenation in the ICN paper is actually hierarchical name –"The semantics of such concatenations (A.B.C) are that when following routing entries for A, you will eventually find one for B; and that when following routing entries for B, you will eventually find an entry for C.” in Section 3.1 The only difference is the component of a concatenation is flat name The ICN paper also admitted that the label part in SCN name could also be hierarchical –“This hybrid choice merely requires that the labels in the P:L format for self-certifying names be human readable and hierarchical.” in Section 2.2 Denial of Service 12

Flexibility of SCN The ICN paper was focused on the flexibility of trust model The paper argued that NDN has to rely on PKI, because –network must be able to verify data –without key as a part of name, decentralized trust is impossible 13

Flexibility is not just about trust model NDN is more flexible than SCN in trust model –NDN, from very beginning, allows decentralized trust consumers decide if the signing key can be trusted –given a binding between name and data NDN allows multiple signers SCN allows only one signer, which is bound to the name NDN is more flexible than SCN in naming –NDN does not restrict the format of names –SCN name can be represented as NDN name two-component NDN name: producer’s key and data name concatenation in SCN is also NDN name as well –several pairs of producers’ key and data name –NDN name cannot be represented as SCN name SCN name requires key which does not exist in NDN name 14

General process of data fetching NDN –given a data name –send an interest to network –get the data with signature and signer info –consumer determines whether the signer can be trusted –if so, accept the data –if not, notify router to try some other paths SCN –given a data label –consumer determines who is the producer –consumer gets producer’s key –construct a SCN name Hash(key) + label –send request –assume returned data is always correct 15

NDN vs. SCN 16 The goals of NDN 1 are –security: NDN is as secure as SCN NDN allows consumers to decide which key can be trusted NDN use intelligent forwarding to prevent against DoS –usability: NDN name is more useful Human-readable name is easier to use than flat name NDN name stays with data, while SCN name has to changes due to routine key replacement –flexibility: NDN is more flexible than SCN in general More flexible trust model More flexible naming mechanism The ICN paper also mentioned scalability –SCN resolved back to hierarchical name which has been used by NDN 1. Diana Smetters and Van Jacobson, “Securing Network Content”, NDN TR