On 8/10/23 11:38, Frank Habicht wrote:

from a 2019 DB snapshot:

aut-num:        AS327933 as-name:        GROUPE-TELECOM-SPRL descr:          GROUPE TELECOM SPRL status:         ASSIGNED org:            ORG-GTS2-AFRINIC admin-c:        YM8-AFRINIC tech-c:         YM9-AFRINIC notify:         ***@gtl-rdcongo.com mnt-lower:      GTS2-MNT mnt-routes:     GTS2-MNT mnt-by:         AFRINIC-HM-MNT changed:        ***@afrinic.net 20150917 source:         AFRINIC

I think the most common way to get out of this DB is to not pay something.

I'd guess that

aut-num:        AS37451 as-name:        CongoTelecom descr:          CONGO TELECOM

has a relationship with them and AS327933 wanted to prepend 2x [1] to their sole provider.....  (AS37451)

We are seeing some weird routing from them, and the AS2 they are attached to (University of Delaware) seems odd. Not sure if any of the American folk on this list can verify AS2 is really part of the University of Delaware... Mark.

On 8/10/23 15:22, Frank Habicht wrote:

ouch! I see in your LG that this AS 2 is originating 197.157.254.0/24 .

which seems to mean that it's not just a plain "we want to prepend 2 times, put the number 2 into config and the NOS takes this as the ASN to insert"

putting someone from  AS37451 into BCC.

ouch again! looking for "show ip bgp regexp _37451 2_" in Mark's LG, i see there are many originated and downstream's prefixes of AS37451 affected.

Right, these are the "odd" issues I am referring to that we are looking into.

So i'd now thing it's a AS37451 issue, not AS327933 alone.

Needless to say that the grapevine seems to claim that AS327933 is announcing bogons. We are reaching out to our customer (China Telecom) who is their provider to investigate. Thanks, Frank. Mark.

Haha :) you are right. I just checked Caida AS ranking: http://as-rank.uu3.net/?as=2 A lot of "providers" for UDEL-DCN. Yeah right.. They all indeed probably try to prepend their AS 2 times ending up having ASN 2 in path. ---------- Original message ---------- From: Mike Davis <davis@udel.edu> To: nanog@nanog.org Subject: Re: Dodgy AS327933 ...? Date: Thu, 10 Aug 2023 09:24:32 -0400 AS2 is the most hijacked prefix in the world.  Yes UD still owns it, but since different router vendors use different methods of prepending AS numbers, many folks try to prepend twice and end up announcing on AS2.. thanks mike On 8/10/23 9:02 AM, Mark Tinka wrote:

On 8/10/23 11:38, Frank Habicht wrote:

...

from a 2019 DB snapshot:

aut-num:        AS327933 as-name:        GROUPE-TELECOM-SPRL descr:          GROUPE TELECOM SPRL status:         ASSIGNED org:            ORG-GTS2-AFRINIC admin-c:        YM8-AFRINIC tech-c:         YM9-AFRINIC notify:         ***@gtl-rdcongo.com mnt-lower:      GTS2-MNT mnt-routes:     GTS2-MNT mnt-by:         AFRINIC-HM-MNT changed:        ***@afrinic.net 20150917 source:         AFRINIC

I think the most common way to get out of this DB is to not pay something.

I'd guess that

aut-num:        AS37451 as-name:        CongoTelecom descr:          CONGO TELECOM

has a relationship with them and AS327933 wanted to prepend 2x [1] to their sole provider.....  (AS37451)

We are seeing some weird routing from them, and the AS2 they are attached to (University of Delaware) seems odd.

Not sure if any of the American folk on this list can verify AS2 is really part of the University of Delaware...

Mark.

-- Mike Davis Lead Network Architect University of Delaware - 302.831.8756 Newark, DE 19716 Email davis@udel.edu

Mark Tinka wrote on 11/08/2023 09:43:

Did I miss the memo where vendors went from explicitly defining the AS multiple times to determine the number of prepends, to, this :-)?

yep, sure did. Check out the "set-bgp-prepend" action on routeros - it's right next to "set-bgp-prepend-path". https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters <watches Mark's face as it dawns on him why this happens so regularly> Nick

Mark Tinka wrote on 11/08/2023 10:17:

So how would one fumble it to the degree where a fat-finger results in what should be a prepend becoming an AS_PATH?

Genuine question - I have zero experience with Mikrotik in an SP role.

If your asn is 327933, then: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend=2 ... will produce: "327933 327933", and: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend-path=2 ... will produce: "327933 2". Routeros does command completion on the CLI, so this is finger-slip territory, and the two commands are visually similarly enough to each other that it would be easy not to notice. Nick

Mark Tinka wrote on 11/08/2023 10:33:

It is not terribly clever of Mikrotik to have two commands that do different things be that close in syntax.

no, indeed.

That said, why are we giving the routers the ability to manually generate AS_PATH's? On any router OS, this is simply asking for it.

bgp is a policy based distance vector protocol. If you can't adjust the primary inter-domain metric to handle your policy requirements, it's not much use. Nick

BGP was indeed designed in an era when trust was implicit. Introducing ASPA to sign a cryptographic list of authorized providers steps in the right direction. By validating both AS_PATH and route origin, the chances of BGP hijack and misconfigurations can be substantially reduced. https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ On 2023-08-11 13:51, Mark Tinka wrote:

On 8/11/23 12:56, Nick Hilliard wrote:

...

bgp is a policy based distance vector protocol. If you can't adjust the primary inter-domain metric to handle your policy requirements, it's not much use.

I am not talking about appending one's own AS in the AS_PATH. I am talking about appending someone else's AS in the AS_PATH.

