Download Document

Naming in Content-Oriented
Architectures
1
Data publishing
RWI
select
produce
own
Data
Name
certify
Key
2
“Basic bindings”
The ICN paper argued that
RWI, Name, and Key
should be bound together
“If not, then it is impossible to
identify the principal of the object”
Name
RWI
“If not, then anyone could claim to
be the principal associated with
the data”
“If not, then the receiver doesn’t
know which public key to use to
verify the provenance of the data”
Key
3
Binding between RW and cyberspace
Real world
RWI
Who should take care of the bindings associated with RWI?
Network or users?
Cyberspace
Data
Name
Key
4
“NDN bindings” in the ICN
paper
RWI
The paper argued “The purpose of
human-readability is to establish an
intrinsic binding between the name
and the RWI”
Name
The paper argued “The binding
(between the name and key) can be
established using an external
authority.”
Key
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
Data
Name
certify
Key
6
SCN bindings
RWI
The paper said “the binding
between the RWI and key must be
established by an external authority”
“Name”
Key Label
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”
Key
7
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 selfcertifying names
• Upon receiving a request
for A.B.C, look up A, B,
and C in routing table
• Take the deepest match
Router 1
A.B.C
name
A
B
F
out-if
1
2
3
✔
out-if
1
3
4
✔
Router 2
A.B.C
name
B
C
F
11
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
• The goals of NDN1 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
16