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
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
