DDoS protection with your own ASN: LOA, IRR and RPKI steps

Most DDoS protection on the market rests on one assumption: your servers sit on the provider's network, and the protection sits at the edge of that network. For organisations that hold their own autonomous system number (ASN) and their own IP range there is a second model. The range is announced through the protection provider's network; dirty traffic stops there and clean traffic is delivered to you. Where your servers physically sit stops being the deciding factor.

The technical part of this model is the easy part. The hard part is the records — and a wrong record does not leave your range unprotected, it makes it globally unreachable. What follows is the order of operations and exactly where people trip over it.

What the model actually does

From the moment your range is announced through the Datafex network, all traffic destined for it reaches our filtering layer first. Volumetric attacks — DNS, NTP and TCP reflection or amplification — are cut at router level. Packets with forged source addresses, botnet-driven request floods and the rules you define for your own project are handled by the Fexwall layer. The legitimate traffic that remains is delivered to your infrastructure over a GRE tunnel or a direct connection.

The real gain is where the filter sits: your line does not fill during an attack, because the dirty traffic never reaches your line at all. No firewall at your own edge can do that, however good it is — by the time a packet gets there it has already consumed the link. If you have never thought about the layer distinction, the L3/L4 versus L7 split in what DDoS protection is comes before this article; everything below assumes you know it.

Prerequisites: an ASN and at least a /24

You need two things at once — your own autonomous system number and an IPv4 range of at least /24. The second is not negotiable: prefixes longer than /24 are filtered by most operators in the global routing table, so announcing a /25 produces the same result as not announcing at all. On the IPv6 side the commonly accepted limit is /48.

If either piece is missing the model cannot be applied. In that case IP rental or simply running the services on our infrastructure gives a better outcome — and if someone is selling you "BGP protection" without an ASN, what is being sold is something else.

Four records, in this order

Here is the work that has to be finished before announcement day:

1. ASN and prefix verification. The size of the range and where it is announced from today are confirmed. How you are connected to your current providers decides how the cutover is designed.
2. The LOA. A letter of authorisation showing the range is yours to use and announce. It is not a technical setting; it is the basis on which filters are opened on the provider side.
3. The IRR record. The route object for the range (route6 for IPv6) is updated to point at the ASN that will make the announcement. Many operators limit the announcements they accept using filters generated from IRR data, and a prefix whose record was not updated gets caught by them.
4. The RPKI ROA. The origin ASN and maxLength in the ROA defined for your range are brought into exact agreement with the new announcement.

These records can take hours to propagate. That is why all of them have to be complete before announcement day: when record updates and the announcement are squeezed into the same hours, isolating the cause of whatever goes wrong becomes impossible too.

Why RPKI is the last and most critical step

If your ROA does not match the new announcement, the announcement is marked invalid and operators performing RPKI validation will not accept the traffic at all. That is not "I am less protected", it is "those networks cannot reach me" — and because the symptom is partial it is hard to diagnose: one region reaches you while another does not, and your ping from your own office looks fine.

The second common mistake is leaving maxLength wider than necessary. RPKI checks only two things: the ASN making the announcement and the prefix length. Keeping maxLength longer than what you actually announce stamps a more specific announcement made with your origin ASN — but not made by you — as valid, which opens the door for parts of your range to be announced by someone else.

Because these records are tied to your own RIPE account, you make the updates; we tell you what the values should be — origin ASN, maxLength, the route object. For the detail, see what RPKI and ROA are.

How traffic gets back to you

How the cleaned traffic reaches your infrastructure is solved one of two ways. If your servers are already on our side — through colocation or cabinet rental — a direct connection is the simplest route. If you are in another location the traffic is carried over a GRE tunnel, and the tunnel's MTU and MSS settings are agreed as part of the build. Do not leave that to the day of installation; GRE tunnels and MTU describes what skipping it looks like.

Announcement day: window, monitoring, rollback

An announcement is not instantaneous. A new one usually becomes globally visible over minutes, while changes on the records side can spread over hours. That is why the transition is placed in a low-traffic window.

Three things are watched during it: whether your range is visible from independent observers — RIPE RIS, looking glass services, public BGP monitoring tools — whether RPKI validation reads as valid, and whether real user traffic arrives over the expected path. The cutover is not finished until all three confirm at once.

The rollback plan is written in advance too. When you withdraw an announcement, traffic returning to the old path is subject to the same propagation delay, so "we can revert instantly if needed" is not a realistic sentence. Methods such as AS-path prepending can be used for a gradual cutover; which one fits depends on how you are connected to your existing providers.

Six mistakes that keep recurring

• Announcing before updating RPKI.
• Leaving maxLength wider than necessary.
• Skipping MSS clamping on the tunnel; small packets cross, large ones disappear.
• Planning to announce a prefix longer than /24.
• Cutting over at peak hour.
• Trying to protect UDP-based game or voice traffic with an HTTP proxy — that layer never sees those packets.

If you are planning a cutover with your own range, the starting point is an inventory: the ASN, the prefix list, today's announcement arrangement and where your servers sit. Share those four through the contact form and we can work out the record values and the transition plan together; the scope of the service itself is on the BGP protection page.