SlideShare a Scribd company logo
Security of
Software Defined Networking (SDN)
Cognitive Radio Network (CRN)
Prepared by:
Ameer Sameer Hamood
University of Babylon - Iraq
Information Technology - Information Networks
Security of Software Defined Networking (SDN)
Overview
Definition Software Defined Networking (SDN)
SDN security & Security Challenges
SDN Attack Surface & Attacks Examples
SDN Threat Model
Open Research issues SDN
Future Research Directions
Simulator for Software Defined Networking
Overview
Definition Cognitive Network
Security of Cognitive Radios & Threats
Security issues in cognitive radio
Attacks and the proposed defense mechanisms
Open Research issues in Cognitive Radio
Evaluation Methodologies for Cognitive Networking
Future Research Directions
Simulator for Cognitive Radio
Security of Cognitive Radio Network (CRN)
What is Software Defined Networking (SDN) ?
•All of these are mechanisms.
• SDN is not a mechanism.
•It is a framework to solve a set of problems Many
solutions
•Software-Defined Networking (SDN) has been envisioned
as a way to reduce the complexity of network
configuration and management, enabling innovation in
production networks.
Figure 1
SDN is a framework to allow network administrators to
automatically and dynamically manage and control a large
number of network devices, services,
topology,traffic paths, and packet handling(quality of
service)policies using high-level languages and APIs. See
fig 2:
Software Defined Networking Definition
Figure 2
Although much has been said about the benefits of SDN to
solve persistent network security problems, our
current knowledge on SDN threats and attacks is
limited. The new systems required to carry out SDN
functions may themselves come under malicious
attacks.While some attacks will be common to existing
networks, others will be more specific to SDN.
Adversaries will inevitably exploit SDN systems if
a successful network compromise could be achieved
through such exploitations.
A vulnerable SDN network could therefore undermine
security and availability of the entire network. See
fig 3:
Software Defined Networking Security
Figure 3
Software Defined Networking Security (con..)
New features and new network deployments can introduce
faults and risks that open the door for threats that
did not previously exist or are more serious than before.
For example
one provider’s SDN controller can directly access and
manipulate another provider’s SDN switches. This
configuration is not recommended for
deployment in practice. In addition to the
traditional attack vectors on traffic flows, switches,
administrative stations, and recovery and fault
diagnosis, the controllers and the communications
related to the Controller plane result in new
security issues that are specific to SDN.
SDN-Specific Security Challenges
1- Centralized Control
2- Programmability
A - Traffic and resource isolation
B - Trust between third party applications and the
controller
C - Interface Security protection on A-CPI and I-
CPI
3- Challenge of Integrating Legacy Protocols
4- Cross Domain Connection
5- etc…
SDN-Specific Security Challenges(cont..)
1- Centralized Control
Centralized control or logically centralized control
(i.e. distributed but coordinated control function)
exposes a high-value asset to
attackers.
Attackers may attempt to manipulate the common network
services or even control the entire network by tricking
or compromising a controller . This is distinct from
a larger number of autonomous assets in a
completely distributed control domain.
SDN-Specific Security Challenges(cont..)
2- Programmability
New types of threats arise due to the explicit
programmatic access SDN offers to clients that are
typically separate organizational or business
entities. This new business model presents requirements
that do not exist within closed administrative
domains in terms of protecting system integrity,
third-party data and open interfaces.
SDN-Specific Security Challenges(cont..)
2- Programmability
A-Traffic and resource isolation
Operators must ensure that business management and real-
time control information of one entity is fully
isolated from that of all others Best practices
from existing automated interfaces between
customer and provider business support systems may be of
use here. This element extends to the existing
security issue of multi-tenant traffic and
resource isolation to avoid interference and misuse. Due
to the new business model for SDN described above,
there may be additional dynamic interactions introducing
further requirements for isolation in order to meet
different SLAs, private addressing issues, etc.
SDN-Specific Security Challenges(cont..)
2- Programmability
B- Trust between third party applications and the
controller
Programmability is a double-edged sword; it offers
flexibility to implement newly innovated market-
driven applications but it also opens the door to
malicious and vulnerable applications.
Authentication and different authorization levels should
be enforced at the point of application registration to
the controller in order to limit the controller
exposure.
SDN-Specific Security Challenges(cont..)
2- Programmability
C- Interface Security protection on A-CPI and I-CPI
Beyond the communication with applications through A-CPIs
a controller may be controlled either by an upper
layer controller or may work in tandem with another
controller at the same hierarchical level. Lack of
protection across these interfaces may lead to
malicious attacks on the SDN.
Security attributes and operation checkpoints should
therefore be defined for securing A-CPIs and I-CPIs
(Intermediate - controller plane interface).
SDN-Specific Security Challenges(cont..)
3- Challenge of Integrating Legacy Protocols
SDN interfaces and protocols are being developed in the
recognized context of escalating exploitation of
technical and process deficiencies, with
increasingly severe consequences that could lead to
security issues. However, experience has demonstrated the
difficulty of retrofitting security
capabilities into existing technologies (Domain Name
Server (DNS) and Border Gateway Protocol(BGP) are notable
examples). It is critical that compatibility be checked
before implementing legacy protocols (e.g., Network
Address Translation (NAT), BGP) into SDN. It is
also important that weaknesses previously
addressed by legacy architectures not be repeated or
even inflated when building the SDN framework.
SDN-Specific Security Challenges(cont..)
4- Cross Domain Connection
An additional requirement of SDN implementation requires
that infrastructure of different domains can be
connected. This can be realized by connecting
controllers of different providers via the I-CPI. The
mechanisms to establish trust relationships, to determine
authorization level in order to prevent abuse and
secure channel setup should all be considered.
SDN-Specific Security Challenges(cont..)
The SDN threat modeling requires understanding of the SDN
architectural components and their
interconnections. Figure 4 illustrates a
typical SDN architecture to reveal the main SDN building
blocks, which include the SDN planes and interfaces. Any
of these architectural components could
contain vulnerabilities and be exploited by
attackers to compromise a SDN network.
SDN Attack Surface
Figure 4. The SDN components
The SDN components
Figure 4
attacks could be launched on SDN components to
achieve unauthorized access, unauthorized
disclosure of information, unauthorized
modification, destruction, and/or disruption of
service.
1-Unauthorized Access Using Password Brute-Forcing
or Password-Guessing Attacks
2-Unauthorized Access Using Remote Application
Exploitation Attacks
3-Unauthorized Disclosure of Information Using RAM
scraping Attacks
4-etc ……
SDN Attacks Examples
1- Unauthorized Access Using Password Brute-Forcing or Password-
Guessing Attacks
•Figure 5. An unauthorized access attack is illustrated
using the EXT->ACC->MGR path.
SDN Attacks Examples(cont..)
Figure 5
1- Generic network infrastructure threats
2- SDN specific Threats
3- Network Virtualization Threats
SDN Threat Model
1- Generic network infrastructure threats
1- Physical threats
2- Damage/loss
3- Failures/malfunctions
4- Outages
5- Disaster
6- Legal
we present types of threats that are specific to SDN. Such threats may relate
to different assets in the reference SDN architecture
1- Data forging
2-Traffic diversion
3-Side channel attack
4- Flooding attack
5- Software/firmware exploits
6- Denial of Service (DoS)
7- Identity spoofing
8- API exploitation
9- Memory scraping
10- Remote application exploitation
11-Traffic sniffing
2- SDN specific Threats
Figure 6 :Threats of SDN reference architecture
2- SDN specific Threats(cont..)
1- Data forging: This threat involves compromising an SDN
element (e.g., controller, router, switch) in order to
forge network data and launch other attacks (e.g.,
DOS).
2-Traffic diversion: This threat involves compromising a
network element in order to divert traffic flows and
to enable eavesdropping. Traffic diversion is a threat
relating to network elements of the data plane.
3- Side channel attack: This threat involves extracting
information on existing flow rules that are used by
network elements. The threat can be realized by exploiting
patterns of network operations (e.g. exploiting the
time required for establishing a network connection).
2- SDN specific Threats(cont..)
4-Flooding attack: Flooding attacks involve compromising a
SDN component in order to make it flood other
components, which it interacts with.
5- Software/firmware exploits: This threat involves
exploiting vulnerabilities of the
software/firmware in order to cause some
malfunction, reduction or disruption of service,
eavesdrop data or destroy/compromise data.
6- Denial of Service (DoS): This threat relates to attacks
aimed at causing reduction or disruption of the SDN
service. DoS threats may occur in all layers of the SDN
reference architecture. At the data plane, DoS can
be caused by attackers, which flood the bandwidth or
resources of network elements.
2- SDN specific Threats(cont..)
7- Identity spoofing: Identity spoofing is a threat where a
threat agent successfully determines the identity of
a legitimate entity and then masquerades this entity in
order to launch further attacks.
8-API exploitation: This threat involves exploiting the API
of a software component in order to launch
different types of further attacks such as the
unauthorized disclosure, compromise of integrity and/or
destruction of information, or the unauthorized
destruction/ degradation of service.
9-Memory scraping: This threat arises when an attacker
scans the physical memory of a software component in order
to extract sensitive information that is it not authorized
to have.
2- SDN specific Threats(cont..)
10- Remote application exploitation: In this threat, an
attacker gains access or obtains higher access
privileges to an SDN application by exploiting
software vulnerabilities of it. This can then be used to
execute operations illegitimately.
11-Traffic sniffing:Traffic sniffing involves tapping data
flows within a network. In SDN, traffic sniffing has been
identified primarily as an attack upon the communication
link between an application at the SDN application
plane and a controller at the control plane in order to
gain access to important controller configuration data or
application-level credentials.
2- SDN Threat Model(cont..)
3- Network Virtualization Threats
Network virtualization threats are threats related to the
underlying IT infrastructure used for virtualizing
network operations. Such threats can be distinguished
into:
1- Threats related to servers running virtualized network functions
(virtualized host abuse)
2- Threats to data centres hosting SDN operations (Data centre
threats):
3- Threats related to virtualization mechanism: (Network
Virtualization bypassing):
• Scalability:
• Control plane bottleneck.
• Single controller is not sufficient to manage large scale network.
• How many controllers are needed to support large scale network?
• When to scale down?
• Multi Controllers.
• Each controller is responsible to a subset of the network.
• Concern with synchronization and communication between
controllers.
• How to slice the resources among controllers?
• Latency between controllers and switches.
• Less accurate decision?
What is Relation between WSN and SDN?
Open Research issues SDN
Open Research issues SDN(cont..)
• Slicing Resources (CPU, bandwidth, etc).
- How to allocate resources to different controllers and users?
- Formulated to optimization and fairness problems.
• Using SDN to achieve more green DCN.
•No substantial works in this area.
•As 2015, few publications on this subject are published in IEEE
ICC and IEEEE Globecom.
•Some software may provide measurement on power usage or
capability to turn on/off switches.
• NetFPGA, Mininet and OpenFlow?
How to leverage from SDN approach to have more flexible and secure WSN & IoT?
Open Research issues SDN as 2015(cont..)
The future, however, will most likely use a combination
of these
(and perhaps other) models, standards, and
implementations.
Models such as I2RS are likely to be used to provide
network programmability in those heterogeneous
environments in which scalability is the primary
concern. The architectural models underlying
I2RS envision layered, distributed control planes in
which the control and data planes share fate.
Future Research Directions
Using a software-defined radio together with MATLAB and
Simulink for wireless design, simulation, and analysis
enables engineers and students to:
1- Set up SDR hardware with preconfigured radio functions
2- Transmit and receive standards-based and custom-generated
signals
3- Test designs in the presence of interference and other real-
world conditions
4- Perform real-time signal analysis and measurement
5- Deploy, prototype, and verify custom designs on SDR hardware
using HDL and C code generation from algorithm models
6- Verify implementation with radio-in-the loop tests
Simulator for Software Defined Networking
Pareto-Optimal Resilient Controller Placement in SDN-based Core
Networks by David Hock, Matthias Hartmann, Steffen Gebert,
Michael Jarschel, Thomas Zinner, Phuoc Tran-Gia from the
University of Wuerzburg, Germany
A Matlab-based tool for calculating pareto-optimal placements
of controllers in a network topology.
https://github.com/lsinfo3/poco
Pareto Optimal Controller Placement (POCO) Matlab-based tool
Figure 7
OpenDaylight SDN Controller with the Mininet Network Emulator
OpenDaylight (ODL) is a popular open-source SDN
controller framework. To learn more about OpenDaylight,
it is helpful to use it to manage an emulated network of
virtual switches and virtual hosts. Most people use the
Mininet network emulator to create a virtual SDN network
for OpenDaylight to control.
https://www.opendaylight.org/platform-overview-beryllium
Figure 8
Mininet Network Emulator
Mininet is a network emulator which creates a network of
virtual hosts, switches, controllers, and links. Mininet
hosts run standard Linux network software, and its
switches support OpenFlow for highly flexible custom
routing and Software-Defined Networking.
Mininet supports research, development, learning,
prototyping, testing, debugging, and any other tasks that
could benefit from having a complete experimental network
on a laptop or other PC.http://mininet.org/
Figure 9
NS-3 Network Simulator
NS-3 is a discrete-event open-source network simulator
for Internet systems, used primarily for research and
educational use. NS-3 is a complex tool that runs
simulations described by code created by users, so you
may need programming skills to use it.
https://www.nsnam.org/
Figure 10
Cognitive radio offers the promise of intelligent
radios that can learn from and adapt to their
environment.
And change how they communicate, it's crucial that
they select optimal, secure means of
communications. Data integrity and
confidentiality can be handled by higher-layer
cryptographic security
Cognitive radio can be described as an intelligent
and dynamically reconfigurable radio .
See Figure.11, cognitive radio scenario
Definition Cognitive Network
Figure.11, cognitive radio scenario
Definition Cognitive Network(cont..)
The main objective of the security system is to
protect the
communication from the malicious users. The
cognitive radio network has the same security
requirements as that of the general wireless
networks because of the open air nature of
wireless media . The major difference between the
cognitive radio network and the traditional
wireless network is that it doesn’t operate on a
fixed frequency spectrum i.e. the
frequency spectrum is being used dynamically.
Security of Cognitive Radio
Security of Cognitive Radio at different layers
1- Physical layer
- Example of possible attacks (Intentional jamming
attack)
2- Link layer
- Example of possible attacks (Biased utility attack , DOS
attack)
3- Network layer
- Example of possible attacks (Hole attack)
4- Transport layer
- Example of possible attacks (Key depletion attack)
5- Application layer
- As a result, any attack on physical, link,network or
transport layers may have an adverse affect on the
application layer
- Secure authentication mechanisms,
- Confidentiality,
- Data integrity,
- Accessibility,
- Multimodal strategies for the isolation of adversary
nodes,
- Ability to differentiate between adversaries and
unintentionally misbehaving SUs
Security Requirement of Cognitive Radio
Threat is a constant danger through persons, objects, or
any resources where as an attack is an act of
or event that exploits the vulnerability. The policies,
learning mechanisms, and self-propagation in cognitive
radio architecture prevents the threats (cannot
escape the threats). In CR, a threat can happen while
sensing of information (due to involvement of a
malicious user).This information will
then feed for learning and decision making. The
results produced will lead to inappropriate decisions
(unacceptable decisions) due to a malicious user
injected the faults.
Threats and Attacks in Cognitive Radio Networks
Attacks Layer Involved in Cognitive Radio Networks
Cross-layer attacks are possible in CRN. There is a need
to be given individual attention for such attacks.
Jamming on routing information happens due to
lack of common control channels. Traffic
analysis attack on data privacy and location privacy will
be avoided by authentication and controlling the
access rights of cognitive user.
Attacks Layer Involved in Cognitive Radio Networks(cont..)
In comparison with traditional wireless networks,
there are more chances open to attackers in
cognitive radio technology. As a result, security in
cognitive radio networks has become a challenging
task . Quality of service (QoS) provisioning and
security requirement for the entire network may be
adversely affected by these weaknesses and
vulnerable aspects, introduced by the
nature of cognitive radio .The data in the
wireless media may be eavesdropped or altered
without notice and the channel might be jammed or
overused by the adversaries
Security issues in cognitive radio
- multi-hop cognitive radio networks
- medium access control (MAC) and network layers of the
multi-hop cognitive radio protocol stack. Issues
considered include efficient spectrum sharing, optimal relay
node selection, interference mitigation, end-to-end delay,
etc.
-Surveys on Channel Assignment Problem in CRN
- Spectrum Assignment
* Selection criteria, approaches, techniques, and
challenges
- Channel Assignment Algorithms
* Coordination mechanisms, objectives, solving
approaches, network types, number of radios, PU
characteristics, routing dependencies, and channel
Open Research issues in Cognitive Radio
- Problems in Multichannel Hidden Terminal
- Energy Efficient MAC Protocol
- Self-interference Problem
- Negotiation Mechanism and Time Synchronization
Open Research issues in Cognitive Radio(cont..)
1- Broader Evaluation
- System wide
- Interdisciplinary
- Scale
- Safety
- Realism
- Rigor
2- Testbed Requirements
3- Cognitive Radio Platforms
- Base stations , Client nodes , Mobile platforms
4- Testbed Deployment and Management
Evaluation Methodologies for Cognitive Networking
Most of the proposed solutions do not cover major issues
related to CR dynamic environment. Therefore, some
research proposals are first suggested in the context of
MAC protocol entity.
More research in future is required to search for
accurate sensing schemes. Although the hardware
limitations of CR users is a critical issue on spectrum
sensing. So, more efficient and robust alternatives must
be investigated in terms of CCC design. Clear assignments
to deal with transmit power, coding scheme,
transmission rate to the CR users must be devised
Future Research Directions
Further research may include QoS for SUs in the context
of dynamic resource availability.
However, ensuring a reliable network coordination and
reconfiguration mechanism is another
major issue that must be addressed efficiently.
Majority of the current research has focused on improving
the throughput of CR networks.
Clear assignments to deal with transmit power, coding
scheme, transmission rate to the CR users must be
devised. MAC Design focusing on energy introduces
new challenges in CR MAC design research.
Future Research Directions(cont..)
1- simulation framework based on NS2 (CogNS) for
cognitive radio networks
2- NS-3 Simulator Extension for Cognitive Radio
3- matlab
4- Cognitive Radio Simulation based on OMNeT++/MiXiM
Simulator for Cognitive Radio
simulation framework based on NS2 (CogNS)
framework can be used to investigate and evaluate the
impact of lower layers, i.e., MAC and physical layer,
on the transport and network layers protocols. Due
to the importance of packet drop probability, end-
to-end delay and throughput as QoS requirements in real-
time reliable applications, these metrics are evaluated
over CRNs through CogNS framework.http://cogns.net/
Figure 12
OMNeT++ CR Simulation Framework
OMNeT++/MiXiM was chosen as the developing platform,
mainly due to its open source nature, its well-
organized modular architecture, the
existing documentation, and the provided IDE
(Integrated Development Environment).https://omnetpp.org/
Figure 13
Conclusions
Security of Software-Defined Networks (SDN)
Security within the SDN paradigm will arguably be a
challenge, as all layers, sub-layers and components
will need to communicate according to
strict security policies.
Security challenges for Software-Defined Networks
differ in some respects from those of a
classical network due to the specific network
implementation and SDN’s inherent control and
programmability characteristics.
our current knowledge on SDN threats and attacks is
limited. The new systems required to carry out SDN
functions may themselves come under malicious
attacks. While some attacks will be common to
Security of Cognitive Radio Network (CRN)
Most of the attacks presented are specific to PHY-layer
cognition. Sensors and decisions at higher layers can
often be cryptographically protected, making them less
vulnerable to manipulatory attacks.
The threat detection mechanisms can be developed for
cognitive radio networks in the same lines of
intrusion detection mechanisms. The threat detection and
protection of information are serious issues in wireless
networks as well as cognitive radio networks
Intrusion detection models are required in such
situations. Cryptographic techniques
are useful with the additional burden of computing
time.The trust models are more appropriate than to
cryptographic techniques due to their simplicity and
computational efficiency. Cloud application helps to
Conclusions
Review Question
1- What is the relation between SDR and Cognitive
radio ?
2- What would be an appropriate conceptual model for SDR-
CR?
3- What is self-propagating AI virus in A virus spreading
model for cognitive radio networks ?
4-What is The function of MAC protocols to ensure
interference-free (with PUs or other CR users) in CR
networks?
5- what is The Impact of SDN on Network Security ?
6- Give list some important design issues that are
necessary to be addressed in distributed CR MAC
design?
7- What is CCC of CR MAC protocols ?
8- What is Technical recommendations for Administrators
Reference
1-Introduction to Software Defined Networking (SDN)
Raj Jain
Washington University in Saint Louis
Saint Louis, MO 63130 , 2013
2- Taxonomic Modeling of Security Threats in Software Defined Networking ,
Jennia Hizver, PhD ,BlackHat Conference , August 5-6, 2015
3- Principles and Practices for Securing Software-Defined
Networks , January 2015, ONF TR-511
4- The Software-Defined-Networking Research Group
Published by the IEEE Computer Society 1089-7801/13/$31.00 © 2013 IEEE
5- “Cognitive Radio Communications and Networks: Principles and Practice”
By A. M. Wyglinski, M. Nekovee, Y. T. Hou (Elsevier, December 2009)
6- Security in Cognitive Radio Networks : Threats and Mitigation ,T. Charles
Clancy,
Nathan Goergen
7- Security in Cognitive Radio Networks
Kresimir Dabcevic, Lucio Marcenaro, Carlo S. Regazzoni , University of
Genova, Italy
8- Security Challenges in Cognitive Radio Networks ,
Hanen Idoudi, Kevin Daimi, and Mustafa Saed
9-- Future Directions in Cognitive Radio Network Research , NSF Workshop Report
Edited by: Peter Steenkiste, Douglas Sicker, Gary Minden, Dipankar
Raychaudhuri
March 9-10, 2009
10- Cognitive Radio: Technology Survey and Future Research Directions
José Marinho , Edmundo Monteiro
11- AN INVESTIGATION OF SECURITY CHALLENGES IN COGNITIVE RADIO NETWORS
By Deepraj Vernekar in 30-12-2012
12- Cognitive Radio Networks
edited by Yang Xiao, Fei Hu
13- Cognitive Radio RF: Overview and Challenges
Van Tam Nguyen,1 Frederic Villain,2 and Yann Le Guillou3
1 Institut Mines-Telecom, Telecom ParisTech, LTCI CNRS UMR 5141, 75634
Paris, France
2 BL TV Front End, NXP, 14460 Colombelles, France
3 Renesas Mobile Corporation, 35517 Cesson Sevigne Cedex, France
Reference
14-Threat Landscape and Good Practice Guide for Software Defined Networks/5G
DECEMBER 2015 by
European Union Agency For Network And Information Security
15- Introduction to Software Defined Network (SDN)
By Hengky “Hank” Susanto, Sing Lab, HKUST
16- Security Issues and Threats in Cognitive Radio Networks
•Yenumula B. Reddy
• Department of Computer Science, Grambling State University
•Grambling, Louisiana, USA
17- Channel Assignment Algorithms in Cognitive Radio Networks: Taxonomy, Open
Issues, and Challenges
ARTICLE in IEEE COMMUNICATIONS SURVEYS & TUTORIALS · OCTOBER 2014
18- Cognitive Radio MAC Protocols: A Survey, Research Issues, and Challenges
Mahfuzulhoq Chowdhury1, Asaduzzaman1, and Md. Fazlul Kader
Received November 19, 2014; Revised December 29, 2014; Accepted January 26,
2015; Published February 28, 2015
Reference
https://www.researchgate.net/profile/Ameer_Sameer
://www.slideshare.net/AmeerSameer
s://www.facebook.com/ameer.Mee
https://www.linkedin.com/in/ameer-sameer-452693107
Any Question :
ameersameer.it@gmail.com

