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

[Sergio Rojas. . .]

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