You are on page 1of 25

This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 1

Security and Privacy Analysis of National Science


Foundation Future Internet Architectures
Moreno Ambrosin, Alberto Compagno,
Mauro Conti, Senior Member, IEEE, Cesar Ghali, Gene Tsudik Fellow, IEEE

Abstract—The Internet Protocol (IP) is the lifeblood of the Internet Architecture – Next Phase” (FIA-NP) program. Unlike
modern Internet. Its simplicity and universality have fueled the FIA which focused on architectural research, FIA-NP empha-
unprecedented and lasting global success of the current Internet. sizes evaluation, via prototypes, testbeds, trial deployments,
Nonetheless, some limitations of IP have been emerging in recent
years. Furthermore, starting in mid-1990s, the advent of mobility, and extensive experimentation.
wirelessness and the web substantially shifted Internet usage and FIA originally included four research projects: Nebula [19],
communication paradigms. This accentuated long-term concerns [20], Named-Data Networking (NDN) [133], MobilityFirst
about the current Internet architecture and prompted interest in (MF) [111], and eXpressive Internet Architecture (XIA) [57].
alternative designs. Each project focuses on a new Internet architecture with
The U.S. National Science Foundation (NSF) has been one
of the key supporters of efforts to design a set of candidate a distinct vision and design principles. Nebula envisions a
next-generation Internet architectures. As a prominent design highly-available and extensible core network interconnecting
requirement, NSF emphasized “security and privacy by design” numerous data centers that enable new means of distributed
in order to avoid the long and unhappy history of incremental communication and computing. NDN focuses on scalable and
patching and retrofitting that characterizes the current Internet efficient data distribution – thus addressing inadequacies of the
architecture. To this end, as a result of a competitive process, four
prominent research projects were funded by the NSF in 2010: current Internet’s host-centric design – by naming data instead
Nebula, Named-Data Networking (NDN), MobilityFirst (MF), of its location. MF concentrates on scalable and ubiquitous
and Expressive Internet Architecture (XIA). This paper provides mobility and wireless connections. Meanwhile, XIA stresses
a comprehensive and neutral analysis of salient security and flexibility and addresses the need to support different com-
privacy features (and issues) in these NSF-funded Future Internet munication models by creating a single network that offers
Architectures. Prior surveys on future Internet architectures
provide a limited, or even no, comparison on security and privacy inherent support for communication between various princi-
features. In addition, this paper also compares the four candidate pals (including hosts, content and services) while remaining
designs with the current IP-based architecture and discusses extensible to future ones. Only three of the original four FIA
similarities, differences, and possible improvements. architectures were selected for continued funding under FIA-
Index Terms—network security, privacy, trust, future internet NP: NDN, MF and XIA. Figure 1 illustrates the timeline of
architectures each project in FIA and FIA-NP programs.

I. I NTRODUCTION Nebula [19], [20]


Named-Data Networking
HE original Internet was intended to support thousands
T of users, mainly in North America, accessing shared
resources via dumb terminals. Nowadays, the Internet connects
(NDN) [133]
MobilityFirst
(MF) [111]
over 3 billion of mobile and desktop devices with a variety eXpressive Internet
Architecture (XIA) [57] Time
of applications ranging from simple web browsing to video
conferencing and content distribution. These extreme changes FIA (late 2010) FIA-NP (2014)
in Internet usage accentuated limitations of the current IP-
based architecture and prompted research into alternative in- Fig. 1. Timeline of FIA & FIA-NP programs
ternetworking architectures.
In 2010, the National Science Foundation (NSF) launched Security and Privacy by design is one main goals of all
its “Future Internet Architecture” (FIA) program [96]. Origi- FIA projects. It is mainly motivated by increasing reliance on
nally, FIA was a 5-year program with the goal of designing Internet services, growing range and sophistication of attacks1 ,
a set of candidate next-generation Internet architectures. In and increasing demand for privacy. Given the rocky history
2015, NSF renewed its commitment with a follow-on “Future of security and privacy in the current Internet, this goal is both
very sensible and extremely important.
M. Ambrosin and M. Conti are with the Department of Mathematics,
University of Padua, Padua, Italy (e-mail: surname@math.unipd.it). Contribution. In this paper, we survey and evaluate security
A. Compagno is with the Department of Computer Science, University of
Rome “La Sapienza”, Rome, Italy (e-mail: compagno@di.uniroma1.it).
and privacy features in the aforementioned four FIA projects.
C. Ghali and G. Tsudik are with the Department of Computer
Science, University of California, Irvine, CA, USA (e-mail: 1 https://www.theguardian.com/technology/2016/oct/21/
cghali@uci.edu/gene.tsudik@uci.edu). ddos-attack-dyn-internet-denial-service

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 2

In doing so, we consider the network layer of the current (NetInf). The work concentrates on naming, routing and
Internet architecture as a point of reference. This is because forwarding, caching, and mobility. It marginally considers
the network layer reflects the most innovative choices and security and privacy aspects. [24] compares various naming
differences with respect to today’s Internet. We also show how and routing schemes in DONA, NetInf, PURSUIT and PSIRP
each FIA architecture succeeds or fails with respect to security architectures. [122], [123] compare mobility features of NDN,
and privacy features of current Internet’s network layer, i.e., DONA, NetInf, and PURSUIT. None of them [24], [122],
Internet Protocol (IP) [103] and IP Security Extensions (IPsec) [123] discusses security and privacy in much detail.
[110]. We also discuss potential vulnerabilities that can be
Organization. We begin by overviewing IP, IPsec, DNS and
exploited to attack transmission channels, end-nodes, and the
its security extensions in Section II. Next, sections III through
network infrastructure. Since different types of resolution
VI summarize Nebula, NDN, MF and XIA, respectively.
services are needed in all FIA architectures, we compare
Section VII evaluates security and privacy features of these
security and privacy features of such services to those of
architectures, and compares them with those of IP and IPsec.
Domain Name System (DNS) [89] and its prominent security
Section VIII analyzes security and privacy of resolution ser-
extensions, such as the DNS Security Extensions (DNSSEC)
vices used by each new architecture. Section IX summarizes
[22], and DNSCurve protocol [45].
our comparative analysis, and highlights open issues, and pos-
While we recognize that there are several future Inter-
sible future research directions. Finally, Section X concludes
net architecture proposals outside the FIA program, such as
our paper.
DONA [67], PSIRP [48], NetInf [40] and SINET [132], we
Given familiarity with any FIA architectures, the corre-
decided to focus our survey only on the four involved in the
sponding sections, can be skipped without the loss of con-
FIA project. We believe that this choice allows us to provide
tinuity.
a fair and clear plane for comparison since all FIA projects
share the same design principles, which includes security and
privacy from the outset. II. T HE I NTERNET OF T ODAY
To the best of our knowledge, this paper represents the Today’s Internet architecture was designed over three
first comprehensive security and privacy treatment of four decades ago to seamlessly inter-connect multiple heteroge-
FIA architectures. Since it is impossible to predict which FIA neous networks. At the core of today’s Internet is the TCP/IP
architecture(s), if any, will ultimately succeed, we strive to protocol suite, which puts together protocols, applications and
remain neutral, i.e., to provide a complete and fair analysis. network mediums, and organizes them into four abstraction
layers: Link, Internet, Transport and Application. This design
Prior FIA surveys. An early article by Pan et al. [98] leads to an hourglass shape with IP as the network layer as
overviews Global Environment for Network Innovations its “thin waist” [15].
(GENI). Unlike this paper, [98] provides a general overview We consider IP, which operates at the Internet layer, to be
and does not dwell on security and privacy aspects. The our point of reference when analyzing security and privacy
work in [65] provides a broad security analysis of the four of FIA architectures. IP is responsible for forwarding packets
NSF-founded FIA architectures, plus Recursive InterNetwork (a.k.a. datagrams) from the source IP interface to its destina-
Architecture (RINA), Service Oriented Network Architecture tion counterpart. A host may have one or more IP interfaces,
(SONATE), and Netlet-based Node Architecture (NENA). The while a router has at least two. Each IP interface is identified
analysis in [65] considers four security features: confiden- by at least one distinct fixed-length IP address.
tiality, integrity, availability and authentication. This paper Another fundamental component of today’s Internet ar-
provides a more in-depth security analysis and comparison of chitecture, and subject of our analysis, is DNS. DNS is a
the four NSF-funded FIA architectures. In contrast with [65], distributed service that translates application-specific domain
it: (1) offers a thorough description of the said architectures names (specified in URLs) into their corresponding IP ad-
and their resolution services; (2) treats a larger set of security dresses, allowing hosts to communicate using meaningful
features; and (3) discusses in detail security mechanisms at names, rather than IP addresses.
the network layer including the resolution services. In what follows, we briefly describe IP and DNS.
Other more focused surveys addresses security and privacy
aspects of Information-Centric Networking (ICN) architectures
[6], [7], [78], [121]; [78] analyzes security and privacy of A. Internet Protocol
NDN alone. [6] investigates denial of service attacks in NDN, The cornerstone of IP is addressing of network devices.
while [7], [121] give a broader security analysis of several ICN Every network-layer entity (router or host) is identified by at
architectures, considering several types of attacks on: naming, least one IP address which consists of a network prefix and a
routing, and caching. Finally, [121] separately considers ICN host identifier. The boundary between them is flexible, which
security, privacy and access control. allows IP addressing to scale.
Other, more general, surveys of ICN architectures do not An IP datagram contains source and destination addresses
focus on security and privacy aspects [14], [24], [122], [123]. along with other fields that convey control information. Actual
[14] analyze Data-Oriented Network Architecture (DONA), data is carried in the payload field. When a packet is received,
Named Data Networking (NDN), Publish-Subscribe Inter- a router searches its Forwarding Information Base (FIB) to
net Routing Paradigm (PSIRP), and Network of Information identify the next hop for that packet. A FIB contains a set

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 3

of entries, each mapping one or more network prefixes to B. Domain Name System
a router’s interface and a next-hop IP address. This allows The purpose of DNS is translation of domain names (e.g.,
routers to perform longest-prefix matching on the destination those found in URL prefixes) into IP addresses. Domain names
address to identify the next hop. If a packet can not be are organized in a hierarchical fashion: a top-level domain
forwarded, it is dropped and an error message is generated (e.g., “.com”) is followed by many sub-level domains (e.g.
via the Internet Control Message Protocol (ICMP) [102].2 second-level domain “example.com”, and third-level do-
One important IPv4 feature is packet fragmentation. If the main “sub.example.com”). For each domain, DNS assigns
size of an IP packet is larger than the forwarding interface’s an authoritative name server that stores information of, and
Maximum Transmission Unit (MTU) [31], the packet must be responds to queries for, a specific contiguous portion of the
divided into smaller chunks, called fragments. A destination domain name space, called DNS zone. This information is
host must reassemble fragments to recover the original packet. contained in Resource Records (RR-s) – basic DNS elements
Other network entities, such as Network Address Translation which are also carried in DNS replies. Moreover, authoritative
tables (NATs) [56], [118] and firewalls might also assemble name servers might delegate authority over sub-domains to
fragments. other name servers, thus increasing DNS’s scalability.
As mentioned earlier, IP was originally designed for a A user interacts with DNS by issuing a query to a local
small and relatively amicable research community. Neither resolver: a process running on the end-user’s device which
its longevity nor its popularity was foreseen. Thus, it is forwards the query to the appropriate name server(s). The
unsurprising that IP lacks any security and privacy features. resolver sends a UDP (User Datagram Protocol [101]) packet
In late 1980-s and early 1990-s, as IP started to gain global containing the query to the DNS server, which is usually
popularity and the Internet transcended into the commercial located in the resolver’s local network. The server then checks
sector, IPsec suite [110] was designed to provide basic security if it can reply to the query from its cache. Otherwise, it fetches
services, such as: origin authentication, data integrity, and the response from other local or remote DNS servers.
confidentiality for IP datagrams. The first two are attained via DNS queries can be of two types: iterative or recursive. An
Authentication Header (AH) protocol [63], while Encapsula- iterative query allows a DNS server to return the best answer
tion Security Payload (ESP) protocol [64] provides all three to the resolver, based on its local information, i.e., either a
security features. IPsec supports two modes of operation: cached RR or an RR belonging to its zone. If the server does
• Transport: provides end-to-end communication, e.g., not have an exact match for the queried name, it returns a
client-server communications. Only packet payloads are referral: a pointer to a DNS server authoritative for a lower
encrypted and authenticated in transport mode. Transport level of the domain namespace. The resolver then queries the
and application layers of packets are secured by a hash, DNS server in the referral which can also reply with a referral.
thus, they can not be modified, e.g., using NAT. NAT- This process continues until the resolver receives requested
Traversal (NAT-T) [66] is developed to overcome this information, or an error is generated. In the recursive query,
issue. DNS servers reply with either the requested RR or an error.
• Tunnel: typically used between gateways to provide a If the DNS server does not have the requested information, it
secure connection (pipe) between physically separate recursively queries other DNS servers.
Although DNS was originally designed as a static dis-
networks, e.g., different sites of the same organization.
tributed database, it now allows dynamic records updates
Tunnel mode also supports secure host-to-gateway com-
[30], [129] and zone transfers [70]. Also, a recent proposal
munication. An IP packet is encrypted in its entirety and
envisions DNS as a distributed database to store IP related
encapsulated as a datagram with a new outer IP header.
information [8]. For instance, [107] proposes storing IPsec
One popular application of tunnel mode is Virtual Private
keys related information in DNS records and mapping them
Networks (VPN) [84].
to IP addresses.
IPv6 [43] is a newer version of IP developed to overcome some The original DNS did not include any security or privacy
limitations of IPv4. One of its main new features is extended features. DNS Security Extensions (DNSSEC) [22] was added
128-bit address space (as opposed to 32 bits in IPv4). Another to provide data integrity and origin authentication for DNS
departure from IPv4 is lack of in-network fragmentation. messages. In DNSSEC, RR-s are signed by their authoritative
Before sending an IP datagram must first discover the smallest servers’ keys. The basic mechanism and the query-response
MTU on the path to the destination and fragment the datagram protocol of DNS remain unaltered.
accordingly. To help with this, the Path MTU Discovery There have been other attempts to secure DNS, e.g.,
protocol [86] was designed and implemented. IPv6 also takes DNSCurve [45]. It provides link-level security between
into consideration security and privacy by implementing some clients and DNS servers, using elliptic-curve cryptography.
features similar to IPsec – such as AH and ESP – as extension DNSCurve guarantees hop-by-hop query/response confiden-
headers [1]. tiality, authenticity and integrity.
In the rest of this paper, we use the term “IP” to refer to
both IPv4 and IPv6, unless otherwise specified. III. N EBULA
Nebula [18]–[20] is a FIA project focused on providing
2 ICMP is also used for sending control messages, such as routing redirect a secure and cloud-oriented networking infrastructure. Its
for networks and hosts. architecture is composed of three tiers:

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 4

