You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Database Working Group

Threaded
Collapse

[db-wg] NRTM v4 Requirements Gathering BoF

User Image

Ed Shryane

2021-10-11 14:48:53 CET

RIPE NCC staff member

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


User Image

Ed Shryane

2021-10-14 09:30:16 CET

RIPE NCC staff member

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 _at_ zoomcrc _dot_ 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 _at_ ripe _dot_ 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
> 
> 


User Image

Ed Shryane

2021-10-19 11:40:58 CET

RIPE NCC staff member

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 _at_ ripe _dot_ 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
>