RE: Virginia voter registration down due to cable cut

[Keith Medcalf]

>In other news, New Zealand is having national elections this weekend.
>New Zealand is usually ranked in the top 10 best election administrations
>worldwide. NZ expects to have the majority of ballots counted within 2
>hours of their polls closing on Saturday evening.

I thought the HGIC (Head Ghoul In Charge) had cancelled all the elections in 
New Zealand and declared herself to the new Dictator Ghoul In Charge until 
ousted by violent uprising by the peasants?  Has there been an uprising to oust 
the Head Ghoul via bullet-to-the-brain that was not reported in the socialist 
media?

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: Linux router network cards

[Keith Medcalf]

And do not use an Intel CPU.

Intel only has 4x PCIe lanes that are shared out into whatever configuration 
they claim to have and are totally unsuitable for use in a computer that 
actually has to be able to do high-speed I/O.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>Eric Kuhnke
>Sent: Saturday, 24 October, 2020 06:22
>To: Jared Geiger 
>Cc: NANOG 
>Subject: Re: Linux router network cards
>
>In addition to Jared's advice, I would recommend calculating PCI-Express
>bandwidth bus points for whatever platform one is using.
>
>
>For instance using the Intel X710-DA4, which could be capable in a
>maximal scenario of 80Gbps of traffic, ensure it's in at least a PCI-E
>3.0 x4 slot. And calculate the total number of PCI-E 3.0 x1 (or PCI-E 4.0
>if a very new system) lanes that exist and are connected to the CPU. Big
>difference between some options for Ryzen and Threadripper vs Intel CPUs,
>towards the lower end of the cost range.
>
>
>With recent Linux kernels if you have an Intel 510 or 710 series two or
>four port card in a slot that can't support its full capability, you'll
>get a warning in dmesg at boot time.
>
>
>
>On Thu, Oct 22, 2020 at 9:30 PM Jared Geiger  > wrote:
>
>
>   I use DANOS with Intel XL710 10G NICs in DPDK mode for linux based
>routing.
>
>   If you're doing routing protocols, allocate 2 CPU cores to the
>control plane and then a CPU core per 10G/1G interface for the dataplane,
>plus an extra core for good measure. So for a 4 x 10G router taking in
>full routes, 2 cores for control plane, 5 cores for the dataplane. Those
>cores should be Intel Xeon E5-2600v3/4 or newer and faster the clocks,
>the better.
>
>   Similar CPU core allocations if you choose TNSR.
>
>   On Thu, Oct 22, 2020 at 3:21 PM Jean St-Laurent via NANOG
>mailto:nanog@nanog.org> > wrote:
>
>
>   Chelsio cards are probably what you are looking for.
>
>   https://www.chelsio.com/terminator-6-asic/
>
>   It's closer to an asic than a traditional nic as the
>router/firewall rules
>   are pushed directly into the hardware.
>
>   I don't know how good they are with linux and they seem to be
>compatible.
>   https://www.chelsio.com/linux/
>
>   You will need to mess around a bit and fiddle here and there.
>If you don't
>   mind using FreeBSD instead of linux, you could achieve a
>smoother and more
>   integrated experience.
>
>   Jean
>
>   -Original Message-
>   From: NANOG  > On Behalf Of micah
>   anderson
>   Sent: Thursday, October 22, 2020 5:31 PM
>   To: Philip Loenneker  >; NANOG
>   mailto:nanog@nanog.org> >
>   Subject: RE: Linux router network cards
>
>
>   Thanks for the reply.
>
>   Philip Loenneker  > writes:
>   > Take a look at the Mellanox ConnectX 5 series of cards. They
>handle
>   > DPDK, PVRDMA (basically SR-IOV that allows live migration
>between
>   > hosts), and can even process packets within the NIC for some
>
>   From what I can tell, SR-IOV/PVRDMA aren't really useful for
>me in building
>   a router that wont be doing any virtualization.
>
>   If the card can do DPDK, can it do XDP?
>
>   > The slidedeck for the presentation is here:
>   > https://www.ausnog.net/sites/default/files/ausnog-
>2019/presentations/1
>   > .9_Rhod_Brown_AusNOG2019.pdf
>   >
>   > It's heavily targeting virtualised workloads but some of the
>feature sets
>   apply to bare-metal uses too.
>
>   Yeah, this wont be a virtualized environment, just a router
>passing packets,
>   dropping them, handling bgp and collecting flows.
>
>   --
>   micah
>
>

RE: outlook inbound email issues?

[Keith Medcalf]

Outlook is a client.  Microsoft e-mail servers run Sex-Change and the 
outlook.com domain refers to the servers, not the clients.  The Outlook client 
can "connect" to just about any server ever written but has nothing to do with 
Microsoft Sex-Change servers.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>nanog
>Sent: Friday, 23 October, 2020 22:40
>To: nanog@nanog.org
>Subject: outlook inbound email issues?
>
>I have a client who is receiving 50% of their mail on outlook servers
>for the past few hours.
>
>MX records point to:
>x-com.mail.protection.outlook.com has address 104.47.38.36
>x-com.mail.protection.outlook.com has address 104.47.36.36
>
>Anyone aware of outlook issues or have someone they can poke to check
>into this?  (Both answer smtp requests, guessing a queue is backed up
>somewhere.)
>
>thanks
>bill
>
>--
>This email has been checked for viruses by Avast antivirus software.
>https://www.avast.com/antivirus

RE: Weather Service faces Internet bandwidth shortage, proposes limiting key data

[Keith Medcalf]

Simply get rid of the gigabytes of JavaScript and stupidly designed crap
and hire someone who knows what they are doing and a bandwidth DOWNGRADE
will be in order.  The root cause is incompetence and it can be fixed by
getting rid of all the children and hiring someone who knows what they
are doing.


--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>Rich Kulawiec
>Sent: Thursday, 10 December, 2020 01:13
>To: nanog@nanog.org
>Subject: Fwd: Weather Service faces Internet bandwidth shortage,
proposes
>limiting key data
>
>- Forwarded message from Dave Farber  -
>
>> From: Dave Farber 
>> Date: Thu, 10 Dec 2020 15:47:44 +0900
>> Subject: [IP] Weather Service faces Internet bandwidth shortage,
>proposes limiting key data
>>
>> Weather Service faces Internet bandwidth shortage, proposes limiting
>key data
>> The National Weather Service is proposing to place limits on
accessing
>its
>> life-saving weather data in a bid to fix Internet outages.
>> By Jason Samenow and Andrew Freedman
>>
>> https://www.washingtonpost.com/weather/2020/12/09/nws-data-limits-
>internet-bandwidth/
>
>[snip]
>
>
>This seems like a problem that this group could solve rather rapidly
with
>minimal
>incremental expense.  It also seems like one that's very much worth
>solving.
>
>---rsk

RE: Are the days of the showpiece NOC office display gone forever?

[Keith Medcalf]

On Tuesday, 22 December, 2020 22:42, Wayne Bouchard wrote:
>On Wed, Dec 23, 2020 at 02:58:32PM +1000, Robert Brockway wrote:
>> On Thu, 17 Dec 2020, Tom Beecher wrote:

>> If the last 50 years has shown us anything it is that humans and
>> computers working together can achieve far more than either in
>> isolation.

> And if the last 15 years has shown us anything, it is that when you
> can't get past the auto-attendant and talk to a real human, and if
> that person can't talk to you like a person instead of reading scripts
> at you, your stress levels go way up as does your desire to break
> things. Automation in customer service (or excessive emphasis on
> procedures) is a really nice way of taking a five minute problem and
> turning it into an hour long ordeal.

The correct term of art for these humans that execute "scripts" when
answering inquiries is "flapper".  Often there are multiple layers of
"flapper" before one can communicate with someone who has any clue what
they (or you) are speaking about.  This is deliberate in an attempt to
cull the wheat from the chaff of the support calls because 99.999%
of callers are "chaff" and do not have a problem that is worthy of
attention by someone who knows what they are doing.

Many organizations which employ "flappers" have "flapper bypass systems"
in place in which there are either "magical incantations" or perhaps an
entry in the CRM system that identifies the probability that a caller is
"wheat" vs "chaff" so that the multi-level flapper system can be
bypassed.

There are even a few organizations which do not employ flappers at all
-- though they are few and far between.

If an organization does not have a functional "flapper bypass system"
then usually the most effective system to bypass multiple layers of
flappers is what is called the "shit principle".  The "shit principle"
states that shit works best when flowing downhill and therefore the most
effective "flapper bypass" is to direct the problem to the higest level
executive in the organization with the least probability of being able
to address the issue.  That person will simply direct an under-thing to
"take care of this and have them stop bothering me" which will result in
you immediately having the issue resolved by a competent individual.

Organizations without other functional "flapper bypass" procedures
usually have a huge organization dedicated to addressing issues raised
through the "shit principle" since this is, in reality, their chosen
"flapper bypass" system.

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

RE: [External] Re: 10g residential CPE

[Keith Medcalf]

>If the operator wants to keep bufferbloat low you will not be able to
>utilise your 1 Gbps to that speed when downloading from distant servers.
>But with the same bufferbloat measured in milliseconds you will still
>have a 10x bigger buffer and thus 10x bigger bandwidth delay product.
>That translates to 10x the speed.

I should think that the speed were limited to some fraction of the speed of 
light being either the speed of signal propagation in copper or of photon 
travel in glass, and completely unrelated to bufferbloat or anything of that 
ilk.

1 Gps is a measure of volume, not of speed.  The speed is constant.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: [External] Re: 10g residential CPE

[Keith Medcalf]

On: Sunday, 27 December, 2020 03:26, Mark Tinka wrote:

>In the end, and for various reasons, I settled on renewables.

Me too.  On top of that, diesel and gasoline are pretty reliable.  Though some 
people may argue about "renewables" the fact is that it is all a matter of 
time-frame.  Solar power, for example, is not renewable.  Once it is all used 
up, it will not "renew" itself -- and this "using up" process is quite 
independent of our usage of it, as it happens.  The time to depletion may be 
somewhat long, but it still has a time to depletion.  Oil and Gas, however, is 
a "renewable" resource and as a mere physical and chemical process it is 
occurring at this very moment.

The "greenies" simply have bad colloquial language usage.  This is probably as 
a result of a failure to understand even rudimentary physics and chemistry and 
operating on miniscule time-scales.

On the other hand, the aliens could be quite pissed when they return to 
retrieve their fuel stash and discover that we have used it all.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: 10g residential CPE

[Keith Medcalf]

On Monday, 28 December, 2020 10:48. Darin Steffl wrote:

>The "Free" service doesn't cover your cost of support which is much
>higher for residential than any business customer. Our residential
>customers call at least 15x more often compared to business customers
>compared on a 1:1 ratio.

Are you sure that is not related to "residential services" being of a generally 
lower quality than business services?  It has been my experience that shoddy 
service generates higher need for "support" than does "non-shoddy" service.  In 
this regard, the price for "business" services should be less than "residential 
service" by a couple of orders of magnitude since it costs orders of magnitude 
more money to "support" shoddy services than non-shoddy services.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: NDAA passed: Internet and Online Streaming Services Emergency Alert Study

[Keith Medcalf]

>I think the challenge here is that there's a category of people
>who don't have cell phones, who don't have cable TV, but
>receive content over their internet connection.  I happen to
>live with someone like that, so I know it's a non-zero portion
>of the population.

I pay for my Internet connection and I do not want "your shit" to be spending 
"my money".  If you think this is oh so important then *YOU* can pay to install 
at your sole expense, a device which emits your silly warnings -- I do not want 
them.  You will also have to negotiate for easement rights on my Private 
Property and those are not going to be given away for cheap.

And even if you do pay me %1 Million a month that it will cost to acquire the 
necessary easement on my Private Property, I will put your annoying shit inside 
a soundproof faraday cage in the closet.

So you might as well just not bother.

This is the same thing I tell shithead politicians and pollsters that cause my 
phone to ring.  If you wish to speak with me then you can pay to install your 
own communications equipment at your own expense.  That does not mean that I 
will be answer or pay any attention to it or refrain from taking action to 
prevent it from disturbing me.  For the shitheads that use robotic callers I 
have a wonderful digital war-dialer that can tie up a whole central switch -- 
one way or the other the assholes will be forced to cease their disgusting 
behaviour!

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: Parler

[Keith Medcalf]

That all only matters if you (the oppressor) believes that your victim
(the oppressed) has the means to "bring peace to their enemy" either by
wielding devices of War and Destruction or through the Legal System.
This is the case with all "habitual criminals" such as AWS, Twitter,
Facebook, Google, Law Enforcement, and the Government.

Given that the number of "victims" capable of obtaining "redress" for
the improper actions of the above mentioned "habitual criminals" is very
low, there is little risk of the "habitual criminal" suffering any
consequence for their actions, thus they consider themselves impervious
and may act as they please whenever they please with zero consequence.

You will note that the aforementioned "habitual criminals" *never* act
against those capable of defending themselves or bringing them peace.

This is simply the way of the world.  It has always been thus and will
always be thus.

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>Wayne Bouchard
>Sent: Sunday, 10 January, 2021 06:55
>To: sro...@ronan-online.com
>Cc: nanog@nanog.org
>Subject: Re: Parler
>
>Ah, yes... re-enter the experiences of Compuserve. For that, I give
>you Telecom '96 and section 230 which, they think, makes them exempt
>from such things. Regardless, there are a whole lot of little
>triggering pebbles that risk being trodden upon here. From monopolist
>behaviour to basic discrimination (just because you're a private
>company, you do not have the right to descriminate in who you are
>willing to do business with. Wasn't that the whole point of the
>wedding thing?), there are many things to be careful of here, even
>though it will probably be a hard sell. Still, damned irresponsible to
>risk touch that precedent, IMO. It means a whole lot of flak comes
>around to the rest of us.
>
>On Sun, Jan 10, 2021 at 08:42:56AM -0500, sro...@ronan-online.com
wrote:
>> While Amazon is absolutely within their rights to suspend anyone they
>want for violation of their TOS, it does create an interesting problem.
>Amazon is now in the content moderation business, which could
potentially
>open them up to liability if they fail to suspend any other customer
who
>hosts objectionable content.
>>
>> When I actively hosted USENET servers, I was repeatedly warned by in-
>house and external counsel, not to moderate which groups I hosted based
>on content, less I become responsible for moderating all groups,
>shouldn???t that same principal apply to platforms like AWS and
Twitter?
>>
>> Sent from my iPhone
>>
>> > On Jan 10, 2021, at 3:24 AM, William Herrin  wrote:
>> >
>> > ???Anybody looking for a new customer opportunity? It seems Parler
is
>in
>> > search of a new service provider. Vendors need only provide all the
>> > proprietary AWS APIs that Parler depends upon to function.
>> >
>> > https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-
>suspension/
>> >
>> > Regards,
>> > Bill HErrin
>
>---
>Wayne Bouchard
>w...@typo.org
>Network Dude
>http://www.typo.org/~web/

RE: Parler

[Keith Medcalf]

>It's amazing how far the world has stumbled that "fomenting violent
>insurrection and calling for the murder of elected officials" now
>falls under standard T&Cs against abusive behaviour where this used
>to be perfectly fine a year ago.

The world is now a different place with the election of the Nazi's.

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

RE: Parler

[Keith Medcalf]

That is an exercise for the reader.  Unfortunately I do not have the
answer sheet for the exercizes to hand yet.

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

>-Original Message-
>From: James Laszko 
>Sent: Sunday, 10 January, 2021 15:07
>To: Keith Medcalf 
>Subject: RE: Parler
>
>Which ones are the Nazi’s?
>
>
>
>
>
>James
>
>
>
>From: NANOG  On Behalf
Of
>Keith Medcalf
>Sent: Sunday, January 10, 2021 1:59 PM
>To: nanog@nanog.org
>Cc: niels=na...@bakker.net
>Subject: RE: Parler
>
>
>
>
>
>
>
>>It's amazing how far the world has stumbled that "fomenting violent
>
>>insurrection and calling for the murder of elected officials" now
>
>>falls under standard T&Cs against abusive behaviour where this used
>
>>to be perfectly fine a year ago.
>
>
>
>The world is now a different place with the election of the Nazi's.
>
>
>
>--
>
>Be decisive.  Make a decision, right or wrong.  The road of life is
>
>paved with flat squirrels who could not make a decision.
>
>
>
>
>
>

RE: Parler

[Keith Medcalf]

>The first amendment deals with the government passing laws restricting
>freedom of speech. It has nothing to do with to whom AWS chooses to sell
>their services. It is also not absolute (fire, crowded theater, etc.)

You are correct and incorrect.  The First Amendment prohibits the Government 
from passing laws which constitute "prior restraint".  It does nothing with 
respect to anyone other then the "Government" and its agents.

You are also incorrect.  Freedom of Speech is Absolute.  There is no prior 
restraint which precludes you from "(fire, crowded theatre, etc.)" whatever 
that means.  That does not mean that speech does not have "consequences".  The 
first amendment only protects against prior restraint, it does not protect 
against the suffering of consequences.  And of course "consequences" come AFTER 
the speech, not BEFORE the speech.

Furthermore your "(fire, crowded theater, etc.)" (whatever the hell that means) 
cannot, as a matter of fact, possibly justify any action taken prior to the 
so-called speech having been made as that would be an assumption of fact not in 
evidence (also known as a hypothetical question) and the courts do not rule on 
hypotheticals.  If you do not understand the difference then perhaps you should 
be sentenced to death since you have a hand, and having a hand it could hold a 
gun, and since it could hold a gun, you could also murder someone.  So 
therefore you should be put to death now as "prior restraint" to prevent you 
from committing murder.

I am neither a lawyer nor a yankee doodle and I know these facts to be 
self-evident.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: Parler

[Keith Medcalf]

That would make me wonder how many cases there have been of someone
"shouting fire in a crowded theatre" where there was no fire and at
least one person died as a result; and the charge laid against the
shouter was "reckless disregard for human life resulting in culpable
homocide" and the elements of that offence being proved, was dismissed
on the basis that the "speech" was protected by the first amendment?

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