More Related Content

What's hot

Storage Area Network(SAN)
Storage Area Network(SAN)Storage Area Network(SAN)
Storage Area Network(SAN)Krishna Kahar
 
Firewall Basing
Firewall BasingFirewall Basing
Firewall Basing
Pina Parmar
 
WLAN
WLANWLAN
VPN (virtual private network)
VPN (virtual private network) VPN (virtual private network)
VPN (virtual private network)
Netwax Lab
 
Wireless Sensor Networks UNIT-3
Wireless Sensor Networks UNIT-3Wireless Sensor Networks UNIT-3
Wireless Sensor Networks UNIT-3
Easy n Inspire L
 
Location Aided Routing (LAR)
Location Aided Routing (LAR) Location Aided Routing (LAR)
Location Aided Routing (LAR)
Pradeep Kumar TS
 
CSGR(cluster switch gateway routing)
CSGR(cluster switch gateway routing)CSGR(cluster switch gateway routing)
CSGR(cluster switch gateway routing)
Gaurav Dalvi
 
Software Defined Networking (SDN) Technology Brief
Software Defined Networking (SDN) Technology BriefSoftware Defined Networking (SDN) Technology Brief
Software Defined Networking (SDN) Technology Brief
Zivaro Inc
 
Routing protocols for ad hoc wireless networks
Routing protocols for ad hoc wireless networks Routing protocols for ad hoc wireless networks
Routing protocols for ad hoc wireless networks
Divya Tiwari
 
