You are here: Home > Participate > Join a Discussion > RIPE Forum
This mailing list interface will be retired once we upgrade our mailing list system. Click here to use the new RIPE NCC Forum.

Database Working Group

Threaded
Collapse

[db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects

User Image

Job Snijders

2022-11-14 18:41:16 CET

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

Ben Cartwright-Cox

2022-11-14 19:29:12 CET

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 <db-wg _at_ ripe _dot_ 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
> 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

denis walker

2022-11-14 22:08:00 CET

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 <db-wg _at_ ripe _dot_ 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
> 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

Korsbaeck, Fredrik

2022-11-14 22:34:42 CET

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" <db-wg-bounces _at_ ripe _dot_ net on behalf of db-wg _at_ ripe _dot_ net> 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 <db-wg _at_ ripe _dot_ 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
    > 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

User Image

Gert Doering

2022-11-14 22:36:08 CET

Hi,

On Mon, Nov 14, 2022 at 05:41:16PM +0000, 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 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Cynthia Revström

2022-11-15 01:19:45 CET

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
<db-wg _at_ ripe _dot_ net> 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" <db-wg-bounces _at_ ripe _dot_ net on behalf of db-wg _at_ ripe _dot_ net> 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 <db-wg _at_ ripe _dot_ 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
>     > 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
>
> --
>
> 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

Clement Cavadore

2022-11-15 08:54:56 CET

Hello Job,

On Mon, 2022-11-14 at 17:41 +0000, 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.


User Image

Markus Weber

2022-11-15 10:00:59 CET

> 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

User Image

Pierfrancesco Caci

2022-11-16 10:48:18 CET

Hi 
Speaking as be.ccafrique and uk.pccwg-uk I support Job's proposal. 

Pf

On Mon, 14 Nov 2022 17:41:16 +0000
Job Snijders via db-wg <db-wg _at_ ripe _dot_ net> 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 <pcaci _at_ pccwglobal _dot_ com> 
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.  


Yang Yu

2022-11-16 11:06:57 CET

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 <db-wg _at_ ripe _dot_ net> 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

User Image

Teun Vink

2022-11-16 11:19:17 CET

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           | teun _at_ bit _dot_ nl     | +31 318 648 688
KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE

Marco d'Itri

2022-11-16 12:50:32 CET

On Nov 14, Job Snijders via db-wg <db-wg _at_ ripe _dot_ net> 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
User Image

Emil Palm

2022-11-16 13:06:34 CET

>
> 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 <db-wg _at_ ripe _dot_ 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
> 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
>

denis walker

2022-11-16 17:11:52 CET

Hi Yang

On Wed, 16 Nov 2022 at 11:06, Yang Yu <yang.yu.list _at_ gmail _dot_ com> 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 <db-wg _at_ ripe _dot_ net> 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

User Image

Sander Steffann

2022-11-16 19:06:06 CET

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


User Image

Stavros Konstantaras

2022-11-17 15:08:39 CET

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


From: db-wg <db-wg-bounces _at_ ripe _dot_ net> on behalf of Emil Palm via db-wg <db-wg _at_ ripe _dot_ net>
Reply to: Emil Palm <emil _at_ netnod _dot_ se>
Date: Wednesday, 16 November 2022 at 13:07
To: "db-wg _at_ ripe _dot_ net" <db-wg _at_ ripe _dot_ 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 <db-wg _at_ ripe _dot_ netdb-wg _at_ ripe _dot_ 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
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
User Image

Erik Bais

2022-11-18 10:45:18 CET

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" <db-wg-bounces _at_ ripe _dot_ net on behalf of db-wg _at_ ripe _dot_ net> wrote:

    Hi,

    On Mon, Nov 14, 2022 at 05:41:16PM +0000, 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 14        Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

denis walker

2022-11-19 16:00:23 CET

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

User Image

Cynthia Revström

2022-11-19 18:27:33 CET

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 <db-wg _at_ ripe _dot_ net> 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

User Image

Job Snijders

2022-11-20 14:07:37 CET

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

Nick Hilliard

2022-11-20 18:52:12 CET

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

User Image

Job Snijders

2022-11-20 19:01:27 CET

On Sun, Nov 20, 2022 at 05:52:12PM +0000, 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

denis walker

2022-11-21 13:54:14 CET

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 <db-wg _at_ ripe _dot_ 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
> 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

User Image

Ed Shryane

2022-11-21 15:00:21 CET

RIPE NCC staff member

Hi Denis, Colleagues,

> On 21 Nov 2022, at 13:54, denis walker via db-wg <db-wg _at_ ripe _dot_ net> 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



User Image

Ed Shryane

2022-11-22 17:48:13 CET

RIPE NCC staff member

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 <db-wg _at_ ripe _dot_ net> wrote:
> 
> Hi Denis, Colleagues,
> 
>> On 21 Nov 2022, at 13:54, denis walker via db-wg <db-wg _at_ ripe _dot_ net> 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


denis walker

2022-11-22 20:00:47 CET

Colleagues

On Mon, 21 Nov 2022 at 13:54, denis walker <ripedenis _at_ gmail _dot_ com> 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

User Image

Gert Doering

2022-11-22 20:05:12 CET

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 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Nick Hilliard

2022-11-22 20:11:17 CET

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


User Image

Job Snijders

2022-11-22 20:13:41 CET

On Tue, Nov 22, 2022 at 07:11:17PM +0000, 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

denis walker

2022-11-22 21:17:16 CET

Hi Nick

On Tue, 22 Nov 2022 at 20:11, Nick Hilliard <nick _at_ foobar _dot_ org> 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
>

User Image

Niall O'Reilly

2022-11-23 00:30:19 CET

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

denis walker

2022-11-23 17:56:45 CET

Hi Niall

On Wed, 23 Nov 2022 at 00:30, Niall O'Reilly via db-wg <db-wg _at_ ripe _dot_ net> 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

User Image

Niall O'Reilly

2022-11-23 19:17:51 CET

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

User Image

Stavros Konstantaras

2022-11-24 13:54:01 CET

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" <db-wg-bounces _at_ ripe _dot_ net on behalf of db-wg _at_ ripe _dot_ net> wrote:

    Hi Niall

    On Wed, 23 Nov 2022 at 00:30, Niall O'Reilly via db-wg <db-wg _at_ ripe _dot_ net> 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

Nick Hilliard

2022-11-24 16:13:48 CET

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

User Image

Cynthia Revström

2022-11-25 00:20:37 CET

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 <db-wg _at_ ripe _dot_ net> 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

User Image

Cynthia Revström

2022-11-25 00:46:56 CET

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 <me _at_ cynthia _dot_ re> 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 <db-wg _at_ ripe _dot_ net> 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

Korsbaeck, Fredrik

2022-11-28 11:59:51 CET

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" <me _at_ cynthia _dot_ re> 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 <me _at_ cynthia _dot_ re> 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 <db-wg _at_ ripe _dot_ net> 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

denis walker

2022-11-29 14:00:38 CET

Colleagues

Any thoughts on these 'RIPE-NONAUTH' objects?

On Tue, 22 Nov 2022 at 21:17, denis walker <ripedenis _at_ gmail _dot_ com> wrote:
>
> Hi Nick
>
> On Tue, 22 Nov 2022 at 20:11, Nick Hilliard <nick _at_ foobar _dot_ org> 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

Nick Hilliard

2022-11-29 19:30:34 CET

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 ASnnnnn has source: RIPE-NONAUTH, then the corresponding as-set would 
be ASnnnnn: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

User Image

Cynthia Revström

2022-11-29 19:56:20 CET

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 <db-wg _at_ ripe _dot_ net> 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 ASnnnnn has source: RIPE-NONAUTH, then the corresponding as-set would
> be ASnnnnn: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

Nick Hilliard

2022-11-29 20:44:36 CET

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

denis walker

2022-11-29 21:09:56 CET

On Tue, 29 Nov 2022, 19:56 Cynthia Revström, <me _at_ cynthia _dot_ re> 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 <db-wg _at_ ripe _dot_ net>
> 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 ASnnnnn has source: RIPE-NONAUTH, then the corresponding as-set would
> > be ASnnnnn: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
>

denis walker

2022-11-29 23:07:53 CET

On Tue, 29 Nov 2022 at 20:44, Nick Hilliard <nick _at_ foobar _dot_ org> 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
>

denis walker

2022-11-30 15:26:27 CET

On Thu, 24 Nov 2022 at 16:13, Nick Hilliard via db-wg <db-wg _at_ ripe _dot_ net> 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.

This is an interesting point. I know nothing about bgpq3 or peval
(even though it has been around since the beginning of time). So I
just read the documentation on GitHub for them. I never realised this
feature existed. What you have described here Nick is in effect a
cross registry dependency. A feature that, as far as the RIPE Database
is concerned, is undocumented and unsupported. If anyone actually uses
this feature we have probably just broken it with NWI-19.

These two tools (and there may be others) work differently. Let's look
first at peval. It says in the docs:

"\-s "
Consider the sources specified in the comma separated .
If an object is defined in multiple sources in ,
peval uses the definition first encountered in 
from left to right.

Suppose we have '-s RIPE,RADB'. If RADB contains AS-AMAZON and we
create an AS-AMAZON in the RIPE Database, then the object in RIPE DB
will be used instead of the one in RADB. I guess that is the problem
we are trying to solve. But suppose RADB contains AS-WALKER and you
don't trust this object. By creating an empty AS-WALKER object (or one
with different content) in the RIPE DB you can effectively override
the object in RADB in your aggregation. This could be an intentional
and legitimate action. The question is, does anyone actually do this?
If so we may have just broken this. You can no longer create a short
name AS-SET object in the RIPE DB to override one in RADB.