• Network core (NCore) is a collection of routers and Each packet contains a header (shown in Figure 2(b))
interconnections that provide reliable connectivity be- including: (1) the path P consisting of all ICING nodes N j
tween routers and data centers. NCore is based on high- forming it, and, (2) a list of verifiers Vj , one per node N j in
performance core routers and rich interconnected topolo- the path except the sender. This allows each verifier to prove
gies [73]. that the packet passed through all previous nodes.
• Nebula Virtual and Extensible Networking Techniques A sender builds a packet header as follows:
(NVENT) represents the control plane of Nebula. 1) Proof of Provenance (PoP) token, one for each node on
NVENT helps in establishing trustworthy routes based the path (action 2 in Figure 2(b)), is generated using
on policy routing [23] and service naming [95]. a PoP key k j shared with the corresponding node j. In
• Nebula Data Plane (NDP) is responsible for routing Figure 2(b), PoPs are denoted as PoPi, j , where i is the
packets along the paths established by NVENT. To index of the node generating the PoP and j is the index of
guarantee confidentiality, availability, and integrity, NDP the node for which PoP is generated. Specifically, PoP0, j
ensures that packets for a specific communication can is computed by node 0 using k j , path P, and message M
only be carried when all parties, i.e., end nodes and itself.
routers in between, have agreed to participate. 2) Authenticator A j is computed for each node j using PoC j ,
P and M.
A. Nebula Network Layer 3) Verifiers Vj , one per node, are computed by XORing the
corresponding A j and PoPi, j .
The original design of Nebula specifies different candidate
network layer stacks for NDP [20], e.g., ICING [92], TorIP PoP tokens are used by each node on the path to prove that
[74], and Transit-as-a-Service (TaaS) [100]. From this list, downstream nodes have handled the received packets based
ICING was picked as the most suitable candidate and was on the established policies. When an intermediate node Ni
included in the Zodiac Nebula prototype implementation [19]. receives a packet, it performs the following actions:
ICING provides a new primitive, called Path Verification 1) Computes the corresponding PoCi .
Mechanism (PVM), which guarantees the following two prop- 2) Computes PoP j,i using k j , for each downstream node N j .
erties: 3) Verifies that the received PoCi and PoP j,i match the
• Path Consent – every entity in a path between two
two values computed in the previous two steps. If this
hosts consents the use of the whole path before the verification fails, Ni drops the packet.
communication starts. 4) Derives a shared PoP key kl , for each upstream node Nl ,
• Path Compliance – the possibility for each node in a path
and computes PoPi,l as described above.
between two hosts to verify that a received packet: (1) 5) Modifies the verifiers to include the computed PoP, and
follows the approved path; and (2) has been “correctly” forwards the packet upstream (actions 3 and 4 in
forwarded by all the previous nodes in the path, i.e., Figures 2(a) and 2(b)).
according to a specific pre-established policy. The previous steps allow any node to guarantee that all packets
are forwarded by all the consenting nodes while establishing
ICING can be deployed either at the network layer or as an
the path.
overlay on top of IP. In the former case, service providers can
deploy ICING nodes as ingress gateways to their networks.
However, in the latter case, ICING nodes may become way- B. Nebula Control Plane
points, interconnected using IP, providing waypoint-level path The control plane in Nebula is provided by NVENT.
guarantees. NVENT uses declarative networking [76], [77], and allows
To start communication, a sender must first establish a administrators to provide high-level specifications of their
complete path. Such a path can be provided by DNS with routing policies. NVENT also involves special interfaces,
policy enforcement [92]. Figures 2(a) and 2(b) show how called service interfaces, that enable service access and specify
forwarding works in ICING and a high-level representation the required level of availability. For instance, an emergency
of how the ICING header evolves. service can request high availability, which can be provided
Once a path is selected, the sender requests a Proof of by multi-path interdomain routing. A distributed resolution
Consent (PoC j ), for each node j on the path (action 1 in service is used for discovery of other NVENT services. This
Figure 2(a)). PoCs are cryptographic tokens created by each service is populated by service providers, e.g., NCore data
node transit provider, which attest to the provider’s consent to centers [17].
carry packets along the specified path. Each PoC certifies that Serval is an implementation of NVENT based on the con-
the corresponding network provider consents to (1) the full cept of service-centric networking [54], [87], which decouples
path, and (2) a specific policy-based set of local actions (e.g., service instances (e.g., web or email services) from their physi-
forwarding) to be performed on packets traversing the path. cal locations (i.e., IP address and port). Serval introduces a new
PoCs are generated by a consent server, which is owned by the layer, the Service Access Layer (SAL), between the network
transit provider or acts on its behalf. Such servers share secret layer and the transport layer. With Serval, each service is
keys with each node (router) in their corresponding providers. identified by a serviceID, a unique identifier that applications
Once all PoCs are received, the path is established and packet use to communicate with the service. In addition, each local
transmission can begin. traffic flow, representing a connection between two hosts, is

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 5

Consent Consent Consent


Server 1 Server 2 Server 3
1 1 1 ⨁ ⨁ ⨁

⨁ ⨁ ⨁ ⨁ ⨁

⨁ ⨁ ⨁ ⨁ ⨁ ⨁

Sender Node 1 Node 2 Receiver


2 3 4 2 3 4

(a) Packet forwarding in ICING (b) ICING packet high-level structure

Fig. 2. ICIN [92] architecture

identified by a unique flowID. The request is handled by SAL, IV. NAMED -DATA N ETWORKING
which uses local control plane policies to map the serviceID to While IP traffic consists of packets sent between com-
a service instance. SAL eventually creates a new flowID that municating end-points, NDN traffic is comprised of explicit
identifies the established connection. This flowID is delivered requests for, and responses to, named content objects. NDN
to the destination host during connection setup, and used by is based on the principle of Content-Centric Networking,
both parties for connection identification. Finally, SAL routes where content, rather than hosts, occupies the central role in
the packet based on specific control plane rules contained in the architecture. NDN is primarily oriented towards efficient
its SAL table. For instance, a host application that wants to large-scale content distribution. Rather than directly addressing
connect to a specific service might direct the first request to specific hosts, NDN users (called consumers) request pieces
a default Serval router (using its IP address). The SAL of the of content by name. The network is in charge of finding the
router then processes the request and take further decisions closest copy of the content, and delivering it. This decoupling
based on its SAL table (e.g., forward to another router or send of content and location allows NDN to efficiently implement
directly to a known service instance). Moreover, Serval does multicast, content replication and fault tolerance.
not directly provide clients a way to learn serviceIDs: It simply
suggests the use of directory services or search engines [95].
A. NDN Network Layer
Figure 3 presents a view of how all Nebula components
integrate to allow a user to negotiate a custom end-to-end The NDN network layer uses hierarchical structured names
path to a specific data center and send the desired packets. to directly address content. Names are composed of a num-
First, the user (either the mobile phone or the laptop in the ber of components, e.g. /ndn/bbc/frontpage/news where
figure) contacts NVENT to request a path to NCore. NVENT “/” represents the boundary between two components. Since
determines a suitable path that complies with each transit names are opaque to the network, they can contain binary or
network’s policies and contacts the corresponding consent human-readable components.
servers to obtain the necessary PoCs. Once the path and all To support content distribution, NDN defines two types of
PoCs are delivered to the user, the latter generates appropriate packets: interest and content (the latter is also called data
packet headers and forwards them, using the NDP forwarders packet). NDN communication adhered to the pull model, that
network, to the nearest NCore router. This router ensures that is: every content is delivered to consumers only upon explicit
all header fields are valid (as described above) and verifies that request. Specifically, a consumer issues an interest packet
the negotiated path has actually been traversed. Once verified, carrying the name of the desired content. The network will
the core router forwards received packets to the correct data then forward the interest towards the producer.
center using its NCore links. One important feature of NDN is in-network caching: any
router can store a copy of the content it receives or forwards,
and use it to satisfy subsequent interests. Therefore, an NDN
interest might be satisfied by the actual content producer or
any intermediate router. Along with in-network caching, NDN
introduces another important feature called interest collapsing:
only the first of multiple closely spaced (and timed) interests
requesting the same content is forwarded by each router.
Each NDN entity (not only routers) maintains the following
three components [133]:
• Content Store (CS) – cache used for content caching and
retrieval. A router’s cache size is determined by local
resource availability. Each router unilaterally determines
what content to cache and for how long. From here on,
we use the terms CS and cache interchangeably.
Fig. 3. High-level view of Nebula components integration [18]–[20] • Forwarding Interest Base (FIB) – table of name prefixes
and corresponding outgoing interfaces. FIB is used to

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 6

route interests based on longest-prefix matching of their Furthermore, interest collapsing can cause content objects to
names. be fragmented (or even re-fragmented) by routers [50]. The
• Pending Interest Table (PIT) – table of outstanding (pend- question remains to whether to perform a hop-by-hop reassem-
ing) interest names and a set of corresponding incoming bly [12], or cut-through processing of content fragments [50].
interfaces, denoted as arrival-interfaces Regardless of its claimed benefits, it is trivial to see that hop-
When an NDN entity receives an interest, it searches its PIT by-hop reassembly incurs unnecessary overhead and end-to-
to determine whether another interest for the same content is end latency.
pending. There are three possible outcomes: Not all interests result in content being returned. If an
1) If a PIT entry for the same name exists, and the arrival interest encounters either: (1) a router that can not forward
interface of the present interest is already in arrival- it further or (2) a producer that has no matching content, no
interfaces, the interest is discarded. error is generated. PIT entries in intervening routers simply
2) If a PIT entry for the same name exists, yet the arrival expire when no matching content is received. In such case,
interface is new, the router appends the new incoming the consumer can choose to re-issue the same interest after a
interface to arrival-interfaces, and the interest is not timeout.
forwarded further.
3) Otherwise, the router looks up its cache for a matching B. NDNS Distributed Database
content. If it succeeds, the cached content is returned and
no new PIT entry is needed. Conversely, if no matching Since content can be addressed using human-readable
content is found, the router creates a new PIT entry and names, NDN in principle does not require a resolution service
forwards the interest using its FIB. that translate user-friendly names into network addresses.
Upon receipt of the interest, the producer, or an intermediate However, as discussed in [11], a distributed database similar
router, responds with a matching content, thus satisfying the to DNS, if existed, provides several benefits to the NDN
interest. The content is then forwarded towards the consumer, architecture:
traversing the reverse path of the preceding interest. Each • Cryptographic credential management: Since each data
router on the path flushes the corresponding PIT entry and packet is required to be signed, a distributed database is
forwards the content out on all interfaces specified by that optimal to store and serve security information (e.g., keys
entry. If a content is received by a router with no prior and certificates) for namespaces.
matching interest, the content is considered unsolicited and is • Namespace regulation in the global routing: Similar to
discarded. Since no additional information is needed to deliver the ROVER project [49], a DNS-like service can store
content, interests do not carry any form of source addresses. information that certifies the authorization of ASes to
The last component at the end of content name can carry announce a particular prefix in the global routing.
an implicit digest (hash) component of the content that is re- • Scaling NDN routing: The fact that NDN names can
computed at every hop. This effectively provides each content be arbitrary long renders the namespace infinitely large.
with a unique name. Names carrying such digest forms what This exceeds the number of possible routable IP prefixes.
is called as Self-Certifying Names (SCNs). If an interest is Therefore, a DNS-like service can be used to implement
issued using SCN, the retrieved content is guaranteed, due to a Map-n-encap solution to increase scalability in NDN
longest-prefix matching, to be the same content requested by routing [13].
the consumer. However, in most cases, the hash component is Two distributed database systems that resemble the DNS de-
not present in interest packets, since NDN does not provide sign, KRS and NDNS, are proposed in [11], [80], respectively.
any secure mechanism to learn a content hash a priori. These two proposals adopt a similar design and provide the
Apart from the name, content packets carry a Signature same features. In the rest of this paper we use NDNS to refer
generated by the content producer and covering the entire to such a distributed system.
content. For this reason, each producer is required to have Similar to domain names in DNS, NDNS organizes names-
at least one public key, represented as a bona fide named paces in a hierarchical set of zones and assigns replicated
content object. Other notable fields in content packets are: authoritative servers for each of them. NDNS queries are
the Payload containing the actual data of the content and expressed via interest, in which, names carry all query’s
the ContentType defining the type of the content, e.g. data necessary information. NDNS responses are carried in content
or key. Other important fields in interest packets are: the objects where their payloads contain the information requested
KeyLocator which references to the public key required by the corresponding query.
to verify the signature, and the InterestLifetime which NDNS reflects many of the DNS protocol machinery: a
specifies the lifetime of an interest before it expires (and its resolver issues an iterative or recursive query to a local NDNS
corresponding PIT entry is flushed). server. In case of iterative query, the server can reply with
Similar to IP, fragmentation of NDN packets can not be the answer (if known), a referral, or a negative response. In
avoided. The fact that names can grow arbitrary long might case of recursive query, if the NDNS server does not know
cause interests length to span beyond some link MTU values. the answer, it recursively queries another NDNS server until
In this case, fragmentation must occur. However, since FIB it receives an answer (i.e., the requested data or a negative
forwarding is based on the availability of the entire name, response). Moreover, secure dynamic updates are provided as
reassembling of fragmented interests at every hop is a must. in DNS [127].

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 7

Figure 4 shows the basic dynamics of NDN naming resolu- human readable name can be assigned to a principal and
tion and forwarding. Consumer 1 retrieves a routable content later resolved (by GNS) to the corresponding GUID.
name from NDNS (Step 1 in Figure 4), then issues an • Network Address (NA): a flat address that identifies
interest, which is routed to its Producer (Step 2 in Figure 4). a network to which a particular principal (GUID) is
The Producer, then responds with a data packet matching connected. MF networks are equivalent to ASes on
the interest, which is routed back to Consumer 1 on the today’s Internet. NAs can be used to identify finer-
reverse path (Step 3 in Figure 4). Subsequent interests for grained networks such as subnets or organizations. In
the same data packet (Step 4 in Figure 4) may be satisfied cases where principals are connected to multiple networks
by intermediate network caches (Step 5 in Figure 4). (e.g., using 3G and WiFi simultaneously), multiple NAs
can correspond to the same principal.
NDNS As a consequence of this addressing scheme, MF defines a
2 new packet type called Packet Data Unit (PDU). PDUs contain
Producer source and destination GUIDs, lists of source and destination
NDN Network Layer
3
1 2 NAs, payload, and other control fields.
Figure 5 shows a simplified architecture of MF, and regis-
2 3
5 tration and mobility handling. When connecting to a network
2
3 4 with network address NA1 (Step 1 in Figure 5), a MF host
5 first registers itself at GNS under a specific GUID (Step 2 in
3 Figure 5). When such host moves into a different network and
Consumer 1 4 obtains address NA2 (Step 3 in Figure 5), it updates GNS
Interest
Data packet served by Producer
database to reflect its new location (Step 4 in Figure 5).
Consumer 2
Data packet cached and served by switch D In order to communicate with a specific GUID, endpoints
need to query GNS to obtain the corresponding NA. The
Fig. 4. NDN architecture and forwarding retrieved tuple (GUID, NA) is then carried in the PDU header
as a routable destination identifier. PDUs are first delivered
to their corresponding destination NAs (using inter-domain
V. M OBILITY F IRST routing), and then to the destination GUIDs (using intra-
MobilityFirst (MF) architecture aims to overcome the inef- domain routing). In case of delivery failure, the packet is stored
ficiencies and limitations of today’s Internet due to mobility. inside the network (in routers) and GNS is periodically queried
It focuses on scenarios where wireless connections are ubiqui- for a new or updated GUID-NA mapping.
tous and pervasive. To this end, MF has been designed around
the concepts of mobility and trustworthiness. All endpoints
Global Name System (GNS)
must be able to seamlessly switch network connection, and
the network must be resilient to compromised endpoints and
GUID ↔ NA2
routers. GUID ↔ NA1 Network Layer
Registration
MF treats principals – devices, content, interfaces, services, Initial Update
Registration
4
human end-users, or a collection of identifiers – as primary 2
Network 2
addressable network entities. To promote mobility, the (con- Network 1
stant) identity of a principal and its (dynamic) network location NA
1
NA 2
are strictly separated. This requires a distributed Global Name 1
Connection to
Network 1 3
Service (GNS) to bind principal identities to network ad- Mobility to Network 2

