[We can drop GROW list for now; moved them to bcc]
Hi Maria,
>What may work is this, not running on ASPA verification but as an auxiliary
>BGP session check.
>…
Yes, initially I also wanted to phrase it as “an auxiliary BGP session check”.
Good, we can agree on that.
In the following procedure description, I would replace the second occurrence
of MUST with SHOULD. The rest seems fine.
-- begin procedure description --
- During BGP session initiation, both parties MUST check whether either:
- the Customer has no ASPA record, or
- their SPAS includes the Provider's AS.
If the check fails, the BGP session MUST *[KS: replace with SHOULD]* be
terminated immediately.
- For any established BGP session, the check MUST be repeated any time
the appropriate SPAS changes, appears or disappears. The session
SHOULD be terminated immediately if the condition is not met anymore.
- If not terminated, the operators SHOULD resolve the issue as soon as
possible to prevent possible ASPA Invalids being spread out.
-- end --
On the topic of egress verification, I have explained this before and I can do
it again here. The thing that makes egress verification unworkable/harmful can
be explained with two test cases:
Test case 1:
p1--AS X -----> {AS Y: R1 (ingress router) -----> R2 (egress router)}
-----> AS Z
AS X is a peer (or provider) of AS Y. AS Z is also a peer (or provider) of AS
Y. AS X does not have an ASPA, and it originates a prefix p1.
AS Y is the verifying AS, where ingress (upstream) verification is done at R1
on route p1 {AS X}, and egress (upstream) verification is being proposed by you
to be done at R2 on route p1 {AS Y, AS X} -- per step 5 or 6 (in 6 it seems
you include AS Z also, OK) in the algorithm you described.
Based on its configuration, R1 knows locally whether AS X is a provider, peer,
or customer of AS Y. R2 does not know that. Egress verification at R2 is done
using ASPAs only.
Your step 5 or 6 will incorrectly produce “Unknown” for the verification result
and R2 will forward the route to AX Z and thus cause a local route leak. Do you
agree?
Test case 2:
The picture mostly the as above. AS X has an ASPA, it has a complex relation
with AS Y including a C2P session and a separate p2p session, so AS X’s ASPA
includes AS Y, and the route is received from AS X to AS Y on the p2p session.
The egress verification per your step 5 or 6 at R2 produces an incorrect
“Valid” result for the route and R2 forwards it to AS Z causing a local route
leak. Do you agree?
In both above test cases, the existing ingress algorithm in the draft
determines at R1 that p1{AS X} is Valid. OTC is attached to the route. Then R2
will not forward the route to AS Z. This works correctly.
The combination of the existing ingress verification together with OTC works
correctly in all cases. We have separately addressed above the issue of error
in ASPA creation with the neighbor.
Thanks.
Sriram
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
