[LACNIC/Politicas] LAC-2023-7 v2 - comentarios adicionales

jordi.palet at consulintel.es jordi.palet at consulintel.es
Wed May 15 12:39:28 -03 2024


Hola Jesus David,

Te contesto debajo entre líneas solo a algunos puntos para aclararnos.

Saludos,
Jordi

@jordipalet


> El 15 may 2024, a las 17:19, Jesus David Macmahon Vergara <jedmacmahonve at unal.edu.co> escribió:
> 
> ¡Hola chicos, buen día, increíble que el hilo de esta discusión vuelva a
> tan rápido!
> 
> Aquí mis comentarios respecto!
> 
> 1) Restringir las transferencias temporales a /20, otro prefijo o sin
> restricción?
> *No debería haber restricción de tamaño al momento de realizar
> transferencias, ya que esto lo debe pactar el dueño del prefijo y el
> receptor!*
> 2) Mantener la justificación de la necesidad o eliminarla?
> *Deberíamos mantener la justificación de uso, con eso al menos tenemos un
> filtro.*
> 3) Requisitos adicionales.
> *El dueño del prefijo se encargaría de filtrar a sus clientes, ellos ya lo
> hacen con sus contratos y filtros, entonces no deberíamos cargar al RIR con
> eso. (¿Cómo lo hacen en los RIR's donde permiten transferencias
> temporales?)*

Tal y como está redactada la propuesta ahora mismo no es así.

El dueño del prefijo, cuando hacemos una transferencia temporal, al igual que con una transferencia definitiva, diría que en el 99,99% de los casos no es quien proporciona tránsito (luego no puede filtrar nada) al que recibe las direcciones (de otro modo no sería una transferencia, sino un uso legítimo de las direcciones como parte del servicio de conectividad). Precisamente lo que la propuesta dice es que no sea el RIR quien se ocupa de esto. Los pasos, como yo lo veo, serían a grandes rasgos:
a) El RIR puede elaborar un modelo de contrato (posiblemente de la mano de algunos brokers que ya lo tienen, al menos la parte que implique el cumplimiento de la política), que cumpla con la política. Esto es opcional. Alternativamente los brokers pueden hacer el contrato y confirmar con LACNIC - si tienen dudas - que cumple. No lo sabia, pero en al menos un RIRs hay modelos de contratos (he hecho una búsqueda rápida).
b) El oferente es el que tendrá que confirmar que el contrato se cumple. es obvio, porque también tendrá otras condiciones, no relacionadas con la política que le conviene que se cumplan.
c) El RIR podrá verificarlo en cualquier momento, entiendo que se pueden hacer algunas verificaciones automáticas, como ya se hacen para otras partes del manual de políticas, pero también se hacen auditorias periódicas, o se atiende a denuncias, sospechas, etc., etc.

Es decir, a priori, el RIR solo tiene que confirmar la justificación de la necesidad (igual que ahora con las transferencias definitivas) y que el contrato es conforme con la política. El resto de cumplimientos de politicas tal y como se hacen ahora.

A ningún oferente le interesa que haya incumplimiento por parte de sus clientes, porque entonces, si reincide, LACNIC podría recuperar los recursos. Exactamente igual que ocurre hoy con el resto de las políticas.

El único RIR que permite transferencias temporales es RIPE NCC, y no hay ningún tipo de restricciones, ni siquiera justificación de la necesidad. Te podrás imaginar que yo no estoy de acuerdo con ello, es un “wild west”.

> a) Que las direcciones no puedan ser utilizadas para abusos.
> *El dueño del prefijo deberá garantizar que estos no sean utilizados para
> abusos.*
> 

Eso es lo que tenemos en el texto propuesto.

> b) Disponer de IPv6. *Seria increible pero quien lo comprueba?*

Considero que no es nada difícil comprobarlo. Igualmente se están haciendo medidas en todo el mundo de que hay tráfico IPv6 y que cantidades. Los resultados los tienes por ASNs. Desde APNIC, Google, Akamai, Meta, etc.

> c) Disponer de RPKI. *El usuario debe implementarlo, ¿por qué no debería
> hacerlo?*
> d) Geolocalización e IRR. *El usuario debe hacerlo,* *¿por qué no debería
> hacerlo?*
> e) Cumplir con MANRS. *El usuario debe hacerlo,* *¿por qué no debería
> hacerlo?*
> 
> 

Entiendo que estas de acuerdo con estas 3 últimas.

> 
> 
> El mar, 14 may 2024 a las 9:07, jordi.palet--- via Politicas (<
> politicas at lacnic.net>) escribió:
> 
>> Hola a todos,
>> 
>> Con este correo quiero debatir a algunos de los comentarios, tras revisar
>> el video, que hubo durante la presentación de la propuesta en el pasado
>> foro, dado que íbamos muy justos de tiempo.
>> 
>> Sería muy importante recibir feedback al respecto de los siguientes puntos
>> que creo que son los mas debatidos, obviamente no exclusivamente:
>> 
>> 1) Restringir las transferencias temporales a /20, otro prefijo o sin
>> restricción?
>> Bajo mi punto de vista, y con la experiencia de casos reales de despliegue
>> de IPv6, puede haber muchos casos de operadores que tengan varios PoPs
>> donde conectan a sus upstreams y por lo tanto necesitan un /24 por cada uno
>> de ellos, dado que no pueden anunciar eficazmente, por ejemplo, un /25 o
>> /26. Por lo tanto un /22 sería excesivamente pequeño en algunos casos. La
>> alternativa es no poner limite alguno. Personalmente no tendría problema en
>> ello si mantenemos la justificación de la necesidad.
>> 
>> 2) Mantener la justificación de la necesidad o eliminarla? Personalmente
>> creo que es importante mantenerla. No le veo el sentido a que se puedan
>> realizar transferencias de ningún tipo si no hay una necesidad demostrada,
>> pues entonces impera el poderío económico frente a los que realmente
>> necesitan direcciones.
>> 
>> 3) Requisitos adicionales. Mi lectura de la discusión de esta propuesta y
>> de la que se presentó con objetivos similares, es que una parte
>> (importante) de la comunidad desea que haya un grado de control. Además,
>> las propias empresas de leasing nos han dicho que ellos imponen ese control
>> en sus contratos. Por lo tanto, dado que puede haber empresas de leasing
>> “buenas y malas” (entendiendo aquí por malas aquellas que alquilan las
>> direcciones sin comprobar nada, e incluso a sabiendas de que pueden ser
>> usadas de forma maliciosa, generando casos de abuso, etc.), porque no
>> uniformizar los requisitos para que todas estén no solo buscando su
>> negocio, sino también siendo buenos “cyber-ciudadanos” y contribuyendo al
>> bien de la comunidad?
>> 
>> De forma resumida, veamos esas restricciones, para entender si el problema
>> es que debe haber ciertas restricciones, pero no todas (por ejemplo):
>> a) Que las direcciones no puedan ser utilizadas para abusos. Alguna razón
>> por la que debamos permitir abusos desde esas direcciones?
>> b) Disponer de IPv6. Quizás que sea al menos un compromiso el despliegue
>> de IPv6?
>> c) Disponer de RPKI. Porque no va a desplegar RKPI alguien que reciba
>> recursos?
>> d) Geolocalización e IRR. Porque no va a geolocalizar y tener
>> correctamente el IRR alguien que reciba recursos?
>> e) Cumplir con MANRS. Porque no va a desear cumplir con MANRS quien recibe
>> direcciones?
>> 
>> Si lo pensamos detenidamente, se me hace difícil comprender que alguien
>> que recibe recursos para usos “buenos” no quiera protegerse también y
>> cumplir con estos requisitos. Entiendo que pueda haber otros puntos de
>> vista, pero creo que es necesario explicarlos y debatirlos.
>> 
>> 4) Misma sección de transferencias definitivas o diferente. Creo que el
>> problema es meramente editorial y que en realidad “en este momento” puede
>> parecer que se lee confuso, porque en una propuesta tal y como se lee en el
>> sistema de políticas, no se lee tan fácilmente. Si ponemos en un PDF a dos
>> columnas el texto actual con el texto propuesto, bajo mi punto de vista, le
>> lee perfectamente.
>> 
>> Saludos,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the exclusive use of
>> the individual(s) named above and further non-explicilty authorized
>> disclosure, copying, distribution or use of the contents of this
>> information, even if partially, including attached files, is strictly
>> prohibited and will be considered a criminal offense. If you are not the
>> intended recipient be aware that any disclosure, copying, distribution or
>> use of the contents of this information, even if partially, including
>> attached files, is strictly prohibited, will be considered a criminal
>> offense, so you must reply to the original sender to inform about this
>> communication and delete it.
>> 
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>> Desuscribirse/Descadastre-se/Unsubscribe
>> <https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe>:
>> https://mail.lacnic.net/mailman/options/politicas
>> 
>> El Codigo de Conducta de la Comunidad de LACNIC (
>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
>> LACNIC.
>> O Codigo de Conduta da Comunidade do LACNIC (
>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
>> LACNIC.
>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
>> applies to LACNIC's discussion lists.
>> 
>> 
> 
> -- 
> *Aviso legal:* El contenido de este mensaje y los archivos adjuntos son 
> confidenciales y de uso exclusivo de la Universidad Nacional de Colombia. 
> Se encuentran dirigidos sólo para el uso del destinatario al cual van 
> enviados. La reproducción, lectura y/o copia se encuentran prohibidas a 
> cualquier persona diferente a este y puede ser ilegal. Si usted lo ha 
> recibido por error, infórmenos y elimínelo de su correo. Los Datos 
> Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra 
> Política de Datos Personales que podrá consultar en la página web 
> www.unal.edu.co <http://www.unal.edu.co/>.* *Las opiniones, informaciones, 
> conclusiones y cualquier otro tipo de dato contenido en este correo 
> electrónico, no relacionados con la actividad de la Universidad Nacional de 
> Colombia, se entenderá como personales y de ninguna manera son avaladas por 
> la Universidad.
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> Desuscribirse/Descadastre-se/Unsubscribe: https://mail.lacnic.net/mailman/options/politicas
> 
> El Codigo de Conducta de la Comunidad de LACNIC (https://rir.la/codigoconducta-SP) aplica a las listas de discusion de LACNIC.
> O Codigo de Conduta da Comunidade do LACNIC (https://rir.la/codigoconducta-PT) se aplica as listas de discussao do LACNIC.
> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN) applies to LACNIC's discussion lists.
> 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



More information about the Politicas mailing list