Summary

  • The Government of Andorra said DDoS attacks affected internet and 4G service for some Andorra Telecom users from 21:00 to 22:30 on January 21, 2022 and from 19:00 to 22:00 on January 22 [1].
  • Press reports connected the timing to the SquidCraft gaming tournament and described broader countrywide disruption, but those claims are wider than the government's confirmed wording and must remain attributed [2][3].
  • The public record does not identify the attack vector, measured volume, saturated component, mitigation provider, affected subscriber count, or exact recovery sequence.
  • RFC 4732 explains why link congestion, early filtering, monitoring, out-of-band control, and distributed service design are separate controls; it does not prove which of them Andorra Telecom used [5].
  • A credible closeout would bind AS6752 and service inventories to observed traffic, capacity, filter actions, fixed and mobile outcomes, external probes, and a negative recurrence test.

What happened

The Government of Andorra published the narrowest authoritative incident account on January 24, 2022. It said several denial-of-service attacks intended to disrupt the programming of some YouTubers affected internet and 4G service for some Andorra Telecom users. The notice gave two windows: Friday evening from 21:00 to 22:30 and Saturday from 19:00 to 22:00 [1].

That statement confirms the operator, service classes, attack category, dates, time windows, and at least some customer impact. It does not say that every subscriber lost service. It does not identify a packet rate, bits per second, attack protocol, target address, upstream path, firewall state, or mitigation action. Those omissions define the evidence boundary for any responsible analysis.

The Record reported attacks on four consecutive days, identified the network as Andorra Telecom AS6752, linked the timing to the SquidCraft tournament, and described countrywide connectivity failures. It also cited unnamed sources for bursts reaching 100 Gbps [2]. Tom's Hardware reported simultaneous disconnections among Andorra-based participants and said the country had little or no internet connectivity for more than half an hour [3]. These accounts help describe observed effects and public context. They do not replace operator telemetry or convert the 100 Gbps figure into an official measurement.

The difference between "some users" and "the entire country" is not a detail to smooth away. It is an unresolved scope question. It may reflect different observation windows, partial reachability, fixed-versus-mobile behavior, geographic variation, recovery at different times, or reporting imprecision. The public record does not let an outside reader choose among those explanations.

Why concentration changes the consequence

A DDoS attack is distributed because traffic arrives from many sources. The defender cannot solve it by blocking one address, and the hostile traffic may be hard to distinguish from a sudden legitimate audience. The direct objective is exhaustion: fill an access link, overwhelm packet processing, consume connection state, overload a service, or force a protective system to become the bottleneck.

The consequence depends on where concentration exists. In a market with many independent access networks, an attack against one provider can still be severe without becoming a national dependency event. In Andorra, public records describe Andorra Telecom as a public company and connect it to the country's telecommunications infrastructure and universal fiber-access framework [6]. Contemporary reporting described it as the only internet provider [2][3]. That concentration raises the blast radius of a shared external bottleneck or common mitigation control.

Concentration is not proof of negligence. A small country cannot copy the topology, economics, or supplier diversity of a continent. It does change what preparedness must demonstrate. Capacity planning has to consider correlated demand across the customer base. External links need failure and saturation boundaries. Fixed internet and 4G may share upstream transport, filtering, identity systems, control rooms, power, or suppliers even when their access technologies differ.

The accountability standard is therefore not "prevent every attack." RFC 4732 notes that defending against all possible denial-of-service attacks is unrealistic and that operators should build systems robust to malicious and non-malicious overload [5]. The standard is to make known attack classes expensive, contain the failure domain, preserve control access, recover predictably, and retain enough evidence to show which layer worked or failed.

The technical layer

The first possible bottleneck is international capacity. If attack traffic fills a cross-border link before it reaches local filtering, a device inside Andorra can discard every bad packet and still fail to restore useful capacity: the scarce link has already carried the traffic. RFC 4732 makes this point directly and recommends eliminating obviously bad traffic earlier, closer to its source where possible [5]. Operationally, that requires upstream coordination, remotely triggered controls, or a scrubbing path with enough clean return capacity.

