Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns

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

The draft states:

An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements onward, e.g. to the Provider’s upstream providers or peers.

I suggest to make this more precise and to add the "otherwise" condition:

An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements to all of the provider's neighbors. If an AS, AS-A publishes at least one ASPA and it lists AS-B as a provider and AS-C is connected to AS-A, but AS-A does not list AS-C in an ASPA, then AS-A authorizes AS-B to propagate the announcements of AS-A to all of AS-B's neighbor ASes and authorizes AS-C to propagate AS-A's announcements only to ASes that consider AS-C to be their provider. I.e., AS-A prohibits AS-C from propagating the announcements of AS-A to AS-D if AS-D does not consider AS-C to be provider for AS-D.

Consequently, a chain of ASPAs can be used to verify the plausibility of an AS-PATH.


Thanks,
Jakob.


On Jul 26, 2019, at 11:08 AM, Alexander Azimov <[e-mail]<mailto:[e-mail]>> wrote:

I'm sorry for the last email. It was supposed to be bigger.

пт, 26 июл. 2019 г. в 08:38, Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>>:
If you receive an AS-PATH of 2 ASes and neither of them make any attestation,
then your procedure calls it valid. It could be invalid,
so it must be considered unknown.
It an interesting point. When I was writing the ASPATH verification procedure I had in mind that we need to detect invalids. But for debugging purposes, it might be also useful to distinguish fully verified paths where all pairs are valid and those paths that represent a combination of valid and unknown pairs. It will also require clarification that for backward compatibility such unknown paths MUST be treated as valid. We should add this option into consideration.

If an AS-PATH contains an AS-SET, then the segments on either side of
the AS-SET can still be verified. If any such segment turns out to be
invalid, then the whole path must be considered invalid, not unverifiable.
I do agree and that's how both downstream path upstream path procedures are defined in the draft.
As we discussed in person, we might need additional clarification in the beginning where {AS(I), AS(I-1)...} sequence is defined.

My procedure accounts for these cases and more.
For the cases where every AS makes an attestation, my procedure agrees with yours.
If you have ASPA(1, 2) you can't make assumptions about relations of 2. Otherwise, it may lead to incorrect results in the case of siblings.

BTW, you have a copy/paste error in 5.2 Downstream paths:
If a route from ROUTE_AFI address family is received from a customer
should be:

If a route from ROUTE_AFI address family is received from a provider

Yes, you are right. Copy-paste can become tricky. Will be fixed in the next version.