Routing Integrity and Origin Protection

Internet routing is fundamentally based on trust

BGP does not verify intent or ownership of address space; it simply propagates routing information between autonomous systems. When that information is incorrect, the impact can extend far beyond a single network.

At an Internet Exchange Point, routing mistakes are amplified. A misconfigured announcement can immediately affect every connected participant. For this reason, routing hygiene is not optional — it is a shared operational responsibility.

This document explains:

  • What responsible behavior means as an ASN
  • How to protect your prefixes and routing reputation
  • How CNX enforces routing hygiene on its Route Servers

Your ASN Is Your Responsibility

Your Autonomous System Number represents your network globally. Your IP prefixes represent address space that you are accountable for operating correctly. If your address space is announced incorrectly, traffic may be misrouted or dropped. If your network originates routes that you are not authorized to announce, the incident can affect multiple networks and damage operational trust.

Good routing hygiene protects:

  • Your customers
  • Your upstream and peering partners
  • Your own operational credibility

Maintaining accurate routing data is therefore a core part of operating an ASN.

Principles of Good Routing Hygiene

At CNX, responsible routing behavior includes:

  • Maintaining accurate IRR route objects
  • Publishing valid Route Origin Authorizations (ROAs)
  • Maintaining a correct hierarchical AS-SET when announcing downstream networks
  • Keeping PeeringDB information up to date
  • Filtering customer announcements
  • Performing route origin validation on inbound routes

These are not administrative formalities. They are practical measures that reduce the likelihood and impact of routing errors.

The Three Layers of Route Protection

CNX filtering is based on three complementary layers of validation. Each layer serves a different purpose, and together they provide deterministic and automated route filtering.

1. IRR – The Documentation Layer

The Internet Routing Registry (IRR) contains route objects that document which ASN is expected to originate a specific prefix. IRR data allows networks to construct prefix filters automatically. Without correct IRR entries, other networks cannot safely determine whether your announcements are expected.

CNX builds prefix filters using authoritative IRR data. We do not manually insert prefixes into our filters. If your IRR records are incomplete or outdated, your routes may not be accepted. Maintaining accurate IRR records ensures that your routing intentions are clearly documented and machine-readable.

2. RPKI and ROA – The Cryptographic Authorization Layer

While IRR documents intent, Resource Public Key Infrastructure (RPKI) provides cryptographic authorization.

A Route Origin Authorization (ROA) states that a specific ASN is authorized to originate a specific prefix. Route Origin Validation (ROV) checks whether a received route matches the published ROA data.

Each route evaluated under RPKI has one of three states:

  • Valid – the origin ASN matches the ROA
  • Invalid – a ROA exists but does not authorize the announcing ASN
  • NotFound – no ROA exists for the prefix

At CNX Route Servers:

  • RPKI Invalid routes are rejected
  • Valid routes are accepted
  • NotFound routes are currently accepted (will switch to be rejected by 2027)

Publishing correct ROAs protects your address space from unauthorized origin announcements. Performing ROV protects your network from accepting invalid routes.

3. AS-SET – The Downstream Declaration Layer

If you announce only your own prefixes, your ASN must originate them directly. If you announce prefixes for downstream customers, you must publish a hierarchical AS-SET that:

  • Lists all authorized downstream ASNs
  • Is registered with your RIR
  • Is referenced in your PeeringDB entry

The AS-SET enables other networks to determine which origin ASNs are legitimately behind your ASN. CNX expands your AS-SET automatically when building Route Server filters. If a downstream ASN is not listed in your AS-SET, its routes will be rejected. Maintaining an accurate AS-SET prevents accidental route leaks and ensures that downstream announcements are clearly authorized.

How CNX Enforces Routing Hygiene

CNX Route Servers apply automated and deterministic filtering. All filtering logic is generated from authoritative public data and enforced consistently. Manual exceptions or private override lists are not maintained. When a route is received from a participant, it is evaluated through a series of validation steps before it is propagated to other peers.

Validation Flow

For each received route, CNX performs the following checks:

  1. Session and Path Sanity
    • The route must be received via BGP.
    • The left-most ASN in the AS_PATH must match the participant’s ASN.
    • The AS_PATH length must be within defined limits.
    • The NEXT_HOP must be one of the participant’s authorized addresses.
    • The AS_PATH must not contain invalid or reserved ASNs.
  2. Origin Authorization (AS-SET Enforcement)
    • The origin ASN must match the participant’s ASN, or
    • Be included in the participant’s published hierarchical AS-SET.

    If the origin ASN is not authorized, the route is rejected.

  3. Prefix Authorization (IRR-Derived Prefix Sets)
    • The prefix must match the prefix set generated from the participant’s published routing data.

    If the origin ASN is authorized but the prefix is not present in the derived prefix set, CNX attempts additional validation using RPKI and other registry datasets used by the validator. This reduces false negatives caused by incomplete IRR data while still enforcing strict origin control.

  4. RPKI Route Origin Validation (ROV)
    • CNX performs RPKI validation on received routes.
    • Routes with state Invalid are rejected.
    • Routes with state Valid are accepted (subject to other policy checks).
    • Routes with state NotFound/Unknown may be accepted if all other authorization checks pass.
  5. Prefix Length Policy
    • Global minimum and maximum prefix-length filters are enforced (e.g., IPv4 /8–/24).
    • Prefixes outside the allowed length range are rejected unless handled under a specific policy mechanism such as blackhole signaling.
  6. Bogon and Global Blacklist Filtering
    • Bogon and reserved address space is rejected.
    • Prefixes on global blacklist datasets are rejected.

Only routes that pass all applicable checks are propagated to other participants.

Blackhole Signaling

For supported blackhole requests, CNX applies a dedicated filtering path.
In this case:

  • The request is evaluated according to blackhole policy.
  • RPKI origin validation may not be performed.
  • The route is internally tagged to indicate that validation was bypassed for this purpose.

This mechanism is strictly limited to blackhole signaling and does not apply to normal routing announcements.

Outbound Announcements

When exporting routes to participants, CNX:

  • Does not announce RPKI Invalid routes.
  • Applies route control communities.
  • Enforces policy-based advertisement restrictions.
  • Applies prepend and no-export handling where applicable.

All outbound policy is deterministic and community-controlled.

Deterministic and Data-Driven Operation

CNX filtering logic is built automatically from:

  • RIR and IRR datasets
  • Published AS-SET objects
  • RPKI repositories
  • Global bogon and policy datasets

CNX does not manually insert or remove individual prefixes. If your registry and RPKI data are correct, your routes will be accepted. If they are inconsistent or unauthorized, they will be rejected.

Protecting Your ASN Beyond CNX

Routing hygiene should extend beyond your participation at CNX.

As an ASN operator, you should:

Filter Customer Announcements

  • Require correct IRR route objects
  • Require valid ROAs
  • Maintain an accurate AS-SET
  • Apply maximum prefix limits
  • Prevent default route leaks

Filtering customer announcements reduces the risk that their misconfiguration affects other networks.

Perform Route Origin Validation

Enabling ROV on your edge routers allows you to:

  • Reject RPKI Invalid routes
  • Monitor NotFound prefixes
  • Reduce exposure to route hijacks

Route validation is a baseline expectation for professionally operated networks.

Monitor Your Own Routing State

Regularly verify:

  • That your prefixes are RPKI Valid
  • That no unexpected ASN originates your address space
  • That your AS-SET reflects current downstream relationships

Early detection of inconsistencies can prevent larger incidents.

Operational Checklist for CNX Participants

Before enabling Route Server peering:

  • ASN registered and visible in IRR
  • All announced prefixes have route objects
  • All prefixes have correct ROAs
  • Hierarchical AS-SET published (if announcing downstream)
  • PeeringDB entry complete and accurate

Ongoing maintenance:

  • Update ROAs when delegations change
  • Update AS-SET when downstream relationships change
  • Review PeeringDB information periodically
  • Monitor RPKI validation status