[lacnog] Registro de puertos de origen en servidores web / Source Port Logging on Web Servers

[Fernando Gont]

On 8/4/19 15:29, JORDI PALET MARTINEZ via LACNOG wrote:
> Hola Fernando,
> 
> El 8/4/19 14:41, "Fernando Gont" <fernando en gont.com.ar> escribió:
[....]
>     
>     Ejemplo: vos has aseverado en conversacion nuestra por twitter (publica)
>     que ahora ha mejorado la situacion de los EH en internet. Para tal
>     aseveracion, esperaba algo con igual o mayor rigurosidad que RFC 7872.
>     TE pedi referencias al menos un apr de veces... y nunca recibi nada.
>     
>     
> Acabo de mirar en twitter y tengo que insistir en lo que dije. Bajo mi punto de vista, a algo que dije ("Los protocolos pueden ser perfectos y los operadores o implementaciones, usarlos mal. Ejemplo si un operador filtra DNS, esta mal hecho el protocolo o el operador lo hace mal ?"), tu lo sacaste por la tangente y yo insisto en ello. Podemos tener cualquier protocolo perfecto, y sin embargo los operadores pueden aplicarlo mal. Eso pasa en Internet y en cualquier sector de la actividad.


No. Tu comentario es que la situacion respecto del filtrado de paquetes
que contiene EHs ha mejorado.

Tal aseveracion la hiciste sin respaldo alguno.





>     [...]
>     > Como resumen de ese documento, tienes que el tráfico de video de
>     > Internet es del 58%, y su distribución varía de unas regiones a
>     > otras, entre NetFlix, Youtube y Facebook. Si a eso le sumas el resto
>     > del tráfico del resto de las webs de Google, Facebook, y todos los
>     > CDNs y caches, se confirma que, en una red residencial, el tráfico
>     > medio supera el 65% que he indicado hacia CDNs, y seguramente me he
>     > quedado hasta corto. Y todo ese trafico esta disponible con IPv6.
>     
>     En el contexto de tal aseveracion:
>     Por que asumis que por estar disponible en IPv6 se lo accede por IPv6?
>     
> Por la experiencia en las redes cuyos datos conozco que no es poca, y que coincide con las de otras redes que han hecho públicos sus datos, como T-Mobile en v6ops.
> 
> Si tu tienes una red dual-stack y tienes CDNs y caches en tu propia red o en el IX (también con dual-stack, pues desde hace años la mayoría de los CDNs y caches exigen soporte de IPv6 para "conectarse"), salvo que tengas *mal* implementado IPv6 y por lo tanto actúe happy-eyeballs, el trafico será IPv6.
> 
> Si actúa happy-eyeballs en algo "auto-contenido" (que eso es básicamente un CDN o caché) en tu propia red o IX (no en algo remoto que te pueden afectar proveedores de transito o de contenidos ajenos a ti), realmente tienes un problema importante.

Pareciera que intentaras reemplazar la medicion real (y documentacion
correspondiente) con un analisis "logico".

Eso no es aceptable ni usal en nada que tenga cierta relacion con la
"ciencia".


Cuando uno tiene una conversacion tecnica, y espera que el campo
evolucione, hay que tener discusiones basadas en mediciones concretas y
documentadas.

Dejame darte un ejemplo. Nosotros hicimos RFC7872, y como parte de ello
documentamos la metodologia. Geoff Huston hizo un estudio
complementario, cuestionando un poco nuestra metodologia (con toda
razon), y publico esto: http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html

LOs datos terminaron coincidiendo. Pero es justamente no solo la
medicion, sino tambièn la documentacion del proceso lo que permite la
evaluacion por parte de pares, el mayor entendimiento de la materia, y
el hallazgo de errores en la metodologia o medicion (si es que los hubiera).


Por el contrario, cuando los argumentos son "Medi tal cosa, y me dio
X... -- Tenes que creerme", la conversacion termina siendo mas de bar,
supermercado, o contranoche que otra cosa.


-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492