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

From: Alexander Azimov <[email-masked]>
Date: Tue, 20 Aug 2019 12:08:38 +0300

Hi Jakob,

I'm sorry that it took so long to reply to your suggestion.

I think that explicitly state what means the absence of record (AS-A, AS-C)
is a good idea.
There are already several minor issues that were found in the draft, I will
work them through in the next couple of weeks.

сб, 27 июл. 2019 г. в 04:35, Jakob Heitz (jheitz) <[email-masked]>:

> 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 <[email-masked]>
> wrote:
>
> I'm sorry for the last email. It was supposed to be bigger.
>
> пт, 26 июл. 2019 г. в 08:38, Jakob Heitz (jheitz) <[email-masked]>:
>
>> 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.
>
>

-- 
Best regards,
Alexander Azimov