Carlos Martinez-Cagnazzo and the Boundary Work of Routing Security

Summary

• Carlos Martinez-Cagnazzo's significance lies in boundary work: connecting LACNIC's regional number-resource mandate with RPKI standards, operational security questions, cross-registry coordination and practical instruction for network operators.
• His co-authorship of RFC 8360 and RFC 9691 is evidence of sustained standards contribution on validation and trust-anchor key rollover, but it is not evidence that he alone designed those mechanisms, controlled consensus or caused their deployment.
• A 2025 route-hijack case, later described by Martinez-Cagnazzo and Sanjaya, shows why routing security depends on identity checks and institutional escalation as well as cryptography; the measurable effects of his wider work, ASPA adoption, ROA MaxLength discipline and live trust-anchor practice remain important watchpoints.

When a valid-looking request carries a false story

The revealing moment in a routing-security incident is not always the instant when a route appears in the global table. It may come earlier, when an upstream network receives what looks like an ordinary request from a prospective customer. Addresses are supplied. Authority is asserted. A session is provisioned. The technical system then distributes a claim whose human foundation was never properly established. By the time alarms sound, the protocol may be doing exactly what the connected networks have instructed it to do.

That is the problem at the centre of a 2026 APNIC Blog case study by Carlos Martinez-Cagnazzo and Sanjaya. Their account concerns a BGP hijack in 2025 that combined a technical routing event with social engineering. It describes LACNIC escalating the matter to APNIC, APNIC contacting APJII and IDNIC, the upstream request being confirmed as fraudulent, and the relevant BGP session being terminated.

The chain of action crosses a regional internet registry, another regional registry, national and operator communities, and the provider whose customer-facing process had been abused.

The account is useful because it resists a comfortable division between technical security and administrative procedure. Resource Public Key Infrastructure, or RPKI, can provide cryptographically verifiable information about which autonomous system is authorised to originate a route for an address prefix. It cannot make a provider perform a sound identity check before accepting a customer. Nor can a signed entity telephone another institution, interpret a report or persuade a network to investigate a suspicious relationship.

The incident therefore exposes two security surfaces at once: the validity of a route as assessed through routing data, and the validity of the commercial or organisational story used to create the connection.

It would be easy to turn this case into a heroic opening about Martinez-Cagnazzo detecting and defeating an attacker. The sources do not support that account. The article is jointly authored. Its own sequence is multi-party. The provider made the decision to terminate the session after coordination involving several institutions. The case demonstrates Martinez-Cagnazzo's place in a public technical account of the response, and it shows the sort of boundary problem on which he speaks. It does not establish that he alone discovered, investigated or resolved the incident.

That limitation is not merely a legalistic caveat. It points to the form of competence that matters in routing security. The internet's inter-domain routing system has no single operations centre with authority over every entity. Each network chooses its neighbours and policies. Number registries hold authoritative information within defined mandates. Standards bodies develop common mechanisms, but implementation and operating decisions remain distributed.

When a false route spans jurisdictions, the response depends on parties recognising one another, knowing whom to contact and treating the report as credible enough to act. Coordination is not a soft supplement to the technical system. It is one of the means by which the system is made governable.

Martinez-Cagnazzo is an informative subject because his public record sits across those layers. LACNIC's current staff directory identifies him as CTS / Chief Technology Strategist. The IETF record associates him with two standards-track RFCs concerning RPKI validation and trust-anchor keys. An ARIN account places him in cross-registry technical education. None of these items, taken separately, proves institution-wide results.

Together they describe a person whose work is repeatedly located at the edge between a formal control and the organisations expected to operate it.

That edge is where strategy becomes concrete. A strategy for routing security cannot consist only of urging more cryptography. It must consider how validators behave when certification relationships become awkward, how a trust anchor changes keys without breaking reliance, how operators authorise prefixes, how providers assess customers, and how registries coordinate when a route appears to have been obtained by deception. The relevant authority is therefore bounded.

It is the authority to contribute, interpret, convene and advise within a distributed system, not the authority to command the system as a whole.

A strategist inside a regional mandate

The current title matters because it is both specific and limited. LACNIC lists Martinez-Cagnazzo as CTS / Chief Technology Strategist, not as its current chief technical officer. An APNIC author page uses the same Chief Technology Strategist description. Older LACNIC material identifies him as CTO, but that is a dated part of his career rather than a present office.

Treating the two titles as interchangeable would make a small biographical error and a larger analytical one: titles are evidence about the period in which authority was publicly assigned, not permanent attributes of a person.

LACNIC describes itself as the internet address registry for Latin America and the Caribbean, managing IPv4 and IPv6 address resources, autonomous system numbers and reverse resolution for the region. That mandate puts it near the administrative foundations of routing without making it the operator of the networks that use those resources. It can maintain registry functions, issue services related to number resources, support technical communities and participate in standardisation.

It cannot configure every router, vet every transit customer or determine every network's route policy.

