Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Ray Wong]

My first internet connection was some generic 2400baud.I had software
support for MNP 5, which probably claims speeds up to 9600 bps? {perfomance
in the lab with pretty cooperative factors like noise when squirrels eat
through the protective coatings, and then chew up the actual wire, and at
least compromise the protection. Oh anyway tl;dr, I found a couple modem
numbers that weren't listed in the company publications, of course. they
suppported MNP5 on three dialup lines. All totally spoke IP and didn't
require authentication accounts, (things were pretty new for them, I'think)
so I'd periodically call the other numbers in the list an see if it was
crowded. I mostly did that because it obviously meant for general use but
some department or whatever had need.

So yeah, free 9600bps. at least people understood using words instead of
having to slap the words on an image, which isn't so appealing, while the
noise:signal ratio was the same, the total of each was much smaller. being
concise was often perceived a too short an answer, of the go away kind. The
slowest part was downloading the install cd images, and you had to make you
weren't trying to use it for anything else even so, hah

I finally lucked out. had an employer who wanted everyone in operational
duties to be able to respond faster in emergencies, and actually did it!

So then I graduated to...iDSL! yes, that's right, at the time I was too far
from the box for regular DSL. So, yeah it cost more, around 150/month I
think, maybe more, maybe less. but now I was up tp 128kbps bidirectional!
okay, so it wasn't great for moving lots of data to my home resources, but
it was enough to support the plenty of mail  coming through, including some
mailing lists for personal interests. And of course, people would email
porn. fortunately, postfix is quite good at noticing the gargantuan files,
and if they don't work the first time, fall pretty fow down the priorities,
so, i guess it worked since that was a very different time

Then I move to a new place in SF. for some reason I can't get anything
telco-based to install, so I finally turned to Comcast, first
Residential, Buisiness internet, which costs more for slower rates you
probably can't count on get, but it'll be close. They've turned out to be a
lot more clueful than the folks on the Residential service. Apparently, I
got in at a good time, because as I said I need it for work and need fixed
IP the VPN to autoconnect properly, asked me to list off the server roles
for 5 addresses instead of just the one, so it was easy to justfity 5
instead of just getting the one fixed it. I believe they've gotten more
stringent as IPv4 address, even small /29s So, it was cheap, why not try
it? It turns out that comcast business is an entirely different
organIzation.The SLA They have a 4 our onsite for someone to show up and
say they need to order a part, they're often pretty prepared by incident I
provided so have a guess where to look. There's a separate support number
only business class customers are allowed to us, so which means threre'
usually not much of a wait, if any. Because BC is presented as a complete
package, the reason they make you rent whichever cablemodemrouterfirewall
they've got their custom firmware on. If they can determine that it's your
box, they'll make sure the truck has one. Of they need to be onside trouble
shoot, they're quite competent at calling in what's needed, and most of
what they'll have is where they're stationed.

For work internet connections, I've long since track. probably all ofthem,
though i'd never be am exact who used what. I do recall one interview with
a candidate, and he asked about our network topology for whatever reason. I
happili obliged, 2Gb

We in the US have gotten used to other many mountries ahead of us for
gigabit to the home. We should do it, but in all honesty, having 57Mbps
down and 12 up, I havent been found my bandwidth seems fine. Usually looks
like either another exchange router had a problem and the remaining routes
are sitll converging with the new reality of how to transit traffic. In
fact, come to think of it, i've had exactly ONE ticket call for a railed
router. The was wsa somewhere outsie.

ANyway, 57dn12up may not be enough for what you guys do on the internet
with so much data may need, but it's still overkill for probably most of
the customers who need time to figure out how to use the computer again.
The main reason for increased capactiy all they way to plugs on the wall
and some kind of WiFI in there someone

Oh, as long giving kudos to comcast business, for those with a lot of
traffic to comcast users, their peering rates are much more affordable.
That's probably becase they get to make money on both ends of the traffic.
since they've already got networks spread out to do their stuff peering, so
worthwhile.They're nice guys to work with, too

And of course, there is the fact that traffic will always grow to exceed
capacity

Re: Backup over 4G/LTE

[Colton Conor]

Cradlepoint is probably the biggest player in this space.

On Tue, Jan 28, 2020 at 5: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: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Ben Cannon]

Right??  That’s in a customer’s office building too… I’ve got the same 
connection on my workstation of course.

I actually have another test that I don’t normally share.  It’s NOT fake.  I 
found out that the speedtest algorithm rounds to the nearest whole millisecond. 
 And that it will round DOWN below 400ns… 

A friend, being kind of sassy, said recently “Hey Ben, so like when you got the 
10g, did you just like, download all of Netflix?”  And I had to pause and give 
a semi serious reply, where I said “Actually no… Because we’ve got a Netflix 
Openconnect in SF2 that has like 80g into the fabric, and we’ve got 100g into 
there, and even over the 10g to my desktop, that’s still faster than my SSD.  
So no, I’m not going to be downloading all of Netflix.  The internet is my LAN, 
I already have…"

(It’s honestly all so cool that I wake up every day without an alarm clock, and 
*run* downstairs to do what I do.   Best job in the world.)

-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 




> On Jan 25, 2020, at 8:29 PM, Aaron Gould  wrote:
> 
> I love the symmetric ~10 gig speed test to put it into perspective for how 
> far we’ve come….also the 3 ms ping result.  Ain’t it great
>  
> -Aaron
>  
> From: Ben Cannon [mailto:b...@6by7.net ] 
> Sent: Friday, January 24, 2020 5:27 PM
> To: b...@theworld.com 
> Cc: Aaron Gould; NANOG Operators' Group
> Subject: Reminiscing our first internet connections (WAS) Re: akamai 
> yesterday - what in the world was that
>  
> I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…   
>  
> in ’93 or so.  (I was a child, in Jr High…)
>  
> -Ben.
>  
>  
> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC 
> b...@6by7.net 
>  
> 
> 
>  
>> On Jan 24, 2020, at 3:21 PM, b...@theworld.com  
>> wrote:
>>  
>> 
>> On January 24, 2020 at 08:55 aar...@gvtc.com  (Aaron 
>> Gould) wrote:
>> 
>> Thanks Jared, When I reminisce with my boss he reminds me that this 
>> telco/ISP here initially started with a 56kbps internet uplink , lol
>> 
>> Point of History:
>> 
>> When we, The World, first began allowing the general public onto the
>> internet in October 1989 we actually had a (mildly shared*) T1
>> (1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
>> shared a handful of 2400bps modems, we still have them.
>> 
>> * It was also fanned out of our office to a handful of Boston-area
>> customers who had 56kbps or 9600bps leased lines, not many.
>> 
>> -- 
>>-Barry Shein
>> 
>> Software Tool & Die| b...@theworld.com 
>>  | http://www.TheWorld.com 
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
> 
>  

Re: Backup over 4G/LTE

[Ben Cannon]

New player in this space is Ubiquiti: https://unifi-lte.ui.com - more suited 
for branch office applications IMO, but the setup couldn’t be easier.Expect 
this space to grow dramatically.


-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 




> On Jan 28, 2020, at 3:41 PM, Brandon Svec  wrote:
> 
> All Cisco Meraki MX and Z units.  Some via USB and some with SIM slot.
> 
> https://meraki.cisco.com/products/appliances 
> 
> Security Made Simple with Cisco Meraki: http://bit.ly/MerakiSecure 
> 
> 
> Brandon Svec 
> CA C-7 Lic. #822064 
> 
> .ılı.ılı. Cisco Meraki CMNA
> 15106862204  voice | sms
> teamonesolutions.com  
> 14729 Catalina St. San Leandro, CA 94577
> 
> 
> 
> 
> 
> On Tue, Jan 28, 2020 at 3: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: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Paul Nash]

Carrying on with the “first Internet connection” thread:

I forget how I found out about Usenet and UUCP email (lost in the mosts of 
time).  I ran a store and forward dial-up link from South Africa to DDSW1 in 
Chicago (Hi Karl!  Thanks!).  I cobbled together a package with a DOS-based 
mail reader and a DOS port of UUCP that several people used to get their email 
(including a local medical research establishment and the local veterinary 
college).  Demand grew, along with a request to relay email to the UNHCR in 
Northen Mozambique, so I scraped some money together to import a horribly 
expensive Telebit modem.  I ended up being the regional non-academic email hub 
for Southern Africa.

Just prior to the 1994 election, I got together with a two friends (Alan Barret 
and Chris Pinkham) and founded the first ISP in sub-Saharan Africa.  We managed 
to get a 64k satellite link at a very good price (the satellite folk were busy 
being retrenched and we were prepared to sign a contract specifically requiring 
satellite service for 5 years, which gave them some job security).  We borrowed 
a Cisco router from DiData (Cisco agents), skirted other telco regulations to 
link regions.

One of our early customers was a group of students who wanted to start a small 
dial ISP nearby.  We gave them service, bootstrapping what became our biggest 
competitor, Internet Solutions (now part of DiData, who never did ask for their 
router back).  Our little ISP grew and grew, and eventually merged with our 
biggest client, was sold, sold again, and so on.  Last time I looked, it had 
become Verizon Africa.

paul

> On Jan 28, 2020, at 6:40 PM, Forrest Christian (List Account) 
>  wrote:
> 
> So to add my two stories:
> 
> I provided the Idea and a whole bunch of time/labor/etc to start a dialup ISP 
> in our hometown back in 1994.   I remember having a big debate on whether to 
> bring in a single 56K leased line or 128K fractional T1.  We went with the 
> Fractional T1 just because it could be easily expanded over time.   (That T1 
> is now multiple 10GB circuits - yes the ISP is still running and I still am 
> involved).   So a single 128K fractional T1, a cisco 2501 (with external DSU, 
> those internal cards didn't exist yet), and 8 14.4 modems attached to a 
> single Sun Unix box.  Note that this was pre-web, and back in the days where 
> you pretty much knew at least generally everything which was on the internet.
> 
> Things grew quickly, don't remember how many lines.   At some point we moved 
> to having 56K modems on our end, which required a digital carrier to the 
> central office.   T1's were very expensive, so we did a bit of tariff 
> arbitrage.   One could obtain a 'metered' ISDN BRI line for like next to 
> nothing - the metering had to do with the fact they were going to charge you 
> by the minute for any calls, but here's the catch:  for outgoing calls only, 
> incoming calls were free which worked great for a dialup ISP.The problem 
> was that 56K dialin concentrators all wanted T1 lines.What we discovered 
> is that Adtran made a box which would take a whole bunch of ISDN BRI (each 
> with 2 channels), and combine them into a single T1.   And due to the retail 
> pricing difference for T1 vs BRI, we could pay for the box in a few months.   
>  So we took a whole truckload of ISDN BRI lines and combined them into a few 
> channelized T1's and ended up paying a lot less to the phone company.
> 
> Of course, things have grown past that (we have an extensive WISP network and 
> have an ever-growing amount of fiber in the ground).  But it's fun to think 
> about where we started.
> 
> On Mon, Jan 27, 2020 at 1:00 PM  wrote:
> 
> On January 27, 2020 at 22:57 ma...@isc.org (Mark Andrews) wrote:
>  > The hardware support was 2B+D but you could definitely just use a single 
> B.   56k vs 64k depended on where you where is the world and which style of 
> ISDN the telco offered. 
> 
> FWIW bulk dial-up lines were often brought in as PRIs which were 24
> ISDN 2B+D lines on basically a T1 (1.544mbps) and then you could break
> those out to serial lines.
> 
> The sort of cool thing was that you could get caller information on
> those even if the caller thought they blocked it with *69 or whatever
> it was and log it. I forget the acronym...no no, that's the usual
> caller-id this was...u, DNI? Something like that.
> 
> I won a court case with that data.
> 
> -- 
> -Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
> 
> 
> -- 
> - Forrest

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

[Damian Menscher via NANOG]

I recommend you *not* block the outgoing RST packets, as blocking them will
only make matters worse:
  - it leaves the webservers being abused for reflection in the half-open
SYN_RECV state, which may attract more attention (and blacklisting)
  - retries from those servers will increase the load to your network

Damian

On Tue, Jan 28, 2020 at 1:42 PM 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 
> 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" 
>> wrote:
>>
>>
>> On Jan 28, 2020, at 11:40, Dobbins, Roland 
>> 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 
>>
>>

Re: Backup over 4G/LTE

[Brandon Svec]

All Cisco Meraki MX and Z units.  Some via USB and some with SIM slot.

https://meraki.cisco.com/products/appliances
*Security Made Simple with Cisco Meraki: *http://bit.ly/MerakiSecure

*Brandon Svec*
CA C-7 Lic. #822064

.ılı.ılı. Cisco Meraki CMNA

*15106862204 <15106862204> voice | sms**teamonesolutions.com
*


*14729 Catalina St. San Leandro, CA 94577*




On Tue, Jan 28, 2020 at 3: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: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Forrest Christian (List Account)]

So to add my two stories:

I provided the Idea and a whole bunch of time/labor/etc to start a dialup
ISP in our hometown back in 1994.   I remember having a big debate on
whether to bring in a single 56K leased line or 128K fractional T1.  We
went with the Fractional T1 just because it could be easily expanded over
time.   (That T1 is now multiple 10GB circuits - yes the ISP is still
running and I still am involved).   So a single 128K fractional T1, a cisco
2501 (with external DSU, those internal cards didn't exist yet), and 8 14.4
modems attached to a single Sun Unix box.  Note that this was pre-web, and
back in the days where you pretty much knew at least generally everything
which was on the internet.

Things grew quickly, don't remember how many lines.   At some point we
moved to having 56K modems on our end, which required a digital carrier to
the central office.   T1's were very expensive, so we did a bit of
tariff arbitrage.   One could obtain a 'metered' ISDN BRI line for like
next to nothing - the metering had to do with the fact they were going to
charge you by the minute for any calls, but here's the catch:  for outgoing
calls only, incoming calls were free which worked great for a dialup ISP.
  The problem was that 56K dialin concentrators all wanted T1 lines.
What we discovered is that Adtran made a box which would take a whole bunch
of ISDN BRI (each with 2 channels), and combine them into a single T1.
 And due to the retail pricing difference for T1 vs BRI, we could pay for
the box in a few months.So we took a whole truckload of ISDN BRI lines
and combined them into a few channelized T1's and ended up paying a lot
less to the phone company.

Of course, things have grown past that (we have an extensive WISP network
and have an ever-growing amount of fiber in the ground).  But it's fun to
think about where we started.

On Mon, Jan 27, 2020 at 1:00 PM  wrote:

>
> On January 27, 2020 at 22:57 ma...@isc.org (Mark Andrews) wrote:
>  > The hardware support was 2B+D but you could definitely just use a
> single B.   56k vs 64k depended on where you where is the world and which
> style of ISDN the telco offered.
>
> FWIW bulk dial-up lines were often brought in as PRIs which were 24
> ISDN 2B+D lines on basically a T1 (1.544mbps) and then you could break
> those out to serial lines.
>
> The sort of cool thing was that you could get caller information on
> those even if the caller thought they blocked it with *69 or whatever
> it was and log it. I forget the acronym...no no, that's the usual
> caller-id this was...u, DNI? Something like that.
>
> I won a court case with that data.
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>


-- 
- Forrest

Re: Backup over 4G/LTE

[Mike Lyon]

Peplink Balance line of routers:

https://www.peplink.com/products/balance/

-Mike

> On Jan 28, 2020, at 15:31, 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.
>  

Backup over 4G/LTE

[K MEKKAOUI]

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: AFRINIC: The Saga Continues

[Ronald F. Guilmette]

In message , 
thomas brenac  wrote:

>Thank you Ronald, I also heard of governance issue in AFRINIC by some 
>people during the last RIPE meeting so the word is spreading. Now is 
>there any other /16 impacted to your knowledge ? Would be worth pushing 
>to have them in as many Drop list as possible maybe :)

As reported in Jan Vermeulen's article on the web site mybroadband.co.za
published December 4, there has been, and continues to be a large number
of blocks, both "legacy" blocks and other blocks, that were stolen from
the Afrinic free pool.  These blocks are of varying sizes, generally /16
blocks but also some larger ones as well as a few smaller ones.

The list of affected legacy blocks from Jan's article are as follows:

196.10.64.0/19
196.10.61.0/24
196.10.62.0/23
160.121.0.0/16
155.235.0.0/16
152.108.0.0/16
155.237.0.0/16
169.129.0.0/16
165.25.0.0/16
160.122.0.0/16
168.80.0.0/15
165.3.0.0/16
165.4.0.0/16
165.5.0.0/16
160.115.0.0/16

In addition to all of the above, I have some reason to believe that the
following additional legacy block WAS (past tense) stolen, but has now
been reclaimed by, and ressigned to its rightful modern owner:

152.108.0.0/16

It is highly probable that there are other and additional legacy blocks
that have also been stolen.  I have been prevented from fully completing
my research work on this part of the problem by ongoing stonewalling by
Afrinic.  Specifically, despite Afrinic having a defined protocol whereby
legitimate researchers may request confidential access to the unredacted
Afrinic WHOIS data base for legitimate research purposes... a protocol
and a process which is fully supported and operational at all of the other
four global RIRs... Afrinic has, for reasons unknown, elected to only
provide redacted versions of its WHOIS data base which are identical
to what may be obtained at any time, and without any special protocol,
directly from Afrinic's FTP server (via anonymous FTP).  Because the
accurate identification of stolen Afrinic legacy blocks involves the
careful analysis of the *unredacted* contact person: records, access to
only the redacted data base is of no value whatsoever in the task of
identifying stolen Afrinic legacy blocks.

Here is the page on the Afrinic web site where they needlessly torment
legitimate researchers into believing that they will be able to get the
same kind of unredacted WHOIS data base access as is provided, upon
vetting and approval, by all of the other RIRs:

https://www.afrinic.net/services/207-bulk-whois-access

The list of blocks that appear to have been stolen from the Afrinic free
pool, as published in Jan's Dec 4 article are as follows:

"Infoplan"/"Network and Information Technology Limited":
196.16.0.0/14
196.4.36.0/22
196.4.40.0/22
196.4.44.0/23

"Cape of Good Hope Bank"/"CGHB":
165.52.0.0/14
137.171.0.0/16
160.184.0.0/16
168.211.0.0/16
192.96.146.0/24  -- NOTE!!  -- 100% legitimate legacy allocation!

The following additional blocks had also been stolen from the Afrinic free
pool.  I had informed Jan about these blocks also, but for some reason
these were not mentioned in Jan's Dec 4th article.  (I assume that this
was simply a clerical oversight on Jan's part.  I had given him quite
a lot of material to sort through.)

