Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Eric Kuhnke]

The press release doesn't reference at all, but Aeronet (the largest WISP
in Puerto Rico, and an operator of gigabit class service in MDUs) has been
testing Facebook/Terragraph 802.11ay 60 GHz based, point to multipoint last
mile stuff for a while now. Very short range, high speed, high capacity.

They use it in addition to a number of licensed band and 71-86 GHz PTP
links.

https://www.peeringdb.com/net/20459

Various 802.11ay based PtMP solutions are about to hit the market from 4 or
5 different competing vendors.





On Mon, Nov 2, 2020 at 8:22 AM Sean Donelan  wrote:

>
> FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband
> Service As A Result Of Uniendo A Puerto Rico Fund
>
> Nearly a Third of Locations Will Get Speeds of At Least 1 Gbps with All
> Other Locations Getting Speeds of At Least 100 Mbps
>
>
> https://www.fcc.gov/document/fcc-announces-usf-support-high-speed-broadband-puerto-rico
>
> WASHINGTON, November 2, 2020—The Federal Communications Commission’s
> Wireline Competition Bureau today announced that funding through Stage 2
> of the Uniendo a Puerto Rico Fund will result in all locations in Puerto
> Rico having access to fixed broadband service
> with speeds of at least 100 Mbps. And nearly one-third of those locations
> will have access to fixed broadband service with speeds of at least 1
> Gbps.
>
> Two winning applicants in the Uniendo a Puerto Rico Stage 2 Competitive
> Process submitted bids for $127.1 million in funding over 10 years
> covering more than 1.2 million locations through a competitive process
> that awarded support for fixed voice and broadband services based on the
> weighting of price and network performance, including speed, latency,
> usage allowance, and resiliency. Liberty Communications has committed to
> offering service to over 914,000 locations, and Puerto Rico Telephone
> Company will offer service to over 308,000 locations.
>

PeeringDB Satisfaction Survey open now til November 20th

[Steve McManus]

PeeringDB is a non-profit, freely available, user-maintained, database of 
networks, and the go-to location for interconnection data. The database 
facilitates the global interconnection of networks at Internet Exchange Points 
(IXPs), data centers, and other interconnection facilities, and is the first 
stop in making interconnection decisions.

We want input from network operators, exchange operators, facility providers, 
content distributors and anyone who uses our interconnection database. This 
year we are running an anonymous satisfaction survey in addition to the usual 
feedback gathering we employ.

The survey will be available here: 
  https://surveyhero.com/c/f7be5236  

until 23:59 UTC on 20 November 2020.

We would like your feedback to help us make PeeringDB more useful to everyone 
involved in connecting networks.This survey will help us understand what is 
important to you and how satisfied you are with what we are doing. We will use 
your responses to focus our product roadmap on the improvements that will make 
things better for you. If you have specific comments or suggestions, we’d love 
you to leave them along with your ratings.

This is the first survey we are making available in multiple languages. In this 
survey we are using the six UN languages for the questions. That said, we’re 
happy with people providing free text comments in another whichever language 
they are happiest expressing themselves.

We’ll share the results and the new product roadmap early in 2021.

Steve McManus on behalf of PeeringDB Product Committee

Re: Youtube TV Location error. Google Confirms issue but can't fix.

[Josh Luthman]

Did you try this?  https://support.google.com/websearch/workflow/9308722

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Nov 2, 2020 at 2:01 PM Nate Burke  wrote:

> Anyone here from the Youtube TV side of Google?   I've had a ticket open
> for 2 months on one of my /24 subnets getting the wrong City location.
> Every ticket reply from Google confirms that they see the incorrect
> location, They reference that it is part of a larger geo-location
> problem with YoutubeTV, and it's been sent to engineering.  For 2 months
> Engineering has been 'working on a fix' with no ETA.
>
> Anyone know what this massive geo-location issue is that they reference,
> and when it will be fixed?  Other subnets are locating correction, just
> this one /24, that's part of a larger block I've had for 20 years.
>
> Nate Burke
> Blast Communications
>

