KT's 2021 Routing Error Made Protocol-Boundary Validation a Natio

Summary

South Korea's Ministry of Science and ICT said KT's disruption began at about 11:16 on 25 October 2021 and that restoration measures were completed around 12:45, an interval of roughly 89 minutes. The government's joint investigation rejected KT's initial suspicion of a distributed denial-of-service attack and identified a routing configuration error during router-replacement work. [1]
The approved maintenance window was reportedly 01:00 to 06:00 the following day, yet the work took place during daytime while the network remained connected. The investigation also said partner-company workers carried out the change without a KT work manager present. [1][3][4]
A missing exit command failed to end an IS-IS configuration context. According to the official account, route information intended for BGP processing entered the IS-IS domain, producing a volume and type of routing information that the internal protocol was not expected to receive. [1]
The event was not a malicious BGP hijack, an RPKI origin-validation failure or a proven protocol-design defect. It was an operational boundary failure in a live carrier network. Protocol specifications help explain why BGP and IS-IS play different roles, but they do not reveal KT's private topology, router vendor, software version or exact installed state. [12][13]
Two manual review stages did not detect the omitted command. The public investigation also found no isolated virtual environment that represented the change before live execution and no effective mechanism that prevented a regional routing error from spreading nationally. [1][3]
Accountability therefore belongs at the level of practical control. KT controlled change authority, network access, topology, telemetry, rollback and customer communication. Contractors controlled the work they performed within those permissions. Regulators controlled investigation and sector requirements. Customers and merchants did not control KT's routing domain.
The minimum evidence for a consequential routing change should include the rendered command set and hash, parser context, device and software matrix, expected route counts by protocol, a representative test result, a canary rollout, automatic halt conditions, external reachability observations and a rehearsed rollback record.
The case is fundamentally about network infrastructure. Remove BGP, IS-IS, route distribution, internal propagation and national telecom continuity, and the accountability thesis disappears.

The official record changed the incident from an attack story to a control story

The first public explanation was not the final explanation. As service disruption spread, KT initially raised the possibility of a DDoS attack. That was a plausible operational hypothesis in the first minutes of a major outage, but it did not survive the investigation. The Ministry of Science and ICT's joint review attributed the disruption to a routing configuration error made during enterprise-router replacement work in Busan. The distinction is not semantic. A DDoS response focuses on hostile traffic, filtering, capacity and attack attribution.

A configuration response focuses on change authority, parser state, protocol boundaries, propagation controls and rollback. [1][2]

The reported timeline is bounded but useful. The disruption began at approximately 11:16. Restoration measures were completed at around 12:45. Contemporary reporting described failures across wired and wireless Internet services and the payment and business activities that depended on them. Those records support the conclusion that this was a national continuity event, not merely a brief fault on one office network. They do not establish that every customer was disconnected for the same 89 minutes, that every KT product failed identically or that all dependent services recovered at the instant KT completed its network measures. [1][4][6][8]

That separation matters for honest impact analysis. A carrier can restore core reachability while a merchant terminal, authentication session, branch connection or application remains in a retry cycle. Conversely, some customers may have retained partial connectivity while the broader incident was still active. An accountable incident report should distinguish the time at which the first network fault appeared, the time at which propagation stopped, the time at which routing state stabilized and the time at which dependent services were confirmed healthy.

The public sources do not provide that complete layered chronology. They provide enough to identify the control failure and the broad restoration window. They do not provide all router logs, all affected prefixes, every regional adjacency, every customer ticket or an audited economic-loss total. A rigorous account should use the facts that are available without converting the gaps into invented precision.

A maintenance window is permission, not proof of safe execution

The investigation reportedly found that the approved work window ran from 01:00 to 06:00 on 26 October, while the change was performed during the preceding daytime period. It also found that partner-company personnel carried out the routing work without a KT work manager present and while the affected network remained connected. These findings create an obvious governance question: how could a task approved for one window acquire execution authority in another? [1][3][5]

But the accountability lesson is larger than compliance with a calendar. A correctly scheduled command can still be unsafe. A manager can be present while a parser consumes an unintended line. A change ticket can contain the right objective while the rendered device configuration contains the wrong state. Maintenance governance is necessary because it limits when and under whose authority risk may be introduced. It is not sufficient evidence that the resulting network state is valid.

