1
00:00:00,000 --> 00:00:03,458
[AUDIO LOGO]

2
00:00:03,458 --> 00:00:08,109

3
00:00:08,109 --> 00:00:11,570
So now let's jump in
and get an introduction

4
00:00:11,570 --> 00:00:16,740
to some of the route filtering
options available in BGP.

5
00:00:16,740 --> 00:00:20,030
Now please keep in
mind that this is just

6
00:00:20,030 --> 00:00:23,270
going to be an introduction to
some of the filtering options

7
00:00:23,270 --> 00:00:24,740
that we have available.

8
00:00:24,740 --> 00:00:29,120
Later in the course, we
will have an entire skill

9
00:00:29,120 --> 00:00:33,020
about route filtering
and redistribution

10
00:00:33,020 --> 00:00:36,380
between several
different protocols, BGP

11
00:00:36,380 --> 00:00:37,620
being one of them.

12
00:00:37,620 --> 00:00:40,850
So we will see these
things in more detail

13
00:00:40,850 --> 00:00:44,910
and actually implement
it later in the course.

14
00:00:44,910 --> 00:00:47,780
Now that said, we
do, at least have

15
00:00:47,780 --> 00:00:51,360
to mention filtering here
because it is, of course,

16
00:00:51,360 --> 00:00:52,950
a security feature.

17
00:00:52,950 --> 00:00:56,120
It can also be used
for path manipulation,

18
00:00:56,120 --> 00:01:00,650
but I would say that its
primary purpose is to filter

19
00:01:00,650 --> 00:01:03,140
routes to secure environments.

20
00:01:03,140 --> 00:01:04,640
This, of course,
is what we're going

21
00:01:04,640 --> 00:01:06,680
to use for things
like preventing

22
00:01:06,680 --> 00:01:11,580
our customers from advertising
those RFC 1918 addresses

23
00:01:11,580 --> 00:01:13,350
that they're not supposed to.

24
00:01:13,350 --> 00:01:15,700
And, of course,
many other purposes.

25
00:01:15,700 --> 00:01:19,080
So let's go ahead and jump
in and get that introduction

26
00:01:19,080 --> 00:01:24,020
to some of the filtering
options that we have in BGP.

27
00:01:24,020 --> 00:01:26,590
So the first type of filtering
we're going to talk about

28
00:01:26,590 --> 00:01:28,780
is prefix filtering.

29
00:01:28,780 --> 00:01:31,780
And as the name
sounds, this would

30
00:01:31,780 --> 00:01:35,840
be filtering based on
the actual prefix itself.

31
00:01:35,840 --> 00:01:38,320
And as we go through each
of these different filtering

32
00:01:38,320 --> 00:01:40,810
options, we're going
to talk about this

33
00:01:40,810 --> 00:01:43,930
from the perspective of
the service provider,

34
00:01:43,930 --> 00:01:46,480
but we'll also talk about
it from the perspective

35
00:01:46,480 --> 00:01:49,720
of the customers because,
of course, with things

36
00:01:49,720 --> 00:01:53,290
like managed edge services,
as the service provider,

37
00:01:53,290 --> 00:01:57,470
we may be managing the
customer's devices as well.

38
00:01:57,470 --> 00:02:01,690
So to begin with from the
service provider's perspective,

39
00:02:01,690 --> 00:02:04,510
reasons to implement
prefix filtering.

40
00:02:04,510 --> 00:02:08,830
Number one, of course, we've
discussed this a few times now,

41
00:02:08,830 --> 00:02:14,380
to prevent the advertisement
of those RFC 1918 addresses

42
00:02:14,380 --> 00:02:19,240
into BGP, be that through
redistribution or maybe

43
00:02:19,240 --> 00:02:21,550
somebody actually puts
in a network statement

44
00:02:21,550 --> 00:02:22,990
and injects them.

45
00:02:22,990 --> 00:02:27,740
But either way, we of course,
don't want these in BGP.

46
00:02:27,740 --> 00:02:32,420
Also we want to prevent
unauthorized prefixes