This distinction explains both the importance and the modesty of a technology-strategy role at a registry. The institution has a regional view and relationships that individual operators do not possess. It can see recurring problems across networks, contribute to common technical tools, and help create forums in which operational practice is discussed. Yet much of the intended effect occurs outside its direct control. A more usable validation rule matters only when software incorporates it and relying parties operate that software.

A well-designed key-rollover mechanism matters only when the relevant authorities and validators implement it correctly. A training session matters only if entities carry useful knowledge back into their own networks.

The public title does not disclose a complete map of Martinez-Cagnazzo's decision rights. It does not show which budgets he controls, which operational changes require approval from others or how LACNIC divides responsibility among engineering, policy, executive and community bodies. A strategy title can easily invite inflated conclusions because it sounds wider than the available evidence.

The defensible claim is narrower: LACNIC publicly places him in its current technical-strategy function, and his record in standards, education and incident discussion is consistent with work conducted across institutional boundaries.

That boundary position differs from generic registry governance. Number-resource institutions are often described through elections, policy meetings and representation. Those features matter, but they are not the centre of this profile. Martinez-Cagnazzo's visible contribution is more technical and operational: questions about how authorisation is validated, how keys can change safely, how routing incidents are escalated, and how operators learn to apply shared controls.

Governance appears here not mainly as committee procedure but as the allocation of trust and responsibility in working infrastructure.

It also differs from a generic explanation of RPKI. The cryptography is only one part of the subject. The person-level question is what kind of work becomes necessary when a registry helps maintain a security system that it cannot impose on every network. The record suggests an answer built from translation between domains. Standards language has to be connected to validator behaviour. Registry authority has to be connected to operator decisions. A cross-border report has to reach the right institution.

Advice about route-origin authorisation has to reach people who can change a live configuration. The strategist's operating surface is the set of joins between those tasks.

This is why the absence of sweeping outcome figures should not be repaired with rhetoric. The sources reviewed here do not quantify how much RPKI deployment Martinez-Cagnazzo caused, how many routing incidents his work prevented or how operator behaviour changed after a particular session. They establish a credible field of contribution, not a personal scorecard for regional security.

The fairest measure of his significance begins with the problems he has helped make tractable and the forums in which he has done so, while keeping the final operating decisions with the networks and institutions that own them.

A technical career, without hindsight doing the work

LACNIC's staff biography describes Martinez-Cagnazzo as an electrical engineer whose early work involved planning and operating IP networks. It says that from 2005 to 2010 he worked in computer security, helped create Uruguay's first computer security incident response team, and taught computer security and networks at university. These claims come from the institution that employs him. They are suitable for establishing LACNIC's account of his background; they are not an independent audit of his responsibility for each project.

The wording around the Uruguayan response team deserves particular care. Helping to create and deploy a national capability is not the same as creating it alone. A response team is, by definition, an organisational achievement. It depends on colleagues, authority, procedures, contacts and continued operation after the founding moment. The biography supports participation in that work and a period of security practice. It does not identify every contributor, reconstruct the decisions or allow the result to be assigned to Martinez-Cagnazzo personally.

A historical LACNIC event profile provides the clearest dated sequence after that period. It says he joined LACNIC in 2010 as the first member of its Research and Development group, was appointed manager of the Security and Stability Program in 2013, and became CTO in 2014. It associates his interests and projects with internet measurement, internet exchange points, BGP and routing security, DNS security, DDoS mitigation and DNSSEC deployment.

Again, this is LACNIC's account of one of its senior technical figures, not independent proof that every programme outcome was his.

The chronology is nevertheless informative. It moves from operating IP networks to security work, then into a registry research function and a programme explicitly concerned with security and stability. The later CTO title is historical evidence that his institutional remit widened. His current strategist title suggests a further change in how LACNIC presents the role. What cannot be inferred is a neat private plan connecting each step.

Careers are usually shaped by organisational needs, available posts, collaborators and circumstances as well as personal intention. The record supplies a sequence of responsibilities, not a diary of motives.

That distinction protects the profile from a destiny narrative. It would be tempting to say that early incident-response work inevitably led to later regional responsibilities, or that electrical engineering naturally produced RPKI standards authorship. Neither follows. Many security practitioners never write an RFC, and many standards authors do not take on a registry strategy role.

The meaningful observation is that Martinez-Cagnazzo accumulated experience on both sides of a recurring divide: the design of shared technical mechanisms and the institutional response required when networks fail or are deceived.

LACNIC also says he has been involved in promoting IPv6 and DNSSEC adoption, RPKI implementation and deployment, the expansion of capacity-building activity including +RAICES, and the promotion of internet exchange points. These are broad institutional claims. They show the range within which LACNIC wants his contribution understood. They do not provide figures for adoption, isolate his part from that of colleagues, or establish that a named programme succeeded because of his decisions.

The correct use of the biography is to define a field of involvement, then look elsewhere for independent traces of particular work.

