Re: [Sidrops] On validating AS paths

[Alexander Azimov <[e-mail]>]

Here is a sample of pseudocode:

def verify_aspath(local_role, reverse_aspath, neigbor_asn):
>     if not len(reverse_aspath) or local_role in (customer, peer, rs,
> provider) and neigbor_asn != reverse_aspath[0]:
>         return False
>
>     if local_role in (provider, peer, rs):
>         for i in range(len(reverse_aspath)):
>             if not i or reverse_aspath[i-1] == reverse_aspath[i]:
>                 continue
>
>             if verify_pair(reverse_aspath[i-1], reverse_aspath[i]) ==
> invalid:
>                 return False
>     elif local_role in (customer, rs_client):
>         going_up = True
>         for i in range(len(reverse_aspath)):
>             if not i or reverse_aspath[i-1] == reverse_aspath[i]:
>                 continue
>
>             if going_up and verify_pair(reverse_aspath[i-1],
> reverse_aspath[i]) == invalid:
>                 going_up = False
>                 continue
>
>             if not going_up and verify_pair(reverse_aspath[i],
> reverse_aspath[i-1]) == invalid:
>                 return False
>
>     return True


It's slightly simplified (I ignored AS_SETs) but it shows that it is
possible to add route leak detection for prefixes that are received from
providers without changing ASPA profile.

пт, 5 июл. 2019 г. в 00:55, 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
>


-- 
Best regards,
Alexander Azimov