Resumen

  • El IESG abrió el 28 de agosto el Last Call de draft-ietf-sidrops-publication-server-bcp-10, destinado a Best Current Practice; el Datatracker fija el cierre para el 11 de septiembre.
  • El texto adopta los términos de BCP 14, pero añade que las mayúsculas enfatizan importancia operativa y no constituyen requisitos formales de implementación.
  • Un BCP publicado acreditaría revisión y consenso documental. No probaría que un servicio concreto aplicó cada práctica, mantuvo sus niveles durante un periodo o se recuperó bien de un incidente.
  • Hace falta un recibo por secciones: versión, arquitectura, estado, excepción, definición de medida, ventana, restauración, reinicio RRDP, aviso a autoridades de certificación, resincronización y observación independiente acotada.
  • Las fuentes no declaran conforme o incumplidor a ningún operador ni convierten al IETF en auditor, regulador o parte de un contrato de servicio.

La publicación es el tramo que no aparece en la firma

Una autoridad de certificación produce objetos RPKI firmados. Después, un motor acepta publicaciones y retiradas mediante RFC 8181. Los repositorios RRDP y rsync ofrecen el estado al público. Los relying parties descargan, validan y construyen datos que los operadores de red pueden emplear en sus políticas.

El Last Call iniciado el 28 de agosto se concentra en ese tramo intermedio. La versión 10 de Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services reúne prácticas sobre disponibilidad, separación funcional, pérdida de datos, sincronización, dependencia de DNS y rutas, CDN, instantáneas, deltas y equilibrio de carga. No propone que una firma cambie de significado; pregunta cómo se conserva y entrega de forma fiable lo ya firmado.

La distinción es esencial. Una ROA puede ser válida y no haber alcanzado todavía el repositorio visible. El motor puede aceptar una operación mientras una réplica sigue atrasada. Una restauración puede devolver el sistema a un estado anterior sin que la autoridad de certificación consulte inmediatamente. Dos nodos pueden ofrecer vistas distintas durante una transición. Ninguno de esos estados se resuelve preguntando únicamente si el objeto posee una firma correcta.

Por eso el documento no es una lista de consejos accesorios. Describe el lugar donde una intención criptográficamente auténtica puede quedar operativamente pendiente.

Una norma fuerte sin organismo de certificación

RFC 2119 y RFC 8174 dan un significado preciso a MUST, SHOULD y otras palabras cuando aparecen en mayúsculas. La primera representa una exigencia absoluta de la especificación. La segunda admite razones válidas para apartarse, siempre que se comprendan y ponderen sus consecuencias.

El borrador de publicación incorpora ese lenguaje y acto seguido limita su uso: las palabras resaltan la importancia para la operación; no se exigen como requisitos formales de implementación.

No hay contradicción si se mantienen separados tres planos. Primero, el plano técnico: ciertas acciones son críticas para evitar estados incoherentes o irrecuperables. Segundo, el plano documental: el IETF puede decidir que esas acciones describen la mejor práctica actual. Tercero, el plano probatorio: ni el texto ni la mayúscula inspeccionan la infraestructura de un operador.

RFC 7841 explica qué comunica la categoría de un RFC y qué revisión recibió un documento del flujo IETF. Si este trabajo culmina como BCP, esa procedencia le dará peso. No otorgará por sí sola un certificado a un RIR, NIR, proveedor comercial o repositorio propio. Tampoco definirá el alcance de una auditoría, el periodo cubierto o el remedio contractual por una caída.

Una práctica consensuada y una implementación comprobada son objetos distintos. El prestigio del primero no puede suplir la evidencia del segundo.

Separar escritura, distribución y observación

El proyecto recomienda que el motor orientado a las autoridades de certificación funcione en máquinas distintas de las que atienden RRDP y rsync. La razón es sencilla: una carga elevada sobre la distribución pública no debe impedir que los editores registren cambios.

Esa arquitectura produce tres superficies medibles. El motor puede estar disponible para publicar. RRDP puede estar disponible y fresco para recuperar. rsync puede ofrecer su propia vista. Un único indicador de disponibilidad mezcla causas y consecuencias que no son equivalentes.

La indisponibilidad del motor impide distribuir nuevas emisiones y revocaciones de ROA, ASPA o certificados BGPsec. Si se prolonga, manifiestos, listas de revocación y objetos firmados pueden quedar obsoletos. La indisponibilidad pública bloquea la recuperación normal por los relying parties. Una interrupción corta, sin embargo, puede quedar absorbida por cachés todavía válidas. La métrica necesita un reloj de frescura, no sólo respuestas a sondas.

El documento recomienda medir la ida y vuelta: comparar cuándo se espera que aparezca un objeto reemitido y cuándo se observa realmente. La medida debe indicar evento inicial, evento final, puntos de observación, periodo, percentiles, fallos y exclusiones. Decir que el puerto HTTPS respondió no demuestra que la intención nueva atravesó todo el camino.

También se recomienda anunciar las ventanas de mantenimiento. Puede publicarse una prueba útil sin revelar contactos privados ni un mapa defensivo: inicio previsto y real, superficie afectada, antelación del aviso, impacto declarado, desviación y cierre.

Una recuperación produce varios hechos

El escenario más revelador del borrador es la pérdida de datos. Si una restauración provoca regresión de contenido, el servidor debe iniciar una nueva sesión RRDP. El operador debería informar cuanto antes a las autoridades dependientes para que puedan resincronizarse por completo.

La autoridad de certificación, por su parte, debería consultar la lista que el servidor reconoce antes de enviar cambios. Las operaciones destinadas a formar un solo conjunto deberían viajar dentro de una solicitud de varios elementos, reduciendo el riesgo de un efecto parcial incoherente. Una comprobación periódica sin cambios es posible, aunque el texto desaconseja hacerla con mayor frecuencia que cada diez minutos salvo acuerdo, porque RFC 8181 no ofrece una señal adecuada de espera o limitación.

