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: 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.

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: FCC to Consider New Rules to Combat International Scam Robocalls

[Keith Medcalf]

>With AT 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 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.

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: 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: 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: 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: 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: 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: 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: 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]

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: 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: 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 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 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]

>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 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 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: 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: 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: [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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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 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 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 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 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]

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 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]

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: 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: QUIC traffic throttled on AT 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: 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: 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: 5G roadblock: labor

[Keith Medcalf]

On Friday, 3 January, 2020 10:53, Radu-Adrian Feurdean 
 wrote:

>On Fri, Jan 3, 2020, at 16:38, Paul Nash wrote:

>>> And more interestingly, if that city's residents and visitors had the
>>> option of connecting to active 5G or wi-fi, what do we think they'd
>>> choose?

>> They’d probably choose whichever popped un onto the device first.

> Don't know how things work in US, but mobile devices sold here in Europe
> do prefer wifi over cellular. If a pre-"approved" wifi network exists,
> and it doesn't have a captive portal, it will be systematically
> preferred.

> And here in France we have some networks lile this. they use SIM-EAP.

How absolutely awful that must be, to always be relegated to slow and insecure 
childrens band.  I turn off childrens band (WiFi) on my phone with extreme 
prejudice and it stays that way.  I have yet to meet a childrens band network 
(WiFi) that was worth connecting too.

Then again I don't play on my phone ...

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

RE: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Keith Medcalf]

On Tuesday, 31 December, 2019 04:44, Constantine A. Murenin 
 wrote:

>Just to make it clear: are you suggesting that it should be a requirement
>to always verify the site where anonymous people make anonymous edits?
>Let that sink in.

TLS 1.2 as deployed in Web Browsers does not authenticate the end-point.  What 
it does is present an "Advertizing ID" that is akin to the "Advertizing ID" 
that the telco's sold as "Caller ID", because they new that y'all proles would 
not pay if there were truth in naming.  By the same token the general 
certificate system will "say" whatever he who pays wants it to say.  It does 
not verify anything other than the fact that the remote end-point went to the 
bother of buying (or the trouble of fiddling about with) advertizing 
certificates.

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

RE: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Keith Medcalf]

On Tuesday, 31 December, 2019 02:48, Antonios Chariton  
wrote:

>Ignoring the obvious reasons why TLS is needed and HTTP should not be
>used,

I am curious -- what exactly are those "obvious reasons"?  (And for the record 
HTTP *IS* being used, it is just being tunneled inside a TLS connection).

I certainly cannot fathom any "obvious reasons" ...

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

RE: 5G roadblock: labor

[Keith Medcalf]

>> It'd be nice to see what benefits 5g really has for carriers and
>> consumers/users... It looks, to me, like a bunch of the 5g hype is
>> really: "uhm, we need to sell these carriers on the G++ ... spin up
>> the hype machine about speed!" never mind the cost to deploy, range of
>> deployment, changes in handset/radio gear / etc... more $ to the
>> vendors!

>You know that there is a massive amount of hype going on when they tie
>IoT to why it's definitely most certainly needed the mostest. I mean,
>your average IoT gadget is going to consume exactly how much bandwidth?
>And why on earth would I want to deploy using cellular when my router
>can have a zigby port and send it using my home connection?

Why on earth would I want to send it anywhere at all over the Internet?

One already has to disassemble and inspect very closely almost all electronic 
gadgets so that the internal embeded spyware microphone and camera and wireless 
can be removed with pliers.  This is just another thing to inspect for and 
forcibly disable.

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

RE: 5G roadblock: labor

[Keith Medcalf]

>> Also, keep in mind that 10 years ago, you didn't know you would want
>> or need 25mbits to your phone,

>Who needs 25mbits to their phone?

I can only talk to one party at a time, so there is no need for more than a 
single bearer channel worth of bandwidth.

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

RE: 5G roadblock: labor

[Keith Medcalf]

On Monday, 30 December, 2019 13:24, Matthew Petach  
wrote:

>Unfortunately, Wi-Fi handoffs suck donkey balls compared to
>cell tower handoffs when moving.  It's fine when you're
>stationary, but walking down the street, and shifting from
>one wifi hotspot to the next, you're going to be dropping
>and re-establishing connections with a new endpoint IP
>address every time.

