Amazon/AWS should be listed as partially safe

[Michagogo]

This article from a couple weeks ago highlights a case of inadvertent hijacking of outbound traffic from AWS to a Direct Connect Public VIF due to a typoed third octet in an advertised /26.

To quote from AWS’s response brought in said article:

In the instance you reported, there was an issue with our process for validating the ownership of the IP prefix, which led to the traffic being sent to an unintended destination. We have since improved the process by expanding the checks being performed.

AWS has adopted Resource Public Key Infrastructure (RPKI) in its public peering and transit facing infrastructure [3]. However, RPKI had not yet been adopted in DirectConnect due to the increased burden RPKI would put on DirectConnect users. We are actively investigating improvements to the customer experience by adopting more streamlined mechanisms to verify prefix ownership, similar to the Bring your own IP address (BYOIP) features used with EC2 and Amazon Global Accelerator [4].

So there is supposed to be validation everywhere, and in some places they use RPKI, but it seems they use different forms of fallible (human error-susceptible?) validation on one of the entry points by which customers can inject routes that pull AWS-origin outbound traffic globally. In fact, this seems to be the worst place to not validate, because it’s a connection point that allows — by design — for any customer to inject routes, as opposed to only transit providers or other large network operators that meet the requirements for public peering.

[digizeph]

Based on current available resources, Amazon AS16509 is signing most of their routes and the ROV rate is relatively high.
https://bgp-inspector.pages.dev/asn/16509

I don't know about their product like DirectConnect and their BYOIP services to comment on this incident.

[Michagogo]

Correct me if I’m wrong, but my understanding is that there are two aspects to a network being considered safe: having the prefixes it advertises be properly signed with RPKI, and validating that inbound routes are RPKI-valid.

From what I can tell from the various docs, it seems that they do sign their own prefixes that they advertise, and for BYOIP (where a customer enrolls their own addresses and has AWS advertise the prefix in order to use the addresses for EC2 etc.) they require the customer to configure an appropriate ROA as well before they will advertise the prefix.

However, on the validation front, while it seems they do validate RPKI for routes coming in via their standard public peering interfaces, there’s a second possibility to advertise routes to them that draw traffic from the entirety of AWS, namely Direct Connect, which is essentially a service allowing customers to pay for peering for their own traffic when they don’t meet the requirements for free peering.

The service allows the customer to create two main types of virtual interfaces (VIFs). Private and transit VIFs are used to peer with VPCs and access resources within them (as well as AWS services via PrivateLink endpoints), and when using those the customer advertises their own private prefixes, and AWS advertises the prefixes of the connected VPC(s). Public VIFs, OTOH, are used to access AWS services and resources using public IP addresses without requiring any particular cloud networking infrastructure. In that scenario, the customer advertises their own public prefix(es), which are propagated across the global AWS network, while AWS advertises all of their various prefixes to the customer network.

It seems that while they obviously don’t allow any customer to advertise/hijack whatever prefix they want, the prefix(es) a customer requests permission to advertise aren’t validated with RPKI. Instead, they seem to undergo a one-off manual verification process, and as with any manual validation process, there’s room for human error, whether that’s a simple typo (as in the article mentioned in the OP), or hypothetically more malicious scenarios such as a forged LOA. Additionally, as far as I can tell there’s no mention of that verification being kept up to date, for situations where e.g. an IP block changes hands after a given prefix is approved for DX.