On Thu, Jul 22, 2021 at 12:33:47PM +1000, Aftab Siddiqui wrote:
I was under the impression that it is not possible to create route objects with private ASN, I tried it this morning to test as well and yes it doesn't work. But I don't know how these showed up in the database.
It is not possible to create route objects with private ASNs in Whois directly, by e.g. using the Whois updates page in MyAPNIC. This is because Whois requires that such an update be authorised for both the IP address range and the ASN in the update. However, the route management interface in MyAPNIC permits users to create route objects with arbitrary ASNs (including private ASNs). This is because route management abstracts over both Whois route objects and RPKI ROAs, RPKI does not impose any authorisation requirement on the use of an ASN in a ROA (only IP authorisation is required), and using the RPKI standard across the board seemed like the sensible thing to do here when this was developed.
We intend to update Whois such that arbitrary ASNs may be used in direct updates, in order to align with the route management behaviour in MyAPNIC. However, it's not a request that comes up frequently from members, so it's not a high priority (though if it is causing problems for anybody, please let us know).
On Wed, Jul 21, 2021 at 08:52:05PM -0700, Ronald F. Guilmette wrote:
I have been in communication with APNIC staff members about these specific bogon routes fairly continuously for over three weeks now, but the only thing I am being told is that these routes are being "discussed internally".
Part of the issue here is that our system supports this purposefully at the moment, due to wanting the route management system to align where possible across both RPKI and Whois. We aren't yet sure how to deal with this problem, though. One option is to follow what RIPE do at the moment, per the discussion happening in the db-wg mailing list, and prevent route objects from being created for private/reserved ASNs. We could additionally warn the user, but allow override, for the other potentially problematic cases (route objects with undelegated ASNs, RPKI ROAs with private/reserved ASNs, RPKI ROAs with undelegated ASNs). Feedback on this from list participants would be welcome.
Regarding the specific route objects you have raised with APNIC with bogon ASNs, we are working through this list with the account holders, to avoid any unintended consequences from removal (per e.g. https://firstname.lastname@example.org/msg02844.html). Some of those objects have since been removed, while others are still pending. We will let you know once the status of each has been resolved.