[lacnog] Resumen de LACNOG, Vol 170, Envío 12

Mike Burns mike en iptrading.com
Vie Feb 4 18:40:28 -03 2022


Yes, thank you Emilio for your thoughtful response.

 

On the issue of ROA creation, I am not sure if I support the ability for assignees to generate ROAs but I may not understand fully. I thought it would be important for the RIR to have a direct legal contract with the issuer of the ROA.

 

In ARIN the reason why legacy blocks without an LRSA can’t offer RPKI is because the ARIN legal staff see that as a risk, offering the ability to sign routes to an entity without a contract. ARIN is the trust authority and requires trust in those who can do ROAs, and that trust only comes from a legal contract.

 

It would certainly be easier for the assignee to do the ROA and not rely on the block registrant.

We do want RPKI to grow, but I am unclear on the risks. Maybe the assignees do have a legal contract?

 

I will stop writing now because I’ve introduced too many English messages and they could distract.

Thanks for those who made the effort to be bilingual and were able to read and reply to these.

 

Regards,
Mike

 

 

 

From: LACNOG <lacnog-bounces en lacnic.net> On Behalf Of Hernan Moguilevsky
Sent: Friday, February 04, 2022 4:21 PM
To: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Subject: Re: [lacnog] Resumen de LACNOG, Vol 170, Envío 12

 

Excelente explicación Emilio.

 

En cuanto a lo que comentas de la organización que delega direcciones y genera los ROA, en algunas ocasiones no es tan expeditivo ni sencillo. Por esto es la propuesta de política que mencionó Carlos en el hilo.

La idea es que la organización receptora pueda gestionar los ROA una vez que obtiene la delegación. 

 

Saludos

HM

 

El El vie, 4 feb. 2022 a la(s) 17:49, Emilio Piovesan vía LACNOG <lacnog en lacnic.net <mailto:lacnog en lacnic.net> > escribió:

Hola Javier, hola todos.

 

Sobre esto que comentas en tu mensaje, permíteme compartirte lo que veo comúnmente en el día a día. Aquí se ha hablado mucho de "lo que debería ser" (políticas de LACNIC), de "cómo quisiera que sea" (el punto de vista de brokers), y yo te hablo desde "lo que es" (prácticas comunes, de facto) desde mi punto de vista como asesor técnico, ingeniero de redes, programador de routers y dueño de un ISP pequeño; en donde me toca gestionar el tema de direccionamiento IP y buscar soluciones.

 

Imaginemos que un proveedor carrier/mayorista de acceso a internet, tuvo posibilidad de obtener varios /16 hace unos 15 años atrás cuando no había mayores dificultades para conseguir. Este proveedor mayorista proporciona conectividad a dos ISP, uno mediano y un ISP nuevo que recién está comenzando a operar. Ten en cuenta que es común ver a viejos proveedores de internet con decenas de miles de direcciones IPv4 y aún asignan una IPv4 por servicio, y que estos ofrecen también tránsito a ISP pequeños y medianos, como los dos que pongo en el ejemplo.

 

El primer ISP solicitó a LACNIC un /22 de IPv4, un /32 de IPv6 y un ASN hace apenas dos años y no puede pedir más por la escasez y políticas, pero tiene 10.000 clientes comprimidos en un cg-nat con ese /22. Por otro lado supongamos que el ISP que recién arrancó operaciones no tiene ningún prefijo IPv4 y que LACNIC solamente le ha podido proveer IPv6 y ASN.

 

En cualquiera de los dos escenarios, el ISP que arrancó hace un par de años y ha crecido rápidamente, o el ISP que recién arrancó, un prefijo IPv4 /24 les vendría de maravilla para alivianar el CGNAT, para asignar a clientes empresariales que piden IP estática, servidores, etc...

 

En este caso, el mayorista/carrier/upstream con quien hace peering BGP le ofrece sub-asignar de sus abundantes /16s un /24 y le da posibilidad de ofrecer más si es que lo requieren a futuro. Le propone dos opciones: o incrementar la capacidad de ancho de banda en GBPs contratado (por tanto incrementando facturación), o le da un precio por GBPs más caro; en todo caso, camufla el precio del alquiler dentro del precio de la venta de capacidad y acceso a internet. Este escenario podría replicarse de manera análoga para un proveedor de hosting en un datacenter. Es muy común que a más MBPs/GBPs, más direcciones IP gratis.

 

El mayorista/carrier/upstream entonces hace dos cosas: 

1) sub-asigna de su prefijo /16 un /24 mediante el registro de LACNIC.

2) Crea RoA y registros IRR en favor del ASN del cliente. 

3) Permite en sus filtros BGP anunciar el prefijo asignado.

 

