mntner with misleading primary key
Hello db-wg, A simple query to the RIPEDB ('whois -h whois.ripe.net -r AS2856') returns the aut-num AS2856 that you would expect, but it also returns a mntner with the same primary key: % Information related to 'as2856' mntner: as2856 admin-c: JA6431-RIPE auth: SSO # Filtered mnt-by: as2856 created: 2018-08-23T15:46:37Z last-modified: 2018-08-23T15:46:37Z source: RIPE # Filtered This has caused some concern, and while we (2856) have already determined how that mnter came to be in the database - and that there isn't any immediate risk - it isn't in any way affiliated with the AS2856 network, or any part of the parent company. One can imagine that given the quality of NOCs & their understanding of database objects the world over, that one of them might be convinced that the person associated with this mntner was indeed associated with the network AS2856, and they might also be convinced to announce prefixes that they otherwise should not. It is obvious that speaking to the owner of the mntner and politely asking them to switch to a new mntner would be pertinent, but as far as I'm aware they're under no obligation to do so. Yet, it feels that AS2856 (or any network in the RIPE region) remains potentially at some risk should a bad actor combine such a mntner, with some questionable verification of their credentials, and socially engineer their way toward a route hijack. Should it be possible to create mntners (or other objects) that infer a relationship and/or authority to a given aut-num (or organisation?) Might there be negative side-effects in restricting the primary key of mntners from impersonating other objects? I'm unable to construct a query to the RIPEDB that looks for mntner objects beginning with 'as', in order to gauge how common this is. I suspect that's because the phrase is too short, but if it is possible please do enlighten me! :) Regards, -- Tom
Tom Hill via db-wg wrote on 01/07/2020 15:56:
I'm unable to construct a query to the RIPEDB that looks for mntner objects beginning with 'as', in order to gauge how common this is. I suspect that's because the phrase is too short, but if it is possible please do enlighten me! :)
No direct way to query via the standard interface, but you can do it this way:
crumpet% wget ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.mntner.gz [...] crumpet% gzcat ripe.db.mntner.gz | egrep -i '^mntner:[[:space:]]+as[0-9]+$' mntner: AS327833 mntner: AS58224 mntner: AS42910 mntner: AS37527 mntner: AS8362 mntner: AS202723 mntner: as2856 mntner: AS12400 mntner: AS427313 mntner: AS397268 mntner: AS12655 mntner: AS30956 mntner: AS49717 crumpet%
Otherwise:
Should it be possible to create mntners (or other objects) that infer a relationship and/or authority to a given aut-num (or organisation?)
Yes, this is a problem with any DB which returns text-based output based on searches of arbitrary input tokens. In an IRR, some object primary keys have restrictions on what you can call them. For example, an as-set must start with "AS-". What you're really asking in the context of this style of database is that each primary key must assume a specific format which cannot be replicated on any other object type. This would be difficult to retrofit. Nick
On 01/07/2020 16:56, Nick Hilliard wrote:
No direct way to query via the standard interface, but you can do it this way:
crumpet% wget ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.mntner.gz [...] crumpet% gzcat ripe.db.mntner.gz | egrep -i '^mntner:[[:space:]]+as[0-9]+$' mntner: AS327833 *snip*
Aha! Thank you - I knew someone would know.
Should it be possible to create mntners (or other objects) that infer a relationship and/or authority to a given aut-num (or organisation?)
Yes, this is a problem with any DB which returns text-based output based on searches of arbitrary input tokens.
In an IRR, some object primary keys have restrictions on what you can call them. For example, an as-set must start with "AS-".
What you're really asking in the context of this style of database is that each primary key must assume a specific format which cannot be replicated on any other object type. This would be difficult to retrofit.
Would it actually be difficult to retrofit a "MUST NOT match '^as*|^AS*'" rule on creation? Unless of course, parsing/filtering before insertion (thus augmenting the database's table natural design restrictions) is not something Good To Do. Database design definitely isn't my primary skill. Saying that, I have long been idly frustrated by the way that mntners seemingly have a reversible, unwritten standard of 'MNT-[random]' or '[random]-MNT'. I can't be the only one. Regards, -- Tom
Dear Tom, On Wed, Jul 1, 2020, at 16:16, Tom Hill via db-wg wrote:
Unless of course, parsing/filtering before insertion (thus augmenting the database's table natural design restrictions) is not something Good To Do. Database design definitely isn't my primary skill.
Saying that, I have long been idly frustrated by the way that mntners seemingly have a reversible, unwritten standard of 'MNT-[random]' or '[random]-MNT'. I can't be the only one.
It is possible to change this, but it'll take some time: extensive research to figure out a path which causes the least disruption to the fewest amount of people. Ideally only a handful of people have to change their "mntner:" primary key. I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-) It starts with a volunteer who does some digging in the data to see if a migration path can be constructed or not. A conclusion may be that it is too hard, but we don't know yet. Are you up for it? :) Kind regards, Job
I am not sure how feasible the mandatory "-mnt" would be at this point tbh. I can easily think of at least 2 maintainers that are actually used that I see quite often that wouldn't fit that pattern. There are probably a considerable amount of maintainers that do not follow this pattern in fact... $ grep -P 'mntner:\s+(?:(?!mnt\-|MNT\-|MAINT\-|maint\-).(?!\-MNT|\-mnt|\-maint|\-MAINT))+$' ripe.db.mntner | wc -l 6990 $ grep -P 'mntner:\s+' ripe.db.mntner | wc -l 56524 I don't think we can make 12% of people change their maintainer for this purpose. - Cynthia On Wed, Jul 1, 2020 at 6:28 PM Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear Tom,
On Wed, Jul 1, 2020, at 16:16, Tom Hill via db-wg wrote:
Unless of course, parsing/filtering before insertion (thus augmenting the database's table natural design restrictions) is not something Good To Do. Database design definitely isn't my primary skill.
Saying that, I have long been idly frustrated by the way that mntners seemingly have a reversible, unwritten standard of 'MNT-[random]' or '[random]-MNT'. I can't be the only one.
It is possible to change this, but it'll take some time: extensive research to figure out a path which causes the least disruption to the fewest amount of people. Ideally only a handful of people have to change their "mntner:" primary key.
I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-)
It starts with a volunteer who does some digging in the data to see if a migration path can be constructed or not. A conclusion may be that it is too hard, but we don't know yet. Are you up for it? :)
Kind regards,
Job
I fully agree with Cynthia here, we use the maintainer STACLAR for example. I have looked through the database files and there seem to be exactly 26 maintainer objects that are named as an ASN (without any prefixes or suffixes). I think the best solution would be to just block the creation of new objects like this and manually check through the existing ones to find potentially fraudulent ones. Matthias Merkel Vice President Staclar, Inc. [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/phon...] +1-302-291-1141 | +49 15678 585608 [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/emai...] matthias.merkel@staclar.com<mailto:matthias.merkel@staclar.com> [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/link...] staclar.com<https://staclar.com/> [https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/addr...] Munich, Germany [https://staclar.com/images/logo.png] [linkedin]<https://www.linkedin.com/in/matthias-merkel/> ________________________________ From: db-wg <db-wg-bounces@ripe.net> on behalf of Cynthia Revström via db-wg <db-wg@ripe.net> Sent: Wednesday, July 1, 2020 7:36 PM To: Job Snijders <job@instituut.net> Cc: DB-WG <db-wg@ripe.net> Subject: Re: [db-wg] mntner with misleading primary key I am not sure how feasible the mandatory "-mnt" would be at this point tbh. I can easily think of at least 2 maintainers that are actually used that I see quite often that wouldn't fit that pattern. There are probably a considerable amount of maintainers that do not follow this pattern in fact... $ grep -P 'mntner:\s+(?:(?!mnt\-|MNT\-|MAINT\-|maint\-).(?!\-MNT|\-mnt|\-maint|\-MAINT))+$' ripe.db.mntner | wc -l 6990 $ grep -P 'mntner:\s+' ripe.db.mntner | wc -l 56524 I don't think we can make 12% of people change their maintainer for this purpose. - Cynthia On Wed, Jul 1, 2020 at 6:28 PM Job Snijders via db-wg <db-wg@ripe.net<mailto:db-wg@ripe.net>> wrote: Dear Tom, On Wed, Jul 1, 2020, at 16:16, Tom Hill via db-wg wrote:
Unless of course, parsing/filtering before insertion (thus augmenting the database's table natural design restrictions) is not something Good To Do. Database design definitely isn't my primary skill.
Saying that, I have long been idly frustrated by the way that mntners seemingly have a reversible, unwritten standard of 'MNT-[random]' or '[random]-MNT'. I can't be the only one.
It is possible to change this, but it'll take some time: extensive research to figure out a path which causes the least disruption to the fewest amount of people. Ideally only a handful of people have to change their "mntner:" primary key. I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-) It starts with a volunteer who does some digging in the data to see if a migration path can be constructed or not. A conclusion may be that it is too hard, but we don't know yet. Are you up for it? :) Kind regards, Job
On 01/07/2020 18:43, Matthias Merkel via db-wg wrote:
I have looked through the database files and there seem to be exactly 26 maintainer objects that are named as an ASN (without any prefixes or suffixes). I think the best solution would be to just block the creation of new objects like this and manually check through the existing ones to find potentially fraudulent ones.
If it were possible, that would solve the risk associated. I'm not sure, however, if that sort of creation filter is appropriate? Is there precedent for this? -- Tom
On Wed, Jul 1, 2020, at 20:34, Tom Hill via db-wg wrote:
On 01/07/2020 18:43, Matthias Merkel via db-wg wrote:
I have looked through the database files and there seem to be exactly 26 maintainer objects that are named as an ASN (without any prefixes or suffixes). I think the best solution would be to just block the creation of new objects like this and manually check through the existing ones to find potentially fraudulent ones.
26 is at the number where we can pick up the phone and ask politely
If it were possible, that would solve the risk associated. I'm not sure, however, if that sort of creation filter is appropriate? Is there precedent for this?
Yes, creation filters have precedent. Would be a good tool here IMHO. Kind regards, Job
Hi, On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
I am not sure how feasible the mandatory "-mnt" would be at this point tbh. I can easily think of at least 2 maintainers that are actually used that I see quite often that wouldn't fit that pattern.
It would annoy me a bit, because all our stuff is under SPACENET-N and SPACENET-P ("networks and person objects"). And all tools. Of course it is doable, but... why? Convince me :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Wed, Jul 1, 2020, at 20:52, Gert Doering wrote:
On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
I am not sure how feasible the mandatory "-mnt" would be at this point tbh. I can easily think of at least 2 maintainers that are actually used that I see quite often that wouldn't fit that pattern.
It would annoy me a bit, because all our stuff is under SPACENET-N and SPACENET-P ("networks and person objects"). And all tools.
Of course it is doable, but... why? Convince me :-)
As I understand the conversation, the one option on the table to discuss is how to deal with primary keys that clash with other scopes of context, specifically autnums. Of those only 26 exist SPACENET-P does not look like an AS number so isn't an issue and doesn't need to change. Kind regards, Job
Hi, On Wed, Jul 01, 2020 at 09:00:44PM +0200, Job Snijders wrote:
On Wed, Jul 1, 2020, at 20:52, Gert Doering wrote:
On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
I am not sure how feasible the mandatory "-mnt" would be at this point tbh. [..] As I understand the conversation, the one option on the table to discuss is how to deal with primary keys that clash with other scopes of context, specifically autnums. Of those only 26 exist
SPACENET-P does not look like an AS number so isn't an issue and doesn't need to change.
This is true, but I was responding to Cynthia's suggestion of having a mandatory "-mnt". Which would affect us - as I said, doable, but it needs to make sense. Of course if it's only about "looks like an ASN" mntners, I'll go back in my lurking corner and watch with interest :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the
Hi Gert, I was not suggesting it, I think it is a bad idea, but I interpreted the following as Job suggesting it. maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-) - Cynthia On Wed, Jul 1, 2020 at 9:05 PM Gert Doering <gert@space.net> wrote:
Hi,
On Wed, Jul 1, 2020, at 20:52, Gert Doering wrote:
On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
I am not sure how feasible the mandatory "-mnt" would be at this
On Wed, Jul 01, 2020 at 09:00:44PM +0200, Job Snijders wrote: point tbh. [..]
As I understand the conversation, the one option on the table to discuss is how to deal with primary keys that clash with other scopes of context, specifically autnums. Of those only 26 exist
SPACENET-P does not look like an AS number so isn't an issue and doesn't need to change.
This is true, but I was responding to Cynthia's suggestion of having a mandatory "-mnt". Which would affect us - as I said, doable, but it needs to make sense.
Of course if it's only about "looks like an ASN" mntners, I'll go back in my lurking corner and watch with interest :-)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Wed, Jul 1, 2020, at 19:06, Cynthia Revström wrote:
I was not suggesting it, I think it is a bad idea, but I interpreted the following as Job suggesting it.
I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-)
Apologies for being not clear. I can rephrase: it would've been nice if from the start a suffix like "-MAINT" was used to clearly label the object names as the type they are. But that ship clearly has long sailed. We can't change that anymore. The next best thing we can now do is attempt to rename the ones that actually clash with autnums, which luckily is only a very short list, and prevent future occurrences with a creation filter. Kind regards, Job
On 01/07/2020 20:54, Job Snijders via db-wg wrote:
The next best thing we can now do is attempt to rename the ones that actually clash with autnums, which luckily is only a very short list, and prevent future occurrences with a creation filter.
As I don't think we have seen this exploited (yet) I'd settle for the latter; to prevent future occurrences. It wouldn't hurt to ask those nicely to rename their mntners, but I'd wager most of those mntners identified will be in use by the aut-num of the same AS number. A random selection from Matthias' list that I've just checked quickly are exactly like that; aut-num AS49717, mnt-by AS49717. Regards, -- Tom
Colleagues "We can't change that anymore" Anything is possible and anything can be changed and any new rules/filters can be implemented. The RIPE NCC can, and has on many occasions in the past, done updates across the whole database to 'fix problems'. I would suggest that you don't concern yourselves at this stage with 'how' something can be done. Discuss and debate what you think is needed or wanted and justifiable. Bearing in mind that not everyone will agree on either need or want or the justification. If we can reach a consensus on what is needed to be done, then the RIPE NCC can look at the how and the impact. cheersdenis co-chair DB-WG On Wednesday, 1 July 2020, 21:55:20 CEST, Job Snijders via db-wg <db-wg@ripe.net> wrote: On Wed, Jul 1, 2020, at 19:06, Cynthia Revström wrote:
I was not suggesting it, I think it is a bad idea, but I interpreted the following as Job suggesting it.
I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-)
Apologies for being not clear. I can rephrase: it would've been nice if from the start a suffix like "-MAINT" was used to clearly label the object names as the type they are.But that ship clearly has long sailed. We can't change that anymore. The next best thing we can now do is attempt to rename the ones that actually clash with autnums, which luckily is only a very short list, and prevent future occurrences with a creation filter. Kind regards, Job
Colleagues My apologies for once again being a conversation killer :( Let me try to revive this conversation and see if we have a consensus. There seemed to be two main issues:1/ MNTNER names not having a clear 'tag' indicating a MNTNER object2/ MNTNER names specifically confused with ASNs For the first part we can add a prefix (MNT-) or suffix (-MNT), or allow both options, and enforce this on all 'new' MNTNER object creations. For the second part, if there are specific objects that 'look like' ASNs and not belonging to the organisations holding those ASNs, they can be further investigated, if it is considered necessary. Please also bear in mind that PERSON and ROLE objects can also appear to be ASNs. It is also possible to create MNTNER objects that could be confused as IP ranges to unfamiliar database users. There may be other examples of objects that could be confused as a resource object. So if we go down this route where do we draw the line? Final comments please? cheersdenis co-chair DB-WG On Thursday, 2 July 2020, 15:19:53 CEST, ripedenis--- via db-wg <db-wg@ripe.net> wrote: Colleagues "We can't change that anymore" Anything is possible and anything can be changed and any new rules/filters can be implemented. The RIPE NCC can, and has on many occasions in the past, done updates across the whole database to 'fix problems'. I would suggest that you don't concern yourselves at this stage with 'how' something can be done. Discuss and debate what you think is needed or wanted and justifiable. Bearing in mind that not everyone will agree on either need or want or the justification. If we can reach a consensus on what is needed to be done, then the RIPE NCC can look at the how and the impact. cheersdenis co-chair DB-WG On Wednesday, 1 July 2020, 21:55:20 CEST, Job Snijders via db-wg <db-wg@ripe.net> wrote: On Wed, Jul 1, 2020, at 19:06, Cynthia Revström wrote:
I was not suggesting it, I think it is a bad idea, but I interpreted the following as Job suggesting it.
I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-)
Apologies for being not clear. I can rephrase: it would've been nice if from the start a suffix like "-MAINT" was used to clearly label the object names as the type they are.But that ship clearly has long sailed. We can't change that anymore. The next best thing we can now do is attempt to rename the ones that actually clash with autnums, which luckily is only a very short list, and prevent future occurrences with a creation filter. Kind regards, Job
On Tue, Sep 1, 2020 at 3:58 PM ripedenis--- via db-wg <db-wg@ripe.net> wrote: [...]
There seemed to be two main issues: 1/ MNTNER names not having a clear 'tag' indicating a MNTNER object 2/ MNTNER names specifically confused with ASNs
For the first part we can add a prefix (MNT-) or suffix (-MNT), or allow both options, and enforce this on all 'new' MNTNER object creations.
For the second part, if there are specific objects that 'look like' ASNs and not belonging to the organisations holding those ASNs, they can be further investigated, if it is considered necessary. Please also bear in mind that PERSON and ROLE objects can also appear to be ASNs. It is also possible to create MNTNER objects that could be confused as IP ranges to unfamiliar database users. There may be other examples of objects that could be confused as a resource object. So if we go down this route where do we draw the line?
Final comments please?
Strong support for reducing the opportunities for confusion from me. Thanks for the summary. Regards, Leo Vegoda
Colleagues I must stop sending out emails at 1am. It seems Leo is the only person reading emails at that time in the morning :) Some (final) comments on this issue would be appreciated to see if we can move forward... cheersdenis co-chair DB-WG ----- Forwarded message ----- From: ripedenis--- via db-wg <db-wg@ripe.net>To: Cynthia Revström <me@cynthia.re>; Gert Doering <gert@space.net>; Job Snijders <job@instituut.net>Cc: Tom Hill via db-wg <db-wg@ripe.net>Sent: Wednesday, 2 September 2020, 00:58:21 CESTSubject: Re: [db-wg] mntner with misleading primary key Colleagues My apologies for once again being a conversation killer :( Let me try to revive this conversation and see if we have a consensus. There seemed to be two main issues:1/ MNTNER names not having a clear 'tag' indicating a MNTNER object2/ MNTNER names specifically confused with ASNs For the first part we can add a prefix (MNT-) or suffix (-MNT), or allow both options, and enforce this on all 'new' MNTNER object creations. For the second part, if there are specific objects that 'look like' ASNs and not belonging to the organisations holding those ASNs, they can be further investigated, if it is considered necessary. Please also bear in mind that PERSON and ROLE objects can also appear to be ASNs. It is also possible to create MNTNER objects that could be confused as IP ranges to unfamiliar database users. There may be other examples of objects that could be confused as a resource object. So if we go down this route where do we draw the line? Final comments please? cheersdenis co-chair DB-WG On Thursday, 2 July 2020, 15:19:53 CEST, ripedenis--- via db-wg <db-wg@ripe.net> wrote: Colleagues "We can't change that anymore" Anything is possible and anything can be changed and any new rules/filters can be implemented. The RIPE NCC can, and has on many occasions in the past, done updates across the whole database to 'fix problems'. I would suggest that you don't concern yourselves at this stage with 'how' something can be done. Discuss and debate what you think is needed or wanted and justifiable. Bearing in mind that not everyone will agree on either need or want or the justification. If we can reach a consensus on what is needed to be done, then the RIPE NCC can look at the how and the impact. cheersdenis co-chair DB-WG On Wednesday, 1 July 2020, 21:55:20 CEST, Job Snijders via db-wg <db-wg@ripe.net> wrote: On Wed, Jul 1, 2020, at 19:06, Cynthia Revström wrote:
I was not suggesting it, I think it is a bad idea, but I interpreted the following as Job suggesting it.
I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the maintainers primary key string does pop up from time to time without any context, and this can lead to confusion. See https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's email error code is another person's BGP autonomous system reference. :-)
Apologies for being not clear. I can rephrase: it would've been nice if from the start a suffix like "-MAINT" was used to clearly label the object names as the type they are.But that ship clearly has long sailed. We can't change that anymore. The next best thing we can now do is attempt to rename the ones that actually clash with autnums, which luckily is only a very short list, and prevent future occurrences with a creation filter. Kind regards, Job
On 07/09/2020 12:16, ripedenis--- via db-wg wrote:
enforce this on all 'new' MNTNER object creations I'm all for enforcing this syntax per you comment above.
Makes sense to _always_ be able to expect certain syntax rules for different DB objects types.
So if we go down this route where do we draw the line?
Current standpoint: For a "phase I". I would suggest enforcing syntax rules for _new_ objects. Future standpoint up for discussion: For a "phase II", walkthrough current DB primary keys to get a scope of how many objects primary keys would need to be updated to follow "phase I" enforced syntax rules(?) -- Kind regards, CHRIZTOFFER
Hi Chriztoffer,
On 7 Sep 2020, at 12:45, Chriztoffer Hansen via db-wg <db-wg@ripe.net> wrote:
On 07/09/2020 12:16, ripedenis--- via db-wg wrote:
enforce this on all 'new' MNTNER object creations I'm all for enforcing this syntax per you comment above.
Makes sense to _always_ be able to expect certain syntax rules for different DB objects types.
The mntner name currently conforms to the <object-name> syntax defined in the RPSL RFC: https://tools.ietf.org/html/rfc2622#section-2 <https://tools.ietf.org/html/rfc2622#section-2> There is no requirement to prefix or postfix with "MNT" at all.
So if we go down this route where do we draw the line?
Current standpoint: For a "phase I". I would suggest enforcing syntax rules for _new_ objects.
A syntax rule change can be done without needing a cleanup, if only enforced for new objects.
Future standpoint up for discussion: For a "phase II", walkthrough current DB primary keys to get a scope of how many objects primary keys would need to be updated to follow "phase I" enforced syntax rules(?)
I checked the RIPE database and found 12480 mntners starting with "MNT-", 36347 mntners ending with "-MNT", and 7772 for all other names.
-- Kind regards, CHRIZTOFFER
Users can also report inaccurate information in the RIPE database to the RIPE NCC: https://www.ripe.net/contact-form <https://www.ripe.net/contact-form> We can contact the user and ask them to correct or remove the object. Regards Ed Shryane RIPE NCC
ripedenis--- via db-wg wrote on 01/09/2020 23:56:
Let me try to revive this conversation and see if we have a consensus.
There seemed to be two main issues: 1/ MNTNER names not having a clear 'tag' indicating a MNTNER object 2/ MNTNER names specifically confused with ASNs
For the first part we can add a prefix (MNT-) or suffix (-MNT), or allow both options, and enforce this on all 'new' MNTNER object creations.
there are 12660 (22%) objects starting with MNT-, 36334 (64%) starting with -MNT, and 7844 (14%) with neither MNT- nor -MNT. Curiously, there are 10 objects starting with MNT- and ending with -MNT. I guess some people like to be sure. Someone seems to have registered "MNT" as a maintainer name, which is inventive in a minimalist way. There are 14 objects which match /^AS([0-9]+)$/. This is messy because by convention that regexp describes an ASN. There are 4 objects which match /^AS-/. This is a problem because /^AS-/ is reserved for as-sets. These need to be removed / renamed. There are no objects which match /^(FLTR|RTRS|PRNG)-/. There needs to be code to block /^(AS|FLTR|RTRS|PRNG)-/, and the existing 4 objects probably ought to be changed.
For the second part, if there are specific objects that 'look like' ASNs and not belonging to the organisations holding those ASNs, they can be further investigated, if it is considered necessary. Please also bear in mind that PERSON and ROLE objects can also appear to be ASNs. It is also possible to create MNTNER objects that could be confused as IP ranges to unfamiliar database users. There may be other examples of objects that could be confused as a resource object. So if we go down this route where do we draw the line?
Creating one key which looks like another style of key is going to cause confusion. Some judicious use of regular expressions might be a good to stop this. Nick
Hi,
On Wed, Jul 01, 2020 at 09:00:44PM +0200, Job Snijders wrote:
On Wed, Jul 1, 2020, at 20:52, Gert Doering wrote:
On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
I am not sure how feasible the mandatory "-mnt" would be at this point tbh. [..] As I understand the conversation, the one option on the table to discuss is how to deal with primary keys that clash with other scopes of context, specifically autnums. Of those only 26 exist
SPACENET-P does not look like an AS number so isn't an issue and doesn't need to change. This is true, but I was responding to Cynthia's suggestion of having a mandatory "-mnt". Which would affect us - as I said, doable, but it needs to make sense.
Of course if it's only about "looks like an ASN" mntners, I'll go back in my lurking corner and watch with interest :-)
Gert Doering -- NetMaster I would be a fan of the mandatory -mnt. This can cause other problems
On 7/1/2020 3:05 PM, Gert Doering via db-wg wrote: like I mentioned here a few weeks ago... RDAP will not work with KR4422-RIPE, because this is both a mntner and a person.
Hi Tom, On Wed, 1 Jul 2020 at 18:16, Tom Hill via db-wg <db-wg@ripe.net> wrote:
Would it actually be difficult to retrofit a "MUST NOT match '^as*|^AS*'" rule on creation?
1,375 maintainers (including ours) are named ASxxx-MNT (1,330) or MNT-ASxxx (45), so it is not only acceptable but common practice. Those same social engineering risks apply to those. Prohibiting "^AS.*" entirely would make 1,563 total maintainers illegal. What you are looking for here is not a regexp to tell them their standard is wrong, but some business rule that prevents someone from creating an maintainer with a name that is potentially confusing (according to some narrowly defined rules that will all of a sudden start imparting meaning to an previously effectively freetext field) unless you have [some other authorisation] that entitles you to use that [other object reference]. Sounds far too complicated a rule to implement, or determine whether someone has the authority for. I think enforcing -MNT on *new* creations going forward is not a bad idea, as it solves the original problem of them showing up in other searches due to identical primary keys. There is after all precedent for enforcing a naming convention (role, person). I don't know about the feasibility of then taking it a step further and ensuring authority for creation of ASxxx-MNT, nor do I know where that ends. Should I be concerned about someone creating DC5052-RIPE-MNT? Regards, David
participants (12)
-
Brian Rak -
Chriztoffer Hansen -
Cynthia Revström -
David Croft -
Edward Shryane -
Gert Doering -
Job Snijders -
Leo Vegoda -
Matthias Merkel -
Nick Hilliard -
ripedenis＠yahoo.co.uk -
Tom Hill