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

[Randy Bush <[e-mail]>]

andrew:

thanks for reviewing.

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

hmmm.  point.  do you have suggestions or cites for a rigorous operators
test methodology?

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

a number of issues here

  o rov is not bgp security; it presents no real barrier to attack, cf.
    this week's event.  as a fellow researcher said the other month, rov
    is bgp safety not security

  o indeed it does say that, if you can not run rov without acting
    badly, then do not run it.  but it does not say do not run any bgp
    security mechanism, for example gtsm, route filters, ...

  o but, indeed, the intent is that, if a device can not do rov without
    the described bad behavior, it should not run rov.

> a.) Either say that operators should plan for upgrades - but turn off
> RPKI in the meantime

well, it kind of says that.  but it does not say rpki in general.  this
spec concentrates on rov.

and it does not say the operator shoud turn rov off in general, only on
the device(s) incapable of doing full adjribin or saving dropped routes.

as close as i could get is

      If the BGP speaker's equipment has insufficient resources to
      support either of the two proposed options (keeping a full
      AdjRibIn or at least the dropped routes), it MUST NOT be used for
      Route Origin Validation.  The equipment should either be replaced
      with capable equipment or ROV not used.

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

wow!  do you really want to go down this path?  are there other spec
violations that we suggest peers negotiate?  exceedingly long as path
prepends might be popular this season :)

all sorts of operational complexity, e.g. my peer's staff changes next
month and the new staff does not like me beating on their routers.

all in all, i can see such under the table negotiations happening
occasionally.  but i am uninclined to put a recipe in the spec.  and it
would have no actual technical content anyway.

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

again, this is per device, not per operator.  and (rpki != rov).  the
device might be capable of other rpki-based functions.

but, having put a lot of time and effort over the last two decades
trying to keep the specs achievable on existing hardware, i have great
sympathy for the direction you're trying to go.  i just don't see how to
get there simply and realistically.  send more clue.

in general, i see your comments in an operational sense.  but this is a
protocol, not operational draft.  it is not a bcp or a bcop.  perhaps
you would care to work on an rov bcop?

randy