sidrops IETF UPDATE#

Tom Harrison, APNIC

• Why: The plumbing of RPKI distribution is being redesigned; if you operate relying parties or a publication point, this affects you.
• What: Three sidrops work items: the Erik synchronization protocol (draft-ietf-sidrops-rpki-erik-protocol), NRO Trust Anchor Constraints, and Best Current Practices for RPKI publication servers.
• How: Erik is the interesting one — today every relying party fetches from every publication point (an M:N problem that worsens over time, where one slow PP holds up an RP's whole validation run). An Erik relay, runnable by anybody, fetches from PPs and serves RPs over the new protocol: PPs go from handling thousands of RPs to ~20 relays in full deployment. It also fixes RRDP's encoding waste (base64 adds 33%, XML another ~10%), serves raw DER objects, and uses Merkle trees to support cheap diffs and individual-file repair — eliminating the "delta failed, re-fetch a 100 MB snapshot" thundering herd (the deck shows a 102 MB snapshot vs. a 68 KB delta).
• Where applicable: All RPKI operators; deployable incrementally alongside rsync/RRDP. Reference implementations exist (rpkitouch relay, public relay instance).