Software Defined Networks
Software Defined NetworksSoftware Defined Networks
Software Defined Networks
Shreeya Shah
 
WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...
WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...
WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...
ArunChokkalingam
 
Sensor Protocols for Information via Negotiation (SPIN)
Sensor Protocols for Information via Negotiation (SPIN)Sensor Protocols for Information via Negotiation (SPIN)
Sensor Protocols for Information via Negotiation (SPIN)rajivagarwal23dei
 
Virtual Private Network VPN
Virtual Private Network VPNVirtual Private Network VPN
Virtual Private Network VPN
Farah M. Altufaili
 
Lecture 23 27. quality of services in ad hoc wireless networks
Lecture 23 27. quality of services in ad hoc wireless networksLecture 23 27. quality of services in ad hoc wireless networks
Lecture 23 27. quality of services in ad hoc wireless networksChandra Meena
 
Vpn
VpnVpn
Networking concepts
Networking conceptsNetworking concepts
Networking conceptsritajindal2
 
CCNP Switching Chapter 1
CCNP Switching Chapter 1CCNP Switching Chapter 1
CCNP Switching Chapter 1
Chaing Ravuth
 

What's hot (20)

Storage Area Network(SAN)
Storage Area Network(SAN)Storage Area Network(SAN)
Storage Area Network(SAN)
 
Firewall Basing
Firewall BasingFirewall Basing
Firewall Basing
 
WLAN
WLANWLAN
WLAN
 
Sdn ppt
Sdn pptSdn ppt
Sdn ppt
 
VPN (virtual private network)
VPN (virtual private network) VPN (virtual private network)
VPN (virtual private network)
 
Wireless Sensor Networks UNIT-3
Wireless Sensor Networks UNIT-3Wireless Sensor Networks UNIT-3
Wireless Sensor Networks UNIT-3
 
Vpn ppt
Vpn pptVpn ppt
Vpn ppt
 
Location Aided Routing (LAR)
Location Aided Routing (LAR) Location Aided Routing (LAR)
Location Aided Routing (LAR)
 
CSGR(cluster switch gateway routing)
CSGR(cluster switch gateway routing)CSGR(cluster switch gateway routing)
CSGR(cluster switch gateway routing)
 
Software Defined Networking (SDN) Technology Brief
Software Defined Networking (SDN) Technology BriefSoftware Defined Networking (SDN) Technology Brief
Software Defined Networking (SDN) Technology Brief
 
Routing protocols for ad hoc wireless networks
Routing protocols for ad hoc wireless networks Routing protocols for ad hoc wireless networks
Routing protocols for ad hoc wireless networks
 
Software Defined Networks
Software Defined NetworksSoftware Defined Networks
Software Defined Networks
 
WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...
WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...
WSN network architecture -Sensor Network Scenarios & Transceiver Design Consi...
 
Sensor Protocols for Information via Negotiation (SPIN)
Sensor Protocols for Information via Negotiation (SPIN)Sensor Protocols for Information via Negotiation (SPIN)
Sensor Protocols for Information via Negotiation (SPIN)
 
Ad-Hoc Networks
Ad-Hoc NetworksAd-Hoc Networks
Ad-Hoc Networks
 
Virtual Private Network VPN
Virtual Private Network VPNVirtual Private Network VPN
Virtual Private Network VPN
 
Lecture 23 27. quality of services in ad hoc wireless networks
Lecture 23 27. quality of services in ad hoc wireless networksLecture 23 27. quality of services in ad hoc wireless networks
Lecture 23 27. quality of services in ad hoc wireless networks
 
Vpn
VpnVpn
Vpn
 
Networking concepts
Networking conceptsNetworking concepts
Networking concepts
 
CCNP Switching Chapter 1
CCNP Switching Chapter 1CCNP Switching Chapter 1
CCNP Switching Chapter 1
 

Similar to Security of software defined networking (sdn) and cognitive radio network (crn)

Software Defined Networking Attacks and Countermeasures .docx
Software Defined Networking Attacks and Countermeasures .docxSoftware Defined Networking Attacks and Countermeasures .docx
Software Defined Networking Attacks and Countermeasures .docx
rosemariebrayshaw
 
Unified Security Plugin for Opendaylight Controller
Unified Security Plugin for Opendaylight ControllerUnified Security Plugin for Opendaylight Controller
Unified Security Plugin for Opendaylight ControllerSaikat Chaudhuri
 
A review on software defined network security risks and challenges
A review on software defined network security risks and challengesA review on software defined network security risks and challenges
A review on software defined network security risks and challenges
TELKOMNIKA JOURNAL
 
Security sdn
Security sdnSecurity sdn
Security sdn
Priya Singh
 
Enhancing Security in OpenFlow
Enhancing Security in OpenFlowEnhancing Security in OpenFlow
Enhancing Security in OpenFlowNiketa Chellani
 
Performance Analysis of Wireless Trusted Software Defined Networks
Performance Analysis of Wireless Trusted Software Defined NetworksPerformance Analysis of Wireless Trusted Software Defined Networks
Performance Analysis of Wireless Trusted Software Defined Networks
IRJET Journal
 
A Novel SDN Architecture for IoT Security
A Novel SDN Architecture for IoT SecurityA Novel SDN Architecture for IoT Security
A Novel SDN Architecture for IoT Security
ijtsrd
 
Security and risk analysis in the cloud with software defined networking arch...
Security and risk analysis in the cloud with software defined networking arch...Security and risk analysis in the cloud with software defined networking arch...
Security and risk analysis in the cloud with software defined networking arch...
IJECEIAES
 
IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...
IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...
IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...
IRJET Journal
 
Security of software defined networks: evolution and challenges
Security of software defined networks: evolution and challengesSecurity of software defined networks: evolution and challenges
Security of software defined networks: evolution and challenges
International Journal of Reconfigurable and Embedded Systems
 
Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Security in Software Defined Networks (SDN): Challenges and Research Opportun...Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Editor IJCATR
 
Cloud Security Solution Overview
Cloud Security Solution OverviewCloud Security Solution Overview
Cloud Security Solution Overview
Cisco Service Provider
 
IRJET- Software Defined Network: DDOS Attack Detection
IRJET- Software Defined Network: DDOS Attack DetectionIRJET- Software Defined Network: DDOS Attack Detection
IRJET- Software Defined Network: DDOS Attack Detection
IRJET Journal
 
Cloud computing challenges and solutions
Cloud computing challenges and solutionsCloud computing challenges and solutions
Cloud computing challenges and solutions
IJCNCJournal
 
Network Security Roadmap have some perception of provided security
Network Security Roadmap have some perception of provided securityNetwork Security Roadmap have some perception of provided security
Network Security Roadmap have some perception of provided security
slametarrokhim1
 
Sdn pres v2-Software-defined networks
Sdn pres v2-Software-defined networksSdn pres v2-Software-defined networks
Sdn pres v2-Software-defined networks
ahmad abdelhafeez
 
Review Paper on Predicting Network Attack Patterns in SDN using ML
Review Paper on Predicting Network Attack Patterns in SDN using MLReview Paper on Predicting Network Attack Patterns in SDN using ML
Review Paper on Predicting Network Attack Patterns in SDN using ML
ijtsrd
 
Controller Placement Problem resiliency evaluation in SDN-based architectures
Controller Placement Problem resiliency evaluation in SDN-based architecturesController Placement Problem resiliency evaluation in SDN-based architectures
Controller Placement Problem resiliency evaluation in SDN-based architectures
IJCNCJournal
 
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
Controller Placement Problem Resiliency Evaluation in SDN-based ArchitecturesController Placement Problem Resiliency Evaluation in SDN-based Architectures
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
IJCNCJournal
 
Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)
IJERD Editor
 

Similar to Security of software defined networking (sdn) and cognitive radio network (crn) (20)

Software Defined Networking Attacks and Countermeasures .docx
Software Defined Networking Attacks and Countermeasures .docxSoftware Defined Networking Attacks and Countermeasures .docx
Software Defined Networking Attacks and Countermeasures .docx
 
Unified Security Plugin for Opendaylight Controller
Unified Security Plugin for Opendaylight ControllerUnified Security Plugin for Opendaylight Controller
Unified Security Plugin for Opendaylight Controller
 
A review on software defined network security risks and challenges
A review on software defined network security risks and challengesA review on software defined network security risks and challenges
A review on software defined network security risks and challenges
 
Security sdn
Security sdnSecurity sdn
Security sdn
 
Enhancing Security in OpenFlow
Enhancing Security in OpenFlowEnhancing Security in OpenFlow
Enhancing Security in OpenFlow
 
Performance Analysis of Wireless Trusted Software Defined Networks
Performance Analysis of Wireless Trusted Software Defined NetworksPerformance Analysis of Wireless Trusted Software Defined Networks
Performance Analysis of Wireless Trusted Software Defined Networks
 
A Novel SDN Architecture for IoT Security
A Novel SDN Architecture for IoT SecurityA Novel SDN Architecture for IoT Security
A Novel SDN Architecture for IoT Security
 
Security and risk analysis in the cloud with software defined networking arch...
Security and risk analysis in the cloud with software defined networking arch...Security and risk analysis in the cloud with software defined networking arch...
Security and risk analysis in the cloud with software defined networking arch...
 
IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...
IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...
IRJET- Detection of Distributed Denial-of-Service (DDos) Attack on Software D...
 
Security of software defined networks: evolution and challenges
Security of software defined networks: evolution and challengesSecurity of software defined networks: evolution and challenges
Security of software defined networks: evolution and challenges
 
Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Security in Software Defined Networks (SDN): Challenges and Research Opportun...Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Security in Software Defined Networks (SDN): Challenges and Research Opportun...
 
Cloud Security Solution Overview
Cloud Security Solution OverviewCloud Security Solution Overview
Cloud Security Solution Overview
 
IRJET- Software Defined Network: DDOS Attack Detection
IRJET- Software Defined Network: DDOS Attack DetectionIRJET- Software Defined Network: DDOS Attack Detection
IRJET- Software Defined Network: DDOS Attack Detection
 
Cloud computing challenges and solutions
Cloud computing challenges and solutionsCloud computing challenges and solutions
Cloud computing challenges and solutions
 
Network Security Roadmap have some perception of provided security
Network Security Roadmap have some perception of provided securityNetwork Security Roadmap have some perception of provided security
Network Security Roadmap have some perception of provided security
 
Sdn pres v2-Software-defined networks
Sdn pres v2-Software-defined networksSdn pres v2-Software-defined networks
Sdn pres v2-Software-defined networks
 
Review Paper on Predicting Network Attack Patterns in SDN using ML
Review Paper on Predicting Network Attack Patterns in SDN using MLReview Paper on Predicting Network Attack Patterns in SDN using ML
Review Paper on Predicting Network Attack Patterns in SDN using ML
 
Controller Placement Problem resiliency evaluation in SDN-based architectures
Controller Placement Problem resiliency evaluation in SDN-based architecturesController Placement Problem resiliency evaluation in SDN-based architectures
Controller Placement Problem resiliency evaluation in SDN-based architectures
 
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
Controller Placement Problem Resiliency Evaluation in SDN-based ArchitecturesController Placement Problem Resiliency Evaluation in SDN-based Architectures
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
 
Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)
 