However for peval you can get around this using:

"\-f "
IRR cache file. You can have any RPSL object in this file, except route
objects.
They will override these objects in IRR.
This option is intended for private objects, or to test new public objects
before publishing. You can specify more than one cache file by specifying this
option repeatedly.

So you could put a short name AS-SET object in a cache file to
override the object you want to ignore in RADB.

The bgpq3 tool also has a source flag (-S) and sources with identical
objects are handled the same way as with peval. This tool doesn't have
the cache file option of peval. So with bgpq3 you can no longer
intentionally override an object in RADB using this feature, if anyone
ever does do this.

This is an odd feature as it creates interdependencies between IRR
databases that are not defined in the database documentation. It also
means that, if anyone uses this feature, we cannot safely delete any
AS-SET based on being empty or un-referenced (within its own registry
database). It also breaks the self referential integrity of the RIPE
Database (and others) because data may be entered into the RIPE
Database for use by external tools to impact on data in another
registry. Even though peval has been around since the beginning of
time, this feature is not even covered by the historical purposes of
the RIPE Database. Yet again showing that we don't understand how the
RIPE Database is used.

So can anyone say, with any certainty, if this feature is being used?

cheers
denis
co-chair DB-WG



>
> Nick
>

User Image

Niall O'Reilly

2022-11-30 17:15:00 CET

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

