Re: Anyone running C-Data OLTs?

[Brandon Martin]

On 7/10/20 6:22 PM, Alexander Neilson wrote:
I haven’t checked (on mobile) but those affected model numbers could 
confirm if it’s OLT, ONT, or both. Possibly the confusion could come 
from the bug affecting both.


All of the part numbers I was able to find a description of (after 
sifting through the numerous pages copying the vulnerability disclosure) 
appeared to be low-cost, low- to mid-density pizza-box EPON OLTs.  I 
didn't see any ONUs, but then I also didn't find data on everything.


I know a low of EPON deployments go for all-in-ones with the ONU, 
router, WLAN, etc. integrated into a single box presumably because it's 
cheaper for initial deployment than separate boxes for ONU and CPE 
router/AP.  No indication of those being affected in this notice, at 
least that I could find.


--
Brandon Martin

Re: Anyone running C-Data OLTs?

[Alexander Neilson]

I think the article may also be confusing OLT and ONT. 

They are talking about how the “OLT” that is vulnerable is the device that 
translates the fibre into the copper Ethernet connected to customers equipment 
which may indicate these are actually ONT’s being talked about or the article 
authors got their explanation confused. 

For these to be internet exposed presumably they must be including a router 
function and not simply doing some bridging of customer traffic. 

I haven’t checked (on mobile) but those affected model numbers could confirm if 
it’s OLT, ONT, or both. Possibly the confusion could come from the bug 
affecting both. 

Regards
Alexander

Alexander Neilson
Neilson Productions Limited
021 329 681
alexan...@neilson.net.nz

> On 11/07/2020, at 08:04, Mel Beckman  wrote:
> 
>  The “WAN” port of an OLT _is_ it’s management port. Data, IPTV, and VoIP 
> traffic pass on VLANs, typically encrypted. These are passive optical network 
> (PON) devices, where all CPE in a group of, say, 32 premises receive the same 
> light via an optical splitter. Thus network partitioning is a requirement of 
> the architecture. There is no concept of a traditional “WAN” port facing the 
> Internet. 
> 
> -mel via cell
> 
>>> On Jul 10, 2020, at 12:21 PM, Owen DeLong  wrote:
>>> 
>> 
>> Um, from the article it appears that this isn’t on the Management interface, 
>> but the WAN port of the OLT.
>> 
>> Owen
>> 
>> 
>>> On Jul 10, 2020, at 11:01 , Mel Beckman  wrote:
>>> 
>>> But who, who I ask, opens their management interface to the public 
>>> Internet?!?!
>>> 
>>> Maybe this is vulnerability if you have a compromised management network, 
>>> but anybody who opens CPE up to the Internet is just barking mad :-)
>>> 
>>> -mel via cell
>>> 
 On Jul 10, 2020, at 10:00 AM, Owen DeLong  wrote:
 
  
 https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872
 
 Wow… Just wow.
 
 Owen
 
>> 

Re: Anyone running C-Data OLTs?

[blakangel]

Well here are a couple hundred:

https://www.shodan.io/search?query=Command+Line+Interface+for+EPON+System

-Keith

Mel Beckman wrote on 7/10/2020 1:07 PM:

Perhaps you’re confusing OLT with ONT? An OLT is a “curbside” 
distribution node, the ONT is the CPE. The vulnerability is in the 
distribution node, not the CPE. No provider with any sense exposes 
their distribution node admin interface to the Internet.


-mel via cell


On Jul 10, 2020, at 1:01 PM, m...@beckman.org wrote:

The “WAN” port of an OLT _is_ it’s management port. Data, IPTV, and 
VoIP traffic pass on VLANs, typically encrypted. These are passive 
optical network (PON) devices, where all CPE in a group of, say, 32 
premises receive the same light via an optical splitter. Thus network 
partitioning is a requirement of the architecture. There is no 
concept of a traditional “WAN” port facing the Internet.


-mel via cell


On Jul 10, 2020, at 12:21 PM, Owen DeLong  wrote:


Um, from the article it appears that this isn’t on the Management 
interface, but the WAN port of the OLT.


Owen


On Jul 10, 2020, at 11:01 , Mel Beckman > wrote:


But who, who I ask, opens their management interface to the public 
Internet?!?!


Maybe this is vulnerability if you have a compromised management 
network, but anybody who opens CPE up to the Internet is just 
barking mad :-)


-mel via cell

On Jul 10, 2020, at 10:00 AM, Owen DeLong > wrote:


 
https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872 



Wow… Just wow.

Owen

Re: Anyone running C-Data OLTs?

[Mel Beckman]

Perhaps you’re confusing OLT with ONT? An OLT is a “curbside” distribution 
node, the ONT is the CPE. The vulnerability is in the distribution node, not 
the CPE. No provider with any sense exposes their distribution node admin 
interface to the Internet.

