[LACNIC/Politicas] LAC-2012-011 - Nueva versión (2) / Nova versão (2) / New version (2)

[Alejandro Rodriguez]

Yo también estoy en contra.

Sencillamente alguien esta haciendo un despliegue académico  y necesita 
que los usuarios de manera masiva RPKI.


saludos

Alejandro Rodriguez
Gerente Tecnico
Stealth Telecom del Ecuador
www.stealthtelecom.net
Telf: 2248233 / 2248887

El 05/10/2012 9:54, Ricardo Patara escribió:
> Roque, que tal?
>
> Mi posición sigue la misma. Estoy en contra la propuesta.
>
> No veo ninguna relación entre tener que ter RPKI para justificar
> direcciones adicionales.
>
> El hecho de que se ponga como una "obligacion" al solicitante para
> recibir direcciones adicionales no le hará aprender acerca de RPKI, lo
> que sería una de las justificativas de esa propuesta.
>
> saludos
>
>    Ricardo Patara
>
>
>> DATOS DEL AUTORES:
>>
>>
>> Nombre - eMail - Teléfono (Phone) - Entidad (Organización)
>>
>> Roque Gagliano - rogaglia at cisco.com - - Cisco Systems
>>
>> DATOS de la PROPUESTA:
>>
>>
>> Título de la Propuesta: Requerimiento de inscripción en RPKI para
>> recursos adicionales
>>
>> Tipo de propuesta: LACNIC
>>
>> Id (Si existe): LAC-2012-11
>>
>> Versión: 2 (Thu Oct 4 06:48:40 2012)
>>
>> Resumen de la Propuesta: La propuesta consiste en requerir que toda
>> entidad buscando recursos adicionales de LACNIC deba
>> haber previamente inscripto sus recursos en el sistema RPKI. Se
>> entiende que se cumple con este
>> requerimiento cuando la entidad cuente con: una o más entidades
>> certificadoras registradas en el
>> sistema de LACNIC, uno o más certificados RPKI que cubran la totalidad
>> de los recursos. S i
>> corresponde, uno o más ROAs que cubran la totalidad de los recursos no
>> delegados y uno o más
>> repositorios públicos donde se pueda obtener esta información sin restricciones.
>>
>>
>> Justificación: La implementación actual de RPKI require algunos pasos
>> mínimos para que los miembros en el sistema
>> de gestión de LACNIC. Muchas veces nos enfrentamos a problemas
>> operativos en las entidades. Por
>> ejemplo, comúnmente, la persona que opera la red puede no ser la misma
>> que utiliza el sistema de LACNIC.
>>
>> Adicionalmente, como todo sistema de registro, RPKI sufre el problema
>> de antiguedad de la
>> información almacenada. Con esta propuesta, se le da una herramienta
>> al sistema de registro para
>> requerir una evaluación de la información en el RPKI cada vez que la
>> entidad entra en contacto con
>> LACNIC para solicitar recursos adicionales. Herramientas similares ya
>> existen en el manual de
>> políticas de LACNIC para el registro Whois y DNS reverse.
>>
>> Con esta propuesta de política, se logran varios objetivos:
>> - palear el problema de la antiguedad de la información en el registro RPKI
>> - inducir la generación de material criptográfico en el RPKI.
>> - educar sobre el RPKI y seguridad en el sistema global de enrutamiento.
>>
>> El costo para el operador es mínimo (un par de clicks en el sistema de
>> LACNIC), siempre que cuente
>> con un sistema de gestión de la información.
>>
>> El costo para LACNIC debería ser mínimo pues no requiere cambios en
>> los sistemas de gestión.
>>
>>
>> Texto de la Propuesta: Sección 2.3.4.
>> (Se agrega este texto como punto 8 y se renumera el siguiente como punto 9)
>>
>> 8- El solicitante debe estar al día con sus registro en el sistema de
>> certificación
>> RPKI. Para ello debe contar con:
>> a. una o más entidades certificadoras registradas en el sistema RPKI de
>> LACNIC
>> b. uno o más certificados válidos (según RFC 6487) de entidad
>> certificadora (CA) RPKI que cubran la
>> totalidad d e los recursos
>>
>> Si corresponde, se solicitará que el solicitante verifique que cuenta con:
>> c. uno o más ROAs bien formados (según RFC 6482) que cubran la
>> totalidad de los recursos no delegados
>> d. uno o más repositorios públicos que verifiquen RFC 6481, donde se
>> pueda obtener esta información
>> sin restricciones.
>>
>> ---------
>> IPv6: Sección 4.5.2.1. Criterio de distribución subsiguiente
>> Se adiciona el siguiente texto:
>>
>> El solicitante debe estar al día con sus registro en el sistema de
>> certificación RPKI. Para ello
>> debe contar con:
>> a. una o más entidades certificadoras registradas en el sistema RPKI de LACNIC
>> b. uno o más certificados válidos (según RFC 6487) de entidad
>> certificadora (CA) RPKI que cubran la
>> totalidad de los recursos
>>
>> Si corresponde, se solicitará que el solicitante verifique que cuenta con:
>> c. uno o más ROAs bien formados (según RFC 6482) que cubran la
>> totalidad de los recursos no delegados
>> d. uno o más repositorio s públicos que verifiquen RFC 6481, donde se
>> pueda obtener esta información
>> sin restricciones.
>>
>>
>> INFORMACÍON ADICIONAL:
>>
>>
>> Tiempo de implementación: inmediato
>>
>> Grupo de trabajo: políticas
>>
>> Propuestas previas relacionadas:
>>
>> Referencias: http://rpki.lacnic.net
>>
>> Cambios desde versión anterior: - Pedido de ROAs y repositorios es condicional.
>> Esto es pues pueden haber razones para no publicar
>> ROAs (por ejemplo redes no públicas).
>> - Agregué información normativa como fue
>> consensuado en la lista.
>> - Agregué la justificación relacionada con la
>> antiguedad de la información
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>