The world needs a secure and resilient Internet, especially in the face of an ongoing pandemic still driving more activity and more people online. The trend makes cybersecurity a crucial issue as citizens and businesses increasingly move to exclusively digital modes.
The Australian government especially is concerned with critical infrastructure given the new focus on the trio of telecommunications, cloud services, and electricity. In fact, the Australian Cyber Security Centre recently issued new guidance on gateways, including Border Gateway Protocol route security.
The Internet Society, sponsored by Aftab Siddiqui, engaged me to investigate this topic based on the Mutually Agreed Norms for Routing Security (MANRS) and the results were published in the recent study, “Status of RPKI in Australia and New Zealand” (PDF).
The study examined whether websites belonging to both public and private institutions in the two economies rejected connections from clearly invalid sources of traffic. It also examined if networks, where these websites are hosted, provide necessary measures to avoid route hijacks. The results were concerning for both.
We set out to study the state of Resource Public Key Infrastructure (RPKI) uptake in Australia and New Zealand, with particular emphasis on the security of critical infrastructure.
During the research for the report, there were various tests of routing across Australia and New Zealand to a select set of websites. Some of these sites included government services and educational organizations.
Methodology
Gathering data for this project involved the capture of network information for 870,011 Australian domains (ending in .au) and 197,009 New Zealand domains (ending in .nz) with a control group of 38,232 domains from Pakistan with domains ending in .pk, as shown in Table 1. This methodology was tested extensively over routes to Pakistan.
| Unique traceroutes from all sources | 2,333,647 |
| Unique domains all destinations | 1,002,493 |
| Tested top-level domains | AU, NZ, PK |
| Tested second-level domains | school.nz, govt.nz, asn.au, org.au, net.pk, edu.au, com.au, gos.pk, org.pk, net.nz, co.nz, org.nz, id.au, com.pk, net.au, gov.au, edu.pk |
DNS
A total of 2,610,020 DNS records were captured as the first step in each test. 706,743 records were CNAMES or alias to another domain name. While 271,330 records were IPv6, these destinations were not tested. That left 1,633,947 IPv4 addresses recorded and eventually tested. The origins of each test were either a valid or an invalid Route Origin Authorization (ROA) IPv4 address.
Traffic source
Each tested domain was given one or more tests. The origin of the tests, which I will refer to as the valid and invalid sources, were two different IP addresses from two adjoining address ranges. One had a published ROA that validated the source of the traffic — the valid source. The other was purposely set up with an invalid origin, failing to match the published ROA, therefore becoming the invalid source.
Connectivity
The first step in each test was to make a TCP/443 connection to the target address. This test, if successful, would verify that a web server was running HTTPS (Hypertext Transfer Protocol Secure) and would reply to TCP traceroute to the host on port 443. There were occasions, for some targets, that this test continuously failed for the invalid source with no response ever received. Only successful attempts are recorded in traces. Counts for targets only with valid source results clearly indicated the target was immune to ROA attacks.
Trace routes
For each successful connection, a path was recorded for the outgoing packets. In Internet terms, it is a traceroute that returns information about each hop as the test passes each router along the route. Note here that traces record the outbound route, source to destination. It is entirely possible for the return path to be different, as discussed in the paper “Traceroute Probe Method and Forward IP Path Inference” (PDF).
Route paths
Each hop in the trace to the destination was mapped to an Autonomous System Number (ASN). This is then vectorized to give a path of Autonomous Systems (ASes) across the Internet. Note again, the path being explored is source to destination. The mapping used APIs like Team Cymru and ATLAS to get public data. While it was entirely possible to gather data from routing tables on Border Routers, this may not have been strictly true of the actual path taken, due to the policies of intermediate ASes across the Internet.
Highlights
One test involved connecting to websites from an address space in Sydney with a valid ROA. The next test to the same websites used a source address with an intentionally invalid ROA, therefore was designed to fail Route Origin Validation (ROV). However, on many occasions, that test did not fail.
The implications of these ‘successful’ results for invalid origins strongly suggest these sites could be accessed from hijacked addresses. Moreover, various networks serving these websites were allowing traffic to move over their networks without a check of the route origin. This also leads to finding that some upstream providers from these sites are passing traffic between the invalid origin and remote websites.
For the sites that never responded to the invalid connection test, the finding was very clear — some network along the path was dropping the traffic at the edge of their network. Time and again during the tests, these networks never passed invalid origin traffic.
The implication of this is that some networks are insecure and are not adopting practices to keep their routing secure. Many of these networks provide services to important government services. Furthermore, under these circumstances, a routing hijack would adversely affect these networks and those services.
This study found that while Australia and New Zealand have made progress, routing security is still in a poor state, exposing businesses, government, and citizens to great risks of data loss, theft, or interrupted critical services.
The possible remedy for these issues is obvious — the adoption of RPKI and the associated practices that prevent attacks and loss of routing integrity. The report data indicates half of the tested websites are at risk.
Network operators have a responsibility to ensure a globally robust and secure routing infrastructure. Your network’s safety depends on a routing infrastructure that weeds out bad actors and accidental misconfigurations that wreak havoc on the Internet. The more network operators work together, the fewer incidents there will be, and the less damage they can do.
All Internet Service Providers should aspire to become MANRS participants and comply with routing security best practices, including implementing RPKI. Learn more about MANRS, implement the actions for network operators, and join the community of security-minded operators working together to make the Internet safer for everyone.
View the full report online.
Terry Sweetser has 30+ years of ITEE/Telco experience, and is well known in peering and governance forums. He has now joined APNIC as the Training Delivery Manager (South Asia and Oceania).
This post is adapted from the original at MANRS Blog.
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.