MANRS for CDN and Cloud Providers

Originally designed for network operators, the MANRS initiative has expanded over the years to also address the unique needs and concerns of Internet Exchange Points (IXPs) and now CDNs and cloud providers.

CDNs and cloud providers typically exchange trafﬁc with thousands of other networks so data can ﬂow efﬁciently around the world. This makes them large hubs of the Internet interconnection infrastructure. Their participation in MANRS ampliﬁes the positive effect they have on routing security, and the routing hygiene of networks they peer with.

According to industry estimates, over half of all web trafﬁc is served over CDNs, and their use continues to grow to meet Internet users’ growing appetite for media content, such as video, music, gaming, and software downloads. CDNs are therefore in a unique position to help to secure the global Internet.

By joining, CDN and cloud providers support and commit to the baseline of routing security deﬁned by a set of six security-enhancing actions, of which ﬁve are mandatory to implement.

The CDN and Cloud Programme Actions

Action 1. Prevent propagation of incorrect routing information (mandatory)

Baseline Requirement: Ensure correctness of own announcements. Ensure correctness of announcements of their peers (non-transit) and customers by implementing explicit (allow-list) filtering with prefix granularity. (mandatory)

Additional requirements: Participants can further indicate they comply with one or both of the following additional requirements of Action 1: the use of RPKI as a primary source of validating information, and the use of a Standard AS-SET Expansion Process. (recommended)

Baseline requirement:

Content Delivery Network (CDN) and Cloud providers have many peering relationships, specifically with networks that do not provide transit for them. Implementing ingress filtering for all non-transit peers and their customers will not only make a significant positive impact on routing security but will also send a clear signal that incorrect routing announcements are not acceptable. Whenever feasible, participants should check that the announcements originate from legitimate holders.

Additional requirement: Use RPKI as a primary source of validating information

Ensure that validation of BGP updates using RPKI is implemented and has precedence over validation using the IRR system (see the Validation Flow).

Validation flow

The implementation of ingress filtering should make sure the following checks are involved:

Ensure that the origin ASN is in the set of ASNs of peer’s customer cone. This is done by expanding the corresponding AS-SET object in the IRR system (see section “Standard AS-SET expansion process”). If the origin ASN is not in the set of the ASNs, filter this announcement. (mandatory)
RPKI validation. For announcements that pass step 1, if the outcome is RPKI VALID, accept the route. If the outcome is RPKI INVALID, then filter it. If the outcome is RPKI UNKNOWN, continue with the IRR validation. (recommended)
IRR validation (mandatory):
1. For all ASNs defined by the AS-SET there must be a “route” or “route6” object with a correct “origin:” ASN for the prefix to be accepted.
2. More specifics of IRR “route” objects will be accepted, however an exact match of the “route” object for every prefix the peer intends to advertise is strongly recommended.
3. If no corresponding object is found, then filter the announcement.

Additional requirement: Standard AS-SET expansion process (recommended)

CDN and Cloud providers use a standard validation process for obtaining routing information and, therefore, encourage their peers to do the same. A separate optional “checkbox” indicates whether a participant exactly follows the standard validation process.

Standard AS-SET expansion process:

If a peer-AS has downstream customer ASNs (customer cone ASNs), they are to be gathered through the “as-set” object. The “as-set” (or AS-SETs) will be picked up from PeeringDB, “IRR as-set/route-set” field. The syntax of the name should be IRR-NAME::ASX:AS-SET-NAME, where ASX is the ASN of the peer-AS. If no AS-SET is provided, only the ASN of the peer-AS will be used in the following steps.
All the IRRs mirrored by RADB will be consulted to collect all “route” objects with the “origin:” field matching the ASNs collected in step 1
If the collection of data results in conflicting objects, the following rules apply in the following order until all conflicts are resolved:
1. The primary IRR specified by IRR-NAME has the priority
2. AFRINIC, APNIC, ARIN, LACNIC, RIPE have the priority
3. The most recently updated object has the priority
4. If further tie breaking is needed, could select the object based on lexicographic order of the IRR DB names.

Conformance checks:

This requirement is part of the peering policy of the CDN and Cloud provider and is publicly available (e.g. on their website or peering portal).