Two such traces are unusually durable: published standards. The IETF Datatracker profile lists two RFCs for Martinez-Cagnazzo, RFC 8360 from 2018 and RFC 9691 from 2024. The RFC bylines use the abbreviated form C. Martinez and give LACNIC as the affiliation. These documents do not reveal every meeting, review or compromise behind them. They do establish attributable co-authorship in a process whose output can be read independently of an employer's biography.

There is a further limit in the same IETF record. As observed for the evidence used here, it showed no active IETF role and no active internet draft for him, while listing expired drafts from earlier work. That does not diminish the two RFCs. It prevents a different exaggeration: published authorship should not be converted into a claim of a current formal IETF office or continuous control over subsequent work. Standards contributions persist even when a person's present role in the standards organisation is not active.

The resulting biography is less dramatic than the familiar story of an inventor changing an industry, and more useful. Martinez-Cagnazzo appears as a practitioner whose remit widened from networks and security into regional technical strategy, while leaving verifiable contributions at selected points. The record does not show him owning the whole security problem. It shows repeated participation where operational experience, institutional mandate and common technical rules have to be brought into contact.

Validation reconsidered: what RFC 8360 contributes

RPKI begins from an administrative fact: internet number resources are allocated through a hierarchy, but routing announcements are made by networks at the edge of that hierarchy. A Route Origin Authorisation, or ROA, allows the holder of address resources to state which autonomous system is authorised to originate routes for a prefix, subject to the terms represented in the authorisation. Validators collect signed material and determine what can be relied on. Operators may then use the resulting route-origin validation state as an input to routing policy.

That description can make the system sound almost mechanical. The hard questions appear when the certification hierarchy and the claims within it do not align cleanly. A parent certificate may constrain resources in a way that affects material below it. A subordinate entity may appear to claim beyond those bounds. If validation responds by discarding too much related material, an error or inconsistency at one point can have effects wider than the security objective requires.

A cryptographic system intended to reduce false routing claims can become operationally fragile if its failure behaviour invalidates otherwise useful information.

RFC 8360, Resource Public Key Infrastructure (RPKI) Validation Reconsidered, addresses that class of problem. Published on the Standards Track in April 2018, it names C. Martinez of LACNIC among its authors. At a high level, the document specifies an alternative validation procedure intended to retain security properties while reducing operational fragility. Its scope includes the treatment of overclaiming and consequences for validation of ROAs and BGPsec router certificates.

The title is revealing. Reconsideration is not abandonment. The problem was not that validation had no value, but that a security mechanism's behaviour under imperfect conditions needed closer attention. Infrastructure standards must contend with mistakes, transition states and partial inconsistency. A rule that is pure in a diagram may be hazardous if a small certification error causes relying parties to lose a much larger body of valid information. Conversely, a rule designed for operational tolerance must not quietly permit unauthorised claims.

The standards task is to define where rejection should stop.

This is the first way RFC 8360 illuminates Martinez-Cagnazzo's profile. It concerns the boundary between formal correctness and operational consequence. A regional registry works within a hierarchy of resource certification while serving organisations that depend on stable validation. Its technical strategists have reason to care both about the security meaning of a certificate and about the blast radius of a mistake. Co-authorship does not prove that Martinez-Cagnazzo personally supplied every insight in the document.

It does place him among the people who carried that operational problem into a standards-track answer.

The second lesson is that a published standard is collective authority. An RFC lists authors, but the result passes through review, discussion and the wider IETF process. Its language embodies more than one person's preferences. Calling Martinez-Cagnazzo an author is accurate. Calling him the sole designer, the controller of consensus or the person who made the internet adopt the procedure would not be. The evidence identifies contribution to a shared technical instrument; it does not allocate all intellectual credit or subsequent influence.

The third lesson concerns deployment. A standard can make an implementation possible or more coherent without showing that it is widely implemented. The document itself cannot establish which validator versions adopted its procedure, when operators installed those versions, how relying parties configured them or what routing outcomes followed. Those questions require separate implementation and operating evidence. RFC 8360 is therefore a result in one sense—a completed standards contribution—and not a result in another.

It is not a measure of security improvement attributable to one author.

That distinction is especially important in RPKI, where several actions must line up. Resource holders must create and maintain appropriate authorisations. Repositories and publication services must remain available. Validators must retrieve and process material correctly. Network operators must decide how validation states affect route selection or filtering. Staff must respond when an authorisation becomes stale or an announcement changes. A better validation model helps one part of this chain. It does not perform the others.

Nor should the RFC become an excuse to write a self-contained RPKI tutorial around Martinez-Cagnazzo. The person-level significance lies in the kind of problem selected. Validation reconsideration is boundary work: it asks how a cryptographic hierarchy behaves in the untidy operating world and how to contain error without surrendering the control. That concern recurs elsewhere in his record.