"ITC":
196.194.0.0/15
196.246.0.0/16
196.45.112.0/20
196.42.128.0/17
196.193.0.0/16

"Link Data Group":
160.255.0.0/16
196.62.0.0/16
198.54.232.0/24
196.207.64.0/18
196.192.192.0/18
160.181.0.0/16
213.247.0.0/19

As of this moment, Afrinic has properly reclaimed all of the "ITC" and
"Link Data Group" and "Cape of Good Hope Bank"/"CGHB" blocks.  Those
blocks are now officially unregistered.  I am informed and believe that
it is Afrinic's intent to place all of these blocks into a "quarantine"
status for a minimum of 1 year, which I think is entirely proper and
prudent, under the circumstances.

I have no explanation for why Afrinic has not yet reclaimed any of the
"Infoplan"/"Network and Information Technology Limited" blocks, especially
the 196.16.0.0/14 block.  This is for me deeply troubling, as I have some
reason to believe that these blocks were stolen by a party or parties,
who were also Afrinic insiders, but people other than the one "insider"
perpetrator of these crimes who has already been identified by myself and
Jan, and who is now the subject of a police investigation in Mauritius.

I am not personally aware of any action that Afrinic has taken to try to
remediate the situation with regards to the stolen legacy blocks, as
listed above.  These blocks all quite provably had their associated
person: contact records fiddled in the WHOIS data base in a manner so
as to redirect both emails and phone calls to either the perpetrators
or those others to whom the perpetrators had re-sold these stolen goods.

