Re: [Sidrops] Call for SIDROPS WG Agenda Items

[Alexander Azimov <[e-mail]>]

Andrei,

Thank you for the comments.

2018-07-10 13:55 GMT+03:00 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?
>
I had in mind two scenarios:

   - Provide a limited opportunity to 'old' BGP software to verify routes
   using ASPA;
   - Provide solution for a case when AS_PATH wasn't properly reconstructed
   and there are AS_TRANS left.



> >  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.
>
Yes, each ISP by signing ASPA will improve the level of its own security
and security of its customers - that's a really important motivation. If
there is a complete sequence of signed ASPAs from edge to Tier1 - then the
attacker will have no opportunity to create a valid AS_PATH in terms of the
verification procedure.

We can consider adding additional state 'unknown' or 'partial valid'. It
will have similar semantics to 'unknown' output of ROA validation
procedure. But as you know, the current practices are focussing on dropping
'invalid' routes, there is no difference in processing 'unknown' and
'valid' routes.

>
> > 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?
>
For me it seems that we don't need any additional information to verify
routes received from customers and peers.
So, I've tried to make it as simple as possible.

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: [phone]
| mob.: [phone]
| skype: mitradir
| mailto: [e-mail]
| visit: www.qrator.net