More from Ameer Sameer

Web ontology language (owl)
Web ontology language (owl)Web ontology language (owl)
Web ontology language (owl)
Ameer Sameer
 
Cognitive radio wireless sensor networks applications, challenges and researc...
Cognitive radio wireless sensor networks applications, challenges and researc...Cognitive radio wireless sensor networks applications, challenges and researc...
Cognitive radio wireless sensor networks applications, challenges and researc...
Ameer Sameer
 
Common linux ubuntu commands overview
Common linux  ubuntu commands overviewCommon linux  ubuntu commands overview
Common linux ubuntu commands overview
Ameer Sameer
 
Software defined networking players
Software defined networking playersSoftware defined networking players
Software defined networking players
Ameer Sameer
 
Open network operating system (onos)
Open network operating system (onos)Open network operating system (onos)
Open network operating system (onos)
Ameer Sameer
 
Internet of things (IoT)
Internet of things (IoT)Internet of things (IoT)
Internet of things (IoT)
Ameer Sameer
 
Cognitive radio networks
Cognitive radio networksCognitive radio networks
Cognitive radio networks
Ameer Sameer
 

More from Ameer Sameer (7)

Web ontology language (owl)
Web ontology language (owl)Web ontology language (owl)
Web ontology language (owl)
 
Cognitive radio wireless sensor networks applications, challenges and researc...
Cognitive radio wireless sensor networks applications, challenges and researc...Cognitive radio wireless sensor networks applications, challenges and researc...
Cognitive radio wireless sensor networks applications, challenges and researc...
 
Common linux ubuntu commands overview
Common linux  ubuntu commands overviewCommon linux  ubuntu commands overview
Common linux ubuntu commands overview
 
Software defined networking players
Software defined networking playersSoftware defined networking players
Software defined networking players
 
Open network operating system (onos)
Open network operating system (onos)Open network operating system (onos)
Open network operating system (onos)
 
Internet of things (IoT)
Internet of things (IoT)Internet of things (IoT)
Internet of things (IoT)
 
Cognitive radio networks
Cognitive radio networksCognitive radio networks
Cognitive radio networks
 

Recently uploaded

Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...
Product School
 
Knowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and backKnowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and back
Elena Simperl
 
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMsTo Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
Paul Groth
 
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdfSmart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
91mobiles
 
The Future of Platform Engineering
The Future of Platform EngineeringThe Future of Platform Engineering
The Future of Platform Engineering
Jemma Hussein Allen
 
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdfLeading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
OnBoard
 
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdfFIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance
 
Essentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with ParametersEssentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with Parameters
Safe Software
 
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Tobias Schneck
 
When stars align: studies in data quality, knowledge graphs, and machine lear...
When stars align: studies in data quality, knowledge graphs, and machine lear...When stars align: studies in data quality, knowledge graphs, and machine lear...
When stars align: studies in data quality, knowledge graphs, and machine lear...
Elena Simperl
 
Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*
Frank van Harmelen
 
UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3
DianaGray10
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Albert Hoitingh
 
FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf
FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdfFIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf
FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf
FIDO Alliance
 
Epistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI supportEpistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI support
Alan Dix
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Jeffrey Haguewood
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
DianaGray10
 
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using SmithyGenerating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using Smithy
g2nightmarescribd
 
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
Sri Ambati
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
Product School
 

Recently uploaded (20)

Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...
 
Knowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and backKnowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and back
 
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMsTo Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
 
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdfSmart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
 
The Future of Platform Engineering
The Future of Platform EngineeringThe Future of Platform Engineering
The Future of Platform Engineering
 
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdfLeading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
 
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdfFIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
 
Essentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with ParametersEssentials of Automations: Optimizing FME Workflows with Parameters
Essentials of Automations: Optimizing FME Workflows with Parameters
 
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
 
When stars align: studies in data quality, knowledge graphs, and machine lear...
When stars align: studies in data quality, knowledge graphs, and machine lear...When stars align: studies in data quality, knowledge graphs, and machine lear...
When stars align: studies in data quality, knowledge graphs, and machine lear...
 
Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*
 
UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
 
FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf
FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdfFIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf
FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf
 
Epistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI supportEpistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI support
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
 
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using SmithyGenerating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using Smithy
 
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
 

