>> : So this is abusing software defined networks, so, yeah, here we go. [Applause]. >> : Thank
you. I'll try to get this right. It's very loud this year. You used to have to pretty much hold
your face right in the mic. Okay. Thank you first of all for coming out to the talk today. As
he said, this is abusing software defined networks. My name is Gregory Pickett with
Hellfire Security. You don't have to applaud. A brief overview of today's talk--what
is it? What is software defined networking? And some weaknesses in software defined networking
and how to exploit them. Okay. And no matter how much fun it is in breaking things, we are here
also to help. So also I'll tell you how to fix it. [Applause]. >> : Moving forward obviously we
need to protect, protect it now as well as for the future. It is going to be a bit part of what
we do with the network. And then wrapping up, I will be introducing a toolkit today to
explore SDN, these particular controllers, as well as in your own environment. So I will show
you where to find that, as well as provide some links to learn more about software defined
networking. We will start with -- well, networks as they stand today. They are very vendor
dependent. You learn a unique set of skills. You learn the commands for a particular piece
of hardware that a vendor sells. There are unique features to those pieces of equipment we
buy--the switches, the routers, that we all become dependent upon. Now these networks are
difficult to scale. We're adding one box after the other. Right? Each with its own configuration;
therefore, the network becomes rather complex rather fast and prone to break. The
configuration is distributed and is often an inconsistency each box has its own unique view of
that network. We make mistakes, all sorts of things happen, and they use protocols that, well,
we're not responsible for these protocols. They were developed, turned into a standard, and we
have to use them as they are regardless of how well they work for us. And the network is also
unable to consider other factors. Like application needs, business needs. Can't see
anything outside the bits and bytes of the flows. Right? And good luck. Once you have all
this set up, it's rather brittle. Good luck if you actually want to actually try to
change it. Enter software defined networking. The idea is to separate the control and the
data point. Before any decisions are made by the controller, you take the logic off of those
switches and routers. You put it into a central controller, and then the switches and routers
just forward packets. Add the controller with the logic. It's programmed with the
intelligence. It has full visibility of the network and can consider the totality of the
network before making any decisions to enforce a very granular and consistent policy
across that entire network. This leaves the switches as bare metal only. Any vendor,
hardware, software, it really doesn't matter. They are truly a commodity. It solves lots of
problems with commodity switches. Right? The harbor, then, is very inexpensive, less
expensive, right? So it reduces the cost of operating a network. It solves a lot of problems that
we have with VGP and aspects of VGP that are lacking. Right? A lot of neat things you can do.
You could do a maintenance tryout. You don't have to take a router out of service, wait for
the registry to calculate and propagate. You can just steer the traffic around that router
ahead of time before you do your maintenance. You can give your customers the opportunity to
choose where on the network their packets egress. You get better security at the right
level, the VGP, because you can consider other factors such as reputation before selecting.
Faster Convergence. You don't have to wait for events to occur, nodes to detect it,
propagation of routes. You can just go ahead and tell everyone, this is now your next hop. And
it also allows for granular hearing at the internet exchange points. You don't have to -- we
don't have to be in a situation of all or nothing. You can decide what sorts of protocols
you're going to peer over, what protocols you're going to use to communicate with your neighbors.
Okay? And it expands our capability. We can do real world network slicing of the flow
space. You can take that VLAN idea and expand that network wide. We also are able to
expand--can expand from server load balancing to network load balancing, gaining a significant
amount of efficiency in the network. And security--there's so many things you can do with
security under SDM. Access control. You can apply your access control that includes a
lot more than just this host can talk to this host over these protocols over these ports. You
can then begin to say, okay, times a day. You can add a lot more dimension to it. Adapter
traffic monitoring. You no longer have to have fixed points on the network that you are
looking at. You can move your traffic monitoring around as the needs -- as needs change. And it
also allows you to program the network with a bit of intelligence so that the network
can begin detecting attacks and engaging in mitigation automatically. So a lot of
really neat things you can do with SDN. Now there are some emerging standards that they
have come up with. Well, not really come up with. When they realize after a certain point
that the network gets a little unwieldy, a little out of control, and we've kind of known
this for a while, they attempted to adapt existing protocols to kind of gain the breadth of
control as well as the consistency that SDN provides before I think even SDN was an
idea. So they had SNMP, extensions of DGP, Netcom list. But there was always something
lacking. So they went ahead and designed the protocol from the ground up and opened flow with a
sister protocol VSDB to implement SDN from the ground up considering all the different
factors that might be involved in it to start over. And that's what we'll be talking about
today. Open flow. It established the elements. It establishes that paradigm with the
controller making all the decisions, a secure channel for the controller to talk to the
different forwarding elements over and defines a forwarding process at those forwarding
elements and messaging format to be able to communicate information back from the
forwarding elements to the controllers. The forwarding process. The forwarding element
will check the flow table. If a match is found, it will carry out the action. This is very
much like a firewall. If no match is found, then it sends the package to the controller.
The controller makes his decision, referencing policy and then updates the flow table on
that forwarding element. The forwarding element has a flow table. It's basically a set of
match action entries. There are 12 fields available for matching, and there's wild card
matching available too. So you can pretty much kill more than one bird with a single stone.
You don't have to have a single entry for each type of packet that you might end up running
across. Graphical representation of that relationship. Controller communicating with the, in this
case, an open flow switch with its flow table over the secure channel using the open flow
protocol. So this is the paradigm we will be looking at today. What these people have
tried to make happen in their products. All right. So we have some proprietary controllers.
There are lots of controllers out there, but these are some of the leading platforms. Cisco has
some, HP, IBM and of course Open Source, Nocs, Pocs, RIU, and the ones we will look at
today--Floodlight and Open Daylight, specifically because, well, they're production
capable. They are promoted as something you want to put in your network to run your
operations. So we need to know what we're in for. Okay? Floodlight is an open source
Java controller. It's primarily an open flow base controller supporting version 1.0. It's a
fork from the beacon Java open flow controller maintained by big switch networks. So one
outfit is behind this. Open Daylight is an open source Java controller with many southbound
actions, including open flow. And there's a lot of backward compatibility there with the
other protocols supporting 1.0 and 1.3, and it's also a fork from the beacon Java open flow
controller, Linux Foundation collaborative project though by a lot of companies with their
hands in it--Citrix, Red Had, Ericsson, Hewlett-Packard, the rest there, a lot of industry
heavyweights. So we have some problems. Open flow. We've had this idea for SDN open flow is
going to do it for us. It's going to solve those problems, and it's going to be nothing but
puppy dogs and rainbows. Right? That's what they always tell us when they're trying to sell it
to you. Not exactly. That's why we're here. So there are some protocol weaknesses. And we'll
start with the protocol, less serious to the more serious things. Encryption and
authentication is specified. It's implemented using TLS, but it's more of a suggestion than a
requirement. It started out very good. 1.0 was saying, okay, yes, TLS. Got to do TLS. 1.4 said,
no, we don't have to do TLS. You don't have to do TLS. You can do TCP if you want. And as you know
when give someone the opportunity to be less secure, to slack, if you will, they will
do so. And we'll see some slackers here. So Floodlight said, ah, we're not going to do
it then. You don't require it? We're not going to do it. So no support. Open Daylight is a tad
better than Floodlight. It separates it, but it's not required. And the switches.
Switch vendors are kind of a mixed bag. But you're really in the same boat. Arista, no. Dell,
no. Stream, yes. There's a couple yeses in here but a lot are no. So along with some more
noes here. So you really have a situation where even if you want to do TLS based on the makeup of
your controller and your switches, you may not be able to. So a large portion of people
wanting to even try to do this won't be able to do. And what we've found with these
imitations is that it kind of left a few things out. Encryption, yes, of course. It's
TLS. But going through all the configuration options, you really don't see anything in
there for certificates. Without certificates, you can't have authentication. That means
pretty much anyone and their dog to use an overused phrase can talk to this and manipulate it
and attack it, kind of like what I've done. So, you know, it's a mixed bag here. So a large
portion of people don't even have an option because you don't have a matching of controllers
and switches. And even if you do get it, you know, really you're kind of half covered here.
You're really still exposed there. Now what this can lead to. For a mass majority or a
vast majority of people using these products and using the protocol, information disclosure
through interception and modifications through man in the middle. That's a large portion
of the people trying to do open flow, trying to do SDN, because they don't have the right match
of equipment. Now everyone though is going to have an issue with the service because even if
you are one of the lucky ones that happens to have a controller using TLS and a
switch that uses TLS, you can't change. Once you have your switches in place, it's not easy
to change over. You're stuck with it. But let's say you are lucky and have a switch that
supports it, and you have a controller that supports it. It really doesn't matter. No
authentication, so pretty much everyone across the board is going to have issues with denial
of service. So speaking of denial of service nastiness, open flow. It's about
centralization. Centralization, well it's dependency. Dependency can be exploited. So we have to
look at how the vendors are handling it. Well, Selman looked at it, looked up Floodlight. And
it's an experiment. They set up a Floodlight controller. They brought up some instances of
CBench, and what they found was that Floodlight handles it poorly. It even -- well, there's
actually some options and when you compile it to put in some rate limiting and they found
when you turn on the rate limiting, it was actually worse. Okay? Now their presentation on
this is on the slide share. I recommend you look at it to see what they came up with, how much
-- how many instances of CBench it took to actually take this thing down. It wasn't hard at
all. So now there's also Open Daylight. It is unknown. I didn't take a stab at this, but
it's worth investigating because it is Java for God's sake. Memory issues. Right? Now you
too can recreate Salma Natal's work or play with your own controller, poke at it. All
right. Start off looking at SDN in particular, Open Flow, and I built kind of an emulator here
or a switch. This is the beginning of the toolkit. It impersonates an open flow switch
utilizing 1.0. It exchanges the hellos. It will receive a feature request. It will return
the features. It will receive a set configuration. It will respond to that. It will receive
a get configuration. It does the whole thing. Send a bogus configuration back and then do
echo or request echo or apply over open flow with that controller. So you can observe
that yourself and see how these things interrelate. Well, Flood takes that a little bit further.
It establishes that relationship and then just pounds on it. Pound, pound, pound. There are
12 fields available for matching. You just do the math, the number of possible
combinations. One instance of flood hitting that controller with all those millions of
packets. You throw up a couple more, and let's see how many it takes to knock over the
controller of your choice. Okay? So a little fun you can have there. Now it's important to
note -- so we have the TLS issue. Right? TLS issue not really implementing it really
well. Those who are as part of the standard. As they move along and get to that and they begin
to completely get through the standard and become more compliant, D bug force will be a
problem. There's no encryption, no authentication, just full control of the switches. This is
a switch side issue. You can use it very easily with an obtainable tool--DPCTL. As I
said, they are still working out getting TLS in there. So it's not a problem yet, but once they
get past that and get more compliant to get to the D bug port and start looking for those
in your environment, are the D bug ports showing up on our switches? So it's not a problem
yet but soon will be. Now this is where we get to the fun stuff. Controller weaknesses. It
gets bad here. Floodlight. No encryption, no authentication on the northbound API. You can just
connect to it, take control of it, and have your way with it. Not a problem. It's a very easy
controller. Open Daylight. There is encryption for the northbound API, but they were kind enough
to have it turned off by default. Thank you very much. Well, I work a lot in defensive
security, so for me it's a blessing. I like those things. And there is some authentication
for that northbound API, but it's HTTP basic authentication. Not much of a challenge. Default
with passing and strong passwords turned off. Another thank you. Now, you may say to
yourself, with Open Daylight we have a little coverage. Not really. There are weak
protections there, but we can actually get around those. I have an exploit for you today.
It's brand new. I have a zero day that's going to allow you to bypass all that. So while
they're there, they won't be a problem for you. Now what this means is both controllers,
either directly with Floodlight or indirectly with Open Daylight we're using an exploit. They're
going to have problems with information disclosure through interception, topology,
credentials. If they don't turn on the encryption on the Open Daylight, you can get the
credentials. Information disclosure through unauthorized access, topology and targets
directly with Floodlight and indirectly with Open Daylight using the exploit and then turn
around and do the same thing, and there's problems here with topology flow and message
modification through unauthorized access. While you're there, you might as well
add access, remove access, hide traffic, put blind spots in those sensors, and you can
change traffic. Flow rules are rather flexible. You can change things to add the VLANs, taking
[indiscernible] away. So directly with Floodlight or indirectly with Open Daylight,
still both of these have these problems. Now, first off you have to identify controllers and
switches. You can't have fun with them if you don't know where they're at. Now, they're
currently listening on TCP port 6633, but there's now an official port of 6653. All the
tools allow you to change the port, so if you run across a next gen or version 2 of any of
these things and they change the port or they're trying to be secret and they hide the port by
moving it to something else, you can go ahead and adapt, add a port as a commandlet and still
use the tools. Now to identify these guys, you try to exchange hellos with the service to see
if you're working with an open flow based service, and if you get a feature request back, then
you know you're dealing with a controller. So as we do here with the next tools. These two
are about discovery. So you're going to give them lists of targets, and they're going to
narrow things down for you. You start with your bigger list to OFcheck. It identifies open flow
services and reports on diversions. Say you have 100. You give two or more. They're
going to class C. So you give that big list to -- I don't recommend necessary internet,
but they're out there. I'll just say that. All right. So you have a list of let's say 100, and you
go ahead and you go through that with OFcheck. You'll take that smaller list, and you're going
to hand it off to enum, and then you'll enumerate the end points there. It will tell you whether
or not you're working with a controller or a switch because, of course, you want the
controllers because they're the fun ones. Okay? All right. Now for those who don't play around
with Python too much there is also in Metscript to add that capability, same functionality
as OFenum. [Indiscernible] End points. [Indiscernible]. Whether it's a controller or a switch.
So let's go ahead and identify some right now. Is that big enough? Okay. So we have a
target list, open flow service version 1 found at 192.168.2.67. I kind of knew it was there. So
we have that there, and then you would go ahead and take that smaller list and pass it off
to--. Bigger. I think the next size is way too big. So we have open flow controller found at
192.168.2.67, so very easy to identify these guys. So once you've identified
it-[indiscernible]. So once you've identified it, you can go about some naughtiness. We have
a small local area network there. I've instantiated in main net. It's a great
experimentation tool. One admin host, two user hosts, one server, and a censor, which I
will call an IDS. So there's hacker me. That's the fun stuff, so I'm going to do it here.
Identify targets, enumerate ACLs, and, of course, look around to see if anyone is
listening/looking at what may be going on. We'll do that with OFmap. It downloads slow from an
open flow controller and then uses those slows to identify targets and target services,
identify ACLs, and to identify censors. It works with Floodlight and Open Daylight and
JSON. It auto detects the controller you're working with. Now, I did mention that the work
credentials are Open Daylight. The exploit actually allows you to get the credentials for Open
Daylight. It will start off with an Open Daylight controller. It will use the default for you.
That's very nice of it. If you must go get the credentials with the exploit, you can then plug
them in. OFMap and the next one OFaccess will allow you to add credentials. Should they change
it, you have to go get it and put them in there and then go ahead and hit D Open Daylight
control anywhere. And we'll demonstrate. Here we go. I have to learn how to spell. And we
know that Controller and then 2168, 2067. There we go. So the first thing we want to do is map
that network. It's going to report on that. There. Map the network and then, of course, the
connection. It would normally tell you the switch you're attached to. That's a bonus
actually, because you want to know if you're going to make some modifications, you kind of
want to know where you're at. For some reason, these networks here, I'm not seeing them. I
have to figure out why. Next thing you might want to do is look at the flows. But in the
production network, I don't necessarily recommend you do that, at least not live on the
screen. You can if you want. Number 2 lists all the flows. The option in the production
network is to do number 7, which is dump the flows to a file. We can go ahead and take a look
real quick. I don't know if it will fit here. All right. So we'll go ahead and jump to the
good stuff here, which is missed targets. 225, 215, 227, 228. This happens to be me 215.
Server 225, admin 228. Next thing I want to look at here is the ACLs. I want to know what
I'm being kept out of because that's actually exactly where I want to go. Found one. It's just
very big. Okay. So 215 is me. I'm being kept out of 225. As I said, that's where I'm not
allowed to go. That's the first place I want to go. So here we go. Isn't that where all the fun
stuff is at, right? Behind locked doors? So we have the salesmen. I want to check to see
if there are any censors. This does it by dissecting or looking through the flow tables to see
if there is any mirroring. So number 6 identify censors. All right. So there's some mirroring
going on to port 5. And I'm going select this because I need this later on. So very easy to
dump the flows, identify targets, and then find anything that might be looking at you,
watching what's going on. All right. Well we're not going to stop there, right? You always
start off an attack with reconnaissance, but the next thing is our vulnerable
identification, exploitation, that sort of thing. So as an attacker, I'm going to open the
way for myself and take that same network. I'm going to grant myself access to that server,
and them I'm going to isolate the administrator. Turnabout is fair play. Right? I don't want
him interfering, and then I'm going to put a blind spot in that censor, and I'm going to
remove that mirroring for myself and my target. And that leaves me free to then attack the
server. The tool we'll be using is OFaccess, or I'll be using. Modifies flows on the network
through the open flow controller, adds and removes access for the host, applies
transformation. You can actually write your own flow roll and put it in right from the tool. It
also removes mirroring for any particular IP of interest, yourself-I'm going to do that,
of course, and the target. It works for Floodlight and Open Daylight as well via JSON, audit
the text, everything, put credentials in if you need to by the Open Daylight controller and
demonstration. So we're going over here and run this, OFaccess. Now the first thing I
want to go after is that server, but then I have to grant myself access. So let's show how I can
talk to the server now. Nothing up my sleeves. So I currently can't talk to that server.
Request timed out. Now I'm going to go ahead and through the magic of SDN and, in this case,
Floodlight-it's easiest to go after--I will grant myself access. And that is why I need
that switch. I need to know what switch to put the flow roll on, and priority. Priority is a
little tricky. Right now, the tools only overwrite entries, so it's important to have a high
priority. With Floodlight, overwriting requires the highest priority, so I'm going to accept
the default here. Next version, yes, I know, it's always that way. Next version I will be
adding a feature to remove flow rules. Hooks up that and then confirm. It's very polite. And
then ping that server. OK? There we go. [Applause]. >> : We're not finished yet. We have to go
after that administrator. All right. So we have H4 as an administrator and H1 as the
server. Internally contain the server. We'll let that go. And then I'm going to take that
away. I'll drop traffic, 192.168.2.228 is the administrator. And 225 is the
server, same switch, same priority, yes and now, denied. There we go. [Applause]. >> :
We'll break that off there. We're seeing lots of drops there. 42% [indiscernible]. But
there's still some mirroring going on there. I want to take care of that. So I'm going to
move that up there. Let's go ahead and hide from sensor. I'm going to go ahead and hide
anything heading toward me. Don't mirror that. And that same switch. And we know it's on port
5. Not quite yet. I want to show you something here. I'm going to do TCP dump. We'll see how it
does currently see me. No tricks here. Some pings. So we're seeing both sides of that
conversation currently being mirrored to the sensor. Now let's put the blind spot in. And
I need to go over. So anything heading toward me will not be mirrored, and then let's do the
other side of the server. I actually did the wrong one here. All right. There we go. So
that's 225. Yes, yes. On that same switch. Stopping mirroring to port 5 or anything heading
toward that server. You have to excuse my Windows 8. Get out of here. >> : [Off mic] >> : And
back to this way. Right here. This was a last-minute replacement. I haven't yanked
all that stuff off. So that was hidden. Now, let's go ahead and start this up again. There we
go. Pinging of course, going through, and let's go zero packets captured. [Applause]. >>
: Thank you. Nice little blind spot, which is what I like. So now you can do whatever you
want. Have your way with that server if you will. And now, not only will nothing see you, but
no one can stop you. OK. So we talked about Open Daylight, a little indirect. Right? So
there's a small problem with Open Daylight. A little bit of a problem. So I found that, and
we're going to go ahead and exploit that weakness, exploit Open Daylight. So sorry, no
puppy dogs and rainbows for you. All right. So this is awfully detailed, probably more detailed
than it should be. So Open Daylight, very backwards compatible, and there's other
southbound APIs besides Open Flow. No encryption. No authentication on this. It's a
TCP version of Netcom. Just connect and exchange messages. Can you see where I'm going with
this here? What's hot today? XXE, external entity injection. A little Java. If you're
familiar with XXE, Java has a big problem. You've got all sorts of space out there
dedicated to that. OS pretty much paints a door right on this and just go in. Java has big
problems with XXE. So boom goes Open Daylight. And this is a bonus here. Yes, that's what I
said. Demonstration. So, let's go ahead and exit out of here. Let's just do this. I tweaked
out a little bit, added features. Got one at 60. All right. There you go. Now, it
starts out with default of a password file, but I'm greedy. So I'm going to go after the
shadow file. You got the access, you might as well use it. It's very friendly. Says hello.
Everything is okay. Here we go. We're feeling all right. That's the latest one. So there we go.
[Applause]. >> : Thank you. And that's the good stuff. Right? So then you can mount an offline
password attack, gain a sense of credentials. You're going to get a lot more in that box than
northbound API credentials, but after you're done with that box, you might as well go after
everything else. So you get those credentials and you plug them into the tool, and then
I'll show you in just a second here. All right. It's important to note before I go through the
whole thing, the whole cycle again with Open Daylight or show you what you can do there, if
the service is not available, all right, say you don't have the opportunity to use the
exploit because the service is not available or, low and behold, they fix it, not to
worry. You can password guess it. Okay? Default pass or tweak. Strong passwords turned off by
default. No account lockout. And no sys lock output. So you can just pound on it and pound on it
and pound on it, and it gets credentials that way. So either way, you just repeat. All right.
Go through the whole cycle again and then own that network too. So Open Daylight. Put those
extra protections in place, and it didn't turn out to be much. Other exploits are waiting to be
found. This is where you guys come in. The only way to get these people to secure this
stuff is just keep poking at it. Northbound APIs, Floodlight, southbound APIs for Floodlight
as well. Open Daylight has northbound APIs. Open flow has southbound APIs. The Netcoms,
there's also an SSH1 D bug port for Netcomp. And this is the other servers also running the
box. Okay? Lots of these are XML based being run by Java. I see some duplication here. Some
duplication. So we'll go out there, poke at this sucker. You're going to find stuff. You
are. Available solutions. Yes, this is the less exciting part. For now and for the future, of
course. For right now, transport security. We're talking about it, but it's not really
finished. They're not really done with it. For those not supporting it, put it in. And
when you put it in, add authentication, please. Do certificates. Those who
currently have it, throw that extra piece on. We need to close the loop on this. I'm not sure
how good TLS is in this situation unless you're using certificates. Now as we move to
commodity switches, it then also becomes realistic. There are some cycles for TLS. That's
probably a lot of the reason why vendors aren't implementing it. It takes extra cycles to do TLS.
Going to commodity switches, you have the cycles. So it's very feasible and very realistic to
make it happen. Hardening, of course. These are some of the basic things we should be doing
anyway. And then, of course, VLAN, too many flat networks out there. I'm a network guy. All
right? But even I know you need to do a code review. Right? As I said, OS pretty much paints the
door on the outside of this box and says, here, this is how you get in. I can't imagine that did
a code review. Please go back and do a code review. Those vendors out there, if you
haven't done a code review, we haven't looked at it yet. Do one before we get there. Please. Now
for the future. This is a little more the details of that scan to protect against denial of
service. You have to consider your architecture, partition that network. Don't put one
controller or a group of controllers in charge of the whole network. Not a great idea,
especially as the network gets larger, performance also comes into consideration because not
just denial of service but also in the performance of the daily operations of network. And then
controller clustering. Spread the burden out a bit. Share the load. And then when you can, put
in site flow entries. A lot of this is going to occur because you've got reactive mode where
the switch is going to go ahead for every single packet it sees, it's going to send up. It
doesn't have anything to go with at the beginning. It's going to send every single packet. That's
a lot of combinations-there are millions--up to the controller. If you have some flip site floor
entries that you can use, use them so it doesn't necessarily have to depend on the controller
as much. It doesn't need to depend on it as much as possible, so minimize that. And
then, of course, to protect against modification. This is about DSDN applications. Traffic
counters are available. You don't have to infer the network. You can actually measure that
out. You can see it as it's currently operating. The application space within the
controller is really supposed to be about putting in these code sets, modules to put on these
boxes that are supposed to do a lot of that work. The APIs are kind of secondary to external
integration. So as you go on here, you can throw on secondary applications that are all about
security. Right? Reading in the traffic counters, measuring them, looking for
[indiscernible], and then responding. So have those applications in there to kind of
check what's going on. Now, that's kind of after things are in operation. You can do things
on the front side too with verification with header space analysis where you turn the
switches and the routers into a mathematical model, and then you basically punch all your packets
through that, and you can actually see how the network is going to operate beforehand. So
the verification is the front side where we can verify how a policy will function, and then
you have something on the back side with the secondary applications to monitor things
and respond. So can get coverage there and protect against people like me poking around. Now how
prevalent is this going to be? We see issues. We see these weaknesses, weaknesses that are
easily exploitable. But if they're just a couple people, you know, well we have a couple
people that may have it, but what about the rest of us? Well, Garter says, the academics say
this is going to be one of the 10 critical IT trends for the next five years. So they are
looking into their crystal ball and seeing this having a really big impact on the enterprises
out there. Major networking vendors have products planned for SDN, and they're betting
money on this, and people are already moving on it. 60 percent felt that SDN would be part of
their network within five years. 43 percent already have plans to put it in production. It's
actually here now. Data centers and cloud space, investments, VMware. This is considered the
killer [indiscernible]. And the expectation is actually higher, 80 percent. And of course we're
seeing it in the LAN with Caltech and [indiscernible] and [indiscernible] as well, already
here. Google has it on one of their major backbones, and NTT and AT&T, everyone is rushing
forward into this. So this is something that we're all going to have to keep an eye on. This
is something we're all going to have to worry about it. It's not just isolated to these
controllers and these unique situations. It's all of us. We're going to have to address
this. Now so mainly we move forward on this. We are going to move forward on this. How could
it go right? What are the things we expect to see out of this besides the problems that it
solves? Vendor independence, ultimately our costs. A lot of the limitations are currently
experienced in network space will go away. Network is the mask to the application and the
business needs and not the other way around. We don't have to make our network fit the
equipment. We can make the equipment fit what we want to do on our network and the faster
evolution of that network. We can actually run production scale simulations side by side,
and we do lots of experimentation. It allows us to do things like exchange network
aspects, instantiate network function virtualization, where we actually have middle boxes.
We have load bouncers. We have firewalls, and we can actually move those things around
wherever they need to be as traffic conditions change and the situation changes. And you
get dynamic and truly active defenses. You can program that network and detect
abnormalities, respond to those abnormalities, and start defending itself. A lot of
amazing things. But a lot of bad things can also happen too. Denial of service. It's like a
dog pile. All the nodes on the network gang up on one other network. You think bots are bad?
Wait until you harness an entire network and you can slam somebody else. So that's bad.
The flip side of that, selectively dropping traffic. A message disappears, an important
message. A transaction never arrives. Man in the middle. Let's say you want to be a
little more creative, a little more ninja, man in the middle an entire network. Local subnet
host. Change a transaction route. Change maybe an email a little bit, piss some people
off, start manipulating events. It gets bad. Networks within networks. You get uber admins
moving chess pieces behind the scenes. This could go bad if we're not keeping our eye on the
ball. So we need to make a difference. This is what this is about. Traditional means of
securing controllers still applies. Now, security has been part of the discussion. I said
it needs to be, but it needs to be done in a different way. Until now, it's been about
you're all very excited about how it can help security, but people aren't really looking at
how secure SDN is. And all this is being done typically by outsiders. People are doing it
and are doing it in a traditional approach, a very 2D approach, very Isolated. The
code guys, the application guys are looking at it separately from the network guys. They need
to converge there because controllers, really, they need a security reference. They need a
security reference and an audit capability. They talk about these as network operating
systems, so start treating it like one. Make sure that operations are authorized. Make
that once authorized operations occur that someone can figure out who did it, what they did,
and when. All right. Now, some final thoughts. We're wrapping up here. SDN has the potential
to turn the entire internet into a cloud. The benefit would be orders of magnitude above what
we see now, but there's a hole in the middle that could be filled by the likes of the NSA,
nation-states like China. We pick on China, but they're all doing it--United States, Russia,
the Euro block, governments are getting in the middle. We don't want them there. All right.
Let's not let that happen, and that starts here by telling you guys about this. So we start
poking holes. We start holding vendors to account, these developers. The toolkit as we
wrap up here. It's available at SDN-toolkit@sourceforge.net. I'm a little old school, the hash
there. Make sure it's genuine. Available here. And some links, let me get that mouse back. To
provide some context to today's talk, get more information, I highly recommend these, a course
taught here by Nick Finster, Professor Finster, SDN nuts and bolts from beginning to end,
learning about SDN. So that's it. Thanks for coming. [Applause].