-mel via cell

On Jul 10, 2020, at 1:01 PM, m...@beckman.org wrote:

The “WAN” port of an OLT _is_ it’s management port. Data, IPTV, and VoIP 
traffic pass on VLANs, typically encrypted. These are passive optical network 
(PON) devices, where all CPE in a group of, say, 32 premises receive the same 
light via an optical splitter. Thus network partitioning is a requirement of 
the architecture. There is no concept of a traditional “WAN” port facing the 
Internet.

-mel via cell

On Jul 10, 2020, at 12:21 PM, Owen DeLong  wrote:


Um, from the article it appears that this isn’t on the Management interface, 
but the WAN port of the OLT.

Owen


On Jul 10, 2020, at 11:01 , Mel Beckman 
mailto:m...@beckman.org>> wrote:

But who, who I ask, opens their management interface to the public Internet?!?!

Maybe this is vulnerability if you have a compromised management network, but 
anybody who opens CPE up to the Internet is just barking mad :-)

-mel via cell

On Jul 10, 2020, at 10:00 AM, Owen DeLong 
mailto:o...@delong.com>> wrote:

 
https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872

Wow… Just wow.

Owen

Re: Anyone running C-Data OLTs?

[Mel Beckman]

The “WAN” port of an OLT _is_ it’s management port. Data, IPTV, and VoIP 
traffic pass on VLANs, typically encrypted. These are passive optical network 
(PON) devices, where all CPE in a group of, say, 32 premises receive the same 
light via an optical splitter. Thus network partitioning is a requirement of 
the architecture. There is no concept of a traditional “WAN” port facing the 
Internet.

-mel via cell

On Jul 10, 2020, at 12:21 PM, Owen DeLong  wrote:


Um, from the article it appears that this isn’t on the Management interface, 
but the WAN port of the OLT.

Owen


On Jul 10, 2020, at 11:01 , Mel Beckman 
mailto:m...@beckman.org>> wrote:

But who, who I ask, opens their management interface to the public Internet?!?!

Maybe this is vulnerability if you have a compromised management network, but 
anybody who opens CPE up to the Internet is just barking mad :-)

-mel via cell

On Jul 10, 2020, at 10:00 AM, Owen DeLong 
mailto:o...@delong.com>> wrote:

 
https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872

Wow… Just wow.

Owen

Re: Anyone running C-Data OLTs?

[Owen DeLong]

Um, from the article it appears that this isn’t on the Management interface, 
but the WAN port of the OLT.

Owen


> On Jul 10, 2020, at 11:01 , Mel Beckman  wrote:
> 
> But who, who I ask, opens their management interface to the public 
> Internet?!?!
> 
> Maybe this is vulnerability if you have a compromised management network, but 
> anybody who opens CPE up to the Internet is just barking mad :-)
> 
> -mel via cell
> 
>> On Jul 10, 2020, at 10:00 AM, Owen DeLong  wrote:
>> 
>>  
>> https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872
>>  
>> 
>> 
>> Wow… Just wow.
>> 
>> Owen
>> 

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 11 Jul, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  814906
Prefixes after maximum aggregation (per Origin AS):  309350
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  393731
Total ASes present in the Internet Routing Table: 68570
Prefixes per ASN: 11.88
Origin-only ASes present in the Internet Routing Table:   5
Origin ASes announcing only one prefix:   24571
Transit ASes present in the Internet Routing Table:9682
Transit-only ASes present in the Internet Routing Table:297
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  43
Max AS path prepend of ASN ( 22394)  38
Prefixes from unregistered ASNs in the Routing Table:   856
Number of instances of unregistered ASNs:   857
Number of 32-bit ASNs allocated by the RIRs:  32419
Number of 32-bit ASNs visible in the Routing Table:   26740
Prefixes from 32-bit ASNs in the Routing Table:  122999
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:519
Number of addresses announced to Internet:   2844535296
Equivalent to 169 /8s, 140 /16s and 42 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  275092

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   213547
Total APNIC prefixes after maximum aggregation:   62625
APNIC Deaggregation factor:3.41
Prefixes being announced from the APNIC address blocks:  207325
Unique aggregates announced from the APNIC address blocks:86072
APNIC Region origin ASes present in the Internet Routing Table:   10707
APNIC Prefixes per ASN:   19.36
APNIC Region origin ASes announcing only one prefix:   3015
APNIC Region transit ASes present in the Internet Routing Table:   1598
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 28
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5787
Number of APNIC addresses announced to Internet:  768306560
Equivalent to 45 /8s, 203 /16s and 109 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:238511
Total ARIN prefixes after maximum aggregation:   109521
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   235868
Unique aggregates announced from the ARIN address blocks:116804
ARIN Region origin ASes present in the Internet Routing Table:18529
ARIN Prefixes per ASN:12.73
ARIN Regi

