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

[Ties de Kock <[e-mail]>]

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.

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.

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.

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.

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

Kind regards,
Ties

On Sat, 1 Jun 2024 at 12:51, gengnan
<gengnan=[e-mail]> wrote:
>
> Hi,
>
> > I think new semantics are generally best done as separate, explicit, complementary types.
> Agreed.
>
> A new object for DSR prefixes is an optional solution. BAR-SAV can use BGP, ASPA, ROA, and DSR data to generate SAV rules.
>
> Another option is to use SPL to explicitly state DSR prefixes.
>
> "Implicit method" may induce some security risks and operational complexity.
>
> Best,
> Nan
>
> -----Original Message-----
> From: Tim Bruijnzeels <[e-mail]>
> Sent: Wednesday, May 29, 2024 4:14 PM
> To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[e-mail]>
> Cc: Amir Herzberg <[e-mail]>; [e-mail]; [e-mail]
> Subject: [Sidrops] Re: WG Adoption call for draft-sriram-sidrops-spl-verification - ENDS 06/03/2024 (June 3 2024)
>
>
> Hi,
>
> > On 28 May 2024, at 22:37, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[e-mail]> wrote:
> >
> >>
> >> 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.
>
> I think discussion is good, but generally speaking I am not keen on changing the ROA format. We have a lot of deployment, CA implementations and UIs/APIs, RPs, best practices, documentation, etc.
>
> I think new semantics are generally best done as separate, explicit, complementary types. This way it’s also clear that the signer explicitly opted in to making a statement - rather than going with an implicit default which is what we might end up with if we had a next version ROA with optional extra bits.
>
> I support adopting SPL, my feeling is that some more discussion is needed before it’s done, but adopting it so we can have that discussion makes sense to me.
>
> Tim
> _______________________________________________
> Sidrops mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]