Action 2. Prevent traffic with illegitimate source IP addresses (mandatory)

Implement anti-spoofing controls to prevent packets with illegitimate source IP address from leaving the network (egress filters).

Description:

There is a difference between CDN and Cloud network with regards to this Action. There is additional challenge for Cloud providers, since they have to monitor and control what a virtual machine can do on the network. This Action requires controls that prevent traffic with illegitimate source IP addresses leaving the Autonomous System of the CDN or Cloud provider.

Conformance checks:

A cloud provider periodically runs a Spoofer (https://www.caida.org/projects/spoofer/) test from a VPS (typical setup) confirming that controls are in place. A CDN can run the test from their own infrastructure segment.

Action 3. Facilitate global operational communication and coordination (mandatory)

Maintain globally accessible up-to-date contact information in PeeringDB and relevant RIR databases.

Description:

The operator should register and maintain contact information in PeeringDB and appropriate RIRs’ whois databases. This contact information should include the operator’s current point of contact information for the NOC of the AS.

Conformance checks:

Check that phone or e-mail address (other than abuse-c) for provider’s AS’es is present in at least one RIR database
Check that PeeringDB contains Contact information for provider’s AS’es

Action 4. Facilitate validation of routing information on a global scale (mandatory)

Publicly document ASNs and prefixes that are intended to be advertised to external parties. Two main types of repositories are IRRs and RPKI. The requirement is to publish this information in at least one type of the repository (there may be more than one appropriate IRR); a recommendation is to maintain in both.

Action 4a. Facilitate IRR validation of routing information on a global scale

Document ASNs and prefixes that are intended to be advertised to external parties in the IRR.

Action 4b. Facilitate RPKI validation of routing information on a global scale

Document ASNs and prefixes that are intended to be advertised to external parties in the RPKI.

Requirements:

To enable other network operators to validate routing announcements from their neighbours, routing information needs to be properly registered in public routing repositories. CDN and Cloud providers indirectly contribute to the facilitation of validation on a global scale by implementing Action 1. It effectively results in motivating third parties to maintain such information. This will have a significant impact on the quality and completeness of such data.

The two main types of repositories are IRRs and RPKI. The requirement for Action 4 is to publish this information in at least one IRR (there may be more than one appropriate IRR). If an AS-SET is used to describe the set of ASNs operated by a CDN or a Cloud provider, it must be registered in that IRR and in PeeringDB (IRR as-set/route-set field). The selection of the IRRs and the AS-SET must follow the rules specified in the section “Standard AS-SET expansion process”

Additionally, Action 4b requires that all prefixes a CDN or a Cloud provider intends to advertise to their peers must have up-to-date corresponding ROA objects in the RPKI repository.

Conformance checks:

Action 4a: Check that the announcements originated by a peer’s ASes are registered in at least one IRR. The check is implemented in the MANRS Observatory.
Action 4b: Check that the announcements originated by a peer’s ASes are registered in the RPKI. The check is implemented in the MANRS Observatory.
Check that if AS-SET is registered in the PeeringDB, it conforms to the syntax provided in section “Standard AS-SET expansion process”

Action 5. Encourage MANRS adoption (mandatory)

Actively encourage MANRS adoption among the peers.

Description:

There is benefit in encouraging the implementation of good practices on routing security from the peers. Even if Action 1 is implemented by a CDN/Cloud provider, an incorrect announcement from a peer can still find its way in the routing table, e.g. through a transit arrangement. Implementation of the MANRS Actions by a peer ensures this won’t happen. Additionally, a reference to a clearly defined specific baseline as MANRS can align such requests and amplify them. This is essential for scaling up the adoption of MANRS. This is a path for transforming MANRS in true norms with the global effect.

Conformance checks:

A publicly available policy, a peering form or an e-mail template with a recommendation to implement MANRS.

Action 6. Provide monitoring and debugging tools to the peering partners (recommended)

Provide a mechanism to inform peering partners if their announcements did not meet the requirements of the peering policy of the CDN and Cloud provider.

Description:

To facilitate debugging of potential routing problems and provide feedback to peers on the effects of policy controls applied by a CDN and Cloud provider, the provider offers a tool, accessible publicly, or at least to the peering partners.