RPKI y anclas de confianza

Las anclas de confianza son la herramienta que tienen las partes que confían (es decir, las personas que desean usar una infraestructura de clave pública (PKI) para validar atestaciones firmadas digitalmente) para validar todos los artefactos firmados digitalmente en esa PKI. En el mundo de los certificados X.509, la validación requiere que la parte que confía construya una cadena de certificados donde cada eslabón de la cadena corresponda a una autoridad de certificación cuya clave privada ha firmado el siguiente certificado de clave pública (o su subordinado inmediato) en la cadena.

Esta cadena de relaciones emisor/sujeto finaliza con el Certificado de Entidad Final de la clave pública utilizado en el certificado digital. En el otro extremo de esta cadena hay un certificado autofirmado en el que la parte aceptante está dispuesta a confiar, cualquiera sean las circunstancias.

Normalmente, dentro del contexto de una determinada PKI, las anclas de confianza estarían ampliamente distribuidas. Se espera que cada parte que confía aprenda estas anclas de confianza de una manera en la que esté preparada para confiar. Pienso que las razones de esto son bastante obvias, pero para ilustrar lo que podría salir mal si una parte que confía simplemente cree todo lo que le dicen, pensemos lo siguiente: un potencial atacante podría representar un certificado autofirmado que haya creado para que este ataque sea un ancla de confianza y presente a la víctima un objeto firmado digitalmente, una cadena de certificados y esta supuesta ancla de confianza.

Típicamente, un ancla de confianza está ampliamente distribuida dentro de una PKI y almacenada localmente en caché por cada parte que confía dentro de esta PKI. Por lo tanto, es preferible que el ancla de confianza de una PKI sea muy estable y cambie con poca frecuencia o que no lo haga en absoluto, ya que cualquier cambio debe propagarse entre todas las partes que confían.

Esto es similar a la función de la clave para firma de claves (KSK) en DNSSEC. Como vimos en el ejercicio reciente de cambio del valor de la KSK, asegurarse de que todas las partes que confían estén sincronizadas con este cambio y reemplacen su confianza en la antigua ancla de confianza por confianza en la nueva ancla de confianza es un asunto complicado. Por lo tanto, nos gustaría que las anclas de confianza fueran estables y duraderas, y normalmente cambiaríamos el valor de la clave del ancla de confianza con poca frecuencia o no lo haríamos nunca. Y si va a cambiar, sería mejor que esta ancla de confianza cambie en momentos previstos y bien señalados para que las partes que confían puedan administrar su confianza en sincronía con estos cambios.

Ahora agreguemos una consideración adicional sobre PKI de recursos (RPKI). El ancla de confianza también debe incluir un conjunto de recursos numéricos IP que estén dentro del “alcance” de esta ancla de confianza. La consecuencia es que el material de confianza se debe cambiar cada vez que cambia el conjunto asociado de recursos numéricos dentro de este alcance. Esto es válido tanto para los certificados de anclas de confianza autofirmados como para todos los demás certificados RPKI. Si bien los cambios en los valores de las claves se pueden planificar, los cambios en la titularidad de los recursos no son necesariamente tan predecibles, lo que tiene implicaciones de diseño para las anclas de confianza de RPKI.

RPKI introdujo un giro sutil en la interpretación convencional de los certificados de clave pública X.509.

De manera informal, una PKI construye una estructura de confianza transitiva que permite que una parte que confía responda la pregunta: ¿Esta firma digital es genuina? Esta pregunta se transforma en una pregunta ligeramente diferente: ¿La clave pública es parte del par de claves que se usa para generar la firma que pertenece a la parte que afirma haber generado esta firma?

Dado que la parte que hace esta pregunta puede no conocer a la parte firmante o su clave pública, la PKI es útil para responder una variante de esta pregunta: ¿Hay personas en las que confío que conozcan a la parte firmante y que puedan garantizar que el par de claves pertenece a la parte que afirma haber generado esta firma o que ellos mismos confíen en otros que puedan ofrecer esta garantía? Aquí la clave es que el papel convencional de la PKI tiene que ver con las claves y con la identidad. “¿Es esta tu llave?” Esta pregunta es la razón de ser de la PKI.

RPKI es diferente. No se trata de afirmaciones de identidad. Se trata de afirmaciones de propiedad. Los certificados RPKI X.509 incluyen un conjunto de recursos de números IP (direcciones IP y/o Números de Sistema Autónomo). La pregunta que RPKI pretende responder es “¿Es esta su dirección?” Ya no se trata de la asociación de las claves con la identidad sino de las claves con el control sobre los recursos IP.