The second bottleneck is the mitigation edge. A firewall, flow detector, load balancer, carrier-grade NAT system, mobile packet gateway, or scrubbing appliance has finite packet-per-second, state, memory, and control-plane capacity. A defense sized only in gigabits can fail on a high packet rate. A stateful defense can fail differently from a stateless filter. The incident record should distinguish link utilization, packets per second, flow creation, table occupancy, CPU, drops, queueing, and legitimate success.

The third bottleneck is route and service scope. Blackholing can protect the rest of a network by discarding traffic to a targeted address, but it deliberately makes that address unreachable. Andorra Telecom's current business terms reserve the right to activate protection, including blackholing, when necessary to protect the national internet network or customer traffic from DDoS effects [7]. That is evidence of a current control category, not proof that blackholing was used in 2022.

A blackhole action needs an exact target, time limit, approval, route observation, and customer-impact record. An over-broad prefix can remove unrelated services. A stale route can outlive the attack. A mitigation provider can announce a more-specific route and attract traffic, but the return path, route authorization, and capacity must be verified. The operator should know not only that a control was requested, but what route appeared in the running network and which services remained reachable.

The fourth bottleneck is operational control. During a data-plane flood, engineers still need access to routers, mitigation systems, DNS, authentication, monitoring, and communications. RFC 4732 recommends private out-of-band access because in-band management may fail during the same attack [5]. A closeout should show that operators could observe and change the network without depending on the congested path.

The fifth bottleneck is recovery. Attack traffic may stop, a filter may engage, a route may change, or a saturated system may restart. Those are different recovery mechanisms. A green internal dashboard does not prove customers can reach services, and a restored BGP route does not prove application traffic succeeds. Fixed and mobile probes from inside and outside Andorra should show when DNS, transport, and representative applications returned.

The defense chain should be observable

Detection begins with a normal baseline. RFC 4732 recommends monitoring abnormal traffic before an event, because a defender cannot characterize what it did not observe [5]. The useful baseline separates customer demand from attack traffic by interface, protocol, destination, packet size, source distribution, and service class. It also records normal headroom and the time needed to invoke each external defense.

Classification should avoid false certainty. The timing of the 2022 attacks supported the tournament link reported by the government and press, but timing does not identify the attacker. A packet sample can identify protocols and source patterns without proving who controlled the sources. A DDoS-for-hire hypothesis is not an attribution result unless infrastructure, payment, account, or law-enforcement evidence closes the chain.

Mitigation should preserve an action ledger. For each filter, rate limit, route change, scrubbing diversion, or blackhole, the ledger should record the exact target, requester, approver, timestamp, expiry, expected effect, observed effect, and rollback. The record must include unsuccessful actions and ambiguous responses. Retrying an operation after a timeout can duplicate or widen a control unless the interface is idempotent.

Verification needs external vantage points. One probe inside the operator may share the same blind spot as the failing network. The operator should test fixed broadband, mobile data, DNS, public websites, business endpoints, and public-sector services from multiple paths. It should record partial failure, not compress all states into up or down.

Finally, the operator should run a negative recurrence test. The test is not a ceremonial replay of a dashboard. It should send a safe controlled load or simulate route and mitigation state, trigger the same alarm class, invoke a bounded defense, prove that unrelated prefixes and services stay reachable, expire the control, and reconcile every event against external observations.

The registry is a ledger, not the outcome

PeeringDB currently identifies Andorra Telecom as AS6752 and lists a regional network footprint with public interconnection information [4]. That record is useful for identity, contact, and intended interconnection. Because it is current, it cannot reconstruct the operator's January 2022 peers, capacity, route policy, or mitigation contracts.

This distinction matters beyond historical caution. An autonomous system number identifies a routing domain; it does not prove that every announcement was correct, every path had capacity, or every packet reached a customer. A list of links records intended infrastructure; it does not prove that paths were physically independent or available under a correlated flood. A mitigation contract records authority to act; it does not prove the requested route or filter reached the network.

