Re: [Sidrops] ASPA verification algorithm error

[Alexander Azimov <[e-mail]>]

Jacob, you are right that additional heuristics can be added to ASPA logic
to transform some Unknown states to Valid, though it will not improve
leak/hijack detection.
Nevertheless, I agree with Ben. Such changes can result in
misleading understanding if one will try to distinguish if the path is more
reliable a.e. Valid from Unknown. This has special importance if we start
speaking about malicious activity.



пт, 12 февр. 2021 г. в 11:10, Ben Maddison <benm=
[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
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>


-- 
Best regards,
Alexander Azimov