Re: UCEPROTECT-NETWORK

[Bjoern Franke]

> Someone from please contact me offlist.
> 
> Thanks.
> 
> 

You want to appear on their cart00ney site?

Regards

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
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 http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 03 Jul, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  856005
Prefixes after maximum aggregation (per Origin AS):  323522
Deaggregation factor:  2.65
Unique aggregates announced (without unneeded subnets):  411204
Total ASes present in the Internet Routing Table: 71531
Prefixes per ASN: 11.97
Origin-only ASes present in the Internet Routing Table:   61536
Origin ASes announcing only one prefix:   25393
Transit ASes present in the Internet Routing Table:9995
Transit-only ASes present in the Internet Routing Table:317
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  55
Max AS path prepend of ASN ( 48366)  51
Prefixes from unregistered ASNs in the Routing Table:  1102
Number of instances of unregistered ASNs:  1108
Number of 32-bit ASNs allocated by the RIRs:  36518
Number of 32-bit ASNs visible in the Routing Table:   30342
Prefixes from 32-bit ASNs in the Routing Table:  141342
Number of bogon 32-bit ASNs visible in the Routing Table:26
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:523
Number of addresses announced to Internet:   3039747968
Equivalent to 181 /8s, 46 /16s and 223 /24s
Percentage of available address space announced:   82.1
Percentage of allocated address space announced:   82.1
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:  284965

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   229856
Total APNIC prefixes after maximum aggregation:   65794
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  225679
Unique aggregates announced from the APNIC address blocks:90541
APNIC Region origin ASes present in the Internet Routing Table:   11696
APNIC Prefixes per ASN:   19.30
APNIC Region origin ASes announcing only one prefix:   3326
APNIC Region transit ASes present in the Internet Routing Table:   1662
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6863
Number of APNIC addresses announced to Internet:  773655296
Equivalent to 46 /8s, 29 /16s and 11 /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-147769
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:249828
Total ARIN prefixes after maximum aggregation:   114073
ARIN Deaggregation factor: 2.19
Prefixes being announced from the ARIN address blocks:   249616
Unique aggregates announced from the ARIN address blocks:118884
ARIN Region origin ASes present in the Internet Routing Table:18850
ARIN Prefixes per ASN:13.24
ARIN 

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Michael Thomas]

People who are actually interested in this subject are well advised to 
read this thoroughly because it equally applies to SIP spam with a 
system far less complex and far fewer gaping security holes as STIR.


https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf

Mike

On 7/2/21 8:54 AM, Paul Timmins wrote:


Fun part is that just because it's a telnyx number with a checkmark, 
it doesn't mean the call came from Telnyx, just that the call came 
from a carrier that gave the call attestation A. As the carrier, we 
can see who signed the call (it's an x509 certificate, signed by the 
STI-PA, with the carrier's name and OCN in it) and hold them 
accountable for the traffic, which is huge.


But that's where the confusion will lie - a customer might say well 
this is a verizon wireless number, i'll yell at them! But the actual 
call came in through Lumen, and they're the ones who can stop it. A 
carrier can see the cert, but you can just get the verstat flag from 
the P-Asserted-Identity field in the call to the handset and see that 
it passed the tests for attestation A.


Just because you don't see a checkmark doesn't mean signatures aren't 
happening. Attestation B and C aren't displayed on the handset (but 
are seen in the carrier's systems) and most androids don't have a way 
to display stir/shaken stuff yet. T-Mobile doesn't send the verstat 
header to handsets they don't verify as s/s compliant (usually only 
ones they sell). My trick was to sim swap into an iphone for a day, 
then back to my android which started displaying the verification 
after that.


It's all new, but just because you don't see it doesn't mean it's not 
there. Report the calls to your carrier, they have new tools to track 
down the misbehavior.


On 7/2/21 8:32 AM, Nick Olsen wrote:
Not all have implemented it yet. But if you haven't. You were 
supposed to implement some kind of robo calling mitigation plan (Or 
atleast certify that you have one). At $dayjob we're fully deployed 
(inbound and outbound).