Re: Anyone running C-Data OLTs?

[Mel Beckman]

But who, who I ask, opens their management interface to the public Internet?!?!

Maybe this is vulnerability if you have a compromised management network, but 
anybody who opens CPE up to the Internet is just barking mad :-)

-mel via cell

On Jul 10, 2020, at 10:00 AM, Owen DeLong  wrote:

 
https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872

Wow… Just wow.

Owen

Your Voice, Your Vote — Help Shape NANOG's Future 👉

[NANOG News]

Our success depends on the collective expertise of the NANOG community to
help direct and shape our organization in service of our mission.

The first of NANOG's two 2020 elections takes place July 20-22. Become a
NANOG member before voting opens to exercise your right to participate, and
make your voice heard!

Learn More 

Anyone running C-Data OLTs?

[Owen DeLong]

https://www.zdnet.com/article/backdoor-accounts-discovered-in-29-ftth-devices-from-chinese-vendor-c-data/?ftag=TRE-03-10aaa6b&bhid=29077120342825113007211255328545&mid=12920625&cid=2211510872
 


Wow… Just wow.

Owen

Re: IPv6 over vxlan+evpn Arista?

[David Hubbard]

Nope the underlay can be v4-v4, just need to be able to carry the v4+v6 overlay 
to allow for migration of addresses.

From: Tyler Conrad 
Date: Friday, July 10, 2020 at 12:39 PM
To: David Hubbard 
Cc: "nanog@nanog.org" 
Subject: Re: IPv6 over vxlan+evpn Arista?

Do you need to carry the v6 af in the underlay? I’ve used 6pe/6vPE to carry v6 
over v4 next-hops in the overlay without issue, but can’t say I’ve tested a 
dual-stack vtep.

On Fri, Jul 10, 2020 at 08:07 David Hubbard 
mailto:dhubb...@dino.hostasaurus.com>> wrote:
Hi all, was curious if anyone is doing dual stack v4/v6 over Arista’s 
implementation of vxlan / evpn (the inter-data center transport would be v4)?  
They have plenty of references for v4 deployments but had to check on v6 
support, which can make one nervous; they did confirm it’s supported.  Looking 
to leverage it as a way to migrate a dual-stack data center without 
re-addressing.

Thanks,

David

Re: IPv6 over vxlan+evpn Arista?

[Tyler Conrad]

Do you need to carry the v6 af in the underlay? I’ve used 6pe/6vPE to carry
v6 over v4 next-hops in the overlay without issue, but can’t say I’ve
tested a dual-stack vtep.

On Fri, Jul 10, 2020 at 08:07 David Hubbard 
wrote:

> Hi all, was curious if anyone is doing dual stack v4/v6 over Arista’s
> implementation of vxlan / evpn (the inter-data center transport would be
> v4)?  They have plenty of references for v4 deployments but had to check on
> v6 support, which can make one nervous; they did confirm it’s supported.
> Looking to leverage it as a way to migrate a dual-stack data center without
> re-addressing.
>
>
>
> Thanks,
>
>
>
> David
>

IPv6 over vxlan+evpn Arista?

[David Hubbard]

Hi all, was curious if anyone is doing dual stack v4/v6 over Arista’s 
implementation of vxlan / evpn (the inter-data center transport would be v4)?  
They have plenty of references for v4 deployments but had to check on v6 
support, which can make one nervous; they did confirm it’s supported.  Looking 
to leverage it as a way to migrate a dual-stack data center without 
re-addressing.

Thanks,

David

Re: 60ms cross continent

[Mark Tinka]

On 10/Jul/20 10:50, Eric Kuhnke wrote:
> With common Ku band TVRO (receive only) dishes and decoders, one of
> the constraints for moving to higher bitrates is the physical sizes of
> the customer dish and economics.
>
> For a good example go to a very densely populated developing nation
> environment. Saddar, central Rawalpindi, Pakistan would be one such
> place. Get up on a tall roof and look at the numerous low cost Ku dish
> and LNB setups on other roofs.
>
> Achievable bps/Hz and modulation type, code rates, and type of FEC are
> very limited when the antenna has to be so small. Usually something
> like qpsk 3/4. In order to have something like a 4k stream and not
> require end users to replace their 75-100cm size dishes with something
> much bigger, you'd need to use a lot more MHz on the geostationary
> satellite's transponder. Greatly increasing monthly transponder fees
> for the tv broadcaster. Any sort of modulation like 8PSK or a 16QAM is
> probably not achievable as long as the end user consumer antennas
> remain so small.
>
> For people who are accustomed to a terrestrial microwave link budget
> and path loss, Geostationary will seem weird. For SCPC two way data
> links you can spend a lot of money and construct 3.8-4.5m size earth
> stations, definitely a construction project with a capital P, but the
> laws of physics will dictate your link sees only 4 bps/Hz or less.
> Even with the very best modems on the market now. 
>
> Ultimately advances in codecs may help this somewhat. 4k AV1 at fairly
> low bitrates is remarkably not terrible. H.266 was just standardized.
> It'll take a long time for full hardware decode to show up in ultra
> low cost satellite TV boxes.

