This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Problem definition for new NWI (12?) - NRTM service
- Previous message (by thread): [db-wg] Problem definition for new NWI (12?) - NRTM service
- Next message (by thread): [db-wg] [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sasha Romijn
sasha at mxsasha.eu
Thu Nov 19 15:03:34 CET 2020
Hello Stavros, Thanks for writing the problem definition. One comment: On 13 Nov 2020, at 21:58, Stavros Konstantaras via db-wg <db-wg at 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
- Previous message (by thread): [db-wg] Problem definition for new NWI (12?) - NRTM service
- Next message (by thread): [db-wg] [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]