Ahora, imaginemos que estos dos ISP beneficiarios de direccionamiento reasignado, por temas de mejora técnica y redundancia, deciden contratar otro carrier mayorista simultáneamente y anunciar los prefijos por BGP hacia ellos también; en otras palabras, se vuelven multi-homed con su proveedor inicial X y su nuevo proveedor "Y". A pesar de anunciar una subasignación de un prefijo por el proveedor "X", no existe ningún impedimento técnico para anunciar con la competencia "Y". El anuncio se haría con el mismo ASN origen, que "X" ya autorizó al emitir RoA con el ASN del ISP.

 

Tenemos entonces dos ISP felices con su /24 listo para desplegar su red y alivianar la demanda inmediata. El carrier obtiene un beneficio económico indirecto de un recurso que ya tenía. Todos felices. Este es el escenario que entendí de tu mensaje y creo que es bastante válido, común y relevante que lo hayas consultado, y yo lo veo cada vez más frecuentemente en la región.

 

Conclusiones y comentarios:

*	El alquiler de prefijos IPv4 es un hecho en la región de LAC y lo veo desde hace más de una década; no a manera de "broker" y mercado de compra/venta pero sí como un servicio complementario de los carriers para satisfacer las necesidades de sus clientes. Es condición necesaria contratar tránsito con este carrier, en mis años de experiencia nunca he visto que se pueda alquilar sin haber contratado tránsito y enrutarlo por esa vía. Últimamente Cogent ofrece el alquiler por sí solo, pero son recursos de ARIN por tener matriz en EEUU.
*	Los carriers cuidan sus direcciones IPv4 como oro en polvo y a veces se asocian con ISP antiguos moribundos para absorber sus prefijos IPv4. 
*	No es negocio para los carriers alquilar IPs. Cuando les pides muchas IPv4 (más de 2 /24s, por ejemplo), te dicen que vayas a conseguir por otro lado (menos Cogent que tiene exceso y tiene explícitamente el negocio de alquiler). 
*	Si anuncias un prefijo /24 sub-asignado por un carrier y el carrier anuncia el prefijo "padre" completo /16 o el que fuese, a veces suelen darse bucles en la red por mala configuración de BGP en los peers involucrados. Puede que el /24 no entre en negociación con algún IXP, o cosas por el estilo que me han tocado resolver. El carrier, con el fin de evitar "solapamiento" no va a dejar de anunciar el /16 y pasar a anunciar 256 /24s dejando de anunciar los cedidos porque haría más torpe la tabla global de enrutamiento. Lo ideal es trabajar abriendo tickets y solucionar con reglas que eviten este comportamiento indeseado. La jerarquía del prefijo más específico debe prevalecer, pero a veces en los backbones internos regionales no se aprende el BGP global. Ojo con esto.
*	Últimamente Lumen LATAM ha dado un respiro en su escasez pues ha decidido usar recursos de ARIN. En lugar de manejar con cuentagotas los pocos recursos de IP que le quedaban de sus antiguos prefijos de Impsat y Globalcrossing, ahora desempolvaron unos antiquísimos 8.X.X.X, 204.X.X.X y 67.X.X.X que están usando en la región de LAC a pesar de ser de ARIN. Técnicamente no impacta en nada, pues los RIR son solo como un directorio telefónico, al protocolo BGP "le da igual". Los nuevos clientes de Lumen tienen entonces direcciones exóticas de ARÍN gracias a la cantidad exhorbitante de stock que ellos tienen tras décadas de fusiones y absorciones.
*	Quienes suelen alquilar más, son pequeños ISP o proveedores de hosting jóvenes que entraron al mercado recientemente, en plena escasez de IPv4. Ellos están desesperados porque ya llegan a un punto que les ponen en lista negra las pocas direcciones que tienen, o sitios creen que es tráfico de bot. IPv6 ayuda pero de momento no soluciona completamente.
*	El alquiler rara vez aparece en la factura de un carrier, aunque sí lo he llegado a ver explícitamente en facturas de Telefónica, Lumen/Centurylink, Ufinet, etc y con prefijos de LACNIC.
*	Un prefijo sub-asignado puede anunciarse por varios peers BGP, no existe diferencia técnica si es asignado o sub-asignado. Los routers entienden BGP como un protocolo de negociación de rutas. El resto son políticas humanas y administrativas.
*	Es una excelente opción, y amparado en las políticas de LACNIC, el "alquiler" de direccionamiento IPv4 siempre y cuando el beneficiario de la asignación utilice esos recursos en conjunto con la provisión de tránsito. Pongo entre comillas alquiler porque dentro de la negociación comercial, la asignación de las direcciones viene como parte de un paquete global en donde el precio definido va marcado más por las características de enlace y otros servicios (capacidad, hilos de fibra, respaldo vía radio, múltiples sitios, transporte nacional, telefonía, etc) y el lucro viene de proveer conectividad, no de alquilar direcciones per se.
*	Proveedores de hosting, que despliegan múltiples POP por datacenters del mundo, (a menos que sean un AWS, Google, Azure con millares de stock de IPv4) a veces contratan, de manera análoga al ejemplo antes mencionado, unidades de rack y servidores dedicados para revender servidores virtuales pequeños al minoreo, con direcciones IP como parte de su matriz de costo. Ejemplo: soy Godaddy y deseo tener POP en Paraguay; consigo una empresa de hosting a quien le alquilo un servidor dedicado entero con 1 Gbps de tránsito y un /24 de IPs, pero deseo anunciar el /24 con mi ASN y con subasignación en LACNIC para que las IP estén "brandeadas" como de Godaddy cuando se consulte el whois. Es lógico que si contrato el servidor con 1 Gbps de solamente tránsito, o si por el contrario, contrato el Gbps de tránsito MÁS 256 direcciones IP, el precio a pagar mensual va a diferir, pues el proveedor del datacenter y de tránsito estaría destinando una parte de su limitado pool. Tenemos aquí un "alquiler" implícito en conjunto con un servicio de infraestructura y conectividad. Si adicionalmente desea tener salida internacional por otro carrier con conexión en el mismo datacenter, podrá perfectamente anunciar en paralelo el prefijo si el dueño se lo permite (LoA)
*	Ojo con la asignación de direccionamiento, este se asigna a una ORGANIZACIÓN, no a un ASN. Dicha organización puede tener o no ASN, y puede ser anunciado por un ASN propio o de un tercero. No es que LACNIC asigna direcciones IP y van atadas a un ASN. Precisamente la validación RPKI con certificados RoA permite declarar qué ASN tiene permiso de anunciar tal o cual prefijo. Hago esta aclaración que es fundamental.
*	Si una entidad tiene un sobrante de direcciones IPv4 y desea "monetizarlas" sin violar las políticas de LACNIC y correr riesgos, la entidad deberá proveer direccionamiento IP como consecuencia de proveer conectividad, housing, hosting, tránsito nacional, etc y que sea demostrable; no un alquiler como manejan los brokers. ¿Esto puede alguien confirmarlo?
*	Por último, una recomendación, tener cuidado con la geolocalización cuando un proveedor cede un prefijo porque suele estar incorrecta y genera problemas. Toca hablar con docenas de proveedores de API y rogarles la actualización, o utilizar los dichosos geofeeds que son ignorados casi siempre. Si estás en Bolivia y te cede Telefónica un prefijo que era antes de Argentina, pues pasará un tiempo hasta que veas Netflix de tu país con tu programación diferenciada, si es que la hubiere.
*	Personalmente no he lidiado con ningún broker de IPs en la región LAC, solamente cuando he realizado proyectos en España, en donde es completamente normal y común esto de comprar, acaparar, vender, alquilar, etc al estar reglado por RIPE, y que veo que tiene sus pros y contras. Recientemente ayudé a un cliente de Barcelona a configurar en su backbone y core un prefijo /22 que alquiló de un broker de unas direcciones que estaban antes en Rumanía y fue muy entretenido para mí.