47
00:02:32,420 --> 00:02:35,660
from being advertised
by customers.

48
00:02:35,660 --> 00:02:39,770
And this is what we were talking
about in the previous video

49
00:02:39,770 --> 00:02:42,920
when we mentioned that
they may try to maliciously

50
00:02:42,920 --> 00:02:46,760
advertise maybe another
company's prefixes.

51
00:02:46,760 --> 00:02:49,040
Again, it could
also be accidental.

52
00:02:49,040 --> 00:02:51,590
But that can really
cause an issue

53
00:02:51,590 --> 00:02:55,370
for those other customers,
maybe our own customers or maybe

54
00:02:55,370 --> 00:02:57,470
somebody else out
there on the internet.

55
00:02:57,470 --> 00:03:00,900
Either way, we should
not allow this to happen.

56
00:03:00,900 --> 00:03:03,170
And then in the
other direction, we

57
00:03:03,170 --> 00:03:05,150
want to make sure
that we're only

58
00:03:05,150 --> 00:03:10,220
sending the requested
prefixes to the customers.

59
00:03:10,220 --> 00:03:14,510
This is really focusing
on what level of routing

60
00:03:14,510 --> 00:03:16,730
has this customer requested?

61
00:03:16,730 --> 00:03:19,220
Generally speaking,
we offer three levels

62
00:03:19,220 --> 00:03:21,410
of routing to a customer.

63
00:03:21,410 --> 00:03:24,860
Possibly, they want
just a default route.

64
00:03:24,860 --> 00:03:28,160
Another possibility,
the service provider

65
00:03:28,160 --> 00:03:31,430
and its directly
connected customers

66
00:03:31,430 --> 00:03:33,870
to be sent to that customer.

67
00:03:33,870 --> 00:03:37,400
That way, they can come
to this service provider

68
00:03:37,400 --> 00:03:40,400
if what they're doing is
going to another customer,

69
00:03:40,400 --> 00:03:43,580
but maybe they go to a
different service provider

70
00:03:43,580 --> 00:03:46,110
if they're going
elsewhere on the internet.

71
00:03:46,110 --> 00:03:48,200
So, of course, this
would be generally

72
00:03:48,200 --> 00:03:50,810
for multihomed
customers, so that they

73
00:03:50,810 --> 00:03:55,350
can go to the most efficient
path to get to another network.

74
00:03:55,350 --> 00:03:57,920
And then finally, of
course, the third option

75
00:03:57,920 --> 00:04:00,810
would be full internet
routes, in which case,

76
00:04:00,810 --> 00:04:02,930
they're going to take
the best possible path,

77
00:04:02,930 --> 00:04:06,660
according to BGP, to get
to every destination.

78
00:04:06,660 --> 00:04:10,640
So that's what we would be
using these outbound prefix

79
00:04:10,640 --> 00:04:13,130
filters for to
ensure the customers

80
00:04:13,130 --> 00:04:16,100
are getting the route
that they requested.

81
00:04:16,100 --> 00:04:18,800
And then on the
customer side, they're

82
00:04:18,800 --> 00:04:22,220
basically going to be
doing the opposite.

83
00:04:22,220 --> 00:04:24,920
They're going to be making
sure that they're only

84
00:04:24,920 --> 00:04:31,130
advertising their assigned
or owned prefixes into BGP.

85
00:04:31,130 --> 00:04:35,720
They're going to prevent the
service provider from sending

86
00:04:35,720 --> 00:04:37,610
unrequested prefixes.

87
00:04:37,610 --> 00:04:40,040
If all they want
is a default, they

88
00:04:40,040 --> 00:04:42,920
need to ensure that we don't
send them the full internet

89
00:04:42,920 --> 00:04:44,400
routing table.

90
00:04:44,400 --> 00:04:47,390
Now another sort of unique
thing that the customers should

91
00:04:47,390 --> 00:04:52,970
be doing is preventing
self-originated prefixes