I received my first ever STIR/SHAKEN signed (iPhone Check mark, 
highly scientific) spam call on my personal Cell phone on 6/30. It 
was a Telnyx number. Had the call terminated to $dayjob network. I 
fully would have collected all various information and ticketed it 
with Telnyx.


Time will tell how truly effective this is. But we have better 
originating information now (breadcrumbs) to follow back to the source.


On Thu, Jul 1, 2021 at 5:42 PM Andreas Ott > wrote:




On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf
mailto:kmedc...@dessus.com>> wrote:

... and the end carrier is making money for terminating them. 



Survey (of n=1) says: nothing has changed, aka the new technology
is not working. I just received the same kind of recorded message
call of "something something renew auto warranty" on my AT
u-Verse line. This time when I called back the displayed caller
ID number it was ring-no-answer, versus the previous "you have
reached a number that is no longer in service". By terminating
the call the carrier made probably more money than it would cost
them to enforce the new rules.

Other than the donotcall.gov  portal, is
there a new way to report the obvious failure of STIR/SHAKEN?

-andreas

Re: Layer 2 based anycast - Kind like GLBP - Research

[Dobbins, Roland]

> On 2 Jul 2021, at 01:04, Douglas Fischer  wrote:
> 
> Answering suggestions in advance:

As others have pointed out, what you’re describing isn’t anycast, nor anything 
directly to do with high availability.

There are multiple well-understood frameworks which can be used to do what 
you’re describing.

This is strictly a layer-7 issue, nothing to do with layer-2 nor anycast.  
There’s no need to get down into the networking weeds to accomplish what you 
appear to be trying to accomplish.

Just do it all at layer-7.


Roland Dobbins 

Re: FreeBSD's ping Integrates IPv6

[Niels Bakker]

I just noticed (although it appears to have come in version 13.0) 
that FreeBSD's "ping" app now defaults to IPv6, i.e., no need for 
ping6:


* ra...@psg.com (Randy Bush) [Fri 02 Jul 2021, 18:48 CEST]:
pola breakage.  especially fun if you have tools which run on both 
sides of the koolaid.


On the one hand, yes. On the other hand, Linux had already made this 
change for ping specifically. Almost all other tools you'd use 
regularly are dual-stack by default that follow what's configured for 
the system to prefer (for FreeBSD that's ip6addrctl_policy): tools 
like telnet, ssh, mtr all follow the system default with -4 and -6 
command-line options to override the default if situationally needed. 
ping and traceroute were the only odd ones out, and now only 
traceroute is. I think this was an unavoidable change worth the 
temporary discomfort while tools using these tools are adjusted.



-- Niels.

Re: FreeBSD's ping Integrates IPv6

[Randy Bush]

> I just noticed (although it appears to have come in version 13.0) that
> FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6:

pola breakage.  especially fun if you have tools which run on both sides
of the koolaid.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Michael Thomas]

On 7/1/21 1:05 PM, Paul Timmins wrote:



On 7/1/21 3:53 PM, Keith Medcalf wrote:

And this is why this problem will not be solved.  The "open relay" is making money from processing 
the calls, and the end carrier is making money for terminating them.  Until fine(s) -- hopefully millions of 
them, one for each improperly terminated call, together with jail time for the CEO of the company for 
"conspiracy to commit fraud" --  and EACH of the fines is EQUAL OR GREATER than the total yearly 
worldwide REVENUE of that end carrier, they will not have any impetus to "fix" the problem.


How about 47 CFR 64.1200(k)(4)?

(4) A provider may block voice calls or cease to accept traffic from 
an originating or intermediate provider 
 
without liability under the Communications Act or the Commission's 
rules where the originating or intermediate provider 
, 
when notified by the Commission, fails to effectively mitigate illegal 
traffic within 48 hours or fails to implement effective measures to 
prevent new and renewing customers 
 
from using its network to originate illegal calls. Prior to initiating 
blocking, the provider shall provide the Commission with notice and a 
brief summary of the basis for its determination that the originating 
or intermediate provider 
 
meets one or more of these two conditions for blocking.


ie: "You're not really a phone company anymore, says the rest of the PSTN"