RFC 9691 asks how a root of trust can change keys without disrupting reliance, while his operator-facing work concerns the points at which formal controls have to become operating practice. Each problem occurs not inside a single component but at a transition between components, organisations or states.

There is also an institutional modesty in this form of standards work. A registry can contribute knowledge gained from operating close to resource holders, but a globally used mechanism must be legible beyond one region. Publishing through the IETF makes the proposal open to scrutiny and reusable by others; it also means LACNIC does not own the result. Martinez-Cagnazzo's affiliation is relevant context, not a claim that the standard expresses a unilateral regional policy.

The fair conclusion from RFC 8360 is thus precise. It shows a dated, attributable contribution to making RPKI validation less operationally brittle while preserving its security purpose. It strengthens the case that Martinez-Cagnazzo's technical-strategy work extends into the design of common infrastructure. It does not show how many routes became safer, which networks deployed the procedure, or whether any particular incident would have unfolded differently without it. Those outcomes remain outside the document's proof.

Trust has to survive a change of key

Trust anchors create a different transition problem. A relying party needs an initial basis for trusting the signed material it retrieves. In RPKI, that relationship is represented through a Trust Anchor Locator, which supplies information needed to find and validate the trust anchor. The arrangement is necessarily conservative: if the starting point of validation changes carelessly, material below it may become unreachable or untrusted. Yet cryptographic keys cannot sensibly be treated as eternal.

They may need to be replaced through planned operational practice, including changes associated with cryptographic equipment.

RFC 9691, A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs), addresses that tension. Published on the Standards Track in December 2024, it lists C. Martinez of LACNIC first among the authors. The document defines a signed RPKI object for Trust Anchor Keys. Its purpose is to support planned trust-anchor key rollover without disrupting RPKI validation, including successor-key signalling and an operational motivation involving migration between hardware security module vendors.

The subject can sound remote even by internet-infrastructure standards. It is, however, a concentrated form of governance. A trust anchor is a point at which a relying party accepts authority rather than deriving it from something higher in the same system. Changing the associated key therefore requires more than generating a fresh cryptographic pair.

The successor has to be signalled, the relying party has to recognise the transition, the relevant entities have to be published and retrieved, and the old and new states have to overlap or sequence in a way that avoids an accidental break in validation.

The TAK entity is an attempt to make that transition more explicit and manageable. It provides a signed means of representing information about trust-anchor keys and a successor. This does not abolish operational judgement. Someone still has to plan the rollover, protect key material, maintain publication, monitor relying-party behaviour and decide how to respond if the expected transition does not occur cleanly. The standard gives those actors a common entity and procedure around which to organise work.

Here again, Martinez-Cagnazzo's contribution is best understood as participation in the design of a boundary. The boundary is temporal rather than geographic: the system must pass from one trusted key to another while continuing to validate. A trust model that works only while nothing changes is not a durable operating model. RFC 9691 treats change itself as something that needs standardised signals, because otherwise local improvisation at a root of trust could impose uncertainty on every relying party below it.

The hardware-security motivation makes the issue tangible. Cryptographic keys are protected and used through equipment whose vendors, life cycles and operating characteristics can change. A registry or other trust-anchor operator may need to migrate. That procurement and security decision intersects with a validation ecosystem distributed across many networks. The change cannot be evaluated solely as a back-office equipment replacement because relying parties care about continuity of trust, not the reasons the hardware changed.

A common TAK profile is a means of connecting those two realities.

Authorship boundaries remain essential. Being first in a list of RFC authors is not sole authorship. It does not establish that Martinez-Cagnazzo originated every element, persuaded every reviewer or controlled the publication timetable. The standards record demonstrates a named contribution alongside other authors and through a collective process. Nor does publication prove that LACNIC, every regional registry or validator operator has completed implementation. The source establishes what the standard defines, not a census of adoption.

That absence of deployment evidence is analytically useful. It prevents the profile from substituting paper architecture for operating success. A trust-anchor rollover mechanism can be thoughtfully specified and still depend on software support, careful exercises and disciplined execution. A relying party that does not understand the new entity will not gain its benefits merely because the RFC exists. An authority that does not rehearse the procedure may still encounter trouble.

Public evidence of implementation guidance, validator support, rollover tests and post-change review would be needed to assess operational maturity.

RFC 9691 also brings a wider meaning to the word trust. Cryptography can authenticate a signed statement, but institutions decide which keys occupy the anchor position, how those keys are protected and how transitions are communicated. Operators decide which trust-anchor material to use and how to maintain it. Vendors implement the relevant entities. Standards communities define interoperable behaviour. Trust is therefore neither purely social nor purely mathematical.

It is a distributed arrangement in which mathematical verification is made dependable by repeated institutional action.

For a technical strategist at a regional registry, this is an unusually fitting problem. LACNIC's mandate concerns authoritative number-resource administration in a defined region, while RPKI validation extends across networks and borders. A trust-anchor operation must be locally controlled enough to be accountable and globally legible enough to be relied upon. Martinez-Cagnazzo's standards authorship does not make him the custodian of that entire relationship. It does show engagement with one of the mechanisms by which local authority is made interoperable.

