[PATCH] Wrong calculation in as_path_getlen, and check_aspa improvement suggestion

[Alarig Le Lay]

Hello,

On Tue 02 Sep 2025 16:44:46 GMT, Ondrej Zajicek wrote:
> On Sun, Aug 31, 2025 at 06:04:12PM +0200, Alarig Le Lay via Bird-users wrote:
> > Hello,
> > 
> > We (Evann and I) found a bug related to as_path_getlen() when used by
> > aspa_check(). When a route contains an AS_SET segment type, the length
> > returned by as_path_getlen() is incorrect. The function assumes that the
> > length of an AS_PATH_SET is a single AS (1), while in reality an
> > AS_PATH_SET is an unordered set of ASN (as described here
> > https://www.rfc-editor.org/rfc/rfc4271#section-9.2.2.1).
> 
> Hello
> 
> Thanks, merged the second patch:
> 
> https://gitlab.nic.cz/labs/bird/-/commit/93012b3ac81bc8e2a0a9b7e48b552c269b0523d9
> 
> (I modified comments and expanded as_path_contains_set() to match also
> AS_CONFED_SET, which is irrelevant to this case, but it is fitting.)
> 

Thanks a lot!

> > Originally, the segfault was handled by returning ASPA_INVALID on AS_PATH
> > that contained an AS_SET, but we discovered that this was not the real
> > problem, but rather a bad allocation due to an incorrect calculation of
> > the AS path length. We mitigated this issue with our first patch.
> 
> The real problem was using as_path_getlen() to estimate the size of a
> buffer in general. The primary purpose of as_path_getlen() is to compute
> AS_PATH length for the best route comparison, and here the AS_SET segment
> should be considered of length 1:
> 
> https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.2
> 
>       a) Remove from consideration all routes that are not tied for
>          having the smallest number of AS numbers present in their
>          AS_PATH attributes.  Note that when counting this number, an
>          AS_SET counts as 1, no matter how many ASes are in the set.
> 
> Therefore, the first patch would break the best path selection.

Oh yes I totally forgot about that, sorry. The issue we had we’ll be
fixed with the first patch anyway, so I’m fine with that :)

-- 
Alarig