When the leading satellite TV provider in Africa first started
delivering service via satellite back in 1997, it was on C-Band, with
the smallest dish needing to be 2.4m.

When they moved to Ku-Band around 2010, every home now has 90cm dishes.
While they do say 60cm dishes are viable, you won't be able to pick up
any HD service with those.

Mark.

Re: 60ms cross continent

[Eric Kuhnke]

With common Ku band TVRO (receive only) dishes and decoders, one of the
constraints for moving to higher bitrates is the physical sizes of the
customer dish and economics.

For a good example go to a very densely populated developing nation
environment. Saddar, central Rawalpindi, Pakistan would be one such place.
Get up on a tall roof and look at the numerous low cost Ku dish and LNB
setups on other roofs.

Achievable bps/Hz and modulation type, code rates, and type of FEC are very
limited when the antenna has to be so small. Usually something like qpsk
3/4. In order to have something like a 4k stream and not require end users
to replace their 75-100cm size dishes with something much bigger, you'd
need to use a lot more MHz on the geostationary satellite's transponder.
Greatly increasing monthly transponder fees for the tv broadcaster. Any
sort of modulation like 8PSK or a 16QAM is probably not achievable as long
as the end user consumer antennas remain so small.

For people who are accustomed to a terrestrial microwave link budget and
path loss, Geostationary will seem weird. For SCPC two way data links you
can spend a lot of money and construct 3.8-4.5m size earth stations,
definitely a construction project with a capital P, but the laws of physics
will dictate your link sees only 4 bps/Hz or less. Even with the very best
modems on the market now.

Ultimately advances in codecs may help this somewhat. 4k AV1 at fairly low
bitrates is remarkably not terrible. H.266 was just standardized. It'll
take a long time for full hardware decode to show up in ultra low cost
satellite TV boxes.






On Thu, Jul 9, 2020, 9:01 AM Christopher Munz-Michielin <
christop...@ve7alb.ca> wrote:

> > On 09/07/2020 08:00, Mark Tinka wrote:
> > So is there a reason why we are not seeing widespread 1080p TV via
> > satellite? They seem to exist where a broadcaster also supports an IPTV
> > platform.
> >
> > Mark.
> I'd assume it's a question of available bandwidth and availability of
> decoders.  From my observations most HD satellite feeds seem to sit
> between 3 and 5 mbps, a typical Ku band transponder might have a
> bandwidth of around 20-25mbps.  This means you can cram 5-8 HD feeds
> onto a single transponder.  With 4K streams the bandwidth requirements
> double, meaning you can cram a lot less in the same amount of
> transponder space and satellite bandwidth is expensive!
>
> The other issue is on the decoder side.  Right now, the vast majority of
> satellite subscribers receive programming though dedicated decoders (set
> top boxes).  Most of these decoders only have hardware to decode MPEG2
> and H.264 video, while 4K stuff is almost exclusively H.265.   That
> means it's not a simple matter of turning on 4K, you'd have to arrange
> to send new decoders to all your subscribers wanting to receive 4K.
>
> As time moves along, I'm sure we'll start to see more satellite feeds
> available in 4K but like the transition to HD video, it'll be a slow
> process.
>
> Chris
>
>

Re: 60ms cross continent

[Mark Tinka]

On 9/Jul/20 22:49, Masataka Ohta wrote:

> We should also use IP even over radio waves. IP over MPEG2-TS
> over DVB (or terrestrial broadcast network) is doable though
> IP directly over DVB should be better.

Well, when we moved over from traditional satellites to inclined orbit
satellites back in 2000 across most of Africa, IP was carried directly
over DVB for downlink traffic. The uplink traffic still required regular
SCPC modems.

We had to use a DVB decoder reconfigured for IP carriage (rather than
video) to decode the DVB stream (via a unique key, since DVB is a
Multicast-type medium) and pass the IP packets over to your router.

So yes, this technology does exist, and is way cheaper than SCPC in the
downlink direction.


>
> Unicast video over satellite link costs a lot.

Which is my point, and makes me wonder whether we shall ever see 1080p
or greater via satellite, en masse.

DVB, however, is more Multicast-y. So technically, you aren't unicasting
video over DVB, which is what a number of satellite TV providers are
using to deliver their services.

Mark.