The progression from RFC 8360 to RFC 9691 should not be treated as a personal master plan. Six years separate the publications, their author groups and technical questions differ, and the public record does not supply a private theory joining them. Their analytical connection is observable rather than psychological. One concerns containing the consequences of problematic certification claims during validation. The other concerns maintaining continuity as the key at an anchor changes.

Both ask how a security system behaves at a difficult edge, and both turn that question into a common technical procedure.

That is enough to support a restrained judgement. Martinez-Cagnazzo has contributed to standards that address not the sales pitch for RPKI but two of its maintenance problems: validation under imperfect resource relationships and trust during planned key change. These are the kinds of problems that appear after a security architecture is taken seriously as infrastructure. They do not generate an easy deployment statistic. They reveal attention to the conditions under which a system can continue to work.

Capacity building is part of the control surface

Standards work is often described as upstream from operations: experts define a mechanism, implementers build it and operators deploy it. In practice, the relationship runs both ways. Operational mistakes expose ambiguities in a standard. Training questions reveal where documentation is weak. Regional communities identify constraints that may be invisible to a small author group. A registry strategist who works only at the standards end risks producing a technically coherent answer that does not reach the people configuring networks.

The independent public evidence for Martinez-Cagnazzo's operator-facing work is modest but concrete. An ARIN-CaribNOG Technical Community Forum recap from May 2021 names him, then described by his historical LACNIC CTO title, as a featured speaker. It says he and Mark Kosters were joined by ARIN colleagues for a practical session covering RPKI, the Internet Routing Registry and internet number resources. The source comes from another regional registry and places him in a cross-registry educational setting rather than only on a LACNIC page.

The recap does not say that he taught alone, designed the whole session or caused attendees to adopt any control. It offers no before-and-after measurement of ROA creation, validation or routing policy. Its evidentiary value is narrower: by 2021, Martinez-Cagnazzo was publicly involved in practical instruction with peers from another registry, for a community whose networks connect island and continental jurisdictions. That is a real surface of technical strategy because regional routing security depends on operator competence beyond any one institution's service area.

LACNIC's biography adds a wider, institution-controlled account. It associates him with the promotion of IPv6 and DNSSEC adoption, RPKI implementation and deployment, expansion of the +RAICES capacity-building programme, and support for internet exchange points. These statements make capacity building part of LACNIC's presentation of his role. They should not be converted into a list of personal achievements.

Programmes have teams, partners, entities and funders; exchanges are built and operated by communities; technology adoption has many causes. The biography establishes claimed involvement, not isolated impact.

Why, then, treat instruction as more than public outreach? Because many routing-security controls are optional decisions made by autonomous networks. A registry can provide a service and publish guidance, but a network still has to understand what a ROA says, choose an appropriate maximum prefix length, operate a validator or consume validated data, and decide what policy follows from a route's state. Misunderstanding can create false confidence or unnecessary rejection.

The quality of deployment depends partly on whether operators can connect an abstract trust model to their own change procedures.

The same is true of Internet Routing Registry information and number-resource administration. The mechanisms differ, and they should not be collapsed into one security product. Yet operators encounter them together when documenting routing intentions, managing resources and evaluating announcements. A practical session that sets these tools side by side can help entities understand which claim each system makes and which it does not.

The value lies less in memorising labels than in avoiding the assumption that one registry record or signed entity removes every other verification duty.

Cross-registry education also performs institutional work. ARIN, LACNIC and Caribbean operator communities have different mandates and constituencies, while routes ignore those boundaries. Sharing technical material can create common vocabulary and contact familiarity before an incident. An escalation may later have to pass from one registry region to another and then through national or operator bodies. Education does not prove that such coordination will succeed, but the two activities inhabit the same relationship network.

Capacity building has limits that are easy to conceal. Attendance is not understanding. Understanding is not deployment. Deployment is not correct maintenance. Correct maintenance at one network does not secure an upstream that accepts a fraudulent customer. A session can be well designed and still reach only a small part of the operator community. No material reviewed for this profile provides measured adoption attributable to Martinez-Cagnazzo's teaching.

The honest result is participation in a practical, cross-registry educational effort, not a quantified change in regional practice.

This limited result still belongs in a person profile because it clarifies the nature of his technical authority. Martinez-Cagnazzo's standards record could otherwise make him look like a document author at some distance from network operations. The ARIN recap shows him in a setting where concepts have to be explained to practitioners alongside colleagues. LACNIC's biography describes a longer capacity-building interest.

Together they support the idea of a strategist translating between specification and use, while leaving the effectiveness of that translation open to evidence.

What the route-hijack case actually proves