Security of software defined networking (sdn) and cognitive radio network (crn)

  • 1. Security of Software Defined Networking (SDN) Cognitive Radio Network (CRN) Prepared by: Ameer Sameer Hamood University of Babylon - Iraq Information Technology - Information Networks
  • 2. Security of Software Defined Networking (SDN) Overview Definition Software Defined Networking (SDN) SDN security & Security Challenges SDN Attack Surface & Attacks Examples SDN Threat Model Open Research issues SDN Future Research Directions Simulator for Software Defined Networking
  • 3. Overview Definition Cognitive Network Security of Cognitive Radios & Threats Security issues in cognitive radio Attacks and the proposed defense mechanisms Open Research issues in Cognitive Radio Evaluation Methodologies for Cognitive Networking Future Research Directions Simulator for Cognitive Radio Security of Cognitive Radio Network (CRN)
  • 4. What is Software Defined Networking (SDN) ? •All of these are mechanisms. • SDN is not a mechanism. •It is a framework to solve a set of problems Many solutions •Software-Defined Networking (SDN) has been envisioned as a way to reduce the complexity of network configuration and management, enabling innovation in production networks. Figure 1
  • 5. SDN is a framework to allow network administrators to automatically and dynamically manage and control a large number of network devices, services, topology,traffic paths, and packet handling(quality of service)policies using high-level languages and APIs. See fig 2: Software Defined Networking Definition Figure 2
  • 6. Although much has been said about the benefits of SDN to solve persistent network security problems, our current knowledge on SDN threats and attacks is limited. The new systems required to carry out SDN functions may themselves come under malicious attacks.While some attacks will be common to existing networks, others will be more specific to SDN. Adversaries will inevitably exploit SDN systems if a successful network compromise could be achieved through such exploitations. A vulnerable SDN network could therefore undermine security and availability of the entire network. See fig 3: Software Defined Networking Security
  • 7. Figure 3 Software Defined Networking Security (con..)
  • 8. New features and new network deployments can introduce faults and risks that open the door for threats that did not previously exist or are more serious than before. For example one provider’s SDN controller can directly access and manipulate another provider’s SDN switches. This configuration is not recommended for deployment in practice. In addition to the traditional attack vectors on traffic flows, switches, administrative stations, and recovery and fault diagnosis, the controllers and the communications related to the Controller plane result in new security issues that are specific to SDN. SDN-Specific Security Challenges
  • 9. 1- Centralized Control 2- Programmability A - Traffic and resource isolation B - Trust between third party applications and the controller C - Interface Security protection on A-CPI and I- CPI 3- Challenge of Integrating Legacy Protocols 4- Cross Domain Connection 5- etc… SDN-Specific Security Challenges(cont..)
  • 10. 1- Centralized Control Centralized control or logically centralized control (i.e. distributed but coordinated control function) exposes a high-value asset to attackers. Attackers may attempt to manipulate the common network services or even control the entire network by tricking or compromising a controller . This is distinct from a larger number of autonomous assets in a completely distributed control domain. SDN-Specific Security Challenges(cont..)
  • 11. 2- Programmability New types of threats arise due to the explicit programmatic access SDN offers to clients that are typically separate organizational or business entities. This new business model presents requirements that do not exist within closed administrative domains in terms of protecting system integrity, third-party data and open interfaces. SDN-Specific Security Challenges(cont..)
  • 12. 2- Programmability A-Traffic and resource isolation Operators must ensure that business management and real- time control information of one entity is fully isolated from that of all others Best practices from existing automated interfaces between customer and provider business support systems may be of use here. This element extends to the existing security issue of multi-tenant traffic and resource isolation to avoid interference and misuse. Due to the new business model for SDN described above, there may be additional dynamic interactions introducing further requirements for isolation in order to meet different SLAs, private addressing issues, etc. SDN-Specific Security Challenges(cont..)
  • 13. 2- Programmability B- Trust between third party applications and the controller Programmability is a double-edged sword; it offers flexibility to implement newly innovated market- driven applications but it also opens the door to malicious and vulnerable applications. Authentication and different authorization levels should be enforced at the point of application registration to the controller in order to limit the controller exposure. SDN-Specific Security Challenges(cont..)
  • 14. 2- Programmability C- Interface Security protection on A-CPI and I-CPI Beyond the communication with applications through A-CPIs a controller may be controlled either by an upper layer controller or may work in tandem with another controller at the same hierarchical level. Lack of protection across these interfaces may lead to malicious attacks on the SDN. Security attributes and operation checkpoints should therefore be defined for securing A-CPIs and I-CPIs (Intermediate - controller plane interface). SDN-Specific Security Challenges(cont..)
  • 15. 3- Challenge of Integrating Legacy Protocols SDN interfaces and protocols are being developed in the recognized context of escalating exploitation of technical and process deficiencies, with increasingly severe consequences that could lead to security issues. However, experience has demonstrated the difficulty of retrofitting security capabilities into existing technologies (Domain Name Server (DNS) and Border Gateway Protocol(BGP) are notable examples). It is critical that compatibility be checked before implementing legacy protocols (e.g., Network Address Translation (NAT), BGP) into SDN. It is also important that weaknesses previously addressed by legacy architectures not be repeated or even inflated when building the SDN framework. SDN-Specific Security Challenges(cont..)
  • 16. 4- Cross Domain Connection An additional requirement of SDN implementation requires that infrastructure of different domains can be connected. This can be realized by connecting controllers of different providers via the I-CPI. The mechanisms to establish trust relationships, to determine authorization level in order to prevent abuse and secure channel setup should all be considered. SDN-Specific Security Challenges(cont..)
  • 17. The SDN threat modeling requires understanding of the SDN architectural components and their interconnections. Figure 4 illustrates a typical SDN architecture to reveal the main SDN building blocks, which include the SDN planes and interfaces. Any of these architectural components could contain vulnerabilities and be exploited by attackers to compromise a SDN network. SDN Attack Surface
  • 18. Figure 4. The SDN components The SDN components Figure 4
  • 19. attacks could be launched on SDN components to achieve unauthorized access, unauthorized disclosure of information, unauthorized modification, destruction, and/or disruption of service. 1-Unauthorized Access Using Password Brute-Forcing or Password-Guessing Attacks 2-Unauthorized Access Using Remote Application Exploitation Attacks 3-Unauthorized Disclosure of Information Using RAM scraping Attacks 4-etc …… SDN Attacks Examples
  • 20. 1- Unauthorized Access Using Password Brute-Forcing or Password- Guessing Attacks •Figure 5. An unauthorized access attack is illustrated using the EXT->ACC->MGR path. SDN Attacks Examples(cont..) Figure 5
  • 21. 1- Generic network infrastructure threats 2- SDN specific Threats 3- Network Virtualization Threats SDN Threat Model
  • 22. 1- Generic network infrastructure threats 1- Physical threats 2- Damage/loss 3- Failures/malfunctions 4- Outages 5- Disaster 6- Legal
  • 23. we present types of threats that are specific to SDN. Such threats may relate to different assets in the reference SDN architecture 1- Data forging 2-Traffic diversion 3-Side channel attack 4- Flooding attack 5- Software/firmware exploits 6- Denial of Service (DoS) 7- Identity spoofing 8- API exploitation 9- Memory scraping 10- Remote application exploitation 11-Traffic sniffing 2- SDN specific Threats
  • 24. Figure 6 :Threats of SDN reference architecture 2- SDN specific Threats(cont..)
  • 25. 1- Data forging: This threat involves compromising an SDN element (e.g., controller, router, switch) in order to forge network data and launch other attacks (e.g., DOS). 2-Traffic diversion: This threat involves compromising a network element in order to divert traffic flows and to enable eavesdropping. Traffic diversion is a threat relating to network elements of the data plane. 3- Side channel attack: This threat involves extracting information on existing flow rules that are used by network elements. The threat can be realized by exploiting patterns of network operations (e.g. exploiting the time required for establishing a network connection). 2- SDN specific Threats(cont..)
  • 26. 4-Flooding attack: Flooding attacks involve compromising a SDN component in order to make it flood other components, which it interacts with. 5- Software/firmware exploits: This threat involves exploiting vulnerabilities of the software/firmware in order to cause some malfunction, reduction or disruption of service, eavesdrop data or destroy/compromise data. 6- Denial of Service (DoS): This threat relates to attacks aimed at causing reduction or disruption of the SDN service. DoS threats may occur in all layers of the SDN reference architecture. At the data plane, DoS can be caused by attackers, which flood the bandwidth or resources of network elements. 2- SDN specific Threats(cont..)
  • 27. 7- Identity spoofing: Identity spoofing is a threat where a threat agent successfully determines the identity of a legitimate entity and then masquerades this entity in order to launch further attacks. 8-API exploitation: This threat involves exploiting the API of a software component in order to launch different types of further attacks such as the unauthorized disclosure, compromise of integrity and/or destruction of information, or the unauthorized destruction/ degradation of service. 9-Memory scraping: This threat arises when an attacker scans the physical memory of a software component in order to extract sensitive information that is it not authorized to have. 2- SDN specific Threats(cont..)
  • 28. 10- Remote application exploitation: In this threat, an attacker gains access or obtains higher access privileges to an SDN application by exploiting software vulnerabilities of it. This can then be used to execute operations illegitimately. 11-Traffic sniffing:Traffic sniffing involves tapping data flows within a network. In SDN, traffic sniffing has been identified primarily as an attack upon the communication link between an application at the SDN application plane and a controller at the control plane in order to gain access to important controller configuration data or application-level credentials. 2- SDN Threat Model(cont..)
  • 29. 3- Network Virtualization Threats Network virtualization threats are threats related to the underlying IT infrastructure used for virtualizing network operations. Such threats can be distinguished into: 1- Threats related to servers running virtualized network functions (virtualized host abuse) 2- Threats to data centres hosting SDN operations (Data centre threats): 3- Threats related to virtualization mechanism: (Network Virtualization bypassing):
  • 30. • Scalability: • Control plane bottleneck. • Single controller is not sufficient to manage large scale network. • How many controllers are needed to support large scale network? • When to scale down? • Multi Controllers. • Each controller is responsible to a subset of the network. • Concern with synchronization and communication between controllers. • How to slice the resources among controllers? • Latency between controllers and switches. • Less accurate decision? What is Relation between WSN and SDN? Open Research issues SDN
  • 31. Open Research issues SDN(cont..) • Slicing Resources (CPU, bandwidth, etc). - How to allocate resources to different controllers and users? - Formulated to optimization and fairness problems. • Using SDN to achieve more green DCN. •No substantial works in this area. •As 2015, few publications on this subject are published in IEEE ICC and IEEEE Globecom. •Some software may provide measurement on power usage or capability to turn on/off switches. • NetFPGA, Mininet and OpenFlow? How to leverage from SDN approach to have more flexible and secure WSN & IoT?
  • 32. Open Research issues SDN as 2015(cont..)
  • 33. The future, however, will most likely use a combination of these (and perhaps other) models, standards, and implementations. Models such as I2RS are likely to be used to provide network programmability in those heterogeneous environments in which scalability is the primary concern. The architectural models underlying I2RS envision layered, distributed control planes in which the control and data planes share fate. Future Research Directions
  • 34. Using a software-defined radio together with MATLAB and Simulink for wireless design, simulation, and analysis enables engineers and students to: 1- Set up SDR hardware with preconfigured radio functions 2- Transmit and receive standards-based and custom-generated signals 3- Test designs in the presence of interference and other real- world conditions 4- Perform real-time signal analysis and measurement 5- Deploy, prototype, and verify custom designs on SDR hardware using HDL and C code generation from algorithm models 6- Verify implementation with radio-in-the loop tests Simulator for Software Defined Networking
  • 35. Pareto-Optimal Resilient Controller Placement in SDN-based Core Networks by David Hock, Matthias Hartmann, Steffen Gebert, Michael Jarschel, Thomas Zinner, Phuoc Tran-Gia from the University of Wuerzburg, Germany A Matlab-based tool for calculating pareto-optimal placements of controllers in a network topology. https://github.com/lsinfo3/poco Pareto Optimal Controller Placement (POCO) Matlab-based tool Figure 7
  • 36. OpenDaylight SDN Controller with the Mininet Network Emulator OpenDaylight (ODL) is a popular open-source SDN controller framework. To learn more about OpenDaylight, it is helpful to use it to manage an emulated network of virtual switches and virtual hosts. Most people use the Mininet network emulator to create a virtual SDN network for OpenDaylight to control. https://www.opendaylight.org/platform-overview-beryllium Figure 8
  • 37. Mininet Network Emulator Mininet is a network emulator which creates a network of virtual hosts, switches, controllers, and links. Mininet hosts run standard Linux network software, and its switches support OpenFlow for highly flexible custom routing and Software-Defined Networking. Mininet supports research, development, learning, prototyping, testing, debugging, and any other tasks that could benefit from having a complete experimental network on a laptop or other PC.http://mininet.org/ Figure 9
  • 38. NS-3 Network Simulator NS-3 is a discrete-event open-source network simulator for Internet systems, used primarily for research and educational use. NS-3 is a complex tool that runs simulations described by code created by users, so you may need programming skills to use it. https://www.nsnam.org/ Figure 10
  • 39. Cognitive radio offers the promise of intelligent radios that can learn from and adapt to their environment. And change how they communicate, it's crucial that they select optimal, secure means of communications. Data integrity and confidentiality can be handled by higher-layer cryptographic security Cognitive radio can be described as an intelligent and dynamically reconfigurable radio . See Figure.11, cognitive radio scenario Definition Cognitive Network
  • 40. Figure.11, cognitive radio scenario Definition Cognitive Network(cont..)
  • 41. The main objective of the security system is to protect the communication from the malicious users. The cognitive radio network has the same security requirements as that of the general wireless networks because of the open air nature of wireless media . The major difference between the cognitive radio network and the traditional wireless network is that it doesn’t operate on a fixed frequency spectrum i.e. the frequency spectrum is being used dynamically. Security of Cognitive Radio
  • 42. Security of Cognitive Radio at different layers 1- Physical layer - Example of possible attacks (Intentional jamming attack) 2- Link layer - Example of possible attacks (Biased utility attack , DOS attack) 3- Network layer - Example of possible attacks (Hole attack) 4- Transport layer - Example of possible attacks (Key depletion attack) 5- Application layer - As a result, any attack on physical, link,network or transport layers may have an adverse affect on the application layer
  • 43. - Secure authentication mechanisms, - Confidentiality, - Data integrity, - Accessibility, - Multimodal strategies for the isolation of adversary nodes, - Ability to differentiate between adversaries and unintentionally misbehaving SUs Security Requirement of Cognitive Radio
  • 44. Threat is a constant danger through persons, objects, or any resources where as an attack is an act of or event that exploits the vulnerability. The policies, learning mechanisms, and self-propagation in cognitive radio architecture prevents the threats (cannot escape the threats). In CR, a threat can happen while sensing of information (due to involvement of a malicious user).This information will then feed for learning and decision making. The results produced will lead to inappropriate decisions (unacceptable decisions) due to a malicious user injected the faults. Threats and Attacks in Cognitive Radio Networks
  • 45. Attacks Layer Involved in Cognitive Radio Networks
  • 46. Cross-layer attacks are possible in CRN. There is a need to be given individual attention for such attacks. Jamming on routing information happens due to lack of common control channels. Traffic analysis attack on data privacy and location privacy will be avoided by authentication and controlling the access rights of cognitive user. Attacks Layer Involved in Cognitive Radio Networks(cont..)
  • 47. In comparison with traditional wireless networks, there are more chances open to attackers in cognitive radio technology. As a result, security in cognitive radio networks has become a challenging task . Quality of service (QoS) provisioning and security requirement for the entire network may be adversely affected by these weaknesses and vulnerable aspects, introduced by the nature of cognitive radio .The data in the wireless media may be eavesdropped or altered without notice and the channel might be jammed or overused by the adversaries Security issues in cognitive radio
  • 48. - multi-hop cognitive radio networks - medium access control (MAC) and network layers of the multi-hop cognitive radio protocol stack. Issues considered include efficient spectrum sharing, optimal relay node selection, interference mitigation, end-to-end delay, etc. -Surveys on Channel Assignment Problem in CRN - Spectrum Assignment * Selection criteria, approaches, techniques, and challenges - Channel Assignment Algorithms * Coordination mechanisms, objectives, solving approaches, network types, number of radios, PU characteristics, routing dependencies, and channel Open Research issues in Cognitive Radio
  • 49. - Problems in Multichannel Hidden Terminal - Energy Efficient MAC Protocol - Self-interference Problem - Negotiation Mechanism and Time Synchronization Open Research issues in Cognitive Radio(cont..)
  • 50. 1- Broader Evaluation - System wide - Interdisciplinary - Scale - Safety - Realism - Rigor 2- Testbed Requirements 3- Cognitive Radio Platforms - Base stations , Client nodes , Mobile platforms 4- Testbed Deployment and Management Evaluation Methodologies for Cognitive Networking
  • 51. Most of the proposed solutions do not cover major issues related to CR dynamic environment. Therefore, some research proposals are first suggested in the context of MAC protocol entity. More research in future is required to search for accurate sensing schemes. Although the hardware limitations of CR users is a critical issue on spectrum sensing. So, more efficient and robust alternatives must be investigated in terms of CCC design. Clear assignments to deal with transmit power, coding scheme, transmission rate to the CR users must be devised Future Research Directions
  • 52. Further research may include QoS for SUs in the context of dynamic resource availability. However, ensuring a reliable network coordination and reconfiguration mechanism is another major issue that must be addressed efficiently. Majority of the current research has focused on improving the throughput of CR networks. Clear assignments to deal with transmit power, coding scheme, transmission rate to the CR users must be devised. MAC Design focusing on energy introduces new challenges in CR MAC design research. Future Research Directions(cont..)
  • 53. 1- simulation framework based on NS2 (CogNS) for cognitive radio networks 2- NS-3 Simulator Extension for Cognitive Radio 3- matlab 4- Cognitive Radio Simulation based on OMNeT++/MiXiM Simulator for Cognitive Radio
  • 54. simulation framework based on NS2 (CogNS) framework can be used to investigate and evaluate the impact of lower layers, i.e., MAC and physical layer, on the transport and network layers protocols. Due to the importance of packet drop probability, end- to-end delay and throughput as QoS requirements in real- time reliable applications, these metrics are evaluated over CRNs through CogNS framework.http://cogns.net/ Figure 12
  • 55. OMNeT++ CR Simulation Framework OMNeT++/MiXiM was chosen as the developing platform, mainly due to its open source nature, its well- organized modular architecture, the existing documentation, and the provided IDE (Integrated Development Environment).https://omnetpp.org/ Figure 13
  • 56. Conclusions Security of Software-Defined Networks (SDN) Security within the SDN paradigm will arguably be a challenge, as all layers, sub-layers and components will need to communicate according to strict security policies. Security challenges for Software-Defined Networks differ in some respects from those of a classical network due to the specific network implementation and SDN’s inherent control and programmability characteristics. our current knowledge on SDN threats and attacks is limited. The new systems required to carry out SDN functions may themselves come under malicious attacks. While some attacks will be common to
  • 57. Security of Cognitive Radio Network (CRN) Most of the attacks presented are specific to PHY-layer cognition. Sensors and decisions at higher layers can often be cryptographically protected, making them less vulnerable to manipulatory attacks. The threat detection mechanisms can be developed for cognitive radio networks in the same lines of intrusion detection mechanisms. The threat detection and protection of information are serious issues in wireless networks as well as cognitive radio networks Intrusion detection models are required in such situations. Cryptographic techniques are useful with the additional burden of computing time.The trust models are more appropriate than to cryptographic techniques due to their simplicity and computational efficiency. Cloud application helps to Conclusions
  • 58. Review Question 1- What is the relation between SDR and Cognitive radio ? 2- What would be an appropriate conceptual model for SDR- CR? 3- What is self-propagating AI virus in A virus spreading model for cognitive radio networks ? 4-What is The function of MAC protocols to ensure interference-free (with PUs or other CR users) in CR networks? 5- what is The Impact of SDN on Network Security ? 6- Give list some important design issues that are necessary to be addressed in distributed CR MAC design? 7- What is CCC of CR MAC protocols ? 8- What is Technical recommendations for Administrators
  • 59. Reference 1-Introduction to Software Defined Networking (SDN) Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 , 2013 2- Taxonomic Modeling of Security Threats in Software Defined Networking , Jennia Hizver, PhD ,BlackHat Conference , August 5-6, 2015 3- Principles and Practices for Securing Software-Defined Networks , January 2015, ONF TR-511 4- The Software-Defined-Networking Research Group Published by the IEEE Computer Society 1089-7801/13/$31.00 © 2013 IEEE 5- “Cognitive Radio Communications and Networks: Principles and Practice” By A. M. Wyglinski, M. Nekovee, Y. T. Hou (Elsevier, December 2009) 6- Security in Cognitive Radio Networks : Threats and Mitigation ,T. Charles Clancy, Nathan Goergen 7- Security in Cognitive Radio Networks Kresimir Dabcevic, Lucio Marcenaro, Carlo S. Regazzoni , University of Genova, Italy
  • 60. 8- Security Challenges in Cognitive Radio Networks , Hanen Idoudi, Kevin Daimi, and Mustafa Saed 9-- Future Directions in Cognitive Radio Network Research , NSF Workshop Report Edited by: Peter Steenkiste, Douglas Sicker, Gary Minden, Dipankar Raychaudhuri March 9-10, 2009 10- Cognitive Radio: Technology Survey and Future Research Directions José Marinho , Edmundo Monteiro 11- AN INVESTIGATION OF SECURITY CHALLENGES IN COGNITIVE RADIO NETWORS By Deepraj Vernekar in 30-12-2012 12- Cognitive Radio Networks edited by Yang Xiao, Fei Hu 13- Cognitive Radio RF: Overview and Challenges Van Tam Nguyen,1 Frederic Villain,2 and Yann Le Guillou3 1 Institut Mines-Telecom, Telecom ParisTech, LTCI CNRS UMR 5141, 75634 Paris, France 2 BL TV Front End, NXP, 14460 Colombelles, France 3 Renesas Mobile Corporation, 35517 Cesson Sevigne Cedex, France Reference
  • 61. 14-Threat Landscape and Good Practice Guide for Software Defined Networks/5G DECEMBER 2015 by European Union Agency For Network And Information Security 15- Introduction to Software Defined Network (SDN) By Hengky “Hank” Susanto, Sing Lab, HKUST 16- Security Issues and Threats in Cognitive Radio Networks •Yenumula B. Reddy • Department of Computer Science, Grambling State University •Grambling, Louisiana, USA 17- Channel Assignment Algorithms in Cognitive Radio Networks: Taxonomy, Open Issues, and Challenges ARTICLE in IEEE COMMUNICATIONS SURVEYS & TUTORIALS · OCTOBER 2014 18- Cognitive Radio MAC Protocols: A Survey, Research Issues, and Challenges Mahfuzulhoq Chowdhury1, Asaduzzaman1, and Md. Fazlul Kader Received November 19, 2014; Revised December 29, 2014; Accepted January 26, 2015; Published February 28, 2015 Reference

