[lacnog] Sobre BGP y anuncios (era Re: IPv6 still 5–10 years away from mainstream use)
Fernando Frediani
fhfrediani en gmail.com
Vie Jul 23 17:18:28 -03 2021
Hola Carlos
No estoy proponiendo una solución única, pero estoy exponiendo un
problema que es real y no podemos simplemente ignorarlo porque
simplemente es bueno seguir haciéndolo desde un punto de vista técnico.
Como mencioné en mi correo anterior, existen alternativas y opciones
técnicas y no necesariamente algo *necesita* hacerse siempre de una
manera única. El área técnica también necesita adaptarse a las políticas
y reglas vigentes y a medida que vayan cambiando, es compromiso de la
organización seguir adaptándose, por lo que aunque eventualmente a
algunos en la industria no les guste, no tendrán más opción que cumplir
con algo que es justificable. .
Una vez más, cito que, por muy cómodo que sea hacer algo de alguna
manera, no podemos ignorar las posibilidades de fraude que pueden surgir
a medida que cambia el contexto y el problema que mencioné sigue siendo
real y de alguna manera debe abordarse. Esto no significa también
combatir usos que sigan cumpliendo con las justificaciones dadas a los
RIR o que es diferente.
Saludos
Fernando
On 23/07/2021 17:06, Carlos M. Martinez wrote:
>
> Fernando,
>
> Simplemente voy a decir que sigo creyendo que esa restricción que tu
> propones es profundo error. Muy profundo.
>
> Por mi parte creo que no tengo mas para decir. Solamente compartir un
> ejemplo del tipo de usos 100% legítimos que esa restricción que tu
> propones “invalidaría” (pongo comillas porque por mas que esa
> restricción se aprobara, nadie en la industria la aplicaría).
>
> Este es un caso al azar que me llevó mas o menos 30 segundos encontrar.
>
> |❯ whois -h whois.lacnic.net 2.19.251.0 % This is the RIPE Database
> query service. % The objects are in RPSL format. % % The RIPE Database
> is subject to Terms and Conditions. % See
> http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this
> output has been filtered. % To receive output for a database update,
> use the "-B" flag. % Information related to '2.19.240.0 -
> 2.19.255.255' % Abuse contact for '2.19.240.0 - 2.19.255.255' is
> 'abuse en akamai.com' inetnum: 2.19.240.0 - 2.19.255.255 netname:
> AKAMAI-PA descr: Akamai Technologies country: DE admin-c: NARA1-RIPE
> tech-c: NARA1-RIPE status: ASSIGNED PA mnt-by: AKAM1-RIPE-MNT
> mnt-routes: DTAG-RR created: 2010-12-11T20:49:44Z last-modified:
> 2011-01-12T11:44:11Z source: RIPE role: Network Architecture Role
> Account address: Akamai Technologies address: 8 Cambridge Center
> address: Cambridge, MA 02142 phone: +1-617-938-3130 abuse-mailbox:
> abuse en akamai.com admin-c: NF1714-RIPE admin-c: CKAK-RIPE tech-c:
> NF1714-RIPE tech-c: JP1944-RIPE tech-c: APB15-RIPE tech-c: CKAK-RIPE
> tech-c: TBAK-RIPE tech-c: NB782-RIPE tech-c: RM4844-RIPE tech-c:
> AKAY-RIPE nic-hdl: NARA1-RIPE mnt-by: AKAM1-RIPE-MNT created:
> 2002-03-06T09:02:17Z last-modified: 2019-04-15T17:17:53Z source: RIPE
> # Filtered % Information related to '2.19.251.0/24AS6057' route:
> 2.19.251.0/24 descr: Akamai Technologies origin: AS6057 mnt-by:
> AKAM1-RIPE-MNT created: 2020-02-05T21:56:13Z last-modified:
> 2020-02-05T21:56:13Z source: RIPE % This query was served by the RIPE
> Database Query Service version 1.101 (BLAARKOP) |
>
> S2
>
> Carlos
>
> On 23 Jul 2021, at 14:13, Fernando Frediani wrote:
>
> Olá Carlos, entendo bem o que quer dizer e faço alguns comentários
> à respeito de alguns pontos da sua mensagem:
>
> - Cloud Providers usando modalidades de BYOP não necessariamente
> precisam anunciar esses endereços com seus próprios ASN. É
> possível preservar o ASN de origem sem quaisquer problemas desde
> que o produto seja feito prevendo isso que é algo bastante normal
> Sobre associados que não querem gerir seus próprio BGP ainda sim
> caso deleguem isso para um terceiro nada impede de preservar o ASN
> de origem da organização detentora como padrão.
> Sobre mitigação DDoS, mesmo olhando para os aspectos técnicos
> anunciar os endereços com o ASN da empresa de mitigação é algo bem
> controverso e desde meu ponto de vista técnico desnecessário.
> Também é possível preservar o ASN e ainda sim conseguir atrair o
> tráfego do ataque para si para realizar a mitigação.
>
> O que disse sobre a possibilidade de uma possível restrição é
> apenas o preço a se pagar para ter algum tipo de garantia que os
> endereços IP continuarão a serem utilizados conforme a
> justificativa que foi dada para os RIRs. Há de existir um
> equilíbrio entre o que você diz e a garantia da comunidade de
> saber que os endereços IPs entregues continuam sendo justificados.
> Mesmo que o período do soft-landing (que concordo contigo ter sido
> algo muito responsável da comunidade) e que as listas de espera
> sejam algo cada vez mais distante para novos entrantes serem
> contemplados não podemos nos esquecer que os atuais endereços já
> distribuídos devem continuar com suas justificativas válidas por
> muito tempo e se existem mecanismos que permitem burlar isso
> alguma ação é necessária para contra-balancear isso.
>
> Obrigado pelo seu aporte à discussão.
> Abraços
> Fernando
>
> On 23/07/2021 13:41, Carlos M. Martinez wrote:
>>
>> Hola
>>
>> On 23 Jul 2021, at 13:01, Fernando Frediani wrote:
>>
>> Hola Carlos
>> Somos conscientes de que esto no es un requisito hoy en día,
>> pero ¿por qué no podría serlo? No por razones técnicas, ya
>> que este requisito no existe realmente para BGP, pero ¿por
>> qué no podría serlo desde el punto de vista de las políticas?
>>
>> Porque es un profundo error. Pondría a los registros en un curso
>> de colisión con la industria que no terminaría bien de ninguna
>> forma, ya que volvería incompatibles con las políticas una serie
>> de negocios completamente legítimos:
>>
>> * mitigación de DDoS
>> * ciertas modalidades de CDN
>> * sub-asignacion de IPs por parte de carriers que también usan BGP
>> * cloud providers usando las modalidades de “BYOP” (bring your
>> own IP)
>> * asociados que no quieren gestionar su propio BGP y prefieren
>> delegarlo en su carrier
>>
>> La única implicación es preservar el AS-Path y esto realmente
>> no es un problema técnico y termina dando una mayor garantía
>> de que esas direcciones IP realmente se utilizarán para los
>> fines para los que se justificaron. Pero para eso es
>> imperativo que toda organización que tenga asignadas
>> direcciones IP también tenga un ASN, que con ASN de 32 bits
>> no supone ningún problema.
>>
>> El problema no es la abundancia de numeros de ASN, el problema es
>> el que describo más arriba. Esa garantía adicional (relativa a mi
>> juicio, cuestionable en valor) vendría al costo de lo que
>> describo mas arriba. En mi opinión, es un costo completamente
>> inaceptable.
>>
>> Si en el pasado este requisito no era necesario, pero con el
>> agotamiento de IPv4 y los crecientes intentos de arrendar o
>> prestadas de direcciones IP de una organización a otra (lo
>> que puede violar la justificación inicialmente dada para el
>> RIR), ahora existe motivación para que esto se ajuste. Y que
>> no imponga pérdidas técnicas, solo mayor control para evitar
>> la posibilidad de mal uso de este bien escaso.
>> No todo lo que es técnicamente posible debe hacerse
>> necesariamente.
>>
>> No tiene nada que ver con el agotamiento de IPv4. Esta
>> restricción de ASN-prefijo no va ayudar en nada al agotamiento de
>> IPv4. IPv4 ya se agotó, es historia pasada. Las únicas formas hoy
>> de obtener IPv4 son via transferencias o esperando el tiempo que
>> haya que esperar en las listas de espera de los diferentes RIRs.
>>
>> Las empresas solas se van a ir dando cuenta de esto, a medida que
>> les vaya tocando. No a todas les va a pasar a la vez, y algunas
>> lo van a sufrir más que otras. La comunidad actuó
>> responsablemente en su momento creando políticas de soft landing
>> que hicieron de este agotamiento una experiencia menos
>> traumática, pero ese tiempo ya también pasó.
>>
>> Es hora de dejar partir al IPv4, y sobre todo, es hora de dejar
>> de tratar de arreglar IPv4 destruyendo las cosas que hacen que
>> Internet sea lo que es hoy.
>>
>> Saludos
>>
>> /Carlos
>>
>> Saludos
>> Fernando
>> On 23/07/2021 12:42, Carlos M. Martinez wrote:
>>
>> Hola
>> Hay que des-asociar las funciones de registro que cumplen
>> los RIRs y NIRs de lo que son los protocolos en sí.
>> Debemos ser claros con eso.
>> Para usar BGP hay que usar un sistema autónomo. Ese
>> sistema autónomo, ¿debe ser el propio, asignado a la
>> misma organización que tiene la titularidad de las IPs?
>> Definitivamente *NO*.
>> Hay muchos escenarios en los que la misma organización
>> puede anunciar parte de sus IPs desde un AS propio, otra
>> parte desde otro sistema autónomo, delegarle IPs a un
>> cliente que tiene otro sistema autónomo.
>> Siempre que leo estos hilos veo una tendencia a ir hacia
>> “cada organización que tiene asignadas IPs debe usar
>> *únicamente* su propio sistema autónomo para sus anuncios”.
>> Esta afirmación no solo es un error desde el punto de
>> vista técnico (es requisito no existe en BGP, BGP no sabe
>> lo que es un RIR/NIR/LIR), pero sobre todo, *desconoce la
>> realidad de la industria y de la prestación de servicios
>> de conectividad*.
>> Saludos,
>> /Carlos
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> <https://mail.lacnic.net/mailman/listinfo/lacnog>
>> Cancelar suscripcion:
>> https://mail.lacnic.net/mailman/options/lacnog
>> <https://mail.lacnic.net/mailman/options/lacnog>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> <https://mail.lacnic.net/mailman/listinfo/lacnog>
>> Cancelar suscripcion:
>> https://mail.lacnic.net/mailman/options/lacnog
>> <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 list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> <https://mail.lacnic.net/mailman/listinfo/lacnog>
> Cancelar suscripcion:
> https://mail.lacnic.net/mailman/options/lacnog
> <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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20210723/278c1274/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG