WEBVTT

1
00:00.000 --> 00:06.120
So now with our scenario, we know that we have a VXLan tunnel extended between

2
00:06.120 --> 00:06.560
our edge

3
00:06.560 --> 00:07.760
nodes.

4
00:07.760 --> 00:12.540
Thanks to the power of Lisp, we have been able to extract the information that

5
00:12.540 --> 00:13.320
we need,

6
00:13.320 --> 00:17.660
so we know where to send it, we know to send it over to this other fabric edge

7
00:17.660 --> 00:18.400
node,

8
00:18.400 --> 00:23.480
this is good from a control plane, as well as from a data plane perspective.

9
00:23.480 --> 00:27.720
But what about the security policy that we've made so much out of?

10
00:27.720 --> 00:31.680
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

10
00:27.720 --> 00:31.680
We have said from the start that security must be built into this system from

11
00:31.680 --> 00:32.280
the ground

12
00:32.280 --> 00:33.280
up.

13
00:33.280 --> 00:37.690
To the point that we actually have said that this entire domain is going to be

14
00:37.690 --> 00:38.240
managed

15
00:38.240 --> 00:45.650
by Catalyst Center, as the controller that is responsible for this software

16
00:45.650 --> 00:47.560
defined network.

17
00:47.560 --> 00:51.810
Software defined network is managed by a controller, which means that I as the

18
00:51.810 --> 00:52.880
admin, I get to

19
00:52.880 --> 00:58.080
log in now to a single point of management and push my policy out through the

20
00:58.080 --> 00:59.440
controller.

21
00:59.440 --> 01:05.400
Except that's not just this one controller, we actually have another controller
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:59.440 --> 01:05.400
Except that's not just this one controller, we actually have another controller

22
01:05.400 --> 01:06.320
involved,

23
01:06.320 --> 01:09.800
which is the identity services engine or ICE.

24
01:09.800 --> 01:14.800
And this is how I can set a security policy.

25
01:14.800 --> 01:18.430
Now despite the fact that ICE is involved, I as the admin will continue to log

26
01:18.430 --> 01:19.240
into Catalyst

27
01:19.240 --> 01:23.930
Center, ICE is simply a part of the overall solution, but we're not asking Cat

28
01:23.930 --> 01:24.760
alyst Center

29
01:24.760 --> 01:26.440
to manage the security.

30
01:26.440 --> 01:31.330
Instead, whatever security policies I set here via the graphical user interface
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:26.440 --> 01:31.330
Instead, whatever security policies I set here via the graphical user interface

31
01:31.330 --> 01:31.640
or the

32
01:31.640 --> 01:36.000
rest API, either way, there's going to be an exchange of information between

33
01:36.000 --> 01:36.600
Catalyst

34
01:36.600 --> 01:41.110
Center and ICE, which will ensure that my policy gets deployed out into the

35
01:41.110 --> 01:41.720
rest of the

36
01:41.720 --> 01:43.200
network.

37
01:43.200 --> 01:48.450
And so now when we look at our scenario, we've said that this host A is sending

38
01:48.450 --> 01:49.960
a packet destined

39
01:49.960 --> 01:56.360
for B. And the idea here is that we'll receive it over on this edge device.

40
01:56.360 --> 02:01.570
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

40
01:56.360 --> 02:01.570
Call this the egress edge now, meaning that it's where the packet exits out of

41
02:01.570 --> 02:02.400
the fabric

42
02:02.400 --> 02:05.360
and into the rest of the forwarding domain.

43
02:05.360 --> 02:12.080
So we have our egress edge and we have our ingress edge over here.

44
02:12.080 --> 02:17.180
And so we made the assumption that we are going to descend that packet down to

45
02:17.180 --> 02:18.000
B once we get

46
02:18.000 --> 02:22.440
it on the other side and technically be a layer to frame at that point.

47
02:22.440 --> 02:30.880
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

47
02:22.440 --> 02:30.880
But the question we have to ask is, is this allowed by our security policy?

48
02:30.880 --> 02:38.160
Because we have set a security policy through Catalyst Center and with help

49
02:38.160 --> 02:39.440
from ICE, we are

50
02:39.440 --> 02:43.200
trying to deploy that policy out into the rest of the network.

51
02:43.200 --> 02:49.620
And so maybe we have said that A and B should not be allowed to communicate

52
02:49.620 --> 02:51.120
whatsoever.

53
02:51.120 --> 02:55.520
At this point, we need to respect the security policy and drop this frame.

