Refuse invalid origin ASNs in route objects

[mxsasha]

Currently, IRRd accepts any ASN from 0 to 4294967295 as origin in route(6) objects, key for an aut-num, or part of the key for an as-set. We should probably restrict that a bit.

The scope filter can cover this partially, filtering these objects from any source, but the idea of this issue is that the use of these ASNs can be considered a validation error of the object text, i.e. creation of an object with these ASNs in their primary key in authoritative databases will be refused in the same way as trying to make one for AS -1. In line with that, this would not be a user configurable parameter.

The ASNs to consider are:

• AS0: blocking is consistent with IRRd 3. RFC 7607 says this must not occur in BGP. No current objects.
• AS65535 and AS4294967295 are reserved per RFC 7300. About 75 route(6) objects have 65535 as an origin.
• AS23456 is reserved per RFC 6793 - its use in IRR doesn't make sense. About 75 route(6) objects have this as origin.

RIPE database says "Any originating AS Number can be used, so long as it’s not in reserved space. The originating AS Number does not have to exist in the RIPE Database".

Note that private ASNs are not considered to be refused: they are valid to use in BGP, and while there are many cases in the IRR where their usage would be incorrect, there are probably valid use cases.

[fischerdouglas]

I guess this is not the time to address this.
But just to put it on the agenda...

Wouldn't it be possible to cross-reference the Origin AS data with the ASNs that have actually been delegated by the RIRs?

Create a PseudoSource from cyclic fetchs of the delegated-extended files from each of the RIRs, and cross-check that the ASN exists there.

If that were done, in addition to knowing whether the ASN is for reserved use (invalid) or not, it would be possible to know (mark with some flag and remark) whether the ASN truly exists or not.