>-Original Message-
>From: Rod Beck 
>Sent: Monday, 11 January, 2021 05:13
>To: Keith Medcalf 
>Subject: Re: Parler
>
>Hi,
>
>
>Your distinction sounds specious. The Courts have consistently that the
>1st amendment protects free speech from government retaliation in many
>instances. It is not just prior restraint.
>
>
>Best,
>
>
>Roderick.
>
>
>
>
>From: NANOG 
on
>behalf of Keith Medcalf 
>Sent: Monday, January 11, 2021 3:11 AM
>To: nanog@nanog.org 
>Subject: RE: Parler
>
>>The first amendment deals with the government passing laws restricting
>>freedom of speech. It has nothing to do with to whom AWS chooses to
sell
>>their services. It is also not absolute (fire, crowded theater, etc.)
>
>You are correct and incorrect.  The First Amendment prohibits the
>Government from passing laws which constitute "prior restraint".  It
does
>nothing with respect to anyone other then the "Government" and its
>agents.
>
>You are also incorrect.  Freedom of Speech is Absolute.  There is no
>prior restraint which precludes you from "(fire, crowded theatre,
etc.)"
>whatever that means.  That does not mean that speech does not have
>"consequences".  The first amendment only protects against prior
>restraint, it does not protect against the suffering of consequences.
>And of course "consequences" come AFTER the speech, not BEFORE the
>speech.
>
>Furthermore your "(fire, crowded theater, etc.)" (whatever the hell
that
>means) cannot, as a matter of fact, possibly justify any action taken
>prior to the so-called speech having been made as that would be an
>assumption of fact not in evidence (also known as a hypothetical
>question) and the courts do not rule on hypotheticals.  If you do not
>understand the difference then perhaps you should be sentenced to death
>since you have a hand, and having a hand it could hold a gun, and since
>it could hold a gun, you could also murder someone.  So therefore you
>should be put to death now as "prior restraint" to prevent you from
>committing murder.
>
>I am neither a lawyer nor a yankee doodle and I know these facts to be
>self-evident.
>
>--
>Be decisive.  Make a decision, right or wrong.  The road of life is
paved
>with flat squirrels who could not make a decision.
>
>
>

RE: Re Parler

[Keith Medcalf]

I thought y'all yankee doodles had this thing called the Communication Decency 
Act section 230 that prevented a "service provider" from being responsible for 
the content of third-party's -- whether or not they were acting as a publisher; 
and, also the principle of law that an agreement to violate the law (as in a 
Contract which ignored that provision that the "service provider" was not 
liable for the content provided by third-parties) was nul ab initio?

Therefore it would appear to me that AWS has not a leg to stand on, that the 
terms of the contract which violate section 230 constitute a prior agreement to 
violate the law and therefore are a nullity, and that Parler is entitled to 
specific performance of the contract and/or damages, including aggravated or 
punitive damages, from Amazon.

The only exception would be if the "content" were Criminal and that would 
require a court finding that the content was Criminal but, such facts not in 
evidence, Amazon has violated the law and should be held liable.  You cannot 
convict someone of murder and have them executed simply because they have a 
hand which may hold a gun which may then be used to commit murder in order to 
prevent the murder.

First there must be establishment of the fact of the murder, not the mere 
establishment of a hypothetical fantasy of fact.

But then again it is likely that the lawyers representing Parler are of low 
ability and unable to make the case required.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>Jeff P
>Sent: Wednesday, 13 January, 2021 10:43
>To: nanog@nanog.org
>Subject: Re Parler
>
>ICYMI: Amazon's response to Parler Antitrust relief:
>
>https://cdn.pacermonitor.com/pdfserver/LHNWTAI/137249864/Parler_LLC_v_Ama
>zon_Web_Services_Inc__wawdce-21-00031__0010.0.pdf
>
>JeffP
>je...@jeffp.us 
>
>

RE: Re Parler

[Keith Medcalf]

On Thursday, 14 January, 2021 04:53, adamv0...@netconsultings.com wrote:

>https://aws.amazon.com/agreement/
>7.2 Termination.
>(a) Termination for Convenience. You may terminate this Agreement for any
>reason by providing us notice and closing your account for all Services
>for which we provide an account closing mechanism. We may terminate this
>Agreement for any reason by providing you at least 30 days’ advance
>notice.

How do you know that this is the contract that was in effect?  That is an 
assumption of fact not in evidence.  Furthermore, that provision requires at 
least 30 days notice.  If that clause was in effect AND it was used as you 
suggest THEN UNLESS at least 30 days notice was given the plaintiff Parler is 
entitled to specific performance of the contract and/or aggravated/punitive 
damages for Amazon's violation of the contract terms.

>How/where does the above violate the Communication Decency Act section
>230?

It does not.

>See AWS can claim they terminated the contract because it was sunny
>outside and they just felt like it, in other words using section 7.2 (a)
>of their customer agreement.

Why anyone in their right mind would enter into such a contract is beyond my 
ken and would only be done by a lunatic.

>With regards to business continuity,

>My experience is that the above is a standard clause in all contracts
>(and 30 days is pretty standard as well),

I have never ever seen that in any contract to which I am a party.  Plus you 
are also claiming that a "contract of adhesion" is a valid contract, which it 
is not (at least not in countries with rational legal systems).

>I know we negotiated longer advance notices with some of our vendors, but
>I'm actually not sure what it says on our contracts with say big router
>vendors?

That is your own business issue and as a party to the contract, you are free to 
negotiate contract terms as you please.

>Do you folks?

>If say Cisco tells you one day that "in 30days we stop taking your
>support calls cause we don't feel like working with you anymore", and
>you'd be like omg the license on the 32x100G core cards will expire in 2
>months and I can't renew cause these guys won't talk to me anymore.

So, that is Cisco's problem, not yours.  I would take the position that if 
Cisco no longer wants to take money then that is their choice and it has 
absolutely zero effect on the validity of the license (in fact, the license is 
now free).  Of course, it depends on what the contract says, if it says 
anything at all that is relevant.

>Also an interesting business continuity case is when a vendor goes under
>(yes highly unlikely in case of AWS/Juniper/Cisco/etc..), but do you have
>contractual terms governing this case?

Unless you are stupid, you do.  However in my experience there is a large 
quantity of stupid people in the world.

>What if you're licenses are about to expire say in 2 months and the
>vendor goes under? Even if the product still works can you actually
>legally use it? Do you own it then? Etc..

Yes.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: Re Parler

[Keith Medcalf]

On Thursday, 14 January, 2021 10:02, Mel Beckman  wrote:

>I, however, do know that this is the contract that was in force. Because
>I read the lawsuit, and the contract, which I’ve verified is identical to
>the one posted online, is included as an exhibit (although the courts
>managed to get the pages out of order).

>And yes, Amazon had a duty to provide 30 days notice in advance of
>termination. Amazon says they are calling this a “suspension”, but that’s
>weaselwording, because they told Parler that they had secured Parler’s
>data so that Parler could “move to another provider.” You would only do
>that in a termination.

>Parler also has an excellent antitrust case, as the idea that three
>companies would simultaneously pull the plug on their services for a
>single common customer is going to be hard to explain to a judge.

>Right now I think Amazon’s safest escape from this mess is to restore
>Parlor’s services, and pay them damages. Otherwise, why would anyone do
>business with Amazon if they can pull the rug out with zero advance
>notice (Parler learned of Amazon’s termination from the news, since
>Amazon gave the media a scoop before notifying its customers).

>However you look at this, Amazon’s actions have huge implications for
>anyone using them for operational networking.

This result will only come to pass if Parler wins their lawsuit (which is 
likely) *AND* the FTC imposes a billion dollar fine against Amazon for their 
Fraudulent business practices.

Otherwise, Amazon will not change their Fraudulent Business Practices because 
they will determine that the COST associated with Fraudulent Business Practices 
is negligible, and there continues to be no shortage of stupid customers who, 
for some reason, insist on placing TRUST in the inherently UNTRUSTWORTHY, even 
when it that UNTRUSTWORTHYNESS has already been demonstrated as fact.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: Hosting recommendations ... ?

[Keith Medcalf]

>Is nested virtualization really a thing?

Real Computers have been running VMs inside VMs for about 50 years.  Bringing 
this technology to "bitty boxes" is a recent thing.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: 10 years from now... (was: internet futures)

[Keith Medcalf]

Net to mention, of course, that the Low Orbit constellation would need to be 
"parked" over China (or where-ever you want to access it).  I am quite sure 
that "shooting down" such low orbit stationary vehicles would not be too 
difficult.  And if they are owned by an adversary who has no permission to fly 
those objects in your airspace, I doubt that anything could be done about it.

If I owned a bunch of low orbit satellites costing millions of dollars each, I 
would not want to "park" them in low orbit over a hostile territory.

Then you also have the requirement to maintain positive control over the 
satellites which, unlike those in geostationary orbits, need to be under 
continual thrust and control in order to stay "parked".  I doubt that any 
"private" (ie, non-Government organization) could afford to do so without the 
cooperation of the state over which they are parking.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>Eric Kuhnke
>Sent: Sunday, 28 March, 2021 18:24
>To: na...@jima.us
>Cc: nanog@nanog.org
>Subject: Re: 10 years from now... (was: internet futures)
>
>I would also concur that the likelihood of Starlink (or a Oneweb, or
>Kuiper) terminal being used successfully to bypass the GFW or similar
>serious Internet censorship, in an authoritarian environment, is probably
>low. This is because:
>
>a) It has to transmit in known bands.
>
>
>b) It has to be located in a location with a very good, clear view of the
>sky in all directions (even a single tree obstruction in one section of
>the sky, relative to where the antenna is mounted will cause packet
>loss/periodic issues on a starlink beta terminal right now). Visually
>identifying the terminal would not be hard.
>
>
>c) Portable spectrum analyzers capable of up to 30 GHz are not nearly as
>expensive as they used to be. They also have much better GUIs and
>visualization tools than what was available 6-10 years ago.
>
>
>d) You could successfully train local law enforcement to use these sort
>of portable spectrum analyzers in a one-day, 8-hour training course.
>
>
>e) The equipment would have to be smuggled into the country
>
>f) Many people such as in a location like Iran may lack access to a
>standard payment system for the services (the percentage of Iranians with
>access to buy things online with visa/mastercard/american express or
>similar is quite low).
>
>
>
>There are already plenty of places in the world where if you set up a
>1.2, 1.8 or 2.4 meter C, Ku or Ka band VSAT terminal using some sort of
>geostationary based services, without appropriate government "licenses",
>men with guns will come to dismantle it and arrest you.
>
>I am not saying it is an impossible problem to solve, but any system
>intended for that sort of purpose would have to be designed for
>circumvention, and not a consumer/COTS adaptation of an off the shelf
>starlink terminal.
>
>
>
>
>
>
>
>
>
>On Sat, Mar 27, 2021 at 8:31 PM na...@jima.us 
>mailto:na...@jima.us> > wrote:
>
>
>   Please don't forget that RF sources can be tracked down by even
>minimally-well-equipped adversaries.
>
>   - Jima
>
>   -Original Message-
>   From: NANOG  > On Behalf Of scott
>   Sent: Saturday, March 27, 2021 19:36
>   To: nanog@nanog.org 
>   Subject: Re: 10 years from now... (was: internet futures)
>
>
>   On 3/26/2021 9:42 AM, Michael Thomas wrote:
>   > LEO internet providers will be coming online which might make a
>   > difference in the corners of the world where it's hard to get
>access,
>   > but will it allow internet access to parachute in behind the Great
>   > Firewall?
>   
>   > How do the Chinas of the world intend to deal with the Great
>Firewall
>   > implications?
>
>
>   This is what I hope will change in the next 10 years.  "Turning off
>the
>   internet" will be harder and harder for folks suppressing others,
>many
>   times violently, and hiding it from everyone else.  A small-ish
>antenna
>   easily hidden would be necessary.
>
>   scott
>
>
>
>

RE: Google IP Geolocation

[Keith Medcalf]

Does nothing.  Does it require permitting the unfettered execution of arbitrary 
untrusted and untrustworthy code perchance?

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

