Re: [Sidrops] Call for SIDROPS WG Agenda Items

[Alexander Azimov <[e-mail]>]

Hi Tim,

Thank you for the feedback! Please see my inline comments

2018-07-05 13:01 GMT+03:00 Tim Bruijnzeels <[e-mail]>:

> Since it’s the customer ASN who signs would it be a good idea if they
> listed all provider ASNs in a single object? There is no fate sharing risk
> like we have in ROAs when including multiple signing prefixes. On the other
> hand this would guarantee atomicity.
>
Interesting point. We will consider changing it this way.


> One small thing, eventually this will need a filename extension to be
> included in the IANA “RPKI Repository Name Scheme” registry. See also:
> https://tools.ietf.org/html/rfc6481#section-7.2
>
> https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/
>
>
> I am not entirely clear on the AS_PATH verification in section 5. It reads
> to me like the outcome is invalid, or unverifiable if not all of the ASNs
> on the path have published ASPAs. And that unverifiable is considered close
> to invalid. But I may have misunderstood.. so I would be particularly
> interested in this part of your presentation.
>
> All that said, I think that it would be extremely useful if a partial,
> incremental deployment can be supported. IMHO one of the big issues with
> BGPSec deployment is that it’s all or nothing, so there really is no
> incentive to deploy until everybody else has done so. With ASPAs you could
> argue that a route should be dropped if any of the pairs in the path turns
> out to be invalid, but it’s okay to accept unknowns. This would allow ASNs
> to get benefits from publishing ASPAs without requiring that everyone else
> does so as well. Of course things will be better when they do as well, but
> until that time there still is a benefit. So, there is incentive for ASNs
> to be pro-active.
>
> But as I said.. I am not sure that I got this section 5 completely..
>
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';
   3. Otherwise - 'valid'.

So, the procedure may return 'valid' also in case if part of AS_PATH isn't
fully covered by ASPAs.
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.