92
00:04:52,970 --> 00:04:56,510
from being advertised
back to them.

93
00:04:56,510 --> 00:04:58,660
Now there are, of
course, always could

94
00:04:58,660 --> 00:05:03,290
be some unique corner case
where this is not appropriate.

95
00:05:03,290 --> 00:05:06,640
But in most customer
environments,

96
00:05:06,640 --> 00:05:10,150
nobody else in the world
should be advertising

97
00:05:10,150 --> 00:05:12,980
their own prefixes to them.

98
00:05:12,980 --> 00:05:15,550
In fact, it's a
type of an attack.

99
00:05:15,550 --> 00:05:21,190
If a customer, for example, is
advertising a /24 prefix out

100
00:05:21,190 --> 00:05:23,740
onto the internet, which
they probably wouldn't be,

101
00:05:23,740 --> 00:05:26,050
but let's just make it easy.

102
00:05:26,050 --> 00:05:33,010
As an attacker, I could try
to send two /25s covering

103
00:05:33,010 --> 00:05:36,550
the lower and upper end
of their address space,

104
00:05:36,550 --> 00:05:39,820
therefore trying to get
the internet to follow more

105
00:05:39,820 --> 00:05:41,630
specific prefixes.

106
00:05:41,630 --> 00:05:44,290
Now, that again should
hopefully be stopped

107
00:05:44,290 --> 00:05:46,300
by other service providers.

108
00:05:46,300 --> 00:05:49,210
But worst case
scenario, that makes

109
00:05:49,210 --> 00:05:54,700
it all the way to the customer
themselves, and their routers

110
00:05:54,700 --> 00:05:57,230
might start following
these other prefixes

111
00:05:57,230 --> 00:05:59,480
to get to their
own destinations.

112
00:05:59,480 --> 00:06:02,520
And that, of course,
should never be allowed.

113
00:06:02,520 --> 00:06:05,870
So we generally want to
filter our own prefixes

114
00:06:05,870 --> 00:06:09,920
from being advertised to us,
not only for the customer,

115
00:06:09,920 --> 00:06:12,320
but also for service providers.

116
00:06:12,320 --> 00:06:17,050
But normally, it's customers are
going to be focusing on this.

117
00:06:17,050 --> 00:06:20,560
Another choice with filtering
is, of course, AS path

118
00:06:20,560 --> 00:06:24,250
filtering, which is
filtering prefixes based

119
00:06:24,250 --> 00:06:27,670
on the ASs in the AS path.

120
00:06:27,670 --> 00:06:32,170
These use something called
a regular expression.

121
00:06:32,170 --> 00:06:35,800
Again, we will be covering
these more in our videos

122
00:06:35,800 --> 00:06:39,350
on route filtering
later in the course.

123
00:06:39,350 --> 00:06:43,100
But just from a use
perspective, from again,

124
00:06:43,100 --> 00:06:45,710
the service provider's
perspective here,

125
00:06:45,710 --> 00:06:49,100
what do we want to use
AS path filtering for?

126
00:06:49,100 --> 00:06:52,720
So our first one, of course,
is to prevent customers

127
00:06:52,720 --> 00:06:57,070
from advertising
prefixes from another AS,

128
00:06:57,070 --> 00:06:59,650
meaning not the customers.

129
00:06:59,650 --> 00:07:02,050
This is what's going
to prevent them

130
00:07:02,050 --> 00:07:05,140
from becoming a transit AS.

131
00:07:05,140 --> 00:07:09,400
This is another method either
in addition to or instead

132
00:07:09,400 --> 00:07:11,860
of prefix filtering
that we could

133
00:07:11,860 --> 00:07:17,360
use to send the customers again
either all the internet routes

134
00:07:17,360 --> 00:07:20,570
or just the service
providers routes

135
00:07:20,570 --> 00:07:23,280
and the direct customers.

136
00:07:23,280 --> 00:07:26,540
In fact, this is
probably the best way

137
00:07:26,540 --> 00:07:29,060
if what the customer
wants is the service

