Re: [Sidrops] Call for SIDROPS WG Agenda Items

[Andrei Robachevsky <[e-mail]>]

Alexander,

Alexander Azimov wrote on 06/07/2018 22:07:
> Yes, it seems that here is a misunderstanding. Behind section 5 there is
> a simple idea:
> 
>  1. If there is 'invalid' subpath - then the outcome is 'invalid';
>  2. If the AS_PATH can't be fully verified even if all corresponding
>     ASPAs exist (AS_SETs, AS_TRANS) - then the outcome is 'unverifiable';

In case the speaker understands 32-bit ASNs a path may be reconstructed
using the AS4_PATH attribute. Do you refer to AS_PATH in a sense of
constructed AS path (where AS_TRANS may be replaced), rather then the
AS_PATH received from a neighbor who doesn't support 32-bit ASNs?

>  3. Otherwise - 'valid'.>
> So, the procedure may return 'valid' also in case if part of AS_PATH
> isn't fully covered by ASPAs. 

It doesn't make much sense to me to declare the path valid even if some
of the segments cannot be verified. As opposed to BGPsec it is not all
or nothing in this case, as I understand it. Valid ASPAs linking
segments on both ends of the path provide value since an attacker cannot
craft a shorter path, and will probably lose because of that. So in this
sense every ASPA is an incremental improvement.

> And to support detection of intentionally malformed AS_PATH for selected
> ASN it's enough if all its upper providers create ASPAs. For
> transit-free networks this rule is even more simplified - they just need
> to create ASPA0. IMHO - it provides a quite powerful mechanism even at
> the state of partial deployment.

I like the simplicity of the approach, are different types of
relationships between the two AS'es outside the scope?

Thanks,

Andrei