Concerning the structure of ASPA tables and AS0

[Ralph Covelli]

Hi Maria!

Interesting stuff!  I suppose you could consider the different AS's in 
the SET as "lateral" from each other on "the mountain".

It looks like the newest (aspa-19) wording of the standard demands that 
you throw them all out as invalid anyway.

https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/

7.2.  Algorithm for Upstream Paths

    3.  If the AS_PATH has an AS_SET, then the procedure halts with the
        outcome "Invalid".

7.3.  Algorithm for Downstream Paths

    3.  If the AS_PATH has an AS_SET, then the procedure halts with the
        outcome "Invalid".

I am going to see if I can convince the powers that be to change 7.3.3 
to "Unknown".

Thanks again!

Ralph Covelli
Network Engineer
Hurricane Electric / AS6939

On 12/27/2024 12:31 PM, Maria Matejka via Bird-users wrote:
>
> Hello Ralph,
>
>     Yes, “I have no providers” is a much more accurate description of
>     AS 0.  It can be used by tier 1 networks as well as people trying
>     to depreciate their old ASN.
>
> Well, yes, a deprecated ASN has also no providers, yet it can still be 
> (maliciously) placed into a valid AS path if it is on the top place. 
> OTOH, with that, the attack surface is limited only to your downstream 
> networks.
>
>     It looks like the source of my confusion was that I was under the
>     assumption that the transit ASPA entries could be used to
>     auto-detect upstream vs downstream as opposed to doing the check
>     in the filter script.  Sorry about that!
>
> No problem, everybody is confused by ASPA. It’s hard to get it right.
>
>     I noticed in aspa_check() you check for confeds but AS_PATH_SET is
>     never checked for.
>
> Well, that looks like another oversight, thank you for reporting.
>
>     The specs say they should return ASPA_INVALID however I noticed
>     when I did that I lost about 64 routes which caused some customer
>     complaints.  I had to end up slightly changing the code to return
>     ASPA_INVALID if upstream and ASPA_UNKNOWN if downstream.
>
> Mhmmm. That’s definitely a problem. We can do various things with and 
> around that. First of all, the default behavior of |aspa_check()| must 
> conform to the RFC.
>
> Brainstorming:
>
>  *
>
>     something like |if bgp_path.contains_sets|
>
>  *
>
>     allowing a more precise for-cycle over |bgp_path|, e.g.
>
>     |for bgppath_segment bs in bgp_path do { case bgppath_segment.type
>     { AS_PATH_SEQUENCE: for int a in bs do { ... } AS_PATH_SET: for
>     int a in bs do { ... } AS_PATH_CONFED_SEQUENCE: ... } }|
>  *
>
>     adding an optional argument to |aspa_check()| to allow sets,
>     treting them as “any of the ASNs in the set”
>
>  *
>
>     adding an |aspa_is_customer(table, A, B)| function, returning
>     whether A can be a custormer of B according to the given table
>
> Any other thoughts on that?
>
> Thanks,
> Maria
>
> –
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20241227/e38bfd09/attachment.htm>