[RPKI] Use of Refresh/Retry/Expire Timers and RTR Versions

[Martin Hoffmann]

Hi!

Jacquie Zhang via RPKI wrote:
> 
> 1. RTR Side
> =========
> 
> 1. In RTRv0, none of the 3 timers has any effect on the RTR side. A
> router defines its own Refresh/Retry/Expire time. There is no
> communication about them between a validator and a router over RTR.
> 2. In RTRv1, all 3 timers have effect on the RTR side. A validator
> dictates them via EoD PDU and tells the router what to use.
> Communication is one way only, from the validator to the router, it's
> dictation, not negotiation.
> 
> Is this understanding correct?

Yes. Although a router is free to ignore these values or trim extremes
to more reasonable values.


> 2. Repository Side
> ==============
> 
> There definitely is a refresh timer to tell how often Routinator
> should poll the Repository to fetch ROAs. As there are no other
> config parameters in the conf file, "refresh" timer must be for this.
> Is there a retry timer as well? The Routinator could lose its Internet
> connection due to a firewall or routing fault. When that happens, is
> there a retry timer at play?

No. There currently is no logic to determine a full network outage, so
Routinator only considers fetches of individual repositories successful
or failed.

We feel there is no real need to change this as the default refresh
timeout is short enough to just wait for that time.

> What about the expire timer? In the event a Routinator loses its
> Internet connection, does it hold the VRPs for a period of time
> (Expire Time) then delete them?

It will retain all previously fetched objects and will keep using them
for validation until they expire and only then delete them. These
objects are signed and carry a certificate which in turn contains a
“not after” time. After that time, the certificate becomes invalid
which means the object cannot be validated anymore. Additionally, the
CA certificates describing the CA that created these objects can expire
in the same way, also making these objects invalid.

Typically, we are talking about a day or so before that happens. So you
have enough time to restore connectivity.

But also keep in mind that ROV fails open. If you loose all your VRPs,
routes will be "RPKI unknown" and accepted. So the fallout of loosing
your RPKI data isn’t that terrible.

> This is what I think:
> 
> 
> refresh = 600  [meaningful in RTRv1 only, not meaningful in RTRv0.
> Also meaningful on the Repository side]
> 
> retry = 600      [meaningful in RTRv1 only, not meaningful in RTRv0.
> Not meaningful on the Repository side]
> 
> expire = 7200  [meaningful in RTRv1 only, not meaningful in RTRv0. Not
> meaningful on the Repository side]

That is correct.

> 3. Objects in the Repository
> =====================
> 
> From Routinator document:
> 
>        --refresh=*seconds*
> 
>               The amount of seconds the server should wait after
> having  fin-
> 
>               ished updating and validating the local repository
> before start-
> 
>               ing to update again. The next update will start earlier
>  if  ob-
> 
>               jects  in  the  repository expire earlier.  The default
> value is
> 
>               600 seconds.
> 
> Can someone please explain what "objects in the repository expire
> earlier" mean? Which expire timer is this? I see ROAs have expiration
> in the RIRs, but that expiration is normally a year and I read ROAs
> will be auto-renewed when they expire, so I don't think it is this
> one.

Correct. This usually isn’t something you need to worry about. But we
felt that documentation should be precise -- and this is what
Routinator does. While doing a validation run, it keeps track of when
next object expires and if that is before the refresh time, adjusts it
accordingly. Keep in mind that you are free to set the refresh time to
quite large values, like, say, a day. You shouldn’t, but you could ... 

> And it says "objects in the repository", so it's not the VRPs in the
> Routinator after ROAs have been processed, so I think this doesn't
> indicate there is an expire timer for the VRPs.

Not directly, but obviously, if the ROA containing the VRP expires (and
this ROA is the only one containing that particular VRP), it is being
removed from the set.

> 4. My Cisco and Juniper Routers Only Support RTRv0
> ======================================
> 
> Because the routers don't support RTRv1, I am thinking whether I
> should disable RTRv0 explicitly in the Routinator and set retry and
> expire time to 0, that is, if my understanding is correct, they do
> nothing in RTRv0. Should I do this? Where to disable it, go to the
> source code? Is setting to 0 allowed?

There is no way to disable RTRv0. When establishing a connection,
router and validator negotiate the RTR version to be used. If your
router says that it only speaks v0, then that’s what is going to be
used.

I wouldn’t worry too much about these timers. Given that they are set
manually in Routinator config and not calculated in any way, you can
simply set similar values in your router config.

Not knowing the refresh value is fine too. Every time it has new data,
Routinator will ping all connected RTR clients and tell them about that.

> Is anyone aware of any router vendor or router model that supports
> RTRv1? Cisco TAC told me RTRv1, RFC8210, will be revised so they have
> skipped RTRv1 altogether. Sounded like they will never support RTRv1.

A new RTR version is indeed in the works. It will be necessary to
support ASPA. This may be an incentive for Cisco to implement this v2,
but, well, you know.

HTH and cheers,
Martin