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
__________________________________________________
Francisco Torres-Reyes
__________________________________________________
Jonathan Ventura
__________________________________________________
Chuan Yue
__________________________________________________
Yanyan Zhuang
Date ______________________
TABLE OF CONTENTS
1Abstract5
2Introduction6
3The Issue of Privacy and anonymity8
4The Onion Router (TOR) project for anonymous browsing11
4.1How TOR works:16
5Software-defined networking (SDN)19
5.1SDN Architecture:22
5.2SDN Domains:24
5.3OpenFlow Switch26
5.4Flow-Table Components28
6Cloud-based TOR34
6.1System Overview35
7Research Proposal37
7.1Proposed Approach of Software Defined Network based Onion
Routing System:37
7.1.1Proposed Systems Challenges and Threats:40
7.2Design anonymous SDN-based Onion Routing System41
7.2.1Retrieving the SOR Directory41
7.2.2SOR Tokens procedure42
7.2.3Authenticating with Relays43
7.3Explore alternate SOR design to improve the performance and
low the cost:44
7.4Explore the Censorship Resistance45
7.5Evaluation Plan47
8References48
Abstract
Anonymity tools have gained more attention and becomes critical
for free and open Internet access, and for avoiding Internet
censorship and surveillance. Tor is one of the most popular
anonymity tools for accessing the Internet anonymously.
Tor operates by tunneling a users traffic through a series of
relays, allowing such traffic to appear originating from its last
relay, rather than from the user. However, Tor has limitations,
including poor performance, inadequate capacity, and a
susceptibility to wholesale blocking.
We propose deploying onion-routing services on the
Software-Defined Networking (SDN) platforms to leverage the large
capacities, robust connectivity, and economies of scale inherent to
commercial datacenters. This proposal presents SDN-based Onion
Routing (SOR), which builds onion-routed tunnels over multiple
anonymity service providers and through multiple SDN hosting
providers.
We plan to build a SDN simulator to evaluate the data network
using SOR system and verify their anonymity and correctness. We
will verify whether having acquired tokens and a list of relays
during the bootstrapping phase can benefit a client in building a
new efficient onion-routed circuit.
Introduction
Nowadays, with the rapid advancement of information technology,
the privacy and anonymity become a big concern for individuals and
organizations. Both governments and private companies are able to
monitor and track almost everyone activities online. Every day in
the online live, our right to privacy are violated by different
kinds of intrusions. What we say, where we go, and people we know,
are all targets [15].
It is concerned how the collected information could be used by
both governments and corporations in a way that will lead to
unwanted control and behavioral prediction. The demand is very high
for technologies to help Internet users achieve a great degree 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
users 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.
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, SDN 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 proposed research, we attempt to deploy onion-routing
services on the SDN networks 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. The new security
policies and mechanisms needed for such a provider-based ecosystem
are discussed.
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 its
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 mens room, it shouldnt
mean that he is doing something criminal or planning to take over
the government in the mens 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 its 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].
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 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. Users data
and identity can be also compromised through certain techniques
offered by ISPs, 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 peoples 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 peoples 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].
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].
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
Figure 1: TOR Browser
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 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 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?
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.
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 [22]
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 users tracks so
no observer at any single point can tell where the data came from
or where it's going [22].
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 [22].
Figure 4: How TOR Works - Step 2 [22]
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 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].
Figure 5: How TOR Works - Step 3 [22]
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 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.
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 doesnt 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 usinga centralized control console.
SDN includes manytypes 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.
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 theVirtual Machineis 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.
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 for applications and network
services, and also enabling the network to be treated as a logical
unit [8].
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
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.
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].
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, 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
QoS requirements from user application request
Integral infrastructure status (IT, energy consumption)
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 associated with a matching flow entry
does not specify a next table; at this point the packet is usually
modified and forwarded.
Figure 8: Idealized OpenFlow Switch communicates with a
controller over a secure connection using the OpenFlow protocol
[12].
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].
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].
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.
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).
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.
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.
Physical Port
Metadata
Ethernet src/dst
VLAN id
VLAN Priority
IPv4 / IPv6 DS and ECN
SCTP src port
ICMP Type
SCTP dst port
ICMP code
ARP Opcode
IPv4 src / ARP Payload
IPv6 Flow Label
ICMPv6 Type and Code fields
IPv6 Neighbor Discovery Target
MPLS Label Value/ Traffic Class/ and Bottom of Stack
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
termflow.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.
Theinstructions componentof 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.
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.
AnAction Setis 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.
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 among 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 unknown volunteers, we base security on the assumption
that multiple autonomous and known entities involved in an
onion-routed network will not collude [16].
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 main difference in operating
anonymizing relays is that users have to pay for the right to use
COR relays in compare to the free 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).
Figure 9: COR Overview
The problem can be solved by throwing in a layer of indirection.
COR splits the role of operating anonymizing relays (by so-called
anonymity service providers, or ASPs) from the 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 tokesn 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 a new relay is needed, 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 users data is
hop-by-hop onion-routed and encrypted along the circuit exactly
like in Tor, serving to anonymize the user from the relays he uses,
the clouds he crosses, and other network eavesdroppers he
meets[16].
Research Proposal
The proposed research attempts to deploy onion-routing services
on the SDN platforms 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
architecture and operation 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. The 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 Section 7.1 we discuss the proposed approach of the SOR.
Section 7.2 details the basic design of SOR. Section 7.3 discusses
the task for creating the alternate SOR designs based on the
analysis the basic SOR design. Section 7.4 considers the
development of techniques for censorship attacks and defense of SOR
systems. Section 7.5 is the evaluation plan.
Proposed Approach of Software Defined Network based Onion
Routing System
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. SORs 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 SORs 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.
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 users 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.
Figure 10: SOR system overview including the token server
Proposed Systems 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 machines 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 tunnels
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 users 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.
Design anonymous SDN-based Onion Routing System
This section explains on some of proposed SORs 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.
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 users 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 users 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 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.
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 Chaums 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 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 users 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).
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 connections 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.
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
connections 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
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.
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-users
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 organizations jurisdiction. We anticipate that SOR
provider will have a large number of incoming and outgoing traffic
from multiple ISPs [27].
This makes timing analysis and measurement significantly more
difficult than in Tor, due to a SOR providers 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.
We plan to analyze the potential vulnerabilities of the SOR and
develop techniques for exploiting them. We will then develop the
defense mechanisms on SOR for the enhancing the censorship
resistence.
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 the proposed design with
those of the state-of-art. 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
g. Feedback and reviews from SOR clients. To prevent identifying
SOR users, we could ask end user to rate just the closest SOR
switch, which was used to establish anonymity.
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
[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.
[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. ONiel. (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/.
34
