Embed Size (px)
Citation preview
Anonymity Software-Defined-Network-Based
Onion Routing
(SOR)
By
Abdelhamid Elgzil
A dissertation proposal submitted in partial
fulfillment of the requirement for the degree
This dissertation proposal for Doctor of Philosophy degree by
Abdelhamid Elgzil
Has been approved for the
Department of Computer Science
By
__________________________________________________C. Edward Chow, Chair
__________________________________________________Jonathan Ventura
__________________________________________________Chuan Yue
__________________________________________________Yanyan Zhuang
__________________________________________________Francisco Torres-Reyes
Date ______________________
2
TABLE OF CONTENTS
1 Abstract...................................................................................................................................................................... 5
2 Introduction............................................................................................................................................................. 6
3 The Issue of Privacy and anonymity.............................................................................................................8
4 The Onion Router (TOR) project for anonymous browsing............................................................11
4.1 How TOR works:......................................................................................................................................... 16
5 Software-defined networking (SDN)..........................................................................................................19
5.1 SDN Architecture:.......................................................................................................................................225.2 SDN Domains:.............................................................................................................................................. 245.3 OpenFlow Switch........................................................................................................................................265.4 Flow-Table Components......................................................................................................................... 28
6 Cloud-based TOR.................................................................................................................................................34
6.1 System Overview........................................................................................................................................ 35
7 Research Proposal.............................................................................................................................................. 37
7.1 Proposed Approach of Software Defined Network based Onion Routing System:.......377.1.1 Proposed System’s Challenges and Threats:.........................................................................40
7.2 Design anonymous SDN-based Onion Routing System.............................................................417.2.1 Retrieving the SOR Directory.......................................................................................................417.2.2 SOR Tokens procedure....................................................................................................................427.2.3 Authenticating with Relays...........................................................................................................43
7.3 Explore alternate SOR design to improve the performance and low the cost:...............447.4 Explore the Censorship Resistance....................................................................................................457.5 Evaluation Plan............................................................................................................................................47
8 References.............................................................................................................................................................. 48
3
1 Abstract
Anonymity tools gain more and more attention and start to be increasingly critical for free and
open Internet access, and to avoid increased Internet censorship and surveillance. TOR is one of
the most popular tools for accessing the Internet anonymously.
Tor operates by tunneling a user’s traffic through a series of relays (proxies), allowing such
traffic to appear to originate from its last relay, rather than the user. However, Tor has limitations,
including poor performance, inadequate capacity, and a susceptibility to wholesale blocking.
We propose moving onion-routing services to the “SDN” to leverage the large capacities,
robust connectivity, and economies of scale inherent to commercial datacenters. This proposal
describes Software-Defined-Network-based Onion Routing (SOR), which builds onion-routed
tunnels over multiple anonymity service providers and through multiple Software Defined
Network (SDN) hosting providers.
We plan to build a SDN simulator to evaluate the data network using SOR system and verify
their anonymity and correctness. Also, we propose to test, if having acquired tokens and a list of
relays during the bootstrapping phase, can benefit a client to build a new onion-routed circuit.
4
2 Introduction
Now days, with the rapid advancement of information technology, the privacy and anonymity
are becoming a big concern for individuals and organizations. Both government and private
companies are able to monitor and track almost everyone activities online. Every day in the online
live, our right to privacy will be overwhelmed affected from different kind of intrusions. However,
it is not just the privacy exposed when all what we say, anywhere we go, and everybody we know,
are target [15].
It is concerned how the collected information could be used by both government and
corporation in a way that will lead to more control and behavioral prediction. The demand is very
high to aim for technologies that help Internet users achieve a great deal of privacy protection
through anonymous browsing and connection.
The Onion Routing (TOR) is one of the most popular tools for accessing the Internet
anonymously. Tor operates by tunneling a user’s traffic through a series of relays (proxies),
allowing such traffic to appear to originate from its last relay, rather than the user. Tor relays are
hosted by volunteers all over the world, which is beneficial in providing jurisdictional arbitrage for
relayed traffic. Yet, its reliance on volunteers also results in adverse performance. Many Tor relays
offer only consumer-grade ISP connections with poor latency and bandwidth capacity.
Additionally, Tor nodes are presented publicly via Tor directory servers. This openness makes Tor
vulnerable to censorship: Any censoring government can easily enumerate the IP addresses of all
public Tor relays and block them.
5
Software Defined Networks infrastructure is everything that Tor is not: there are a smaller
number of providers, yet they administer a much larger number of high-quality, high-bandwidth
nodes. While fewer in number, these providers are still spread over multiple administrative and
jurisdictional boundaries.
Basically, software-defined-networks based onion routing, does not have to change the basic
Tor protocol. Instead, it proposes a means to establish Tor-like tunneling in a more market-friendly
and easy administrated setting of anonymity service and SDNs. Of course, this raises its own
technical challenges and security concerns. These challenges include how end-users pay for (or be
freely given) access to relays while preserving Anonymity, and how clients can discover relays
without being vulnerable to partitioning attacks.
In this proposal research plan, we attempt to move onion-routing services to the Software
Defined Networks (SDNs) to leverage the large capacities, robust connectivity, and economies of
scale inherent to commercial datacenters. It describes SDN-based Onion Routing (SOR), which
builds onion-routed tunnels over multiple anonymity service providers and through multiple
SDNs, dividing trust while making censors to experience large collateral cost. They discuss the
new security policies and mechanisms needed for such a provider-based ecosystem
6
3 The Issue of Privacy and anonymity
With the rapid and ever evolving advancement of information technology, individuals and
businesses are getting more productive. Getting things done are becoming more and more
convenient and relatively easy. Unfortunately, with all that comes a hefty price in term of privacy
and security.
With that in mind, Privacy and anonymity are two different thoughts. They are both
progressively essential as we get increasingly monitored and pursued, legally or not, and it’s
important to know why they are an integral part of our civil rights – why they are not just valuable
to the individual, but absolutely critical to a free society [14].
When you try to keep something to yourself, nevertheless how it impacts the society, than we
are talking about Privacy. For example, if somebody locks the door of the men’s room, it shouldn’t
mean that he is doing something criminal or planning to take over the government in the men’s
room. It is simply, because that person wants to keep this activity to himself [14].
In the other hand, anonymity is letting people see what you do, however not that it’s you doing
it. An example would be when you want to blow the whistler on power abuse or any other kind of
corruption in your company without to risk your career or social standing in that institution, which
is typically the reason to have strong laws to protect sourced of the free press. User could in this
situation form post data anonymously online using the TOR anonymizing network. This is the
analog equivalent of the anonymous tip-off letter, which has been seen as a staple diet in our
checks and balances [14].
7
In addition, people and organizations are concerned of their anonymity online. Many users
want to hide their offline identities that nobody can connect them with things they say online. They
are concerned about political or economic retribution, harassment, or sometimes dangers to their
lives. Human rights employees fight against repressive governments; whistleblowers report
accidents that companies and governments want to suppress; parents try to build a safe browsing
way for their children; victims of family violence attempt to rebuild their lives without abusers
could follow them [9].
Many consider anonymity to be the cornerstone of the Internet culture, for the fact that it is
required to sharing and free speech. That being said, anonymity is tremendously effective in
supporting freedom of expression [10].
The mainstream of the techniques used to guarantee privacy is related to a combination of
encryption and anonymity techniques. The vast majority of anonymity techniques rely on
protecting the real identity through a combination of methods that are tough to trace the beginning
and destination of the communication channel. Even though the encryption mechanisms can be
very difficult, most of the modern and popular application protocols provide the possibility to
establish the connection through secure channels; either through the use of the Transport Secure
Layer (TLS), or through the configuration of proxies or socket secure (SOCKS) mechanisms.
Privacy and anonymity will be measured using certain methods. The degree of privacy is
mostly dependent on the type of encryption utilized and computational capacity offered. Different
encryption algorithms are currently available, offering certain guarantees for the users. Numerous
8
protocols in the application layer rely on these algorithms as the core of privacy enforcement [1].
Using the public-key cryptography [7] and algorithms such as Rivest-Shamir-Adleman algorithm
(RSA) [17] and Digital Signature Algorithm (DSA) [18], present specific example of that.
Threats against privacy and anonymity can caused, under some circumstances, because of
absence of proper technology. Sometimes these threats can happen unintentionally. Software bugs
are one of those examples; when they are not exposed and somehow leak information including the
user identity and/or data. Another example is wrong configured Internet services that do not use
proper encryption while offering interaction with users. User’s data and identity can be also
compromised through certain techniques offered by ISP’s, who already intentionally focused on
bandwidth maximization. Not well-educated users can harm themselves by giving away their
identity and data freely without to know the side effect of that [1].
According to American Civil Liberty Union (ACLU), both governments and corporations are
gathering people’s online actions and data. While the governments use the collected information to
tighten up observation and watching of people, corporations are making a lot of money by selling
the gathered information to whoever pays more including to governments. ACLU characterizes
this as attack of privacy that is threatening people’s civil freedom. With increasingly moving of
our lives online, these intrusions have shocking effects of our right to privacy. But more than just
privacy is threatened when everything we say, everywhere we go, and everyone we associate with
is fair game. It is easy to see that watching, whether by governments or corporations, lowers free
speech and free association, undermines a free media, and threatens the free practicing of religion
[15].
9
4 The Onion Router (TOR) project for anonymous browsing
According to TOR project website [22], TOR network uses many volunteer operated servers,
which gives opportunity to every one to surf the Internet privately and secure. In TOR, connections
go through a series of virtual tunnels instead of making a direct connection. Using TOR helping
keep the identity of users anonymous to be traced and censored. With the ever evolving
information technology, people and organizations are getting more and more concerned about
improving their privacy and security on the Internet. Which lead software developers to build new
communication tools with built-in privacy features. These applications should help organizations
and individuals to share information over public networks without compromising their privacy.
Nowadays, Internet users are inclined towards using TOR to protect their privacy while browsing
the Internet, to get connected to news sites, using instant messaging services, or avoid geo-
blocking. Using TOR's hidden services, users can publish web sites and other services without
exposing the location of the site. Users with special need can also use TOR for socially sensitive
communication like chat rooms and web forums for rape and abuse survivors, or people with
illnesses [21].
TOR is a $2 million per year a nonprofit project. It consists of 30 developers spread out over
12 countries. TOR is increasing the effort to get free, powerful, and easy tools into the hands of
everyone. It offers an anonymous instant messenger integrated in the TOR-Browser [21]. TOR
introduces the solution against traffic analysis, a common form of Internet surveillance. Using
traffic analysis helps to connect a sender of a message to its receiver, which can lead to find out
who is talking to whom in a public network. The source and destination information makes it easy
to track the user activity and interests regardless is the connection encrypted or not [22].
10
According to [2] TOR [11] is an anonymizing overlay network consisting of thousands of
volunteer relays that provide forwarding services used by hundreds of thousands of clients. To
protect their identity, clients encrypt their messages multiple times before source-routing them
through a circuit of multiple relays. Each relay decrypts one layer of each message before
forwarding it to the next-hop relay or destination server specified by the client. Without traffic
analysis, the client and server are unlinkable: no single node on the communication path can link
the messages sent by the client to those received by the server
At present, TOR provides an anonymity layer for TCP by carefully constructing a three-hop
path (by default), or circuit, through the network of TOR routers using a layered encryption
strategy similar to onion routing [12]. TOR clients are responsible for path selection at the overlay
Figure 1: TOR Browser
11
layer, and form virtual circuits through the overlay network by selecting three relays from a public
list for each: an entry; a middle; and an exit. Once a circuit is established, the client creates streams
through the circuit by instructing the exit to connect to the desired external Internet destinations.
Each pair of relays communicates over a single onion routing connection that is built using the
Transmission Control Protocol (TCP). The application layer protocols rely on this underlying TCP
connection to guarantee reliability and in-order delivery of application data, called cells, between
each relay. As a result of using hop-by-hop TCP at the network layer, TOR does not allow relays
to drop or reorder cells at the application layer. Streams are multiplexed over circuits, which
themselves are multiplexed over connections [3].
It is important to note that only the entrance router can directly observe the originator of a
particular request through the TOR network. Also, only the exit node can directly examine the
decrypted payload and learn the final destination server. It is infeasible for a single TOR router to
infer the identities of both the initiating client and the destination server. To achieve its low-
latency objective, TOR does not explicitly re-order or delay packets within the network [13].
Individual users use TOR to protect themselves or their family members from tracking in
Internet, or to get connected to news sites, instant messaging services, or the like when their local
Internet providers blocked them. Using TOR's hidden services, users can publish web sites and
other services without exposing the location of the site. Users with special need also use TOR for
socially sensitive communication: chat rooms and web forums for rape and abuse survivors, or
people with illnesses.
One of the important target groups using tor is Journalists, who need to communicate more
safely with whistleblowers and dissidents. Non-governmental organizations (NGOs) also use TOR
to allow their workers to connect to their home website while they're in a foreign country. This
12
allows them to have anonymous connection without to notifying everybody nearby that they're
working with that organization.
Figure 2: The TOR Network's System Architecture
Groups such as Indymedia recommend TOR for safeguarding their members' online privacy
and security. Activist groups like the Electronic Frontier Foundation (EFF) recommend TOR as a
mechanism for maintaining civil liberties online. Corporations use TOR as a safe way to conduct
competitive analysis, and to protect sensitive procurement patterns from eavesdroppers. They also
use it to replace traditional VPNs, which reveal the exact amount and timing of communication.
Which locations have employees working late? Which locations have employees consulting job-
hunting websites? Which research divisions are communicating with the company's patent
lawyers?
13
A branch of the U.S. Navy uses TOR for open source intelligence gathering, and one of its
teams used TOR while deployed in the Middle East recently. Law enforcement uses TOR for
visiting or surveilling web sites without leaving government IP addresses in their web logs, and for
security during sting operations. The variety of people who use TOR is actually part of what makes
it so secure. TOR hides you among the other users on the network, so the more populous and
diverse the user base for TOR is, the more your anonymity will be protected [22].
TOR is also the solution, when it comes to protect against traffic analysis, a common form of
Internet surveillance. Traffic analysis can be used to find who is talking to whom over a public
network. Using the source and destination information of someone Internet traffic can lead to track
the user behavior and interests, even if the connection is encrypted.
14
4.1 How TOR works:
TOR allows reducing the risks of both simple and sophisticated traffic analysis by distributing
user transactions over several servers on the Internet, so no single point can link user to his
destination.
Figure 3: How TOR Works - Step 1 [25]
The idea is comparable to using a twisty, hard-to-follow path in order to get away from
somebody who is following you — and then regularly removing your footprints. Instead of taking
a direct route from source to destination, data packets on the TOR network take a random path
across several relays that hide user’s tracks so no observer at any single point can tell where the
data came from or where it's going [25].
15
User's software or client incrementally forms a circuit of encrypted connections through relays
on the network, to create a private network pathway with TOR. The circuit is extended one hop at
a time, and each relay along the way recognizes only which relay gave it data and which relay it is
giving data to. No specific relay ever knows the whole path that a data packet has taken. The client
negotiates a separate set of encryption keys for each hop along the circuit to ensure that each hop
can't trace these connections as they pass through [25].
To avoid statistical profiling attacks, the default TOR client restricts its choice of entry nodes
to a persistent list of three randomly chosen nodes named “entry guards”. For the middle node, the
TOR client sorts TOR relays based on their access link bandwidth and randomly select a relay,
with the probability of selection being higher for relays with higher bandwidth. For the selection of
the exit node, clients are constrained by the fact that a large fraction of relays choose to not serve
Figure 4: How TOR Works - Step 2 [25]
16
as exit nodes. This is because destination servers see the exit node as the computer that
communicates with them; if any malicious activity is detected by the destination, it will assume
that the exit relay is responsible. Therefore, when selecting an exit node, a client chooses at
random (again with bias for higher bandwidth relays) among those relays willing to serve as an
exit node for the particular destination that the client is attempting to contact and the particular
service with which this communication is associated [4].
After a TOR circuit has been established, several kinds of data can be exchanged and many
different sorts of software applications can be used over the TOR network. In the circuit, each
relay sees no more than one hop, which makes it difficult for an eavesdropper, or a compromised
relay using traffic analysis to link the connection's source and destination. TOR only works for
TCP streams and can be used by any application with SOCKS support [5]. For efficiency, the TOR
Figure 5: How TOR Works - Step 3 [25]
17
software uses the same circuit for connections that happen within the same ten minutes or so. Later
requests are given a new circuit, to keep people from linking your earlier actions to the new ones.
5 Software-defined networking (SDN)
SDN is a computer-networking concept that originally defined an approach to allow network
administrators design, building, and manage network services through abstraction of lower-level
functionality. SDN is designed because static architecture of traditional network doesn’t fulfill the
need of more storage and dynamic computing such as data centers. This is possible by separating
the system part that responsible for decisions about where traffic is going (control plane), which
become directly programmable, from the main system part that forwarded traffic to the selected
destination (data plane) that will be abstracted for applications and networks services.
In the minds of many people, SDN and OpenFlow will be one in the same. However,
OpenFlow is actually part of the general SDN architecture. OpenFlow is becoming the standard
way of implementing an SDN, and presenting the communications protocol that allows the control
plane to communicate with the forwarding plane. There are some other protocols beside OpenFlow
available or in development for SDN [6].
The goal of Software-Defined Networking is to allow administrators and engineers of cloud
and network to respond fast to justify work requirements using a centralized control console. SDN
includes many types of network technologies intended to make the network more flexible and agile
to support the virtualized server and storage infrastructure of the modern data center.
18
Several network requirements lead to a need for a flexible, response method to manage traffic
flows within a network or the Internet. One of the primary factors is the progressively widespread
demand for Server Virtualization. Basically server virtualization masks server resources, including
the number and identity of individual physical servers, processors, and operating systems, from
server users. This masking conserve hardware resources and makes it possible to partition a single
machine into multiple, independent servers. In the case of machine failure, this masking also helps
to migrate a server fast from one machine to another for load balancing or for dynamic switchover.
Server virtualization has become a central element in dealing with "big data" applications and in
implementing cloud-computing infrastructures. However, Server virtualization causes different
problems with traditional network architectures like configuring Virtual LANs (VLANs). Network
managers need to make sure the VLAN used by the Virtual Machine is assigned to the same switch
port as the physical server running the virtual machine. Because the virtual machine is movable, it
is necessary to reconfigure the VLAN every time that a virtual server is relocated. In general
terms, network administrator needs to be able to manage, add, drop, and change resources and
profiles dynamically, which matches the flexibility of server virtualization. This process is difficult
to do with conventional network switches, in which the control logic for each switch is co-located
with the switching logic.
Traffic midst virtual servers represents another effect of server virtualization. It flows differ
significantly from the traditional client-server model. Typically, there is a considerable amount of
traffic among virtual servers, for such purposes as preserving steady images of the database and
invoking security functions such as access control. These server-to-server flows change in location
and intensity over time, demanding a flexible method to managing network resources.
19
Additional issue leading to the demand for quick response in allocating network resources is
the growing usage by employees of mobile devices such as smartphones, tablets, and notebooks to
access enterprise resources. Network administrator must be able to respond to rapidly substituting
resource, Quality of Service (QoS), and security requirements.
Existing network infrastructures can respond to changing requirements for the management of
traffic flows, providing differentiated QoS levels and security levels for individual flows, but the
process can be very time-consuming if the enterprise network is large and/or involves network
devices from multiple vendors. The network manager must configure each vendor's devices
individually, and modify performance and security parameters on a per-session, per-application
basis. Every time a new virtual machine is brought up to the network of a large enterprise, it can
take hours or even days for network administrator to manage the needed reconfiguration.
This state of affairs has been related to the mainframe time of computing. In the time of the
mainframe, applications, the operating system, and the hardware were vertically combined and
delivered by a single vendor. All of these components were exclusive and closed, leading to time-
consuming innovation. Nowadays, most computer platforms use the x86 instruction set, and a
variety of operating systems (Windows, Linux, or Mac OS) run on top of the hardware.
The OS delivers APIs that allow outside providers to develop applications, leading to fast
innovation and implementation. In a similar fashion, commercial networking devices have
exclusive features and particular control planes and hardware, all vertically integrated on the
switch. As will be seen, the SDN architecture and the OpenFlow standard afford an open
architecture in which control functions are disconnected from the network device and placed in
manageable control servers. This structure enables the fundamental infrastructure to be abstracted
20
for applications and network services, and also enabling the network to be treated as a logical unit
[8].
21
5.1 SDN Architecture:
The following figure demonstrates the logical structure of SDN, where the middle plane
presents involved functions, including routing, naming, policy declaration, and security checks.
This plane constitutes the SDN Control Plane, and consists of one or more SDN servers
Figure 6: SDN Logical Structure
22
In the Data Plane, the SDN Controller responsible for describing the data flows. After the
controller proves if a communication is permitted by the network policy, it gives the permission
for each flow to get through the network, computes a route for the flow to take, and adds an entry
for that flow in each of the switches along that path. Using the complex functions included by the
controller, switches basically manage flow tables whose entries can be filled only by the controller.
Generally, OpenFlow as a protocol and API will be used to establish the communication between
the controller and the switches.
It is remarkable that the SDN architecture flexible, which is helps, operating with different type
of switches and at different protocol layers. SDN controllers and switches can be implemented for
Ethernet switches (Layer 2), Internet routers (Layer 3), transport (Layer 4) switching, or
application layer switching and routing. SDN relies on the common functions existing on
networking devices, which basically involve forwarding packets based on some form of flow
description.
Switch in SDN architecture, implements the following functions:
The switch encapsulates and forwards the first packet of a flow to an SDN controller,
allowing the controller to decide whether the flow should be added to the switch flow
table.
The switch forwards received packets out the right port based on the flow table, that
may include priority information dictated by the controller.
The switch can drop packets on a specific flow, temporarily or permanently, as stated
by the controller. Packet dropping can be used for security purposes, restriction Denial-
of-Service (DoS) attacks or traffic management requirements.
23
Indeed, in the SDN, the controller manages the forwarding state of the switches. This is
happening over a vendor-independent API that enables the controller to address a wide variety of
operator requirements without replacing any of the lower-level features of the network, including
topology.
With the splitting of the control and data planes, SDN allows applications to deal with a single
abstracted network device without worry for the details of how the device operates. Network
applications go through a single API to the controller. Thus it is possible to quickly create and
utilize new applications to organize network traffic flow to meet specific enterprise requirements
for best performance or security [8].
5.2 SDN Domains:
Operator of huge enterprise or carrier network needs most likely to split the entire network
into several SDN domains that not intersect each other, because it getting harder and
disadvantageous to implement a single controller to manage all network devices in such large
enterprise network. SDN Domain is the network portion that covered by one SDN controller.
Scalability is one of many reasons for using SDN domains, because an SDN controller can
just manage limited number of devices. Therefor, Administrators need to be ready to organize
multiple SDN controllers to that large network. Another reason is the privacy, where a carrier
could need to apply different privacy policies in different SDN domains. Finally, Incremental
deployment is also a reason for using SDN domains that allows a carrier to divide the network into
multiple, individually manageable SDN domains to be flexible incremental deployment. Specially,
24
for network consist of mix of traditional and newer infrastructure. The existence of multiple
domains builds a condition for individual controllers to communicate with each other via a
standardized protocol to exchange routing information.
Figure 7: SDN Domain Structure
SDNi is one of the protocols, which is developed from IETF (The Internet Engineering
Task Force). It represents an interface mechanism between SDN domains in a large network. SDNi
is managed at the SDN controller.
Furthermore, SDN Domains exchange the following information between each other in one huge
network:
Network topology
Network events
User defined request information
25
QoS requirements from user application request
Integral infrastructure status (IT, energy consumption…)
5.3 OpenFlow Switch
OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized
interface to add and remove flow entries. The flow tables and a group table form part of the
OpenFlow Switch, which perform packet lookups and forwarding, and an OpenFlow channel to
external controller (Figure 8). The switch will be managed from the controller via the OpenFlow
protocol. The controller can use this protocol to add, update, and delete flow entries, both
reactively (in response to packets) and proactively.
Each flow table in the switch includes a set of flow entries; each flow entry consists of
match fields, counters, and a set of instructions to apply to matching packets. Matching begins at
the first flow table and may last to additional flow tables. Flow entries match packets in priority
order, with the first matching entry in each table being used. If a matching entry is discovered, the
instructions related to the particular flow entry are executed. When there is no match is found in a
flow table, the result hangs from switch configuration: the packet may be forwarded to the
controller over the OpenFlow channel, dropped, or may continue to the next flow table.
Instructions related to each flow entry describe packet forwarding, packet modification, group
table processing, and pipeline processing. Pipeline processing instructions permit packets to be
sent to subsequent tables for additional processing. It allows also information between tables to be
communicated, in the form of metadata. Table pipeline processing ends when the instruction set
26
associated with a matching flow entry does not specify a next table; at this point the packet is
usually modified and forwarded.
Typically, flow entries may forward to a physical port, but it may also be a virtual port
defined by the switch or a reserved virtual port defined by this specification. Reserved virtual ports
may specify generic forwarding actions such as sending to the controller, flooding, or forwarding
using non-OpenFlow methods, such as “normal” switch processing, while switch-defined virtual
ports may specify link aggregation groups, tunnels or loopback interfaces [12].
Figure 8: Idealized OpenFlow Switch communicates with a controller over a secure connection using the OpenFlow protocol [12].
27
Flow entries may also point to a group, which indicates additional processing. Groups
signify sets of actions for flooding, as well as more complex forwarding semantics (e.g. multipath,
fast reroute, and link aggregation). Groups also enable multiple flows, as a general layer of
indirection, to forward to a single identifier (e.g. IP forwarding to a common next hop). This
concept lets usual output actions, which across flows, to be changed efficiently.
The group table contains group entries; each group entry contains a list of action buckets
with specific semantics dependent on group type. One or more action buckets contains actions,
which are applied to packets sent to the group. Switch designers are able to implement the internals
in any way suitable, delivered that correct match and instruction semantics are preserved. For
example, while a flow may use an all group to forward to multiple ports, a switch designer may
decide to implement this as a single bitmask within the hardware-forwarding table. Another
example is matching; the pipeline exposed by an OpenFlow switch may be physically designed
with a different number of hardware tables [12].
5.4 Flow-Table Components
Flow table is the basic building block of the logical switch architecture. Each packet that
enters a switch passes through one or more flow tables. Each flow table includes entries consisting
of six components:
Match Fields: Used to select packets that match the values in the fields, including
packet headers, the ingress port, and the metadata value.
Priority: Relative priority of table entries.
28
Counters: Updated for matching packets. There are assortments of timers, which
define in the OpenFlow specification. Examples include the number of received
bytes and packets per port, per flow table, and per flow-table entry; number of
dropped packets; and duration of a flow.
Instructions: Actions to be taken if a match occurs. It either contains a set of
actions to add to the action set, includes a list of actions to apply directly to the
packet, or modifies pipeline processing.
Timeouts: Maximum amount of idle time before a flow is expired by the switch.
Cookie: anonymous data value chosen by the controller. May be used by the
controller to filter flow statistics, flow modification, and flow deletion; not used
when processing packets.
Table 1: Main components of a flow entry in a flow table
Match Fields Priority Counters Instructions Timeouts Cookie
A flow table may include a table-miss flow entry, which renders all Match Fields wildcards (every
field is a match regardless of value) and has the lowest priority (priority 0). The Match Fields
component of a table entry consists of the following required fields:
Ingress Port: The identifier of the port on the switch where the packet arrived. It
may be a physical port or a switch-defined virtual port.
Ethernet Source and Destination Addresses: Each entry can be an exact address, a
bit masked value for which only some of the address bits are checked, or a wildcard
value (match any value).
29
IPv4 or IPv6 Protocol Number: A protocol number value, indicating the next
header in the packet.
IPv4 or IPv6 Source Address and Destination Address: Each entry can be an exact
address, a bit masked value, a subnet mask value, or a wildcard value.
TCP Source and Destination Ports: Exact match or wildcard value.
User Datagram Protocol (UDP) Source and Destination Ports: Exact match or
wildcard value.
Any OpenFlow-compliant switch must support the preceding match fields. The following fields
may be optionally supported:
Physical Port: Used to designate underlying physical port when packet is
received on a logical port.
Metadata: Additional information that can be passed from one table to another
during the processing of a packet. Its use is discussed subsequently.
Ethernet Type: Ethernet Type field.
VLAN ID and VLAN User Priority: Fields in the IEEE 802.1Q Virtual LAN header.
IPv4 or IPv6 DS and ECN: Differentiated Services and Explicit Congestion
Notification fields.
Stream Control Transmission Protocol (SCTP) Source and Destination
Ports: Exact match or wildcard value.
30
Internet Control Message Protocol (ICMP) Type and Code Fields: Exact match or
wildcard value.
Address Resolution Protocol (ARP) Opcode: Exact match in Ether-net Type field.
Source and Target IPv4 Addresses in Address Resolution Protocol (ARP)
Payload: Can be an exact address, a bitmasked value, a subnet mask value, or a
wildcard value.
IPv6 Flow Label: Exact match or wildcard.
ICMPv6 Type and Code fields: Exact match or wildcard value.
IPv6 Neighbor Discovery Target Address: In an IPv6 Neighbor Discovery
message.
IPv6 Neighbor Discovery Source and Target Addresses: Link-layer address
options in an IPv6 Neighbor Discovery message.
Multiprotocol Label Switching (MPLS) Label Value, Traffic Class, and Bottom of
Stack (BoS): Fields in the top label of an MPLS label stack.
Table 2: Fields from packets used to match against flow entries.
Phys
ical
Por
t
Met
adat
a
Ethe
rnet
src
/dst
VLA
N i
d
VLA
N P
riorit
y
IPv4
/ IP
v6 D
S an
d EC
N
SCTP
src
port
ICM
P Ty
peSC
TP d
st p
ort
ICM
P co
de
AR
P O
pcod
e
IPv4
src
/ A
RP
Payl
oad
IPv6
Flo
w L
abel
ICM
Pv6
Type
and
Cod
e fie
lds
IPv6
Nei
ghbo
r Dis
cove
ry T
arge
t
MPL
S L
abel
Val
ue/
Tra
ffic
C
lass
/ and
Bot
tom
of S
tack
31
Thus, OpenFlow can be used with network traffic relating a variety of protocols and
network services. Note that at the MAC/link layer, only Ethernet is supported. Thus, OpenFlow as
currently defined cannot control Layer 2 traffic over wireless networks.
From all that, we can now offer a more precise definition of the term flow. From the point
of view of a single switch, a flow is a sequence of packets that matches a specific entry in a flow
table. The definition is packet-oriented, in the sense that it is a function of the values of header
fields of the packets that constitute the flow, and not a function of the path they follow through the
network. A combination of flow entries on multiple switches defines a flow that is bound to a
specific path.
The instructions component of a table entry consists of a set of instructions that are
executed if the packet matches the entry. Before describing the types of instructions, we need to
define the terms "Action" and "Action Set." Actions describe packet forwarding, packet
modification, and group table processing operations. The OpenFlow specification includes the
following actions:
Output: Forward packet to specified port.
Set-Queue: Sets the queue ID for a packet. When the packet is forwarded to a port
using the output action, the queue id determines which queue attached to this port is
used for scheduling and forwarding the packet. Forwarding behavior is dictated by
the configuration of the queue and is used to provide basic QoS support.
Group: Process packet through specified group.
Push-Tag/Pop-Tag: Push or pop a tag field for a VLAN or MPLS packet.
32
Set-Field: Their field type identifies the various Set-Field actions; they modify the
values of respective header fields in the packet.
Change-TTL: The various Change-TTL actions modify the values of the IPv4 Time
To Live (TTL), IPv6 Hop Limit, or MPLS TTL in the packet.
An Action Set is a list of actions associated with a packet that are accumulated while the packet is
processed by each table and executed when the packet exits the processing pipeline. Instructions
are of four types [8]:
Direct packet through pipeline: The Goto-Table instruction directs the packet to a
table farther along in the pipeline. The Meter instruction directs the packet to a
specified meter.
Perform action on packet: Actions may be performed on the packet when it is
matched to a table entry.
Update action set: Merge specified actions into the current action set for this packet
on this flow, or clear all the actions in the action set.
Update metadata: A metadata value can be associated with a packet. It is used to
carry information from one table to the next.
33
6 Cloud-based TOR
Poor performance, inadequate capacity, and a susceptibility to wholesale blocking, are the
main limitations of TOR. Therefore, instead of utilizing a large number of volunteers (as Tor
does), it is a decent alternative to move onion-routing services to the “cloud”. Jones, Nicholas, et
al. from Princeton University, describes a proposal for Cloud-based Onion Routing (COR) [16].
Cloud infrastructure is everything that Tor is not: there are a smaller number of providers,
yet they manage a much larger number of high-quality, high-bandwidth nodes. While fewer in
number, Cloud providers are still coverage multiple administrative and jurisdictional boundaries.
Further, cloud infrastructure is elastic: One can incrementally add (or remove) relays to a cloud,
simply by spinning up new virtual machine (VM) instances in the cloud. This can be mainly
effective given the typical diurnal nature of client demand. This elasticity also reduces wholesale
blocking. While Tor relays commonly use static addresses, clouds allow one to rotate between IP
addresses quickly (either by retiring and spinning up new VMs, or having existing VMs issue and
obtain new IPs). A censor is therefore left the option of either blocking all IP prefixes used by the
cloud provider, and causing large collateral damage, or allowing the traffic to flow unrestricted.
However we have to deal with a security dilemma: Does adopting a cloud implementation
threaten the actual anonymity we seek? There are already several privately-hosted anonymity
solutions (proxies like anonymizer.com, private VPNs, etc.). Clients have to fully trust the
provider of these existing solutions. As a result, we need a hybrid solution to build a high-quality
TOR-based network on multiple cloud-hosting providers. Much like Tor has no trust between its
34
unknown volunteers, we base security on the assumption that multiple autonomous and known
entities involved in an onion-routed network will not collude [16].
6.1 System Overview
To launch an anonymous connection in COR, an end-user iteratively forms an encrypted
tunnel through a circuit of relay nodes, much like in TOR. The motivation for operating
anonymizing relays is, users have to “pay” for the right to use COR relays in compare to freely
TOR. This raises a security challenge: If COR users were to provide payment directly to cloud
hosting providers (CHPs), their billing information could be used to de-anonymize their Internet
access (e.g., the entry CHP could link billing information to client IP, while the exit CHP could
link billing information to request plaintext).
Overcoming this problem could be throw using a layer of indirection. COR splits the role
of operating anonymizing relays (by so-called anonymity service providers, or ASPs) from the
Figure 9: COR Overview
35
actual CHPs that run the infrastructure. These ASPs rent VMs, run anonymizing relays in these
VMs, and accept cryptographic tokens from connecting users in exchange for transmitting their
traffic. The main cryptographic property for those token is the impossibility to associate the
purchase of a token with the redemption of the token. It prevents ASPs from finding out which
user redeemed a particular token.
Because of the security concerns, COR is composed of two separate relay networks
conceptually:
1. The bootstrapping network allows users to be anonymous when starting to use COR.
A user can use this network to keep IP private while purchasing tokens, obtaining directory server
information, and establishing an initial circuit. Since a user does not primarily have tokens, the
bootstrapping network does not need tokens to use its relays. To prevent abuse, however, it is
limited in that it can only be used to access COR directory and token servers, and not the wider
Internet.
2. The data network is a high-bandwidth, low-latency network through which users are
able to anonymously access the Internet. Having acquired tokens and a list of relays during the
bootstrapping phase, a client can now build an onion-routed circuit. Every time when new relay
need, the user provides a valid token to that relay, which grants it temporary access (typically
metered by consumed bandwidth). The user repeats this process multiple times to build the full
circuit.
Figure 9 shows a COR data tunnel, where the user establishes a circuit through relays
managed by ASP 1 and 2, which includes traversing clouds operated by CHP A and B. The user’s
data is hop-by-hop onion-routed encrypted along the circuit exactly like in Tor, serving to
36
anonymize the user from the relays he uses, the clouds he crosses, and other network
eavesdroppers he meets[16].
7 Research Proposal
The proposed research plan attempts to move onion-routing services to the Software
Defined Networks (SDNs) to leverage the large capacities, robust connectivity, and economies of
scale inherent to commercial datacenters. It describes SDN-based Onion Routing (SOR), which
builds onion-routed tunnels over multiple anonymity service providers and through multiple
SDNs, dividing trust while making censors to experience large collateral cost. They discuss the
new security policies and mechanisms needed for such a provider-based ecosystem, and present
some preliminary benchmarks. SOR structure will be introduced in details in section 7.1
Fundamentally, SOR does not have to change the basic Tor protocol. Instead, it proposes a
means to establish Tor-like tunneling in a more market-friendly and easy administrated setting of
anonymity service and SDNs. Of course, this raises its own technical challenges and security
concerns. These challenges include how end-users pay for (or be freely given) access to relays
while preserving Anonymity, and how clients can discover relays without being vulnerable to
partitioning attacks.
7.1 Proposed Approach of Software Defined Network based Onion Routing System:
37
SOR separates the role of operating anonymizing relays (by so-called anonymity service
providers, or ASPs, which include SOR-Controller and SOR-Switch) from the actual SDN
providers (SDNPs) that manage the infrastructure. These ASPs rent VMs, run anonymizing
controller and relays in these VMs, and accept cryptographic payments (tokens) from connecting
users in exchange for relaying their traffic. These tokens have the cryptographic property that it is
impossible to link the purchase of a token with the redemption of the token, preventing ASPs from
determining which user redeemed a particular token. It also to imagine, that ASPs could even
accept tokens issued by other ASPs. SOR’s use is illustrated by two phases. First, clients involve in
the process of obtaining tokens and learning the set of relays in the federation. Second, clients
form an onion-routed circuit by redeeming the tokens at the relays of their choice, which will be
used as a circuit for anonymous communication. This separation is analogous to the control/data
plane separation of SDN itself and other capabilities-based systems that seek to protect against
denial-of-service attacks (DoS) [19][20], in which the data plane is protected by a capability, while
the control plane needs to be protected by other means (although SOR’s focus is on anonymity,
rather than DoS protection).
Given the phases’ different security concerns, SOR is composed of two separate relay
networks conceptually: The first one is the bootstrapping network permits users to preserve
anonymity when starting to use SOR. A user can use this network to ensure IP privacy while
obtaining tokens, acquiring directory server information, and starting an initial circuit. Initially
bootstrapping network does not require tokens to use its relays, because a user does not have
tokens. To prevent abuse, however, it is limited in that it can only be used to access SOR directory
and token servers, and not the wider Internet. The second network is the data network with high-
bandwidth, low-latency network through which users are able to anonymously access the Internet.
38
We propose to build a SDN simulator to evaluate the data network using SOR system
illustrated in Figure 10 and verify their anonymity and correctness. Also, we propose to test, if
having acquired tokens and a list of relays during the bootstrapping phase, can benefit a client to
build a new onion-routed circuit.
To extend a circuit to a new relay, the client provides a valid token to that relay, which
grants it temporary access (typically metered by consumed bandwidth). The user repeats this
process multiple times to build the full circuit.
Figure 10 illustrate a SOR data tunnel, where the user establishes a circuit through relays
managed by SOR controllers and switches, which includes traversing SDNs operated by different
providers. The user’s data is hop-by-hop onion encrypted along the circuit exactly like in Tor,
serving to anonymize the user from the relays he uses, the SDNs he traverses, and other network
eavesdroppers he confronts.
39
7.1.1 Proposed System’s Challenges and Threats:
TOR and SOR have different trust model, because SOR presents new roles and
relationships into the system. Within Tor, there are only two roles: end-users seeking anonymity
and relay operators that provide it. SOR realy in compare will be accessed from two
administratively-distinct parties: the ASP that directly operates it, and the SDN provider (SDNP)
that has administrative access to the physical machine (and the virtual machine’s hypervisor).
Thus, we need to examine the threats posed by both ASPs and SDN providers, in addition to
malicious users and censors. The threat model for ASPs and SDN providers is very similar. While
the tunnel’s security relies on the fact that some of the involved ASPs/ SDNPs do not collude,
individual malicious ASPs or SDNPs may keep detailed logs, packet traces, or otherwise attempt
to de-anonymize users. Due to the risks of traffic analysis, the same ASP should not appear in
multiple, noncontiguous places within a circuit. Similarly, because SDNPs have administrative
control over ASPs’ virtual machines, a user’s circuit should not use relays that are all controlled by
the same SDNP. End users have limited ability to attack SOR. Users can attempt to perform
denial-of-service attacks on the network. Malicious users can also try to modify the load
characteristics of relays to perform side-channel attacks. Due to clouds’ traffic volumes and ASPs’
ability to spin up new instances when relays become loaded, we consider these attacks can be
made unsuccessful.
40
7.2 Design anonymous SDN-based Onion Routing System
This section explains on some of proposed SOR’s design details. First, we discuss the
process through which users contact ASP directory servers to determine SOR relays. Next, we
discuss the properties of SOR tokens and their distribution methods. Finally, we discuss the
authentication and token redemption mechanisms of SOR relays.
7.2.1 Retrieving the SOR Directory
Before a user can build a SOR circuit across multiple ASPs’ relays, a user must discover
potential relays from the ASPs’ (TOR) directories (Figure 10 – Steps 1&2). Directories are
responsible for tracking the available SOR nodes for a given ASP. Tor directories are public, and
any user can download the entire directory at any time. This makes the nodes returned by these
directories vulnerable to IP-addressbased blocking by censors.
When a user retrieves the SOR directory, they do not receive the entire list of available
nodes, but only a subset of the available nodes. Unfortunately to expect, this design creates new
vulnerabilities. Consider the scenario of a malicious directory server. Since SOR directories only
return a small subset of the total number of nodes, a malicious directory server could target an
individual user (or, more specifically, the user’s IP address) and send that user a specific and easy
to identify list of relay nodes. An proposed option, to avoid this kind of partitioning attack,
directory retrieval within SOR always happens through a SOR circuit that hides the user’s true
identity by anonymizing access. Initially, when a user does not have an established SOR circuit in
the data network, the user can use the so-called bootstrapping network to create an anonymizing
circuit and retrieve the directory. A bootstrapping fetch works as follows: Any user can contact a
directory and ask for a bootstrapping relay without supplying a token. The user adds the given
41
bootstrap node to his circuit, and then contacts a different directory through this circuit. This
process is repeated until the user has fully constructed his bootstrapping circuit. The user thus
incrementally builds his circuit. Once the circuit is complete, the user is able to purchase tokens or
retrieve a directory for the data network.
7.2.2 SOR Tokens procedure
SOR Tokens offer the means for a user to achieve access to a relay for some specified
duration and/or transfer size. This is could be implemented with Chaum’s blinded signature
scheme [21]. User sends a blinded random nonce to the token server to purchase or otherwise
getting a token. The token server then replies with a signature of the random nonce without ever
learning its value. When redeeming the token, the user sends the signed random nonce to the token
server, which upon verifying the signature (and the fact that the nonce was never used before),
authorizes the token and adds the nonce to the list of used nonces. Since each blinded signature can
only produce a valid signature for one nonce, and the token server keeps a list of used nonces, it is
assured that a token can only be used once. The user is assured that privacy is preserved because it
is computationally hard for the token server to correlate the blinded nonce it learned when the user
acquired the token with the signed nonce sent to it during token redemption. Previous proposals
like XPay [22] and Par [23] offer more complex solutions than those needed by SOR. XPay deals
with micropayments, while Par assumes a single central bank, neither of which applies to SOR. All
Bitcoin transaction, in compare, are logged and stored within the Bitcoin network, which make
Bitcoin not appropriate for use as a token [26]. However, Bitcoin could be used as a currency to
buy tokens, much like any other currency that a token server chooses to accept.
In practice, one of the major predictable challenges is the distributing of SOR tokens while
preserving anonymity. The original work on ecash assumed the use of anonymous channels, the
42
very thing we are trying to construct! Using whatever standards the token server considers
necessary, tokens may be distributed to users. However, most token servers will want to
authenticate the user in some way before granting a user a token. For example, ASPs may want to
authenticate the user’s association with an organization for which they seek to provide free access.
Alternatively, they may want to guarantee the user delivered payment. In any case, if the IP
address used during token purchasing is the same IP that will be used when accessing SOR, the
ASP can de-anonymize the user when the token is redeemed. We can assume avoiding this attack
by making sure that all access to the token server is done through a SOR circuit. If a user does not
have access to SOR relays within the data network already; e.g., he is connecting to SOR for the
first time, he can access ASPs via the bootstrapping network (section 7.1).
7.2.3 Authenticating with Relays
Before a user starts a connection with a SOR relay, the user must present a SOR token to
the relay (Figure 10 Steps 4, 8, & 14). The relay then immediately contacts the token server, which
issued the token to check its validity (Figure 10 Steps 5, 9, &13). If the token is accepted, the user
gains access to that relay according to the terms stipulated by the ASP, with the relay measuring
the connection’s aggregate resource use (Figure 10 Steps 6, 10, &12). When the connection is
about to expire or exceeds its approved usage, the user can redeem an additional token to keep the
circuit alive.
43
7.3 Explore alternate SOR design to improve the performance and low the cost:
Performance is one of the major factors inspiring our work on SOR. However, using
encryption and tokens could influence both connection’s performance and cost. Going throw the
steps 3 to 15 in Figure 10 repeatedly will influence the characters that we aimed with using SOR
including large capacities, robust connectivity, and economies of scale inherent to commercial
datacenters.
Figure 11: Alternative route for the subsequences packets in SOR
44
A proposed alternative to improve the SOR is to used the concept mentioned in section 7.1
just for the communication start. Only the first packet will go throw all encryption and token
authentication (section 7.2.3). First packet sent from a user to a distention will be onion routed
encrypted using the public keys for all SOR controllers. Correspondingly, all used token have to
authenticate throw token server to allow the packet traverses the SDN.
After the first packet permitted and crossed the particular SOR switches to the destination, we
propose to build a virtual tunnel between the user and destination including the SOR switches.
The rest of the subsequences packet could flow throw the SOR switches aiming to the destination
without to be encrypted and/or require tokens. When the connection is about to expire or exceeds
its approved usage, the user can redeem an additional token to keep the circuit alive.
7.4 Explore the Censorship Resistance
SOR should protect, as in TOR, against network level censors and
monitoring eavesdroppers. These challengers may be government agencies,
ISP monitors, or corporations wishing to monitor or block traffic. We assume
that such adversaries can monitor an end-user’s traffic and have the ability to
block traffic to specific addresses. However, there are limits to the power of
any such adversary. Traffic monitoring, for example, cannot take place outside
of an organization’s jurisdiction. We anticipate that SOR provider will have a
large number of incoming and outgoing traffic from multiple ISPs [27].
45
This makes timing analysis and measurement significantly more difficult
than in Tor, due to a SOR provider’s number of connections, traffic volume,
heterogeneous use, and asymmetric routing. In addition to better network
connectivity and dynamic scaling, SOR infrastructure also inhibits blocking.
Some clouds as SDN providers allow virtual machine instances to switch IP
addresses quickly (e.g., using DHCP and gratuitous ARPs), while IP addresses
can be rotated through in others by assigning new instances. In both cases,
blocked IP addresses can be retired and new ones adopted.
A censor is thus left with two options: block all IP prefixes used by the SDN
provider, or otherwise allow the traffic to flow mostly untrammeled. This
becomes a problem of collateral damage: Amazon EC2, for example, hosted
over a million instances that share common IP prefixes in 2010 [28]. Indeed, a
determined adversary might be able to dynamically track IP addresses within
the cloud and “whitelist” certain services. However, this would challenging
game of blocking, which would need to occur on all SDN services
simultaneously.
46
7.5 Evaluation Plan
To evaluate the scalability and other SOR impact factors for the proposed
schemes and the existing state-of-art schemes, we will develop a simulation
platform. This network simulator, will be used to study and compare the
performance of both proposed Design. In order to evaluate the potential success of the
proposed solution, we anticipate using the following plan:
1. Test SOR system designed in section 7.1 using selected SOR switches and self created
tokens
2. Test SOR system designed in section 7.3 using encryption and without encryption for
the whole flow including the first packet and all other subsequences packets.
3. Test for scalability and cost improvement using the following criteria and
classifications:
a. Geographic location of preferred SOR switches and controllers
b. Domain of SOR provider
c. Organization name/ID for SOR provider
d. Cloud provider hosting the favored SDN
e. Minimum guaranteed bandwidth from SOR provider
f. Number of hops that SOR packet crossed
47
g. Feedback and reviews from SOR clients. To prevent identifying SOR users, we
could ask end user to rat just the closest SOR switch, which was used to
establish anonymity.
8 References
[1] Yanes, Adrian. Privacy and Anonymity. arXiv preprint arXiv:1407.0423 (2014)
[2] Jansen, R., Bauer, K. S., Hopper, N., & Dingledine, R. Methodically Modeling the Tor
Network. In CSET (2012)
[3] Jansen, R., Tschorsch, F., Johnson, A., & Scheuermann, B. (2014). The sniper attack:
Anonymously deanonymizing and disabling the Tor network. OFFICE OF NAVAL
RESEARCH ARLINGTON VA (2014)
[4] Akhoondi, M., Yu, C., & Madhyastha, H. V. LASTor: A low-latency AS-aware Tor client. In
Security and Privacy (SP), 2012 IEEE Symposium on (pp. 476-490). IEEE (2012)
[5] Air VPN, “What is a vpn”. [Online]. Available: https://airvpn.org/faq/what_is/
[6] SdxCentral, “SDN”. [Online]. Available: https://www.sdxcentral.com/sdn/
[7] J.Callas, L.Donnerhacke, H.Finney, D.Shaw, and R.Thayer. OpenPGP Message Format. RFC
4880 (Proposed Standard), November 2007. Updated by RFC 5581.
[8] W. Stallings. “Software-Defined Networks and OpenFlow - The Internet Protocol Journal”.
[Online]. Available: http://www.cisco.com/c/en/us/about/press/internet-protocol-
journal/back-issues/table-contents-59/161-sdn.html
[9] Electronic Frontier Foundation, “Anonymity”. [Online]. Available:
https://www.eff.org/issues/anonymity
48
[10] Karina Rigby. (1995), “Anonymity on the Internet Must be Protected”. [Online]. Available:
http://groups.csail.mit.edu/mac/classes/6.805/student-papers/fall95-papers/rigby-
anonymity.html
[11] Dingledine, R., Mathewson, N., Syverson, P.: Tor: The second-generation onion router. In:
Proceedings of the 13th USENIX Security Symposium. (August 2004)
[12] Ben Pfaff. (2011), “OpenFlow Switch Specification”. [Online]. Available:
http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf
[13] McCoy, Damon, et al. "Shining light in dark places: Understanding the Tor network." Privacy
Enhancing Technologies. Springer Berlin Heidelberg, 2008
[14] Rick Falkvinge. (2013), “How Does Privacy Differ From Anonymity, And Why Are Both
Important?” [Online]. Available: https://www.privateinternetaccess.com/blog/2013/10/how-
does-privacy-differ-from-anonymity-and-why-are-both-important/
[15] American Civil Liberties Union, “Internet Privacy” [Online]. Available:
https://www.aclu.org/technology-and-liberty/internet-privacy
[16] Jones, Nicholas, et al. "Hiding Amongst the Clouds: A Proposal for Cloud-based Onion
Routing." FOCI. 2011.
[17] J. Jonsson and B. Kaliski. Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1. RFC 3447 (Informational), February 2003.
[18] National Institute of Standards and Technology. FIPS PUB 180-1: Secure Hash Standard.
April 1995. Supersedes FIPS PUB 180 1993 May 11.
[19] A. Yaar, A. Perrig, and D. Song. Siff: A stateless internet flow filter to mitigate DDoS
flooding attacks. In Proc. IEEE Security and Privacy, 2004.
49
[20] X. Yang, D. Wetherall, and T. Anderson. A DoS-limiting Network Architecture. In Proc.
SIGCOMM, 2005.
[21] D. Chaum. Blind signatures for untraceable payments. In Proc. CRYPTO, 1982.
[22] Y. Chen, R. Sion, and B. Carbunar. XPay: Practical anonymous payments for tor routing
and other networked services. In Proc. WPES, 2009.
[23] E. Androulaki, M. Raykova, S. Srivatsan, A. Stavrou, and S. Bellovin. PAR: Payment for
anonymous routing. In Proc. PET, 2008.
[24] P. H. O’Niel. (2014), “Tor is building an anonymous instant messanger” [Online]. Available:
http://www.dailydot.com/technology/tor-instant-messaging-bundle/
[25] TOR Project. (2014), [Online]. Available: https://www.torproject.org/about/overview.html.en
[26] Bitcoinwiki. (2015), “Anonymity” [Online}. Available: https://en.bitcoin.it/wiki/
Anonymity.
[27] Z. Zhang, M. Zhang, A. Greenberg, Y. C. Hu, R. Mahajan, and B. Christian. Optimizing cost
and performance in online service provider networks. In Proc. NSDI, 2010.
[28] Recounting EC2 One Year Later. http://www. jackofallclouds.com/2010/12/recounting-
ec2/.
50