https://www.law.cornell.edu/cfr/text/47/64.1200

Those who fail to understand the Usenet Death Penalty are doomed to 
(not) repeat it.


Mike

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Paul Timmins]

Fun part is that just because it's a telnyx number with a checkmark, it 
doesn't mean the call came from Telnyx, just that the call came from a 
carrier that gave the call attestation A. As the carrier, we can see who 
signed the call (it's an x509 certificate, signed by the STI-PA, with 
the carrier's name and OCN in it) and hold them accountable for the 
traffic, which is huge.


But that's where the confusion will lie - a customer might say well this 
is a verizon wireless number, i'll yell at them! But the actual call 
came in through Lumen, and they're the ones who can stop it. A carrier 
can see the cert, but you can just get the verstat flag from the 
P-Asserted-Identity field in the call to the handset and see that it 
passed the tests for attestation A.


Just because you don't see a checkmark doesn't mean signatures aren't 
happening. Attestation B and C aren't displayed on the handset (but are 
seen in the carrier's systems) and most androids don't have a way to 
display stir/shaken stuff yet. T-Mobile doesn't send the verstat header 
to handsets they don't verify as s/s compliant (usually only ones they 
sell). My trick was to sim swap into an iphone for a day, then back to 
my android which started displaying the verification after that.


It's all new, but just because you don't see it doesn't mean it's not 
there. Report the calls to your carrier, they have new tools to track 
down the misbehavior.


On 7/2/21 8:32 AM, Nick Olsen wrote:
Not all have implemented it yet. But if you haven't. You were supposed 
to implement some kind of robo calling mitigation plan (Or atleast 
certify that you have one). At $dayjob we're fully deployed (inbound 
and outbound).


I received my first ever STIR/SHAKEN signed (iPhone Check mark, highly 
scientific) spam call on my personal Cell phone on 6/30. It was a 
Telnyx number. Had the call terminated to $dayjob network. I fully 
would have collected all various information and ticketed it with Telnyx.


Time will tell how truly effective this is. But we have better 
originating information now (breadcrumbs) to follow back to the source.


On Thu, Jul 1, 2021 at 5:42 PM Andreas Ott > wrote:




On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf mailto:kmedc...@dessus.com>> wrote:

... and the end carrier is making money for terminating them. 



Survey (of n=1) says: nothing has changed, aka the new technology
is not working. I just received the same kind of recorded message
call of "something something renew auto warranty" on my AT
u-Verse line. This time when I called back the displayed caller ID
number it was ring-no-answer, versus the previous "you have
reached a number that is no longer in service". By terminating the
call the carrier made probably more money than it would cost them
to enforce the new rules.

Other than the donotcall.gov  portal, is
there a new way to report the obvious failure of STIR/SHAKEN?

-andreas

Re: FreeBSD's ping Integrates IPv6

[Mark Tinka]

On 7/2/21 16:12, Patrick Cole wrote:

Mark,

iputils-ping on linux seems to behave the same for quite some time...

[z@tyl][~] % host ns0
ns0.spirit.net.au has address 27.113.240.197
ns0.spirit.net.au has IPv6 address 2403:3600:8002::100

[z@tyl][~] % ping ns0
PING ns0(2403:3600:8002::100 (2403:3600:8002::100)) 56 data bytes
64 bytes from 2403:3600:8002::100 (2403:3600:8002::100): icmp_seq=1 ttl=63 
time=0.344 ms
64 bytes from 2403:3600:8002::100 (2403:3600:8002::100): icmp_seq=2 ttl=63 
time=0.447 ms


Thanks for the feedback, Patrick. This is great!

This led me to test the same on the family Windows 10 (21H1 version) 
machine, and Microsoft are doing the same, which is great to see.


Mark.

Re: FreeBSD's ping Integrates IPv6

[Mark Tinka]

On 7/2/21 16:22, Niels Bakker wrote:



Yes, this broke some of my home network monitoring. Sadly there is no 
'ping4' in the system, you have to add -4 to the commandline to return 
to the common BSD behaviour.


