Routing Policies

Running a clean network matters. We enforce industry-standard security measures to protect both our infrastructure and your services from hijacks, spoofing, and abusive traffic. Our policies are designed to balance security with flexibility, so you can focus on what matters most—your business.

RPKI Validation

We enforce RPKI (Resource Public Key Infrastructure) filtering on all BGP sessions—both upstream and downstream. What this means: if a prefix has invalid RPKI or fails validation, it gets dropped. No exceptions.

ASPA Enforcement

When ASPA (Autonomous System Provider Authorization) data is available, we enforce it. Invalid ASPA announcements from both upstreams and downstreams will be dropped to prevent route leaks and unauthorized path manipulation.

Authenticated IRR Filtering

For downstream customers, we require proper IRR (Internet Routing Registry) entries from an official RIR (Regional Internet Registry). We do not accept entries from private IRR databases like ALTDB or similar registries.

Bogon & Unannounced Prefix Protection

We blackhole bogons (reserved/unallocated IP space) and unannounced prefixes to prevent hijacking attempts and IP spoofing. This keeps malicious traffic from reaching our network and your services.

Route Leak Prevention

To prevent route leaks, we implement several safeguards:

• Prefix limits: Each BGP session has configured prefix limits appropriate for the peering relationship
• Transit ASN filtering: We drop announcements containing transit provider ASNs in the path to prevent accidental or malicious re-advertisements

These measures protect both our network and the broader internet routing ecosystem from propagating incorrect routes.

Abuse Filtering

We actively filter traffic from known abusive ASNs and IP ranges. This isn't about limiting legitimate use—it's about protecting our customers from malicious actors and keeping your services online and accessible.

BGP Communities

Transit customers can use BGP communities to control how we handle your announcements. Our full community documentation is available on our bgp.tools page:

ASN Validation Process

Before we bring up any BGP session with a downstream customer, we require ASN validation. This means you'll need access to the ASN's registered NoC or Abuse contact email addresses to complete verification.

This step ensures you actually control the ASN you're announcing from. It's a simple process, and we're here to help you through it if needed.

Hijack Detection & Prevention

We don't tolerate hijacks on our network—period. ASNs and IP ranges announced through our network may be inspected by automated systems and manual review. We're looking for red flags like:

• Recent WHOIS changes on legacy/older prefixes without matching transfer records
• Recent WHOIS changes on legacy/older ASNs without matching transfer records
• Recently re-registered expired domains in WHOIS information (especially if the re-registration happened after the last WHOIS update)
• Resources belonging to defunct companies or merged entities where the IP space/ASN was never properly updated
• Other indicators that raise concerns about legitimate ownership

If something looks off, we'll reach out to discuss it. Our goal isn't to create hoops to jump through—it's to make sure the resources being announced through our network are legitimately yours.

Port 25 Policy

By default, port 25 (SMTP) is blocked on all services. If you need it open for running a business or personal mail server, just ask—we'll review your request and open it for legitimate mail server use.