BIRD - RoA with aggregated prefixes - issue

Javor Kliachev jkliachev at neterra.net
Tue Jul 14 07:40:38 CEST 2020


Hello,

Thank you very much for the quick responses.

We don't use BGP aggregated routes but our customers are using.

Best~

Javor Kliachev 
Senior Engineer IP Services 
office: +359 2 974 33 11 
mobile: +359 885 98 84 95 
[ http://www.neterra.net/ | www.neterra.net ] [ https://bg.linkedin.com/pub/javor-kliachev/11/b46/843 | 
                                                                                                      ]

----- Original Message -----
From: "Chriztoffer Hansen" <ch at ntrv.dk>
To: "bird-users" <bird-users at network.cz>
Cc: "nmt-ip" <nmt-ip at neterra.net>, "Javor Kliachev" <jkliachev at neterra.net>
Sent: Monday, 13 July, 2020 20:38:22
Subject: Re: BIRD - RoA with aggregated prefixes - issue

Javor,

On Mon, 13 Jul 2020 at 08:32, Javor Kliachev <jkliachev at neterra.net> wrote:
> We're using BIRD 1.6.4 as Route Server.
>
> Recently we have implemented ROA prefix validation but we have hit the issue with prefixes that are aggregated only.
>
> What do I mean: When the prefix is aggregate and has something like 1234 { 10, 20 } in AS_PATH in the last ASN, bgp_path.last value returns zero ( 0 ). As a result of this, we just discarding such prefixes.

Do not use BGP aggregate routes?

RPKI validation is not feasible for BGP aggregate routes. E.g. the ROA
for AS 10 is valid and invalid for AS 20. What do you do in this case
if AS-path is 1234 { 10, 20 }? Say OK and accept it or reject the
unknown, due to the impossibility of validation the BGP route fairly
in accordance with the earlier mentioned expected RFC behaviour.

I general, the amounts of BGP aggregate routes in the DFZ is low
(measured -at most- in the hundreds if not in the tens).

-- 
Chriztoffer



More information about the Bird-users mailing list