Es necesario equilibrar objetivos en conflicto. En teoría, queremos anclas de confianza estables y duraderas, como la KSK para DNSSEC. El problema es que, si cambiamos un ancla de confianza, todas las partes que confían deben eliminar sus anclas de confianza existentes y cargar otras nuevas. Algunas lo harán, pero al igual que nuestra experiencia con la rotación de la KSK, otras no lo harán. Y a medida que la RPKI madura y que las implementaciones de las herramientas de las partes que confían se diversifican, sería muy ingenuo pensar que cada implementación tratará a las anclas de confianza de la RPKI como altamente volátiles y verificará en forma permanente si hay cambios en el ancla de confianza.

Algunas implementaciones inevitablemente tratarán al ancla de confianza actual como un valor estático. Por otro lado, si estas partes que confían tratan al ancla de confianza como volátil, deberán verificar continuamente con el punto de publicación del ancla de confianza original para ver si hay actualizaciones en este material. Esto hace que los puntos de publicación de anclas de confianza sean un recurso crítico.

Un ataque DDOS en un punto de publicación de ancla de confianza supondría un riesgo para toda la RPKI, ya que estas partes que confían y que constantemente están verificando si hay actualizaciones tendrían que inventar cosas porque no pudieron alcanzar el punto de publicación del ancla de confianza. Es preferible utilizar anclas de confianza cuyo material sea altamente estable.

La fuente de la “verdad” para la RPKI es la colección de datos de los Registros de Internet. Cuando un registro de Internet asigna un bloque de números a un registro subordinado receptor, no solo se registra esa transacción en el registro, sino que cuando el receptor de la dirección envía una solicitud de firma de certificado al registro “padre”, el registro emitirá un certificado para vincular el bloque de direcciones asignado con la clave pública del receptor. La idea es que esto sea válido para todas las partes de la RPKI, desde el certificado raíz hasta los certificados de entidad final en las “hojas” de la jerarquía.

Este modelo de operación implica que la RPKI debe seguir con precisión las acciones de asignación de direcciones de los registros de Internet. Si esto fuera todo, este sería el final de la historia.

Sin embargo, en respuesta al agotamiento de las direcciones IPv4, las comunidades regionales de políticas adoptaron el concepto de transferencias de direcciones, tanto para transacciones dentro de una misma región como entre diferentes regiones. Si bien la RPKI se diseñó para describir la asignación jerárquica de direcciones mediante certificados, el movimiento “horizontal” de direcciones IP entre registros presentó algunos problemas fundamentales para el diseño de la RPKI.

Para ver las implicaciones de las transferencias en la estructura de RPKI, veamos la transferencia de una dirección entre dos RIR desde la perspectiva de RPKI.

El ISP A, una entidad atendida por el RIR X, transfiere un prefijo de direcciones al ISP B, que es una entidad atendida por el RIR Y. El RIR X deberá revocar el certificado que había emitido al ISP A y, si el ISP A todavía tiene otros recursos numéricos, deberá emitir un nuevo certificado para el ISP A con un conjunto reducido de recursos numéricos. El RIR Y deberá emitir (o volver a emitir) su certificado para el ISP B; el nuevo certificado deberá incluir el prefijo de direcciones transferido.

La elección de los modelos de anclas de confianza afecta la complejidad de este conjunto de acciones sobre los certificados.

Si cada uno de estos RIR publica un ancla de confianza que incluye todos los recursos (un certificado autofirmado ‘0/0’), las acciones que implica la transferencia son bastante sencillas:

1. El RIR X emite un nuevo certificado para el ISP A que no contiene los recursos transferidos.
2. El RIR X revoca el certificado anterior para el ISP A.
3. El RIR Y emite un nuevo certificado para el ISP B que contiene los recursos transferidos.
4. El RIR Y revoca el certificado anterior para el ISP B.

La consideración de la “vitalidad” determina el orden de estas acciones. Si desea permitir que la red que utiliza esta dirección siempre esté cubierta por un certificado RPKI que se pueda validar en todo momento, el RIR Y primero emitirá un nuevo certificado y la revocación del certificado anterior será el acto final de la transferencia. En otras palabras, la secuencia anterior sería 3, 1, 4, 2.

¿Qué sucede si cada RIR publica un ancla de confianza que no enumera 0/0 sino que enumera precisamente las direcciones que figuran en su registro local y nada más? Ahora la secuencia es un poco más compleja, la transferencia implica un cambio en las anclas de confianza de los RIR que participan en la transferencia:

1. El RIR Y emite una nueva ancla de confianza que incluye los recursos a transferir.
2. El RIR Y emite un nuevo certificado para el ISP B que contiene los recursos a transferir.
3. El RIR X emite un nuevo certificado para el ISP A que no contiene los recursos transferidos.
4. El RIR Y revoca el certificado anterior para el ISP B.
5. El RIR X revoca el certificado anterior para el ISP A.
6. El RIR X emite una nueva ancla de confianza que no contiene los recursos transferidos.