The 2025 incident returns the analysis to a live boundary. According to the joint APNIC Blog account, the hijack involved social engineering directed at an upstream relationship. LACNIC escalated the matter to APNIC; APNIC contacted APJII and IDNIC; the upstream request was confirmed as fraudulent; and the BGP session was terminated. The article connects the episode with careful ROA MaxLength choices, Autonomous System Provider Authorisation, stronger provisioning checks and coordination among routing institutions.

Those facts support several conclusions, but not the most dramatic one. They show that Martinez-Cagnazzo and Sanjaya presented a technical account of a cross-region incident and used it to discuss weaknesses around routing authorisation and customer verification. They show an escalation path in which registries and operator bodies contributed different relationships or information. They do not identify Martinez-Cagnazzo as the sole investigator, establish that he made the termination decision, or provide a complete independent forensic record.

Because he is one of the authors, the article is partly a entity's account on an independent registry platform.

The case matters first because it distinguishes route-origin authorisation from business-relationship authorisation. A ROA concerns whether an autonomous system is authorised to originate a route for a prefix within the conditions represented by the entity. It does not say whether a transit provider has performed due diligence on the person asking to establish a service.

If an attacker can impersonate a legitimate party or present convincing resource information, weak onboarding may create the connection through which the false announcement is propagated. Cryptographic validity and customer legitimacy are related controls, not substitutes.

Second, the case illustrates why MaxLength deserves discipline. A ROA can cover a prefix and specify how specific an authorised announcement may be. Choices that permit more-specific routes can support legitimate network design, but overly permissive settings may leave room for announcements that the resource holder did not intend in practice. The joint article links the incident to this issue. The evidence used here does not provide a regional measurement of MaxLength configuration quality or show that behaviour changed after publication.

It supports the technical warning: authorisations should be made no broader than operational need requires.

Third, the authors discuss ASPA. The mechanism is intended to provide verifiable information about provider relationships, addressing a different part of route validation from origin authorisation. Its relevance to a socially engineered upstream arrangement is intuitive: the security of routing depends not only on who originates a prefix but also on whether the path's provider relationships make sense. Yet the case does not prove that ASPA was deployed widely enough to prevent the event, nor that it would remove the need for provider checks.

Standards and signed relationship information can make deception easier to detect; they do not interview the customer or close a suspicious account.

Fourth, the incident shows the value and cost of distributed escalation. No single institution in the described chain appears to possess every necessary relationship. LACNIC had reason to raise the issue. APNIC could work within its region. APJII and IDNIC brought national or operator-community connections. The provider controlled the session. This distribution limits unilateral authority, which can protect autonomy, but it can also slow response and make contact quality decisive.

Routing security therefore depends on maintained institutional pathways as surely as it depends on maintained repositories and validators.

The cross-border feature should not be romanticised. Coordination that succeeds in one reported case does not establish a universal response capability. The account does not tell readers how quickly every step would occur in a different time zone, with another provider, or where contacts were stale. It does not supply a comparative incident series. Its value is diagnostic. It reveals the kinds of organisations that may need to cooperate and the point at which a provider's commercial process becomes an internet-security concern.

The APNIC Routing Security SIG recap places these themes in the APRICOT 2026 and APNIC 61 community setting, where social engineering, RPKI, ASPA and trust-anchor constraints were discussed. It corroborates that the subject reached a regional technical forum rather than remaining only in LACNIC material. It does not provide a separate full biography of Martinez-Cagnazzo or transform the case study into independent proof of his personal impact.

The presentation context matters because incident accounts can change operating culture even when they do not introduce a new protocol. A concrete story can make a provider revisit onboarding, make a resource holder narrow an authorisation, or make a registry test its escalation contacts. But those are possible effects, not demonstrated results here. There is no survey showing what the audience changed. The responsible conclusion stops at public technical education based on a named case.

The case also guards against a narrow interpretation of strategy. A chief technology strategist could be imagined as someone concerned mainly with long-term architecture. Martinez-Cagnazzo's public account focuses on a failure in which an apparently ordinary service request met the permissive assumptions of inter-domain routing. The lesson spans standards development, operational configuration, provider process and institutional response. It is strategic precisely because no single patch resolves it.

That does not mean every layer has equal responsibility. The upstream provider controls its provisioning process. Resource holders control their authorisations. Software implementers control validator behaviour. Registries operate services and hold relationships within their mandates. Network operators set routing policy. Standards authors contribute common mechanisms. Good analysis assigns each actor the task it can perform, rather than using the complexity of the system to dissolve accountability.

Martinez-Cagnazzo's role in the public case is to help articulate the joins among those tasks, not to absorb them into his own record.

The most important result is therefore conceptual but operationally grounded. The case demonstrates that a signed authorisation does not authenticate the whole story by which a route enters the network. RPKI can strengthen a specific claim. ASPA can address another class of relationship information. Neither makes social engineering disappear, and neither removes the need for people who know how to escalate across institutions. Routing security improves when these controls overlap without being confused.

Technical strategy without the sovereignty illusion

