the semantics of AS0 in ROAs (was: misunderstanding or incorrectly implemented filter?)

[Ondrej Zajicek]

On Sat, Oct 05, 2019 at 10:43:00AM +0000, Christoph wrote:
> >>> Reject RPKI INVALID announcement 200.124.231.0/24 by AS0
> > 
> >>
> >> So I was wondering:
> >> - Did I incorrectly assume first match wins?
> >> - Is the reject_bogon_asns() function not working as intended?
> > 
> > Hello
> > 
> > bgp_path.last returns 0 if the last item is AS_SET. There are most likely
> > no AS0 in the path.
> 
> Thank you for your explanation.
> 
> I looked into the relevant RFC to find out what is supposed to happen
> in cases where the final segment type is AS_SET:
> 
> It looks like BIRD's mapping from "NONE" to "0"
> leads to the following problem and attack possibility:
> 
> RPKI ROAs with an AS0 are used by address holders to state "this prefix
> is not in use don't accept any announcement containing it" [1].
> examples: https://rpki-validator.ripe.net/roas?q=AS0
> 
> AS0 in AS_PATH is commonly filtered but the announcements
> in question do not actually contain any AS0 and will not be filtered.
> 
> As I understand it BIRD's ROA check as seen in the
> documentation will return a RPKI validity state of VALID
> if the last AS_PATH item was of type AS_SET and the
> address holder created a ROA with AS0 for it.

That is a good point, but the ROA check verifies that ASN is non-zero
in order to success:

  if (asn && (roa->asn == asn) && (roa->max_pxlen >= px->pxlen))
    return ROA_VALID;

So it should be correct.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."