>-Original Message-
>From: NANOG  On Behalf Of
>William Guo
>Sent: Saturday, 10 April, 2021 02:49
>To: MunFai Lee 
>Cc: NANOG Mailing List 
>Subject: Re: Google IP Geolocation
>
>Do you mind trying https://ipinsight.io/ and see if they're correct
>locations (we're 100% confident)?
>
>And see if anyone from Google could have a try on our data to help its
>users.
>
>On Tue, Apr 6, 2021 at 8:28 AM MunFai Lee  > wrote:
>
>
>   We're also having similar issues - Google is detecting our Singapore
>IP range as coming from HK, and our HK Ip range as coming from Vietnam
>
>   Just applied for access to Google's ISP portal - let's see what
>happens.
>
>   If anyone else have any more ideas how to get Google to fix this,
>please do share - my users are getting fed up!
>
>
>
>   From: NANOG  > on behalf of Benjamin Hatton
>mailto:bhat...@htva.net> >
>   Sent: Tuesday, March 30, 2021 9:47 PM
>   Cc: NANOG Mailing List mailto:nanog@nanog.org> >
>   Subject: Re: Google IP Geolocation
>
>   Just as another viewpoint on this.
>
>   We do not peer or have GGC Cache servers, but I put in a request for
>a portal account after seeing this thread, and it was approved in less
>than 24h, so YMMV.
>
>   The only thing I can think of that is different, is that we do move
>enough traffic for Google to have us flagged as 'Your traffic levels
>qualify for Google Peering' (~2.5Gbps) and are an eyeball network.
>
>
>   Ben Hatton
>
>   Network Engineer | Haefele Connect
>
>   d:(607)589-8000 | b...@haefeleconnect.com
>
>
>
>
>
>
>   On Tue, Mar 30, 2021 at 9:15 AM Troy Kelly via NANOG
>mailto:nanog@nanog.org> > wrote:
>
>
>   We've also been denied access to the ISP portal.
>
>   When we replied as to why, we were told to not open another
>ticket. They aren't interested in conversation.
>
>
>   Sent from ProtonMail mobile
>
>
>
>    Original Message 
>   On 30 Mar 2021, 6:53 am, Mike Hammett < na...@ics-il.net
> > wrote:
>
>
>   I've had others at Google specifically say that portal
>should be used for that purpose, so maybe they need to make sure right
>and left hands know what the other is doing.
>
>
>
>
>   -
>   Mike Hammett
>   Intelligent Computing Solutions
>   http://www.ics-il.com
>
>   Midwest-IX
>   http://www.midwest-ix.com
>
>
>
>
>   From: "Josh Luthman"  >
>   To: "Christopher Morrow"  >
>   Cc: nanog@nanog.org 
>   Sent: Monday, March 29, 2021 1:52:48 PM
>   Subject: Re: Google IP Geolocation
>
>
>   https://isp.google.com
>
>
>   I signed up for an account there and they said:
>
>   "Currently, the Google ISP portal is designed for our
>partners of GGC, PNI or IX programs.
>
>   The access to portal is granted on request only to our
>partners."
>
>   Josh Luthman
>   24/7 Help Desk: 937-552-2340
>   Direct: 937-552-2343
>   1100 Wayne St
>   Suite 1337
>   Troy, OH 45373
>
>
>   On Mon, Mar 29, 2021 at 2:08 PM Christopher Morrow
>mailto:morrowc.li...@gmail.com> > wrote:
>
>
>
>
>   On Mon, Mar 29, 2021 at 1:59 PM Josh Luthman
>mailto:j...@imaginenetworksllc.com> >
>wrote:
>
>
>   Google ISP specifically told me they 
> didn't
>want to do deal with geolocation on the ISP portal.
>
>
>
>
>   unsure who 'google isp' is here, but ... I 
> think if
>you point at a properly formed geo-location data file it'll get eaten and
>produce proper results for you.
>   you do have to add that in your isp portal:
>  tri-pipe-thingy -> configuration -> IP
>geolocation
>   and /register feed/ button on that page.
>
>
>   Josh Luthman
>   24/7 Help Desk: 937-552-2340
>   Direct: 937-552-2343
>   

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

[Keith Medcalf]

>On Wednesday, 30 June, 2021 13:53, Michael Thomas  wrote:

>From an automated standpoint, I really don't care about whether a phone
>number is authentic, I care about the domain that onramped it so I can
>theoretically punish it. It's the people who are allowing the spoofing
>that is the real problem which directly analogous to email open relays.

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

If a law were passed that imposed a $1 million penalty payable by the 
terminating carrier to each subscriber for each such call a subscriber received 
together with a term of 1 year imprisonment at hard labour for the CEO of the 
terminating carrier, the whole issue would be fixed before lunch-time.

THe motivated self-interest however, is to do nothing.  Eventually someone will 
bring a racketeering claim against the terminating carriers and they will then 
be properly "motivated" to stop profiteering off criminal activity.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

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

[Keith Medcalf]

>On Friday, 9 July, 2021 16:32, K. Scott Helms wrote:

>Robocalls really aren't a product of the legacy PSTN.  Today almost none
>of them originate from anywhere but VOIP.  Now, you can certainly say
>that if SS7 had robust authentication mechanisms that we could then trust
>caller ID (more) but there's no sign of us abandoning the PSTN anytime
>soon.  Having said that, there's any number of protocols we rely on today
>that have the exact same gap.  BGP is arguably even worse than SS7.

The root of the problem is that the "Caller ID" is not a "Caller ID".  If there 
were a requirement for "truth in advertizing" it would properly be called the 
"Caller Advertizement" because it is primarily intended as an advertizement by 
the caller, and not an ID of the caller.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

RE: ICANN extracts $20m signing fee for $1bn dot-com price increases and guess who's going to pay for it?

[Keith Medcalf]

On NANOG list , Dan Hollis 
wrote:

>https://www.theregister.co.uk/2020/01/07/icann_verisign_fees/

Operator of the dot-com registry, Verisign, has decided to pay DNS
overseer ICANN $4m a year for the next five years in order to “educate
the wider ICANN community about security threats.”

>98% of the comments were opposed.

>How many / which companies would have to get onboard in order to get
>enough support for an icann alternative?

>Is such a thing even feasible?

Forget about being opposed or not.  If ICANN wants to buy education
about security threats why are they receiving money?  Quite obviously
something fishy is going on (or El Reg is full'o'shit).

I'd like a Phd in Physics.  Please give me $2million for each of the
next five years for the privilege of lecturing me.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

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

[Keith Medcalf]

On Wednesday, 8 January, 2020 14:35. Octolus Development  
wrote:

>Sony are currently "looking into it" but they do not seem to care much. I
>am a customer of Sony, I own PlayStation consoles and I am not able to
>access their service. They tell me to change my IP instead of solving the
>actual problem with this exploit.

Stop doing business with Criminal Organizations (SONY).  Problem solved.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: QUIC traffic throttled on AT&T residential

[Keith Medcalf]

On Thursday, 20 February, 2020 08:31, Ca By  wrote:

>On Thu, Feb 20, 2020 at 8:34 AM Tom Beecher  wrote:

>   I only wish I were insane; but from where I'm sitting, QUIC
>has broken
>   my internet, and the resolution is blocking QUIC.
>
>   The QUIC protocol itself isn't breaking anything ; some middlebox is
>breaking QUIC. It's likely collateral damage from honest attempts to
>mitigate bad stuff. Blocking QUIC at your home edge surely helps to some
>degree, but the upstream issue still remains.

>   I recall reading a draft from the WG about having things open a
>parallel TCP connection in case UDP got horked for seamless fallback, but
>I don't remember if it ever moved past that, or if anyone actually
>implemented it.

>UDP is broken
>
>The Google devs said it would in fine in 2014
>
>They said it would be “exciting”

UDP is not "broken".  UDP is the UNRELIABLE DATAGRAM PROTOCOL and it is living 
up to its name!  What is broken is something pretending that the "U" in UDP 
means something other than UNRELIABLE and then pretending their use of an 
unreliable delivery mechanism makes it reliable when that clearly is not the 
case.

In other words, applying a coat of paint to a sows ear to make it look like a 
silk purse does not make the sows ear into a silk purse.  It is still just a 
sows ear painted to look like a silk purse, and still behaves like a sows ear.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: akamai yesterday - what in the world was that

[Keith Medcalf]

Warzone is a 83-101GB download for new, free-to-play users*.

And I remember the days when that would have taken 10 and a half years to 
download and consumed 56,000 floppy diskettes.

My, how times have changed!

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

I don't know but we just issued travel restrictions to the United States
as it is now a Hot Spot for the unrestricted spread of the coronavirus
which causes COVID-19.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of g...@1337.io
>Sent: Thursday, 12 March, 2020 11:22
>To: nanog@nanog.org
>Subject: COVID-19 vs. our Networks
>
>With talk of there being an involuntary statewide (WA) and then
national
>quarantines (house arrest) for multiple weeks, has anyone put thought
>into the impacts of this on your networks if/when this comes to
fruition?
>
>We're already pushing the limits with telecommuters / those that are
WFH,
>but I can only imagine what things will look like with everyone stuck
at
>home for any duration of time.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Thursday, 12 March, 2020 20:37, Valdis Kletnieks
 wrote:

>On Thu, 12 Mar 2020 18:08:05 -0600, "Keith Medcalf" said:

>> I don't know but we just issued travel restrictions to the United
>> States as it is now a Hot Spot for the unrestricted spread of the
>> coronavirus which causes COVID-19.

> Hopefully they're more sensible restrictions than the US policy that
> prohibits travel from most of Europe except the UK... but only for
> foreigners.  If you're a US citizen, you're still perfectly welcome
> to go to Italy and come home with a few extra microbes to pass around
> a week after you return.

No idea what the policy for foreigners is, as that is a matter of
Federal jurisdiction.  And our Prime Minister is currently in
"self-isolation" apparently.

> The word for anybody who designs a network firewall with that sort of
> logic is "pwned".  Just sayin'.

These are Provincial policies.  The Federal Government cannot prohibit
Canadian citizens from entering Canada but the Province is in charge of
matter of Health and Civil Rights, so as soon as they enter the Province
from outside Canada they are "requested" to self-isolate for 14-days.
This is for citizens.  Don't know what the policy is for non-Canadians.

> (Fortunately, I'm in a position to hide in my apartment and only
emerge
> for grocery shopping at 2AM until things wind down... Hope everybody
else
> has a good contingency plan)

Yeah, sounds like a plan.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

If it is "critical" you need a dedicated circuit.  If it is "meh, who gives a 
shit", then you can go though the Internet.

The root of the issue is that some idiot did a bad Risk Assessment.  Hope it 
got fired or killed so it won't do this again in the future.

Hope you also learned something as well.  Freedom of the Press belongs to He 
Who Owns the Press.  If you are using someone else's presses (particularly 
without directly paying and contracting with that party for the use of their 
presses), you will live or die according to the whim of the owner of the Press, 
and there is SFA you can do about that.  That is how the world has worked for 
billions of years.  You would think people would understand that by now.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of Mike Bolitho
>Sent: Saturday, 14 March, 2020 12:02
>To: Clayton Zekelman 
>Cc: nanog 
>Subject: Re: COVID-19 vs. our Networks
>
>First of all, we use a mixture of layer 2/3 private lines and DIA
>circuits. You don't know our infrastructure, stop being condescending. It
>goes against the spirit of this mailing list.
>
>Second, yes, the Internet is protected. Both public and private lines. I
>know this because we have TSP coded circuits and I spent four years at a
>Tier I ISP servicing TSP coded circuits
>
>Third, the trouble we had was a third party service having congestion
>issues. They are hosted by the same CDN as Call of Duty. The problem was
>both outside of our control and our third party service's control. The
>chokepoint was between ISPs/IXPs and the CDN. I've seen this time and
>time again while working at the aforementioned ISP. Saturated links on
>ISP/IXP/CDN networks. This is where the TSP code comes in. In this day
>and age of cloud services, it is financially unfeasible for every company
>to have a private line to every single cloud provider. That's
>preposterous to even suggest.
>
>- Mike Bolitho
>
>
>On Sat, Mar 14, 2020 at 10:40 AM Clayton Zekelman  > wrote:
>
>
>
>
>   The Internet is not a telecommunications service, according to your
>FCC.  If you want predictability, buy WAN circuits, not Internet
>circuits.   If your provider is co-mingling Internet and WAN traffic
>(i.e. circuits with defined endpoints vs. public Internet or VPN), then
>you need to talk to them about their prioritization.
>
>   If you have mission critical applications, put them on mission
>critical infrastructure, not the public Internet.
>
>   Oh, that's right - Internet circuits are cheaper than WAN circuits
>
>
>Clayton Zekelman
>Managed Network Systems Inc. (MNSi)
>3363 Tecumseh Rd. E
>Windsor, Ontario
>N8W 1H4
>
>tel. 519-985-8410
>fax. 519-985-8409

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Tuesday, 17 March, 2020 03:31, Mark Tinka  wrote:

>On 16/Mar/20 21:08, Owen DeLong wrote:

>> For up to date local information, check with the local public health
>> authority in your jurisdiction. In the US, that will usually
>> be your county public health agency. In some cases, individual
>> municipalities also have public health departments.

>It's the price we pay for hyper-connectedness (not trying to coin a
>phrase, hehe).

>Everybody (especially the kids) lives on their device 99% of the time.
>If you're not on their device, you are not relevant to them.

If by "device" you mean "computer", then you are correct.

>When was the last time you bought a newspaper?

Never in 57 years.

>How many times do your kids watch the news, either on TV or their device?

Never because I don't have any.  But I don't either.  Babbling idiots don't do 
anything for me.

And before you ask, I get "important news" directly.  If the building next door 
falls over, I notice.  Otherwise I don't think there *IS* such a thing as 
*important news*, or I can only think of a couple of "important news" that have 
happened in my entire lifetime on one hand.  In no case was a babbling idiot or 
propaganda purveyor of any particular use.

>But they are all over WhatsApp, Instagram, Twitter, SnapChat, WeChat, et al.

Never used any of those.  They are just hangouts for yet more babbling idiots.  
Some of them are even named appropriately -- like Twitter -- which as I 
understand it is the place where all the twits congregate.

>And even if they have the "News" app on their phone, they probably have never 
>opened it.
>If they opened it, they didn't find value in it.

Correct.  No value there.  Just more babbling idiots.

>On average, the we (and the kids) will give your app two tries; if we
>don't like it, you're out - which explains why we all have 3,000 apps on
>our phones, but only use 2 or 3 of them most consistently.

I have an e-mail app on my phone that is connected to my (not someone else's) 
e-mail server that handles e-mail, contacts, and calendaring in a distributed 
fashion that is the same on every "device" I own.  If a device will not work 
with my e-mail server, does not function as I need it to function, or is not 
safe and secure to my requirements, I do not buy that device (that means that 
the list of devices that I refuse to buy and will not permit in the same room 
as me is VERY VERY VERY long).  Most of the other rubbish has been banished 
because it is nothing more than yet more piles of babbling idiots.

>Whoever wants to get professional and verified information out (to the
>kids who live on their devices) needs to find a way to do so in a manner
>we find relevant, otherwise we'll simply keep trading mis-information
>for whatever reason we feel gives us value.

Send e-mail.  Or provide an e-mail list.  I will not fiddle faddle with going 
to websites chock full of malicious websites nor will I let any Tom Dickhead 
send their malicious crap to me.  By the time the malicious crap infestation is 
filtered out, there is nothing left.

Then again I am an old fart.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Tuesday, 17 March, 2020 11:04, Mike Bolitho  wrote:

>>The answer is don't shove application traffic that has tight service
>>level requirements onto the public internet at large and expect the same
>>performance as private circuits or other SLA protected services.

>I keep seeing this over and over again in this long thread. What's your
>suggestion? How does a hospital, with dozens of third party
>applications/devices across multiple cloud platforms do this?

Do what everyone else that has "critical infrastructure" does.  Put a 
requirement in the RFP that the thing you want to buy must continue to operate 
even when totally isolated from the outside world.  And then do not select to 
purchase products that do not meet this requirement.

It is quite simple actually.  We do this all the time with great success.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Tuesday, 17 March, 2020 15:48, Rich Kulawiec  wrote:

>On Tue, Mar 17, 2020 at 11:35:59AM -0700, Owen DeLong wrote:

>> Anything in the healthcare vertical that is outside of the medical
>> providers control/ownership is a result of the medical provider
>> buying into that model on some level. STOP DOING THAT.  (How am I
>> suddenly reminded of the old adage ???Doctor, doctor, it hurts when I
>> do this!??)

>> I understand how the allure of lower costs and the frustration of
>> ???every vendor does this, we can???t find one who doesn???t???
>> plays out.
>>> However, the only way ???every vendor does it??? will continue
>> is if every vendor continues to be able to make sales without
>> changing.

>Fought this battle, lost this battle.

>Why?

>Because the people with the authority to make purchasing decisions are
>not the people who will be on the phone to some vendor's tech support
at
>3 AM on a Sunday morning, frantically pleading with them to fix a
problem
>because they really need that piece of equipment to work right now.

So you failed because you did not require the person making the decision
to take responsibility for their decision.  That is, your organization
has a severely flawed process wherein the "R" for making the decision is
not the same person as has the "R" for the repercussions.

>Decisions are no longer based on the greater good or on anticipating
>worst case scenarios or on maximizing preparedness or anything that
>we might hope they're based on.  They're based, coldly and
calculatingly,
>on money.

No, they are based on whatever the specification for making decisions
happens to be.  If you have chosen that basis to be "cheapest bidder",
then that is what you can expect to receive.

>If you want this to change -- and I sure would like it to change --
>then money needs to be entirely removed from that calculation.  That is
>a problem whose solution lies outside the scope of NANOG.

No.  One simply has to assign a "cost" to "suitability for use".  For
example, if you put out an RFQ for a CT Machine and someone bids a bag
of peanuts for $1.50, that is probably the lowest bid, and that is what
you will get if you choose based entirely on the lowest bid.  However,
if you also require that the purchased machine also actually be capable
of performing Computed Tomography then clearly that $1.50 bid will be
rejected.

You simply have to define what you want to achieve, then do it.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Wednesday, 18 March, 2020 05:24, Rich Kulawiec  wrote:

>On Wed, Mar 18, 2020 at 03:43:37AM -0600, Keith Medcalf wrote:

>> So you failed because you did not require the person making the
>> decision to take responsibility for their decision.  That is, your
>> organization has a severely flawed process wherein the "R" for
>> making the decision is not the same person as has the "R" for
>> the repercussions.

>The use of "you/your" here and throughout is misplaced and
inappropriate.

It is the "Royal You".  However, you can replace that with generics if
y'all wish.

The point is that the root of the problem is the failure of the
organizational decision maker to take responsibility for their decision.

As a business person (now retired) once told me about the things he
sells in his shop, "I will not sell that here because in my opinion it
is crap.  If you want that, you can go to the shop next door.  They will
be quite willing to sell that crap to you, but don't come complaining to
me when your failure to take my advice comes back to bite you in the
ass."

>Also: this not an isolated or unique experience.  It's this way pretty
>much everywhere in the US now.  And I can disapprove of it, you can
>disapprove of it, we can all disapprove of it, but like I said, until
>money is completely removed from the calculation, this is how it will
be.
>Critiques of process and role and organization and everything else are
>interesting, maybe even correct --  but will change nothing.

Yes, it is generally an USian problem.  While I cannot speak to its
prevelance in the US I can attest to the fact that USians try to bring
this philosophy with them were ever they go and that such thinking has
to be repelled with large bats.

I have had to deal with such things several times and my response is
quite simple:  My name will not be associated in any way with that
stupidity other than complete opposition to it.  If you want me to sign
off on it, then I will not.  And if you decide to do it anyway then do
not ask me to have anything to do with the mess that ensues because the
only action you will get from me is "told you so -- you made your bed
now go sleep in it".

Generally the encroachment of ill-conceived plans is staved off until
the resistant retire leaving the inmates in charge of the asylum.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Thursday, 19 March, 2020 10:07, Matt Hoppes 
 wrote:

>Agreed... 720 or 1080 Netflix will work just as fine as 4K for the next
>month or two.

As long as NetFlix lowers their prices proportionately with their reduced level 
of service.  For example, if NetFlix decides they will only provide 
"half-quality" service then they should only charge half price.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Friday, 20 March, 2020 07:52, Mike Hammett  wrote:

>Some of the pipes Netflix goes through is also used by other services
>that aren't as adaptable.

Can you explain why you think that is Netflix problem?

I should think that it is a problem being experienced by persons who 
deliberately chose to accept the risk that Internet congestion may be a problem 
for the path upon which they have deliberately chosen to embark.  That Risk 
might now come to fruition and those persons should be activating their 
pre-planned mitigation.  If their pre-planned mitigation was "well, Netflix can 
shut down", then they had (hopefully) defective mitigation planning.  Perhaps 
in the future they will do a better job of assessing Risk and mitigating that 
Risk.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Friday, 20 March, 2020 20:43, Mark Tinka  wrote:

>If we go down this path, who's to say which service provider will or
>won't be "targeted" next at the whim of some command & control policy
>maker? Is it a rabbit hole whose top-soil we want to uncover?

Perhaps the "advertizing" and "JavaScript" should be banned from websites 
first.  That would have more effect than fiddling with streaming media services.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Sunday traffic curiosity

[Keith Medcalf]

On Monday, 23 March, 2020 04:19, Alexandre Petrescu 
 wrote:

> ... like  'remote surgery' needs to transmit haptic feedback effect across 
> long distances.

Personally, if I were asked to give consent for surgery and it contained a risk 
"the communications uses the Internet for transport and the Internet is a 
best-effort only communications method" I would not consent.  And in this 
jurisdiction, it would be unlawful to fail to disclose that risk.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: South Africa On Lockdown - Coronavirus - Update!

[Keith Medcalf]

On Monday, 23 March, 2020 14:21, Peter Beckman  wrote:

>Software-based TOTP offer more security than no one-time passwords, but
>admittedly less than the physical tokens. Google Authenticator, Authy,
>1Password, LastPass all support TOTP.

Hardware tokens are nothing more than dedicated hardware TOTP devices with 
perhaps a few additional parameters programmed at manufacturing time.  Example, 
RSAID keyfobs are nothing more than TOTP generators with manufacturer 
programmed secrets and dedicated clock and display hardware with no external 
interface which permits access to the secret.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: South Africa On Lockdown - Coronavirus - Update!

[Keith Medcalf]

Both Fido and OAuth2 are inherently insecure.

While they may be better than nothing at all, they are only very slightly 
better than proper password selection and management.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of Eric Tykwinski
>Sent: Monday, 23 March, 2020 15:55
>To: Mark Tinka 
>Cc: nanog@nanog.org
>Subject: Re: South Africa On Lockdown - Coronavirus - Update!
>
>I think that’s the major sticky point, I would hope we could all agree on
>one thing, but that also leaves one entry point of failure.  Hopefully we
>can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run
>so everything can just use one simple authentication mechanism.
>
>
>Sincerely,
>
>Eric Tykwinski
>TrueNet, Inc.
>P: 610-429-8300
>
>
>   On Mar 23, 2020, at 5:23 PM, Mark Tinka <mailto:mark.ti...@seacom.mu> > wrote:
>
>
>
>   On 23/Mar/20 22:39, Keith Medcalf wrote:
>
>
>
>   Hardware tokens are nothing more than dedicated hardware TOTP
>devices with perhaps a few additional parameters programmed at
>manufacturing time.  Example, RSAID keyfobs are nothing more than TOTP
>generators with manufacturer programmed secrets and dedicated clock and
>display hardware with no external interface which permits access to the
>secret.
>
>
>
>   For some of my banks, OTP tokens are issued via their device apps. I
>   used to have physical key fobs for that; those are now gone.
>
>   Admittedly, not all of my banks have made the transition. On the
>other
>   hand, many of the banks have moved on to support Face ID and QR code
>   verification via device apps.
>
>   Not specific to VPN access management, but in the same vein.
>
>   Mark.
>
>

RE: free collaborative tools for low BW and losy connections

[Keith Medcalf]

On Monday, 30 March, 2020 11:19, Michael Thomas  wrote:

>On 3/30/20 5:52 AM, Rich Kulawiec wrote:
>> On Mon, Mar 30, 2020 at 06:30:16AM -0500, Joe Greco wrote:

>>> Actual text traffic has been slowly dying off for years as webforums
>>> have matured and become a better choice of technology for nontechnical
>>> end users on high speed Internet connections.

>> My view is that the move to web forums is a huge downgrade.  Mailing
>> lists are vastly superior.

>[]

>The thing that mailing lists lack is a central directory of their
>existence. The discovery problem is a pretty big one.

Where is this to be found for webforums?  I have never seen one.  Or do you 
think Google is such a master index?  Can you please pose your Google query 
that you think results in a comprehensive index of *all* webforums?

Or is your comment nothing more that you noticing that NEITHER e-mail lists NOR 
webforums have a master index, which is a rather useless observation that would 
indicate that webforums have zero advantage over mailing lists in this regard, 
so what is the point of the whataboutism?

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Huawei on Mount Everest

[Keith Medcalf]

Build a nuclear power plant of course.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of Eric Tykwinski
>Sent: Friday, 1 May, 2020 12:14
>To: Aaron Gould 
>Cc: John Levine ; nanog@nanog.org
>Subject: Re: Huawei on Mount Everest
>
>Honestly, being an amateur rock climber, I’m in the same boat, but how
>the hell are they going to get power up there for dependability.
>Solar power sure is a great option, but I was under the assumption that
>repairs will be hell to put it bluntly.
>Batteries in that cold of a climate is also a regular trip. which doesn’t
>seem feasible, unless there’s something I don’t know.
>
>
>Sincerely,
>
>Eric Tykwinski
>TrueNet, Inc.
>P: 610-429-8300
>
>
>   On May 1, 2020, at 2:07 PM, Aaron Gould  > wrote:
>
>   You made me curious...
>
>   https://en.wikipedia.org/wiki/List_of_people_who_died_climbing_Mount
>_Everest
>
>   wow, I guess it would be great to be able to use cell/gps technology
>to communicate with and track a lost/endangered climber
>
>
>   -Original Message-
>   From: NANOG [mailto:nanog-bounces+aaron1=gvtc@nanog.org] On
>Behalf Of John Levine
>   Sent: Friday, May 1, 2020 12:58 PM
>   To: nanog@nanog.org
>   Subject: Re: Huawei on Mount Everest
>
>   In article
> you
>write:
>
>
>   -=-=-=-=-=-
>
>   https://telecoms.com/504051/huawei-and-china-mobile-stick-a-
>5g-base-station-on-mount-everest/
>
>   Why dont we leave the Everest alone? OTOH, we can now have
>tiktok
>   videos and latest instagram posts from the summit.
>
>
>
>   Given how dangerous the ascent is, I would think it would be a good
>   thing for climbers to be able to check in and say whether they are
>OK.
>
>   I agree it's mostly a publicity stunt, though.
>
>
>
>

RE: Curious Cloudflare DNS behavior

[Keith Medcalf]

On Saturday, 30 May, 2020 13:18, Joe Greco  wrote:

>The Internet didn't evolve in the way its designers expected.  Early
>mistakes and errors required terrible remediation.  As an example, look
>at the difficulty involved in running a service like e-mail or DNS.
>E-mail requires all sorts of things to interoperate well, including
SPF,
>DKIM, SSL, DNSBL's, etc., etc., and it is a complicated service to run
>self-hosted.  DNS is only somewhat better, with the complexity of
DNSSEC
>and other recent developments making for more difficulties in
maintaining
>self-hosted services.

I've been running my own DNS and e-mail for more than a quarter century.
Contrary to your proposition it hasn't gotten much more complicated over
than time.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: understanding IPv6

[Keith Medcalf]

On Sunday, 7 June, 2020 21:49, William Herrin  wropte:

> ...
> Keepalive requirements are a property of whether or not you employ stateful 
> firewalls.
> ...

Keepalive's are not designed for stateful firewalls, they are designed to 
permit the endpoints to know whether the communication channel is still intact.

They may also be useful to "keepalive" connection table entries in stateful 
firewalls and NAT/NATP devices, however this is merely a side effect and not 
their purpose.

--
Both optimists and pessimists contribute to society.  The optimist invents the 
aeroplane, the pessimist the parachute.

RE: SRv6

[Keith Medcalf]

On Monday, 21 September, 2020 16:16, Randy Bush wrote:

>> I'm not sure what you're saying here, I never said MPLS VPNs are
>> secure, only private. I hope others recognise that they are
>> different concepts.

>yes, privacy is one aspect of security.  and, as mpls vns are not
>private sans encryption, they are not secure.

That is blatantly untrue.  I have an MPLS VPN running from my Living
Room to my Bathroom.  It is not encrypted.  It is protected with 3G
security (Guards, Guns, Gates).  You do not need "encryption" in order
to be "secure".

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

RE: S.Korea broadband firm sues Netflix after traffic surge

[Keith Medcalf]

On Sunday, 10 October, 2021 14:21, Mark Tinka wrote:

>They are looking at the aggregate Gbps or Tbps of traffic that
>BigContent is seeking to deliver across their network, for "no $$".

This is blatantly incorrect.  The bits were payed for by the requestor.

BigContent does not "send bits" to non-requestors.
The Internet is Point-to-Point, not a Broadcast medium.

If the seller (the network operator) cannot provide the service which they have 
sold, they should be imprisoned for the remainder of their natural lives at 
hard labour.  This sort of behaviour by the network operator is a Criminal 
Activity called FRAUD (based on Fraudulent Misrepresentation of Material Fact) 
and is, in fact, a Criminal Conspiracy.

--
You can tell a politician is lying because it's lips are moving.
The only good politician is a dead politician.

RE: FCC to Consider New Rules to Combat International Scam Robocalls

[Keith Medcalf]

>With AT&T and perhaps others, you can forward the message to 7726
>(spells SPAM on the keypad) and they'll reply asking for the originating
>phone number or email address.

This is, of course, the root of the problem.  The recipient of the spam does 
not know either the originating phone number or the originating e-mail address. 
 All they know is the Advertizing ID -- and that is useless for everything 
except what it was designed for -- advertizing.

If one knew the originating phone number then one would know who to hunt down 
and which throat to slit from ear to ear, and there would be no need to involve 
AT&T at all... This, and the fact that the Telco's get bloody rich from 
providing termination for all the crap they have enabled is exactly the reason 
they did it in the first place!

--
(CAUTION) You are advised that if you attack my person or property, you will be 
put down in accordance with the provisions of section 34 & 35 of the Criminal 
Code respectively.  If you are brandishing (or in possession) of a weapon then 
lethal force will be applied to your person in accordance with the law.  This 
means that your misadventures may end in your death.  Consider yourself 
cautioned and govern your actions appropriately.

ICANN

[Keith Medcalf]

Does anyone have contact information (or address for service of legal
documents) for ICANN?  There web site does not appear to contain contact
information.

ICANN apparently promulgates a policy which requires clickage on spam
links in e-mail.  I intend to sue them for trillions of dollars for this
policy.


--
(CAUTION) You are advised that if you attack my person or property, you
will be put down in accordance with the provisions of section 34 & 35 of
the Criminal Code respectively.  If you are brandishing (or in
possession) of a weapon then lethal force will be applied to your person
in accordance with the law.  This means that your misadventures may end
in your death.  Consider yourself cautioned and govern your actions
appropriately.

RE: ICANN

[Keith Medcalf]

On Friday, 8 July, 2022 19:02, Karl Auerbach  said:

>Spammers are a scourge and I hope you get that $trilliion.  But ICANN
>will fairly easily deflect most legal efforts based on a claim that
>ICANN bears responsibility.  Years ago I proposed a solution from King
>Croesus as described by Herodotus: to drag each ill doer over a bed of
>wool cards, but it seems to have fallen flat as perhaps too extreme for
>modern sensibilities. ;-)