So the primary benefit of 5G is that it will allow for an increase in asshats 
not watching where they are going because they are busy staring at their phones?

I suppose there is the advantage then of more dead asshats.  At least they will 
only walk in front of a speeding lorry once and then be dead, thus solving the 
problem.

Maybe 5G *is* a good thing as it will inherently encourage clean-up of the gene 
pool.  Now if only we could figure out a way to reliably get them out of the 
gene pool before they reached breading age ...

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

RE: Iran cuts 95% of Internet traffic

[Keith Medcalf]

Why would anyone with anything important to say use somethingmail.com

Somethingmail.com is not e-mail.  It is a Giggle Gaggle Google thing.

--
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 Scott Weeks
>Sent: Sunday, 29 December, 2019 15:38
>To: nanog@nanog.org
>Subject: Re: Iran cuts 95% of Internet traffic
>
>
>
>--- jhellent...@dataix.net wrote:
>From: "J. Hellenthal" 
>
>Yeah sorry to say any email list or not is going to be one
>of the things that are not going to get through unless ...
>you’ve taken extra measures to circumvent that.
>
>Personally, email would be the easiest to block behind
>riuting.
>---
>
>
>After I sent the email I started to realize I likely
>misunderstood.  I hesitated to correct that to the list,
>but here I go. :)
>
>
>> queues can be written to media, physically transported
>> in/out, and then injected either into an internal or
>> external network seamlessly modulo the time delay.
>
>I believe he meant similar to *nix boxes where you could
>just copy the files in $HOME/mail (or where ever it is)
>onto media and once the data is out of the country it can
>be copied onto another mail system's $HOME/mail and then
>shared with the unblocked part of the internet.  Not a
>user account on somethingmail.com, but rather the entire
>$HOME/mail of all accounts and mailed to someone else who
>is somewhere else on a regular basis.  Also, the reverse
>path for receiving mail in the repressive country.
>
>A good idea either way.  KISS works. :)
>
>scott
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>--
> J. Hellenthal
>
>The fact that there's a highway to Hell but only a stairway to Heaven
>says a lot about anticipated traffic volume.
>
>> On Dec 29, 2019, at 15:57, Scott Weeks  wrote:
>>
>>
>>
>> :: If you're trying to get information in/out of a
>> :: society that is raising network barriers to
>> :: realtime communication, then you need methods
>> :: that don't rely on a network and aren't realtime.
>>
>>
>> This is a great idea, but 99.9% of folks use GUI
>> email. :-(
>>
>> scott
>>
>>
>>
>>
>> --- r...@gsp.org wrote:
>>
>> From: Rich Kulawiec 
>> To: nanog@nanog.org
>> Subject: Re: Iran cuts 95% of Internet traffic
>> Date: Sun, 29 Dec 2019 09:11:23 -0500
>>
>>
>> And this is why, despite all the disdainful remarks labeling such
>> things as "antiquated", mailing lists and Usenet newsgroups are vastly
>> superior to web sites/message boards/et.al. when it comes to
>facilitating
>> many-to-many communications between people.  Why?  Well, there are many
>> reasons, but one of the applicable ones in this use case is that their
>> queues can be written to media, physically transported in/out, and then
>> injected either into an internal or external network seamlessly modulo
>the
>> time delay.  And because the computing resources required to handle
>this
>> are in any laptop or desktop made in the last decade, probably earlier.
>>
>> If you're trying to get information in/out of a society that is raising
>> network barriers to realtime communication, then you need methods that
>> don't rely on a network and aren't realtime.
>>
>> ---rsk
>>
>>
>>
>

RE: power to the internet

[Keith Medcalf]

>I just looked up Telsa's battery packs and they seem to be between
>60-100kwh. Our daily use is about 30kwh in the fall, so it's only 2-3
>days. Admittedly we can turn off the hot tub, water heater, etc to
>stretch it out. And of course, that means that you can't drive it... The
>one thing that would be for everybody's good is using them during peak
>hours. If you work normal hours, then that only gets part of the peak
>load, unfortunately.

Just buy three of them.  Two to leave in the garage as a "mobile battery pack" 
and one to drive around.

All problems solved.

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

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

On Friday, 20 December, 2019 10:57, Mark Milhollan wrote:

>On Thu, 19 Dec 2019, Keith Medcalf wrote:

>>You should ALWAYS talk to the call center behind the robocaller.  The
>>robocaller (the one playing the message) is relatively local and the
>>cost of that call is minimal.  When you select to talk to the
>>robocaller, that generates an international handoff to a call center
>>in India.

>Generally the call center phone number is also "local" even if the warm
>body is in some other country as that usually occurs via SIP.

Be that as it may, every minute you keep the call center person on the
line is a minute they are not busily scamming someone else.
Furthermore, while it is merely anecdotal, I can indeed report that
since instituting a policy of ALWAYS answering robocalls and ALWAYS
keeping them talking as long as possible, the number of such calls has
decreased markedly, from several per day to now only one every couple of
weeks / month.

Because there *is* a cost associated with robo-scams, they must keep
score in order to maximize return for the resources consumed (unlike
e-mail spam scams which have effectively no need to prune the potential
target list) you simply have to make the "cost" of dialing your
telephone more expensive that the other couple billion potential
targets.  Its like being in a group being chased by a bear.  You needn't
run faster than the bear, merely faster than the slowest in the group.

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

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

On Thursday, 19 December, 2019 19:07, Valdis Kletnieks 
wrote:

>On Thu, 19 Dec 2019 16:02:42 -0700, "Keith Medcalf" said:

>> That stupid people do stupid things has no bearing on me.  If there
is
>> a legal requirement for these people to be "notifying" then they are
>> required to notify.

>> I do not want to receive robocalls period.  End of Line.  No
Exception.
>> Ever.  For any reason.

> So... what do you recommend if it's a legally mandated robocall that
> says "shelter in place - active shooter" or "tornado alert"?

Then they can pay for the phone line to be used for that purpose.  I
will rent them the space necessary to house the phone and its
accoutrements, but I will not guantee that I will ever answer it.  That
will cost my usual rate of $750.00 per hour, with a four hour minimum,
paid in advance.  If whomever did the "legally mandating" failed to
account for the cost of their "mandating" that is not my problem.

If I am paying for the phone line then I get to choose what calls I will
accept.

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

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

This, of course, will do no good.  These so called "Robocalls" are exactly 
that.  They generate a random number to call and play the silly canned message. 
 If you press whatever the code is to talk to the idiots, they then hand off 
the call to a call center.

You should ALWAYS talk to the call center behind the robocaller.  The 
robocaller (the one playing the message) is relatively local and the cost of 
that call is minimal.  When you select to talk to the robocaller, that 
generates an international handoff to a call center in India.  This costs more 
money (it costs THEM more money).  The longer you can keep the bastards talking 
on the phone, the MORE it costs them.  It can also be quite entertaining and 
you can keep them on the line for HOURS with enough practice.

If you do this EVERY SINGLE TIME then in rather short order your telephone 
number will be fed back to the company doing the "robocalling" as a "bad 
target" and you will get no more robocalls (since there are only two or three 
companies in the whole world who run the front end for a whole shitload of 
scammers).

