Weekly Global IPv4 Routing Table Report

2022-01-28 Thread Routing Table Analysis Role Account
This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 29 Jan, 2022

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  887357
Prefixes after maximum aggregation (per Origin AS):  333907
Deaggregation factor:  2.66
Unique aggregates announced (without unneeded subnets):  426824
Total ASes present in the Internet Routing Table: 72715
Prefixes per ASN: 12.20
Origin-only ASes present in the Internet Routing Table:   62389
Origin ASes announcing only one prefix:   25723
Transit ASes present in the Internet Routing Table:   10326
Transit-only ASes present in the Internet Routing Table:371
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  53
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:   909
Number of instances of unregistered ASNs:   912
Number of 32-bit ASNs allocated by the RIRs:  38417
Number of 32-bit ASNs visible in the Routing Table:   31981
Prefixes from 32-bit ASNs in the Routing Table:  148775
Number of bogon 32-bit ASNs visible in the Routing Table:21
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:546
Number of addresses announced to Internet:   3069057792
Equivalent to 182 /8s, 238 /16s and 27 /24s
Percentage of available address space announced:   82.9
Percentage of allocated address space announced:   82.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  300224

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   233500
Total APNIC prefixes after maximum aggregation:   65661
APNIC Deaggregation factor:3.56
Prefixes being announced from the APNIC address blocks:  228240
Unique aggregates announced from the APNIC address blocks:93955
APNIC Region origin ASes present in the Internet Routing Table:   12316
APNIC Prefixes per ASN:   18.53
APNIC Region origin ASes announcing only one prefix:   3526
APNIC Region transit ASes present in the Internet Routing Table:   1721
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7502
Number of APNIC addresses announced to Internet:  774614912
Equivalent to 46 /8s, 43 /16s and 175 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:258031
Total ARIN prefixes after maximum aggregation:   118815
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   258096
Unique aggregates announced from the ARIN address blocks:123187
ARIN Region origin ASes present in the Internet Routing Table:18939
ARIN Prefixes per ASN:   

Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Mark Tinka



On 1/28/22 15:42, Mike Hammett wrote:

I also think the complexities, requirements, tolerances, etc. of an 
EPC are also being understated in the thread. The difference being is 
that I am aware (and stated as such) that I'm understating Netflix's 
usage. The other side doesn't know how particular EPCs can be.


I don't think we are understating the sensitives of the EPC... what we 
are likely understating is Amazon's ability to actually operate one. And 
I can see why...


Mark.

Re: [EXTERNAL] Re: Flow collection and analysis

2022-01-28 Thread Marcel Mitsuto
My colleagues developers started adding valid let's encrypt certs
everywhere. Now I have multiple NAT entry points for build-servers in my
VPC because of the renewal frequency.

I feel less secure with them adding valid SSL certs everywhere that runs on
a PRIVATE NETWORK.

It's just dumb reasoning, and the CTO agreed with them. They are all gone
by now, but their legacy remains.

Now I have to find all those certs and replace them with 10 year
self-signed, and add --no-check-certificates flags in their http client
requests.

All NAT entrypoints are gone.

I'm feeling safe now.

On Fri, 28 Jan 2022 at 13:26, Jean St-Laurent via NANOG 
wrote:

> Why DNS are still travelling in clear text?
>
> The software running the DNS services worldwide are probably written in C
> or any languages you mentioned below.
>
> Why don't they just strap a libressl on DNS or NanoSSL?
>
> Okay, there is DNS over https. I don't know the stats, but I doubt it's
> close to 100% adoption worldwide.
>
> I don't understand what is the issue about SSL, zero trust has anything to
> do about collecting flows. Do I need ssl to run shell commands in my
> terminal to read flows? Not really. Do I need to strap ssl on grep, notepad
> and excel? I'm not sure how could one do that.
>
> When you see the flows of your customers, you have access to how many
> times did they use Netflix, facebook and anything you could think of
> because these people are querying DNS to reach these... in clear text. They
> are also hitting servers that are well known.
>
> I would worry more about who is reading the flows of my business'
> customers than these flows being  not protected by SSL. They are anyway in
> a highly secure environment with zero trust.
>
> So if you don't like elastiflow or any software that are not being
> protected by SSL, then maybe switch off your computer. Protonmail won't
> help you to keep your digital life secure.
>
> This email was sent by a secure infrastructure using TLS 1.2 and clear
> text dns.
>
> Thank you
>
> Jean
>
> -Original Message-
> From: NANOG  On Behalf Of Laura
> Smith via NANOG
> Sent: January 28, 2022 5:15 AM
> To: Mel Beckman 
> Cc: nanog@nanog.org list 
> Subject: Re: [EXTERNAL] Re: Flow collection and analysis
>
> ‐‐‐ Original Message ‐‐‐
>
> On Friday, January 28th, 2022 at 03:55, Mel Beckman 
> wrote:
>
> > But nobody asked for anything from scratch Eric. Open SSL is it complete
> ready to integrate package. Any developer worth his salt should be able to
> put it on any web application. In addition to OpenSSL, there are very
> compact commercial SSL libraries such as Mocana NanoSSL and wolfSSL, if you
> want to really simplify the process.
> >
>
> Yup. Every single modern programming language out there has a crypto
> library.
>
> The high-level languages (e.g. Go) have crypto built into the standard
> library.
>
> The low-level languages (e.g C or Rust) all have at least one or more well
> supported third party crypto libraries (e.g. for C there's OpenSSL, GnuTLS,
> LibreSSL, Boring SSL, Mbed TLS ... and those are the ones that I can think
> of off the top of my head).
>
> There's no need to do any crypto "from scratch", and indeed you SHOULD NOT.
>
>


RE: [EXTERNAL] Re: Flow collection and analysis

2022-01-28 Thread Laura Smith via NANOG


‐‐‐ Original Message ‐‐‐

On Friday, January 28th, 2022 at 11:52, Jean St-Laurent  
wrote:

> Why DNS are still travelling in clear text?
>

It doesn't have to.  In 2022 there are many encryption options for DNS. There 
are also things like DNSSEC and DANE for ensuring authenticity over cleartext.

