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

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

Hi Ties,

Thank you for the detailed review and comments. 

Glad to know that you see threats/scenarios #1, #2, and #5 (Section 6) pointing to beneficial use cases of SPL. 

All your comments will be carefully taken into consideration to revise the draft going forward.  Please see my other responses inline below.

> -----Original Message-----
> From: Ties de Kock <[e-mail]>
> Sent: Monday, June 3, 2024 3:44 AM
>
> I have read the draft and support adoption.
>
> I think the use cases and deployment considerations for SPL need more discussion.
> SPL is the minimal proposal for this problem space so far. I feel that adopting this document is the way to continue this discussion.
>
> We are introducing multiple objects that can serve the same goal. SPLs overlaps with both ROAs and ASPAs. To me, this is a downside, since each partial mitigation makes perfect deployment of any other mitigation less likely.

May be -- s/multiple objects that can serve the same goal/multiple objects that serve varying but somewhat overlapping goals/.  

>
> Threats 1 and 2 will help prevent misattribution (and add non-repudiation for legitimate announcements) for networks that actively participate in the internet. That is a real benefit.
>
> Scenario 5 slightly improves over an empty provider set for ASPA and will make reclaiming unused ASNs easier.
>
> However, I have questions about the other scenarios mentioned.
>
> As I understand it, scenario 3 is mitigated if the originating AS has a ROA for the original announcements.
>

You are right. My thoughts:  Typically, there would be many prefixes affected in this anomaly (scenario 3) and originated by possibly different ASes.  SPL offers additional protection in case some of those (prefix, origin AS) pairs have ROAs and others don't (partial deployment).   

> Scenario 4 describes how minimal SPLs improve the situation where overly permissive ROAs exist (or not all space is announced). I think that the underlying assumption that operators will maintain a strict SPL while the ROAs are overly permissive is unrealistic (e.g. it is likely operators would create permissive SPLs). Section 7.4 also assumes the permissive pre-positioned ROA+SPL for DDOS mitigation, contradicting this premise.

Good observations.  Yes, the DDOS mitigation scenario in Sec. 7.4 is an exception to the premise in Scenario 4 (Sec. 6).  The DDoS mitigation client (prefix owner) may consider the permissive SPL (along with a permissive ROA) an acceptable trade-off: benefit of quick responsiveness of DDoS mitigation vs. increased attack surface for forged-origin hijack.  Of course, in this situation, the ASPA offers a reasonable partial protection (i.e., protected when the bad BGP Update is received from a customer or lateral peer).  

If prefix owners use maxlength or include unannounced prefixes in their ROAs for preventing prefix squatting, SPL can be protective by being less permissive.

>
> Minor comments:
>   * Section 3: "For a given asID, ... does not originate any prefixes": This
>     needs to be described on the level of validated SPL payload (which is the union over
>     1..n SPLs for an AS).
>
>     The behaviour in the non-recommended case (multiple SPL) needs to be unambiguously defined.

Yes, will revise the wording per your suggestions above.

>
>   * Section 6: It is implicit that SPL-ROV is valid for the described effects
>     to exist. I would clarify this in the text.

Your question is not very clear.  The SPL-ROV must give Invalid result to detect the anomaly or attack, such as forged-origin hijacks.  We can clarify this in the text.

Thanks!

Sriram