Four objects should be kept separate. The plan describes an intended task. The generated or edited command set is the executable input. The parser context determines how the device interprets that input. The installed and distributed state is what the network actually uses. A review that examines only the plan may never see a rendering defect. A review that sees the text but not the device's parser context may misunderstand the effect. A lab test that uses a different software release may not reproduce the production behavior. A local command that looks correct may still create a harmful distributed state after other routers receive it.

For a national carrier, the authorization record should therefore bind these objects together. It should identify the task, approved window, operator role, exact rendered bytes or canonical configuration, cryptographic hash, target device, software image, protocol context, expected state transition, validation result and rollback artifact. If any binding changes, the approval should no longer be treated as evidence for the new input.

This does not mean every routing adjustment requires bureaucracy so heavy that operators cannot respond. It means the process must preserve the relationship between intention and execution. Fast work can still be deterministic. Emergency authority can still be bounded. A short machine-verifiable record is often stronger than a long meeting record that never proves what the router received.

One missing boundary acquired national authority

The most important technical fact in the official account is the missing exit command. The government said that the command should have ended an IS-IS configuration context. Because it was omitted, information associated with BGP processing entered the IS-IS domain. Public explanations contrasted the roughly ten-thousand-item scale expected in the internal context with hundreds of thousands of BGP items. The resulting routing errors disrupted the network. [1][3][5]

The public record does not disclose the complete command file, the router manufacturer, the model, the software release or the exact table state. It would therefore be wrong to reconstruct a vendor-specific command sequence or claim that one published syntax exactly matches KT's device. The defensible conclusion is narrower: a missing context boundary caused the live system to interpret subsequent material in a way that violated the intended protocol scope.

This is why the event should not be dismissed as a typo. A typo becomes nationally consequential only when the surrounding controls grant it authority. The change system accepted input without proving its context. Review failed to detect the missing boundary. Execution occurred on a connected network. The internal architecture allowed harmful information to spread beyond its point of introduction. Detection and rollback did not stop the effect before national services were disrupted.

The command was small; the control path was large. Accountability analysis should follow the path rather than concentrate moral blame on the person who omitted a word. Naming an individual without a complete employment, instruction, review and access record would confuse the initiating act with the system that made the act consequential. A mature carrier assumes that operators and contractors will occasionally omit, transpose or misunderstand commands. It designs change controls so ordinary human error cannot silently become unbounded network state.

The critical question is not whether a careful person could have noticed exit. It is whether the system could prove where one configuration context ended and another began before the commands reached production. A parser-aware check could identify unclosed configuration modes. A semantic diff could show that BGP-derived material was about to affect IS-IS. A route-volume model could reject a result far beyond the expected internal scale. A representative test could expose the resulting state. A canary could limit the first execution to a topology whose failure would not become national.

None of those controls is guaranteed to prevent every incident. Together, however, they convert syntax from an act of faith into a testable input.

BGP and IS-IS are different control planes, and precision matters

BGP and IS-IS both participate in routing, but they solve different problems and carry different operational assumptions. BGP is the principal interdomain reachability protocol. It allows autonomous systems to exchange routes and apply policy to path selection and advertisement. IS-IS is a link-state protocol often used within an operator's own network to describe topology and calculate internal paths. RFC 4271 defines BGP's core behavior, while RFC 1195 describes the use of IS-IS for routing in TCP/IP environments. [12][13]

The official KT account says BGP-scale information was introduced into the IS-IS domain. That does not make the event a malicious route hijack. It does not show that an external network falsely originated KT prefixes. It does not establish that a route-origin authorization was missing or invalid. It does not prove a defect in either protocol specification. The central failure was the operational crossing of an intended boundary inside a carrier network.

Route-leak terminology also needs care. RFC 7908 provides a taxonomy for the propagation of routes beyond their intended scope in interdomain settings. That vocabulary can help operators think about policy violations, but the public investigation did not classify KT's internal incident under a specific RFC 7908 type. Applying that label as if it were an official forensic conclusion would add certainty the sources do not supply. [14]

Operational guidance for BGP emphasizes filtering, policy consistency, limits and monitoring because routing information is an authority-bearing input. RFC 7454 collects many of those practices. RFC 4098 describes terminology for benchmarking BGP convergence. These documents are useful context for questions about route control and recovery measurement. They are not evidence that KT used a particular filter, threshold, convergence tool or recovery procedure on 25 October 2021. [15][16]

The distinction between context and incident proof is essential. Protocol standards can explain what a well-defined control might measure. Only KT's records and the investigation can show what actually happened on its routers. Where those records are not public, the article should identify the missing evidence rather than fill the space with a preferred architecture.

Manual review did not represent the system that would execute the change

The investigation said KT had first- and second-stage review but that both stages depended on manual inspection and failed to detect the omitted command. That result should not be interpreted as proof that human review is useless. Experienced engineers can catch policy errors, unsafe assumptions and context that automated tools miss. The result does show that multiple approvals of the same weak representation do not create independent assurance. [1][3]

Two people can read the same plan and miss the same rendered defect. Two teams can inspect text without running the target parser. A checklist can confirm that a review occurred without proving what was reviewed. Independence requires more than separate names; it requires a check that can fail for a different reason.

A stronger chain would combine complementary controls. The first control could validate syntax and configuration context against the actual software family. The second could compare the candidate state with policy: which routes may be redistributed, how many are expected and which neighbors or areas may receive them. A third could execute the change in a representative environment. A fourth could observe the canary result from outside the device. Human approval would then evaluate the evidence and exceptions instead of acting as the only detector.

Representative validation is difficult in carrier networks. A laboratory rarely reproduces every adjacency, route, hardware behavior and traffic load. That limitation is not a reason to abandon testing. It is a reason to state the test boundary. A useful record identifies which software release, route set, protocol interactions and failure conditions were represented, which were simulated and which remained untested.

The same principle applies to automated config linting. A linter that only checks grammar might accept a syntactically valid but operationally dangerous redistribution. A policy engine that checks intended relationships might miss a vendor-specific parsing behavior. A digital twin can be stale. A canary can be unrepresentative. Accountability does not demand a mythical perfect validator. It demands a layered record showing which classes of error each control could detect and what happened when evidence disagreed.

Route-volume invariants could turn surprise into an automatic stop

The official explanation's contrast between the normal internal scale and the much larger BGP-derived information set points to a concrete control: route-volume invariants. A carrier knows, within bounded variation, how many items a protocol instance, area, neighbor or redistribution policy should handle. A candidate change that suddenly proposes an order-of-magnitude increase should not pass silently into the network. [1]

An invariant is not merely an alert threshold. It expresses an expected relationship. An IS-IS domain may have an expected number of prefixes, links or reachable objects. A redistribution rule may permit only a defined family of routes. A region may be authorized to originate or inject a bounded set. The system can compare the candidate and observed state with those expectations before and during rollout.

Good invariants need context. A fixed threshold can become obsolete as the network grows. A global number can hide a local anomaly. A temporary maintenance state may legitimately increase entries. The control record should therefore identify the baseline, permitted deviation, scope, duration, exception authority and automatic response. If the state exceeds the bound, the default should be to halt or isolate the change unless an accountable operator accepts the exception with evidence.

The KT event also shows why alerting alone is not enough. A warning that appears after bad state has propagated nationally may help diagnosis but not containment. A useful safeguard acts near the point of introduction. It can reject the update, disable redistribution, keep the change inside a canary topology or prevent onward advertisement until independent observations agree.

This is an application of running-state primacy. A ticket may say that only a small enterprise-router change is intended. The network's route counters may say that hundreds of thousands of items are moving into an internal protocol. When those records conflict, the running evidence must override the narrative. Permission does not make an abnormal state safe.

National propagation was an architectural outcome, not an inevitable property of routing

Reporting on the investigation described the error spreading to other regions within tens of seconds and identified the absence of a mechanism that could prevent one regional routing error from becoming national. This is the second major accountability layer. The initiating configuration error explains why bad state appeared. The propagation architecture explains why the effect escaped its origin. [1][3][7]

Large carrier networks require distribution. Routes and topology must move so traffic can reach destinations and failures can be bypassed. The answer cannot be to isolate every router permanently. The design question is how to divide the network into failure domains that permit normal operation while limiting erroneous state.

Useful controls can include constrained redistribution points, route-policy filters, maximum-prefix limits, area or level boundaries, staged deployment, route reflectors with explicit policy, canary devices and automatic rollback. The correct combination depends on architecture. The public sources do not show which of these KT had, how they were configured or which would have stopped this exact event. They do support the broader requirement that a carrier should be able to demonstrate the maximum propagation domain of a candidate change.

