[LACNIC/Politicas] Nueva propuesta LAC-2021-1 / Nova proposta LAC-2021-1 / New proposal LAC-2021-1

Fernando Frediani fhfrediani at gmail.com
Thu May 20 23:19:16 -03 2021


Hola Hernán, ¿cree que LACNIC no debe fiscalizar si los recursos 
entregados a una organización continúan siendo utilizados de la forma en 
que estaban justificados? Cuál es tu miedo ?
¿Por qué existe la posibilidad de revocar recursos en el manual de 
políticas si está en contra de la "policía de recursos de Internet"? 
Cual es el sentido? (no confundir con la policía de enrutamiento)
Creo que quizás no he leído o entendido algunas de las cosas que 
escribí, porque para mí quien está conscientemente en contra solo hay 
una razón: querer usar los recursos de numeración de manera contraria a 
lo que prevén las políticas.

Digo de nuevo, si no creemos que esta sea una de las funciones del RIR, 
pasamos a un escenario de anarquía donde, luego de recibir los recursos 
de numeración, el titular ya no debería rendir cuentas a nadie sobre el 
uso de esos recursos (que no le pertenecen). ¿De dónde pueden surgir 
este tipo de ideas?
El trabajo del RIR no termina en el momento en que entrega o asigna 
recursos a una organización y los registra en el whois, sino que es 
continuo en el sentido de monitorear si esos recursos se están 
utilizando adecuadamente y en ese sentido no hay nada de malo en 
diciendo que es el supervisor de eso todo.

Fernando

On 20/05/2021 22:10, Hernan Moguilevsky wrote:
> Hola todos,
>
> En contra de cualquier forma de “policía” de los recursos de Internet.
>
> A favor de la propuesta, que es sólo un intento registro de lo que sucede
> en la práctica.
>
> Saludos.
>
>
> El El jue, 20 may. 2021 a la(s) 18:46, Fernando Frediani <
> fhfrediani at gmail.com> escribió:
>
>> Hola Carlos
>>
>> On 20/05/2021 17:19, Carlos M. Martinez wrote:
>>> Fernando,
>>>
>>> On 20 May 2021, at 16:12, Fernando Frediani wrote:
>>>
>>>> No puedo creer que sea normal y que existan "un montón" de escenarios
>>>> en los que es normal anunciar recursos de numeración por otro ASN
>>>> diferente al que fueron asignados los recursos y que esto no debe
>>>> levantar sospechas. Parece que estamos cambiando un poco las cosas
>>>> aquí. Si un recurso se asigna a una organización y ASN específicos,
>>>> se espera SI que los anuncios provengan de ese ASN. Para resolver
>>>> muchas de estas situaciones de manera permanente, existen políticas
>>>> de transferencia de recursos.
>>> Si, esos casos existen. Hay multiplicidad de situaciones que llevan a
>>> que una organización pueda querer anunciar recursos por diferentes
>>> Ases. Esto incluye desde el uso de mitigación de DDoS, el no querer
>>> hablar BGP, el uso de infraestructura de cloud con IPs propias, la
>>> sub-asignación de prefijos IP de carriers a clientes y el simple
>>> ejercicio de la autonomía como una organización.
>> Ya he trabajado más directamente en la mitigación de los ataques DDoS y
>> puedo decir que hacer un hijack como una forma de mitigar es innecesario
>> y está mal. Es posible conservar el ASN de origen. Este ha sido incluso
>> un punto cada vez más controvertido en el campo técnico. En cuanto a la
>> autonomía de una organización para el uso de estos recursos hay que
>> recordar que no es tan absoluta.
>> Como dije, hay situaciones justificables, pero no tengo duda de que no
>> son en gran número o que cuando lo son, deben estar debidamente
>> justificadas.
>>> Los recursos **NO** se asignan a “una organización y AS especifico”.
>>> Esto no es ni fue nunca así. Los recursos se asignan a organizaciones
>>> solamente. De hecho no hay obligación de contratar un numero de AS a
>>> la hora de solicitar numeración IP.
>> Hemos hablado de esto antes, pero el punto aquí, como expliqué en el
>> mensaje anterior, es un prefijo asignado a una organización anunciado
>> por un ASN asignado a otra organización. Es fácil sospechar operaciones
>> como arrendamientos o préstamos con prefijos IP y operaciones "por bajo
>> la mesa", ya que parece haber ido en aumento en estos tiempos de
>> escasez. Solo en el último mes recibí 2 propuestas de una empresa para
>> alquilar recursos de LACNIC a terceros !
>> Aunque no es el objetivo de esta discusión desde mi punto de vista es
>> algo muy equivocado y que causa más confusión la non obligación de tener
>> una ASN para toda la organización, principalmente después de los ASNs de
>> 32 bits.
>>> Esta vinculación **tampoco existe a nivel del protocolo BGP ni existe
>>> en RPKI tampoco**. De hecho los WGs del IETF que tratan el tema RPKI y
>>> routing security han hecho siempre énfasis en la libertad y autonomía
>>> de los operadores a la hora de definir sus políticas de enrutamiento.
>> No es porque no haya un vínculo técnico que no pueda existir en las reglas.
>> La autonomía de los operadores no es absoluta con respecto al uso de los
>> recursos de numeración.
>>
>> Les doy un ejemplo claro aquí: en nuestra región, los recursos de
>> numeración asignados por LACNIC deben ser utilizados mayoritariamente
>> dentro de la región (1.14). Esto es independiente de la autonomía,
>> voluntad o políticas de enrutamiento de los operadores y debe hacerse de
>> esta manera.
>>
>> En resumen, si queremos avanzar con esta propuesta para que cumpla su
>> propósito, no podemos simplemente ignorar los efectos que puede causar
>> en la creación o estimulación de situaciones perjudiciales para la
>> gestión de los recursos de numeración.
>>
>> Saludos
>> Fernando
>>
>>
>>> Si tu individualmente, en tu red, quieres asegurarte de que únicamente
>>> vas a aceptar rutas a prefijos que están anunciados por los Ases de
>>> cada organización, puedes con un cierto esfuerzo crear scripts y
>>> prefix-lists que te permitan asegurarte de esto.
>>>
>>> S2
>>>
>>> /Carlos
>>> _______________________________________________
>>> 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