RSS Feed for this list?

[Timothy Brown]

Hi,

I noticed that now the old gossamer-threads.com archives of the NANOG mailing 
list are redirecting to a hosting company or MSP.  I used to consume these 
archives via RSS as it was a little easier for me than grinding through a NANOG 
folder.  Is there any extant RSS feed for the NANOG list?

Tim

Youtube TV Location error. Google Confirms issue but can't fix.

[Nate Burke]

Anyone here from the Youtube TV side of Google?   I've had a ticket open 
for 2 months on one of my /24 subnets getting the wrong City location.  
Every ticket reply from Google confirms that they see the incorrect 
location, They reference that it is part of a larger geo-location 
problem with YoutubeTV, and it's been sent to engineering.  For 2 months 
Engineering has been 'working on a fix' with no ETA.


Anyone know what this massive geo-location issue is that they reference, 
and when it will be fixed?  Other subnets are locating correction, just 
this one /24, that's part of a larger block I've had for 20 years.


Nate Burke
Blast Communications

Re: Newbie Questions: How-to remove spurious IRR records (and keep them out for good)?

[Job Snijders]

Dear Pirawat,

On Mon, Oct 26, 2020 at 08:13:19PM +0700, Pirawat WATANAPONGSE wrote:
> I am seeking advice concerning someone else announcing IRR records on
> resources belonging to me.

Change is underway in the IRR ecosystem! The situation we are all used
to is that it is rather cumbersome to get IRR databases to remove IRR
objects. The IRR database operator may not trust your request for object
removal, or is busy doing other things. There was no industry-wide
automated process for IRR object removal.

With the introduction of "RIPE-731" 
(https://www.ripe.net/publications/docs/ripe-731)
in the RIPE region, the "RIPE-NONAUTH" database has slowly been
shrinking. The RIPE-NONAUTH database exclusively contains IRR objects
covering non-RIPE space. As more and more people create RPKI ROAs, which
in turn provide automated evidence whether objects in RIPE-NONAUTH are
valid or not valid. If an object is found to be invalid, it is deleted.

While RIPE-731 addressed the issue of stale objects in the RIPE-NONAUTH
database, of course it did not change anything for non-RIPE databases.
Most non-RIPE databases use software called "IRRd" (the likes of NTTCOM,
RADB, TC, etc). The IRRd software is the main entrypoint into the IRR
system, and recently IRRd v4.1.0 was released which can automatically
delete RPKI invalid IRR route objects.

A youtube video from last week with some information on IRRdv4 can be
seen here: https://www.youtube.com/watch?v=V9fsU0mNcA4

NTT has not yet upgraded from 4.0.0 -> 4.1.0, we are working on that.
RADB is also investigating a migration path. LACNIC & ARIN already are
on the v4 train.

The moment NTT and RADB have deployed 4.1.0 at rr.ntt.net and
whois.radb.net there will be an industry-wide fully automated IRR
cleanup process running which accomplishes two things:

- stale/rogue/erroneous objects (conflicting with RPKI) are deleted
- new objects which are in conflict with RPKI ROAs cannot be created

Using RPKI to clean up the IRR is a continuous process: this mechanism
helps clean up the past, but also going forward ensures that IRR does
not contain new information which is in conflict with published
cryptographically signed RPKI ROAs.

This 2018 video outlines the strategy how to migrate to an improved
state of internet routing security: https://www.youtube.com/watch?v=3BAwBClazWc
https://nlnog.net/static/nlnogday2018/9_routing_security_roadmap_nlnog_2018_snijders.pdf
Reality is now nearly synced up to all slides of the deck :-)

Kind regards,

Job

Re: Newbie Questions: How-to remove spurious IRR records (and keep them out for good)?

[Brandon Martin]

