Re: [Sidrops] ASPA verification algorithm error

[Ben Maddison <[e-mail]>]

Hi Jakob,

On 02/11, Jakob Heitz (jheitz) wrote:
> pair_check with either AS2 or AS3 as customer will return unknown.
> Therefore, the algorithm returns unknown, when it should return valid.
> 
If I'm understanding you correctly:
*Any* ASPA (even an [AS0] one) issued by either AS2 or AS3 would result
in a valid path.
Therefore, you are arguing, even if no ASPA covers the AS2<->AS3
adjacency, the path should be considered *valid* since there is no possible
ASPA object that could result in it being *invalid*?

I think that logic holds. However I don't favor incorporating it into
the validation algorithm for a few reasons:
1.  We (and I expect most others) will make no policy distinction
    between valid and invalid paths in policy. Thus any additional complexity
    is a poor trade.
2.  It is important that engineers are able to easily reason about how a
    set of ASPA objects and an observed AS_PATH result in a validation
    state. Whilst I think the above logic is valid, accounting for it
    mentally is non-trivial.
3.  In the event that operators do de-pref invalid in favor of unknown
    (yes, I know I said above that they probably won't: but *if* they do),
    then AS2 and AS3 lose traffic on that adjacency (which is undesirable for
    them both - otherwise they won't have built it).
    This creates a positive economic incentive for AS2 and/or AS3 to go
    and create an ASPA. Positive incentives are in short supply in the
    routing security world - I don't think we should opt-out of them
    lightly!
4.  There is no creation dependency problem for ASPAs, like there is for
    ROAs - where e.g. a provider has to wait for customers to issue ROAs
    for all sub-allocations before issuing for the aggregate. As a
    result I don't believe that we should be spending cycles
    accommodating those operators that don't bother doing it.

Interested to hear your thoughts?

Cheers,

Ben