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

Christoph cm at appliedprivacy.net
Sat Oct 5 12:43:00 CEST 2019


>>> 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:

https://tools.ietf.org/html/rfc6811 :
>    o  Route Origin ASN: The origin AS number derived from a Route as
>       follows:
> 
>       *  the rightmost AS in the final segment of the AS_PATH attribute
>          in the Route if that segment is of type AS_SEQUENCE, or
> 
>       *  the BGP speaker's own AS number if that segment is of type
>          AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty,
>          or
> 
>       *  the distinguished value "NONE" if the final segment of the   <<<<
>          AS_PATH attribute is of any other type.                      <<<<
[...]
>    We observe that no VRP can have the value "NONE" as its VRP ASN.
>    Thus, a Route whose Origin ASN is "NONE" cannot be Matched by any
>    VRP.  Similarly, no valid Route can have an Origin ASN of zero [AS0].
>    Thus, no Route can be Matched by a VRP whose ASN is zero.

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.

So an attacker could do the following to bypass BIRD's ROA check:
- lookup prefixes for which an AS0 ROA exists
- announce these prefixes using an AS_SET segment type

Can you confirm that?

thanks,
Christoph


[1] https://tools.ietf.org/html/rfc7607 :
>    By allowing a Resource Public Key Infrastructure (RPKI) resource
>    holder to issue a ROA saying that AS 0 is the only valid origin for a
>    route, we allow them to state that a particular address resource is
>    not in use.




More information about the Bird-users mailing list