<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1479439613040_167800"><span id="yui_3_16_0_ym19_1_1479439613040_170465">Hi Ronald</span></div><div id="yui_3_16_0_ym19_1_1479439613040_167805"><span id="yui_3_16_0_ym19_1_1479439613040_170471"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_168981"><span id="yui_3_16_0_ym19_1_1479439613040_168980">You have touched on several issues here. I will take them one at a time.</span></div><div id="yui_3_16_0_ym19_1_1479439613040_168982"><span id="yui_3_16_0_ym19_1_1479439613040_168987"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1479439613040_168984"><span id="yui_3_16_0_ym19_1_1479439613040_168983">The current model of the RIPE Database was deployed in 2001. Before that there was another version that did not require mandatory authorisation. So when the data was migrated to the current data model any objects that did not have any authorisation had this 'ripe-ncc-none-mnt' added as an "mnt-by:". This MNTNER object did not have any password or pgp. It had the "auth: none" value. This meant that no authorisation was needed but made the objects syntactically correct. As with any major change backwards compatibility was essential. So anyone could use the auth value 'none' in their own MNTNER objects. This allowed users who were not familiar with using authorisation in the RIPE Database to comply with the syntax but not add any real authorisation.<br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169208" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169249" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983">As you may have realised there is lots of static data in the RIPE Database. This is data that is still correct and still in use but has not needed to be changed in any way for, possibly, decades. For the users who manage this data they generally don't follow RIPE Database events and don't spend any time 'actively' managing this data. Everything just works so if it ain't broken there is no need to fix it.</span></div><div id="yui_3_16_0_ym19_1_1479439613040_169328" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169460" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983">In 2003 it was proposed that this 'false' concept of authorisation was deprecated. That happened in 2004. Despite the publicity, many users with this static data simply got on with life. So now, 12 years later, there are still objects in the database that are maintained by this 'ripe-ncc-locked-mnt' from this security fix in 2004.</span></div><div id="yui_3_16_0_ym19_1_1479439613040_169554" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169555" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983">Now lets jump forward to more recent times. The MNTNER object 'ripe-ncc-locked-mnt' is used by the RIPE NCC in any situation where data needs to be locked. It was used recently to lock the remaining unmaintained PERSON and ROLE objects.<br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169576" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169615" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983">Until about 3 or 4 years ago (when the software was re-written in java), authorisation was not validated on object creation. So anyone could create any object referencing any MNTNER object in the database, including 'ripe-ncc-locked-mnt'. Of course as soon as you created it you were locked out as you would not have the authorisation for that MNTNER you referenced. But if you didn't need to modify it the object would sit quite happily in the database and you could still reference it.</span></div><div id="yui_3_16_0_ym19_1_1479439613040_169698" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169739" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983">With the re-write of the software that issue was closed. So now you do need to authorise object creations. Another change that was added is that no one outside the RIPE NCC can add or remove any of the RIPE NCC's MNTNER objects. This includes the 'ripe-ncc-locked-mnt' object. If you try this now you get these errors:</span></div><div id="yui_3_16_0_ym19_1_1479439613040_169853" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"><br></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169852" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983">Create FAILED: [person] AUTO-1 test guy<br id="yui_3_16_0_ym19_1_1479439613040_169838"><br id="yui_3_16_0_ym19_1_1479439613040_169839">person: test guy<br id="yui_3_16_0_ym19_1_1479439613040_169840">address: amsterdam<br id="yui_3_16_0_ym19_1_1479439613040_169841">phone: +31<br id="yui_3_16_0_ym19_1_1479439613040_169842">nic-hdl: AUTO-1<br id="yui_3_16_0_ym19_1_1479439613040_169843">mnt-by: ripe-ncc-locked-mnt<br id="yui_3_16_0_ym19_1_1479439613040_169844">source: RIPE<br id="yui_3_16_0_ym19_1_1479439613040_169845"><br id="yui_3_16_0_ym19_1_1479439613040_169846">***Error: Authorisation for [person] TG5494-RIPE failed<br id="yui_3_16_0_ym19_1_1479439613040_169847"> using "mnt-by:"<br id="yui_3_16_0_ym19_1_1479439613040_169848"> not authenticated by: RIPE-NCC-LOCKED-MNT<br id="yui_3_16_0_ym19_1_1479439613040_169849"><br id="yui_3_16_0_ym19_1_1479439613040_169850">***Error: You cannot add or remove a RIPE NCC maintainer<br id="yui_3_16_0_ym19_1_1479439613040_169851"></span></div><div id="yui_3_16_0_ym19_1_1479439613040_169976" dir="ltr"><span id="yui_3_16_0_ym19_1_1479439613040_168983"></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1479439613040_168985" class="qtdSeparateBR"><br><div dir="ltr" id="yui_3_16_0_ym19_1_1479439613040_169977">I did a free text search to find some ROUTE object that had this MNTNER, 'ripe-ncc-locked-mnt'. I found this example:</div><pre id="yui_3_16_0_ym19_1_1479439613040_170088"> route-set: rs-AS327795<br id="yui_3_16_0_ym19_1_1479439613040_170179"> descr: Tanzania e-Government Agency<br id="yui_3_16_0_ym19_1_1479439613040_170180"> tech-c: GM16-AFRINIC<br id="yui_3_16_0_ym19_1_1479439613040_170181"> admin-c: GM16-AFRINIC<br id="yui_3_16_0_ym19_1_1479439613040_170182"> mnt-by: RIPE-NCC-LOCKED-MNT<br id="yui_3_16_0_ym19_1_1479439613040_170183"> mnt-lower: eGA-MNT<br id="yui_3_16_0_ym19_1_1479439613040_170184"> created: 2015-04-01T14:16:38Z<br id="yui_3_16_0_ym19_1_1479439613040_170185"> last-modified: 2016-04-25T13:09:57Z<br id="yui_3_16_0_ym19_1_1479439613040_170186"> source: RIPE<br></pre><div id="yui_3_16_0_ym19_1_1479439613040_170192"><br></div><div id="yui_3_16_0_ym19_1_1479439613040_170199">But if you look at the history of this object you will see the original object was this:</div><div id="yui_3_16_0_ym19_1_1479439613040_170459"><br></div><div id="yui_3_16_0_ym19_1_1479439613040_170285" dir="ltr">route-set: rs-AS327795<br id="yui_3_16_0_ym19_1_1479439613040_170255">descr: Tanzania e-Government Agency<br id="yui_3_16_0_ym19_1_1479439613040_170256">tech-c: GM16-AFRINIC<br id="yui_3_16_0_ym19_1_1479439613040_170257">admin-c: GM16-AFRINIC<br id="yui_3_16_0_ym19_1_1479439613040_170258">mnt-by: RIPE-NCC-RPSL-MNT<br id="yui_3_16_0_ym19_1_1479439613040_170259">mnt-lower: eGA-MNT<br id="yui_3_16_0_ym19_1_1479439613040_170260">created: 2015-04-01T14:16:38Z<br id="yui_3_16_0_ym19_1_1479439613040_170261">last-modified: 2015-04-01T14:16:38Z<br id="yui_3_16_0_ym19_1_1479439613040_170262">source: RIPE<br></div><div id="yui_3_16_0_ym19_1_1479439613040_170286"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1479439613040_170287">This was another fix done by the RIPE NCC that was requested by the community. The MNTNER 'ripe-ncc-rpsl-mnt' has a public password listed in a "remarks:" in the object. So it is not secure. This object only exists to create ROUTE objects for out of region resources. Again it is not possible now for any user to create an object referencing this MNTNER. But many objects were created until recently with this MNTNER. So the RIPE NCC locked all such objects as another security fix.</div><div id="yui_3_16_0_ym19_1_1479439613040_170458" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1479439613040_170457" dir="ltr">I could have jumped straight to this example, but I thought the history behind all these changes may help with understanding why some situations exist/existed.</div><div id="yui_3_16_0_ym19_1_1479439613040_170455" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1479439613040_170453" dir="ltr">cheers</div><div id="yui_3_16_0_ym19_1_1479439613040_170454" dir="ltr">denis<br></div><div id="yui_3_16_0_ym19_1_1479439613040_170452"><br></div></div><div style="display: block;" id="yui_3_16_0_ym19_1_1479439613040_169047" class="yahoo_quoted"> <div id="yui_3_16_0_ym19_1_1479439613040_169046" style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1479439613040_169045" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1479439613040_169044" dir="ltr"> <font id="yui_3_16_0_ym19_1_1479439613040_169043" face="Arial" size="2"> <hr id="yui_3_16_0_ym19_1_1479439613040_169042" size="1"> <b id="yui_3_16_0_ym19_1_1479439613040_169207"><span id="yui_3_16_0_ym19_1_1479439613040_169206" style="font-weight:bold;">From:</span></b> Ronald F. Guilmette <rfg@tristatelogic.com><br> <b><span style="font-weight: bold;">To:</span></b> db-wg@ripe.net <br> <b><span style="font-weight: bold;">Sent:</span></b> Sunday, 20 November 2016, 5:21<br> <b><span style="font-weight: bold;">Subject:</span></b> [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT<br> </font> </div> <div id="yui_3_16_0_ym19_1_1479439613040_169205" class="y_msg_container"><br><br><br>I am having a bit of trouble decyphering the explanation/description of<br>RIPE-NCC-LOCKED-MNT given on the following page, and I hope someone will<br>help me to understand.<br><br><a href="https://www.ripe.net/publications/news/announcements/deprecation-of-the-none-authentication-scheme" target="_blank">https://www.ripe.net/publications/news/announcements/deprecation-of-the-none-authentication-scheme</a><br><br><br>It appears from the above, that there was a transition/reorganization<br>that took place back around 2004, and that RIPE-NCC-LOCKED-MNT was set<br>as the maintainer on various objects that were present in the data base<br>at that time (specifically objects which were not already adequately<br>password protected) in order to protect some such objects from unauthorized<br>modification.<br><br>Is that description approximately accurate, I mean to a first approximation?<br>(I understand that I'm probably glossing over a number of the fine points<br>here, but I am doing so just because I doubt that any of those are even<br>pertinent to my real question.)<br><br>So anyway, my real question is this:<br><br>If in fact RIPE-NCC-LOCKED-MNT was just something which was used as a<br>sort-of "passing phase" stop-gap mechanism, i.e. as just a convenient<br>expedient for securing things that would otherwise poorly secured,<br>and if it was only applied in this way back in 2004, and for perhaps<br>a year or two afterwards, then what would be the explanation for a<br>*recently created* data base object (e.g. a route object) that has a<br>created: date of, say, 2014, 2015, or 2016 and also a mnt-by value of<br>RIPE-NCC-LOCKED-MNT?<br><br><br>Regards,<br>rfg<br><br><br><br></div> </div> </div> </div></div></body></html>