Re: AFRINIC: The Saga Continues

[Ronald F. Guilmette]

In message , 
Dan Hollis  wrote:

>What can or should be done when a registry goes rogue?

Answering that question is a task which is above my pay grade.  I would
be remiss however if I did not take this opportunity to make a few brief
and relevant points.

*)  There are other and additional shoes yet to drop with respect to
AFRINIC.  I am not free to go into more details regarding that assertion
at this time.

*)  It is implausible on the face of it that only one AFRINIC insider was
stealing all of this stuff and spiriting it all out the backdoor at midnight
while all other AFRINIC employees, management, and board were entirely
clueless and totally in the dark about the fact that any of this was going
on, right under their own roof and right under their noses.  And I have
some not-entirely-speculative reasons to believe that others were involved.

*)  Throughout my investigation, AFRINIC officials and board members have,
almost without exception, avoided answering many simple and relevant
questions regarding this and other matters, even when the questions quite
obviously do not have any relevance whatsoever to AFRINIC's contractual
confidentiality commitments to its member organizations.  If you ask
AFRINIC what time of day it is, they will tell you that that is covered
under an NDA, and that thus, they can't tell you.

It really is almost that bad, and there appears to me to be a pervasive
culture of secrecy within the organization which effectively thwarts
reasonable inquiry and any and all outside accountability.  This appeared
to me to be the case even well before AFRINIC became fully aware of
the activities of their rogue employee, and now, the existance of what
is supposedly a serious police inquiry by the crack Mauritian police
investigators is being used as a basis for AFRINIC to answer even fewer
questions than before, since the whole matter is now said to be "under 
police investigation".

(It is left as an exercise for the reader to deduce whether or not the
high-tech crimes investigative unit of the Mauritian national police is
at all likely to obtain or expose more answers in this case than I and
journalist Jan Vermeulen already have done.  In estimating the odds of
that, it may be of value to keep in mind that the entire nation of
Mauritius, known primarily for sunny beaches and tax avoidance schemes,
has a total population of slighty less than the city of Dallas, Texas.)

*) Ever since the publication of Jan Vermeulen's first article on this
matter on September 1, 2019, it has been alleged that AFRINIC has been
conducting its own internal investigation.  More recently Jan has learned
that AFRINIC's internal investigation may have actually started much
earlier, in April of 2019.  In all this time, neither anyone from AFRINIC
nor anyone from the Mauritian national police have made any effort to ask
either Jan or myself what, if anything, we know about these matters that
has not yet appeared in print.  If they had asked, as part of their
"internal investigation", we could have told them some things. They never
asked.

*)  Entirely separate from the matter of the looting of IPv4 resources
from AFRINIC, it was announced some time ago the AFRINIC's auditor of
many years, PriceWaterhouseCoopers (PwC), has effectively fired its client,
AFRINIC, for reasons that have yet to be revealed, either to the AFRINIC
membership or to the public at large.  This is the same accounting firm
that has been named in numerous recent press reports as having possibly
played some role in the large scale looting of the state coffers of the
southern African country of Angola:

https://www.nytimes.com/2020/01/19/world/africa/isabel-dos-santos-angola.html

https://www.theguardian.com/world/2020/jan/23/pwc-growing-scrutiny-isabel-dos-santos-scandal-luanda-leaks-angola

https://www.icij.org/investigations/luanda-leaks/pwc-head-shocked-and-disappointed-by-luanda-leak-revelations/

This raises the almost unavoidable question:  How bad must AFRINIC's books
be in order to cause even the likes of PriceWaterhouseCoopers to walk away
from their client, AFRINIC, after so many years?  And what is it in those
books that AFRINIC and its board would prefer everyone not know about?

*)  At the present time, and reportedly even well before Jan Vermeulen's
September 1st article which suggested, unambiguously, that there was
something rotten going on within AFRINIC, AFRINIC has been allegedly
endeavoring to investigate itself.  I problems with that are, I believe,
self-evident to any unbiased observer.

I personally have no faith that the full truth or the full facts relating
either to the IPv4 pilfering or to the other and unrelated accounting
issues, whatever they may be, are at all likely to emerge from AFRINIC's
investigation of itself.  Furthermore, I believe that this is itself
considered by the AFRINIC board to be a feature rather than a bug.

If anyone were seriously motivated to get to the full truth of these matters
then the 

Re: abrupt speed changes and TCP

[Peter Beckman]

