shortest path between the targeted set of clients and that
server. CCN content can be supplied by anything that
has a copy and every CCN node can use any and all of its
interfaces simultaneously to locate and retrieve a copy.
Thus hiding content is exponentially more difficult for the
attacker. It must establish a filtering perimeter around its
targets that covers all paths to all possible copies of the consent. Any copy that makes it through the perimeter immediately becomes a new source that will virally propagate the
content to all interested clients.
Dro wning (DDo S) attacks can be mounted against sources
of CCN content but are substantially more difficult than
they are with TCP/IP. The flow balance between Interest
and Data prevents any sort of Data flooding, so attackers
must attack via Interest packets. Say an attacker marshals a horde of zombies to simultaneously generate interests in some ContentName. If they all use the same name,
the Interests will be aggregated (at most one pending
Interest in a name is ever forwarded over any link) and no
flood will result. So they must all use different names under
the targeted prefix. If the different names refer to actual
ContentObjects, those objects will be cached everywhere
along the paths from the content source(s) to the zombies;
thus the flood near the source will quickly clear as Interests
are satisfied by downstream cached copies of the Data.i
If the zombie’s names are randomly generated then their
Interests will never be satisfied by a matching Data and
will time out. Thus every intermediate node learns that many
bogus Interests are being generated for the targeted prefix.
Nodes can decide to temporarily rate limit such Interests
(similar to the push-back strategy used against TCP/IP DDoS)
or simply prioritize them lower than Interests that are
resulting in Data responses.j In either case the effect of the
attack on legitimate traffic is minimized.
4. 5. Policy controls
CCN also provides tools that allow an organization to
exercise control over where their content will travel.
Routers belonging to an organization or service provider
can enforce policy-based routing, where content forwarding policy is associated with content name and signer.
For example, PARC might have a “content firewall” that
only allows Interests from the Internet to be satisfied
if they are requesting content under the / parc.com/public
namespace. An organization could also publish its policies
about what keys can sign content under a particular name
prefix (e.g., PARC could require that all content in the /
parc.com namespace be signed by a key certified by a /parc.
com root key), and have their content routers automatically
drop content that does not meet those requirements, without asking those routers to understand the semantics of
the names or organizations involved. Finally, Interests
i This does result in a distributed cache poisoning attack that must be
addressed in the CCN node’s cache replacement policy.
j A CCN content router has a limit on the number of pending Interests
it will allow on any link (generally related to the bandwidth × delay product
of that link). The router can choose if it wants to hold or discard arriving
Interests over the limit and how it selects Interests up to the limit.
could in certain cases be digitally signed, enabling policy
routing to limit what namespaces or how often particular
signers may query.
In this section we describe and evaluate the performance
of our prototype CCN implementation. Our current implementation encodes packets in the ccnb compact binary
XML representation using dictionary-based tag compression. Our CCN forwarder, ccnd, is implemented in C as a
userspace daemon. Interest and Data packets are encapsulated in UDP for forwarding over existing networks via
broadcast, multicast, or unicast.
Most of the mechanics of using CCN (ccnd communication, key management, signing, basic encryption and trust
management) are embodied in a CCN library. This library,
implemented in Java and C, encapsulates common conventions for names and data such as encoding segmentation and
versioning in names and representing information about
keys for encryption and trust management. These conventions are organized into profiles representing application-specific protocols layered over basic CCN Interest-Data.
This architecture has two implications. First, the security
perimeter around sensitive data is pushed into the application; content is decrypted only inside an application that has
rights to it and never inside the OS networking stack or on
disk. Second, much of the work of using CCN in an application consists of specifying the naming and data conventions
to be agreed upon between publishers and consumers.
All components run on Linux, Mac OS X™, Solaris™,
FreeBSD, NetBSD, and Microsoft Windows™. Cryptographic
operations are provided by OpenSSL and Java.
5. 1. Data transfer efficiency
TCP is good at moving data. For bulk data transfer over terrestrial paths it routinely delivers app-to-app data throughput near the theoretical maximum (the bottleneck link
bandwidth). TCP “fills the pipe” because its variable window
size allows for enough data in transit to fill the bandwidth ×
delay product of the path plus all of the intermediate store-and-forward buffer stages. 9 CCN’s ability to have multiple
Interests outstanding gives it the same capability (see
Section 3. 1) and we expect its data transfer performance to be
similar to TCP’s.
To test this we measured the time needed to transfer a
6MB file as a function of the window size (TCP) and number of outstanding Interests (CCN). The tests were run
between two Linux hosts connected by 100 Mbps links to our
campus ethernet. For the TCP tests the file was transferred
using the test tool ttcp. For the CCN tests the file was pre-staged into the memory of the source’s ccnd by requesting
it locally.k This resulted in 6278 individually named, signed
CCN Data packets (ContentObjects) each with 1KB of
data (the resulting object sizes were around 1350 bytes).
k This was done so the measurement would reflect just communication
costs and not the signing cost of CCN content production.
l Since CCN transacts in packet-sized content chunks, the TCP window size
was divided by the amount of user data per packet to convert it to packets.