54
02:55.520 --> 02:57.000
So how are we going to do this?

55
02:57.000 --> 03:02.000
Well, we are going to leverage Cisco TrustSec.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:57.000 --> 03:02.000
Well, we are going to leverage Cisco TrustSec.

56
03:02.000 --> 03:08.310
Cisco TrustSec, which can be abbreviated as CTS, is going to be part of not the

57
03:08.310 --> 03:08.960
control

58
03:08.960 --> 03:13.020
plane or the data plane, but as we have said, it is part of what Cisco calls

59
03:13.020 --> 03:13.720
the policy

60
03:13.720 --> 03:14.720
plane.

61
03:14.720 --> 03:19.590
It allows me to push policy, especially security policy and access control

62
03:19.590 --> 03:20.720
policy, out into

63
03:20.720 --> 03:24.600
my network, so that I can define things like whether host A should be able to

64
03:24.600 --> 03:25.440
talk to host

65
03:25.440 --> 03:26.440
B.

66
03:26.440 --> 03:30.340
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

66
03:26.440 --> 03:30.340
And as we have said, we are going to rely on the identity services engine in

67
03:30.340 --> 03:30.960
order to

68
03:30.960 --> 03:34.120
do this, but it goes beyond just ICE.

69
03:34.120 --> 03:35.960
ICE is not in the traffic flow.

70
03:35.960 --> 03:40.200
The packet doesn't go through ICE and ICE decides to drop the packet.

71
03:40.200 --> 03:42.120
That's how this works at all.

72
03:42.120 --> 03:46.750
We need the egress edge, or I suppose the ingress edge, we need something in

73
03:46.750 --> 03:48.360
the traffic path

74
03:48.360 --> 03:51.600
to be able to drop the frame.

75
03:51.600 --> 03:56.630
As such, ICE is going to integrate with our catalyst center and we are going to

76
03:56.630 --> 03:57.400
leverage

77
03:57.400 --> 04:04.400
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

77
03:57.400 --> 04:04.400
what Cisco calls the platform exchange grid or PX grid in order to do so.

78
04:04.400 --> 04:08.990
We are also going to take advantage of REST APIs that exist between ICE and

79
04:08.990 --> 04:10.480
catalyst center,

80
04:10.480 --> 04:17.120
especially around the idea of pushing policy from the admins back and forth.

81
04:17.120 --> 04:25.880
Cisco TrustSec allows us to essentially define a matrix of access control.

82
04:25.880 --> 04:31.760
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

82
04:25.880 --> 04:31.760
What this looks like is my ability to say that not only maybe host A and host B

83
04:31.760 --> 04:32.720
shouldn't

84
04:32.720 --> 04:37.590
be able to communicate, but I could also say that VLAN 10 and VLAN 20 shouldn't

85
04:37.590 --> 04:38.320
be allowed

86
04:38.320 --> 04:39.560
to communicate.

87
04:39.560 --> 04:44.000
I could go as far as users to talk about which users should be able to have

88
04:44.000 --> 04:44.720
access to

89
04:44.720 --> 04:46.480
which resources.

90
04:46.480 --> 04:48.680
This is the power of Cisco ICE.

91
04:48.680 --> 04:53.970
It's why it's a foundational component not only to secure Cisco's entire

92
04:53.970 --> 04:55.760
security framework,

93
04:55.760 --> 04:57.840
but also to SDA.

94
04:57.840 --> 05:02.810
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

94
04:57.840 --> 05:02.810
As we are trying to look at this holistically to say that it's not just a

95
05:02.810 --> 05:03.760
matter of us

96
05:03.760 --> 05:09.080
having to decide between layer 2 and layer 3 campus architectures and say, well

97
05:09.080 --> 05:09.400
, both

98
05:09.400 --> 05:14.840
of them have some bad issues and some downsides and so we're going to come up

99
05:14.840 --> 05:16.360
with a way to

100
05:16.360 --> 05:19.200
forward traffic in a way that gives us only upsides.

101
05:19.200 --> 05:20.200
That's great.

102
05:20.200 --> 05:22.520
The SDA fabric is good for that.

103
05:22.520 --> 05:27.420
We're trying to inject security not as a layer on top, try to throw a firewall

104
05:27.420 --> 05:27.760
in there

105
05:27.760 --> 05:32.720
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

105
05:27.760 --> 05:32.720
somewhere, but instead say from the ground up, we're going to have security.

106
05:32.720 --> 05:36.600
That is a major flaw to our existing campus architectures.

