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

[Amir Herzberg <[e-mail]>]

I've read the draft and have the following comments.

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.

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. 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.

best, Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography and Cybersecurity' textbook:
https://sites.google.com/site/amirherzberg/crypto-cyber-book