Google and Its Contribution to Routing Security in the Region
15/12/2022
Content Delivery and Interconnection Strategy at Google
The problem of routing security is difficult to solve, as it requires multiple tools and solutions, as well as the participation of the majority of the interconnected networks. To contribute to this effort, Google has developed its network in compliance with the best practices for secure Internet routing. This involves publishing and checking that the information in our Internet Routing Registry (IRR) and Resource Public Key Infrastructure (RPKI) is correct and up-to-date, and using this information from other networks to create filters that will avoid routing security issues. With this, we hope to increase the security of our network and reduce the possibility of route leaks or hijacking.
What information must an organization provide when installing a cache or peering with the Content Distribution Network (CDN)? What objects must be created in RPKI and the IRR?
For the IRR, the network must create at least its route objects, its ASN objects (single autonomous system), and its maintainer. If the organization is providing transit to other ASNs, an AS-SET object must be created, which must also be shared in their PeeringDB record. In the case of RPKI, the network must create its ROAs (digitally signed objects to support routing security) and check that they are valid for the prefix announcements that are sent to us.
For the moment, the IRR and RPKI requirement applies only to peering. Google does not currently require these records for GGC (caches on the operator’s network).
Why do we use AS-SET?
The AS-SET object is used to verify that the prefixes of a third-party autonomous system (e.g., a client or downstream ASN) can be received through our peer (the ASN that interconnects directly with Google.) The AS-SET must contain the ASNs of all the prefixes that our peer wishes to announce to us.
Because the AS-SET is a string of characters (e.g., AS-GOOGLE), there is no direct relationship between an AS number and this object that can be inferred or obtained automatically. Therefore, this relationship must be created with an external mechanism. Today, the ‘IRR as-set/route-set’ field of the PeeringDB record is used to link both objects. Just as RPKI prevents the theft of the origin of a prefix, filtering with AS-SET avoids problems with route leaks, which is why it is required.
Recommendations
Although many networks have RPKI and IRR records, we have detected that they are outdated. The networks peering (exchanging traffic) with CDNs and cloud providers should check and update this information.
Various public and private sources that provide information on the validity of a route (IRR and/or RPKI) can also be used. Examples of the former include the RIPE NCC Routing Information Service, Hurricane Electric’s BGP page, and MANRS, while examples of the latter include the Google ISP Portal. Networks can follow the guidelines established by MANRS and, if possible, join as members of the initiative.
*This column is part of a series of articles published by LACNIC News about CDNs in Latin America and the Caribbean.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.