That demonstration should be tested. A diagram of regional segmentation is not enough if a live policy allows state to cross every boundary. A written rule is not enough if an emergency account can bypass it without a compensating check. A rollback plan is not enough if the team has never observed how long stale state persists after withdrawal.

National networks also contain dependencies that make blast radius nonlinear. A routing fault can affect retail access, mobile data, enterprise links, payment connectivity and services operated by other organizations. The same route may support multiple logical products. A recovery that restores one path may leave another dependency impaired. Segmentation evidence therefore needs to cover both routing state and service impact.

The accountability question is practical: what prevented one regional work item from changing national reachability? If the answer is only that reviewers were expected not to make mistakes, the architecture delegated blast-radius control to human perfection.

A canary is meaningful only when its authority is genuinely limited

Staged rollout is a common response to change risk, but the term can conceal weak controls. A canary is not simply the first production router modified. It is a deliberately bounded deployment whose effect can be observed before wider authority is granted.

For the KT scenario, a meaningful canary would constrain topology and propagation. It would use the same relevant parser and software behavior as production. It would receive a representative but controlled route set. Monitoring would compare expected and actual protocol state, route counts, adjacency health and reachable services. A pre-defined decision would either expand the rollout or restore the previous state.

The canary must not be able to leak unvalidated state into the full national domain. Otherwise it is merely the first point of failure. The expansion step should require evidence from the canary and preferably from an independent observation point. The operator should be able to show which condition authorized the next region or device.

Canary design also needs negative tests. A validation environment should intentionally omit a context boundary, introduce an excessive route set, attempt prohibited redistribution and simulate a failed rollback. The purpose is to prove that safeguards reject dangerous states, not only that a correct input succeeds.

No public source establishes that a particular canary design would certainly have prevented KT's outage. Network behavior can differ across devices and topologies. The bounded conclusion is that live national execution was too authoritative for an input whose parser context and resulting route volume had not been proven. A canary with real containment and measurable promotion criteria would have supplied stronger evidence than manual review alone.

Detection should distinguish hostile traffic from self-inflicted reachability loss

KT's initial DDoS suspicion illustrates a diagnostic challenge. From a customer's perspective, both a traffic flood and a routing failure can look like timeouts, intermittent reachability or complete service loss. At the network edge, high traffic, route churn, adjacency failure and application retry storms can occur together. Early hypotheses are necessary, but the response system should quickly discriminate among them.

The evidence needed for that discrimination includes traffic volume and direction, interface errors, route-table changes, protocol adjacency events, configuration audit logs, CPU and memory pressure, external route visibility and service probes. A DDoS hypothesis should be supported by hostile or anomalous traffic evidence. A routing hypothesis should be supported by changes in reachability or control-plane state. Operators may pursue both while facts are incomplete, but public communication should mark a hypothesis as provisional.

The investigation's rejection of DDoS is important because it demonstrates correction. Persisting with the attack narrative after configuration evidence emerged would have misallocated remediation. Filtering traffic cannot repair an erroneous routing state. Conversely, rolling back a config will not absorb a real volumetric flood. [1][2]

This is another reason to preserve exact change evidence. When an outage begins during or after network work, investigators need to compare the installed state with the last known good state quickly. If commands were applied outside the authorized window or through an unbound work channel, the audit trail becomes harder to trust. A carrier should not have to choose between restoring service and preserving evidence; the change system should capture evidence automatically as execution occurs.

Fast diagnosis is not simply an operational convenience. It affects public accountability. The initial cause determines which organizations are asked to act, which risks customers should manage and which remedies regulators may require. A corrected explanation should identify why the first hypothesis was displaced and what evidence supports the replacement.

Restoration, recovery and verification are separate claims

The government timeline says restoration measures were completed at around 12:45. That is a meaningful milestone, but it should not be expanded into a claim that every dependent service was fully normal at the same second. Routing restoration, customer reachability, session recovery and business-process recovery occur at different layers. [1][6][8]

A router may have a correct table while caches, sessions or edge devices still retain stale state. Mobile devices may need to reconnect. Payment terminals may retry. Enterprise tunnels may renegotiate. Applications may have circuit breakers or backlogs. An operator's internal network can be stable while customer-visible performance remains degraded.

