Re: cloudflare 1.1.1.2 filtered DNS

[Justin Paine via NANOG]

Hi Bill,

Report it via the form you mentioned and the team will review it shortly.
We don't currently publish our data sources for the filtered service.

Thanks,
Justin



_
*Justin Paine*
He/Him/His
Head of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

101 Townsend St, San Francisco, CA 94107



On Tue, Aug 11, 2020 at 3:25 PM William Herrin  wrote:

> Howdy,
>
> Is there an RBL lookup that provides information on why Cloudflare has
> elected to block a name lookup via the "1.1.1.1 for Families" service
> or is it a black box where you can only complain via
> https://report.teams.cloudflare.com/ and maybe they'll do something
> about it?
>
> Thanks,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

cloudflare 1.1.1.2 filtered DNS

[William Herrin]

Howdy,

Is there an RBL lookup that provides information on why Cloudflare has
elected to block a name lookup via the "1.1.1.1 for Families" service
or is it a black box where you can only complain via
https://report.teams.cloudflare.com/ and maybe they'll do something
about it?

Thanks,
Bill Herrin


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

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 11/Aug/20 17:55, adamv0...@netconsultings.com wrote:

> Can you elaborate? 
> Apart from licensing scheme what stops one from redirecting traffic to one 
> vTMS instance per say each transit link or per destination /24 (i.e. 
> horizontal scaling)? (vTMS is not stateful or is it?)

In an effort to control costs, we considered a vTMS from Arbor.

Even Arbor didn't recommend it, which was completely unsurprising.

Arbor can flog you a TMS that can sweep 10Gbps, 20Gbps, 40Gbps or
100Gbps worth of traffic. I don't see how you can run that kind of
traffic in a VM.



> Can you please point out any efforts where operators are trying to 
> standardize the orchestration piece? 

NETCONF, YANG, LSO.


> I think industry is not falling over on this just progressing at steady rate 
> while producing artefacts in the process that you may or may not want to use 
> (I actually find them very useful and not impeding).   

What's 10 years between friends :-)...


> Personally, I don't need a standard on how I should orchestrate network 
> services. There are very interesting and useful ideas, or better put 
> "frameworks", that anyone can follow (and most are), but standardizing these, 
> ...no point in my opinion.

Now that's something we can agree on... and once folk realize that
getting your solution going is the end-goal - rather than bickering over
whether NETCONF or YANG or SSH or whatever should be the BCOP - is when
we shall finally see some real progress.

Personally, I don't really care of you choose to keep CLI or employ
thousands of software heads to automate said CLI. As long as you are
happy and not wasting time taking every meeting from every vendor about
"automation".

Mark.

RE: Has virtualization become obsolete in 5G?

[adamv0025]

> From: Mark Tinka 
> Sent: Tuesday, August 11, 2020 2:19 PM
> 
> On 10/Aug/20 15:15, adamv0...@netconsultings.com wrote:
> 
> > Mark,
> > 1) first you have your edge - lots of small instances that are meant
> > to be horizontally scaled (not vertically- i.e. not 40's/100's of Gbps
> > pushed via single Intel CPU)
> > - that's your NFVI.
> > - could be compute host in a DC "cloud", or in a customer office (acting as
> CPE), or at the rooftop of the office building i.e. (fog/edge computing) -e.g.
> hosting self-driving intersection apps via 5G -to your point regarding latency
> in metro), or in the same rack as core routers (acting as vRR), or actually
> inside a router as a routing engine card (hosting some containerized app).
> 
> Nothing new. This happens today already.
> 
Yes apart from the fog/edge computing all aforementioned is business as usual.

> The main issue, as discussed earlier, was licensing options for CPE-type
> deployments. This is what killed our plan for the same.
> 
Yes vendors need to abandon the old physical unit types of licensing schemes 
for the horizontal scaling to make sense.   

> 
> > 2) Any of the compute hosts mentioned above can host one or more of any
> type of the network function you can think of ranging from EPG, SBC,  PBX, all
> the way to PE-Router, LB, FW/WAF or IDS.
> 
> Yes, but the use-case determines the scale limitations. And there are many
> services that you cannot scale by offloading to several little boxes and 
> expect
> the same predictability, e.g., a vArborTMS.
> 
Can you elaborate? 
Apart from licensing scheme what stops one from redirecting traffic to one vTMS 
instance per say each transit link or per destination /24 (i.e. horizontal 
scaling)? (vTMS is not stateful or is it?)


> > 4) Now how you make changes to control-planes of these NFs (i.e. virtual
> CPU-based NFs and physical NPU-based NFs) programmatically, that's the
> realm of SDN.
> > - If you want to do it right you do it in an abstracted declarative
> > way (not exposing the complexity to a control program/user - but rather
> localizing it to a given abstraction layer) Performing tasks like:
> > - Defining service topology/access control a.k.a. micro segmentation (e.g. A
> and B can both talk to C, but not to each other).
> > - Traffic engineering a.k.a. service chaining, a.k.a. network slicing
> > (e.g. traffic type x should pas through NF A, B and C, but traffic
> > type Y should pass only through A and C)
> 
> This is the bit that I see working well on a per deployment basis, if 
> operators
> aren't too concerned about standardizing the solution.
> 
> Where the industry has kept falling over is wanting to standardize the entire
> orchestration piece, which is very noble, but ultimately, fraught with many a
> complication.
> 
Can you please point out any efforts where operators are trying to standardize 
the orchestration piece? 
I think industry is not falling over on this just progressing at steady rate 
while producing artefacts in the process that you may or may not want to use (I 
actually find them very useful and not impeding).   


> I'm sure we'd all like to see a standard on how we orchestrate the network
> and services, but I'm not sure that is practical. After all, operators are
> autonomous systems.
> 
Personally, I don't need a standard on how I should orchestrate network 
services. There are very interesting and useful ideas, or better put 
"frameworks", that anyone can follow (and most are), but standardizing these, 
...no point in my opinion.


> > 5) And for completeness, in the virtual world you have the task of VNF
> > lifecycle management (cause the VNFs and virtual networks connecting
> > them can be instantiated on demand)
> 
> So I first read all about this in 2015, through a document Cisco published
> called "Cisco vMS 1.0 Introduction and Overview Design Guide".
> 
> Safe to say not much as changed in the objective, since then :-).
> 
Really? Never mind then ;)

adam

Re: Compromized modems in Thai IP Space

[Masataka Ohta]

Alexander Maassen wrote:


It turns out that in
Thailand, people can easily get cloned modems in order to internet for
'free',


I think you failed to explain that, in Thailand, wiretapping is
commonly performed by people illegally having free Internet access,
against which MAC address is used, in vain, to identify true users.


it simply boils down to mac cloning,


Of course.


My question here kinda is, how to permanently get rid of this evil in an
effective way,


Let access ISPs use TDR (Time Domain Reflectometry) to detect
wiretapping, which requires periodic monitoring, which costs.

Or, though less elegantly, password protection by something like
PPPoE may work, which requires initial cost to change equipment.

Anyway, preventing free riding should increase revenue of the ISPs.


and who to contact?


ISPs who want to protect paying customers (maybe, partly from your
blacklisting).


(yes, I tried to get through to NOC's
of the affected providers),


ISPs can do nothing, unless they know how to prevent free riding by
wiretapping without harming paying customers.

Masataka Ohta

Re: Compromized modems in Thai IP Space

[Christopher Morrow]

On Tue, Aug 11, 2020 at 9:31 AM JORDI PALET MARTINEZ via NANOG
 wrote:
>
> I don't know what you tried in APNIC, my experience is that they are usually 
> responding very quickly.
>
> Have you tried the abuse contacts of the ISP?
>

For the Thai ISP space you might also get some traction just talking
to the thai cert org.
h  ttps://www.thaicert.or.th/about-en.html

perhaps even this path:
  https://www.thaicert.or.th/report-en.html

> If they fail, have you tried to escalate to escalation-ab...@apnic.net, 
> following our abuse-mailbox proposal 
> (https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt), which 
> was adopted long time ago?
>
>  You could also try the APNIC Talk mailing list.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 11/8/20 15:10, "NANOG en nombre de Alexander Maassen" 
>  outsi...@scarynet.org> escribió:
>
> Hello folks,
>
> Before you shoot me with 'wrong mailing list' replies, believe me, I
> tried, THNOG is dead, APNIC ain't responding either and the ISP's over
> there don't seem to care much. And I've been looking at this situation for
> over 2 years now since first incident. I simply hope that with the
> contacts you folks have due to your professions to be able to help.
>
> So, I came across this botnet which decided to pick my IRC network as
> control center, and I have been digging into them. It turns out that in
> Thailand, people can easily get cloned modems in order to internet for
> 'free', it simply boils down to mac cloning, so let me spare you the
> details. The problem is that these modems also carry a digital STD in the
> form of additional botnet code, allowing the controllers to do, well,
> botnet stuff.
>
> I disabled their ability to control by glining everything on join to the
> control channel, and since I am maintainer of DroneBL, add them to the
> blacklist. Doing that for 2+ years now. The amount of removal requests
> because people no longer are able to play on cncnet is amazing.
>
> My question here kinda is, how to permanently get rid of this evil in an
> effective way, and who to contact? (yes, I tried to get through to NOC's
> of the affected providers), or could perhaps someone be so nice to use one
> of their contacts in Thailand to speed things up?
>
> Kind regards,
>
> Alexander Maassen
> Maintainer DroneBL
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
>
>
>

Cisco EOL Support

[Ian Couch]

Hey everyone,
I was just wondering what types of support besides hardware support that
anyone may have been able to acquire for EOL cisco gear, specifically 7600
gear.  We can get NBD support for hardware failure pretty easily, I was
just wondering if anyone has had any experience with any further support.
Not IOS upgrades obviously, but potentially troubleshooting support.  With
the EOL dates coming up in 2021 we've been tasked to "see what's out there".

Thanks,
Ian.

-- 

Ian Couch | Network Planner

Tbaytel | 751 Tungsten St. | Thunder Bay, Ontario | P7B 6T1

Tel. (807) 625-2018 | Cell. (807) 624-6355 | Fax. (807) 623-2237

www.tbaytel.net

respect. connects here.

-- 


This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this email. Please notify 
the sender immediately by e-mail if you have received this email by mistake 
and delete this e-mail from your system. If you are not the intended 
recipient you are notified that disclosing, copying, distributing or taking 
any action in reliance on the contents of this information is strictly 
prohibited.

Re: Compromized modems in Thai IP Space

[JORDI PALET MARTINEZ via NANOG]

I don't know what you tried in APNIC, my experience is that they are usually 
responding very quickly.

Have you tried the abuse contacts of the ISP?

If they fail, have you tried to escalate to escalation-ab...@apnic.net, 
following our abuse-mailbox proposal 
(https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt), which was 
adopted long time ago?

 You could also try the APNIC Talk mailing list.
 
Regards,
Jordi
@jordipalet
 
 

El 11/8/20 15:10, "NANOG en nombre de Alexander Maassen" 
 escribió:

Hello folks,

Before you shoot me with 'wrong mailing list' replies, believe me, I
tried, THNOG is dead, APNIC ain't responding either and the ISP's over
there don't seem to care much. And I've been looking at this situation for
over 2 years now since first incident. I simply hope that with the
contacts you folks have due to your professions to be able to help.

So, I came across this botnet which decided to pick my IRC network as
control center, and I have been digging into them. It turns out that in
Thailand, people can easily get cloned modems in order to internet for
'free', it simply boils down to mac cloning, so let me spare you the
details. The problem is that these modems also carry a digital STD in the
form of additional botnet code, allowing the controllers to do, well,
botnet stuff.

I disabled their ability to control by glining everything on join to the
control channel, and since I am maintainer of DroneBL, add them to the
blacklist. Doing that for 2+ years now. The amount of removal requests
because people no longer are able to play on cncnet is amazing.

My question here kinda is, how to permanently get rid of this evil in an
effective way, and who to contact? (yes, I tried to get through to NOC's
of the affected providers), or could perhaps someone be so nice to use one
of their contacts in Thailand to speed things up?

Kind regards,

Alexander Maassen
Maintainer DroneBL




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Corero

[Mark Tinka]

On 10/Aug/20 23:09, JASON BOTHE via NANOG wrote:

> Folks
>
> Anyone on using Corero?

We were to start testing it back in March, but then the Coronavirus hit
and priorities shifted.

We are just resurrecting it this month.


>   Thoughts around it? 

From the way I understood it, it's not a replacement for a proper
TMS-type system.

It should be able to handle a decent number of (not all) Layer 3 - 4
attacks reasonably okay, but you'll need a TMS-type solution for Layer 7
(and more sophisticated) attacks.

It's a cheap (yet to see licensing prices) way to solve, I'd say, about
30% of the easy DoS noise, especially those based on crafting IP header
madness. And since it's integrated into the MX, it's something you can
have as part of your everyday traffic, and not a product you have to
think about selling to customers to recoup investments.

Would definitely give it a try!

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 10/Aug/20 15:15, adamv0...@netconsultings.com wrote:

> Mark, 
> 1) first you have your edge - lots of small instances that are meant to be 
> horizontally scaled (not vertically- i.e. not 40's/100's of Gbps pushed via 
> single Intel CPU) 
> - that's your NFVI.  
> - could be compute host in a DC "cloud", or in a customer office (acting as 
> CPE), or at the rooftop of the office building i.e. (fog/edge computing) 
> -e.g. hosting self-driving intersection apps via 5G -to your point regarding 
> latency in metro), or in the same rack as core routers (acting as vRR), or 
> actually inside a router as a routing engine card (hosting some containerized 
> app).

Nothing new. This happens today already.

The main issue, as discussed earlier, was licensing options for CPE-type
deployments. This is what killed our plan for the same.

But as an RR, yes, since 2014.


> 2) Any of the compute hosts mentioned above can host one or more of any type 
> of the network function you can think of ranging from EPG, SBC,  PBX, all the 
> way to PE-Router, LB, FW/WAF or IDS. 

Yes, but the use-case determines the scale limitations. And there are
many services that you cannot scale by offloading to several little
boxes and expect the same predictability, e.g., a vArborTMS.


>   
> 3) While inside a compute host it's CPU based forwarding, but as soon as you 
> leave compute host's NICs there's world of solely NPU based forwarding 
> (that's where you do 40's, 100's, or even 400's Gbps). 

Yes, plenty of white boxes in the world ready to run an OS and ship with
a version of Broadcom. It's a purpose-built device doing one thing and
one thing only.


>  
> 4) Now how you make changes to control-planes of these NFs (i.e. virtual 
> CPU-based NFs and physical NPU-based NFs) programmatically, that's the realm 
> of SDN.
> - If you want to do it right you do it in an abstracted declarative way (not 
> exposing the complexity to a control program/user - but rather localizing it 
> to a given abstraction layer)
> Performing tasks like:
> - Defining service topology/access control a.k.a. micro segmentation (e.g. A 
> and B can both talk to C, but not to each other).
> - Traffic engineering a.k.a. service chaining, a.k.a. network slicing (e.g. 
> traffic type x should pas through NF A, B and C, but traffic type Y should 
> pass only through A and C)

This is the bit that I see working well on a per deployment basis, if
operators aren't too concerned about standardizing the solution.

Where the industry has kept falling over is wanting to standardize the
entire orchestration piece, which is very noble, but ultimately, fraught
with many a complication.

I'm sure we'd all like to see a standard on how we orchestrate the
network and services, but I'm not sure that is practical. After all,
operators are autonomous systems.


>  
> 5) And for completeness, in the virtual world you have the task of VNF 
> lifecycle management (cause the VNFs and virtual networks connecting them can 
> be instantiated on demand)

So I first read all about this in 2015, through a document Cisco
published called "Cisco vMS 1.0 Introduction and Overview Design Guide".

Safe to say not much as changed in the objective, since then :-).

Mark.

Compromized modems in Thai IP Space

[Alexander Maassen]

Hello folks,

Before you shoot me with 'wrong mailing list' replies, believe me, I
tried, THNOG is dead, APNIC ain't responding either and the ISP's over
there don't seem to care much. And I've been looking at this situation for
over 2 years now since first incident. I simply hope that with the
contacts you folks have due to your professions to be able to help.

So, I came across this botnet which decided to pick my IRC network as
control center, and I have been digging into them. It turns out that in
Thailand, people can easily get cloned modems in order to internet for
'free', it simply boils down to mac cloning, so let me spare you the
details. The problem is that these modems also carry a digital STD in the
form of additional botnet code, allowing the controllers to do, well,
botnet stuff.

I disabled their ability to control by glining everything on join to the
control channel, and since I am maintainer of DroneBL, add them to the
blacklist. Doing that for 2+ years now. The amount of removal requests
because people no longer are able to play on cncnet is amazing.

My question here kinda is, how to permanently get rid of this evil in an
effective way, and who to contact? (yes, I tried to get through to NOC's
of the affected providers), or could perhaps someone be so nice to use one
of their contacts in Thailand to speed things up?

Kind regards,

Alexander Maassen
Maintainer DroneBL