Dear Colleagues, Following is my summary of the NRTM v4 Requirmements Gathering BoF held yesterday. Thanks to all who attended (and please correct me or add detail below as needed). Summary Sasha Romijn presented an NRTM v4 protocol, designed to address issues in IRR database mirroring and borrowing from the RPKI RRDP (RPKI Repository Delta Protocol). See https://github.com/mxsasha/nrtmv4/ . We discussed the protocol in detail. I proposed to use this protocol as a Solution Definition for NWI-12 to the DB-WG. Job Snijders proposed to create an IETF draft document. Discussion Job suggested it's a good choice to model after RRDP. It's hard to resynchronise in RRDP but not a problem in IRR as the objects do not expire. Anand Buddhev said he uses NRTM for detecing domain object updates in the RIPE database, that the current NRTM v3 works OK, and asked whether object filtering will be considered. Sasha replied that server-side filters get horribly complicated. Ed replied that the RIPE NCC can keep v3 running if there is demand for it. Job suggested that object filtering can be implemented by the client. Ed asked what happens to deltas when a new snapshot is created. Sasha replied that the deltas are still available, but older deltas must be removed. Job suggested to create a snapshot more frequently as needed when there is a spike in updates, rather than generating 100's of deltas. Sasha mentioned she experimented with Websocket HTTP for a persistent connection for faster updates, but it has the same problems as the NRTM v3 protocol. Mitchell Koch asked about session ids. Job replied the session id is used to detect if the client has de-synchronised from the server. If there is a new session id then the client needs to resynchronise using a snapshot. Mitchell asked if there is room for sideband notification. Sasha replied it's a lot of work for less than 1 minute delay (a delta is created once a minute). Job pointed out we get a lot of innovation for free by switching the transport to HTTPS. Denis asked if the number registry object types will be included, as NRTM is also used to track changes to resources. Ed replied the same object types will be supported as now. Mitchell asked if using encrypted HTTP is a checksum enough for data validation. Sasha replied if only using HTTPS we extend the trust to the CDN. We also will sign the Update Notification file. Job said there is an additional burden in key management and to use a long-lived key. Sasha suggested to allow more than one key on the client side for key rollover. Job replied not to rollover too often, but not to use an indefinite lifetime either (we lose the ability to rollover). Job suggested that we should signal that a new key is available. Mitchell asked whether key expiry be in-band, Job replied it's definitely worth considering. Sasha said key rollover should be done in two scenarios, if the current key is compromised or on scheduled expiration. Job asked Anand his opinion on key rollover, Anand replied don't roll unless you have to, and if you don't roll frequently people forget how to do it. Anand suggested rolling annually at the very least, and to allow rollover earlier if there is a compromise. Finally, Job suggested to ask IANA to register keys in a central location. Regards Ed Shryane RIPE NCC
On 14 Oct 2021, at 09:30, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues,
The Doodle poll is now closed, thanks for your responses, we have chosen 3pm CEST on Monday 18th October for the BoF meeting.
This meeting is public, you don't need to sign up in advance, see the details below.
The meeting will not be recorded. I will post a summary to the DB-WG afterwards.
Regards Ed Shryane RIPE NCC