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

Mon Oct 8 09:58:46 BRT 2012

Roque,

Comentarios entre lineas.

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

> 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.
>
>
Si. En la parte de IPv6 del manual de politicas no veo como llegas a la
conclusion de que la inversa de DNS es necesario para una asignacion
adicional.

> > 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.
>
>
Nadie esta hablando de no ofrecer RPKI.

Creo que el esquema actual es el adecuado: RPKI es implementado por los
ISPs porque ellos lo consideran necesario y no porque las politicas lo
forzan. LACNIC promueve la adopcion con educacion, seminarios, etc.

Mi pregunta a legal es porque no me gustaria que al aprobar tu propuesta
expongamos a LACNIC a un problema.

Las consecuencias de los escenarios de error con RPKI a diferencia con
WHOIS/DNS inverso son en mi opinion muy diferentes.

> > 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.
>
>
Entonces, este texto:

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.

Su objetivo es que el hostmaster le pregunte al ISP si tiene ROAs, y el
hostmaster le platique al ISP sobre los ROAs, ya que el ISP basicamente no
estaria forzado a generar ROAs.

No veo la utilidad sinceramente en este texto y ahora entiendo porque tu
propuesta esta siendo comparada con un ejercicio academico.

Saludos,
Gustavo

> 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
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>

-- 

Regards,
Gustavo Lozano