The evidence chain has to join the ledger to reality. The operator should bind service prefixes, upstreams, peers, scrubbing routes, fixed and mobile dependencies, and control owners to time-stamped observations from the running network. Disagreements must remain visible. If the inventory says two paths are independent while both fail together, the closeout should correct the dependency record rather than redefine the outage.

Who was affected

The government confirmed impact to some internet and 4G customers [1]. Press reports described wider effects on homes, businesses, government agencies, and tournament participants [2][3]. The safe conclusion is that a visible gaming event exposed a much broader shared dependency. The public evidence does not support an exact customer count, duration for each user, revenue loss, or service-by-service outage map.

Households experienced failed or degraded ordinary connectivity. Streamers had an unusually visible failure because continuous upstream traffic and low latency were necessary to remain in the event. Businesses faced potential payment, cloud, communications, and remote-access interruption. Public services could share the same external connectivity even if internal systems remained healthy. Mobile users were relevant because the government explicitly included 4G.

Each group needs a different continuity metric. A speed test does not measure emergency communications. A reachable home page does not prove a VPN transaction completes. A mobile registration indicator does not prove data reaches an external service. A national-operator closeout should therefore report representative service outcomes, not only aggregate traffic or device health.

What a credible incident package would contain

The first section is the timeline. It should show first abnormal traffic, first customer symptom, alert, classification, each upstream contact, every mitigation action, fixed and mobile recovery, control expiry, and final external confirmation. Times should share a clock and preserve uncertainty rather than backfilling false precision.

The second section is scope. It should list targeted addresses and prefixes, affected links and systems, customer/service classes, geographic variation, and unaffected controls. If the attack moved between targets or changed protocol, the record should show the transition.

The third section is capacity and action. It should record bits per second, packets per second, flows, link headroom, device state, scrubbing capacity, filter counters, route changes, and clean-traffic return capacity. Public disclosure can aggregate sensitive values while still naming the saturated layer and control class.

The fourth section is service verification. External probes should show DNS, TCP or QUIC setup, representative transactions, fixed access, mobile data, business connectivity, and priority public-service paths. Internal telemetry and customer reports should be reconciled rather than presented as competing truths.

The fifth section is recurrence prevention. It should identify the durable change, owner, deadline, exercise, failure criteria, and retained evidence. "More capacity" is incomplete if filtering invocation is slow. "Better filtering" is incomplete if the link saturates upstream. "More links" is incomplete if they share a control or facility.

What to watch next

The most important public signal is whether later incident notices distinguish attack volume from customer effect and name the constrained layer. A second signal is whether fixed internet and mobile data are reported separately. A third is whether recovery means attack traffic stopped, mitigation engaged, routes stabilized, or representative services actually worked.

Operators and customers should also watch the scope of protective routing. Current blackholing terms make target and expiry discipline material [7]. An operator can protect the national network while sacrificing one destination, but it should be able to show why the action was proportionate, which customers were affected, and when normal reachability returned.

The lasting lesson is not that a gaming tournament can "take down a country." The supported conclusion is narrower and more useful: repeated hostile traffic against a concentrated national operator produced confirmed internet and 4G disruption. Resilience becomes accountable when the operator can connect identity, capacity, mitigation actions, observed service, and recovery in one testable record.

Sources

  1. https://www.govern.ad/ca/w/dos-atacs-de-denegacio-de-servei-afecten-de-nou-alguns-usuaris-d-andorra-telecom-1
  2. https://therecord.media/ddos-attacks-on-andorras-internet-linked-to-squid-game-minecraft-tournament
  3. https://www.tomshardware.com/news/minecraft-ddos-attack-leaves-small-european-country-without-internet
  4. https://www.peeringdb.com/api/net?asn=6752
  5. https://www.rfc-editor.org/rfc/rfc4732.html
  6. https://www.andorratelecom.ad/en/applicable-legislation/
  7. https://www.andorratelecom.ad/en/product-conditions/services-solutions-companies/