Re: [Sidrops] ASPA verification algorithm error

["Jakob Heitz (jheitz)" <[e-mail]>]

It seems we all agree that the path I illustrated is valid and the algorithm in the draft marks it unknown.
The first priority is to get the correct result.

ASPA has to work as well as possible without full participation.
It will never work if full participation is required.

I agree with Ben that it is difficult to reason with the model of ASPA as written in the draft.
Here is an alternative:

    Every transit AS in the path must have at least one neighbor that calls it a provider.

That's a lot easier to reason about than trying to figure out where upstream turns to downstream
in the presence of bilateral peers, siblings, complex relationships and ASes making no attestations.
You only need to consider one AS at a time and what is to its left and to its right.

Repeating:

Consider the as-path (1 2 3 4), where
1 attests that 2 is its provider
4 attests that 3 is its provider
2 and 3 make no attestations.
Then the path is valid.

Here is a simple and working algorithm:


  *   The received AS-path is prepared:
     *   Remove duplicate ASNs.
     *   Prepend own ASN.
     *   May also prepend Forwarded-to ASN to detect own leak. (optional)
  *   For every sequence (A, B, C) of consecutive ASes in an AS-path:
     *   If A attests that B is not a provider and C attests that B is not a provider,
then B leaked the route: B is transiting for free. The segment is invalid.
     *   If either A or C attests that B is a provider, then the AS-path segment  (A, B, C) is valid.
     *   Else if either A or C make no attestation, then the leak state is unknown. Even if B lists both A and C as providers, it is not necessarily a leak, because either A or C could consider B as a provider for some of their routes, even though they don’t attest to it.
  *   If all the path segments are valid, then the whole path is valid.
  *   If any of the path segments is invalid, then the whole path is invalid.
  *   Else, at least one path segment is unknown and one more rule must be applied: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1 is not a provider and C attests that Bn is not a provider, then the AS-path is invalid. This is for any number of Bx greater than 1.




Regards,
Jakob.

From: Sidrops <[e-mail]> On Behalf Of Alexander Azimov
Sent: Friday, February 12, 2021 10:26 AM
To: Ben Maddison <benm=[e-mail]>
Cc: Jakob Heitz (jheitz) <jheitz=[e-mail]>; [e-mail]; Lukas Tribus <[e-mail]>
Subject: Re: [Sidrops] ASPA verification algorithm error

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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azimov