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