{"id":17395,"date":"2022-06-02T17:09:27","date_gmt":"2022-06-02T17:09:27","guid":{"rendered":"https:\/\/prensa.lacnic.net\/news?p=17395"},"modified":"2023-03-21T13:47:30","modified_gmt":"2023-03-21T13:47:30","slug":"rpki-e-as-ancoras-de-confianca","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/","title":{"rendered":"RPKI e as \u00e2ncoras de confian\u00e7a"},"content":{"rendered":"\n

Por Geoff Huston<\/a><\/p>\n\n

Publicaci\u00f3n original: blog de APNIC<\/a><\/p>\n\n

Muchas veces me han preguntado por qu\u00e9 utilizamos un marco de confianza distribuido en el que cada uno de los Registros Regionales de Internet (RIR) publica un ancla de confianza que reclama la totalidad del espacio num\u00e9rico de Internet.<\/p>\n\n

Sospecho que la pregunta volver\u00e1 a surgir en el futuro, por lo que me parece \u00fatil registrar aqu\u00ed las consideraciones de dise\u00f1o con la esperanza de que pueda ser de utilidad para quienes se encuentren con la misma pregunta en el futuro.<\/p>\n\n

Las anclas de confianza son la herramienta que tienen las partes que conf\u00edan (es decir, las personas que desean usar una infraestructura de clave p\u00fablica (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\u00f3n requiere que la parte que conf\u00eda construya una cadena de certificados donde cada eslab\u00f3n de la cadena corresponda a una autoridad de certificaci\u00f3n cuya clave privada ha firmado el siguiente certificado de clave p\u00fablica (o su subordinado inmediato) en la cadena.<\/p>\n\n

\"\"
Figura 1 \u2013 Cadena de certificados X.509<\/figcaption><\/figure>\n

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

\"\"
Figura 2: Cadena de certificados X.509 con un ancla de confianza.<\/figcaption><\/figure>\n

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

T\u00edpicamente, un ancla de confianza est\u00e1 ampliamente distribuida dentro de una PKI y almacenada localmente en cach\u00e9 por cada parte que conf\u00eda 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\u00edan.<\/p>\n\n

Esto es similar a la funci\u00f3n 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\u00edan est\u00e9n 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\u00eda que las anclas de confianza fueran estables y duraderas, y normalmente cambiar\u00edamos el valor de la clave del ancla de confianza con poca frecuencia o no lo har\u00edamos nunca. Y si va a cambiar, ser\u00eda mejor que esta ancla de confianza cambie en momentos previstos y bien se\u00f1alados para que las partes que conf\u00edan puedan administrar su confianza en sincron\u00eda con estos cambios.<\/p>\n\n

Ahora agreguemos una consideraci\u00f3n adicional sobre PKI de recursos (RPKI). El ancla de confianza tambi\u00e9n debe incluir un conjunto de recursos num\u00e9ricos IP que est\u00e9n 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\u00e9ricos dentro de este alcance. Esto es v\u00e1lido tanto para los certificados de anclas de confianza autofirmados como para todos los dem\u00e1s 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\u00f1o para las anclas de confianza de RPKI.<\/p>\n\n

RPKI introdujo un giro sutil en la interpretaci\u00f3n convencional de los certificados de clave p\u00fablica X.509.<\/p>\n\n

De manera informal, una PKI construye una estructura de confianza transitiva que permite que una parte que conf\u00eda responda la pregunta: \u00bfEsta firma digital es genuina<\/em>? Esta pregunta se transforma en una pregunta ligeramente diferente: \u00bfLa clave p\u00fablica es parte del par de claves que se usa para generar la firma que pertenece a la parte que afirma haber generado esta firma?<\/p>\n\n

Dado que la parte que hace esta pregunta puede no conocer a la parte firmante o su clave p\u00fablica, la PKI es \u00fatil para responder una variante de esta pregunta: \u00bfHay personas en las que conf\u00edo 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\u00eden en otros que puedan ofrecer esta garant\u00eda? Aqu\u00ed la clave es que el papel convencional de la PKI tiene que ver con las claves y con la identidad. “\u00bfEs esta tu llave?” Esta pregunta es la raz\u00f3n de ser de la PKI.<\/p>\n\n

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\u00fameros IP (direcciones IP y\/o N\u00fameros de Sistema Aut\u00f3nomo). La pregunta que RPKI pretende responder es “\u00bfEs esta su direcci\u00f3n?” Ya no se trata de la asociaci\u00f3n de las claves con la identidad sino de las claves con el control sobre los recursos IP.<\/p>\n\n

Es necesario equilibrar objetivos en conflicto. En teor\u00eda, 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\u00edan deben eliminar sus anclas de confianza existentes y cargar otras nuevas. Algunas lo har\u00e1n, pero al igual que nuestra experiencia con la rotaci\u00f3n de la KSK, otras no lo har\u00e1n. Y a medida que la RPKI madura y que las implementaciones de las herramientas de las partes que conf\u00edan se diversifican, ser\u00eda muy ingenuo pensar que cada implementaci\u00f3n tratar\u00e1 a las anclas de confianza de la RPKI como altamente vol\u00e1tiles y verificar\u00e1 en forma permanente si hay cambios en el ancla de confianza.<\/p>\n\n

Algunas implementaciones inevitablemente tratar\u00e1n al ancla de confianza actual como un valor est\u00e1tico. Por otro lado, si estas partes que conf\u00edan tratan al ancla de confianza como vol\u00e1til, deber\u00e1n verificar continuamente con el punto de publicaci\u00f3n del ancla de confianza original para ver si hay actualizaciones en este material. Esto hace que los puntos de publicaci\u00f3n de anclas de confianza sean un recurso cr\u00edtico.<\/p>\n\n

Un ataque DDOS en un punto de publicaci\u00f3n de ancla de confianza supondr\u00eda un riesgo para toda la RPKI, ya que estas partes que conf\u00edan y que constantemente est\u00e1n verificando si hay actualizaciones tendr\u00edan que inventar cosas porque no pudieron alcanzar el punto de publicaci\u00f3n del ancla de confianza. Es preferible utilizar anclas de confianza cuyo material sea altamente estable.<\/p>\n\n

La fuente de la “verdad” para la RPKI es la colecci\u00f3n de datos de los Registros de Internet. Cuando un registro de Internet asigna un bloque de n\u00fameros a un registro subordinado receptor, no solo se registra esa transacci\u00f3n en el registro, sino que cuando el receptor de la direcci\u00f3n env\u00eda una solicitud de firma de certificado al registro “padre”, el registro emitir\u00e1 un certificado para vincular el bloque de direcciones asignado con la clave p\u00fablica del receptor. La idea es que esto sea v\u00e1lido para todas las partes de la RPKI, desde el certificado ra\u00edz hasta los certificados de entidad final en las “hojas” de la jerarqu\u00eda.<\/p>\n\n

Este modelo de operaci\u00f3n implica que la RPKI debe seguir con precisi\u00f3n las acciones de asignaci\u00f3n de direcciones de los registros de Internet. Si esto fuera todo, este ser\u00eda el final de la historia.<\/p>\n\n

Sin embargo, en respuesta al agotamiento de las direcciones IPv4, las comunidades regionales de pol\u00edticas adoptaron el concepto de transferencias de direcciones, tanto para transacciones dentro de una misma regi\u00f3n como entre diferentes regiones. Si bien la RPKI se dise\u00f1\u00f3 para describir la asignaci\u00f3n jer\u00e1rquica de direcciones mediante certificados, el movimiento “horizontal” de direcciones IP entre registros present\u00f3 algunos problemas fundamentales para el dise\u00f1o de la RPKI.<\/p>\n\n

Para ver las implicaciones de las transferencias en la estructura de RPKI, veamos la transferencia de una direcci\u00f3n entre dos RIR desde la perspectiva de RPKI.<\/p>\n\n

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\u00e1 revocar el certificado que hab\u00eda emitido al ISP A y, si el ISP A todav\u00eda tiene otros recursos num\u00e9ricos, deber\u00e1 emitir un nuevo certificado para el ISP A con un conjunto reducido de recursos num\u00e9ricos. El RIR Y deber\u00e1 emitir (o volver a emitir) su certificado para el ISP B; el nuevo certificado deber\u00e1 incluir el prefijo de direcciones transferido.<\/p>\n\n

\"\"
Figura 3 \u2013 Escenario de transferencia de direcciones.<\/figcaption><\/figure>\n

La elecci\u00f3n de los modelos de anclas de confianza afecta la complejidad de este conjunto de acciones sobre los certificados.<\/p>\n\n

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:<\/p>\n\n

  1. El RIR X emite un nuevo certificado para el ISP A que no contiene los recursos transferidos.<\/li>
  2. El RIR X revoca el certificado anterior para el ISP A.<\/li>
  3. El RIR Y emite un nuevo certificado para el ISP B que contiene los recursos transferidos.<\/li>
  4. El RIR Y revoca el certificado anterior para el ISP B.<\/li><\/ol>\n

    La consideraci\u00f3n de la \u201cvitalidad\u201d determina el orden de estas acciones. Si desea permitir que la red que utiliza esta direcci\u00f3n siempre est\u00e9 cubierta por un certificado RPKI que se pueda validar en todo momento, el RIR Y primero emitir\u00e1 un nuevo certificado y la revocaci\u00f3n del certificado anterior ser\u00e1 el acto final de la transferencia. En otras palabras, la secuencia anterior ser\u00eda 3, 1, 4, 2.<\/p>\n\n

    \u00bfQu\u00e9 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\u00e1s? Ahora la secuencia es un poco m\u00e1s compleja, la transferencia implica un cambio en las anclas de confianza de los RIR que participan en la transferencia:<\/p>\n\n

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

      El proceso anterior es fr\u00e1gil en muchos sentidos. Las acciones de los RIR est\u00e1n en un orden particular, pero no as\u00ed las acciones de las partes que conf\u00edan. \u00bfQu\u00e9 sucede si una parte que conf\u00eda 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\u00eda, ese certificado no es v\u00e1lido porque no est\u00e1 “cubierto” por el ancla de confianza del RIR Y.<\/p>\n\n

      Para que este proceso sea m\u00e1s s\u00f3lido, es necesario introducir demoras para permitir que las partes que conf\u00edan se mantengan al d\u00eda, y estas demoras deben medirse en d\u00edas antes que en horas. El siguiente es un proceso modificado:<\/p>\n\n

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

        Se est\u00e1n produciendo muchas transferencias. Y no hay duda de que las transferencias se intensificar\u00e1n 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\u00edan en un estado de cambio constante y que las partes que conf\u00edan tendr\u00edan que consultar continuamente estos puntos de publicaci\u00f3n de anclas de confianza para asegurarse de que la copia del ancla de confianza almacenada en su cach\u00e9 local est\u00e9 actualizada.<\/p>\n\n

        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\u00edan a cambios en el material de las claves, algo que se puede gestionar de una forma mucho m\u00e1s controlada.<\/p>\n\n

        La conclusi\u00f3n 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\u00edan no tengan que volver a verificar constantemente el estado de su ra\u00edz de confianza. Otros enfoques para abordar un conjunto de anclas de confianza basadas \u200b\u200ben los RIR son m\u00e1s fr\u00e1giles.<\/p>\n\n

        El camino alternativo es que los RIR no publiquen sus propias anclas de confianza. Este camino alternativo prev\u00e9 que la IANA publique un ancla de confianza \u00fanica para toda la RPKI. Este enfoque fue la posici\u00f3n de partida en el dise\u00f1o de la RPKI.<\/p>\n\n

        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.<\/p>\n\n

        No obstante, surge la pregunta: \u00bfQu\u00e9 hay en los certificados que emite la IANA para cada RIR?<\/p>\n\n

        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\u00edan en la informaci\u00f3n del registro de la IANA<\/a> con respecto a los recursos asignados para que los gestione cada RIR.<\/p>\n\n

        En este contexto, veamos una vez m\u00e1s la transferencia de recursos del ISP A al ISP B. \u00bfEst\u00e1 involucrada la CA de la IANA en esta transferencia?<\/p>\n\n

        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).<\/p>\n\n

        \"\"
        Figura 4 \u2013 Transferencia de direcciones con certificados de la IANA.<\/figcaption><\/figure>\n

        Esta transferencia no est\u00e1 en el registro de n\u00fameros 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\u00eda un certificado donde los contenidos contradir\u00edan el registro de la IANA.<\/p>\n\n

        Esto se podr\u00eda 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\u00f3n actual de todos los recursos transferidos. Esta propuesta plantea un conjunto de preguntas relacionadas con las pol\u00edticas, ya que coloca a la IANA en la posici\u00f3n de “aprobar” todas y cada una de las transferencias de direcciones e ingresarlas en el registro de la IANA.<\/p>\n\n

        Tambi\u00e9n plantea la pregunta: \u201c\u00bfQu\u00e9 es el registro de la IANA?\u201d Ya no representar\u00eda un registro confiable y preciso de las acciones de asignaci\u00f3n de la IANA en el pasado, sino un compendio de transacciones que otras partes le han comunicado a la IANA. Presuntamente, los registros idear\u00edan 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\u00f3n b\u00e1sica sigue siendo que la IANA ya no registra sus propias acciones, sino que act\u00faa como un registro de las acciones realizadas por otros registros.<\/p>\n\n

        Mi reacci\u00f3n ante este posible modelo es que el problema m\u00e1s dif\u00edcil para los RIR no ser\u00edan las consideraciones operativas para ejecutar tales transacciones de manera confiable en todo momento sino la cuesti\u00f3n de las pol\u00edticas. Es dif\u00edcil comprender c\u00f3mo las comunidades de los RIR aceptar\u00edan colocar a la IANA en un rol que esencialmente supervise y t\u00e1citamente deba dar su visto bueno al aprobar cada microacci\u00f3n que es una transferencia de direcciones. \u00bfQu\u00e9 sucede si la IANA alguna vez desaprueba y se niega a procesar una transacci\u00f3n de direcciones propuesta por dos RIR?<\/p>\n\n

        Si este no es un arreglo aceptable, entonces la pregunta siguiente ser\u00eda c\u00f3mo eliminar a la IANA del ciclo.<\/p>\n\n

        La alternativa es que la IANA emita certificados a cada RIR que sean una r\u00e9plica exacta de las acciones de asignaciones hist\u00f3ricas descritas en el registro existente de la IANA. Cuando los ISP A y B realicen su transferencia, la IANA no estar\u00e1 involucrada y los certificados de la IANA para los RIR X e Y no podr\u00e1n cambiar. La IANA no realiz\u00f3 la transferencia, de modo que la IANA no tiene motivos para realizar cambios en su registro.<\/p>\n\n

        Teniendo en cuenta estas restricciones, \u00bfc\u00f3mo se pueden certificar los recursos transferidos? El \u00fanico 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 \u201cinter-RIR\u201d como su \u201cpadre\u201d. Ahora, el ISP B podr\u00eda acabar con dos certificados: uno para los recursos cuya asignaci\u00f3n sigui\u00f3 el camino IANA > RIR Y > ISP B y un segundo certificado para aquellos cuya asignaci\u00f3n fue IANA > RIR X > RIR Y > ISP B. Estos dos certificados no se pueden fusionar.<\/p>\n\n

        \"\"
        Figura 5 \u2013 Transferencia con certificados inter-RIR.<\/figcaption><\/figure>\n

        \u00bfQu\u00e9 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\u00eda estar en la posici\u00f3n de tener que “aprobar” esta transacci\u00f3n, dado que no tiene relaci\u00f3n con ninguna de las partes de esta transacci\u00f3n posterior.<\/p>\n\n

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

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

        No parece tan malo, \u00bfverdad? Mientras estos certificados puedan validarse y no se contradigan entre s\u00ed, todo estar\u00eda bien, \u00bfcierto? Al menos desde un punto de vista t\u00e9cnico, sin importar la posible carga operativa, todo estar\u00eda bien, \u00bfno es as\u00ed? \u00bfCu\u00e1l ser\u00eda el problema?<\/p>\n\n

        Quer\u00edamos un sistema que aumentara el registro con claves digitales. La posesi\u00f3n de una clave privada permit\u00eda al titular de un recurso decir: \u201cEse es mi recurso y mi RIR validar\u00e1 mi firma digital si firmo una atestaci\u00f3n digital a tal efecto\u201d. Es una versi\u00f3n “fuerte” de la herramienta\u00a0whois<\/em>.<\/p>\n\n

        Quer\u00edamos un sistema de certificaci\u00f3n de clave p\u00fablica 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\u00edticas y organizativo entre los RIR y entre los RIR y la IANA, el espacio de decisi\u00f3n sobre c\u00f3mo dise\u00f1ar la confianza en el RPKI es un espacio muy restringido.<\/p>\n\n

        Si queremos evitar anclas de confianza altamente vol\u00e1tiles y queremos evitar la creciente complejidad en la emisi\u00f3n y administraci\u00f3n de certificados, y si adem\u00e1s queremos evitar reescribir el marco de pol\u00edticas de la relaci\u00f3n entre los RIR y la IANA, la \u00fanica opci\u00f3n 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\u00e1s modelos convencionales crean complejidad y fragilidad adicionales; adem\u00e1s, algunos modelos requieren una reelaboraci\u00f3n de las funciones y el marco de la IANA\/RIR, \u00a1una tarea que nadie parece querer siquiera contemplar!<\/p>\n\n

        Esa es la raz\u00f3n por la que los RIR utilizan un conjunto de anclas de confianza de certificados autofirmados 0\/0 basados \u200b\u200ben 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\u00f3n de recursos, no hay otra opci\u00f3n de dise\u00f1o factible disponible.<\/p>\n","protected":false},"excerpt":{"rendered":"

        Por Geoff Huston Publicaci\u00f3n original: blog de APNIC Muchas veces me han preguntado por qu\u00e9 utilizamos un marco de confianza distribuido en el que cada uno de los Registros Regionales de Internet (RIR) publica un ancla de confianza que reclama la totalidad del espacio num\u00e9rico de Internet. Sospecho que la pregunta volver\u00e1 a surgir en […]<\/p>\n","protected":false},"author":6,"featured_media":17370,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1328,510],"tags":[1272,1293],"archivo":[1346],"taxonomy-authors":[1179],"tipo_autor":[],"class_list":["post-17395","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interconexao","category-seguranca-cibernetica","tag-ciberseguranca","tag-interconexao","archivo-edicoes-anteriores","taxonomy-authors-geoff-huston-pt-br"],"acf":{"author":"","related_notes":null},"yoast_head":"\nLACNIC Blog | RPKI e as \u00e2ncoras de confian\u00e7a<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"LACNIC Blog | RPKI e as \u00e2ncoras de confian\u00e7a\" \/>\n<meta property=\"og:description\" content=\"Por Geoff Huston Publicaci\u00f3n original: blog de APNIC Muchas veces me han preguntado por qu\u00e9 utilizamos un marco de confianza distribuido en el que cada uno de los Registros Regionales de Internet (RIR) publica un ancla de confianza que reclama la totalidad del espacio num\u00e9rico de Internet. Sospecho que la pregunta volver\u00e1 a surgir en […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\" \/>\n<meta property=\"og:site_name\" content=\"LACNIC Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/lacnic\" \/>\n<meta property=\"article:published_time\" content=\"2022-06-02T17:09:27+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-03-21T13:47:30+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png\" \/>\n\t<meta property=\"og:image:width\" content=\"680\" \/>\n\t<meta property=\"og:image:height\" content=\"330\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Gianni\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@lacnic\" \/>\n<meta name=\"twitter:site\" content=\"@lacnic\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\"},\"author\":{\"name\":\"Gianni\",\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/person\/1338d9cfdb0137e8bc5581f3771f39ab\"},\"headline\":\"RPKI e as \u00e2ncoras de confian\u00e7a\",\"datePublished\":\"2022-06-02T17:09:27+00:00\",\"dateModified\":\"2023-03-21T13:47:30+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\"},\"wordCount\":3764,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/blog.lacnic.net\/#organization\"},\"image\":{\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png\",\"keywords\":[\"Ciberseguran\u00e7a\",\"Interconex\u00e3o\"],\"articleSection\":[\"Interconex\u00e3o\",\"Seguran\u00e7a cibern\u00e9tica\"],\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\",\"url\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\",\"name\":\"LACNIC Blog | RPKI e as \u00e2ncoras de confian\u00e7a\",\"isPartOf\":{\"@id\":\"https:\/\/blog.lacnic.net\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png\",\"datePublished\":\"2022-06-02T17:09:27+00:00\",\"dateModified\":\"2023-03-21T13:47:30+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage\",\"url\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png\",\"contentUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png\",\"width\":680,\"height\":330},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Portada\",\"item\":\"https:\/\/blog.lacnic.net\/pt-br\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"RPKI e as \u00e2ncoras de confian\u00e7a\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.lacnic.net\/#website\",\"url\":\"https:\/\/blog.lacnic.net\/\",\"name\":\"LACNIC Blog\",\"description\":\"LACNIC Internet Community Newsletter\",\"publisher\":{\"@id\":\"https:\/\/blog.lacnic.net\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.lacnic.net\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/blog.lacnic.net\/#organization\",\"name\":\"LACNIC Blog\",\"url\":\"https:\/\/blog.lacnic.net\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg\",\"contentUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg\",\"caption\":\"LACNIC Blog\"},\"image\":{\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/lacnic\",\"https:\/\/x.com\/lacnic\",\"https:\/\/www.instagram.com\/lacnic\/?hl=es-la\",\"https:\/\/uy.linkedin.com\/company\/lacnic\",\"https:\/\/www.youtube.com\/user\/lacnicstaff\",\"https:\/\/www.lacnic.net\/podcast\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/person\/1338d9cfdb0137e8bc5581f3771f39ab\",\"name\":\"Gianni\",\"url\":\"https:\/\/blog.lacnic.net\/pt-br\/author\/gianni\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"LACNIC Blog | RPKI e as \u00e2ncoras de confian\u00e7a","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/","og_locale":"pt_BR","og_type":"article","og_title":"LACNIC Blog | RPKI e as \u00e2ncoras de confian\u00e7a","og_description":"Por Geoff Huston Publicaci\u00f3n original: blog de APNIC Muchas veces me han preguntado por qu\u00e9 utilizamos un marco de confianza distribuido en el que cada uno de los Registros Regionales de Internet (RIR) publica un ancla de confianza que reclama la totalidad del espacio num\u00e9rico de Internet. Sospecho que la pregunta volver\u00e1 a surgir en […]","og_url":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/","og_site_name":"LACNIC Blog","article_publisher":"https:\/\/facebook.com\/lacnic","article_published_time":"2022-06-02T17:09:27+00:00","article_modified_time":"2023-03-21T13:47:30+00:00","og_image":[{"width":680,"height":330,"url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png","type":"image\/png"}],"author":"Gianni","twitter_card":"summary_large_image","twitter_creator":"@lacnic","twitter_site":"@lacnic","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#article","isPartOf":{"@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/"},"author":{"name":"Gianni","@id":"https:\/\/blog.lacnic.net\/#\/schema\/person\/1338d9cfdb0137e8bc5581f3771f39ab"},"headline":"RPKI e as \u00e2ncoras de confian\u00e7a","datePublished":"2022-06-02T17:09:27+00:00","dateModified":"2023-03-21T13:47:30+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/"},"wordCount":3764,"commentCount":0,"publisher":{"@id":"https:\/\/blog.lacnic.net\/#organization"},"image":{"@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage"},"thumbnailUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png","keywords":["Ciberseguran\u00e7a","Interconex\u00e3o"],"articleSection":["Interconex\u00e3o","Seguran\u00e7a cibern\u00e9tica"],"inLanguage":"pt-BR","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/","url":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/","name":"LACNIC Blog | RPKI e as \u00e2ncoras de confian\u00e7a","isPartOf":{"@id":"https:\/\/blog.lacnic.net\/#website"},"primaryImageOfPage":{"@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage"},"image":{"@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage"},"thumbnailUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png","datePublished":"2022-06-02T17:09:27+00:00","dateModified":"2023-03-21T13:47:30+00:00","breadcrumb":{"@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#primaryimage","url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png","contentUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png","width":680,"height":330},{"@type":"BreadcrumbList","@id":"https:\/\/blog.lacnic.net\/pt-br\/rpki-e-as-ancoras-de-confianca\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Portada","item":"https:\/\/blog.lacnic.net\/pt-br\/"},{"@type":"ListItem","position":2,"name":"RPKI e as \u00e2ncoras de confian\u00e7a"}]},{"@type":"WebSite","@id":"https:\/\/blog.lacnic.net\/#website","url":"https:\/\/blog.lacnic.net\/","name":"LACNIC Blog","description":"LACNIC Internet Community Newsletter","publisher":{"@id":"https:\/\/blog.lacnic.net\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.lacnic.net\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/blog.lacnic.net\/#organization","name":"LACNIC Blog","url":"https:\/\/blog.lacnic.net\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/","url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg","contentUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg","caption":"LACNIC Blog"},"image":{"@id":"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/lacnic","https:\/\/x.com\/lacnic","https:\/\/www.instagram.com\/lacnic\/?hl=es-la","https:\/\/uy.linkedin.com\/company\/lacnic","https:\/\/www.youtube.com\/user\/lacnicstaff","https:\/\/www.lacnic.net\/podcast"]},{"@type":"Person","@id":"https:\/\/blog.lacnic.net\/#\/schema\/person\/1338d9cfdb0137e8bc5581f3771f39ab","name":"Gianni","url":"https:\/\/blog.lacnic.net\/pt-br\/author\/gianni\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2022\/06\/rpki-and-trust-anchors-june-2022-lacnic-blog.png","jetpack_sharing_enabled":true,"wpml_current_locale":"pt_BR","wpml_translations":[{"locale":"es_ES","id":17365,"post_title":"RPKI y anclas de confianza","slug":"rpki-y-anclas-de-confianza","href":"https:\/\/blog.lacnic.net\/rpki-y-anclas-de-confianza\/"},{"locale":"en_US","id":17393,"post_title":"RPKI and Trust Anchors","slug":"rpki-and-trust-anchors","href":"https:\/\/blog.lacnic.net\/en\/rpki-and-trust-anchors\/"}],"_links":{"self":[{"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/posts\/17395","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/comments?post=17395"}],"version-history":[{"count":4,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/posts\/17395\/revisions"}],"predecessor-version":[{"id":20683,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/posts\/17395\/revisions\/20683"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/media\/17370"}],"wp:attachment":[{"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/media?parent=17395"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/categories?post=17395"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/tags?post=17395"},{"taxonomy":"archivo","embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/archivo?post=17395"},{"taxonomy":"taxonomy-authors","embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/taxonomy-authors?post=17395"},{"taxonomy":"tipo_autor","embeddable":true,"href":"https:\/\/blog.lacnic.net\/pt-br\/wp-json\/wp\/v2\/tipo_autor?post=17395"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}