138
00:07:29,060 --> 00:07:33,020
provider and the
direct customers,

139
00:07:33,020 --> 00:07:35,630
because getting the
direct customers

140
00:07:35,630 --> 00:07:40,050
is real easy when we're
using a regular expression.

141
00:07:40,050 --> 00:07:43,880
So that way, we don't have to
match on every single prefix

142
00:07:43,880 --> 00:07:46,220
from every single
one of our customers

143
00:07:46,220 --> 00:07:49,700
when we're trying to
send just our prefixes

144
00:07:49,700 --> 00:07:51,650
to another customer.

145
00:07:51,650 --> 00:07:54,710
And, of course, we can
use this same methodology

146
00:07:54,710 --> 00:07:56,940
between service providers.

147
00:07:56,940 --> 00:07:59,600
So we could send just the
service provider and customer

148
00:07:59,600 --> 00:08:02,750
routes to other
service providers.

149
00:08:02,750 --> 00:08:06,620
Now notice on here,
this is dependent

150
00:08:06,620 --> 00:08:12,080
on the peering agreements
with other service providers.

151
00:08:12,080 --> 00:08:15,770
Quite honestly, this one is
probably not a very common

152
00:08:15,770 --> 00:08:18,680
option because it
effectively means

153
00:08:18,680 --> 00:08:22,680
that this service provider
would not be a transit AS.

154
00:08:22,680 --> 00:08:27,320
So this is usually going to be
for like a tier B or a tier C

155
00:08:27,320 --> 00:08:31,770
provider, not a tier A
provider because, of course,

156
00:08:31,770 --> 00:08:35,299
a service provider by nature
is generally a transit AS.

157
00:08:35,299 --> 00:08:37,500
That's what that means.

158
00:08:37,500 --> 00:08:41,000
So again, this wouldn't be a
very common implementation,

159
00:08:41,000 --> 00:08:44,360
but it is a possibility,
again possibly

160
00:08:44,360 --> 00:08:48,350
for some of those smaller
service providers that may not

161
00:08:48,350 --> 00:08:52,370
want to be transit between
two major service providers

162
00:08:52,370 --> 00:08:54,320
because, well,
honestly, they probably

163
00:08:54,320 --> 00:08:56,740
have faster circuits anyway.

164
00:08:56,740 --> 00:08:58,890
Now from the
customer's perspective,

165
00:08:58,890 --> 00:09:00,930
what we're usually
going to want to do

166
00:09:00,930 --> 00:09:07,170
is only send locally
originated routes.

167
00:09:07,170 --> 00:09:10,410
This is actually a very,
very simple and common

168
00:09:10,410 --> 00:09:11,950
regular expression.

169
00:09:11,950 --> 00:09:13,650
So I'll just put it here.

170
00:09:13,650 --> 00:09:16,710
It's representative
of an empty string,

171
00:09:16,710 --> 00:09:19,830
because if it's
locally originated,

172
00:09:19,830 --> 00:09:22,960
then there should be
nothing in the AS path.

173
00:09:22,960 --> 00:09:25,200
So the regular
expression for this

174
00:09:25,200 --> 00:09:30,270
is simply beginning of
string, end of string

175
00:09:30,270 --> 00:09:32,370
with nothing in the middle.

176
00:09:32,370 --> 00:09:35,790
And the customers would
apply this outbound.

177
00:09:35,790 --> 00:09:39,210
The goal of this is, again,
to prevent the customer

178
00:09:39,210 --> 00:09:41,940
from becoming a transit AS.

179
00:09:41,940 --> 00:09:46,110
Another use here is to prevent
receiving of certain prefix

180
00:09:46,110 --> 00:09:50,950
or prefixes from
undesirable AS numbers.

181
00:09:50,950 --> 00:09:53,890
Once again, I don't see
this one implemented

182
00:09:53,890 --> 00:09:59,120
very commonly because Yes,
there are bad actors out there.

183
00:09:59,120 --> 00:10:04,780
But if you use this option, you
would be killing an entire AS.

