Software Defined Network

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
9 hours 59 minutes
Difficulty
Intermediate
CEU/CPE
10
Video Transcription
00:01
>> In this video, we'll take a look at
00:01
common approaches to Cloud network virtualization.
00:01
Then we'll spend most of our time taking
00:01
a deeper look at software-defined networks.
00:01
In the last video, we talked about creating
00:01
three isolated networks in
00:01
a particular Cloud and that was
00:01
a good approach for small-scale Cloud provider.
00:01
But when you do that,
00:01
the Cloud resources still need to
00:01
be able to talk to each other and they
00:01
themselves are going to want to define
00:01
virtual networks that
00:01
the cloud resources will operate in.
00:01
You can do this in several different ways.
00:01
One being virtual local area networks
00:01
also referred to as VLANs.
00:01
This is a common technology
00:01
used in a lot of enterprise networks,
00:01
whether it's Cloud-specific networks
00:01
or just your large office setup,
00:01
or an enterprise that spans, say,
00:01
multiple different buildings and physical locations.
00:01
VLAN technology essentially uses tagging of
00:01
network packets to create a single broadcast domain.
00:01
What this means is it's good for segmenting the network,
00:01
that is partitioning a network into
00:01
smaller networks but it's not
00:01
good for isolation and by isolation I mean,
00:01
restricting communication to
00:01
the intended destination machine only.
00:01
What that means is someone can create
00:01
a traffic sniffer very easily in intercept and
00:01
look at all the network traffic that is flowing between
00:01
two different devices or
00:01
endpoints that it really has no business looking at.
00:01
Your security team won't be happy if you
00:01
do this in your enterprise network and they
00:01
probably have technologies to detect when a machine is
00:01
just sniffing packets that it has no business looking at.
00:01
However, they may not catch you,
00:01
worse off they may not catch
00:01
the bad guys when a bad guy is
00:01
attempting to do then on the VLAN.
00:01
When you're in a multi-tenant environment,
00:01
that lack of isolation is no good,
00:01
but it is okay for
00:01
a single-tenant private Cloud scenario.
00:01
It's definitely not as effective as
00:01
security barrier as some of
00:01
the other options we'll discuss
00:01
and it does have some real performance and
00:01
size limitations when we're looking at Cloud scale.
00:01
Specifically, you're limited to the number of
00:01
IP addresses and devices that can be
00:01
connected to that network
00:01
and you really have to make sure that there's
00:01
no overlapping of IP addresses on that network.
00:01
Switching gears a little bit we
00:01
look at software-defined networking.
00:01
This abstracts the networking hardware,
00:01
brings things to another plane and it pushes
00:01
through those traditional LAN limitations.
00:01
It's very flexible for a multi-tenant environment.
00:01
In fact, it supports overlapping IP ranges,
00:01
even if we're talking about things running on
00:01
the same physical network hardware.
00:01
As a final point, SDNs have
00:01
both standard implementations and proprietary.
00:01
One of the most popular standard implementations
00:01
for SDN is OpenFlow.
00:01
This was first released in 2011
00:01
by the Open Networking Foundation,
00:01
and it was a major influence on RFC 7426.
00:01
That is the Request for Comments,
00:01
basically the open specification
00:01
entitled SDN layers in architecture terminology.
00:01
On the right, you can see there's three layers,
00:01
application layer, controller layer,
00:01
infrastructure layer.
00:01
There are actually many open-source implementations
00:01
of controller layers.
00:01
These controller layers, they communicate with
00:01
OpenFlow compliant network devices to
00:01
manage flow tables and direct traffic.
00:01
The devices at
00:01
the very bottom, that infrastructure level,
00:01
these are physical device is operating at Layer 2,
00:01
directing the traffic at Layer 2.
00:01
This means the physical devices hosting
00:01
your Cloud network understand
00:01
the OpenFlow protocol and will
00:01
behave according to what
00:01
the control layer tells them to do.
00:01
Not all devices do this and it's
00:01
a special device you're going to be looking
00:01
at closely if you are creating
00:01
a private Cloud or a community Cloud.
00:01
Now, diving a bit deeper and SDN architecture,
00:01
we have this really complicated diagram
00:01
that I pulled off of Wikipedia.
00:01
It depicts a lot of the details
00:01
about how an SDN is implemented.
00:01
The very left pillar on the diagram
00:01
depicts three different planes. You see them there.
00:01
There's the application plane,
00:01
the control plane, and the data plane.
00:01
This is akin to the three layers that we
00:01
just described in the OpenFlow diagram,
00:01
except they're named a little bit differently.
00:01
The control plane sits in the middle layer,
00:01
and this is the brains behind defining
00:01
the rules of how traffic should be routed.
00:01
In traditional networking, you
00:01
have a router device and that
00:01
plays the control plane at Layer 3 by
00:01
determining how traffic should be
00:01
routed and then that device
00:01
forwards the traffic appropriately
00:01
working with DataFrames on layer two.
00:01
In the SDN world,
00:01
the data plane are responsible for that second part.
00:01
The data plane follows the orders from the control plane
00:01
and sends packets between the interfaces.
00:01
We'll go into this in more detail,
00:01
but this decoupling between the control plane and
00:01
data plane makes it much easier to secure these networks.
00:01
On the diagram, you'll notice the data plane is
00:01
physically below the control plane.
00:01
If this was a traditional geography map,
00:01
we'd say that the data plane is to the south of
00:01
the control plane and to the north of
00:01
the control plane sits the application plane.
00:01
The control plane talks to
00:01
the application plane using northbound interfaces.
00:01
You'll notice the diagram abbreviates these as NBIs.
00:01
Applications running in this plain talk with
00:01
the control plane and vice versa using those NBIs.
00:01
As a result, the application
00:01
can build an abstracted view of
00:01
the network by collecting
00:01
information from the control plane.
00:01
These applications include
00:01
networking management analytics,
00:01
and business applications used to run large data centers.
00:01
For example, an analytics application
00:01
might be built to recognize
00:01
suspicious network activity for
00:01
security purposes of providers
00:01
also use applications on this plane,
00:01
two-meter bandwidth usage,
00:01
tracking the ingress and egress traffic for
00:01
each customer so they can ultimately give those
00:01
customers a bill based on their bandwidth usage.
00:01
I personally went through my CCSK training
00:01
at Black Hat in Las Vegas.
00:01
After a long day of training,
00:01
I was on my way back to the hotel and I took a Rideshare.
00:01
I think it was Uber at the time,
00:01
but it might as well could have been Lyft too.
00:01
But the point isn't the particular Rideshare service,
00:01
but it was more looking at how things
00:01
transpired that really
00:01
solidified the software-defined networks,
00:01
planes, and the roles and
00:01
responsibilities of those three planes.
00:01
Like everybody who's used a Rideshare,
00:01
I opened up the app,
00:01
and then I said, I need a ride.
00:01
This told Uber at the time that they needed to identify
00:01
the driver and taking into account
00:01
their knowledge of where the drivers were,
00:01
will sent them a notice, somebody accepted it.
00:01
Then they provided that driver with a route,
00:01
to come and pick me up, the turn-by-turn directions.
00:01
Then finally, the driver themselves followed the route.
00:01
What you can see by this
00:01
is we have the application plane.
00:01
This was identifying the driver,
00:01
having a holistic overview
00:01
of everything that's going on,
00:01
and identifying a point for
00:01
optimization but then there were the brains.
00:01
How do you get from point A to B?
00:01
That was defining the route.
00:01
That's what the control plane does in
00:01
the software-defined networking and
00:01
then finally we had driving the route.
00:01
This is the hardware plane,
00:01
where it's actually moving
00:01
the DataFrames from point A to point B.
00:01
It's also worth noting that,
00:01
well, as an SDN user,
00:01
it may look much like a regular network,
00:01
they function very differently, as you can see.
00:01
In fact, the network packets when they're
00:01
leaving the virtual machines,
00:01
they actually get encapsulated
00:01
so each packet gets capsulated,
00:01
or wrapped with special header information
00:01
and so as it travels through the SDN,
00:01
the real payload itself isn't
00:01
examined whether that header information
00:01
is examined by the hardware.
00:01
It moves the packets and
00:01
frames to the correct destination.
00:01
Once the packet makes its way through the SDN,
00:01
that extra wrapping that was added gets taken off and
00:01
the unwrapped packet is presented to
00:01
the destination device or virtual machine.
00:01
From the two endpoints perspective,
00:01
the packet looks as if it was
00:01
just on a traditional network.
00:01
This is why it doesn't require new drivers,
00:01
or new special operating systems because of
00:01
the plains and because of
00:01
the layers and because of the encapsulation,
00:01
the fact that it's running on
00:01
a software-defined network is completely abstracted from
00:01
the virtual machines and
00:01
other virtual devices that are
00:01
running on that virtualized network.
00:01
What did we talk about in this video?
00:01
We looked at common approaches
00:01
to Cloud network virtualization.
00:01
VLANs and software-defined networks,
00:01
which in a Cloud world is definitely a preferred route.
00:01
We explored software-defined networks
00:01
a little bit deeper,
00:01
looking at the application plane,
00:01
the control plane, which is the brains of everything,
00:01
and the data plane which is
00:01
responsible for moving the frames around.
Up Next