Re: [Sidrops] On validating AS paths

[Iljitsch van Beijnum <[e-mail]>]

Hi Alexander,

On 26 Jun 2019, at 18:39, Alexander Azimov <[e-mail]> wrote:

> I assume that after talking with Job Snijders you are aware of ASPA drafts.

Yes.

> They cover the detection of anomalies (invalid ASPATHs) that are received from customers and peers + specify RPKI object exactly for customer-to-provider pairs.

Yes. Note that in my previous message I was specifically addressing validating the _entire_ path, while ASPA only concerns itself with validating the "up" part of the path, where the only valid relationships are provider-customer and sibling-sibling.

Of course once we can validate the entire path, we can by definition also validate any subset.

> And of course, a path //^\ (in your notation) received from customer or peer is invalid. But I assume that you also had this in mind.

Yes, this is a valid full path but if you get it from a peer then it's actually \//^\ (from a customer) or ^//^\ (from a peer) so that's not valid.

> What I find curious in your proposal is the goal to extend the detection of invalid paths for prefixes that are received from providers.
> I was also considering this option, but it will not work with c2p database only. The problem occurs with siblings. 

Basically, a sibling relationship occurs when there is a customer - provider relationship in both directions. (As per Gao/Rexford there is the additional constraint that these relationships have the lowest local preference, but that's probably not relevant for path validation.)

So for the "up" part of the path we can use your algorithm for validation. Then for the "down" part of the path (i.e., the part that your customers see when they get updates from you, not covered in your draft) the same procedure will work as long as we look at customer -> provider relationships rather than provider <- customer relationships. I.e.:

900 800 200 100 i

You care 800. You see a valid 200 \ 100 relationship. You know that 800 ^ 200 because you are 800.

900 sees a valid 900 / 800 relationship. 900 sees 800 ? 200 based on the C2P database as there is no C2P relationship between 800 and 200 in either direction. But as per my previous message, any path with exactly one unknown relationship between a valid up part and a valid down part is still valid so the entire path is valid.

> Take a look at the next example:
> a1 p2p a2 c2c a3 p2c a4 (p2p for peering, c2c for sibling, a4 is checking ASPATH)

Do you mean: a1 ^ a2 - a3 \ a4

Note that you are using the opposite order to how BGP AS paths are normally shown, with the origin on the right. But as valley-freeness doesn't depend on the direction, I'll ignore that here.

a1 ^ a2 - a3 \ a4 = /-^ is a valid path, there are no valleys.

> If records for a1 exists (so we know that a2 isn't in the set of providers of a1), (a2, a3) records exist, but (a3, a2) doesn't, the outcome of verification procedure at a4 will be invalid. 

So a2 / a3 but not a2 \ a3 and thus not a2 - a3.

This means the path a1 ^ a2 - a3 \ a4 is actually:

a1 ^ a2 / a3 \ a4

^/\ is not a valid path. So a3 has to register its C2P relationship with a2.

> 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).

> 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.

Greetings,

Iljitsch