184
00:10:04,780 --> 00:10:07,750
Now, if this is an
entire company that's

185
00:10:07,750 --> 00:10:10,330
attacking your
company, Yeah, OK,

186
00:10:10,330 --> 00:10:12,220
you might want to
filter out their AS

187
00:10:12,220 --> 00:10:15,220
and not accept any
of their prefixes.

188
00:10:15,220 --> 00:10:20,450
More commonly, this is going
to be done for bad prefixes.

189
00:10:20,450 --> 00:10:22,270
So we could actually
use the prefix

190
00:10:22,270 --> 00:10:25,850
filtering that we talked about
a moment ago for this as well.

191
00:10:25,850 --> 00:10:28,330
So usually, one of
these two options,

192
00:10:28,330 --> 00:10:35,500
depending on the extent of the
bad AS that's attacking us.

193
00:10:35,500 --> 00:10:37,090
The last filtering
option that we're

194
00:10:37,090 --> 00:10:40,570
going to be discussing
right now is the remote

195
00:10:40,570 --> 00:10:43,720
triggered black hole filtering.

196
00:10:43,720 --> 00:10:46,240
And essentially what
we're talking about here

197
00:10:46,240 --> 00:10:52,480
is a tool that our customers
can use to protect themselves

198
00:10:52,480 --> 00:10:56,600
if they're under a distributed
denial of service attack.

199
00:10:56,600 --> 00:10:59,230
So the way this
works is we're going

200
00:10:59,230 --> 00:11:03,440
to identify the traffic
that's attacking our network.

201
00:11:03,440 --> 00:11:06,100
And once it's been
identified, we're

202
00:11:06,100 --> 00:11:10,600
going to use RTBH
to stop the traffic.

203
00:11:10,600 --> 00:11:13,180
From a functional
perspective, we're

204
00:11:13,180 --> 00:11:18,010
going to have a signaling router
that informs all of the edge

205
00:11:18,010 --> 00:11:23,740
routers to drop this offending
traffic that we identified up

206
00:11:23,740 --> 00:11:25,370
here.

207
00:11:25,370 --> 00:11:30,040
Now there are two different
types of black hole filtering.

208
00:11:30,040 --> 00:11:34,520
One is destination-based,
which as the name implies,

209
00:11:34,520 --> 00:11:37,510
it's going to look at
the traffic destination

210
00:11:37,510 --> 00:11:41,720
and do the filtering based on
where the traffic is going.

211
00:11:41,720 --> 00:11:43,630
And, of course, the
opposite of that

212
00:11:43,630 --> 00:11:48,520
would be our source-based black
hole filtering, which as again

213
00:11:48,520 --> 00:11:51,430
the name implies, would
be filtering traffic

214
00:11:51,430 --> 00:11:55,270
based on its source.

215
00:11:55,270 --> 00:11:59,590
In this video, we just jumped
in and got an introduction

216
00:11:59,590 --> 00:12:03,850
to some of the filtering
options available in BGP.

217
00:12:03,850 --> 00:12:07,360
This was more of a
design type perspective

218
00:12:07,360 --> 00:12:09,970
as far as what type
of filtering we

219
00:12:09,970 --> 00:12:11,950
would probably want to do where.

220
00:12:11,950 --> 00:12:14,810
Remember, as I
mentioned earlier,

221
00:12:14,810 --> 00:12:18,790
we do have entire skills
in this course that

222
00:12:18,790 --> 00:12:21,790
are going to cover not
only filtering, but also

223
00:12:21,790 --> 00:12:25,540
redistribution, and using
filtering with redistribution

224
00:12:25,540 --> 00:12:29,660
and so on not only
for security purposes,

225
00:12:29,660 --> 00:12:34,390
but also for path selection
and loop prevention.

226
00:12:34,390 --> 00:12:36,550
I hope this has been
informative for you.

227
00:12:36,550 --> 00:12:39,660
And I'd like to thank
you for viewing.

228
00:12:39,660 --> 00:12:43,000