Hi all,
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://www.mail-archive.com/db-wg@ripe.net/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.
-Tom