I'd hope that the 4G and 5G radios might operate in such a way that it
would intelligently manage packets coming from either radio and, when
possible, seemlessly merge them virtually and then pass them to the
underlying OS stack. Or have the OS do it.

Maybe this is why the rollout of 5G is slow as the carriers and handset
manufacturers figure out the issues of jumping between 4G and 5G networks.
It may be why Apple decided to hold off on 5G in September 2019.

Didn't they figure this out between 3G and LTE/4G? Or was it not a problem?
And maybe it won't be a problem?

On Thu, 30 Jan 2020, Ahmed Borno wrote:


I am only guessing here, but I think the Apps of today would have their own
built in mechanisms to work around lower layers, starting with DB query
timeouts, load balancers performance based resets. CDN segmentation, QUIC,
HTTP2etc

But it is a valid question and I'd like to know from people with real
experience in TCP performance impact of 4 to 5G switching.

~A

On Thu, Jan 30, 2020 at 10:59 AM Michael Thomas  wrote:



So it occurs to me in the rollout of 5G just walking down the street you
might shift back and forth between high speed 5G bands and 4G because of
uneven deployment and all sorts of other reasons. It sounds like this
could vary block by block practically.

I assume TCP just views this as congestion? But with all of the
congestion avoidance algorithms and the rapidly fluctuating bandwidth,
wouldn't that result in the sender essentially adapting to the least
common denominator (eg 4G)? The same goes with latency, I suppose for
real time apps.

Mike






---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: The curious case of 159.174.0.0/16

[Large Hadron Collider]

Could not have worded it better myself.

On Wed, 29 Jan 2020 16:30:22 +
Mel Beckman  wrote:

> Then why are you sending email to nanog@nanog.org?
>
> LOL!
>
>  -mel
>
> > On Jan 29, 2020, at 12:41 AM, Ronald F. Guilmette  
> > wrote:
> >
> > I have a standing policy of never attempting to converse with unaccountable
> > anonymized role accounts.  Based on past experience, this is without
> > exception an utter waste of my time.


--
Large Hadron Collider 

Re: Backup over 4G/LTE

[Shawn Ritchie]

Yes, the 510 has LTE options for both North American and Asian frequencies 
(separate boxes).

They can hold 2 SIMs but only one can be active at a time. 

--
Shawn




On Wed, Jan 29, 2020, at 8:44 PM, Colton Conor wrote:
> Does Velcloud make an actual LTE box? 
> 
> On Wed, Jan 29, 2020 at 6:44 AM K. Scott Helms  wrote:
>> There are lots of options to solve that problem. 
>> 
>> Peplink, 128T, Viptela (Cisco), Velocloud (VMWare), etc.
>> 
>> Scott Helms
>> 
>> 
>> On Tue, Jan 28, 2020 at 6:31 PM K MEKKAOUI  wrote:
>>> Dear NANOG Community,

>>> __ __

>>> Can anyone help with any device information that provides redundancy for 
>>> business internet access? In other words when the internet provided through 
>>> the cable modem fails the 4G/LTE takes over automatically to provide 
>>> internet access to the client.

>>> __ __

>>> Thank you

>>> __ __

>>> KARIM M.

>>> __ __

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Jean | ddostest.me via NANOG]

I'm a bit confused as I thought it was the other way around.

No big deal though. So these SYN don't have options which is not normal 
today. It was in the previous millenium. You should see more options.


What you can do is filter SYN based on packet length. 54 bytes is your 
signature here. The hacker is using hping3 or some basic rudimentary tools.


Cheers

Jean

On 2020-01-28 16:41, Octolus Development wrote:

Yes, my server would then respond with RST.

Screenshot: https://i.imgur.com/ZVti2yY.png

We've blocked outgoing RST, 136.244.67.19 was our test server.

But even if the ip is not even exposed to the internet, services will 
blacklist us. Even if we don't respond, and block every request from 
the internet incoming & outgoing.


On 28.01.2020 22:36:18, "Jean | ddostest.me via NANOG" 
 wrote:


But you do receive the SYN/ACK?

The way to open a TCP socket is the 3 way handshake. Sorry to write 
that here... I feel it's useless.


1. SYN

2. SYN/ACK

3. ACK

Step 1: So hackers spoof the original SYN with your source IP of your 
network.


Step 2: You should then receive those SYN/ACK packets with your 
network as the dst ip and SONY as the src ip. Can you catch a few and 
post the TCP flags that you see please? (This is step 2)


You don't need sony or imperva for that. Just a sniffer at the right 
place in your network. You won't block anything, but we should see 
something  very interesting that will help you fix this.


