RPKI ROA max length smaller than my actual announcement

• ROA max-length /24 on my /22
• RIPE shows valid, some RIRs show invalid
• Partial propagation = nightmare
• Anyone seen this before?

I announced a /22 with a ROA that had max-length /24. Thought that meant "anything from /22 to /24 is fine." Turns out no. Some validators interpreted it as "only exact /24s under this /22 are valid," which made my /22 itself invalid. Took 6 hours to find because most paths looked fine. Only one upstream's filtering caught it and blackholed partial traffic.

• Vultr side: clean
• Hetzner side: 30% loss
• Leaseweb side: clean

Updated ROA to max-length /22, fixed in ~10 minutes propagation. But why is this default behavior anywhere?

RFC 6482 section 3.3, the max-length is inclusive upper bound, not a wildcard. Your /22 with max-length /24 creates a set of valid prefixes: the /22 itself plus any /23 or /24 that falls inside it. AS path validation should accept the /22. If your upstream's validator rejected the /22, their implementation is non-compliant.

Here's what a proper ROA looks like for your prefix:

AS64496
192.0.2.0/22
Max-length: 22
|
+-- valid: 192.0.2.0/22
|
+-- with max-length 24, also valid:
192.0.2.0/23, 192.0.2.0/24, etc.

What validator software is your upstream running? Without knowing your AS and prefix I can't check their ROV setup, but this smells like a bug in their parser, not your config. The RFC is at https://datatracker.ietf.org.

Specs:

• ROA: /22 with max-length /24
• Intent: announce /22 as valid
• Reality: some validators (rpki-client 8.x, specific build) had bug where parent prefix validity depended on child existence

Numbers:

• 6 hours to diagnose
• 30% traffic loss
• 10 minutes to fix after diagnosis

As said, the /22 itself should validate. The bug was in rpki-client 8.2 through 8.4, fixed in 8.5. Your upstream likely runs outdated validator.

Dry humor: you spent 6 hours proving someone else's software was wrong. Welcome to BGP.

Check your provider's TOS section 7.3 on "acceptable use" of their RPKI validation services. If their buggy validator caused packet loss, that's a service deficiency, not a routing policy violation on your end.

Pedantic point: "ROA" is the object itself; "ROV" is the validation outcome. Your ROA was syntactically valid. Their ROV implementation was functionally deficient. These are distinct concepts under ARIN's Relying Party Agreement section 4.2, which disclaims liability for validation software errors.

Also, "partial invalidation" is not defined in any RFC. You experienced selective route suppression due to inconsistent validator behavior. Precision matters if you escalate to your upstream's NOC.

Route via Vultr adds 2ms, clean
Route via Hetzner adds 14ms and 30% loss

Host                            Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.0.2.1                      0.0%    10    0.3   0.4   0.2   0.6   0.1
2. 10.64.0.1                      0.0%    10    2.1   2.3   1.9   3.1   0.3
3. lg-ams.vultr.com          0.0%    10    2.4   2.5   2.2   3.4   0.3
4. hetzner.com     30.0%    10   16.2  15.8  14.1  18.3   1.2

The loss pattern matches RPKI invalid drop, not congestion. Single-path failure, asymmetric return. Your traceroute to affected destinations would show blackholes at hop 4 specifically.

Anyway I stayed up until 4am reproducing this in my lab

Idk why I do this

$ rpki-client -V
rpki-client 8.3
$ # /22 shows invalid, /23 shows valid, same ROA
$ # upgrade to 8.5: both valid

The bug was literally "if max-length!= prefix-length and no more-specific ROAs exist, parent marked invalid"

Who ships this. Who

Same bug, 3 hours last month

Which rpki-client version is your upstream running, 8.2 or 8.4

If RIPE showed valid, how did only one upstream catch it?