Earlier this year, Telstra AS1221 quietly announced it had signed Route Origin Authorizations (ROAs) for its prefixes with a plan to start monitoring invalids by June 2020.
Its decision aligns with other major carriers’ efforts around the world to implement Resource Public Key Infrastructure (RPKI) to certify the truth of routing messages, and in doing so, protect against the most common form of BGP hijacking.
In the announcement, Telstra’s Senior Network Engineer, Mark Duffell, explained that until June, everyone who interconnects with AS1221 who hasn’t already started to create ROAs for their own address space are encouraged to do so. This is so that once Telstra starts its soft Route Origin Validation (ROV) launch in June, no unsigned or incorrectly signed routes will be dropped when routed through AS1221.
Currently 1,560 Autonomous Systems (ASes) connect with AS1221, making it one of the most interconnected networks in the Asia Pacific.
To learn more about Telstra AS1221’s strategy and ROA signing experience, we reached out to Mark and the Telstra RPKI Engineering team, who were happy to provide feedback on some of the technical intricacies of the deployment.
“We plan to start monitoring invalids in June 2020 with a view to drop invalids once we’ve worked through this data with our industry peers and customers,” says Mark.
“We chose to sign our ROAs with APNIC to cut down on the additional complexity of having to administer our own certification engine and repository. That’s not to say we won’t look to do this in the future as there are benefits with self-hosted engines.
“Creating the ROAs in MyAPNIC was really straightforward; we followed the APNIC Blog post (link below), which is a great place to get started.”
Mark says participating in the RPKI Deployathon, held in Melbourne as part of APRICOT 2020 in February, provided him greater insight into which RPKI validator they will now consider when implementing ROV later in the year.
“Both RIPE NCC’s Validator 3 and NLnet Labs Routinator 3000 seemed the easiest to use and most robust from the testing and feedback during the Deployathon, so we’ll consider using one of these or a combination of these two to allow for validation,” says Mark.
“As part of the initial deployment we also plan on using a number of geo-diverse located validator containers of the same code type.”
Looking ahead Mark says they also have plans as to how they will handle issues such as repository invalidity and flush timers on their diverse array of vendor border routers.
“At this stage, we are reverting to everything as VALID or UNKNOWN. We’ll review and assess this after we complete our monitoring phase and ROV is deployed.
“Flush timers will be standardized across all devices where possible. Again, it’s about making things as easy as possible.”
Mark and the Telstra RPKI Engineering team welcome any queries or expressions of interest regarding their ROV adoption: rpkideployment at team.telstra.com
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.