On 10/30/20 9:26 PM, Rubens Kuhl wrote:
> 1 - You should worry a little, but not much. Filters allowing unwanted
> announcements might be created using these erroneous IRR records, but
> they won't do any damage by themselves. An actual wrong BGP
> announcement is required for any damage to happen, and even without
> those IRR records, a wrong announcement will cause some havoc since
> not everyone builds filters based on IRR and not everyone runs RPKI
> validation.

I've had problems where people who build filters on IRR will build their 
filters SOLELY based on IRR.  That is, they are not permissive and will assume 
that, if there is an IRR object present for a prefix, that ONLY the 
announcements matching that object should be accepted.  This can lead to severe 
reachability issues if not corrected.
-- 
Brandon Martin

Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Jorge Santiago]

No WISP's just the local CLEC and cable company. Given the terrain in PR a
wireless delivery application might suit best.

On Mon, Nov 2, 2020 at 11:23 AM Sean Donelan  wrote:

>
> FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband
> Service As A Result Of Uniendo A Puerto Rico Fund
>
> Nearly a Third of Locations Will Get Speeds of At Least 1 Gbps with All
> Other Locations Getting Speeds of At Least 100 Mbps
>
>
> https://www.fcc.gov/document/fcc-announces-usf-support-high-speed-broadband-puerto-rico
>
> WASHINGTON, November 2, 2020—The Federal Communications Commission’s
> Wireline Competition Bureau today announced that funding through Stage 2
> of the Uniendo a Puerto Rico Fund will result in all locations in Puerto
> Rico having access to fixed broadband service
> with speeds of at least 100 Mbps. And nearly one-third of those locations
> will have access to fixed broadband service with speeds of at least 1
> Gbps.
>
> Two winning applicants in the Uniendo a Puerto Rico Stage 2 Competitive
> Process submitted bids for $127.1 million in funding over 10 years
> covering more than 1.2 million locations through a competitive process
> that awarded support for fixed voice and broadband services based on the
> weighting of price and network performance, including speed, latency,
> usage allowance, and resiliency. Liberty Communications has committed to
> offering service to over 914,000 locations, and Puerto Rico Telephone
> Company will offer service to over 308,000 locations.
>

Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Shane Ronan]

I would guess the dollar numbers represent the amount that they are
receiving in incentives and not the total cost of construction.

Shane

On Mon, Nov 2, 2020 at 11:58 AM Brandon Svec 
wrote:

> Maybe it *is* for wireless. That would be more likely with those numbers,
> but still quite unbelievable.
>
> My company does low voltage cabling. We charge more than $100 per drop to
> provide CAT6 in a newly constructed office building. It would be impossible
> to provide wires to 1.2 million locations across PR for $100/each.
>
> Brandon
>
> On Nov 2, 2020, at 8:51 AM, Shane Ronan  wrote:
>
> 
> Seems you could do something with Wireless much easier,
> guaranteeing access to speed of +/- 300mbits by using the CBAND spectrum
> that is coming available. Why run wires to the home at all?
>
>

Mellanox / Cumulus

[Bryan Holloway]

Curious to hear if the community has had any real-world experience using 
Mellanox/Cumulus (nVidia) for L2/L3 things outside of the datacenter.


Like other vendors, notably Arista, they seem to be trying to move out 
of the datacenter and target SPs and the layer 3 market. Personally, I 
think Arista has worked out most of the kinks over the last few years, 
and we've been happy with their L3 solutions (e.g., the 7280s)


While Mellanox's chipset is intriguing, I get a sense of feature-itis 
from their marketing. (BGP, OSPF, NAT, we do it all etc.) No IS-IS 
support, I'm told ...


Anybody using these in production in an SP environment? And if so, any 
opinions, good or bad?


Feel free to reach out off-list if you prefer. Thank you,

- bryan

Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Brandon Svec]

Maybe it is for wireless. That would be more likely with those numbers, but 
still quite unbelievable. 

