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

Fernando Frediani fhfrediani at gmail.com
Wed Jan 20 13:51:27 -03 2021


Hola Sergio
Gracias por sus comentarios y contribuciones a esta discusión.

Creo que vale la pena intentar aclarar mi posición e inquietudes con 
respecto a esta propuesta y quién sabe, quizás podamos encontrar algo 
que funcione bien y al mismo tiempo sea capaz de mitigar estas 
inquietudes que expresé en mensajes anteriores.
Creo que también que casi nadie se opondrá a tener más firmas de ROA y, 
por lo tanto, más seguridad de enrutamiento. Aquí hacemos el caso 
nuestro homework de firmar todos los ROAS además de sugerir a los 
clientes que tienen sus propios recursos que también lo hacen.

Escenario 1: Para asignaciones de /25 a /31, creo que esta propuesta no 
tiene ningún efecto práctico, que aún requiere que el Proveedor de 
conectividad firme las ROA en un mínimo de / 24.
Escenario 2: para organizaciones que eventualmente puedan recibir un 
bloque /24 o mayor de su proveedor de conectividad pero que aún tengan 
conectividad a través de ese proveedor y justificar esta asignación 
sería el caso más apropiado para aplicar esta propuesta
Escenario 3: Una organización que no tiene ningún vínculo de 
conectividad con otra organización que tiene recursos de numeración 
simplemente "presta" o alquila direcciones IP para anunciar desde su 
propio ASN es donde vive mi preocupación y esta política puede alentar a 
que se haga. Creo que en este caso quedaría más claro que no es el 
escenario anterior y daría soporte a aplicación del punto 7 del manual.

Fernando Frediani

