Re: mail admins?

[Töma Gavrichenkov]

Peace,

On Wed, Apr 22, 2020, 12:45 AM Randy Bush  wrote:

> sad.  http://nanog.org used to be the brilliant example of a fully
> featured web site sans javascript, flash, ...
>

That was long ago now.  It was using Cvent for everything meeting-related
for 3 years already, and Cvent doesn't feel good with JS turned off.

As for the flash, it is quite reliably dead so no need to worry.

--
Töma

>

Re: mail admins?

[William Herrin]

On Tue, Apr 21, 2020 at 8:37 PM Michael Thomas  wrote:
> telnet host 587
>
> mail-from <>
>
> rcpt-to <>
>
> data

I did a bit of that last week when Google up and decided that gmail's
"send as" feature would no longer communicate with servers offering
starttls with a self-signed certificate.

-Bill


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

Re: mail admins?

[Michael Thomas]

On 4/21/20 7:46 PM, Scott Weeks wrote:


--- m...@mtcc.com wrote:

From: Michael Thomas 
To: nanog@nanog.org
Subject: Re: mail admins?
Date: Tue, 21 Apr 2020 17:34:36 -0700


On 4/21/20 5:19 PM, Scott Weeks wrote:



I think you just need to let scripts run in your browser for
nanog.org.

sad.  http://nanog.org used to be the brilliant example of a fully
featured web site sans javascript, flash, ...
---


I'm not one to plus-one anything, but this should be plus-infinity.
I whined about it a year or so ago.  Crickets.  I gave up on doing
anything on the web site because I can't get anything to work
unless I make my computer less secure.  Sad trend.  More flash and
trash marketing crap and less network engineering acumen.  Like
configuring routers from a web browser, rather than a CLI...


this ship left port in the 90's. you might as well be an old man yelling
at clouds. oh wait, randy does kind of resemble grandpa simpson :)
--



So I should just get used to configuring routers with HTTP and
Notepad and forget about that nasty, old, 20th century vi crap? :)

scott

ps.  One guy I know claims vi is the spawn of satan.


telnet host 587

mail-from <>

rcpt-to <>

data


Mike

Re: mail admins?

[Scott Weeks]

--- m...@mtcc.com wrote:

From: Michael Thomas 
To: nanog@nanog.org
Subject: Re: mail admins?
Date: Tue, 21 Apr 2020 17:34:36 -0700


On 4/21/20 5:19 PM, Scott Weeks wrote:
>
>
>> I think you just need to let scripts run in your browser for
>> nanog.org.
> sad.  http://nanog.org used to be the brilliant example of a fully
> featured web site sans javascript, flash, ...
> ---
>
>
> I'm not one to plus-one anything, but this should be plus-infinity.
> I whined about it a year or so ago.  Crickets.  I gave up on doing
> anything on the web site because I can't get anything to work
> unless I make my computer less secure.  Sad trend.  More flash and
> trash marketing crap and less network engineering acumen.  Like
> configuring routers from a web browser, rather than a CLI...
>
this ship left port in the 90's. you might as well be an old man yelling 
at clouds. oh wait, randy does kind of resemble grandpa simpson :)
--



So I should just get used to configuring routers with HTTP and 
Notepad and forget about that nasty, old, 20th century vi crap? :)

scott

ps.  One guy I know claims vi is the spawn of satan.

Re: mail admins?

[Michael Thomas]

On 4/21/20 5:19 PM, Scott Weeks wrote:




I think you just need to let scripts run in your browser for
nanog.org.

sad.  http://nanog.org used to be the brilliant example of a fully
featured web site sans javascript, flash, ...
---


I'm not one to plus-one anything, but this should be plus-infinity.
I whined about it a year or so ago.  Crickets.  I gave up on doing
anything on the web site because I can't get anything to work
unless I make my computer less secure.  Sad trend.  More flash and
trash marketing crap and less network engineering acumen.  Like
configuring routers from a web browser, rather than a CLI...

this ship left port in the 90's. you might as well be an old man yelling 
at clouds. oh wait, randy does kind of resemble grandpa simpson :)


Mike

Re: mail admins?

[Scott Weeks]

> I think you just need to let scripts run in your browser for
> nanog.org.

sad.  http://nanog.org used to be the brilliant example of a fully
featured web site sans javascript, flash, ...
---


I'm not one to plus-one anything, but this should be plus-infinity.
I whined about it a year or so ago.  Crickets.  I gave up on doing 
anything on the web site because I can't get anything to work 
unless I make my computer less secure.  Sad trend.  More flash and 
trash marketing crap and less network engineering acumen.  Like 
configuring routers from a web browser, rather than a CLI...

scott

Construction crew hits underground fiber line, causes outage of 'call before you dig' hotline

[Sean Donelan]

https://www.9news.com/article/news/local/fiber-line-damage-colorado-811-outage-call-before-dig/73-b4b4753d-d524-400d-8cd8-5ee605c02236

Construction crew hits underground fiber line, causes outage of 'call 
before you dig' hotline
Through the 811 hotline you can call to have utility lines marked before 
doing any digging.



DENVER — It looks like someone may have forgotten to call before they 
started digging and now others are unable to do so due to an outage of the 
Colorado 811 hotline caused by a busted fiber line.


A message on the Colorado 811 website says there's an outage in the 
communication system. It says an underground fiber line was damaged and 
it's causing "significant" outages in the Denver area.


Construction activity caused underground damage, according to the website. 
Crews are working to repair the damage, but repairs are not expected to be 
completed until around 8 p.m. Tuesday.


[...]

Re: mail admins?

[William Herrin]

On Tue, Apr 21, 2020 at 3:36 PM Bryan Fields  wrote:
> I'm also assuming this is about the 5 bounce messages I got from this last
> message to the list "Message to 9728466...@email.uscc.net failed."

Them and the Swedish site that's still opening tickets in Swedish in
response to nanog list posts. I was thinking of volunteering to help.
It's not exceptionally hard to figure out which list subscriber is the
problem but it's not baked in to mailman; you have to do a little bit
of work.

-Bill


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

Re: Are underground utility markers essential workers?

[Wayne Bouchard]

It really goes back to what I have maintained in that you can't really
say who is essential or not because such declarations never extend the
full width and breadth of the supply and distribution chain. For
example, someone manufacturing cardboard boxes might not be thought of
as essential but when these cardboard boxes are used to package food
items so they can be sent around the country, does that mean that they
now are? What if they're being used to package medical supplies?
Trying to judge "essential" and "non-essential" is always going to be
problematic and you're always going to get it wrong.

On Tue, Apr 21, 2020 at 02:57:15PM -0400, Sean Donelan wrote:
> 
> Utility markers don't get the recognition they deserve.  If they aren't
> essential workers, they should be and get hazard pay.
> 
> They help protect everyone's fiber and cables and pipes that go boom.
> 

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

Re: mail admins?

[Bryan Fields]

On 4/21/20 6:28 PM, Bryan Fields wrote:
> On 4/21/20 5:11 PM, William Herrin wrote:
>> Howdy,,
>>
>> How do we contact the nanog mail admins? I looked at
>> https://archive.nanog.org/list and https://archive.nanog.org/list/faq
>> but apparently someone thought it'd be clever to redact all the email
>> addresses from that page. "Questions should be directed to[email
>> protected]."
> 
> It's a mailman list, so nanog-ow...@nanog.org should work.  If not reach out
> to the communications committee.
> 
> Now i did try searching the website for the communications committee, and I
> can't tell if it's still a thing.  The one time I actually interacted with
> them, I just emailed Matt Griswold, but that was years ago.

I'm also assuming this is about the 5 bounce messages I got from this last
message to the list "Message to 9728466...@email.uscc.net failed."