My company does low voltage cabling. We charge more than $100 per drop to 
provide CAT6 in a newly constructed office building. It would be impossible to 
provide wires to 1.2 million locations across PR for $100/each. 

Brandon

> On Nov 2, 2020, at 8:51 AM, Shane Ronan  wrote:
> 
> 
> Seems you could do something with Wireless much easier, guaranteeing access 
> to speed of +/- 300mbits by using the CBAND spectrum that is coming 
> available. Why run wires to the home at all?

Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[j k]

Skeptical about the timing and scoping of the project.

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Mon, Nov 2, 2020 at 11:48 AM Brandon Svec 
wrote:

> This seems like very good news. I am quite skeptical this can be
> accomplished per the provided numbers though.
>
> > On Nov 2, 2020, at 8:24 AM, Sean Donelan  wrote:
> >
> > $127.1 million in funding over 10 years covering more than 1.2 million
> locations
>

Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Shane Ronan]

Seems you could do something with Wireless much easier, guaranteeing access
to speed of +/- 300mbits by using the CBAND spectrum that is coming
available. Why run wires to the home at all?

On Mon, Nov 2, 2020 at 11:22 AM Sean Donelan  wrote:

>
> FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband
> Service As A Result Of Uniendo A Puerto Rico Fund
>
> Nearly a Third of Locations Will Get Speeds of At Least 1 Gbps with All
> Other Locations Getting Speeds of At Least 100 Mbps
>
>
> https://www.fcc.gov/document/fcc-announces-usf-support-high-speed-broadband-puerto-rico
>
> WASHINGTON, November 2, 2020—The Federal Communications Commission’s
> Wireline Competition Bureau today announced that funding through Stage 2
> of the Uniendo a Puerto Rico Fund will result in all locations in Puerto
> Rico having access to fixed broadband service
> with speeds of at least 100 Mbps. And nearly one-third of those locations
> will have access to fixed broadband service with speeds of at least 1
> Gbps.
>
> Two winning applicants in the Uniendo a Puerto Rico Stage 2 Competitive
> Process submitted bids for $127.1 million in funding over 10 years
> covering more than 1.2 million locations through a competitive process
> that awarded support for fixed voice and broadband services based on the
> weighting of price and network performance, including speed, latency,
> usage allowance, and resiliency. Liberty Communications has committed to
> offering service to over 914,000 locations, and Puerto Rico Telephone
> Company will offer service to over 308,000 locations.
>

Re: FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Brandon Svec]

This seems like very good news. I am quite skeptical this can be accomplished 
per the provided numbers though. 

> On Nov 2, 2020, at 8:24 AM, Sean Donelan  wrote:
> 
> $127.1 million in funding over 10 years covering more than 1.2 million 
> locations

Re: Asus wifi AP re-writing DNS packets

[Anurag Bhatia]

Hi Alarig


I tried that but somehow DNS traffic still does not work. I tried adding
rules in prerouting as well and still no impact.


anurag@RT-AC58U:/tmp/home/root# iptables -t nat  -L PREROUTING -v -n
Chain PREROUTING (policy ACCEPT 25 packets, 3147 bytes)
 pkts bytes target prot opt in out source
destination
  672 46143 ACCEPT udp  --  *  *   0.0.0.0/0
0.0.0.0/0udp dpt:53
0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp dpt:53
anurag@RT-AC58U:/tmp/home/root# iptables -t nat  -L -v -n
Chain PREROUTING (policy ACCEPT 63 packets, 10481 bytes)
 pkts bytes target prot opt in out source
destination
  993 68310 ACCEPT udp  --  *  *   0.0.0.0/0
0.0.0.0/0udp dpt:53
0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp dpt:53

Chain INPUT (policy ACCEPT 46 packets, 8909 bytes)
 pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp dpt:53
0 0 ACCEPT udp  --  *  *   0.0.0.0/0
0.0.0.0/0udp dpt:53
anurag@RT-AC58U:/tmp/home/root#