In fact, I am not even sure that Afrinic even has the capability to undo
the damage in the case of these legacy blocks and their fiddled contact
person: records.  Quite obviously, proper 

Re: Recommended DDoS mitigation appliance?

[Colton Conor]

Mike,

What did you end up going with if not fastnetmon? Were you using their paid
or free version?

On Thu, Dec 5, 2019 at 4:45 PM Mike  wrote:

>
> On 12/5/19 1:43 PM, Hugo Slabbert wrote:
> >> FastNetMon is awesome, but its a detection tool with no mitigation
> >> capacity whatsoever.
> >
> > Does is not, though, provide the ability to hook into RTBH or Flowspec
> > setups?
> >
>
> Yes it does provide RTBH hook.
>
> I evaluated fastnetmon using exactly the 'quick setup' and found it to
> have some serious problems with false alarms and statistical anomalies,
> at least when using pure netflow data (did not try sampled mode).  Hosts
> that were not in fact receiving >100mbps traffic (a traffic level I
> predetermined as 'attack' for a given network segment), would
> occasionally get flagged as such (and rtbh activated), while 2 real
> attacks that came during the testing period (60 days for me) went
> completely unnoticed. Support seemed to concede that sampled mode is
> really the only accurate method, and which by this time I'd expended all
> my interest. Great concept, cool integration, just not ready for prime
> time.
>
>
> MIke-
>
>

Re: RIP: Bill Manning

[Ray Wong]

I also had the good fortune of working with Bill. I learned a lot from him,
both while he was officially our vendor, and afterwards, when he was always
ready and willing to provide insight and advice when I asked. He was
absolutely one of those rare individuals who would never hesitate to help
out behind the scenes without any expectation of reward or recognition. A
simple personal thank you was always appreciated, and even that seemed to
surprise him, as if he really didn't even believe he'd done anything. He
will be missed.

-R>




On Tue, Jan 28, 2020 at 8:20 AM Don Wilder  wrote:

> I too am saddened by this news. I had the honor to work with Bill during
> our time together at ARIN. The world is dimmed by his passing.
> -
> Don Wilder
> -
>
> Programming today is a race between software engineers striving to build
> bigger and better idiot-proof programs, and the Universe trying to produce
> bigger and better idiots. So far, the Universe is winning.
>
>
> On Mon, Jan 27, 2020 at 5:54 PM Rabbi Rob Thomas  wrote:
>
>> Dear team,
>>
>> I was very sad when I heard this news.  Bill was a fun and friendly
>> presence, and patiently mentored me in my early days.  I’ll never forget
>> when he scrawled “I love bots” on one of my NANOG badges.  I still have
>> it.  :)  I had the fortune to be on a couple of panels with him, and I
>> learned from his answers and the way he presented them.  I admire that he
>> cared, and he gave of himself without hesitation.  I will miss him and his
>> contributions.
>>
>> Zichrono livracha, Bill’s memory is definitely for blessing.
>>
>> Be well,
>> Rabbi Rob.
>>
>>
>> > On Jan 27, 2020, at 3:34 PM, Brett Watson 
>> wrote:
>> >
>> > I was saddened to see this yesterday, that Bill Manning had passed. I
>> was surprised this morning that it hadn’t hit NANOG yet but thought I’d
>> post something because I have a ton of respect for Bill as I’m sure many
>> here do.
>> >
>> > I met Bill as a very young, thought-I-knew-everything network engineer
>> around ’92 when I was starting my internet life at a small ISP in Houston.
>> Bill was visiting Stan Barber @ Sesquinet, which was my upstream provider
>> at the time via T1, if I remember it all correctly.
>> >
>> > I was young, fresh out of college with a CS degree, and learning this
>> “internet thing.” I met with Bill on campus at Rice University to discuss
>> networking/routing, and Bill taught me CIDR, which I had no f-ing idea at
>> that time what it was. Bill was always gracious and willing to share/teach.
>> We always chatted and stayed in touch at NANOG and IETF conferences and
>> through his relationship with Los Nettos over the years. Most notable, to
>> me, was 2007 when my youngest daughter was diagnosed with cancer, and I
>> believe Bill’s wife had (or previously battled) cancer as well. I hadn’t
>> seen Bill for a few years, but he immediately reached out, shared his
>> positive thoughts/prayers, and kept in touch during the battle we went
>> through. Bill cared about people, and as noted below, he was smart as hell,
>> and always had a crazy idea for how to solve a problem. Also as noted in
>> Rod’s note below, Bill had a wealth of music knowledge and could always
>> recommend something new and interesting to listen to.
>> >
>> > I’ll definitely miss Bill, and his passing makes me feel the years, and
>> the mileage, but in a good way.
>> >
>> > -b
>> >
>> >>> This morning I talked to Julie Manning, Bill's wife. Bill died early
>> >>> Saturday morning, at home in Oregon.  Most of you know Bill was
>> >>> waiting for a new heart. He would perhaps have gotten one next
>> >>> month. I guess the old one just wouldn't hold out long enough.
>> >>>
>> >>> I first met Bill in about 1995, when I returned to ISI after my first
>> >>> stint in Japan.  He had taken a position in the Los Nettos project at
>> >>> ISI, a regional network project in the days when Internet service and
>> >>> operations work was still heavily shared between business and
>> >>> academia.  Bill brought an operator's eye to the project, often seeing
>> >>> things differently from the researchers in the group.
>> >>>
>> >>> Bill kept the most erratic hours of any non-student I've ever met.  He
>> >>> might be in the office at 2am or at 2pm, either was equally likely.
>> >>> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I
>> >>> was here before that, and you were already here, it must have been
>> >>> earlier."  "Greenwich Mean Time."
>> >>>
>> >>> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He
>> >>> would speculate about his average altitude and speed over the previous
>> >>> month.
>> >>>
>> >>> And, like any good geek, Bill had a spectacular collection of tie-dye
>> >>> t-shirts.  He came by the look honestly: growing up in the Bay Area,
>> >>> he had actually snuck into Grateful Dead rehearsals held in a barn,
>> >>> and had 

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

[Octolus Development]

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  
[mailto:beec...@beecher.cc] 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: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Jean | ddostest.me via NANOG]

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

[thomas brenac via NANOG]

Hi there,

Thank you Ronald, I also heard of governance issue in AFRINIC by some 
people during the last RIPE meeting so the word is spreading. Now is 
there any other /16 impacted to your knowledge ? Would be worth pushing 
to have them in as many Drop list as possible maybe :)


I took the liberty to forward your message in FRnoG list (giving you 
credit of course), as France do have access to AFRINIC via the French 
indies Isles. Hope you don't mind


--
Thomas BRENAC
https://www.brenac.eu
+33686263575
Registered IPv4 Broker by RIPE NCC, ARIN, APNIC and LACNIC

On 28/01/2020 05:46, Ronald F. Guilmette wrote:

For the benefit of those of you who may have been living in caves
for the past two months, I would like to share the following links
regarding a massive fraud that appears to have been perpetrated by
at least one AFRINIC insider.  (It has still not been definitively
determined if he had help or not.)

https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth-r800-million-were-stolen-and-sold-on-the-black-market.html

https://krebsonsecurity.com/2019/12/the-great-50m-african-ip-address-heist/

https://www.theregister.co.uk/2019/12/17/another_afrinic_scandal/

https://mybroadband.co.za/news/security/335226-here-are-the-police-charges-filed-in-the-great-african-ip-address-heist.html

I hate to say that I told you so, but I told you so.  I reported right
here on the NANOG list, in both 2016 and 2017, that there was quite a
lot of funny business going on down in Africa.  Nobody listened and
there was no meaningful investigation whatsoever by anybody until I
took it upon myself, starting in July of last year, to finally get to
the bottom of this colossal mess.

Here are links to my old public posts relating to this:

November, 2016:
https://mailman.nanog.org/pipermail/nanog/2016-November/089164.html
https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html
https://lists.afrinic.net/pipermail/rpd/2016/006129.html

August, 2017:
https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html
https://mailman.nanog.org/pipermail/nanog/2017-August/091954.html
https://mailman.nanog.org/pipermail/nanog/2017-August/092092.html

AFRINIC supposedly began an investigation of these matters as early
as last April (2019), but here's the funny thing:  Not a single person
from AFRINIC, or from any other part of what passes for "Internet
governance" ever contacted me or asked a single question of me about
any of this.  I can only infer from this that nobody involved in
this so-called investigation had any real or burning interest in
gathering all of the relevant facts.

In light of the facts that have now come out in the press, AFRINIC is
still, allegedly, "investigating" and now, even nearly two months
after the story broke in the press, AFRINIC has still not even reclaimed
100% of the valuable IPv4 space that was provably stolen from their
own free pool.  (Various online criminal enterprises are continuing
to use that IPv4 space aqs we speak.)  Worse yet, AFRINIC has done
nothing whatsoever to address the problem of the large number of
AFRINIC legacy /16 blocks that got stolen via some clever internal
manipulation of AFRINIC's own WHOIS record.  Those manipulations, and
the benefits from them have flowed to various parties who are now all
too well known, including one who previosuly made a brief guest apperance
right here on this mailing list.

In fact, that party has just recently found a brand new helpful and
compliant small-time hosting provider in India to route for him the
stolen 165.25.0.0/16 block, which is and has been "liberated" from
its rightful owners, i.e. the City of Cape Town, South Africa.

 https://bgp.he.net/AS393960#_prefixes
 https://bgp.he.net/net/165.25.8.0/22#_whois

Note that whereas AS393960 claims to be located in my own state of
California, is is not incorporated here.  It -is- incorporated in the
state of Wyoming, but the owner and CEO, by his own admission, is
actually located in Pune, India:

 https://in.linkedin.com/in/kushalraha

(That small detail did not, of course, prevent ARIN, in its infinite
wisdom, from giving the the proprietor of this place his own AS, two
IPv4 /22 blocks and one IPv4 /24 block, all apparently on the basis of
his tissue-thin Wyoming shell company.  But I digress.)

Anyway, I just wanted you all to be aware of all of these fun facts.

Like I always say, just another day in paradise.


Regards,
rfg


--
Thomas BRENAC
https://www.brenac.eu
+33686263575

Certified IPv4 Broker by RIPE NCC, ARIN, APNIC and LACNIC


The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of this 
message with any third party, without a written consent of the sender. If you 
received this message by mistake, please reply to this message and follow with 
its deletion, so that we can ensure such a mistake does not occur in the future.
This message has been 

Major issues with Cloudflare DNS (specifically DNS-over-HTTPS)

[John Von Essen]

Can someone from Cloudflare contact me off-list?

I work for a major search engine (not Google) and starting yesterday, we are 
getting reports from around the world about a DNS issue. They are either not 
resolving our site, or they are getting incorrect resolution (i.e. the wrong 
IP).

The issues appears to be centered around Firefox users who have DNS-over-HTTPS 
enabled, with Cloudflare as the provider.

Thanks
John

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Andy Ringsmuth]

> On Jan 28, 2020, at 10:53 AM, Paul Ebersman  wrote:
> 
> wsimpson> When we first designed PPP in the late '80s to replace SLIP
> wsimpson> and SLFP, it was expected to run at 300 bps and scale up, so
> wsimpson> the timeouts reflected that.  When I designed PPP over ISDN,
> wsimpson> added language to allow faster retransmission.
> 
> SLIP and PPP were quite... robust. Some UCB folks managed to get SLIP
> over tin can and string. Two acoustic coupler 150b modems, 2 8oz V8 cans
> and waxed cotton thread.

I remember a bit of those days as well. Not working with them but seeing 
acoustic coupler modems in action. In the late 80s when my grandfather was 
mayor of a small town in Minnesota, he had some kind of little terminal in his 
basement with an acoustic coupler modem. It was so he could add messages to a 
city TV station in his official mayoral capacity. I was probably 8 or 9 at the 
time. My brother and I thought it was really, really cool when he showed us how 
it worked by putting our names on TV. He put some little “welcome to my 
grandkids from Nebraska” message that, to a 9 year old in the 1980s was awesome 
to see.


-Andy

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[t...@pelican.org]

On Tuesday, 28 January, 2020 16:53, "Paul Ebersman"  
said:

> SLIP and PPP were quite... robust. Some UCB folks managed to get SLIP
> over tin can and string. Two acoustic coupler 150b modems, 2 8oz V8 cans
> and waxed cotton thread.

https://www.revk.uk/2017/12/its-official-adsl-works-over-wet-string.html

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Large Hadron Collider]

Imagine the racket!

Is anyone connected with PPP over OC3? I'm just curious. I don't have that sort
of connection myself. I'm just on dumbass DOCSIS. My first connection was PPP
over the analogue PSTN.

On Tue, 28 Jan 2020 09:53:26 -0700
Paul Ebersman  wrote:

> wsimpson> When we first designed PPP in the late '80s to replace SLIP
> wsimpson> and SLFP, it was expected to run at 300 bps and scale up, so
> wsimpson> the timeouts reflected that.  When I designed PPP over ISDN,
> wsimpson> added language to allow faster retransmission.
>
> SLIP and PPP were quite... robust. Some UCB folks managed to get SLIP
> over tin can and string. Two acoustic coupler 150b modems, 2 8oz V8 cans
> and waxed cotton thread.
>
> wsimpson> Like many of you, I started an ISP in 1994 with a 56 kbps
> wsimpson> uplink, and only 6 local customers  The routers were in a
> wsimpson> bathroom over the garage.
>
> Our first CA hub was in the janitor's closet at a now defunct computer
> company. We initially had problems with the janitors unplugging the
> router on weekends to plug in their floor buffers.
>
> Ah, the good old days.
>
>


--
Large Hadron Collider 

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Paul Ebersman]

wsimpson> When we first designed PPP in the late '80s to replace SLIP
wsimpson> and SLFP, it was expected to run at 300 bps and scale up, so
wsimpson> the timeouts reflected that.  When I designed PPP over ISDN,
wsimpson> added language to allow faster retransmission.

SLIP and PPP were quite... robust. Some UCB folks managed to get SLIP
over tin can and string. Two acoustic coupler 150b modems, 2 8oz V8 cans
and waxed cotton thread.

wsimpson> Like many of you, I started an ISP in 1994 with a 56 kbps
wsimpson> uplink, and only 6 local customers  The routers were in a
wsimpson> bathroom over the garage.

Our first CA hub was in the janitor's closet at a now defunct computer
company. We initially had problems with the janitors unplugging the
router on weekends to plug in their floor buffers.

Ah, the good old days.

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

[Octolus Development]

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: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Tom Beecher]

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 
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" 
> wrote:
>
>
> On Jan 28, 2020, at 11:40, Dobbins, Roland 
> 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 
>
>

Call for Presentations: 33rd DNS-OARC Workshop, Paris, France, May 09 - 10th 2020

[Joe Abley]

The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche Hotel & 
Conference Center in Paris, France on May 9th and 10th 2020. It is co-located 
with and will take place right after the ICANN GDD (May 3rd to 6th), 
Registrations Operations Workshop (May 6th) and ICANN DNS Symposium (May 7th 
and 8th).

The Workshop's Program Committee is requesting proposals for presentations. All 
DNS-related subjects are welcome.

A time slot will also be available for lightning talks (5-10 minutes each) on 
day two of the workshop, for which submissions will be accepted just before the 
start of the workshop and until the start of the morning break on day two. 
Poster submissions are also welcome.

There will be an OARC Business session during the workshop, which will be for 
OARC Members only. If you are an OARC member and have a sensitive topic that 
you wish to present during that session those can be accommodated.

Workshop Milestones:
  10 Jan 2020 - Submissions open via Indico
  05 Mar 2020 - Deadline for submission (midnight CEST)
  19 Mar 2020 - Initial Contribution list published
  02 Apr 2020 - Full agenda published
  02 May 2020 - Deadline for slideset submission
  09 May 2020 - Workshop begins

Details for presentation submission are published here:

  

The workshop presentations will be organized by common themes, depending on the 
topics and the timing of each presentation. There are 30-minute and 15-minute 
slots, let us know your preference in your submission.

To allow the Programme Committee to make objective assessments of submissions, 
so as to ensure the quality of the workshop, submissions SHOULD include slides. 
Draft slides are acceptable on submission.

If you have questions or concerns you can contact the Programme Committee:

  https://www.dns-oarc.net/oarc/programme

via 

Joe Abley, for Dave Knight, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social events. 
 Please contact  if your organization is interested in 
becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a position 
to reimburse expenses or time for speakers at its meetings.)

DHCP Snooping Issue on Cisco N3K SW

[Md. abdullah Al naser via NANOG]

Hi everyone,

I hope all you are fine. I'm very new to this mailing list and looking for a 
solution if anyone could help me.
I am a network operation engineer and working for an ISP in Bangladesh. We are 
serving internet, data connectivity, IPTSP, IPTV and other services to 
corporate and retail clients. Retail clients are basically home users and small 
offices.
To connect their CPE devices to our access network we are using DHCP. For 
example, we are using 192.168.0.1/24 IP in our BRAS interface and rest of all 
IPs are in DHCP pool to be allocated to the end users. By this time we had some 
bad experience with rouge DHCP server while clients connect the WAN link to the 
LAN port of CPE devices.
To overcome that we recently deployed DHCP-snooping on our distribution 
switches which is in between the DHCP server and clients. But we are facing new 
problem after deploying that. Sometime our switch got stuck and clients don't 
get any IP via DHCP and all the allocations on valid DHCP server are stuck in 
"OFFERED" state. If we disable and then again enable the DHCP snooping feature 
in switch then problem is resolved for temporary. But few hours later the same 
problem happens repeatedly.
For your information we are using Cisco Nexus 3000 switch and around 3k to 4k 
clients are there under that switch. We have a different location/POP where not 
more than 500 users are there and we don't have this kind of problem at all.
So we assume that our Nexus 3000 switch is not performing well to handle DHCP 
snooping for large number of customers!!!
For better understanding please check the network topology diagram (attached)
SW Details:
Hardware  cisco Nexus3000 C3064PQ Chassis   Software  BIOS: version 3.8.0  
NXOS: version 7.0(3)I4(3)  NXOS image file is: bootflash:///nxos.7.0.3.I4.3.bin

Just seeking expert opinion on above mention issue.





Thanks & Regards, 
Naser

Re: RIP: Bill Manning

[Don Wilder]

I too am saddened by this news. I had the honor to work with Bill during
our time together at ARIN. The world is dimmed by his passing.
-
Don Wilder
-

Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.


On Mon, Jan 27, 2020 at 5:54 PM Rabbi Rob Thomas  wrote:

> Dear team,
>
> I was very sad when I heard this news.  Bill was a fun and friendly
> presence, and patiently mentored me in my early days.  I’ll never forget
> when he scrawled “I love bots” on one of my NANOG badges.  I still have
> it.  :)  I had the fortune to be on a couple of panels with him, and I
> learned from his answers and the way he presented them.  I admire that he
> cared, and he gave of himself without hesitation.  I will miss him and his
> contributions.
>
> Zichrono livracha, Bill’s memory is definitely for blessing.
>
> Be well,
> Rabbi Rob.
>
>
> > On Jan 27, 2020, at 3:34 PM, Brett Watson  wrote:
> >
> > I was saddened to see this yesterday, that Bill Manning had passed. I
> was surprised this morning that it hadn’t hit NANOG yet but thought I’d
> post something because I have a ton of respect for Bill as I’m sure many
> here do.
> >
> > I met Bill as a very young, thought-I-knew-everything network engineer
> around ’92 when I was starting my internet life at a small ISP in Houston.
> Bill was visiting Stan Barber @ Sesquinet, which was my upstream provider
> at the time via T1, if I remember it all correctly.
> >
> > I was young, fresh out of college with a CS degree, and learning this
> “internet thing.” I met with Bill on campus at Rice University to discuss
> networking/routing, and Bill taught me CIDR, which I had no f-ing idea at
> that time what it was. Bill was always gracious and willing to share/teach.
> We always chatted and stayed in touch at NANOG and IETF conferences and
> through his relationship with Los Nettos over the years. Most notable, to
> me, was 2007 when my youngest daughter was diagnosed with cancer, and I
> believe Bill’s wife had (or previously battled) cancer as well. I hadn’t
> seen Bill for a few years, but he immediately reached out, shared his
> positive thoughts/prayers, and kept in touch during the battle we went
> through. Bill cared about people, and as noted below, he was smart as hell,
> and always had a crazy idea for how to solve a problem. Also as noted in
> Rod’s note below, Bill had a wealth of music knowledge and could always
> recommend something new and interesting to listen to.
> >
> > I’ll definitely miss Bill, and his passing makes me feel the years, and
> the mileage, but in a good way.
> >
> > -b
> >
> >>> This morning I talked to Julie Manning, Bill's wife. Bill died early
> >>> Saturday morning, at home in Oregon.  Most of you know Bill was
> >>> waiting for a new heart. He would perhaps have gotten one next
> >>> month. I guess the old one just wouldn't hold out long enough.
> >>>
> >>> I first met Bill in about 1995, when I returned to ISI after my first
> >>> stint in Japan.  He had taken a position in the Los Nettos project at
> >>> ISI, a regional network project in the days when Internet service and
> >>> operations work was still heavily shared between business and
> >>> academia.  Bill brought an operator's eye to the project, often seeing
> >>> things differently from the researchers in the group.
> >>>
> >>> Bill kept the most erratic hours of any non-student I've ever met.  He
> >>> might be in the office at 2am or at 2pm, either was equally likely.
> >>> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I
> >>> was here before that, and you were already here, it must have been
> >>> earlier."  "Greenwich Mean Time."
> >>>
> >>> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He
> >>> would speculate about his average altitude and speed over the previous
> >>> month.
> >>>
> >>> And, like any good geek, Bill had a spectacular collection of tie-dye
> >>> t-shirts.  He came by the look honestly: growing up in the Bay Area,
> >>> he had actually snuck into Grateful Dead rehearsals held in a barn,
> >>> and had traveled as a deadhead for a while.
> >>>
> >>> At ISI, we called Bill "the bad idea fairy".  He always brought a
> >>> slightly-off-kilter view of technical problems, which triggered
> >>> endless discussions of fascinating, if usually implausible,
> >>> alternatives.
> >>>
> >>> He had the most broad-ranging musical tastes of anyone I knew, and
> >>> would eat almost anything (though, like me, he didn't drink alcohol).
> >>> I was often envious of his eating and musical experiences.  He
> >>> certainly lived life to its fullest.
> >>>
> >>> On one occasion, I recall, we were eating lunch in a Thai restaurant
> >>> for the first time.  Bill called for the food "the way you'd make it
> 

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Derek Traynor]

I had a USR 2400 baud external modem. Local ISP offered PPP service as
well. We also had a few BBS's in the area of which I ran two of them.

On Mon, Jan 27, 2020 at 10:31 AM Daniel Seagraves <
dseag...@humancapitaldev.com> wrote:

> > On Jan 24, 2020, at 5:26 PM, Ben Cannon  wrote:
> >
> > I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…
>
> Hayes Smartmodem here, 1200 baud. Local BBS offered PPP service.
>
> When I got my first sysadmin job, $work had a T1 and it felt like more
> speed than was fair…
>

Re: akamai yesterday - what in the world was that

[Tom Deligiannis]

>
> Shouldn't game patches like this be released overnight during off-peak
> hours? Fortnite releases their updates around 3 or 4am when most ISP's
> networks are at their lowest utilization. It seems somewhat reckless to
> release such a large patch during awake hours.
>

I can't speak for PS4 and PC, but xbox does have a setting to keep the
console in a state that allows the device to download updates when it is
'off' but I've noticed that the consoles don't always follow that rule and
the update starts downloading when the user powers on the console, which is
usually during peak hours. If this worked properly, it would be great since
most of the updates would download while users were at school, working,
sleeping, etc.

On Sat, Jan 25, 2020 at 1:36 PM Darin Steffl 
wrote:

