Re: [Sidrops] [GROW] IXP Route Server question

[Nick Hilliard <[e-mail]>]

Sriram, Kotikalapudi (Fed) wrote on 13/03/2022 16:20:
> Not sure why Ben even raised that question. To me, it doesn't seem
> relevant. In the route leak detection procedures, the
> receiving/validating AS does not require information about the nature
> of ASes (RS or not RS) in the AS Path except for the sending/neighbor
> AS which it knows to be an RS in case it knows itself to be an
> RS-client. The procedures rely only on ASPA objects for the origin AS
> and ASes in the middle.
Stepping back a bit, there's no fundamental difference between the 
behaviour of a transparent RS and a non-transparent RS, except that the 
transparent RS happens to elide the RS AS number from the AS path.  The 
remainder of the AS path will be the same in either case.

The algorithm for check_ix_path() implements a check to flip between 
upstream path verification and downstream path verification based on 
whether the RS is transparent or non-transparent.

Even if it gives a workable outcome, I think this is the wrong approach 
from an algorithmic point of view. The algorithm needs to accept that 
the two situations are basically the same except that in one (rare) 
case, the RS ASN is present in the AS path, and in the other, it isn't.

Section 5.3 says that the client has prior knowledge about whether the 
peer is a RS.  I.e. the draft already admits that rs client 
implementations will need a config flag.

So rather than discussing whether non-transparent ASNs are included in 
the specification, the discussion needs to focus on whether RS ASN's 
should be included in the ASPA verification algorithm at all, and if so 
/ if not, how this should be done.

The answer to this question is (surprisingly) not immediately clear. 
RSs do not partake in traffic forwarding, so they are not part of the 
data path between two ASNs; they're only part of the signaling path 
between the two ASNs.  This is a useful hack from a practical point of 
view, but it causes algorithmic breakage in places which assume 
congruency between the data plane and the signaling plane.  One of these 
places is AS path verification.

This changes the question of whether or not a hack is deployed to 
mitigate the effects of RS hackiness, but simply what style of hack 
should be used.  The current proposal is a mitigation approach, but can 
I propose an alternative approach, namely that the draft reintroduces 
congruence between the data plane and the signaling plane from the point 
of view of ASPA verification?

I.e. if the WG opinion is to include RS's as being in scope, then the AS 
path that the aspa algorithm operates on should include the RS ASN, 
regardless of how the RS is transparent or non-transparent. 
Alternatively, if WG opinion is to exclude RS's from the scope of this 
draft, then ASPA should be handled on the basis that the RS ASN is 
deleted from the as path list.

The only information necessary is whether the rs-client is aware that 
it's talking to a RS, but we already know that.

If RS's are kept in scope, then the RS should be treated as a provider 
by the rs client; the rs client should include the RS ASN in its SPAS; 
the rs client should evaluate ASPA as if the RS ASN were included in the 
path; the rs should evaluate clients as customers

If they're out of scope, then ASPA verification should elide the RS ASN 
from the AS PATH if it has not already been elided, and ASPA 
verification should proceed as if the two rs-client ASNs were directly 
connected and each should treat the other as a provider.

Nick