On 20/01/2021 13:00, Sergio Rojas. . . wrote:
> Fernando,
>
> El 20/1/21 a las 12:41, Fernando Frediani escribió:
>> Sérgio, el manual no es algo binario con todas las posibilidades 
>> posibles y también necesita alguma interpretación. No funciona querer 
>> tener un punto exacto que aborde esto sin involucrar el análisis que 
>> conoces bien que involucra varios puntos subjetivos.
>> Por ejemplo, durante el análisis inicial de una ASN, se solicitan una 
>> serie de documentos y comprobantes de uso para aquellas direcciones 
>> que no están especificadas o 'ipsis litris' en el manual de políticas 
>> y sabes bien que son necesarios para poder realizar un análisis con 
>> discreción y garantía que los recursos están realmente justificados.
> SR: Totalmente de acuerdo, y REITERO lo siguiente:
>     *Totalmente de acuerdo con esto, y estoy seguro que LACNIC se 
> encarga de analizar correctamente el cumplimiento de estos requisitos 
> a la hora de aprobar una solicitud de recursos.
>>
>> Si una organización presentó un plan de uso y justificó los recursos 
>> para un propósito (ex: uso propio y de sus clientes de 
>> conectividade), no puede usarlos para otro, especialmente cuando la 
>> organización tiene la capacidad de recibirlos directamente del RIR.
>> ¿Te das cuenta de que muchos de estos casos vergonzosos que vemos de 
>> alquilar direcciones IP, una organización no tiene ningún tipo de 
>> conectividad con la organización que alquila esas direcciones IP?
>
> SR: Si este fuera el caso, LACNIC cuenta con suficientes mecanismos en 
> el punto 7 del Manual de Políticas para poder iniciar un proceso de 
> revocación de recursos por incumplimiento de políticas. También está 
> establecido en el Acuerdo de Servicio que los recursos deben ser 
> utilizados únicamente para su infraestructura interna o para asignar a 
> sus clientes (Artículo 2do).
>
> SR: Si bien es un punto interesante de discusión, no encuentro motivo 
> u objeción técnica fundada para no implementar esta propuesta, que 
> básicamente lo que está proponiendo es que la organización que haya 
> recibido espacio IPv4/IPv6 subasignado del proveedor pueda gestionar 
> sus propias ROAs.
>
> Saludos,
>
> Sergio. . .
>
>
>>
>> Una organización que asigna una gran cantidad de direcciones a otra 
>> que puede acudir directamente a LACNIC para solicitarlas (a través de 
>> una transferencia estos días) ciertamente no justifica mantenerlas 
>> bajo su custodia.
>> Es algo tan, mas tan absurdo que no es posible que podamos 
>> considerarlo como normal y aceptable.
>>
>> Fernando
>>
>> On 20/01/2021 12:28, Sergio Rojas. . . wrote:
>>> Fernando,
>>>
>>> El 20/1/21 a las 11:35, Fernando Frediani escribió:
>>>> Sérgio, Carlos, buenos días.
>>>>
>>>> Creo que lo más importante a entender en este contexto es lo 
>>>> siguiente: cada organización (ASN o no) cuando acude a LACNIC o uno 
>>>> de sus NIRs necesita justificar el uso de las todas direcciones IP 
>>>> que solicita (ya sea para una primera asignación o una 
>>>> transferencia) y (importante) utilícelos de acuerdo con esas 
>>>> justificaciones.
>>>>
>>>> Nunca es demasiado recordar que, dado que no es una propiedad, las 
>>>> direcciones siempre deben continuaren a usarse *para lo que se 
>>>> justificó* o se debe devolver.
>>>
>>>
>>> Totalmente de acuerdo con esto, y estoy seguro que LACNIC se encarga 
>>> de analizar correctamente el cumplimiento de estos requisitos a la 
>>> hora de aprobar una solicitud de recursos.
>>>
>>>>
>>>> Dudo que LACNIC o cualquiera de sus NIR acepten alguna vez como 
>>>> justificación que una organización necesita una cantidad de 
>>>> direcciones bajo su responsabilidad para asignar a varias otras 
>>>> organizaciones que tienen la capacidad de ir directamente a LACNIC 
>>>> o sus NIR para hacer esto directamente. Dado que esta no es una 
>>>> justificación aceptada, no puede tratarse como normal.
>>> ¿nos puedes decir en que parte del Manual de Políticas esta práctica 
>>> no es una justificación aceptada? ¿que pasa si simplemente la 
>>> organización NO desea recibir recursos directamente de LACNIC y en 
>>> lugar de eso recibir recursos solo de su ISP? no veo el motivo por 
>>> el cual deba verse obligado a solicitar unicamente recursos a LACNIC.
>>>>
>>>> Y sí, este asunto tiene que ver con la discusión de esta propuesta 
>>>> porque si la justificación es que esto es posible, estoy 
>>>> argumentando que no puede ser algo aceptable y por lo tanto 
>>>> invalida una de las justificaciones de esta propuesta.
>>>
>>> Si nos dices en qué parte del Manual de Políticas dice esto, te daré 
>>> la razón y no volveré a discutir, pero de momento sigo a favor de 
>>> esta propuesta.
>>>
>>> Sergio. . .
>>>
>>>
>>>>
>>>> Saludos
>>>> Fernando
>>>>
>>>> On 20/01/2021 09:58, Carlos Martinez-Cagnazzo wrote:
>>>>> Hola, buenos días a todos y espero que todos hayan tenido un 
>>>>> excelente
>>>>> comienzo de año.
>>>>>
>>>>> Creo que es conveniente realizar un par de aclaraciones para 
>>>>> clarificar el
>>>>> rol de LACNIC en el uso de direcciones IP y sistemas autónomos.
>>>>>
>>>>> On Sun, Jan 17, 2021 at 6:58 PM Fernando Frediani 
>>>>> <fhfrediani at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hola Hernan
>>>>>>
>>>>>> La función de asignar direcciones a ser anunciadas a Internet
>>>>>> directamente por los Sistemas Autónomos es exclusiva de LACNIC o 
>>>>>> sus NIRs.
>>>>>> 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. En 
>>>>>> resumen: la
>>>>>> función de firmar un ROA sigue siendo responsabilidad del 
>>>>>> destinatario
>>>>>> del bloque por parte de LACNIC.
>>>>>>
>>>>> No, esto no es así. LACNIC y los NIRs operan de manera conjunta un
>>>>> *registro* de direcciones y de sistemas autónomos. Esto quiere 
>>>>> decir que
>>>>> LACNIC y los NIRs *asignan* direcciones y números de sistema 
>>>>> autónomo a
>>>>> diferentes *organizaciones* de la región.
>>>>>
>>>>> De ninguna manera LACNIC considera que las direcciones IP 
>>>>> asignadas a una
>>>>> organización A deba ser anunciada exclusivamente por los sistemas 
>>>>> autónomos
>>>>> asignados a la misma organización A. Quiero ser muy enfático en esto:
>>>>> LACNIC *no asigna direcciones IP a sistemas autónomos*, LACNIC asigna
>>>>> números IP y números de sistema autónomo a *organizaciones*, las 
>>>>> que luego
>>>>> pueden utilizar estos recursos de la manera que consideren más 
>>>>> adecuada
>>>>> para alcanzar sus objetivos de negocio siempre en cumplimiento con 
>>>>> las
>>>>> políticas de LACNIC.
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>> Usar up/down (modo delegado) o hacerlo a través del sistema de 
>>>>> MiLACNIC es
>>>>> un detalle de implementación, no hace al fondo de la cuestión.
>>>>>
>>>>> Saludos,
>>>>>
>>>>> /Carlos
>>>>>
>>>>>
>>>>>> 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
>> _______________________________________________
>> 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