Regional internet registries occupy an awkward position in debates about control. They are authoritative within defined resource functions, geographically organised and accountable through regional communities. Yet the internet they support is cross-border by design. A route originated in one economy may traverse providers in several others. A validator can rely on signed material produced under multiple trust anchors. A customer relationship formed in one jurisdiction can affect reachability far beyond it.

Regional authority is necessary, but it cannot be sovereign in the ordinary territorial sense.

Martinez-Cagnazzo's record makes that constraint visible. His current role is at LACNIC, whose mandate is Latin America and the Caribbean. His standards contributions were published through the IETF for interoperable use. The 2021 education record crosses LACNIC and ARIN communities. His work repeatedly begins from a regional base and ends in a shared operating problem.

This is where cross-border connectivity becomes a governance question rather than a map of cables. Connectivity depends on networks accepting and propagating one another's routing claims. The institutions that allocate resources, publish authorisations, standardise validation and respond to abuse have to make their claims mutually intelligible.

A failure of translation—between a resource record and a provider process, between one registry's report and another region's contacts, or between a new signed entity and old validator behaviour—can become a reachability failure.

A technical strategist in this setting cannot promise control over outcomes. The useful contribution is to reduce ambiguity at the boundaries. RFC 8360 narrows the consequences of problematic certification relationships. RFC 9691 provides a profile for signalling trust-anchor keys and succession. Operator education connects those mechanisms to practice. Incident discussion identifies where formal controls stop and human verification begins. The pattern is not command from the centre but the construction of more dependable hand-offs.

This also explains why institutional claims must remain attributed. LACNIC says Martinez-Cagnazzo contributed to RPKI deployment, IPv6 and DNSSEC promotion, capacity-building expansion and internet exchange point activity. Those are plausible parts of a regional technical remit, but the institution is describing its own senior employee. Without independent outcome data, the claims should be read as a declaration of involvement and priority.

The standards documents and third-party event recaps provide narrower corroboration, not a licence to treat the whole regional agenda as his achievement.

The restraint matters because infrastructure work is intrinsically collaborative. A person profile can easily distort it by assigning every institutional result to the most visible title. That produces an attractive protagonist at the cost of understanding the system. Martinez-Cagnazzo is more interesting when his authority is kept bounded.

His record shows how an individual can matter in a distributed environment: by contributing language that others can implement, bringing operational problems into common forums, and participating in relationships that allow action to pass from one institution to another.

There is no evidence here that this model always succeeds. Standards can wait years for implementation. Training can fail to change practice. Contact networks can be incomplete. Providers can accept fraudulent requests. Trust-anchor changes can be postponed because the perceived operational risk is high. The boundary role is not a solution in itself. It is a way of organising attention around points where no actor can succeed alone.

The uncertainties are part of the judgement

The first watchpoint is deployment evidence. The record supports Martinez-Cagnazzo's co-authorship of two RFCs, LACNIC-attributed involvement in several technical programmes, participation in an operator forum and joint public analysis of one incident. It does not quantify validator adoption of RFC 8360, implementation of RFC 9691, RPKI use caused by his work, or reductions in hijacks across the LACNIC region.

Future assessment should look for implementation records, operational reports and independently described changes rather than infer effects from publication alone.

The second is the boundary of his current title. The authoritative public staff listing identifies him as CTS / Chief Technology Strategist. Historical LACNIC and ARIN material uses CTO for the periods it describes. The available public pages do not disclose the full difference in decision rights between those roles. Analysts should not continue the old title into the present, and they should not assume that the strategist title confers sole authority over LACNIC's engineering, security services or standards positions.

The third is ASPA adoption and operational use. The 2026 case study treats provider authorisation as relevant to the class of problem exposed by a fraudulent upstream relationship. That makes ASPA an important watchpoint, not a demonstrated outcome. Evidence would need to show production support, publication by relevant networks, consumption by validators or routing systems, and operating policies that use the information appropriately.

Even substantial adoption would not eliminate customer verification; it would add another verifiable constraint to the routing relationship.

The fourth is ROA MaxLength discipline. The case study uses the incident to emphasise careful authorisation. The unresolved question is whether resource holders understand and maintain the narrowest settings compatible with their routing plans, and whether operational changes trigger timely review. A MaxLength value can be correct for a network that legitimately originates more-specific prefixes and unnecessarily permissive for another. Counting ROAs alone would not answer the question.

Useful evidence would examine configuration quality, stale authorisations and how operators correct them.

The fifth is trust-anchor operation after RFC 9691. A signed TAK entity is a standards result; a safe rollover is an operational result. Observers should distinguish the two. The relevant evidence would include support in relying-party software, published operational guidance, exercises, monitoring, handling of incompatible validators and a completed change that preserves validation continuity. Hardware-security migration is one motivation, but the public record used here does not show which trust-anchor operators have carried out such a transition with the new profile.

