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

Roque Gagliano (rogaglia) rogaglia at cisco.com
Mon Oct 8 09:13:46 BRT 2012 

Gustavo,

El texto dice:

"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."

El condicional refleja la discutido en la lista. Creo que eso puede ser dejado a que el analista la discuta con el solicitante, pero si quieres puedes ofrecer texto.

te contesto el resto entre líneas.

slds
Roque


>> 
> Entonces, la propuesta no es clara:
> 
> "Pedido de ROAs y repositorios es condicional.
> Esto es pues pueden haber razones para no publicar ROAs (por ejemplo redes
> no públicas)."
> 
> Como LACNIC decide que es una red publica y cual no lo es?
> 
> Y este texto: "Si corresponde, se solicitará que el solicitante verifique
> que cuente con:", significa que el solicitante se verifica a si mismo?
> 
> Favor de clarificar.
> 
>> 
>>>> - La reflexión es la siguiente y toca el tema de la responsabilidad de
>>>> LACNIC... si lo que consultas asumimos que puede ser de esa manera, que
>>>> sucede si por un "bug en el registro de LACNIC" uno tiene problemas con
>> sus
>>>> reversos o delegación de prefijos DNS? tiene sentido hacer responsable
>> al
>>>> RIR al nivel de una compensación? O es más razonable buscar soluciónar
>> el
>>>> problema mitigando el efecto hasta que el "bug" sea resuelto?
>>>> Lo mismo aplica a una política aprobada que fuese de alguna manera
>>>> "perjudicial" para los intereses de algún miembro...
>>>> 
>>>> 
>>> Posiblemente se me escapo al leer el manual de políticas, pero no
>> encuentro
>>> donde se especifique como requisito tener delegaciones de reversa de DNS
>>> para obtener direccionamiento adicional.
>> 
>> Definitivamente se te escapó: tienes que ver 2.3.4 punto 5. Hay otra serie
>> de obligaciones.
>> 
>> 
> Si el argumento de la resolucion inversa es la justificacion para tu
> propuesta creo que es muy debil por la diferencia de escenarios de error, y
> porque solamente aplica para IPv4.
> 

??? Te puedo buscar la referencia para IPv6.... Ya creo que cerramos el tema de la relación del manual con otras tecnologías.


> Nota para el webmaster: he estado usando el manual en linea "
> http://www.lacnic.net/web/lacnic/manual-2" y al parecer los bullets
> numericos no estan presentes (al menos en chrome y firefox)
> 
>> 
>>> Si RPKI es utilizado por la mayoría de los grandes ISPs, un error en el
>>> firmado de tus prefijos puede ocasionar que tus prefijos no sean visibles
>>> en Internet, para un ISP o un usuario final eso podría significar
>> perdidas
>>> cuantiosas.
>>> 
>>> Ahora bien, el escenario que me preocupa es si las políticas me obligan a
>>> usar RPKI, y es donde me gustaría escuchar la opinión de legal de LACNIC.
>>> Las políticas obligan a un ISP a usar RPKI, entonces si LACNIC comete
>>> errores con RPKI con repercusiones para el negocio del ISP, podría el ISP
>>> demandar a LACNIC y tener posibilidades reales de obtener una reparación
>>> económica?
>>> 
>>> Creo que el escenario actual no representa problema alguno para LACNIC
>>> porque las políticas no te obligan a usar la tecnología RPKI.
>>> 
>> 
>> Creo que tu punto es interesante.
>> 
>> Personalmente veo que si utilizas el servicio "hosted", quiere decir que
>> estás atado a las condiciones de uso:
>> http://lacnic.net/en/rpki/cps/condiciones-uso.html
>> 
>> Sino, puedes utilizar tu propio software y operación.
>> 
> 
> El servicio "hosted" fue para ejemplificar el escenario.
> 
> El escenario que planteo es el mismo, LACNIC es un eslabon mas de la
> cadena, y aunque no utilice el servicio "hosted" es necesaria la correcta
> operacion de la infraestructura de RPKI de LACNIC
> 
> De igual forma, me gustaria escuchar la opinion de legal de LACNIC al
> respecto.
> 
> Respecto a los terminos y condiciones, creo que apoyan el argumento de que
> tu propuesta no es viable.
> Como se puede exigir implementar una tecnologia a los miembros, cuando
> LACNIC no ofrece garantia sobre la infraestructura para sopotar la misma?
> 

Entonces dejamos de dar el servicio de whois o de reverso DNS? En este sentido están en la misma condición. Tengo la impresión que estás tratando de ser más papista que el papa y no entiendo bien porqué. O acaso ICANN es responsable por el lucro-sesante del servicio de Root-DNS? estas mismas condiciones están en toda letra chica de contrato de registro, sino el riesgo financiero sería tan grande que no tendríamos ningún registro posible. 

> Creo que los terminos de uso y el estatus actual de las politicas es el
> adecuado, la utilizacion de RPKI es por decision propia del ISP.
> 

La mismo aplica para la propuesta pues pusimos en condicional el generar el ROA. Básicamente queda algo abstracto que estás fomentando la discusión entre el hostmaster y el solicitante.

Roque

> 
>> Roque
>> 
>>> 
>>>> Entiendo tu preocupación. En lo personal creo que no correspondería
>> buscar
>>>> compensación sino más bien solución. Pues más allá de que podamos estar
>> de
>>>> acuerdo o no con ciertas políticas, estas son de y para la comunidad y
>> creo
>>>> que no podemos ni corresponde responsabilizar al RIR por las mismas.
>>>> 
>>> 
>>> La pregunta es si LACNIC esta blindado legalmente por el proceso
>>> "bottom-up" en el escenario que describo con anterioridad porque no deja
>> de
>>> ser el directorio quien ratifica las propuestas.
>>> 
>>> 
>>>> Nosotros como comunidad somos en ultima instancia los responsables de
>> que
>>>> una política llegue a ser aplicada o no... para eso debatimos e
>>>> intercambiamos opiniones.
>>>> 
>>> 
>>> Totalmente de acuerdo, y me interesa analizar a profundidad la propuesta
>>> desde todos los ángulos (técnicos, operativos, legales, etc).
>>> 
>>> 
>>>> 
>>>> En definitiva, en lo personal creo que la respuesta a la consulta que
>> haces
>>>> es un "no, no corresponde compensación"...
>>>> 
>>>> 
>>> Gracias por la respuesta. Me gustaría escuchar también la opinión de
>> legal
>>> de LACNIC al respecto.
>>> 
>>> Saludos,
>>> Gustavo Lozano
>>> 
>>> Fraterno saludo,
>>>> Nico
>>>> 
>>>> 
>>>> 
>>>> 2012/10/7 Gustavo Lozano <glozano.gli at gmail.com>
>>>> 
>>>>> Creo que ya expuse mis argumentos por los cuales seria un error aprobar
>>>> la
>>>>> propuesta LAC-2012-011, los cuales aplican para la versión 2 de la
>> misma.
>>>>> 
>>>>> 
>>>>> Ha sido un buen ejercicio pensar en las ramificaciones de propuestas
>> que
>>>>> buscan forzar tecnologías en los miembros.
>>>>> 
>>>>> 
>>>>> Durante mi análisis de esta propuesta, me surge una duda que me
>> gustaría
>>>>> que el staff de LACNIC me apoyara a resolver:
>>>>> 
>>>>> 
>>>>> Si la propuesta LAC-2012-011 fuera aprobada, y ratificada por el
>>>>> directorio, entonces los miembros de LACNIC se verían forzados a
>>>> desplegar
>>>>> una tecnología. Si un miembro tuviera problemas (ej. problemas de
>>>>> visibilidad de sus prefijos) por un error atribuible al sistema de
>> LACNIC
>>>>> (ej. bug en el sistema RPKI de LACNIC) podría ese miembro buscar una
>>>>> compensación económica por parte de LACNIC?
>>>>> 
>>>>> Saludos,
>>>>> Gustavo Lozano
>>>>> 
>>>>> 2012/10/5 Max Larson Henry <maxlarson.henry at transversal.ht>
>>>>> 
>>>>>> Estimados suscriptores de la lista de políticas de LACNIC,
>>>>>> 
>>>>>> Se recibió una nueva versión (2) de la propuesta de Política
>>>>> LAC-2012-011:
>>>>>> 
>>>>>> -----------------------------------------
>>>>>> 
>>>>>> Prezados membros da lista políticas do LACNIC,
>>>>>> 
>>>>>> Se recebeu uma nova versão (2) da proposta de Política LAC-2012-011 :
>>>>>> 
>>>>>> -----------------------------------------
>>>>>> 
>>>>>> Dear Policy-list Members,
>>>>>> 
>>>>>> There is a new version (2) of the Policy Proposal LAC-2012-011:
>>>>>> 
>>>>>> It' will be published shortly in the other two LACNIC working
>>>> languages.
>>>>>> 
>>>>>> Max Larson Henry
>>>>>> Nicolas Antoniello
>>>>>> co-Chairs of Public Policy Forum - LACNIC
>>>>>> 
>>>>>> ============================================================
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Regards,
>>>>> Gustavo Lozano
>>>>> _______________________________________________
>>>>> 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
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> 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
>> 
> 
> 
> 
> -- 
> 
> Regards,
> Gustavo Lozano
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas

More information about the Politicas mailing list