>From my client behind Asus Wifi AP:

 dig @1.1.1.1 whoami.akamai.net

; <<>> DiG 9.10.6 <<>> @1.1.1.1 whoami.akamai.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached



Whether or not I have these rules, I see no traffic on port 53 when doing
tcpdump on the core router (in the North of Asus wifi AP). So clearly
firewall rules are not working.
Please suggest if you see something wrong here.


Also, in meantime, I heard from Asus and their support mentioned that this
re-writing is intentional and is done so that end users can access device
on router.asus.com hostname. I requested them to make this feature optional
so that at least folks like us can disable it. Let's see how that goes.



Thanks.


On Thu, Oct 29, 2020 at 3:13 PM Alarig Le Lay  wrote:

> On Thu 29 Oct 2020 02:10:25 GMT, Anurag Bhatia wrote:
> > I tried deleting the rule and it drops the traffic completely. So DNS
> > resolution stops working and I am unsure why. It's not like default drop
> or
> > anything. I can edit the rule and whatever active port 53 related rule is
> > there works. But I want case of no such rule at all. :-)
>
> Did you try to add
> -t nat -A POSTROUTING -p tcp -m tcp --dport 53 -j ACCEPT
> -t nat -A POSTROUTING -p udp -m udp --dport 53 -j ACCEPT
>
> after the deletion?
>
> --
> Alarig
>


-- 
Anurag Bhatia
anuragbhatia.com

FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband Service

[Sean Donelan]

FCC Announces All Of Puerto Rico To Have Access To High-Speed Broadband 
Service As A Result Of Uniendo A Puerto Rico Fund


Nearly a Third of Locations Will Get Speeds of At Least 1 Gbps with All 
Other Locations Getting Speeds of At Least 100 Mbps


https://www.fcc.gov/document/fcc-announces-usf-support-high-speed-broadband-puerto-rico

WASHINGTON, November 2, 2020—The Federal Communications Commission’s 
Wireline Competition Bureau today announced that funding through Stage 2 
of the Uniendo a Puerto Rico Fund will result in all locations in Puerto 
Rico having access to fixed broadband service
with speeds of at least 100 Mbps. And nearly one-third of those locations 
will have access to fixed broadband service with speeds of at least 1 
Gbps.


Two winning applicants in the Uniendo a Puerto Rico Stage 2 Competitive 
Process submitted bids for $127.1 million in funding over 10 years 
covering more than 1.2 million locations through a competitive process 
that awarded support for fixed voice and broadband services based on the 
weighting of price and network performance, including speed, latency, 
usage allowance, and resiliency. Liberty Communications has committed to 
offering service to over 914,000 locations, and Puerto Rico Telephone 
Company will offer service to over 308,000 locations.

Re: att or sonic "residential" fiber service at a "nontraditional" residence.

[Scott McGrath]

I’d say ‘it depends’ on the sales organization being willing to sell it.
 The non-profit also has to realize that they get the same service
restoration speeds and customer support that a residential customer gets.



On Sun, Nov 1, 2020 at 8:24 PM Mark Seiden  wrote:

> att 1Gb/sec symmetric fiber is about $70/month.
>
> their “business class” service costs >10x that price.
>
> if i don’t want an SLA, does anything keep a non-profit organization from
> ordering (from att or sonic) residential service at what normally would be
> considered a business location?
> sonic seems to overlay on the att fiber network (in parts of the sf bay
> area)?
>
> (say, for example, you have a caretaker who lives on premises and you
> terminate the fiber in or near the caretaker’s apartment…)
>
> (would this violate some tariff?  could they refuse to install?)
>
> (for me this harkens back to much earlier days where i would order dry
> copper loops intended for alarm purposes and run data or conditioned audio
> over them…)

Re: 100G over 100 km of dark fiber

[Ariën Vijn via NANOG]

Hi Jared,

4x25Gbit/s, 'directly detected' MAY work but it won't be easy at all. As many 
already have suggested, coherent detection will give you much much less 
headaches. 

