CGNAT – algo más que un número de puertos por usuario

La escasez de direccionamiento IPv4 es una realidad desde hace más de una década, con todos los RIRs, con la excepción de AFRINIC en la última fase de asignación de sus recursos IPv4.

Si particularizamos en el caso de RIPE, su “waiting list” para recibir una paupérrima clase C es de unos 400 días para los nuevos LIRs.

La escasez de direccionamiento IPv4 y la incapacidad de IPv6 para ser una alternativa inmediata a la escasez de direccionamiento IPv4, llevó al desarrollo del CGNAT (Carrier Grade Network Address Translation) como estrategia de los operadores y las empresas para “ahorrar” direccionamiento público, permitiendo que múltiples clientes/usuarios compartan una misma dirección IP pública. Los más puristas dirán que CGNAT rompió el paradigma de la transparencia extremo a extremo de internet y que IPv6 recupera. No niego que lo haya hecho, pero en ese momento era la mejor solución en plazos y coste para mantener el crecimiento de clientes de las operadoras, especialmente con el espectacular crecimiento de la demanda de servicios de datos en las redes móviles desde la aparición de la tecnología 3G hace más de 10 años.

Sin embargo, el desarrollo de CGNAT no impidió un escenario al que la humanidad está acostumbrada en cuanto un recurso es escaso: un mercado secundario de direccionamiento IPv4. Los RIRs, como RIPE, han intentado establecer cierto control en el mismo estableciendo reglas para la transferencia temporal y permanente de direccionamiento IPv4 (RIPE-807), aunque nunca entrando en el aspecto económico de estas transacciones. RIPE, de hecho, listaba en su página web a diferentes “brokers” que ponen en contacto a vendedores y compradores de direccionamiento. Este listado ha sido siempre polémico, pues estar en dicha lista no supone respaldo alguno por parte de RIPE, que está en estos momentos replanteándose esta situación. Sin embargo, ser parte de este listado de RIPE es innegable que confiere cierta respetabilidad a estos “brokers”, cuando hemos de entender que RIPE no aplica control alguno sobre sus actividades. RIPE optó por eliminarla a finales de 2023.

¿Y cuál es el precio de una dirección IPv4? Podemos decir que actualmente oscila entre los 35$ y 50$ dependiendo del tamaño del bloque y del momento concreto. Lo que sí se ha producido es un descenso de precio durante 2023, que realmente no es explicado por los más entendidos de este mercado.

CGNAT como tabla de salvación

La situación de escasez de direccionamiento IPv4, el lento despliegue de IPv6 incapaz de ser una alternativa real, así como el rápido crecimiento de los servicios de datos móviles y de la banda ancha fija, llevó a los operadores a iniciar el despliegue de soluciones de CGNAT. Primero se generalizó en redes móviles y después algunos operadores lo extendieron a sus redes fijas en función de la mayor o menor disponibilidad de direccionamiento IPv4 propio.

Los proveedores de soluciones CGNAT podemos clasificarlos en tres grandes grupos en función de su procedencia:

  • Routing – proveedores clásicos como Juniper, Nokia, Cisco o Huawei
  • Datacenter (balanceadores de carga) – A10 Networks y F5 están en este segmento
  • Datacenter (seguridad) – los últimos en llegar, Fortinet y Palo Alto han comenzado a incorporar CGNAT dentro de las funcionalidades de sus plataformas

Sin embargo, hemos de entender que CGNAT se ha “comoditizado” como funcionalidad de red. Existen muchas alternativas de garantías a la hora de ofrecer la funcionalidad. Identificar las ventajas de una solución frente a otra requiere de un análisis técnico tal vez demasiado profundo para lo que hoy se demanda en los operadores nacionales. En la práctica, la adaptación de la plataforma de CGNAT a los requerimientos particulares de la red destino, junto con los aspectos puramente económicos suelen determinar la plataforma seleccionada en cada caso.