dresses. Furthermore, identity and network address separation:


(1) facilitates service implementation and deployment; and Fig. 5. MF architecture and GUID-NA mapping registration at GNS
(2) supports designing routing protocols that overcome link
fluctuation and disconnections [94].
Multihoming, anycast, and multicast are supported by mul-
We now briefly describe MF’s network layer and its GNS.
ticast GUIDs (MIDs). MID has the same format as a regular
GUID, except its resolution results in a set of NAs (instead
A. Network Layer of, at most, one). Technically, GNS associates one MID with
Two types of identifiers are used to differentiate between several GUIDs (the ones belonging to the multicast group).
principal identities and their physical locations. Resolving all of them results in one or more elements of the
output NAs set.
• Global Unique Identifier (GUID): a flat self-certifying
MF can also support content distribution networks. In this
identifier that uniquely identifies a principal. GUIDs can
case, GUIDs are composed of two parts:
be generated using multiple methods depending on the
provided service type. For instance, they can be derived • Content GUID (CID): uniquely identifies the content and
from the public key of a host or a service principal or the is generated by computing the hash of the corresponding
hash of a content principal. For the sake of usability, a content.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 8

• Publisher GUID (PID): points to the network entity The user generates and signs the request containing the
providing the content. Such an entity can be the actual GUID-NA mapping. Local and border routers are in charge of
content provider, or a third-party content repository. verifying validity of the announced mapping. This is achieved
A router may be equipped with a cache. This opportunistic by verifying that the announced NA is the network connected
caching feature facilitates content distribution at the network to the user (and the local router), and querying the DHCP
layer by reducing end-to-end latency and bandwidth consump- server to ensure that the returned NA corresponds to the
tion. Moreover, MF exploits in-network caching to implement announced GUID. If the NA matches the one contained in
a per-segment (i.e., a continuous set of links with caching the update or the insert request, the mapping is accepted
routers at each end) reliable chunk (few hundred of megabytes) and added or updated in the GNRS table.
transfer. Each chunk is fragmented and transmitted according In the secure query request, the protocol involves three
to the segment MTU. Then, the caching router at the other end entities: the user, the border gateway, and GNRS. The user
assembles the entire chunk and stores it. In case of transferring issues an authenticated request and the border router checks its
failure, caching routers can re-transmit a chunk via the same, validity. The router then forwards the request to the appropriate
or even a different, path. GNRS replica. On receipt, the GNRS satisfies the request with
a signed GUID-NA mapping response.
There are several differences [112] between GNRS and
B. Global Name Service DNS [89]. First, GNRS does not restrict the structure of the
GNS is an essential part of the MF architecture. Its main names, while DNS only supports hierarchical names. Second,
task is to map endpoint identifiers (GUIDs or human readable scalability of GNRS does not rely on TTL-based caching,
names) to a set of attributes including the endpoint network which has been proven to be ineffective in the presence of high
address. GNS relies on the following two services: mobility. Third, GNRS does not statically give the authority
• Name Certification Service (NCS): is equivalent to a to a replicated server for a specific set of names. Active and
Certificate Authority (CA). Its purpose is to (1) assign on-demand replication reduce reliance on passive caching and
GUIDs to human-readable names and (2) attest this ensure that mapping replicas are always accessible close to
mapping by generating certificates. MF allows multiple clients.
NCSs without a global root of trust. Moreover, if GUID
space is large enough, the need for coordination between VI. E X PRESSIVE I NTERNET A RCHITECTURE
different NCSs is eliminated. eXpressive Internet Architecture (XIA) is another research
• Global Name Resolution Service (GNRS): a distributed effort aiming to design a new architecture. XIA is based on
naming service similar to Domain Name System (DNS) three types of principals. Host-centric networking can support
that stores the mapping between GUIDs and NAs [75], end-to-end communication, such as video conferencing and
[90], [126].3 Two GNRS implementations are evaluated: file sharing. Service-centric networking allows users to access
(1) a distributed hash table maintained among all ASes of various network services such as printing and data storage
the Internet (DMap [128]), and (2) a number of replica- services. Meanwhile, content-centric networking can support
controllers that migrate data (GUID-NA mappings) be- Web browsing and content distribution. However, XIA’s design
tween a variable number of active replicas (Auspice is extensible in that it can adaptively provide network evolution
[112]). and support any new principal type that might emerge in the
Regardless of its implementation, GNRS clients interact with future.
the service by issuing the following requests to the GNRS A core architectural property of XIA is intrinsic security
resolver: of all principals. Any entity should be able to authenticate
the principal it is communicating with, without trusted third
• insert: register a new GUID-NA mapping when a
parties. This can be achieved by binding one or more security
principal joins the network.
properties with principal names. For instance, using the hash
• update: keep the GUID-NA mapping up-to-date when
of a service (or a host) public key as its name allows entities to
the corresponding principal migrates to a new network
verify that they are communicating with the desired principal.
location.
Similarly, binding content with its name can be achieved using
• query: retrieve the list of NAs associated with a specific
the hash of the content as its name, allowing users to verify
GUID.
the integrity of a requested content.
In [75], a secure version of the above three GNRS request XIA defines three main design requirements:
types is proposed. The secure insert and update requests
1) All network entities must be capable of clearly expressing
adopt a two-step approach to check validity of a GUID-NA
their intent. This is achieved by designing the network to
mapping. Four network entities are involved in this process:
be principal-centric and allowing in-network optimiza-
(1) the user issuing the new GUID-NA mapping, (2) the local
tion. Routers can perform principal-specific operations
router to which the user is connected, (3) the border gateway
when receiving, processing, and forwarding packets.
router that connects the user’s AS to the rest of the Internet,
2) The network must be able to adapt to new types of
and (4) the DHCP server which assigns the user’s address.
principals. This is essential to support network evolution.
3 GNRS is the actual GNS service that is responsible for maintaining GUID- 3) Principal identifiers must be intrinsically secure. This
NA mappings. depends on the principal type, e.g., authenticating hosts in

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 9

host-centric networking is different than verifying content • Multiple paths – this supports recovery from link fail-
integrity in content-centric networking. ures. An example of this style is shown in Figure 6(e).
Principal identifiers are denoted as XID, where X defines the Figure 7 shows a high level overview of an XIA router. Its
type of principle. For instance, HID identifies a host, SID a modular design allows efficient multi-principal processing and
service, NID a network, and CID a content. supports network evolution. Each router contains two main
XID-specific processing modules:
• Source XID-specific processing: necessary for certain
A. eXpressive Internet Protocol XID types. For instance, in case of a reply to a CID
In order to comply with the aforementioned requirements, request, the “CID processing” unit can implement in-
eXpressive Internet Protocol (XIP) is designed. XIP defines network content caching.
packet format, addressing schemes, and behavior of all nodes • Next Destination XID-specific processing: invoked by
while processing incoming and outgoing packets from/to var- the Next Destination XID-specific Classifier which de-
ious principal types. One of the main features of the XIP termines the appropriate forwarding action. Similar to
addressing scheme is flexibility of defining multiple (fallback) source processing, this module consists of several units
paths to destinations. This prevents downtime and service in- that carry on XID-specific operations right before for-
terruption, especially while gradually deploying new principal warding the packet.
types. An XIP address is a directed acyclic graph (DAG) with If all outgoing DAG edges of a node lead to unrecognizable
several properties: XIDs, the packet is dropped and an unreachable destination
• Each address is a single connected component. error is generated. It is the responsibility of user applications to
• Each DAG starts with an untyped entry node and ends provide appropriate fallback paths to avoid forwarding failures
with one or multiple “sink” nodes. Thus, each node in at any router. Usually fallback paths are built using well-
the address graph has a unique XID except for the entry supported principals, e.g. HID and NID.
node.
• Edges define next hops in the path. B. Principals
• Multiple outgoing edges of a single node are processed As mentioned above, principals in XIA support emerging
in the order they are listed. communication paradigm on the current Internet. When intro-
• Out-degree of each node is upper bounded to restrict ducing a new principal, the following issues arise:
performance overhead. • What does it mean to communicate with a principal of
Using DAGs as a basis for XIP addresses allows applications this type?
to build several “styles” of addresses, such as: • How is the principal’s unique XID generated and how
• Shortcut routing – this style, shown in Figure 6(a) is does it map to intrinsic security properties?
best suitable for requesting content principal. Each node • What are the source and next destination XID-specific
has a direct edge to the destination principal CID1 , which processing actions that routers should perform and how
enables in-network caching. If a node does not have the can such actions be implemented?
content cached, the fallback path is processed and the We now describe several principal types and discuss their ad-
packet is forwarded to the next hop. dressing schemes, in-router processing behaviors, and security
• Binding – some services require that communication is properties.
bound to a specific source or destination. For instance, a 1) Network and Host: Network and host principal iden-
service hosted in multiple geographical locations. Users tifiers are denoted as NID and HID, respectively. They are
can establish a session with the closest host providing generated by using the public key hash of the network or the
this service. Then, all further communications must be host. Unlike hosts on current Internet, each XIA host has a
directed to this particular host. Figure 6(b) shows an unique HID regardless of the interface it is communicating
example of this addressing style. The first packet is through. This feature helps support host mobility. In order to
destined to SID1 , i.e. the closest host, while the second support fallback paths, all XIA routers should implement NID
packet is destined to SID1 provided by a specific host and HID processing modules.
HID1 . As mentioned above, the fact that the network and host
• Infrastructure evolution – as mentioned above, XIA addresses are derived from their corresponding public keys
supports gradual network evolution for emerging prin- allows users to verify the identity of entities with whom they
cipal types using fallback paths. Figure 6(c) shows an are communicating. Furthermore, this security requirement
example of this style. Assume that NID1 is gradually helps defend against address spoofing, Denial of Service
deploying service SID1 . All NID1 routers that are not yet (DoS), and cache poisoning attacks.
updated to recognize and process SID1 use the fallback 2) Service: Services in XIA represent applications in to-
path through HID1 and HID2 . day’s Internet. Users communicating with a service SID can
• Source routing – Figure 6(d) gives an example of this use a destination address of the form NID:HID:SID. In today’s
addressing style, in which the source routes the packet to terminology, this is analogous to sending a packet to a spe-
the destination through a third party domain and service, cific host in a specific network and indicating the associated
NIDa and SIDa , respectively. protocol and port number.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 10

NID SID SID


1 1 2
NID SID
1 1

NID NID CID NID HID SID HID HID


1 2 1 1 1 1 1 2

(a) Shortcut routing (b) Binding (c) Infrastructure evolution

NID NID CID


1 2 1

NID SID NID NID CID


a a 1 2 1
NID NID NID
3 4 5

(d) Source routing (e) Multiple paths

Fig. 6. XIP Addressing Styles [57]

Source XID-Specific Next Dest. XID-Specific


Processing Processing

NID processing NID processing

Source XID- HID processing Next Dest. HID processing yes


Incoming Route Outgoing
Type XID-Type
Interface Success? Interface
Classifier SID processing Classifier SID processing

CID processing CID processing


no

Fallback

Fig. 7. XIA Router Diagram [57]

Since different services might require different specialized • Trust: confidence (sometimes based on inconclusive evi-
processing, implementing in-router source and next destination dence) (1) that an entity will behave as expected; and (2)
processing modules is a challenge. Therefore, routers are that a content comes from a trusted source.
only required to perform default processing, routing, and • Data origin authentication: corroboration that the
forwarding of SID packets. All other specialized processing source of the received data is as claimed.
should be handled by end-nodes. • Peer entity authentication: corroboration that a peer
SIDs are generated by computing the hash of the service entity in an association is the one claimed.
public key. This inherits security properties similar to NIDs • Data integrity: assurance that data has not been tampered
and HIDs. with, in any (unauthorized or accidental) manner.
3) Content principals: This principal type signifies user’s • Authorization and access control: respectively: (1) a
intent to retrieve content. Packets carrying content identifiers secure means for an entity to access (e.g., read, write,
(CID) as destination addresses will be routed all the way delete) some resource, and (2) protection of a resource
to the node hosting the content. Routers can use a cached against unauthorized access.
version of the content as a reply to such packets. As mentioned • Accountability: assurance that all actions can be securely
above, caching is implemented by routers source XID-specific traced to their source(s).
processing module. • Availability: accessibility and usability of a resource
CIDs are generated based on the cryptographic hash of upon demand by an authorized entity.
the content they address. This binds the content to its name, • Data confidentiality: unavailability of data to unautho-
forming a self-certifying name. rized entities.
• Traffic flow confidentiality: a set of countermeasures to
traffic analysis.
VII. N ETWORK -L AYER S ECURITY AND P RIVACY
• Anonymous communication: inability to determine
As mentioned earlier, security and privacy by design is one identities of communicating entities.
of the key NSF-stipulated guidelines for all FIA projects. In
this section, we provide a comparison between the security
and privacy features offered at the network layer of each ar- We consider the last three as instrumental to privacy at the
chitecture introduced above, and compare them with IP/IPsec. network layer. In the rest of this section, we discuss each
We consider the following security and privacy features, which feature separately. Tables I and II summarize our comparison
we consider to be essential [113]. on security and privacy features, respectively.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 11

A. Trust available end-to-end communication. The network is divided


