Problem definition for new NWI (12?) - NRTM service
Dear db-wg community, Please find below the problem definition for the (upcoming) NWI-12 item as we have discussed it and envisioned it for this project. Problem definition: Back on October 2019 during the RIPE 79 meeting in Rotterdam, we discussed about the need to move forward with a next generation of NRTM service. Upon the completion of NWI-9 and the lifting of the legal restrictions, we can now proceed to design the new solution. As we discussed preciously, the version 3 of the current NRTM solution is not suitable anymore for network operations on 2020. A summary of the reasons are: -Is a Telnet based protocol, thus: • No keep alive mechanism is adopted, • It provides plain text/unencrypted transport of data -The bootstrap process is not always trivial and sometimes is slow -Long time synchronisation is complicated and users need to re-synchronise after a couple of weeks. -No well specified protocol (There is just a PDF doc that describes it) For all the reasons above (and reasons that we might have not think about yet but you are welcome to share), it becomes a necessity for the community to proceed with a new implementation that will be easily adopted by modern tools and last for the years to come. I hope the above text is sufficient for the db-wg chairs to kick off the process and the community to share its feedback. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net
Hi Stavros Thanks for starting this off with a draft problem statement. As there has been a lot of interest in this recently we will initiate "NWI-12 NRTMv4". Ed can you set that up on the NWI web page? We would welcome comments from other community members on this problem statement. cheers denis co-chair DB-WG On Fri, 13 Nov 2020 at 21:58, Stavros Konstantaras via db-wg <db-wg@ripe.net> wrote:
Dear db-wg community,
Please find below the problem definition for the (upcoming) NWI-12 item as we have discussed it and envisioned it for this project.
Problem definition:
Back on October 2019 during the RIPE 79 meeting in Rotterdam, we discussed about the need to move forward with a next generation of NRTM service. Upon the completion of NWI-9 and the lifting of the legal restrictions, we can now proceed to design the new solution. As we discussed preciously, the version 3 of the current NRTM solution is not suitable anymore for network operations on 2020. A summary of the reasons are:
-Is a Telnet based protocol, thus: • No keep alive mechanism is adopted, • It provides plain text/unencrypted transport of data
-The bootstrap process is not always trivial and sometimes is slow -Long time synchronisation is complicated and users need to re-synchronise after a couple of weeks. -No well specified protocol (There is just a PDF doc that describes it)
For all the reasons above (and reasons that we might have not think about yet but you are welcome to share), it becomes a necessity for the community to proceed with a new implementation that will be easily adopted by modern tools and last for the years to come.
I hope the above text is sufficient for the db-wg chairs to kick off the process and the community to share its feedback.
Best regards,
Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net
RRDP was designed in the light of experience with NRTM. It has good fast convergence, TLS protection, fits the CDN model, and we have deployment experience. RDAP mirroring protocol is a design in early test, for RDAP to do NRTM like mirroring, which was informed by RRDP. I would like to suggest that a design of an NRTM replacement could reflect on RRDP, and on the emerging JSON/RDAP mirroring activity. APNIC is of course interested in the NRTM re-design work: we have significant investment in NRTM both as an information provider, to people who want NRTM, and specifically to RADB and RIPE, and for coordination of Whois data with the NIR, and with two IRR sources operating in region: JPIRR and IDNIC's new IRR. cheers -George On Mon, Nov 16, 2020 at 10:38 PM denis walker via db-wg <db-wg@ripe.net> wrote:
Hi Stavros
Thanks for starting this off with a draft problem statement. As there has been a lot of interest in this recently we will initiate "NWI-12 NRTMv4". Ed can you set that up on the NWI web page?
We would welcome comments from other community members on this problem statement.
cheers denis co-chair DB-WG
On Fri, 13 Nov 2020 at 21:58, Stavros Konstantaras via db-wg <db-wg@ripe.net> wrote:
Dear db-wg community,
Please find below the problem definition for the (upcoming) NWI-12 item as we have discussed it and envisioned it for this project.
Problem definition:
Back on October 2019 during the RIPE 79 meeting in Rotterdam, we discussed about the need to move forward with a next generation of NRTM service. Upon the completion of NWI-9 and the lifting of the legal restrictions, we can now proceed to design the new solution. As we discussed preciously, the version 3 of the current NRTM solution is not suitable anymore for network operations on 2020. A summary of the reasons are:
-Is a Telnet based protocol, thus: • No keep alive mechanism is adopted, • It provides plain text/unencrypted transport of data
-The bootstrap process is not always trivial and sometimes is slow -Long time synchronisation is complicated and users need to re-synchronise after a couple of weeks. -No well specified protocol (There is just a PDF doc that describes it)
For all the reasons above (and reasons that we might have not think about yet but you are welcome to share), it becomes a necessity for the community to proceed with a new implementation that will be easily adopted by modern tools and last for the years to come.
I hope the above text is sufficient for the db-wg chairs to kick off the process and the community to share its feedback.
Best regards,
Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net
Hello Stavros, Thanks for writing the problem definition. One comment: On 13 Nov 2020, at 21:58, Stavros Konstantaras via db-wg <db-wg@ripe.net> wrote:
• It provides plain text/unencrypted transport of data
My main concern here isn’t actually the lack of encryption: it’s the lack of authentication. Mirroring between IRRs is currently based on opening a TCP socket to some IP and then completely trusting whatever you get. Which in turn is used to configure routing policy. There is zero verification on whether the data is authentic and from the source you meant to get it from. Encryption is a lesser concern for me, because IRR data is usually public already, but we should include it. Anything that has a TLS layer could satisfy both of this, so it’s not really a hard problem. Sasha
participants (4)
-
denis walker -
George Michaelson -
Sasha Romijn -
Stavros Konstantaras