1 00:00:01,599 --> 00:00:03,600 Join us as we gather around the hedge, 2 00:00:03,600 --> 00:00:04,980 where we dig into technology, 3 00:00:05,359 --> 00:00:08,080 business, and culture with the finest minds in 4 00:00:08,080 --> 00:00:09,059 computer networking. 5 00:00:20,654 --> 00:00:21,875 Hello again, Tom. 6 00:00:22,254 --> 00:00:24,734 I'm not even gonna talk about your plant 7 00:00:24,734 --> 00:00:27,370 because we just did. Okay. Well, my I 8 00:00:27,370 --> 00:00:29,130 think my plant gets an ego boost every 9 00:00:29,130 --> 00:00:31,289 time we record because it hears you just 10 00:00:31,289 --> 00:00:33,689 praising it. And Although I just talked about 11 00:00:33,689 --> 00:00:34,590 it by saying 12 00:00:34,969 --> 00:00:36,090 I'm not gonna talk about it. Yeah. About 13 00:00:36,090 --> 00:00:39,289 it. So that's that's the way this works. 14 00:00:39,289 --> 00:00:39,950 I'm sorry. 15 00:00:40,854 --> 00:00:42,395 The plan likes it. It's all good. 16 00:00:44,215 --> 00:00:45,734 I do think, though, that you need to 17 00:00:45,734 --> 00:00:47,335 get your your boys in there to draw 18 00:00:47,335 --> 00:00:49,655 some pictures on that rather blank whiteboard. It's 19 00:00:49,655 --> 00:00:51,034 too wild. We need spaceships. 20 00:00:51,655 --> 00:00:54,375 Yeah. We need something that's like there's something 21 00:00:54,375 --> 00:00:57,039 wrong with that. K. You go ahead. Yeah. 22 00:00:57,039 --> 00:00:59,039 You can let him know that. So we 23 00:00:59,039 --> 00:01:01,060 are joined again by Henry Burge Lee. 24 00:01:01,600 --> 00:01:02,820 Princeton. Right? 25 00:01:03,840 --> 00:01:06,099 Princeton. Okay. And we talked about 26 00:01:06,560 --> 00:01:09,219 Mexican places the last time we talked, probably. 27 00:01:11,575 --> 00:01:13,515 Places to eat in in Princeton, 28 00:01:14,615 --> 00:01:17,594 and string quartets and string quintets 29 00:01:18,295 --> 00:01:19,995 and trumpet quintets 30 00:01:20,855 --> 00:01:23,915 Woah. Which which were quite fascinating. But, anyway, 31 00:01:24,689 --> 00:01:27,489 so BGP security is the topic today, not 32 00:01:27,489 --> 00:01:29,989 broadly, but a very specific type of attack. 33 00:01:30,209 --> 00:01:32,709 But let's back up and talk about BGP 34 00:01:32,769 --> 00:01:34,310 hijacks to start with 35 00:01:34,769 --> 00:01:37,170 just so our listeners have some clue. I 36 00:01:37,170 --> 00:01:39,144 mean, I think most of our listeners know 37 00:01:39,144 --> 00:01:42,045 this, but it never hurts to, like, say, 38 00:01:42,344 --> 00:01:44,584 you know, what is a hijack? What what's 39 00:01:44,584 --> 00:01:45,564 going on here? 40 00:01:46,825 --> 00:01:49,384 Yeah. So I think a BGP hijack and 41 00:01:50,129 --> 00:01:52,390 what is a hijack is a surprisingly 42 00:01:52,689 --> 00:01:54,770 deep question if you really get into it. 43 00:01:54,770 --> 00:01:55,989 Mhmm. But, essentially, 44 00:01:56,530 --> 00:01:58,229 I like to think of it as organization 45 00:01:58,689 --> 00:01:59,670 x owns 46 00:02:00,049 --> 00:02:01,750 some plaque of IP space 47 00:02:02,129 --> 00:02:04,885 and expects standard Internet routing so that traffic 48 00:02:04,885 --> 00:02:07,204 to their IP space goes to them. And 49 00:02:07,204 --> 00:02:09,365 then somewhere else in the Internet, an adversary 50 00:02:09,365 --> 00:02:11,944 that previously would not have been 51 00:02:12,485 --> 00:02:15,044 on the route to that IP block makes 52 00:02:15,044 --> 00:02:16,264 a BGP announcement 53 00:02:16,860 --> 00:02:19,500 so that now some fraction of Internet traffic, 54 00:02:19,500 --> 00:02:21,919 if not all of Internet traffic, goes through 55 00:02:22,299 --> 00:02:22,799 adversary, 56 00:02:23,900 --> 00:02:25,580 and then they can choose to forward it 57 00:02:25,580 --> 00:02:27,439 to organization x or 58 00:02:27,819 --> 00:02:29,519 just answer it themselves. 59 00:02:31,165 --> 00:02:31,665 Okay. 60 00:02:32,365 --> 00:02:34,365 So when we say a hijack, we're basically 61 00:02:34,365 --> 00:02:34,865 saying 62 00:02:36,205 --> 00:02:37,585 the route is originated 63 00:02:39,485 --> 00:02:42,145 by someone who's not supposed to be originating 64 00:02:42,205 --> 00:02:43,264 it, basically. 65 00:02:43,639 --> 00:02:45,259 Yeah. So that that's one 66 00:02:45,879 --> 00:02:47,419 absolutely accurate definition. 67 00:02:48,360 --> 00:02:50,300 And when I said it's very 68 00:02:50,759 --> 00:02:52,599 complicated, if you wanna drill to the bottom 69 00:02:52,599 --> 00:02:54,039 of that Oh, yeah. Yeah. No. There's there's 70 00:02:54,039 --> 00:02:56,039 a lot more complexity than that, but that's 71 00:02:56,039 --> 00:02:57,719 the basic But that's the easiest way to 72 00:02:57,719 --> 00:03:00,275 think of it. Like, you know, organization x 73 00:03:00,275 --> 00:03:02,615 owns that block. They should be originating it. 74 00:03:02,675 --> 00:03:03,974 And then mister bad 75 00:03:04,354 --> 00:03:06,194 guy originates that route, goes out to the 76 00:03:06,194 --> 00:03:09,074 Internet and then traffic to organization x goes 77 00:03:09,074 --> 00:03:10,995 to the bad guy. A threat actor with 78 00:03:10,995 --> 00:03:11,895 a red laptop. 79 00:03:12,419 --> 00:03:14,900 Yeah. Exactly. Because they're always and the hat. 80 00:03:14,900 --> 00:03:17,219 Yes. They always they always have a red 81 00:03:17,219 --> 00:03:19,240 lap laptop, and they have a hoodie 82 00:03:19,540 --> 00:03:22,419 and the hat. Right? That's that's all that's 83 00:03:22,419 --> 00:03:23,800 how you know they're threat actors 84 00:03:24,115 --> 00:03:26,615 because they're that's what they are. 85 00:03:28,115 --> 00:03:28,615 So 86 00:03:29,155 --> 00:03:31,735 so alright. So given that, 87 00:03:32,514 --> 00:03:34,435 currently, what we're looking at to try to 88 00:03:34,435 --> 00:03:37,014 solve that problem, what's been mandated by 89 00:03:37,629 --> 00:03:39,389 NIST and the US government, I don't remember 90 00:03:39,389 --> 00:03:40,209 the regulation, 91 00:03:41,069 --> 00:03:42,750 at least here in The US, is to 92 00:03:42,750 --> 00:03:43,729 deploy RPKI. 93 00:03:44,750 --> 00:03:46,590 So I don't wanna spend a ton of 94 00:03:46,590 --> 00:03:47,889 time talking about RPKI. 95 00:03:48,989 --> 00:03:50,669 Although I think it's a fine it's a 96 00:03:50,669 --> 00:03:52,049 fine way of doing things, 97 00:03:52,814 --> 00:03:54,034 but it's nonetheless, 98 00:03:54,335 --> 00:03:55,795 you know, it does add complexity. 99 00:03:56,495 --> 00:03:58,495 Don't get me started on BGP sec, because 100 00:03:58,495 --> 00:03:59,955 BGP secomy is like 101 00:04:00,254 --> 00:04:02,194 worse. It's one of those diseases 102 00:04:03,055 --> 00:04:04,895 that cures that's worse than a disease, in 103 00:04:04,895 --> 00:04:05,555 my opinion, 104 00:04:05,889 --> 00:04:07,889 because it's so complex and it opens up 105 00:04:07,889 --> 00:04:10,289 so many new attack surfaces. I'm I'm very 106 00:04:10,289 --> 00:04:12,049 refreshed to hear you say that because I 107 00:04:12,049 --> 00:04:13,349 have talked to many. 108 00:04:13,650 --> 00:04:16,449 There are absolutely attack vectors within the BGP 109 00:04:16,449 --> 00:04:18,870 sec ecosystem. There are attacks it doesn't cover 110 00:04:19,115 --> 00:04:20,175 and then the complexity. 111 00:04:20,875 --> 00:04:23,774 I I guess a very fun digression, but 112 00:04:23,915 --> 00:04:25,295 the the only known 113 00:04:25,754 --> 00:04:27,995 BGP sec implementation I know of is from 114 00:04:27,995 --> 00:04:30,154 NIST, and it's based on, like, an obsolete 115 00:04:30,154 --> 00:04:31,055 version of Quagga. 116 00:04:31,435 --> 00:04:33,459 I was doing an experiment with some researchers, 117 00:04:33,459 --> 00:04:35,139 and we said, oh, what happens if you 118 00:04:35,139 --> 00:04:37,459 set MRAI to to zero? And no other 119 00:04:37,459 --> 00:04:38,360 router implementation 120 00:04:38,740 --> 00:04:41,639 has a problem with MRAI zero. Most networks 121 00:04:42,099 --> 00:04:44,439 run MRAI zero. It's quite common nowadays. 122 00:04:44,979 --> 00:04:47,865 But this old implementation of Quagga, the whole 123 00:04:47,865 --> 00:04:50,824 NIST BGP sec implementation crashes when you set 124 00:04:50,824 --> 00:04:52,824 MRA at this zero. Yeah. So it's like 125 00:04:52,824 --> 00:04:54,185 there's still a little work to be done 126 00:04:54,185 --> 00:04:56,025 if you wanna put that in the production 127 00:04:56,025 --> 00:04:56,525 box. 128 00:04:56,904 --> 00:04:59,384 Well, my absolute favorite is is that if 129 00:04:59,384 --> 00:05:00,660 I connect with you, 130 00:05:01,060 --> 00:05:02,360 okay, and I 131 00:05:02,740 --> 00:05:04,500 I agree to a connect with you and 132 00:05:04,500 --> 00:05:06,040 I have a contract with you, 133 00:05:06,660 --> 00:05:07,480 and then 134 00:05:08,420 --> 00:05:09,240 you say, 135 00:05:10,019 --> 00:05:10,519 okay, 136 00:05:12,259 --> 00:05:14,279 we're mad at each other, so we disconnect. 137 00:05:14,675 --> 00:05:17,014 Right? Whatever happens, contract fails, whatever. 138 00:05:17,875 --> 00:05:18,375 My 139 00:05:18,754 --> 00:05:19,814 previous upstream 140 00:05:20,754 --> 00:05:22,775 still has my signed routes, 141 00:05:23,875 --> 00:05:25,735 and I they can advertise them 142 00:05:26,115 --> 00:05:26,615 forever 143 00:05:27,649 --> 00:05:29,829 until I change roll my key. 144 00:05:30,129 --> 00:05:32,850 Right? Until you roll. Yeah. So so if 145 00:05:32,850 --> 00:05:33,669 I'm a provider 146 00:05:34,129 --> 00:05:36,610 advertising 10,000 routes and I have to roll 147 00:05:36,610 --> 00:05:38,310 the key on 10,000 routes 148 00:05:38,930 --> 00:05:41,089 to stop my old up to stop somebody 149 00:05:41,089 --> 00:05:41,589 from 150 00:05:41,915 --> 00:05:43,295 advertising my originating. 151 00:05:43,915 --> 00:05:46,095 No. I'm sorry. That's not happening. 152 00:05:46,634 --> 00:05:47,454 That's like 153 00:05:47,915 --> 00:05:50,875 Here's the other fun one. Prefix 1234 154 00:05:50,875 --> 00:05:51,935 is out on the Internet. 155 00:05:52,714 --> 00:05:55,194 You know, BGP sec. Let's assume world's doing 156 00:05:55,194 --> 00:05:58,269 great. BGP sec. Then prefix owner deaggregates 157 00:05:58,569 --> 00:06:00,649 back to, like, a slash 23. That prefix 158 00:06:00,649 --> 00:06:01,310 is withdrawn. 159 00:06:01,850 --> 00:06:03,709 Until people roll all their keys, 160 00:06:04,009 --> 00:06:05,930 you, the bad guy, still have the one, 161 00:06:05,930 --> 00:06:08,490 two, three, four route signed everything. You just 162 00:06:08,490 --> 00:06:10,704 announced that out to the Internet, and now 163 00:06:10,704 --> 00:06:12,785 you're the only announcement point for 1 2 164 00:06:12,785 --> 00:06:15,185 3 4. So you just hijacked everything. You're 165 00:06:15,185 --> 00:06:16,485 gonna be in separate. 166 00:06:17,024 --> 00:06:18,384 A a lot of this just comes from 167 00:06:18,384 --> 00:06:19,925 BGP doesn't have timers. 168 00:06:20,225 --> 00:06:21,845 Right? It's not rip. 169 00:06:22,384 --> 00:06:23,845 A route is permanently 170 00:06:24,225 --> 00:06:26,680 good as once it's been advertised. You have 171 00:06:26,680 --> 00:06:30,060 to there there's no there's no secure withdraw 172 00:06:30,120 --> 00:06:31,660 system in BGP. 173 00:06:32,199 --> 00:06:35,399 Right? And so and and implicits make it 174 00:06:35,399 --> 00:06:37,660 hard. There's all these problems with withdraw 175 00:06:38,040 --> 00:06:39,959 in BGP. And by the way, this even 176 00:06:39,959 --> 00:06:40,779 goes generally. 177 00:06:41,354 --> 00:06:43,914 People think BGP converges really fast. They think 178 00:06:43,914 --> 00:06:45,694 so because they all look at updates. 179 00:06:47,274 --> 00:06:49,274 They don't look at implicit withdrawals. They don't 180 00:06:49,274 --> 00:06:50,095 look at withdrawals. 181 00:06:50,634 --> 00:06:51,134 Withdraws 182 00:06:51,914 --> 00:06:52,414 are 183 00:06:52,714 --> 00:06:53,214 eternal 184 00:06:54,074 --> 00:06:54,814 in BGP. 185 00:06:55,274 --> 00:06:57,370 I mean, they're really not. They're like three 186 00:06:57,370 --> 00:06:59,329 to five minutes to get a withdraw through 187 00:06:59,329 --> 00:07:01,490 the global Internet. But still, it's three to 188 00:07:01,490 --> 00:07:03,669 five it's, like, three to five minutes. 189 00:07:03,970 --> 00:07:06,449 I give mine up to 12 minimum before 190 00:07:06,449 --> 00:07:08,129 I start to not see that in the 191 00:07:08,129 --> 00:07:10,550 table. Yeah. Like, it's it, like, 192 00:07:10,995 --> 00:07:13,014 it's it's like just a thing with BGP. 193 00:07:13,074 --> 00:07:15,074 And people always measure this one thing, and 194 00:07:15,074 --> 00:07:16,514 then they don't pay attention to the other. 195 00:07:16,514 --> 00:07:18,595 Yeah. But Russ, you're much more refreshing to 196 00:07:18,595 --> 00:07:21,395 talk to than the academic reviewers, I have 197 00:07:21,395 --> 00:07:22,055 to admit. 198 00:07:24,435 --> 00:07:26,970 Oh, my goodness. Well, my history with BGP 199 00:07:26,970 --> 00:07:29,370 Sec is very old. I was co chair 200 00:07:29,370 --> 00:07:31,050 of the BGP Sec Working Group in the 201 00:07:31,050 --> 00:07:31,550 IETF 202 00:07:32,649 --> 00:07:35,449 many, many years ago. And then the Working 203 00:07:35,449 --> 00:07:37,129 Group was shut down because we could come 204 00:07:37,129 --> 00:07:37,949 to no agreements. 205 00:07:39,205 --> 00:07:41,764 And so that but that's a bit of 206 00:07:41,764 --> 00:07:44,324 weird history that's that goes a long time 207 00:07:44,324 --> 00:07:44,824 ago. 208 00:07:45,525 --> 00:07:46,884 In fact, there was a time I was 209 00:07:46,884 --> 00:07:47,785 talking to somebody 210 00:07:48,324 --> 00:07:50,805 on a on the BGP segmenting list, and 211 00:07:50,805 --> 00:07:53,839 they said, well, signing the update makes it 212 00:07:53,839 --> 00:07:54,339 secure. 213 00:07:55,120 --> 00:07:56,100 And I said, 214 00:07:56,480 --> 00:07:57,300 does signing 215 00:07:57,839 --> 00:07:58,660 your doorknob 216 00:07:59,040 --> 00:08:00,259 make it more secure? 217 00:08:00,959 --> 00:08:03,620 I'm just like, I'm very curious. 218 00:08:04,240 --> 00:08:07,355 Is it the signature that does the work? 219 00:08:07,574 --> 00:08:08,074 Like, 220 00:08:08,454 --> 00:08:09,435 what are you 221 00:08:09,975 --> 00:08:11,254 okay. Whatever. Anyway 222 00:08:13,894 --> 00:08:15,274 so so let's talk about 223 00:08:15,975 --> 00:08:16,475 stealth 224 00:08:17,095 --> 00:08:19,175 BGP attacks. And what you mean what do 225 00:08:19,175 --> 00:08:20,699 you mean when you say it is a 226 00:08:20,779 --> 00:08:23,040 stealth or a stealthy BGP tag? 227 00:08:23,500 --> 00:08:25,660 Yeah. So that that's that's a great question, 228 00:08:25,660 --> 00:08:27,500 and that's often at the crux of this 229 00:08:27,500 --> 00:08:28,720 work. So 230 00:08:29,580 --> 00:08:32,139 I think to explain stealth, it's important to 231 00:08:32,139 --> 00:08:33,519 understand the BGP 232 00:08:34,475 --> 00:08:37,355 ecosystem a bit. And really what I'm narrowing 233 00:08:37,355 --> 00:08:40,175 in on in this paper is BGP monitoring. 234 00:08:40,235 --> 00:08:43,115 So we have public data feeds of BGP 235 00:08:43,115 --> 00:08:44,335 attacks, most notably, 236 00:08:44,955 --> 00:08:45,455 RipeRisks 237 00:08:46,235 --> 00:08:47,295 and route views. 238 00:08:47,889 --> 00:08:50,709 They peer with several hundred organizations including 239 00:08:51,089 --> 00:08:53,190 all essentially of the tier one ISPs. 240 00:08:53,809 --> 00:08:56,230 They dump their updates and then they publish, 241 00:08:56,690 --> 00:08:59,730 you know, consumable formats for researchers or even 242 00:08:59,730 --> 00:09:01,990 online attack detection systems. 243 00:09:02,445 --> 00:09:04,225 You move into the private space, 244 00:09:05,085 --> 00:09:05,585 ThousandEyes, 245 00:09:06,445 --> 00:09:09,504 CodeBGP, which then got acquired by Cisco ThousandEyes 246 00:09:09,565 --> 00:09:11,884 and bundled in and, you know, a couple 247 00:09:11,884 --> 00:09:11,965 other 248 00:09:14,699 --> 00:09:17,360 And even and even some DDoS providers, Akamai 249 00:09:17,419 --> 00:09:18,799 and Exactly. Fastly 250 00:09:19,179 --> 00:09:20,000 and Cloudflare 251 00:09:20,379 --> 00:09:21,339 will So essentially 252 00:09:21,899 --> 00:09:23,980 Yeah. They're monitoring. You know, they're looking at 253 00:09:23,980 --> 00:09:24,879 BGP updates. 254 00:09:25,899 --> 00:09:27,679 And this is one, I'd say, 255 00:09:28,004 --> 00:09:30,345 pillar kind of of the BGP security. RPKI 256 00:09:30,485 --> 00:09:32,884 is firmly on the prevention side for the 257 00:09:32,884 --> 00:09:35,205 most part. It's meant to, you know, you 258 00:09:35,205 --> 00:09:37,205 can't make that announcement. It will get filtered 259 00:09:37,205 --> 00:09:38,585 if it's RPKI invalid. 260 00:09:39,045 --> 00:09:41,519 BGP monitoring is kind of on the detection 261 00:09:41,580 --> 00:09:44,220 side. Some people have proposed active measures based 262 00:09:44,220 --> 00:09:46,299 on monitoring. But essentially the idea is you're 263 00:09:46,299 --> 00:09:48,379 looking, you're consuming all the global data feeds 264 00:09:48,379 --> 00:09:49,120 and then 265 00:09:49,500 --> 00:09:51,899 something bad happens in PGP and you'd like 266 00:09:51,899 --> 00:09:54,399 to have a I got hacked button that 267 00:09:54,539 --> 00:09:56,355 you will press at that time when your 268 00:09:56,355 --> 00:09:58,774 BGP monitoring tells you that you got hacked. 269 00:09:58,995 --> 00:10:01,815 So it's a retroactive preventative measure. 270 00:10:02,674 --> 00:10:03,815 Okay. Cool. 271 00:10:04,195 --> 00:10:06,355 So we're talking about monitoring, and we're talking 272 00:10:06,355 --> 00:10:08,134 about the ability to monitor 273 00:10:08,929 --> 00:10:10,950 effectively and effectively detect 274 00:10:11,730 --> 00:10:12,230 Exactly. 275 00:10:13,330 --> 00:10:13,830 Attacks. 276 00:10:14,210 --> 00:10:14,710 Right? 277 00:10:15,649 --> 00:10:18,289 Exactly. Right. Alright. By the way, I didn't 278 00:10:18,289 --> 00:10:20,149 realize Jennifer Rexford's on this. 279 00:10:20,865 --> 00:10:23,024 Yeah. Well, I work under I work under 280 00:10:23,024 --> 00:10:26,144 Jennifer Rexford. Okay. Alright. That is interesting in 281 00:10:26,144 --> 00:10:28,325 and of itself. I know Jennifer from IETF 282 00:10:28,384 --> 00:10:31,184 work and stuff. That's wonderful. Yeah. Yeah. So 283 00:10:31,184 --> 00:10:32,865 so that's so that's interesting. I didn't realize 284 00:10:32,865 --> 00:10:34,559 Jennifer was involved in it, which is cool. 285 00:10:34,559 --> 00:10:36,399 I mean, she's a very good researcher. She's 286 00:10:36,399 --> 00:10:39,440 very strong, understands BGP really well. And I 287 00:10:39,440 --> 00:10:40,960 didn't I didn't just didn't realize she was 288 00:10:40,960 --> 00:10:43,220 involved in this. But anyway, alright. So 289 00:10:43,919 --> 00:10:44,740 we are 290 00:10:45,200 --> 00:10:47,919 trying to detect these attacks and then we 291 00:10:47,919 --> 00:10:50,365 find we found a way to make it 292 00:10:50,365 --> 00:10:53,985 basically impossible to detect them. Right? Exactly. So 293 00:10:54,125 --> 00:10:55,424 the monitoring infrastructure, 294 00:10:57,004 --> 00:10:59,565 largely works off of these peering sessions with 295 00:10:59,565 --> 00:11:02,529 the major ISPs that essentially dump. You can 296 00:11:02,529 --> 00:11:04,610 almost imagine it like a customer route table 297 00:11:04,610 --> 00:11:06,149 that they give out to these 298 00:11:06,529 --> 00:11:09,169 organizations for free, and then they get all 299 00:11:09,169 --> 00:11:11,110 the routes, and that's what you're monitoring. 300 00:11:11,490 --> 00:11:14,529 And, essentially, what I was really interested here 301 00:11:14,529 --> 00:11:16,049 is that it turns out that if I'm 302 00:11:16,049 --> 00:11:17,965 a direct customer of, let's say, 303 00:11:19,184 --> 00:11:21,144 I feel like like I'll I'll go with 304 00:11:21,144 --> 00:11:22,924 Cogent because we did some of the experiments, 305 00:11:23,384 --> 00:11:26,205 with them. But it's not specific to Cogent. 306 00:11:26,585 --> 00:11:28,745 But I'm a direct customer of Cogent, and 307 00:11:28,745 --> 00:11:30,665 I can put a route in Cogent's table 308 00:11:30,665 --> 00:11:32,445 and tag it with the 309 00:11:32,809 --> 00:11:34,669 no export BGP community. 310 00:11:35,289 --> 00:11:37,289 And the fun thing is it turns out 311 00:11:37,289 --> 00:11:39,289 that just the way routers work and the 312 00:11:39,289 --> 00:11:41,850 way most people's networks are set up, this 313 00:11:41,850 --> 00:11:44,330 no export community will have the intended of 314 00:11:44,490 --> 00:11:45,615 the effect of 315 00:11:45,934 --> 00:11:47,695 causing Cogent not to send the route to 316 00:11:47,695 --> 00:11:49,934 BGP monitoring. So it's not just no export 317 00:11:49,934 --> 00:11:52,274 to their customers, which is what you'd expect. 318 00:11:52,495 --> 00:11:54,894 It's also no export to BGP monitoring. So 319 00:11:54,894 --> 00:11:55,794 in this manner, 320 00:11:56,174 --> 00:11:58,414 I can send anything that they're willing to 321 00:11:58,414 --> 00:12:00,894 accept. Maybe I'm trying to social engineer their 322 00:12:00,894 --> 00:12:03,740 teams or bypass some white list filters. You 323 00:12:03,740 --> 00:12:05,580 know? And if they're willing to accept it, 324 00:12:05,580 --> 00:12:07,179 it will never go out to the global 325 00:12:07,179 --> 00:12:10,000 monitoring community. It'll just be kinda secretly hidden 326 00:12:10,460 --> 00:12:11,919 within Cogent's network. 327 00:12:13,340 --> 00:12:14,960 Okay. So it's interesting. 328 00:12:16,954 --> 00:12:19,115 The the thing let's think about no export 329 00:12:19,115 --> 00:12:21,434 for a second. So what no export does 330 00:12:21,434 --> 00:12:23,434 is it says, don't send this out of 331 00:12:23,434 --> 00:12:25,595 my local AS, this route. I'm gonna advertise 332 00:12:25,595 --> 00:12:27,995 something to you. Don't advertise it. It's not 333 00:12:28,470 --> 00:12:31,029 there is another another one that's not well 334 00:12:31,029 --> 00:12:33,269 understood, which is no advertise, which is don't 335 00:12:33,269 --> 00:12:35,129 even advertise it to any of my peers. 336 00:12:35,189 --> 00:12:38,389 Zero. Nobody. No IBGP, no IBGP. Don't tell 337 00:12:38,389 --> 00:12:41,289 anybody about this. This prefix is a secret. 338 00:12:41,865 --> 00:12:44,445 Shut up. And then you have no export, 339 00:12:44,825 --> 00:12:45,884 which just means 340 00:12:46,745 --> 00:12:49,644 don't send it out over any eBGP connections. 341 00:12:49,945 --> 00:12:52,264 Right? All iBGP connections are fine, but not 342 00:12:52,264 --> 00:12:52,764 eBGP. 343 00:12:53,465 --> 00:12:55,465 So what you're saying is is they are 344 00:12:55,465 --> 00:12:55,965 announcing 345 00:12:58,559 --> 00:12:59,379 an advertisement 346 00:13:00,079 --> 00:13:01,059 with no export 347 00:13:02,000 --> 00:13:02,500 to 348 00:13:03,199 --> 00:13:04,100 their adversary's 349 00:13:04,639 --> 00:13:07,039 route. So it's it's it's restricted to a 350 00:13:07,039 --> 00:13:08,579 one hop, basically, 351 00:13:08,959 --> 00:13:10,100 because of the no export. 352 00:13:10,559 --> 00:13:12,500 But then because it's no export, 353 00:13:13,174 --> 00:13:15,274 you don't even send it to 354 00:13:15,735 --> 00:13:17,754 the route view server. Exactly. 355 00:13:18,214 --> 00:13:20,074 Right. Come out. Okay. 356 00:13:20,534 --> 00:13:23,334 Now wouldn't this be, to some degree, cured 357 00:13:23,334 --> 00:13:24,475 by using BMP 358 00:13:25,574 --> 00:13:27,674 Yeah. For the route view server? Okay. 359 00:13:28,019 --> 00:13:30,420 Exactly. So there are many cures, and I 360 00:13:30,420 --> 00:13:30,920 think 361 00:13:31,300 --> 00:13:33,300 really why I'm so excited to talk about 362 00:13:33,300 --> 00:13:34,279 this on the podcast 363 00:13:34,660 --> 00:13:36,740 is I wanna know your thoughts on cures, 364 00:13:36,740 --> 00:13:39,220 and I want network operators listening to this 365 00:13:39,220 --> 00:13:41,639 to let me know their thoughts on cures. 366 00:13:41,884 --> 00:13:43,644 Because there are many ways to fix it. 367 00:13:44,524 --> 00:13:46,924 But right now, it feels like there's not 368 00:13:46,924 --> 00:13:48,684 a lot of sort of, like, what is 369 00:13:48,684 --> 00:13:50,445 the immediate next step? And I think that's 370 00:13:50,445 --> 00:13:51,585 a question that 371 00:13:51,964 --> 00:13:53,325 has come up a bunch that I really 372 00:13:53,325 --> 00:13:55,964 wanna answer. And just to clarify exactly the 373 00:13:55,964 --> 00:13:57,345 mechanism at play, it's 374 00:13:57,769 --> 00:13:59,230 precisely what you were saying. 375 00:13:59,850 --> 00:14:02,490 Route views, when they talk to these networks 376 00:14:02,490 --> 00:14:04,730 to get the route tables, they run an 377 00:14:04,730 --> 00:14:05,230 eBGP 378 00:14:05,690 --> 00:14:09,129 normally multi hop session with them. And route 379 00:14:09,129 --> 00:14:11,690 views has an ASN and so does RIPE 380 00:14:11,690 --> 00:14:14,105 RISC. And to the routers that terminate these 381 00:14:14,105 --> 00:14:15,404 sessions, they are just 382 00:14:15,944 --> 00:14:19,144 standard EBGP sessions with, like, a customer. But 383 00:14:19,144 --> 00:14:21,304 it's not really a customer. It's actually BGP 384 00:14:21,304 --> 00:14:23,704 monitoring. And so when they consume the no 385 00:14:23,704 --> 00:14:26,184 export community that may have been attached by 386 00:14:26,184 --> 00:14:27,404 the adversary, they 387 00:14:28,019 --> 00:14:30,840 stop exporting to these sessions. So, yeah, BMP 388 00:14:30,980 --> 00:14:32,120 is a great answer. 389 00:14:32,660 --> 00:14:36,019 But right now, both Rypress and RouteViews have 390 00:14:36,019 --> 00:14:37,240 not fully 391 00:14:38,019 --> 00:14:40,684 embraced the BMP train. And then I think 392 00:14:40,684 --> 00:14:41,585 a lot of networks 393 00:14:42,044 --> 00:14:43,585 are like, well, BMP 394 00:14:44,365 --> 00:14:47,004 can be configured, but BMP can also leak 395 00:14:47,004 --> 00:14:47,985 a whole lot of 396 00:14:48,605 --> 00:14:51,004 internal network data that you don't want. And 397 00:14:51,004 --> 00:14:53,940 it's an extra CPU load on the routers 398 00:14:53,940 --> 00:14:56,179 that terminate BMP. So, you know, you talk 399 00:14:56,179 --> 00:14:58,179 to people about BMP. They're not always exactly, 400 00:14:58,179 --> 00:14:59,079 like, happy. 401 00:15:00,019 --> 00:15:02,100 Yeah. It it's also extra load on the 402 00:15:02,100 --> 00:15:03,559 device that's sending the BMP. 403 00:15:04,019 --> 00:15:06,919 We we use BMP extensively in my network. 404 00:15:07,139 --> 00:15:08,445 In in the network I work on. It's 405 00:15:08,445 --> 00:15:10,125 not mine, you know, I didn't build. But 406 00:15:10,125 --> 00:15:10,625 anyway, 407 00:15:11,004 --> 00:15:11,504 but, 408 00:15:13,004 --> 00:15:14,705 we do run into issues 409 00:15:15,164 --> 00:15:15,664 with 410 00:15:16,365 --> 00:15:16,865 performance 411 00:15:17,245 --> 00:15:18,304 on both ends, 412 00:15:19,245 --> 00:15:20,384 sending and receiving. 413 00:15:20,829 --> 00:15:22,850 And so we tend to be a bit 414 00:15:22,909 --> 00:15:23,409 careful 415 00:15:24,110 --> 00:15:25,649 about where we use BMP. 416 00:15:26,429 --> 00:15:28,190 And to some degree, I think it's because 417 00:15:28,190 --> 00:15:30,190 of the formatting of BMP. I don't think 418 00:15:30,190 --> 00:15:31,490 BMP is very, 419 00:15:32,589 --> 00:15:34,450 it's it's like what they did 420 00:15:34,904 --> 00:15:35,644 with BGPLS. 421 00:15:36,664 --> 00:15:38,524 Rather than just taking the ISIS 422 00:15:39,304 --> 00:15:39,804 LSA 423 00:15:40,184 --> 00:15:42,284 as the TLV as it exists 424 00:15:42,824 --> 00:15:43,644 and encapsulating 425 00:15:43,945 --> 00:15:45,404 it in an address family, 426 00:15:45,945 --> 00:15:47,464 they said, well, we wanna be able to 427 00:15:47,464 --> 00:15:48,524 use the same 428 00:15:49,370 --> 00:15:49,870 stuff 429 00:15:50,490 --> 00:15:51,389 for both 430 00:15:51,929 --> 00:15:54,809 IS IS and OSPF. So we're gonna invent 431 00:15:54,809 --> 00:15:55,549 a third 432 00:15:56,409 --> 00:15:58,110 LSP or LSA type, 433 00:15:58,809 --> 00:16:00,190 and we're gonna translate 434 00:16:00,730 --> 00:16:04,085 IS IS and OSPF LSAs into that new 435 00:16:04,085 --> 00:16:06,884 standardized type, and we'll carry that as an 436 00:16:06,884 --> 00:16:08,264 address family in BGP. 437 00:16:08,725 --> 00:16:09,465 And, like, 438 00:16:09,845 --> 00:16:11,785 it's brilliant in some sense, 439 00:16:13,445 --> 00:16:16,504 but it's not brilliant from a router load 440 00:16:16,644 --> 00:16:19,940 perspective. Yeah. Right? It's it's it's actually very 441 00:16:19,940 --> 00:16:22,019 hard for the router to process. It'd be 442 00:16:22,019 --> 00:16:24,579 much easier just to encapsulate it. So in 443 00:16:24,579 --> 00:16:26,740 much the same way, I don't remember a 444 00:16:26,740 --> 00:16:28,579 lot about the BMP format, but I do 445 00:16:28,579 --> 00:16:30,500 think it's like that. It's like I have 446 00:16:30,500 --> 00:16:32,659 to take this update I've just received, and 447 00:16:32,659 --> 00:16:34,394 I can't just encapsulate the update. 448 00:16:35,355 --> 00:16:37,675 I have to actually, like, process it. I 449 00:16:37,675 --> 00:16:39,054 have to do something 450 00:16:39,355 --> 00:16:42,095 with it. And then the receiver has to 451 00:16:42,315 --> 00:16:44,575 look at that processed update and go, 452 00:16:44,955 --> 00:16:46,254 oh, that means this. 453 00:16:46,634 --> 00:16:48,235 I've gotta back it out and create a 454 00:16:48,235 --> 00:16:49,774 database out of it again. 455 00:16:50,389 --> 00:16:52,389 So that that I think has always been 456 00:16:52,389 --> 00:16:53,610 an issue with BMP. 457 00:16:54,789 --> 00:16:56,490 Yeah. No. That's exactly right. 458 00:16:58,309 --> 00:17:01,990 So another option would be, I suppose, would 459 00:17:01,990 --> 00:17:04,250 be to ignore no export. 460 00:17:05,085 --> 00:17:07,424 When you're talking to a route view server 461 00:17:07,884 --> 00:17:10,204 Yeah. That's or a looking glass. We we 462 00:17:10,204 --> 00:17:10,704 strongly 463 00:17:11,565 --> 00:17:13,804 recommend it. I think there's sort of two 464 00:17:13,804 --> 00:17:14,865 variants of that. 465 00:17:15,164 --> 00:17:17,484 So one that we propose in the paper 466 00:17:17,484 --> 00:17:19,265 is rewrite no export 467 00:17:19,909 --> 00:17:22,150 at ingress to your entire network. So if 468 00:17:22,150 --> 00:17:24,230 you have an AS and the customer tags 469 00:17:24,230 --> 00:17:24,809 no export, 470 00:17:25,190 --> 00:17:26,569 rewrite that to, 471 00:17:27,029 --> 00:17:28,329 like, my internal 472 00:17:28,789 --> 00:17:30,630 no export, which is just something in your 473 00:17:30,630 --> 00:17:31,690 community space, 474 00:17:32,150 --> 00:17:34,490 and then match on that at your border 475 00:17:34,694 --> 00:17:36,294 so that it behaves the same as no 476 00:17:36,294 --> 00:17:37,274 export. But 477 00:17:37,734 --> 00:17:39,815 if you have a server session with route 478 00:17:39,815 --> 00:17:42,454 views, obviously, ignore that. You know? So now 479 00:17:42,454 --> 00:17:43,194 you avoid 480 00:17:43,654 --> 00:17:45,974 the sort of baked in router behavior of 481 00:17:45,974 --> 00:17:47,194 the well known community, 482 00:17:47,575 --> 00:17:49,339 and then you do it up. I don't 483 00:17:49,339 --> 00:17:50,000 think NetOps 484 00:17:50,299 --> 00:17:51,839 love that either because 485 00:17:52,140 --> 00:17:54,859 now you're talking about filters on maybe hundreds 486 00:17:54,859 --> 00:17:56,400 of customer facing routers. 487 00:17:57,099 --> 00:17:58,940 And then there's a variant of that where 488 00:17:58,940 --> 00:17:59,680 I believe 489 00:18:00,380 --> 00:18:02,539 I'll admit I haven't tried the configs, but 490 00:18:02,539 --> 00:18:04,835 I believe that if you just have say 491 00:18:04,835 --> 00:18:06,674 you have two servers that talk to route 492 00:18:06,674 --> 00:18:08,914 views, I believe at those servers you could 493 00:18:08,914 --> 00:18:11,174 even rewrite the no export on the iBGP 494 00:18:11,795 --> 00:18:14,535 session in and then just do a config 495 00:18:14,595 --> 00:18:15,095 change 496 00:18:15,954 --> 00:18:18,035 at those routers that talk to route you. 497 00:18:18,035 --> 00:18:19,174 So there's possibilities. 498 00:18:21,080 --> 00:18:21,740 I think 499 00:18:22,039 --> 00:18:24,200 largely, you know, a lot of network operators 500 00:18:24,200 --> 00:18:27,160 have expressed, like, these are config changes. They're 501 00:18:27,160 --> 00:18:27,660 happening 502 00:18:28,200 --> 00:18:30,680 to core production routers, and there's kind of 503 00:18:30,680 --> 00:18:31,340 a risk 504 00:18:32,119 --> 00:18:34,355 involved with doing it. 505 00:18:34,815 --> 00:18:37,615 Yeah. Particularly the border one. Yeah. I I 506 00:18:37,615 --> 00:18:39,875 would be very afraid of about overriding 507 00:18:40,174 --> 00:18:42,894 no export on my inbound side. That would 508 00:18:42,894 --> 00:18:45,295 be scary to me because just because it's 509 00:18:45,295 --> 00:18:47,214 very easy for somebody to mess something up. 510 00:18:47,214 --> 00:18:48,595 I'd rather do the opposite. 511 00:18:49,250 --> 00:18:51,170 I'd rather have the router that's peering to 512 00:18:51,170 --> 00:18:52,630 the route view server 513 00:18:53,410 --> 00:18:53,910 say, 514 00:18:54,769 --> 00:18:56,049 I don't have to pay attention to no 515 00:18:56,049 --> 00:18:57,590 export. Yeah. Exactly. 516 00:18:58,369 --> 00:18:59,970 But but I'm not sure how many config 517 00:19:00,049 --> 00:19:02,769 how many routers, like, how many implementations of 518 00:19:02,769 --> 00:19:03,269 BGP 519 00:19:04,275 --> 00:19:06,134 allow you to strip 520 00:19:07,154 --> 00:19:09,654 prefixes on the outbound side 521 00:19:09,955 --> 00:19:13,075 k. Towards an individual peer. Yeah. It gets 522 00:19:13,075 --> 00:19:13,715 a little, like 523 00:19:14,434 --> 00:19:17,154 I think right now, most of the main 524 00:19:17,154 --> 00:19:19,559 configs don't have that. Like, what people I 525 00:19:19,559 --> 00:19:20,539 think are most 526 00:19:21,000 --> 00:19:22,940 acceptable doing is, like, 527 00:19:23,240 --> 00:19:25,240 on the one session they have with route 528 00:19:25,240 --> 00:19:27,099 views, they make a config change 529 00:19:27,640 --> 00:19:30,140 on that one session that says, please ignore 530 00:19:30,200 --> 00:19:31,099 the no export. 531 00:19:31,640 --> 00:19:33,579 And that's, I think, the most sane 532 00:19:34,214 --> 00:19:35,674 config change location. 533 00:19:36,535 --> 00:19:38,375 But when you look at vendor support and 534 00:19:38,375 --> 00:19:39,755 just the way BGP, 535 00:19:40,214 --> 00:19:43,835 you know, BGP community filtering is implemented, 536 00:19:44,454 --> 00:19:46,615 I'm not sure if you're actually able to 537 00:19:46,615 --> 00:19:49,434 make that one config change in that one 538 00:19:49,960 --> 00:19:52,519 localized place. And I've talked to to vendors, 539 00:19:52,519 --> 00:19:54,680 like, would you put consider putting in, like, 540 00:19:54,680 --> 00:19:55,180 a 541 00:19:55,640 --> 00:19:58,360 a monitoring style session so you could just 542 00:19:58,360 --> 00:20:00,039 have a flag that said this session is 543 00:20:00,039 --> 00:20:02,680 monitoring style, and it's going to ignore, you 544 00:20:02,680 --> 00:20:03,500 know, like, 545 00:20:03,894 --> 00:20:05,434 standard no export communities. 546 00:20:06,535 --> 00:20:08,535 And then their response was, well, if a 547 00:20:08,535 --> 00:20:10,394 bunch of networks were doing it already, 548 00:20:10,855 --> 00:20:12,454 we might make their life easier with that 549 00:20:12,454 --> 00:20:14,214 flag, but we're not gonna go out of 550 00:20:14,214 --> 00:20:16,519 our way and develop that flag. So to 551 00:20:16,519 --> 00:20:18,519 me, it feels a little bit like we're 552 00:20:18,519 --> 00:20:19,339 at an impasse, 553 00:20:19,799 --> 00:20:22,460 and yet it seems like the attacks have 554 00:20:22,599 --> 00:20:24,139 potential to do damage. 555 00:20:24,440 --> 00:20:26,279 So I'm kinda wondering, like, where do we 556 00:20:26,279 --> 00:20:26,940 go next? 557 00:20:29,000 --> 00:20:30,700 Yeah. So it is actually 558 00:20:33,555 --> 00:20:35,875 the way that the b b BGP tables 559 00:20:35,875 --> 00:20:37,654 are structured in most implementations, 560 00:20:39,394 --> 00:20:40,775 it is difficult to 561 00:20:42,994 --> 00:20:43,894 strip out 562 00:20:44,355 --> 00:20:46,295 communities on the outbound side, 563 00:20:47,099 --> 00:20:49,819 I would think. That's just my my when 564 00:20:49,819 --> 00:20:51,259 I think about, like, the way if our 565 00:20:51,259 --> 00:20:53,740 routing works, the way iOS works, the way 566 00:20:53,740 --> 00:20:56,140 XR works, and thinking about the code in 567 00:20:56,140 --> 00:20:58,079 my head of how that actually works, 568 00:20:58,859 --> 00:21:00,079 you walk the table. 569 00:21:00,380 --> 00:21:01,279 You say, okay. 570 00:21:01,875 --> 00:21:03,315 A lot of people think you walk the 571 00:21:03,315 --> 00:21:05,494 table based on the prefix first. You don't. 572 00:21:05,875 --> 00:21:07,875 You walk the table from the from the 573 00:21:07,875 --> 00:21:08,855 attribute side, 574 00:21:09,555 --> 00:21:12,195 which is which is very unusual. People don't 575 00:21:12,195 --> 00:21:13,494 think about it in those terms. 576 00:21:15,460 --> 00:21:17,619 Some old implementations, we walk the table based 577 00:21:17,619 --> 00:21:19,700 on the on the prefix side. But a 578 00:21:19,700 --> 00:21:20,839 lot of newer implementations, 579 00:21:21,460 --> 00:21:23,380 you don't walk you walk the table from 580 00:21:23,380 --> 00:21:25,619 the attribute side because what happens is is 581 00:21:25,619 --> 00:21:27,779 you have this separate table of attributes over 582 00:21:27,779 --> 00:21:30,414 here. And this set table of attributes says, 583 00:21:30,474 --> 00:21:31,134 all right. 584 00:21:31,515 --> 00:21:33,215 I have some number of routes 585 00:21:33,674 --> 00:21:34,414 that have 586 00:21:34,955 --> 00:21:36,815 community one, two, and three on them. 587 00:21:37,195 --> 00:21:38,555 So now what I'm gonna do is I'm 588 00:21:38,555 --> 00:21:40,075 gonna start with that group because I'm trying 589 00:21:40,075 --> 00:21:41,809 to build a peer group. Right? I'm trying 590 00:21:41,809 --> 00:21:44,210 to build a single packet that goes to 591 00:21:44,210 --> 00:21:45,190 multiple peers 592 00:21:46,289 --> 00:21:47,970 based on that. So I'm trying to pack 593 00:21:48,049 --> 00:21:49,829 and not only that, I'm trying to pack 594 00:21:50,049 --> 00:21:52,710 as many prefixes onto that set of attributes 595 00:21:52,769 --> 00:21:54,974 as I can. If I walk from the 596 00:21:55,454 --> 00:21:57,454 if I walk my table from the prefix 597 00:21:57,454 --> 00:21:57,954 side, 598 00:21:58,494 --> 00:22:00,414 I have to, like, Okay, this prefix has 599 00:22:00,414 --> 00:22:00,914 community123 600 00:22:01,375 --> 00:22:03,054 on it. Skip it. Go to the next 601 00:22:03,054 --> 00:22:04,575 one. Oh, that one has one, two. Okay. 602 00:22:04,575 --> 00:22:06,414 I can use that one. If I walk 603 00:22:06,414 --> 00:22:09,054 from the attribute side, I can pick the 604 00:22:09,054 --> 00:22:10,275 common sets of attributes 605 00:22:10,950 --> 00:22:13,750 and choose the prefixes that match those, which 606 00:22:13,750 --> 00:22:15,289 allow me to pack the packet. 607 00:22:16,069 --> 00:22:18,809 So I think it's hard to filter because 608 00:22:19,190 --> 00:22:20,789 what you basically have to do is you 609 00:22:20,789 --> 00:22:22,329 have to say, for one neighbor, 610 00:22:23,705 --> 00:22:26,105 I'm going to ignore this attribute when I'm 611 00:22:26,105 --> 00:22:26,605 walking 612 00:22:26,984 --> 00:22:28,924 the attribute table. Right? 613 00:22:29,465 --> 00:22:31,164 That's actually why it's hard. 614 00:22:31,545 --> 00:22:33,484 To me, that's why it would be difficult 615 00:22:33,945 --> 00:22:36,505 to implement it that way. The other idea 616 00:22:36,505 --> 00:22:37,884 of just not paying attention 617 00:22:38,529 --> 00:22:41,029 is actually a better idea of just having 618 00:22:41,809 --> 00:22:43,190 a separate, like, 619 00:22:45,730 --> 00:22:47,569 let's see. Then you have to implement basically 620 00:22:47,569 --> 00:22:48,710 the opposite walk 621 00:22:49,009 --> 00:22:50,690 to do it. So this is why it's 622 00:22:50,690 --> 00:22:51,750 probably hard. 623 00:22:52,365 --> 00:22:54,924 It's almost better to have a dedicated BGP 624 00:22:54,924 --> 00:22:55,424 speaker 625 00:22:55,964 --> 00:22:56,785 that strips 626 00:22:57,644 --> 00:22:59,724 all of the community the no export on 627 00:22:59,724 --> 00:23:01,984 the inbound side of that BGP community 628 00:23:02,285 --> 00:23:05,184 or that community that that internal BGP speaker, 629 00:23:05,404 --> 00:23:07,505 and then peer that BGP speaker 630 00:23:08,029 --> 00:23:10,769 with your routing server. I think that's probably 631 00:23:11,309 --> 00:23:12,789 the way out is that you just have 632 00:23:12,789 --> 00:23:14,929 to have a dedicated BGP speaker 633 00:23:15,230 --> 00:23:17,309 whose job it only is is to talk 634 00:23:17,309 --> 00:23:19,470 to route user risk. Some networks even kind 635 00:23:19,470 --> 00:23:22,375 of have this. And then inbound to that 636 00:23:22,375 --> 00:23:24,394 guy, you do all the filtering processing, 637 00:23:24,934 --> 00:23:27,515 and then that by just runs normal unmodified 638 00:23:27,735 --> 00:23:29,275 BGP to send out 639 00:23:30,215 --> 00:23:32,615 what you need. Yeah. So that probably is 640 00:23:32,615 --> 00:23:34,235 the best way out. 641 00:23:36,190 --> 00:23:36,990 Yeah. That's 642 00:23:37,309 --> 00:23:38,990 that is probably gonna be the best way 643 00:23:38,990 --> 00:23:40,509 out. Even though it is I mean, it 644 00:23:40,509 --> 00:23:42,430 is you have to throw a piece of 645 00:23:42,430 --> 00:23:43,890 software at it, basically. 646 00:23:44,990 --> 00:23:47,009 Yeah. You you have to throw a a 647 00:23:47,549 --> 00:23:49,250 a, you know, a software router. 648 00:23:49,804 --> 00:23:51,424 If our routing bird something 649 00:23:51,724 --> 00:23:53,884 running on a VM, it's gonna pull all 650 00:23:53,884 --> 00:23:56,204 that data in. And it's gotta peer with 651 00:23:56,204 --> 00:23:57,644 a lot of peer with a lot of 652 00:23:57,644 --> 00:23:58,625 BGP speakers 653 00:23:59,404 --> 00:24:00,304 inside your network. 654 00:24:01,404 --> 00:24:02,625 Potentially. Yeah. 655 00:24:03,849 --> 00:24:06,009 Yeah. I mean, like, with me, I don't 656 00:24:06,009 --> 00:24:07,149 know. We have 657 00:24:07,690 --> 00:24:09,950 probably 10,000 eBGP speakers. 658 00:24:10,250 --> 00:24:12,169 It's probably more than that, but it's it's 659 00:24:12,169 --> 00:24:13,069 at least that. 660 00:24:13,369 --> 00:24:15,210 And so how would I do that? I 661 00:24:15,210 --> 00:24:16,750 have to actually build a hierarchical 662 00:24:18,194 --> 00:24:20,515 thing of BGP speakers that bring me all 663 00:24:20,515 --> 00:24:22,294 the way from the edge up to one 664 00:24:22,674 --> 00:24:24,434 or several boxes that talk to route view 665 00:24:24,434 --> 00:24:26,034 servers. So I see how this is really 666 00:24:26,034 --> 00:24:27,954 hard to get around. This is making a 667 00:24:27,954 --> 00:24:29,095 lot of sense that 668 00:24:29,634 --> 00:24:31,734 this is not an easy problem to solve. 669 00:24:32,809 --> 00:24:33,869 In all honesty, 670 00:24:34,330 --> 00:24:36,650 this is actually not an easy problem to 671 00:24:36,650 --> 00:24:37,150 solve. 672 00:24:38,410 --> 00:24:41,369 So my my my question though is if 673 00:24:41,369 --> 00:24:43,609 the processing of no export is an issue 674 00:24:43,609 --> 00:24:46,714 because it's hiding it's hiding these bad actors, 675 00:24:47,335 --> 00:24:49,755 the methodology you're using to make that statement, 676 00:24:50,615 --> 00:24:53,174 why why can't that be used to detect 677 00:24:53,335 --> 00:24:54,934 like, if you can detect that they're that 678 00:24:54,934 --> 00:24:57,035 they're being stealthy, then they're not being stealthy. 679 00:24:57,335 --> 00:24:58,875 Right. So the the thing is, 680 00:24:59,320 --> 00:25:01,799 as of yet, fingers crossed, we don't know 681 00:25:01,799 --> 00:25:03,820 of a specific no actor 682 00:25:04,200 --> 00:25:05,980 using the stealthy attack technique. 683 00:25:06,599 --> 00:25:08,680 What I do to confirm, because I've launched 684 00:25:08,680 --> 00:25:11,160 these attacks several times, in the wild in 685 00:25:11,160 --> 00:25:13,400 an ethical manner, is I log into the 686 00:25:13,400 --> 00:25:15,535 network's looking glass. So, So, like, 687 00:25:16,255 --> 00:25:18,335 I can put a route into Cogent or 688 00:25:18,335 --> 00:25:18,835 NTT, 689 00:25:19,615 --> 00:25:22,095 and I can see Cogent and not send 690 00:25:22,095 --> 00:25:24,734 that over their session to right route views 691 00:25:24,734 --> 00:25:27,055 risk even though they're sending everything else. And 692 00:25:27,055 --> 00:25:28,894 then I go to Cogent Looking Glass, which 693 00:25:28,894 --> 00:25:30,355 is essentially just a router 694 00:25:30,750 --> 00:25:32,930 telnet login behind a web interface, 695 00:25:33,549 --> 00:25:35,150 and I type in and then sure enough, 696 00:25:35,150 --> 00:25:37,070 there's the prefix in the table. So that's 697 00:25:37,070 --> 00:25:38,450 how I detect them. 698 00:25:39,070 --> 00:25:41,309 But I personally believe that if there was 699 00:25:41,309 --> 00:25:44,029 an attack, like, what are the odds that 700 00:25:44,029 --> 00:25:44,769 said victim's 701 00:25:45,150 --> 00:25:48,255 hobby is logging into Cogent Looking Glass for 702 00:25:48,255 --> 00:25:49,794 their routes every ten minutes. 703 00:25:50,095 --> 00:25:51,934 You know? It needs to go through the 704 00:25:51,934 --> 00:25:54,734 existing pipelines and then process in this sort 705 00:25:54,734 --> 00:25:55,394 of automated 706 00:25:56,015 --> 00:25:58,335 manner that all these companies and services are 707 00:25:58,335 --> 00:26:01,470 consuming the public BGP updates and announcing, you 708 00:26:01,470 --> 00:26:04,049 know, alerts and notifications on them. 709 00:26:04,430 --> 00:26:05,789 But, yeah, the I think the thing to 710 00:26:05,950 --> 00:26:07,870 the answer to that would be we don't 711 00:26:07,870 --> 00:26:10,110 know. Like, if someone did this, we would 712 00:26:10,110 --> 00:26:10,850 not know. 713 00:26:11,390 --> 00:26:13,150 Well, and there and there's another way to 714 00:26:13,150 --> 00:26:15,934 think of this in so so it's the 715 00:26:15,934 --> 00:26:18,255 it's the presence and absence of routes that 716 00:26:18,255 --> 00:26:20,914 is tipping you off to a condition that 717 00:26:21,215 --> 00:26:22,994 could be leveraged against someone. 718 00:26:24,414 --> 00:26:24,914 I 719 00:26:25,615 --> 00:26:27,375 at some point, we will probably have to 720 00:26:27,375 --> 00:26:30,340 move beyond current thinking in how we validate 721 00:26:30,640 --> 00:26:32,660 a given BGP control plans. 722 00:26:34,480 --> 00:26:34,980 It's, 723 00:26:35,519 --> 00:26:37,519 fit fit for like, that is doing what 724 00:26:37,519 --> 00:26:39,680 it needs to do in operational state in 725 00:26:39,680 --> 00:26:41,840 the network. Right? So if and I'm not 726 00:26:41,840 --> 00:26:43,680 I'm not saying any particular tool is the 727 00:26:43,680 --> 00:26:45,794 answer, but it seems like there are there's 728 00:26:45,794 --> 00:26:48,515 another there's an entire category of issues that 729 00:26:48,515 --> 00:26:50,595 could be detected if you were to if 730 00:26:50,595 --> 00:26:51,815 we were to move beyond, 731 00:26:52,755 --> 00:26:55,315 BMP and route views. If you were to 732 00:26:55,315 --> 00:26:56,775 take a look at the system holistically, 733 00:26:57,960 --> 00:27:00,359 you know, download tables, do consistency checking, like, 734 00:27:00,359 --> 00:27:02,119 you wouldn't find just this. You'd find that 735 00:27:02,200 --> 00:27:04,279 you'd find other things too. Completely. Yeah. They're 736 00:27:04,279 --> 00:27:06,839 just like there are control plane behaviors that 737 00:27:06,839 --> 00:27:08,940 you probably never want to see 738 00:27:09,319 --> 00:27:12,859 in a sane, well defined, well operating network, 739 00:27:13,285 --> 00:27:15,605 and you will only see those control plane 740 00:27:15,605 --> 00:27:16,984 behaviors if you 741 00:27:17,365 --> 00:27:18,105 have magically 742 00:27:18,484 --> 00:27:22,424 had visibility into every router's control plane state 743 00:27:22,884 --> 00:27:24,025 and peering relationships. 744 00:27:24,644 --> 00:27:27,444 And even the best research were miles from 745 00:27:27,444 --> 00:27:29,279 that and probably for good reason. You know, 746 00:27:29,279 --> 00:27:30,179 I think companies 747 00:27:30,640 --> 00:27:32,500 have the right to keep their routes hidden 748 00:27:32,799 --> 00:27:35,279 and some amount of their architecture behind closed 749 00:27:35,279 --> 00:27:35,779 doors. 750 00:27:36,559 --> 00:27:38,480 Well and and the the the thing that 751 00:27:38,480 --> 00:27:40,605 lead that led us to the maybe we 752 00:27:40,605 --> 00:27:43,924 need a hierarchical set of of instrumentation routers 753 00:27:43,924 --> 00:27:45,605 to give, you know, to give it some 754 00:27:45,605 --> 00:27:48,164 some sort of name, to let us instrument 755 00:27:48,164 --> 00:27:49,605 our network just for the purpose of analyzing 756 00:27:49,605 --> 00:27:50,105 tables. 757 00:27:50,404 --> 00:27:52,484 If that's where it leads anyway, then that 758 00:27:52,484 --> 00:27:54,664 same infrastructure could be used to do 759 00:27:55,089 --> 00:27:57,109 a lot more sophisticated analysis 760 00:27:57,730 --> 00:28:00,049 of the network anyway. Right? So maybe this 761 00:28:00,049 --> 00:28:01,909 leads us to a to a good place. 762 00:28:02,289 --> 00:28:03,889 That would be kinda neat. Yeah. I think 763 00:28:03,889 --> 00:28:06,230 I think more clean separation of, 764 00:28:06,815 --> 00:28:08,894 you know, what should be public and then 765 00:28:08,894 --> 00:28:10,575 what should be private and, like, can you 766 00:28:10,575 --> 00:28:12,035 have a router that's for 767 00:28:12,575 --> 00:28:13,075 instrumentation 768 00:28:14,015 --> 00:28:17,234 purposes? I think some network architects are moving 769 00:28:17,855 --> 00:28:20,570 in that direction, but once again, like, the 770 00:28:20,570 --> 00:28:22,349 majority of network architectures 771 00:28:23,130 --> 00:28:24,970 don't think, like, well, we should have a 772 00:28:24,970 --> 00:28:27,690 router that just sits there for the purpose 773 00:28:27,690 --> 00:28:29,630 of establishing public data. 774 00:28:30,490 --> 00:28:31,529 It's it's kind of, 775 00:28:32,605 --> 00:28:34,845 it's kind of like remotely triggered black holes. 776 00:28:34,845 --> 00:28:37,184 That that that's more for enforcing policy, 777 00:28:37,644 --> 00:28:40,284 enforcing policy in an entire BGP domain. But 778 00:28:40,284 --> 00:28:42,845 taking that that same approach and saying, well, 779 00:28:42,845 --> 00:28:44,865 we've been operating RTBH forever. 780 00:28:45,620 --> 00:28:47,860 What if RTVH could actually tell you something, 781 00:28:48,180 --> 00:28:49,779 interesting rather than just giving you a way 782 00:28:49,779 --> 00:28:51,559 to enforce policy globally instantly? 783 00:28:51,940 --> 00:28:53,080 What if you could understand, 784 00:28:53,860 --> 00:28:56,740 control plane globally instantly through that same through 785 00:28:56,740 --> 00:28:57,880 the same type of mechanism? 786 00:28:58,580 --> 00:28:59,080 Yeah. 787 00:28:59,704 --> 00:29:01,865 Yeah. That that actually would be really cool. 788 00:29:01,865 --> 00:29:03,484 It's it would be a really great 789 00:29:04,025 --> 00:29:05,945 way to do just being able to gather 790 00:29:05,945 --> 00:29:08,445 the information and see this happening 791 00:29:10,105 --> 00:29:11,164 is is actually 792 00:29:11,990 --> 00:29:14,090 even if you even if, as a provider, 793 00:29:15,350 --> 00:29:17,029 you just tagged every route that came to 794 00:29:17,029 --> 00:29:18,090 you as no export. 795 00:29:19,509 --> 00:29:20,570 And you said, 796 00:29:21,110 --> 00:29:23,110 I'm going to have a script that when 797 00:29:23,110 --> 00:29:24,730 you when I see a no export, 798 00:29:26,295 --> 00:29:27,734 well, I guess it would never show up 799 00:29:27,734 --> 00:29:29,275 in the Raview server. Right? 800 00:29:29,894 --> 00:29:32,634 But in that case, like, maybe I should 801 00:29:32,695 --> 00:29:35,914 investigate that and make sure that it's valid. 802 00:29:36,055 --> 00:29:39,115 Right? So one recommendation we've gotten is, like, 803 00:29:39,630 --> 00:29:40,130 maybe 804 00:29:40,589 --> 00:29:42,990 no export should be something a customer has 805 00:29:42,990 --> 00:29:44,049 to explicitly 806 00:29:44,910 --> 00:29:48,430 turn on with a valid, like, use case 807 00:29:48,430 --> 00:29:49,490 and if you at least 808 00:29:49,789 --> 00:29:52,049 reduce the volume of customers that can 809 00:29:52,565 --> 00:29:54,404 can do it. You know? So, like, imagine, 810 00:29:54,404 --> 00:29:56,724 like, a lot of, sessions are spun up 811 00:29:56,724 --> 00:29:59,065 largely with interactions with the sales team. 812 00:29:59,525 --> 00:30:01,625 And, you know, I have heard some 813 00:30:02,164 --> 00:30:04,644 statements out of networks that the sales teams 814 00:30:04,644 --> 00:30:06,744 are quite eager to spin up new connections. 815 00:30:07,769 --> 00:30:10,410 Maybe somewhat the security teams wish they'd be 816 00:30:10,410 --> 00:30:11,390 a little more hesitant. 817 00:30:11,850 --> 00:30:13,769 But then maybe something like no expert should 818 00:30:13,769 --> 00:30:15,789 be seen as a security critical 819 00:30:16,570 --> 00:30:18,970 piece of functionality and should trigger sort of 820 00:30:18,970 --> 00:30:19,710 more in-depth 821 00:30:20,250 --> 00:30:22,269 vetting. So I've I've sort of heard 822 00:30:22,845 --> 00:30:23,345 that 823 00:30:26,045 --> 00:30:26,545 recommendation. 824 00:30:27,804 --> 00:30:29,644 Yeah. And I like, if someone's giving you 825 00:30:29,644 --> 00:30:31,825 no export, like, why are they 826 00:30:32,365 --> 00:30:34,525 doing Well, I'll tell you this is gonna 827 00:30:34,525 --> 00:30:35,585 become more common. 828 00:30:36,259 --> 00:30:38,099 I believe no export is gonna become more 829 00:30:38,099 --> 00:30:40,279 common. No advertise is as well 830 00:30:41,139 --> 00:30:42,679 because of Unicast RPF. 831 00:30:43,380 --> 00:30:46,259 Oh, yeah. I get that. Because be because 832 00:30:46,259 --> 00:30:49,399 if my upstream is is enforcing Unicast RPF, 833 00:30:50,785 --> 00:30:52,384 that's fine. That's cool. It's a good thing. 834 00:30:52,384 --> 00:30:54,224 It's not a bad thing to enforce unicast 835 00:30:54,224 --> 00:30:57,184 RPF. But if I'm dual honed, it leaves 836 00:30:57,184 --> 00:30:59,505 me in the position of one of my 837 00:30:59,505 --> 00:31:00,724 connections being 838 00:31:01,184 --> 00:31:02,724 toast. Yep. Right? 839 00:31:03,329 --> 00:31:04,929 Because they're only gonna choose one of my 840 00:31:04,929 --> 00:31:07,250 two connections. That's fine. So now what do 841 00:31:07,250 --> 00:31:07,829 I do? 842 00:31:08,210 --> 00:31:09,490 Well, I'll tell you what I do. I 843 00:31:09,490 --> 00:31:11,650 advertise my route with no export or no 844 00:31:11,650 --> 00:31:12,150 advertise, 845 00:31:12,609 --> 00:31:15,009 preferably no advertise, by the way. Not not 846 00:31:15,009 --> 00:31:17,835 not no export. Right? I prefer no advertise 847 00:31:17,835 --> 00:31:19,695 in the case of of Unicast RBF. 848 00:31:20,394 --> 00:31:22,875 But some people will be, I'll just use 849 00:31:22,875 --> 00:31:24,555 no export. Right? They don't even know about 850 00:31:24,555 --> 00:31:26,734 no advertise or whatever the case might be. 851 00:31:27,914 --> 00:31:29,855 Because if I advertise with no advertise, 852 00:31:30,250 --> 00:31:33,069 I'm actually not changing the upstream provider's 853 00:31:33,450 --> 00:31:34,509 best path selection. 854 00:31:35,849 --> 00:31:38,169 All I'm doing is I'm allowing traffic from 855 00:31:38,169 --> 00:31:39,390 my side of the network 856 00:31:40,650 --> 00:31:43,130 to upstream through a path that would normally 857 00:31:43,130 --> 00:31:45,345 be dropped because of unicast r p f. 858 00:31:45,505 --> 00:31:46,724 It allows me to 859 00:31:47,184 --> 00:31:47,765 do asymmetric 860 00:31:48,224 --> 00:31:48,724 pathing 861 00:31:49,984 --> 00:31:52,784 without modifying what the provider is normally doing, 862 00:31:52,784 --> 00:31:54,244 how the provider works. 863 00:31:55,025 --> 00:31:57,505 No export can actually modify what the provider's 864 00:31:57,505 --> 00:31:58,740 best path is. Right? 865 00:31:59,140 --> 00:32:00,660 But a lot of people will be like, 866 00:32:00,660 --> 00:32:02,440 let's just do do a no export. 867 00:32:03,619 --> 00:32:05,220 It's it's gonna be all over the place. 868 00:32:05,220 --> 00:32:07,460 Yeah. Actually, I I I admit I've used 869 00:32:07,460 --> 00:32:10,500 that very configuration. I have, like, global nodes 870 00:32:10,500 --> 00:32:12,279 that are essentially any cast 871 00:32:12,615 --> 00:32:14,855 and then have one node that I need 872 00:32:14,855 --> 00:32:17,434 to send the packets from. I don't necessarily 873 00:32:17,494 --> 00:32:19,494 need to receive packets at that node, but 874 00:32:19,494 --> 00:32:21,434 I wanna send packets to my 875 00:32:21,815 --> 00:32:25,095 anycast service that I'm dynamically modifying all the 876 00:32:25,095 --> 00:32:27,009 time. So what what do I do? I 877 00:32:27,009 --> 00:32:28,849 just write a BGP config that tells my 878 00:32:28,849 --> 00:32:31,570 upstream, don't export this announcement, but I'm giving 879 00:32:31,570 --> 00:32:32,309 it to you 880 00:32:32,769 --> 00:32:34,869 just so I can get past your unicast 881 00:32:35,009 --> 00:32:35,830 RPF filter. 882 00:32:37,009 --> 00:32:38,869 Correct. There's even an RFC 883 00:32:39,170 --> 00:32:41,774 suggesting to do this. Okay. I'm glad the 884 00:32:41,774 --> 00:32:42,994 RFC people agree. 885 00:32:43,855 --> 00:32:45,855 So so there so but I do believe 886 00:32:45,855 --> 00:32:48,575 that RFC uses no advertise, not no export. 887 00:32:48,575 --> 00:32:49,234 But, nonetheless, 888 00:32:49,934 --> 00:32:53,315 I can tell you of several major anycast 889 00:32:53,375 --> 00:32:53,875 providers 890 00:32:54,950 --> 00:32:56,089 that are either 891 00:32:56,390 --> 00:32:58,970 in plans to do it or already are 892 00:32:59,269 --> 00:33:01,529 advertising a % of their routes. 893 00:33:02,390 --> 00:33:04,069 Yeah. Actually, I do get this because and 894 00:33:04,069 --> 00:33:06,569 then Anycast cashment is a very dynamic 895 00:33:07,054 --> 00:33:09,054 sort of ever changing problem. So you can 896 00:33:09,054 --> 00:33:11,934 imagine there's two sides to this. There's how 897 00:33:11,934 --> 00:33:14,095 do I want to strategically route traffic that 898 00:33:14,095 --> 00:33:15,634 is inbound to my network 899 00:33:16,174 --> 00:33:18,015 at my global set of nodes. And it 900 00:33:18,015 --> 00:33:20,015 turns out you will get better routing by 901 00:33:20,015 --> 00:33:22,509 turning some of those nodes off because some 902 00:33:22,509 --> 00:33:24,769 nodes just have longer routes, slower routes, whatever. 903 00:33:25,470 --> 00:33:27,470 And then some of these networks, those are, 904 00:33:27,470 --> 00:33:29,869 like, globally connected data centers, so you don't 905 00:33:29,869 --> 00:33:31,950 know where that traffic's gonna egress. So if 906 00:33:31,950 --> 00:33:34,644 I was operating in any cast network, I 907 00:33:34,644 --> 00:33:36,644 would personally definitely do it. I'd just say 908 00:33:36,644 --> 00:33:38,345 every node can egress everything, 909 00:33:38,724 --> 00:33:41,444 just gonna double tables of no advertised so 910 00:33:41,444 --> 00:33:43,444 I never get hit by that, and then 911 00:33:43,444 --> 00:33:46,404 my ingress, I'm gonna traffic engineer dynamically, you 912 00:33:46,404 --> 00:33:46,904 know, 913 00:33:47,359 --> 00:33:49,759 So Yep. The best that I can. Yeah. 914 00:33:49,759 --> 00:33:51,759 I mean, you can't advertise everything with no 915 00:33:51,759 --> 00:33:52,660 export. Right? 916 00:33:52,960 --> 00:33:55,200 But you're gonna ingress what you're actually gonna 917 00:33:55,200 --> 00:33:57,059 do is you're gonna ingress traffic 918 00:33:57,440 --> 00:33:57,940 engineer 919 00:33:58,400 --> 00:34:00,880 by advertising everything with no export or no 920 00:34:00,880 --> 00:34:01,380 advertise. 921 00:34:02,085 --> 00:34:05,044 And then you're going to measure your inbound 922 00:34:05,044 --> 00:34:07,285 load and say, oh, this data center or 923 00:34:07,285 --> 00:34:09,764 this entrance point has lower load than I 924 00:34:09,764 --> 00:34:10,505 would like. 925 00:34:11,525 --> 00:34:13,625 So I'm gonna take no export, no advertise 926 00:34:14,244 --> 00:34:15,224 off of that. 927 00:34:16,130 --> 00:34:18,769 Right? Yep. Yep. Which then allows me to 928 00:34:18,769 --> 00:34:21,890 be very precise, not precise, but more precise 929 00:34:21,890 --> 00:34:23,110 than many other ways 930 00:34:23,489 --> 00:34:25,510 of doing inbound load management 931 00:34:26,369 --> 00:34:28,769 using no export, no advertise. That's a very 932 00:34:28,769 --> 00:34:30,070 smart way of doing it. 933 00:34:30,625 --> 00:34:32,385 Yeah. So that so the so it's gonna 934 00:34:32,385 --> 00:34:34,625 become more common. So it's gonna become more 935 00:34:34,625 --> 00:34:36,005 of an issue in detecting 936 00:34:36,465 --> 00:34:37,585 the stealth attacks 937 00:34:37,905 --> 00:34:38,405 Yeah. 938 00:34:38,945 --> 00:34:41,425 As people use those tools to get around 939 00:34:41,505 --> 00:34:43,505 So this is an existing tool that's well 940 00:34:43,505 --> 00:34:45,800 established for customers to use, and I've actually 941 00:34:45,800 --> 00:34:47,340 seen adversaries that 942 00:34:47,719 --> 00:34:50,780 pose as mid tier hosting providers that 943 00:34:51,320 --> 00:34:53,559 only reasonably be doing this type of thing. 944 00:34:53,559 --> 00:34:56,139 So this is a completely reasonable legitimate behavior. 945 00:34:56,760 --> 00:34:58,920 Then if there's an adversarial dimension when I 946 00:34:58,920 --> 00:35:01,644 announce my victim's prefix with no export 947 00:35:02,344 --> 00:35:04,344 and that stops it from going to monitoring, 948 00:35:04,344 --> 00:35:06,184 I I personally see it as a fairly 949 00:35:06,184 --> 00:35:07,005 large problem. 950 00:35:07,385 --> 00:35:09,144 But as I said, I'm still trying to 951 00:35:09,144 --> 00:35:10,925 understand, like, what is the 952 00:35:11,799 --> 00:35:12,940 thing to do today 953 00:35:13,799 --> 00:35:14,539 for operators? 954 00:35:14,920 --> 00:35:16,519 And then if there is no thing to 955 00:35:16,519 --> 00:35:17,819 do today, 956 00:35:18,199 --> 00:35:20,279 I guess, to me, it brings into question, 957 00:35:20,279 --> 00:35:20,779 like, 958 00:35:21,079 --> 00:35:22,619 what is the monitoring infrastructure 959 00:35:22,920 --> 00:35:24,859 for? Is monitoring, like, a sustainable, 960 00:35:26,474 --> 00:35:29,195 reasonable way of doing BGP security? Because it's 961 00:35:29,195 --> 00:35:31,035 really emerged, I'd say, almost as, like, a 962 00:35:31,035 --> 00:35:31,775 fan favorite 963 00:35:32,315 --> 00:35:33,215 in the space. 964 00:35:34,635 --> 00:35:35,695 Yeah. Yeah. 965 00:35:37,195 --> 00:35:39,295 Yeah. And and until you know 966 00:35:40,119 --> 00:35:42,280 how prevalent this is, it's hard to know 967 00:35:42,280 --> 00:35:43,500 the answer to that question. 968 00:35:44,359 --> 00:35:45,960 But you don't know how prevalent it is 969 00:35:45,960 --> 00:35:48,199 because you can't detect it today. Yeah. Right? 970 00:35:48,199 --> 00:35:49,420 It's like this whole, 971 00:35:51,894 --> 00:35:54,454 circular, like Exactly. Yeah. That's the thing that 972 00:35:54,454 --> 00:35:56,215 scares me a lot also. Like, I work 973 00:35:56,215 --> 00:35:58,454 with threat intelligence as well where we're digging 974 00:35:58,454 --> 00:35:58,954 through 975 00:35:59,335 --> 00:36:02,155 BGP logs from months ago or years ago, 976 00:36:02,535 --> 00:36:06,155 correlating those with attack announcements and the certificate 977 00:36:06,375 --> 00:36:06,875 logs, 978 00:36:07,250 --> 00:36:09,750 and we're trying to piece back together the 979 00:36:10,130 --> 00:36:12,690 chain of events that some adversary used. And 980 00:36:12,690 --> 00:36:14,929 if you get rid of that BGP log, 981 00:36:14,929 --> 00:36:17,010 like, it's not just the, oh, I didn't 982 00:36:17,010 --> 00:36:18,530 detect it today. It's like there is no 983 00:36:18,530 --> 00:36:19,829 historical record. 984 00:36:20,244 --> 00:36:22,724 Because after those that attack is over, if 985 00:36:22,724 --> 00:36:24,405 it's not in route user risk, we have 986 00:36:24,405 --> 00:36:25,844 nothing to go on point to and say, 987 00:36:25,844 --> 00:36:26,664 like, we 988 00:36:27,284 --> 00:36:29,704 got it. So it's sort of just invisible 989 00:36:29,844 --> 00:36:30,344 forever. 990 00:36:33,339 --> 00:36:35,280 Yeah. This yeah. This is actually 991 00:36:35,820 --> 00:36:37,739 a major problem that that now that I'm 992 00:36:37,739 --> 00:36:39,339 starting to think through, like, all the different, 993 00:36:39,339 --> 00:36:41,199 like, how do you 994 00:36:42,619 --> 00:36:43,359 do this? 995 00:36:43,739 --> 00:36:45,760 How do you like, this is hard. 996 00:36:46,894 --> 00:36:48,974 And so, yeah, this is this is very 997 00:36:48,974 --> 00:36:50,755 interesting. This is a very interesting paper. 998 00:36:51,295 --> 00:36:52,755 Thanks. I appreciate that. 999 00:36:54,574 --> 00:36:56,594 So I don't have anything else to 1000 00:36:57,375 --> 00:36:59,454 I don't have any other directions to go. 1001 00:36:59,454 --> 00:37:00,105 I'm kind of 1002 00:37:01,989 --> 00:37:02,650 It's Friday. 1003 00:37:03,030 --> 00:37:04,869 It's Friday. Yeah. I'm kind of out of 1004 00:37:04,869 --> 00:37:06,010 directions on this. 1005 00:37:06,390 --> 00:37:08,969 But it is really interesting, and it is 1006 00:37:09,110 --> 00:37:10,469 I'm gonna have to go back and read 1007 00:37:10,469 --> 00:37:11,989 the paper and share it around with some 1008 00:37:11,989 --> 00:37:12,489 folks 1009 00:37:12,869 --> 00:37:14,329 in the BGP world 1010 00:37:14,869 --> 00:37:17,894 and figure out, like, what we do or 1011 00:37:17,894 --> 00:37:19,195 how we think about this. 1012 00:37:19,815 --> 00:37:21,655 I'm not so deeply involved in the IETF 1013 00:37:21,655 --> 00:37:22,875 anymore just because of 1014 00:37:23,255 --> 00:37:24,715 where I am now, but 1015 00:37:25,095 --> 00:37:26,855 this is a this is a major problem 1016 00:37:26,855 --> 00:37:28,614 or a major thing that that needs to 1017 00:37:28,614 --> 00:37:30,539 be thought about. So Thank you. I'll try 1018 00:37:30,539 --> 00:37:32,006 to spend some time I will bring a 1019 00:37:32,059 --> 00:37:34,380 about it. Just with remaining time, I'll bring 1020 00:37:34,380 --> 00:37:36,619 attention to one proposed solution I've heard a 1021 00:37:36,619 --> 00:37:39,500 bunch of, which is IVG sessions. So you 1022 00:37:39,500 --> 00:37:40,880 imagine RIPE risk. 1023 00:37:41,260 --> 00:37:42,960 Right now, it's an eBGP session. 1024 00:37:43,755 --> 00:37:44,255 Kentech, 1025 00:37:44,795 --> 00:37:45,934 and several other 1026 00:37:46,394 --> 00:37:47,454 private monitoring 1027 00:37:47,755 --> 00:37:48,255 services, 1028 00:37:48,875 --> 00:37:51,994 they use iBGP sessions. So they're the, you 1029 00:37:51,994 --> 00:37:55,034 know, the monitoring service router instead of peering 1030 00:37:55,034 --> 00:37:57,694 as an external peer peers as an iBGP 1031 00:37:57,914 --> 00:37:58,414 peer. 1032 00:37:58,769 --> 00:38:00,449 Looks like they're part of your AS, and 1033 00:38:00,449 --> 00:38:03,090 they just run the session open, you know, 1034 00:38:03,090 --> 00:38:04,710 with that customer's ASN. 1035 00:38:05,250 --> 00:38:06,150 So that 1036 00:38:06,610 --> 00:38:09,329 seemingly immediately solves the problem. But once again, 1037 00:38:09,329 --> 00:38:10,610 we kind of go back to this idea 1038 00:38:10,610 --> 00:38:13,010 of, like, it's actually a trust boundary between 1039 00:38:13,010 --> 00:38:13,750 your network 1040 00:38:14,075 --> 00:38:14,894 and the external provider. 1041 00:38:15,355 --> 00:38:17,855 And when Kentek and these other commercial 1042 00:38:18,474 --> 00:38:20,735 offerings establish that iBGP peering, 1043 00:38:21,195 --> 00:38:23,275 my suspicion, and I have some data to 1044 00:38:23,275 --> 00:38:24,494 back this up, is that 1045 00:38:24,795 --> 00:38:27,855 that's done on the grounds that that secret 1046 00:38:28,409 --> 00:38:30,089 I b g p data is not gonna 1047 00:38:30,089 --> 00:38:30,589 leave 1048 00:38:31,049 --> 00:38:33,289 Kentek. Like, it's going to Kentek for the 1049 00:38:33,289 --> 00:38:36,010 use of your net ops team to query 1050 00:38:36,010 --> 00:38:38,030 Kentek for what your routes look like. 1051 00:38:38,489 --> 00:38:40,650 When I talk to network operators, like, when 1052 00:38:40,650 --> 00:38:42,329 you do I b g p with Bright 1053 00:38:42,329 --> 00:38:43,869 Brist, they're sort of like, 1054 00:38:44,344 --> 00:38:44,844 no. 1055 00:38:45,304 --> 00:38:47,224 Like, my I b g p feed might 1056 00:38:47,224 --> 00:38:49,065 leak more than my e b g p. 1057 00:38:49,065 --> 00:38:50,264 I know I'll do e b g p 1058 00:38:50,264 --> 00:38:52,424 with them because that's the same config I 1059 00:38:52,424 --> 00:38:54,505 would give any customer that signs up to 1060 00:38:54,505 --> 00:38:55,164 my network. 1061 00:38:55,704 --> 00:38:57,304 I don't know how I feel about doing 1062 00:38:57,304 --> 00:38:59,304 I b g p because that might leak 1063 00:38:59,304 --> 00:39:01,639 more next next hop info or internal network 1064 00:39:01,639 --> 00:39:02,139 architecture. 1065 00:39:03,319 --> 00:39:05,799 It leaks it leaks internal network architecture all 1066 00:39:05,799 --> 00:39:07,819 over the place in most in most providers. 1067 00:39:08,839 --> 00:39:10,139 That's just and particularly, 1068 00:39:10,599 --> 00:39:13,159 by the way, because we use BGP on 1069 00:39:13,159 --> 00:39:15,099 data centers, fabrics now. Oh. 1070 00:39:16,094 --> 00:39:16,755 Right? So 1071 00:39:17,534 --> 00:39:18,034 so 1072 00:39:18,655 --> 00:39:19,715 it's one thing 1073 00:39:20,494 --> 00:39:21,315 to leak 1074 00:39:22,255 --> 00:39:24,734 the workloads attached to my data center fabric, 1075 00:39:24,734 --> 00:39:26,414 perhaps. You may not even wanna do that 1076 00:39:26,414 --> 00:39:28,114 because a lot of those are internal workloads. 1077 00:39:29,019 --> 00:39:31,680 But to even leak my data center fabric 1078 00:39:32,220 --> 00:39:32,720 infrastructure 1079 00:39:34,460 --> 00:39:34,960 networks 1080 00:39:35,739 --> 00:39:36,640 via iBGP. 1081 00:39:37,019 --> 00:39:39,340 Now, theoretically, that stuff should be filtered at 1082 00:39:39,340 --> 00:39:41,180 the edge of my data center fabric. I 1083 00:39:41,180 --> 00:39:44,695 got that. But, nonetheless, things happen. Right? And 1084 00:39:44,695 --> 00:39:46,375 that's this is this is where people get 1085 00:39:46,375 --> 00:39:49,815 nervous. And I understand the nervous. But, yeah, 1086 00:39:49,815 --> 00:39:51,974 it it it is still a problem. Right? 1087 00:39:51,974 --> 00:39:54,454 It's still another avenue that seems Well, it's 1088 00:39:54,454 --> 00:39:56,375 like there are several options or things you 1089 00:39:56,375 --> 00:39:58,519 could do, but all of them, I think, 1090 00:39:58,519 --> 00:40:01,159 put a large amount of risk onto the 1091 00:40:01,159 --> 00:40:02,920 network operators that would have to go and 1092 00:40:02,920 --> 00:40:04,139 then make those changes. 1093 00:40:04,440 --> 00:40:06,119 And and it's the type of risk that 1094 00:40:06,119 --> 00:40:08,199 if something bad were to happen, you wouldn't 1095 00:40:08,199 --> 00:40:10,664 wanna have to go to your your boss, 1096 00:40:10,664 --> 00:40:12,824 you know, a CSO at the company and 1097 00:40:12,824 --> 00:40:14,505 say, well, yeah, we just dumped a bunch 1098 00:40:14,505 --> 00:40:15,644 of personal information. 1099 00:40:16,344 --> 00:40:19,065 It's because we're trying to eliminate this attack 1100 00:40:19,065 --> 00:40:21,085 vector that no one can even measure anyways. 1101 00:40:21,465 --> 00:40:23,644 You know? So it just doesn't look good. 1102 00:40:25,119 --> 00:40:26,179 Yeah. Yeah. 1103 00:40:28,320 --> 00:40:30,420 Very interesting. Cool. Alright. 1104 00:40:30,880 --> 00:40:32,880 So anything else you wanna talk about before 1105 00:40:32,880 --> 00:40:34,179 we wrap up? And, 1106 00:40:35,920 --> 00:40:38,014 this will be published probably 1107 00:40:38,315 --> 00:40:41,114 about the same time this hedge episode is 1108 00:40:41,114 --> 00:40:41,614 published. 1109 00:40:41,994 --> 00:40:44,094 I think it's within a week or two 1110 00:40:44,234 --> 00:40:46,815 of the two. Yes. That's correct. In March 1111 00:40:46,954 --> 00:40:49,295 at the passive and active measurement conference, 1112 00:40:50,554 --> 00:40:52,255 this paper will be published. 1113 00:40:53,380 --> 00:40:54,199 Alright. Cool. 1114 00:40:54,500 --> 00:40:56,920 So I'll try to remember when we publish 1115 00:40:57,300 --> 00:40:59,539 the hedge to, like, find that paper and 1116 00:40:59,539 --> 00:41:00,039 and 1117 00:41:00,340 --> 00:41:01,780 try to put a pointer to it or 1118 00:41:01,780 --> 00:41:03,480 something. I know sometimes conferences 1119 00:41:03,780 --> 00:41:05,940 give you the URLs of the paper beforehand, 1120 00:41:05,940 --> 00:41:08,260 sometimes afterwards, so we'll have to look and 1121 00:41:08,260 --> 00:41:11,005 and see how this particular conference runs things. 1122 00:41:11,465 --> 00:41:12,285 Alright. Cool. 1123 00:41:12,905 --> 00:41:13,405 So 1124 00:41:14,265 --> 00:41:16,744 but you blog or anything, Henry? Do you 1125 00:41:16,744 --> 00:41:19,224 have any Well outside? No. As I mentioned, 1126 00:41:19,224 --> 00:41:20,605 I do freedom to tinker, 1127 00:41:21,144 --> 00:41:23,144 on an occasional basis, and then I have 1128 00:41:23,144 --> 00:41:25,230 my personal web page. I think I'm not 1129 00:41:25,230 --> 00:41:26,989 quite as much of a public facing, 1130 00:41:27,710 --> 00:41:29,809 blogging entity, although that's always considering 1131 00:41:30,989 --> 00:41:33,090 it. Yeah. That's cool. That's fine. Yeah. 1132 00:41:33,630 --> 00:41:35,309 And, Tom, where can people get in touch 1133 00:41:35,309 --> 00:41:36,610 with you? LinkedIn. 1134 00:41:37,385 --> 00:41:38,824 See, he says the same thing. I don't 1135 00:41:38,824 --> 00:41:40,204 even know why I asked him. 1136 00:41:41,545 --> 00:41:43,864 I should just say, Tom is reachable on 1137 00:41:43,864 --> 00:41:45,005 LinkedIn. Next. 1138 00:41:48,105 --> 00:41:48,925 It's efficient. 1139 00:41:49,400 --> 00:41:52,519 It's efficient. Yeah. Alright. Cool. Alright. I'm Russ 1140 00:41:52,519 --> 00:41:53,640 White. You can always find me here at 1141 00:41:53,640 --> 00:41:55,500 the hedge on rule11.tech, 1142 00:41:56,039 --> 00:41:56,539 LinkedIn, 1143 00:41:56,920 --> 00:41:57,420 and 1144 00:41:58,039 --> 00:42:00,360 x me, Twitter, whatever. I don't log in 1145 00:42:00,360 --> 00:42:01,880 to those things a lot. But if if 1146 00:42:01,880 --> 00:42:04,034 I'm there, if you wanna PM me, that's 1147 00:42:04,034 --> 00:42:04,534 fine. 1148 00:42:05,954 --> 00:42:07,875 Let's see. Thank you for listening to this 1149 00:42:07,875 --> 00:42:09,155 episode of The Hedge all the way to 1150 00:42:09,155 --> 00:42:11,554 the bitter end. We know that we live 1151 00:42:11,554 --> 00:42:14,214 in an attention based economy, and your attention 1152 00:42:14,355 --> 00:42:17,039 is very important to us and that we 1153 00:42:17,039 --> 00:42:19,519 are very happy that you find these episodes 1154 00:42:19,519 --> 00:42:21,760 of The Hedge valuable enough to listen all 1155 00:42:21,760 --> 00:42:22,820 the way to the end. 1156 00:42:23,360 --> 00:42:25,119 Thank you for listening, and we will catch 1157 00:42:25,119 --> 00:42:26,019 you next time.