Conversely if you do not answer or hang up on the robo-message, you will be 
classified as an "excellent target" and you will get MORE calls.

--
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 Chad Dailey
>Sent: Thursday, 19 December, 2019 16:38
>To: nanog@nanog.org
>Subject: Re: FCC proposes $10 Million fine for spoofed robocalls
>
>Perhaps list the phone number of your representatives or your state
>attorney general's office in your domain contact info.
>
>
>On Thu, Dec 19, 2019 at 5:28 PM  > wrote:
>
>
>
>   If you want to end robocalls then every time you get one call your
>   local congress person's or senator's main phone number and say "I
>just
>   got another robocall (perhaps characterizing it like 'for auto
>   warranties' or 'for IRS fraud')".
>
>   Everyone. Every time.
>
>   --
>   -Barry Shein
>
>   Software Tool & Die| b...@theworld.com |
>http://www.TheWorld.com
>   Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>   The World: Since 1989  | A Public Information Utility | *oo*
>

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

As long as that tactical air strike uses MIRV nuclear warheads so none of the 
little f*ckers get away ...

--
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
>Jeff Shultz
>Sent: Thursday, 19 December, 2019 14:59
>To: North American Network Operators' Group 
>Subject: Re: FCC proposes $10 Million fine for spoofed robocalls
>
>On Thu, Dec 19, 2019 at 1:46 PM Rich Kulawiec  wrote:
>>
>> [ Re-sent with proper headers.  My apologies for the typo'd previous
>version. ]
>>
>> On Thu, Dec 19, 2019 at 11:34:48AM -0800, William Herrin wrote:
>> > I don't want to start an arms race with the spam callers, I want to
>> > end it. That means: jump directly to something they can't easily
>> > defeat.
>>
>> It is at this point that I am reminded of the wisdom of former FTC
>> Commissioner Orson Swindle, who was testifying before Congress on
>> the subject of spam when he said "We need a couple of good hangings
>here."
>> It was true in 2003 (which is I believe when he said it) and it's still
>> true now.  Fines, whatever they are, will be evaded and bargained down,
>> companies will be dissolved and reconstituted, money will be laundered,
>> and the problem will persist.
>>
>> ---rsk
>>
>
>I've occasionally thought that a tactical air strike on a couple of
>call centers might just convince the others of the errors of their
>ways.
>
>--
>Jeff Shultz
>
>--
>Like us on Social Media for News, Promotions, and other information!!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_ This message
>contains confidential information and is intended only for the individual
>named. If you are not the named addressee you should not disseminate,
>distribute or copy this e-mail. Please notify the sender immediately by
>e-mail if you have received this e-mail by mistake and delete this e-mail
>from your system. E-mail transmission cannot be guaranteed to be secure
>or
>error-free as information could be intercepted, corrupted, lost,
>destroyed,
>arrive late or incomplete, or contain viruses. The sender therefore does
>not accept liability for any errors or omissions in the contents of this
>message, which arise as a result of e-mail transmission. _

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

On Thursday, 19 December, 2019 14:02, Michael Homas wrote:

>There are robocalls that you want to get. Here in california, our
>wonderful electric company sends out robocalls when they are going to
>cut our electricity so they don't get blamed for burning down cities
>(and then still manage to anyway). I'm not sure if our earthquake alerts
>can robocall or not, but that would certainly be another one that you'd
>want to get. There are plenty more examples.

That stupid people do stupid things has no bearing on me.  If there is a legal 
requirement for these people to be "notifying" then they are required to 
notify.  That they chose an assinine and ineffective method of notification 
does not relieve them of their legal obligations.

I do not want to receive robocalls period.  End of Line.  No Exception.  Ever.  
For any reason.

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

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

On Thursday, 19 December, 2019 13:57, Michael Thomas wrote:

>Plus if it didn't work well/too cumbersome/etc with email, it probably
>won't be any better with voice. We have lots of experience with what
>doesn't work for email.

I really do not care.  It is my e-mail server.  It is my telephone.  I am 
paying for them.  If you wish to communicate with me you *will* comply with my 
rules.  Otherwise you can go stuff yourself.  I really do not care one way or 
the other -- except of course that if you go stuff yourself then I do not have 
to be bothered with you.

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

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

On Thursday, 19 December, 2019 12:54, Dan Hollis
 wrote:

>Fact is the telcos make lots of money off spoofed robocalls so they
have
>zero incentive to stop the practice.

That is an easy one to solve.  The telco simply needs to provide a free
"Call Screening" service that you can activate on your line such that
the telco terminates all calls with a message "Please enter  to ring the subscriber line".  No valid code,
disconnect the call.  They still get to charge a termination fee to
whomever handed the call to them.

Additional features (whitelisting/blacklisting) available for extra
charge.

>On Thu, 19 Dec 2019, Keith Medcalf wrote:
>
>>
>> "CallerID" is a misnomer.  It is actually the "Advertized ID".
>However, the telco's realized you would not pay to receive advertizing
so
>they renamed it to something they thought you would pay for.
>>
>> Pretty canny business model eh?  And apparently y'all fell for it,
>thinking it was related to the Identification of the Caller, rather
than
>being what the caller wished to advertize.
>>
>> --
>> The fact that there's a Highway to Hell but only a Stairway to Heaven
>says a lot about anticipated traffic volume.


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

RE: FCC proposes $10 Million fine for spoofed robocalls

[Keith Medcalf]

"CallerID" is a misnomer.  It is actually the "Advertized ID".  However, the 
telco's realized you would not pay to receive advertizing so they renamed it to 
something they thought you would pay for.

Pretty canny business model eh?  And apparently y'all fell for it, thinking it 
was related to the Identification of the Caller, rather than being what the 
caller wished to advertize.

--
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 Brandon Martin
>Sent: Thursday, 19 December, 2019 10:25
>To: nanog@nanog.org
>Subject: Re: FCC proposes $10 Million fine for spoofed robocalls
>
>On 12/19/19 12:09 PM, Andreas Ott wrote:
>> I have also been told that there is no equivalent of uRPF in the phone
>world.
>
>This is the biggest issue, and unfortunately (and my knowledge of the
>PSTN is admittedly a bit lacking, here), there's likely no good way to
>add it.
>
>Calls on the PSTN are routed essentially based on "who do I feel like
>handing this off to, today", and then that entity may do the same, and
>so on.  It's pretty routine for an outfit to have multiple contracts for
>termination that may not even be aware of the "legitimate" numbers from
>which their customers might "source" a call.
>
>Further, it's entirely normal and perfectly legitimate (to varying
>degrees) for an outfit to purport in CID a number that is not directly
>assigned to them nor which will actually result in a callback being
>routed to them.
>
>Think of caller ID more like reverse DNS.  It's largely advisory and,
>outside some situations where you deliberately want a higher degree of
>repuatation/identity verification and are willing to accept a
>potentially large number of false flags, there's no real reason to rely
>on it outside of human nicety.
>
>The rough analogy to the source IP address is the ANI information that's
>not even passed to most end users.  That's "who should I bill this to?".
>  But even that can get overwritten sometimes during call routing, from
>what I gather.  It's also rarely a valid callback number for any
>non-trivial call source.  Or, at least, if you did call it, the person
>who (might) answer the phone will have no idea what prompted you to do
>so.
>
>SHAKEN/STIR, the leading proposal to "fix" this, is more like RPKI in a
>way albeit very much re-envisioned based on circuit switching rather
>than packet switching.  Each intervening network can attest to what
>degree they are able to verify the CID (and maybe ANI?) information in
>the call.  Unfortunately, a perfectly valid attestation is "I cannot
>verify it", and indeed that's likely to be most of the attestations
>you'll see at least at first.  The best it really lets you do is figure
>out some networks at which to point fingers.
>
>When "full attestation" is present, i.e. the network operator has been
>able to verify that the CID field represents a number authorized for use
>by the entity originating the call, it's maybe more like DKIM in that
>you can, with cryptographic certainty, know THE network at which to
>point fingers as they're the ones who admitted the call into the PSTN
>with authority that the CID field (among others) is "valid".
>
>[And all the old PSTN folks will please forgive me if I'm inaccurate,
>here, though corrections are welcome]
>--
>Brandon Martin