IPsec defines trust as a one-way relationship between two into multiple trust domains consisting of several Autonomous
or more entities (hosts or networks). This relationship is Systems (ASes) that trust each other. Each domain has a
captured by a Security Association (SA). An SA can be trusted root AS responsible for relaying packets to and from
viewed as a “contract” between the peers. It describes security other domains. Roots initiate path establishment to all hosts in
services and contains security information needed to protect their domains based on local policies and available bandwidth.
communication. This process results in constructing a path between each host
and its domain root. Whenever two XIA hosts, in different
Entities involved in secure communication in IPsec establish
domains, want to communicate, the two half paths (from each
SAs via the ISAKMP4 [85] protocol and exchange necessary
host to its domain root) are combined to establish a complete
cryptographic material using the Internet Key Exchange (IKE)
end-to-end path. Such path is trusted since it is created by the
protocol [33]. Host authentication in ISAKMP and IKE can
trusted roots of each domain.
be achieved via either digital signatures, or pre-shared keys.
Digital signatures require the use of certificates to bind entity
B. Data Origin Authentication
identifiers to public keys. This implies the existence of a CA
to create, revoke, and distribute certificates. IP (IPv4 in particular) does not provide any form of au-
Nebula’s ICING-based network layer defines trust orthog- thentication. A separate add-on method, IPsec, provides entity
onally to IPsec: between a host and all nodes forwarding authentication via AH and ESP protocols.6 In transport mode,
its packets. As described in Section III, a host agrees on a two hosts securely negotiate a shared secret key. This key is
“contract” with the network providers carrying its data (i.e., later used to generate a Message Authentication Code (MAC)
the path negotiated using NVENT) to specify the operation [69] for each packet. Successful MAC verification ensures
executed at each hop. Such contracts are cryptographically authenticity of received packets and their origin. In case of
enforced. ICING assumes mutual trust between forwarding gateway-to-gateway communication, gateways can only verify
nodes and consent servers that are responsible for creating that the received data originated by any (not a specific) host
PoC tokens. Therefore, this notion of trust does not require connected to the network at the other end of the tunnel. In host-
any PKI [92]. However, ICING does not provide an end-to- to-gateway communication, the gateway can actually verify
end definition of trust, which can be added by adopting an that the data originated by the involved host, while the latter
IPsec-like approach. can only verify that received data is originated by the network
Unlike IP, the notion of trust in NDN is directly associated located behind the gateway. This partial authentication opens
with contents and not with hosts and networks. Trust in content the door for insider attacks.
can be expressed at different levels of granularity: from a Nebula’s ICING-based network layer does not directly
single content object to an entire namespace. Recall that a provide data origin authentication, which is delegated to
content object is signed by its producer, which allows anyone applications.
to verify its origin and authenticity. Origin refers to the content NDN provides data origin authentication via content signa-
producer and not to any entity that might store a copy of that tures. Before consuming content, consumers are required to
content. To authenticate a content and its origin, its signature verify its signature [133]. However, this operation is optional
must be verified. This requires the verifier to retrieve, and for routers because signature verification is an expensive
establish trust in, the corresponding public key.5 However, operation at line speed and comprehensive trust management is
network-layer trust management is unspecified and relegated not viable at the network layer. Even if we assume that routers
to individual applications. A detailed discussion of this topic know all possible application trust models, establishing trust in
can be found in [52]. content is complicated and expensive. For instance, traversing
a PKI hierarchy requires routers to fetch and verify public key
MF places trust in the principal. Depending on the principal
certificates until a trusted anchor is reached.
type, trust may be established with: (1) hosts, similar to IPsec,
On the other hand, NDN interests can optionally be authen-
(2) content, similar to NDN, and (3) centralized or distributed
ticated using digital signature [3]. In a signed interest, the last
services. Trust semantics in XIA also vary depending on the
component of the name carries a signature computed by the
principal type. However, the intrinsic security feature of these
consumer. In case the interest carries a small payload7 , the
principals (described in Section VI) increases trustworthiness
signature will authenticate the consumer generating it, thus
of end-to-end communication and content retrieval. For in-
providing data origin authentication for interest payload.
stance, ensuring that a content hash matches its identifier
MF and XIA do not provide any data origin authentication
allows receivers (and caching routers) to trust that content.
at the network layer.
As shown in Section VI, an XIA address consists of a
DAG containing a (partial) path to the destination. To provide C. Peer Entity Authentication
trusted path selection for host-to-host communication, SCION
is integrated with XIA [93]. SCION [134] is an architecture IPsec provides peer entity authentication during SA estab-
that provides control and isolation for secure and highly lishment of a secure communication. ISAKMP and IKE, the
6 Recall that IPv6 implements both AH and ESP as extension headers.
4 ISAKMP: Internet Security Association and Key Management Protocol. 7 An interest can carry a small payload to minimize delay in a communi-
5 Public keys in NDN are distributed as special content objects with type cations (e.g., 0.5 RTT rather than 1 RTT to retrieve the data), as well as to
KEY. An object of this type is signed by its issuer, i.e., a CA. support push-model communication of small data that fits in a single packet.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 12

IPsec’s protocols used to establish SAs, can achieve peer entity can always detect malicious manipulation. However, when
authentication using digital signature or pre-shared key. Digital content is requested using SCNs, data integrity is achieved
signatures requires the use of certificates, which bind entity by comparing the content hash to the last name component
identities to their public keys. The use of certificates implies of its name. Furthermore, only signed interests can provide
the existence of a trusted third party or a CA to create, sign and interest integrity.
properly distribute certificates. Pre-shared keys on the other In both MF and XIA, integrity is only available for content
hand requires the communicating parties to agree on the shared principal types. This is again due to the fact that such a prin-
secret key before communication begins. cipal identifier is generated based on the content hash itself.
In Nebula, ICING allows a sender to authenticate the entities Whenever a content is received, its hash is compared with its
issuing the necessary cryptographic tokens, i.e., PoCs. How- identifier to ensure content integrity. For other principal types,
ever, ICING design does not specify how PoCs are retrieved, MF and XIA defer integrity guarantees to the application.
nor does it specify how entities are authenticated [92].
At its current state, NDN does not provide peer entity E. Authorization and Access Control
authentication for consumers and producers. However, in case
Access control in IP is achieved by restricting access based
the authentication of one or both entities is necessary, applica-
on source and destination addresses. This is implemented using
tions can exploit some features provided by the network layer.
Access Control Lists (ACLs) [32], which contain a set of rules
Considering consumers, signed interests can facilitate their
that grant or deny access to network resources. When imple-
authentication. Whereas for producers, content signature can
mented in routers, ACLs specify whether a received packet
ensure that the content is generated by the expected producer.
will be forwarded further to the next hop, or simply getting
Moreover, if interests must be satisfied by producers only (and
dropped. Whereas host ACLs are used to decide whether to
not in-network caches), they should carry unique names that
forward packets up the stack towards the application. Since IP
avoid cache hits and guarantee their delivery to corresponding
does not natively provide packet integrity, address spoofing can
producers.
be used to circumvent ACL rules. Employing IPsec, however,
Similar to NDN, MF and XIA do not provide peer entity
prevents such actions.
authentication. However, the usage of self-certifying identities
In Nebula, paths must be established before communication
as principal identifiers facilitates entity authentication. Recall
begins, i.e., clients must obtain required PoC tokens. There-
that for host, network, and service principals, identifiers are
fore, access control can be implemented by the consent server
generated by computing the hash of the public key asso-
granting or denying PoC requests. Traffic sent without valid
ciated with these principals. Therefore, entity authentication
PoC tokens can be easily detected and dropped.
can be achieved by ensuring that such principal identifiers
Unlike IP, enforcing access control in NDN should be
match their keys. Peer authentication for content principals
done based on content and not network entities. Although not
can be achieved similar to NDN since such principals are
implemented in practice, ACLs can still be used to implement
self-authenticating. Neither MF nor XIA provides a secure
access control. In this case, rules are applied on interest
mechanism for securely retrieving content identifiers.
messages and content objects based on the names they carry.
Longest-prefix can also be employed to grant or restrict access
D. Data Integrity to entire namespaces. Due to the fact that NDN interests do
not carry source addresses, access control on the consumer
Although IPv4 header contains the Header Checksum field
granularity can only be achieved in cases where interests are
that provides transmission error detection (a form of integrity
signed or carry some form of consumer identity [51].
check), it does not prevent packet manipulation. In fact, both
One way of providing access control in NDN is by using en-
versions of IP, introduced in Section II-A, completely delegate
cryption. Producers can encrypt their content and disseminate
integrity to IPsec AH and ESP protocols. Specifically, the
decryption keys to authorized consumers only. Such keys can
HMAC values in these protocol headers are used to achieve
be encapsulated in content objects and should not be cached.
integrity. Depending on the IPsec mode used, host-to-host,
One drawback of this approach is that it requires consumers
gateway-to-gateway, or host-to-gateway integrity guarantees
to issue at least two interests for each content (one to request
can be provided by both AH and ESP protocols. However,
the content itself and one to request the corresponding key).
AH provides integrity for the entire packet (except for mutable
Since MF and XIA can support different principal types,
fields), while ESP guarantees packet headers integrity only.
they facilitate the combination of both NDN- and IP-based
Each packet in Nebula carries a sequence of cryptographic
access control schemes. For content principals, access control
verifiers Vj , one for each hop on the path (see Section III-A
is done at the content granularity, similar to NDN, e.g., content
for details). The packet hash is used as part of Vj ’s calculation.
is encrypted using keys disseminated to only authorized users.
Therefore, ICING guarantees that neither the packet nor the
For all other principal types, ACLs can restrict access to hosts
path can be modified. Also, ICING is recommended only at
and other network services.
domain gateways [92]. Thus, integrity can only be guaranteed
by border routers. Within domains, such guarantees are de-
ferred to either the network-layer protocol or the application. F. Accountability
The way NDN provides integrity is through content sig- One of the main problems in IP is accountability. In fact, IP
nature. By verifying this signature, consumers and routers is subject to source address spoofing that lead to the inability

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 13

of tracing back the entity responsible for a particular action. Unfortunately, this only shifts the attack focus from the net-
A simple countermeasure against IP spoofing requires ASes work layer to consent servers: a single consent server might be
to implement egress filtering and ensure that all outgoing responsible for numerous routers in its domain. Thus, lowering
traffic carries source addresses owned by these ASes. IPsec the former’s ability to issue PoCs can effectively disable all
guarantees peer entity authentication when establishing SAs routers in the domain.
between hosts. Thus, accountability can be achieved. NDN is more resilient to bandwidth depletion attacks as
Nebula provides accountability through path establishment. compared to IP counterpart. Recall that NDN communication
All routers on a path consent to use the whole path before the adheres to the pull model, i.e., content is forwarded only in
communication begins. Moreover, the fact that these routers response to a prior interest. This prevents adversaries from
pre-agree on performing a specific set of actions on each flooding the network with unsolicited content. However, an
packet passing through allows the detection of any malicious adversary can still flood the network with a large number of
activities. interests.
NDN provides full accountability of producers. Since ev- Since MF and XIA use a communication model similar
ery content is signed by its producer, tracing the producer to IP, both are susceptible to bandwidth depletion attacks.
responsible for generating content is a trivial task. However, Countermeasures similar to those applicable to IP can be
accountability can not be provided if content is served from adopted. However, as mentioned above they can only lower,
router caches. Consumers accountability, on the other hand, not eliminate, the impact of such attacks.
can only be achieved when they issue signed interests, or The work in [97] suggested integrating STRIDE into XIA to
include their identities in the interests themselves. Otherwise, protect against DoS attacks. STRIDE [59] is an architecture
accountability can not be provided. resilient to bandwidth depletion (D)DoS attacks. It modifies
Both MF and XIA do not provide accountability at the SCION path establishment to perform tree-based bandwidth
network layer. However, signing requests and responses can allocation. Whenever a trusted domain root initiates the path
provide this feature in a similar fashion to NDN, especially establishment process, bandwidth is allocated as the path is
for content principals. Also, IPsec-similar techniques can be branching out as a tree from that root. This guarantees required
employed to provide accountability for other principal types. bandwidth for benign flows. STRIDE also supports long-term
static paths to provide high available connectivity.

G. Availability Routers Resource Exhaustion. Exhausting router resources


is another usual DoS and DDoS attack goal. For example,
Denial-of-Service (DoS) and Distributed Denial-of-Service
a NAT-enabled IP router might assemble fragments and, at
(DDoS) are well- known attacks on availability. In the fol-
any given time, might maintain multiple reassembly buffers.
lowing, we discuss DoS and DDoS attacks on the network
Each IP packet fragment includes a 16-bit field indicating the
layers of current and future Internet architectures discussed
original packet size. An attack can involve sending a single
above. We also discuss new (and possibly more serious) types
fragment with a very large original packet size. This forces the
of attacks triggered by the new architectures. We specifically
target router to allocate a new buffer and wait for remaining
exclude availability issues that arise due to network miscon-
fragments, which will never arrive.
figurations, disasters, hardware/software faults, or any other
causes that are not a direct consequence of an attack. Other types of attacks might be computational in nature. In
Nebula, an adversary can generate numerous packets forcing
Bandwidth Depletion Attacks. The current Internet is suscep- a router to perform all verification operations described in
tible to bandwidth depletion attacks [117] that aim to exhaust Section III. Such attacks cost very little for an adversary since
bandwidth of a specific link. These attacks can be conducted malicious packets can simply include invalid (e.g., random)
in two ways: (1) distributed – with packets sent at a relatively PoC and PoP values.
low rate by each attack source, or (2) centralized – a single In NDN, the PIT is a mandatory router component that
powerful adversary flooding the target link at a high rate. Due enables interest collapsing and content delivery without source
to today’s high bandwidth allocation and redundancy, the latter or destination addresses. However, since it is a limited and
are harder to perform. valuable resource makes the PIT susceptible to exhaustion. An
Several mitigation and prevention techniques have been adversary can easily generate and send (in close proximity)
proposed and implemented. Examples include: (1) tracing a large number of interests that fill up a router’s PIT. To
malicious traffic back to the source of the attack [26], [109], prevent interests from being collapsed, each can refer to
[114], (2) distinguishing between legitimate and malicious some nonsensical content. Once the PIT is full, a router can
traffic [21], [130], (3) using puzzles to increase the cost for either: drop new incoming interests, or remove old PIT entries
bandwidth consumption [41], [61], and (4) rate-limiting traffic to make space for new ones. Both options, however, can
that causes congestion [60], [81], [119]. However, none of the adversely impact past or future interests. This type of attack
above is a panacea. is called Interest Flooding (IF).
Bandwidth depletion at the data plane is harder to mount Unfortunately, there is no comprehensive remedy for IF
in Nebula, since senders (potential adversaries) must obtain attacks. Although several countermeasures have been pro-
consent of all nodes on a path before sending packets. Thus, posed, they are ineffective against smart adversaries and only
unauthorized packets are dropped by adversary-facing routers. manage to lower the volume of IF attacks [10], [35]. One

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 14