An accountable recovery record should therefore include multiple signals. At the routing layer: adjacency stability, expected route counts, convergence observations and absence of repeated abnormal updates. At the reachability layer: probes from different networks and regions. At the service layer: representative DNS, web, mobile and enterprise transactions. At the customer layer: ticket trends and known dependent-service confirmation.

RFC 4098's convergence terminology is useful because it encourages precise descriptions of when routing information becomes stable, but it does not define KT's customer recovery or prove a measured convergence interval for this event. [16] The APNIC routing-outage research likewise shows how topology and service observations can help detect and characterize outages, while not substituting for KT's private incident data. [9]

Rollback evidence should be equally precise. A carrier should retain the last known good configuration, the commands used to restore it, the time each stage completed, any state that required manual clearing and the external observations that confirmed recovery. If rollback failed or required improvisation, that is itself a control finding.

The strongest closure statement is not “service restored.” It is a bounded claim naming which layer was checked, from where, at what time and against which expected condition.

Accountability follows control, not convenience

Major outages often produce a search for one person to blame. That approach is attractive because it converts a distributed technical failure into a simple story. It is also usually a poor guide to prevention.

KT controlled the production network, the accounts and procedures through which changes could be executed, the approved maintenance schedule, the relationship with partner companies, the topology, the telemetry, the rollback capability and the public customer channel. That concentration of practical control gives KT the primary duty to demonstrate how a configuration became authorized, why checks failed, why propagation was broad and what changed afterward.

Partner-company personnel controlled the specific work they performed, subject to the access, tools, instructions and supervision provided. Their records matter: who received the command set, what they understood the task to be, which environment they believed they were changing and what warnings they saw. But a carrier cannot outsource the accountability for national routing authority merely by outsourcing execution. Access design and acceptance controls remain with the network operator.

Managers controlled scheduling, staffing and exception handling. Engineering owners controlled technical standards and safeguards. Security and reliability teams controlled monitoring and incident classification. Executives controlled resources and risk acceptance. These roles may overlap, and the public evidence does not establish individual legal liability. A useful investigation maps decisions and evidence without guessing at personal culpability.

Regulators and government investigators control a different layer. They can require reporting, test whether sector-wide safeguards are credible and preserve public evidence. They should distinguish prescriptive paperwork from measurable outcomes. A rule requiring two reviews would not answer this event if both reviews remained manual and representation-limited. A stronger requirement would ask carriers to prove deterministic validation, bounded rollout and recovery evidence for consequential routing changes.

Customers, merchants and public-service users controlled their own continuity choices but not KT's internal protocol boundary. Large organizations may reasonably maintain redundant providers or offline procedures. Small users may have little practical ability to diversify. Dependency planning can reduce harm, yet it should not transfer responsibility for preventing a carrier's national routing error to those who could not inspect or control the network.

Number-resource records help identify authority but do not reveal private topology

APNIC's RDAP service identifies AS4766 as a public autonomous-system resource associated with KT. That record is useful because autonomous-system identifiers are part of the public routing accountability layer. They help operators identify origin and policy relationships, contact responsible networks and correlate observations. [11]

The record does not reveal KT's private IS-IS topology, configuration contexts, all internal routers or the path of the 2021 error. Public registry data is a ledger of allocated network identity and contact information, not a sovereign declaration about every operational fact. It should be accurate, current and usable, but it cannot replace incident telemetry.

This distinction reflects a broader principle. Network accountability depends on records that map authority to running systems. ASN registration says which organization holds or operates a public number resource. Route observations say what reachability was advertised. Configuration logs say what a device was told to do. Protocol state says what it accepted. Service probes say what users could reach. None of these records alone is the whole truth.

When the records disagree, operators need a method for resolving them. A maintenance ticket cannot override a route table merely because it was approved. A registry record cannot prove the private path merely because the ASN is correct. A dashboard cannot prove customer recovery if it observes only one internal location. The reality layer is built from multiple records tied to time, identity and scope.

The KT outage is especially instructive because the intended administrative boundary and the running protocol boundary diverged. The accountable response is to preserve both records and explain the difference, not to treat the approved intent as if it were the executed state.

Public impact should be described without invented precision

Contemporary reporting described disruptions to Internet use, payment systems, businesses and services that depended on KT connectivity. In a highly connected economy, even an outage measured in tens of minutes can interrupt transactions, remote work, logistics and public access. [2][4][6][7][8]

