So now with our scenario, we know that we have a VXLan tunnel extended between
our edge
nodes.
Thanks to the power of Lisp, we have been able to extract the information that
we need,
so we know where to send it, we know to send it over to this other fabric edge
node,
this is good from a control plane, as well as from a data plane perspective.
But what about the security policy that we've made so much out of?
We have said from the start that security must be built into this system from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have said from the start that security must be built into this system from
the ground
up.
To the point that we actually have said that this entire domain is going to be
managed
by Catalyst Center, as the controller that is responsible for this software
defined network.
Software defined network is managed by a controller, which means that I as the
admin, I get to
log in now to a single point of management and push my policy out through the
controller.
Except that's not just this one controller, we actually have another controller WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Except that's not just this one controller, we actually have another controller
involved,
which is the identity services engine or ICE.
And this is how I can set a security policy.
Now despite the fact that ICE is involved, I as the admin will continue to log
into Catalyst
Center, ICE is simply a part of the overall solution, but we're not asking Cat
alyst Center
to manage the security.
Instead, whatever security policies I set here via the graphical user interface WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, whatever security policies I set here via the graphical user interface
or the
rest API, either way, there's going to be an exchange of information between
Catalyst
Center and ICE, which will ensure that my policy gets deployed out into the
rest of the
network.
And so now when we look at our scenario, we've said that this host A is sending
a packet destined
for B. And the idea here is that we'll receive it over on this edge device.
Call this the egress edge now, meaning that it's where the packet exits out of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Call this the egress edge now, meaning that it's where the packet exits out of
the fabric
and into the rest of the forwarding domain.
So we have our egress edge and we have our ingress edge over here.
And so we made the assumption that we are going to descend that packet down to
B once we get
it on the other side and technically be a layer to frame at that point.
But the question we have to ask is, is this allowed by our security policy? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the question we have to ask is, is this allowed by our security policy?
Because we have set a security policy through Catalyst Center and with help
from ICE, we are
trying to deploy that policy out into the rest of the network.
And so maybe we have said that A and B should not be allowed to communicate
whatsoever.
At this point, we need to respect the security policy and drop this frame.
So how are we going to do this?
Well, we are going to leverage Cisco TrustSec. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, we are going to leverage Cisco TrustSec.
Cisco TrustSec, which can be abbreviated as CTS, is going to be part of not the
control
plane or the data plane, but as we have said, it is part of what Cisco calls
the policy
plane.
It allows me to push policy, especially security policy and access control
policy, out into
my network, so that I can define things like whether host A should be able to
talk to host
B.
And as we have said, we are going to rely on the identity services engine in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as we have said, we are going to rely on the identity services engine in
order to
do this, but it goes beyond just ICE.
ICE is not in the traffic flow.
The packet doesn't go through ICE and ICE decides to drop the packet.
That's how this works at all.
We need the egress edge, or I suppose the ingress edge, we need something in
the traffic path
to be able to drop the frame.
As such, ICE is going to integrate with our catalyst center and we are going to
leverage
what Cisco calls the platform exchange grid or PX grid in order to do so. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what Cisco calls the platform exchange grid or PX grid in order to do so.
We are also going to take advantage of REST APIs that exist between ICE and
catalyst center,
especially around the idea of pushing policy from the admins back and forth.
Cisco TrustSec allows us to essentially define a matrix of access control.
What this looks like is my ability to say that not only maybe host A and host B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What this looks like is my ability to say that not only maybe host A and host B
shouldn't
be able to communicate, but I could also say that VLAN 10 and VLAN 20 shouldn't
be allowed
to communicate.
I could go as far as users to talk about which users should be able to have
access to
which resources.
This is the power of Cisco ICE.
It's why it's a foundational component not only to secure Cisco's entire
security framework,
but also to SDA.
As we are trying to look at this holistically to say that it's not just a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As we are trying to look at this holistically to say that it's not just a
matter of us
having to decide between layer 2 and layer 3 campus architectures and say, well
, both
of them have some bad issues and some downsides and so we're going to come up
with a way to
forward traffic in a way that gives us only upsides.
That's great.
The SDA fabric is good for that.
We're trying to inject security not as a layer on top, try to throw a firewall
in there
somewhere, but instead say from the ground up, we're going to have security. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
somewhere, but instead say from the ground up, we're going to have security.
That is a major flaw to our existing campus architectures.
It's not just layer 2 for instance, layer 3.
It's the fact that we have a severe lack of security controls.
I can only block traffic going between two VLANs at the SVI without getting
into some
very complex architectures as we've talked about before.
SDA is trying to solve not only the problem of the control and data plane with
the layer
2 and layer 3, but also the problems of how do we manage and maintain a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
2 and layer 3, but also the problems of how do we manage and maintain a
security policy
over the course of time.
ICE and integrating with SDA is going to be Cisco's solution to that problem.
Here's how this works.
Our endpoints are going to be mapped into virtual networks or VNs as well as
scalable groups
or SGs.
Virtual networks are macro segmentation type of deployment saying that we think WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Virtual networks are macro segmentation type of deployment saying that we think
about trying
to block traffic between VLANs.
I might say that I want to deploy these endpoints into different virtual
networks at a large
scale and then deploy policy between them.
That's why we call it macro segmentation.
Scalable groups on the other hand, this is micro segmentation, meaning that I
've got
host A and host B within the same grouping, the same VLAN, and yet I can make
them deploy
them as part of two different scalable groups or SGs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
them as part of two different scalable groups or SGs.
Even within a VLAN, I can control that these two users should not be accessing
one another.
At this point, what we need to do is define our policy to say we've got this
access of
our matrix of access control and we're going to define how the communications
exist between
security groups and among the virtual networks.
But then we have to look back at the fact that I'm sending a packet to the In
gress Edge
node and then that packet's going to arrive over on the Egress node and the E WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
node and then that packet's going to arrive over on the Egress node and the E
gress node needs
to know should I drop this packet.
So we need to mark this packet in some way.
So this endpoint's traffic, the packets that it creates and sends into the
fabric are going
to be marked with scalable group tags, otherwise known as SGTs.
Now, if you've been around the industry for a while, at one point Cisco
referred to SGTs
as security group tags, but now we can do more with these tags than simple WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as security group tags, but now we can do more with these tags than simple
security policy.
That's the focus of this conversation.
And so Cisco has kind of changed the definition of the S to be scalable group
tags.
So be aware of that.
We are now saying that it stands for scalable group tags.
As a result of this architecture, I can now push security policy out to the
fabric in the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
fabric in the
form of what we call scalable group access control lists or SG ACLs.
It defines for these edge nodes whether traffic can be allowed or whether it
should be dropped.
And so these SG ACLs are going to be pushed out to the various edge nodes.
So that's an important first step is that we push the policy out.
The important second step is that we mark our packets with the SGTs.
So now I get this packet with an SGT. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now I get this packet with an SGT.
And as we mentioned before, that is helped along by VXLAN.
We insert that into the VXLAN header so that information arrives on the other
side.
So now this egress edge node has two things.
It has the SG ACL, which is the policy, and it has the SGT, which defines for
us what
traffic type this is, and I compare these two and I either allow it or I drop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
traffic type this is, and I compare these two and I either allow it or I drop
it.
Again, is this allowed by the security policy?
And now we have a way of determining this.
Now an important facet in all of this is notice this decision about whether to
allow or
drop the frame, this is happening on the egress edge node.
This is not a decision that happens on the egress side.
Now security policy typically says that in a perfect world, we would always
drop on the
egress side.
I mean, why waste resources? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, why waste resources?
Why have a security risk of sending a packet that's not allowed into the
network and drop
it later?
We should drop it right away.
Well, with this particular security policy, we don't want to necessarily do
that.
And there's a good reason for it.
The reason is as packets come in to this ingress edge node, if that ingress
edge node were
to drop this frame, think about all of the policies that it would need.
It would need to know policies for every single remote destination. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It would need to know policies for every single remote destination.
And it would have to be able to store that information and know whether to drop
the
frame as it comes in.
Whereas the egress edge can just know the policies that apply to its own local
hosts.
And so it makes it so it's much more efficient from the perspective of storing
that information
on the egress side rather than putting it on the ingress.
And yes, that does make it so the egress side is the one responsible for
dropping it.
But again, Cisco has a good reason for doing so.
So as we see, security is integrated from the beginning. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as we see, security is integrated from the beginning.
It is not an afterthought with software defined access.
And it's going to be an integral part of our ability to enforce policy with
this design.