107
05:36.600 --> 05:38.880
It's not just layer 2 for instance, layer 3.

108
05:38.880 --> 05:43.160
It's the fact that we have a severe lack of security controls.

109
05:43.160 --> 05:48.350
I can only block traffic going between two VLANs at the SVI without getting

110
05:48.350 --> 05:49.000
into some

111
05:49.000 --> 05:53.320
very complex architectures as we've talked about before.

112
05:53.320 --> 05:57.870
SDA is trying to solve not only the problem of the control and data plane with

113
05:57.870 --> 05:58.360
the layer

114
05:58.360 --> 06:03.270
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

114
05:58.360 --> 06:03.270
2 and layer 3, but also the problems of how do we manage and maintain a

115
06:03.270 --> 06:04.840
security policy

116
06:04.840 --> 06:06.880
over the course of time.

117
06:06.880 --> 06:13.920
ICE and integrating with SDA is going to be Cisco's solution to that problem.

118
06:13.920 --> 06:15.320
Here's how this works.

119
06:15.320 --> 06:21.930
Our endpoints are going to be mapped into virtual networks or VNs as well as

120
06:21.930 --> 06:23.360
scalable groups

121
06:23.360 --> 06:25.320
or SGs.

122
06:25.320 --> 06:31.260
Virtual networks are macro segmentation type of deployment saying that we think
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

122
06:25.320 --> 06:31.260
Virtual networks are macro segmentation type of deployment saying that we think

123
06:31.260 --> 06:32.000
about trying

124
06:32.000 --> 06:34.240
to block traffic between VLANs.

125
06:34.240 --> 06:38.540
I might say that I want to deploy these endpoints into different virtual

126
06:38.540 --> 06:39.640
networks at a large

127
06:39.640 --> 06:42.800
scale and then deploy policy between them.

128
06:42.800 --> 06:46.440
That's why we call it macro segmentation.

129
06:46.440 --> 06:50.780
Scalable groups on the other hand, this is micro segmentation, meaning that I

130
06:50.780 --> 06:51.240
've got

131
06:51.240 --> 06:57.630
host A and host B within the same grouping, the same VLAN, and yet I can make

132
06:57.630 --> 06:58.760
them deploy

133
06:58.760 --> 07:02.440
them as part of two different scalable groups or SGs.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
06:58.760 --> 07:02.440
them as part of two different scalable groups or SGs.

134
07:02.440 --> 07:06.410
Even within a VLAN, I can control that these two users should not be accessing

135
07:06.410 --> 07:08.080
one another.

136
07:08.080 --> 07:12.350
At this point, what we need to do is define our policy to say we've got this

137
07:12.350 --> 07:13.440
access of

138
07:13.440 --> 07:18.370
our matrix of access control and we're going to define how the communications

139
07:18.370 --> 07:19.240
exist between

140
07:19.240 --> 07:22.640
security groups and among the virtual networks.

141
07:22.640 --> 07:26.670
But then we have to look back at the fact that I'm sending a packet to the In

142
07:26.670 --> 07:27.400
gress Edge

143
07:27.400 --> 07:31.890
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

143
07:27.400 --> 07:31.890
node and then that packet's going to arrive over on the Egress node and the E

144
07:31.890 --> 07:32.880
gress node needs

145
07:32.880 --> 07:36.840
to know should I drop this packet.

146
07:36.840 --> 07:41.360
So we need to mark this packet in some way.

147
07:41.360 --> 07:47.080
So this endpoint's traffic, the packets that it creates and sends into the

148
07:47.080 --> 07:48.240
fabric are going

149
07:48.240 --> 07:54.440
to be marked with scalable group tags, otherwise known as SGTs.

150
07:54.440 --> 07:58.460
Now, if you've been around the industry for a while, at one point Cisco

151
07:58.460 --> 07:59.520
referred to SGTs

152
07:59.520 --> 08:04.220
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

152
07:59.520 --> 08:04.220
as security group tags, but now we can do more with these tags than simple

153
08:04.220 --> 08:06.240
security policy.

154
08:06.240 --> 08:08.240
That's the focus of this conversation.

155
08:08.240 --> 08:12.710
And so Cisco has kind of changed the definition of the S to be scalable group

156
08:12.710 --> 08:13.320
tags.

157
08:13.320 --> 08:14.320
So be aware of that.

158
08:14.320 --> 08:23.920
We are now saying that it stands for scalable group tags.

159
08:23.920 --> 08:29.910
As a result of this architecture, I can now push security policy out to the

