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

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

Hi Amir,

Thank you for your review and comments. My responses below.

> From: Amir Herzberg <[e-mail]>
>
> 1. I think the draft doesn't clearly distinguish between (intentional) 
> attacks and unintentional misconfigurations. I think that the authors 
> really meant, mostly or always, to prevent unintentional 
> misconfigurations, in which case, their use of the term `attack' is 
> confusing. Changing the term should be easy.
>

I think you are right. We'll take a closer look and change 'attack' to 'anomaly' where it is appropriate.  I think the term 'attack' can be used when we talk about DoS/DDoS incidents. Also, the term "attack surface" is correctly used in the context of forged-origin prefix hijacks (as you acknowledged below).  

>
> 2. An exception is the 4th reason, i.e., when a prefix owner publishes 
> ROA for AS 7 and some prefix 1.2.3/24 but AS 7 doesn't announce 1.2.3/24.
> In this case, attacker could do origin hijack of 1.2.3/24 by 
> announcing it with origin AS 7 (and itself as the next AS). I 
> understand the motivation of supporting direct server return (DSR) 
> using BAR-SAV, where we want a ROA to exist without announcing the prefix.

Yes, SPL helps in the DSR scenario for BAR-SAV.  Igor also observed that.
 
> However, is SPV the best mechanism to deal with this?
> I think a better alternative would be an extension to the ROA 
> mechanism. This extension will define a `conditional ROA'.
> This conditional ROA will also contain the result of a hash function 
> h(x) over some random x. You can use the conditional ROA in two ways:
>
> - without the preimage x: such ROA will not make announcements for AS
> 7 and 1.2.3/24 valid. However, it could be used to allow DSR , i.e., 
> it would be considered for BAR-SAV filtering.
>
> - with the preimage x, provided as a transitive BGP attribute or otherwise:
> this turns the conditional ROA into regular ROA.
>

Your proposal involves modifying the ROA to add a new field. Perhaps it can be taken up in the future by the WG as new work.  I'll be happy to discuss its the pros and cons off-list.

Sriram