If you want to go with directly detected for financial reasons than first make 
sure you know the type(s) of fibers and the dispersion you can expect. 
Fiber-operators tend to splice different types of fiber together. Don't just 
assume that it will be all G.652 compatible fiber.

If there is G.655 or even G.653 compatible fiber in your path then it is 
unlikely that you can operate in the O-band (1310nm). 

In that case you need to go with the C-band (1550nm), which is easier to 
amplify than the O-band, because you can use commonly available EDFAs. 

You probably need to compensate the chromatic dispersion in the C-band. For 
that it is again very important to know the fiber type(s) in your path.Because 
a '100km DCM', assumes 100km G.652 fiber. If your path consists of 50km G.652 
and 50km G.655 then you need to compensate for 50km. 

Last but not least, your hardware or optics probably need to be able to do FEC 
to get a bit of a decent BER.

-- Ariën



> On 30 Oct 2020, at 15:19, Jared Brown  wrote:
> 
> Hello NANOG!
> 
> I need to push 100G over 100 km of dark fiber. Since there are no 100G 
> pluggable optics with this reach (~25 dB), I have been offered coherent 
> transport systems to solve my problem. This is all good and well, except 
> total system costs start from high five figures.
> 
> So, my question is, do I have any other options?
> 
> I can't help noticing that you can break out a 100G QSFP into four 25G QSFPs. 
> 25G DWDM systems are relatively inexpensive (low five figures), but can you 
> make 25G DWDM go 100 km?
> 
> I only need the one 100G, so I don't really need a highly scalable DWDM 
> system. I can't put anything midspan, or if I could it would cost more than 
> just going with a coherent system.
> 
> 
> Jared

Re: Apple Catalina Appears to Introduce Massive Jitter - SOLVED!

[Karl Auerbach]

Let me jump in and add a bit more information.

I am not an RF guy - I stopped playing with radios [and TV] in the days 
when they used vacuum tubes (yes, really.)


Many laptops share radio and antenna resources between WiFi and bluetooth.

Bluetooth lives on the 2.4ghz band.  Wifi presently uses both that band 
and also a 5ghz band. Different antennas might be used for each.


I encountered Wi-Fi/Bluetooth contention issues a couple of years back

My home wifi has (or rather had) distinct SSIDs for Wifi on the 2.4 and 
5ghz bands.  It was a rough attempt at manual load and distance balancing.


(Our house is in a relatively quiet area, RF wise, so there's not really 
any seriously competing wi-fi - or for that matter cell signal, 
broadcast TV, or FM radio.)


I began to notice that when I had one of my laptops on the 5ghz WiFi and 
was listening to music via some bluetooth speakers that my remote 
terminal keystrokes sometimes had that sluggish feel that is familiar 
when doing remote terminal command-line stuff over long paths with a lot 
of latency/jitter.  And at the same time the music via Bluetooth often 
broke up or stuttered.  There was a clear correlation between the two 
problems.


I had heard from some Linux kernel developers that deep down in the 
Linux kernel the simultaneous use of Wifi on a 5ghz channel and 
bluetooth on 2.4 causes a lot of thrashing and flogging of the the radio 
system.  I don't know, but I suspect that as a result there are queues 
of outbound traffic waiting for the radio or antennas to become 
operational on the channel they need.  I have no idea what happens to 
inbound frames when the radio system is tuned elsewhere - I never 
measured whether the frames are lost or delayed.


I suspect similar issues are present in *BSD, MacOS, and Windows kernels.

So I did some simple empirical testing to compare life with the laptop 
coerced to use an SSID present only on the 2.4ghz band. The problems 
went away.


I went back to the laptop, but coerced onto the 5ghz band for WiFi and, 
voila, there was trouble.


I've done this with a MacBook Pro (circa 2015 model) using various 
versions of MacOS and with my rather newer Linux laptops (mostly Dell 
XPS units with Fedora.)  Same sorts of behavior.