Lets see if it honors "Reply-to:" :)
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: mail admins?

[Jan Schaumann]

Neil Hanlon  wrote:
> I think you just need to let scripts run in your browser for nanog.org.
> 
> It uses Javascript to add the emails in after the fact, it appears.

Yep.  It's obfuscation via an XOR with a key included
in the href.  So if you do not want to run javascript,
you can grab the href, pull out the key, xor the
remaining obfuscated string with it and you get the
address.

I.e.:

for email in $(curl https://archive.nanog.org/list | sed -n -e 
's/.*cfemail="\(.*\)".*>/\1/p'); do n=0; for b in $(echo "${email}" | sed -e 
's/\(..\)/\1 /g'); do if [ $n -eq 0 ]; then key=$b; else printf "\\$(printf 
"%o" $(( 0x${key} ^ 0x${b})) )"; fi; n=1; done; echo; done

It's all so obvious, isn't it?

-Jan

"This Email As A Tweet":
https://twitter.com/jschauma/status/1191062800082317312

Re: mail admins?

[Bryan Fields]

On 4/21/20 5:11 PM, William Herrin wrote:
> Howdy,,
> 
> How do we contact the nanog mail admins? I looked at
> https://archive.nanog.org/list and https://archive.nanog.org/list/faq
> but apparently someone thought it'd be clever to redact all the email
> addresses from that page. "Questions should be directed to[email
> protected]."

It's a mailman list, so nanog-ow...@nanog.org should work.  If not reach out
to the communications committee.

Now i did try searching the website for the communications committee, and I
can't tell if it's still a thing.  The one time I actually interacted with
them, I just emailed Matt Griswold, but that was years ago.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: mail admins?

[Randy Bush]

> I think you just need to let scripts run in your browser for
> nanog.org.

sad.  http://nanog.org used to be the brilliant example of a fully
featured web site sans javascript, flash, ...

randy

Re: mail admins?

[Neil Hanlon]

I think you just need to let scripts run in your browser for nanog.org.

It uses Javascript to add the emails in after the fact, it appears.

On Apr 21, 2020, 17:15, at 17:15, William Herrin  wrote:
>Howdy,,
>
>How do we contact the nanog mail admins? I looked at
>https://archive.nanog.org/list and https://archive.nanog.org/list/faq
>but apparently someone thought it'd be clever to redact all the email
>addresses from that page. "Questions should be directed to[email
>protected]."
>
>Thanks,
>Bill Herrin
>
>
>--
>William Herrin
>b...@herrin.us
>https://bill.herrin.us/

Re: Are underground utility markers essential workers?

[Ben Cannon]

In the scope and performance of their duties includes any work involving 
essential telecommunications expansion or restoration - then yes.

And agreed.  They save lives.  Period. 
Call before you dig. Please.

-Ben

Ms. Benjamin PD Cannon, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
b...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world."



> On Apr 21, 2020, at 11:57 AM, Sean Donelan  wrote:
> 
> 
> Utility markers don't get the recognition they deserve.  If they aren't
> essential workers, they should be and get hazard pay.
> 
> They help protect everyone's fiber and cables and pipes that go boom.
> 
> 

mail admins?

[William Herrin]

Howdy,,

How do we contact the nanog mail admins? I looked at
https://archive.nanog.org/list and https://archive.nanog.org/list/faq
but apparently someone thought it'd be clever to redact all the email
addresses from that page. "Questions should be directed to[email
protected]."

Thanks,
Bill Herrin


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

Re: Are underground utility markers essential workers?

[William Herrin]

On Tue, Apr 21, 2020 at 11:57 AM Sean Donelan  wrote:
> Utility markers don't get the recognition they deserve.  If they aren't
> essential workers, they should be and get hazard pay.

Hi Sean,

I agree that they're essential, but what hazard are we talking about?
The virus isn't mysteriously floating about "out there," beyond your
window. it's proximate to other people and more indoors than out.
Utility markers only rarely wound their way through crowds even when
the crowds weren't hunkered down at home.

Delivery workers, grocery workers, medical staff, I see a plausible
source of hazard there. What's the abnormal hazard to utility markers?

Regards,
Bill Herrin


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

Re: Are underground utility markers essential workers?

[Brandon Martin]

On 4/21/20 2:57 PM, Sean Donelan wrote:

Utility markers don't get the recognition they deserve.  If they aren't
essential workers, they should be and get hazard pay.

They help protect everyone's fiber and cables and pipes that go boom.


If underground construction is an essential activity (and it certainly 
is, at least repairs generally are - new construction perhaps could be 
argued), then underground utility marking is, too, since it's mandatory 
for safely performing underground construction.

--
Brandon Martin

Re: Are underground utility markers essential workers?

[Jared Mauch]

USIC is not marking on Fridays around here.

URG is marking but only 4 hours a day.

- Jared

> On Apr 21, 2020, at 4:44 PM, Jeff Shultz  wrote:
> 
> Since in our case they are Outside Plant Tech's who are assigned the
> duties as needed, they are essential workers.
> 
> On Tue, Apr 21, 2020 at 11:59 AM Sean Donelan  wrote:
>> 
>> 
>> Utility markers don't get the recognition they deserve.  If they aren't
>> essential workers, they should be and get hazard pay.
>> 
>> They help protect everyone's fiber and cables and pipes that go boom.
>> 
>> 
> 
> 
> -- 
> 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: Are underground utility markers essential workers?

[Jeff Shultz]

Since in our case they are Outside Plant Tech's who are assigned the
duties as needed, they are essential workers.

On Tue, Apr 21, 2020 at 11:59 AM Sean Donelan  wrote:
>
>
> Utility markers don't get the recognition they deserve.  If they aren't
> essential workers, they should be and get hazard pay.
>
> They help protect everyone's fiber and cables and pipes that go boom.
>
>


-- 
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: xplornet contact or any experience with their satellite service?

[Brandon Martin]

On 4/21/20 2:54 PM, Mel Beckman wrote:
> It’s not really oversold bandwidth. It’s just that the turnaround time for a 
> bolus of data is too long for two-way video conferencing to be smooth or 
> reliable. It’s like video conferencing using post cards :)

Are consumer satellite provider networks TDD or FDD?  I guess I had assumed the 
latter, but maybe not?

Assuming FDD, I don't see why the downstream needs to necessarily have problems 
with extremely long user-data-striping periods unless there's some factor I am 
just totally not considering.

The upstream is of course more of a problem.  I assume it's TDMA, and the 
terminals have imperfect clocks.
-- 
Brandon Martin

Re: xplornet contact or any experience with their satellite service?

[Brandon Martin]

On 4/21/20 2:35 PM, Brian J. Murrell wrote:
> Interesting.  So basically as Mel said, over-sold network.  :-(

This is pretty typical of consumer VSAT and such.  You can of course get better 
performance...if you're willing to pay for it.  If you find the right 
carrier/re-seller, you can perhaps find one whose "system" (to include ground 
station, terminals, and smarts on the bird) can respect DSCP and flag at least 
your voice traffic appropriately (probably EF) to perhaps lower the jitter and 
make conferencing more palatable.  Finding competent folks at a typical 
consumer provider's helpdesk to talk to about such things is probably the 
limiting factor.  The higher up the foodchain you go towards the folks who 
"own" the spectrum rather than re-sell will perhaps get you more luck on 
something like this though probably also at higher MRC.

Unfortunately, it's just what happens when you spread an already limited 
resource (transponder bandwidth) out over essentially an entire continent or at 
least substantial portions of it.  Imagine if you had a cable provider with a 
single node for an entire, say, US state.
-- 
Brandon Martin

Are underground utility markers essential workers?

[Sean Donelan]

Utility markers don't get the recognition they deserve.  If they aren't
essential workers, they should be and get hazard pay.

They help protect everyone's fiber and cables and pipes that go boom.

Re: xplornet contact or any experience with their satellite service?

[Mel Beckman]

It’s not really oversold bandwidth. It’s just that the turnaround time for a 
bolus of data is too long for two-way video conferencing to be smooth or 
reliable. It’s like video conferencing using post cards :)

 -mel 