Espero que la información sea de utilidad para ti y todos, y desde ya me disculpo por lo extenso. Insisto, esto es lo que veo desde hace años como alguien que se dedica a configurar BGP en routers de ISP pequeños y proveedores de servicios cloud. Aprovecho para dejar mi email emilio en telecu.net <mailto:emilio en telecu.net>  por si alguien necesita alguna consulta directa.

 

Un saludo,
Emilio Piovesan

 

 

 

 

El vie, 4 feb 2022 a las 9:10, Javier Galvez vía LACNOG (<lacnog en lacnic.net <mailto:lacnog en lacnic.net> >) escribió:

Una consulta referente a este asignamiento...

 

que pasa si el bloque de IP's que se quiere ASIGNAR a otro ASN tambien tiene BGP con la empresa que tiene asignados esos ip's , y el ASIGNADO es decir el ASN del cliente, tiene o levanta una sesion bgp con el duenio de los IP's y tambien con otros ASN's (otros proveedores), el hecho que se le este PRESTANDO los IP's pero se le este brindando un servicio (no solo leasing de ip's) sino tambien transito, pero con el convenio que se tenga un servicio de conectividad, en ese caso si seria legal el leasing y el roa, y rpki ???

 

despues de todo al usuario final que tiene SOLO SU ASN, y "contrata" un IPTRANSIT del que le esta asignando los IP's y por temas de redundancia, si desea contrata a otros proveedores, esto quiza no estaria fuera de la norma, o que dicen?

 

Salu2,

 

Javier Galvez Funes

 

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net <mailto: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 <mailto: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/20220204/870601e2/attachment-0001.htm>


Más información sobre la lista de distribución LACNOG