The sixth is attribution for LACNIC programmes. The institution's biography gives Martinez-Cagnazzo a wide field of involvement, from IPv6 and DNSSEC to RPKI, +RAICES and internet exchange points. Future profiles should resist turning every positive regional indicator in those fields into proof of his impact. The stronger evidence would identify a decision he made, collaborators who describe the division of work, the intervention that followed and a result measured at the appropriate level.

Until then, the biography is a reliable statement of how LACNIC presents his contribution, not an independent performance evaluation.

The seventh is the durability of cross-registry incident coordination. The reported 2025 case ended with confirmation of fraud and termination of a BGP session. What remains unknown is how repeatable the pathway is across other registries, national communities and providers. Contact lists change. Escalation standards differ. Evidence of exercises, shared procedures and additional incident accounts would show whether the coordination was institutionalised or depended heavily on particular personal relationships.

The eighth concerns public technical education. The ARIN-CaribNOG recap establishes that Martinez-Cagnazzo participated in a practical session, but it does not show what attendees implemented. Capacity-building should be assessed with more than event counts. Follow-up configuration work, sustained operator communities, local trainers, validated deployments and entity evidence would offer a firmer view. This is not a demand that every educational event produce a clean causal metric.

It is a reminder that speaking and system change occupy different evidentiary categories.

The ninth is his current standards activity. The IETF profile records the two published RFCs but, at the time reflected in the reviewed material, no active IETF role or active draft. That is a snapshot, not a judgement on continuing influence. It means this profile should describe completed standards authorship rather than imply a current formal IETF position. New drafts, implementation work or operational guidance would change the picture and should be evaluated when they appear.

The tenth is a historical governance claim. The older LACNIC event biography says Martinez-Cagnazzo had been appointed to ICANN's Security and Stability Advisory Committee at that time. The evidence reviewed here does not establish present membership. The claim belongs, if used at all, to the dated biography. It should not be carried into a current list of offices without a current authoritative source.

These uncertainties do not amount to a hidden negative case. No evidence reviewed here supports allegations of personal failure, improper conduct or exaggerated credentials. The limits arise because first-party biographies, standards documents and event recaps answer different questions. A biography can establish how an institution describes a role. An RFC can establish authorship and technical scope. A case study can provide a entity account. An event recap can corroborate presence. None substitutes for measured deployment or a complete allocation of responsibility.

Keeping those categories separate produces a more credible assessment. Martinez-Cagnazzo's record is strongest where the evidence is most durable: current LACNIC title, dated career milestones attributed to LACNIC, named co-authorship of two RFCs, a joint published incident account, and independently hosted evidence of cross-registry technical education. It is weakest where infrastructure profiles often become inflated: personal causation, regional adoption, prevented incidents and institution-wide outcomes.

The correct response is not to fill the gaps with plausible assumptions, but to make them visible as questions for future observation.

The authority to connect, not to command

Carlos Martinez-Cagnazzo's career is a study in how technical authority works when no institution owns the whole problem. LACNIC can administer number resources and operate services within its mandate. The IETF can publish interoperable standards. A provider can accept or terminate a BGP session. Operator communities can teach, compare and escalate. Relying parties can validate signed material. Each actor controls something consequential; none can secure inter-domain routing alone.

His public significance lies in moving among those partial authorities. LACNIC's account places him in network operations, security, research and later senior technical roles. RFC 8360 records a contribution to containing validation fragility. RFC 9691 records a contribution to planned trust-anchor key rollover. The ARIN-CaribNOG recap places him alongside peers explaining resource and routing tools. The APNIC case study places his technical voice in a multi-party account of social engineering and route hijacking.

The record does not justify the grander claim that Martinez-Cagnazzo transformed regional routing security. There are no figures connecting his decisions to deployment, no basis for assigning IETF consensus to him, and no evidence that a single strategist determined the outcome of the reported incident. Those absences are not editorial inconveniences. They describe the system in which he works. Results are distributed because authority, implementation and risk are distributed.

What can be said is more specific. He has helped address the moments when a formal security model encounters change or human weakness: a certification relationship that overclaims, a trust anchor that must change keys, an operator who must understand several sources of routing information, and an upstream request whose convincing story is false. These are not peripheral details. They are where an infrastructure control proves whether it can survive the conditions of use.

The measure of a boundary strategist is therefore not the number of systems he can be said to own. It is whether the connections become clearer and more dependable: whether standards contain failure sensibly, whether operators understand the limits of authorisation, whether trust transitions can be rehearsed, and whether institutions can reach one another before a routing anomaly becomes prolonged harm. The available evidence shows Martinez-Cagnazzo contributing to that work. It leaves the scale of the outcome open.

That is the restrained conclusion his record supports. Routing security is not made by cryptography alone, and it is not made by personal authority. It is assembled from precise claims, careful operations and institutions willing to coordinate across their own boundaries. Martinez-Cagnazzo matters because his work has repeatedly occupied that difficult middle ground—not as its sole architect, but as one of the technical strategists trying to make it hold.