Nick Hilliard

2022-11-30 18:56:34 CET

denis walker wrote on 30/11/2022 14:26:
> This is an interesting point. I know nothing about bgpq3 or peval
> (even though it has been around since the beginning of time). So I
> just read the documentation on GitHub for them. I never realised this
> feature existed. What you have described here Nick is in effect a
> cross registry dependency. A feature that, as far as the RIPE Database
> is concerned, is undocumented and unsupported. If anyone actually uses
> this feature we have probably just broken it with NWI-19.

Well, heh. This assumes the feature worked to start with.

Cross-registry queries are a fact of life.  It is advisable to specify 
source lists explicitly because otherwise you can end up with all sorts 
of junk in a query (e.g. from RADB which mirrors several well known 
registries).  No-one uses the "-f" option in peval because it's very 
inefficeint, although there are several query frameworks out there which 
do the same sort of thing, namely to pull down a copy of the objects 
they are interested in into a local database, and then run a query from 
there (IXP Manager does this, but it's ixp/route server specific).

Long term, the fix is to use fully qualified object names, i.e. 
source::ASxxxxx:localtoken.  This means updating RPSL, because that 
syntax is currently not legitimate.

Nick

Nick Hilliard

2022-11-30 18:59:13 CET

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

User Image

Randy Bush

2022-11-30 20:02:49 CET

> Cross-registry queries are a fact of life.  It is advisable to specify
> source lists explicitly because otherwise you can end up with all
> sorts of junk in a query

the ancient grotty code here orders the source query list per peer as it
generate phyltres, prioritiising the one they tell me when we agree to
peer.  driven off a grotty little file.

AS      PeerIP           Primary Database     AS-Set             MD5 Auth
4242    206.81.80.666    RIPE,RIPE-NONAUTH    AS-SMALL           md5-secret 
2424    206.81.80.667    RADB                 AS-BEHEMOTH        md5-secret 

randy

User Image

Cynthia Revström

2022-11-30 23:59:28 CET

Hi denis,

I am not sure if this feature is used or not however I think this is a
very good reason to not go forward with a clean-up (at least until we
have properly evaluated things).
We will probably have to figure out some other way to deal with
objects that are currently causing issues I think.

-Cynthia

On Wed, Nov 30, 2022 at 3:27 PM denis walker via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>
> On Thu, 24 Nov 2022 at 16:13, Nick Hilliard via db-wg <db-wg _at_ ripe _dot_ net> 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.
>
> This is an interesting point. I know nothing about bgpq3 or peval
> (even though it has been around since the beginning of time). So I
> just read the documentation on GitHub for them. I never realised this
> feature existed. What you have described here Nick is in effect a
> cross registry dependency. A feature that, as far as the RIPE Database
> is concerned, is undocumented and unsupported. If anyone actually uses
> this feature we have probably just broken it with NWI-19.
>
> These two tools (and there may be others) work differently. Let's look
> first at peval. It says in the docs:
>
> "\-s "
> Consider the sources specified in the comma separated .
> If an object is defined in multiple sources in ,
> peval uses the definition first encountered in 
> from left to right.
>
> Suppose we have '-s RIPE,RADB'. If RADB contains AS-AMAZON and we
> create an AS-AMAZON in the RIPE Database, then the object in RIPE DB
> will be used instead of the one in RADB. I guess that is the problem
> we are trying to solve. But suppose RADB contains AS-WALKER and you
> don't trust this object. By creating an empty AS-WALKER object (or one
> with different content) in the RIPE DB you can effectively override
> the object in RADB in your aggregation. This could be an intentional
> and legitimate action. The question is, does anyone actually do this?
> If so we may have just broken this. You can no longer create a short
> name AS-SET object in the RIPE DB to override one in RADB.
>
> However for peval you can get around this using:
>
> "\-f "
> IRR cache file. You can have any RPSL object in this file, except route
> objects.
> They will override these objects in IRR.
> This option is intended for private objects, or to test new public objects
> before publishing. You can specify more than one cache file by specifying this
> option repeatedly.
>
> So you could put a short name AS-SET object in a cache file to
> override the object you want to ignore in RADB.
>
> The bgpq3 tool also has a source flag (-S) and sources with identical
> objects are handled the same way as with peval. This tool doesn't have
> the cache file option of peval. So with bgpq3 you can no longer
> intentionally override an object in RADB using this feature, if anyone
> ever does do this.
>
> This is an odd feature as it creates interdependencies between IRR
> databases that are not defined in the database documentation. It also
> means that, if anyone uses this feature, we cannot safely delete any
> AS-SET based on being empty or un-referenced (within its own registry
> database). It also breaks the self referential integrity of the RIPE
> Database (and others) because data may be entered into the RIPE
> Database for use by external tools to impact on data in another
> registry. Even though peval has been around since the beginning of
> time, this feature is not even covered by the historical purposes of
> the RIPE Database. Yet again showing that we don't understand how the
> RIPE Database is used.
>
> So can anyone say, with any certainty, if this feature is being used?
>
> 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

Nick Hilliard

2022-12-01 19:34:51 CET

Cynthia Revström wrote on 30/11/2022 22:59:
> I am not sure if this feature is used or not however I think this is a
> very good reason to not go forward with a clean-up (at least until we
> have properly evaluated things).
> We will probably have to figure out some other way to deal with
> objects that are currently causing issues I think.

the "feature" is used, yes.  Some providers have customers in different 
RIR service regions.  Some organisations have address space registered 
in different RIR service regions. It's impossible to avoid in many 
situations.

What's important right now is to close off the option to create new 
unqualified as-set names, and to move the existing qualified non-RIPE 
ASxxxx:as-set objects from source: RIPE to source: RIPE-NONAUTH.

Denis was correct that this was a bug during the implementation of NWI-5 
(not ripe-731 which I mistakenly quoted).

After that, we can afford to spend a bit of time looking at potential 
clean-up options.  There are 1590 empty as-set objects.  700 of these 
haven't been updated in the last 5 years, and some going back 20 years.

I wouldn't lose too much sleep about deleting empty as-sets.  Contact 
people, set a timeout, and then delete.  Worst case, people can 
reference new, qualified as-sets.

Nick