This is a good point, as it's the same reason I discovered this today. A 
transient IPv6 issue on a specific host broke NTP, and when I tried to 
ping the NTP time servers during troubleshooting, it hang for a while 
because IPv6 was broken.


Mark.

Re: FreeBSD's ping Integrates IPv6

[Niels Bakker]

* mark@tinka.africa (Mark Tinka) [Fri 02 Jul 2021, 16:02 CEST]:
I just noticed (although it appears to have come in version 13.0) that 
FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6:


Yes, this broke some of my home network monitoring. Sadly there is no 
'ping4' in the system, you have to add -4 to the commandline to return 
to the common BSD behaviour.



-- Niels.

Re: FreeBSD's ping Integrates IPv6

[Patrick Cole]

Mark, 

iputils-ping on linux seems to behave the same for quite some time...

[z@tyl][~] % host ns0 
ns0.spirit.net.au has address 27.113.240.197
ns0.spirit.net.au has IPv6 address 2403:3600:8002::100

[z@tyl][~] % ping ns0  
PING ns0(2403:3600:8002::100 (2403:3600:8002::100)) 56 data bytes
64 bytes from 2403:3600:8002::100 (2403:3600:8002::100): icmp_seq=1 ttl=63 
time=0.344 ms
64 bytes from 2403:3600:8002::100 (2403:3600:8002::100): icmp_seq=2 ttl=63 
time=0.447 ms


-PC

Fri, Jul 02, 2021 at 04:00:16PM +0200, Mark Tinka wrote:


>Hi all.
> 
>I just noticed (although it appears to have come in version 13.0) that
>FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6:
> 
>    https://www.freebsd.org/cgi/man.cgi?query=ping=8=html
> 
>Does anyone know whether other *nix systems are doing this now?
> 
>My Mac (Catalina) still requires ping6, and I don't have any recent Linux
>systems handy.
> 
>#ThisIsGood
> 
>Mark.

-- 
Patrick Cole 
Chief Architect
Spirit Technology Solutions
19-25 Raglan St, South Melbourne VIC 3205
Desk:0385541391
Mobile:  0410626630

FreeBSD's ping Integrates IPv6

[Mark Tinka]

Hi all.

I just noticed (although it appears to have come in version 13.0) that 
FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6:


https://www.freebsd.org/cgi/man.cgi?query=ping=8=html

Does anyone know whether other *nix systems are doing this now?

My Mac (Catalina) still requires ping6, and I don't have any recent 
Linux systems handy.


#ThisIsGood

Mark.

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Nick Olsen]

Not all have implemented it yet. But if you haven't. You were supposed to
implement some kind of robo calling mitigation plan (Or atleast certify
that you have one). At $dayjob we're fully deployed (inbound and outbound).

I received my first ever STIR/SHAKEN signed (iPhone Check mark, highly
scientific) spam call on my personal Cell phone on 6/30. It was a Telnyx
number. Had the call terminated to $dayjob network. I fully would have
collected all various information and ticketed it with Telnyx.

Time will tell how truly effective this is. But we have better
originating information now (breadcrumbs) to follow back to the source.

On Thu, Jul 1, 2021 at 5:42 PM Andreas Ott  wrote:

>
>
> On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf  wrote:
>
>> ... and the end carrier is making money for terminating them.
>
>
> Survey (of n=1) says: nothing has changed, aka the new technology is not
> working. I just received the same kind of recorded message call of
> "something something renew auto warranty" on my AT u-Verse line. This
> time when I called back the displayed caller ID number it was
> ring-no-answer, versus the previous "you have reached a number that is no
> longer in service". By terminating the call the carrier made probably more
> money than it would cost them to enforce the new rules.
>
> Other than the donotcall.gov portal, is there a new way to report the
> obvious failure of STIR/SHAKEN?
>
> -andreas
>

Moo fiber cleaner needed near London equinix ld5

[Tony McCrory]

Any suggestions for local purchase of a mpo fiber cleaner near equinix
London ld5?

Much appreciated 

Re: Layer 2 based anycast - Kind like GLBP - Research

[Masataka Ohta]

