Summary

  • LACNIC's 28 July article opens with a malformed BGP Prefix-SID attribute, code 40, observed on 20 May 2025 and a burst of more than 150,000 updates in ten seconds.
  • The account says Cisco IOS-XR and Nokia SR OS discarded the attribute, Junos propagated it, Arista EOS reset sessions, and several IXP route servers relayed it.
  • RFC 8669 requires a malformed Prefix-SID attribute to be discarded and logged, but that standards rule does not identify the release, active fault-tolerance settings or inherited policy on any installed router.
  • A public conformance matrix should bind the same sanitized UPDATE bytes to exact software, effective configuration, boundary type, action, forwarded-byte result and route impact. Vendor names alone are too coarse.

One UPDATE, three verbs

LACNIC published a sharp routing-security argument on 28 July. Its central taxonomy reaches beyond prefix hijacks and route leaks to failures that cryptographic origin validation was never designed to classify. The opening example is unusually concrete: a BGP UPDATE observed on 20 May 2025 carried a corrupted Prefix-SID attribute. Prefix-SID is optional and transitive, and IANA assigned it path-attribute code 40.

The article describes a heterogeneous chain. Cisco IOS-XR and Nokia SR OS discarded the malformed attribute and continued. Junos passed the message onward intact. Arista routers reset BGP sessions when they received it. Route servers at several Internet exchange points relayed the attribute without filtering it. In ten seconds, the article says, the global routing system produced more than 150,000 updates; routes at several named networks flapped. It adds that Arista changed the behaviour in EOS 4.28.11 and later releases.

Those sentences perform valuable work. They separate an attribute-handling failure from a hijack, a leak and an RPKI verdict. A route can have an authorized origin and still carry bytes that exercise incompatible parsers or error policies downstream. The registry record and the ROA answer a different question.

But the comparison also stops one column early. Cisco, Nokia, Juniper and Arista are product families, not reproducible states. An operator cannot tell from a logo whether the router ran the affected parser, whether revised UPDATE handling was enabled, whether a peer-group template changed the effective setting, or whether the update crossed a customer, transit, peer or route-server boundary.

The standard is exact; deployment is conditional

RFC 8669 is not vague about malformed Prefix-SID syntax. The attribute is a set of TLVs. If the attribute is too short, contains a TLV with an invalid length or lets a TLV extend beyond the attribute boundary, the receiving speaker must discard the attribute and log the error. The RFC maps that result to the Attribute discard action in RFC 7606.

That is the normative action for a conforming implementation under the applicable conditions. It is not an inventory of deployed behaviour.

The contemporary incident analysis by Ben Cox preserves a qualification that matters. It says IOS XR and SR OS filtered the offending object assuming their systems had been configured for RFC 7606 error tolerance. The LACNIC article compresses that into the cleaner claim that the two platforms did what RFC 7606 says. Both statements can point toward the same observed outcome. Only the first tells an operator that configuration may be part of the proof.

The gap is not a gotcha. Technical journalism must shorten. Research surveys must normalize terminology. A live incident also rarely arrives with a perfect laboratory transcript. The proper response is to preserve the useful claim and attach the missing conditions, not to replace it with empty caution.

The public NANOG discussion illustrates why. Participants connected the Arista behaviour to bug 899981 and identified changed releases in four EOS trains: 4.28.11, 4.29.8, 4.30.6 and 4.31.2. They also asked whether the change would have produced a cleaner result for the exact message seen that day. A later Arista presentation at JANOG 57 repeats the vendor comparison and the fix list. That is strong operational context. It still does not become one controlled replay across all four platform families.

Update volume is not an impact census

The reported burst above 150,000 is arresting because it makes amplification visible. It should remain attached to its unit. The source graph is a collector observation expressed as an update rate over a ten-second average. It is not 150,000 unique routes, sessions, routers, networks or outages.

The same boundary applies to the named networks. Seeing routes associated with Starlink, Disney, Zscaler or ByteDance flap does not establish that every organization used an affected Arista release, received the same malformed bytes from the same neighbor or suffered the same service result. They are observations in a distributed control plane, not a vendor census.

The origin also remains bounded. The sources say the UPDATE came from an AS in the Asia-Pacific region and discuss several possible innocent paths to the event, including configuration error, duplicate automation or a software defect. They do not establish malicious intent. Labelling the class an attack category does not prove that this occurrence was an attack.

These limits make the event more useful, not less. They show exactly what evidence must survive the next one.

Add the configuration column

LACNIC can turn the anecdote into a reusable operational asset without pretending to control vendor code or operator networks. The useful public object is a versioned conformance matrix built from a sanitized replay of the same malformed UPDATE.

Each row should begin with an immutable hash of the input bytes and a test-vector version. It should record code 40, flags, declared attribute length and the precise TLV error. Next come platform and software release, the relevant fix identifier and the effective error-handling configuration after group, template and neighbor inheritance.

The relationship column is equally important. An implementation may apply different policy to an internal session, a customer, a transit provider, a settlement-free peer or an IXP route server. Route server must not become shorthand for one uniform product or filtering policy.

The output columns should state the resulting action: session reset, address-family disable, treat-as-withdraw, attribute discard, acceptance or another standards-defined action. If the message was forwarded, publish the sanitized forwarded-byte hash. If it was not, state that explicitly. Then bind the action to the session result and to route state: how many routes changed in Adj-RIB-In, Loc-RIB and the forwarding table, within the controlled test.

No public row needs a peer IP address, customer name, credential, private topology or production configuration dump. Operators can keep raw captures under controlled access while publishing the test vector, method, aggregate result, loss state, correction history and retest date.

That record would also separate responsibility. RFC authors define the required action. Vendors implement and repair parsers. Operators choose releases and policy. Route-server operators decide which attributes cross their service. LACNIC's legitimate role is narrower: preserve a clear regional research account and give practitioners a method they can reproduce.

What the evidence does not say

The sources do not show that LACNIC originated the UPDATE, operated an affected route server or could have stopped the event. They do not show one global outage, a measured user population or a complete list of affected sessions. They do not prove timeless defaults for any vendor.

Nor does the event diminish RPKI within its actual boundary. Origin validation can tell a relying network whether a prefix-origin pair is covered by a valid authorization. It does not inspect every optional-transitive path attribute for parser safety. Asking RPKI to answer the second question would confuse two controls.

The news is therefore not that cryptography failed. It is that a modern routing-security account has exposed a place where operational evidence still depends on local, versioned behaviour. LACNIC has supplied the verbs. The next publication should supply the conditions under which each verb was true.

Sources