[lacnog] Validación de prefijo

[Hernan Moguilevsky]

Estimados,

Tomando en cuenta este hilo, he presentado una propuesta en el proceso de
políticas de LACNIC para resolver el problema.

https://mail.lacnic.net/pipermail/politicas/2020-November/005967.html


Saludos.


El El vie, 30 oct. 2020 a la(s) 19:17, Ramon Flores <rfmairena en gmail.com>
escribió:

> Roque, es buena su consulta, me gustaría tener control del ROA de los IP
> que me asignó el proveedor. Así no hubiese tenido el inconvenientes, que
> por cierto ya se resolvió.
>
> Saludos.
>
> El vie., 30 oct. 2020 a las 10:00, Roque Gagliano (<rgaglian en gmail.com>)
> escribió:
>
>> Hola Alejandro,
>>
>> En realidad el problema de Ramón se puede solucionar desde los sistemas
>> de LACNIC.
>>
>> El caso es de un SP (el proveedor) que ha delegado un bloque de
>> direcciones para otro cliente. En el modelo teórico de RPKI, el proveedor
>> debería adoptar el modelo "delegado" de RPKI, administrar un CA y darle a
>> Ramón la opción de administrar sus certificados y ROAs (sea de forma hosted
>> o delegada).
>>
>> Lo que no sé (pues hace tiempo que no uso el sistema) es si el sistema
>> "hosted" de LACNIC le permitiría a Ramón de administrar sus
>> certificados/ROAs siempre que el proveedor delegue los prefijos (agregando
>> una CA en el sistema).
>>
>> Saludos,
>> Roque
>>
>>
>>
>>
>> On Thu, Oct 29, 2020 at 5:52 PM Alejandro Acosta <
>> alejandroacostaalamo en gmail.com> wrote:
>>
>>> teoría vs vida real :-)
>>> On 10/29/20 12:01 PM, Nicolas Antoniello wrote:
>>>
>>> Estimad en s,
>>>
>>> De acuerdo con el comentario de Tomas.
>>> Yo pienso que es algo muy normal el tener que dividir prefijos por
>>> varias razones operativas. Desde balancear tráfico (combinado con
>>> comunidades de BGP como no tránsito, etc...), temas puntuales de seguridad
>>> de ruteo (como cuando se produce un secuestro de rutas), etc.
>>>
>>> Es decir, creo que son cosas diferentes y por ello existen ambas
>>> posibilidades de configuración en el sistema de RPKI (configurar cada
>>> prefijo y al mismo tiempo preever el grado máximo de des agregación que
>>> vamos a permitir).
>>>
>>> Tal vez alguien me va tirar con algo por la cabeza por esta
>>> recomendación, pero creo que para alguien que recién comienza con RPKI o
>>> que no sabe a priori cuanto o cuando va a desagregar, puede ser
>>> recomendable setear el máximo en /24 para un prefijo IPv4 (y lo análogo
>>> para IPv6) 😊
>>>
>>> Fraterno saludo,
>>> Nico
>>>
>>>
>>>
>>> El El jue, oct. 29, 2020 a la(s) 12:45, Tomas Lynch <
>>> tomas.lynch en gmail.com> escribió:
>>>
>>>> Como toda BCP se va a chocar con el día a día de la operación donde
>>>> muchas empresas agregan y desagregan prefijos por distintos motivos en
>>>> distintos tiempos (e.g. empresas que balancean tráfico por /24, que no digo
>>>> que esté bien, pero es la realidad)
>>>>
>>>> On Thu, Oct 29, 2020 at 10:06 AM Marcos Manoni <marcosmanoni en gmail.com>
>>>> wrote:
>>>>
>>>>> Hola,
>>>>>
>>>>> El mié., 28 oct. 2020 a las 13:39, Tomas Lynch
>>>>> (<tomas.lynch en gmail.com>) escribió:
>>>>> > El mayor error cuando crean los ROAs es no poner bien el max len.
>>>>> Esto lo estuvimos analizando en el último LACNOG.
>>>>> >
>>>>> > Simplificando, hay tres campos para llenar: sistema autónomo, el
>>>>> prefijo y la máxima longitud permitida. Mucha gente confunde la máxima
>>>>> longitud con el tamaño del prefijo y terminan poniendo lo mismo.
>>>>>
>>>>> Ese comportamiento, más que error, está camino a ser una "best
>>>>> practice". Lo que tiene que coincidir es el ROA con los anuncios BGP.
>>>>> O sea, conviene hacer varios ROAs (1 por prefijo anunciado) en lugar
>>>>> de pocos con máscara grande.
>>>>>
>>>>> The Use of Maxlength in the RPKI
>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/
>>>>> [...]whenever possible, operators SHOULD use "minimal ROAs" that
>>>>> include only those IP prefixes that are actually originated in BGP,
>>>>> and no other prefixes.
>>>>>
>>>>> Saludos,
>>>>> Marcos
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> LACNOG en lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>
>>>
>>> _______________________________________________
>>> LACNOG mailing listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>
>>
>> --
>>
>>
>> At least I did something
>> Don Draper - Mad Men
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
-- 
HM
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20201125/c6e94eaa/attachment.htm>