Summary

  • LACNIC policy defines routing-c as the contact who may register the routing policies adopted by an ASN through the IP and ASN administration system.
  • The field does not reveal who has router credentials, who operates BGP sessions, whether a declared policy is deployed, or which origins and paths are visible now.

A role with a specific verb

The decisive word in LACNIC’s definition is “register.” The routing-c contact can enter routing-policy information through the resource-administration system. That role affects a consequential public evidence surface: operators may consult registry and IRR data when building filters or evaluating an ASN’s intended announcements.

Registration authority is not trivial. Analysts should record the handle, the object in which it appears, the retrieval time and the policy or route objects associated with the ASN.

But the field does not contain a router login, configuration snapshot, BGP session state, route collector observation or employment record. It says who may register policy, not who typed the last command on a router or who is on shift in the network operations centre.

Three contact roles, three questions

LACNIC policy separates owner-c, routing-c and abuse-c into distinct contact fields. For this analysis, the source-defined function that matters is narrow: routing-c may register the routing policies adopted by the ASN.

The separation prevents a common attribution error. Because the record does not disclose router access, BGP session control or the operating team, routing-c alone cannot establish the human operational role.

Declared policy and observed routing

LACNIC describes an Internet Routing Registry as a database in which operators express routing policy so other parties can use the information when configuring filters and equipment. The declaration has operational value, but it remains a declaration. It may be incomplete, stale, more permissive than current announcements or implemented differently across routers.

Observed BGP supplies a different view. Time-aligned collector data can show that a prefix was announced with a given origin and path at particular vantage points. That still does not identify the human operator, prove universal visibility, establish traffic flow or reveal the internal command chain. RPKI can add route-origin authorization evidence, but authorization is again distinct from observation and human operation.

A defensible attribution therefore joins evidence without collapsing it: the exact LACNIC ASN and contact records; relevant IRR and RPKI artifacts; timestamped BGP observations; and current organizational evidence for the team or provider actually responsible for network operations.

Sources