[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 18:46:07 -03 2021


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


More information about the Politicas mailing list