RE: Gmail email blocking is off the rails (again)

[Keith Medcalf]

On Wednesday, 4 December, 2019 23:24, b...@theworld.com wrote:

>But that's ok, the new masters of this universe will just charge both
>ends for each and every email (perhaps a few included free with your
>Hulu or Netflix subscription) and old timers will talk about how great
>it was back in the old days when you could run lists like nanog for
>roughly nothing tho I don't know where they'll talk about that.

Somehow NetFlix has decided that my email address is "suddenly" invalid
(the one that has been in continuous use since the mid-80's).
Apparently the third-party that they use to send e-mail is a dirty
spammer and thus has been blacklisted.  I tried to tell then this, but
no one at NetFlix seems to have a clue, and my clue-by-four has no one
to hit over the head.

I really do no care what the Masters of the Universe think.  They can
pry my mail server and domain from my cold dead fingers, and until then,
they can shove themselves where the sun doesn't shine ...

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

RE: Disney+ Streaming

[Keith Medcalf]

On Friday, 29 November, 2019 05:43, Brandon Butterworth
 wrote:

>I'm not conviced music really learned either, once CDs are gone
>there will be little access to reasonable quality uncompressed
>downloads as everyone chases quite compressed streams.

There are quite a lot of places where you can buy DRM free lossless
audio files ranging in quality from CD (44.1 kHz/16-bit/2 channel) all
the way up to 192 kHz/32-bit/5.1 channel and beyond.  These are
basically CDs (or better) without the physical CD media and packaging.
There are also streaming services that stream in "CD" quality (lossless
44.1kHz/16-bit) or better, if you prefer that model (and can live with
the fleeting availability of the content).  There are even a few record
companies (as long as you do not want an American one) that will sell
you their entire collection of digital studio masters in lossless DRM
free format.

There is not, however, and equivalent for Video -- it is presently stuck
at the "compressed all to ratshit" video and audio level -- unless you
buy physical media and extract the data yourself.

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

RE: Iran cuts 95% of Internet traffic

[Keith Medcalf]

>"Internet penetration and complexity has vastly grown in Iran
>over the past decade, but the country’s users still connect
>to the global network through just two gateways. Both are
>controlled by the regime, and can be blocked when it chooses."
>
>"Access to the internet is gradually being restored in Iran
>after an unprecedented five-day shutdown that cut its population
>off from the rest of the world and suppressed news of the
>deadliest unrest since the country’s 1979 revolution."

Gradually?  How long does it take to plug in a network connection and converge 
BGP?

Like most things it is a matter of motivation.  A gun held to the head will 
change "gradually" into "instantly" ... it can also change "instantly" into 
"gradually over the next week" depending on the requirements of he who holds 
the gun.

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

RE: New Alaskan Network

[Keith Medcalf]

Bwahahahaha!

It is internally inconsistent.  Perhaps this is just shoddy reporting,
or perhaps the whole thing is just someone's idea of a wet dream.

"The line will begin in North Pole, Alaska and will travel through
Canada, connecting with Canadian carriers, where it will finally connect
with “any major hub” in the US"

"According to the press release, only internet traffic that both
originates and terminates in the US will be carried over the network."

Questions:

(1) Why interconnect with Canadian Carriers at all?
(2) "Any major hub"?
(3) Only traffic originated and terminated in the US.

Given (3) then (1) is a useless waste of money.
Given (2) it would appear that this is a "fibre to nowhere"
Given (3) it would not provide access to the Internet

--
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 Rod Beck
>Sent: Friday, 25 October, 2019 11:57
>To: Nanog@nanog.org
>Subject: New Alaskan Network
>
>Unusual in that it will traverse Canada to reach the lower 48.
>
>
>https://www.theverge.com/2019/5/1/18525866/alaska-fiber-optic-network-
>cable-continental-us-100-terabit
>
>
cable-continental-us-100-terabit>
>Alaska will connect to the rest of the US via a 100-terabit fiber optic
>network - The Verge fiber-optic-network-cable-continental-us-100-terabit>
>MTA Fiber Holdings announced today that it would build the "first and
>only all-terrestrial" fiber optic network running from Alaska and into
>the Lower 48. The line will begin in North Pole, Alaska ...
>www.theverge.com
>
>
>
>Roderick Beck
>
>VP of Business Development
>
>United Cable Company
>
>www.unitedcablecompany.com 
>
>New York City & Budapest
>
>
>rod.b...@unitedcablecompany.com
>
>36-70-605-5144
>
>
>
>
>
>

RE: Unable to email anyone from my primary domain name; thanks Google Mail and G Suite.

[Keith Medcalf]

On Wednesday, 23 October, 2019 18:36, Brandon Applegate  
wrote:

>Bigger picture, I think that (unfortunately) we will see more and more
>problems like this.  With the large providers running so much (as you
>mentioned - “monoculture”), and their services tending toward the “black
>box” ... I don’t know what the answer is.

DNUESTTM (Do Not Use Entertainment Systems for Things That Matter)

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

RE: BGP over TLS

[Keith Medcalf]

On Tuesday, 22 October, 2019 13:26, Jared Mauch 
wrote:

>No,

>> On Oct 22, 2019, at 2:08 PM, Keith Medcalf 
wrote:

>> At this point further communications are encrypted and secure against
>>eavesdropping.

>The problem isn't the protocol being eavesdropped on. The data is
already
>published publicly by many people.

>The problem is one of mutual authentication and authorization of the
>transport.

I see.  It is an AIC problem, not a CIA problem.  TLS in its default
usage is a CIA thing because, well, it was designed to solve CIA
problems where even temporary secrecy is more important than being down
for a week.  As had been pointed out though, TLS does allow for non-CIA
configuration and usage such as by using PSK or fingerprint
authentication.  SSH is also an AIC thing.  It solves the problem by
recording the fingerprint on first connect and alarming if the
fingerprint is not subsequently what was expected.  Cannot TLS be
configured to do the same thing bidirectionally?

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

RE: BGP over TLS

[Keith Medcalf]

>TLS in the traditional sense 'requires' that there be an X.509
>certificate to use in authenticating (and to some extent authorizing -
>can you be a CA? sign email? etc...) endpoints, ideally you do 'tls
>mutual authentication'...

That is incorrect.

I believe that an endpoint (lets call it Alice) can connect to another endpoint 
(lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a 
secret key between us".  "Yokkely dokelly", says Bob, "Lets do that".  They 
then exchange some stuff to and fro and then Alice says "Righty then, lets 
encrypt!" and Bob says, "Yabba Doodle Doo".

At this point further communications are encrypted and secure against 
eavesdropping.  Alice still has no idea who she is talking to (other than it is 
the dude that picked up the phone), and Bob has no idea who he is talking too 
other than the fact it is whoever rang him up.

The Security part in Transport Layer Security is Encryption.  Authentication is 
lathered on top as an afterthought and requires external measures be taken in 
order to have *any* effect whatsoever.

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

RE: BGP over TLS

[Keith Medcalf]

On Monday, 21 October, 2019 09:44, Robert McKay  wrote:

>On 2019-10-21 16:30, Keith Medcalf wrote:

>> Why do you need to do anything?  TLS is Transport Layer Security and
>> it's sole purpose is to protect communications from eavesdropping or
>> modification by wiretappers on/in the line between points A and B.
>> MD5 in BGP is used for authentication (rudimentary, but authentication
>> nonetheless).

>> Why cannot one just put the MD5 authenticated connection inside a TLS
>> connection?  What is the advantage to be gained by replacing the
>> authentication mechanism with weaker certificate authentication method
>> available with TLS?

>The MD5 authentication is built into TCP options.. not obvious how you
>would transport it over TLS which afaik doesn't offer similar
>functionality.

AHA!  I understand now and sit corrected.  I was under the mistaken impression 
that MD5 authentication was an application level thing, not a TCP level thing.

>You'd probably have to basically tunnel TCP frames inside TLS, which
>doesn't really sound ideal (reimplement TCP in userspace?)

>Either that or maybe use some other simpler MD5 based authentication
>(unrelated to the TCP implementation currently used in BGP).. but then
>that raises lots of questions like why even use MD5.

You are correct.  There is no point in using or moving the current MD5 
authentication method when it can just be "turned off" and some (perhaps better 
alternate) authentication method used as provided by the TLS wrapper.  This of 
course presumes that if one turns off MD5 that the additional TCP option header 
is not used ...

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

RE: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")

[Keith Medcalf]

>On 21/10/19 6:30 pm, Bjørn Mork wrote:

>> Yes, and I really like Julien's proposal.  It even looks pretty
>> complete.  There are just a few details missing around how to make the
>> MD5 => TLS transition smooth.

>At least for those systems that run on Linux (which is most all of the
>major's except Juniper) I suspect if we went to the relevant kernel folk
>with a clear plan on how handling TCP-MD5 in a way that would make
>transitions much easier they'd listen.

Why do you need to do anything?  TLS is Transport Layer Security and it's sole 
purpose is to protect communications from eavesdropping or modification by 
wiretappers on/in the line between points A and B.  MD5 in BGP is used for 
authentication (rudimentary, but authentication nonetheless).

Why cannot one just put the MD5 authenticated connection inside a TLS 
connection?  What is the advantage to be gained by replacing the authentication 
mechanism with weaker certificate authentication method available with TLS?

--
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 Sunday, 20 October, 2019 06:08, Bjørn Mork  wrote:

>Hank Nussbacher  writes:

>> Centralized Internet routing - sounds like DoH for BGP.

>Great idea!  Why don't we just run BGP over HTTPS?  Everyone already has
>a browser, so we can get rid of all these expensive routers.

>The future is BoH

And that is just one letter short of the BOFH ...

--
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 plan, limiting that
&g

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]

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

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: 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.

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: 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.

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 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 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 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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]

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 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.