Re: What's going on with AS147028?

[noc]

I scanned all LLIX members 
again, no LLIX members feeds junk routes to RIS now. I think we can remove 
AS141011/AS140731/AS141237/AS147028 from the filter list now.


From: JK-Net NOC 
Sent: Saturday, July 16, 2022 3:50 PM
To: nanog@nanog.org 
Cc: n...@he.net 
Subject: Re: What's going on with AS147028?

I think one of the reason is LL-IX strips their own ASN (59947) from the path 
and feed it to the route server. I see it as junk routes, and lots of people 
forgot(or intentionally not) to add 59947 back.
I scanned all LLIX members 
this morning(https://i.imgur.com/CsB8I1M.png), only AS140731 is still feeding 
junk routes generated by LL-IX to the RIS and bgp.tools, I think it's fine to 
remove AS141011/AS141237/AS147028 from the filter list.


On Wed, Jul 13, 2022 at 6:22 AM Mike Leber wrote:



This kind of thing is a problem from time to time with the data we get
from route collectors.

When we see it we have to add the culprit ASN to a filter list we keep
in bgp.he.net.

It tends to be a repeat problem with some collectors and some ASNs.

We haven't really figured out why people send junk routes to route
collectors.

The things we've seen aren't just route leaks.  We've seen a variety of
AS path spoofing.

We've already added this specific ASN to the filter list and pushed an
update for bgp.he.net.

Note, this email is specifically talking about routes received from
route collectors and not routes operationally received by he.net via BGP
sessions with actual networks.

Mike.

On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:


A friend of mine mentioned that both our Canadian ASNs were listed in
AS147028's peer list on https://bgp.he.net/AS147028 but we have no
adjacency to this network.

Their peer count jumped from 1 in May 2022 to 1,800 and just a few
days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on
are virtual IX with a few dozen "hobby networks".

The only lead I have is they use HE as transit and they're pumping
back BGP feed to route collectors like RIPE RIS or Route Views with
routes stripped of HE's ASN.

Eric

Re: What's going on with AS147028?

[noc]

I think one of the reason is LL-IX strips their own ASN (59947) from the path 
and feed it to the route server. I see it as junk routes, and lots of people 
forgot(or intentionally not) to add 59947 back.
I scanned all LLIX members 
this morning(https://i.imgur.com/CsB8I1M.png), only AS140731 is still feeding 
junk routes generated by LL-IX to the RIS and bgp.tools, I think it's fine to 
remove AS141011/AS141237/AS147028 from the filter list.


On Wed, Jul 13, 2022 at 6:22 AM Mike Leber wrote:



This kind of thing is a problem from time to time with the data we get
from route collectors.

When we see it we have to add the culprit ASN to a filter list we keep
in bgp.he.net.

It tends to be a repeat problem with some collectors and some ASNs.

We haven't really figured out why people send junk routes to route
collectors.

The things we've seen aren't just route leaks.  We've seen a variety of
AS path spoofing.

We've already added this specific ASN to the filter list and pushed an
update for bgp.he.net.

Note, this email is specifically talking about routes received from
route collectors and not routes operationally received by he.net via BGP
sessions with actual networks.

Mike.

On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:


A friend of mine mentioned that both our Canadian ASNs were listed in
AS147028's peer list on https://bgp.he.net/AS147028 but we have no
adjacency to this network.

Their peer count jumped from 1 in May 2022 to 1,800 and just a few
days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on
are virtual IX with a few dozen "hobby networks".

The only lead I have is they use HE as transit and they're pumping
back BGP feed to route collectors like RIPE RIS or Route Views with
routes stripped of HE's ASN.

Eric

Re: Papers/analysis on network equipment pricing since pandemic/banning foreign competition

[Mel Beckman]

Drew,

The YouTube channel Asianometry has some good insights into the underlying 
supply chain problems:

https://youtu.be/YJrOuBkYCMQ

Deposits that the issue isn’t with leading as chips, as you might think, but 
with so-called “trailing edge“ chips: microprocessors and support circuits  
that make up the bulk of electronic components, including routers and switches.

Asianometry points out that trailing edge components account for 50% of sales 
in the chip market, and given their much lower price of just a few dollars 
each, they represent many times as many units. This makes them a much larger 
factor in the supply chain problem.

Everything is finally keyed to “just in time“ manufacturing, with very little 
component supply in the pipelines. When Covid hit, those pipelines dried up and 
everything collapsed.

 -mel beckman

On Jul 16, 2022, at 4:19 PM, Forrest Christian (List Account) 
 wrote:


The underlying problem is silicon Fab capacity.   It has nothing to do with the 
actual manufacturing of the products once all the components arrive.   If you 
don't have components for your product, a new order for components will take a 
year to arrive just because the factories that turn raw silicon wafers into 
computer chips are backlogged 12 to 18 months.

Note that all of the existing factories are running around the clock, and 
although additional facilities are being built it takes time for them to be 
completed.   I'm also assuming that there has been some question about whether 
this is short term or long term demand which would influence whether you spend 
a billion dollars or more building a new fab.

On Fri, Jul 15, 2022, 11:57 AM Drew Weaver 
mailto:drew.wea...@thenap.com>> wrote:
Has anyone seen any interesting write ups or analysis on what has been 
happening with network equipment pricing and availability in the United States 
over the last couple of years?

Everyone (or at least I did) knew by March 2020 that what manufacturers were 
doing wasn’t really going to work anymore going forward and yet it’s 2 1/3 
years later and we’re still looking at a 1+ year lead time on basic products.

Not to be glib but I am pretty sure I could’ve devised a process to build 
ethernet switches by hand with a soldering iron by now.

Not to mention how many additional supply chains could’ve been established 
since then.

Did Huawei actually serve an important purpose in the market?

Did we put too many eggs in the Broadcom basket?

Did the industry come together and “agree” that the time is nigh to charge 
$16,000 for a Dell S4148T but also that it would take 9 months to get it at 
that price?

I think it would be fascinating to learn more about what is happening in this 
market.

Please share any resources on or off-list.

Thanks and have a great weekend!
-Drew

Re: Papers/analysis on network equipment pricing since pandemic/banning foreign competition

[Forrest Christian (List Account)]

The underlying problem is silicon Fab capacity.   It has nothing to do with
the actual manufacturing of the products once all the components arrive.
 If you don't have components for your product, a new order for components
will take a year to arrive just because the factories that turn raw silicon
wafers into computer chips are backlogged 12 to 18 months.

Note that all of the existing factories are running around the clock, and
although additional facilities are being built it takes time for them to be
completed.   I'm also assuming that there has been some question about
whether this is short term or long term demand which would influence
whether you spend a billion dollars or more building a new fab.

On Fri, Jul 15, 2022, 11:57 AM Drew Weaver  wrote:

> Has anyone seen any interesting write ups or analysis on what has been
> happening with network equipment pricing and availability in the United
> States over the last couple of years?
>
>
>
> Everyone (or at least I did) knew by March 2020 that what manufacturers
> were doing wasn’t really going to work anymore going forward and yet it’s 2
> 1/3 years later and we’re still looking at a 1+ year lead time on basic
> products.
>
>
>
> Not to be glib but I am pretty sure I could’ve devised a process to build
> ethernet switches by hand with a soldering iron by now.
>
>
>
> Not to mention how many additional supply chains could’ve been established
> since then.
>
>
>
> Did Huawei actually serve an important purpose in the market?
>
>
>
> Did we put too many eggs in the Broadcom basket?
>
>
>
> Did the industry come together and “agree” that the time is nigh to charge
> $16,000 for a Dell S4148T but also that it would take 9 months to get it at
> that price?
>
>
>
> I think it would be fascinating to learn more about what is happening in
> this market.
>
>
>
> Please share any resources on or off-list.
>
>
>
> Thanks and have a great weekend!
>
> -Drew
>
>
>
>
>
>
>
>
>
>
>

Re: Tool for virtual networks

[Saku Ytti]

On Fri, 15 Jul 2022 at 21:57, Grant Taylor via NANOG  wrote:

> Have you ever walked away from your terminal without locking it?  Or
> seen anyone else do it?

Probably, and probably also after I've already sudoed regardless of
authentication. And of course a retrospective look from any point to
history shows us various trivial local privilege escalation bugs which
have existed for 5-10-15-20 years, i.e. various trivial local
privilege escalation bugs exist now for anyone with hobbyist interest
finding them.
Devices which have a large commercial motive to keep safe and the
vendor owns the whole vertical and thus are easy to build securely,
are regularly owned by hobbyists just for fun. If there is a
commercial motive, you are being pwned regardless of your sudo policy.
Realised risks for big companies appear to be extremely cheap, based
on publicly disclosed  issues and their impact on market
capitalization. Cost of protection must be significantly lower than
realised risk.
Attacker has massive financial leverage, I don't have context to say
anything actually useful, but I believe the leverage is easily 1k, and
could be much more than 1M. That is, every dollar my adversary spends
attacking, I must spend 1000 dollars protecting, to successfully stop
them.
We have many obvious problems in tooling, like using C, which we
pretend are user errors 'git good', which if we decided to fix, could
significantly reduce attack surface, but we don't, no one cares about
infosec.

> There are also concerns of changing effective users on systems to one
> that has the NOPASSWD: option, thereby enabling the original user to do
> what the new user could do without authenticating as the new user.

I can accept concerns, and people are very much free to interpret
their security posture as they wish. But offering objective truths
from opinions is not appropriate.

It is very easy to paint various risk scenarios, but without
substantiating what is the cost of preventing the risk and what is the
cost of realised risk, it is just horoscope. One thing you can achieve
easily in infosec, is decreased productivity due to making things
slower or reducing motivation by forcing people to use workflow they
are not accustomed to.
This model causes escalation of dubious policies which never needed to
be substantiated. Maybe some help, maybe not, but at least they
increase cost.

Various models of working are valid, you could have root only, and you
could use ssh certificate signing for certificates which are valid for
minutes.

> I don't believe avoiding NOPASSWD: is just a horoscope.

Believe being the operative word. Maybe you are right, maybe not,
presenting it as factual truth is dishonest and potentially harmful.

My general rule of thumb, satisfy legal, regulatory and customer
contract requirements for infosec and other than that, largely ignore
policies which are only justifiable by infosec. Of course in many
cases doing things the right way, happens to align with the infosec
community desires and has 0 infosec cost, while having some perceived
infosec gains, and that is fine.

-- 
  ++ytti