El proceso anterior es frágil en muchos sentidos. Las acciones de los RIR están en un orden particular, pero no así las acciones de las partes que confían. ¿Qué sucede si una parte que confía no ve el ancla de confianza modificado para el RIR Y, pero primero toma el nuevo certificado para el ISP B? Desde la perspectiva de la parte que confía, ese certificado no es válido porque no está “cubierto” por el ancla de confianza del RIR Y.

Para que este proceso sea más sólido, es necesario introducir demoras para permitir que las partes que confían se mantengan al día, y estas demoras deben medirse en días antes que en horas. El siguiente es un proceso modificado:

1. El RIR Y emite una nueva ancla de confianza que incluye los recursos a transferir.
2. Espera.
3. El RIR Y emite un nuevo certificado para el ISP B que contiene los recursos a transferir.
4. El RIR X emite un nuevo certificado para el ISP A que no contiene los recursos transferidos.
5. El RIR Y revoca el certificado anterior para el ISP B.
6. Espera.
7. El RIR X revoca el certificado anterior para el ISP A.
8. El RIR X emite una nueva ancla de confianza que no contiene los recursos transferidos.

Se están produciendo muchas transferencias. Y no hay duda de que las transferencias se intensificarán en el futuro, por lo que este proceso de ocho pasos puede ejecutarse muchas veces en paralelo. Esto implica que las anclas de confianza para los RIR estarían en un estado de cambio constante y que las partes que confían tendrían que consultar continuamente estos puntos de publicación de anclas de confianza para asegurarse de que la copia del ancla de confianza almacenada en su caché local esté actualizada.

La alternativa es que cada RIR utilice un ancla de confianza que contenga un conjunto de recursos 0/0. De esta forma, los cambios en las anclas de confianza se limitarían a cambios en el material de las claves, algo que se puede gestionar de una forma mucho más controlada.

La conclusión es que, si cada uno de los RIR publica un ancla de confianza, entonces el uso de un conjunto de recursos 0/0 en estas anclas permite estabilidad en este material de modo que las partes que confían no tengan que volver a verificar constantemente el estado de su raíz de confianza. Otros enfoques para abordar un conjunto de anclas de confianza basadas ​​en los RIR son más frágiles.

El camino alternativo es que los RIR no publiquen sus propias anclas de confianza. Este camino alternativo prevé que la IANA publique un ancla de confianza única para toda la RPKI. Este enfoque fue la posición de partida en el diseño de la RPKI.

Tener un ancla de confianza 0/0 firmada por la IANA tiene muchas ventajas. Es estable, duradera y se puede gestionar de forma segura. Todos estos son atributos deseables para un ancla de confianza.

No obstante, surge la pregunta: ¿Qué hay en los certificados que emite la IANA para cada RIR?

La respuesta convencional es la misma respuesta que utilizan los RIR en la RPKI, es decir, que la RPKI es un reflejo exacto del contenido actual del registro. Un certificado RPKI no solo se inventa, sino que se basa en el contenido del registro. En consecuencia, los certificados emitidos por la IANA se basarían en la información del registro de la IANA con respecto a los recursos asignados para que los gestione cada RIR.

En este contexto, veamos una vez más la transferencia de recursos del ISP A al ISP B. ¿Está involucrada la CA de la IANA en esta transferencia?

Un enfoque es que los certificados de la IANA que certifican el RIR X y el RIR Y se deben modificar para reflejar esta transferencia, moviendo el recurso del certificado desde el RIR X al RIR Y (Figura 4).

Esta transferencia no está en el registro de números de la IANA, ya que el registro de la IANA solo registra las asignaciones de la IANA a los RIR y las acciones de reserva por parte del IETF. Este enfoque implica que la IANA emitiría un certificado donde los contenidos contradirían el registro de la IANA.

Esto se podría arreglar instituyendo un nuevo proceso operativo en el que la IANA procese todas las transferencias entre diferentes RIR y los registros de la IANA se actualicen para reflejar la disposición actual de todos los recursos transferidos. Esta propuesta plantea un conjunto de preguntas relacionadas con las políticas, ya que coloca a la IANA en la posición de “aprobar” todas y cada una de las transferencias de direcciones e ingresarlas en el registro de la IANA.

También plantea la pregunta: “¿Qué es el registro de la IANA?” Ya no representaría un registro confiable y preciso de las acciones de asignación de la IANA en el pasado, sino un compendio de transacciones que otras partes le han comunicado a la IANA. Presuntamente, los registros idearían una forma segura y autenticada de informar a la IANA de una manera que no pueda ser repudiada y que probablemente sea genuina en ambos lados de la transferencia y estas pruebas deben ser verificables por cualquiera que quiera hacerlo. Sin embargo, la observación básica sigue siendo que la IANA ya no registra sus propias acciones, sino que actúa como un registro de las acciones realizadas por otros registros.