comprehensive, though drastic, remedy is to eliminate the PIT b) Cache pollution: Pollution is another type of (D)DoS
– the main target of IF attacks. For this reason, [53] suggests attacks against router caches. In such attacks, adversaries
a modified Content-Centric Networking (CCN) architecture attempt to manipulate reference locality of caches, causing
without router PITs. incorrect decisions made by cache eviction strategies. This
Router resource exhaustion attacks do not apply to MF. causes routers to possibly evict popular content reducing the
Similar to IP routers, MF routers do not perform expensive overall content distribution performance. NDN, MF, and XIA
cryptographic operation nor do they handle per connection- are all susceptible to this attack.
state. Moreover, MF does not implement NAT, rendering NAT- Conti et al. discuss this attack in [38]. It is shown that
based attacks irrelevant. with even limited adversarial resources, a highly effective
cache pollution attack can be mounted. In fact, even small
Cache-Related Attacks. Despite the benefits of in-network
cache locality manipulation can cause a significant content
caching, it prompts new types of (D)DoS attacks that are
distribution disruption [46]. It is also shown in [38] that
not relevant to today’s Internet: content poisoning and cache
launching pollution attacks on large networks is relatively easy,
pollution. We now discuss resiliency of NDN, MF, and XIA
and smart adversaries reduce the effectiveness of proposed
against these attacks. Nebula is excluded since it does not
countermeasures.
provide in-network caching.
Cache pollution attacks do not prevent users from retrieving
a) Content poisoning: Content poisoning occurs when
the requested data. Instead, they negatively effect the perfor-
an adversary injects fake content into router caches. A fake
mance of content distribution, and eliminate the benefits of
content is not generated by a benign producer and, conse-
in-network caching.
quently, does not satisfy user requests. If cached in routers,
such content is used to satisfy future requests. H. Data Confidentiality
Since NDN adheres to the pull model makes it harder, yet
still feasible, to inject fake content into router caches, in at The natural way to achieve data confidentiality at the
least two ways: network layer is by using encryption.
IP does not provide data confidentiality. This is done by
• Reactive: the adversary is a node eavesdropping or con-
using IPsec. The level of confidentiality depends on the mode
trolling a link, e.g., an upstream malicious router. The
of operation. In transport mode, ESP only encrypts the IP
adversary responds to interests on that links with a fake
packet payload and data confidentiality is host-to-host. Tunnel
content that is cached in all downstream routers.
mode extends confidentiality to the entire encapsulated IP
• Proactive: this method involves the adversary that, an-
packet, including both payload and header. However, data
ticipating demand for certain content, issues one or more
confidentiality can only be achieved in host-to-gateway or
bogus interests (perhaps from strategically placed zombie
gateway-to-gateway scenarios. Also, ESP confidentiality is
consumers), before genuine interests are issued. The
not generally effective against active adversaries. It has been
adversary then replies with fake content (from a set of
demonstrated that achieving confidentiality without a strong
compromised routers or compromised producers) thus
integrity mechanism, or even applying integrity before encryp-
pre-poisoning the caches of all routers forwarding the
tion, can only protect against passive adversaries [25], [44],
bogus interests.
[68]. Thus, even though IPsec provides confidentiality, poor
[52] investigated the causes of content poisoning and usage practices can negate its benefits.
proposed a simple approach for its full mitigation. The main Nebula’s ICING-based network layer does not natively
idea is for consumers and producers to collaborate in providing provide data confidentiality. Instead, it can be achieved by
routers with enough contextual trust information to perform combining ICING with end-to-end encryption of the packet
a single signature verification per content.8 This approach is payload.
captured by a simple tenet called Interest Key Binding (IKB) Data confidentiality in NDN can be attained by encrypting
rule. content payload. This is not supported by the architecture and
An orthogonal content poisoning mitigation mean is the is left to the application. However, even if content is encrypted,
use of SCNs. By definition, an SCN contains a value that the fact that it carries a human-readable name might leak
(uniquely) identifies the principal to which it refers. In case information about its data.
of a content principal in MF and XIA, and content objects MF and XIA provides content principal confidentiality using
in NDN, an SCN is the hash of the data itself. When a user methods similar to the those used in NDN. Fortunately, and
requests content using SCN, the network guarantees that re- due to the fact that such principal identifiers are generated
quested content will be correctly delivered. As a result, MF and using the hash of the content itself, inspecting them does
XIA obviate content poisoning attacks, by design. It is worth not leak information about the encrypted content. Moreover,
mentioning that using SCNs does not prevent adversaries from confidentiality of data communicated between host, network
injecting fake content in router caches. Instead, it guarantees and service principals can be achieved using similar techniques
that benign users will not receive such fake content. In order to to IPsec.
use SCNs, the system needs to be bootstrapped without them,
e.g., by using IKB, as described above. I. Traffic Flow Confidentiality
8 This assumes that in the near future, public key-based signature verification It is well known that encryption does not protect against
will be available in hardware and will be achievable at line speed. statistical traffic analysis – attacks that monitor traffic in order

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 15

TABLE I
N ETWORK S ECURITY F EATURES C OMPARISON

IP/IPsec Nebula NDN MF XIA

Trusted Model Hierarchical. Hierarchical. Hierarchical. Hierarchical. Distributed.

Trusted Entity Host. Forwarding nodes. Content. Host, Content, Service. Host, Content, Service.
Trust

Trust Management PKI + certificates, shared PoC tokens. Certificates. Distributed architecture Undefined.
keys. + certificates.

Coverage Gateway-to-Gateway, None. Producer-to-Consumer. None. None.


Host-to-Gateway.
Data Origin Auth.

Type of packet Every that belongs to an None. Content, Interest if None. None.
IPsec SA. signed.

Mechanism HMAC. None. Signature. None. None.

Authenticated Host, Gateway. Consent Server. None. None. None.


Peer Auth.

Entity

Mechanism Signature, Shared key. PoC. None. None. None.

Coverage Gateway-to-Gateway, Host-to-Forwarding Producer/Cache-to- Producer/Cache-to- Producer/Cache-to-


Host-to-Gateway. nodes. Consumer. Consumer. Consumer.
Integrity

Type of packet Every. Every. Content, Interest if Content. Content.


signed.

Mechanism IPsec tunnel + HMAC. Hash. Signature. Hash. Hash.

Enforced on Router, Host. Consent Server. Router, Producer. Router, Host. Router, Host.
Accountability Authz. & Access Cont.

Mechanism ACL. ACL. ACL, Encryption. ACL. ACL.

Entity accounted Host. Host. Producer, Consumer. None. None.

Mechanism Egress Filter on router, Path Consent. Signature in Content or None. None.
IPsec channel. Interest packets.

Bandwidth No architectural design Path consent can block Pull model prevents No architectural design No architectural design
Depletion Attacks countermeasures attacks. Consent Servers flooding with content. countermeasures. countermeasures.
are Single Point Of Fail- Weak to interest
ure. flooding.
Routers Resource Weak to fragmentation Weak to attack targeting Weak to Interest Flood- None. None.
Availability

Exhaustionn attack on NAT-enabled path consent verification ing attack on PIT.


IP routers. on routers.
Cache-Related At- None. None. Weak to Content poi- SCN as countermeasure SCN as countermeasure
tacks soning. IKB rules as to Content poisoning. to Content poisoning.
countermeasure to con- Weak to cache pollution. Weak to cache pollution.
tent poisoning. Weak to
cache pollution.

to extract properties, such as volume and timing [105]. traffic and flow confidentiality.
IPsec provides some traffic flow confidentiality by padding
packet payloads to hide their size patterns. However, according
Another architecture-agnostic alternative is to add artificial
to IPsec specifications, this is not mandatory and, therefore,
delays to communications to better hinder time-based attacks.
may not be supported in all IPsec implementations [110].
This, however, comes at the expense of increasing end-to-end
NDN, MF, Nebula and XIA are all susceptible to traffic latency and reducing overall network performance, especially
analysis attacks Fortunately, padding can be used to provide for time-sensitive traffic.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 16

J. Anonymous Communication because such addresses might include (part of) the path to the
destination, as described in Section VI. Due to the similarity
IP (with or without IPsec) does not support anonymous to IP with respect to the communication model adopted, both
communication. This is mainly because source and destination MF and XIA can use approaches developed to preserve users
addresses are in the clear in packet headers. However, partial anonymity in IP networks. For instance, Tor can be used to
anonymity can be achieved using the tunnel mode of IPsec protect MF and XIA host principals’ anonymity [82].
along with ESP. This is because tunnel mode allows the ESP
protocol to encrypt the original IP packet along with the source
and destination addresses, and it encapsulates that packet into a VIII. R ESOLUTION S ERVICES S ECURITY
new one with a new header reflecting gateway addresses. This Resolution service is a fundamental part of the current In-
combination hides end-host identities among the set of other ternet architecture. It maps human-readable names to routable
hosts connected to respective end-networks. However, this is network addresses. As mentioned above, new Internet archi-
only effective if the adversary is eavesdropping on the link tectures also require similar resolution services to operate. In
between the two gateways and is not located inside one of the this section we compare the security and privacy features of
end-networks. Furthermore, in case of host-to-gateway tunnel the various resolution services proposed in FIA projects. We
mode, only anonymity of hosts located behind the gateway is exclude Nebula and XIA since they do not propose a new
preserved. resolution service and only exploit the existing DNS, and its
Crowds [106] is one of the first proposals to achieve user security extensions.
anonymity. In it, a message is randomly forwarded between We consider the following security features: trust, data
group members before it reaches its destination. Therefore, origin authentication, data integrity, peer entity authentication,
none of the group members nor the end recipient learn the authorization and access control, accounting, data confiden-
actual source of the message. The Onion Router (Tor) [120] tiality and availability. We consciously exclude other privacy-
is another method that provides anonymous communication related features, i.e., traffic flow confidentiality and anonymous
through a “circuit.” Circuits are multi-hop encrypted commu- communication, since we believe they should be provided at
nication channels established using at least three Tor nodes. the network layer. We summarize our comparison on security
Theoretically, Tor guarantees anonymity with respect to an and privacy features in resolution services in Table III.
adversary controlling, at most, two Tor nodes. However, flawed
Tor implementations can reduce its provided anonymity level A. Trust
[27].
DNSSEC introduces the notion of trust into DNS. It
Hosts anonymity is not provided by ICING-based Nebula.
considers authoritative servers as trusted entities responsible
By inspecting packet headers, eavesdroppers can easily de-
of maintaining and securely providing the correct mapping
termine a packet’s source, as well as the path it traversed.
between human-readable domain names and corresponding
However, host anonymity can be achieved by replacing ICING
IP addresses. Recall that each DNSSEC server signs the
with TorIP [74], thus resulting in a level of anonymity similar
resource records (name-to- IP mappings) of its respective
to that provided by Tor in today’s Internet.
domain. Trustworthiness of such servers is ensured by a
Unlike IP, NDN has some features that facilitate anonymous chain-of-trust model that resembles the domains hierarchical
communication. A PIT allows interest messages and content organization. The top-level domain resides at the root of
objects to only carry the requested content name without this chain. DNSCurve considers a different attacker model,
any consumer-related information. While this help to protect where external attackers (malicious non-DNSCurve servers)
consumer’s privacy form on-path observers inspecting pack- try to modify queries and/or responses, or to mount DoS
ets deep in the core network, its efficacy will decrease as attacks. Mitigating such attacks requires additional trust in
the observer moves closer to the consumer. At the network every DNSCurve-enabled server in the system.
access (e.g., wireless access point or a broadband network Similar to DNSSEC, NDNS applies the same notion. Au-
gateway) an observer can easily correlate interests with the thoritative server are trusted entities and their trustworthiness
consumer issuing them. If the observer sits multiple hops far is ensured by a similar chain-of-trust model.
away from the consumer, he will only be able to correlate GNRS, on the other hand, adopts a different approach.
interests with a set of consumers (i.e., all the consumers Every network is responsible of providing signed GUID-
reachable from the observer). Moreover, Compagno et al. NA mappings. Thus, verifying these signatures ensures their
show in [34] that off-path adversaries can abuse the NDN validity. This also prevents (compromised) GNRS from ma-
content caching and forwarding state to determine consumers’ nipulating GUID-NA mappings without being detected.
location. DiBenedetto et al. proposed ANDāNA [47], a tool
that provides a level of anonymity similar to Tor, while
requiring only two intermediate nodes, instead of three. B. Data-origin Authentication and Data Integrity
MF and XIA suffer from the same privacy and anonymity DNSSEC provides data-origin authentication and data in-
problems as IP. Packets contain both source and destination tegrity by requiring: (1) authoritative servers to sign each of
GUIDs (or principal identifiers), thus revealing the hosts their resource records, and (2) resolvers to verify the validity
involved. To make the matter worse, XIA packets path can be of these signatures and their corresponding public keys. This
revealed by inspecting their destination DAG addresses. This is prevents adversaries from injecting bogus data into the DNS

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 17

TABLE II
N ETWORK P RIVACY F EATURES C OMPARISON

IP/IPsec Nebula NDN MF XIA

Coverage Gateway-to-Gateway, Host-to-Host. Producer-to-Consumer. Host-to-Host. Host-to-Host.


Data Conf.

Host-to-Gateway.

Mechanism IPsec ESP header (pay- ICING + end-to-end en- Payload encryption. End-to-end encryption. End-to-end encryption.
load encryption). cryption. Human-readable name
might leak information.
Traffic flow Conf.

Coverage Gateway-to-Gateway, None. Producer-to-Consumer. None. None.


Host-to-Gateway.

Mechanism Padding (no mandatory None. None. None. None.


on IPsec specification).

Level of anonymity Partial using IPsec in None. Partial, consumer has no None. None.
Anonymous comm.

tunnel mode. address. Router’s state


can be used to de-
anonymize consumers.
Additional Mecha- Tor. TorIP. Andana. Tor. Tor.
nism to achieve full
anonymity

system. Signing every response resource record is an expensive particular, NDNS servers can sign the gaps between existing
operation that authoritative server should not perform at run- names. Furthermore, Compagno et al. proposed in [36] the
time. Adversaries can abuse such costly operation to launch use of a Bloom filter [28] to defeat the aforementioned DoS
(D)DoS attacks against authoritative servers. To this end, attacks. This, however, requires some changes in the NDN
resource record signatures should always be generated in architecture as well as the introduction of a new content type.
advance. While this method can be easily applied in case GNRS also provides data-origin authentication and integrity
resolvers asks for existing domain names, it does not work by means of GUID-NA mapping signatures. The main differ-
for a non-existing domain names. DNS uses the NXDOMAIN ent between GNRS and DNSSEC is that the former does not
resource records to inform a resolver that the queried name assume that GNRS servers are trusted [75], while the latter
does not exist. However, providing data-origin authentication requires all authoritative servers to be trusted.
and integrity for NXDOMAIN resource records can not be
done by generating the signature in advance, because of the C. Peer Entity Authentication
number of possible non-existing names is infinite. To solve In DNS, and DNSSEC, there is no entity authentication
this problem, DNSSEC introduces a new record type called the between a resolver and a DNS server. Resolvers usually know
NextSECure (NSEC) resource record. Specifically, assuming the IP address of a DNS server which is used to initiate
a canonical ordering of the domain names, a NSEC record queries. Usually, such IP address is manually configured on
contains two consecutive existing names in the canonical the resolver or obtained through DHCP and considered valid.
ordering, thus describing the gaps between them. Such records Using a TLS connection between resolvers and DNS servers
are signed and used as authenticated denial of existence for can provide entity authentication [29], [135]. Authentication
non-existing names. Since NSEC records contain existing among DNS servers is obtained through Transaction sig-
names, their signatures can be calculated a priori. DNSCurve natures (TSIG) [127]. TSIG involves pairwise keys shared
guarantees integrity of queries and responses exchanged with among DNS servers and used to secure dynamic updates,
next-hop servers. However, it does not guarantee data-origin zone transfers and recursive queries. Moreover, in case of
authentication. dynamic updates generated from DNS clients, a signature is
In NDNS, query responses are carried in content object used to authenticate these clients, and validate the update.
payloads, thus data-origin authentication and integrity is in- Similar to DNS and DNSSEC, DNSCurve does not provide
herited from NDN. One difference between DNSSEC and entity authentication by default. However, this could be easily
NDNS resides in the granularity of these authentication and achieved by associating client public keys with certificates.
integrity guarantees. While DNSSEC can offer such security NDNS follows the same approach of DNS by not providing
properties per individual resource record or resource record entity authentication. However, the fact that both NDNS
set, the fact that a NDNS record is carried in a content object users and servers are regular NDN consumers and producers,
can only guarantee the authentication and integrity of said respectively, allows approaches similar to what is proposed in
record. Although this is a clear restriction in the flexibility and Section VII-C to be adopted. Furthermore, securing dynamic
scalability of the protocol, it does not jeopardize its security updates requires NDNS clients to have previously shared their
[11]. In order to overcome DoS attacks due to requests for non- certificate with the NDNS servers. Signing the updates will
existing names, NDNS adopts methods similar to DNSSEC. In then authenticate them.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 18

