Re: plea for comcast/sprint handoff debug help

2020-11-05 Thread Christopher Morrow
I hate to jump in late. but... :)

After reading this a few times it seems like what's going on is:
  o a set of assumptions were built into the software stack
 this seems fine, hard to build with some assumptions :)

  o the assumptions seem to include: "if rrdp fails  feel free
to jump back/to rsync"
I think SOME of the problem is the 'how' there.
Admittedly someone (randy) injected a pretty pathological failure
mode into the system
and didn't react when his 'monitoring' said: "things are broke yo!"

  o absent a 'failure' the software kept on getting along as it had before.
Afterall, maybe the operator here intentionally put their
repository into this whacky state?
How is an RP software stack supposed to know what the PP's
management is meaning to do?

  o lots of debate about how we got to where we are, I don't know that
much of it is really helpful.

I think a way forward here is to offer a suggestion for the software
folk to cogitate on and improve?
   "What if (for either rrdp or rsync) there is no successful
update[0] in X of Y attempts,
   attempt the other protocol to sync down to bring the remote PP back
to life in your local view."

This both allows the RP software to pick their primary path (and stick
to that path as long as things work) AND
helps the PP folk recover a bit quicker if their deployment runs into troubles.

0: I think 'failure' here is clear (to me):
1) the protocol is broken (rsync no connect, no http connect)
2) the connection succeeds but there is no sync-file (rrdp) nor
valid MFT/CRL

The 6486-bis rework effort seems to be getting to: "No MFT? no CRL?
you r busted!"
so I think if you don't get MFT/CRL in X of Y attempts it's safe to
say the PP over that protocol is busted,
and attempting the other proto is acceptable.

thanks!
-chris

On Mon, Nov 2, 2020 at 4:37 AM Job Snijders  wrote:
>
> On Mon, Nov 02, 2020 at 09:13:16AM +0100, Tim Bruijnzeels wrote:
> > On the other hand, the fallback exposes a Malicious-in-the-Middle
> > replay attack surface for 100% of the prefixes published using RRDP,
> > 100% of the time. This allows attackers to prevent changes in ROAs to
> > be seen.
>
> This is a mischaracterization of what is going on. The implication of
> what you say here is that RPKI cannot work reliably over RSYNC, which is
> factually incorrect and an injustice to all existing RSYNC based
> deployment. Your view on the security model seems to ignore the
> existence of RPKI manifests and the use of CRLs, which exist exactly to
> mitigate replays.
>
> Up until 2 weeks ago Routintar indeed was not correctly validating RPKI
> data, fortunately this has now been fixed:
> https://mailman.nanog.org/pipermail/nanog/2020-October/210318.html
>
> Also via the RRDP protocol old data be replayed, because because just
> like RSYNC, the RRDP protocol does not have authentication. When RPKI
> data is transported from Publication Point (RP) to Relying Party, the RP
> cannot assume there was an unbroken 'chain of custody' and therefor has
> to validate all the RPKI signatures.
>
> For example, if a CDN is used to distribute RRDP data, the CDN is the
> MITM (that is literally what CDNs are: reverse proxies, in the middle).
> The CDN could accidentally serve up old (cached) content or misserve
> current content (swap 2 filenames with each other).
>
> > This is a tradeoff. I think that protecting against replay should be
> > considered more important here, given the numbers and time to fix
> > HTTPS issue.
>
> The 'replay' issue you perceive is also present in RRDP. The RPKI is a
> *deployed* system on the Internet and it is important for Routinator to
> remain interopable with other non-nlnetlabs implementations.
>
> Routinator not falling back to rsync does *not* offer a security
> advantage, but does negatively impact our industry's ability to migrate
> to RRDP. We are in 'phase 0' as described in Section 3 of
> https://tools.ietf.org/html/draft-sidrops-bruijnzeels-deprecate-rsync
>
> Regards,
>
> Job


Re: BGP Peers Data modeling schema

2020-11-05 Thread Christopher Morrow
On Thu, Nov 5, 2020 at 4:27 PM Christopher Morrow
 wrote:
>
> 1) I shot myself in the foot .. the meeting data I cared about is
> directly available on www.nanog.org (or the link  to it anyway)
>
> 2) I meant feb 2020 (which SEEMS like 1.5yrs ago? or 100.5 yrs ago? :)
> ) and meeting 78:
> https://www.nanog.org/meetings/nanog-78/
> specifically this talk: https://youtu.be/DpO1Tfa4IZ4
> I guess amin's talk didn't have a presentation deck saved :(
> Actually the presentation I wanted was not Amin, but Bikash:
>  https://youtu.be/f2Pe0SHmgyo?list=PLO8DR5ZGla8jSzWlrWt_cz13LLAz44rHY
> (link to where he talks about this)
>   (I dont' see his slides included in the presentation data either though)

It was pointed out to me that perhaps these 2 links may also provide some help:
  https://www.usenix.org/conference/nsdi20/presentation/mogul - an
overview... (the link to the paper is here too)
  
https://www.usenix.org/sites/default/files/conference/protected-files/nsdi20_slides_mogul.pdf
- jeff's slideware

>
> 3) yang, sure.
>
> On Thu, Nov 5, 2020 at 1:43 PM Christopher Morrow
>  wrote:
> >
> > On Thu, Nov 5, 2020 at 7:55 AM Douglas Fischer  
> > wrote:
> > >
> > > I'm designing a tool for provisioning configurations for an ITP and his 
> > > Peers.
> > > The idea is that based on that, all the configs to all the involved 
> > > components configurations to be deployed based on that source of data. 
> > > I'm Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc...
> > >
> > > But, once again, I'm feeling that I'm reinventing the wheel.
> > > I'm pretty sure that someone else has already suffered from that.
> > >
> >
> > you might go digging at Amin Vahadat's presentation at nanog-sfo ~1.5
> > yrs back... (keynote I think it was? nanog75 perhaps)
> > I can't seem to search the presentation archive properly (or at all,
> > nanog webmaster mail sent already about this), but ideally the
> > presentation and video is helpful.
> >
> > > I search for a bit, and I didn't find anything...
> > > But with this gray area between developers and network operators, I'm not 
> > > sure if I'm looking at the right place.
> > >
> > > I even tried to look at http://schema.org but didn't find anything 
> > > related to networks and BGP there yet.
> > >
> > >
> > > So, anyone could point me in the right direction?
> > > --
> > > Douglas Fernando Fischer
> > > Engº de Controle e Automação


Re: BGP Peers Data modeling schema

2020-11-05 Thread Christopher Morrow
1) I shot myself in the foot .. the meeting data I cared about is
directly available on www.nanog.org (or the link  to it anyway)

2) I meant feb 2020 (which SEEMS like 1.5yrs ago? or 100.5 yrs ago? :)
) and meeting 78:
https://www.nanog.org/meetings/nanog-78/
specifically this talk: https://youtu.be/DpO1Tfa4IZ4
I guess amin's talk didn't have a presentation deck saved :(
Actually the presentation I wanted was not Amin, but Bikash:
 https://youtu.be/f2Pe0SHmgyo?list=PLO8DR5ZGla8jSzWlrWt_cz13LLAz44rHY
(link to where he talks about this)
  (I dont' see his slides included in the presentation data either though)

3) yang, sure.

On Thu, Nov 5, 2020 at 1:43 PM Christopher Morrow
 wrote:
>
> On Thu, Nov 5, 2020 at 7:55 AM Douglas Fischer  
> wrote:
> >
> > I'm designing a tool for provisioning configurations for an ITP and his 
> > Peers.
> > The idea is that based on that, all the configs to all the involved 
> > components configurations to be deployed based on that source of data. I'm 
> > Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc...
> >
> > But, once again, I'm feeling that I'm reinventing the wheel.
> > I'm pretty sure that someone else has already suffered from that.
> >
>
> you might go digging at Amin Vahadat's presentation at nanog-sfo ~1.5
> yrs back... (keynote I think it was? nanog75 perhaps)
> I can't seem to search the presentation archive properly (or at all,
> nanog webmaster mail sent already about this), but ideally the
> presentation and video is helpful.
>
> > I search for a bit, and I didn't find anything...
> > But with this gray area between developers and network operators, I'm not 
> > sure if I'm looking at the right place.
> >
> > I even tried to look at http://schema.org but didn't find anything related 
> > to networks and BGP there yet.
> >
> >
> > So, anyone could point me in the right direction?
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação


Re: Technology risk without safeguards

2020-11-05 Thread Sabri Berisha
- On Nov 5, 2020, at 5:58 AM, Tom Beecher  wrote: 

Hi,

>> The parts that Tom cited, are very much relevant, and only reinforce the
>> notion that at this time, we simply do not know enough. We do know, that
>> at the low doses we generally receive, there is no evidence for harmful
>> consequences.