Douglas Fischer wrote:


Yes... It probably solves my issues on a v6 only world.


No, not at all.

I'm afraid you don't understand what your issues are.

At least, neither L2 or L3 anycast has anything to do with
high reliability because reachability to a server and
availability of the server are different things.

Masataka Ohta

RE: Layer 2 based anycast - Kind like GLBP - Research

[Jean St-Laurent via NANOG]

Maybe a spine and leaf architecture could work for you. 

 

You could install 1 server per leaf or more. I believe this could achieve 
high-availability and load-balancing at layer 2.

 

There is a kind of layer 3 overlay, but for the hosts this is transparent and 
it feels like a real pure layer 2. 

 

I would go that route as it is also a very common setup these days. It scales 
well horizontally and no active/passive. It’s just 
active/active/active/active…./active.

 

Jean

Re: Layer 2 based anycast - Kind like GLBP - Research

[Douglas Fischer]

Hello William!

An ARP Controller to compose a L2 Cluster solution seems a good Idea to a
begging...
(I would include ND)

I will try to think a bit on that...

Any suggestions are welcome.

Em qui., 1 de jul. de 2021 às 16:06, William Herrin 
escreveu:

> On Thu, Jul 1, 2021 at 11:05 AM Douglas Fischer
>  wrote:
> > I'm looking for solutions do deploy some type of selective high
> availability and load balance based on the glue between Layer 2 and Layer 3
> (ARP or ND).
>
> Hi Douglas,
>
> Anycast is where you send to one network address and the "nearest"
> single server with that address receives the packet.
>
> By definition, every piece of equipment in an L2 broadcast domain is
> exactly one hop from every other -- no equipment is "nearer." So
> conceptually, there is no anycast.
>
> However, L2 domains aren't built with hubs any more; they're built
> with switches. There actually are variable distances between
> equipment, they're just not expressed in the protocols. So, in theory
> you could build an SDN controller for your switches which sets up
> different FIB entries in each switch to select which port receives the
> traffic for the designated "anycast" mac address. But you may face
> limitations where the hardware can't reasonably be programmed to give
> each port its own FIB allowing fine-grained control of which client
> reaches which server.
>
> Realistically... that approach would tend to be both expensive to
> build and very brittle. There's almost certainly a better way to
> accomplish your goal than trying to invent L2 anycast.
>
> If you're load balancing IP traffic, another approach might be a
> custom ARP controller which responds to ARP requests with different
> MAC addresses depending on the request source. There's no guaranteed
> timeout for ARP bindings but if you shared around a pool of MAC
> addresses guaranteeing that every MAC address in the pool gets
> assigned to a currently-working server it could work. You just have to
> keep in mind that gratuitous arp absolutely would not work in this
> sort of scenario so you have to have a plan for switching loads
> between servers without it.
>
> I don't think anybody has built that sort of arp controller (at least
> I haven't heard of one) so you'd have to invent it yourself.
>
> From what I understand of EVPN, it's about creating something
> equivalent to VLANs across a distributed virtual server
> infrastructure. Basically like what Amazon does under the hood for its
> virtual private cloud. Since you're trying to get the machines to
> appear on the same subnet, not separate them to different subnets, I
> don't think it's what you're looking for.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: Layer 2 based anycast - Kind like GLBP - Research

[Douglas Fischer]

Hello Masataka!

Yes... It probably solves my issues on a v6 only world.
But unfortunately, in this scenario there is IPv4 also, and to make me cry
alone in the bathroom there are some IPv4 only...
So, I will need to provide some solution that covers IPv4 also.


Em qui., 1 de jul. de 2021 às 19:51, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> escreveu:

> Douglas Fischer wrote:
>
> > I'm looking for solutions do deploy some type of selective high
> > availability and load balance based on the glue between Layer 2 and
> Layer 3
> > (ARP or ND).
>
> If you are looking for L2 anycast, it was purposelessly
> invented as a functionality of ND, though it does not
> satisfy your requirements. See rfcs 2461 and 4861.
>
> Glad to know it is totally ignored by most, if not all.
>
> Masataka Ohta
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação