Subject: [Sidrops] rpki rp frequency

From: Randy Bush <[email-masked]>
Date: Sat, 11 Apr 2020 13:04:29 -0700

how often do RPs fetch?  how often to routers fetch from RPs?

an experiment announces 147.28.241.0/24 constantly from 47065

a CA has a ROA for { 147.28.241.0/24 47065 } from 12:00 to 04:00 UCT and
for some other, non-announcing i.e. incorrect, AS from 04:00 to 12:00.

it's 19:50 UTC, and a seattle router shows

    r0.sea#sh ip bg rpki table | i ^147.28.241
    147.28.241.0/24      24      47065      0       147.28.0.30/323

i.e. it sees the ROA for the announcing prefix

but the received bgp route to 147.28.241.0/24 is does not reach that
router maybe because transits dropped as invalid?  2914 is the upstream
for that router.

but rv shows

    route-views>show ip bgp 147.28.241.0/24
    BGP routing table entry for 147.28.241.0/24, version 523202351
    Paths: (12 available, best #12, table default)
      Not advertised to any peer
      Refresh Epoch 2
      3303 47065
	217.192.89.50 from 217.192.89.50 (138.187.128.158)
	  Origin IGP, localpref 100, valid, external
	  Community: 3303:1004 3303:1006 3303:1030 3303:3051 47065:332
	  path 7F57D930ED10 RPKI State valid
	  rx pathid: 0, tx pathid: 0

and more.  but with no paths through 2914.

how do we diagnose such things?

randy

---

From: "Job Snijders" <[email-masked]>
Date: Sun, 12 Apr 2020 00:34:27 +0200

> how do we diagnose such things?

My approach would be just like most other BGP reachability issue? First step is to figure out the peer who'd you expect to carry the route to the global system. I think in the case of this experiment the relevant upstream might be AS 8283.

Luckily they have a public looking glass, we can see that their EBGP-in side rejects 2 routes from AS 47065 https://birdseye.coloclue.net/birdseye/app/routeservers/0/protocols/peer_AS47065_49DA60/routes It shows the route being rejected because of RPKI.

One could then go to https://www.peeringdb.com/asn/8283 for NOC contact info and other information. There we also see "filters facing peers are updated every 12 hours" - I suspect that coincidences in a specific way with the pace of the experiment.

Full disclosure: I was the architect of AS 8283's network automation system (https://github.com/coloclue/kees). One of my design choices was to not use RTR. Instead, the 'kees' system generated & distributes a configuration snippet to all routers and SIGHUPs the BGP process. The snippet contains all the RPKI VRPs. This process runs every few hours.

In the large RPKI deployments some people opted for a sort of tiered setup: a few validators at the top, and then a distribution mechanism to RTR servers, which then in turn distribute data via RTR to the BGP routers. I expect operators to pick different timers for publishing & fetching at each tier. I hope I can share more at a later point about such setups.

Some low-hanging fruit outside of IETF might be to introduce a new field to PeeringDB's datamodel where operators can self-declare what the "RPKI Delay" in their network roughly is. The "RPKI Delay" would be the maximum number of minutes that could lapse between a ROA becoming available for fetching at the publication point, to the moment the VRP is present on all routers, during normal operations.

Or perhaps a new RPKI Object profile is defined to message some operational parameters about the validation process policies an ASN operator applies? Some of the data elements in PeeringDB were put there only because there wasn't any other place to put it. 

Kind regards,

Job

---

From: Di Ma <[email-masked]>
Date: Sun, 12 Apr 2020 17:42:06 +0800

Randy,

> 2020年4月12日 04:04，Randy Bush <[email-masked]> 写道：
> 
> how often do RPs fetch?

As often as necessary that the RP can synchronize with a repository.

But the repository manager MAY limit RP’s access in the light of security, which by the way, RPSITR encounters at times.

Di

---

From: Randy Bush <[email-masked]>
Date: Sun, 12 Apr 2020 11:31:31 -0700

> As often as necessary that the RP can synchronize with a repository.

how often is 'necessary?'  in units of time, please.

i suspect that we are judging 'success' by the number of ASs doing
'something,' and not the quality of what they do in terms of, for
example, publishing ROAs in a 'reasonable' time (imiho < 1hr), actual
routers responsiveness to changing ROA registration, BGP announcements,
etc.

randy

---

From: Di Ma <[email-masked]>
Date: Mon, 13 Apr 2020 16:18:49 +0800

> 2020年4月13日 02:31，Randy Bush <[email-masked]> 写道：
> 
>>> how often do RPs fetch?

I think It is the ISP who defines what is necessary.

Instead,  I would prefer to talk about “how often is possible”. 

Once upon a time, RPSTIR can do fetching every half an hour, which by the way is the time that takes RPSTIR to accomplish synchronization. 

Granted, as I said, repository manager could limit the frequency.

Di

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Apr 2020 07:17:21 -0700

> I think It is the ISP who defines what is necessary.

what is reasonable for the good of routing in the internet?  i suggest
an hour.

before notify, we tolerated dns propagation of a day, and it was very
painful.  that seems primitive and silly now.

randy

---

From: Jared Mauch <[email-masked]>
Date: Mon, 13 Apr 2020 10:25:45 -0400

> On Apr 13, 2020, at 10:17 AM, Randy Bush <[email-masked]> wrote:
> 

Most of the IRRs are mirroring at an interval of 5 minutes or so these days, or that was one of the last things I asked to be changed at 2914 before I left to ensure regular sync.

I think 300s is reasonable, but 3600 (60 min) is likely the high limit.

- Jared

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Apr 2020 10:30:55 -0700

> Most of the IRRs are mirroring at an interval of 5 minutes or so these
> days, or that was one of the last things I asked to be changed at 2914
> before I left to ensure regular sync.

there are the questions of how frequently a CA publishes, how often an
RP pulls, and how often routers pull from their RP(s).

for CA publishing, a few seconds seems easily achieved with reasonable
software.

for RPs pulling, 600s may be optimistic in the short term given
  o the load it will put on publication services
  o and one notorious repo which is against spec
but it should be achievable in a while.  an hour would be the longest
acceptable in my mind today.

for the router(s) pulling from the RP(s), 300-3600s is a wide window.
but remember, the rpki-rtr protocol does have the equivalent of dns
notify, where the cache tells the router that it has some nice tasty
new data.  you're welcome :)

i imagine that few here are old enough to remember when curtis only
updated the backbone (there was only one) routing peering once a week
on wednesday.

if we want the internet to rely on this stuff, it's time to get into the
21st century.

randy