The temptation is to convert that broad evidence into a single customer or loss number. The available sources do not support a complete figure. Reports may refer to subscriber populations, complaint counts or particular services, but those measures are not interchangeable. A subscriber base is not an outage count. A complaint is not a unique affected line. A failed payment attempt is not necessarily a final economic loss. A national network event can also affect wholesale or shared dependencies in ways retail counts miss.

An accountable impact assessment should define the unit. It could count access lines that lost reachability, sessions that failed, regions that experienced impairment, dependent organizations that activated continuity procedures or transactions that could not complete. It should state the observation interval and whether partial degradation is included. It should avoid combining fixed, mobile and enterprise services without explaining overlap.

Public compensation and regulatory response may use different definitions from engineering analysis. That is legitimate if the differences are explicit. A compensation rule may prioritize simplicity and fairness. An engineering review may prioritize root cause and control coverage. A national resilience assessment may focus on critical dependencies rather than individual bills.

The absence of a complete public loss figure does not diminish the event's significance. It limits the claims that can be made. The strongest conclusion is that a live routing configuration error disrupted national telecom continuity and multiple dependent activities, while the full distribution and economic cost remain unverified in the cited public record.

Later commitments are not the same as verified repair

KT's 2021 ESG reporting described business-continuity and disaster-management commitments. Such material can show how the operator framed its responsibilities after or around the event. It is useful follow-on evidence, but it is a company statement. It does not independently prove that every corrective control was installed, tested and remains effective. [10]

Verification requires observable artifacts. If KT introduced an automated config validator, the evidence should show which devices, software versions and command classes it covers. If it built a virtual test environment, the evidence should show representativeness and known gaps. If it segmented propagation, the evidence should show enforced boundaries and test results. If it changed contractor supervision, the evidence should show how access and execution authority are technically bound to approved work.

Remediation should also be tested against recurrence, not only existence. A control can be present but bypassed. A route threshold can be configured but set too high. A lab can exist but use stale topology. A rollback can be documented but fail under load. Periodic exercises should intentionally introduce safe versions of the failure class and record whether the control stops them.

Public reporting need not disclose exploitable configuration. It can publish bounded assurance: the scope tested, date, independent reviewer, failure classes covered and unresolved limitations. Regulators can inspect more detailed evidence under appropriate protections. What matters is that commitments lead to falsifiable claims.

The distinction between announcement and proof is not hostility toward the operator. It is how infrastructure trust becomes durable. A carrier can improve after a serious failure and still acknowledge that no control eliminates all risk. Evidence lets customers, regulators and engineers distinguish measured progress from reassurance.

A minimum evidence chain for high-authority routing changes

The KT event supports a concrete evidence chain for routing work whose blast radius could cross regions or services.

Control point	Evidence before execution	Evidence during execution	Evidence after execution
Authority	Approved task, window, accountable owner, target devices and exception rules	Authenticated operator and bound session	Immutable record of who executed which approved bytes
Configuration	Rendered commands, hash, parser context and semantic diff	Device acceptance and unexpected-warning capture	Installed-state diff against intended and last-known-good states
Protocol boundary	Permitted BGP-to-IGP relationships and expected route classes	Route counts, redistribution state and adjacency changes	Confirmation that prohibited cross-boundary state is absent
Blast radius	Maximum topology and service scope, canary boundary	Automatic halt on scope or volume violation	Independent proof that no unintended region retained the state
Recovery	Versioned rollback, clear success conditions and rehearsed timing	Rollback trigger and progress evidence	Routing convergence plus external reachability and service checks
Communication	Incident classification criteria and responsible channel	Time-stamped hypothesis updates	Cause correction, bounded impact and unresolved unknowns

This table is not a universal architecture. It is a minimum record of control. Different carrier designs will implement it differently. The critical feature is traceability from permission to bytes, from bytes to state, from state to propagation and from restoration to externally observed service.

The evidence should be durable enough for later review. Screenshots are weak if they cannot be tied to a device and time. A ticket reference is weak if the command bytes changed after approval. A dashboard summary is weak if the underlying observations are unavailable. Hashes, signed logs, versioned policy and independent measurements make the chain harder to rewrite after the fact.

Evidence retention must also respect security. Detailed topology and credentials should not be exposed publicly. Access can be tiered. Operators, auditors and regulators may see different levels of detail while sharing a common event identity and hash. Public summaries can state what was verified without publishing sensitive commands.