If it is happening like you  are describing, you should see those 
packets and you should be able to capture them.


No worries if you can't.

Jean

On 2020-01-28 11:31, Octolus Development wrote:

I have tried numerous of times to reach out to Imperva.

Imperva said Sony have to contact them & said they cannot help me 
because I am not a customer of theirs.
Something Sony will not do. Sony simply stopped responding my emails 
after some time.


But yes you are right.

My IP's are being spoofed, spoofing SYN requests to hundreds of 
thousands of web servers. Which then results in a blacklist, that 
Imperva uses.. which prevents me and my clients from accessing 
Sony's services.. because they use Imperva.


On 28.01.2020 17:29:12, Tom Beecher  wrote:

Trying to summarize here, this convo has been a bit disjointed.

Is this an accurate summary?

- The malicious traffic with spoofed sources is targeting multiple 
different destinations.
- The aggregate of all those flows is causing Impervia to flag your 
IP range as a bad actor.
- Sony uses Impervia blacklists, and since Impervia has flagged 
your space as bad, Sony is blocking you.


If that is true, my advice would be to go right to Impervia. 
Explain the situation, and ask for their assistance in identifying 
and or/reaching out to the networks that they are detecting this 
spoofed traffic coming from. The backscatter, as Jared said 
earlier, could probably help you a bit too, but Impervia should be 
willing to assist. It's in their best interests to not have false 
positives, but who knows.


On Tue, Jan 28, 2020 at 6:17 AM Octolus Development 
mailto:ad...@octolus.net>> wrote:


The problem is that they are spoofing our IP, to millions of
IP's running port 80.
Making upstream providers filter it is quite difficult, i don't
know all the upstream providers are used.

The main problem is honestly services that reports SYN_RECV as
Port Flood, but there isn't much one can do about misconfigured
firewalls.I am sure there is a decent amount of honeypots on
the internet acting the same way, resulting us (the victims of
the attack) getting blacklisted for 'sending' attacks.


On 28.01.2020 05:50:14, "Dobbins, Roland"
mailto:roland.dobb...@netscout.com>> wrote:




On Jan 28, 2020, at 11:40, Dobbins, Roland
mailto:roland.dobb...@netscout.com>> wrote:

And even if his network weren't on the receiving end of a
reflection/amplification attack, OP could still see
backscatter, as Jared indicated.


In point of fact, if the traffic was low-volume, this might in
fact be what he was seeing.



Roland Dobbins mailto:roland.dobb...@netscout.com>>

Re: AFRINIC: The Saga Continues

[Dan Hollis]

On Wed, 29 Jan 2020, Ronald F. Guilmette wrote:

In all cases noted below, the networks in question are unambiguously routing IP
blocks that were obtained, in the first instance, via thefts perpetrated
by one or more AFRINIC insiders and then resold on the black market
in secretive deals.


What can or should be done when a registry goes rogue?

-Dan

Re: abrupt speed changes and TCP

[Michael Thomas]

On 1/30/20 11:46 AM, William Herrin wrote:

On Thu, Jan 30, 2020 at 10:58 AM Michael Thomas  wrote:

So it occurs to me in the rollout of 5G just walking down the street you
might shift back and forth between high speed 5G bands and 4G because of
uneven deployment and all sorts of other reasons. It sounds like this
could vary block by block practically.

I assume TCP just views this as congestion? But with all of the
congestion avoidance algorithms and the rapidly fluctuating bandwidth,
wouldn't that result in the sender essentially adapting to the least
common denominator (eg 4G)? The same goes with latency, I suppose for
real time apps.

Hi Mike,

TCP speed is about two things: round trip time and packet loss.

If the round trip time gets long and then gets short again, TCP will
immediately adjust. It doesn't much care about the clock time, it
cares about whether it has received the ack it was looking for.

When packets are lost... trouble. TCP starts with 10 packets, waits
for an ack, doubles to 20 packets, waits for an ack, doubles to 40
packets, etc. This is called the congestion window and that early
phase is called "slow start." When the first packet is lost, that
doubling growth stops hard. Slows down to one or two additional
packets per round trip time. Then there's later packet loss.. get very
much and the congestion window starts halving and only growing pack at
a packet or two per round trip time. So if you drop packets switching
back and forth between 4G and 5G, that TCP connection will slow to a
crawl.

And just for fun: packet reordering is often interpreted as packet
loss. So if your 5G packet beats your earlier 4G packet to the
destination, it's as if you lost a packet.