Of course ICANN will be able to deflect the use of their name by the other 
co-defendant for the purposes of threatening to interfere with the economic 
benefit of a contract (even though the co-defendant is the one issuing the 
threat of economic interference).  I am not interested in ICANN, per se.  It 
is, however, within the realm of possibility that the non-ICANN co-defendant is 
correct in their assertion that the liable party is ICANN.  If ICANN is not the 
snivilling guilty party, then they will, of course, be found such by the court. 
 It would be perspicacious for them, however, to ensure that they "go after" 
the organization using their name is vain, as it were.  Since they have not 
done so, they will not be saved their costs.

--
(CAUTION) You are advised that if you attack my person or property, you will be 
put down in accordance with the provisions of section 34 & 35 of the Criminal 
Code respectively.  If you are brandishing (or in possession) of a weapon then 
lethal force will be applied to your person in accordance with the law.  This 
means that your misadventures may end in your death.  Consider yourself 
cautioned and govern your actions appropriately.

RE: Rogers Outage Canada

[Keith Medcalf]

>I can't either, but the reality right now seems to be that 911 calls are
>failing for anyone on a Rogers cellphone.

This is par for the course.  These people chose to deal with Rogers despite 
knowing the consequences.  It is like if you bought a Rogers Snowblower and it 
did not work.  That would mean that people who bought the Rogers Snowblower 
will not be using it to get rid of the snow that is preventing them from 
leaving their house.

Mutatis mutandis when Rogers is down things that are Rogers dependent will not 
work.

Some people are so retarded it is astonishing!

--
(CAUTION) You are advised that if you attack my person or property, you will be 
put down in accordance with the provisions of section 34 & 35 of the Criminal 
Code respectively.  If you are brandishing (or in possession) of a weapon then 
lethal force will be applied to your person in accordance with the law.  This 
means that your misadventures may end in your death.  Consider yourself 
cautioned and govern your actions appropriately.

>-Original Message-
>From: NANOG  On Behalf Of
>Eric Kuhnke
>Sent: Friday, 8 July, 2022 13:34
>To: jim deleskie 
>Cc: NANOG list 
>Subject: Re: Rogers Outage Canada
>
>
>I have seen anecdotal reports that the mobile network is in a half broken
>state that phones remain registered to, so a 911 call will attempt and
>then fail.
>
>
>This is unlike what would happen if you had a US/Canada cellphone with
>battery power but no SIM card in it that would search for any available
>network in RF range for a 911 call if needed.
>
>
>On Fri, 8 Jul 2022 at 12:31, jim deleskie  > wrote:
>
>
>   i cant see BGP taking out SS7.
>
>   -jim
>
>   On Fri, Jul 8, 2022 at 2:45 PM Snowmobile2004
>mailto:greenjosh6...@gmail.com> > wrote:
>
>
>   According to Cloudflare Radar
> , Rogers
>BGP announcements spiked massively to levels 536,777% higher than normal
>(343,601 vs 64 normally) just minutes before the outage. I would not be
>surprised if this happened to be the culprit.
>
>   Regards,
>   Josh Green
>
>   On Fri, Jul 8, 2022 at 2:19 PM Andrew Paolucci via NANOG
>mailto:nanog@nanog.org> > wrote:
>
>
>   In the early hours of the morning around 2-3am my modem
>got hit with a configuration update that caused a DHCP release that
>wasn't renewed for about two hours, after rollback the connection was
>fine for 3 hours before this network wide outage.
>
>
>   Maybe a failed night time update was attempted again
>during office hours, I've heard daytime guys are still WFH and night
>shift is in building.
>
>
>   I expect we'll never get a real explanation. Rogers is
>notorious for withholding any type of helpful or technical information.
>
>
>   Sent from my inoperable Rogers Mobile via emergency 
> eSIM.
>
>
>   Regards,
>
>   Andrew Paolucci
>    Original Message 
>   On Jul. 8, 2022, 1:48 p.m., Jay Hennigan < j...@west.net
> > wrote:
>
>
>   On 7/8/22 07:44, Robert DeVita wrote: > Does 
> anyone
>have information on a widespread Rogers outage in Canada. I > have
>customers with multiple sites down. There's discussion on the Outages
>mailing list. Seems widespread, affecting all services, mobile, voice,
>Internet. No cause or ETR posted yet. -- Jay Hennigan - j...@west.net
>  Network Engineering - CCIE #7880 503 897-8550 -
>WB6RDV
>
>
>
>   --
>
>   Josh Green.

RE: Banned by Akamai (or some websites hosted with Akamai)

[Keith Medcalf]

>https://www.akamai.com/us/en/clientrep-lookup/?language=en_US

Well, isn't that just jammed up with malicious third-party javascript ...

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Frontier rural FIOS & IPv6

[Keith Medcalf]

It is not possible for web pages to load faster over IPv6 than over IPv4.  All 
other factors being equal, IPv6 has higher overhead than IPv4 for the same 
payload throughput.  This means that it is physically impossible for IPv6 to be 
move payload bytes "faster" than IPv4 can move the same payload.

In other words, IPv6 has a higher "packet tax" than IPv4.  Since you have no 
choice but to pay the "packet tax" the actual payload data flows more slowly.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ca By
>Sent: Sunday, 31 March, 2019 18:53
>To: Matt Hoppes
>Cc: Aaron C. de Bruyn; NANOG mailing list
>Subject: Re: Frontier rural FIOS & IPv6
>
>
>
>On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes
> wrote:
>
>
>   Going to play devils advocate.
>
>   If frontier has a ton of ipv4 addresses, what benefit is there
>to them in rolling out ipv6?
>
>   What benefit is there to you?
>
>
>I love xbox and xbox works better on ipv6,
>
>https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47
>.pdf
>
>Also, webpages load faster , and i love fast web pages
>
>https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on-
>board/
>
>
>https://www.akamai.com/fr/fr/multimedia/documents/technical-
>publication/a-case-for-faster-mobile-web-in-cellular-ipv6-
>networks.pdf
>
>
>
>
>   On Mar 31, 2019, at 7:11 PM, C. A. Fillekes
> wrote:
>
>
>
>
>   Still it's pretty darn good having real broadband on the
>farm.  One thing at a time.
>
>
>   But, let's start thinking about ways to get Frontier up to
>speed on the IPv6 thing.
>
>
>
>   On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn
> wrote:
>
>
>   You're not alone.
>
>   I talked with my local provider about 4 years ago and
>they said "We will probably start looking into IPv6 next year".
>   I talked with them last month and they said "Yeah,
>everyone seems to be offering it.  I guess I'll have to start reading
>how to implement it".
>
>   I'm sure 2045 will finally be the year of IPv6
>everywhere.
>
>   -A
>
>   On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes
> wrote:
>
>
>
>   So by COB yesterday we now officially have FIOS
>at our farm.
>
>
>   Went from 3Mbps to around 30 measured average.
>Yay.
>
>
>   It's a business account, Frontier.  But...still
>no IPv6.
>
>
>   The new router's capable of it.  What's the hold
>up?
>
>
>   Customer service's response is "We don't offer
>that".
>
>
>
>
>

RE: Facebook (account)

[Keith Medcalf]

It would depend on whether FB is being paid to provide a service or not.  
However, if "your friend" is not paying FB to provide a service to them then 
there is really nought that you can do about it.  Otherwise, the course of 
action to be taken will be specified in the contract which was signed by both 
parties ... and at the very least payment for services which are not being 
provided should be terminated immediately.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Nathan
>Anderson
>Sent: Tuesday, 9 April, 2019 20:05
>To: 'nanog@nanog.org'
>Subject: Facebook (account)
>
>Fellow NetOps,
>
>I realize this is an unorthodox / off-topic request, but I've been
>trying to help a friend out and don't know how to advise her next.
>
>If there is someone from FB here who has connections to someone in
>account security and is willing to contact me off-list, I'd really
>appreciate it.  A friend had her FB account of many years hijacked
>and then held for ransom by a random dude.  When she asked FB to
>intercede, she appeared to have her account back for a short time (<
>24 hrs) before FB themselves blocked the account, and that's where we
>are now.  It's been over 2 weeks and she has been going round and
>round with "CS" and getting nowhere...whoever these robots are keep
>repeating requests for her to send in ID, which she does, and then
>they repeat the request again and it just goes in a circle.  I have a
>feeling that I know what's going on behind-the-scenes, but we can't
>seem to get a living, breathing human over there who isn't just
>reading a script to actually listen to her.  Seriously, what is the
>average person supposed to do under these circumstances?
>
>If this was just the story of a lone FB account I'm not sure I would
>bother and I'd just tell her to get a new one.  But she runs a
>business (popular local coffee shop) with a FB page that this account
>of hers was apparently the only admin for.
>
>Thanks in advance for any leads,
>
>--
>Nathan Anderson
>First Step Internet, LLC
>nath...@fsr.com

RE: Incoming SSDP UDP 1900 filtering

[Keith Medcalf]

On Thursday, 11 April, 2019 08:08, Patrick McEvilly 
 wrote:

>I'm working with Level3 on a similar problem.  They filter both UDP
>and TCP port 1900 on our peer to them.  This is blocking all
>connections that randomly use ephemeral tcp port 1900.

>They are refusing to remove the tcp port 1900 filter without
>dispensation from the DDoS security gods. I understand blocking UDP
>1900, what is the purpose of Level3 filtering tcp port 1900?

They are both port 1900 (that is, they have a 1900 in them -- they also 
probably block TCP/UDP 19000 bidirectionally as well, since that has a "1900" 
in it -- they likely also tried to block TCP/UDP 19 as well, but for some 
reason even through that also has "1900" in it the firewall would not accept it 
as a 16-bit port number, so they submitted a bug report to the vendor and 
closed the ticket).

In short, never ascribe to malice that which can be oh so easily and correctly 
attributed to ignorance, stupidity (incurable ignorance) and incompetence.

Besides, the "Internet" package that you purchased did not include that 
channel.  If you wish to receive channels 1900 and 19000 they are available as 
an add-on feature pack.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: NTP question

[Keith Medcalf]

On Wednesday, 1 May, 2019 15:36, Harlan Stenn  wrote:

>So I gotta ask, just as a reality check:

>- Why do folks want to have one or more NTP server masters that have
>at least 1 refclock on them in a data center, instead of having their
>data center NTP server masters that only get time over the internet?

That entirely depends on what you need the time for.

For example, in a Continuous Control environment you really do not care about 
the accuracy of the time -- just like a printer will not suddenly fail to print 
documents with dates in them because of Y2K, the printer neither cares nor 
knows what time it is.

What you may care about, however, is that all your Distributed Control and 
Outboard Systems have the SAME TIME and that that time, relative to each other, 
is closely synchronized.  This has a huge impact when comparing log events from 
one system to another.  What is important is that they all have the same time, 
and that they all drift together.