The purpose is not paperwork for its own sake. During an outage, the same chain accelerates diagnosis. Engineers can see what changed, where it propagated and which rollback is valid. After an outage, it supports fair accountability because conclusions can be tied to control and evidence rather than organizational status.

A bounded repair program for carriers and regulators

The public record supports a repair agenda focused on this failure class, not a claim that one checklist would eliminate national outages.

First, carriers should bind change approval to immutable rendered configuration. The approved object should be the exact input or a reproducible artifact whose output is hashed. Any later edit should invalidate the prior approval or require a logged exception.

Second, validation should be parser-aware and semantic. It should detect unclosed contexts, prohibited redistribution and route-volume departures. It should run against the relevant device and software families, with explicit gaps where representation is incomplete.

Third, the network should enforce propagation boundaries. A regional change should not gain national scope merely because a command is accepted. Canary topology, policy filters and automatic halt conditions should be designed so their failure domain is real rather than nominal.

Fourth, carriers should measure recovery from independent points. Internal control-plane stability, public route visibility, access reachability and representative customer transactions are different signals. Closure should identify which passed.

Fifth, contractor access should be technically constrained. A contract or work order should not be the only boundary. Accounts, sessions, devices, windows and command artifacts should be bound to the approved task, with emergency paths separately logged and reviewed.

Sixth, incident communication should preserve hypothesis changes. KT's initial DDoS suspicion and the later routing conclusion should be recorded as a corrected diagnostic sequence. This helps the public understand why remediation changed and gives engineers evidence for improving detection.

Seventh, regulators should test outcomes rather than count signatures. A requirement for two reviews is weak if both inspect the same incomplete representation. Sector assurance should ask whether an intentionally malformed context is rejected, whether abnormal route volume stops propagation and whether rollback meets a measured recovery objective.

Finally, operators should publish bounded remediation evidence. They need not reveal exploitable topology. They can state the scope of tests, covered device families, date, independent assurance and known exclusions. That is enough to make continuity commitments more than aspirational.

What the public record still cannot prove

Several facts remain outside the available evidence. The complete command bytes are not public. The router vendor, model and software release are not established here. The exact route entries, prefixes, adjacencies and regions affected are not enumerated. The private IS-IS topology and redistribution policy are not disclosed. The full sequence of recovery commands and convergence observations is unavailable.

The record also does not establish a complete customer count or audited economic-loss total. It does not prove that every affected service recovered at 12:45. It does not identify every contractor decision, every manager action or every alert. It does not establish negligence, intent, concealment, contractual breach or vendor fault.

Later continuity statements do not verify every technical repair. Public registry data does not reconstruct the internal path. RFCs do not prove which controls KT deployed. News reports describe impact and findings but cannot replace primary router telemetry.

These limitations should shape the language of accountability. It is fair to say the official investigation attributed the outage to a routing configuration error and identified weaknesses in review, execution and propagation control. It is fair to require evidence that those weaknesses were repaired. It is not fair to invent hidden facts or assign individual legal culpability from a public summary.

Uncertainty is not an excuse for inaction. It defines the verification agenda. The missing records are precisely the artifacts an operator and regulator should preserve for the next review: immutable commands, parser context, route-volume observations, topology scope, rollback history and layered recovery checks.

Conclusion

KT's 2021 outage was a national network-infrastructure accountability test because a small configuration boundary error became authoritative running state in a connected carrier network. The approved window, work order and two manual reviews described intention and process. They did not prove what the router would parse, which protocol domain would receive the information or how far the resulting state could travel.

The strongest response is not to demand flawless operators. It is to build controls that assume ordinary error and prevent it from acquiring extraordinary reach. Exact rendered configuration, parser-aware validation, route-volume invariants, real canary boundaries, automatic halt conditions, rehearsed rollback and independent recovery observations make that possible.

Accountability follows the organizations that control those systems. KT retained responsibility for live network authority even where partner companies performed work. Regulators retained responsibility for testing whether sector assurances measure outcomes. Customers retained responsibility for their own continuity choices, but not for preventing an internal carrier routing error they could neither inspect nor stop.

The lasting lesson is simple: in network infrastructure, running state outranks administrative narrative. A permission record is valuable only when it stays bound to the bytes, parser context, protocol scope and measurable effect that the network actually executes.

KT's 2021 Routing Error Made Protocol-Boundary Validation a National Network Accountability Test