Product deep dive

Prolexic

Network-layer DDoS defence for everything that is not HTTP: entire IP subnets, DNS infrastructure, VPN concentrators, mail, gaming and voice traffic, routed through globally distributed scrubbing centres.

Why a separate product from the web edge

The Akamai edge platform inherently absorbs attacks against HTTP/HTTPS properties it proxies. But an enterprise also runs services the CDN does not front: SIP trunks, IPsec/SSL VPN concentrators, SMTP, authoritative DNS on your own IPs, game servers, SFTP and legacy TCP applications. Prolexic protects those by routing entire network prefixes through scrubbing centres, at layers 3 and 4, independent of protocol.

How traffic gets to a scrubbing centre

BGP route advertisement

You advertise your prefix (typically a /24 or larger for IPv4) from Prolexic's scrubbing centres instead of, or in addition to, your own transit. Internet traffic destined for that prefix is drawn into the nearest scrubbing centre by anycast, filtered, and only clean traffic is delivered onward to your datacentre.

Internet  --->  Anycast scrubbing centres (multi-Tbps, globally distributed)
                    |  filters: ACLs, flowspec, signatures, behavioural
                    |  drops: spoofed, malformed, amplified, out-of-state
                    v
                Clean traffic returned over GRE tunnels
                    or a dedicated interconnect
                    v
                Customer datacentre / origin

Return path options

GRE tunnels — encapsulated delivery from scrubbing centre to your edge routers. Widely deployable, but watch MTU: GRE overhead of 24 bytes means you must clamp TCP MSS (commonly to 1436 or lower) or you will chase mysterious large-payload failures.
Dedicated connectivity / private interconnect — lowest latency and highest capacity, more lead time to provision.
Proxy mode — for specific applications where you cannot advertise a prefix.

Always-on versus on-demand

	Always-on	On-demand
Routing	Traffic permanently flows through scrubbing	Routes are advertised only when an attack is declared
Time to mitigate	Immediate — controls are already applied	Minutes: detection, decision, BGP convergence
Latency	Small, constant addition	None in peacetime
Best for	Business-critical, frequently targeted, or compliance-driven services	Cost-sensitive or latency-critical services with rare exposure

Always-on is strongly preferred for anything whose outage has a revenue or safety cost. The failure mode of on-demand is human: someone must notice, decide and trigger, at 3 a.m., correctly.

What the scrubbing centre actually does

Coarse filtering — drop protocols and ports you never use, invalid source addresses (bogons, RFC1918), and malformed packets. The single highest-value control most customers under-use: a tight proactive ACL that permits only the protocols your services genuinely serve.
Flowspec-style rules — rapid, granular drop/rate-limit rules matched on 5-tuple, packet length, TCP flags and fragmentation state.
Signature and heuristic matching — known amplification signatures (DNS ANY, NTP monlist, memcached, CLDAP, SSDP), reflection sources, booter fingerprints.
Stateful TCP validation — SYN cookies and out-of-state ACK/RST dropping so spoofed L4 floods never touch your firewalls.
Behavioural anomaly detection — deviation from learned per-prefix, per-protocol baselines.
SOC involvement — Akamai's SOCC applies and tunes countermeasures during an event under an agreed runbook.

Proactive mitigation controls

Rules pre-agreed and pre-loaded so that mitigation is applied the moment attack traffic appears, rather than after analysis. This is what makes a zero-second mitigation SLA meaningful: the controls are already in the data path. Building them requires you to document, honestly, which protocols and ports each protected prefix must serve — an exercise that itself usually finds exposed services nobody remembered.

Runbook design

A Prolexic deployment is only as good as its runbook. It should record, per protected prefix:

Permitted protocols, ports and expected peak rates (pps and bps) in peacetime.
Known legitimate sources that must never be filtered (partners, payment processors, monitoring).
Authorised contacts who may declare an attack and approve aggressive countermeasures, with out-of-band contact details — your email may be part of the outage.
Escalation and communication paths, including who talks to customers.
Acceptable collateral: is dropping an entire country acceptable at 2 a.m. if it restores service?

Test the routing, not just the plan. Schedule live GRE/BGP failover drills. The most common real-world failure is not the scrubbing — it is an MTU mismatch, a stale ACL on your own border router, or an expired contact.

Pairing Prolexic with the rest of the stack

Hide your origin. Prolexic protects the prefixes you route through it; if attackers can reach an unprotected IP, they will. Consolidate and enumerate your public address space.
Protect DNS separately. Authoritative DNS is best served by Edge DNS's anycast footprint rather than by scrubbing your own nameserver IPs.
Layer 7 stays at the edge. Scrubbing centres do not see inside your HTTPS sessions; HTTP floods are stopped by App & API Protector and the Behavioral DDoS Engine.
Monitor the seams. Correlate scrubbing-centre telemetry with edge and origin metrics so you can prove where an event was stopped.