Editor's Notes

  1. Recent advances in software defined networking (SDN) provide an opportunity to create flexible and secure next-generation networks. Many companies have expressed the interest in SDN utilization. Although much has been said about the ability of SDN to solve persistent network security problems, our current knowledge on SDN vulnerabilities, threats, and attacks is limited.
  2. */ Software Define Networking (SDN) is an emerging networking paradigm that aims to change the limitations of the traditional networking. The value of SDN lies in its ability to provide consistent policy enforcement and deliver greater scalability and control over the entire network by means of centralized management and network programmability. The next generation of security solutions will take advantage of the wealth of network usage information available in SDN to improve policy enforcement and traffic anomaly detection and mitigation. */ Management includes provisioning, operating, monitoring , optimizing, and managing FCAPS (faults , configuration, accounting, performance, and security) in a multi-tenant environment.
  3. */ In order to secure SDN networks, all of the potential security threats and attacks must be anticipated before attackers take advantage of vulnerabilities. In general, security-enabling mechanisms for SDRs can be divided into hardware-based and software-based ones, each with their own advantages and disadvantages. Hardware-based mechanisms include hardware modules for monitoring the SDR’s reconfigurable parameters. However, unlike the SDRs they are securing, these mechanisms themselves are typically not easily reconfigurable, and updating the security parameters or policies may be problematic and expensive. Software-based mechanisms rely on deploying the tamper-resistance techniques, providing safe and secure authentication, communication security and integrity, as well as safe algorithms for download, updating and distribution of the software. The potential vulnerability of such schemes is the openness to malicious modification.
  4. */ SDN-based security architecture to improve network security. The solution has the following features Delegate tasks to multiple controllers (instead of a single controller) Detection of high-resolution attacks such as ARP Cache Poisoning, and ARP Spoofing, that cannot be detected without access to all incoming packets of a networking device Detection of low-resolution attacks such as DoS, DDoS, and DNS Amplification, that does not necessarily require access to all the incoming packets. Usage of an intelligent component "Orchestrator" which handles both high-resolution and low-resolution attacks differently >>>>>> SDN orchestration platforms can include many types of proprietary or open source software, often built using common APIs that can tie into standard networking technologies. Some of the companies that supply or develop SDN orchestration tools include Anuta Networks, Big Switch, CENX, Cisco Systems, Cyan, Nuage Networks, Overture Networks, and UBIqube. SDN orchestration often involves coordinating software actions with an SDN Controller, which can be built using open source technology such as OpenDaylight. The controller can also be programmed to make automate decisions about the network, in the case of traffic congestion, faulty devices, or security problems. SDN-based orchestration can use a number of network protocols including OpenFlow and IP-based networking. >>>> Decoupling of the network monitoring component from the controller to reduce overhead on it Applications for detecting and mitigating attacks such as ARP spoofing / cache poisoning, Denial of Service (DoS), Distributed Denial of Service (DDoS), Domain Name System (DNS) amplification attacks, and Port Scanning behavior
  5. */service-level agreements (SLAs). SLAs originated with network service providers, but are now widely used by telecommunication service providers and cloud computing service providers. SLAs measure the service provider’s performance and quality in a number of ways.
  6. */ Intermediate - controller plane interface).or Data - controller plane interface D-CPI between data and controller planes, across which the SDN controller controls data plane resources ::::: */ Application - Control Programming Interface A-CPI between application and SDN controller, across which an application receives services from the SDN controller
  7. Figure 1. The SDN components include applications (APP), controllers (CTRL), network elements (NE), management consoles (MGR), the northbound interface (NBI), the southbound interface (SBI), east/west bound interface (EWBI), and the management interface (MGI). The following planes are identified in SDN: · the data plane comprising network elements for traffic forwarding or processing · the controller plane comprising a set of controllers, which control network elements in the data plane · the application plane comprising applications with access to resources exposed by controllers · the management plane comprising management consoles for applications, controllers, and network elements and supporting remote management tasks. The following interfaces are identified in SDN: · the east/west bound interfaces required by distributed controllers for importing/exporting data between controllers and monitoring/notification capabilities · the northbound interfaces enabling the communication between the controller plane and the application plane the southbound interfaces providing the link between the controller plane and the data plane · management interfaces performing management functions on applications, controllers, and network elements in each plane.
  8. Unauthorized Access Using Password Brute-Forcing or Password-Guessing Attacks An attacker residing on a non-SDN element may achieve unauthorized access to a SDN component. For instance, an attacker may access a management console through random or systematic guessing of passwords (see Figure 5). The compromised console would empower the attacker with resources to launch attacks on the controller and the network managed by the controller. Unauthorized Access Using Remote Application Exploitation Attacks By exploiting a software vulnerability in a SDN component, an attacker may be able to gain unauthorized access to the component. For instance, an attacker with access to a management console may exploit a buffer overflow vulnerability in a SDN application server to gain access to SDN applications Unauthorized Disclosure of Information Using API Exploitation Attacks The controller plane provides APIs for applications to query SDN network information and to monitor and react to network changes. The APIs or applications built using the APIs may contain vulnerabilities that could allow an attacker to perform a variety of information disclosure attacks. For example, an unauthorized disclosure of information case could involve a malicious user harvesting information regarding flow rules by exploiting the northbound interface Unauthorized Disclosure of Information Using RAM Scraping Attacks In a traditional RAM scraper attack, the attacker first gains unauthorized access to a victim system, and scans its physical memory in the hope to extract sensitive information. If an attacker is successful in gaining access to a SDN application server, the attacker may scan SDN-related process memory to extract flow rules that may have previously been sent in an API request to a controller
  9. Physical threats: This type of attack refers to actions (attacks) aimed at destroying, disabling, altering or stealing physical ICT infrastructure assets. This type of threat applies to any network and computing infrastructure, including SDN/5G infrastructures. Physical threats are very important due to the virtualisation of networking functions, which may result in deploying such functions in remote servers and data centres. Despite the existence of physical protection mechanisms (e.g., physical surveillance and surveillance cameras, security locks, security guards), physical breaches and insider threat attacks still occur53. Examples of such attacks include fraud, sabotage vandalism, theft, information leakage/sharing, unauthorised physical access and terrorist attacks. Damage/loss: This type of threats refers to intentional or unintentional destruction of ICT infrastructure. It may be physical as for example the destruction of a server or take the form of a cyber damage as, for example, mixing-up information in a data centre due to maintenance errors or erroneous system administration. Failures/malfunctions: This type of threats refers to failures or insufficient functioning of network and infrastructure subsystems. Examples of this threat type include failure or malfunctioning of devices including network elements, controllers and network management applications, disruption of the communication links, and/or failure of service providers. Outages: This type of threats refers to the interruption or failure in the supply of a service. In the case of SDN/5G networks, it includes interruption of support services such as Internet and electricity, the loss of network connectivity either due to cable errors or the loss of (part of) a wireless network, or loss of human (e.g. strike of employees of a network operator) or physical resources. Disaster: A disaster is a sudden incident that interrupts the daily activities of the society. It can be categorised in disasters caused by the intervention of human (environmental) or natural disasters such as floods, earthquakes etc. Legal: Since the 5G landscape is of multi-operator nature, where all operators will be interconnected to each other, multi-operator related threats are very important, operators of the SDN infrastructure that will not honestly stick to business agreements (SLAs) should be considered. Moreover, measures for non-repudiation of SLAs between different operators should be considered.
  10. Data forging: This threat involves compromising an SDN element (e.g., controller, router, switch) in order to forge network data and launch other attacks (e.g., DOS). Whilst data forging may, in principle, relate to data held by any component of an SDN (e.g., network switches, controllers and/or SDN applications), a threat specific to SDN consists in forging requests from accessible low level SDN controllers to upper level ones, in order to drive their decisions on how to redefine large parts of the network. In the literature it has been identified as a threat related to components in the data plane and the controller plane. Traffic diversion: This threat involves compromising a network element in order to divert traffic flows and to enable eavesdropping. Traffic diversion is a threat relating to network elements of the data plane. A specific kind of traffic diversion that is available in virtualized networks is network slice trespassing. This occurs when the mandatory isolation between slices is compromised in any active node or when the enforcing access to a slice in the edge equipment is either bypassed or misconfigured. This ends with alien traffic circulating on a given slice. Side channel attack: This threat involves extracting information on existing flow rules that are used by network elements. The threat can be realised by exploiting patterns of network operations (e.g. exploiting the time required for establishing a network connection). Side channel attacks is a threat relating to network elements of the data plane.
  11. Flooding attack: Flooding attacks involve compromising a SDN component in order to make it flood other components, which it interacts with. Flooding occurs through the transmission of data that can exhaust component resources and lead to a reduction or complete shutdown of the service provided by the component. Flooding attacks occur primarily for network components of the data plane. In such cases, the threat involves compromising a network component in order to make it flood its controller with network messages, and overload and eventually exhaust the controller’s resources. Flooding attacks can also occur at the control plane. In such cases, a controller is flooded with messages from other (malicious) controllers that can exhaust its resources causing a reduction or complete shutdown of the controller’s service. Specific to SDN are amplification flooding attacks where a small stream of requests with a faked sender elicits a flooding large stream of response. While protection from such attacks have been devised for many known network protocol, the exposure of several network functions (NFV) by SDN controllers presents a whole new landscape of threats. Software/firmware exploits: This threat involves exploiting vulnerabilities of the software/firmware in order to cause some malfunction, reduction or disruption of service, eavesdrop data or destroy/compromise data. Software/firmware exploits may occur in all layers of the SDN reference architecture, and depending on the layer that they relate to they have been distinguished into network element software/firmware exploits, controller software/firmware exploits, and SDN applications software/firmware exploits. Software/firmware exploits of network elements and controllers cause the malfunction or even their termination of operation. In the case of switches, for example, the exploited switches can drop, slow down, clone or deviate network traffic. Exploited switches software/firmware can also create forged traffic in order to exhaust other switches and/or the controllers the switches are connected to. Denial of Service (DoS): This threat relates to attacks aimed at causing reduction or disruption of the SDN service. DoS threats may occur in all layers of the SDN reference architecture. At the data plane, DoS can be caused by attackers, which flood the bandwidth or resources of network elements. This arrack type in many occasions originate by multiple compromised systems, such as botnets, which are flooding the targeted SDN with traffic. At the control plane, a DoS can be caused by congesting controllers through a large number of forged flow arrivals, causing network performance degradation and interruption. Traditional DoS defences’ approaches focus on protecting the data plane, and are therefore ineffective in the cases of SDN control plane DoS attacks. DoS attacks may also appear at the application plane affecting, for example, network management applications.
  12. Identity spoofing: Identity spoofing is a threat where a threat agent successfully determines the identity of a legitimate entity and then masquerades this entity in order to launch further attacks. Identity spoofing is a threat that can affect any type of software component or human agents. In the case of SDN, identify spoofing has been identified as an attack affecting mainly SDN controllers (SDN controller identity spoofing). In this attack, the attacker spoofs the identity of a legitimate controller and interacts with the network elements controlled by the legitimate controller (i.e., elements of the data plane) in order to trigger several other types of attacks (e.g., instantiate network flows, divert traffic etc.). API exploitation: This threat involves exploiting the API of a software component in order to launch different types of further attacks such as the unauthorized disclosure, compromise of integrity and/or destruction of information, or the unauthorized destruction/degradation of service. In SDN, API exploitation may relate to all the different types of APIs that may be found in an SDN. These include: (a) the Northbound API (Northbound API exploitation) that facilitates the communication between SDN controllers and SDN applications; (b) the Southbound API that facilitates the communication between SDN network elements and SDN controllers (i.e., Southbound API exploitation), and (c) the Eastbound/Westbound API that facilitates the communication between SDN controllers (i.e., Eastbound/Westbound API exploitation). Memory scraping: This threat arises when an attacker scans the physical memory of a software component in order to extract sensitive information that is it not authorised to have. Whilst in SDN, memory scrapping can affect components of any layer, this type of threat has been primarily identified for SDN application servers41. While the memory scrapping threat is exclusive to SDN, a core dump (e.g. as the result of malicious software) can be used to exploit private data. Furthermore SDN reconfiguration may require reboots that an attacker could use in order to attack the boot procedure. Once successfully performed, memory scrapping can be used to extract sensitive SDN data (e.g., flow rules at the Northbound API).
  13. Remote application exploitation: In this threat, an attacker gains access or obtains higher access privileges to an SDN application by exploiting software vulnerabilities of it. This can then be used to execute operations illegitimately. Traffic sniffing: Traffic sniffing involves tapping data flows within a network. In SDN, traffic sniffing has been identified primarily as an attack upon the communication link between an application at the SDN application plane and a controller at the control plane in order to gain access to important controller configuration data or application-level credentials. Traffic sniffing can be enabled by the use of weak or no encryption in the relevant communication link. It should be noted that traffic sniffing might also be used for legitimate reasons (e.g., for network monitoring and administration) and if used in this manner it should not be regarded as an attack.
  14. Threats related to servers running virtualized network functions (virtualized host abuse): Virtualisation of functions and their operation on virtual machines (e.g., a server that can be used as a network switch) is a common practice in SDN. Therefore traditional security threats for servers running virtualised network operations such as network monitoring, access control, network management etc. should be considered. Threats to data centres hosting SDN operations (Data centre threats): Many SDN systems are deployed within data centres. Hence, security threats of data centres should be considered, similarly to the server case. Moreover, data servers are using Data Centre Interconnect (DCI) protocols, which may lack authentication and encryption to secure the packet contents. Thus an attacker could create spoofed traffic in such a way that it traverses the DCI links or to create a DoS attack of the DCI connections. Threats related to virtualization mechanism: (Network Virtualization bypassing): The use of the network between different tenants need to assure that only legitimated traffic enters or leaves a network slice, but also that any switching element checks and enforces the traffic isolation by installing legitimate flow rules preventing slice trespassing.
  15. Answer ? Software-Defined WSN (SD-WSN), an architecture featuring a clear separation be-tween a data and a control plane, and Sensor OpenFlow (SOF), the core component of SD-WSN as a standard communication protocol between the two planes. The data plane consists of sensors performing flow-based packet forwarding, and the control plane consists of one (or possibly more) controller that centralizes all the network intelligence, performing network control such as routing and QoS control. relation between WSN and SDN Software -Defined Networking Logically centralized control the network behavior Proposed to reduce complexity of network configuration and management. Some proposals for WSN:−Flow-Sensor −Sensor OpenFlow SDWN
  16. data center network architectures have been proposed. They usually employ richly-connected topologies and multi-path routing to provide high network capacity. Unfortunately, they also undergo inefficient network energy usage during the traffic valley time. To address the problem, many energy-aware flow scheduling algorithms are proposed recently, primarily considering how to aggregate traffic by flexibly choosing the routing paths, with flows fairly sharing the link bandwidths. Answer : Use TinySDN combined to WSN-ETESec and key agreement protocol. − TinySDN : • enables different communication patterns • enables different applications • allows multiple controllers • runs on resource constrained platforms − WSN-ETESec • enables end-to-end security services on resource constrained devices Use TinySDN combined to WSN-ETESec and key agreement protocol to circumvent some challenges in WSN and IOT. While SDN started focusing on wired networks, there were proposals specifically for Wireless Sensor Networks (WSN), but all of them required a single controller to be coupled to the sink. TinySDN, a TinyOS-based SDN framework that enables multiple controllers within the WSN. It comprises two main components: the SDN-enabled sensor node, which has an SDN switch and an SDN end device, and the SDN controller node, where the control plane is programmed. TinySDN was designed and implemented to be hardware independent.
  17. in some environments (for example, data centers) overlay technologies can provide scale and adaptability. What we do know from our 25 or so years of building networks is that systems that are scalable, resilient, and evolvable have certain, well defined architectural features. One such feature is a distributed control plane. Nevertheless, the degree to which a control plane is centralized versus distributed remains one of the many active debates in the SDN community. Other features conferring scalability and evolvability include a high degree of layering, robust feedback control, and protocol-based architectures, among others. Debates notwithstanding, it’s clear that one key to building scalable and evolvable SDN systems will be to understand which pieces of the distributed control plane can be efficiently “peeled off” and run in a (logically) centralized fashion. For example, traffic engineering can clearly benefit from a global, network- wide view. PCE is an example of a traffic engineering technology under consideration as a candidate for measured separation of control and data planes, with the goal of making the network (more) programmable and architecturally centralized. Note, however, that even in the PCE case, the underlying distributed control plane remains. In this way, PCE retains the resilience and scale of the underlying distributed control plane while still providing programmability and a global network view for use in traffic engineering.
  18. http://www.mathworks.com/discovery/sdr.html?requestedDomain=www.mathworks.com
  19. The findings of the evaluations done with POCO have been published in the paper Pareto-Optimal Resilient Controller Placement in SDN-based Core Networks by David Hock, Matthias Hartmann, Steffen Gebert, Michael Jarschel, Thomas Zinner, Phuoc Tran-Gia from the University of Wuerzburg, Germany With the introduction of Software Defined Networking (SDN), the concept of an external and optionally centralized network control plane, i.e. controller, is drawing the attention of researchers and industry. A particularly important task in the SDN context is the placement of such external resources in the network. In this paper, we discuss important aspects of the controller placement problem with a focus on SDN-based core networks, including different types of resilience and failure tolerance. When several performance and resilience metrics are considered, there is usually no single best controller placement solution, but a trade-off between these metrics. We introduce our framework for resilient Pareto-based Optimal COntroller placement (POCO) that provides the operator of a network with all Pareto-optimal placements. The ideas and mechanisms are illustrated using the Internet2 OS3E topology and further evaluated on more than 140 topologies of the Topology Zoo. In particular, our findings reveal that for most of the topologies more than 20% of all nodes need to be controllers to assure a continuous connection of all nodes to one of the controllers in any arbitrary double link or node failure scenario.
  20. If openFlow is the most significant part of your work then use mininet. Otherwise if checking large nw behavior is as important as openflow, go for ns3. Even I was looking for simulators and after going through various resources have tentatively decided upon NS3. Mininet and estinet would be far easier than ns3 but ns3 would give you more control. ::::::: I find Mininet together with the open source controller of choice such as pox or floodlight good tools. For academic simulations, I use mininet and pox as they can be easily installed and configured by my students in their laptops. It doesn't need a lot of resources but has a lot of flexibility. Also each node in mininet is a process and various applications can be run on them. At the same time, it is powerful enough to model some complex topologies. Lastly, if Python is your cup of tea then both mininet and pox are extendible with Python.
  21. ns-3 has OpenFlow support which for the time being is restricted to being simulation only. Basically we have an OpenFlow switch [1] model that does not speak the actual switch - controller protocol, but instead, it talks to a singleton object that implements the controller behavior. There have been discussions around fixing this so that one may run a controller inside a VM, connect the VM to an ns-3 node using a tap-bridge device, and then run ns-3 in emulation mode. This would allow you to switch your controller logic from simulation to emulation and then to actual testbeds rather easily.
  22. While implementing security scheme in CR network various factors need to be taken into consideration because cognitive radio deals with the use of unused spectrum in an opportunistic manner with the unscheduled appearance of the primary users.
  23. Physical layer Physical layer is the lowest layer and it provides an interface to the transmission medium. Cognitive radio network doesn’t operate on a fixed frequency that is signals can be transmitted and received at various frequencies across wide frequency spectrum band. The frequency spectrum is used dynamically. Thus, this makes the operation of physical layer in cognitive radio more complicated. Spectrum sensing is a key part cognitive radio, since it deals with identifying vacant bands or spectrum holes. Following are the possible attacks associated with physical layer. Intentional jamming attack The malicious secondary user intentionally transmits signal in a licensed band and jams primary and other secondary users. The problem would be worse when the malicious mobile node launches attack in one geographical area and moves to another area before being identified Link layer Link layer sits just above physical layer in the protocol layer stack. This layer is responsible for transfer of data from one node to other in single hop. It ensures that initial connection has been set up, divides output data into data frames, and handles the acknowledgements from a receiver that the data arrived successfully. The MAC layer which controls channel assignment, is one of the important sub layers of the link layer. One of the important parameters to decide the fairness of a channel allocation scheme in traditional wireless environments is SNR. On the contrary, in cognitive network various parameters such as holding time, delay, Path loss, interference and link error rate are as important as the SNR. Hence channel assignment is a more complex operation in cognitive radio networks Biased utility attack A malicious secondary node may try to change the parameters of utility function in order to increase its own bandwidth. As a result of this the good secondary user is deprived of available bandwidth. DOS attack The main objective of malicious node is to prevent good secondary nodes from accessing the vacant radio frequency band. An attacker may try to jam a network and thus reduce a legitimate user’s bandwidth, prevent access to a service, or disrupt service to a specific system or a user. Network layer The main objective of network layer is end-to-end packet delivery. Functions of the network layer are routing, flow control, ensures quality of service (QoS). Every node maintains routing information about its neighboring nodes in the network. Before establishing connection, every node identifies which of its neighbors should be the next link in the path towards the destination. An attacker in the path can drastically alter routing by either redirecting the packets in the wrong direction or by broadcasting incorrect routing information to its neighbors. Following are the possible attacks associated with the network layer. Hole attack In the hole attack the node which pretends is called a hole. There are various types of hole attacks such as Black hole attack, Gray hole attack, Worm hole attack. Black hole attack is defined as attack in which the malicious node attracts/request packets from every other node and drops all the packets. The gray hole attack is defined as the attack in which the malicious node selectively drops the packets. The worm hole attack is defined as the attack in which the malicious user uses two pairs of nodes and there exist a private connection between the two pairs. The worm hole attack is a considered as dangerous attack amongst all. It can prevent route discovery where the source and the destination are more than two hops away. Protocols like Ariadne or secure AODV prevents such types of Transport layer The transport layer is responsible for transfer of data between two end hosts. It is responsible for flow control, congestion control and end-to-end error recovery. Some attacks occur during session setup, while others happen during the period of sessions. Following are the attacks associated with this layer Key depletion attack Sessions in cognitive networks last only for a short period of time due to frequently occurring retransmissions. Therefore, large numbers of sessions are being initiated. Security protocols at the transport layer like SSL and TLS establish cryptographic keys at the beginning of every transport layer session. Since numbers of sessions in cognitive networks are large, large numbers of keys are established, thereby increasing the probability of using the same key twice. Key repetitions can be exploited to break the underlying cipher system. The WEP and TKIP protocols used in IEEE 802.11 are more prone to key repetition attacks Application layer It is the top most layer of the protocol stack. It provides application services to the end users. Protocols that run at the application layer completely rely on the services provided by the underlying lower layers. As a result, any attack on physical, link, network or transport layers may have an adverse affect on the application layer
  24. Availability Within CRNs, the Base stations (BSs) should ensure the availability of spectrum needed by PUs and SUs. BSs should be equipped with the needed security measures to deter DoS attacks including distributed DoS. Authentication To ensure that CRN devices and components are communicating with a legal party, PUs, SUs, and other devices, authenticating them is essential. This applies to BS authenticating CRNs and CRNs authenticating each other. All components involved in the CRNs must be able to identify other legitimate devices and systems. Various cryptographic techniques are used for this purpose. CRNs should be capable of preventing or at least detecting various attacks on cryptographic protocols including man-in-the middle attack. Integrity It is demanding to ensure that the messages sent by BS, CRN, PU, or SU have not been modified when arriving at their destination. This assurance entitles that the messages received have not been through any modification, insertion, deletions, or replay on its way to its destination. Commands and signals issued by various constituents of the CRN are critical messages, and therefore, need to be clear of any modifications. Cryptographic hash functions and MACS need to be adopted to ensure message integrity. Confidentiality/Privacy PUs and SUs are interested in keeping their communications confidential. They want to ensure that their messages are only disclosed to the authorized CRNs, PUs, and SUs. In many applications, such as healthcare applications, privacy is essential. CRNs should adopt cryptology to enforce privacy.
  25. Many general schemes proposed in the past cannot satisfy such special network requirements, since the spectrum is used dynamically in cognitive radio. Cognitive radio network is similar to wireless network. Since the nature of the wireless media is open air, it is more vulnerable to attacks as compared to that of wired network.
  26. Well designed multi-hop cognitive radio networks can provide high bandwidth efficiency by using dynamic spectrum access technologies as well as provide extended coverage and ubiquitous connectivity for the wireless end users. However, the special features of multi-hop cognitive radio networks also raise several unique design challenges. medium access control (MAC) and network layers of the multi-hop cognitive radio protocol stack. Issues considered include efficient spectrum sharing, optimal relay node selection, interference mitigation, end-to-end delay, etc.
  27. Problems in Multichannel Hidden Terminal Problems in multichannel hidden terminals have been identified in multi-channel networks. A SU equipped with single radio can listen to only one channel at any time, and therefore can miss control messages when its radio is busy transmitting or receiving data. This SU might initiate communication with another SU node in an already allocated channel, resulting in a collision. This is called the MHTP. It can be better addressed in a multi-transceiver MAC protocol. But multiple radios at each SU node make the system more complex and expensive. However, single radio MAC protocols are much cheaper and less complex to implement. Cognitive networks enable efficient sharing of the radio spectrum. Multi-hop cognitive network is a cooperative network in which cognitive users take help of their neighbors to forward data to the destination. Control signals exchanged through a common control channel (CCC) to enable cooperation communication. But, using a common control channel introduces a new issue like channel saturation which degrades the overall performance of the network. Moreover, the multi-channel hidden terminal problem will be another important challenge in cognitive radio networks, in which the multi-channel hidden terminals can decrease the throughput, cause much overhead, and sometimes even make the whole network invalidated. Energy Efficient MAC Protocol The CR MAC design approach must address mechanisms that are energy efficient, since most of the devices are battery powered. The number of sensed channels must also be minimized through efficient mechanisms. Lightweight protocols are required for estimation, learning, and decision-making operations. Self-interference Problem The main challenge for active SU’s is to detect a PU’s presence during the data transmission phase. It is really difficult for active SUs to sense/detect and transmit at the same time and in the same channel. But without undergoing simultaneous sensing/detection and transmission, we cannot predict the presence of PUs. A multi-antenna-based system suffers from the self-interference problem created by both sensing/detection and transmission antennas . Usually, a multi-antenna system suffers from the self-interference problem. That’s why different sets of sensing/detection and transmission antennas were needed to avoid self-interference. Hardware implementations and detailed descriptions of antenna isolation are discussed in. The cancellation of active antennas based on spatial filtering to combat the self-interference problem is proposed in. They show that transmitted power cancels spatially in the direction of detection before reaching the detection antenna. They claim that a wideband isolation level of ~60 dB is obtained through their proposed system. Another method to improve the self-interference problem is proposed in Negotiation Mechanism and Time Synchronization There must be an efficient mechanism for a transmitter and its intended receiver to select a common available channel for transmission. In distributed CR networks, there is no central authority, which makes it necessary for SUs to go through a channel negotiation process. Many CR MAC protocols use CCC in an initial control message exchange, which is shared by many or all SUs. Some MAC protocols incorporate time synchronization among SUs. Selection of CCC is not easy and may also cause a loss of resources. Therefore, the channel negotiation mechanism should be designed properly. If not, it may be troublesome to manage the proper utilization of resources and overhead time. Without time synchronization, it is difficult to implement channel negotiation. It leads to improper coordination between network establishment and SUs. Therefore, network-wide time synchronization is a major research challenge at present, because of the uncertainty of spectrum availability.
  28. 1 Broader Evaluation Cognitive networks are very complex systems that include many components that are developed by widely different communities. Both the scope and the interdisciplinary nature of cognitive networks create unique challenges for the evaluation of cognitive networking research. For example: • System wide: Testing individual components is not enough – system level testing, i.e., involving all components integrated in a functional network, is essential to validate cognitive networking as a usable technology. Interdisciplinary: Researchers from different communities (communications, networking, policy, …) will want to evaluate their work both in isolation and in an integrated system context. • Scale: The scalability of the solutions needs to be evaluated. • Safety: Experiments, including failed experiments, should not affect/harm other wireless users. • Realism: The behavior and performance of a cognitive network will depend critically on many external factors such as traffic loads, user behavior and levels of interference. The CN system needs to be evaluated in ways that reflects realistic environments. One consideration that deployment environments can be very diverse, e.g., rural areas versus downtown DC. • Rigor: The evaluation needs to be very rigorous so the results are convincing. This is especially the case if results are needed to drive changes in policy in the DSA domain. 2 Testbed Requirements Evaluation of cognitive wireless networks requires two types of testbeds: Controlled testbeds that can be used for relatively early testing of prototypes of partially or fully integrated networks. Key requirements are flexibility (i.e., being able to run very diverse experiments and involving heterogeneous platforms), high degree of control (i.e., ability to create very diverse scenarios for testing), isolation, repeatability (so results can be validated and compared) and safety (i.e., errors in various network components will not cause any harm). Controlled cognitive testbeds can be based on a number of different technologies, including signal-propagation emulation, large anechoic chambers or testbeds in remote, isolated regions where ample spectrum is available. The scale of controlled testbeds can vary from tens to possibly a hundred nodes. Two examples of existing radio testbeds with cognitive networking capabilities are the CMU emulator [22] and the ORBIT radio grid testbed at Rutgers – these are briefly described in Appendix A. Open testbeds that can support larger scale experiments in fully realistic environments. The key difference with controlled testbeds is that being immersed in the real world (“open”), the signal propagation environment will include the effects of real world objects, mobile objects and people, and possibly interference from a variety of RF sources. Key requirements include heterogeneity (e.g., diverse devices and applications, mobile and stationary hosts, diverse device densities, etc.), use of a reasonably rich spectrum (involving licensed and unlicensed), and programmability at all levels of the system. Since any testbed will be tied to a particular physical environment, a small number of open testbeds in diverse contexts would be made available, e.g., rural, inner city, etc. targeting different classes of applications. Ideally, some of the testbed would involve real users to achieve a high degree of realism, since traffic load mobility, two key inputs to cognitive network behavior, depend in part on user behavior. Alternatively, 3 Cognitive Radio Platforms Multiple classes of platforms will be needed to populate the testbeds. These include: • Base stations: more powerful nodes with no power constraints • Client nodes: typically less capable, more compact and lower cost • Mobile platforms: more challenging clients since there are size, weight and power constraints. Some of these challenges may be reduced by using cars for deployment. • Wide band spectrum sensors • Various RF sources of interferences or different types of users in specific spectrum bands. 4 Testbed Deployment and Management The deployment of testbeds in outdoor environments (e.g., open testbeds or partially controlled testbeds in isolated areas) is very challenging. It may involve collocating equipment with commercial providers (e.g., on cell towers), right of ways issue, and power and network access in various locations. Ideally, these tasks would be handled by partner companies that have experience in this area. One example is Open Range Communication. Another challenge is the management of the testbed infrastructure and support for experiment control. These issues are currently being addressed by the GENI effort and it would make sense to leverage that work, for example by collaborating with one of the control frameworks that were established as part of the Spiral 1 development effort headed by BBN. Frameworks such as ProtoGeni already provide support for many functions such as node management, experiment control, federation, etc. in the context of heterogeneous testbeds. Note that GENI is currently focusing on integrating existing testbeds, rather than building new ones, so the focus of any CRN testbed effort would be complementary.
  29. CCC-based MAC protocol for CRNs. This protocol enables the cognitive users to exchange negotiation packets in the data channels such that no CCC is required. In this protocol, time is divided into slots and each slot is dedicated to one channel in order to control message exchange. All cognitive users in a network are synchronized and switch to a channel in the predefined time slots. A node beacons in all its available channels at the beginning of the corresponding time slots. After nodes receive a message, the nodes exchange information regarding their channel sets. After a network is initialized, nodes are synchronized and at the beginning of each slot, the control radio of every node tunes to the respective channel. When a cognitive user wants to send data to the receiver, the cognitive user selects a common channel between them. Then, the cognitive user sends a control message to the receiver at the beginning of the time slot. After the control message exchange, data transfer starts.
  30. This extension is written to add cognitive radio (CR) capabilities to the Network Simulator-3. It will cover the installation process, the documentation of such an extension and provide examples to get you started. We call this extension module CRE-NS3. This extension provides the basic blocks that are necessary to provide such functionality in Network Simulator 3 (ns-3). CRE-NS3 adhers to the ns-3 standards when it comes to documentations by using Doxygen. 
  31. Why based on NS-2? There are several reasons to base on NS-2 for the development of cognitive radio simulators. First, NS-2 is open source software. Any contributions to NS-2 are accessible by people around the world. Second, NS-2 provides an interface for users to configure different network protocol at each network layers, which is essential for simulation. Third, NS-2 already provides many radio models, such as 802.11, 802.16, 802.15.3, 802.15.4. Users can make use of these radio models for cognitive radio network simulations. Finally, NS-2 has incorporated with different topology and traffic generators, which enable users to create different simulation scenarios.