On 9/29/21 17:27, George Tasioulis wrote:
Hi everyone,
We recently setup a new rack at a datacenter in Greece with a BGP
transit (a blend of Level3, Cogent & PCCW) from them.
Everything runs smoothly but we entered a conflict when we tried to
blackhole an IP using their blackhole community while implementing
fastnetmon.
Apparently they suggest that in order for them to accept my /32
announcement (using their blackhole community), it needs to have a ROA
in order to be RPKI valid. Otherwise they reject it (which is why ours
tests failed).
So I never had this before with other ISPs, and it got me baffled.
Obviously having to log into my RPKI dashboard, add a ROA, wait till
it propagates in order to be able to blackhole an IP is time consuming
and of course counterproductive. To this, they suggested I can contact
their support if I need to have an IP blackholed faster…
Why do they offer a blackhole community in the first place then?
Anyway, I provided my objections but obviously it’s their network they
can run it however they want. Yesterday they contacted me again, and
told me I can create a second ROA for each of my prefixes I announce
via them, but with a /32 maxLegth, which would validate my /32
announcements.
Again, I never had to do that in the past with other datacenters, nor
have I ever heard of this so I looked it up.
Looks like Job Snijders clearly states that this should be avoided
(1^st recommendation):
https://mail.lacnic.net/pipermail/lacnog/2019-May/007058.html
So here I am, asking the community for their input on this matter.
- Have you had similar issues with your transit providers in the past?
- Shouldn’t blackholing precede RPKI validation so that the “invalid”
/32 announcement doesn’t matter?
- What do you think about their suggestion to add a second ROA with
maxLength value of /32 – what are the implication?
Any other info/help will be greatly appreciated.
Well, if we did not imagine how the RPKI could be used to create
unnecessary breakage, human being will never cease to surprise.
In short, it's a pity that they are doing this. It's needlessly complex,
adds a terrible failure mode, and negates the RTBH service they are
offering. I have never believed that RPKI and RTBH should be conflated;
each of them is more reliable when operated on its own. I still maintain
that belief.
Polluting the RPKI database with additional ROA's to account for
complexities that don't add any real value certainly introduces new
problems whose consequences we can't immediately foresee.
Find someone with someone at your upstream that has some idea about how
networking actually works, and hit them with a clue bat.
Not sure if Job is on this list, but if he isn't, I'll loop him in anyway.
Mark.
