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

Mon Oct 8 08:53:54 BRT 2012

Roque,

Comentarios entre lineas.

2012/10/8 Roque Gagliano (rogaglia) <rogaglia at cisco.com>

> Gustavo,
>
> On Oct 8, 2012, at 4:12 AM, Gustavo Lozano wrote:
>
> > Comentarios en linea.
> >
> > 2012/10/7 Nicolas Antoniello <nantoniello at gmail.com>
> >
> >> Chair Hat == Off;
> >>
> >> Hola Gustavo,
> >>
> >> Tengo una consulta y una reflexión:
> >>
> >> - Cuando te referís a "obligado a desplegar", asumo que es únicamente a
> la
> >> generación de ROA y firma de los prefijos... el resto (es decir ir más
> >> allá) queda a criterio de cada uno y no es está obligado por la política
> >> propuesta no?
> >>
> >>
> > Si, y parte del despliegue es la generación de ROA y firma de prefijos.
>
> En la nueva propuesta no se pide la generación de ROAs.
>
>
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.

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?

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.

> 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