[Sidrops] Re: WG Adoption call for draft-sriram-sidrops-spl-verification - ENDS 06/03/2024 (June 3 2024)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Igor,



My responses are inline below.



>I’ve read the draft, focusing mostly on section "6. BGP Security Threats Addressed by SPL-ROV" -- the problems SPL wants to solve that are not solved by ROA and ASPA.



>I see threat 4 as the real concern here without a widespread ASPA adoption.  Just for that I support the adoption.



Thank you. See comments about the complementary nature of ASPA and SPL below.



>It is especially important to solve threat 4 if we are recommending adding ASNs to ROA for direct server return cases for SAV purposes (for algorithms like BAR-SAV).



Yes, the DSR scenario benefits from SPL’s reduction of attack surface (threat 4).



>I do have questions about the rest of the threats mentioned.



>Threats 1, 2, and 5 are "If someone is forging some announcements, do not let them blame it on my AS".  Is this “AS reputation” a big concern? Protecting against threats 1 and 5 does not help protect any packets from being misrouted/hijacked (and no IP space is being hijacked in threat 2 to begin with), since the malicious AS can pick any other ASN as the origin.  It is just about not letting my AS show up as the "origin", right?



If someone’s unprotected prefix or subprefix is not reachable (hijacked) and your AS is made to appear to be the origin AS (accidentally or intentionally), then that route is rejected (considered ineligible) due to the assertion by your SPL. One may call it prevention of AS abuse.



>Threats 2 and 4 can be mostly solved by ASPA (but only if providers also maintain ASPA entries, transitively, so it is a tall order).



SPL and ASPA are complementary. Threats 2 and 4 can be mostly solved by a combination of ASPA and adherence to RFC 9319. But RFC 9319 is not very well adopted so far.  Also, ASPA solves the forged-origin hijack only in the upstream direction (i.e., routes received from customer or lateral peer), but not for routes received from a provider.  Assuming that there are generous or loose ROAs, SPL-ROV reduces the attack surface without the directionality limitation mentioned above. There may exist loose/generous ROAs out of necessity (e.g., DSR, DDoS mitigation [RFC9319]. Sometimes it may be due to unwise use of maxlength.



>Threat 3 can be solved by ROA, but that may be not under AS’s control.  It is really an AS protecting against its own mistakes.


Yes, true. Just in case some or all the needed ROAs are absent, SPL-ROV provides the added protection.



Sriram