Un informe serio puede unir estos pasos: copia restaurada, antigüedad conocida, regresión detectada, sesión RRDP reiniciada, editores notificados, estado listado, conjunto íntegro reenviado y resultado visto desde fuera. Un tablero de uptime no dice si las altas recientes de editores sobrevivieron ni si una retirada volvió a aparecer por usar una copia vieja.

La corrección debe ser aditiva. Si el primer diagnóstico atribuyó el problema a una réplica y después se halló una restauración incompleta, el segundo estado se agrega con su evidencia. Borrar el primero destruye la historia necesaria para aprender.

Ni el serial ni el manifiesto son certificados de servicio

RRDP proporciona un identificador de sesión, un serial, instantáneas y deltas. Facilita que un relying party sepa si puede continuar desde su estado o necesita una sincronización completa. Sus archivos inmutables también permiten usar cachés con eficiencia.

Pero un serial creciente sólo describe revisiones dentro de una sesión observada. No confirma que todos los nodos publicaran a la vez, que el servidor aceptara el conjunto pretendido por el editor o que todos los relying parties lo recuperaran. El borrador exige que el archivo de notificación no sea visible antes de los archivos que referencia y que los backends ofrezcan una vista consistente. El orden es parte de la verdad.

RFC 9286 permite detectar determinadas sustituciones por versiones antiguas, eliminaciones o modificaciones mediante una lista firmada de archivos y hashes. Es una garantía técnica precisa, no una opinión sobre el plan de mantenimiento, la topología dual, la antigüedad de la copia, la atención al editor o la configuración del CDN.

El problema de gobernanza aparece cuando todas esas dimensiones se esconden detrás de cumple el BCP. ¿Qué sección? ¿Qué versión? ¿Qué arquitectura? ¿Quién lo observó y cuándo? Sin respuestas, la frase puede ser comercialmente útil y probatoriamente vacía.

Preferir concentración no equivale a conceder autoridad

La experiencia recogida en el borrador indica más problemas de disponibilidad en repositorios autoalojados que en servicios de organizaciones especializadas. Muchos puntos pequeños también incrementan el trabajo de los relying parties. De ahí la recomendación de que las autoridades padre ofrezcan publicación y de que sus hijas la utilicen; un tercero fiable puede servir cuando el padre no lo hace.

Es una preferencia de operación y escala. No es una licencia exclusiva para que una institución controle la publicación. El texto reconoce que un repositorio pequeño y poco cambiante puede alcanzar alta disponibilidad con medios modestos. También admite opciones distintas para autoridades descendientes y obliga a ponderar dependencias.

Lo mismo sucede con el alojamiento en direcciones y sistemas autónomos que no dependan exclusivamente de la propia autoridad publicada. La separación reduce un bucle en el que el repositorio no puede distribuir el objeto que repararía su alcance. A la vez, utilizar infraestructura de otra organización introduce una dependencia diferente. La mejor práctica exige una decisión explícita, no una respuesta idéntica en todas las redes.

El recibo debe registrar el modelo escogido y el razonamiento acotado. No aplica es aceptable. Sí, cumplimos todo sin detalles no lo es.

El recibo que falta

Primero, identidad: operador, servicio, arquitectura, identificadores públicos y versión exacta del documento. Una mención sin versión envejece en cuanto cambia el borrador.

Segundo, registro de controles: una fila por sección material con estado implementado, no aplicable, planificado, excepción o desconocido; fecha, responsable y motivo. No se publican claves, credenciales, identidades privadas ni detalles que faciliten un ataque.

Tercero, definición de evidencia. La disponibilidad conserva denominadores separados. La propagación define sus extremos. La coherencia de nodos se prueba con un método seguro. La caché de notificaciones indica regla y observación. Los fallos y exclusiones no desaparecen del cálculo.

Cuarto, cambios e incidentes: mantenimiento, regresión, nuevo identificador de sesión, avisos, resincronización, reconciliación y asuntos abiertos. Las correcciones son nuevas versiones.

Quinto, procedencia: declaración del propio operador, medida externa, auditoría contractual o revisión posterior al incidente. La ficha nunca atribuye al IETF una certificación inexistente.

El resultado no garantiza rutas. Hace más estrecha una afirmación y, por ello, permite comprobarla.

Límites de la noticia

El Last Call no ha aprobado el texto. No existe aún número de RFC o BCP. Los comentarios pueden producir revisiones y el IESG todavía debe evaluar el documento.

Las afiliaciones de los autores no acreditan la práctica de sus organizaciones. Las fuentes no muestran una caída encubierta ni una recuperación fallida de un operador nombrado. Tampoco convierten el BCP en ley, contrato o decisión de encaminamiento.

Lo probado es más útil que una acusación: existe ahora una propuesta detallada para operar el tramo de publicación RPKI. Su posible autoridad documental será real. La evidencia de adopción seguirá perteneciendo a cada operador y a quienes lo observen.

Fuentes

  1. IESG — Last Call del borrador sobre servicios de publicación RPKI
  2. IETF Datatracker — registro vigente del documento
  3. IETF Datatracker — versión 10 del borrador
  4. RFC 2119 — palabras de nivel de exigencia
  5. RFC 8174 — uso normativo de las mayúsculas
  6. RFC 7841 — flujos, categorías y textos de estado
  7. RFC 8181 — protocolo de publicación RPKI
  8. RFC 8182 — RPKI Repository Delta Protocol
  9. RFC 9286 — manifiestos RPKI
  10. RFC 7115 — operación de la validación de origen RPKI