I kinda hope that Fred will chime in here because he's usually clued in
about research stuff. I suppose at some level we've been here with the
transition between 3 and 4G, but streaming, etc were a lot less common
then. So do you think it would effectively settle into the least common
denominator or would it be an ongoing cluster fuck?

Mike

Re: abrupt speed changes and TCP

[Ahmed Borno]

I am only guessing here, but I think the Apps of today would have their own
built in mechanisms to work around lower layers, starting with DB query
timeouts, load balancers performance based resets. CDN segmentation, QUIC,
HTTP2etc

But it is a valid question and I'd like to know from people with real
experience in TCP performance impact of 4 to 5G switching.

~A

On Thu, Jan 30, 2020 at 10:59 AM Michael Thomas  wrote:

>
> So it occurs to me in the rollout of 5G just walking down the street you
> might shift back and forth between high speed 5G bands and 4G because of
> uneven deployment and all sorts of other reasons. It sounds like this
> could vary block by block practically.
>
> I assume TCP just views this as congestion? But with all of the
> congestion avoidance algorithms and the rapidly fluctuating bandwidth,
> wouldn't that result in the sender essentially adapting to the least
> common denominator (eg 4G)? The same goes with latency, I suppose for
> real time apps.
>
> Mike
>
>

Re: abrupt speed changes and TCP

[William Herrin]

On Thu, Jan 30, 2020 at 10:58 AM Michael Thomas  wrote:
> So it occurs to me in the rollout of 5G just walking down the street you
> might shift back and forth between high speed 5G bands and 4G because of
> uneven deployment and all sorts of other reasons. It sounds like this
> could vary block by block practically.
>
> I assume TCP just views this as congestion? But with all of the
> congestion avoidance algorithms and the rapidly fluctuating bandwidth,
> wouldn't that result in the sender essentially adapting to the least
> common denominator (eg 4G)? The same goes with latency, I suppose for
> real time apps.

Hi Mike,

TCP speed is about two things: round trip time and packet loss.

If the round trip time gets long and then gets short again, TCP will
immediately adjust. It doesn't much care about the clock time, it
cares about whether it has received the ack it was looking for.

When packets are lost... trouble. TCP starts with 10 packets, waits
for an ack, doubles to 20 packets, waits for an ack, doubles to 40
packets, etc. This is called the congestion window and that early
phase is called "slow start." When the first packet is lost, that
doubling growth stops hard. Slows down to one or two additional
packets per round trip time. Then there's later packet loss.. get very
much and the congestion window starts halving and only growing pack at
a packet or two per round trip time. So if you drop packets switching
back and forth between 4G and 5G, that TCP connection will slow to a
crawl.

And just for fun: packet reordering is often interpreted as packet
loss. So if your 5G packet beats your earlier 4G packet to the
destination, it's as if you lost a packet.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Backup over 4G/LTE

[Brian Knight]

In the past couple of years, we deployed CradlePoint IBR650's and
IBR600's (with and without wifi respectively).  It's a configurable
mini-router that can also accept wired access.  There is an on-board SIM
slot.  Downside is that the unit is a bit expensive as a CPE. 

Lately we have been deploying Proxicast PocketPort units.  These have an
RJ45 jack at one end, USB port on the other, with no built-in cell
antenna.  So you'll need a USB 4G/LTE dongle in addition.  Those
PocketPorts are a bit more limited in terms of config, but they work for
our use case and are less expensive overall than CradlePoint. 

If you want to stick with a router from big C, I've also worked with the
newer C-8PLTEEA which has an onboard SIM slot.  We tested them but
didn't put them in production due to cost. 

HTH! 

-Brian 

On 2020-01-28 17:30, K MEKKAOUI wrote:

> Dear NANOG Community, 
> 
> Can anyone help with any device information that provides redundancy for 
> business internet access? In other words when the internet provided through 
> the cable modem fails the 4G/LTE takes over automatically to provide internet 
> access to the client. 
> 
> Thank you 
> 
> KARIM M.

[NANOG-announce] NANOG 78 is less than 2 weeks away!

[NANOG Marketing]

*View the agenda, meet our keynote speakers, register to hack, get social,
discover what to do + see in San Francisco, and more! *

*The NANOG 78 agenda is now LIVE*
Are you as ready as we are for San Francisco? Scope out the complete
peer-reviewed
program  of talks, tutorials,
keynotes, and panels at our next community-wide gathering, February 10-12.

