[connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call

Hi

>But we are trying to solve only one aspect of the problem: by not using
>anymore the unauthenticated IRRs we will have removed a whole class of
>possibile hijackings.

And also you might invalidate a lot of valid objects causing issues for the
networks using the RS in the IX.

Let me make a few comments.

I agree with some of the concerns raised here. IMO I do not think that is a
good idea to just ignore some of the IRR databases, instead you could use
something similar to what we have proposed on the MANRS for Cloud/CDN
providers. I think it is a good balance to use a variety of IRR DBs:

--->

Standard AS-SET expansion process:

   1. If a peer-AS has downstream customer ASNs (customer cone ASNs), they
   are to be gathered through the “as-set” object. The “as-set” (or AS-SETs)
   will be picked up from PeeringDB, “IRR as-set/route-set” field. The syntax
   of the name should be IRR-NAME::ASX:AS-SET-NAME, where ASX is the ASN of
   the peer-AS. If no AS-SET is provided, only the ASN of the peer-AS will be
   used in the following steps.
   2. All the IRRs mirrored by RADB will be consulted to collect all
   “route” objects with the “origin:” field matching the ASNs collected in
   step 1
   3. If the collection of data results in conflicting objects, the
   following rules apply in the following order until all conflicts are
   resolved:
   4. The primary IRR specified by IRR-NAME has the priority
   5. AFRINIC, APNIC, ARIN, LACNIC, RIPE have the priority
   6. The most recently updated object has the priority
   7. If further tie breaking is needed, could select the object based on
   lexicographic order of the IRR DB names

Source: https://manrs.org/cdn-cloud-providers/actions/

--->

Also, it is true that this is meant to be applied on European IXs, but as
Nick mentioned, regulators et al. might take this as the BOCP for everyone
(even no IXs.)  Believe it or not, this document might have a lot of
influential power and you should be careful on what you propose, because it
might have some unintended repercussions.

Finally, on a practical note, for organizations that have to maintain a few
thousands of IRR objects, doing it manually is not an option, so we need to
rely on APIs. The less the better, and the more the same, the better.
Unfortunately not all RIRs support API calls to manage IRRs objects, and
for the ones that they do I think they are different. So, it is much easier
to use RADB or other single DB.

Regards
as

On Thu, Jun 6, 2024 at 11:54 AM Marco d'Itri <md at linux.it> wrote:

> On Jun 06, "Mullally, Ronan via connect-wg" <connect-wg at ripe.net> wrote:
>
> > But if a bad actor manages to masquerade as somebody else’s ASN,
> > either directly or via ‘downstream’ routes then neither of the above
> > help.  If anything there is a risk that if we blindly consider a route
> > that matches a route object / ROA to be beyond doubt we may be less
> > able to identify such actions.
> Of course, this is obvious.
> But we are trying to solve only one aspect of the problem: by not using
> anymore the unauthenticated IRRs we will have removed a whole class of
> possibile hijackings.
> For the others indeed other technologies will be needed.
>
> --
> ciao,
> Marco
> _______________________________________________
> connect-wg mailing list
> connect-wg at ripe.net
> https://mailman.ripe.net/
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/connect-wg/attachments/20240606/d3abbdd5/attachment.html>