CGNAT permite maximizar el uso del escaso direccionamiento público de los operadores al permitir que una dirección IP pública sea compartida por “n” suscriptores, cada uno de los cuales recibe una dirección IP privada. A primera vista puede parecer trivial, pero trae consigo otra serie de desventajas:

  • Inversión adicional en hardware dedicado a la función de CGNAT
  • Incorporación de nuevos puntos de fallo en la red
  • Costes adicionales asociados a las obligaciones de retención de datos de los operadores. Estas obligaciones les exigen ser capaces de registrar qué usuario tenía una IP pública en determinado momento, algo que se complica por el hecho de compartir varios usuarios una misma dirección IP pública.

Aunque sea una afirmación polémica, el 99,9% de los usuarios pueden operar con normalidad desde detrás del CGNAT y sólo usuarios con requerimientos especiales han de acogerse a mecanismos de “opt-out”, que los operadores ofrecen para poder retornar a estos usuarios a un escenario de IP pública. En la práctica, las aplicaciones finales ha evolucionado para operar de modo fluido en escenarios de CGNAT o NAT444 (NAT en el CPE de cliente y CGNAT en la red). En el caso de protocolos muy específicos como FTP activo o RTSP, existen “ayudas” en las soluciones de CGNAT, los “Aplication Layer Gateways” o ALGs. También los hay para RTP, pero mejor activarlo con precaución y tras verificar cómo responden las aplicaciones de voz de tu red.

Fundamentos de CGNAT

Los requisitos de una solución de CGNAT están recopilados en la RFC6888 del IETF, “Common Requirements for Carrier-Grade NATs (CGNs)”. Es una RFC de tipo “Best Current Practice”, pero se puede considerar la principal referencia técnica existente.

Si miramos los tres tipos de configuración de CGNAT que las diferentes plataformas permiten, encontramos tres posibilidades:

  • CGNAT puerto a puerto
    • Se realizan mapeos puerto a puerto entre la IP privada y la IP pública (un usuario siempre recibirá puertos de la misma IP pública, tal y como se recoge en la RFC6888 antes mencionada)
    • Este modelo supone:
      • Máximo aprovechamiento de los puertos de cada dirección IP y máxima flexibilidad para acoger clientes con diferentes demandas de número de puertos.
      • Máxima seguridad en cuanto que no es predecible cuál será el puerto siguiente que un mismo usuario recibirá de la IP pública a la que se mapea.
      • Máximo nivel de log de CGNAT en la asignación y liberación de puertos de su dirección IP pública, es decir, los registros necesarios para saber qué IP pública y puerto fue asignado a un usuario en cada momento.
    • En definitiva, es un modelo flexible, pero con una enorme carga de información de log a almacenar y procesar
  • PBA o Port Block Allocation
    • En este caso, ante el primer flujo de un usuario que atraviesa el CGNAT, éste recibe un bloque de puertos de la dirección IP pública a la que queda asociado. Si agota dicho bloque, es posible asignar bloques adicionales siempre dentro de la misma dirección IP pública.
    • Este modelo supone:
      • Aprovechamiento intermedio de los puertos de cada dirección IP. Se asignan bloques de puertos de tamaño fijo a los usuarios, aunque no necesariamente todos los puertos del bloque vayan a usarse. Un mismo usuario puede recibir varios bloques de puertos de la misma IP pública, lo cual aporta una flexibilidad intermedia para acoger clientes con diferentes demandas de número de puertos.
      • Seguridad intermedia en cuanto que es algo más predecible cuál será el puerto siguiente que un mismo usuario recibirá de la IP pública a la que se mapea, puesto que siempre quedan dentro de bloques de puertos consecutivos.
      • Nivel de log de CGNAT para “retención de datos” intermedio, el cual se genera en la asignación y liberación de los bloques de puertos de su dirección IP pública.
  • CGNAT determinístico
    • Este modelo establece una relación estática entre IPs privadas e IPs públicas de modo que cada IP privada recibe de modo fijo un bloque de puertos consecutivos dentro de la IP pública que le es asignada. El usuario no puede recibir bloques de puertos adicionales.
    • Este modelo supone:
      • Aprovechamiento menor de los puertos de cada dirección IP. Se asignan un bloque de puertos de tamaño fijo de manera automática a cada dirección IP privada a NATear, tanto si esos puertos se usan como si no. Un usuario no puede usar más puertos de los recibidos.
      • Seguridad menor en cuanto que es aún más predecible cuál será el puerto siguiente que un mismo usuario recibirá de la IP pública a la que se mapea, puesto que siempre quedan dentro de su único bloque de puertos.
      • Nivel de log de CGNAT nulo. Al ser una relación estática entre IPs privadas e IPs públicas las plataformas de CGNAT generan un registro fijo como puede ser un fichero “csv” o incluso las hay que generan un fichero ejecutable en Python que se puede interrogar para establecer estos mapeos.