Unlike DNS and NDNS, GNRS authenticates every client approach can not achieve an efficient load balancing because
issuing requests (query, update and delete) by retrieving the it does not consider replica workloads and network traffic.
corresponding certificate, from NCS, and verifying the GUID DNS can be exploited to launch (D)DoS amplification at-
authenticity. GNRS clients can ensure server authentication by tacks against other hosts. These attackstake advantage of open
performing similar steps, requesting certificates from NCS and DNS resolvers, and involve forwarding (D)DoS traffic through
verifying servers identities. DNS servers to amplify the volume of data being sent to a
target [39], [62]. This issue is exacerbated by DNSSEC [108],
which may be exploited by attackers to cause an amplification
D. Authorization and Access Control
effect of 50 or more times the original attack bandwidth [16],
Both DNS/DNSSEC and NDNS do not provide any form of [124]. DNSCurve has approximately the same amplification
access control. All resource records are publicly available to effect as regular DNS.
every host in the network. However, authorization and access DNS resolvers (not implementing DNSSEC protocol), and
control is provided for dynamic updates. With DNSCurve, on DNSCurve resolvers, can be subject to cache poisoning at-
the other hand, exchanged packets between are encrypted, and tacks. This attack is similar, in concept, to content poisoning
thus cannot be publicly accessed by other unauthorized entities described in Section VII-G. In DNS cache poisoning attacks,
in the network. the goal of the adversary is to inject spoofed responses
GNRS does not follow the same trend and consider access (name-IP mappings) in the resolver caches [116]. Injecting
control a crucial part of its design. Specifically, GNRS stores a false DNS responses can be achieved using a man-in-the-
set of access control policies along with GUID-NA mappings. middle attack in which the adversary satisfies requests with
Such policies regulate access to particular GNRS resources false DNS responses [116]. The introduction of data- origin
by specifying read and write permissions which blacklist and authentication in DNSSEC allows resolvers to verify the origin
whitelist certain user GUIDs. of data in DNS response, thus eliminating this attack.
NDNS follows the same hierarchical design of DNS. In
E. Accountability principles NDNS authoritative servers seems to offer the same
level of resilience to DDoS as DNS authoritative servers.
DNS/DNSSEC guarantees accountability only for secure Furthermore, NDNS envisions the use of a set of secondary
DNS dynamic updates [129]. This is because such requests servers to balance the workload, which was proven to be
must in fact be signed by their originators. DNSCurve allows not effective. The same anycast approach used in DNS could
accountability for queries, since they contain client public be employed in NDNS. Such forwarding strategy must be
keys. implemented by NDN routers. Moreover, NDNS is susceptible
NDNS does not provide any mechanism for accountability. to content poisoning attacks. Fortunately, the same counter-
The fact that NDNS users and servers are consumers and measures described in Section VII-G can be effective.
producers allows the adoption of similar approaches described GNRS design appears to be more resilient to DDoS than
in Section VII-F. DNS design. In fact, GNRS does not adopt a hierarchical
GNRS uses a different approach and mandates GNRS structure, instead it distributes the GUID-NA mappings among
clients to sign every request. By doing so, accountability is a number of replicas using Distributed Hashtables (DHT)
provided for all insert, update and query requests. maintained by all the ASes in the Internet. This allows GNRS
to easily scale and distribute a DDoS attack.
F. Availability
As a public available service, DNS is subject to (D)DoS G. Data Confidentiality
attacks which jeopardize its availability. In particular, adver- Neither DNS nor DNSSEC provide confidentiality. Queries
saries can flood authoritative servers with a large number of and resource records are never encrypted by authoritative
query requests to exhaust their resources.9 Although the use servers and are always exchanged in cleartext. One way of
of DNS caching and redundancy servers reduce the effect achieving confidentiality in DNS/DNSSEC is to establish a
of DDoS, a number of such attacks have been successfully TLS session between resolvers and authoritative servers [29],
directed against root and top-level DNS servers in past years [135]. DNSCurve, however, uses symmetric encryption to
[2], [4], [5]. Many solutions have been presented that either: provide data confidentiality of DNS messages.
(1) require some changes in the DNS protocol [42], [88], Similarly, both NDNS and GNRS designs do not take confi-
[99], [104], or (2) propose new resolution services [58], dentiality into consideration. Fortunately, similar approaches to
[131]. Nowadays, DNS uses a single approach that does using TLS channels can be adopted. This feature is important
not require any modification to its architecture, which is the to provide private communication
adoption of “Anycast” [9]. In this case, a single DNS server is
replicated in different geographically locations among several IX. L ESSONS L EARNED AND F UTURE D IRECTIONS
ASes. Therefore, routing protocols forward DNS requests to
In this section, we summarize security and privacy features
the nearest server that can satisfy them [37]. However, this
provided by the network layer in the four studied FIA ar-
9 The use of secure dynamic updates involving asymmetric encryption chitectures, as well as their respective resolution services. We
increases the effect of the attack. also highlight missing features and outline directions for future

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 19

TABLE III
R ESOLUTION S ERVICES S ECURITY & P RIVACY F EATURES C OMPARISON

DNS/DNSSEC NDNS GNRS

Trusted Model Hierarchical. Authoritative Servers Hierarchical. Authoritative Servers Distributed. Hosts, DHCP servers,
are trusted for their respective do- are trusted for their respective do- Border routers must cooperate.
mains. Delegation is supported mains. Delegation is supported

Trusted entity Authoritative Server. Authoritative Server. None.


Trust

Trust Management PKI + certificates, shared keys. Certificates. Distributed architecture + certificates.

Coverage Authoritative Server-to-Client. Authoritative Server-to-Client. GNRS server-to-Client.


Data Origin Auth.

Type of packet Response. Response. Response.

Mechanism Signature. Signature. Self Certifying name + Signature.

Authenticated None. None. Client and GNRS server.


Peer Auth.

Entity

Mechanism None. None. Signature.

Coverage Authoritative Server-to-Client. Authoritative Server-to-Client. GNRS Server-to-Client.


Integrity

Type of packet Response. Response. Request.

Mechanism Signature. Signature. Self Certifying name + Signature.

Enforced on None. None. GNRS Server.


Accountability Authz. & Access Cont.

Mechanism None. None. ACL.

Entity accounted Host updating DNS. None Client and host updating GNRS.

Mechanism Signature. None. Signature.

DNS Request IP “Anycast” distribute the number Secondary server to distribute the More resilient to flooding due to its
Availability

Flooding Attacks of request across many authoritative load + in network load-balancing distributed design.
servers. techniques.

Mechanism None. None. None.


Data Conf.

work. Finally, we briefly discuss the current implementation Nebula. At its current state, Nebula includes trust, data origin
status and performance characteristics of each architecture. authentication, peer entity authentication, data integrity, au-
thorization and access control, accountability, and availability
features. All of them are provided between senders and routers
A. Network Layer
implementing ICING, except for peer entity authentication
Overall, we believe that the NSF mandatory requirement that is guaranteed between senders and consent servers during
of Security and Privacy by Design has only been partially PoCs retrieval. With respect to IP and IPsec, Nebula certainly
accomplished. Table IV summarizes security and privacy fea- increases the security of intra-domain communication. How-
tures provided by each FIA architecture.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 20

TABLE IV
N ETWORK L AYER S ECURITY AND P RIVACY C OMPARISON

Network layers
Security & Privacy Features
Nebula NDN MF XIA
Trust 3 3 3 3
Data Origin Authentication } 3 7 7
Peer entity Authentication } } } }
Data Integrity } 3 7 7
Authorization and Access Control 3 } } }
Accountability 3 } } }
Data Confidentiality 7 3 7 7
Traffic Flow Confidentiality 7 7 7 7
Anonymous Communication 7 7 7 7
Availability } } } }
3indicates that a feature is present in the architecture.
7indicates that a feature is unavailable.
} indicates that a feature is partially available or the architecture provides a means to
facilitate its implementation by applications.

ever, it lacks inter-domain and end-to-end communication se- features. Currently, NDN provides: trust, data origin authen-
curity support, even if IPsec is used to establish a secure “pipe” tication, data integrity and data confidentiality. Other features
between communicating end-hosts. We believe that integration (e.g., peer entity authentication and accountability) are avail-
of new or existing mechanisms to support both inter-domain able only when derived from data origin authentication for
and end-to-end security deserves further investigation. both interest and content. Ubiquitous caching further compli-
Availability in Nebula is provided by path verification mech- cates achieving these two features. In fact, when a consumer
anism which prevents any adversary from sending unrequested obtains a content from an intermediate router’s cache, there is
data to perform bandwidth depletion attacks. However, ICING currently no way to provide peer entity authentication between
nodes and consent servers could be the target of a DoS attack, the consumer and the router providing the content. Similarly,
due to the heavy use of cryptographic operations. Consent NDN does not provide accountability for content use: the
servers can be another target for DoS attacks. In particular, distinction between a content served by its producer or from
an adversary can flood a server with an abnormal amount of a router’s cache.
request. If the target server controls a large number of routers, Availability is an aspect for which NDN provides some im-
the attack can effectively disable all of them. We believe that provements with respect to IP/IPsec. NDN reduces the amount
such attack deserves further investigation. of traffic both inside the network and at the producer by: (1)
By design, Nebula does not provide the three privacy fea- aggregating “matching” interests, and (2) serving matching
tures we considered in this paper: data confidentiality, traffic requests from local caches, when possible. Unfortunately, at
flow confidentiality, and anonymous communication. The first the same time NDN opens the door to new types of attacks.
two can be easily implemented via IPsec-like techniques, while Indeed, while the pull model communication prevents any
the latter can be achieved by adopting existing solutions, such adversary from flooding a host with non-requested content,
as TorIP [74]. Nevertheless, we believe these aspects in Nebula adversaries can exhaust router states (i.e., PIT and CS),
deserve further investigation. Specifically, Nebula should make decreasing the performance of a network. Even though several
these features available by design before any adoption in the countermeasures have been proposed, none of them has been
real world. Furthermore, anonymous communications conflicts chosen and implemented as part of the architecture.
with the current ICING design, which requires path establish-
ment for each communication. This is an issue of concern that The remaining security features: authorization and access
needs to be explored and, ideally, remedied. control, traffic flow confidentiality and anonymous communi-
From a feasibility perspective, ICING can be effectively cation are not provided by NDN at the network layer. Even
deployed in Internet backbone routers [92], despite its heavy if ACL can be implemented, NDN delegates access control
use of cryptographic operations at the data plane, and its to the application layer, which is responsible for encrypting
large header size10 . However, as reported in [92], this incurs content and distributing appropriate keys only to authorized
a higher normalized cost of 93% over IP, i.e., hardware cost consumers. Traffic flow confidentiality and anonymous com-
as equivalent gate count per unit of throughput. munication are not natively available. The former can be
provided by adopting existing approaches designed for IP
NDN. NDN moves hosts and interfaces into the background and IPsec, without any modification of the NDN architecture.
and focuses on content as its primary network-layer entity. The latter can be obtained by adopting solutions similar to
This strongly influences network-layer security and privacy the one presented in [47]. Note that NDN design improves
10 ICING’s header occupies approximately 18.3% of a 1514 bytes packet, privacy guarantees for consumers, since neither interest nor
compared to 1.3% with IP, on a path through 7 realms [91]. data packets carry consumers address. Nevertheless, consumer

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 21

privacy can still be compromised by motivated attackers [34]. TABLE V


Heavy use of digital signatures in NDN introduces a major R ESOLUTION S ERVICES S ECURITY & P RIVACY C OMPARISON
source of overhead in the network. This has been extensively Resolution Services
Security and Privacy Features
evaluated in [115]. To the best of our knowledge, no as- NDNS GNRS
sessment on the implications of router signature verification Trust 3 3
in NDN has been conducted. The only work considering Data Origin Authentication 3 3
the performance impact of signature generation by producers Peer entity Authentication 7 3
has been recently evaluated in [83]. From an interoperability Data Integrity 3 3
perspective, NDN can be used alongside with IP as an overlay Authorization and Access Control 7 3
network. Accountability } 3
MobilityFirst (MF). MF security features can be viewed Data Confidentiality 7 7
as a hybrid of end-to-end and content-based approaches of Availability } 3
IP/IPsec and NDN. In its current state, MF provides only 3indicates that a feature is present in the architecture.
7indicates that a feature is unavailable.
few security features: trust as well as authorization and access } indicates that a feature is partially available or the architecture
control. The adoption of SCNs to address hosts facilitates the provides a means to facilitate its implementation by applications.
implementation of data origin authentication, peer entity au-
thentication, and accountability. Peer entity authentication can
be achieved involving a simple challenge-response protocol It is worth mentioning that XIA’s performance is compara-
between the two peers. While this would guarantee end-to- ble with IP in core network routers [79].
end accountability, it is not enough for network accountability.
In order to achieve that, edge routers should prevent address B. Resolution Services
spoofing.
Nebula’s resolution service is used by the NVENT to
Data integrity and data confidentiality are currently not
perform path discovery. In NDN, the same service provides the
provided at network layer and it remains unclear whether MF
mapping between namespaces and the corresponding security
will delegate these aspects to upper layers. Traffic flow confi-
information, i.e., a mapping between public key(s) and name
dentiality and anonymous communication are also not natively
prefixes. In MF, the resolution service is actively involved in
provided. Existing approaches for traffic flow confidentiality
any communication guaranteeing the binding between GUIDs
designed for IP/IPsec can be easily imported. However, TOR-
and NAs. Finally, XIA’s DNS-based resolution service is used
like solutions for anonymous communication should be further
for the address/path resolution.
studied and developed. A relatively recent initial effort in
Although all architectures requires a resolution service, only
this direction is represented in [82]. Additionally, according
NDN and MF are actually investigating their own proposal.
to [71], the use of Disposable Identifiers [55], [72] is currently
Table V summarizes security and privacy features of NDNS
under examination to guarantee GUID-NA unlinkability. We
and GNRS.
believe that more research is needed to construct techniques
that take advantage of MF’s architectural idiosyncrasies. NDNS. NDNS borrows many features from DNS and
MF is somewhat effective against content poisoning attacks DNSSEC without introducing much novelty. NDNS involves
due to its usage of SCNs. Meanwhile, it does not consider the same notion of trust of DNSSEC in which servers are
other network attacks, such as bandwidth depletion and cache trusted entities. Moreover, NDNS queries and responses pro-
pollution. Current IPsec-like methods can be applied to mit- vide: data origin authentication, data integrity, accountability
igate these issues. Further work is necessary to provide new (only for dynamic updates), and availability. The last feature is
architecture-specific countermeasures. provided by server replication. However, while DNSSEC uses
To the best of our knowledge there is no large scale per- the “Anycast” technique to choose the closes server to the
formance assessment of MF. In [125], the authors performed resolver, in NDNS the network must be aware of all servers
some benchmarks on a commodity hardware, and reached a and implement specific forwarding strategies to balance the
maximum forwarding rate of 1 Gbps. We believe that further requests among them, which adds more complexities.
effort should be devoted to study and improve MF performance Peer entity authentication, authorization and access control,
to meet real-world requirements. as well as data confidentiality, are not provided. We believe
that NDNS should be enhanced to provide better availability
XIA. XIA’s main goal is to support communication between
and currently missing security features.
multiple and different principals. XIA security approach ex-
tends, de-facto, MF approach, where security focuses on two GNRS. GNRS is fundamentally different from DNS,
principals: content and hosts. XIA does not limit the number DNSSEC, and DNSCurve. In fact, since MF adopts a flat name
of principals but instead provides the freedom to design new structure, it also forces GNRS to use the same structure for
ones. To this end, XIA security is based on each principal its servers. This different organization has some side effects
intrinsic security feature. on the provided security features: servers are not assumed to
In its current state, XIA offers the same security and privacy be trusted. Also, data origin authentication is provided by the
features as MF. This is due to their similar approach in owner of the GUID and not by servers. GNRS also introduces
addressing principals using SCNs. authorization and access control of its stored information and

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 22

