Resumen

  • El blog de LACNIC diferencia martians, bogons asociados al estado de los recursos y anuncios RPKI Invalids. El autor presenta el texto a título personal y aclara que sus opiniones no necesariamente representan a LACNIC.
  • Las categorías pueden formar parte de una política razonable, pero requieren tres relojes de evidencia: el registro de direcciones de propósito especial, una instantánea de estado de recursos y la vista de ROA validada por una caché.
  • RFC 6811 define Invalid frente a datos de autorización de origen validados; permite que las cachés locales difieran y deja a cada operador la acción que tomará ante el resultado.
  • La forma responsable de informar un total es adjuntar un recibo de categorías y tiempos, no publicar rutas ni declarar que un único número demuestra una mitigación uniforme.

El nombre de un descarte no explica su causa

La nota de LACNIC sobre martians, bogons y RPKI Invalids parte de una distinción que suele desaparecer al final de una cadena de filtrado. Un martian se relaciona con espacio reservado para usos especiales. Un bogon, según la explicación de la nota, puede estar ligado a recursos que aún no tienen el estado de delegación o asignación esperado. Un resultado RPKI Invalid trata otra relación: una ruta, un prefijo y un sistema autónomo de origen que no satisfacen la autorización que se ve en los datos ROA pertinentes.

Separar los términos no equivale a atribuir una norma a LACNIC ni a diagnosticar una red de América Latina y el Caribe. Sergio Kleiman firma el artículo como arquitecto y gerente de redes, y el propio texto advierte que las opiniones vertidas no representan necesariamente a LACNIC. No ofrece un censo regional, no identifica rutas, ni afirma que todos los operadores rechacen un estado de validación concreto. Su contribución permite hacer una pregunta más exacta: cuando una regla actúa, ¿qué fuente definía esa categoría y en qué momento fue consultada?

La primera respuesta procede del registro de direcciones IPv4 de propósito especial de IANA. Ese registro organiza propiedades de espacios de dirección particulares. Si una política usa esas propiedades, una explicación posterior necesita retener la versión, revisión o momento de consulta que la sustentó, junto con el ámbito IPv4 o IPv6 aplicable. Sin esa referencia temporal, un resultado puede parecer una cualidad permanente de la dirección cuando en realidad depende de los datos con los que se evaluó la regla.

El reloj de los bogons basados en recursos es otro. La guía subraya que las listas cambian cuando los registros hacen disponibles, delegan o asignan recursos. Por ello, una observación de esta clase debería poder ligarse a una instantánea de estado. Una lista conservada demasiado tiempo puede producir una decisión que exija revisión; una asignación posterior tampoco reescribe por sí sola lo que la lista decía antes. La cuestión de control es poder distinguir actualización de recursos, retraso de distribución de la lista y resultado de una regla local.

El tercer reloj pertenece a la validación de origen. RFC 6811 describe Invalid cuando existen datos ROA validados que cubren la ruta, pero ninguno autoriza el par formado por el prefijo y el AS de origen. El RFC también contempla que dos cachés locales no tengan exactamente el mismo contenido, por su calendario de actualización o de recuperación. Y fija una frontera decisiva: el protocolo ofrece un estado de validación; la política de aceptar, preferir, registrar o rechazar es local. Además, comprobar el origen no comprueba el camino completo que recorrió la ruta.

Por eso, una cifra que agrupe los tres casos puede servir como indicador de carga y aun así ser insuficiente como explicación. No prueba que las rutas compartieran un fallo, que fueran equivalentes en riesgo, que provinieran del mismo tipo de vecino o que una medida concreta las haya corregido. Tampoco autoriza a tratar una discrepancia de datos como una falta atribuible a un tercero. La agregación es útil sólo si conserva la posibilidad de desagregar la evidencia que la produjo.

Un recibo permite corregir sin revelar la red

El registro público no necesita incluir prefijos, AS, pares, nombres de clientes, dispositivos, tickets ni fragmentos de configuración. Puede limitarse a una fila por categoría que indique la fuente y su versión o instantánea, hora de obtención, hora de observación, familia de direcciones, dirección de tráfico, clase amplia de vecino, acción local, clase de excepción y cuenta agregada. Puede incluir también la frecuencia de actualización y un canal responsable de corrección.

Esa información separa tres clases de respuesta. Un dato de propósito especial exige comprobar su fuente; un bogon de recursos puede requerir actualizar una instantánea; un Invalid puede conducir a revisar una autorización de origen o una excepción local. Ninguna de esas posibilidades demuestra, por sí sola, que haya existido una incidencia o que una intervención la haya resuelto. Pero el recibo mantiene la trazabilidad necesaria para averiguarlo sin convertir la transparencia en una exposición operativa.

Fuentes