[db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Dear DB-WG, Speaking in individual capacity. In RFC 2622 section 5 specifies the naming convention for AS-SET objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 There basically are two styles: * "short" (example: AS-SNIJDERS) * "hierarchical" (example: AS15562:AS-SNIJDERS) Problem statement = In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy of the object is the the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. Solution proposal = I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. Related work Related work throughout the registry industry: IRRd version 4 forces new AS-SET objects to be structured hierarchically: https://github.com/irrdnet/irrd/issues/408 Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
I also support this proposal. I've assisted some of the mentioned networks in the Original Post to solve the overlapping AS-SETS and it has been a real operational pain. It's clear that the actors that are doing this are motivated either by amusement at causing networks downtime or pain, or as a way to ransom the impacted networks. While those actors could move to another RIR or non-authenticated database to do this, I believe that solving this here would help shift networks to using a more secure by default AS-SET convention, and protect networks that have yet to move. I see two ways out of this problem, RIPE comes up with a policy for getting overlapping AS-SET objects removed from the database (that are causing problems, either accidentally or in these cases deliberately) or deprecate (as discussed in the OP) short AS-SETs. On Mon, Nov 14, 2022 at 6:03 PM Job Snijders via db-wg wrote: > > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > In recent weeks a number of hypergiant cloud providers have faced the > thorny effects of adversarial AS-SET object naming collisions between > IRR databases. > > An example of this phenomenon is the existence of AS-AMAZON in both RADB > and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy > of the object is the the correct one and populated with a number of > members entries. The RIPE one is empty, and not under control of Amazon. > > The existence of the AS-AMAZON object in the RIPE database might cause > some operators to inadvertently apply empty prefix-filters to EBGP > sessions which in turn causes various problems. > > It seems Amazon has no recourse to get the AS-AMAZON object removed from > the RIPE database; because the existence of that object in the RIPE > database does not violate any policies (as far as I know). But perhaps, > going forward, this community can do a little bit more to help prevent > similar situations from happening to others. > > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as applied by the RIPE Whois Server database engine do a decent > job of protecting/separating namespaces. 'Grandfathering' existing > short-named objects ensures that implementation of this solution > proposal causes minimal (if any) disruption to existing workflows. > > The RIPE database engine blocking creation of short-named AS-SETs might > help nudge the industry towards making hierarchical naming the norm. > > Related work > > Related work throughout the registry industry: IRRd version 4 forces new > AS-SET objects to be structured hierarchically: > https://github.com/irrdnet/irrd/issues/408 > > Kind regards, > > Job > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Job Interesting timing. I was about to make the same suggestion but for a different reason...accountability. Currently ANYONE can create a set object in the RIPE Database. You can be completely anonymous, not a member or LIR, hold no resources. All you need to do is create a ROLE, MNTNER and set object. I was going to ask this question: Although anyone CAN create a set object, who DOES create set objects? Ignoring the abuse situation you are referring to, is there any legitimate reason for anyone to create a (short named) set object who does not hold an ASN resource? Only if the answer is no, can we enforce hierarchical naming. cheers denis co-chair DB-WG On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg wrote: > > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > In recent weeks a number of hypergiant cloud providers have faced the > thorny effects of adversarial AS-SET object naming collisions between > IRR databases. > > An example of this phenomenon is the existence of AS-AMAZON in both RADB > and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy > of the object is the the correct one and populated with a number of > members entries. The RIPE one is empty, and not under control of Amazon. > > The existence of the AS-AMAZON object in the RIPE database might cause > some operators to inadvertently apply empty prefix-filters to EBGP > sessions which in turn causes various problems. > > It seems Amazon has no recourse to get the AS-AMAZON object removed from > the RIPE database; because the existence of that object in the RIPE > database does not violate any policies (as far as I know). But perhaps, > going forward, this community can do a little bit more to help prevent > similar situations from happening to others. > > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as applied by the RIPE Whois Server database engine do a decent > job of protecting/separating namespaces. 'Grandfathering' existing > short-named objects ensures that implementation of this solution > proposal causes minimal (if any) disruption to existing workflows. > > The RIPE database engine blocking creation of short-named AS-SETs might > help nudge the industry towards making hierarchical naming the norm. > > Related work > > Related work throughout the registry industry: IRRd version 4 forces new > AS-SET objects to be structured hierarchically: > https://github.com/irrdnet/irrd/issues/408 > > Kind regards, > > Job > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Job, Ben So while I 100% agree with the problem statement here. (if not clear by my email-address, I do work for Amazon, and me in particular has been fighting both RIPE and the adversaries about this illicit Entry) Ideally I don't want to maintain my data in more than one place (right now, that place is RADB). With this suggestion and the hieararchical "protected namespace" this would, if I understand this correctly, not be a problem? I have no problem in moving over to use AS16509:AS-AMAZON as my official AS-SET going forward, if this can't be recreated elsewhere and therefor create these problems, which has the potential of being fairly large if an ISP generates empty prefix lists for us. Another alternative we thought about was to be able to have "invisible" objects or "protected objects" or whatever you want to call them, so we can create for example AS-AMAZON in every IRR-source but have it be invisible to avoid maintaining it, to protect ourselves from automatic prefix-list generators that would use the RIPE-object (empty) infront of the RADB-object (millions of routes). We touch our IRR-data basically daily (RPKI data every minute...) so scaling out here is not very nice. And on this topic, we tried to get this object deleted through regular support, but it was not possible since there is technically nothing that stops anyone from registering anything and calling it whatever. So there is really no jurisdiction from a database point of view to address it. However one thing that IS interesting is that the name itself, is a registered and protected trademark in essentially every single country in the world, so that’s an avenue one could argue should carry some weight in database-cleanliness? Either way, before we torch IRR to the ground there is some incremental steps we could take to make it better it seems like All for. /FK PS: Perhaps RIPE could charge me 8$/mo for a verified blue checkmark on our as-set objects? __ .DS On 2022-11-14, 19:30, "db-wg on behalf of Ben Cartwright-Cox via db-wg" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I also support this proposal. I've assisted some of the mentioned networks in the Original Post to solve the overlapping AS-SETS and it has been a real operational pain. It's clear that the actors that are doing this are motivated either by amusement at causing networks downtime or pain, or as a way to ransom the impacted networks. While those actors could move to another RIR or non-authenticated database to do this, I believe that solving this here would help shift networks to using a more secure by default AS-SET convention, and protect networks that have yet to move. I see two ways out of this problem, RIPE comes up with a policy for getting overlapping AS-SET objects removed from the database (that are causing problems, either accidentally or in these cases deliberately) or deprecate (as discussed in the OP) short AS-SETs. On Mon, Nov 14, 2022 at 6:03 PM Job Snijders via db-wg wrote: > > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > In recent weeks a number of hypergiant cloud providers have faced the > thorny effects of adversarial AS-SET object naming collisions between > IRR databases. > > An example of this phenomenon is the existence of AS-AMAZON in both RADB > and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy > of the object is the the correct one and populated with a number of > members entries. The RIPE one is empty, and not under control of Amazon. > > The existence of the AS-AMAZON object in the RIPE database might cause > some operators to inadvertently apply empty prefix-filters to EBGP > sessions which in turn causes various problems. > > It seems Amazon has no recourse to get the AS-AMAZON object removed from > the RIPE database; because the existence of that object in the RIPE > database does not violate any policies (as far as I know). But perhaps, > going forward, this community can do a little bit more to help prevent > similar situations from happening to others. > > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as appli
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi, On Mon, Nov 14, 2022 at 05:41:16PM +, Job Snijders via db-wg wrote: > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. Support. (Though I think that ASes that use RADB as their primary documentation store deserve some amount of pain, but that's a different crusade) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi, I am not going to outright support this proposal as I think that this is not really the way we should be dealing with it. The main reason for this is because I think it is quite pointless unless every common IRR database does it. (all RIRs + RADB, ALTDB, etc...). Also there is no way to really do this in the non-authenticated IRRs (RADB, ALTDB, etc.) so I think it is something that will only work if we abandon the non-RIR IRRs. I think Fredrik's idea of allowing certain names to be blocked is good along with putting in a procedure for these names to be removed. This would still have the same problems as this proposal but it feels like a more minor thing as I do think this is a pretty minor issue in terms of the number of entities that are likely to have this happen to them. Those entities might very well also have worldwide trademarks and it seems sensible to have a policy of letting companies with trademarks have an as-set using that trademark removed, especially when it is clearly not being used for a legitimate purpose. Disallowing something like AS-SNIJDERS just seems like it is doing more than is really justified for how little I imagine would change. It also comes with the added potential issue if some org has an as-set with a name that was previously allowed and if they for some reason accidentally delete it and are then unable to recreate it. I am not sure how likely that is to be an issue but it seems like it could very well be an issue that might occur. I will also reiterate what I said on routing-wg regarding essentially the same issue: IRR is not good and there is no way we can really make it good and especially not while people are still relying on non-authenticated IRRs (like RADB, ALTDB, etc.). For as long as we use non-authenticated IRRs, the system will be broken. Maybe a good first step to try to prevent this would be for the big companies getting impacted by these issues to switch to authenticated IRRs hosted by RIRs. Not placing blame on these companies for getting impacted, but the fact that RADB and other non-authenticated IRRs are still used is part of why this problem will be difficult to fix. In the long run we just need to fully replace IRR though. Finally I want to say that I am willing to support this proposal if everyone else thinks that is the best way to "solve" this issue but I would like you to also consider my suggestions as a potential alternative. -Cynthia On Mon, Nov 14, 2022 at 10:35 PM Korsbaeck, Fredrik via db-wg wrote: > > Job, Ben > > So while I 100% agree with the problem statement here. (if not clear by my > email-address, I do work for Amazon, and me in particular has been fighting > both RIPE and the adversaries about this illicit Entry) > > Ideally I don't want to maintain my data in more than one place (right now, > that place is RADB). With this suggestion and the hieararchical "protected > namespace" this would, if I understand this correctly, not be a problem? > > I have no problem in moving over to use AS16509:AS-AMAZON as my official > AS-SET going forward, if this can't be recreated elsewhere and therefor > create these problems, which has the potential of being fairly large if an > ISP generates empty prefix lists for us. > > Another alternative we thought about was to be able to have "invisible" > objects or "protected objects" or whatever you want to call them, so we can > create for example AS-AMAZON in every IRR-source but have it be invisible to > avoid maintaining it, to protect ourselves from automatic prefix-list > generators that would use the RIPE-object (empty) infront of the RADB-object > (millions of routes). We touch our IRR-data basically daily (RPKI data every > minute...) so scaling out here is not very nice. > > And on this topic, we tried to get this object deleted through regular > support, but it was not possible since there is technically nothing that > stops anyone from registering anything and calling it whatever. So there is > really no jurisdiction from a database point of view to address it. However > one thing that IS interesting is that the name itself, is a registered and > protected trademark in essentially every single country in the world, so > that’s an avenue one could argue should carry some weight in > database-cleanliness? > > Either way, before we torch IRR to the ground there is some incremental steps > we could take to make it better it seems like > > All for. > > /FK > > PS: Perhaps RIPE could charge me 8$/mo for a verified blue checkmark on our > as-set objects? __ .DS > > > On 2022-11-14, 19:30, "db-wg on behalf of Ben Cartwright-Cox via db-wg" > wrote: > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > I also support this proposal. > > I've assisted some of the mentioned networks in the Original Post to > solve the overla
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hello Job, On Mon, 2022-11-14 at 17:41 +, Job Snijders via db-wg wrote: > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > (...) > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. I support that. I have been confronted to issue with one of my downstream, which used to (legitimately) have AS-KIWI as AS-SET at RIPE IRR. However, AS-KIWI also exists in AFRINIC, which was parsed first by one of my connectivity provider, leading to incorrect filters (and, worse, anti-spoof access-lists). I solved the solution by making my downstream use another as-set, but I think it could be easier to have hierarchical IRR naming convention only. But it should become a mandatory thing on all IRR. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
> Job Snijders wrote on Monday, November 14, 2022 6:41 PM: > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. Forcing people to something they could already make use of? Wouldn't mind ... for sure it's minimizing the accidental collision of set names (esp. in other RRs). > The RIPE database engine blocking creation of short-named AS-SETs > might help nudge the industry towards making hierarchical naming > the norm. If others follow. But even if all "important" ones follow - and as Cynthia wrote - as long as RADB and other "open" major RRs are around - the abuse of *evil* person registering the aut-num and a bad as-set would be still possible. So not a final solution, just improving the situation. Markus -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Speaking as be.ccafrique and uk.pccwg-uk I support Job's proposal. Pf On Mon, 14 Nov 2022 17:41:16 + Job Snijders via db-wg wrote: > CAUTION: External email. Do not click links or open attachments unless you > recognize the sender and know the content is safe. > > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > In recent weeks a number of hypergiant cloud providers have faced the > thorny effects of adversarial AS-SET object naming collisions between > IRR databases. > > An example of this phenomenon is the existence of AS-AMAZON in both RADB > and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy > of the object is the the correct one and populated with a number of > members entries. The RIPE one is empty, and not under control of Amazon. > > The existence of the AS-AMAZON object in the RIPE database might cause > some operators to inadvertently apply empty prefix-filters to EBGP > sessions which in turn causes various problems. > > It seems Amazon has no recourse to get the AS-AMAZON object removed from > the RIPE database; because the existence of that object in the RIPE > database does not violate any policies (as far as I know). But perhaps, > going forward, this community can do a little bit more to help prevent > similar situations from happening to others. > > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as applied by the RIPE Whois Server database engine do a decent > job of protecting/separating namespaces. 'Grandfathering' existing > short-named objects ensures that implementation of this solution > proposal causes minimal (if any) disruption to existing workflows. > > The RIPE database engine blocking creation of short-named AS-SETs might > help nudge the industry towards making hierarchical naming the norm. > > Related work > > Related work throughout the registry industry: IRRd version 4 forces new > AS-SET objects to be structured hierarchically: > https://github.com/irrdnet/irrd/issues/408 > > Kind regards, > > Job > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > -- Pierfrancesco Caci VP Network & Security Architecture - AS3491 Peering Coordinator Tel.: +39 0287 049 871 www.pccwglobal.com This message (and any attachments) may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy the message or delete it from your system immediately and notify the sender. PCCW Global cannot guarantee that this e-mail is secure, error-free and/or virus-free as e-mail messages could be intercepted, altered, corrupted, lost, delayed or become incomplete and/or infected by viruses in the course of their transmission. PCCW Global and the sender therefore do not accept liability for any loss or damage arising from any errors or omissions in the contents of this e-mail. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
I support this proposal. >It seems Amazon has no recourse to get the AS-AMAZON object removed from >the RIPE database; because the existence of that object in the RIPE >database does not violate any policies (as far as I know). Also ran into this issue and would like to see policy support to handle this kind of abuse. On Mon, Nov 14, 2022 at 3:08 PM denis walker via db-wg wrote: > Interesting timing. I was about to make the same suggestion but for a > different reason...accountability. Currently ANYONE can create a set > object in the RIPE Database. You can be completely anonymous, not a > member or LIR, hold no resources. All you need to do is create a ROLE, > MNTNER and set object. Anyone with an email can make a RIPE account and start creating objects in RIPE database. In other registries there are usually some safeguards on user / mntner object creation. Limiting database updates to only accounts associated with LIR sounds reasonable. Yang -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi all, On 14 Nov 2022, at 18:41, Job Snijders via db-wg wrote: [...] > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > I support this proposal. Kind regards, -- Teun Vink BIT | t...@bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
> Limiting database updates to only accounts associated with LIR sounds reasonable. I cannot support this unless it is limited to AS-SET and similar; i for example hand out IPv6 prefixes to endusers and that would be impossible if they are unable to create MNT/Person/ORGs. I support this in general for AS-SET which makes no sense to have access to unless you have an ASN, but the startup maintainer process should stay the same. Same for ORGs - to request ASNs the enduser needs an ORG and i as LIR should not have to create that or even have MNT-BY on it. — William Sent from my iPhone > On 16.11.2022, at 12:00, db-wg-requ...@ripe.net wrote: > > Send db-wg mailing list submissions to >db-wg@ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit >https://lists.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to >db-wg-requ...@ripe.net > > You can reach the person managing the list at >db-wg-ow...@ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Pierfrancesco Caci) > 2. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Yang Yu) > 3. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Teun Vink) > > > -- > > Message: 1 > Date: Wed, 16 Nov 2022 10:48:18 +0100 > From: Pierfrancesco Caci > To: Job Snijders via db-wg > Subject: Re: [db-wg] proposal: disallow creation of new >non-hierarchically named AS-SET objects > Message-ID: <20221116104818.25bba...@lavoro.tippete.net> > Content-Type: text/plain; charset=US-ASCII > > Hi > Speaking as be.ccafrique and uk.pccwg-uk I support Job's proposal. > > Pf > >> On Mon, 14 Nov 2022 17:41:16 + >> Job Snijders via db-wg wrote: >> >> CAUTION: External email. Do not click links or open attachments unless you >> recognize the sender and know the content is safe. >> >> Dear DB-WG, >> >> Speaking in individual capacity. >> >> In RFC 2622 section 5 specifies the naming convention for AS-SET >> objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 >> There basically are two styles: >> >>* "short" (example: AS-SNIJDERS) >>* "hierarchical" (example: AS15562:AS-SNIJDERS) >> >> Problem statement >> = >> In recent weeks a number of hypergiant cloud providers have faced the >> thorny effects of adversarial AS-SET object naming collisions between >> IRR databases. >> >> An example of this phenomenon is the existence of AS-AMAZON in both RADB >> and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy >> of the object is the the correct one and populated with a number of >> members entries. The RIPE one is empty, and not under control of Amazon. >> >> The existence of the AS-AMAZON object in the RIPE database might cause >> some operators to inadvertently apply empty prefix-filters to EBGP >> sessions which in turn causes various problems. >> >> It seems Amazon has no recourse to get the AS-AMAZON object removed from >> the RIPE database; because the existence of that object in the RIPE >> database does not violate any policies (as far as I know). But perhaps, >> going forward, this community can do a little bit more to help prevent >> similar situations from happening to others. >> >> Solution proposal >> = >> I think the solution is to - GOING FORWARD - disallow creation of new >> AS-SET objects which follow the 'short' naming style. >> >> The advantage of hierarchical naming is that the existing authorization >> rules as applied by the RIPE Whois Server database engine do a decent >> job of protecting/separating namespaces. 'Grandfathering' existing >> short-named objects ensures that implementation of this solution >> proposal causes minimal (if any) disruption to existing workflows. >> >> The RIPE database engine blocking creation of short-named AS-SETs might >> help nudge the industry towards making hierarchical naming the norm. >> >> Related work >> >> Related work throughout the registry industry: IRRd version 4 forces new >> AS-SET objects to be structured hierarchically: >> https://github.com/irrdnet/irrd/issues/
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On Nov 14, Job Snijders via db-wg wrote: > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. I support this. -- ciao, Marco signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
> > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. I support this solution On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg wrote: > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > In recent weeks a number of hypergiant cloud providers have faced the > thorny effects of adversarial AS-SET object naming collisions between > IRR databases. > > An example of this phenomenon is the existence of AS-AMAZON in both RADB > and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy > of the object is the the correct one and populated with a number of > members entries. The RIPE one is empty, and not under control of Amazon. > > The existence of the AS-AMAZON object in the RIPE database might cause > some operators to inadvertently apply empty prefix-filters to EBGP > sessions which in turn causes various problems. > > It seems Amazon has no recourse to get the AS-AMAZON object removed from > the RIPE database; because the existence of that object in the RIPE > database does not violate any policies (as far as I know). But perhaps, > going forward, this community can do a little bit more to help prevent > similar situations from happening to others. > > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as applied by the RIPE Whois Server database engine do a decent > job of protecting/separating namespaces. 'Grandfathering' existing > short-named objects ensures that implementation of this solution > proposal causes minimal (if any) disruption to existing workflows. > > The RIPE database engine blocking creation of short-named AS-SETs might > help nudge the industry towards making hierarchical naming the norm. > > Related work > > Related work throughout the registry industry: IRRd version 4 forces new > AS-SET objects to be structured hierarchically: > https://github.com/irrdnet/irrd/issues/408 > > Kind regards, > > Job > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Yang On Wed, 16 Nov 2022 at 11:06, Yang Yu wrote: > > I support this proposal. > > >It seems Amazon has no recourse to get the AS-AMAZON object removed from > >the RIPE database; because the existence of that object in the RIPE > >database does not violate any policies (as far as I know). > > Also ran into this issue and would like to see policy support to > handle this kind of abuse. > > On Mon, Nov 14, 2022 at 3:08 PM denis walker via db-wg wrote: > > Interesting timing. I was about to make the same suggestion but for a > > different reason...accountability. Currently ANYONE can create a set > > object in the RIPE Database. You can be completely anonymous, not a > > member or LIR, hold no resources. All you need to do is create a ROLE, > > MNTNER and set object. > > Anyone with an email can make a RIPE account and start creating > objects in RIPE database. In other registries there are usually some > safeguards on user / mntner object creation. Limiting database updates > to only accounts associated with LIR sounds reasonable. It is not quite as open as you think. Someone with nothing at all in the database can create a ROLE/MNTNER pair of objects. If these are not referenced by any operational data within 90 days they will be automatically deleted. So if you don't hold any internet resources, or more specifics, there is not much you can do in the database. The one exception to this is with the set objects. Anyone can create any of the set object types and reference their ROLE and MNTNER objects. This group of objects is then protected from any automated cleanup. The set object can be almost empty with only the mandatory, basic attributes. This does not only apply to the AS-SET but any of the set object types. I did ask a question and although the answer is implied from some of the comments made, from a database perspective, if you want the syntax rules changed someone needs to positively confirm or deny my question. Is there any legitimate reason for anyone to create a (short named) set object who does not hold an ASN resource? Only if the answer is no, can we enforce hierarchical naming. cheers denis co-chair DB-WG > > > Yang -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi, > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as applied by the RIPE Whois Server database engine do a decent > job of protecting/separating namespaces. 'Grandfathering' existing > short-named objects ensures that implementation of this solution > proposal causes minimal (if any) disruption to existing workflows. > > The RIPE database engine blocking creation of short-named AS-SETs might > help nudge the industry towards making hierarchical naming the norm. +1 This step will gradually improve the reliability of the database by preventing fake or misleasing short names to be created. It won’t solve existing problems, but that is something that we can look at later. First let’s implement this initial step to avoid the “dweilen met de kraan open” (*) scenario. Let’s close the tap first. Cheers, Sander (*) literally: mopping with the tap running -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
I support the idea as well. Kind Regards Stavros Konstantaras | Sr. Network Engineer | AMS-IX Frederiksplein 42, 1017 XN Amsterdam, The Netherlands M +31 (0) 620 89 51 04 ams-ix.net<http://ams-ix.net> From: db-wg on behalf of Emil Palm via db-wg Reply to: Emil Palm Date: Wednesday, 16 November 2022 at 13:07 To: "db-wg@ripe.net" Subject: Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects Solution proposal = I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. I support this solution On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg mailto:db-wg@ripe.net>> wrote: Dear DB-WG, Speaking in individual capacity. In RFC 2622 section 5 specifies the naming convention for AS-SET objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc2622%23section-5.1&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BJKdbzxhekJUUBiprtS6%2B00dLK%2BsuSxv%2FxaCnWUFFpc%3D&reserved=0> There basically are two styles: * "short" (example: AS-SNIJDERS) * "hierarchical" (example: AS15562:AS-SNIJDERS) Problem statement = In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to https://www.peeringdb.com/net/1418<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.peeringdb.com%2Fnet%2F1418&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TslaSp8LfMPD%2Ba1z2Aauez8LLnpqc6tEQGPl1r%2B%2FrMM%3D&reserved=0> the RADB copy of the object is the the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. Solution proposal = I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. Related work Related work throughout the registry industry: IRRd version 4 forces new AS-SET objects to be structured hierarchically: https://github.com/irrdnet/irrd/issues/408<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Firrdnet%2Firrd%2Fissues%2F408&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qoot5BPK95InIXGeQH9Hhp0ZcPM4I8dD95cpEE%2F9%2Bac%3D&reserved=0> Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fdb-wg&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OCpNwUO8IhZ%2BGoO%2FO%2FIVQ5Z0Nk5imw%2Bh8NG9rW4jljU%3D&reserved=0> -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
I support the proposal of moving away from the short naming. And I also agree with Gert on his remark .. about the pain for using RADB __ Regards, Erik Bais On 14/11/2022, 22:36, "db-wg on behalf of Gert Doering via db-wg" wrote: Hi, On Mon, Nov 14, 2022 at 05:41:16PM +, Job Snijders via db-wg wrote: > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. Support. (Though I think that ASes that use RADB as their primary documentation store deserve some amount of pain, but that's a different crusade) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Colleagues I know it is a weekend but there does seem to be some urgency on this matter. The chairs have been following this discussion and have a couple of questions before we move on. The chairs believe we can consider this to be a feature request for the RIPE Database and handle it through the Numbered Work Item (NWI) mechanism. This will address the matter much faster, unless anyone believes it should be based on a formal policy. To assist the RIPE NCC with their impact analysis can we be clear on how you want to change the syntax. My understanding is you want rules along these lines: -An AS-SET name must be hierarchical -There must be at least one colon (:) character in the name -The first element of the name must be an ASN -The second element of the name must be an AS-SET name starting with 'AS-' -Any further elements can be either ASNs or AS-SET names -Any other existing syntax rules that don't conflict with this change -These rules to only apply to creating new AS-SET objects -Existing non-hierarchical AS-SET objects can still be updated This discussion has focused on the AS-SET object and the authorisation problems they can cause. Should we make this change to all set object types? The benefits of doing this include: -Consistent rules applied to all set object types -Accountability for all (new) set objects in the database -Close the one exception where anyone can create a cluster of objects in the database and link them to a (operationally empty) set object to protect them from automated deletion -Objects can then only be created in the database by holders of Internet resources or more specifics If we apply it to all set objects then my original question still stands, is there any legitimate reason for someone to create any set object if they don't hold an ASN resource? If we can address these issues then the chairs can move this process on quickly at the start of next week. cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Denis, While I agree with your goal of trying to clean up the DB more generally, I think all of the more general issues have to be left for another time as I don't think that is appropriate for a NWI and should be done through the PDP. I think we should purely tackle the issue of as-sets for now as I think there is enough unanimity in it and it is small enough in scope that it makes sense to do it through the NWI process. (I think the main person raising any objections was myself) I have a question though, do we know if all current hierarchical as-sets were authorized by the ASN holder when they were created? I wrote the above question and then I looked into it, but as it is a bit off-topic and some other things that popped up, I decided to put it in a separate thread. The TL;DR of it though is that, I am pretty sure that the answer is no. There are at least some that weren't authorized. Another issue is how to deal with the short as-sets that already exist and are potentially causing issues. Just as an example, I can see that there is currently an AS-AMAZON in the RIPE DB that I assume was not authorized by Amazon and looks to not have any good reason to exist (no members). I think having a way for trademark holders and well-known entities to deal with dubious as-sets would be good. Maybe just during a limited time period to prevent any future uncertainty. -Cynthia On Sat, Nov 19, 2022 at 4:01 PM denis walker via db-wg wrote: > > Colleagues > > I know it is a weekend but there does seem to be some urgency on this > matter. The chairs have been following this discussion and have a > couple of questions before we move on. > > The chairs believe we can consider this to be a feature request for > the RIPE Database and handle it through the Numbered Work Item (NWI) > mechanism. This will address the matter much faster, unless anyone > believes it should be based on a formal policy. > > To assist the RIPE NCC with their impact analysis can we be clear on > how you want to change the syntax. My understanding is you want rules > along these lines: > > -An AS-SET name must be hierarchical > -There must be at least one colon (:) character in the name > -The first element of the name must be an ASN > -The second element of the name must be an AS-SET name starting with 'AS-' > -Any further elements can be either ASNs or AS-SET names > -Any other existing syntax rules that don't conflict with this change > -These rules to only apply to creating new AS-SET objects > -Existing non-hierarchical AS-SET objects can still be updated > > This discussion has focused on the AS-SET object and the authorisation > problems they can cause. Should we make this change to all set object > types? The benefits of doing this include: > > -Consistent rules applied to all set object types > -Accountability for all (new) set objects in the database > -Close the one exception where anyone can create a cluster of objects > in the database and link them to a (operationally empty) set object to > protect them from automated deletion > -Objects can then only be created in the database by holders of > Internet resources or more specifics > > If we apply it to all set objects then my original question still > stands, is there any legitimate reason for someone to create any set > object if they don't hold an ASN resource? > > If we can address these issues then the chairs can move this process > on quickly at the start of next week. > > cheers > denis > co-chair DB-WG > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Dear Denis, others, (still talking in person capacity) On Sat, Nov 19, 2022 at 04:00:23PM +0100, denis walker wrote: > To assist the RIPE NCC with their impact analysis can we be clear on > how you want to change the syntax. My understanding is you want rules > along these lines: > > -An AS-SET name must be hierarchical > -There must be at least one colon (:) character in the name > -The first element of the name must be an ASN Yes to the above. > -The second element of the name must be an AS-SET name starting with 'AS-' The rules for what constitute valid AS-SET names are specified in RFC2622 section 5: https://www.rfc-editor.org/rfc/rfc2622#section-5 """ Set names can also be hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ":". At least one component of such a name must be an actual set name (i.e. start with one of the prefixes above). All the set name components of an hierarchical name has to be of the same type. For example, the following names are valid: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS- EXCEPTIONS:RS-BOGUS. """ I'd argue that the rules for what constitute valid hierarchical names should not be changed; so the second component of the name doesn't need to start with 'AS-'. > -Any further elements can be either ASNs or AS-SET names > -Any other existing syntax rules that don't conflict with this change > -These rules to only apply to creating new AS-SET objects > -Existing non-hierarchical AS-SET objects can still be updated Aye. > This discussion has focused on the AS-SET object and the authorisation > problems they can cause. Should we make this change to all set object > types? To avoid scope creep I'd exclusively focus on AS-SET objects for now, because that's the object type for which operational issues were reported in recent weeks. Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Job Snijders via db-wg wrote on 20/11/2022 13:07: I'd argue that the rules for what constitute valid hierarchical names should not be changed; so the second component of the name doesn't need to start with 'AS-'. you mean "does need to start with 'AS-'"? I don't see how rfc2622 allows naked terms, or how that would allow rpsl consumers to determine what type of set a specific named item was. Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On Sun, Nov 20, 2022 at 05:52:12PM +, Nick Hilliard wrote: > Job Snijders via db-wg wrote on 20/11/2022 13:07: > > I'd argue that the rules for what constitute valid hierarchical names > > should not be changed; so the second component of the name doesn't need > > to start with 'AS-'. > > you mean "does need to start with 'AS-'"? I don't see how rfc2622 allows > naked terms, or how that would allow rpsl consumers to determine what type > of set a specific named item was. Errr... yes, thank you for the cluebat, Nick. When I sent the email I thought perhaps "AS15562:AS15562:AS-THING" might also be valid; but upon further reflection Section 5 of RFC 2622 also specifies at least 1 component needs to have the 'AS-' prefix (because, as you suggest, otherwise one can't infer the set type); which would mean that you can't create AS15562:AS15562:AS-THING (because you can't create AS15562:AS15562 against which it would be authorized). Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Colleagues The chairs discussed this issue over the weekend and agreed that we see a consensus to change the syntax rules for AS-SET object names in the RIPE Database. We also agreed that we believe this feature request can be managed through the Numbered Work Item process. We therefore ask the RIPE NCC to document 'NWI-19 Change to AS-SET object naming rules'. The problem statement is as specified by Job: Problem statement = In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy of the object is the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. The solution proposal was also specified by Job with some clarification on the required syntax changes. Solution proposal = I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. The new syntax rules will follow these lines: -An AS-SET name must be hierarchical -There must be at least one colon (:) character in the name -The first element of the name must be an ASN -The second element of the name must be an AS-SET name starting with 'AS-' -Any further elements can be either ASNs or AS-SET names -Any other existing syntax rules that don't conflict with this change -These rules to only apply to creating new AS-SET objects -Existing non-hierarchical AS-SET objects can still be updated One question to the community...do we want to disallow authorisation of new AS-SET objects from ASNs in RIPE-NONAUTH? The chairs would like the RIPE NCC to prepare an impact analysis. cheers denis and William co-chairs DB-WG On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg wrote: > > Dear DB-WG, > > Speaking in individual capacity. > > In RFC 2622 section 5 specifies the naming convention for AS-SET > objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 > There basically are two styles: > > * "short" (example: AS-SNIJDERS) > * "hierarchical" (example: AS15562:AS-SNIJDERS) > > Problem statement > = > In recent weeks a number of hypergiant cloud providers have faced the > thorny effects of adversarial AS-SET object naming collisions between > IRR databases. > > An example of this phenomenon is the existence of AS-AMAZON in both RADB > and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy > of the object is the the correct one and populated with a number of > members entries. The RIPE one is empty, and not under control of Amazon. > > The existence of the AS-AMAZON object in the RIPE database might cause > some operators to inadvertently apply empty prefix-filters to EBGP > sessions which in turn causes various problems. > > It seems Amazon has no recourse to get the AS-AMAZON object removed from > the RIPE database; because the existence of that object in the RIPE > database does not violate any policies (as far as I know). But perhaps, > going forward, this community can do a little bit more to help prevent > similar situations from happening to others. > > Solution proposal > = > I think the solution is to - GOING FORWARD - disallow creation of new > AS-SET objects which follow the 'short' naming style. > > The advantage of hierarchical naming is that the existing authorization > rules as applied by the RIPE Whois Server database engine do a decent > job of protecting/separating namespaces. 'Grandfathering' existing > short-named objects ensures that implementation of this solution > proposal
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Denis, Colleagues, > On 21 Nov 2022, at 13:54, denis walker via db-wg wrote: > > Colleagues > > The chairs discussed this issue over the weekend and agreed that we > see a consensus to change the syntax rules for AS-SET object names in > the RIPE Database. We also agreed that we believe this feature request > can be managed through the Numbered Work Item process. We therefore > ask the RIPE NCC to document 'NWI-19 Change to AS-SET object naming > rules'. I've updated the NWI page: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items This change will go live shortly after an internal review. > > The chairs would like the RIPE NCC to prepare an impact analysis. > The DB team will prepare an impact analysis now. Regards Ed Shryane RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Denis, Colleagues, Following is the impact analysis of NWI-19. Low impact on Whois. * The DB team will disallow the creation of AS-SET objects which follow the 'short' naming style (i.e. starting with 'AS-' and without a colon). * Only AS-SET objects which follow the 'hierarchical' naming style (i.e. including one or more colons) can be created. * Existing AS-SET objects are not affected and can be updated or deleted as before. However, if an existing AS-SET object with short naming style is deleted, it cannot be re-created with the same name. No impact on the LIR Portal or internal registry software. No impact on the RPKI service. Client software needs to be checked so that AS-SET objects with 'short' naming style will not be created in the RIPE database. It will still be possible to create AS-SET objects with a 'short' naming style in other RIR databases and other IRR databases such as RADB. Clients may not be able to use the same name in the RIPE database as in other databases. Implementing and deploying this change will take some time. In the meantime, there may be an increase in AS-SET object creation with a 'short' naming style. Regards Ed Shryane RIPE NCC > On 21 Nov 2022, at 15:00, Edward Shryane via db-wg wrote: > > Hi Denis, Colleagues, > >> On 21 Nov 2022, at 13:54, denis walker via db-wg wrote: >> >> Colleagues >> >> The chairs discussed this issue over the weekend and agreed that we >> see a consensus to change the syntax rules for AS-SET object names in >> the RIPE Database. We also agreed that we believe this feature request >> can be managed through the Numbered Work Item process. We therefore >> ask the RIPE NCC to document 'NWI-19 Change to AS-SET object naming >> rules'. > > I've updated the NWI page: > https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > This change will go live shortly after an internal review. > >> >> The chairs would like the RIPE NCC to prepare an impact analysis. >> > > The DB team will prepare an impact analysis now. > > Regards > Ed Shryane > RIPE NCC > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Colleagues On Mon, 21 Nov 2022 at 13:54, denis walker wrote: > > One question to the community...do we want to disallow authorisation > of new AS-SET objects from ASNs in RIPE-NONAUTH? > Any thoughts on this? There are 2128 AUT-NUM objects with source RIPE-NONAUTH. Do we want these to be able to authorise the creation of hierarchical AS-SET objects when we don't know who maintains the AUT-NUM objects? Another suggestion. There are 1361 short named AS-SET objects that don't have any 'members' or 'mbrs-by-ref' attributes. In other words they are operationally empty objects. (This includes AS-AMAZON.) We could introduce an automated cleanup process similar to the way we remove unreferenced PERSON and ROLE objects. If an AS-SET object remains operationally empty for 90 days it will be automatically deleted. This would include hierarchical objects. The hierarchical objects can easily be recreated by the ASN maintainers at any time if they are needed later. This gets around the problem of who has the authority to remove rogue objects. It becomes a database cleanup operation. Any thoughts? cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi, On Tue, Nov 22, 2022 at 08:00:47PM +0100, denis walker via db-wg wrote: > Another suggestion. There are 1361 short named AS-SET objects that > don't have any 'members' or 'mbrs-by-ref' attributes. In other words > they are operationally empty objects. (This includes AS-AMAZON.) We > could introduce an automated cleanup process similar to the way we > remove unreferenced PERSON and ROLE objects. If an AS-SET object > remains operationally empty for 90 days it will be automatically > deleted. This would include hierarchical objects. The hierarchical > objects can easily be recreated by the ASN maintainers at any time if > they are needed later. This gets around the problem of who has the > authority to remove rogue objects. It becomes a database cleanup > operation. Any thoughts? I would support that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
denis walker via db-wg wrote on 22/11/2022 19:00: Any thoughts on this? There are 2128 AUT-NUM objects with source RIPE-NONAUTH. Do we want these to be able to authorise the creation of hierarchical AS-SET objects when we don't know who maintains the AUT-NUM objects? I don't see a particular reason to prevent holders of existing NON-AUTH ASNs from defining a hierarchical AS-SET object associated with their ASN. The as-set object would be no more or less authoritative than the aut-num object. Another suggestion. There are 1361 short named AS-SET objects that don't have any 'members' or 'mbrs-by-ref' attributes. In other words they are operationally empty objects. (This includes AS-AMAZON.) We could introduce an automated cleanup process similar to the way we remove unreferenced PERSON and ROLE objects. If an AS-SET object remains operationally empty for 90 days it will be automatically deleted. This would include hierarchical objects. The hierarchical objects can easily be recreated by the ASN maintainers at any time if they are needed later. This gets around the problem of who has the authority to remove rogue objects. It becomes a database cleanup operation. Any thoughts? Careful with this, e.g. AS-NULL. There are some situations where referencing an empty set can be useful in RPSL. Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On Tue, Nov 22, 2022 at 07:11:17PM +, Nick Hilliard via db-wg wrote: > Careful with this, e.g. AS-NULL. There are some situations where > referencing an empty set can be useful in RPSL. For 'AS-NULL' back history see this thread: https://www.ripe.net/ripe/mail/archives/db-wg/2014-December/thread.html#4461 Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Nick On Tue, 22 Nov 2022 at 20:11, Nick Hilliard wrote: > > denis walker via db-wg wrote on 22/11/2022 19:00: > > Any thoughts on this? There are 2128 AUT-NUM objects with source > > RIPE-NONAUTH. Do we want these to be able to authorise the creation of > > hierarchical AS-SET objects when we don't know who maintains the > > AUT-NUM objects? > > I don't see a particular reason to prevent holders of existing NON-AUTH > ASNs from defining a hierarchical AS-SET object associated with their > ASN. The as-set object would be no more or less authoritative than the > aut-num object. Then another option could be to only allow such objects to also have the source NON-AUTH > > > Another suggestion. There are 1361 short named AS-SET objects that > > don't have any 'members' or 'mbrs-by-ref' attributes. In other words > > they are operationally empty objects. (This includes AS-AMAZON.) We > > could introduce an automated cleanup process similar to the way we > > remove unreferenced PERSON and ROLE objects. If an AS-SET object > > remains operationally empty for 90 days it will be automatically > > deleted. This would include hierarchical objects. The hierarchical > > objects can easily be recreated by the ASN maintainers at any time if > > they are needed later. This gets around the problem of who has the > > authority to remove rogue objects. It becomes a database cleanup > > operation. Any thoughts? > > Careful with this, e.g. AS-NULL. There are some situations where > referencing an empty set can be useful in RPSL. We have a mechanism to protect specified PERSON and ROLE objects from automatic deletion. We could also protect AS-NULL from such automatic deletion. cheers denis co-chair DB-WG > > Nick > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On 22 Nov 2022, at 19:11, Nick Hilliard via db-wg wrote: Careful with this, e.g. AS-NULL. There are some situations where referencing an empty set can be useful in RPSL. I'm not sure whether Nick meant this as a single exception, or rather as an example of a category of useful empty sets. I can well imagine that most "operationally empty objects" (as Denis put it) are either useless or troublesome. As Nick says, "Careful with this." Niall -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Niall On Wed, 23 Nov 2022 at 00:30, Niall O'Reilly via db-wg wrote: > > On 22 Nov 2022, at 19:11, Nick Hilliard via db-wg wrote: > > > Careful with this, e.g. AS-NULL. There are some situations where > > referencing an empty set can be useful in RPSL. > > I'm not sure whether Nick meant this as a single exception, > or rather as an example of a category of useful empty sets. One empty set is the same as any other empty set. We only need one clearly defined and easily recognisable empty set and we have that, AS-NULL. If I create an empty set, AS-WALKER it doesn't do anything that AS-NULL can't do. But AS-WALKER isn't instantly recognisable as an empty set. You have to query it to see that. If we have 100 empty sets in the database, including AS-NULL, that are all being used for valid reasons, 99 of them are redundant, duplicated objects and should be deleted...unless someone can tell me the value of a duplicated empty set. cheers denis co-chair DB-WG > > I can well imagine that most "operationally empty objects" > (as Denis put it) are either useless or troublesome. > > As Nick says, "Careful with this." > > Niall > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On 23 Nov 2022, at 16:56, denis walker wrote: > One empty set is the same as any other empty set. We only need one > clearly defined and easily recognisable empty set and we have that, > AS-NULL. If I create an empty set, AS-WALKER it doesn't do anything > that AS-NULL can't do. Sure. What I have in mind is AS-NIALLSPECIAL, which I populate with a list of AS numbers which I want to advertise to let others know that these are to be handled in some special way, unlike those in AS-NIALLNORMAL. According to operational circumstances, there might be periods, even long ones, with nothing special going on; AS-NIALLSPECIAL would then be empty, but only for as long as this continued to be the case. Something I don't know is whether this hypothetical scenario is operationally realistic or simply a product of my certainly ill-informed, and perhaps over-active, imagination. If it were the latter, then a special case just for AS-NULL would be sufficient. Otherwise, inferring equivalence to AS-NULL of any set which happens to have been empty for some specified period seems unsafe. I'll be happy to learn that I'm imagining trouble that can never arise. Niall -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Denis, I support the idea of having empty AS-SETs deleted automatically and keeping only AS-NULL in the DB. @Edward Shryane question to the DB team: would it be possible to have some functionality in the LIR portal that converts the short-named AS-SETs to the hierarchical ones with a click of a button? That would help people transition much easier and faster to the hierarchical AS-SETs. Perhaps a button that can be triggered by user and 1) creates a new hierarchical AS-SET 2) copies all elements from old AS-SET to the new one 3) Deletes the old AS-SET 4) Updates the corresponding import/export rules. Kind Regards Stavros On 23/11/2022, 17:58, "db-wg on behalf of denis walker via db-wg" wrote: Hi Niall On Wed, 23 Nov 2022 at 00:30, Niall O'Reilly via db-wg wrote: > > On 22 Nov 2022, at 19:11, Nick Hilliard via db-wg wrote: > > > Careful with this, e.g. AS-NULL. There are some situations where > > referencing an empty set can be useful in RPSL. > > I'm not sure whether Nick meant this as a single exception, > or rather as an example of a category of useful empty sets. One empty set is the same as any other empty set. We only need one clearly defined and easily recognisable empty set and we have that, AS-NULL. If I create an empty set, AS-WALKER it doesn't do anything that AS-NULL can't do. But AS-WALKER isn't instantly recognisable as an empty set. You have to query it to see that. If we have 100 empty sets in the database, including AS-NULL, that are all being used for valid reasons, 99 of them are redundant, duplicated objects and should be deleted...unless someone can tell me the value of a duplicated empty set. cheers denis co-chair DB-WG > > I can well imagine that most "operationally empty objects" > (as Denis put it) are either useless or troublesome. > > As Nick says, "Careful with this." > > Niall > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fdb-wg&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C3c1aa8fca7914446d88408dacd73e9da%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638048194975456541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tk2suM5OkDIBLif6XXQnKk05lSl0O3ua37Lc5ZtWPdU%3D&reserved=0 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fdb-wg&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C3c1aa8fca7914446d88408dacd73e9da%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638048194975456541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tk2suM5OkDIBLif6XXQnKk05lSl0O3ua37Lc5ZtWPdU%3D&reserved=0 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Niall O'Reilly via db-wg wrote on 23/11/2022 18:17: What I have in mind is AS-NIALLSPECIAL, which I populate with a list of AS numbers which I want to advertise to let others know that these are to be handled in some special way, unlike those in AS-NIALLNORMAL. According to operational circumstances, there might be periods, even long ones, with nothing special going on; AS-NIALLSPECIAL would then be empty, but only for as long as this continued to be the case. this ^^^ is one of the failure modes. It would not be safe to assume that empty as-sets named in RPSL policies are unused. It would be less unsafe to assume that unreferenced as-sets are unused. A reasonable middle ground might be - after the proposed new unqualified as-set block has been implemented - to check out all unreferenced as-sets older than a specific period of time and flag those for deletion. It would also be worthwhile inspecting rpsl in other IRRDBs to see if there are any references. The reason for this is that lots of people use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g. RADB, NTT, etc. So if you have RPSL in another IRRDB and this references an empty as-set in the RIPE IRRDB, that definition may be picked up in preference to other as-set definitions. I.e. by removing an as-set definition in the RIPE IRRDB, it could unexpectedly influence routing policies elsewhere. These are corner cases, but they should show why some care will be needed to figure out whether deleting these objects is a good idea. Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Based on what has been said in this thread so far, I cannot support automatic clean-up of AS-SETs even if they are empty. There is simply way too little to be gained compared to the issues it could cause. Also if there is someone who maliciously created a short AS-SET, they could simply just add an ASN into it to exclude it from automatic clean-up. It might be complicated but I really think the better way to go about it is to handle each of the individual cases in which this is an issue as I suspect that there are not many and they are probably pretty clear cases. I know of AS-AMAZON but are we aware of any other potentially problematic AS-SETs in the RIPE DB currently? Also I don't even know if it is currently causing issues for amazon, but maybe Fredrik could answer that? -Cynthia On Thu, Nov 24, 2022 at 4:14 PM Nick Hilliard via db-wg wrote: > > Niall O'Reilly via db-wg wrote on 23/11/2022 18:17: > > What I have in mind is AS-NIALLSPECIAL, which I populate with a list of > > AS numbers which I want to advertise to let others know that these > > are to be handled in some special way, unlike those in AS-NIALLNORMAL. > > > > According to operational circumstances, there might be periods, even > > long ones, with nothing special going on; AS-NIALLSPECIAL would then be > > empty, but only for as long as this continued to be the case. > > this ^^^ is one of the failure modes. > > It would not be safe to assume that empty as-sets named in RPSL policies > are unused. It would be less unsafe to assume that unreferenced as-sets > are unused. A reasonable middle ground might be - after the proposed > new unqualified as-set block has been implemented - to check out all > unreferenced as-sets older than a specific period of time and flag those > for deletion. > > It would also be worthwhile inspecting rpsl in other IRRDBs to see if > there are any references. The reason for this is that lots of people > use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g. > RADB, NTT, etc. > > So if you have RPSL in another IRRDB and this references an empty as-set > in the RIPE IRRDB, that definition may be picked up in preference to > other as-set definitions. I.e. by removing an as-set definition in the > RIPE IRRDB, it could unexpectedly influence routing policies elsewhere. > > These are corner cases, but they should show why some care will be > needed to figure out whether deleting these objects is a good idea. > > Nick > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
I have just been informed that AS-AMAZON in the RIPE DB is indeed causing issues for Amazon currently, so please disregard that question. -Cynthia On Fri, Nov 25, 2022 at 12:20 AM Cynthia Revström wrote: > > Based on what has been said in this thread so far, I cannot support > automatic clean-up of AS-SETs even if they are empty. > There is simply way too little to be gained compared to the issues it > could cause. > Also if there is someone who maliciously created a short AS-SET, they > could simply just add an ASN into it to exclude it from automatic > clean-up. > > It might be complicated but I really think the better way to go about > it is to handle each of the individual cases in which this is an issue > as I suspect that there are not many and they are probably pretty > clear cases. > I know of AS-AMAZON but are we aware of any other potentially > problematic AS-SETs in the RIPE DB currently? > Also I don't even know if it is currently causing issues for amazon, > but maybe Fredrik could answer that? > > -Cynthia > > On Thu, Nov 24, 2022 at 4:14 PM Nick Hilliard via db-wg > wrote: > > > > Niall O'Reilly via db-wg wrote on 23/11/2022 18:17: > > > What I have in mind is AS-NIALLSPECIAL, which I populate with a list of > > > AS numbers which I want to advertise to let others know that these > > > are to be handled in some special way, unlike those in AS-NIALLNORMAL. > > > > > > According to operational circumstances, there might be periods, even > > > long ones, with nothing special going on; AS-NIALLSPECIAL would then be > > > empty, but only for as long as this continued to be the case. > > > > this ^^^ is one of the failure modes. > > > > It would not be safe to assume that empty as-sets named in RPSL policies > > are unused. It would be less unsafe to assume that unreferenced as-sets > > are unused. A reasonable middle ground might be - after the proposed > > new unqualified as-set block has been implemented - to check out all > > unreferenced as-sets older than a specific period of time and flag those > > for deletion. > > > > It would also be worthwhile inspecting rpsl in other IRRDBs to see if > > there are any references. The reason for this is that lots of people > > use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g. > > RADB, NTT, etc. > > > > So if you have RPSL in another IRRDB and this references an empty as-set > > in the RIPE IRRDB, that definition may be picked up in preference to > > other as-set definitions. I.e. by removing an as-set definition in the > > RIPE IRRDB, it could unexpectedly influence routing policies elsewhere. > > > > These are corner cases, but they should show why some care will be > > needed to figure out whether deleting these objects is a good idea. > > > > Nick > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or change > > your subscription options, please visit: > > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Hi Cynthia "Problems" is a wide definition. We know that some ISPs have built filters using the malicious AS-AMAZON record in RIPE DB, instead of the real record in RADB. This generates an empty prefix-list, and therefor completely filtered the inbound routes from us to that ISP. However, luckily in all of our cases, there has been enough capacity on upstream links and therefor all traffic rerouted without end-user really noticing, however the path is probably not the most optimal, diminishing the value of peering (not good). And since this is affecting our inbound-traffic, we have to spend significant time vetting all of our interconnects currently to look for suspicious drops in inbound-traffic, based upon heuristic models. The blatant trolling in the RIPE db has forced us to craft alarms based upon this peculiar behavior, where inbound flows moves around without any sensible explanation (such as linkdown, port-errors, etc etc). We have hundreds of thousands of BGP-sessions in the world so this is no small task. I would like to point out though, that despite all of this, I think the other affected companies, have had bigger outages, and I guess we are just waiting for when that day comes to us, which is also why we are fairly invested in fixing this. In almost all cases "we" (as in the routing security community) have been able to found the original creators of said objects (seems to all come from a tunnelbroker discord server) and pulling the historic chatlogs when it was created, it was all for fun & games, and most creators decided to just delete them when people from the community reached out and explained that the risk involved in this behavior, is probably larger than what most people believe, given it's also potentially squatting on trademarks. /FK On 2022-11-25, 00:47, "Cynthia Revström" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I have just been informed that AS-AMAZON in the RIPE DB is indeed causing issues for Amazon currently, so please disregard that question. -Cynthia On Fri, Nov 25, 2022 at 12:20 AM Cynthia Revström wrote: > > Based on what has been said in this thread so far, I cannot support > automatic clean-up of AS-SETs even if they are empty. > There is simply way too little to be gained compared to the issues it > could cause. > Also if there is someone who maliciously created a short AS-SET, they > could simply just add an ASN into it to exclude it from automatic > clean-up. > > It might be complicated but I really think the better way to go about > it is to handle each of the individual cases in which this is an issue > as I suspect that there are not many and they are probably pretty > clear cases. > I know of AS-AMAZON but are we aware of any other potentially > problematic AS-SETs in the RIPE DB currently? > Also I don't even know if it is currently causing issues for amazon, > but maybe Fredrik could answer that? > > -Cynthia > > On Thu, Nov 24, 2022 at 4:14 PM Nick Hilliard via db-wg wrote: > > > > Niall O'Reilly via db-wg wrote on 23/11/2022 18:17: > > > What I have in mind is AS-NIALLSPECIAL, which I populate with a list of > > > AS numbers which I want to advertise to let others know that these > > > are to be handled in some special way, unlike those in AS-NIALLNORMAL. > > > > > > According to operational circumstances, there might be periods, even > > > long ones, with nothing special going on; AS-NIALLSPECIAL would then be > > > empty, but only for as long as this continued to be the case. > > > > this ^^^ is one of the failure modes. > > > > It would not be safe to assume that empty as-sets named in RPSL policies > > are unused. It would be less unsafe to assume that unreferenced as-sets > > are unused. A reasonable middle ground might be - after the proposed > > new unqualified as-set block has been implemented - to check out all > > unreferenced as-sets older than a specific period of time and flag those > > for deletion. > > > > It would also be worthwhile inspecting rpsl in other IRRDBs to see if > > there are any references. The reason for this is that lots of people > > use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g. > > RADB, NTT, etc. > > > > So if you have RPSL in another IRRDB and this references an empty as-set > > in the RIPE IRRDB, that definition may be picked up in preference to > > other as-set definitions. I.e. by removing an as-set definition in the > > RIPE IRRDB, it could unexpectedly influence routing policies elsewhere. > > > > These are corner cases, but they should show why some care will be > > needed to figure out w
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Colleagues Any thoughts on these 'RIPE-NONAUTH' objects? On Tue, 22 Nov 2022 at 21:17, denis walker wrote: > > Hi Nick > > On Tue, 22 Nov 2022 at 20:11, Nick Hilliard wrote: > > > > denis walker via db-wg wrote on 22/11/2022 19:00: > > > Any thoughts on this? There are 2128 AUT-NUM objects with source > > > RIPE-NONAUTH. Do we want these to be able to authorise the creation of > > > hierarchical AS-SET objects when we don't know who maintains the > > > AUT-NUM objects? > > > > I don't see a particular reason to prevent holders of existing NON-AUTH > > ASNs from defining a hierarchical AS-SET object associated with their > > ASN. The as-set object would be no more or less authoritative than the > > aut-num object. > > Then another option could be to only allow such objects to also have > the source NONAUTH > > > These ASNs have 'source: RIPE-NONAUTH' because we don't know who created the AUT-NUM objects or who now maintains them in the RIPE Database. They were created when anyone could create an AUT-NUM object in the RIPE Database for non RIPE issued ASNs. Authorisation was bypassed to allow them to be created. The 'NONAUTH' tag makes it clear they are not authoritative. Consumers of this data can then make an informed decision about whether or not they trust these objects. If we allow these objects to authorise hierarchical AS-SET objects with 'source: RIPE' we have in effect turned non authoritative data back into authoritative data. If we give the related AS-SET objects 'source: RIPE-NONAUTH' we make it clear that these objects are also not authoritative. Consumers of the data should make their own informed decisions about the content of these AS-SET objects. cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
denis walker wrote on 29/11/2022 13:00: If we allow these objects to authorise hierarchical AS-SET objects with 'source: RIPE' we have in effect turned non authoritative data back into authoritative data. If we give the related AS-SET objects 'source: RIPE-NONAUTH' we make it clear that these objects are also not authoritative. Consumers of the data should make their own informed decisions about the content of these AS-SET objects. if ASn has source: RIPE-NONAUTH, then the corresponding as-set would be ASn:FOOBAR, so this would also need to be RIPE-NONAUTH. I don't see an issue with RIPE-NONAUTH aut-nums being able to create scoped RIPE-NONAUTH as-sets. This also gives a clear route for garbage collection: if the aut-num becomes invalid, then the corresponding as-sets also become invalid. IIRC it's not possible to create new aut-num objects with source: RIPE-NONAUTH? Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
I agree with Nick. However there are currently as-set objects in RIPE based on aut-num objects in RIPE-NONAUTH. I think it might be worth considering if these should be cleaned up. I posted about this about a week ago in a separate thread on db-wg. -Cynthia On Tue, Nov 29, 2022 at 7:30 PM Nick Hilliard via db-wg wrote: > > denis walker wrote on 29/11/2022 13:00: > > If we allow these objects to authorise hierarchical AS-SET objects with > > 'source: RIPE' we have in effect turned non authoritative data back into > > authoritative data. If we give the related AS-SET objects 'source: > > RIPE-NONAUTH' we make it clear that these objects are also not > > authoritative. Consumers of the data should make their own informed > > decisions about the content of these AS-SET objects. > if ASn has source: RIPE-NONAUTH, then the corresponding as-set would > be ASn:FOOBAR, so this would also need to be RIPE-NONAUTH. > > I don't see an issue with RIPE-NONAUTH aut-nums being able to create > scoped RIPE-NONAUTH as-sets. This also gives a clear route for garbage > collection: if the aut-num becomes invalid, then the corresponding > as-sets also become invalid. > > IIRC it's not possible to create new aut-num objects with source: > RIPE-NONAUTH? > > Nick > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Cynthia Revström wrote on 29/11/2022 18:56: I agree with Nick. However there are currently as-set objects in RIPE based on aut-num objects in RIPE-NONAUTH. I think it might be worth considering if these should be cleaned up. I posted about this about a week ago in a separate thread on db-wg. right, yes, you're correct. I've included a list below. The RIPE NCC can't stand over the authenticity of these objects because the AS in question isn't a RIPE-authenticated ASN. So RIPE-NONAUTH would be an appropriate place for them. Changing this should not be service affecting, because the AS in question is already RIPE-NONAUTH. Having said that, "should not" is not the same as "will not". Some of these objects are stale. Some of them are legacy resources, but can be subject to the same approach as defined in ripe-731. Do we need a policy change to move these, e.g. similar to ripe-731, or simply including them in the scope of ripe-731? Nick -- AS702:AS-AT-CUSTOMER AS702:AS-BE-CUSTOMER AS702:AS-CH-CUSTOMER AS702:AS-CUSTOMER AS702:AS-CZ-CUSTOMER AS702:AS-DE-CUSTOMER AS702:AS-DK-CUSTOMER AS702:AS-ES-CUSTOMER AS702:AS-EURO-CUSTOMER AS702:AS-FI-CUSTOMER AS702:AS-FR-CUSTOMER AS702:AS-GR-CUSTOMER AS702:AS-HU-CUSTOMER AS702:AS-IE-CUSTOMER AS702:AS-IT-CUSTOMER AS702:AS-NL-CUSTOMER AS702:AS-NO-CUSTOMER AS702:AS-PT-CUSTOMER AS702:AS-SE-CUSTOMER AS702:AS-UK-CUSTOMER AS4004:AS-TO-AIX AS9327:AS-HOPCOUNT AS12041:AS-AFILIAS AS12041:AS-PEERS AS12041:AS-SET AS12041:AS-SET:AS12287 AS12041:AS-SET:AS13714 AS12041:AS-SET:AS13901 AS12041:AS-SET:AS40490 AS12041:AS-TRANSIT AS12287:AS-AFILIAS AS13657:AS-EGATE AS13657:AS-PEERS AS13657:AS-TRANSIT AS13714:AS-AFILIAS AS13810:AS-AFILIAS AS13901:AS-AFILIAS AS17400:AS-CUSTOMERS AS19551:AS-GLOBAL AS20375:AS-CUSTOMERS AS21003:AS-LTT AS24115:AS-GENEVA AS24115:AS-PARIS AS24115:AS-ZURICH AS26754:AS-PEERS AS36692:AS-UMBRELLA AS36925:AS-MEDI AS36925:AS-PROVIDERS AS36997:AS-TRANSIT AS37002:AS-ALL AS37012:AS-ALL AS37133:AS-327707 AS37148:AS-GLOBACOM AS37155:AS-PROVIDERS AS37183:AS-SET AS37284:AS-ALJEEL AS37314:AS-CUSTOMERS AS37314:AS-CUSTOMERS:AS328074 AS37314:AS-JINX AS37314:AS-NAPAFRICA AS37314:AS-NEOTEL AS37314:AS-SEACOM AS37366:AS-PROVIDERS AS37558:AS-LITC AS38193:AS-PEERS-RIPE AS396071:AS-COMPLETE AS396071:AS-CUSTOMERS AS40490:AS-AFILIAS AS55293:AS-A2HOSTING AS58580:AS-ALL AS62512:AS-CUSTOMER AS135164:AS-PEERS AS135183:AS-INSTALINKS AS327717:AS-26754 AS327717:AS-26754:AS-328015 AS327717:AS-328015 AS327717:AS-328084 AS327938:AS-PEERS -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On Tue, 29 Nov 2022, 19:56 Cynthia Revström, wrote: > I agree with Nick. > However there are currently as-set objects in RIPE based on aut-num > objects in RIPE-NONAUTH. > I think it might be worth considering if these should be cleaned up. > As an intermediate step we could set the source to RIPE-NONAUTH for any existing AS-SET objects related to ASNs with that source. Cheers denis Co-chair DB-WG I posted about this about a week ago in a separate thread on db-wg. > > -Cynthia > > On Tue, Nov 29, 2022 at 7:30 PM Nick Hilliard via db-wg > wrote: > > > > denis walker wrote on 29/11/2022 13:00: > > > If we allow these objects to authorise hierarchical AS-SET objects with > > > 'source: RIPE' we have in effect turned non authoritative data back > into > > > authoritative data. If we give the related AS-SET objects 'source: > > > RIPE-NONAUTH' we make it clear that these objects are also not > > > authoritative. Consumers of the data should make their own informed > > > decisions about the content of these AS-SET objects. > > if ASn has source: RIPE-NONAUTH, then the corresponding as-set would > > be ASn:FOOBAR, so this would also need to be RIPE-NONAUTH. > > > > I don't see an issue with RIPE-NONAUTH aut-nums being able to create > > scoped RIPE-NONAUTH as-sets. This also gives a clear route for garbage > > collection: if the aut-num becomes invalid, then the corresponding > > as-sets also become invalid. > > > > IIRC it's not possible to create new aut-num objects with source: > > RIPE-NONAUTH? > > > > Nick > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On Tue, 29 Nov 2022 at 20:44, Nick Hilliard wrote: > > Cynthia Revström wrote on 29/11/2022 18:56: > > I agree with Nick. > > However there are currently as-set objects in RIPE based on aut-num > > objects in RIPE-NONAUTH. > > I think it might be worth considering if these should be cleaned up. > > I posted about this about a week ago in a separate thread on db-wg. > > right, yes, you're correct. I've included a list below. > > The RIPE NCC can't stand over the authenticity of these objects because > the AS in question isn't a RIPE-authenticated ASN. So RIPE-NONAUTH would > be an appropriate place for them. > > Changing this should not be service affecting, because the AS in > question is already RIPE-NONAUTH. Having said that, "should not" is not > the same as "will not". > > Some of these objects are stale. > > Some of them are legacy resources, but can be subject to the same > approach as defined in ripe-731. > > Do we need a policy change to move these, e.g. similar to ripe-731, or > simply including them in the scope of ripe-731? The policy ripe-731 is all about deleting objects that conflict with RPKI. So I don't see this issue being a part of the same scope. However, RIPE-NONAUTH is considered to be a separate IRR registry, even if the objects are physically in the same database. As a community we can argue that it is logical that if an ASN in the registry RIPE-NONAUTH authorises the creation of an AS-SET object, that new object must be located in the same registry. So putting these previously created AS-SET objects in the RIPE registry was a bug. We can therefore fix this bug and move these objects to the correct registry. I don't see that needing a policy. We can add it to NWI-19. Thoughts??? cheers denis co-chair DB-WG > > Nick > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
On 29 Nov 2022, at 22:07, denis walker via db-wg wrote: > I don't see that needing a policy. We can add it to NWI-19. > > Thoughts??? If we indeed don't need a policy, I think it would be cleaner to make this a new NWI, as adding to an NWI after implementation work has begun seems, IMESHO, likely to cause confusion. €0,20 Niall -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
Niall O'Reilly via db-wg wrote on 30/11/2022 16:15: If we indeed don't need a policy, I think it would be cleaner to make this a new NWI, as adding to an NWI after implementation work has begun seems, IMESHO, likely to cause confusion. agreed. In terms of breakage, we're carrying a 25yo basket of eggs. Any shift in position will is likely to cause a crack here or there. It's unlikely that any shift in position will cause more breakage than introducing RIPE-NONAUTH in the first place. Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
