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

[Andrew Alston - IETF <[e-mail]>]

Hi Randy,

Thanks for the prompt response.  You make some good points and I admit - I need a bit of time to think this through, because while I do acknowledge your points, I also see the issues that I've raised in the original discuss and want to give it a few days thought to see if I can't possibly find some other suggestion that may be more palatable.

I'll come back to you shortly - hope you don't mind the request for a few days of consideration.  Will also discuss this with Mark face to face when I see him.

In the meantime - if you have any further thoughts on how we could potentially address the issues I've raised I'd love to hear them - since if my reading is correct you can see where I'm coming from on this.

Thanks

Andrew

-----Original Message-----
From: iesg <[e-mail]> On Behalf Of Randy Bush
Sent: Thursday, August 25, 2022 9:22 PM
To: Andrew Alston via Datatracker <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; SIDR Operations WG <[e-mail]>
Subject: Re: Andrew Alston's Discuss on draft-ietf-sidrops-rov-no-rr-06: (with DISCUSS)

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


Internal All Employees