> This is a gross mischaracterization, and I would go so far to say patently
> incorrect.

Well, from the parts you quoted yourself, cut and paste from your email:

- "it’s not clear how RF radiation might be able to cause cancer."
- "the results of these types of studies have not provided clear answers so 
far."
- "this is still an area of research."
- "these studies had strengths, they also had limitations that make it hard to
   know how they might apply to humans"
- "(ICNIRP) determined that the limitations of the studies didn’t allow
   conclusions to be drawn regarding the ability of RF energy to cause cancer."

Which part of that is patently incorrect?

Again, I'm not saying anything regarding the actual topic itself, I'm not an 
expert in that field.

> His findings go into the pile with all the other findings, and they get 
> properly
> evaluated.

Exactly. That how science works. Glad you understand it. You evaluate the data, 
instead of dismissing the doctor as some kind of QAnon conspiracy theorist.

And that was the whole point of my post. I never made any assertion with regards
to whether or not the hypothesis was correct. I merely quoted resources which
indicated that more research was needed.

Thanks,

Sabri




Re: Verizon or Verizon Wireless contact

2020-11-05 Thread Mike Hammett
https://puck.nether.net/mailman/listinfo/voiceops 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Jeff Shultz"  
To: "North American Network Operators' Group"  
Sent: Thursday, November 5, 2020 2:26:25 PM 
Subject: Verizon or Verizon Wireless contact 


Looking for a contact with a clue at Verizon/Wireless who can help me with a 
problem, to wit, Verizon is blocking calls from our landline customers to one 
of their local wireless prefixes. We've got the error that the Verizon switch 
gives ("Welcome to Verizon your call can not be completed as dialed. 
Announcement for switch 3 0 dash 2.) 


Any publicly available numbers or tech support just leads me in circles. I 
figure if I keep at it long enough, I'll collect the whole set of their toll 
free numbers... but I'd prefer not to. 


Thanks! 


-- 





Jeff Shultz 

Central Office Technician 
SCTC 
(503) 769-2125 
Go Big Ask for Gig 
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. *** 


Verizon or Verizon Wireless contact

2020-11-05 Thread Jeff Shultz
Looking for a contact with a clue at Verizon/Wireless who can help me with
a problem, to wit, Verizon is blocking calls from our landline customers to
one of their local wireless prefixes. We've got the error that the Verizon
switch gives ("Welcome to Verizon your call can not be completed as dialed.
Announcement for switch 3 0 dash 2.)

Any publicly available numbers or tech support just leads me in circles. I
figure if I keep at it long enough, I'll collect the whole set of their
toll free numbers... but I'd prefer not to.

Thanks!

-- 
Jeff Shultz
Central Office Technician
SCTC
(503) 769-2125
Go Big  Ask for Gig

-- 
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: BGP Peers Data modeling schema

2020-11-05 Thread David Bass
I second Jeff in using YANG.

On Thu, Nov 5, 2020 at 1:37 PM Jeff Tantsura 
wrote:

> YANG is the right direction.
> OpenConfig BGP and policy models are supported by every vendor on the
> earth.
> We are finalizing IETF BGP and policy models
> draft-ietf-rtgwg-policy-model is about to be last-called
> draft-ietf-idr-bgp-model is pretty much ready
>
> Cheers,
> Jeff
> On Nov 5, 2020, 4:57 AM -0800, Douglas Fischer ,
> wrote:
>
> I'm designing a tool for provisioning configurations for an ITP and his
> Peers.
> The idea is that based on that, all the configs to all the involved
> components configurations to be deployed based on that source of data. I'm
> Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc...
>
> But, once again, I'm feeling that I'm reinventing the wheel.
> I'm pretty sure that someone else has already suffered from that.
>
> I search for a bit, and I didn't find anything...
> But with this gray area between developers and network operators, I'm not
> sure if I'm looking at the right place.
>
> I even tried to look at http://schema.org but didn't find anything
> related to networks and BGP there yet.
>
>
> So, anyone could point me in the right direction?
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>


Re: BGP Peers Data modeling schema

2020-11-05 Thread Jeff Tantsura
YANG is the right direction.
OpenConfig BGP and policy models are supported by every vendor on the earth.
We are finalizing IETF BGP and policy models
draft-ietf-rtgwg-policy-model is about to be last-called
draft-ietf-idr-bgp-model is pretty much ready

Cheers,
Jeff
On Nov 5, 2020, 4:57 AM -0800, Douglas Fischer , 
wrote:
> I'm designing a tool for provisioning configurations for an ITP and his Peers.
> The idea is that based on that, all the configs to all the involved 
> components configurations to be deployed based on that source of data. I'm 
> Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc...
>
> But, once again, I'm feeling that I'm reinventing the wheel.
> I'm pretty sure that someone else has already suffered from that.
>
> I search for a bit, and I didn't find anything...
> But with this gray area between developers and network operators, I'm not 
> sure if I'm looking at the right place.
>
> I even tried to look at http://schema.org but didn't find anything related to 
> networks and BGP there yet.
>
>
> So, anyone could point me in the right direction?
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação


Re: BGP Peers Data modeling schema

2020-11-05 Thread Christopher Morrow
On Thu, Nov 5, 2020 at 7:55 AM Douglas Fischer  wrote:
>
> I'm designing a tool for provisioning configurations for an ITP and his Peers.
> The idea is that based on that, all the configs to all the involved 
> components configurations to be deployed based on that source of data. I'm 
> Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc...
>
> But, once again, I'm feeling that I'm reinventing the wheel.
> I'm pretty sure that someone else has already suffered from that.
>

you might go digging at Amin Vahadat's presentation at nanog-sfo ~1.5
yrs back... (keynote I think it was? nanog75 perhaps)
I can't seem to search the presentation archive properly (or at all,
nanog webmaster mail sent already about this), but ideally the
presentation and video is helpful.

> I search for a bit, and I didn't find anything...
> But with this gray area between developers and network operators, I'm not 
> sure if I'm looking at the right place.
>
> I even tried to look at http://schema.org but didn't find anything related to 
> networks and BGP there yet.
>
>
> So, anyone could point me in the right direction?
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação


Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
Sir, I too believe in taking a low profile approach, but the irony is that
those in academia who I have appoached that do recognize this gap in
safeguards are reticent to take up this topic since it involves research
intersecting with negative actors.

I do not wish to take more time from this group beyond what has been
offered am all ears to being introduced to an intrepid epidemiology
researcher/academic institution who would consider to review the safeguards
I propose.

Regards,
Suresh

On Thursday, November 5, 2020, Alain Hebert  wrote:

