[LACNIC/Politicas] LAC-2012-1

Ricardo Patara patara at registro.br
Thu Sep 6 12:02:16 BRT 2012 

Hola Roque, te contesto en línea:

> 1) Valides de la información:
> Entiendo que tu comentario era sobre la "forma" de los objetos
> firmados. Obviamente si alguien usa el sistema "hospedado" de LACNIC o
> de un NIR esto está descartado. Por eso no lo consideré en la propuesta
> original. Es cierto que si alguien administra su propia entidad
> certificadora, sería bueno hacer un chequeo. Aquí estamos hablando de
> chequear los objetos.

No solamente cuanto a la forma, pero que la información sea "correcta".
Por ejemplo. Para una ROA, que de hecho figure allá el ASN por lo cual
el ISP va a originar sus anuncios. Y eso implica en trabajo extra para
los RIR/NIRs.
Y

> 2) Mantenimiento de la información (o en inglés "information aging"):
> Esto es un problema tradicional de cualquier base de datos de
> registro. Existe este problema actualmente con, digamos, la información
> de Whois de LACNIC.
> Personalmente, yo creo que la política es incluso una mejora en este
> sentido pues le da los instrumentos al staff para requerirle a un
> miembro a que actualice la información en la base de datos.

No estoy de acuerdo que eso va a mejorar la calidad de la información.
Si no hay incentivos para utilizar una tecnología, no habrá incentivos
para mantener la información actualizada.

Y la información de RPKI tiene poca relación con información de
asignación/sub asignación (en lo que toca el whois).

> 3) Verificación de información de ruteo:
> Esto no esta incluido en la propuesta, justamente por la dependencia
> en el punto de observación. Por eso mi comentario de que en general
> las herramientas para generar los objetos RPKI (i.e. la web de
> rpki.lacnic.net o las herramientas que comentaba Arturo) ayudan a un
> operador a crear ROAs "adecuados".

Okay, pero poner la necesidad de generalos asociada a justificativa de
obtener asignación no es adecuado. Ese es mí punto.

> 4) Motivación de despliegue:
> Hay diferentes factores que motivan el despliegue de una tecnología.
> Hay factores económicos, regulatorios, políticos, ecológicos, etc
> (i.e. análisis de PESTEL). Personalmente, creo que esta política
> motiva la creación de material criptográfico que aumente el valor
> percibido de la tecnología no para una entidad específica, pero para
> el conjunto de la comunidad.

Que es mejor, tener un montón de información "sin calidad" o pocas pero
de calidad buena?

> 5) Madurez de la tecnología:
> Justamente la adopción de esta política va a fomentar más material
> criptográfico y por ende más resultados concretos para seguir
> mejorando la madurez de la tecnología. Yo creo realmente en el valor
> de diseños iterativos e incrementales (i.e. ágiles).

No estoy de acuerdo.
Creo que lo que está haciendo LACNIC está bien, o sea, los tutoriales,
charlas, etc. Eso crea masa critica no solamente para implementar sino
que para discutir

"Obligar" uno a ir por ese camino no creo que es lo que va a traer la
madurez.

abrazos.
Ricardo

> Roque
>  
> 
> 
> On Sep 6, 2012, at 3:11 PM, Ricardo Patara wrote:
> 
>> Hola,
>>
>> Como decía, creo que es interesante el esfuerzo en motivar RPKI, pero
>> quería explicitar que no estoy de acuerdo a la propuesta.
>>
>> hay ese punto en relación a los NIRs y eso puede ser interpretado
>> también que se está intentando poner criterios en las políticas con base
>> en algo "técnico" pero que todavía no está aún en el nível de madurez
>> deseado.
>>
>> Cuanto al comentario de Roque en se agregar verificación en los objetos
>> (roas, certs) de acuerdo rfcs. Es un paso, pero nuevamente, tener eso en
>> la política por si solo no va a motivar el uso de la tecnología.
>>
>> Por ejemplo. Suponga que estos criterios de verificación figuren en la
>> política y tal verificación se haga al momento de la solicitud de
>> bloques adicionales. Qué motivación va a tener el ISP en mantener estos
>> objetos "correctos" y actualizados?
>>
>> Y mismo que se agregue ese último comentario de Christian, de que la
>> asignación es válida desde que se mantenga actualizada la información de
>> RPKI. Como LACNIC verificaría eso?
>> Una cosa es registrar información de sub asignación. Otra es registrar
>> información de ruteo. Qué parametros seguiría LACNIC para verificar eso?
>>
>> Y nuevamente al punto, como les parece que eso motiva el despliegue da
>> la tecnología?
>> Uno puede tener todo bien registrado, pero qué vale si nadie lo usa
>> porque no sabe, no conoce?
>>
>> No me gusta la idea de hacer adoptada una tecnología (en especial nueva
>> y no tan madura), a través de políticas de asignación.
>>
>> Abrazos.
>>
>>  Ricardo Patara
>>
>> Em 06-09-2012 09:56, Christian O'Flaherty escreveu:
>>> Apoyo la propuesta incluyendo los comentarios de Ricardo (hacer alguna
>>> referencia al caso de los NIR e incluir la "verificación" del ROA).
>>>
>>> Tambien habría que modificar este punto del manual:
>>>
>>> 2.3.2.10. Validez de las distribuciones de direcciones IPv4
>>>
>>> Las distribuciones de direcciones IPv4 son válidas mientras...
>>>
>>> mantener actualizada la información de las distribuiciones y
>>> asignaciones en la base de datos Whois de LACNIC + RPKI
>>>
>>> Tambien habría que incluirlo en el manual para las asignaciones IPv6,
>>> no? (4.5.6, 4.5.2, etc.)
>>>
>>> Christian
>>>
>>> 2012/9/6 Roque Gagliano (rogaglia) <rogaglia at cisco.com>:
>>>> Hola Ricardo,
>>>>
>>>> On Sep 6, 2012, at 2:10 PM, Ricardo Patara wrote:
>>>>
>>>>> Hola Roque,
>>>>>
>>>>>>>
>>>>>>> Me pareció interesante la idea. Pero me preocupa en especial qué pasaría
>>>>>>> con los NIRs que siguen las políticas de LACNIC pero que todavía no
>>>>>>> tienen un sistema RPKI?
>>>>>>
>>>>>> Quizás sea un incentivo para que lo implementen? Me imagino que los NIR tienen su plan y este tipo de discusiones las deberían tener con sus comunidades.
>>>>>
>>>>> comprendo. pero mi pregunta es que pasaría si la propuesta es aceptada
>>>>> pero los NIRs no tiene todavía su RPKI?
>>>>
>>>> Dicho esto, entiendo que LACNIC, los NIR y sus respectivas comunidades se pondrán de acuerdo en una hoja de ruta razonable para implementar la política. No es lo que sucede en todos los casos?
>>>>
>>>>>>> Además de eso la propuesta no indica nada cuanto a validez de los dados
>>>>>>> de RPKI, por ejemplo, no indica que si la ROA tiene o no que ser válida,
>>>>>>> tampoco si los certificados tienen o no que estar validos (no revocados
>>>>>>> y dentro de las fechas de validez).
>>>>>>>
>>>>>>> Si la idea es motivar el uso, hay que tener preocupación con la validez
>>>>>>> y también de alguna forma motivar su uso. Creo que faltaría esa parte en
>>>>>>> la propuesta.
>>>>>>
>>>>>> Aquí hay dos cosas:
>>>>>>     - "valido" o "invalido" es una clasificación que depende del punto de observación. Por esto no creo que podamos poner ningún texto que ayude aquí. Para mitigar errores de tipeo por parte de los operadores, las herramientas ayudan al operador con información sobre el status de la tabla global de rutas en distintos puntos de observación (RIS o Routeviews).
>>>>>
>>>>> valido y invalido lo queria decir no es en comparación con las rutas,
>>>>> sino que un objeto ROA "correctamente" creado.
>>>>>
>>>>> Uno puede por ejemplo crear un ROA de cualquier forma solamente para
>>>>> cumplir con la solicitud de recursos adicionales y poner por ejemplo ASN
>>>>> 0, o un ASN reservado, o otra cosa.
>>>>>
>>>>>
>>>>>>     - hay un tema de "aging" de la información. Básicamente por más que la información sea "correcta" en el momento de crearla, al pasar el tiempo la info en el RPKI no acompañe la información en el sistema de rutas. Esta propuesta ayuda con la mitigación de este problema pues obliga al ISP a revisar sus ROAs cada vez que pide nuevos  bloques.
>>>>>
>>>>> y nuevamente, si la idea es motivar el uso, al no hacer controle o tener
>>>>> motivaciones para que la información sea valida pueda crear más problemas.
>>>>>
>>>>> Uno puede crear una ROA "incorrecta", o crear y revocar su certificado
>>>>> EE solamente para cumprir con los tramites.
>>>>>
>>>>> Y si al mismo tiempo un provedor inicia el uso/verificación, el problema
>>>>> al ISP que genero los datos puede ser mayor.
>>>>>
>>>>> Lo que quiero decir con eso, que es interesante motivar, pero poner en
>>>>> la política puntos que uno puede "cumplir" por "cumplir" sin otras
>>>>> medidas que motiven el uso puede ser peor .
>>>>
>>>> Entiendo tu punto. Perdón por la confusión.
>>>>
>>>> Te parece agregar que los certificados sean validos según RFC6481 y los ROAs según RFC 6483?
>>>>
>>>> Roque
>>>>
>>>>>
>>>>> saludos
>>>>> Ricardo
>>>>>
>>>>>> Roque
>>>>>>
>>>>>>> un abrazo.
>>>>>>>
>>>>>>> Ricardo Patara
>>>>>>>
>>>>>>> Em 06-09-2012 04:59, Roque Gagliano (rogaglia) escreveu:
>>>>>>>> Hola Gente,
>>>>>>>>
>>>>>>>> Yo soy el autor de LAC-2012-11.
>>>>>>>>
>>>>>>>> Básicamente la propuesta es muy simple. Lo que dice es que agreguemos a los requerimientos para obtener recursos adicionales que una entidad tenga que registrar en el RPKI los recursos que ya tiene.
>>>>>>>>
>>>>>>>> El objetivo es simplemente solucionar un problema administrativo y lograr acelerar la adopción de RPKI. Muchas veces la persona con la clave del sistema de LACNIC no es la misma que opera la red. Con este pedido, simplemente les pedimos a ambas entidades que se "comuniquen" y coloquen la información en el sistema RPKI. También logramos que más miembros se eduquen sobre las capacidades RPKI.
>>>>>>>>
>>>>>>>> El costo para el miembro es mínimo pues la política no pide que registre bloques delegados y pues se puede solucionar con dos o tres clicks en la web RPKI de LACNIC.
>>>>>>>>
>>>>>>>> Espero sus comentarios.
>>>>>>>> Roque
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sep 6, 2012, at 4:45 AM, Nicolas Antoniello wrote:
>>>>>>>>
>>>>>>>>> Dear Policy-list Members,
>>>>>>>>>
>>>>>>>>> There are three new Policy Proposals; numbers LAC-2012-09, LAC-2012-10 and
>>>>>>>>> LAC-2012-11:
>>>>>>>>>
>>>>>>>>> - LAC-2012-09 Update
>>>>>>>>> RIRs-on-48<http://lacnic.net/documentos/politicas/lac-2012-09-EN.pdf>
>>>>>>>>> - LAC-2012-10 Allocation of IPv6 address blocks larger than a
>>>>>>>>> /32<http://lacnic.net/documentos/politicas/lac-2012-10-EN.pdf>
>>>>>>>>> - LAC-2012-11 Requirement to sign up for RPKI when requesting additional
>>>>>>>>> resources <http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>>>>>>>>
>>>>>>>>> <http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>>>>>>>>
>>>>>>>>> As your comments are important, we encourage you to express your views on
>>>>>>>>> the proposals:
>>>>>>>>>
>>>>>>>>>     - Do you support or oppose this proposal?
>>>>>>>>>     - Does this proposal solve a problem you are experiencing? If
>>>>>>>>>       so, tell the community about your situation.
>>>>>>>>>     - Do you see any disadvantages in this proposal?
>>>>>>>>>     - Is there anything in the proposal that is not clear?
>>>>>>>>>     - What changes could be made to this proposal to make it more
>>>>>>>>>       effective?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Max Larson Henry
>>>>>>>>> Nicolas Antoniello
>>>>>>>>> co-Chairs of Public Policy Forum - LACNIC
>>>>>>>>>
>>>>>>>>> ===================================================================================
>>>>>>>>>
>>>>>>>>> Estimados suscriptores de la lista de políticas de LACNIC,
>>>>>>>>>
>>>>>>>>> Se recibieron tres nuevas propuestas de Política; números LAC-2012-09,
>>>>>>>>> LAC-2012-10 y LAC-2012-11:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - LAC-2012-09 Actualización
>>>>>>>>> RIRs-on-48<http://lacnic.net/documentos/politicas/lac-2012-09-SP.pdf>
>>>>>>>>> - LAC-2012-10 Distribución de direcciones IPv6 mayores que
>>>>>>>>> /32<http://lacnic.net/documentos/politicas/lac-2012-10-SP.pdf>
>>>>>>>>> - LAC-2012-11 Requerimiento de inscripción en RPKI para recursos
>>>>>>>>> adicionales <http://lacnic.net/documentos/politicas/lac-2012-11-SP.pdf>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dado que sus comentarios son importantes, solicitamos que exprese sus
>>>>>>>>> puntos de vista sobre las propuestas:
>>>>>>>>>
>>>>>>>>>     - ¿Apoya usted o se opone a esta propuesta?
>>>>>>>>>     - ¿Ésta propuesta resolvería un problema que ud. está
>>>>>>>>> experimentado? En caso
>>>>>>>>>         afirmativo, podría describir sus situación?
>>>>>>>>>     - ¿Ve alguna desventaja en esta propuesta?
>>>>>>>>>     - ¿Hay algo en la propuesta que no está claro?
>>>>>>>>>     - ¿Qué cambios podrían hacerse a esta propuesta para que sea
>>>>>>>>> más eficaz?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Max Larson Henry
>>>>>>>>> Nicolas Antoniello
>>>>>>>>> Moderadores del Foro Público de Políticas de LACNIC
>>>>>>>>>
>>>>>>>>> ====================================================================================
>>>>>>>>>
>>>>>>>>> Prezados membros da lista políticas do LACNIC,
>>>>>>>>>
>>>>>>>>> Se recebeu os três seguintes propostas de Política é asignó o numero
>>>>>>>>> LAC-2012-09, LAC-2012-10 é LAC-2012-11:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - LAC-2012-09 Atualização
>>>>>>>>> RIRs-on-48<http://lacnic.net/documentos/politicas/lac-2012-09-PT.pdf>
>>>>>>>>> - LAC-2012-10 Alocações IPv6 maiores que
>>>>>>>>> /32<http://lacnic.net/documentos/politicas/lac-2012-10-PT.pdf>
>>>>>>>>> - LAC-2012-11 Requerimento de inscrição no RPKI para recursos
>>>>>>>>> adicionais<http://lacnic.net/documentos/politicas/lac-2012-11-PT.pdf>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Considerando que seus comentários são importantes, pedimos que expresse
>>>>>>>>> suas opiniões sobre as propostas:
>>>>>>>>>
>>>>>>>>>      - Você apoia ou se opõe a esta proposta?
>>>>>>>>>      - Esta proposta resolveria um problema que você experiencia?
>>>>>>>>>         No caso afirmativo, você poderia descrever a sua situação?
>>>>>>>>>      - Você vê algum inconveniente com esta proposta?
>>>>>>>>>      - Há algo na proposta que não está claro?
>>>>>>>>>      - Que mudanças poderiam ser feitas para a presente proposta
>>>>>>>>>         para torná-lo mais eficaz?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Max Larson Henry
>>>>>>>>> Nicolás Antoniello
>>>>>>>>> Moderadores do Foro Público de Políticas - LACNIC
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>

More information about the Politicas mailing list