Join us as we gather around the hedge,
where we dig into technology,
business, and culture with the finest minds in
computer networking.
Hello again, Tom.
I'm not even gonna talk about your plant
because we just did. Okay. Well, my I
think my plant gets an ego boost every
time we record because it hears you just
praising it. And Although I just talked about
it by saying
I'm not gonna talk about it. Yeah. About
it. So that's that's the way this works.
I'm sorry.
The plan likes it. It's all good.
I do think, though, that you need to
get your your boys in there to draw
some pictures on that rather blank whiteboard. It's
too wild. We need spaceships.
Yeah. We need something that's like there's something
wrong with that. K. You go ahead. Yeah.
You can let him know that. So we
are joined again by Henry Burge Lee.
Princeton. Right?
Princeton. Okay. And we talked about
Mexican places the last time we talked, probably.
Places to eat in in Princeton,
and string quartets and string quintets
and trumpet quintets
Woah. Which which were quite fascinating. But, anyway,
so BGP security is the topic today, not
broadly, but a very specific type of attack.
But let's back up and talk about BGP
hijacks to start with
just so our listeners have some clue. I
mean, I think most of our listeners know
this, but it never hurts to, like, say,
you know, what is a hijack? What what's
going on here?
Yeah. So I think a BGP hijack and
what is a hijack is a surprisingly
deep question if you really get into it.
Mhmm. But, essentially,
I like to think of it as organization
x owns
some plaque of IP space
and expects standard Internet routing so that traffic
to their IP space goes to them. And
then somewhere else in the Internet, an adversary
that previously would not have been
on the route to that IP block makes
a BGP announcement
so that now some fraction of Internet traffic,
if not all of Internet traffic, goes through
adversary,
and then they can choose to forward it
to organization x or
just answer it themselves.
Okay.
So when we say a hijack, we're basically
saying
the route is originated
by someone who's not supposed to be originating
it, basically.
Yeah. So that that's one
absolutely accurate definition.
And when I said it's very
complicated, if you wanna drill to the bottom
of that Oh, yeah. Yeah. No. There's there's
a lot more complexity than that, but that's
the basic But that's the easiest way to
think of it. Like, you know, organization x
owns that block. They should be originating it.
And then mister bad
guy originates that route, goes out to the
Internet and then traffic to organization x goes
to the bad guy. A threat actor with
a red laptop.
Yeah. Exactly. Because they're always and the hat.
Yes. They always they always have a red
lap laptop, and they have a hoodie
and the hat. Right? That's that's all that's
how you know they're threat actors
because they're that's what they are.
So
so alright. So given that,
currently, what we're looking at to try to
solve that problem, what's been mandated by
NIST and the US government, I don't remember
the regulation,
at least here in The US, is to
deploy RPKI.
So I don't wanna spend a ton of
time talking about RPKI.
Although I think it's a fine it's a
fine way of doing things,
but it's nonetheless,
you know, it does add complexity.
Don't get me started on BGP sec, because
BGP secomy is like
worse. It's one of those diseases
that cures that's worse than a disease, in
my opinion,
because it's so complex and it opens up
so many new attack surfaces. I'm I'm very
refreshed to hear you say that because I
have talked to many.
There are absolutely attack vectors within the BGP
sec ecosystem. There are attacks it doesn't cover
and then the complexity.
I I guess a very fun digression, but
the the only known
BGP sec implementation I know of is from
NIST, and it's based on, like, an obsolete
version of Quagga.
I was doing an experiment with some researchers,
and we said, oh, what happens if you
set MRAI to to zero? And no other
router implementation
has a problem with MRAI zero. Most networks
run MRAI zero. It's quite common nowadays.
But this old implementation of Quagga, the whole
NIST BGP sec implementation crashes when you set
MRA at this zero. Yeah. So it's like
there's still a little work to be done
if you wanna put that in the production
box.
Well, my absolute favorite is is that if
I connect with you,
okay, and I
I agree to a connect with you and
I have a contract with you,
and then
you say,
okay,
we're mad at each other, so we disconnect.
Right? Whatever happens, contract fails, whatever.
My
previous upstream
still has my signed routes,
and I they can advertise them
forever
until I change roll my key.
Right? Until you roll. Yeah. So so if
I'm a provider
advertising 10,000 routes and I have to roll
the key on 10,000 routes
to stop my old up to stop somebody
from
advertising my originating.
No. I'm sorry. That's not happening.
That's like
Here's the other fun one. Prefix 1234
is out on the Internet.
You know, BGP sec. Let's assume world's doing
great. BGP sec. Then prefix owner deaggregates
back to, like, a slash 23. That prefix
is withdrawn.
Until people roll all their keys,
you, the bad guy, still have the one,
two, three, four route signed everything. You just
announced that out to the Internet, and now
you're the only announcement point for 1 2
3 4. So you just hijacked everything. You're
gonna be in separate.
A a lot of this just comes from
BGP doesn't have timers.
Right? It's not rip.
A route is permanently
good as once it's been advertised. You have
to there there's no there's no secure withdraw
system in BGP.
Right? And so and and implicits make it
hard. There's all these problems with withdraw
in BGP. And by the way, this even
goes generally.
People think BGP converges really fast. They think
so because they all look at updates.
They don't look at implicit withdrawals. They don't
look at withdrawals.
Withdraws
are
eternal
in BGP.
I mean, they're really not. They're like three
to five minutes to get a withdraw through
the global Internet. But still, it's three to
five it's, like, three to five minutes.
I give mine up to 12 minimum before
I start to not see that in the
table. Yeah. Like, it's it, like,
it's it's like just a thing with BGP.
And people always measure this one thing, and
then they don't pay attention to the other.
Yeah. But Russ, you're much more refreshing to
talk to than the academic reviewers, I have
to admit.
Oh, my goodness. Well, my history with BGP
Sec is very old. I was co chair
of the BGP Sec Working Group in the
IETF
many, many years ago. And then the Working
Group was shut down because we could come
to no agreements.
And so that but that's a bit of
weird history that's that goes a long time
ago.
In fact, there was a time I was
talking to somebody
on a on the BGP segmenting list, and
they said, well, signing the update makes it
secure.
And I said,
does signing
your doorknob
make it more secure?
I'm just like, I'm very curious.
Is it the signature that does the work?
Like,
what are you
okay. Whatever. Anyway
so so let's talk about
stealth
BGP attacks. And what you mean what do
you mean when you say it is a
stealth or a stealthy BGP tag?
Yeah. So that that's that's a great question,
and that's often at the crux of this
work. So
I think to explain stealth, it's important to
understand the BGP
ecosystem a bit. And really what I'm narrowing
in on in this paper is BGP monitoring.
So we have public data feeds of BGP
attacks, most notably,
RipeRisks
and route views.
They peer with several hundred organizations including
all essentially of the tier one ISPs.
They dump their updates and then they publish,
you know, consumable formats for researchers or even
online attack detection systems.
You move into the private space,
ThousandEyes,
CodeBGP, which then got acquired by Cisco ThousandEyes
and bundled in and, you know, a couple
other
And even and even some DDoS providers, Akamai
and Exactly. Fastly
and Cloudflare
will So essentially
Yeah. They're monitoring. You know, they're looking at
BGP updates.
And this is one, I'd say,
pillar kind of of the BGP security. RPKI
is firmly on the prevention side for the
most part. It's meant to, you know, you
can't make that announcement. It will get filtered
if it's RPKI invalid.
BGP monitoring is kind of on the detection
side. Some people have proposed active measures based
on monitoring. But essentially the idea is you're
looking, you're consuming all the global data feeds
and then
something bad happens in PGP and you'd like
to have a I got hacked button that
you will press at that time when your
BGP monitoring tells you that you got hacked.
So it's a retroactive preventative measure.
Okay. Cool.
So we're talking about monitoring, and we're talking
about the ability to monitor
effectively and effectively detect
Exactly.
Attacks.
Right?
Exactly. Right. Alright. By the way, I didn't
realize Jennifer Rexford's on this.
Yeah. Well, I work under I work under
Jennifer Rexford. Okay. Alright. That is interesting in
and of itself. I know Jennifer from IETF
work and stuff. That's wonderful. Yeah. Yeah. So
so that's so that's interesting. I didn't realize
Jennifer was involved in it, which is cool.
I mean, she's a very good researcher. She's
very strong, understands BGP really well. And I
didn't I didn't just didn't realize she was
involved in this. But anyway, alright. So
we are
trying to detect these attacks and then we
find we found a way to make it
basically impossible to detect them. Right? Exactly. So
the monitoring infrastructure,
largely works off of these peering sessions with
the major ISPs that essentially dump. You can
almost imagine it like a customer route table
that they give out to these
organizations for free, and then they get all
the routes, and that's what you're monitoring.
And, essentially, what I was really interested here
is that it turns out that if I'm
a direct customer of, let's say,
I feel like like I'll I'll go with
Cogent because we did some of the experiments,
with them. But it's not specific to Cogent.
But I'm a direct customer of Cogent, and
I can put a route in Cogent's table
and tag it with the
no export BGP community.
And the fun thing is it turns out
that just the way routers work and the
way most people's networks are set up, this
no export community will have the intended of
the effect of
causing Cogent not to send the route to
BGP monitoring. So it's not just no export
to their customers, which is what you'd expect.
It's also no export to BGP monitoring. So
in this manner,
I can send anything that they're willing to
accept. Maybe I'm trying to social engineer their
teams or bypass some white list filters. You
know? And if they're willing to accept it,
it will never go out to the global
monitoring community. It'll just be kinda secretly hidden
within Cogent's network.
Okay. So it's interesting.
The the thing let's think about no export
for a second. So what no export does
is it says, don't send this out of
my local AS, this route. I'm gonna advertise
something to you. Don't advertise it. It's not
there is another another one that's not well
understood, which is no advertise, which is don't
even advertise it to any of my peers.
Zero. Nobody. No IBGP, no IBGP. Don't tell
anybody about this. This prefix is a secret.
Shut up. And then you have no export,
which just means
don't send it out over any eBGP connections.
Right? All iBGP connections are fine, but not
eBGP.
So what you're saying is is they are
announcing
an advertisement
with no export
to
their adversary's
route. So it's it's it's restricted to a
one hop, basically,
because of the no export.
But then because it's no export,
you don't even send it to
the route view server. Exactly.
Right. Come out. Okay.
Now wouldn't this be, to some degree, cured
by using BMP
Yeah. For the route view server? Okay.
Exactly. So there are many cures, and I
think
really why I'm so excited to talk about
this on the podcast
is I wanna know your thoughts on cures,
and I want network operators listening to this
to let me know their thoughts on cures.
Because there are many ways to fix it.
But right now, it feels like there's not
a lot of sort of, like, what is
the immediate next step? And I think that's
a question that
has come up a bunch that I really
wanna answer. And just to clarify exactly the
mechanism at play, it's
precisely what you were saying.
Route views, when they talk to these networks
to get the route tables, they run an
eBGP
normally multi hop session with them. And route
views has an ASN and so does RIPE
RISC. And to the routers that terminate these
sessions, they are just
standard EBGP sessions with, like, a customer. But
it's not really a customer. It's actually BGP
monitoring. And so when they consume the no
export community that may have been attached by
the adversary, they
stop exporting to these sessions. So, yeah, BMP
is a great answer.
But right now, both Rypress and RouteViews have
not fully
embraced the BMP train. And then I think
a lot of networks
are like, well, BMP
can be configured, but BMP can also leak
a whole lot of
internal network data that you don't want. And
it's an extra CPU load on the routers
that terminate BMP. So, you know, you talk
to people about BMP. They're not always exactly,
like, happy.
Yeah. It it's also extra load on the
device that's sending the BMP.
We we use BMP extensively in my network.
In in the network I work on. It's
not mine, you know, I didn't build. But
anyway,
but,
we do run into issues
with
performance
on both ends,
sending and receiving.
And so we tend to be a bit
careful
about where we use BMP.
And to some degree, I think it's because
of the formatting of BMP. I don't think
BMP is very,
it's it's like what they did
with BGPLS.
Rather than just taking the ISIS
LSA
as the TLV as it exists
and encapsulating
it in an address family,
they said, well, we wanna be able to
use the same
stuff
for both
IS IS and OSPF. So we're gonna invent
a third
LSP or LSA type,
and we're gonna translate
IS IS and OSPF LSAs into that new
standardized type, and we'll carry that as an
address family in BGP.
And, like,
it's brilliant in some sense,
but it's not brilliant from a router load
perspective. Yeah. Right? It's it's it's actually very
hard for the router to process. It'd be
much easier just to encapsulate it. So in
much the same way, I don't remember a
lot about the BMP format, but I do
think it's like that. It's like I have
to take this update I've just received, and
I can't just encapsulate the update.
I have to actually, like, process it. I
have to do something
with it. And then the receiver has to
look at that processed update and go,
oh, that means this.
I've gotta back it out and create a
database out of it again.
So that that I think has always been
an issue with BMP.
Yeah. No. That's exactly right.
So another option would be, I suppose, would
be to ignore no export.
When you're talking to a route view server
Yeah. That's or a looking glass. We we
strongly
recommend it. I think there's sort of two
variants of that.
So one that we propose in the paper
is rewrite no export
at ingress to your entire network. So if
you have an AS and the customer tags
no export,
rewrite that to,
like, my internal
no export, which is just something in your
community space,
and then match on that at your border
so that it behaves the same as no
export. But
if you have a server session with route
views, obviously, ignore that. You know? So now
you avoid
the sort of baked in router behavior of
the well known community,
and then you do it up. I don't
think NetOps
love that either because
now you're talking about filters on maybe hundreds
of customer facing routers.
And then there's a variant of that where
I believe
I'll admit I haven't tried the configs, but
I believe that if you just have say
you have two servers that talk to route
views, I believe at those servers you could
even rewrite the no export on the iBGP
session in and then just do a config
change
at those routers that talk to route you.
So there's possibilities.
I think
largely, you know, a lot of network operators
have expressed, like, these are config changes. They're
happening
to core production routers, and there's kind of
a risk
involved with doing it.
Yeah. Particularly the border one. Yeah. I I
would be very afraid of about overriding
no export on my inbound side. That would
be scary to me because just because it's
very easy for somebody to mess something up.
I'd rather do the opposite.
I'd rather have the router that's peering to
the route view server
say,
I don't have to pay attention to no
export. Yeah. Exactly.
But but I'm not sure how many config
how many routers, like, how many implementations of
BGP
allow you to strip
prefixes on the outbound side
k. Towards an individual peer. Yeah. It gets
a little, like
I think right now, most of the main
configs don't have that. Like, what people I
think are most
acceptable doing is, like,
on the one session they have with route
views, they make a config change
on that one session that says, please ignore
the no export.
And that's, I think, the most sane
config change location.
But when you look at vendor support and
just the way BGP,
you know, BGP community filtering is implemented,
I'm not sure if you're actually able to
make that one config change in that one
localized place. And I've talked to to vendors,
like, would you put consider putting in, like,
a
a monitoring style session so you could just
have a flag that said this session is
monitoring style, and it's going to ignore, you
know, like,
standard no export communities.
And then their response was, well, if a
bunch of networks were doing it already,
we might make their life easier with that
flag, but we're not gonna go out of
our way and develop that flag. So to
me, it feels a little bit like we're
at an impasse,
and yet it seems like the attacks have
potential to do damage.
So I'm kinda wondering, like, where do we
go next?
Yeah. So it is actually
the way that the b b BGP tables
are structured in most implementations,
it is difficult to
strip out
communities on the outbound side,
I would think. That's just my my when
I think about, like, the way if our
routing works, the way iOS works, the way
XR works, and thinking about the code in
my head of how that actually works,
you walk the table.
You say, okay.
A lot of people think you walk the
table based on the prefix first. You don't.
You walk the table from the from the
attribute side,
which is which is very unusual. People don't
think about it in those terms.
Some old implementations, we walk the table based
on the on the prefix side. But a
lot of newer implementations,
you don't walk you walk the table from
the attribute side because what happens is is
you have this separate table of attributes over
here. And this set table of attributes says,
all right.
I have some number of routes
that have
community one, two, and three on them.
So now what I'm gonna do is I'm
gonna start with that group because I'm trying
to build a peer group. Right? I'm trying
to build a single packet that goes to
multiple peers
based on that. So I'm trying to pack
and not only that, I'm trying to pack
as many prefixes onto that set of attributes
as I can. If I walk from the
if I walk my table from the prefix
side,
I have to, like, Okay, this prefix has
community123
on it. Skip it. Go to the next
one. Oh, that one has one, two. Okay.
I can use that one. If I walk
from the attribute side, I can pick the
common sets of attributes
and choose the prefixes that match those, which
allow me to pack the packet.
So I think it's hard to filter because
what you basically have to do is you
have to say, for one neighbor,
I'm going to ignore this attribute when I'm
walking
the attribute table. Right?
That's actually why it's hard.
To me, that's why it would be difficult
to implement it that way. The other idea
of just not paying attention
is actually a better idea of just having
a separate, like,
let's see. Then you have to implement basically
the opposite walk
to do it. So this is why it's
probably hard.
It's almost better to have a dedicated BGP
speaker
that strips
all of the community the no export on
the inbound side of that BGP community
or that community that that internal BGP speaker,
and then peer that BGP speaker
with your routing server. I think that's probably
the way out is that you just have
to have a dedicated BGP speaker
whose job it only is is to talk
to route user risk. Some networks even kind
of have this. And then inbound to that
guy, you do all the filtering processing,
and then that by just runs normal unmodified
BGP to send out
what you need. Yeah. So that probably is
the best way out.
Yeah. That's
that is probably gonna be the best way
out. Even though it is I mean, it
is you have to throw a piece of
software at it, basically.
Yeah. You you have to throw a a
a, you know, a software router.
If our routing bird something
running on a VM, it's gonna pull all
that data in. And it's gotta peer with
a lot of peer with a lot of
BGP speakers
inside your network.
Potentially. Yeah.
Yeah. I mean, like, with me, I don't
know. We have
probably 10,000 eBGP speakers.
It's probably more than that, but it's it's
at least that.
And so how would I do that? I
have to actually build a hierarchical
thing of BGP speakers that bring me all
the way from the edge up to one
or several boxes that talk to route view
servers. So I see how this is really
hard to get around. This is making a
lot of sense that
this is not an easy problem to solve.
In all honesty,
this is actually not an easy problem to
solve.
So my my my question though is if
the processing of no export is an issue
because it's hiding it's hiding these bad actors,
the methodology you're using to make that statement,
why why can't that be used to detect
like, if you can detect that they're that
they're being stealthy, then they're not being stealthy.
Right. So the the thing is,
as of yet, fingers crossed, we don't know
of a specific no actor
using the stealthy attack technique.
What I do to confirm, because I've launched
these attacks several times, in the wild in
an ethical manner, is I log into the
network's looking glass. So, So, like,
I can put a route into Cogent or
NTT,
and I can see Cogent and not send
that over their session to right route views
risk even though they're sending everything else. And
then I go to Cogent Looking Glass, which
is essentially just a router
telnet login behind a web interface,
and I type in and then sure enough,
there's the prefix in the table. So that's
how I detect them.
But I personally believe that if there was
an attack, like, what are the odds that
said victim's
hobby is logging into Cogent Looking Glass for
their routes every ten minutes.
You know? It needs to go through the
existing pipelines and then process in this sort
of automated
manner that all these companies and services are
consuming the public BGP updates and announcing, you
know, alerts and notifications on them.
But, yeah, the I think the thing to
the answer to that would be we don't
know. Like, if someone did this, we would
not know.
Well, and there and there's another way to
think of this in so so it's the
it's the presence and absence of routes that
is tipping you off to a condition that
could be leveraged against someone.
I
at some point, we will probably have to
move beyond current thinking in how we validate
a given BGP control plans.
It's,
fit fit for like, that is doing what
it needs to do in operational state in
the network. Right? So if and I'm not
I'm not saying any particular tool is the
answer, but it seems like there are there's
another there's an entire category of issues that
could be detected if you were to if
we were to move beyond,
BMP and route views. If you were to
take a look at the system holistically,
you know, download tables, do consistency checking, like,
you wouldn't find just this. You'd find that
you'd find other things too. Completely. Yeah. They're
just like there are control plane behaviors that
you probably never want to see
in a sane, well defined, well operating network,
and you will only see those control plane
behaviors if you
have magically
had visibility into every router's control plane state
and peering relationships.
And even the best research were miles from
that and probably for good reason. You know,
I think companies
have the right to keep their routes hidden
and some amount of their architecture behind closed
doors.
Well and and the the the thing that
lead that led us to the maybe we
need a hierarchical set of of instrumentation routers
to give, you know, to give it some
some sort of name, to let us instrument
our network just for the purpose of analyzing
tables.
If that's where it leads anyway, then that
same infrastructure could be used to do
a lot more sophisticated analysis
of the network anyway. Right? So maybe this
leads us to a to a good place.
That would be kinda neat. Yeah. I think
I think more clean separation of,
you know, what should be public and then
what should be private and, like, can you
have a router that's for
instrumentation
purposes? I think some network architects are moving
in that direction, but once again, like, the
majority of network architectures
don't think, like, well, we should have a
router that just sits there for the purpose
of establishing public data.
It's it's kind of,
it's kind of like remotely triggered black holes.
That that that's more for enforcing policy,
enforcing policy in an entire BGP domain. But
taking that that same approach and saying, well,
we've been operating RTBH forever.
What if RTVH could actually tell you something,
interesting rather than just giving you a way
to enforce policy globally instantly?
What if you could understand,
control plane globally instantly through that same through
the same type of mechanism?
Yeah.
Yeah. That that actually would be really cool.
It's it would be a really great
way to do just being able to gather
the information and see this happening
is is actually
even if you even if, as a provider,
you just tagged every route that came to
you as no export.
And you said,
I'm going to have a script that when
you when I see a no export,
well, I guess it would never show up
in the Raview server. Right?
But in that case, like, maybe I should
investigate that and make sure that it's valid.
Right? So one recommendation we've gotten is, like,
maybe
no export should be something a customer has
to explicitly
turn on with a valid, like, use case
and if you at least
reduce the volume of customers that can
can do it. You know? So, like, imagine,
like, a lot of, sessions are spun up
largely with interactions with the sales team.
And, you know, I have heard some
statements out of networks that the sales teams
are quite eager to spin up new connections.
Maybe somewhat the security teams wish they'd be
a little more hesitant.
But then maybe something like no expert should
be seen as a security critical
piece of functionality and should trigger sort of
more in-depth
vetting. So I've I've sort of heard
that
recommendation.
Yeah. And I like, if someone's giving you
no export, like, why are they
doing Well, I'll tell you this is gonna
become more common.
I believe no export is gonna become more
common. No advertise is as well
because of Unicast RPF.
Oh, yeah. I get that. Because be because
if my upstream is is enforcing Unicast RPF,
that's fine. That's cool. It's a good thing.
It's not a bad thing to enforce unicast
RPF. But if I'm dual honed, it leaves
me in the position of one of my
connections being
toast. Yep. Right?
Because they're only gonna choose one of my
two connections. That's fine. So now what do
I do?
Well, I'll tell you what I do. I
advertise my route with no export or no
advertise,
preferably no advertise, by the way. Not not
not no export. Right? I prefer no advertise
in the case of of Unicast RBF.
But some people will be, I'll just use
no export. Right? They don't even know about
no advertise or whatever the case might be.
Because if I advertise with no advertise,
I'm actually not changing the upstream provider's
best path selection.
All I'm doing is I'm allowing traffic from
my side of the network
to upstream through a path that would normally
be dropped because of unicast r p f.
It allows me to
do asymmetric
pathing
without modifying what the provider is normally doing,
how the provider works.
No export can actually modify what the provider's
best path is. Right?
But a lot of people will be like,
let's just do do a no export.
It's it's gonna be all over the place.
Yeah. Actually, I I I admit I've used
that very configuration. I have, like, global nodes
that are essentially any cast
and then have one node that I need
to send the packets from. I don't necessarily
need to receive packets at that node, but
I wanna send packets to my
anycast service that I'm dynamically modifying all the
time. So what what do I do? I
just write a BGP config that tells my
upstream, don't export this announcement, but I'm giving
it to you
just so I can get past your unicast
RPF filter.
Correct. There's even an RFC
suggesting to do this. Okay. I'm glad the
RFC people agree.
So so there so but I do believe
that RFC uses no advertise, not no export.
But, nonetheless,
I can tell you of several major anycast
providers
that are either
in plans to do it or already are
advertising a % of their routes.
Yeah. Actually, I do get this because and
then Anycast cashment is a very dynamic
sort of ever changing problem. So you can
imagine there's two sides to this. There's how
do I want to strategically route traffic that
is inbound to my network
at my global set of nodes. And it
turns out you will get better routing by
turning some of those nodes off because some
nodes just have longer routes, slower routes, whatever.
And then some of these networks, those are,
like, globally connected data centers, so you don't
know where that traffic's gonna egress. So if
I was operating in any cast network, I
would personally definitely do it. I'd just say
every node can egress everything,
just gonna double tables of no advertised so
I never get hit by that, and then
my ingress, I'm gonna traffic engineer dynamically, you
know,
So Yep. The best that I can. Yeah.
I mean, you can't advertise everything with no
export. Right?
But you're gonna ingress what you're actually gonna
do is you're gonna ingress traffic
engineer
by advertising everything with no export or no
advertise.
And then you're going to measure your inbound
load and say, oh, this data center or
this entrance point has lower load than I
would like.
So I'm gonna take no export, no advertise
off of that.
Right? Yep. Yep. Which then allows me to
be very precise, not precise, but more precise
than many other ways
of doing inbound load management
using no export, no advertise. That's a very
smart way of doing it.
Yeah. So that so the so it's gonna
become more common. So it's gonna become more
of an issue in detecting
the stealth attacks
Yeah.
As people use those tools to get around
So this is an existing tool that's well
established for customers to use, and I've actually
seen adversaries that
pose as mid tier hosting providers that
only reasonably be doing this type of thing.
So this is a completely reasonable legitimate behavior.
Then if there's an adversarial dimension when I
announce my victim's prefix with no export
and that stops it from going to monitoring,
I I personally see it as a fairly
large problem.
But as I said, I'm still trying to
understand, like, what is the
thing to do today
for operators?
And then if there is no thing to
do today,
I guess, to me, it brings into question,
like,
what is the monitoring infrastructure
for? Is monitoring, like, a sustainable,
reasonable way of doing BGP security? Because it's
really emerged, I'd say, almost as, like, a
fan favorite
in the space.
Yeah. Yeah.
Yeah. And and until you know
how prevalent this is, it's hard to know
the answer to that question.
But you don't know how prevalent it is
because you can't detect it today. Yeah. Right?
It's like this whole,
circular, like Exactly. Yeah. That's the thing that
scares me a lot also. Like, I work
with threat intelligence as well where we're digging
through
BGP logs from months ago or years ago,
correlating those with attack announcements and the certificate
logs,
and we're trying to piece back together the
chain of events that some adversary used. And
if you get rid of that BGP log,
like, it's not just the, oh, I didn't
detect it today. It's like there is no
historical record.
Because after those that attack is over, if
it's not in route user risk, we have
nothing to go on point to and say,
like, we
got it. So it's sort of just invisible
forever.
Yeah. This yeah. This is actually
a major problem that that now that I'm
starting to think through, like, all the different,
like, how do you
do this?
How do you like, this is hard.
And so, yeah, this is this is very
interesting. This is a very interesting paper.
Thanks. I appreciate that.
So I don't have anything else to
I don't have any other directions to go.
I'm kind of
It's Friday.
It's Friday. Yeah. I'm kind of out of
directions on this.
But it is really interesting, and it is
I'm gonna have to go back and read
the paper and share it around with some
folks
in the BGP world
and figure out, like, what we do or
how we think about this.
I'm not so deeply involved in the IETF
anymore just because of
where I am now, but
this is a this is a major problem
or a major thing that that needs to
be thought about. So Thank you. I'll try
to spend some time I will bring a
about it. Just with remaining time, I'll bring
attention to one proposed solution I've heard a
bunch of, which is IVG sessions. So you
imagine RIPE risk.
Right now, it's an eBGP session.
Kentech,
and several other
private monitoring
services,
they use iBGP sessions. So they're the, you
know, the monitoring service router instead of peering
as an external peer peers as an iBGP
peer.
Looks like they're part of your AS, and
they just run the session open, you know,
with that customer's ASN.
So that
seemingly immediately solves the problem. But once again,
we kind of go back to this idea
of, like, it's actually a trust boundary between
your network
and the external provider.
And when Kentek and these other commercial
offerings establish that iBGP peering,
my suspicion, and I have some data to
back this up, is that
that's done on the grounds that that secret
I b g p data is not gonna
leave
Kentek. Like, it's going to Kentek for the
use of your net ops team to query
Kentek for what your routes look like.
When I talk to network operators, like, when
you do I b g p with Bright
Brist, they're sort of like,
no.
Like, my I b g p feed might
leak more than my e b g p.
I know I'll do e b g p
with them because that's the same config I
would give any customer that signs up to
my network.
I don't know how I feel about doing
I b g p because that might leak
more next next hop info or internal network
architecture.
It leaks it leaks internal network architecture all
over the place in most in most providers.
That's just and particularly,
by the way, because we use BGP on
data centers, fabrics now. Oh.
Right? So
so
it's one thing
to leak
the workloads attached to my data center fabric,
perhaps. You may not even wanna do that
because a lot of those are internal workloads.
But to even leak my data center fabric
infrastructure
networks
via iBGP.
Now, theoretically, that stuff should be filtered at
the edge of my data center fabric. I
got that. But, nonetheless, things happen. Right? And
that's this is this is where people get
nervous. And I understand the nervous. But, yeah,
it it it is still a problem. Right?
It's still another avenue that seems Well, it's
like there are several options or things you
could do, but all of them, I think,
put a large amount of risk onto the
network operators that would have to go and
then make those changes.
And and it's the type of risk that
if something bad were to happen, you wouldn't
wanna have to go to your your boss,
you know, a CSO at the company and
say, well, yeah, we just dumped a bunch
of personal information.
It's because we're trying to eliminate this attack
vector that no one can even measure anyways.
You know? So it just doesn't look good.
Yeah. Yeah.
Very interesting. Cool. Alright.
So anything else you wanna talk about before
we wrap up? And,
this will be published probably
about the same time this hedge episode is
published.
I think it's within a week or two
of the two. Yes. That's correct. In March
at the passive and active measurement conference,
this paper will be published.
Alright. Cool.
So I'll try to remember when we publish
the hedge to, like, find that paper and
and
try to put a pointer to it or
something. I know sometimes conferences
give you the URLs of the paper beforehand,
sometimes afterwards, so we'll have to look and
and see how this particular conference runs things.
Alright. Cool.
So
but you blog or anything, Henry? Do you
have any Well outside? No. As I mentioned,
I do freedom to tinker,
on an occasional basis, and then I have
my personal web page. I think I'm not
quite as much of a public facing,
blogging entity, although that's always considering
it. Yeah. That's cool. That's fine. Yeah.
And, Tom, where can people get in touch
with you? LinkedIn.
See, he says the same thing. I don't
even know why I asked him.
I should just say, Tom is reachable on
LinkedIn. Next.
It's efficient.
It's efficient. Yeah. Alright. Cool. Alright. I'm Russ
White. You can always find me here at
the hedge on rule11.tech,
LinkedIn,
and
x me, Twitter, whatever. I don't log in
to those things a lot. But if if
I'm there, if you wanna PM me, that's
fine.
Let's see. Thank you for listening to this
episode of The Hedge all the way to
the bitter end. We know that we live
in an attention based economy, and your attention
is very important to us and that we
are very happy that you find these episodes
of The Hedge valuable enough to listen all
the way to the end.
Thank you for listening, and we will catch
you next time.