If you have one such installation, then you really do not care about the 
"accuracy" of the time.  However if you have multiple such installations then 
you want them all to have the same time (if you will be comparing logs between 
them, for example).  At some point it becomes "cheaper" to spend thousands of 
dollars per site to have a single Stratum 0 timesource (for example, the GPS 
system) at each site (and thus comparable time stamps) than it is to pay 
someone to go though the rigamarole of computing offsets and slew rates between 
sites to be able to do accurate comparison.  And if you communicate any of that 
info to outsiders then being able to say "my log timestamps are accurate to +/- 
10 nanoseconds so it must be you who is farked up" (and be able to prove it) 
has immense value.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: NTP question

[Keith Medcalf]

>If your network is air gapped from the Internet then sure. If it's
>not, you can run NTP against a reasonably reliable set of time
>sources (not random picks from Pool) and be able to say, "my log
>timestamps are accurate to +/- 10 milliseconds so it must be you who
>is farked up." While my milliseconds loses the pecking order contest,
>it's just as good for practical purposes and a whole lot less
>expensive.

You mean something like this, which is relatively easy to achieve:

==
offset -0.09, frequency -0.823, time_const 30, watchdog 238
synchronised to NTP server (192.5.41.40) at stratum 2
   time correct to within 12 ms
   polling server every 1024 s
==
 remote   refid  st t when poll reach   delay   offset  jitter
==
+clock.sjc.he.ne .CDMA.   1 u  287 1024  377   64.3130.337   0.867
-tock.usnogps.na .IRIG.   1 u5 1024  377  103.080   -2.097   0.316
-tick.usnogps.na .IRIG.   1 u  806 1024  377  103.053   -2.328   0.363
+india.colorado. .NIST.   1 u  270 1024  377   41.214   -0.159   0.113
+time-b-b.nist.g .NIST.   1 u  984 1024  377   42.6090.200   0.045
+time-c-b.nist.g .NIST.   1 u  180 1024  377   42.5630.201   0.064
+time-a-b.nist.g .NIST.   1 u  163 1024  377   42.6390.137   0.032
*192.5.41.40 .PTP.1 u  235 1024  377   12.756   -0.388  12.479
-192.5.41.41 .IRIG.   1 u  312 1024  377   13.575   -1.172   2.425
 LOCAL(0).LOCL.  10 l-   6400.0000.000   0.000
--
pll offset:   -8.474e-06 s
pll frequency:-0.823 ppm
maximum error:0.123149 s
estimated error:  0.000122 s
status:   2001  pll nano
pll time constant:10
precision:1e-09 s
frequency tolerance:  500 ppm
==

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Widespread Firefox issues

[Keith Medcalf]

Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing 
whatsoever happened to my Firefox browser, and all the extensions are still 
working just fine.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle
>Bruns
>Sent: Friday, 3 May, 2019 19:56
>To: NANOG list
>Subject: Widespread Firefox issues
>
>Just an FYI since this is bound to impact users:
>
>https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>
>Basically, Mozilla forgot to renew an intermediate cert, and people's
>Firefox browsers have mass-disabled addons.
>
>Whoops.
>--
>Brielle Bruns
>The Summit Open Source Development Group
>http://www.sosdg.org/ http://www.ahbl.org

RE: Widespread Firefox issues

[Keith Medcalf]

Besides which, if something was signed AT THE TIME when the certificate chain 
was valid, then that signature will be a valid signature forever (unless one of 
the certificates in the chain is revoked).  The future or current expiry of a 
certificate or an intermediary has no effect whatsoever on the validity of a 
signature IF THE CERTIFICATE CHAIN WAS VALID at the time the signature was 
made, and the chain can be verified TO HAVE BEEN VALID at the time the 
signature was made.

In other words, the fact that subsequent to making a signature the pen ran out 
of ink does not make the signature invalid.  If it did so then there would be 
no point in having signatures.  It may be impossible to make a valid signature 
with a pen that is out of ink, but that does not invalidate signatures made 
before the ink ran out.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG [mailto:nanog-bounces+kmedcalf=dessus@nanog.org] On
>Behalf Of Keith Medcalf
>Sent: Friday, 3 May, 2019 20:48
>To: NANOG list
>Subject: RE: Widespread Firefox issues
>
>
>Clearly false, since it is 2019-05-04 02:46:31.342994 now and nothing
>whatsoever happened to my Firefox browser, and all the extensions are
>still working just fine.
>
>---
>The fact that there's a Highway to Hell but only a Stairway to Heaven
>says a lot about anticipated traffic volume.
>
>
>>-Original Message-
>>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle
>>Bruns
>>Sent: Friday, 3 May, 2019 19:56
>>To: NANOG list
>>Subject: Widespread Firefox issues
>>
>>Just an FYI since this is bound to impact users:
>>
>>https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>>
>>Basically, Mozilla forgot to renew an intermediate cert, and
>people's
>>Firefox browsers have mass-disabled addons.
>>
>>Whoops.
>>--
>>Brielle Bruns
>>The Summit Open Source Development Group
>>http://www.sosdg.org/ http://www.ahbl.org
>
>

RE: Widespread Firefox issues

[Keith Medcalf]

HTTPS: has nothing to do with the website being "secure".  https: means that 
transport layer security (encryption) is in effect.  https: is a PRIVACY 
measure, not a SECURITY measure.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Constantine
>A. Murenin
>Sent: Friday, 3 May, 2019 21:02
>To: Brielle Bruns
>Cc: NANOG list
>Subject: Re: Widespread Firefox issues
>
>On Fri, 3 May 2019 at 20:57, Brielle Bruns  wrote:
>
>
>   Just an FYI since this is bound to impact users:
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>
>   Basically, Mozilla forgot to renew an intermediate cert, and
>people's
>   Firefox browsers have mass-disabled addons.
>
>   Whoops.
>
>
>
>This is why it's important that every single website on the internet
>is available ONLY over HTTPS.  Don't forget to install an HSTS
>policy, too, so, if anyone ever visits Kazakhstan or a security-
>conscious corporate office, they'll be prevented from accessing the
>cute pictures of cats on your fully static website.  Of course, don't
>forget to abandon HTTP, too, and simply issue 301 Moved Permanently
>redirects from all HTTP targets to HTTPS, to cover all the bases.
>
>Backwards compatibility?  Don't you worry — no browser lets anyone
>remove HSTS, once installed, so, you're golden.  And HTTPS links
>won't fallback to HTTP, either, so, you're good there, too — your
>cute cats are safe and secure, and once folks link to your new site
>under https://, your future self will be safe and secure from ever
>having the option to go insecure again.  I mean, why would anyone go
>"insecure"?  Especially now with LetsEncrypt?
>
>
>Oh, wait…
>
>
>Wait a moment, and who's the biggest player behind the HTTPS-only
>movement?  Oh, and Mozilla's one of the biggest backers of
>LetsEncrypt, too?  I see…  Well, nothing to see here, move along!
>#TooBigToFail.
>
>
>C.

RE: Widespread Firefox issues

[Keith Medcalf]

I will stick to the "clearly false" since it is now well to the point where we 
are in 2019-05-04 (even in local UT1, let alone UTC), studies are disabled (and 
have been since forever), no studies have been loaded, and my extensions still 
work quite fine, thank-you.  Attempting to install a "new" extension fails with 
a "bad signature" error.

Is the "permanent fix" going to be proper validation of signatures I wonder?
Or will they still consider the signature (made while there was ink in the pen) 
to be invalid after the pen runs out of ink?

Or, more accurately, not invalidate the handwritten signature after the death 
of the witness.  Lordy forbid that the "real world" worked like that ... 
invalidating the signature on a contract merely because the witness or signer 
got killed by a rogue bus ... What a lovely way to render a contract nul ab 
initio -- just kill one of the witnesses ...

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle
>Bruns
>Sent: Saturday, 4 May, 2019 08:30
>To: nanog@nanog.org
>Subject: Re: Widespread Firefox issues
>
>So, for being "Clearly false",  the hotfix pushed out by the Firefox
>Studies feature is...
>
>*drumroll*
>
>An updated intermediate certificate!
>
>
>You can turn on the Studies option under Privacy & Security for a
>little
>while, then check about:studies and you should see one or two in
>there
>regarding the xpi verification/signing.  Once you have those two
>studies, you can disable Studies again.
>
>Likely we'll see a full fix with a point release of Firefox in a day
>or so.
>
>
>
>On 5/3/2019 8:48 PM, Keith Medcalf wrote:
>>
>> Clearly false, since it is 2019-05-04 02:46:31.342994 now and
>nothing whatsoever happened to my Firefox browser, and all the
>extensions are still working just fine.
>>
>> ---
>> The fact that there's a Highway to Hell but only a Stairway to
>Heaven says a lot about anticipated traffic volume.
>>
>>
>>> -Original Message-
>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle
>>> Bruns
>>> Sent: Friday, 3 May, 2019 19:56
>>> To: NANOG list
>>> Subject: Widespread Firefox issues
>>>
>>> Just an FYI since this is bound to impact users:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
>>>
>>> Basically, Mozilla forgot to renew an intermediate cert, and
>people's
>>> Firefox browsers have mass-disabled addons.
>>>
>>> Whoops.
>>> --
>>> Brielle Bruns
>>> The Summit Open Source Development Group
>>> http://www.sosdg.org/ http://www.ahbl.org
>>
>>
>>
>
>
>--
>Brielle Bruns
>The Summit Open Source Development Group
>http://www.sosdg.org/ http://www.ahbl.org

RE: Widespread Firefox issues

[Keith Medcalf]

Aha!  Did the same and it worked.  I had disabled Normandy probably immediately 
when it was introduced.  I guess if you have it disabled then studies (even if 
enabled) are disabled as well.

After getting the studies I disabled studies again (since I don't want them) 
and disabled normandy (since I do not want external third parties frikking 
about with my settings just cuz they feel like it) -- if you want to fiddle 
with the settings on my equipment you have to physically be within the blast 
radius of the device you are fiddling with (or the automated Nitrogen oxygen 
purge system).

We will see what happens mid-afternoon tomorrow when Firefox tries to run a 
signature check again (since the original problem report was in error -- the 
check is only run once every 86400 seconds, so at the next check after the 
intermediate certificate expires the add-ons will be disabled).

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Royce
>Williams
>Sent: Saturday, 4 May, 2019 15:44
>To: nanog@nanog.org
>Subject: Re: Widespread Firefox issues
>
>
>On Sat, May 4, 2019 at 8:02 AM Royce Williams
> wrote:
>
>
>   On Sat, May 4, 2019 at 7:40 AM Royce Williams
> wrote:
>
>
>   On Sat, May 4, 2019 at 7:32 AM Keith Medcalf
> wrote:
>
>
>
>   I will stick to the "clearly false" since it is now
>well to the point where we are in 2019-05-04 (even in local UT1, let
>alone UTC), studies are disabled (and have been since forever), no
>studies have been loaded, and my extensions still work quite fine,
>thank-you.  Attempting to install a "new" extension fails with a "bad
>signature" error.
>
>
>
>   Here's something interesting - a few times now, I've told
>Firefox to enable Studies and then restarted ... but the Studies
>setting reverted to being unchecked.
>
>   Maybe one of my other paranoia-enabling extensions is
>toggling it off ... but if so, I haven't found it yet. Still
>investigating.
>
>
>   Even stranger, I can manually toggle
>'app.shield.optoutstudies.enabled' in about:config ... and *that*
>persists across reboots ... but Studies *still* aren't enabled (the
>about:preferences item is still unchecked, and the "about:studies"
>area still indicates that they're disabled).
>
>   There's definitely something weird about enabling/disabling
>studies.
>
>   FWIW, this is 64-bit 66.0.3 on Ubuntu, and it's an instance of
>Firefox that had studies disabled before this issue emerged. On a
>very similar setup, but one with a vanilla Firefox install that
>already had Studies enabled, I can't recreate this symptom - even if
>I turn Studies off (either using the GUI or with the about:config
>item).
>
>
>Multiple people have replied offthread that they have the same
>symptom.
>
>This workaround worked for me:
>
>https://www.reddit.com/r/firefox/comments/bkk5ss/if_you_dont_want_to_
>wait_do_this/
>
>
>Royce

RE: Traffic ratio of an ISP

[Keith Medcalf]

Having an inbound:outbound ration of 10:1 is known as a leech ...

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Prasun Dey
>Sent: Wednesday, 19 June, 2019 14:58
>To: Aaron Gould
>Cc: nanog@nanog.org
>Subject: Re: Traffic ratio of an ISP
>
>Thank you Aaron,
>This is great. This gives an interesting insight regarding CDN as
>they seem to play a big role here. However, in general, what do you
>call your ISP as? A 'Heavy Inbound' or 'Mostly Inbound'? Is there any
>community standard about this ratio (having 1:10 or higher) to be
>treated as Heavy Inbound? Or this is just a rough estimation?
>
>Thank you.
>-
>Prasun
>
>Regards,
>Prasun Kanti Dey
>Ph.D. Candidate,
>Dept of Electrical and Computer Engineering,
>University of Central Florida
>web: https://prasunkantidey.github.io/portfolio/
>
>
>
>
>
>
>
>   On Jun 19, 2019, at 2:18 PM, Aaron Gould 
>wrote:
>
>   I run an eyeballs/isp network for about ~50,000 subscribers, and
>I see about 1:10 ratio at peak time.  Last night ~4.5 gbps out, ~45
>gbps in.  But, I do have local caching of 4 big name cdn cache
>providers, so that might alter the 1:10 ratio I see on my actual inet
>links (which do not include the local cdn traffic)
>
>   …take Netflix for instance… I see on my local nfx cdn links,
>1:100 ratio of in:out.  20 gbps inbound and .2 gbps outbound  (during
>that same timeframe as aforementioned actual inet links)
>
>   Numbers based on 21:00 CDT last night.
>
>
>   -Aaron
>

RE: Traffic ratio of an ISP

[Keith Medcalf]

Why would you think that "Heavy Inbound" signifies a greater inbound:oubound 
ratio compared to "Mostly Inbound"?

To me "Heavy Inbound" means that there is more inbound than outbound and 
"Mostly Inbound" means exactly that -- mostly/usually/exclusively inbound with 
the occasional outbound byte or two.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Prasun Dey
>Sent: Wednesday, 19 June, 2019 15:33
>To: Mike Hammett
>Cc: nanog@nanog.org
>Subject: Re: Traffic ratio of an ISP
>
>Thank you, Mike.
>From an outsider, I don’t have any information of an ISP’s traffic
>numbers. And this may be confidential unless we are using any
>measurement platform, which CAIDA is doing. To get a rough idea about
>any ISP’s traffic outbound:inbound ratio I can only see it's
>PeeringDB label. But, the question is whether there is any community
>decided values against these labels?
>Like,
>1:2 = Balanced
>1:5 = Mostly Inbound
>1:10 = Heavy Inbound
>10:1 = Heavy Outbound
>I just came up with these values. They don’t mean anything. I don’t
>have any solid evidence or source to support them. So, my question
>is, what people actually use? Or, it totally depends on the ISPs and
>they vary.
>
>-
>Prasun
>
>Regards,
>Prasun Kanti Dey
>Ph.D. Candidate,
>Dept of Electrical and Computer Engineering,
>University of Central Florida
>web: https://prasunkantidey.github.io/portfolio/
>
>
>
>
>
>
>
>   On Jun 19, 2019, at 5:18 PM, Mike Hammett 
>wrote:
>
>   Yes, you seem to misunderstand (at least of what I understand).
>PeeringDB has categories of ratios to choose from. What has the
>community decided is acceptable ratios for each category? It's fairly
>trivial for any network to determine what their ratio is as a number,
>but not necessarily as a PeeringDB label.
>
>
>
>
>   -
>   Mike Hammett
>   Intelligent Computing Solutions 
>
>
>
>
>   Midwest Internet Exchange 
>
>
>
>   The Brothers WISP 
>
>
>
>
>
>   From: "Josh Luthman" 
>   To: "Prasun Dey" 
>   Cc: nanog@nanog.org
>   Sent: Wednesday, June 19, 2019 3:23:33 PM
>   Subject: Re: Traffic ratio of an ISP
>
>
>   >my question was more like to understand when an ISP decides to
>claim itself as any of these (Heavy Outbound/ Inbound or Balanced)
>
>   Maybe I'm missing something but it's as simple as looking at the
>interface graphs.  We see a whole lot of green for inbound and a
>little little blue line for outbound.  We are an ISP with residential
>and commercial customers.
>
>
>   Josh Luthman
>   Office: 937-552-2340
>   Direct: 937-552-2343
>   1100 Wayne St
>   Suite 1337
>   Troy, OH 45373
>
>
>   On Wed, Jun 19, 2019 at 4:20 PM Prasun Dey
> wrote:
>
>
>   Hi Martijn and Josh,
>   Thank you for your detailed explanation. Let me explain my
>requirement so that you may help me better.
>   According to PeeringDB, Charter (Access), Sprint
>(Transit), Amazon (Content) all three of them are ‘Balanced’. While,
>Cable One, an Access ISP says it is Heavy Inbound, while Akamai,
>Netflix (Content) are Heavy Outbound. On the other hand, Cox, another
>access ISP, it says that it is Mostly Inbound.
>   So, my question was more like to understand when an ISP
>decides to claim itself as any of these (Heavy Outbound/ Inbound or
>Balanced)? From an ISP’s own point of view, at what point, it says,
>my outbound:inbound is something, so I’m Heavy Outbound.
>   Please ignore my lack of knowledge in this area. I’m sorry
>I should’ve done a better job in formulating my question earlier.
>   Thank you.
>
>
>   -
>   Prasun
>
>   Regards,
>   Prasun Kanti Dey
>   Ph.D. Candidate,
>   Dept of Electrical and Computer Engineering,
>   University of Central Florida
>   web: https://prasunkantidey.github.io/portfolio/
>
>
>
>
>
>
>
>   On Jun 19, 2019, at 2:13 PM, i3D.net
>  - Martijn Schmidt  wrote:
>
>   It kinda depends on the application that's being
>used. For example, videogaming has a ratio somewhere around 1:2.5
>since you're only transmitting metadata about the players environment
>across the

RE: Russian Anal Probing + Malware

[Keith Medcalf]

On Friday, 21 June, 2019 18:14, Ronald F. Guilmette  
wrote:

>https://twitter.com/GreyNoiseIO/status/1129017971135995904
>https://twitter.com/JayTHL/status/1128718224965685248

Sorry, don't twitter ...  Too much malicious JavaScript there.

>Friday Questionaire:

>Is there anybody on this list who keeps firewall logs and who
>DOESN'T have numerous hits recorded therein from one or more
>of the following IP addresses?

>80.82.64.21 scanner29.openportstats.com
>80.82.70.2 scanner8.openportstats.com
>80.82.70.198 scanner21.openportstats.com
>80.82.70.216 scanner13.openportstats.com
>80.82.78.104 scanner151.openportstats.com
>89.248.160.132 scanner15.openportstats.com
>89.248.162.168 scanner5.openportstats.com
>89.248.168.62 scanner1.openportstats.com
>89.248.168.63 scanner2.openportstats.com
>89.248.168.73 scanner3.openportstats.com
>89.248.168.74 scanner4.openportstats.com
>89.248.168.170 scanner17.openportstats.com
>89.248.168.196 scanner16.openportstats.com
>89.248.171.38 scanner7.openportstats.com
>89.248.171.57 scanner20.openportstats.com
>89.248.172.18 scanner25.openportstats.com
>89.248.172.23 scanner27.openportstats.com
>93.174.91.31 scanner10.openportstats.com
>93.174.91.34 scanner11.openportstats.com
>93.174.91.35 scanner12.openportstats.com
>93.174.93.98 scanner18.openportstats.com
>93.174.93.149 scanner6.openportstats.com
>93.174.93.241 scanner14.openportstats.com
>93.174.95.37 scanner19.openportstats.com
>93.174.95.42 scanner8.openportstats.com
>94.102.51.31 scanner31.openportstats.com
>94.102.51.98 scanner55.openportstats.com
>94.102.52.245 scanner9.openportstats.com

I have just a few.  They have all been blocked.  There have been no incoming 
sessions established, nor any outbound sessions to these addresses.

Why do you think it is a problem and not just run-of-the-mill background 
radiation on the Internet?

Do you (or your endpoints) not have a firewall to block such things?

sqlite> select * from hosts where name like '%openports%';
id  addressname  description  asn   
  lastupdate
--  -    ---  
--  --
366293.174.93.241  scanner14.openportstats.com.   202425
  1561209704
506193.174.95.42   scanner8.openportstats.com.202425
  1560718494
11894   93.174.93.149  scanner6.openportstats.com.202425
  1560732443
17720   93.174.93.98   scanner18.openportstats.com.   202425
  1560640554
54208   80.82.70.2 scanner8.openportstats.com.202425
  1560774033
54790   89.248.160.13  scanner15.openportstats.com.   202425
  1560682732
55081   89.248.168.19  scanner16.openportstats.com.   202425
  1561158220
55629   89.248.168.17  scanner17.openportstats.com.   202425
  1560817976
59858   89.248.171.57  scanner20.openportstats.com.   202425
  1560800216
64626   89.248.171.38  scanner7.openportstats.com.202425
  1560841829
70081   93.174.95.37   scanner19.openportstats.com.   202425
  1560802023
72978   80.82.70.216   scanner13.openportstats.com.   202425
  1560709312
74711   94.102.52.245  scanner9.openportstats.com.202425
  1560589038
80358   89.248.162.16  scanner5.openportstats.com.202425
  1561217966
86148   89.248.172.18  scanner25.openportstats.com.   202425
  1560884061
89484   94.102.51.31   scanner31.openportstats.com.   202425
  1561199715
90131   80.82.70.198   scanner21.openportstats.com.   202425
  1560776777
90531   80.82.78.104   scanner151.openportstats.com   202425
  1561150052
91641   80.82.64.21scanner29.openportstats.com.   202425
  1561184548
104810  94.102.51.98   scanner55.openportstats.com.   202425
  1561138118

sqlite> select * from asns where asn=202425;
asn country rir allocated   description  lastupdate
--  --  --  --  ---  --
202425  SC  ripencc 2018-05-17  INT-NETWORK, SC  1561217966

sqlite> select srcaddress, count(*), min(localtime), max(localtime) from 
firewalllog where srcaddress in (select address from hosts where name like 
'%openportstats.com.') group by srcaddress;
srcaddress   count(*)min(localtime)  max(localtime)
---  --  --  
--
80.82.64.21  6   2019-03-28 05:21:13.919 -06:00  2019-03-31 
06:47:28.309 -06:00
80.82.70.2   208 2019-01-23 12:58:02.557 -07:00  2019-04-02 
06:37:43.125 -06:00
80.82.70.19  114 2019-03-25 14:13:17.058 -06:00  2019-04-02 
06:39:57.214 -06:00
80.82.70.21  17970   2019-02-25 13:34

RE: QoS for Office365

[Keith Medcalf]

Using Orifice 342 will hurt you.

Packet loss (the more the better) will only help you.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Tinka
>Sent: Monday, 8 July, 2019 15:50
>To: Robert Webb
>Cc: NANOG list
>Subject: Re: QoS for Office365
>
>
>
>On 8/Jul/19 21:03, Robert Webb wrote:
>> I took the OP's request as for doing QoS at the edge of their
>network
>> and not necessarily the entire path.
>
>Indeed, but even then, you could be handing off the traffic to a
>downstream customer, and can't guarantee what they do to those ToS
>fields.
>
>
>>
>> As another person stated, the real answer is to add more bandwidth
>if
>> you are having to QoS to Office365 because it is affecting other
>> internet based services.
>
>Yes and no.
>
>More bandwidth never hurt anyone, but packet loss in the remote
>network
>toward the cloud will hurt you.
>
>Mark.

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

On Monday, 8 July, 2019 18:08, Michael Thomas  wrote:

>when we did DKIM back in the day, almost nobody was requiring SMTP
>auth which meant the providers could say "blame me" via the DKIM
>signature, >but couldn't really take much action since they didn't
>know who has doing it.

This is because DKIM was a solution to a problem that did not exist.  You 
always know the identity of the MTA sending you a message, there never was a 
need for DKIM.  It was a solution to a problem that does not and did not nor 
will ever exist.

>we sort of took a leap of faith that that would happen.
>nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i
>have no idea whether DKIM was in any way a motivating factor, but it
>did happen in the meantime.

This happened long long long before DKIM was even a wet spot on the sheets.

>i know the parallels here are not exact (is it really PRI's that are
>the source of most of the spam?) , but it's maybe a little premature to
>completely write off the providers for doing the Right Thing. putting
>the "blame me" badge on might give them some incentive to clean up
>their act. as with email spam, there is no silver bullet of course.

The solution is to disallow spoofing.  If the "pretty overlay information" does 
not equal the "billing information" then do not permit the call to be made.  
Easy Peasy.  However, this will interfere with the carriers ability to make 
money since the ability to make money depends on being in cahoots with the 
fraudsters.  Making it such that the Directors and Officers those carriers in 
cahoots suffer the death penalty (or life imprisonment) will solve the problem 
in an afternoon, but it will not happen because the cahooteers' (those 
Directors and Officers) own the slimy politicians needed to implement the cure.