Mi reacción ante este posible modelo es que el problema más difícil para los RIR no serían las consideraciones operativas para ejecutar tales transacciones de manera confiable en todo momento sino la cuestión de las políticas. Es difícil comprender cómo las comunidades de los RIR aceptarían colocar a la IANA en un rol que esencialmente supervise y tácitamente deba dar su visto bueno al aprobar cada microacción que es una transferencia de direcciones. ¿Qué sucede si la IANA alguna vez desaprueba y se niega a procesar una transacción de direcciones propuesta por dos RIR?

Si este no es un arreglo aceptable, entonces la pregunta siguiente sería cómo eliminar a la IANA del ciclo.

La alternativa es que la IANA emita certificados a cada RIR que sean una réplica exacta de las acciones de asignaciones históricas descritas en el registro existente de la IANA. Cuando los ISP A y B realicen su transferencia, la IANA no estará involucrada y los certificados de la IANA para los RIR X e Y no podrán cambiar. La IANA no realizó la transferencia, de modo que la IANA no tiene motivos para realizar cambios en su registro.

Teniendo en cuenta estas restricciones, ¿cómo se pueden certificar los recursos transferidos? El único camino posible es que el RIR X certifique el RIR Y para los recursos, y que el RIR Y certifique al ISP B utilizando este certificado “inter-RIR” como su “padre”. Ahora, el ISP B podría acabar con dos certificados: uno para los recursos cuya asignación siguió el camino IANA > RIR Y > ISP B y un segundo certificado para aquellos cuya asignación fue IANA > RIR X > RIR Y > ISP B. Estos dos certificados no se pueden fusionar.

¿Qué sucede si el ISP B transfiere posteriormente todos sus recursos al ISP C, una entidad atendida por el RIR Z? Ya no es asunto del RIR X y realmente no debería estar en la posición de tener que “aprobar” esta transacción, dado que no tiene relación con ninguna de las partes de esta transacción posterior.

Si solo queremos realizar esta segunda transacción entre el RIR Y y el RIR Z, entonces el ISP C será el sujeto de un certificado cuya ruta de validación será IANA > RIR X > RIR Y > RIR Z > ISP C y también será el sujeto de un segundo certificado cuya ruta de validación será IANA > RIR Y > RIR Z > ISP C. Nuevamente, estos dos certificados no se pueden fusionar.

A medida que se realizan más transferencias, la estructura de los certificados adquiere una complejidad cada vez mayor. El resultado es que la alternativa a la inclusión de un ancla de confianza de la IANA en cada microtransferencia es una situación en la que el sistema de certificación RPKI se vuelve extraordinariamente complejo muy rápidamente, y los titulares de recursos pueden tener una gran colección de certificados para describir sus direcciones, incluso cuando el titular haya registrado todas sus direcciones en un único RIR.

No parece tan malo, ¿verdad? Mientras estos certificados puedan validarse y no se contradigan entre sí, todo estaría bien, ¿cierto? Al menos desde un punto de vista técnico, sin importar la posible carga operativa, todo estaría bien, ¿no es así? ¿Cuál sería el problema?

Queríamos un sistema que aumentara el registro con claves digitales. La posesión de una clave privada permitía al titular de un recurso decir: “Ese es mi recurso y mi RIR validará mi firma digital si firmo una atestación digital a tal efecto”. Es una versión “fuerte” de la herramienta whois.

Queríamos un sistema de certificación de clave pública X.509 que ordenara cambios en la estructura del RIR o cambios en el modelo IANA/RIR. Para lograr este resultado muy simple y no aceptar un conjunto de externalidades que introduzcan complejidad y fragilidad, o que introduzcan cambios en el panorama de políticas y organizativo entre los RIR y entre los RIR y la IANA, el espacio de decisión sobre cómo diseñar la confianza en el RPKI es un espacio muy restringido.

Si queremos evitar anclas de confianza altamente volátiles y queremos evitar la creciente complejidad en la emisión y administración de certificados, y si además queremos evitar reescribir el marco de políticas de la relación entre los RIR y la IANA, la única opción que queda es usar un ancla de confianza para que cada RIR emita un ancla de confianza autofirmada con un conjunto de recursos 0/0. Todos los demás modelos convencionales crean complejidad y fragilidad adicionales; además, algunos modelos requieren una reelaboración de las funciones y el marco de la IANA/RIR, ¡una tarea que nadie parece querer siquiera contemplar!

Esa es la razón por la que los RIR utilizan un conjunto de anclas de confianza de certificados autofirmados 0/0 basados ​​en los RIR. Dadas las limitaciones de la estructura de los certificados X.509 y las limitaciones del entorno organizativo en el que opera el sistema de gestión de recursos, no hay otra opción de diseño factible disponible.