In addition, if the latest US Federal guidance is anything to go by, we may be 
witnessing the first big nail being put into the cleartext DNS coffin. 
(https://www.bastionzero.com/blog/i-read-the-federal-governments-zero-trust-memo-so-you-dont-have-to)




Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Mike Hammett
IIRC, *EVERYTHING* is in AWS, while their Open Connect deployments actually do 
the heavy lifting for the video content. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mark Tinka"  
To: nanog@nanog.org 
Sent: Friday, January 28, 2022 7:38:12 AM 
Subject: Re: What do you think about the "cloudification" of mobile? 



On 1/28/22 15:22, Josh Baird wrote: 

> I think Netflix's usage of AWS is being understated here. 

My understanding is that the user profiles and library listings are held 
with AWS, but that the actual video is on their OCA's. 

I could be wrong... 

Mark. 



Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Mike Hammett
I also think the complexities, requirements, tolerances, etc. of an EPC are 
also being understated in the thread. The difference being is that I am aware 
(and stated as such) that I'm understating Netflix's usage. The other side 
doesn't know how particular EPCs can be. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Josh Baird"  
To: "Mike Hammett"  
Cc: "Michael Thomas" , "nanog group"  
Sent: Friday, January 28, 2022 7:22:50 AM 
Subject: Re: What do you think about the "cloudification" of mobile? 


I think Netflix's usage of AWS is being understated here. 


On Fri, Jan 28, 2022 at 6:29 AM Mike Hammett < na...@ics-il.net > wrote: 




There's a big difference between a website (admittedly a complex one) and a 
mobile core. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Michael Thomas" < m...@mtcc.com > 
To: nanog@nanog.org 
Sent: Thursday, January 27, 2022 3:54:57 PM 
Subject: Re: What do you think about the "cloudification" of mobile? 


On 1/26/22 11:11 PM, Mark Tinka wrote: 
> 
> 
> On 1/26/22 17:10, Tom Beecher wrote: 
> 
>> 
>> Those folks also tend to learn hard lessons about what happens when 
>> the Magic Cloud provider fails in a way that isn't possible to 
>> anticipate because it's all black box. 
>> 
>> Saving 12 months of opex $ sounds great, except when you lose 18 
>> months of opex $ in 2 days completely outside of your ability to 
>> control. 
> 
> I don't disagree. 
> 
> What this does, though, is democratize access into the industry. For a 
> simple business model that is serving a small community with a handful 
> of eyeballs, not trying to grow forever but put food on the table, 
> it's somewhere to start. 
> 
Didn't Netflix for the longest time run on AWS? I imagine if I were 
talking to a VC these days and said the first thing I was going to do is 
rack up a bunch of servers, I'd get laughed at. Cloud makes sense until 
it doesn't make sense. Just like everything else. 

Mike 







Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Mark Tinka




On 1/28/22 15:22, Josh Baird wrote:


I think Netflix's usage of AWS is being understated here.


My understanding is that the user profiles and library listings are held 
with AWS, but that the actual video is on their OCA's.


I could be wrong...

Mark.


Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Mark Tinka



On 1/28/22 13:28, Mike Hammett wrote:

There's a big difference between a website (admittedly a complex one) 
and a mobile core.


Word is it hasn't been smooth-sailing, but Amazon are pushing on. 
Failing and improving is in their DNA, so I'm sure everyday, they are 
one step closer to the promised land.


Affirmed Networks, I believe, was their first engagement re: vEPC.

Mark.

Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Josh Baird
I think Netflix's usage of AWS is being understated here.

On Fri, Jan 28, 2022 at 6:29 AM Mike Hammett  wrote:

> There's a big difference between a website (admittedly a complex one) and
> a mobile core.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Michael Thomas" 
> *To: *nanog@nanog.org
> *Sent: *Thursday, January 27, 2022 3:54:57 PM
> *Subject: *Re: What do you think about the "cloudification" of mobile?
>
>
> On 1/26/22 11:11 PM, Mark Tinka wrote:
> >
> >
> > On 1/26/22 17:10, Tom Beecher wrote:
> >
> >>
> >> Those folks also tend to learn hard lessons about what happens when
> >> the Magic Cloud provider fails in a way that isn't possible to
> >> anticipate because it's all black box.
> >>
> >> Saving 12 months of opex $ sounds great, except when you lose 18
> >> months of opex $ in 2 days completely outside of your ability to
> >> control.
> >
> > I don't disagree.
> >
> > What this does, though, is democratize access into the industry. For a
> > simple business model that is serving a small community with a handful
> > of eyeballs, not trying to grow forever but put food on the table,
> > it's somewhere to start.
> >
> Didn't Netflix for the longest time run on AWS? I imagine if I were
> talking to a VC these days and said the first thing I was going to do is
> rack up a bunch of servers, I'd get laughed at. Cloud makes sense until
> it doesn't make sense. Just like everything else.
>
> Mike
>
>
>


RE: [EXTERNAL] Re: Flow collection and analysis

2022-01-28 Thread Jean St-Laurent via NANOG
Why DNS are still travelling in clear text?

The software running the DNS services worldwide are probably written in C or 
any languages you mentioned below.

Why don't they just strap a libressl on DNS or NanoSSL?

Okay, there is DNS over https. I don't know the stats, but I doubt it's close 
to 100% adoption worldwide.

I don't understand what is the issue about SSL, zero trust has anything to do 
about collecting flows. Do I need ssl to run shell commands in my terminal to 
read flows? Not really. Do I need to strap ssl on grep, notepad and excel? I'm 
not sure how could one do that.

When you see the flows of your customers, you have access to how many times did 
they use Netflix, facebook and anything you could think of because these people 
are querying DNS to reach these... in clear text. They are also hitting servers 
that are well known.

I would worry more about who is reading the flows of my business' customers 
than these flows being  not protected by SSL. They are anyway in a highly 
secure environment with zero trust.

So if you don't like elastiflow or any software that are not being protected by 
SSL, then maybe switch off your computer. Protonmail won't help you to keep 
your digital life secure.

This email was sent by a secure infrastructure using TLS 1.2 and clear text dns.

Thank you

Jean

-Original Message-
From: NANOG  On Behalf Of Laura Smith 
via NANOG
Sent: January 28, 2022 5:15 AM
To: Mel Beckman 
Cc: nanog@nanog.org list 
Subject: Re: [EXTERNAL] Re: Flow collection and analysis

‐‐‐ Original Message ‐‐‐

On Friday, January 28th, 2022 at 03:55, Mel Beckman  wrote:

> But nobody asked for anything from scratch Eric. Open SSL is it complete 
> ready to integrate package. Any developer worth his salt should be able to 
> put it on any web application. In addition to OpenSSL, there are very compact 
> commercial SSL libraries such as Mocana NanoSSL and wolfSSL, if you want to 
> really simplify the process.
>

Yup. Every single modern programming language out there has a crypto library.

The high-level languages (e.g. Go) have crypto built into the standard library.

The low-level languages (e.g C or Rust) all have at least one or more well 
supported third party crypto libraries (e.g. for C there's OpenSSL, GnuTLS, 
LibreSSL, Boring SSL, Mbed TLS ... and those are the ones that I can think of 
off the top of my head).

There's no need to do any crypto "from scratch", and indeed you SHOULD NOT.



Re: What do you think about the "cloudification" of mobile?

2022-01-28 Thread Mike Hammett
There's a big difference between a website (admittedly a complex one) and a 
mobile core. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Michael Thomas"  
To: nanog@nanog.org 
Sent: Thursday, January 27, 2022 3:54:57 PM 
Subject: Re: What do you think about the "cloudification" of mobile? 


On 1/26/22 11:11 PM, Mark Tinka wrote: 
> 
> 
> On 1/26/22 17:10, Tom Beecher wrote: 
> 
>> 
>> Those folks also tend to learn hard lessons about what happens when 
>> the Magic Cloud provider fails in a way that isn't possible to 
>> anticipate because it's all black box. 
>> 
>> Saving 12 months of opex $ sounds great, except when you lose 18 
>> months of opex $ in 2 days completely outside of your ability to 
>> control. 
> 
> I don't disagree. 
> 
> What this does, though, is democratize access into the industry. For a 
> simple business model that is serving a small community with a handful 
> of eyeballs, not trying to grow forever but put food on the table, 
> it's somewhere to start. 
> 
Didn't Netflix for the longest time run on AWS? I imagine if I were 
talking to a VC these days and said the first thing I was going to do is 
rack up a bunch of servers, I'd get laughed at. Cloud makes sense until 
it doesn't make sense. Just like everything else. 

Mike 




Re: [EXTERNAL] Re: Flow collection and analysis

2022-01-28 Thread Laura Smith via NANOG
‐‐‐ Original Message ‐‐‐

On Friday, January 28th, 2022 at 03:55, Mel Beckman  wrote:

> But nobody asked for anything from scratch Eric. Open SSL is it complete 
> ready to integrate package. Any developer worth his salt should be able to 
> put it on any web application. In addition to OpenSSL, there are very compact 
> commercial SSL libraries such as Mocana NanoSSL and wolfSSL, if you want to 
> really simplify the process.
>

Yup. Every single modern programming language out there has a crypto library.

The high-level languages (e.g. Go) have crypto built into the standard library.

The low-level languages (e.g C or Rust) all have at least one or more well 
supported third party crypto libraries (e.g. for C there's OpenSSL, GnuTLS, 
LibreSSL, Boring SSL, Mbed TLS ... and those are the ones that I can think of 
off the top of my head).

There's no need to do any crypto "from scratch", and indeed you SHOULD NOT.


Re: [EXTERNAL] Re: Flow collection and analysis

2022-01-28 Thread Laura Smith via NANOG
‐‐‐ Original Message ‐‐‐

On Wednesday, January 26th, 2022 at 14:49, heasley  wrote:
>
> confidentiality and integrity, even if you do not care about authentication.
>
> I am surprised that question is asked.
>

Indeed.

And to add the obvious to the obvious observation above, in certain industries 
and/or jurisdictions its effectively mandatory to encrypt the whole stack.

And that's before we start talking about the "modern" "Zero Trust" mentality 
(which incidentally is nothing new and has been around since at least 2004 with 
the Jericho Forum... but I guess "Zero Trust" sounds cooler).