Re: [Sidrops] On validating AS paths

[Alexander Azimov <[e-mail]>]

Hi, bellow my additional comments.
Just in case - I removed from quote those parts where we are on the same
side.

a1 ^ a2 / a3 \ a4
>
> ^/\ is not a valid path. So a3 has to register its C2P relationship with
> a2.
>
You can't enforce it. Sibling occurs not only between parties under single
administrative control.
And you don't want to have such kind of dependency for your security
configuration.


> Maybe it can be fixed by adding a sibling flag to the c2p record, but at
> the moment I'm not sure about security consequences.
>
>
> In the draft you mention that it's important that the customer can claim
> the relationship and not the provider. So I would be hesitant to have a S2S
> relationship record is that would either be too easy to claim (if one
> sibling can do it) or complex to implement (only valid when both siblings
> claim the relationship).
>
IMO the moment we require two (or more) independent parties synchronize
their configuration without automation - we lose.
My idea was to add one-side s2s (or c2c) to make it work. But I'm still not
sure about this.


> And to follow up my previous email, if we have a network with malicious
> intent that would hijack/disaggregate prefixes + create a 'virtual peering
> link' between it and victim ASN, its customers will not able to detect it
> anyway since it will look like a valid path: '-\'.
>
>
> You mean a virtual sibling link? No, we certainly don't want that to be
> possible.
>
No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixes
with a malformed path to my customer.
To bypass filters based on your proposal I just need to have a 'virtual'
link with the originator.

If the original path was 'a1 a2 a3 attacker customer', the path 'a1
attacker customer' will be also valid. (the path is again reversed, just to
keep it same to the previous email).

So, if we are not speaking about BGPSec-like signatures, your approach will
not protect from ASPATH violation.
The thing it might bring is the detection of mistake route leaks that are
received from providers. So, it can bring benefit at the state of early
adoption.

I will try to integrate into ASPA logic. I have a feeling that it can be
done without registering siblings.

-- 
Best regards,
Alexander Azimov