These were all i5 based units with 2 or 4 cores - plenty of CPU power to 
simultaneously handle an SSH remote console client and a music player.


I did not test with mobile phone or tablet platforms.

I do not know if the single radio issue is the result of cost savings or 
some radio-engineering or antenna issue.  I do suspect that these things 
could become more troublesome as WiFi 6 and/or 5G start to use some of 
the higher frequency allocations around 5.9 and 6ghz.)


(A few weeks ago we switched our home WiFi to a WiFi 6 [Netgear Orbi-6] 
mesh system that does not appear to allow separate SSIDs for the 2.4 and 
5ghz bands, so I can not repeat these tests without constructing a test 
network with the now unused access points.  BTW, I did encounter the 
hell that is known as "reconfiguring dozens upon dozens of different 
kinds of IoT devices to use a different SSID".)


Looking somewhat off topic - it is my sense that we will be seeing a lot 
more latency/jitter (and packet resequencing) issues in the future as 
radio systems become more agile and as we begin to use shorter 
(millimeter) wavelength frequencies with reduced ability to penetrate 
walls that, in turn, cause more frequent access-point transitions (with 
possibly distinctly different backhaul characteristics).  I've observed 
that these things can cause trouble for some TCP stacks and some non-TCP 
based VoIP and streaming applications.


        --karl--

On 10/30/20 12:08 PM, Mark Tinka wrote:

Hi all.

So I may have fixed this for my end, and hopefully others may be able 
to use the same fix.


After a tip from Karl Auerbach and this link:

https://developer.apple.com/forums/thread/97805

... I was able to fix the problem by disabling Bluetooth.

Brazil Transit

[Rod Beck]

Hey Folks,

I would be interested in understanding 100 GigE transit pricing in Sao Paulo. 
If you have any insight, contact me off line.

Thanks.

Regards,

Roderick.


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]

Re: plea for comcast/sprint handoff debug help

[Job Snijders]

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: plea for comcast/sprint handoff debug help

[Tim Bruijnzeels]

Hi Randy, all,

> On 31 Oct 2020, at 04:55, Randy Bush  wrote:
> 
>> If there is a covering less specific ROA issued by a parent, this will
>> then result in RPKI invalid routes.
> 
> i.e. the upstream kills the customer.  not a wise business model.

I did not say it was. But this is the problematic case.

For the vast majority of ROAs the sustained loss of the repository would lead 
to invalid ROA *objects*, which will not be used in Route Origin Validation 
anymore leading to the state 'Not Found' for the associated announcements.

This is not the case if there are other ROAs for the same prefixes published by 
others (most likely the parent). Quick back of the envelope analysis: this 
affects about 0.05% of ROA prefixes.

>> The fall-back may help in cases where there is an accidental outage of
>> the RRDP server (for as long as the rsync servers can deal with the
>> load)
> 
> folk try different software, try different configurations, realize that
> having their CA gooey exposed because they wanted to serve rrdp and
> block, ...

We are talking here about the HTTPS server being unavailable, while rsync *is*.

So this means, your HTTPS server is down, unreachable, or has an issue with its 
HTTPS certificate. Your repository could use a CDN if they don't want to do all 
this themselves. They could monitor, and fix things.. there is time.

Thing is even if HTTPs becomes unavailable this still leaves hours (8 by 
default for the Krill CA, configurable) to fix things. Routinator (and the RIPE 
NCC Validator, and others) will use cached data if they cannot retrieve new 
data. It's only when manifests and CRLs start to expire that the objects would 
become invalid.

So the fallback helps in case of incidents with HTTPS that were not fixed 
within 8 hours for 0.05% of prefixes.

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 tradeoff. I think that protecting against replay should be considered 
more important here, given the numbers and time to fix HTTPS issue.


> randy, finding the fort rp to be pretty solid!

Unrelated, but sure I like Fort too.

Tim