Colleagues At a recent BoF Ed suggested adopting Sasha's design as the solution definition for NWI-12. We would like some feedback on this. Do you agree/disagree with this proposed solution? If we can reach a consensus the RIPE NCC can move ahead with an impact analysis.
cheers denis co-chair DB-WG On Tue, 19 Oct 2021 at 11:40, Edward Shryane via db-wg <[email protected]> wrote: > > 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 <[email protected]> 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 > > > >