>fwiw, the stir/shaken problem statement is a good read.

>https://datatracker.ietf.org/doc/rfc7340/

Not a bad work of complete fiction!

Of course, the "root cause" can be found at the very beginning of the thing 
where it is pointed out that there are reasons for providing false data, and 
that since "the other guy" allows the presentation of false data, we should too 
otherwise we will go out of business.  Once this "root cause" is accepted, then 
the inevitable ensues ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

Wow!

You must not know much about networking or programming if you do not know how 
to ask the OS to tell you the address/port associated with the "other end" of a 
TCP connection.  Obviously you know who is sending the message since they are 
in bidirectional communication with you at the time you are receiving the 
message, and you need to know where to send the "carry on James" prompts to get 
them to send more data...

Therefore you always know who submitted a message.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Michael Thomas [mailto:m...@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 18:58
>To: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>
>On 7/8/19 5:54 PM, Keith Medcalf wrote:
>> On Monday, 8 July, 2019 18:08, Michael Thomas 
>wrote:
>>
>>> when we did DKIM back in the day, almost nobody was requiring SMTP
>>> auth which meant the providers could say "blame me" via the DKIM
>>> signature, >but couldn't really take much action since they didn't
>>> know who has doing it.
>> This is because DKIM was a solution to a problem that did not
>exist.  You always know the identity of the MTA sending you a
>message, there never was a need for DKIM.  It was a solution to a
>problem that does not and did not nor will ever exist.
>>
>>
>::eyeroll:: pray tell, how do you "always" know the identity of the
>MTA
>sending you a message?
>
>
>Mike

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

You are the only person who has mentioned reverse DNS lookups.

However, it is true that you do in fact need to already know the identity of 
the sending MTA/MSA before you can do a "reverse DNS lookup".  What does this 
have to do with the price of tea in China?

And what value do you think a reverse DNS lookup adds to the identity 
information you already (obviously) have?

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Michael Thomas [mailto:m...@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 19:12
>To: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>Jon Callas, Eric Allman, the IETF security geek contingent and even
>me
>disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with
>you. Trillions of signed messages disagree with you. Steve Bellovin
>probably disagrees with you too since you seem to be under the
>illusion
>that a reverse DNS lookup tells you anything useful.
>
>::eyeroll::
>
>Mike
>
>On 7/8/19 6:06 PM, Keith Medcalf wrote:
>> Wow!
>>
>> You must not know much about networking or programming if you do
>not know how to ask the OS to tell you the address/port associated
>with the "other end" of a TCP connection.  Obviously you know who is
>sending the message since they are in bidirectional communication
>with you at the time you are receiving the message, and you need to
>know where to send the "carry on James" prompts to get them to send
>more data...
>>
>> Therefore you always know who submitted a message.
>>

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

DKIM brought nothing of any value since it cannot be used to refuse messages or 
abort before entering the DATA phase of the SMTP conversation.  You are, no 
matter what, committing resources to receiving the message and accepting 
responsibility for its delivery.  All you can do is fart about AFTER THE FACT, 
after it is already too late to reject the message.

Presently 99.99% of the SPAM that gets through to me is DKIM signed, yet it 
is still spam.  In fact, that DKIM signature provides absolutely nothing of 
value whatsoever, except to validate that the SPAM was unmolested between the 
sending MTA and me (which is unlikely anyway, and even more unlikely since the 
transport is almost always over a TLS channel which prevents tampering between 
the sending MTA and my MTA anyway).

Like I said, DKIM does nothing of value and is directed to solve a problem that 
does not, never has, and never will, exist in the real world.

Contrast this with SPF which does do something of value.  It enables the 
dropping of the session BEFORE the DATA phase if the envelope-from domain is 
not on the list of authorized MTA to be sending messages for that domain.  The 
only real problem with it is the allowance of prevarication in the data.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Michael Thomas [mailto:m...@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 19:24
>To: Valdis Klētnieks
>Cc: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>
>On 7/8/19 6:11 PM, Valdis Klētnieks wrote:
>> On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
>>> On 7/8/19 5:54 PM, Keith Medcalf wrote:
>>>> This is because DKIM was a solution to a problem that did not
>exist.
>>>>
>>>>
>>> ::eyeroll:: pray tell, how do you "always" know the identity of
>the MTA
>>> sending you a message?
>> It's more subtle than that - you always know the "identity" of the
>purported
>> MTA, because you know their IP address.  Whether "purported" is the
>same as
>> "legitimate" or "authorized" is a whole different kettle of
>fish
>>
>> Remember - port 25 is widely blocked precisely because there were
>always a
>> plenty supply of MTAs whose identity you knew, sending you spam
>from consumer
>> living rooms
>>
>
>Like I said, what DKIM brought is the ability to "blame me". knowing
>the
>IP address doesn't give you that in any useful way. Recall that trust
>is
>mainly a social construct, not a technical one. Bruce Schneier has
>written about that endlessly.
>
>Mike

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

On Monday, 8 July, 2019 19:28, Michael Thomas  wrote:

>On 7/8/19 6:24 PM, Keith Medcalf wrote:

>> You are the only person who has mentioned reverse DNS lookups.

>I'm only trying to guess what enlightens your misinformed world.

You claimed that the "root problem" was not knowing who the originator was.

I claimed that you ALWAYS must know who the originator is -- they are at the 
other end of the connection.

You want to do a "reverse DNS lookup" for some reason.

I still do not understand how doing a "reverse DNS lookup" will help with the 
identity at the other end of the connection, since you already have to know 
that identity in order to perform a reverse DNS lookup...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

Their lawyers probably explained to them that they can "block" the call "after" 
accepting it and thus can get the best of both world -- the revenue from 
terminating the call while still preventing it from bothering their customers 
...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher
>Morrow
>Sent: Wednesday, 10 July, 2019 22:10
>To: Sean Donelan
>Cc: nanog list
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan 
>wrote:
>>
>> On Tue, 9 Jul 2019, Sean Donelan wrote:
>> > The agenda looks like lots of happy, happy talk from industry
>> > representatives.
>>
>> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a
>press
>> release announcing plans to automatically block robocalls for its
>> customers.
>>
>> https://about.att.com/story/2019/att_call_protect.html
>>
>> Automatic Blocking of Fraud Calls Coming to Millions of AT&T
>Customers
>> AT&T* will add automatic fraud blocking and suspected spam-call
>alerts to
>> millions of AT&T consumer lines at no charge.
>
>oh goodie!
>
>So, not being a bell shaped headed person... a question:
>  The calling path and data available inside the phone network smells
>(to me) like:
> ingress trunk + ANI + CallerID + outgoing trunk of destination
>ds0/handset
>
>There seem like a bunch of pretty simple 'correlations' one could
>make, that actually look a heck of a lot like 'netflow/log analysis
>for ddos detection':
>o is this trunk sourcing calls to 'too many' of my subs in
>period-of-time-X
>o is this trunk sourcing calls from a low distribution of ANI but
>a different distribution of CallerID
>o is this trunk sourcing calls from unmatched (as a percent of
>total) ANI/CallerID
>
>I would think you could make similar correlations across the
>destinations on your phone-network:
>o Is there one ANI or CallerID talking to 'all' (a bunch, more
>than X of type Y customer end point) of my endpoints?
>o are there implausible callerid being used? (lots of 'NPA-NXX
>matches destination, yet from a very different geography?)
>
>I imagine that with the number of calls here, this is just a splunk
>correlation away from successful identification and then disabling of
>these nuisance calls...
>I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a
>whiff of a care" on the part of the carrier(s), right?
>Maybe they don't actually care about this problem until they are
>'forced' to care about it by their regulating body?
>'shaken' and 'stir' may not do anything at all useful for the
>problem,
>but they do make it appear that the carriers care about the
>problem...
>I'm certain that they know there are problems. The 5 items above
>can't
>be 'new and novel' concepts ... since this is basically 'logs
>analysis' that any security engineer worth their salt does as a
>matter
>of course daily, right?
>
>-chris

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

On Thursday, 11 July, 2019 11:18, Christopher Morrow  
wrote:

>On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins  wrote:

>> Chris it would be trivial for this to be fixed, nearly overnight,
>> by creating some liability on the part of carriers for illicit use of
>> caller ID data on behalf of their customers.

>'illicit use of caller id' - how is caller-id being illicitly used
>though?
>I don't think it's against the law to say a different 'callerid' in
>the call session, practically every actual call center does this, right?

The problem is that CallerID is not really the CallerID.  It is some fraudulent 
shit created by the caller.  This is not how "CallerID" was originally sold.  
It was sold as being the ID of the Caller.  If it is not the ID of the Caller 
then Fraud is being committed and the bastards should be castrated (or worse), 
and the CEO and Directors of the carrier responsible for fraud getting through 
to the end-user should face the same penalty.

See then how quickly this gets fixed.  You will fall off your chair and it will 
be a "solved problem" before your arse hits the ground!

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

On Thursday, 11 July, 2019 12:38, Ross Tajvar  wrote:

>What if you use different carriers for termination and origination?
>How does your termination carrier validate that your origination
>carrier has allocated certain numbers to you and that you're
>therefore allowed to make outbound calls with a caller ID set to
>those numbers? That doesn't sound to me like something that can be
>solved as quickly and easily as you imply.

It does not really matter.  What matters is that they bear responsibility for 
an act in furtherance of a conspiracy to commit fraud.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>
>On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf 
>wrote:
>
>
>
>   On Thursday, 11 July, 2019 11:18, Christopher Morrow
> wrote:
>
>   >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins
> wrote:
>
>   >> Chris it would be trivial for this to be fixed, nearly
>overnight,
>   >> by creating some liability on the part of carriers for
>illicit use of
>   >> caller ID data on behalf of their customers.
>
>   >'illicit use of caller id' - how is caller-id being illicitly
>used
>   >though?
>   >I don't think it's against the law to say a different
>'callerid' in
>   >the call session, practically every actual call center does
>this, right?
>
>   The problem is that CallerID is not really the CallerID.  It is
>some fraudulent shit created by the caller.  This is not how
>"CallerID" was originally sold.  It was sold as being the ID of the
>Caller.  If it is not the ID of the Caller then Fraud is being
>committed and the bastards should be castrated (or worse), and the
>CEO and Directors of the carrier responsible for fraud getting
>through to the end-user should face the same penalty.
>
>   See then how quickly this gets fixed.  You will fall off your
>chair and it will be a "solved problem" before your arse hits the
>ground!
>
>   --
>   The fact that there's a Highway to Hell but only a Stairway to
>Heaven says a lot about anticipated traffic volume.
>
>
>
>
>

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

Not my job.

However, if you hire me I am sure that I can come up with a solution.

Since retirement my rates have dropped to $1,000/hour with a 4 hour minimum.  
Payable in advance since you probably have no established credit with me.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Ross Tajvar [mailto:r...@tajvar.io]
>Sent: Thursday, 11 July, 2019 12:54
>To: Keith Medcalf
>Cc: Christopher Morrow; North American Network Operators' Group
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>Well yeah, people need to take responsibility, but IMO we as
>engineers need to discuss the specific circumstances and
>methodologies that enable that to happen. It's easy to say "they
>should fix it", and you're not wrong that they should, but how? Do
>you have a validation framework in mind which carriers can implement
>that prevents fraudulent caller ID information from being sent
>without preventing legitimate use cases?
>
>On Thu, Jul 11, 2019, 2:46 PM Keith Medcalf 
>wrote:
>
>
>
>   On Thursday, 11 July, 2019 12:38, Ross Tajvar 
>wrote:
>
>   >What if you use different carriers for termination and
>origination?
>   >How does your termination carrier validate that your
>origination
>   >carrier has allocated certain numbers to you and that you're
>   >therefore allowed to make outbound calls with a caller ID set
>to
>   >those numbers? That doesn't sound to me like something that can
>be
>   >solved as quickly and easily as you imply.
>
>   It does not really matter.  What matters is that they bear
>responsibility for an act in furtherance of a conspiracy to commit
>fraud.
>
>   --
>       The fact that there's a Highway to Hell but only a Stairway to
>Heaven says a lot about anticipated traffic volume.
>
>
>   >
>   >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf
>
>   >wrote:
>   >
>   >
>   >
>   >   On Thursday, 11 July, 2019 11:18, Christopher Morrow
>   > wrote:
>   >
>   >   >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins
>   > wrote:
>   >
>   >   >> Chris it would be trivial for this to be fixed,
>nearly
>   >overnight,
>   >   >> by creating some liability on the part of carriers
>for
>   >illicit use of
>   >   >> caller ID data on behalf of their customers.
>   >
>   >   >'illicit use of caller id' - how is caller-id being
>illicitly
>   >used
>   >   >though?
>   >   >I don't think it's against the law to say a different
>   >'callerid' in
>   >   >the call session, practically every actual call center
>does
>   >this, right?
>   >
>   >   The problem is that CallerID is not really the CallerID.
>It is
>   >some fraudulent shit created by the caller.  This is not how
>   >"CallerID" was originally sold.  It was sold as being the ID of
>the
>   >Caller.  If it is not the ID of the Caller then Fraud is being
>   >committed and the bastards should be castrated (or worse), and
>the
>   >CEO and Directors of the carrier responsible for fraud getting
>   >through to the end-user should face the same penalty.
>   >
>   >   See then how quickly this gets fixed.  You will fall off
>your
>   >chair and it will be a "solved problem" before your arse hits
>the
>   >ground!
>   >
>   >   --
>   >   The fact that there's a Highway to Hell but only a
>Stairway to
>   >Heaven says a lot about anticipated traffic volume.
>   >
>   >
>   >
>   >
>   >
>
>
>
>
>

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


On Thursday, 11 July, 2019 13:03, Peter Beckman  wrote:


>On Thu, 11 Jul 2019, Keith Medcalf wrote:

>> On Thursday, 11 July, 2019 12:38, Ross Tajvar 
>wrote:
>>
>>> What if you use different carriers for termination and
>origination?
>>> How does your termination carrier validate that your origination
>>> carrier has allocated certain numbers to you and that you're
>>> therefore allowed to make outbound calls with a caller ID set to
>>> those numbers? That doesn't sound to me like something that can be
>>> solved as quickly and easily as you imply.
>>
>> It does not really matter.  What matters is that they bear
>responsibility
>> for an act in furtherance of a conspiracy to commit fraud.
>
>  Fraud means you'll need to know the content of the call to
>determine if
>  the spoofing of the CallerID value meets the bar of breaking the
>law.
>
>  Truth in CallerID Act is only violated if there is intent to
>defraud when
>  the CallerID is spoofed. If you spoof CallerID and do not know the
>content
>  of the call, you cannot know if the Act was violated.

The "content" of the call is irrelevant.

If one received identification information (the CallerID) and then passes that 
information on (a deliberate act) with the intent that it be acted upon as if 
valid (is the CallerID), and that information later turns out to be fraudulent 
(it does not in fact identify the caller) then the "passer on" has acted in 
furtherance of the conspiracy to defraud.  Neither negligence nor recklessness 
is a defense against the conspiracy.  The only essential elements that need to 
be proved are that (a) the callerid information was fraudulent (b) the 
passer-on intended that the information be taken as non-fraudulent.  The fact 
that the passer-on also "made money from" its specific act in furtherance of 
the conspiracy is further proof of active participation and benefit from 
participation in the conspiracy.

The second rule in relation to intent also applies:

If one deliberately engages on a course of action in which a given result is 
possible outcome, and that result ensues, implies the intent to cause the 
result so obtained, notwithstanding that the course of action was intended to 
obtain a different result.

If "CallerID" were in fact sold as "whatever information caller chooses to 
convey" rather than as the Identification of the caller, then there would be no 
problem in "passing on" that information.  However holding out that "CallerID" 
is in fact the ID of the Caller, and making money by holding out that to be the 
case, means that the passer-on of the fraudulent information is liable for the 
falsity of that information notwithstanding that he cannot verify it.

So in fact the whole thing is and was from the get-go a designed with the 
intent to convey information under fraudulent pretenses and for fraudulent 
purposes.

RE: Best ways to ensure redundancy with no terrestrial ISPs

[Keith Medcalf]

On Sunday, 4 August, 2019 12:20, Mehmet Akcin  wrote:

>I understand and share your frustration about forcing account
>registration. We had no other way but to implement this as constantly
>we had sources trying to download our data by examining our code. By
>having access controls we were able to stop that. My team had
>recommended user data controls after reviewing Geoserver, mapbox
>requirements, if you know any other way please feel free to
>recommend.

You permit anyone to view the code running on your web server?  Do you permit 
them to modify it too?
Nevertheless, just deny code viewing permission on your web server and only 
serve output of executing that code.
Quite simple.  And no one can steal your code (unless you let them into the 
room containing the web server).

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: What can ISPs do better? Removing racism out of internet

[Keith Medcalf]

On Sunday, 4 August, 2019 21:41, Mehmet Akcin  wrote:

>Most of us who operate internet services believe in not being the
>moderator of internet. We provide a service and that’s it. Obviously
>there are some established laws around protecting copyrights, and
>other things which force us to legally take action and turn things
>down when reported.

>What can we do better as network operators about hate sites like
>8Chan?

>I applaud cloudflare’s (perhaps slightly late) decision on kicking
>8chan off its platform today after El Paso attack.
>https://blog.cloudflare.com/terminating-service-for-8chan/

>I am sure there are many sites like this out there, but could network
>operators do anything to make these sites “not so easy” to be found,
>reached, and used to end innocent lives?

I do not quite understand this.

In days of yore, nutters used to send their screeds to Newspapers, TV and Radio 
stations.  Did you shut them down or move them to frequencies that could not be 
received with COTS TVs and Radios?  Did you ban the newspapers, put them out of 
business, or make it so their broadsheet was only available by travelling by 
aeroplane for 8 hours before breakfast?

Of course not, you silly duck!

There is an advantage to having all the nutters congregating on one place -- 
you know exactly where to find them.  Granted, the advantage is not exactly the 
same as we apply to politicians (or lawyers) who are kepts all in one place so 
that kinetic weapons can dispatch the whole lot at one go if necessary.

However, your solution of sweeping things you do not like under the rug is 
ill-conceived if not brain-dead in conception and you must not be permitted to 
carry out your objectives.  The fate of the free world depends on it.

However, do not worry.  US AG William Barr is doing a fine job deploying his 
"backdoors".  Why just the other day one of them was used to shut down the 
Georgia State Public Safety Services, and prior to that his "backdoors" were 
used to shut down several city computer systems in Florida and even the City of 
Baltimore.  Good work with those backdoors, Mr. Barr.  Job well done!

It is nincompoops who do not think about what they are doing that create such a 
bloody mess of things.  They should let the adults take care of it.

Now, enough of this off-topic stuff and back to our regularly scheduled 
programming.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: What can ISPs do better? Removing racism out of internet

[Keith Medcalf]

On Monday, 5 August, 2019 09:16, Mel Beckman  wrote:

>“Now, enough of this off-topic stuff and back to our regularly
>scheduled programming.”

>Keith, what could be more on-topic than an ISP’s status as a common
>carrier? Seems pretty operational to me.

I think that is closing the barn door after the horse already left.

It is my understanding that in your fabulous United States of America that 
"carriers" (meaning having no content serving nor content consuming customers*) 
may be "common carriers" or can claim to be common carriers.  The rest of you 
who are not pure carriers are, thanks to Ijit Pai, merely Information Services 
and do not have common carrier status, nor can you claim to be common carriers.

A "common carrier" is one who must provide carriage provided the fee for 
carriage is paid.  This is not the case for "Information Service" providers as 
they are not required to provide carriage to any who can pay the fee for 
carriage.

*I hate the term "content", it is somowhat lame.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: What can ISPs do better? Removing racism out of internet

[Keith Medcalf]

On Monday, 5 August, 2019 10:25, Bryan Fields  wrote:

>I'd be more concerned with the lack of notice given to their
>customer.  This was 24 hours notice, and I'd expect at least
>30 days under any hosting contract.  This scares the shit
>out of me as a customer; could cloudflare decide to give me
>no notice and shut my services off?

Yes.  This is in Cloudflare's Terms of Service.  You pay them and they provide 
services.  They may decide to terminate those services at any time, without any 
prior notice whatsoever, and keep your money.  You agree to this when you 
contract with them.

So I would suppose that this just means that you would not do business with 
Cloudflare.  That is your right.  If you do not like the contract provisions 
you are free not to contract with them.

If you do not mind that they may decide at any point in time for any reason or 
no reason at all to terminate your services and stop providing the service for 
which you have paid in advance (and without refund), then you are free to do so.

As always, the choice is yours.  No one compels you to do business with 
Cloudflare.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: What can ISPs do better? Removing racism out of internet

[Keith Medcalf]

>Hey, I got my Network+ too.   dafuq is a "BGP"?

That's what the British get after too much Beer-o-clock.  A Bloody-Good-Puking 
...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: the CLOUD Act (was What can ISPs do better? Removing racism out of internet)

[Keith Medcalf]

On Tuesday, 6 August, 2019 12:17, Anne P. Mitchell, Esq.  
wrote:

...

>John Deaux is from London, and a citizen of the UK. John is working
>in the U.S., at a tech company in Palo Alto, California. John has a
>Gmail account, and uses Dropbox to store his photos. A law
>enforcement agency in the UK decides that it wants access to the data
>in John’s Gmail account and Dropbox account, and so they serve a
>demand for the production of John’s data on Google and Dropbox, under
>the CLOUD Act. If the U.S. and the UK have an executive agreement in
>place as contemplated by the CLOUD Act, Google and Dropbox must
>comply.

I assume that by "serve a demand" you mean "send a letter requesting"?

I realize that the purpose of the terms "serve a demand" if legal 
globedey-glook phrased to pompously instill in the reader some feeling of the 
majesty and due regard for the process (etc), but in reality it is just pompous 
for "send a letter requesting" is it not?

>Google and Dropbox must comply.

Well, no.

They do not "have to" do anything.  You do not *have to comply* with anything.  
Such is the nature of existance and it has always been thus.  Of course, those 
seeking compliance are also free to torture you until you do as they want, but 
you do not "have to comply".  What happens when an irresistable force (the 
torturer) meets and immovable object (the one refusing to comply) depends on 
which has the greatest resolve.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: the CLOUD Act (was What can ISPs do better? Removing racism out of internet)

[Keith Medcalf]

On Tuesday, 6 August, 2019 13:21, Valdis Kletnieks  
wrote:

>On Tue, 06 Aug 2019 12:54:55 -0600, "Keith Medcalf" said:

>> I realize that the purpose of the terms "serve a demand" if legal
>> globedey-glook phrased to pompously instill in the reader some
>> feeling of the majesty and due regard for the process (etc), but
>> in reality it is just pompous for "send a letter requesting" is it not?

> I don't know about that.  Most definitions of "pompous" don't include
> the implied phrase "or end up in a cell on a contempt citation".

In Canada that is called "Extortion" and is a crime punishable by a number of 
years in prison.  If the "implication" of the phraseology is to convey a threat 
in order to obtain compliance with the object of the statement, then the entire 
process is extortion from the get go.  Since this cannot possibly be the case, 
your assertion must be incorrect, and there can be no such implication.

Moveover I would wonder what exactly one would be in contempt of?  The 
politicians who voted in favour of the passage of the Act?  Contempt for the 
sender of the letter?  None of these are capable of being "contempt" in any 
actionable sense.  In fact, failure to comply with an order of a judge who 
makes an "administrative" order (that is, who is not acting as a judge, but is 
merely an administrative functionary or rubber-stamper) does not constitute 
contempt of court in Canada (since there was no actual due process or court 
function of judicial judgement involved to be in contempt of).

>Feel free to be the test case to find out if a demand under the CLOUD
>act can result in a US contempt citation. :)

Anyone can bring whatever proceedings they like before any court at any time 
for any reason or no reason at all without regard to the probability of success 
of those proceedings.  So whether or not "a demand under the CLOUD act can 
result in a US contempt citation" is quite meaningless.

Of course, I only have first-hand knowledge of legal procedures in free 
countries, so how the United States does things is not entirely within my 
experience.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: What can ISPs do better? Removing racism out of internet

[Keith Medcalf]

On Wednesday, 7 August, 2019 13:38, b...@theworld.com wrote:

>I propose that the RIGHT THING TO DO would be to seek out, promote
>(to >both customers and the public), and support various curation
>services like netnanny.

IANAP (I Am Not A Psychiatrist) however, persons who, when reading or hearing 
the words of others cannot control the images which leap, unbidden, into their 
minds causing them to offend themselves or otherwise instill in themselves a 
self-created state of distress, should, IMHO, seek professional help from a 
trained and certified mental health professional who may be able to help them 
overcome their mental disability either through psychotherapy or the 
administration of psychoactive drugs.

I do not think NetNanny is a certified mental health professional in any 
jurisdication -- at least not those within the NANOG region.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Research project on blacklists

[Keith Medcalf]

Cannot access your website.  Just has a spinning colostomy bag.  Too much 
malicious javascript and malicious trackers.

If you expect people to visit the website, perhaps you should make it more 
useable, because at the moment, it is completely and utterly useless!

And there is no way I am going to turn off security in order to access crap 
promulgated by idiots!

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Anushah
>Hossain
>Sent: Thursday, 8 August, 2019 08:08
>To: nanog@nanog.org
>Subject: Research project on blacklists
>
>Hi all,
>
>My colleagues and I at UC Berkeley and the International Computer
>Science Institute are working on a project evaluating third-party
>blacklists. As part of that, we're interested in hearing how you
>utilize them, and what you perceive as their strengths and
>weaknesses. If you have five to ten minutes and are interested in
>sharing your thoughts, you can fill out our anonymous survey here, or
>respond to me directly off-list:
>https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl
>
>There is also an option in the survey to opt-in to receiving a
>notification once the research is made public.
>
>Apologies if you received this message before! We've tried to
>minimize cross-posting as we realize several groups share members.
>
>Best,
>Anushah
>
>--
>
>Anushah Hossain, PhD Student
>Energy and Resources Group, UC Berkeley

RE: Research project on blacklists

[Keith Medcalf]

On Thursday, 8 August, 2019 13:43, J. Hellenthal  wrote:

>Just as well as the proper signature divider in an email is actually
>“dash dash space”

>\o/

>Site works just fine. Doubt javascript here is of any concern to
>anyone whatsoever.

>Just sayin

qualtics.com loads a blacklisted malicious tracker from itself.  The fact that 
it is the first party does not detract from the fact it is loading a malicious 
tracker and that the loading of that malicious tracking javascript is blocked.  
Blocking the tracker precludes the rest of the page from "working".

And yes, I know the sig seperator is -- (dash dash space).  Are you saying that 
my MUA is buggering it up again?

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

[Keith Medcalf]

For efficiency of censorship.  If you want to stop some domain name from 
resolving you have to get everyone on the planet to block that DNS resolution 
in their recursive resolver.  However, if everyone uses the same single DNS 
server operated by a single entity, then you only have to coerce that one 
entity to block resolution of that DNS name.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of Mike Hammett
>Sent: Wednesday, 18 September, 2019 08:19
>To: Jeroen Massar 
>Cc: NANOG 
>Subject: Re: DNS Recursive Operators: Please enable QNAME minimization
>(RFC7816) for the enhanced privacy of your users
>
>Why on Earth would anyone want that (Firefox deciding to do it's own DNS)
>as default behavior?
>
>
>
>
>-
>Mike Hammett
>Intelligent Computing Solutions 
> 
>
>
>
>Midwest Internet Exchange 
> 
>
>
>The Brothers WISP 
> 
>
>
>
>
>From: "Jeroen Massar" 
>To: "NANOG" 
>Sent: Wednesday, September 18, 2019 2:15:49 AM
>Subject: DNS Recursive Operators: Please enable QNAME minimization
>(RFC7816) for the enhanced privacy of your users
>
>Hi Folks,
>
>While in the US soon all Firefox users will *NOT* use your DNS Recursives
>configured using DHCP anymore
>(NXDOMAIN use-application-dns.net to avoid that[1]).
>Next to that, it seems some of the root operators are now creating
>instances in the same networks that offer these kind of services for
>globally figuring out what queries are being made.
>
>
>For those that thus either opt-out or otherwise want to use their own
>system resolvers, I suggest that all that run
>DNS Recursive setups enable "QNAME minimization" as defined in
>(experimental) RFC7816 [2]
>
>For pdns "qname-minimization=yes" [6]
>For unbound "qname­-minimisation: yes" [5]
>For BIND "qname-minimization" option [3] and [4]
>
>Of course, do also provider your users with the option of using DoT or
>even DoH on your recursors...
>
>Noting that DoH operators are supposed to enable RFC7816 also [7], guess
>they do not want others to see all the details they get...
>
>Some more details in DNS Privacy Wiki [8]...
>
>Discuss! :)
>
>Greets,
> Jeroen
>
>
>[1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-
>dns-over-https
>[2] https://tools.ietf.org/html/rfc7816
>[3] https://www.isc.org/blogs/qname-minimization-and-privacy/
>[4] https://gitlab.isc.org/isc-projects/bind9/issues/16
>[5]
>https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf
>[6] https://github.com/PowerDNS/pdns/issues/2311
>[7] https://wiki.mozilla.org/Security/DOH-resolver-policy
>[8] https://dnsprivacy.org/wiki/
>

RE: Colombia Network Operators Group

[Keith Medcalf]

Fascinating.  What is the security threat I wonder, that there is no JavaScript?

>-Original Message-
>From: NANOG  On Behalf Of Scott Weeks
>Sent: Monday, 23 September, 2019 13:06
>To: nanog@nanog.org
>Subject: Re: Colombia Network Operators Group
>
>
>
>--- meh...@akcin.net wrote:
>From: Mehmet Akcin 
>
>Few people who is doing a lot of work in Colombia, we decided to start
>Colombia network operators group and arrange local meetups, provide
>people
>support who want to have infrastructure here.
>
>Feel free to join www.nog.com.co and our first face to face meeting will
>be
>in december, date to be announced soon!
>-
>
>
>
>For whatever reason, cisco is not happy with the site:
>
>"This site is blocked due to a security threat that was discovered by
>the Cisco Umbrella security researchers."
>
>scott

RE: BGP routes by country

[Keith Medcalf]

RIR Delegations data is public.
https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/rir-statistics-exchange-format/

The various RIR delegation statistics can be gotten from:

https://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest
https://ftp.apnic.net/stats/apnic/delegated-apnic-latest
https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest
https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest
https://ftp.ripe.net/ripe/stats/delegated-ripencc-latest

They do follow the format in the rir-statistics exchange format doc.  They are 
not necessarily located or replicated as described (apparently).  Of course, 
the country code does not necessarily reflect where the resource is used -- I 
believe it is the CC of the registering org.  If it were so simple then all the 
geolocation companies would be outa business in a flash.

>-Original Message-
>From: NANOG  On Behalf Of Chris Phillips
>Sent: Thursday, 26 September, 2019 00:46
>To: nanog@nanog.org
>Subject: BGP routes by country
>
>Greetings,
>
>Is anyone offering a service providing BGP routes by country?  I'm not
>looking to buy transit, but rather build policies based on the routes
>received to allow traffic from certain countries, or disallow traffic
>from others.  Kind of like the the CYMRU bogons list, but, by country.
>
>Thank you in advance.

RE: This DNS over HTTP thing

[Keith Medcalf]

On Tuesday, 1 October, 2019 01:39, Stephane Bortzmeyer
 wrote:

>On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin
 wrote

>> It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
>> will go back to using your local DNS server list as per usual.

> Unless, I hope, the user explicitely overrides this. (Because this
> canary domain contradicts DoH's goals, by allowing the very party you
> don't trust to remotely disable security.)

According to Mozilla:
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-ov
er-https

Network administrators may configure their networks to treat DNS
requests for a canary domain differently, to signal that their local DNS
resolver implements special features that make the network unsuitable
for DoH.

In addition to the canary domain signal described above, Firefox will
perform some checks for network features that are incompatible with DoH
before enabling it for a user. These checks will be performed at browser
startup, and each time the browser detects that it has moved to a
different network, such as when a laptop is used at home, work, and a
coffee shop. When any of these checks indicates a potential issue,
Firefox will disable DoH for the remainder of the network session,
unless the user has enabled the "DoH always" preference as mentioned
above.

The additional checks that will be performed for content filtering are:

Resolve canary domains of certain known DNS providers to detect
content filtering
Resolve the "safe-search" variants of google.com and youtube.com to
determine if the network redirects to them
On Windows and macOS, detect parental controls enabled in the
operating system

The additional checks that will be performed for private "enterprise"
networks are:

Is the Firefox security.enterprise_roots.enabled preference set to
true?
Is any enterprise policy configured?

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: This DNS over HTTP thing

[Keith Medcalf]

On Tuesday, 1 October, 2019 22:15, David Conrad  wrote:

>DoH (and DoT) encrypt (and authenticate) the application <-> recursive
>resolver channel (NOT the DNS data) which I gather some view as an attack
>vector.

Actually no.  DoH and DoT encrypt the application <-> recursive resolver 
application channel.  Some people may wish to believe that the current CA 
system provides some sort of meaningful "authentication" of the endpoint, but 
unless you have specifically acquired the remote endpoint's certificate through 
secure means and added it specifically to your verification store (and disabled 
the CA root), the endpoint is *not* authenticated.  (Though it is possible that 
you have very lax authentication requirements and treat "authentication" based 
on the hearsay of a third-party that yet another third-party is trustworthy as 
being valid "authentication")

IF AND ONLY IF the party to whom you have connected has kept their private key 
private THEN AND ONLY THEN is the conversation between the two applications  
protected from being decrypted by eavesdroppers between, but not at or beyond, 
each of those communicating applications.

It is a common fallacy that TLS connections are authenticated.  The vast 
majority of them are not authenticated in any meaningful fashion and all that 
can be said about TLS is that it provides an encrypted connection between the 
two communicating applications.  This is perhaps why it is call *transport* 
layer security ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: This DNS over HTTP thing

[Keith Medcalf]

On Wednesday, 2 October, 2019 03:55, Tom Ivar Helbekkmo  
wrote:

>However: because the browser cannot know for sure that the DNS traffic
>is being routed over a secure channel, and browsers are being used for
>all sorts of sensitive communication, it could check, and try to assist
>the user.

Sensitive communications?  Browsers?  ROTFLMAO!

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: This DNS over HTTP thing

[Keith Medcalf]

On Wednesday, 2 October, 2019 10:55, Sabri Berisha  
wrote:

>> Firefox and Chrome now reportedly use it unless you tell them not to.

>Just imagine how this list would explode if BGP implementations would all
>of a sudden have their default behavior changed to include auto-
>negotiated MD5 passwords.

Bad analogy.  A correct analogy would be that all the BGP implementations 
suddenly decided to get enter into a priority remote peering session with 
SpiesAreUs.com ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: This DNS over HTTP thing

[Keith Medcalf]

On Wednesday, 2 October, 2019 14:52, John Levine  wrote:

>I think in the outside world you'll find very little support for an
>argument that filtering DNS is fundamentally broken.

Well, it is certainly trivial to bypass.  Therefore it is a fantastic tools for 
tyrants and other fuckwads -- just as long as they think they are being 
effective, who really gives a rats ass.

>Sure, you can do it in broken ways, but it's going to be really hard
>to persuade anyone that their lives are better if they have unfiltered
>access to the malware links in their spam.

Having unfiltered access to the malware installed by links in spam is a 
self-limiting problem.  Remove the DNS blocks and in rather short order the 
problem will go away as all the idiots click their way to oblivion.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: This DNS over HTTP thing

[Keith Medcalf]

On Wednesday, 2 October, 2019 15:21, Jay R. Ashworth  wrote:

>>>HTTP/451
>>
>> Completely different protocol than what the rest of this thread is
>> about, much more invasive wrt possibility of logging, and requires
>> a lot more infrastructure and actual lying in DNS to make work.
>
>Closed captioned for the analogy-impaired:
>
>"The idea you're talking about, Jason, is analogous to that embodied in
>the 451 error code in HTTP."

And here I thought it was about the temperature at which the paper on which it 
was written spontaneously combusted ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

FW: This DNS over HTTP thing

[Keith Medcalf]

Masataka Ohta wrote:
>
>Livingood, Jason wrote:
>
>> The challenge of course is that in the absence of a silver bullet
>> solution, that people working to combat all forms of childsorship
>> exploitation are simultaneously trying several things, ranging from
>> going to the source as you suggest and arresting people, to trying to
>> interrupt the online tools that they may use or that might
>> fund/support them, etc.
>
>The Internet was working very well to suppress child porn by
>making video freely distributed, which made child porn industry
>a lot less profitable.
>
>Freely distributed video also makes investigation of victims
>easier.
>
>So, people who want to make money from child porn has been
>trying to have censorship of various degree.
>
>In UK, they are very successful.

Finally, someone with a modicum of common sense and proper reasoning.

I salute you, sir!

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Update to BCP-38?

[Keith Medcalf]

On Thursday, 3 October, 2019 11:50, Fred Baker  wrote:



> A security geek would be all over me - "too many clues!".

Anyone who says something like that is not a "security geek".  They are a 
"security poser", interested primarily in "security by obscurity" and "security 
theatre", and have no clue what they are talking about.  Send them back to the 
burger assembly line at McDonalds -- they are not even qualified to be flipping 
the burgers -- only to assemble the final burger from the pre-flipped burgers 
in the burger drawers.  And keep them away from the deep fryer, cash, and the 
microwave oven.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Update to BCP-38?

[Keith Medcalf]

On Friday, 4 October, 2019 16:05, William Herrin  wrote:

>On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf  wrote:

>> On Thursday, 3 October, 2019 11:50, Fred Baker  
>> wrote:

>>> A security geek would be all over me - "too many clues!".

>> Anyone who says something like that is not a "security geek".  They
>> are a "security poser", interested primarily in "security by obscurity"
>> and "security theatre", and have no clue what they are talking about.

> It's called "operations security" or "OPSEC." The idea is that from lots
> of pieces of insignificant information, an adversary can derive or infer
> more important information you'd like to deny to him. There's a 5-step
> process used by the U.S. Military but the TL;DR version is: if you don't
> have to reveal something, don't.

You and I have completely different opinions of how security works.  In my 
world, security must continue to be effective even in the face of an adversary 
that knows everything there is to know about what is being attacked (except for 
some authentication secrets, which of course need to be kept secret).

If the attacker does not already have that information, then obtaining it is 
usually a rather trivial reconnaissance operation.  The job of "securing" 
something means to make it impervious to outside influence -- it is the other 
side of the "safety" coin -- and Safety and Security go hand in hand.

Security based on keeping something which is trivial to discover secret is 
trivial security and can still be trivially bypassed.

It is telling that of the thousands of "ransomware attacks" that occur each 
second, only 617 have been successful so far this year.  Those victims probably 
relied on keeping something secret that did not matter.  In other words, they 
expended effort on the wrong things -- their analysis of risk was inherently 
flawed.

Can you provide a scenario in which knowledge of the VLAN number is a 
vulnerability that can be exploited?  And if you can find one, is there a more 
effective way to prevent that exploit that will work even if the attacker knows 
the VLAN number?  Would it not be more effective to implement that measure than 
simply using trivial means (that are trivial to defeat) to hide the VLAN 
number?  This does not mean that you need to publish the VLAN numbers on 
Facebook for all to see, merely that knowledge of that fact is now irrelevant, 
and that even if the someone posted the VLAN numbers on Facebook for all to 
see, then that would not be helpful to the adversary.

>IMO, anyone who thinks the folks who developed OPSEC don't have a clue is
>the one I find wanting.

Opinions vary.  That is the nature of opinion.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Keith Medcalf]

On Monday, 7 October, 2019 08:55, Rich Kulawiec  wrote:

>On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote:

>> Otherwise, an impressive amount of WTF. My favorite: "while
>> communication by servers ___on the ground___ might take hundreds of
>> milliseconds, in the cloud the same operation may take only one
>> millisecond from one machine to another"

>My favorite: "The researchers expect their cloud-based system will be
>more secure than the Internet is today [...]"  Apparently they're
blissfully
>unaware that there is no such thing as "cloud security".

I would be interested to know how one connects to their "cloud"?  Do I
need an "Evaporation Adapter" for my computer to send to their cloud?
And do I need a "Rain Collector" to receive from it?  I suppose I also
need the computer to be outside exposed to the elements -- putting it
under a brolly would interfere with incoming rain from the cloud ...
Plus I suppose it would not work very well at all in the desert, but
downloading would be very high bandwidth in the rainforest (or during
monsoon season).

:)

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: Update to BCP-38?

[Keith Medcalf]

>Not everyone attacking your systems is going to have the skills or
>knowledge to get in though - simple tricks (like hiding what web server
>you use) can prevent casual attacks from script kiddies and others who
>aren't committed to targeting you, freeing your security teams to focus
>on the serious threats.

And this is based on what evidence?  It also defies logic.  By
definition script-kiddies run scripts.  If you remove the identification
those scripts can no longer identify what is running, and therefore will
continue to attack it.  What would be useful is to replace that with
alternative "disinformation" headers so that the script-kiddies scripts
will get a positive result, but that result will not be what they are
looking for, so they will go away.  Until having disinformation headers
gets the same "old wives tale" status as "remove the identifying
headers".  At which point either course of either action is a waste of
effort and $$$ because the script-kiddies will just ignore it as it will
be just as cost effective to run the exploit and see what happens.

In other words, simple tricks are exactly that.  They usually do exactly
the opposite of what the "simple tricker" thought they were doing, or do
nothing useful at all.  Which means that effort and $$$ have been
expended at best on a useless endeavour, and at worst one which
increased the very activity it was designed to thwart.  One would have
been far better off putting the $$$ in the slush-fund and using it when
some particularly persistent script-kiddie showed up so you could afford
to add a filter to the firewall.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

RE: Update to BCP-38?

[Keith Medcalf]

On Tuesday, 8 October, 2019 11:03, William Herrin  wrote:

>Limiting the server banner so it doesn't tell an adversary the exact OS-
>specific binary you're using has a near-zero cost and forces an adversary
>to expend more effort searching for a vulnerability. It doesn't magically
>protect you from hacking on its own. As you say, your security must not
>be breached just because the adversary figures out what version you're
>running. But viewed as one layer in an overall plan, limiting that
>information enhances your security at negligible cost. That's security
>smart.

I think your analysis is incorrect.

There are two cases which are relevant:
(1) The attack is non-targetted (that is, it is opportunistic)
(2) The attack is targetted at you specifically.

In the former (1) case, it does not matter whether the "banner" identifies the 
specific OS binary or not as it is irrelevant.  The script either works or it 
does not.  Even if the "banner" says "Beyond this point there be monsters" will 
make absolutely not one whit of difference.

In the latter (2) case, it does not matter whether the "banner" identifies the 
specific OS binary or not as it is irrelevant.  You have been targetted.  All 
possible exploits will be attempted until success is achieved or the vat of 
exploits to try runs dry.

So while the cost of doing the thing may be near-zero, it is not zero.  All 
those near-zero cost things you do that have no actual advantage can add up to 
quite a huge total and it will be more advantageous to spend that somewhere 
where it will, in fact, make a difference.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: Update to BCP-38?

[Keith Medcalf]

You would still be better served by forgetting about hiding the
webserver vendor name and using that money to buy an IDS/IPS that works
properly by detecting the actual exploit attempt rather than looking for
"a spike of errors in the log" in order to block the originating
address, especially since a "spike of errors in the log" can have quite
a few causes other than exploit attempts -- in fact such a "spike in
errors" is more likely to occur for reasons other than attempts to find
a vulnerability.  Furthermore, it is quite possible for the first
exploit attempt to be successful despite having hidden the banner, in
which case the entire thing was merely nothing more than security
theatre.  This is especially true when you consider "many" systems using
this method of protection and millions of attempted exploits per second.

Furthermore, why on earth would an opportunistic attacker use two
requests when one would suffice?  There is nothing to be gained by
probing only to discover "Oh, I am getting all wet cuz this is a juicy
target" when one would merely send the exploit and see what happens --
it either works or it does not -- and probing first adds no value -- in
just makes each attempt expend more resources.  In the time you have
probed a server and gotten a response, you could have simply sent the
exploit to a dozen servers.  So clearly probing for a "good target" is
just a waste of time.

This is why most dirty e-mail spammers just "blast" out their spam
without waiting for the appropriate responses from the SMTP server, and
why having the SMTP server insist on strict RFC compliance (and test
that the connected MTA is RFC compliant) works so well at getting rid of
95% of spam.

So given a choice between:
(1) Spending money hiding the headers and using software to reconfigure
the firewall based on errors in the log; or,
(2) Spending money on an IDS/IPS that can detect and drop an exploit
dynamically

you are probably better served by (2) than by (1).  The software that
monitors the log is most useful to send a notification that there is an
excessive error rate (since that is what it is detecting).

Of the millions of ransomware attacks per second, the 617 victims so far
this year probably relied on method (1) and in hindsight wished they had
been a little smarter and used method (2) instead.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

>-Original Message-
>From: Mark Collins 
>Sent: Tuesday, 8 October, 2019 12:17
>To: Keith Medcalf ; nanog@nanog.org
>Subject: Re: Update to BCP-38?
>
>Any additional effort put in by an attacker will increase the chance of
>an attack being detected before it is successful. COnsider the
following
>two scenerios.
>
>Scenerio 1 is a webserver that makes no effort to obfuscate:
>
>
>1. Attacker does HEAD request on /, which is a legitmate request,
and
>sees the webserver vendor name
>
>2. Attacker does a quick search, and finds there is a vulnerabilty
in
>webserver
>3. Attacker exploits vulnerability
>
>
>Now, consider scenerio 2, where the server is configured to hide the
>webserver vendor and has an IDS/IPS system in place
>
>
>1. Attacker does HEAD request on /, which is a legitmate request,
but
>there is no usable information in the respone.
>2. Attacker does a probe on the webserver to try a number of
attacks,
>which generate a number of 403, 404, 500 etc errors in the webserver
logs
>3. IDS/IPS sees the sudden spike in errors from a single IP address
and
>blocks the source IP
>
>The act of obfuscation made it possible for the IDS/IPS to detect the
>probe, preventing the attack. WIll this block every attack? Probably
not,
>but it increases the effectiveness of the security by forcing the
>attacker to take additional (detectable) actions when trying to break
in.
>
>The lock on your front door can be picked by anyone with a $10 lockpick
>set in under 5 minutes, does that mean you shouldn't bother locking
your
>doors?
>
>Mark
>
>
>
>From: NANOG  on
>behalf of Keith Medcalf 
>Sent: 08 October 2019 18:53
>To: nanog@nanog.org 
>Subject: RE: Update to BCP-38?
>
>
>On Tuesday, 8 October, 2019 11:03, William Herrin 
wrote:
>
>>Limiting the server banner so it doesn't tell an adversary the exact
OS-
>>specific binary you're using has a near-zero cost and forces an
>adversary
>>to expend more effort searching for a vulnerability. It doesn't
>magically
>>protect you from hacking on its own. As you say, your security must
not
>>be breached just because the adversary figures out what version you're
>>running. But viewed as one layer in an overall