[Sidrops] Andrew Alston's Discuss on draft-ietf-sidrops-rov-no-rr-06: (with DISCUSS)

[Andrew Alston via Datatracker <[e-mail]>]

Andrew Alston has entered the following ballot position for
draft-ietf-sidrops-rov-no-rr-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rov-no-rr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Authors,

Thanks for the document, for the most part I find it clear and easy to
understand.

I however would like to discuss the following:

 If the BGP speaker's equipment has insufficient resources to support
   either of the two proposed options, it MUST NOT be used for Route
   Origin Validation.  The equipment should either be replaced with
   capable equipment or ROV not used.  I.e. the knob in Section 4 should
   only be used in very well known and controlled circumstances.

My concerns with this are two fold - firstly - it's entirely unclear what is
meant by "well known and controlled circumstances".

More importantly, I'm concerned that this paragraph as written could lead to a
situation that where people read this as "if you can't support this behavior -
forget BGP security" - and that I would think would be a more dangerous
situation than the route refresh behavior.

I'd be happier if we could
a.) Either say that operators should plan for upgrades - but turn off RPKI in
the meantime or b.) Change the wording such that it says something along the
lines of "it MUST not be used for ROV without the informed consent of the
peers" - meaning that peer that takes the brunt of the refreshes has to consent
explicitly.

Either option prevents the position where operators running smaller older
hardware are handed an excuse to forgo RPKI entirely - or to turn it off -
because in my experience once someone turns something off, getting them to turn
it back on again, can be a tricky proposition.

Let's discuss!

Thanks

Andrew