Yet another BGP hijacking towards AS16509

Tue Aug 23 21:42:54 UTC 2022

Hi Douglas, group,

On Tue, Aug 23, 2022 at 03:03:31PM -0300, Douglas Fischer wrote:
> I was thinking a little about this case...
> 
> I'm almost certain that this case cited by Siyuan would have been
> avoided if there was a cross-check between the items contained in the
> AS-SET objects (and others such as the Route-Set), and the "member-of"
> attributes of the referred objects.

You are right that stronger 'arcs' ("connections") between the various
IRR objects at first glance potentially offer a solution; unfortunately
the objects exist in separate databases ("namespaces"), one has to be
cautious for object name collisions!

Cross-references (through "member-of:" <> "members:" links) for RPSL
objects only work within a single IRR source, in other words: if objects
exist in the same database. An object in one database can't reference
(through 'member-of:') an object in a different database.

> I participated in a small exchange of ideas about this, and there were
> questions about whether this crosscheck should be done by the consumer
> of the IRR data, or if it should be validated at the time of insertion
> in the base through NRTM.

As far as I understand the data model, only the ultimate consumer of IRR
data would be in a position to enforce some kind of policy (such as
requiring cross-references both ways 'members:' <> 'member-of:'); the
middle layer (software packages like IRRD) lack context.

I know of examples where fairly robust RTBH filters were generated using
members:/member-of pairing as a prerequisite; but I'm not aware of a
"cross-RIR" solution.

Kind regards,

Job