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

[Ricardo Patara]

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
>