*Meet our keynote speakers *
Amin Vahdat, Engineering Fellow + Vice President of Systems Infrastructure
at Google, and Bikash Koley, VP of Global Networking at Google, will both
deliver keynote presentations at NANOG 78. Learn more
 about Vahdat and
Koley + view their keynote abstracts, slated for Mon, 2/10 + Tue, 2/11.

*NANOG 78 lightning talks*
Have a topic that's timely? Interesting data? Spur-of-the-moment idea?
Lightning Talks are the perfect way to share your thoughts + findings with
a wider audience. Our full-length CFP is now closed, but you can submit a
10-min talk to the Program Committee starting February 9! Visit our NANOG
78 presentations page
 to start
prepping yours now.

*Get ready to hack! *
Learn alongside some of the brightest networking minds from Verizon Media +
Tesuto + the greater NANOG community at the NANOG 78 Hackathon! The hack
kicks off on Sunday, February 9. And as always, participation is FREE and
open to all. Register Now 

*Play a role in shaping NANOG's future*
Our success depends on the collective expertise of our members to help
guide us in service of NANOG's mission. Every conference includes
opportunities to share your thoughts and ideas with the greater NANOG
community, like the NANOG Member’s Meeting, Community Meeting, Newcomers
Lunch, and Women in Tech Lunch — learn more
 via the NANOG 78 agenda!

*Let's get SOCIAL *
NANOG conferences are just as much about network engineering as they are
about making new friends + catching up with old ones. Check out the full lineup
of socials  in
San Francisco, including Beer 'N Gear, #BeersWithPeers sponsored by
EdgeConneX, and the Monday-Night Social sponsored by NANOG.

*In + Around San Francisco*
"Amoeba Music (1855 Haight St.) in the Upper Haight near Golden Gate Park,
is the place to go for indie records, cds, dvds, and other rare recordings.
Closer in, Japantown's Western Addition features a Kinokuniya book store,
and many authentic Japanese shops and restaurants," says Leigh Brooks,
NANOG Senior Designer + former San Francisco resident.

Wondering what else to do + see while you're in The City by the Bay? Check
out the insider recs
 of two NANOG
staffers with a fondness for San Fran.
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

abrupt speed changes and TCP

[Michael Thomas]

So it occurs to me in the rollout of 5G just walking down the street you 
might shift back and forth between high speed 5G bands and 4G because of 
uneven deployment and all sorts of other reasons. It sounds like this 
could vary block by block practically.


I assume TCP just views this as congestion? But with all of the 
congestion avoidance algorithms and the rapidly fluctuating bandwidth, 
wouldn't that result in the sender essentially adapting to the least 
common denominator (eg 4G)? The same goes with latency, I suppose for 
real time apps.


Mike

RE: Backup over 4G/LTE

[Hiers, David]

VeloCloud’s 510-LTE is one option.



From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colton Conor
Sent: Wednesday, January 29, 2020 6:44 PM
To: K. Scott Helms 
Cc: NANOG list 
Subject: Re: Backup over 4G/LTE

Does Velcloud make an actual LTE box?

On Wed, Jan 29, 2020 at 6:44 AM K. Scott Helms 
mailto:kscott.he...@gmail.com>> wrote:
There are lots of options to solve that problem.

Peplink, 128T, Viptela (Cisco), Velocloud (VMWare), etc.

Scott Helms


On Tue, Jan 28, 2020 at 6:31 PM K MEKKAOUI 
mailto:amekka...@mektel.ca>> wrote:
Dear NANOG Community,

Can anyone help with any device information that provides redundancy for 
business internet access? In other words when the internet provided through the 
cable modem fails the 4G/LTE takes over automatically to provide internet 
access to the client.

Thank you

KARIM M.


--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.

Re: AFRINIC: The Saga Continues

[a...@yandex.ru]

On Wed, 29 Jan 2020 19:51:17 -0800
"Ronald F. Guilmette"  wrote:


> A full list of all of the stolen AFRINIC blocks that are still of
> ongoing concern at the present moment, taking into account the above
> adjustments, is available here:
> 
> https://pastebin.com/raw/71zNNriB
> 
> Note that many of the blocks listed at the link above have already
> been "reclaimed" as far as the AFRINIC WHOIS records are concerned.
> But because routing remains almost entirely decoupled from RIR WHOIS
> data bases, much of this "reclaimed" space is still being routed as
> I write this.  The only difference is that now the space is being
> routed as bogons, rather than as "legitimately" allocated space.
> 

Rightful owners should create RPKI ROAs, what can help, since some
large networks have deployed origin validation and drop RPKI invalids.