To be fair, I have never had to do that, since I've always thought it would be considered bad form. But I suspect that on the simple BGP mechanics of it, no vendor would be able to prevent that in any meaningful way.

Then again, path hijacking likely wasn't a thought at the time the Border Gateway Protocol was being conceived.

Mark.

-- August

It should be a huge embarrasment to the designers. They survive on low price and unique features. It would be quite amazing to have a CLI without the nonsense.

That ship sailed years ago. Even though the legal precedent was set after Cisco vs Arista that CLI elements that are of common , standard usage aren't copyrightable, nobody wants to take the risk. So they come up with other ways that tend to be not good. On Mon, Aug 14, 2023 at 12:21 PM Chris Cappuccio <chris@nmedia.net> wrote:

Mark Tinka [mark@tinka.africa] wrote:

...

It is not terribly clever of Mikrotik to have two commands that do

different

...

things be that close in syntax.

It should be a huge embarrasment to the designers. They survive on low price and unique features. It would be quite amazing to have a CLI without the nonsense.

That's a terrible excuse for the shitty concepts behind MikroTik's CLI.

Fear of being sued into oblivion by a massive corporation, even if they're in the wrong, has influenced many choices in technology. To be clear, I am not stating that Mikrotik made the CLI choices they did BECAUSE of that concern. I have no knowledge there. I do know that Much Larger Vendors have absolutely made tradeoffs because they didn't want to deal with legal actions from Another Large Vendor or Patent Troll, so it's not exactly uncommon. On Tue, Aug 15, 2023 at 5:43 PM Chris Cappuccio <chris@nmedia.net> wrote:

Tom Beecher [beecher@beecher.cc] wrote:

...

...

It should be a huge embarrasment to the designers. They survive on low price and unique features. It would be quite amazing to have a CLI

without

...

the nonsense.

That ship sailed years ago. Even though the legal precedent was set after Cisco vs Arista that CLI elements that are of common , standard usage aren't copyrightable, nobody wants to take the risk. So they come up with other ways that tend to be not good.

That's a terrible excuse for the shitty concepts behind MikroTik's CLI.

I'm not saying my stuff is much better, but yeah, actually I am.

Mike Hammett [nanog@ics-il.net] wrote:

Most people I know don't even use the CLI. They use Winbox.

Which is also terrible.

Mike Hammett [nanog@ics-il.net] wrote:

I'd say it's probably the best router UI ever, but I suppose now we'll find ourselves in a religious argument.

If that's truly how you feel, I would want to talk with you on Signal and get a better idea for what you like and don't like.

On 8/16/23 00:28, Nick Hilliard wrote:

Whatever about the web / winbox UI, there are some fairly serious weaknesses in the cli and api:

1. there's no atomic configuration commit + auto rollback. 2. the CLI is non-idempotent, for example if you're in a list context and issue the command "remove 1", it will do different things each time you execute it. 3. there is no way to delete the configuration tree or sub-trees (e.g. "config replace"), which outright blocks the possibility of clean-slate reconfiguration. 4. as a consequence of #1 and #3, it's not possible to blindly change the config on a routeros device without parsing the existing configuration.

The net outcome is that orchestration is basically impossible on this platform, and it's not possible to fix. It would need a complete CLI/API redesign.

The detriment of the Mikrotik commercial model is also its success. I often tell people that it's a "take it or leave it" kind of model. They offer no roadmaps. They offer no bug-fix guarantees. They offer no release date guarantees. They make promises not to provide any guarantees. They just work at their own pace, and focus on what their heart desires at the time. But because of this model, they keep their software and appliances extremely cheap, focus on what receives most attention from the wider community in lieu of "big customers", and in the end, deliver a product that packs a lot of features in a 12MB-sized OS that most of its followers are able to use to run a service provider network. The inconveniences of the CLI and/or Winbox are just that to their followers... inconveniences. They hurt, but not enough to force them to consider more traditional vendors. Kind of like the dog that sits on the nail continuously whining about the pain, but can't seem to get up from under the nail to free itself of the anguish. Mikrotik aren't going anywhere, because their followers are content with the model. If operators that run traditional vendor gear continue to allow BGP sessions to form with Mikrotik routers, this problem will not go away. I am not stating that non-Mikrotik equipment block Mikrotik BGP sessions; I'm just saying Mikrotik currently have no incentive to put better code out on to the Internet. Mark.

On 8/11/23 02:26, Nick Hilliard wrote:

If your asn is 327933, then:

add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend=2

... will produce: "327933 327933", and:

add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend-path=2

... will produce: "327933 2".

Routeros does command completion on the CLI, so this is finger-slip territory, and the two commands are visually similarly enough to each other that it would be easy not to notice.

In other news, Mikrotik users at that ASN are discovering that 327,933 prepends may be a bit excessive. -- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

Malte Tashiro wrote on 12/08/2023 04:50:

Looking at this I also saw that for a short time some prefixes belonging to AS37451 were announced by AS2454388738 (see [0] and [1]). Anybody have a smart idea which command could have caused this?

AS2454388738 == AS37451.2, in asdot format. Nick

On 8/10/23 20:43, Randy Bush wrote:

classic microtik prepend syntax confusion?

Uncertain. I have a Mikrotik CPE for my home router, but I can't tell you how BGP works on it. It seems that AS2, in the path, is not genuine. We are verifying that, though. Mark.

On 8/10/23 12:01, dc@darwincosta.com wrote:

I know someone you might know them. Happy to introduce off-list.

Yes, Darwin. That would be most appreciated. Thanks. Mark.