provides accountability and peer entity authentication for each [14] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman,
query and response. Finally, GNRS is more robust to DoS “A survey of information-centric networking,” IEEE Communications
Magazine, vol. 50, no. 7, pp. 26–36, 2012.
attacks than DNS. First, compromising one server does not [15] S. Akhshabi and C. Dovrolis, “The evolution of layered protocol stacks
affect others. Second, GNRS is designed to easily adapt to leads to an hourglass-shaped architecture,” SIGCOMM Computer Com-
network changes and to balance GUID-NA mapping among munication Review, vol. 41, no. 4, pp. 206–217, 2011.
[16] M. Anagnostopoulos, G. Kambourakis, P. Kopanos, G. Louloudakis,
many replicas based on locality of requests. and S. Gritzalis, “Dns amplification attack revisited,” Computers &
We believe that GNRS introduces good security improve- Security, vol. 39, pp. 475–485, 2013.
ments with respect to DNS, DNSSEC, and DNSCurve. The [17] T. Anderson, K. Birman, R. Broberg, M. Caesar, D. Comer, C. Cotton,
M. Freedman, A. Haeberlen, Z. Ives, A. Krishnamurthy et al., “Nebula-
only missing feature is data confidentiality. a future internet that supports trustworthy cloud computing,” Tech.
Rep., 2010.
[18] T. Anderson, K. Birman, R. Broberg, M. Caesar, D. Comer, C. Cotton,
X. C ONCLUSION M. Freedman, A. Haeberlen, Z. Ives, A. Krishnamurthy, W. Lehr, B. T.
Despite the unmitigated success of the current IP-based Loo, D. MaziÃĺres, A. Nicolosi, J. Smith, I. Stoica, R. van Renesse,
M. Walfish, H. Weatherspoon, and C. Yoo, “Nebula - a future internet
Internet architecture, lack of security considerations in its that supports trustworthy cloud computing,” Tech. Rep., 2010. [Online].
design led to numerous security and privacy problems, over Available: http://nebula-fia.org/papers/NEBULA-WP_TOC.pdf
the years. Thus, a key goal of any future Internet architectures [19] T. Anderson, K. Birman, R. Broberg, M. Caesar, D. Comer, C. Cotton,
M. J. Freedman, A. Haeberlen, Z. G. Ives, A. Krishnamurthy, W. Lehr,
must be to include – from the outset – a set of comprehensive B. T. Loo, D. Mazières, A. Nicolosi, J. M. Smith, I. Stoica, R. van
and extensible security and privacy features. Renesse, M. Walfish, H. Weatherspoon, and C. S. Yoo, “A Brief
This paper analyzed (mostly network-layer) security and Overview of the NEBULA Future Internet Architecture,” SIGCOMM
Computer Communication Review, vol. 44, no. 3, pp. 81–86, 2014.
privacy features of four prominent NSF-funded FIA architec- [20] T. Anderson, K. Birman, R. Broberg, M. Caesar, D. Comer, C. Cotton,
tures – Nebula, NDN, MobilityFirst and XIA – with IP/IPsec M. Freedman, A. Haeberlen, Z. Ives, A. Krishnamurthy, W. Lehr,
used as a point of reference in the analysis. Prior surveys B. Loo, D. MaziÃĺres, A. Nicolosi, J. Smith, I. Stoica, R. van Renesse,
M. Walfish, H. Weatherspoon, and C. Yoo, “The NEBULA Future
on future Internet architectures provide a limited, or even Internet Architecture,” in The Future Internet, ser. Lecture Notes in
no, comparison on security and privacy features. This paper Computer Science, A. Galis and A. Gavras, Eds., 2013, vol. 7858, pp.
provides a comprehensive and neutral analysis of salient 16–26.
[21] T. Anderson, T. Roscoe, and D. Wetherall, “Preventing internet denial-
security and privacy features (and issues) in these NSF-funded of-service with capabilities,” ACM SIGCOMM Computer Communica-
Future Internet Architectures. tion Review, vol. 34, no. 1, pp. 39–44, 2004.
As evident from this work, while each FIA architecture [22] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “RFC
4033: DNS security introduction and requirements,” 2005.
offers some innovative and effective security and privacy [23] M. Arye, R. Kiefer, K. Super, E. Nordström, M. J. Freedman, E. Keller,
features, none provides a comprehensive set thereof. T. Rondeau, and J. M. Smith, “Increasing network resilience through
edge diversity in nebula,” SIGMOBILE Mobile Computer Communica-
tion Review, vol. 16, no. 3, pp. 14–20, 2012.
R EFERENCES [24] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba, and B. Mathieu,
[1] “IPv6 extension headers review and considerations,” “A survey of naming and routing in information-centric networks,”
https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_ IEEE Communications Magazine, vol. 50, no. 12, pp. 44–53, 2012.
white_paper0900aecd8054d37d.html, accessed: May 26, 2016. [25] S. M. Bellovin, “Problem areas for the ip security protocols,” in
[2] “Nameserver dos attack october 2002.” [Online]. Available: http: Proceedings of the 6th Conference on USENIX Security Symposium,
//www.caida.org/projects/dns-analysis/ Focusing on Applications of Cryptography, 1996, pp. 21–32.
[3] “Signed interest.” [Online]. Available: http://named-data.net/doc/ [26] S. M. Bellovin, M. Leech, and T. Taylor, “Internet Draft: ICMP
ndn-cxx/current/tutorials/signed-interest.html traceback messages,” 2003.
[4] “Ultradns dos attack,” 2002. [Online]. Available: http: [27] A. Biryukov, I. Pustogarov, and R. Weinmann, “Trawling for tor hidden
//www.theregister.co.uk/2002/12/14/ services: Detection, measurement, deanonymization,” in Proceedings of
[5] “Icann factsheet for the february 6, 2007 root server attack,” the 34th IEEE Symposium on Security and Privacy, ser. S&P ’13, 2013,
2007. [Online]. Available: http://www.icann.org/announcements/ pp. 80–94.
factsheet-dns-attack-08mar07.pdf [28] B. H. Bloom, “Space/time trade-offs in hash coding with allowable
[6] M. Aamir and S. M. A. Zaidi, “Denial-of-service in content centric errors,” Communications of the ACM, vol. 13, no. 7, pp. 422–426,
(named data) networking: a tutorial and state-of-the-art survey,” Se- 1970.
curity and Communication Networks, vol. 8, no. 11, pp. 2037–2059, [29] S. Bortzmeyer, “Dns privacy considerations,” 2015.
2015. [30] J. Bound and Y. Rekhter, “Dynamic updates in the domain name system
[7] E. G. AbdAllah, H. S. Hassanein, and M. Zulkernine, “A survey of (dns update),” 1997.
security attacks in information-centric networking,” IEEE Communi- [31] R. Braden, “Ietf rfc 1122: Requirements for internet hosts-
cations Surveys & Tutorials, vol. 17, no. 3, pp. 1441–1454, 2015. communication layers,” 1989. [Online]. Available: https://tools.ietf.
[8] J. Abley and T. Manderson, “Nameservers for ipv4 and ipv6 reverse org/html/rfc1122
zones,” Tech. Rep., 2010. [32] H. Cankaya, “Access control lists,” in Encyclopedia of Cryptography
[9] J. Abley and K. E. Lindqvist, “Operation of anycast services,” 2006. and Security, H. C. van Tilborg and S. Jajodia, Eds., 2011, pp. 9–12.
[10] A. Afanasyev, P. Mahadevan, I. Moiseenko, E. Uzun, and L. Zhang, [33] K. Charlie, H. Paul, N. Yoav, and E. Pasi, “Ietf rfc 5996: Internet key
“Interest flooding attack and countermeasures in named data network- exchange protocol version 2 (ikev2),” 2010.
ing,” in IFIP Networking Conference, 2013, 2013, pp. 1–9. [34] A. Compagno, M. Conti, P. Gasti, L. V. Mancini, and G. Tsudik,
[11] A. Afanasyev, “Addressing operational challenges in named data “Violating Consumer Anonymity: Geo-locating Nodes in Named Data
networking through ndns distributed database,” Ph.D. dissertation, Networking,” in Proceedings of the 13th International Conference on
University of California Los Angeles, 2013. Applied Cryptography and Network Security, ser. ACNS ’15, 2015.
[12] A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang, “Packet frag- [35] A. Compagno, M. Conti, P. Gasti, and G. Tsudik, “Poseidon: Miti-
mentation in ndn: why ndn uses hop-by-hop fragmentation,” technical gating interest flooding ddos attacks in named data networking,” in
report NDN-0032, rev. 1, Tech. Rep., 2015. Proceedings of the 38th Annual IEEE Conference on Local Computer
[13] A. Afanasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, “Map-and- Networks, ser. LCN ’13, 2013, pp. 630–638.
encap for scaling ndn routing,” University of California, Los Angeles, [36] A. Compagno, M. Conti, C. Ghali, and G. Tsudik, “To nack or not to
Tech. Rep, 2015. nack? negative acknowledgments in information-centric networking,”
in Proceedings of the 24th International Conference on Computer
Communication and Networks, ser. ICCCN ’15, 2015, pp. 1–10.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 23

[37] D. Conrad, “Towards Improving DNS Security, Stability, and [61] A. Juels and J. G. Brainard, “Client puzzles: A cryptographic counter-
Resiliency,” 2012. [Online]. Available: http://www.internetsociety.org/ measure against connection depletion attacks.” in Proceedings of the
sites/default/files/bp-dnsresiliency-201201-en_0.pdf 1999 Network and Distributed System Security Symposium, ser. NDSS
[38] M. Conti, P. Gasti, and M. Teoli, “A lightweight mechanism for detec- ’99, vol. 99, 1999, pp. 151–165.
tion of cache pollution attacks in named data networking,” Computer [62] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis, “Detect-
Networks, vol. 57, no. 16, pp. 3178–3191, 2013. ing DNS amplification attacks,” in International Workshop on Critical
[39] D. Dagon, C. Lee, W. Lee, and N. Provos, “Corrupted dns resolution Information Infrastructures Security, 2007, pp. 185–196.
paths: The rise of a malicious resolution authority,” in Proceedings [63] S. Kent, “RFC 4302: IP authentication header,” 2005.
of the 15th Network and Distributed System Security Symposium, ser. [64] ——, “RFC 4303: IP encapsulating security payload (ESP),” 2005.
NDSS ’08, 2008. [65] R. Khondoker, B. Nugraha, R. Marx, and K. M. Bayarou, “Security
[40] C. Dannewitz, D. Kutscher, B. Ohlman, S. Farrell, B. Ahlgren, and of selected future internet architectures: A survey,” in Proceedings of
H. Karl, “Network of information (netinf)–an information-centric net- the 8th International Conference on Innovative Mobile and Internet
working architecture,” Computer Communications, vol. 36, no. 7, pp. Services in Ubiquitous Computing, ser. IMIS ’14, 2014, pp. 433–440.
721–735, 2013. [66] T. Kivinen, B. Swander, A. Huttunen, and V. Volpe, “RFC 3947:
[41] D. Dean and A. Stubblefield, “Using client puzzles to protect tls.” in Negotiation of NAT-Traversal in the IKE,” 2005.
Proceedings of the 10th USENIX Security Symposium, vol. 42, 2001. [67] T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim,
[42] T. Deegan, J. Crowcroft, and A. Warfield, “The main name system: S. Shenker, and I. Stoica, “A data-oriented (and beyond) network
an exercise in centralized computing,” ACM SIGCOMM Computer architecture,” ACM SIGCOMM Computer Communication Review,
Communication Review, vol. 35, no. 5, pp. 5–14, 2005. vol. 37, no. 4, pp. 181–192, 2007.
[43] S. E. Deering, “RFC 2460: Internet protocol, version 6 (ipv6) specifi- [68] H. Krawczyk, “The order of encryption and authentication for pro-
cation,” 1998. tecting communications (or: How secure is ssl?),” in Advances in
[44] J. Degabriele and K. Paterson, “Attacking the ipsec standards in Cryptology – CRYPTO 2001, ser. Lecture Notes in Computer Science,
encryption-only configurations,” in Proceedings of the 28th IEEE J. Kilian, Ed., 2001, vol. 2139, pp. 310–331.
Symposium on Security and Privacy, ser. S&P ’07, 2007, pp. 335–349. [69] H. Krawczyk, R. Canetti, and M. Bellare, “RFC 2104: HMAC: Keyed-
[45] M. Dempsky, “IETF Internet-Draft: DNSCurve: Link-Level Security hashing for message authentication,” 1997.
for the Domain Name System,” 2010. [70] E. Lewis and A. Hoenes, “Dns zone transfer protocol (axfr),” Tech.
[46] L. Deng, Y. Gao, Y. Chen, and A. Kuzmanovic, “Pollution attacks and Rep., 2010.
defenses for internet caching systems,” Computer Networks, vol. 52, [71] J. Lindqvist and M. Gruteser, “Privacy in MobilityFirst Architecture.”
no. 5, pp. 935–956, 2008. [Online]. Available: http://mobilityfirst.winlab.rutgers.edu/documents/
[47] S. DiBenedetto, P. Gasti, G. Tsudik, and E. Uzun, “Andana: Anony- documents/Lindqvist.pdf
mous named data networking application,” in Proceedings of the 18th [72] J. Lindqvist and J.-M. Tapio, “Protecting privacy with protocol stack
Annual Network & Distributed System Security Symposium, ser. NDSS virtualization,” in Proceedings of the 7th ACM workshop on Privacy
’11, 2011. in the electronic society, ser. WPES ’08. ACM, 2008, pp. 65–74.
[48] N. Fotiou, P. Nikander, D. Trossen, and G. C. Polyzos, “Developing [73] V. Liu, D. Halperin, A. Krishnamurthy, and T. Anderson, “F10: A
information networking further: From psirp to pursuit,” in International fault-tolerant engineered network,” in Proceedings of the 10th USENIX
Conference on Broadband Communications, Networks and Systems. Conference on Networked Systems Design and Implementation, ser.
Springer, 2010, pp. 1–13. NSDI ’13, 2013, pp. 399–412.
[49] J. Gersch and D. Massey, “Rover: Route origin verification using dns,” [74] V. Liu, S. Han, A. Krishnamurthy, and T. Anderson, “Tor Instead of IP,”
in Proceedings of the 22nd International Conference on Computer in Proceedings of the 10th ACM Workshop on Hot Topics in Networks,
Communications and Networks, ser. ICCCN ’13, 2013, pp. 1–9. ser. HotNets ’11, 2011, pp. 14:1–14:6.
[50] C. Ghali, A. Narayanan, D. Oran, G. Tsudik, and C. A. Wood, “Secure [75] X. Liu, W. Trappe, and Y. Zhang, “Secure name resolution for
fragmentation for content-centric networks,” in Proceedings of the identifier-to-locator mappings in the global internet,” in Proceedings
2015 IEEE 14th International Symposium on Network Computing and of the 22nd International Conference on Computer Communications
Applications, ser. NCA ’15, 2015, pp. 47–56. and Networks, ser. ICCCN ’13, 2013, pp. 1–7.
[51] C. Ghali, M. A. Schlosberg, G. Tsudik, and C. A. Wood, “Interest- [76] B. T. Loo, T. Condie, M. Garofalakis, D. E. Gay, J. M. Hellerstein,
based access control for content centric networks,” in Proceedings of P. Maniatis, R. Ramakrishnan, T. Roscoe, and I. Stoica, “Declarative
the 2nd International Conference on Information-Centric Networking, networking: language, execution and optimization,” in Proceedings of
ser. ICN ’15, 2015, pp. 147–156. the 2006 ACM SIGMOD international conference on Management of
[52] C. Ghali, G. Tsudik, and E. Uzun, “Network-layer trust in named- data, ser. SIGMOD ’06, 2006.
data networking,” ACM SIGCOMM Computer Communication Review, [77] ——, “Declarative networking,” Communications of the ACM, vol. 52,
vol. 44, no. 5, pp. 12–19, 2014. no. 11, pp. 87–95, 2009.
[53] C. Ghali, G. Tsudik, E. Uzun, and C. A. Wood, “Living in a pit-less [78] R. Lutz, “Security and privacy in future internet architectures -
world: A case against stateful forwarding in content-centric network- benefits and challenges of content centric networks,” CoRR, vol.
ing,” arXiv preprint arXiv:1512.07755, 2015. abs/1601.01278, 2016.
[54] D. Griffin, M. Rio, P. Simoens, P. Smet, F. Vandeputte, L. Vermoesen, [79] M. Machado, C. Doucette, and J. W. Byers, “Linux XIA: an Interoper-
D. Bursztynowski, F. Schamel, and M. Franke, “Service-centric net- able Meta Network Architecture to Crowdsource the Future Internet,”
working,” Handbook of Research on Redesigning the Future of Internet in Proceedings of the Eleventh ACM/IEEE Symposium on Architectures
Architectures, 2015. for networking and communications systems, ser. ANCS ’15. IEEE
[55] M. Gruteser and D. Grunwald, “Enhancing location privacy in wireless Computer Society, 2015, pp. 147–158.
lan through disposable interface identifiers: a quantitative analysis,” [80] P. Mahadevan, E. Uzun, S. Sevilla, and J. Garcia-Luna-Aceves, “Ccn-
Mobile Networks and Applications, vol. 10, no. 3, pp. 315–325, 2005. krs: A key resolution service for ccn,” in Proceedings of the 1st
[56] T. Hain, “RFC 2993: Architectural implications of nat,” 2000. International Conference on Information-centric Networking, ser. ICN
[57] D. Han, A. Anand, F. Dogar, B. Li, H. Lim, M. Machado, A. Mukun- ’14, 2014, pp. 97–106.
dan, W. Wu, A. Akella, D. G. Andersen, J. W. Byers, S. Seshan, and [81] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and
P. Steenkiste, “Xia: Efficient support for evolvable internetworking,” S. Shenker, “Controlling high bandwidth aggregates in the network,”
in Proceedings of the 9th USENIX Conference on Networked Systems ACM SIGCOMM Computer Communication Review, vol. 32, no. 3, pp.
Design and Implementation, ser. NSDI ’12, 2012, pp. 309–322. 62–73, 2002.
[58] M. Handley and A. Greenhalgh, “The case for pushing DNS,” in [82] K. Manandhar, B. Adcock, and X. Cao, “Preserving the Anonymity
Hotnets-IV, 2005. in MobilityFirst networks,” in Proceedings of the 23rd International
[59] H.-C. Hsiao, T. H.-J. Kim, S. Yoo, X. Zhang, S. B. Lee, V. Gligor, Conference on Computer Communication and Networks, ser. ICCCN
and A. Perrig, “STRIDE: sanctuary trail–refuge from internet DDoS ’14. IEEE, 2014, pp. 1–6.
entrapment,” in Proceedings of the 8th ACM SIGSAC symposium on [83] X. Marchal, T. Cholez, and O. Festor, “Server-side performance
Information, computer and communications security, ser. CCS ’13, evaluation of ndn,” in Proceedings of the 3rd ACM Conference on
2013. Information-Centric Networking, ser. ICN ’16. ACM, 2016, pp. 148–
[60] J. Ioannidis and S. M. Bellovin, “Implementing pushback: Router-based 153.
defense against ddos attacks,” 2002. [84] A. Mason, CCSP Self-Study: Cisco Secure Virtual Private Networks
(CSVPN), 2004.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 24

