Re: [Sidrops] Which 8210-bis error code should be used?

[Claudio Jeker <[e-mail]>]

On Tue, May 23, 2023 at 03:10:26PM +0000, Jay Borkenhagen wrote:
> Hi Claudio,
> 
> Regarding the case where an ASPA exists for one AFI but not the other:
> 
> I acknowledge your preference to not require separate but nearly
> identical tables for ipv4 and ipv6, and I agree with you that an
> ASPA-verifying bgp implementation can deal with this situation in its
> hop-check function by inferring a table entry for that 'missing' AFI.
> 
> However, inferring an AS0 ASPA table entry is almost certainly not
> what the creator of the single-AFI ASPA had intended.  I do not know
> all the reasons why someone would create an ASPA for one AFI but not
> the other, but two that come to mind are:
> 
> - "All my INRs are ipv4, so I don't care about ipv6" -- in which case
>   it doesn't matter how ASPA-verification treats ipv6 for this ASN,
>   
> and:
> 
> - "I want to wade carefully into ASPA, so let me do only ipv6 first"
>    -- in which case they do not intend to imply that they are
>    default-free for ipv4. 

I think the creator of such an ASPA record did not do the necessary due
diligence before publishing an ASPA record. Publishing bad records and
hoping for the best is not a winning move.

Regarding your two scenarios:
In the first case you really want to block IPv6 else you open the door for
others to abuse your badly specified entry. ASnums resulting in an unknown
ASPA validation outcome are powerful gadgets to hijack traffic.

While I understand your second argument I do not agree that "lets wade
carefully" is a good aproach in this case. One thing to consider is that
any transit provider ASPA also affects its customers. In general
debugging ASPA issues is more complex than ROA since multiple ASPA records
play together and so having less options makes diagnosing issues easier.
The impact of an ASPA record does not only affect the ASPA record holder,
this is different from ROA.

Right now the publishing rule is very simple: If you publish an ASPA
record your AS is protected by it. There is no half in / half out, maybe
but just a bit mode.
This is a security enhancing element of BGP, it should be simple and easy
to reason about. This is why I argue that the rule of being either in or
out is right.

It is important that the rules on how to build ASPA objects must be
simple and easy to understand. Right now the rules are:

- If you publish a valid ASPA record then your AS is protected.
- The list of SPAs only needs to include real transit provider AS numbers.
  You don't need to add any RS or lateral peer (the only exception are
  sibling relations where the peering provides transit in both directions)
   -> In other words keep the list minimal
- Avoid the trap of specifying an AFI for an entry. It will bite you
  (maybe not now but later at the most inconvenient time). Consider the
  optional afi like the optional maxlen of ROA.
 
> Because an assertion of being default-free is not what any single-AFI
> ASPA creator would intend, this takes us down the path of whether
> ASPA-generating CAs should prohibit or warn operators that they're
> about to do something with more severe consequences than they may
> realize.  It would be good to avoid that mess.
 
I agree that ASPA-generating CAs (especially the RIR portals) need to stop
or warn operators when they create entries that only cover one AFI.
Actually the portals should discourage the operator to use AFI specific
entries in the first place.
 
> As an alternative, I would like to propose inferring a wildcard table
> entry for the missing AFI, as if the signer had created an ASPA
> indicating that every other ASN is one of its providers for the
> missing AFI.
> 
> 
> For the process of rejecting invalid AS_PATHs, a wildcard will have
> the same result as if no ASPA existed, which is the actual situation
> at hand for that 'other' AFI.
> 

I strongly disagre. There was no need to add "wildcard" entries into ROA.
If you cover an address block in RPKI ROA there is no way to uncover some
address space below. There is a good reason for this and that is security.
ASPA must behave the same.

Why do we need to add unnecessary bells and whistles to ASPA?
The only reason to do so is to allow a group of people to write up a
new RFC in the future to tell everyone that this or that feature should
not be used (like RFC9319). Do we really need to go through these loops?
Is it impossible for this group of engineers to learn from previous
mistakes?

Remember:
Rule number one to improve security is to remove options, not adding them.

-- 
:wq Claudio