NRTM v4 Requirements Gathering BoF
Dear Colleagues, I'd like to hold a BoF meeting next week to gather requirements for NRTM v4 and look for a way forwards to an implementation. For background reading on NRTM v4, please read the NWI-12 Problem Definition: https://www.ripe.net/ripe/mail/archives/db-wg/2020-November/006720.html If you are interested in this discussion, please register your interest using this optional Doodle pool to indicate any convenient time(s) for you: https://doodle.com/poll/bfmcaxuyb5v8iwsu?utm_source=poll&utm_medium=link I will close the poll on this Wednesday evening and reply to the DB-WG with a meeting request. You don't need to register to attend. Regards Ed Shryane RIPE NCC
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 Topic: NRTM v4 Requirements Gathering BoF Time: Oct 18, 2021 03:00 PM Amsterdam Join Zoom Meeting https://ripe.zoom.us/j/96557189419?pwd=dXJrQWcvMlJVRDBkYzQ5OXo4TmdqZz09 Meeting ID: 965 5718 9419 Passcode: 699135 One tap mobile +31707006526,,96557189419# Netherlands +31202410288,,96557189419# Netherlands Dial by your location +31 707 006 526 Netherlands +31 20 241 0288 Netherlands +31 20 794 0854 Netherlands +31 20 794 6519 Netherlands +31 20 794 6520 Netherlands +31 20 794 7345 Netherlands +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) Meeting ID: 965 5718 9419 Find your local number: https://ripe.zoom.us/u/akumZ62D8 Join by SIP 96557189419@zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 149.137.68.253 (Mexico) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 965 5718 9419 Passcode: 699135
On 11 Oct 2021, at 14:48, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues,
I'd like to hold a BoF meeting next week to gather requirements for NRTM v4 and look for a way forwards to an implementation.
For background reading on NRTM v4, please read the NWI-12 Problem Definition: https://www.ripe.net/ripe/mail/archives/db-wg/2020-November/006720.html
If you are interested in this discussion, please register your interest using this optional Doodle pool to indicate any convenient time(s) for you: https://doodle.com/poll/bfmcaxuyb5v8iwsu?utm_source=poll&utm_medium=link
I will close the poll on this Wednesday evening and reply to the DB-WG with a meeting request. You don't need to register to attend.
Regards Ed Shryane RIPE NCC
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
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 <db-wg@ripe.net> 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 <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
participants (2)
-
denis walker -
Edward Shryane