Resumen

  • APNIC exige referencias IRT al crear o actualizar objetos inetnum, inet6num y aut-num para dirigir incidentes hacia una superficie de contacto especializada.
  • La referencia prueba una asociación registral en el momento observado; no prueba control de routers, origen BGP activo, transporte, disponibilidad, culpabilidad ni propiedad.

Un enlace obligatorio con una tarea concreta

APNIC hizo obligatorias las referencias a Incident Response Teams en noviembre de 2010. La medida separó el manejo de abuso de los buzones administrativos o técnicos generales. Por eso un registro de recursos incluye mnt-irt, mientras que el objeto IRT relacionado contiene abuse-mailbox, contactos administrativos y técnicos, autenticación y mantenimiento.

El diseño ofrece una ruta pública de escalamiento. Desde 2019, además, APNIC exige validar los contactos IRT cada seis meses y permite reportar direcciones inválidas o que no responden. El registro conserva así una asociación de contacto designada y un estado de validación limitado en el tiempo.

Pero no convierte al contacto en operador. APNIC describe las IRT como equipos especializados en incidentes de seguridad y distintos de los departamentos de operación de red. El puntero identifica el objeto de contacto para incidentes; no identifica al departamento que opera la red ni establece una relación organizativa entre ambas funciones.

abuse-c deriva del mismo origen

APNIC publica también abuse-c en los registros de recursos. Su documentación explica que apunta a un objeto de rol con los mismos datos de contacto visibles en el IRT del miembro y que se genera a partir de ese objeto. Para cambiar la información hay que modificar el IRT.

Por tanto, la presencia conjunta de mnt-irt y abuse-c no equivale a dos testigos independientes. Es la coherencia interna de dos vistas de un mismo modelo. No demuestra que el buzón controle la infraestructura ni que su titular haya causado o autorizado un incidente.

La validación semestral tampoco es una garantía eterna. Prueba que el proceso registral obtuvo una validación en una fecha determinada. La capacidad actual de recibir, comprender y resolver un reporte necesita una prueba actual, con entrega y respuesta registradas por separado.

Cada campo conserva su autoridad

La guía de inetnum separa admin-c, tech-c, abuse-c, mnt-by, mnt-irt y mnt-routes. mnt-by protege cambios en el objeto de base de datos; mnt-routes controla la creación de objetos de ruta asociados; el contacto técnico desempeña otra función. Ninguno observa por sí mismo paquetes atravesando un router.

El origen efectivo requiere observaciones BGP con fecha. La autorización de ruta requiere evidencia de IRR y RPKI. La disponibilidad exige mediciones activas, y la propiedad exige documentación jurídica y corporativa. El contacto IRT puede iniciar esas comprobaciones, no reemplazarlas.

Los Registros Nacionales de Internet introducen otra frontera. APNIC advierte que ciertas consultas remiten a un NIR y que puede ser necesario consultar su base para encontrar al ISP pertinente. Esa remisión orienta la investigación; no demuestra que APNIC o el NIR opere la red.

Cómo formular el hallazgo

Conserve el recurso consultado, el valor exacto de mnt-irt, los objetos IRT y abuse-c enlazados, la base de origen y la hora de consulta. Escriba: «En el momento observado, este registro de APNIC vinculaba este objeto IRT como ruta de contacto para incidentes».

Anote por separado si el buzón fue probado, quién opera la red, qué ASN originó el prefijo, quién puede crear objetos de ruta y quién posee jurídicamente el recurso. La separación evita convertir un contacto útil en una atribución que la base nunca hizo.

Fuentes