160
08:29.910 --> 08:30.800
fabric in the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
08:29.910 --> 08:30.800
fabric in the

161
08:30.800 --> 08:37.640
form of what we call scalable group access control lists or SG ACLs.

162
08:37.640 --> 08:42.490
It defines for these edge nodes whether traffic can be allowed or whether it

163
08:42.490 --> 08:44.280
should be dropped.

164
08:44.280 --> 08:50.680
And so these SG ACLs are going to be pushed out to the various edge nodes.

165
08:50.680 --> 08:54.280
So that's an important first step is that we push the policy out.

166
08:54.280 --> 08:59.400
The important second step is that we mark our packets with the SGTs.

167
08:59.400 --> 09:02.240
So now I get this packet with an SGT.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
08:59.400 --> 09:02.240
So now I get this packet with an SGT.

168
09:02.240 --> 09:06.440
And as we mentioned before, that is helped along by VXLAN.

169
09:06.440 --> 09:10.970
We insert that into the VXLAN header so that information arrives on the other

170
09:10.970 --> 09:11.520
side.

171
09:11.520 --> 09:15.240
So now this egress edge node has two things.

172
09:15.240 --> 09:22.280
It has the SG ACL, which is the policy, and it has the SGT, which defines for

173
09:22.280 --> 09:22.920
us what

174
09:22.920 --> 09:31.360
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

174
09:22.920 --> 09:31.360
traffic type this is, and I compare these two and I either allow it or I drop

175
09:31.360 --> 09:32.160
it.

176
09:32.160 --> 09:35.560
Again, is this allowed by the security policy?

177
09:35.560 --> 09:38.840
And now we have a way of determining this.

178
09:38.840 --> 09:44.000
Now an important facet in all of this is notice this decision about whether to

179
09:44.000 --> 09:44.680
allow or

180
09:44.680 --> 09:49.920
drop the frame, this is happening on the egress edge node.

181
09:49.920 --> 09:53.240
This is not a decision that happens on the egress side.

182
09:53.240 --> 09:57.840
Now security policy typically says that in a perfect world, we would always

183
09:57.840 --> 09:58.360
drop on the

184
09:58.360 --> 09:59.360
egress side.

185
09:59.360 --> 10:00.880
I mean, why waste resources?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

185
09:59.360 --> 10:00.880
I mean, why waste resources?

186
10:00.880 --> 10:05.160
Why have a security risk of sending a packet that's not allowed into the

187
10:05.160 --> 10:06.200
network and drop

188
10:06.200 --> 10:07.200
it later?

189
10:07.200 --> 10:08.520
We should drop it right away.

190
10:08.520 --> 10:12.300
Well, with this particular security policy, we don't want to necessarily do

191
10:12.300 --> 10:12.800
that.

192
10:12.800 --> 10:14.400
And there's a good reason for it.

193
10:14.400 --> 10:19.800
The reason is as packets come in to this ingress edge node, if that ingress

194
10:19.800 --> 10:20.840
edge node were

195
10:20.840 --> 10:25.280
to drop this frame, think about all of the policies that it would need.

196
10:25.280 --> 10:31.280
It would need to know policies for every single remote destination.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
10:25.280 --> 10:31.280
It would need to know policies for every single remote destination.

197
10:31.280 --> 10:35.500
And it would have to be able to store that information and know whether to drop

198
10:35.500 --> 10:35.800
the

199
10:35.800 --> 10:38.280
frame as it comes in.

200
10:38.280 --> 10:43.130
Whereas the egress edge can just know the policies that apply to its own local

201
10:43.130 --> 10:43.800
hosts.

202
10:43.800 --> 10:48.420
And so it makes it so it's much more efficient from the perspective of storing

203
10:48.420 --> 10:49.600
that information

204
10:49.600 --> 10:52.960
on the egress side rather than putting it on the ingress.

205
10:52.960 --> 10:56.470
And yes, that does make it so the egress side is the one responsible for

206
10:56.470 --> 10:57.280
dropping it.

207
10:57.280 --> 10:59.680
But again, Cisco has a good reason for doing so.

208
10:59.680 --> 11:03.440
So as we see, security is integrated from the beginning.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

208
10:59.680 --> 11:03.440
So as we see, security is integrated from the beginning.

209
11:03.440 --> 11:06.880
It is not an afterthought with software defined access.

210
11:06.880 --> 11:11.780
And it's going to be an integral part of our ability to enforce policy with

211
11:11.780 --> 11:12.720
this design.