[LACNIC/Politicas] Nueva propuesta LAC-2020-10 / Nova proposta LAC-2020-10 / New proposal LAC-2020-10

Sergio Rojas. . . sergio.astigarraga at gmail.com
Wed Jan 20 09:39:07 -03 2021 

Hola Fernando,

Como dije en mi correo anterior el Manual de Politicas no impide que un 
ISP pueda subasignar a un tercero ni tampoco tiene como requisito que el 
solicitante lo anuncie a través del ASN de un tercero.

En cuanto al escenario que mencionas en el segundo párrafo, si el ISP 
subasignó al tercero y éste lo anuncia por otro ASN, siempre y cuando 
esté conectado a la infraestructura del proveedor que le subasignó NO 
estaría incumpliendo ninguna política,  en caso contrario ahí si estaría 
incumpliendo la política pero eso LACNIC no lo podrá saber hasta después 
de asignarle los recursos. Como dije en el correo anterior, que un ISP 
subasigne a un tercero y que éste lo anuncie por otro ASN no es parte de 
la discusión de esta propuesta de política.

Sigo estando a favor de esta propuesta.

Saludos!

Sergio. . .

El 20/1/21 a las 00:09, Fernando Frediani escribió:
> Hola Sergio
>
> El principal problema es que el ASN que asigna sus bloques a otro ASN 
> para anunciar directamente a la Internet ahora actúa como un RIR/NIR.
> Cada bloque asignado desde un RIR/NIR a un ASN debe estar justificado 
> y ciertamente *no está entre las justificaciones aceptables* decirle 
> al RIR/NIR que necesita recibir más direccionamiento para asignarlo a 
> otros ASNs.
>
> Veo que un ASN en la región LACNIC que tiene una gran cantidad de 
> direcciones IP y las asigna a otros ASNs terceros para anunciaren 
> directamente está demostrando claramente que no necesita todo este 
> direccionamiento para su propio uso o con sus clientes (sin ASN) y por 
> lo tanto podría ser solicitado devolver parte de estos bloques para 
> que el propio RIR/NIR pueda asignarlos directamente a los ASNs que 
> realmente necesitan de manera directa. Si LACNIC permite que una 
> organización mantenga una gran cantidad de direcciones bajo su 
> custodia solo para reasignarlas a otras organizaciones que son 
> Sistemas Autónomos, puede estar creando una laguna crítica para 
> favorecer el mercado especulativo y estaría obligada a aceptar como 
> justificación  para transferencias bloques para seren asignados para 
> uso por un ASN terceros.
>
> Saludos
> Fernando
>
> On 19/01/2021 23:05, Sergio Rojas. . . wrote:
>> Estimados,
>>
>> Mis comentarios debajo.
>>
>> El 17/1/21 a las 18:57, Fernando Frediani escribió:
>>> Hola Hernan
>>> Este es quizás un tema controvertido y quizás aún no se haya 
>>> explorado lo suficiente.
>>>
>>> ¿Por qué un sistema autónomo asignaría algo mayor que /24 a otro 
>>> sistema autónomo?
>>
>> SR: Ya sea por agotamiento, o simplemente por acuerdo contractual que 
>> el ISP tenga con su cliente, no existe un punto en el manual de 
>> políticas que prohíba esa práctica y personalmente NO me parece que 
>> vaya en contra de las buenas prácticas de ruteo.
>>
>>
>>> Si lo hace por la escasez de direcciones en este segundo sistema 
>>> autónomo, tales prefijos en mi opinión, no deberían ser anunciados 
>>> para la Internet permanentemente desde la ASN de este segundo 
>>> sistema autónomo, de lo contrario esto transformaría la primera ASN 
>>> en un RIR/NIR.
>> SR: ¿Y cual es el problema que el primer ASN le asigne un /24 o 
>> prefijo mayor a su cliente y éste decida anunciarlo por el segundo 
>> ASN? Si bien no es el tema de discusión en esta propuesta de 
>> política, reitero que no veo inconvenientes con esta práctica.
>>> En este caso, el prefijo asignado al segundo ASN se enruta 
>>> exclusivamente a través del backbone del primer AS, que debe 
>>> anunciarlo a Internet.
>>>
>>> La función de asignar direcciones a ser anunciadas a Internet 
>>> directamente por los Sistemas Autónomos es exclusiva de LACNIC o sus 
>>> NIRs.
>>
>> SR: El manual de políticas NO menciona que esta función es exclusiva 
>> de LACNIC, creo que estás malinterpretando algún punto en el manual. 
>> Si puedes compartir en qué parte del manual de políticas dice esto 
>> sería un buen insumo para el análisis de impacto.
>>
>>
>>> Existen situaciones muy excepcionales en las que un ASN puede 
>>> anunciar prefijos de otro, pero no verlos de forma permanente y si 
>>> es permanente que el Sistema Autónomo se esté convirtiendo en un RIR.
>>
>> SR: por lo explicado en el punto anterior este comentario también 
>> sería inválido pues en ningún punto del Manual de Políticas indica 
>> que los ISPs no puedan subasignar rangos anunciables en la Internet a 
>> través de ASNs de terceros. Es mas, el manual dice que SI lo puede 
>> hacer (Ventana de asignación) y lo puede subasignar hasta 15 /24s 
>> inclusive.
>>
>>
>>> En resumen: la función de firmar un ROA sigue siendo responsabilidad 
>>> del destinatario del bloque por parte de LACNIC.
>>
>> SR: No veo el porque una organización que haya recibido una 
>> subasignación de un ISP no pueda crear ROAS. Si el ISP que subasignó 
>> un bloque a su cliente y registra esta subasignación en el whois, le 
>> estará otorgando los privilegios administrativos al tercero, lo cual 
>> implica además de poder configurar los rDNS, la creación de ROAs sin 
>> que esté dependiendo 100% de su ISP.
>>
>>
>>>
>>> Finalmente, incluso si hay alguna inconsistencia en lo que dije 
>>> anteriormente, dejo una pregunta aquí: ¿no funcionaría para el 
>>> servidor con el software que firma los ROA (por ejemplo: Krill) para 
>>> delegar esto en otro servidor Krill de otra organización?
>>
>> SR: escapa de mis conocimientos y no podría opinar al respecto.
>>
>>
>> SR: En conclusión, estoy a 100% favor de esta propuesta.
>>
>> Saludos,
>>
>> Sergio. . .
>>
>>
>>>
>>> Fernando
>>>
>>> On 01/12/2020 18:59, Hernan Moguilevsky wrote:
>>>> Estimado,
>>>>
>>>> Gracias por los comentarios.
>>>>
>>>> Respondo entre líneas.
>>>>
>>>> Saludos.
>>>> HM
>>>>
>>>>
>>>> El lun, 30 de nov. de 2020 a la(s) 00:57, Fernando Frediani (
>>>> fhfrediani at gmail.com) escribió:
>>>>
>>>>> Creo que la intención del autor es buena, en el sentido de 
>>>>> incrementar
>>>>> el alcance del RPKI, sin embargo no veo el efecto práctico de esta
>>>>> medida, tampoco desde el punto de vista técnico.
>>>>>
>>>> La propuesta surgió de los problemas operacionales que implica 
>>>> solicitar al
>>>> ISP la firma de los ROA de bloques delegados.
>>>> La fundamentación de la propuesta no son sólo las buenas 
>>>> intenciones para
>>>> el despliegue de RPKI, sino un problema real.
>>>>
>>>>> La firma de ROA consiste básicamente en decir qué ASN pueden 
>>>>> anunciar un
>>>>> prefijo en particular y también el tamaño de este prefijo.
>>>>> - Si el prefijo es delegado desde el ISP, solo ese Sistema Autónomo
>>>>> tiene la facultad de autorizar a otro Sistema Autónomo a anunciar sus
>>>>> prefijos, incluso cuando se delegue temporalmente en un cliente (que
>>>>> normalmente no es un sistema autónomo)
>>>>>
>>>> Existe un universo de receptores de bloques que cuenta con Sistema 
>>>> Autónomo
>>>> y por diversos motivos deben anunciar esos prefijos a múltiples
>>>> proveedores. Esos son los alcanzados en esta propuesta.
>>>>
>>>>
>>>> - En la mayoría de los casos los prefijos delegados por un ISP (y
>>>>> especialmente en épocas más recientes de escasez) son siempre 
>>>>> mucho más
>>>>> pequeños que /24 (normalmente /27 a /30) y por lo tanto no es posible
>>>>> que ningún otro ASN pueda anunciar estos prefijos para la Internet
>>>>> además del proprio titular de la asignación RIR/NIR.
>>>>>
>>>> Desconozco la estadística planteada.
>>>> La propuesta beneficia a los que cuenten con prefijos mayores a 
>>>> /24, que
>>>> pueden ser anunciados a Internet. En el caso de los menores (/25 le 
>>>> /30)
>>>> no veo que cause ningún problema operativo.
>>>> Como dijiste anteriormente, con la escasez de direcciones IPv4, 
>>>> creo que
>>>> justamente serán las grandes organizaciones, con muchos bloques las 
>>>> que
>>>> deleguen a sus clientes. Estas son las más difíciles de abordar.
>>>>
>>>>
>>>>
>>>>> Por eso creo que la única organización capaz de firmar ROA por un
>>>>> prefijo es el propio titular de esa asignación y esta solicitud debe
>>>>> provenir de los propios clientes que reciben estas 
>>>>> asignaciones,incluso
>>>>> esto puede ser un punto de evaluación por parte de quienes 
>>>>> contratan los
>>>>> servicios de ese ISP. .
>>>>>
>>>> No comprendo cuál puede ser el punto de evaluación.
>>>> Una vez que contamos con recursos asignados, podemos tomar decisiones.
>>>> Mientras tanto, los prefijos delegados sólo pueden ser firmados por el
>>>> contacto administrativo ante LACNIC de la organización titular de los
>>>> recursos.
>>>> Esto se vuelve engorroso y muchas veces imposible de lograr.
>>>>
>>>> Esta propuesta busca darle agilidad a la creación de los ROA. En
>>>> definitiva, si se ha delegado el recurso, por qué no delegar 
>>>> también la
>>>> facultad de la firma del ROA? Por qué mantenerlo separado?
>>>>
>>>>> Entonces, aunque reconozco la buena intención del autor, no estoy a
>>>>> favor de ella.
>>>>>
>>>>> Saludos cordiales
>>>>> Fernando Frediani
>>>>>
>>>>> On 23/11/2020 13:00,info-politicas at lacnic.net wrote:
>>>>>> [Português abaixo]
>>>>>> [English below]
>>>>>>
>>>>>> Estimados suscriptores de la Lista de Políticas de LACNIC,
>>>>>>
>>>>>> Se recibió una nueva propuesta de Política, se le asignó el id
>>>>> LAC-2020-10.
>>>>>> Título: Facultar a receptores de bloques delegados para firmar ROA.
>>>>>>
>>>>>> Resumen: Una vez implementada la política, el contacto técnico de la
>>>>> Organización receptora de un bloque IP delegado por un proveedor 
>>>>> será capaz
>>>>> de firmar los ROA para dicho prefijo mientras dure la delegación.
>>>>>> Para ver el detalle ingrese en:
>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-10/language/sp 
>>>>>>
>>>>>>
>>>>>> Los comentarios y los puntos de vista aportados por la comunidad son
>>>>> vitales para el correcto desarrollo del proceso de la propuestas
>>>>>> - ¿Apoya usted o se opone a esta propuesta?
>>>>>> - ¿Esta propuesta resolvería un problema que usted está 
>>>>>> experimentando?-
>>>>> ¿Ve alguna desventaja en esta propuesta?
>>>>>> - ¿Qué cambios podrían hacerse a esta propuesta para que sea más 
>>>>>> eficaz?
>>>>>>
>>>>>> Por más información contacte ainfo-politicas at lacnic.net
>>>>>> Saludos cordiales,
>>>>>>
>>>>>>
>>>>> ______________________________________________________________________________________________________ 
>>>>>
>>>>>> Prezados assinantes da lista de políticas de LACNIC,
>>>>>>
>>>>>> Foi recebida uma nova proposta de Política, foi atribuído o id
>>>>> LAC-2020-10.
>>>>>> Título: Facultar a receptores de bloques delegados para firmar ROA.
>>>>>>
>>>>>> Resumo: Una vez implementada la política, el contacto técnico de la
>>>>> Organización receptora de un bloque IP delegado por un proveedor 
>>>>> será capaz
>>>>> de firmar los ROA para dicho prefijo mientras dure la delegación.
>>>>>> Para ver o detalhe acesse:
>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-10/language/pt 
>>>>>>
>>>>>>
>>>>>>    Os comentários e os pontos de vista aportados pela comunidade são
>>>>> vitais para o bom desenvolvimento do processo das propostas
>>>>>> - ¿Você é a favor ou contra desta proposta?
>>>>>> - ¿Esta proposta iria resolver um problema que você está
>>>>> experimentando?- ¿Vê alguma alguma desvantagem nesta proposta?
>>>>>> - ¿Que mudanças poderiam ser feitas à proposta para que seja mais 
>>>>>> eficaz?
>>>>>>
>>>>>>    Por mais informações entre em contato conosco através do seguinte
>>>>> e-mail:info-politicas at lacnic.net
>>>>>> Atenciosamente,
>>>>>>
>>>>> ______________________________________________________________________________________________________ 
>>>>>
>>>>>> Dear LACNIC Policy List subscribers,
>>>>>>
>>>>>> A new Policy Proposal has been received and assigned the 
>>>>>> following ID:
>>>>> LAC-2020-10.
>>>>>> Title: Facultar a receptores de bloques delegados para firmar ROA.
>>>>>>
>>>>>> Summary: Una vez implementada la política, el contacto técnico de la
>>>>> Organización receptora de un bloque IP delegado por un proveedor 
>>>>> será capaz
>>>>> de firmar los ROA para dicho prefijo mientras dure la delegación.
>>>>>> To read the proposal, please go to
>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-10/language/en 
>>>>>>
>>>>>>
>>>>>> The community's comments and opinions are essential to the proper
>>>>> functioning of the policy development process.
>>>>>> - Do you support this policy or are you against it?
>>>>>> - Would this proposal solve a problem you are experiencing?- Do you
>>>>> think this proposal has any drawbacks?
>>>>>> - What changes could be made to this proposal to make it more 
>>>>>> effective?
>>>>>>
>>>>>> For further information, please contactinfo-politicas at lacnic.net
>>>>>> Kind regards,
>>>>>> -- 
>>>>>> LACNIC - Registro de Direcciones de Internet para América Latina 
>>>>>> y Caribe
>>>>>> Rambla Rep. de México 6125, CP 11400
>>>>>>
>>>>>> Montevideo-Uruguay
>>>>>>
>>>>>> Teléfono: +598 2604 22 22
>>>>>> www.lacnic.net
>>>>>> _______________________________________________
>>>>>> 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