La importancia de los temporizadores

Y aquí es donde llegamos a una gran pregunta: ¿cuántos puertos reservas de una IP pública para un usuario de red fija o de red móvil? Aquí es donde muchos buscan el santo grial de un número “mágico” obviando múltiples aspectos:

  • ¿Es un usuario dual-stack? Si es así, buena parte de sus sesiones discurrirán sobre IPv6, luego su demanda de puertos será notablemente inferior que si es exclusivamente IPv4.
  • ¿Es un teléfono móvil o un ordenador? El nivel de consumo de puertos es infinitamente inferior en los sistemas operativos móviles, que en los clásicos Windows, MacOS o Linux.
  • Y el aspecto central, la configuración de temporizadores en el CGNAT. Éstos determinan cuándo una sesión es considerada como terminada, luego la solución de CGNAT no ha de mantenerla activa y el puerto o puertos utilizados para la misma pueden ser liberados y utilizados por nuevas sesiones del usuario.

Es evidente que cuanto más cortos sean estos temporizadores, menos puertos requiere un usuario de CGNAT, pues tiene un mayor nivel de reutilización de puertos, y viceversa. De ahí que jamás podamos considerar el número de puertos por usuario un número absoluto, sin considerar los matices anteriores. ¿Y qué nos dice el IETF al respecto?:

  • RFC5382 “Network Address Translation (NAT) Behavioral Requirements for TCP” – no menos de 2 horas y 4 minutos para sesiones TCP establecidas
  • RFC4787 “NAT Behavioral Requirements for Unicast UDP” – no menos de 2 minutos
  • RFC5508 «NAT Behavioral Requirements for ICMP» – no menos de 60 segundos

¿Y qué sucede en la práctica? Valores infinitamente menores funcionan sin el menor de los problemas y permite un ahorro de direccionamiento IP importante.

Es importante comentar que la implementación de estos temporizadores difiere entre vendors de CGNAT. Los mejores son capaces de ser mucho más granulares que TCP, UDP e ICMP, permitiendo contadores para inicios de sesión con TCP-SYN sin respuesta, por ejemplo. Estas soluciones permiten una definición de temporizadores más adaptada y que posibilita optimizar esos puertos asignados por cliente. ¿Veremos temporizadores específicos para QUIC, hoy ya un 33% del tráfico que pasa por internet? Por el momento no y QUIC, apoyado en UDP, ya se ha diseñado para ser inmune a los “rebindings” o reasignación de puertos de CGNAT sin necesidad de restablecimiento de la sesión entre cliente y servidor, pero de esto hablaremos en otro post.

La próxima vez que alguien os pregunte o que os planteéis el diseño de vuestra solución de CGNAT espero que penséis que es algo más que un número de puertos por usuario.

¡¡¡No te pierdas nuevas entradas del blog!!!

¡No hago spam! Sólo recibirás un correo cuando haya una nueva entrada en el blog.


Publicado

en

,

por

Etiquetas:

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *