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

Wed Jan 20 00:09:44 -03 2021

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