[lacnog] Registro de puertos de origen en servidores web / Source Port Logging on Web Servers
Fernando Frediani
fhfrediani en gmail.com
Jue Abr 4 14:30:53 -03 2019
En un evento reciente de NIC.br sobre IPv6 tuve la oportunidad de hablar
sobre este tema y uno de mis argumentos fue que: "No implementar IPv6
necesariamente cuesta más para el ISP".
Y no "cuesta" más en el sentido figurado porque un ISP con IPv6 'es más
bello que uno sin', pero cuesta financieramente en diversos costos
operacionales y capex. Considere lo siguiente:
- Un ISP que posee IPv4-only y CGNAT tiene TODO su tráfico de CGNAT
pasando por un equipo más caro (algunas decenas de miles de dólares) y
cuanto más tráfico mayor y más capex y opex el ISP tendrá que gastar con
este equipo. Si existe IPv6 este tráfico sigue directo al borde sin
"gasto" de capacidad del equipo más caro y crear nuevos bottlenecks.
- Un sistema de indexación de registro de CGNAT es más complejo, y
cuanto más datos entrados en él más él cuesta para ser mantenido
(equipos, sistema, storage, tiempo de personal, etc). Por otro lado,
consultar registros de qué prefijo IPv6 fue entregado a un usuario en el
acto de autenticación y mucho más simple y menos costoso.
Saludos
Fernando Frediani
On 04/04/2019 13:28, Alejandro D'Egidio via LACNOG wrote:
> Es verdad que independientemente del CGN lo primero que hay que hacer
> es desplegar IPv6, de eso creo que no hay dudas.
> Está muy bien el planteo de que al tener IPv6 reduce mucho la cantidad
> de sesiones incluso mas del 50% he visto que se terminan siendo de
> IPv6 por lo que es es un gran motivo adicional para desplegar IPv6.
>
> Con respecto a CGN, mi punto de vista sigue siendo en que no se puede
> escapar, no es perder ni tiempo ni dinero porque ese equipo que tiene
> funcionalidad de CGN (NAT44) normalmente tiene la funcionalidad de NAT64.
> Es de público conocimiento que estamos trabajando para que 464XLAT
> pueda ser desplegado en redes masivas (ej cable) pero hoy veo 2
> grandes motivos que frenan:
>
> 1. Disponibilidad de FW con CLAT en CPE: Por suerte puedo decir que
> nosotros ya tenemos un FW con esta funcionalidad implementada y
> funciona correctamente, luego de mucho tiempo de estar solicitando
> pero es verdad que no es común en las redes fijas.
> 2. Tráfico privado con CDNs: Este modelo permite que los usuarios se
> conecten con sus IPv4 privadas de CGN (100.64.0.0/10 normalmente)
> directamente a las IPv4 públicas de las CDNs lo que evita una
> carga adicional, temas de escalabilidad y rendimiento por el CGN.
>
> A esto digo que se asume que IPv6 ya tiene que estar desplegado en la red.
> Con esto no apoyo el uso del CGN para nada pero es necesario hasta que
> estén resueltos algunos detalles.
>
>
>
> Saludos,
> Alejandro
>
>
> ------------------------------------------------------------------------
> *De: *"Uesley Correa" <uesleycorrea en gmail.com>
> *Para: *"Latin America and Caribbean Region Network Operators Group"
> <lacnog en lacnic.net>
> *Enviados: *Jueves, 4 de Abril 2019 12:07:30
> *Asunto: *Re: [lacnog] Registro de puertos de origen en servidores web
> / Source Port Logging on Web Servers
>
> Así mismo.
> Cuando hay despliegue IPv6, 2000 puertos nomás se necesita a cada
> dirección Privada. Pero cuando hablamos de IPv4 only en CGN ahí hay el
> problema. Cuando alocados de forma fija, en mis pruebas se quedó más
> sencillo establecer un número de puertos que abarque a todos los
> clientes y que no tengamos que hacer / crear excepciones. Y así llegué
> nos 4000 sin IPv6 y 2000 fijos con IPv6. En estos escenarios, no hay
> necesidad de log adicional sino que el de autenticación y el vinculo
> de dirección privada X pública nomás va a resolver el tema.
>
> Saludos,
>
> Uesley Corrêa - Analista de Telecomunicações
> CEO Telecom Consultoria, Entrenamiento y Servicios
> CEO Telecom Fiber Solutions
>
>
> Em qui, 4 de abr de 2019 às 10:59, JORDI PALET MARTINEZ via LACNOG
> <lacnog en lacnic.net <mailto:lacnog en lacnic.net>> escreveu:
>
> Ahí te doy toda la razón en algo que parece obvio, pero no lo es.
>
> Si se comparten direcciones IPv4 **Y** se despliegua IPv6, el
> número de puertos a compartir puede ser inferior, porque el 65-75%
> de tráfico irá por IPv6.
>
> Ahora bien, eso no ayuda las investigaciones de delitos …
>
>
> Saludos,
>
> Jordi
>
> El 4/4/19 16:53, "LACNOG en nombre de Fernando Frediani"
> <lacnog-bounces en lacnic.net <mailto:lacnog-bounces en lacnic.net> en
> nombre de fhfrediani en gmail.com <mailto:fhfrediani en gmail.com>>
> escribió:
>
> Considero siempre como referencia 2 mil puertas por conexión y
> suficiente para la mayoría de los casos.
>
> Hay casos especiales que pueden requerir un poco más como 4 mil
> pero creo que son excesivos y trabajar con 4 mil puertas por
> conexión resulta en algún desperdicio IPv4, considerando los
> tiempos actuales.
>
> Esto sólo es válido en mi visión si la conexión tiene Dual-Stack y
> así el "offload" de una buena parte de las conexiones se hará en
> IPv6 y sólo los destinos IPv4 sólo utilizar estos puertos.
> Esto es especialmente importante en lugares de uso más intenso
> como una empresa. Si la empresa no es IPv6 disponible, entonces la
> única solución adecuada es asegurar la entrega de un IPv4 pública,
> incluso dinámica.
>
> Sobre la cuestión de la investigación no considero que haga mucha
> diferencia cuántos usuarios comparten un memo IPv4 Publico pues si
> eso está bien definido en los registros y es posible identificar
> con precisión a la persona investigada. El acto de consultar los
> logs en sí no es quebrada de privacidad de nadie, incluso porque
> (importante recordarlo) los logs en proveedores de acceso ** no
> deben guardar IP o Porta ta Destino ** pero sólo de Origen.
>
> Fernando
>
> On 04/04/2019 11:32, JORDI PALET MARTINEZ via LACNOG wrote:
>
> Hace unos años, NTT indicó tras algunas pruebas, que por cada
> dispositivo “detrás” del NAT, se requerían al menos 300 puertos.
>
> Un usuario residencial con 5 personas en la familia y un solo
> dispositivo activo por cada uno, implica 1.500 puertos.
>
> Una empresa con 20 empleados, serían 6.000 puertos.
>
> En los tutoriales de IPv6, yo uso una diapositiva de ese
> estudio de NTT (la 37,
> https://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf).
>
> El problema ese que ese estudio tiene muchos años, y ahora se
> utilizan muchas mas conexiones (todo depende de que
> aplicaciones, por supuesto), porque cada vez se usa “mas”
> AJAX. Con http2 y QUIC esto se reducirá.
>
> En algunos países Europeos, se ha optado por usar 4.000
> puertos (es decir, 16 usuario por cada IP). Es un código de
> buenas prácticas entre los ISPs, de forma voluntaria. Pero no
> solo por esto, sino para facilitar, en caso de delitos, que la
> investigación se reduzca a 16 usuarios o menos, porque si
> hubiera 30 usuarios (o mas), un juez no autoriza a
> investigarles a todos.
>
> Fijaros que si solo hay un usuario perfectamente sería
> suficiente 1.000 o 2.000 puertos, pero y si tiene varios
> dispositivos? Y si son mas usuarios? La variabilidad entre
> 300, 1.000, 2.000 o 4.000 puertos, implica que en muchos casos
> (y horas del día), los puertos “estáticos” son una barbaridad,
> pero lo contrario es “log”, como bien dice Alejandro.
>
> Pero además, direcciones IPv4 detrás de CGN es sinónimo a que
> tus IPv4 sean bloqueadas por Sony y otras plataformas, de
> forma **permanente**, han dicho por activa y pasiva, que NO
> las eliminan de las listas negras.
>
> Recomendación/conclusión: No inviertas en CGN, es 100.000
> veces preferible desplegar IPv6 e IPv4 como Servicio (IPv4aaS)
> con 464XLAT, que es una inversión a largo plazo, e incluso
> comprar direcciones IPv4 si llega el caso.
>
>
> Saludos,
>
> Jordi
>
> El 4/4/19 15:58, "LACNOG en nombre de Alejandro D'Egidio via
> LACNOG" <lacnog-bounces en lacnic.net
> <mailto:lacnog-bounces en lacnic.net> en nombre de
> lacnog en lacnic.net <mailto:lacnog en lacnic.net>> escribió:
>
> Hola Uesley:
>
> Con respecto a los métodos de NAT coincido en que si querés
> bajar mucho el log de sesiones te conviene ir a un modelo de
> puertos pre asignados, en lagunas plataformas lo llaman
> Fixed-NAT. Normalmente definís una cantidad de puertos fijos
> de IPs públicas para cada IP privada y adicionalmente un pool
> compartido para el caso en que el usuario exceda la
> utilización de su pool fijo de puertos. Además podés definir
> cuántos puertos dejás que ese usuario (IPv4 privada) pueda
> utilizar del pool compartido. Solo envía log de la utilización
> del pool dinámico. La desventaja de este método es que al
> dejar pre-asignados los puertos para todas las IPv4 privadas,
> hay mucho desperdicio de IPv4 públicas. El beneficio
> claramente es que genera muchísimo menos log que el método
> dinámico. En algunos casos también puede llegar a tener un
> impacto menor de CPU al ya tener pre-asignados los puertos.
>
> En el método dinámico, como beneficio hay un uso mucho mas
> eficiente de las IPv4 públicas pero como desventaja un impacto
> muy grande en logging.
>
> Como apreciación, me parece que 4000 puertos pre-asignados
> por cada IPv4 privada es mucho para un caso normal, ya sería
> casi un top-user. Habría que estudiar la cantidad de sesiones
> concurrentes en cada IP privada, en horario de máximo tráfico
> y ahí ver que porcentaje de usuarios queremos cubrir. Por
> ejemplo, si elegimos cubrir la cantidad de sesiones
> concurrentes del 80% de los usuarios, tomamos ese valor máximo
> para el dimensionamiento de puertos fijos y luego un pool
> compartido para pensar en un concurrente de IPv4 privadas y
> cada una con una cuota (cantidad de puertos del pool
> compartido), podría quedar una pequeña cantidad de clientes
> fuera que serían top-users. Hay que tener muy bien medido para
> no tener falsos positivos y afectar el servicio a clientes que
> no son top-users.
>
> CGN es un tema que en muchos casos no se quiere nombrar
> porque es casi una mala palabra pero es una realidad de casi
> todos los operadores y en vez de evitar nombrarlo creo que
> sería bueno incluso incluirlo en los temas de LACNIC/LACNOG.
> Incluso, en general, estos equipos también soportan métodos de
> transición como NAT64, etc.
>
> Saludos,
>
> ALEJANDRO D'EGIDIO
>
> *Jefe de Ingeniería de Backbone | Dirección de Ingeniería*
>
> M: +54 911 5794-1589 <callto:+54%20911%205794-1589> | F: +54
> 11 3977-1025 <callto:+54%2011%203977-1025> |
> adegidio en telecentro.net.ar <mailto:adegidio en telecentro.net.ar>
>
> Pje. Lavardén 157. Piso 3. CABA (C1437FBC)
>
> cid:708a2b23f422784912356006a328528a46bb6b99 en zimbra
>
> ------------------------------------------------------------------------
>
> *De: *"Uesley Correa" <uesleycorrea en gmail.com>
> <mailto:uesleycorrea en gmail.com>
> *Para: *"Fernando Gont" <fgont en si6networks.com>
> <mailto:fgont en si6networks.com>
> *CC: *"Latin America and Caribbean Region Network Operators
> Group" <lacnog en lacnic.net> <mailto:lacnog en lacnic.net>
> *Enviados: *Miércoles, 3 de Abril 2019 20:20:02
> *Asunto: *Re: [lacnog] Registro de puertos de origen en
> servidores web / Source Port Logging on Web Servers
>
> Fernando,
>
> En el tema de rango de puertos, para que se funcione bien y
> sin muchas interacciones en mis pruebas tuve que poner más de
> 4k puertas por dirección privada. Esto se puede ahorrar con
> bulk allocation. Tienes algunas pruebas y datos para compartir
> de tus implantaciones? Eso me interesa muchísimo conocer...
> Realidades diferentes de las que vivo.
>
> Saludos,
>
> Uesley Corrêa
>
> On Wed, Apr 3, 2019, 19:17 Uesley Correa
> <uesleycorrea en gmail.com <mailto:uesleycorrea en gmail.com>> wrote:
>
> Fernando,
>
> Cuando se loguea IPv6 necesita nomás del prefijo asignado
> y nada más. Cuando se loguea un CGN hay que loguear además
> de la dirección privada, a cuál fija está asignada y la
> puerta de origen de la conexión. Eso se pide en Brasil. Yo
> hice pruebas que me dejaron atónito: un proveedor con 5
> mil clientes genera un promedio de 10GB de datos de log a
> cada 5 dias. Y en Brasil hay que al almacenar este por 5
> años. No estoy seguro que es "más del mismo" cuando en
> IPv6 una o dos tuplas de una tabla de radius solucionan el
> problema.
>
> Saludos,
>
> Uesley Correa
>
> On Wed, Apr 3, 2019, 18:29 Fernando Gont
> <fgont en si6networks.com <mailto:fgont en si6networks.com>> wrote:
>
> On 27/3/19 18:43, Uesley Correa wrote:
> > Hola a todos,
> >
> > En este tema yo tengo debatido muchísimo con los
> operadores. Muchos de
> > ellos no encuentran necesidad en desplegar IPv6 si
> todavía tendrán que
> > mantener IPv4 a funcionar. Y yo les explico
> exactamente eso: el costo de
> > mantener todo un plantel IPv4 con todos los logs
> necesarios de
> > traducción y todo más impactará negativamente en el
> costo del servicio.
> > El ROI será afectado demasiadamente. Algunas pruebas
> que hice están
> > alineadas con lo que dijo Alejandro: son necesarios
> Teras y mas Teras de
> > espacio a esto.
>
> Por que no nateas asignando un rango de puertos a los
> usuarios?
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont en si6networks.com
> <mailto:fgont en si6networks.com>
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25
> 0D55 1D4E 7492
>
>
>
>
>
> _______________________________________________
> 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
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be
> privileged or confidential. The information is intended to be
> for the exclusive use of the individual(s) named above and
> further non-explicilty authorized disclosure, copying,
> distribution or use of the contents of this information, even
> if partially, including attached files, is strictly prohibited
> and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even
> if partially, including attached files, is strictly
> prohibited, will be considered a criminal offense, so you must
> reply to the original sender to inform about this
> communication and delete it.
>
>
>
> _______________________________________________
>
> 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
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be
> privileged or confidential. The information is intended to be for
> the exclusive use of the individual(s) named above and further
> non-explicilty authorized disclosure, copying, distribution or use
> of the contents of this information, even if partially, including
> attached files, is strictly prohibited and will be considered a
> criminal offense. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents
> of this information, even if partially, including attached files,
> is strictly prohibited, will be considered a criminal offense, so
> you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> 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
> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190404/86586002/attachment-0001.html>
Más información sobre la lista de distribución LACNOG