comité asesor at-large

10 abr. 2018 - quizás puedan comunicarse con proveedores clave en el DNS dentro de sus regiones. El sector bancario es uno de los sectores que no debe ...
940KB Größe 3 Downloads 7 vistas
ES

AL-ALAC-ST-0402-01-01-ES ORIGINAL: inglés FECHA: 10 de abril de 2018 ESTADO: ratificado

COMITÉ ASESOR AT-LARGE

Declaración del ALAC sobre el plan para reanudar el proceso de traspaso de la clave para la firma de la llave de la zona raíz (KSK)

Introducción Alan Greenberg, Presidente del Comité Asesor At-Large (ALAC), Hadia Elminiawi, miembro del ALAC perteneciente a la Organización Regional At-Large de África (AFRALO), Javier Rua-Jovet, miembro del ALAC perteneciente a la Organización Regional At-Large de América del Norte (NARALO), John Laprise, miembro del ALAC perteneciente a la Organización Regional At-Large de América del Norte (NARALO), Lutz Donnerhacke, miembro de la Organización Regional At-Large de Europa (EURALO), y Sebastien Bachollet, miembro del ALAC perteneciente a la Organización Regional At-Large de Europa (EURALO), redactaron una versión borrador inicial de esta declaración en representación del ALAC. El 22 de febrero de 2018, el primer borrador de la declaración se publicó en el correspondiente espacio de trabajo de At-Large. Ese mismo día, el personal de políticas de la ICANN, a cargo de asistir a la comunidad At-Large, envió una convocatoria a la comunidad At-Large para que presente sus comentarios sobre la declaración a través de la lista de correo electrónico de trabajo del ALAC. El 25 de marzo de 2018, el presidente del ALAC presentó un comentario. El 2 de abril de 2018, en el espacio de trabajo mencionado anteriormente, se publicó una versión que incluía los comentarios adicionales recibidos y el presidente del ALAC solicitó al personal que se abriera un período de votación para que el ALAC ratificase la declaración propuesta. En aras del tiempo, el presidente del ALAC solicitó que la declaración fuese enviada al proceso de comentario público de la ICANN, con copia al miembro del personal de la ICANN a cargo de este tema en dicho proceso, junto con una nota que indicara que la declaración se encontraba en proceso de ratificación por parte del ALAC. El 6 de abril de 2018, el personal confirmó que, de acuerdo con los resultados de la votación en línea, el ALAC respalda la declaración con 13 votos a favor, ningún voto en contra y ninguna abstención. Téngase en cuenta que el 86,67% (13) de los 15 miembros del ALAC participaron en la votación. Los miembros del ALAC que participaron



en la votación son (en orden alfabético por su nombre de pila) los siguientes: Alan Greenberg, Alberto Soto, Andrei Kolesnikov, Bartlett Morgan, Bastiaan Goslings, Holly Raiche, Javier Rua-Jovet, John Laprise, Kaili Kan, Maureen Hilyard, Ricardo Holmquist, Sebastien Bachollet y Tijani Ben Jemaa. 2 miembros del ALAC, Hadia Elminiawi y Seun Ojedeji, no participaron de la votación. Los resultados están disponibles en el siguiente enlace: https://www.bigpulse.com/pollresults?code=539151mifrfBGRhjvyfkiYs6sA.



Declaración del ALAC sobre el plan para reanudar el proceso de traspaso de la clave para la firma de la llave de la zona raíz (KSK) Si bien el ALAC y la comunidad At-Large entienden la necesidad de efectuar el traspaso de la KSK, partes de la comunidad tienen serias inquietudes respecto del potencial impacto en los usuarios a nivel mundial. Consideramos que se necesita una revisión holística, que incluya una evaluación de riesgo de las alternativas, con el tiempo suficiente para continuar con este análisis en la reunión ICANN62. En la evaluación, se debería incluir la información vigente en su momento, relativa a los informes sobre anclajes de confianza del documento RFC 8145, el pronóstico sobre la disponibilidad del mecanismo “centinela” en desarrollo por parte del IETF y la posibilidad de usar dicho mecanismo para generar un mayor nivel de tranquilidad con antelación al traspaso de la KSK. Al mismo tiempo, la ICANN debería fortalecer su campaña de concientización, utilizando todos los canales posibles para llegar a los ISP, las empresas de telecomunicaciones y los gobiernos, como también a los sectores críticos que deben poder continuar funcionando después del traspaso, y que quizás puedan comunicarse con proveedores clave en el DNS dentro de sus regiones. El sector bancario es uno de los sectores que no debe quedar fuera de línea y que puede tener contactos valiosos a nivel local. Los RIR pueden contar con buena información de contacto de los principales ISP y otros usuarios de gran envergadura en sus regiones. La ICANN también debería facilitar un paquete de información (en un lenguaje llano), confeccionado al menos en los idiomas en los cuales la organización normalmente brinda soporte, y en más idiomas de ser posible, para que tanto usuarios como empresas entiendan esta cuestión y se les indique lo que necesitan hacer/preguntar con respecto a sus ISP locales. La ICANN debería facilitar un sitio web en el cual realizar una prueba de manera sencilla y/o una aplicación mediante la cual los usuarios verifiquen si el resolutor que suelen usar es compatible con las DNSSEC. De no ser así, es probable que no se vean afectados por el traspaso de la KSK. Si su resolutor es compatible con las DNSSEC, entonces se les debería informar lo que deben hacer para tratar de verificar que su proveedor esté al tanto del traspaso y preparado para el mismo (teniendo presente que el soporte técnico que la mayoría de los usuarios puede contactar probablemente no se encuentre al tanto de términos como DNSSEC, KSK o traspaso). http://dnssec.donnerhacke.de es un ejemplo de modelo para dicha herramienta. La ICANN debería proporcionar una lista (visible o con funcionalidad de búsqueda) de los resolutores del DNS de los cuales se sepa que son compatibles con las DNSSEC, como también se sepa a ciencia cierta si tienen o no instalado el nuevo anclaje de confianza, y en la campaña de concientización se debería describir la manera en que los usuarios finales pueden verificar esta lista. Seria incluso mejor tener una aplicación automatizada que los usuarios puedan activar en varias plataformas.



1

Por último, a la comunidad At-Large le preocupa que el traspaso se encuentra programado para un día jueves (y muy probablemente viernes en gran parte del mundo). Ello parece ser un plan diseñado para maximizar y prolongar cualquier problema. Nos gustaría entender el potencial y la posibilidad de un retraso mínimo, a fin de cerciorarnos de que la cuestión del día de semana reduce el impacto en lugar de aumentarlo.



2