Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/647 Thanks!
Please give a warm up, so to speak.
Who are we talking about, IP Version six,
Global Scanning. Thank you.
So good evening, everybody.
Nice that you still made it, even though
it's 11:00 p.m..
Of course this is not working for
me alone. It is.
Jonge work with colleagues from UC Santa
Barbara, Kevin Bangalter,
showing how Christopher Krugel and
Giovanni Vigneault
first thing about me.
I have a Bachelor of Science and
Cognitive Science and somewhat
noticed that wetware is not really my
life.
So I actually went on to get a master's
this network engineering.
And since I got that, I'm
more or less desperately trying to get a
Ph.D. from Professor Felt.
My professor, ciphered to table in
my research interests can be summarized
as basically what nobody
else does, but not because my stuff is
ingenious, but because most people say,
well, that's stupid, that won't work
anyway.
And I think we all know this as
misconfiguration.
So you all
know these nice people that are running
database servers on the Internet without
authentication.
I have heard of a big ISP that actually
managed to run their provisioning system
on the Internet, which
was not that good for connectivity for
their customers.
There's also other nice examples,
so Hutton was
actually pretty good and doing backups,
they even encrypted them and start the
Askey with it.
And there's always the fun of finding
a nice car, the device that
belongs to some bullet proof hoster
right on the Internet
and something I had to learn, there is
something called remote DMA.
What could be better than doing DMA
over the Internet?
So basically, whatever
I will tell you today is directed
at finding these.
But first things first, if
I may tell you about a nice
tool to have a lot of fun with it, but
basically, what do you don't or stupid,
you don't have to back across state lines
from your house.
You get nailed by the FBI where
your brains in your ass
follow this. Good advice.
Think about this Eve and think about the
amount of bandwidth you have.
Think about the amount of benefit other
people have.
Think about them having this nice time
between the holidays at the end of the
year where they don't want to work,
which might happen if suddenly
DNS servers stop crashing
and other services become unreliable.
So
back to my motivation and
some view of related work,
the first part will be a little bit dry.
So if you start to get bored, there's
a special slide where I ask the person
next to you to wake you up
just right before the fun stuff starts.
So please don't run away.
So in the beginning, there
was that map that was like three years
ago
and it started this whole thing
about we can scan the whole IP
for Internet.
We can do like Internet wide security
evaluations.
And that was actually
a whole whole lot of fun.
So I think two years
ago there was this nice service and one
of the lecture halls at this event
where you would have something like
Chatroulette only with BNC
service,
if you like.
But that actually brings us to the second
point. It stops being funny when you find
some asset construction
facility in India on one of these
flights.
That map was heavily used to scan for
Heartbleed and to do analysis and how
Heartbleed was mitigated.
That map was used to scan for,
well, at least open TCAP ports, where you
could then do a key exchange
to see how is
key sharing between servers in the wild.
There was research and amplification
attack servers. Well, basically the
amplifiers for the amplification attacks
and the ability
to exhaustively scan
actually help the security community a
lot.
But as with all good things,
or rather not so good things, in this
case, IPV four
is coming to an end.
There's only so many addresses,
two to the power of 32, in fact,
theoretically.
And there there's a lot of work
investigating how this is getting more
and more exhausted. And by now getting an
IP before address is actually pretty
hard.
So what
happened is that people introduced IPV
six like 20 years ago.
Roundabout's think even more
with IPV six, there comes a lot
more addresses like two to the
power of 128, theoretically.
And we can actually see that IPV six
and starting to that that photograph I
have here is actually
a Bandera's graph from this event.
And we see that at peak points.
Peak points, we saw around 25
percent of outbound IPV six traffic.
This is a little bit skewed because as
soon as you deploy IPV six to you use a
network, you will suddenly see a lot of
traffic to like two or three big players
like Google with YouTube and Facebook.
But it still demonstrates that IPV six
is the thing that's coming.
However, if we start to use, for example,
that map on IPV six,
we will suddenly have to wait.
I cannot really pronounce that number,
but it's a really, really huge and I
don't really intend on living that long.
So let's
come to related work.
So looking at that
before addresses was an interesting tool.
It was not only used in the security
community, but especially
there and helped a lot there.
So people want to have the same
thing. For IPV six,
current work is relatively
focused on starting or trying
to observe IPV six address usage
in the wild, not doing active scans, but
having some vantage point where they sit,
where they can read something which
provides them information about
used IPV six addresses.
So from Saeki, Plonker and Bergere,
they are using the access logs of a large
CDN.
Of course, as good scientists, they don't
disclose which CTM this
is, but one of them has a Nechama mailing
address,
six at all, who are
mostly the vantage
point freest of them all.
They are using various DNS data sources,
but not the same as I will present on
this talk. And then they at
all
they do have for some reason access to a
large European ISP and
can look on flow data there
and thereby can get information about
utilized IPV six addresses in the wild.
So let's quickly go over these.
So Rimsky,
Plunker and Barer actually provided the
nice work where they use their data
sources to train a tool
which could then predict another active.
That means replying to ICMP IPV
six address based on the data sets they
had previously.
They are mostly using the
data. They have a small, really,
really tiny portion of data that was
gathered as the data will present
on and they utilize traceroute
data.
This has certain drawbacks.
For example, they see the analogs, of
course, do not really represent a lot
of well servers,
especially not servers in the wide
Internet out there.
Traceable data is by nature really,
really, really biased towards networking
devices because, well, it's traceroute
data.
The work by Grasset all in principle is
somewhat similar. So they also try to
predict active IPV six addresses
based on a data set they have.
So then we have to at all
this at all are actually.
Doing various minings on the
state assets so they have records
or data sets, so they actually get logs
from the NSA records,
but they are also doing something really
fun where they would actually do a
PR lookup for every address
and the IP before space.
And then at the end quote, I
look up to get the IPV six address for
that student
and their work is actually one of the big
motivations for what I'll be presenting
today, because they figured out
that IPV six security is not really doing
that well, in
other words, is doing terribly,
but well.
So in summary,
I looked in my basement, I didn't find a
CDN.
I looked at off further and I didn't find
an ISP. And when I asked my
ISP if they wanted to let me
read their records or access logs,
they also said something including No.
Well, but on the other hand, so
if I was a politician, I would now be
like, but we have this Iot Internet
of things that we really need
the scanning to protect all the people.
So,
well, we came up with
methodology.
By the way, this is a pond
where you want to wake up people next to
you that didn't really care about related
work.
So first things first,
so there's
another person I'd like to credit, it's
Peter Van Dike.
I'm not really sure if I can do the IJA
thing correctly because I'm not Dutch,
but I hope I.
Well, I tried anyway.
I met him at last. It's in Berlin
and as I well heard, he's Dutch.
I believed him when he started to talk
about the NSA
and he said, if I want to get a lot of
IPV six addresses that are assigned to
service, not clients, I
should actually look at.
Well, IPV six reverse DNS.
He said he had some interesting
previa results thing is, and I should
start to dig into that so well, as
I said, Dutch people know about the like
most of the dinosaurs were currently
using come from the Netherlands.
That's right.
So.
Let's start with a short recap,
so
IPV six address, as I said, hundred
twenty eight hits and you can represent
it in 32 so-called niblets.
Those are the little things
representing decimal characters
we see.
Yeah,
and reverse DNS is a way to get
for an IP address, you have
an epicurean, a fully qualified domain
name.
You do this by
doing some transformation to the IP
address. So you first reversed
it
and then you put basically points between
each of the nibbles for different
levels and the PDR tree.
And as top level domain and second level
domain, you have IP six Tarapur
and that tree, you
then find a record
and that record you can do a PTI request
to you and then you get a epicurean from
the dinosaur.
So the next thing that is somewhat
important at this point is how
DNS works.
So I'm
really sorry for I
hope I got this right.
I see somebody and
the audience that will probably beat me
up if I don't
it's not really clear about it, but tries
to mean it. So it got clarified.
And RC 80-20,
the meaning of Anex domain,
technically anex domain should mean if
you receive the reply anex
domain from a server for point
and a tree like the one to
the right, that there
is nothing at that point you requested or
anywhere there under.
So what does technology basically
is, is defending trees
where we received a nohara for
the root note.
We can actually try this.
So we have our given
route here, which is proper
and we do a and ask for three four zero
six dot offer.
We get an annex domain so we don't
descend in that tree.
We do the same for the one, we do the
same for the two, three, four
up to the E and we always get an X
domain.
We know well we don't have to send that
tree, but when we have the F,
we do get a no error.
We don't get any data back, but we get no
error. So while we the
that tree.
Let's try to.
I never managed to clear up class.
Sorry.
Anyway, we do the same thing again, and
this time we start with a zero and
we immediately get a no data or no
error.
So we can discount that three already
and do the same thing again.
And then we dissect that tree.
And by doing this 32 times so
and then I have six addresses, 32
nibbles,
we can finally arrive at utilized IPV
six addresses.
And you see, if we start with a zero,
this is basically a depth first
search in this huge DNS
tree that is spelled out by
the reverse DNS name system.
So, as I said, this is in itself
not new, you have
see 70, 77, seven,
which actually discusses this
as a possible technique for network
reconnaissance and smaller networks.
And they actually reference
this Peter Van Dike, who recommended this
technique to me,
and he actually wrote a small book
article about this like three, four years
ago and provided the Pisin
implementation, which you can utilize
to actually scan the network
or other DNS PDR prefix.
This was also the starting ground for the
tooling, which will be provided to
you in the end of this talk.
First, what I used
to conduct these scans as
well, basically as the computer we have
for doing machine learning at the
research group, and my colleagues were
not so happy that they have to stop doing
this while my scans.
But as I produce something called
academic code, which is basically like
start up code, what we don't call
production ready,
everybody who loved works in a startup.
But but I'm pretty sure that somebody who
is actually better with code than me, so
like a programmer who can actually write
a production code, will also be
able to run this code.
Well, the code, they write themselves
on the laptop.
So the first thing
when I thought about this technique was
that that that I do a depth first search,
which is a pretty bad thing if the
first part of the tree is on a really,
really slow DNS server on the other side
of the world.
So you want to have the opportunity to do
some kind of breadth, first search
to paralyze over different
servers.
For this, I basically just iterate
and formidable steps.
So in a first step,
well, it's right up to
a length of four nibbles
for all possible
the end of the entries.
Then I will collect all of these and for
each of these do the and immigration step
for another fondles
based on flavor, on
personal tastes.
One might also opt to go from
16 labels to thirty two directly.
So from 64 bit, 228 bit,
which may have advantages, may have
disadvantages, but we will see that later
when we look at the data.
So this was basically
what I built directly after its high
tech, this together
went to the office, ran it
was pretty happy because after
I let it run for a week, I found
something million records.
So
I then looked into the data and was
wondering why I got this funny email from
a large ISP was I'm
complaining about a lot of traffic from
my machine to theirs.
And I learned about a really nice feature
you want to have in your reverse zones
when you're offering reverse zones or
other networks to customers and end
users, which is
dynamic reverse zones.
So I
have an example here. So when you have a
big network and
you don't want to manually set all those
two to the power of 64,
reverse entries for all the possible
users, you could have you just
set a script in your DNS server that
actually generates a reverse
screen for
any given, well,
reverse pointer record.
They also may be static.
And I also found funny,
dynamically generated looking domains
that are probably DNS tools or something
like that. At least they were always
returning 32 bits of
something random.
Point being, in this case, you will never
find the next domain.
So when your algorithm
is just plainly, stupidly going in there,
it will find a lot of records.
But they all belong to well,
however big this reverse,
this dynamically generated reverse onus.
So I thought
about a high risk tax
and I first thought about doing something
computational linguistics and hand stuff
where I would compare.
We turned reverse
return Epicureans to figure
out if they may or may not be actually
somewhat related.
Turns out doesn't really work.
It doesn't really perform.
What perform for better is just just
trying to query static set of records.
And if at least three of these exist,
assumes a domain or the
subtree is dynamically generated
so that these three records as a personal
preference for the
picking of filling up
the tree to a length of certain levels
with zeroes, ones, two or three up until
F is a not so personal reference.
Some people recommended to me to do this
with random data,
but then you actually have to have enough
non blocking entropy for that.
So.
Case question, but this actually
works.
So using this, I actually tried
this again, so I started at
six foot upper, let it enumerate,
and then I found one point six million
records.
And you have to see, I
started off with like 17 million.
It was like really amazing.
And now I only have one point six million
records.
So I was somewhat confused,
which brought me to another nice finding.
So their DNA servers that are for some
reason not RC 80 20 compliant,
so they may actually sent an exclamation
instead of no error.
We have an example here.
So if the DNS server
on which F dot IP six dot upper
is the resident on Sense
and domain because it has no
explicit record at that point.
Well, then I will not say zero,
dot, dot, dot, upper.
And to actually counter this
issue, I got the idea
of seeding my algorithm so I
do not start started IP six Tarapur,
but I started various well-known
predetermined to exist.
Well, some trees of
Sydney, three, five or six Tarapur.
I built a somewhat funny algorithm for
that.
Well, at each step, so at each
level, length remembers a slight
a couple slides back.
So for Furnival's I would actually krup
the seat record
to a Lancs of animals and read the full
record length again of the seat record
just so that I get at each iteration
all the information possible from my seat
records.
The seat sources are used, whereas the
Rothfuss project and to the right
and I
was called
something was BGP we view.
I always forget anyway
these are publicly available
and actually are documented in the
script that will be published with this
talk or other possible sources
are. Of course the algorithm
says it all used where they would
actually do the quarry look lookups for
the return of Koreans of IPB for reverse
pointers and basically
whatever data set you can get your hands
on.
So if you can, for example,
if you are at a big event, a lot of
people are using remote IPV six
servers and you were actually
able to reach the network traffic,
which I recommend not to do.
Then you could also use that as a source
for seating.
So with a seat
set, I actually ran the programs
again this time it took
nearly three days running.
A parallel was a threat and I
found five months, three million records,
which is sounding very small,
but due to the,
well, state of IPV six
deployment practices.
And I think this is still pretty decent.
So it doesn't show
a full, full, full picture, but it
shows a large subset.
But I was not really satisfied
with the speed of this, so I tried to
tell us more because I realized
that my server was, well, not
really that busy.
I tried to run. It was 400 threats.
It ran faster, far less.
And the lesson I had to learn was that
basically the one IP address
I used for resolving ran out of circuits.
So if you want to have any parallelize
this, do do
it on multiple machines with
more addresses to actually use for all
tonti and various
other thing that falls into this, as
if you are running this yourself
half a local resolver, because
latency to your local resolver, for
example, in this network is the result
of a spy network. Operations
will
extremely increase the
length of these scans
and possibly will overload them.
So don't run it against just Beatport.
So this is basically the start
of the case studies
first look into this,
you see basically plotted
here the amount of Currys I needed for
records in slash 60
for us.
And we basically see a nice distribution
between extremely structured zones.
So zones that have
colon, colon, one colon, quanto
extremely structured and those that have
nearly random addresses are possibly
UI 64 addresses
to the left, basically those where I need
more queries to find less records.
And then here are the structured ones
which due to the depth first nature of
the algorithm will also be found first.
That I was then found was less queries,
but I promised more fun parts.
You can also utilize this
tool to look at something specific.
So from
the huge dataset you collect, you can
single out specific networks.
And this, for example, is
an overview of how software
as a service provider does
the network assignment policies so.
So how IP six addresses and networks are
assigned with that service provider
figuring out which service provider is
left as an exercise to the reader.
And I was told that this is too academic
and just boring.
So I looked at something else, which is a
little bit more fun.
So I personally do not really do a lot of
stock trading.
But if you look at IPV six
networks, people suddenly have
a whole lot of addresses to use.
So they will address everything.
They will address lookback, addresses,
public addresses, they will address
it, me with public addresses,
everything.
So if you look at such
a network in this case,
starting here
in September
with with sixty five K of hosts
around about, you suddenly
see a huge jump of around 10k
in just a matter of well two weeks
and like two months later
you can realize that this
as a provider actually announces
record sales quarter.
So.
This is one of the opportunities where
you could use this tool for actually
gathering information on company growth,
but which is probably a lot
more fun as looking at topologies.
So for me, this was the most
fun thing I could do with this, apart
from security scans where we
all know what they will turn up.
So first thing I did was looking
at and I expect, by the way, I'd like
to mention that this
all is my personal opinion and
I'm not representing affiliations and so
forth.
OK, so
I read across Korea our hosts
Lutoslawski 60 Force.
Red states
and green are slash 32.
And if you zoom out a little, you
can also see black ones.
Black ones are those that are for
some reason connected to to
slash sixty four or more.
So.
After importing this, this actually looks
more like a black cube than anything fun,
however, is basically directed
graph one can sort this.
Make it float apart a little so you
can actually recognize parts of the
structure.
You can add funny labels to it.
And
then you can look at what you can
see. So this
is a network of
a huge AXP.
This is, for example,
there pop in Hamburg.
And basically they're peering network.
Of course, they also have a dependance
and Frankfurt.
And I think you can actually see us so
our black friend over there,
they can actually see the networks.
The customers are having a behind
the router.
Behind the peering it in Frankfurt,
they also have this famous black holding
infrastructure, which you can see
being.
Connected to their provisioning
and some internal routing or interconnect
infrastructure.
And five or six appears
to be their central firewall, and
Frankfurt
was a whole lot of hosts connected
to it, for example, on ElasticSearch
system for customer
counting
and processing flow data.
But I think Nertz are somewhat more into
other networks, so this
is an example of Nazareth off.
But there's also somewhat bigger
topologies. One might want to look at
everybody familiar with Decmil.
So little side note, I'm
also doing the monitoring for network
operations and we will now look
into it.
At the moment, the only network
I have the feeling that I know the
topology of Better's and the network at
this conference.
For reasons it
will remain anonymous for the
purpose of this talk, but
technically the data sets are public.
So let's
have a journey to through a network.
So like all networks, it
has a border router.
And some portal systems
administration interfaces.
And possibly use our access networks.
They also run like network
infrastructure, for example, hosts called
Big Brother,
which is which is actually an ancient
monitoring system.
I want to give them that
on which they
actually had to have a lot of servers
for. But they are
currently apparently migrating to
Prometheus, which is a somewhat newer
monitoring system.
So let's look at their
infrastructure, how do they run so
they run a lot of open source software,
so we see Gentoo.
Cabral's, probably not Sahuc,
and they also have a puppet production
host.
Well, they also have
an Admiral Ackbar, which which makes me
think.
Which makes me think that it might be a
honeypot,
but what worries me most is actually this
one.
On a little more serious note,
what this also teaches us, that these
networks are run by Nertz.
So some more fun
things due to popular demand, technical
Iot, the reductions happen
due to well.
For some reason, it is not
opportune to expose
the IP fridges and military installations
when you have collaborators from the
United States.
Another nice thing we actually found in
our data set is TCP IP six
six, the number of the backplane, a six
six in this case as a placeholder
because for reasons I actually talked to
the CEO of that company before this talk
and they were like Nicaea, we
kind of know about this.
And I was like, cool, nice.
So I can talk about it. And they were
like, yeah, well with us.
So when
we are scanning some of the IP addresses
we collected, we would find the CCP port
being open on
hosts that would also
expose talent as Agent BGP and
some what looked like backbone links.
Funnily enough, the TCP people, which
should be on the slides was more
related to technology usually don't
find on a backbone router.
After some communication with a couple of
friends, we figured out that technically
this port should be bound to localhost on
the systems.
As it is used for some backplane
services, funny side
note, the vendor didn't even know how the
customers managed to get this post.
So then we have the HPV
six.
We all know the issues of mobile
devices that suddenly get IPV six
addresses and becomes unreachable.
My most favorite is where printers
and something you see a lot is that these
devices that are then exposed and that
are really vulnerable
actually do have
a four pointer for the end that
is returned for the basics.
Six address that points to an obviously
1918. So a private network address
other things you find as it mean.
So out of bank management and
various forms, what what you basically
use when everything burns down.
One really nice, nice large
operator actually has all their
Ifni interfaces reachable with ICMP
Version six,
which which make me wonder what would
happen, which I of course
didn't do. But well, it's
it's something I'm wondering about
because. Well,
you don't really want your it me on the
Internet and
also something for the people a little
bit more into network infrastructure
besides or exposed back planes.
Besides Oryx Postbag planes,
you will also find a lot of rip
out there, a lot of BGP and
talent, S.H.
of Internet infrastructure and Internet
backbone services.
Another fun thing to find is Tucker
on one part
is the nice things you can deploy a
stalker, for example, ElasticSearch.
It's really amazing who runs
ElasticSearch as a service
without authentication only reachable
via IPV six.
But reachable was IPV six for
Dukkha instances.
I don't know if you do know what these
TCAP ports mean for Dukkha installation.
This is actually an API,
which you have to protect this
information in the documentation, how you
can enable authentication.
There's actually a good blog post on how
you can enable authentication
using certificates and an
engine reverse proxy,
but you can also just expose it to the
Internet.
Well.
So this is just a set
of the opportunities you can have,
which you shouldn't have.
So besides actually doing the right
thing and doing firewall for you,
IPV six network, you could also do
something. Well,
security by obscurity,
you could try to configure a
reverse DNS zones in a way that always
returns are no data or no error,
basically masking them
to this.
It feels hard to say that this is an
attack. But basically to this,
um, this was already
available in 2012 when Fundi
first played with this.
There's tools available, not applicable
to all DNS service out there,
but the concept should be clear, so it
should be implementable.
On the other hand, we should think about
techniques that probably are applicable,
even the.
This specific technique I just presented
is not available,
so let's quickly conclude that
in the end you can try to reject
packets, but you cannot hide your network
topology.
You should think before setting PGR
records and
you should think before connecting things
to the Internet.
You can download my toolchain
from the Gottleib instance of my
research group, and
there is an academic publication coming
up in March 2017,
which is also dealing with this technique
on a more measurement related point of
view.
Thank you. And I'll be happy to answer
any questions that are.
Thank you very much indeed.
First question, as usually goes to the
signal, angel, did
you actually think about trying Deerness
Zone transferred to Civs Server would
give up a bunch of Pityana records
due to misconfiguration
using other techniques like Eigg.
The VA is discussed in the
research publication, but we didn't
actually try it.
Well, there's a Gedling.
OK, next question goes to the Mark Foley
number five.
Yeah, you got me lost.
Oh, sorry, you got me a little
bit here when you said that and
maybe correct me if I'm wrong, you
should run your own local DNS resolver
to get faster.
I don't know what.
And I'm kind of wondering, did
you use some kind of asynchronous
IO in order
like two to parallel your resolutions
instead of using a local resolver?
Or maybe I misunderstood what this
was solving. OK, so so running
a local resolver on the machine you're
doing the measurements on is
basically solving the issue of
overloading the local resolve.
Or if your research institution, having
your system administrator standing in
your office, being really angry,
you know, all these things that happen
when they suddenly have to deal with a
DNS precursor that is doing mostly
the queries you are doing and not those
of other people in the room or
research that you see.
So it's not improving the speed.
It actually helps a little bit speed
because either you do
the resolving yourself or
you put it somewhere else
and you basically have to wait for the
answers. So if you have a little bit of
latency towards your recasner,
the whole process will take longer.
If it's on your local machine, you
basically reduce one one small part of
latency.
But again, you can probably do this
better when you do the recurring and
resolving from the toolchain, which
I didn't do because I'm not a good
programmer.
OK, thank you.
Next question comes from number one.
OK, so did you
actually consider that there might be
a few servers hidden in
the those subnets who have these
generated BTR records?
Yes, there may be servers hidden in
there, but due to the
dynamically generated PDR records, I
cannot verify this without exhaustively
enumerating the whole well,
the whole tree, which
just gets really, really large.
OK, so you just there's like
the I don't know and I cannot know.
All right. Thank you.
OK, next question goes to my phone
number. Too high
from experience.
I found that AP physics
a reverse look ups are more
sparse than the AP
before versions.
So do you have a reference
on how many U.
Hosts you find with that technique
versus hosts that are there without
reverse? Look up.
I would really love to have that.
I also so basically, if you want
to make the statement, you just
basically ask for, you would have
to compare this data set
with another independent data set,
which looks at another
angle of IPV six, for example,
large AXP, for example,
CDN data set well to the
end. Data set will be biased for clients
and servers.
So most probably the ISP data set.
At the moment, I didn't have availability
of those, so I didn't investigate that.
OK, microphone number six,
you mentioned the results
or the data set of your work are
public. So where is it?
Is it.
Well, so it's
actually stored in a distributed manner
on a lot of DNS servers.
And as you know from all
cool platforms that there's a dedicated
download client you have to utilize,
download client source code is available
at that.
Get up, look at get that location.
OK, microphone number five.
Hello.
So quick question.
Most of the data on the slides were
sort of Western and
that male exploration and so on.
So just as a general
question, did you explore the IPV
six or so?
Did you explore a lot of this
on the Asian networks of South Korea,
China, which has massive IPV six
years because of the latency
thing? You know?
Actually, I didn't really
focus on a specific per
continent analysis
I mostly presented
so far and the academic work, the
technique in itself.
And I pick interesting case studies
that that would demonstrate the
potential of the technique.
But what you suggest is actually an
interesting point for further work.
I would, uh, for anyone interested
in that, I would recommend
Hong Kong as to the starting
point to do the scans
just.
OK, any more questions?
OK, thank you very much.
Thank.