> Shouldn't game patches like this be released overnight during off-peak
> hours? Fortnite releases their updates around 3 or 4am when most ISP's
> networks are at their lowest utilization. It seems somewhat reckless to
> release such a large patch during awake hours.
>
> On Sat, Jan 25, 2020, 12:08 PM Brandon Jackson via NANOG 
> wrote:
>
>> "Call of Duty: Modern Warfare fragged our business VOIP: US ISP blames
>> outage on smash-hit video game rush
>> This is Windstream, going dark..."
>> https://www.theregister.co.uk/2020/01/23/windstream_fvoip_outage/
>>
>> Apparently not everyone came out unscathed.
>>
>> --
>> Brandon Jackson
>> bjack...@napshome.net
>>
>>
>> On Thu, Jan 23, 2020 at 10:14 AM Aaron Gould  wrote:
>>
>>> My gosh, what in the word was that coming out of my local Akamai aanp
>>> servers yesterday !?  starting at about 12:00 noon central time lasting
>>> several hours ?
>>>
>>>
>>>
>>> -Aaron
>>>
>>

Re: akamai yesterday - what in the world was that (now old guy stuff)

[Ben Cannon]

The Civil Engineering version of this is SWER electrical distribution.  
Single-Wire, Earth-Return. And it’s as crazy in implementation as it sounds now.




-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 




> On Jan 25, 2020, at 8:24 AM, Allen McKinley Kitchen (gmail) 
>  wrote:
> 
> On Jan 25, 2020, at 08:52, Paul Nash  wrote:
>> 
>> 
>>> 
>>> So, I grew up in South Africa, and one of the more fascinating /
>>> cooler things I saw was a modem which would get you ~50bps (bps, not
>>> Kbps) over a single strand of barbed wire -- you'd hammer a largish
>>> nail into the ground, and clip one alligator[0] clip onto that, and
>>> another alligator clip onto the barbed wire. Repeat the process on the
>>> other side (up to ~5km away), plug the modems in, and bits would
>>> flow... I only saw these used a few times, but always thought they
>>> were cool….
>> 
>> Do you remember anything about the actual type of modem?  Or where you 
>> deployed them?
>> 
> Decades ago, I cobbled together a 20mA current loop interface that may have 
> been an early version of this .. ran a set of Baudot machines (pre-ASCII, 
> upper case & figs only) mostly just to have fun with a set of old ASR 32 
> teletypes.  I used a couple of 500’ spools of zip cord lying on the ground 
> from end to end. Never mind backhoes - it was lawn-mower vulnerable. 
> (However, being flat on the ground seemingly made it less vulnerable to 
> lightning strikes.)
> 
> Of course, this was hardly critical infrastructure!
> 
> Blessings..
> 
> Allen

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

[Jean | ddostest.me via NANOG]

Maybe we're looking at the wrong place when dealing with TCP amp. I 
believe there is a much easier way to solve this.


@OP: can you post the tcp flags of the SYN/CK you are receiving from Sony?

Thanks

Jean

On 2020-01-27 20:49, Damian Menscher via NANOG wrote:
On Mon, Jan 27, 2020 at 5:43 PM Töma Gavrichenkov > wrote:


On Tue, Jan 28, 2020, 4:32 AM Damian Menscher mailto:dam...@google.com>> wrote:

On Mon, Jan 27, 2020 at 5:10 PM Töma Gavrichenkov
mailto:xima...@gmail.com>> wrote:

If this endpoint doesn't connect to anything outside of
their network, then yes.
If it does though, the design of the filter might become
more complicated.


Not really... just requires sorting by volume.  Turns out most
legitimate hosts don't send high-volume syn packets. ;)


This is a good *detection* technique, but you cannot filter by
volume in transit if the set of destinations is large (and random)
enough, and you don't have a time machine.  Not sure if this is
the case but might as well be.


They don't need to filter by destination.  Once a problem customer has 
been identified, they can apply an ACL restricting them to only 
originate IPs they own.  This was all covered in my talk at NANOG last 
year: 
https://pc.nanog.org/static/published/meetings//NANOG76/daily/day_2.html#talk_1976


As for the detection of the real source, everything is technically
possible but you need certain bargaining power which a
medium-sized (at best) VPN service probably doesn't have.


True, but there are ways around that, including public shaming (here), 
or involving law enforcement.


Damian

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

[Dobbins, Roland]

On 28 Jan 2020, at 18:15, Octolus Development wrote:

> The problem is that they are spoofing our IP, to millions of IP's 
> running port 80.

So that does in fact sound like a TCP reflection/amplification attack.

If you have the relevant information, as it seems that you do, you can 
ask operators to perform traceback (they'll likely need timestamps).

Hopefully, some operators will read this thread and begin looking into 
it, as well.


Roland Dobbins 

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

[Octolus Development]

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"  wrote:


On Jan 28, 2020, at 11:40, Dobbins, Roland  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 

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[William Allen Simpson]

On 1/27/20 3:06 PM, b...@theworld.com wrote:


I remember going from 300b to 1200b and thinking wow, this is it,
we're done, I cannot read text scrolling on the screen at 1200b.


Other than the 75 and 110 baud teletypes that only did text, my first
TCP/IP connection was 300b, back when we had to rent the modems (1979).

I had to write my own TCP/IP stacks, on both the Interdata 7/16 at the
office and my first personal computer: a 2 MHz Z80 S-100 bus.  Built my
own serial device too, with a rather large switch on the back to change
speeds.  (Still have it, just carried it out of the garage over the
weekend, haven't turned it on in years as the special floppies have died.)

Eventually, got my own 300b Hayes Micromodem!

It took a long time to upgrade to 1200b, as the modems were thousands of
dollars each.  Roughly $18,000 each in today's dollars.  Only used between
major sites.

Racal-Vadic triple modems were a big step (circa 1986).

When we first designed PPP in the late '80s to replace SLIP and SLFP, it was
expected to run at 300 bps and scale up, so the timeouts reflected that.
When I designed PPP over ISDN, added language to allow faster retransmission.

When we designed IP/PPP/CDMA (IS-99) for cell phones, I was seriously
concerned that it would not be competitive, as it only allowed 14.4 kbps
when 28.8 kbps modems were becoming available.  Turned out to be several
times faster than ATT's CDPD offering

Like many of you, I started an ISP in 1994 with a 56 kbps uplink, and
only 6 local customers  The routers were in a bathroom over the garage.