> Well,
>
> I'm just saying...
>
> Speculating about "how to/was harm", on an open forum, is a good
> way to help design "scenarios" that can be abused by bad actors.  It would
> be better to address it in an academia setting.
>
> *Now* if you're looking for worker safety, surely your local
> jurisdiction have a compliance body able to provide best practices to
> protect the workers.  I hate to bring RFC1149 again, but those high power
> microwave antenna are hell on packet drops on that medium.
>
> PS: From my experiences with 2 .com about a FPGA Based Firewall and a
> FIPS-140 Encryption Network Card.  And my associate ~15y in the RF radio
> industry.
>
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.50 boul. St-Charles 
> 
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
> On 11/5/20 10:22 AM, Suresh Kalkunte wrote:
>
> > Can you provide a case where this may
> > have happened?
> >
> As you mention, a normal operational scenario finds powerful RF on the
> rooftop. My concern is an abnormal scenario where powerful RF is used to
> sabotage an electronic equipment or human. Magnetron + horn antenna
> (forgive me for using this as an example a few times so far) for instance
> is capable of significant harm. If I mention, I have been victimized, at
> present we do not have the diagnostic/forensic tests (forensic DNA
> scientists at the NIST can be contacted to verify) to prove intentional
> harm from powerful EMF  has occurred.
>
> My motivation to bring this topic for discussion is to make aware of the
> unlimited risk _if_ someone chooses to use powerful EMF as a method of
> sabotage. I do not relish to discuss this, but I remember reading on NANOG
> some 20-25 years ago, I paraphrase 'those with anti-social intentions do
> not publish papers'.
>
> Regards,
> Suresh
>
>
> On Thursday, November 5, 2020,  wrote:
>
>> To that end, anyone working around RF should be properly trained and use
>> the safety tools provided them, they should be fine.  If an untrained
>> individual does something and gets hurt with high power RF, it is
>> unfortunate and happens all too often because of people thinking that the
>> worst case things don’t happen to them…
>>
>>
>>
>> Can you provide a case where this may have happened?  Any RF in a Data
>> Center should be on the roof, and isolated from the room at all times.
>> This is standard practice in every RF data room we’ve ever been in, whether
>> it be commercial or Government.
>>
>>
>>
>>
>> Regards,
>>
>> Nathan Babcock
>>
>>
>>
>> *From:* NANOG  *On
>> Behalf Of *Alain Hebert
>> *Sent:* Wednesday, November 4, 2020 10:32 AM
>> *To:* nanog@nanog.org
>> *Subject:* Re: Technology risk without safeguards
>>
>>
>>
>> Maybe someone is just looking for "inspiration".
>>
>> There is other venues to work this out "safely", IMHO.
>>
>> -
>>
>> Alain Hebertaheb...@pubnix.net
>>
>> PubNIX Inc.
>>
>> 50 boul. St-Charles 
>> 
>>
>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>>
>> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>>
>> On 11/4/20 12:24 PM, Matt Harris wrote:
>>
>> Matt Harris​
>>
>> |
>>
>> Infrastructure Lead Engineer
>>
>> 816‑256‑5446
>>
>> |
>>
>> Direct
>>
>> *Looking for something?*
>>
>> *Helpdesk Portal *
>>
>> |
>>
>> *Email Support *
>>
>> |
>>
>> *Billing Portal *
>>
>> We build and deliver end‑to‑end IT solutions.
>>
>> On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte 
>> wrote:
>>
>> Hello,
>>
>>
>>
>> I believe the below described method of causing intentional (1) damage to
>> equipment in data centers and (2) physical injury to a person at the
>> workplace is on-topic for the NANOG community, if not, I look forward to
>> your feedback. As a software developer who has subscribed to the NANOG
>> mailing list for a number of years, I post this note relying on
>> intellectual honesty that I have had the opportunity to observe since
>> 1996-97.
>>
>>
>>
>> The below described technology risk is applicable to
>> computing/communication equipment rendered vulnerable by Intentional
>> Electromagnetic Interference (jamming a

Re: Technology risk without safeguards

2020-11-05 Thread William Herrin
On Thu, Nov 5, 2020 at 5:59 AM Tom Beecher  wrote:
> Let's say roughly half of the science says the hypothesis is false, and half 
> says it is true. It is absolutely fair in this case to state "We don't know 
> enough."

Hi Tom,

Strictly speaking, if a hypothesis is disproven by even one repeatable
experiment then the hypothesis is disproven. It doesn't rule out that
a similar hypothesis could be true but that particular one is false.

Suresh's case can also be dismissed with Security 101: never spend
more protecting an asset than the value of the asset. Practically
speaking this means you assign a risk cost to a particular kind of
attack and then consider whether there are any protections from the
attack which cost less than the risk. That's Vulnerability * Threat *
Incident Cost.

The vulnerability to someone tunnelling under your data center to set
up an RF generator is not high. The logistics of such an effort are
very complicated and the inverse square law dictates that the power in
an RF signal deteriorates quickly with distance even in free air, let
alone with ground between you and the recipient. It is, in a nutshell,
impractical.

The threat for someone tunnelling under your data center to set up an
RF generator is basically zero. There are examples of tunnelling in
crime and war but both involve clandestinely overcoming a superior
force, such as breaking someone out of prison, evading detection by
authorities when smuggling or destroying a fortified military position
with explosives. There is no superior force guarding a data center.
Following staff home and picking them off with a rifle is so much
cheaper and carries a better probability of success.

Nearly zero times zero times some possibly high incident cost still
equals zero. The risk-cost from Suresh's scenario is zero. Hence the
security efforts it justifies are zero.

Regards,
Bill Herrin

-- 
Hire me! https://bill.herrin.us/resume/


Re: Technology risk without safeguards

2020-11-05 Thread Alain Hebert

    Well,

    I'm just saying...

        Speculating about "how to/was harm", on an open forum, is a 
good way to help design "scenarios" that can be abused by bad actors.  
It would be better to address it in an academia setting.


    *Now* if you're looking for worker safety, surely your local 
jurisdiction have a compliance body able to provide best practices to 
protect the workers.  I hate to bring RFC1149 again, but those high 
power microwave antenna are hell on packet drops on that medium.


    PS: From my experiences with 2 .com about a FPGA Based Firewall and 
a FIPS-140 Encryption Network Card.  And my associate ~15y in the RF 
radio industry.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 11/5/20 10:22 AM, Suresh Kalkunte wrote:

> Can you provide a case where this may
> have happened?
>
As you mention, a normal operational scenario finds powerful RF on the 
rooftop. My concern is an abnormal scenario where powerful RF is used 
to sabotage an electronic equipment or human. Magnetron + horn antenna 
(forgive me for using this as an example a few times so far) for 
instance is capable of significant harm. If I mention, I have been 
victimized, at present we do not have the diagnostic/forensic tests 
(forensic DNA scientists at the NIST can be contacted to verify) to 
prove intentional harm from powerful EMF  has occurred.


My motivation to bring this topic for discussion is to make aware of 
the unlimited risk _if_ someone chooses to use powerful EMF as a 
method of sabotage. I do not relish to discuss this, but I remember 
reading on NANOG some 20-25 years ago, I paraphrase 'those with 
anti-social intentions do not publish papers'.


Regards,
Suresh


On Thursday, November 5, 2020, > wrote:


To that end, anyone working around RF should be properly trained
and use the safety tools provided them, they should be fine.  If
an untrained individual does something and gets hurt with high
power RF, it is unfortunate and happens all too often because of
people thinking that the worst case things don’t happen to them…

Can you provide a case where this may have happened?  Any RF in a
Data Center should be on the roof, and isolated from the room at
all times.  This is standard practice in every RF data room we’ve
ever been in, whether it be commercial or Government.


Regards,

Nathan Babcock

*From:* NANOG mailto:sswireless@nanog.org>> *On Behalf Of *Alain Hebert
*Sent:* Wednesday, November 4, 2020 10:32 AM
*To:* nanog@nanog.org 
*Subject:* Re: Technology risk without safeguards

    Maybe someone is just looking for "inspiration".

    There is other venues to work this out "safely", IMHO.

-

Alain Hebert aheb...@pubnix.net  


PubNIX Inc.

50 boul. St-Charles  


P.O. Box 26770 Beaconsfield, Quebec H9W 6G7

Tel: 514-990-5911http://www.pubnix.net       Fax: 
514-990-9443

On 11/4/20 12:24 PM, Matt Harris wrote:



Matt Harris​



|



Infrastructure Lead Engineer

816‑256‑5446



|



Direct

*Looking for something?*

_*Helpdesk Portal* _



|



_*Email Support* _



|



_*Billing Portal* _



We build and deliver end‑to‑end IT solutions.

On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte
mailto:sskalku...@gmail.com>> wrote:

Hello,

I believe the below described method of causing
intentional (1) damage to equipment in data centers and
(2) physical injury to a person at the workplace is
on-topic for the NANOG community, if not, I look forward
to your feedback. As a software developer who has
subscribed to the NANOG mailing list for a number of
years, I post this note relying on intellectual honesty
that I have had the opportunity to observe since 1996-97.

The below described technology risk is applicable to
computing/communication equipment rendered vulnerable by
Intentional Electromagnetic Interference (jamming an
electronic device) and the risk of health sabotage
affecting people (jamming a human) managing the Internet
infrastructure enabled by intentional application of
powerful rad

Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
> Can you provide a case where this may
> have happened?
>
As you mention, a normal operational scenario finds powerful RF on the
rooftop. My concern is an abnormal scenario where powerful RF is used to
sabotage an electronic equipment or human. Magnetron + horn antenna
(forgive me for using this as an example a few times so far) for instance
is capable of significant harm. If I mention, I have been victimized, at
present we do not have the diagnostic/forensic tests (forensic DNA
scientists at the NIST can be contacted to verify) to prove intentional
harm from powerful EMF  has occurred.

My motivation to bring this topic for discussion is to make aware of the
unlimited risk _if_ someone chooses to use powerful EMF as a method of
sabotage. I do not relish to discuss this, but I remember reading on NANOG
some 20-25 years ago, I paraphrase 'those with anti-social intentions do
not publish papers'.

Regards,
Suresh


On Thursday, November 5, 2020,  wrote:

> To that end, anyone working around RF should be properly trained and use
> the safety tools provided them, they should be fine.  If an untrained
> individual does something and gets hurt with high power RF, it is
> unfortunate and happens all too often because of people thinking that the
> worst case things don’t happen to them…
>
>
>
> Can you provide a case where this may have happened?  Any RF in a Data
> Center should be on the roof, and isolated from the room at all times.
> This is standard practice in every RF data room we’ve ever been in, whether
> it be commercial or Government.
>
>
>
>
> Regards,
>
> Nathan Babcock
>
>
>
> *From:* NANOG  *On Behalf
> Of *Alain Hebert
> *Sent:* Wednesday, November 4, 2020 10:32 AM
> *To:* nanog@nanog.org
> *Subject:* Re: Technology risk without safeguards
>
>
>
> Maybe someone is just looking for "inspiration".
>
> There is other venues to work this out "safely", IMHO.
>
> -
>
> Alain Hebertaheb...@pubnix.net
>
> PubNIX Inc.
>
> 50 boul. St-Charles 
> 
>
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
> On 11/4/20 12:24 PM, Matt Harris wrote:
>
> Matt Harris​
>
> |
>
> Infrastructure Lead Engineer
>
> 816‑256‑5446
>
> |
>
> Direct
>
> *Looking for something?*
>
> *Helpdesk Portal *
>
> |
>
> *Email Support *
>
> |
>
> *Billing Portal *
>
> We build and deliver end‑to‑end IT solutions.
>
> On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte 
> wrote:
>
> Hello,
>
>
>
> I believe the below described method of causing intentional (1) damage to
> equipment in data centers and (2) physical injury to a person at the
> workplace is on-topic for the NANOG community, if not, I look forward to
> your feedback. As a software developer who has subscribed to the NANOG
> mailing list for a number of years, I post this note relying on
> intellectual honesty that I have had the opportunity to observe since
> 1996-97.
>
>
>
> The below described technology risk is applicable to
> computing/communication equipment rendered vulnerable by Intentional
> Electromagnetic Interference (jamming an electronic device) and the risk of
> health sabotage affecting people (jamming a human) managing the Internet
> infrastructure enabled by intentional application of powerful
> radiofrequency fields (RF) emitted by re-purposed components salvaged from
> a kitchen heating appliance (Magnetron) or from an outdoor high gain/power
> Line of sight transceiver (unidirectional microwave radio) which has a harm
> causing range up to 25 meters (estimated using a Spectral Power Density
> calculator like www.hintlink.com/power_density.htm).
>
>
>
> This risk from mis-application of powerful RF is from human operated or
> IoT apparatus** with an avenue of approch from (a) subterrain placement
> aided by a compact/mini directional horizontal drilling machine (eg.
> principle of placing a stent in the heart) and/or (b) strategic placement
> in an obscure over-surface location to maximize negative impact on the
> target of opportunity.
>
>
>
> With building materials or ground offer insufficient* protection to block
> the passage of powerful RF and the absence of diagnostic/forensic tests to
> detect biomarkers expressed post-overexposure to harmful RF  (combination
> of RF frequency, Spectral Power Density/Specific Absorption Rate incident
> on a person and duration of exposure), intentional damage to electronic
> equipment and people is at present unrestricted.
>
>
>
> The purpose of bringing this method of exploting technology to your
> attention is with an interest to build the momentum for ushering in the
> much needed safeguards in this context.
>
>
>
> While I'm a bit confused as to what this message is trying to ultimately
> get at, it should be noted that folks who work with RF communications
> equipment and othe

Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
> ...who THINKS he MIGHT have identified
> something to the contrary does not instantly
> disqualify the thousands of studies that have
> already been completed on the topic
>
I am not a doctor. The majority of results you refer to is equivalent to
the Sun' impact on human situated on Earth's surface (benign RF).
Unfortunately, there is no research to demonstrate potent RF's impact on
human which is equivalent to Sun' impact on human in outer space except for
reporting the rare accidental occupational overexposure scenarios.

Exposure to powerful RF (eg. Magnetron + horn antenna) is no different from
pressured water coming from a fire hydrant or coming from welding torch.
EMF is invisible giving room for underestimating its powerful embodiment
while water and flame are visible to give us a clue to head for safety.


On Thursday, November 5, 2020, Tom Beecher  wrote:

> The parts that Tom cited, are very much relevant, and
>> * only reinforce thenotion that at this time, we simply do not know
>> enough.* We do know, that
>> at the low doses we generally receive, there is no evidence for harmful
>> consequences.
>>
>> My point is that we should not dismiss the physician who thought that he
>> may have found something, as some kind of conspiracist. That's not how
>> scientific progress is achieved.
>>
>
>  This is a gross mischaracterization, and I would go so far to say
> patently incorrect.
>
> Assert a general hypothesis of "Does X increase the chance of Y to
> occur?", and a sufficient amount of science is done.
>
> Let's say roughly half of the science says the hypothesis is false, and
> half says it is true. It is absolutely fair in this case to state "We don't
> know enough."
>
> However, let's say that 95% of the science says the hypothesis is false,
> and 5% says it is true. We DO know enough in this case to state with
> reasonable certainty that X does not increase the chance of Y. The
> description then is "Although we cannot absolutely rule it out, we so far
> find no evidence that X causes Y." Then, we go back and do more science
> based on what we have learned so far, and learn some more.
>
> One doctor, who THINKS he MIGHT have identified something to the contrary
> does not instantly disqualify the thousands of studies that have already
> been completed on the topic. His findings go into the pile with all the
> other findings, and they get properly evaluated. An easy analogy : If you
> have a 50 gallon drum of blue paint, and you toss in a drop of yellow, the
> entire thing doesn't turn green.
>
>
> On Thu, Nov 5, 2020 at 12:53 AM Sabri Berisha 
> wrote:
>
>> - On Nov 4, 2020, at 7:19 PM, Randy Bush ra...@psg.com wrote:
>>
>> Hi,
>>
>> >> The fact that we haven't been able to identify a factual relationship,
>> >> does not mean that there isn't any.
>> >
>> > just wow
>> >
>> > and, for all we know, the back side of the moon is green cheese
>>
>> I don't think you got the message buried within my message. True science
>> is open to change, based on learning new facts. Like I said initially, I
>> agree with Suresh that at this time, there is no scientific evidence that
>> links RF with any kind of bodily harm.
>>
>> The parts that Tom cited, are very much relevant, and only reinforce the
>> notion that at this time, we simply do not know enough. We do know, that
>> at the low doses we generally receive, there is no evidence for harmful
>> consequences.
>>
>> My point is that we should not dismiss the physician who thought that he
>> may have found something, as some kind of conspiracist. That's not how
>> scientific progress is achieved.
>>
>> Thanks,
>>
>> Sabri
>>
>>
>>


Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
Hi Sabri,

I hope by now my position on health effects from RF is becoming apparent,
ie., my focus is exclusively on health effects from chronic overexposure
scenarios (unintentional overexposure experienced by firefighters, telecom
workers etc. and intentional overexposure) which have attracted
insufficient attention except for rare instances (references I have
provided in an earlier email and one more#1 that deserves mention). Due to
the low volume of findings associated with _chronic overexposure_, it is
understandable that findings associated with _regulated_ RF emitters
(mobile handsets, base of communication tower etc.) as sage is popular
understanding. The sage opinion is true since the test exposure scenarios
are benign.

I have mentioned the following earlier but I repeat to convey circumstances
that have shaped my resolve to pursue this topic. When I certified Wi-Fi
endpoints at Intel Corporation in 2003-'04, I spent 10+ hour days on a
stretch in close proximity to 2.45GHz emissions. I did not experience
perceptible changes to my health due to this overexposure to cause alarm.
However, at Motorola in 2007 when I worked alongside high power (radiated
RF power)/gain (antenna amplification) outdoor Line of Sight emitters where
I was exposed to either the side or main RF lobes of unidirectional
microwave fields, the types of negative health symptoms induced was cause
for alarm. As a Infantryman trained in the U.S. military to anticipate and
defend onself/team from 360 degree threats, I recognized the high risk of
affordable powerful EMF emitters of civilian origin are opportune to get
improvised for malice with civilian expertse (circuit design/fabrication to
get started). Opportune since there are no diagnostic/forensic tests (I
have checked with forensic DNA scientists at the U.S. NIST) and
statutes/code associated with weapon (checked with the FCC), physical
assault/trespass do not yet delineate improvised potent RF as method of
malice.

I sense there is a perception that this discussion is off-topic. However,
having this discussion protects the unsuspecting people (like I was until
2007) and is as important as protecting electronic equipment in the data
center.

Best,
Suresh

#1  Sir William Stewart. Power Density: Radio frequency Non-Ionizing
Radiation. In:Mobile
Phones and Health: A report from the Independent Expert Group on Mobile
Phones, (The
Stewart Report, 2000).
https://www.ofcom.org.uk/__data/assets/pdf_file/0019/62515/cavi_society_attachment.pdf.
This report presents health effects in animal/avian model resulting from
chronic RF overexposure.



On Thursday, November 5, 2020, Sabri Berisha  wrote:

> Hi Suresh,
>
> I'm not disputing anything you or Tom wrote. The current scientific
> consensus is that most RF exposures are sage. We agree on that.
>
> My point is simply that, as Tom wrote in his citation, the biological
> effects of RF are still an area of research.
>
> And for that reason, it's unfair to dismiss a physician's suggestion to
> look into a case as an "internet conspiracy". That's all.
>
> Thanks,
>
> Sabri
>
>
> - On Nov 4, 2020, at 7:23 PM, Suresh Kalkunte 
> wrote:
>
> Existing research on health effects from RF signals dwell on emissions
> from regulated sources, (mobile handset, base of a tower etc), my
> overriding concern is, unrestricted/chronic exposure for extended duration
> of time for which there are very rare research efforts devoted.
>
> Chronic exposure to RF is found to induce DNA instability^1^. Even if RF
> at chronic exposure levels are not found to cause DNA strands to break, it
> creates upstream conditions such as excess Calcium influx^2,3^ into the
> cell's cytoplasm with implications on cardiac arrhythmia^4^,  invoke and/or
> worsen neurodegenerative^5^ diseases to name a few.
> Labeling any discussion on adverse health from OVEREXPOSURE to RF is a
> cop-out from doing a threadbare analysis.
>
> Suresh S.
>
> ^1^ Mashevich M, Folkman D, Kesar A, et. al. Exposure of human peripheral
> blood lymphocytes to electromagnetic fields associated with cellular phones
> leads to chromosomal instability. Bioelectromagnetics. 2003;24:82–90.
>
> ^2^ Arber SL, Lin JC. Extracellular calcium and microwave enhancement of
> membrane conductance in snail neurons. Radiat Environ Biophys. Jun
> 1985;24(2):149–156.
>
> ^3^ Rao VS, Titushkin IA, Moros EG et al. Nonthermal effects of
> radiofrequency-field exposure on calcium dynamics in stem cell-derived
> neuronal cells: elucidation of calcium pathways.
> Radiat Res. 2008 March. 169(3):319-29.
>
> ^4^ Grace AA , Camm AJ. Voltage-gated calcium -channels and antiarrhythmic
> drug action.
> Cardiovasc Res. Jan 2000;45(1):43–51.
>
> ^5^ Leal SS, Gomes CM. Calcium dysregulation links ALS defective proteins
> and motor neuron
> selective vulnerability. Front Cell Neurosci. 2015;9:225.
>
>
> On Thursday, November 5, 2020, Tom Beecher  wrote:
>
>> The hypothesis that RF may cause damage to human DNA is not at all
>>> conspir

Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
Oops, meant include this reference

*1 Mashevich M, Folkman D, Kesar A, et. al. Exposure of human peripheral
blood lymphocytes
to electromagnetic fields associated with cellular phones leads to
chromosomal instability.
Bioelectromagnetics. 2003;24:82–90.

On Thursday, November 5, 2020, Suresh Kalkunte  wrote:

> Hello,
>
> > ...I agree with Suresh that at this time, there
> > is no scientific evidence that links RF with
> > any kind of bodily harm.
> >
> Please note that there is scientific evidence to link chronic exposure to
> RF result in chromosome instability*1, however there is no diagnostic test
> to attribute a disease as the end state.
>
> > My point is that we should not dismiss the
> > physician who thought that he may have
> > found something, as some kind of
> > conspiracist.
> >
> Thank you. I am your everyday engineer who has had to cope with
> after-effects of powerful EMF and hence self-taught biology. If not for
> medical experts (cancer biology in academia) express confidence in my
> analysis connecting post-exposure to RF biology to likely disease outcome,
> I know better than to make a fool of myself. As I have said before, this
> group has the clue to dig for truth and not be satisfied with pseudo
> concepts.
>
> Regards,
> Suresh
>
>
> On Thursday, November 5, 2020, Sabri Berisha 
> wrote:
>
>> - On Nov 4, 2020, at 7:19 PM, Randy Bush ra...@psg.com wrote:
>>
>> Hi,
>>
>> >> The fact that we haven't been able to identify a factual relationship,
>> >> does not mean that there isn't any.
>> >
>> > just wow
>> >
>> > and, for all we know, the back side of the moon is green cheese
>>
>> I don't think you got the message buried within my message. True science
>> is open to change, based on learning new facts. Like I said initially, I
>> agree with Suresh that at this time, there is no scientific evidence that
>> links RF with any kind of bodily harm.
>>
>> The parts that Tom cited, are very much relevant, and only reinforce the
>> notion that at this time, we simply do not know enough. We do know, that
>> at the low doses we generally receive, there is no evidence for harmful
>> consequences.
>>
>> My point is that we should not dismiss the physician who thought that he
>> may have found something, as some kind of conspiracist. That's not how
>> scientific progress is achieved.
>>
>> Thanks,
>>
>> Sabri
>>
>>
>>


Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
Hello,

> ...I agree with Suresh that at this time, there
> is no scientific evidence that links RF with
> any kind of bodily harm.
>
Please note that there is scientific evidence to link chronic exposure to
RF result in chromosome instability*1, however there is no diagnostic test
to attribute a disease as the end state.

> My point is that we should not dismiss the
> physician who thought that he may have
> found something, as some kind of
> conspiracist.
>
Thank you. I am your everyday engineer who has had to cope with
after-effects of powerful EMF and hence self-taught biology. If not for
medical experts (cancer biology in academia) express confidence in my
analysis connecting post-exposure to RF biology to likely disease outcome,
I know better than to make a fool of myself. As I have said before, this
group has the clue to dig for truth and not be satisfied with pseudo
concepts.

Regards,
Suresh


On Thursday, November 5, 2020, Sabri Berisha  wrote:

> - On Nov 4, 2020, at 7:19 PM, Randy Bush ra...@psg.com wrote:
>
> Hi,
>
> >> The fact that we haven't been able to identify a factual relationship,
> >> does not mean that there isn't any.
> >
> > just wow
> >
> > and, for all we know, the back side of the moon is green cheese
>
> I don't think you got the message buried within my message. True science
> is open to change, based on learning new facts. Like I said initially, I
> agree with Suresh that at this time, there is no scientific evidence that
> links RF with any kind of bodily harm.
>
> The parts that Tom cited, are very much relevant, and only reinforce the
> notion that at this time, we simply do not know enough. We do know, that
> at the low doses we generally receive, there is no evidence for harmful
> consequences.
>
> My point is that we should not dismiss the physician who thought that he
> may have found something, as some kind of conspiracist. That's not how
> scientific progress is achieved.
>
> Thanks,
>
> Sabri
>
>
>


Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
Existing research on health effects from RF signals dwell on emissions from
regulated sources, (mobile handset, base of a tower etc), my overriding
concern is, unrestricted/chronic exposure for extended duration of time for
which there are very rare research efforts devoted.

Chronic exposure to RF is found to induce DNA instability^1^. Even if RF at
chronic exposure levels are not found to cause DNA strands to break, it
creates upstream conditions such as excess Calcium influx^2,3^ into the
cell's cytoplasm with implications on cardiac arrhythmia^4^,  invoke and/or
worsen neurodegenerative^5^ diseases to name a few.

Labeling any discussion on adverse health from OVEREXPOSURE to RF is a
cop-out from doing a threadbare analysis.

Suresh S.

^1^ Mashevich M, Folkman D, Kesar A, et. al. Exposure of human peripheral
blood lymphocytes to electromagnetic fields associated with cellular phones
leads to chromosomal instability. Bioelectromagnetics. 2003;24:82–90.

^2^ Arber SL, Lin JC. Extracellular calcium and microwave enhancement of
membrane conductance in snail neurons. Radiat Environ Biophys. Jun
1985;24(2):149–156.

^3^ Rao VS, Titushkin IA, Moros EG et al. Nonthermal effects of
radiofrequency-field exposure on calcium dynamics in stem cell-derived
neuronal cells: elucidation of calcium pathways.
Radiat Res. 2008 March. 169(3):319-29.

^4^ Grace AA , Camm AJ. Voltage-gated calcium -channels and antiarrhythmic
drug action.
Cardiovasc Res. Jan 2000;45(1):43–51.

^5^ Leal SS, Gomes CM. Calcium dysregulation links ALS defective proteins
and motor neuron
selective vulnerability. Front Cell Neurosci. 2015;9:225.


On Thursday, November 5, 2020, Tom Beecher  wrote:

> The hypothesis that RF may cause damage to human DNA is not at all
>> conspiracy. The
>> fact that we haven't been able to identify a factual relationship, does
>> not mean
>> that there isn't any. For example:
>>
>
> If you are going to cite that American Cancer Society article, you should
> cite all the relevant parts. The parts you skipped are bolded.
>
> *RF waves don’t have enough energy to damage DNA directly. Because of
>> this, it’s not clear how RF radiation might be able to cause cancer. Some
>> studies have found possible increased rates of certain types of tumors in
>> lab animals exposed to RF radiation, but overall, the results of these
>> types of studies have not provided clear answers so far.*
>>
>> *A few studies have reported evidence of biological effects that could be
>> linked to cancer, but this is still an area of research.*
>>
>> In large studies published in 2018 by the US National Toxicology Program
>> (NTP) and by the Ramazzini Institute in Italy, researchers exposed groups
>> of lab rats (as well as mice, in the case of the NTP study) to RF waves
>> over their entire bodies for many hours a day, starting before birth and
>> continuing for at least most of their natural lives. Both studies found an
>> increased risk of uncommon heart tumors called malignant schwannomas in
>> male rats, but not in female rats (nor in male or female mice, in the NTP
>> study). The NTP study also reported possible increased risks of certain
>> types of tumors in the brain and in the adrenal glands.
>>
>> *While both of these studies had strengths, they also had limitations
>> that make it hard to know how they might apply to humans being exposed to
>> RF radiation. A 2019 review of these two studies by the International
>> Commission on Non-Ionizing Radiation Protection (ICNIRP) determined that
>> the limitations of the studies didn’t allow conclusions to be drawn
>> regarding the ability of RF energy to cause cancer.*
>>
>> *Still, the results of these studies do not rule out the possibility that
>> RF radiation might somehow be able to impact human health.*
>>
> The majority of science to date finds no causal relationship between EM
> radiation and cancerous mutations. If someone wants to claim otherwise,
> scientific proof is required.
>
> On Wed, Nov 4, 2020 at 7:56 PM Sabri Berisha 
> wrote:
>
>> Hi,
>>
>> Not that I'm into conspiracy theories, or believe at this point that RF
>> emissions
>> are in any way related to cancer, but Suresh' statement is not very
>> scientific:
>>
>> > This is an internet conspiracy theory with no basis in reality or
>> science.
>>
>> RF emissions are absorbed by the human body. Your kitchen microwave works
>> at
>> the same frequency as your 2.4Ghz wifi. We all know it's a bad idea to
>> put your
>> head in a microwave oven.
>>
>> The hypothesis that RF may cause damage to human DNA is not at all
>> conspiracy. The
>> fact that we haven't been able to identify a factual relationship, does
>> not mean
>> that there isn't any. For example:
>>
>> > In large studies published in 2018 by the US National Toxicology
>> Program (NTP)
>> > and by the Ramazzini Institute in Italy, researchers exposed groups of
>> lab rats
>> > (as well as mice, in the case of the NTP study) to RF waves over their
>> entire
>> > bodie

Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
> Vulnerability to EMI is a lot less than folks imagine.
>
I hope that is true.

> Malicious use of EMI emitters to harm
> human health is definitely out of scope for
> this list.
>
I am of the belief that people are as important as electronic equipment in
the gamut of workplace safety in the ambit of internal sabotage, be it data
center or elsewhere.

On Thursday, November 5, 2020, William Herrin  wrote:

> On Wed, Nov 4, 2020 at 11:37 AM Suresh Kalkunte 
> wrote:
> > Your comments gives me an overall impression that data center equipment
> are on average adequately protected, that is good. Also, public discussion
> on the risk of intentional EMI is a big positive.
>
> I watched a T.V. program a few years ago where an investigative
> reporter did a piece on the risks of malicious electromagnetic
> interference (EMI). He did a demonstration where he tried to cause a
> car to malfunction. A bad actor could cause highway crashes! He had a
> great big apparatus about the size of the car's engine compartment and
> pointed at the car. Nothing happened. So he moved it about 3 feet from
> the car. Nothing happened. So he opened the car's hood and pointed it
> right at the engine. Finally the engine started sputtering and the
> dashboard electronics malfunctioned. The car, of course, remained
> completely controllable and when the EMI generator was turned off it
> resumed normal operation undamaged.
>
> I've also had lightning hit about 50 feet from my unshielded computer
> room. It fried a little plastic COTS router that was connected by
> about 100 feet of UTP ethernet to my core router. The core router
> crashed but worked fine after a reboot. No other equipment was
> affected.
>
> Vulnerability to EMI is a lot less than folks imagine.
>
> > However, targeting a human using powerful RF is uncharacterized (please
> see https://github.com/sureshs20/De_Risk_Technology). If the RF emitters
> conducive for getting re-purposed for malice were prohibitively expensive
> _or_ the expertise to re-purpose RF for malice was very complex _or_ if
> there were diagnostic/forensic tests to detect foul-play using powerful RF,
> I would not be pursuing this initiative to safeguard
> unsuspecting/defenseless targets of opportunity.
>
> Malicious use of EMI emitters to harm human health is definitely out
> of scope for this list.
>
> Regards,
> Bill Herrin
>
> --
> Hire me! https://bill.herrin.us/resume/
>


Re: Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
> There is other venues to work this out
> "safely", IMHO.
>
I started this effort for safeguards in July 2007. Until 2018, I did
exactly what you mention. The FCC's Office of Engineeting and Technology in
2015 has been the only government agency that replied to my email query on
jurisdiction stating the FCC does not regulate/enforce negative
improvisation of outdoor high power wireless transmitters. By 2018, I had
collected sufficient supporting data that was burdensome to send via email
and absent response of multiple governments to address this significant gap
in rule of law prompted me to put up the website competitionunlimited on
Wordpress.

If some institution innumerable to count had agreed to investigate, I would
be very content writing code for commercial data communication systems
which is what took me to the U.S. in 1994. During my overseas deployments
with the U.S. Army National Guard, my reports to higher regarding
vulnerabilities was consistently met with unambiguous
response/acknowledgement indicating my concern is being investigated. Since
I have not had that benefit from civilian organizations, I finally reasoned
that common awareness reduces the element of surprise from an incognito
perpetrator.

Please note that I have wrestled with "Maybe someone is just looking for
"inspiration"" for almost 13 years before bringing this to your collective
notice today.

On Wednesday, November 4, 2020, Alain Hebert  wrote:

> Maybe someone is just looking for "inspiration".
>
> There is other venues to work this out "safely", IMHO.
>
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.50 boul. St-Charles 
> 
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
> On 11/4/20 12:24 PM, Matt Harris wrote:
>
> Matt Harris​
> | Infrastructure Lead Engineer
> 816‑256‑5446
> | Direct
> Looking for something?
> *Helpdesk Portal* 
> | *Email Support* 
> | *Billing Portal* 
> We build and deliver end‑to‑end IT solutions.
> On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte 
> wrote:
>
>> Hello,
>>
>> I believe the below described method of causing intentional (1) damage to
>> equipment in data centers and (2) physical injury to a person at the
>> workplace is on-topic for the NANOG community, if not, I look forward to
>> your feedback. As a software developer who has subscribed to the NANOG
>> mailing list for a number of years, I post this note relying on
>> intellectual honesty that I have had the opportunity to observe since
>> 1996-97.
>>
>> The below described technology risk is applicable to
>> computing/communication equipment rendered vulnerable by Intentional
>> Electromagnetic Interference (jamming an electronic device) and the risk of
>> health sabotage affecting people (jamming a human) managing the Internet
>> infrastructure enabled by intentional application of powerful
>> radiofrequency fields (RF) emitted by re-purposed components salvaged from
>> a kitchen heating appliance (Magnetron) or from an outdoor high gain/power
>> Line of sight transceiver (unidirectional microwave radio) which has a harm
>> causing range up to 25 meters (estimated using a Spectral Power Density
>> calculator like www.hintlink.com/power_density.htm).
>>
>> This risk from mis-application of powerful RF is from human operated or
>> IoT apparatus** with an avenue of approch from (a) subterrain placement
>> aided by a compact/mini directional horizontal drilling machine (eg.
>> principle of placing a stent in the heart) and/or (b) strategic placement
>> in an obscure over-surface location to maximize negative impact on the
>> target of opportunity.
>>
>> With building materials or ground offer insufficient* protection to block
>> the passage of powerful RF and the absence of diagnostic/forensic tests to
>> detect biomarkers expressed post-overexposure to harmful RF  (combination
>> of RF frequency, Spectral Power Density/Specific Absorption Rate incident
>> on a person and duration of exposure), intentional damage to electronic
>> equipment and people is at present unrestricted.
>>
>> The purpose of bringing this method of exploting technology to your
>> attention is with an interest to build the momentum for ushering in the
>> much needed safeguards in this context.
>>
>
> While I'm a bit confused as to what this message is trying to ultimately
> get at, it should be noted that folks who work with RF communications
> equipment and other EM emitters which are strong enough to cause harm to a
> person are generally well aware of the necessary precautions and take them
> on a day to day basis when working with this equipment. If there's evidence
> that some part of our industry is ignoring or failing to train their team
> members on safety best practices, then let's hear that out specifica

Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
> I'm a bit confused as to what this message
> is trying to ultimately get at
>
The superior tactical advantage of causing intentional harm with high power
beam-forming RF and escape detection. Meaning, assault with powerful RF
leaves a victim and bystander unaware of being attacked and my intention is
to mobilize interest to plug the gap in safeguards.

> it should be noted that folks who work
> with RF... well aware of the necessary
> precautions and take them on a day to day
> basis when working with this equipment...
>
At an employer where I developed Wi-Fi based SOHO device, an adjacent group
was testing Line of Sight transceivers. Nobody warned me of the inclement
health (a general physician in 2007 suspected cancer looking at a blood
test) from close quarters exposure to the side lobes emanating from the
microwave radio.

> ...let's hear that out specifically and I'm all
> for working to rectify that.
>
Applicable to workplaces pertinent to the NANOG community and elsewhere,
there is need for publicising policy on curbing harassment using powerful
RF along the lines of curbing gender/race based harassment. Why publicise?
awareness among non-RF professionals of the leading health symptoms
expressed post-overexposure to harmful RF/X-ray voids the element of
surprise on an unsuspecting victim.

> The former is relatively difficult to do by
> virtue of the amount of power necessary.
>
For instance, RF from Magnetron salvaged from a kitchen heating appliance
focused using a horn antenna when positioned on a roof renders the person
one floor above within 2 meters effective range of harm.

> Quite basically, there are much easier ways
> to go about injuring someone if that's what
> you want to do
>
Without a doubt. However, other methods are very well handled by existing
forensic tests to minimize repeat offence. With negative use of RF on
humans, the perpetrator is fearless of law.

> jam RF communications has existed for as
> long as RF communication has, and the
> knowledge of how to accomplish it is
> relatively widespread
>
Very good point, the FCC has enforcable regulations and the DoJ armed with
statutes to curb jamming electronic devices. However jamming a human is not
yet present.

> ...but lacks specificity with regard to what
> safeguards...
>
Thanks for asking. Safeguards I can think of:
- Anti-harassment policy diplayed at a workplace, hospital, hotel etc. to
raise awareness of failing health post-overexposure to harmful RF/X-ray
(EMF).
- Diagnostic/forensic tests that identify biomarkers expressed
post-overexposure to harmful EMF.
- Forensic tests that make visible transformation of paint and characterize
the alteration of microbiome exposed to harmful EMF.
- Detectors worn by firefighters^*^, civil law enforcement, military and
outdoor wireless developers and field technicians.

^*^ Curtis S.D. Massey. The Facts and Dangers of Rooftop Transmitting
Devices on High-Rise
Buildings. Mar 31st, 2005.
https://www.firehouse.com/safety-health/article/10513827/the-facts-and-dangers-of-rooftop-transmitting-devices-on-highrise-buildings
.

On Wednesday, November 4, 2020, Matt Harris  wrote:

> Matt Harris​
> | Infrastructure Lead Engineer
> 816‑256‑5446
> | Direct
> Looking for something?
> *Helpdesk Portal* 
> | *Email Support* 
> | *Billing Portal* 
> We build and deliver end‑to‑end IT solutions.
> On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte 
> wrote:
>
>> Hello,
>>
>> I believe the below described method of causing intentional (1) damage to
>> equipment in data centers and (2) physical injury to a person at the
>> workplace is on-topic for the NANOG community, if not, I look forward to
>> your feedback. As a software developer who has subscribed to the NANOG
>> mailing list for a number of years, I post this note relying on
>> intellectual honesty that I have had the opportunity to observe since
>> 1996-97.
>>
>> The below described technology risk is applicable to
>> computing/communication equipment rendered vulnerable by Intentional
>> Electromagnetic Interference (jamming an electronic device) and the risk of
>> health sabotage affecting people (jamming a human) managing the Internet
>> infrastructure enabled by intentional application of powerful
>> radiofrequency fields (RF) emitted by re-purposed components salvaged from
>> a kitchen heating appliance (Magnetron) or from an outdoor high gain/power
>> Line of sight transceiver (unidirectional microwave radio) which has a harm
>> causing range up to 25 meters (estimated using a Spectral Power Density
>> calculator like www.hintlink.com/power_density.htm).
>>
>> This risk from mis-application of powerful RF is from human operated or
>> IoT apparatus** with an avenue of approch from (a) subterrain placement
>> aided by a compact/mini directional horizontal drilling machine (eg.
>> principle of placing a stent in the heart) and/or (b) strategic placement
>> in an obscure over-surface location 

Re: {Disarmed} Re: Asus wifi AP re-writing DNS packets

2020-11-05 Thread Verdi R-D
I experienced this as well dealing with some soho "routers" such as the
RT-AC1200. I imagine this configuration is something in-common with a lot
of their offerings. The issue was resolved by making sure the primary DHCP
server and the Asus device both pointed to the same DNS server.

On Wed, Nov 4, 2020 at 2:33 PM Tony Wicks  wrote:

> I had a similar discussion with another vendor recently while testing
> their mesh wireless systems. This vendor’s units are actually re-writing
> dhcp requests that clients make to point DNS to the primary mesh unit. This
> even happened when the mesh platform was in pure bridge mode (as opposed to
> router mode). The vendor said this was to make sure their app worked
> reliably. I’d say this sort of behaviour has quietly become common in the
> one app to rule it all world.
>
>
>
>
>
>
>
> *From:* NANOG  *On Behalf Of *Anurag
> Bhatia
> *Sent:* Thursday, 5 November 2020 7:03 am
> *To:* NANOG Mailing List 
> *Subject:* {Disarmed} Re: Asus wifi AP re-writing DNS packets
>
>
>
> Hello
>
>
>
>
>
> An update on this issue:
>
>
>
> Going through (long) Asus support channel, they first agreed that this was
> intentional to make router.asus.com work but did take my request to make
> that optional. They have issued me a test firmware which so far seems to be
> working perfectly with no-rewriting rules. Hoping that it doesn't bring any
> side effects and they eventually put it in their public release after
> testing.
>
>
>
>
>
>
>


Technology risk without safeguards

2020-11-05 Thread Suresh Kalkunte
Hello,

> Did you test against common equipment
> deployments or did you just measure the field
> strength?
>
I have not conducted any test, only going by the field strength that is
capable of causing EMI.

> In common equipment deployments, the
> electronics are wrapped in two layers of
> Faraday cage: the steel case of the equipment
> itself and the steel cabinet into which the
> equipment is installed, both well grounded.
> Penetration from even strong EM fields is limited.
>
I agree. Depending on the magnitude of down side, ie., to mitigate an
attack to induce electrical failure (Magnetron + horn antenna), it may be
necessary for metal clad walls and floor housing the electronic equipment.
The thickness of metal clading would need some testing with an RF emitter
discussed at https://www.datacenterdynamics.com/en/analysis/emp-the-
suitcase-that-can-close-down-your-site/.

> Also, if you go to the expense of boring under
> someone's data center I have to think dynamite
> will be more effective at disabling it.
>
If all data centers without a floor beneath are hardened to repel a
sub-surface horizontal drilling apparatus, that's great. For data centers
that do have a floor beneath, the above said metal clading is relevant.

Your comments gives me an overall impression that data center equipment are
on average adequately protected, that is good. Also, public discussion on
the risk of intentional EMI is a big positive. However, targeting a human
using powerful RF is uncharacterized (please see
https://github.com/sureshs20/De_Risk_Technology). If the RF emitters
conducive for getting re-purposed for malice were prohibitively expensive
_or_ the expertise to re-purpose RF for malice was very complex _or_ if
there were diagnostic/forensic tests to detect foul-play using powerful RF,
I would not be pursuing this initiative to safeguard
unsuspecting/defenseless targets of opportunity.

Please also note that I have been at the threshold of cancer
post-overexposure to a combination of powerful RF and X-ray (re-purposed
X-ray tube)  during this lifetime to be committed to developing
diagnostic/forensic tests and making you all aware of this in the spirit of
'fore warned is fore armed'.

Regards,
Suresh

On Wednesday, November 4, 2020, William Herrin  wrote:

> On Wed, Nov 4, 2020 at 8:49 AM Suresh Kalkunte 
> wrote:
> > I believe the below described method of causing intentional (1) damage
> to equipment in data centers and (2) physical injury to a person at the
> workplace is on-topic for the NANOG community, if not, I look forward to
> your feedback. As a software developer who has subscribed to the NANOG
> mailing list for a number of years, I post this note relying on
> intellectual honesty that I have had the opportunity to observe since
> 1996-97.
>
> Hello,
>
> Did you test against common equipment deployments or did you just
> measure the field strength?
>
> In common equipment deployments, the electronics are wrapped in two
> layers of Faraday cage: the steel case of the equipment itself and the
> steel cabinet into which the equipment is installed, both well
> grounded. Penetration from even strong EM fields is limited.
>
> Also, if you go to the expense of boring under someone's data center I
> have to think dynamite will be more effective at disabling it.
>
> Regards,
> Bill Herrin
>
>
> --
> Hire me! https://bill.herrin.us/resume/
>


RE: Technology risk without safeguards

2020-11-05 Thread nathanb
To that end, anyone working around RF should be properly trained and use the 
safety tools provided them, they should be fine.  If an untrained individual 
does something and gets hurt with high power RF, it is unfortunate and happens 
all too often because of people thinking that the worst case things don’t 
happen to them…  

 

Can you provide a case where this may have happened?  Any RF in a Data Center 
should be on the roof, and isolated from the room at all times.  This is 
standard practice in every RF data room we’ve ever been in, whether it be 
commercial or Government.

 


Regards,

Nathan Babcock



 

From: NANOG  On Behalf Of Alain 
Hebert
Sent: Wednesday, November 4, 2020 10:32 AM
To: nanog@nanog.org
Subject: Re: Technology risk without safeguards

 

Maybe someone is just looking for "inspiration".

There is other venues to work this out "safely", IMHO.



-
Alain Hebertaheb...@pubnix.net 

PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 11/4/20 12:24 PM, Matt Harris wrote:




   





Matt Harris​


|

Infrastructure Lead Engineer




816‑256‑5446


|

Direct



Looking for something?





  Helpdesk Portal


|

  Email Support


|

  Billing Portal




   



We build and deliver end‑to‑end IT solutions.

On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte mailto:sskalku...@gmail.com> > wrote:

Hello,

 

I believe the below described method of causing intentional (1) damage to 
equipment in data centers and (2) physical injury to a person at the workplace 
is on-topic for the NANOG community, if not, I look forward to your feedback. 
As a software developer who has subscribed to the NANOG mailing list for a 
number of years, I post this note relying on intellectual honesty that I have 
had the opportunity to observe since 1996-97.

 

The below described technology risk is applicable to computing/communication 
equipment rendered vulnerable by Intentional Electromagnetic Interference 
(jamming an electronic device) and the risk of health sabotage affecting people 
(jamming a human) managing the Internet infrastructure enabled by intentional 
application of powerful radiofrequency fields (RF) emitted by re-purposed 
components salvaged from a kitchen heating appliance (Magnetron) or from an 
outdoor high gain/power Line of sight transceiver (unidirectional microwave 
radio) which has a harm causing range up to 25 meters (estimated using a 
Spectral Power Density calculator like www.hintlink.com/power_density.htm 
 ).

 

This risk from mis-application of powerful RF is from human operated or IoT 
apparatus** with an avenue of approch from (a) subterrain placement aided by a 
compact/mini directional horizontal drilling machine (eg. principle of placing 
a stent in the heart) and/or (b) strategic placement in an obscure over-surface 
location to maximize negative impact on the target of opportunity.

 

With building materials or ground offer insufficient* protection to block the 
passage of powerful RF and the absence of diagnostic/forensic tests to detect 
biomarkers expressed post-overexposure to harmful RF  (combination of RF 
frequency, Spectral Power Density/Specific Absorption Rate incident on a person 
and duration of exposure), intentional damage to electronic equipment and 
people is at present unrestricted.

 

The purpose of bringing this method of exploting technology to your attention 
is with an interest to build the momentum for ushering in the much needed 
safeguards in this context.

 

While I'm a bit confused as to what this message is trying to ultimately get 
at, it should be noted that folks who work with RF communications equipment and 
other EM emitters which are strong enough to cause harm to a person are 
generally well aware of the necessary precautions and take them on a day to day 
basis when working with this equipment. If there's evidence that some part of 
our industry is ignoring or failing to train their team members on safety best 
practices, then let's hear that out specifically and I'm all for working to 
rectify that. 

 

On the other hand, the post seems to hint at intentionally using high powered 
RF to inflict intentional harm on a person or to jam communications signals. 
The former is relatively difficult to do by virtue of the amount of power 
necessary. Quite basically, there are much easier ways to go about injuring 
someone if that's what you want to do. Of course, intentionally injuring 
another person is a criminal act in just about every jurisdiction. As far as 
the latter goes, the ability to jam RF communications has existed for as long 
as RF com

Re: Technology risk without safeguards

2020-11-05 Thread Tom Beecher
>
> The parts that Tom cited, are very much relevant, and
> * only reinforce thenotion that at this time, we simply do not know
> enough.* We do know, that
> at the low doses we generally receive, there is no evidence for harmful
> consequences.
>
> My point is that we should not dismiss the physician who thought that he
> may have found something, as some kind of conspiracist. That's not how
> scientific progress is achieved.
>

 This is a gross mischaracterization, and I would go so far to say patently
incorrect.

Assert a general hypothesis of "Does X increase the chance of Y to occur?",
and a sufficient amount of science is done.

Let's say roughly half of the science says the hypothesis is false, and
half says it is true. It is absolutely fair in this case to state "We don't
know enough."

However, let's say that 95% of the science says the hypothesis is false,
and 5% says it is true. We DO know enough in this case to state with
reasonable certainty that X does not increase the chance of Y. The
description then is "Although we cannot absolutely rule it out, we so far
find no evidence that X causes Y." Then, we go back and do more science
based on what we have learned so far, and learn some more.

One doctor, who THINKS he MIGHT have identified something to the contrary
does not instantly disqualify the thousands of studies that have already
been completed on the topic. His findings go into the pile with all the
other findings, and they get properly evaluated. An easy analogy : If you
have a 50 gallon drum of blue paint, and you toss in a drop of yellow, the
entire thing doesn't turn green.


On Thu, Nov 5, 2020 at 12:53 AM Sabri Berisha  wrote:

> - On Nov 4, 2020, at 7:19 PM, Randy Bush ra...@psg.com wrote:
>
> Hi,
>
> >> The fact that we haven't been able to identify a factual relationship,
> >> does not mean that there isn't any.
> >
> > just wow
> >
> > and, for all we know, the back side of the moon is green cheese
>
> I don't think you got the message buried within my message. True science
> is open to change, based on learning new facts. Like I said initially, I
> agree with Suresh that at this time, there is no scientific evidence that
> links RF with any kind of bodily harm.
>
> The parts that Tom cited, are very much relevant, and only reinforce the
> notion that at this time, we simply do not know enough. We do know, that
> at the low doses we generally receive, there is no evidence for harmful
> consequences.
>
> My point is that we should not dismiss the physician who thought that he
> may have found something, as some kind of conspiracist. That's not how
> scientific progress is achieved.
>
> Thanks,
>
> Sabri
>
>
>


Re: Bird Router Appliance projects

2020-11-05 Thread Douglas Fischer
I received some contacts in PVT...

And joining the recommendations of some of them, I will give a shot with
BSDRP+Napalm(with Ansible).
Let's see if it can scale as expected.

Thank you all.

Em qua., 4 de nov. de 2020 às 05:15, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:

> I'm deploying some Linux based routers with BIRD as the routing daemon.
>  -> Yep, Bird is a specific requirement for this project.
>
> But is taking me to much time to adjust(and in the future keep it running
> good) the basic like, sysctl adjustments for routing and performance on
> that, ssh/snmp and security tunning for that.
>
>
> So I'm looking for something a bit more "almost ready".
>
>
> I remembered BSRP(which has a recent release with support to Bird 2.0.7).
> But I'm looking for something in the Linux world.
>
>
> P.S.:
> Actually, I believe that what better describes my wishes would be:
> Something like Vyos or Danos, with all the complementary resources of a
> router like: SNMP, Netflow, SSH, Telnet, Interfaces/Address setting...
> But with Bird instead of FRR.
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação


BGP Peers Data modeling schema

2020-11-05 Thread Douglas Fischer
I'm designing a tool for provisioning configurations for an ITP and his
Peers.
The idea is that based on that, all the configs to all the involved
components configurations to be deployed based on that source of data. I'm
Talking about Routers, BMP, SNMP tool(Ex.: Zabbix), etc...

But, once again, I'm feeling that I'm reinventing the wheel.
I'm pretty sure that someone else has already suffered from that.

I search for a bit, and I didn't find anything...
But with this gray area between developers and network operators, I'm not
sure if I'm looking at the right place.

I even tried to look at http://schema.org but didn't find anything related
to networks and BGP there yet.


So, anyone could point me in the right direction?
-- 
Douglas Fernando Fischer
Engº de Controle e Automação