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

Sun May 23 11:01:28 -03 2021

Ya entendí tu intención, pero dejé muy claro los problemas que la 
'solución' de este problema tiene el potencial de causar y sugerí 
algunas formas de tener más control sobre este proceso, pero parece que 
crees que quienes reciben recursos de numeración no deben ser 
perturbados.Cuando cualquier autor de una propuesta introduce algo nuevo 
en el sistema, es necesario evaluar todos los efectos y tratar de 
abordarlos todos a la vez. Uno no puede pensar en resolver un lado de 
forma aislada y no preocuparse por los possibles efectos.

Si no desea realizar ningún tipo de cambio o ajuste en la propuesta, 
entonces creo que continúan con los mismos varios problemas ya 
resaltados y no es positivo proceder de esta manera.
Fernando

On 21/05/2021 08:19, Sergio Rojas. . . wrote:
> Hola Fernando,
>
> Por lo que pude percibir en todos los correos que enviaste, tu 
> preocupación principal es el uso inadecuado de los recursos, llámese 
> arrendamiento, préstamo, otros. Como verás, la sección que estoy 
> intentando modificar se llama *"Inclusión del ASN originador en el 
> WHOIS cuando estuviera disponible" *, expuse claramente el problema en 
> detalle, y *REITERO* que el espíritu de esta propuesta y del autor es 
> corregir la inconsistencia de los datos mostrados en el whois y NO la 
> de indagar e investigar porqué una organización cambió su política de 
> ruteo. Si tanto te preocupa esta situación te invitamos a que envíes 
> una nueva propuesta de política que cree una nueva sección en el 
> manual de políticas o que modifique alguna otra sección que no sea la 
> *"2.3.2.19. Inclusión del ASN originador en el WHOIS cuando estuviera 
> disponible"*
>
> Saludos,
>
> Sergio. . .
>
>
> El 20/5/21 a las 23:19, Fernando Frediani escribió:
>> 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
>>>>
>> _______________________________________________
>> 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