All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
AS24875 NovoServe B.V. is spoofing our AS59432
Today we have received a notification that our AS59432 (GINERNET) had a peering against AS24875, however this is false, in our router there is no BGP session against this AS24875 (NOVOSERVE).
After a thorough analysis, we found that:
The AS24875 (NOVOSERVE) has an AS-SET named: AS-NOVOSERVE-CUSTOMERS.
And our AS59432 (GINERNET) is part of it without being authorized by us.
The prefix 176.57.50.0/24 is visible on the Internet with the AS-PATH: "24875 59432".
However, as I said, we AS59432 (GINERNET) do not have any BGP session against AS24875 (NOVOSERVE).
For this reason, we deduce that the AS24875 (NOVOSERVE) has within its network a "client" that has spoofed our AS59432 (GINERNET) and they are committing the failure to keep that BGP session active.
(I do not understand how someone can activate a BGP session and not verify the authority of the peer).
We have contacted AS24875 (NOVOSERVE) support and what they have replied is just this line:
I have forwarded this to our customer.
I find this answer totally unacceptable... they should remove our AS from their AS-SET and cut the BGP with the router that is spoofing our AS.
What can we do now if they do not attend our request? We understand that this is an illegal action.
Thank you.
Comments
You can open a case in RIPE and get them suspended or worse if you can prove that nothing is being done even after reporting it. They are still responsible for it, even if their customer does it and they approve it.
Best way to get bad attention for them is to make an email into RIPE mailing list explaining the situation and the response you got. It will be solved within hours after that regardless what the client says. I guarantee it.
.
Apparently, this prefix appears in a residual form on bgp.he.net (maybe a cache), because we have not been advertising it for 2 months... But, we had authorization at the time, the same as this one:
https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=141.11.230.0/23AS59432&type=route
Doesn't seem like it from here.
Yet ROA and RPKI is missing. Which is exactly the mechanism to prevent hijacks.
You can see in whois that the route record for this subnet was created last month by IPXO, an IP broker.
This might indicate a legit ongoing IP subnet transfer or temporary lease where the org object is not beeing updated, yet.
We're talking about AS steal, not IP steal.
That prefix hasn't been announced by their AS for the last four weeks: https://stat.ripe.net/ui2013/widget/routing-history#w.resource=141.11.224.0/22&w.starttime=2021-06-05T00:00:00&w.endtime=2022-08-09T00:00:00
Sooo... Sue?
Fuck that this is when you adopt downtown Houston style.
Since you are a RIPE member (LIR), @jmginer, you can submit a ticket to RIPE through your LIR portal.
This is probably one of the effective things you can do.
Yea, this is definitely an AS hijack and we can confirm that this prefix is still visible through NovoServe. If it's their customer, they should just suspend the BGP session as obviously, their customer doesn't have the right to use AS59432.
If Novoserve doesn't respond in time, it's better to contact their upstream. We had the same situation before.
You cannot do so much unfortunately
i bid $7
You can always contact Novoserve's T1 upstreams are tell them to filter out the announcement with novoserve in the AS_PATH
This. If NovoServe is refusing to cooperate, contacting their T1 upstreams should be the next step.
I do advise you to ask for your ticket to be escalated at NovoServe, it sounds like a low-level tech just used the regular canned response when dealing with abuse. As to be escalated to NOC/upper management to get a better response.
The end is nigh.