[85] D. Maughan and M. Schneider, “Internet security association and key [111] I. Seskar, K. Nagaraja, S. Nelson, and D. Raychaudhuri, “MobilityFirst
management protocol (isakmp),” 1998. Future Internet Architecture Project,” in Proceedings of the 7th Asian
[86] J. McCann, J. Mogul, and S. E. Deering, “RF 1981: Path MTU Internet Engineering Conference, ser. AINTEC ’11, 2011, pp. 1–3.
discovery for IP version 6,” 1996. [112] A. Sharma, X. Tie, H. Uppal, A. Venkataramani, D. Westbrook, and
[87] R. McKinney, W. A. Montgomery, H. Ouibrahim, P. Sijben, and J. J. A. Yadav, “A global name service for a highly mobile internetwork,”
Stanaway, “Service-centric networks,” Bell Labs Technical Journal, SIGCOMM Computer Communication Review, vol. 44, no. 4, pp. 247–
vol. 3, no. 3, 1998. 258, 2014.
[88] E. Meshkova, J. Riihijärvi, M. Petrova, and P. Mähönen, “A survey [113] R. W. Shirey, “Internet security glossary, version 2,” 2007.
on resource discovery mechanisms, peer-to-peer and service discovery [114] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio,
frameworks,” Computer Networks, vol. 52, no. 11, pp. 2097–2128, S. T. Kent, and W. T. Strayer, “Hash-based ip traceback,” in ACM
2008. SIGCOMM Computer Communication Review, vol. 31, no. 4, 2001,
[89] P. Mockapetris, “RFC 1035: Domain names - implementation and pp. 3–14.
specification,” 1987. [115] W. So, A. Narayanan, and D. Oran, “Named data networking on
[90] S. Mukherjee, A. Baid, I. Seskar, and D. Raychaudhuri, “Network- a router: Fast and dos-resistant forwarding with hash tables,” in
assisted multihoming in the mobilityfirst future internet architecture,” Proceedings of the ninth ACM/IEEE symposium on Architectures for
Tech. Rep. 415, 2013. [Online]. Available: http://mobilityfirst.winlab. networking and communications systems. IEEE Press, 2013, pp. 215–
rutgers.edu/documents/Mukherjee-MFMultihoming-TR415_000.pdf 226.
[91] J. Naous, M. Walfish, D. Mazieres, A. Nicolosi, and A. Seehra, [116] S. Son and V. Shmatikov, “The Hitchhiker’s Guide to DNS Cache
“Network security via explicit consent,” Technical Report TR-09, Tech. Poisoning,” in Proceedings of the International Conference on Security
Rep., 2012. and Privacy in Communication Systems, 2010, pp. 466–483.
[92] J. Naous, M. Walfish, A. Nicolosi, D. Mazières, M. Miller, and [117] S. M. Specht and R. B. Lee, “Distributed denial of service: Taxonomies
A. Seehra, “Verifying and enforcing network paths with icing,” in of attacks, tools, and countermeasures.” in Proceedings of the 17th In-
Proceedings of the Seventh Conference on Emerging Networking EX- ternational Conference on Parallel and Distributed Computing Systems
periments and Technologies, ser. CoNEXT ’11, 2011, pp. 30:1–30:12. – 2004 International Workshop on Security in Parallel and Distributed
[93] D. Naylor, M. K. Mukerjee, P. Agyapong, R. Grandl, R. Kang, Systems, 2004, pp. 543–550.
M. Machado, S. Brown, C. Doucette, H.-C. Hsiao, D. Han et al., [118] P. Srisuresh and K. B. Egevang, “RFC 3022: Traditional IP network
“XIA: architecting a more trustworthy and evolvable internet,” ACM commaddress translator (traditional NAT),” 2001.
SIGCOMM Computer Communication Review, vol. 44, no. 3, 2014. [119] I. Stoica, S. Shenker, and H. Zhang, “Core-stateless fair queueing:
[94] S. C. Nelson, G. Bhanage, and D. Raychaudhuri, “Gstar: generalized a scalable architecture to approximate fair bandwidth allocations in
storage-aware routing for mobilityfirst in the future mobile internet,” high-speed networks,” IEEE/ACM Transactions on Networking, vol. 11,
in Proceedings of MobiArch ’11, 2011, pp. 19–24. no. 1, pp. 33–46, 2003.
[95] E. Nordström, D. Shue, P. Gopalan, R. Kiefer, M. Arye, S. Y. Ko, [120] P. Syverson, R. Dingledine, and N. Mathewson, “Tor: the second-
J. Rexford, and M. J. Freedman, “Serval: An end-host stack for service- generation onion router,” in Proceedings of the 13th USENIX Security
centric networking,” in Proceedings of the 9th USENIX Conference on Symposium, 2004.
Networked Systems Design and Implementation, ser. NSDI’12, 2012, [121] R. Tourani, T. Mick, S. Misra, and G. Panwar, “Security, privacy,
pp. 85–98. and access control in information-centric networking: A survey,” arXiv
[96] NSF, “NSF Future Internet Architecture Project,” 2014. [Online]. preprint arXiv:1603.03409, 2016.
Available: http://www.nets-fia.net/ [122] G. Tyson, N. Sastry, R. Cuevas, I. Rimac, and A. Mauthe, “A survey
[97] B. Nugraha, R. Khondoker, R. Marx, and K. Bayarou, “A mutual of mobility in information-centric networks,” Communications of the
key agreement protocol to mitigate replaying attack in expressive ACM, vol. 56, no. 12, pp. 90–98, 2013.
internet architecture (XIA),” in Proceedings of the ITU Kaleidoscope [123] G. Tyson, N. Sastry, I. Rimac, R. Cuevas, and A. Mauthe, “A survey
Academic Conference: Living in a converged world-Impossible without of mobility in information-centric networks: challenges and research
standards?, 2014. directions,” in Proceedings of the 1st ACM workshop on Emerging
[98] J. Pan, S. Paul, and R. Jain, “A survey of the research on future internet Name-Oriented Mobile Networking Design-Architecture, Algorithms,
architectures,” IEEE Communications Magazine, vol. 49, no. 7, pp. 26– and Applications, 2012, pp. 1–6.
36, 2011. [124] R. van Rijswijk-Deij, A. Sperotto, and A. Pras, “DNSSEC and its
[99] V. Pappas, D. Massey, and L. Zhang, “Enhancing dns resilience against potential for DDoS attacks: a comprehensive measurement study,”
denial of service attacks,” in Proceedings of the 37th Annual IEEE/IFIP in Proceedings of the 2014 Conference on Internet Measurement
International Conference on Dependable Systems and Networks, ser. Conference, 2014, pp. 449–460.
DNS ’07, 2007, pp. 450–459. [125] A. Venkataramani, J. F. Kurose, D. Raychaudhuri, K. Nagaraja,
[100] S. Peter, U. Javed, Q. Zhang, D. Woos, T. Anderson, and A. Krish- M. Mao, and S. Banerjee, “Mobilityfirst: a mobility-centric and trust-
namurthy, “One tunnel is (often) enough,” in Proceedings of the 2014 worthy internet architecture,” ACM SIGCOMM Computer Communi-
ACM SIGCOMM Conference, ser. SIGCOMM ’14, 2014, pp. 99–110. cation Review, vol. 44, no. 3, pp. 74–80, 2014.
[101] J. Postel, “Rfc 768: User datagram protocol,” 1980. [126] A. Venkataramani, A. Sharma, X. Tie, H. Uppal, D. Westbrook,
[102] ——, “RFC 792: Internet control message protocol,” 1981. J. Kurose, and D. Raychaudhuri, “Design requirements of a global
[103] J. Postel et al., “RFC 791: Internet protocol,” 1981. name service for a mobility-centric, trustworthy internetwork,” in Pro-
[104] V. Ramasubramanian and E. G. Sirer, “The design and implementation ceedings of the 5th IEEE International Conference on Communication
of a next generation name service for the internet,” in ACM SIGCOMM Systems and Networks, ser. COMSNETS ’13, 2013, pp. 1–9.
Computer Communication Review, vol. 34, no. 4, 2004, pp. 331–342. [127] P. Vixie, O. Gudmundsson, D. Eastlake 3rd, and B. Wellington, “Secret
[105] J.-F. Raymond, “Traffic analysis: Protocols, attacks, design issues, and key transaction authentication for dns (tsig),” Tech. Rep., 2000.
open problems,” in Designing Privacy Enhancing Technologies, 2001, [128] T. Vu, A. Baid, Y. Zhang, T. D. Nguyen, J. Fukuyama, R. P. Martin,
pp. 10–29. and D. Raychaudhuri, “Dmap: A shared hosting scheme for dynamic
[106] M. K. Reiter and A. D. Rubin, “Crowds: Anonymity for web transac- identifier to locator mappings in the global internet,” in Proceedings
tions,” ACM Transactions on Information and System Security, vol. 1, of the 2012 IEEE 32Nd International Conference on Distributed
no. 1, pp. 66–92, 1998. Computing Systems, ser. ICDCS ’12, 2012, pp. 698–707.
[107] M. C. Richardson, “A method for storing ipsec keying material in dns,” [129] B. Wellington, “Secure domain name system (dns) dynamic update,”
2005. 2000.
[108] C. Rossow, “Amplification hell: Revisiting network protocols for ddos [130] A. Yaar, A. Perrig, and D. Song, “Siff: a stateless internet flow filter
abuse.” in Proceedings of the 21st Network and Distributed System to mitigate ddos flooding attacks,” in Proceedings of the 2004 IEEE
Security Symposium, ser. NDSS ’14, 2014. Symposium of Security and Privacy, ser. S&P ’04, 2004, pp. 130–143.
[109] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Network support [131] H. Yang, H. Luo, Y. Yang, S. Lu, and L. Zhang, “HOURS: achieving
for ip traceback,” IEEE/ACM Transactions on Networking, vol. 9, no. 3, DoS resilience in an open service hierarchy,” in Proceedings of the 35th
pp. 226–237, 2001. Annual IEEE/IFIP International Conference on Dependable Systems
[110] K. Seo and S. Kent, “RFC 4301: Security architecture for the internet and Networks, ser. DNS ’04, 2004, pp. 83–92.
protocol,” 2005. [132] H. Zhang, W. Su, and W. Quan, Smart Collaborative Identifier Net-
work: A Promising Design for Future Internet. Springer, 2016.

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2798280, IEEE
Communications Surveys & Tutorials
IEEE COMMUNICATION SURVEYS & TUTORIALS 25

[133] L. Zhang, D. Estrin, J. Burke, V. Jacobson, J. D. Thornton, , D. K. dersen, “SCION: Scalability, control, and isolation on next-generation
Smetters, B. Zhang, G. Tsudik, K. Claffy, D. Krioukov, D. Massey, networks,” in IEEE Symposium on Security and Privacy (SP), 2011.
C. Papadopoulos, T. Abdelzaher, L. Wang, P. Crowley, and E. Yeh, [135] L. Zhu, Z. Hu, J. Heidemann, D. Wessels, A. Mankin, and N. Somaiya,
“Named data networking (ndn) project,” Tech. Rep. NDN-0001, 2010. “T-DNS: Connection-Oriented DNS to Improve Privacy and Security,”
[Online]. Available: http://named-data.net/techreport/TR001ndn-proj. in ACM SIGCOMM Computer Communication Review, vol. 44, no. 4,
pdf 2014, pp. 379–380.
[134] X. Zhang, H.-C. Hsiao, G. Hasker, H. Chan, A. Perrig, and D. G. An-

1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.