> On Apr 21, 2020, at 11:36 AM, Brian J. Murrell  wrote:
> 
> On Tue, 2020-04-21 at 11:11 -0700, Sabri Berisha wrote:
>> Hi,
> 
> Hi,
> 
>> Where I worked, phy transmissions are scheduled based on tokens. A UT
>> must have a token to transmit data. If there is no congestion, a
>> token will be available and the UT or ground station may transmit.
>> Congestion does not need to exist in the ground network or even the
>> transponder. It can even be in the spectrum of that geographical
>> area. 
> 
> Interesting.  So basically as Mel said, over-sold network.  :-(
> 
>> To overcome the latency,
> 
> Latency (AFAIU) is not really his primary issue.  it's the lack of
> consistency in bandwidth.  Periods of a second or two even where there
> is no transmission of anything at all followed by a second or two of
> transmission bursting even beyond his subscribed "rate".  This effects
> his subscribed rate but in a really bad way for real-time traffic such
> as live/two-way video.  He'd much, much more rather get a consistent
> pipe at his prescribed rate rather than an average of it over longer
> periods of time because then the codec would not have be encoding for
> those super bad periods of time where there are 1-2 seconds of no
> bandwidth at all.
> 
>> Satellite is obviously not the optimal medium for video conferencing,
> 
> Indeed.
> 
>> but I would recommend that your friend tries to ratelimit their
>> transmissions.
> 
> He doesn't need to.  The over-congested network is doing that for him. 
> :-(  In any case, I don't know that he has any way to put a rate limit
> on the tools he is using.
> 
>> The reason why your latency is higher than you expect,
> 
> It actually isn't.  It's nowhere near as high as I had come to
> (anecdotally -- I'd never had reason to do the math on the latency
> before now) believe it would be.
> 
> Fortunately he might be a candidate for Xplornet (or others') WISP
> services.  Hopefully they are a bit more stable.
> 
> Cheers,
> b.
> 

Re: xplornet contact or any experience with their satellite service?

[Brian J. Murrell]

On Tue, 2020-04-21 at 11:11 -0700, Sabri Berisha wrote:
> Hi,

Hi,

> Where I worked, phy transmissions are scheduled based on tokens. A UT
> must have a token to transmit data. If there is no congestion, a
> token will be available and the UT or ground station may transmit.
> Congestion does not need to exist in the ground network or even the
> transponder. It can even be in the spectrum of that geographical
> area. 

Interesting.  So basically as Mel said, over-sold network.  :-(

> To overcome the latency,

Latency (AFAIU) is not really his primary issue.  it's the lack of
consistency in bandwidth.  Periods of a second or two even where there
is no transmission of anything at all followed by a second or two of
transmission bursting even beyond his subscribed "rate".  This effects
his subscribed rate but in a really bad way for real-time traffic such
as live/two-way video.  He'd much, much more rather get a consistent
pipe at his prescribed rate rather than an average of it over longer
periods of time because then the codec would not have be encoding for
those super bad periods of time where there are 1-2 seconds of no
bandwidth at all.

> Satellite is obviously not the optimal medium for video conferencing,

Indeed.

> but I would recommend that your friend tries to ratelimit their
> transmissions.

He doesn't need to.  The over-congested network is doing that for him. 
:-(  In any case, I don't know that he has any way to put a rate limit
on the tools he is using.

> The reason why your latency is higher than you expect,

It actually isn't.  It's nowhere near as high as I had come to
(anecdotally -- I'd never had reason to do the math on the latency
before now) believe it would be.

Fortunately he might be a candidate for Xplornet (or others') WISP
services.  Hopefully they are a bit more stable.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: xplornet contact or any experience with their satellite service?

[Sabri Berisha]

Hi,

I used to work for a satellite ISP, and if I'm not mistaken Xplornet is buying 
bandwidth of my previous employer. That does not mean that your friend is on 
the same service.

Where I worked, phy transmissions are scheduled based on tokens. A UT must have 
a token to transmit data. If there is no congestion, a token will be available 
and the UT or ground station may transmit. Congestion does not need to exist in 
the ground network or even the transponder. It can even be in the spectrum of 
that geographical area. 

To overcome the latency, a few things are done:

- prefetching on the UT
- WAN acceleration on the UT and in the network (basically syn/ack spoofing)

and a few other proprietary things. 

Satellite is obviously not the optimal medium for video conferencing, but I 
would recommend that your friend tries to ratelimit their transmissions.

The reason why your latency is higher than you expect, is because you expect 
latency to be equivalent to the round-trip time from earth to GEO and back. 
However, most of the time your UT will not be with the shortest line-of-sight, 
meaning the distance is longer. Also, the satellite merely acts as a smart 
mirror, and the traffic must still be backhauled from a groundstation to a 
processing location. They can also be several tens of milliseconds away. Then 
they must follow their normal path along the internet.

Ping me off-list if you have specific questions. 

Thanks, 

Sabri

- On Apr 21, 2020, at 4:58 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:

> A friend of mine just recently got Xplornet satellite service at his
> rural home.  I'm well aware of the latency issues with satellite
> although frankly his latency is much better than I had feared it would
> be and is around 600-700ms.
> 
> But what seems to be worse than the latency is the "burstiness" of the
> traffic and I am just wondering if that is normal/expected for
> satellite service in general, and/or expected from Xplornet's service,
> or if what I am seeing is not expected at all (i.e. not an artifact of
> the satellite signal but rather a network management issue).
> 
> Here's iperf3 for 30 seconds sending data (i.e. upload speed):
> 
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-1.21   sec  12.9 KBytes  87.4 Kbits/sec
> [  5]   1.21-2.00   sec  6.47 KBytes  67.2 Kbits/sec
> [  5]   2.00-3.00   sec  22.0 KBytes   180 Kbits/sec
> [  5]   3.00-4.00   sec  41.4 KBytes   339 Kbits/sec
> [  5]   4.00-5.00   sec  41.4 KBytes   339 Kbits/sec
> [  5]   5.00-6.00   sec  55.6 KBytes   456 Kbits/sec
> [  5]   6.00-7.00   sec  69.9 KBytes   572 Kbits/sec
> [  5]   7.00-8.00   sec  89.3 KBytes   731 Kbits/sec
> [  5]   8.00-9.00   sec   120 KBytes   986 Kbits/sec
> [  5]   9.00-10.00  sec  86.7 KBytes   710 Kbits/sec
> [  5]  10.00-11.00  sec   133 KBytes  1.09 Mbits/sec
> [  5]  11.00-12.00  sec   184 KBytes  1.51 Mbits/sec
> [  5]  12.00-13.00  sec   186 KBytes  1.53 Mbits/sec
> [  5]  13.00-14.00  sec   159 KBytes  1.30 Mbits/sec
> [  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec
> [  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec
> [  5]  16.00-17.00  sec  93.2 KBytes   763 Kbits/sec
> [  5]  17.00-18.00  sec   264 KBytes  2.16 Mbits/sec
> [  5]  18.00-19.00  sec   124 KBytes  1.02 Mbits/sec
> [  5]  19.00-20.00  sec   157 KBytes  1.28 Mbits/sec
> [  5]  20.00-21.00  sec   120 KBytes   986 Kbits/sec
> [  5]  21.00-22.00  sec  86.7 KBytes   710 Kbits/sec
> [  5]  22.00-23.00  sec   369 KBytes  3.02 Mbits/sec
> [  5]  23.00-24.00  sec   197 KBytes  1.61 Mbits/sec
> [  5]  24.00-25.00  sec  90.6 KBytes   741 Kbits/sec
> [  5]  25.00-26.00  sec   193 KBytes  1.58 Mbits/sec
> [  5]  26.00-27.00  sec   192 KBytes  1.57 Mbits/sec
> [  5]  27.00-28.00  sec   189 KBytes  1.55 Mbits/sec
> [  5]  28.00-29.00  sec   193 KBytes  1.58 Mbits/sec
> [  5]  29.00-30.00  sec   179 KBytes  1.46 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-32.20  sec  4.41 MBytes  1.15 Mbits/sec  388 sender
> [  5]   0.00-30.00  sec  3.57 MBytes   998 Kbits/sec  receiver
> 
> which averaged the overall prescribed "upload" speed, but notice that
> it's not 1Mb/s in any kind of a steady stream but rather bursts of
> higher than 1Mb/s speed followed by low/no speed.  At one point it was
> 2 seconds with no transfer at all even.
> 
> and here's receiving (i.e. "download"):
> 
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.35   sec  46.6 KBytes   283 Kbits/sec0   12.9 KBytes
> [  5]   1.35-2.00   sec  0.00 Bytes  0.00 bits/sec0   12.9 KBytes
> [  5]   2.00-3.00   sec  67.3 KBytes   551 Kbits/sec0   37.5 KBytes
> [  5]   3.00-4.00   sec  46.6 KBytes   382 Kbits/sec0   40.1 KBytes
> [  5]   4.00-5.00   sec   105 KBytes   858 Kbits/sec0   44.0 KBytes
> [  5]   5.00-6.00   sec  88.0 KBytes   721 Kbits/sec0   54.3 KBytes
> [  5]   

Re: "Is BGP safe yet?" test

[Andrey Kostin]

Baldur Norddahl писал 2020-04-21 02:49:


My company is in Europe. Lets say an attacker joins the IX in Seattle
a long way from here and a place we definitely are not present at. We
do however use Hurricane Electric as transit and they are peering
freely at Seattle. Everyone there thus sees our prefix with an as path
length of two. The attacker can originate the prefixes himself and
that way his fake announcements win at Seattle by having the length 1.
With RPKI he needs to use our ASN to originate and have his own ASN in
between to facilitate peering.  Thus the fake path also has the length
of two. The real announcement wins by virtue of being the oldest
announcement and the attack fails.

The situation is even worse for the attacker if he needs an IP transit
company to pick up the fake announcement. We have Telia, which filters
invalids, and if the attacker tries to get his fake prefix picked up
by them, his path will end up being one longer than ours, so he can
never succeed.

There are of course plenty of situations where the attack still
succeeds. I am not claiming this is a magical bullet. Just saying it
might do more than some thinks it will. Definitely better than
nothing.



I think that for peering sessions regular filters can do their job more 
directly and effectively. But I see that discussion moved away from 
initial topic to general dispute about RPKI usefullness. The initial 
topic though initially was about public web page that claimes your 
network secure or insecure based on evaluation of only one technology 
checking one particular specially crafted prefix.


Kind regards,
Andrey

Re: xplornet contact or any experience with their satellite service?

[Adam Thompson]

Although I don't know of a way to solve this for videoconferencing, 
historically one way to mitigate the radio/vsat "batchiness" issue and its 
effect on end-to-end latency was to use a caching proxy server connected to a, 
er, "real" network somewhere, preferably as near as possible to the 
headend/uplink station.  The modern web's move to TLS also means this technique 
is becoming pointless even for HTTP/S (although MITMing remains a way around 
that - many a HOWTO abounds, describing how to do this with Squid).


FWIW, some very old radio systems behaved similarly... albeit not with 600+msec 
latency :-/.  Some of the really old asymmetric TV systems (dial-up for uplink, 
CATV for downlink) exhibited similar characteristics and were similarly 
difficult to mitigate.


Good luck!


Adam Thompson
Consultant, Infrastructure Services
[[MERLIN LOGO]]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca


From: NANOG  on behalf of Mel Beckman 

Sent: Tuesday, April 21, 2020 9:05:20 AM
To: Brian J. Murrell
Cc: nanog@nanog.org
Subject: Re: xplornet contact or any experience with their satellite service?

Brian,

Satellite services are shared bandwidth broadcast systems. The behavior you’re 
seeing is pretty common at times when you’re competing for access with other 
users. Just like the regular Internet, there are times of day when people tend 
to move more data, and because of latency and other limitations on 
bidirectional traffic, packets get delivered in batches. It’s not possible to 
interleave bytes, or even packets themselves.

So when you see low or no throughput, it’s because the transponder is 
addressing packets to other users.

 -mel beckman

> On Apr 21, 2020, at 6:53 AM, Brian J. Murrell  wrote:
>
> A friend of mine just recently got Xplornet satellite service at his
> rural home.  I'm well aware of the latency issues with satellite
> although frankly his latency is much better than I had feared it would
> be and is around 600-700ms.
>
> But what seems to be worse than the latency is the "burstiness" of the
> traffic and I am just wondering if that is normal/expected for
> satellite service in general, and/or expected from Xplornet's service,
> or if what I am seeing is not expected at all (i.e. not an artifact of
> the satellite signal but rather a network management issue).
>
> Here's iperf3 for 30 seconds sending data (i.e. upload speed):
>
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-1.21   sec  12.9 KBytes  87.4 Kbits/sec
> [  5]   1.21-2.00   sec  6.47 KBytes  67.2 Kbits/sec
> [  5]   2.00-3.00   sec  22.0 KBytes   180 Kbits/sec
> [  5]   3.00-4.00   sec  41.4 KBytes   339 Kbits/sec
> [  5]   4.00-5.00   sec  41.4 KBytes   339 Kbits/sec
> [  5]   5.00-6.00   sec  55.6 KBytes   456 Kbits/sec
> [  5]   6.00-7.00   sec  69.9 KBytes   572 Kbits/sec
> [  5]   7.00-8.00   sec  89.3 KBytes   731 Kbits/sec
> [  5]   8.00-9.00   sec   120 KBytes   986 Kbits/sec
> [  5]   9.00-10.00  sec  86.7 KBytes   710 Kbits/sec
> [  5]  10.00-11.00  sec   133 KBytes  1.09 Mbits/sec
> [  5]  11.00-12.00  sec   184 KBytes  1.51 Mbits/sec
> [  5]  12.00-13.00  sec   186 KBytes  1.53 Mbits/sec
> [  5]  13.00-14.00  sec   159 KBytes  1.30 Mbits/sec
> [  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec
> [  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec
> [  5]  16.00-17.00  sec  93.2 KBytes   763 Kbits/sec
> [  5]  17.00-18.00  sec   264 KBytes  2.16 Mbits/sec
> [  5]  18.00-19.00  sec   124 KBytes  1.02 Mbits/sec
> [  5]  19.00-20.00  sec   157 KBytes  1.28 Mbits/sec
> [  5]  20.00-21.00  sec   120 KBytes   986 Kbits/sec
> [  5]  21.00-22.00  sec  86.7 KBytes   710 Kbits/sec
> [  5]  22.00-23.00  sec   369 KBytes  3.02 Mbits/sec
> [  5]  23.00-24.00  sec   197 KBytes  1.61 Mbits/sec
> [  5]  24.00-25.00  sec  90.6 KBytes   741 Kbits/sec
> [  5]  25.00-26.00  sec   193 KBytes  1.58 Mbits/sec
> [  5]  26.00-27.00  sec   192 KBytes  1.57 Mbits/sec
> [  5]  27.00-28.00  sec   189 KBytes  1.55 Mbits/sec
> [  5]  28.00-29.00  sec   193 KBytes  1.58 Mbits/sec
> [  5]  29.00-30.00  sec   179 KBytes  1.46 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-32.20  sec  4.41 MBytes  1.15 Mbits/sec  388 sender
> [  5]   0.00-30.00  sec  3.57 MBytes   998 Kbits/sec  receiver
>
> which averaged the overall prescribed "upload" speed, but notice that
> it's not 1Mb/s in any kind of a steady stream but rather bursts of
> higher than 1Mb/s speed followed by low/no speed.  At one point it was
> 2 seconds with no transfer at all even.
>
> and here's receiving (i.e. "download"):
>
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.35   sec  46.6 KBytes   283 Kbits/sec0   12.9 KBytes
> [  5]   1.35-2.00  

Re: "Is BGP safe yet?" test

[Matt Corallo via NANOG]

Sure. This kinda falls under my point that we should be talking about basic 
mitigation, then. I’m not aware of any previous discussion of creating policy 
that instructs RIRs to do so. Again, with a basic step like that, plus a 
validator-enforced time delay between when a RIR can remove a ROA for some IP 
space and when it can be replaced, RPKI would be drastically de-risked. Once 
you start going down that road, there would be way more desire on the part of 
OFAC and other small committees to enforce policy using other levers.

> On Apr 21, 2020, at 09:36, Rubens Kuhl  wrote:
> 
> 
> 
> 
>> On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG  
>> wrote:
>> That’s an interesting idea. I’m not sure that LACNIC would want to issue a 
>> ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at 
>> least need some kind of time delay to give other RIRs and operators and 
>> chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg 
>> in my example mitigation strategy.
>> 
> 
> All 5 RIRs can issue ROAs for all the IP address spaces. They don't as a 
> matter of coordinated operations, but that doesn't prevent court orders 
> determining that to be done. 
> 
> 
> Rubens
>  

Re: "Is BGP safe yet?" test

[Rubens Kuhl]

On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG 
wrote:

> That’s an interesting idea. I’m not sure that LACNIC would want to issue a
> ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at
> least need some kind of time delay to give other RIRs and operators and
> chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg
> in my example mitigation strategy.
>
>
All 5 RIRs can issue ROAs for all the IP address spaces. They don't as a
matter of coordinated operations, but that doesn't prevent court orders
determining that to be done.


Rubens

Re: "Is BGP safe yet?" test

[Christopher Morrow]

On Tue, Apr 21, 2020 at 12:17 PM Matt Corallo via NANOG  wrote:
>
> Not sure how this helps? If RIPE (or a government official/court) decides the 
> sanctions against Iranian LIRs prevents them from issuing number resources to 
> said LIRs, they would just remove the delegation. They’d probably then issue 
> an AS0 ROA to replace out given the “AS0 ROA for bogons” policy. In an hour 
> or so these LIRs are now disconnected from the world.
>

1) there are other ways the black helicopter people can do their
business, this is but one new lever.
2) this is the sort of thing that local TAL / SLURM are meant to help 'fix'.
3) see the long discussions of this in the sidr/sidr-ops wg lists :(

> > On Apr 21, 2020, at 02:30, Alex Band  wrote:
> >
> > 
> >> On 21 Apr 2020, at 11:09, Baldur Norddahl  
> >> wrote:
> >>
> >>
> >>
> >>> On 21.04.2020 10.56, Sander Steffann wrote:
> >>> Hi,
> >>>
>  Removing a resource from the certificate to achieve the goal you 
>  describe will make the route announcement NotFound, which means it will 
>  be accepted. Evil RIR would have to replace an existing ROA with one 
>  that explicitly makes a route invalid, i.e. issue an AS0 ROA for 
>  specific member prefix. This seems like a pretty convoluted way to try 
>  and take a network offline.
> >>> I've seen worse…
> >>> Sander
> >>>
> >>
> >> As long Good RIR continues to publish a valid ROA for the real ASN that 
> >> evil AS0 ROA would have no effect?
> >
> > Correct.
> >
> > Should this really be a concern, then you can run Delegated RPKI. In that 
> > case the RIR can’t tamper with your ROA because it’s not on their systems. 
> > Evil RIR could only revoke a prefix from your certificate or your entire 
> > certificate, but again, your BGP announcements would fall back to NotFound 
> > and would be accepted.
> >
> > -Alex
>

Re: "Is BGP safe yet?" test

[Matt Corallo via NANOG]

Not sure how this helps? If RIPE (or a government official/court) decides the 
sanctions against Iranian LIRs prevents them from issuing number resources to 
said LIRs, they would just remove the delegation. They’d probably then issue an 
AS0 ROA to replace out given the “AS0 ROA for bogons” policy. In an hour or so 
these LIRs are now disconnected from the world.

> On Apr 21, 2020, at 02:30, Alex Band  wrote:
> 
> 
>> On 21 Apr 2020, at 11:09, Baldur Norddahl  wrote:
>> 
>> 
>> 
>>> On 21.04.2020 10.56, Sander Steffann wrote:
>>> Hi,
>>> 
 Removing a resource from the certificate to achieve the goal you describe 
 will make the route announcement NotFound, which means it will be 
 accepted. Evil RIR would have to replace an existing ROA with one that 
 explicitly makes a route invalid, i.e. issue an AS0 ROA for specific 
 member prefix. This seems like a pretty convoluted way to try and take a 
 network offline.
>>> I've seen worse…
>>> Sander
>>> 
>> 
>> As long Good RIR continues to publish a valid ROA for the real ASN that evil 
>> AS0 ROA would have no effect?
> 
> Correct.
> 
> Should this really be a concern, then you can run Delegated RPKI. In that 
> case the RIR can’t tamper with your ROA because it’s not on their systems. 
> Evil RIR could only revoke a prefix from your certificate or your entire 
> certificate, but again, your BGP announcements would fall back to NotFound 
> and would be accepted.
> 
> -Alex

Re: "Is BGP safe yet?" test

[Matt Corallo via NANOG]

Right until RIPE finishes deploying AS0 ROAs for bogons, which I recall is 
moving forward :p.

> On Apr 21, 2020, at 03:01, Mark Tinka  wrote:
> 
> 
> 
>> On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:
>> 
>> Instead of RIRs coordinating address space use by keeping a public list 
>> which is (or should be) checked when a new peering session is added, RPKI 
>> shifts RIRs into the hot path of routing updates. Next time the US 
>> government decides some bad, bad, very bad country should be cut off from 
>> the world with viral sanctions, there’s a new tool available - by simply 
>> editing a database, every border router in the world will refuse to talk to 
>> $EVIL.
> 
> This keeps coming up.
> 
> If a ROA disappears, RPKI state reverts to NotFound. Unless dropping
> "NotFound" is now BCP, I think we'll be okay.
> 
> Mark.

Re: "Is BGP safe yet?" test

[Matt Corallo via NANOG]

That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA 
for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need 
some kind of time delay to give other RIRs and operators and chance to discuss 
the matter before allowing RIPE to issue the AS0 ROA, eg in my example 
mitigation strategy.

> On Apr 21, 2020, at 02:10, Baldur Norddahl  wrote:
> 
> 
> 
>> On 21.04.2020 10.56, Sander Steffann wrote:
>> Hi,
>> 
>>> Removing a resource from the certificate to achieve the goal you describe 
>>> will make the route announcement NotFound, which means it will be accepted. 
>>> Evil RIR would have to replace an existing ROA with one that explicitly 
>>> makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. 
>>> This seems like a pretty convoluted way to try and take a network offline.
>> I've seen worse…
>> Sander
>> 
> 
> As long Good RIR continues to publish a valid ROA for the real ASN that evil 
> AS0 ROA would have no effect?
> 
> Regards,
> 
> Baldur
> 

Re: Spike in traffic to Google caches?

[Töma Gavrichenkov]

Peace,

On Tue, Apr 21, 2020 at 3:57 PM Hank Nussbacher  wrote:
> Did anyone notice a huge jump in traffic today between 11:30-11:40 (GMT)
> directed at Google and Akamai caches coming from Amazon and Google?
> Gaming updates?

There's sort of a reason these days to subscribe to the Steam and
Activision blogs.
E.g. "Call of Duty: Modern Warfare" just got back its classic "Cranked
game mode" yesterday (whatever that means).

--
Töma

Re: Spike in traffic to Google caches?

[Jared Mauch]

> On Apr 21, 2020, at 8:56 AM, Hank Nussbacher  wrote:
> 
> Did anyone notice a huge jump in traffic today between 11:30-11:40 (GMT) 
> directed at Google and Akamai caches coming from Amazon and Google?
> Gaming updates?
> 

I’m not seeing any big spikes in our graphs, but what you are describing may be 
the caches going forward to our customer origin or similar.

If anyone else is seeing something similar or has concerns you can reach me 
off-list.

Hank, can you send me the IPs of your cluster in private to speed up triage?

- Jared

Re: xplornet contact or any experience with their satellite service?

[Mel Beckman]

Brian,

Satellite services are shared bandwidth broadcast systems. The behavior you’re 
seeing is pretty common at times when you’re competing for access with other 
users. Just like the regular Internet, there are times of day when people tend 
to move more data, and because of latency and other limitations on 
bidirectional traffic, packets get delivered in batches. It’s not possible to 
interleave bytes, or even packets themselves. 

So when you see low or no throughput, it’s because the transponder is 
addressing packets to other users.

 -mel beckman

> On Apr 21, 2020, at 6:53 AM, Brian J. Murrell  wrote:
> 
> A friend of mine just recently got Xplornet satellite service at his
> rural home.  I'm well aware of the latency issues with satellite
> although frankly his latency is much better than I had feared it would
> be and is around 600-700ms.
> 
> But what seems to be worse than the latency is the "burstiness" of the
> traffic and I am just wondering if that is normal/expected for
> satellite service in general, and/or expected from Xplornet's service,
> or if what I am seeing is not expected at all (i.e. not an artifact of
> the satellite signal but rather a network management issue).
> 
> Here's iperf3 for 30 seconds sending data (i.e. upload speed):
> 
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-1.21   sec  12.9 KBytes  87.4 Kbits/sec  
> [  5]   1.21-2.00   sec  6.47 KBytes  67.2 Kbits/sec  
> [  5]   2.00-3.00   sec  22.0 KBytes   180 Kbits/sec  
> [  5]   3.00-4.00   sec  41.4 KBytes   339 Kbits/sec  
> [  5]   4.00-5.00   sec  41.4 KBytes   339 Kbits/sec  
> [  5]   5.00-6.00   sec  55.6 KBytes   456 Kbits/sec  
> [  5]   6.00-7.00   sec  69.9 KBytes   572 Kbits/sec  
> [  5]   7.00-8.00   sec  89.3 KBytes   731 Kbits/sec  
> [  5]   8.00-9.00   sec   120 KBytes   986 Kbits/sec  
> [  5]   9.00-10.00  sec  86.7 KBytes   710 Kbits/sec  
> [  5]  10.00-11.00  sec   133 KBytes  1.09 Mbits/sec  
> [  5]  11.00-12.00  sec   184 KBytes  1.51 Mbits/sec  
> [  5]  12.00-13.00  sec   186 KBytes  1.53 Mbits/sec  
> [  5]  13.00-14.00  sec   159 KBytes  1.30 Mbits/sec  
> [  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec  
> [  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec  
> [  5]  16.00-17.00  sec  93.2 KBytes   763 Kbits/sec  
> [  5]  17.00-18.00  sec   264 KBytes  2.16 Mbits/sec  
> [  5]  18.00-19.00  sec   124 KBytes  1.02 Mbits/sec  
> [  5]  19.00-20.00  sec   157 KBytes  1.28 Mbits/sec  
> [  5]  20.00-21.00  sec   120 KBytes   986 Kbits/sec  
> [  5]  21.00-22.00  sec  86.7 KBytes   710 Kbits/sec  
> [  5]  22.00-23.00  sec   369 KBytes  3.02 Mbits/sec  
> [  5]  23.00-24.00  sec   197 KBytes  1.61 Mbits/sec  
> [  5]  24.00-25.00  sec  90.6 KBytes   741 Kbits/sec  
> [  5]  25.00-26.00  sec   193 KBytes  1.58 Mbits/sec  
> [  5]  26.00-27.00  sec   192 KBytes  1.57 Mbits/sec  
> [  5]  27.00-28.00  sec   189 KBytes  1.55 Mbits/sec  
> [  5]  28.00-29.00  sec   193 KBytes  1.58 Mbits/sec  
> [  5]  29.00-30.00  sec   179 KBytes  1.46 Mbits/sec  
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-32.20  sec  4.41 MBytes  1.15 Mbits/sec  388 sender
> [  5]   0.00-30.00  sec  3.57 MBytes   998 Kbits/sec  receiver
> 
> which averaged the overall prescribed "upload" speed, but notice that
> it's not 1Mb/s in any kind of a steady stream but rather bursts of
> higher than 1Mb/s speed followed by low/no speed.  At one point it was
> 2 seconds with no transfer at all even.
> 
> and here's receiving (i.e. "download"):
> 
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.35   sec  46.6 KBytes   283 Kbits/sec0   12.9 KBytes   
> [  5]   1.35-2.00   sec  0.00 Bytes  0.00 bits/sec0   12.9 KBytes   
> [  5]   2.00-3.00   sec  67.3 KBytes   551 Kbits/sec0   37.5 KBytes   
> [  5]   3.00-4.00   sec  46.6 KBytes   382 Kbits/sec0   40.1 KBytes   
> [  5]   4.00-5.00   sec   105 KBytes   858 Kbits/sec0   44.0 KBytes   
> [  5]   5.00-6.00   sec  88.0 KBytes   721 Kbits/sec0   54.3 KBytes   
> [  5]   6.00-7.00   sec   141 KBytes  1.16 Mbits/sec0   69.9 KBytes   
> [  5]   7.00-8.00   sec   124 KBytes  1.02 Mbits/sec0101 KBytes   
> [  5]   8.00-9.00   sec   186 KBytes  1.53 Mbits/sec0146 KBytes   
> [  5]   9.00-10.00  sec   248 KBytes  2.04 Mbits/sec0206 KBytes   
> [  5]  10.00-11.00  

xplornet contact or any experience with their satellite service?

[Brian J. Murrell]

A friend of mine just recently got Xplornet satellite service at his
rural home.  I'm well aware of the latency issues with satellite
although frankly his latency is much better than I had feared it would
be and is around 600-700ms.

But what seems to be worse than the latency is the "burstiness" of the
traffic and I am just wondering if that is normal/expected for
satellite service in general, and/or expected from Xplornet's service,
or if what I am seeing is not expected at all (i.e. not an artifact of
the satellite signal but rather a network management issue).

Here's iperf3 for 30 seconds sending data (i.e. upload speed):

[ ID] Interval   Transfer Bitrate
[  5]   0.00-1.21   sec  12.9 KBytes  87.4 Kbits/sec  
[  5]   1.21-2.00   sec  6.47 KBytes  67.2 Kbits/sec  
[  5]   2.00-3.00   sec  22.0 KBytes   180 Kbits/sec  
[  5]   3.00-4.00   sec  41.4 KBytes   339 Kbits/sec  
[  5]   4.00-5.00   sec  41.4 KBytes   339 Kbits/sec  
[  5]   5.00-6.00   sec  55.6 KBytes   456 Kbits/sec  
[  5]   6.00-7.00   sec  69.9 KBytes   572 Kbits/sec  
[  5]   7.00-8.00   sec  89.3 KBytes   731 Kbits/sec  
[  5]   8.00-9.00   sec   120 KBytes   986 Kbits/sec  
[  5]   9.00-10.00  sec  86.7 KBytes   710 Kbits/sec  
[  5]  10.00-11.00  sec   133 KBytes  1.09 Mbits/sec  
[  5]  11.00-12.00  sec   184 KBytes  1.51 Mbits/sec  
[  5]  12.00-13.00  sec   186 KBytes  1.53 Mbits/sec  
[  5]  13.00-14.00  sec   159 KBytes  1.30 Mbits/sec  
[  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec  
[  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec  
[  5]  16.00-17.00  sec  93.2 KBytes   763 Kbits/sec  
[  5]  17.00-18.00  sec   264 KBytes  2.16 Mbits/sec  
[  5]  18.00-19.00  sec   124 KBytes  1.02 Mbits/sec  
[  5]  19.00-20.00  sec   157 KBytes  1.28 Mbits/sec  
[  5]  20.00-21.00  sec   120 KBytes   986 Kbits/sec  
[  5]  21.00-22.00  sec  86.7 KBytes   710 Kbits/sec  
[  5]  22.00-23.00  sec   369 KBytes  3.02 Mbits/sec  
[  5]  23.00-24.00  sec   197 KBytes  1.61 Mbits/sec  
[  5]  24.00-25.00  sec  90.6 KBytes   741 Kbits/sec  
[  5]  25.00-26.00  sec   193 KBytes  1.58 Mbits/sec  
[  5]  26.00-27.00  sec   192 KBytes  1.57 Mbits/sec  
[  5]  27.00-28.00  sec   189 KBytes  1.55 Mbits/sec  
[  5]  28.00-29.00  sec   193 KBytes  1.58 Mbits/sec  
[  5]  29.00-30.00  sec   179 KBytes  1.46 Mbits/sec  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-32.20  sec  4.41 MBytes  1.15 Mbits/sec  388 sender
[  5]   0.00-30.00  sec  3.57 MBytes   998 Kbits/sec  receiver

which averaged the overall prescribed "upload" speed, but notice that
it's not 1Mb/s in any kind of a steady stream but rather bursts of
higher than 1Mb/s speed followed by low/no speed.  At one point it was
2 seconds with no transfer at all even.

and here's receiving (i.e. "download"):

[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.35   sec  46.6 KBytes   283 Kbits/sec0   12.9 KBytes   
[  5]   1.35-2.00   sec  0.00 Bytes  0.00 bits/sec0   12.9 KBytes   
[  5]   2.00-3.00   sec  67.3 KBytes   551 Kbits/sec0   37.5 KBytes   
[  5]   3.00-4.00   sec  46.6 KBytes   382 Kbits/sec0   40.1 KBytes   
[  5]   4.00-5.00   sec   105 KBytes   858 Kbits/sec0   44.0 KBytes   
[  5]   5.00-6.00   sec  88.0 KBytes   721 Kbits/sec0   54.3 KBytes   
[  5]   6.00-7.00   sec   141 KBytes  1.16 Mbits/sec0   69.9 KBytes   
[  5]   7.00-8.00   sec   124 KBytes  1.02 Mbits/sec0101 KBytes   
[  5]   8.00-9.00   sec   186 KBytes  1.53 Mbits/sec0146 KBytes   
[  5]   9.00-10.00  sec   248 KBytes  2.04 Mbits/sec0206 KBytes   
[  5]  10.00-11.00  sec   311 KBytes  2.54 Mbits/sec0257 KBytes   
[  5]  11.00-12.00  sec  0.00 Bytes  0.00 bits/sec   43194 KBytes   
[  5]  12.00-13.00  sec  0.00 Bytes  0.00 bits/sec   75199 KBytes   
[  5]  13.00-14.00  sec   435 KBytes  3.56 Mbits/sec0199 KBytes   
[  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec   34114 KBytes   
[  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec   34140 KBytes   
[  5]  16.00-17.00  sec   373 KBytes  3.05 Mbits/sec0149 KBytes   
[  5]  17.00-18.00  sec  0.00 Bytes  0.00 bits/sec0162 KBytes   
[  5]  18.00-19.00  sec   373 KBytes  3.05 Mbits/sec0168 KBytes   
[  5]  19.00-20.00  sec  0.00 Bytes  0.00 bits/sec0171 KBytes   
[  

SINGLEHOP-LLC AS32475 - Contact

[James Braunegg]

Dear All

Does anyone have a contact at SingleHop AS32475 which you can share with me ?

Looking for someone who is responsible for BGP / Routing / AS Path etc ?

Looking forward to hearing from you

Kindest Regards

James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com

www.micron21.com/


[cid:image002.png@01D280A4.01865B60]


[cid:image003.png@01D280A4.01865B60]

[cid:image004.png@01D280A4.01865B60]

Follow us on Twitter for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

Spike in traffic to Google caches?

[Hank Nussbacher]

Did anyone notice a huge jump in traffic today between 11:30-11:40 (GMT) 
directed at Google and Akamai caches coming from Amazon and Google?

Gaming updates?

Thanks,
Hank
Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer

Re: "Is BGP safe yet?" test

[Randy Bush]

>> essentially agree.  my pedantic quibble is that i would like to
>> differentiate between the RPKI, which is a database, and ROV, which
>> uses it.
> 
> And I think that is a very important distinction to be clear about.
> Right now, it's not completely arrest-worthy to use RPKI and ROV
> interchangeably, but I think considering that other use-cases might
> come from the database itself in the future, being explicit about it
> and how it can be used is appropriate pedantry.

i have been pushing this rock uphill for over a decade.  to expand, a
bit of text from long ago, so hence a bit out of date, but still clear

RPKI

The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent
with the internet IP address allocation administration, the IANA,
RIRs, ISPs, ...  It is just a database, but is the substrate on
which the next two mechanisms are based.  It is currently deployed
in all five administrative regions.

RPKI-based Origin Validation (ROV)

RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data
to allow a router to verify that the autonomous system originating
an IP address prefix is in fact authorized to do so.  This is not
crypto checked so can be violated.  But it should prevent the vast
majority of accidental 'hijackings' on the internet today, e.g. the
famous Pakistani accidental announcement of YouTube's address space.
RPKI-based origin validation is in shipping code from AlcaLu, Cisco,
Juniper, and possibly others.

BGPsec

RPKI-based Path Validation, AKA BGPsec, a future technology still
being designed [draft-ietf-sidr-bgpsec-overview], uses the full
crypto information of the RPKI to make up for the embarrassing
mistake that, like much of the internet BGP was designed with no
thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to
cryptographically validate that the autonomous systems through which
the announcement passed were indeed those which the sender/forwarder
at each hop intended.

currently, bgosec still has no traction.  there are other proposals in
the space, e.g. ASPA.  but the point is that they USE the rpki, they are
not the rpki.

randy

Re: "Is BGP safe yet?" test

[Mark Tinka]

On 21/Apr/20 12:46, Randy Bush wrote:

> essentially agree.  my pedantic quibble is that i would like to
> differentiate between the RPKI, which is a database, and ROV, which
> uses it.

And I think that is a very important distinction to be clear about.
Right now, it's not completely arrest-worthy to use RPKI and ROV
interchangeably, but I think considering that other use-cases might come
from the database itself in the future, being explicit about it and how
it can be used is appropriate pedantry.

Mark.

Re: "Is BGP safe yet?" test

[Randy Bush]

> Anyhow I think some people think about RPKI in a way too binary manner
> 'because it is not secure, it is not useful'. Yes, AS_PATH
> authenticity is an open problem, but this doesn't mean RPKI is
> useless. Most of our BGP outages are not malicious, RPKI helps a lot
> there and RPKI creates a higher quality database for prefix origin
> information than what we have had.

essentially agree.  my pedantic quibble is that i would like to
differentiate between the RPKI, which is a database, and ROV, which
uses it.

randy

Re: "Is BGP safe yet?" test

[Mark Tinka]

On 20/Apr/20 20:21, Andrey Kostin wrote:

>  
> So this means that there is no single source of truth for PRKI
> implementation all around the world and there are different shades,
> right? As a logical conclusion, the information provided on that page
> may be considered incorrect in terms of proclaiming particular network
> safe or not safe, but when it's claimed (sometimes blatantly) we now
> have to prove to our clients that we are not bad guys.

Years ago, there was talk about giving it to the IANA.

Mark.

Re: "Is BGP safe yet?" test

[Mark Tinka]

On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:

> Instead of RIRs coordinating address space use by keeping a public list which 
> is (or should be) checked when a new peering session is added, RPKI shifts 
> RIRs into the hot path of routing updates. Next time the US government 
> decides some bad, bad, very bad country should be cut off from the world with 
> viral sanctions, there’s a new tool available - by simply editing a database, 
> every border router in the world will refuse to talk to $EVIL.

This keeps coming up.

If a ROA disappears, RPKI state reverts to NotFound. Unless dropping
"NotFound" is now BCP, I think we'll be okay.

Mark.

Re: "Is BGP safe yet?" test

[Alex Band]

> On 21 Apr 2020, at 11:09, Baldur Norddahl  wrote:
> 
> 
> 
> On 21.04.2020 10.56, Sander Steffann wrote:
>> Hi,
>> 
>>> Removing a resource from the certificate to achieve the goal you describe 
>>> will make the route announcement NotFound, which means it will be accepted. 
>>> Evil RIR would have to replace an existing ROA with one that explicitly 
>>> makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. 
>>> This seems like a pretty convoluted way to try and take a network offline.
>> I've seen worse…
>> Sander
>> 
> 
> As long Good RIR continues to publish a valid ROA for the real ASN that evil 
> AS0 ROA would have no effect?

Correct.

Should this really be a concern, then you can run Delegated RPKI. In that case 
the RIR can’t tamper with your ROA because it’s not on their systems. Evil RIR 
could only revoke a prefix from your certificate or your entire certificate, 
but again, your BGP announcements would fall back to NotFound and would be 
accepted.

-Alex

Re: "Is BGP safe yet?" test

[Baldur Norddahl]

On 21.04.2020 10.56, Sander Steffann wrote:

Hi,


Removing a resource from the certificate to achieve the goal you describe will 
make the route announcement NotFound, which means it will be accepted. Evil RIR 
would have to replace an existing ROA with one that explicitly makes a route 
invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a 
pretty convoluted way to try and take a network offline.

I've seen worse…
Sander



As long Good RIR continues to publish a valid ROA for the real ASN that 
evil AS0 ROA would have no effect?


Regards,

Baldur

Re: "Is BGP safe yet?" test

[Baldur Norddahl]

There are in fact five anchors. I am not sure ARIN would be able to stop 
anyone holding RIPE space provided the resource holder uses RIPE RPKI 
anchor for publishing his ROAs.


Regards,

Baldur


On 21.04.2020 08.51, Matt Corallo via NANOG wrote:

I find it fascinating that in this entire thread about the nature of RPKI the 
shift in the role of the RIR hasn’t come up.

Instead of RIRs coordinating address space use by keeping a public list which 
is (or should be) checked when a new peering session is added, RPKI shifts RIRs 
into the hot path of routing updates. Next time the US government decides some 
bad, bad, very bad country should be cut off from the world with viral 
sanctions, there’s a new tool available - by simply editing a database, every 
border router in the world will refuse to talk to $EVIL.

By no means am I suggesting we should stop the RPKI train (and AS397444 happily 
drops invalids and has ROAs for all prefixes), but there’s a very cost here 
that doesn’t appear to have gotten much love, let alone mitigation effort. In 
the context of RIPE having to ask for permission to keep receiving payments 
from several Iranian LIRs, this isn’t completely inconceivable.

By way of an example, something like a waiting period for RIRs to add new ROAs 
replacing removed ROAs (which would imply some kind of signed replacement, but 
you get the point). At least ARIN already has a several-month quieting period 
after yanking resources for non-payment, why not use that to give operators 
time to think about whether they mind talking to Iran?

/ducks

Matt


On Apr 20, 2020, at 08:10, Andrey Kostin  wrote:

Hi Nanog list,

Would be interesting to hear your opinion on this:
https://isbgpsafeyet.com/

We have cases when residential customers ask support "why is your service isn't 
safe?" pointing to that article. It's difficult to answer correctly considering that 
the asking person usually doesn't know what BGP is and what it's used for, save for 
understanding it's function, design and possible misuses.
IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other 
hand is this a proper way for it? How ethical is to claim other market players 
unsafe, considering that scope of possible impact of not implementing it has 
completely different scale for a small stub network and big transit provider?

Kind regards,
Andrey

Re: "Is BGP safe yet?" test

[Sander Steffann]

Hi,

> Removing a resource from the certificate to achieve the goal you describe 
> will make the route announcement NotFound, which means it will be accepted. 
> Evil RIR would have to replace an existing ROA with one that explicitly makes 
> a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems 
> like a pretty convoluted way to try and take a network offline.

I've seen worse…
Sander



signature.asc
Description: Message signed with OpenPGP

Re: "Is BGP safe yet?" test

[Baldur Norddahl]

tir. 21. apr. 2020 07.38 skrev Saku Ytti :

> On Tue, 21 Apr 2020 at 01:02, Baldur Norddahl 
> wrote:
>
> > Yes but that makes the hijacked AS path length at least 1 longer which
> makes it less likely that it can win over the true announcement. It is
> definitely better than nothing.
>
> Attacker has no incentive to honor existing AS path, attacker can
> rewrite it as they wish.
>

My company is in Europe. Lets say an attacker joins the IX in Seattle a
long way from here and a place we definitely are not present at. We do
however use Hurricane Electric as transit and they are peering freely at
Seattle. Everyone there thus sees our prefix with an as path length of two.
The attacker can originate the prefixes himself and that way his fake
announcements win at Seattle by having the length 1. With RPKI he needs to
use our ASN to originate and have his own ASN in between to facilitate
peering.  Thus the fake path also has the length of two. The real
announcement wins by virtue of being the oldest announcement and the attack
fails.

The situation is even worse for the attacker if he needs an IP transit
company to pick up the fake announcement. We have Telia, which filters
invalids, and if the attacker tries to get his fake prefix picked up by
them, his path will end up being one longer than ours, so he can never
succeed.

There are of course plenty of situations where the attack still succeeds. I
am not claiming this is a magical bullet. Just saying it might do more than
some thinks it will. Definitely better than nothing.

Regards
Baldur