[Ietf-lac] Fwd: [dns-esp] Versión en español del Informe IETF 101

[Fernando Gont]

On 05/15/2018 05:33 PM, Alejandro Popovsky wrote:
> 
> Respecto de la seguridad... a veces la falta de conocimiento de los
> problemas de conectividad
> por parte de empresas y proveedores pueden ocasionar pérdidas similares
> a las ocasionadas
> por ciberataques.

La diferencia en este caso es la posibilidad de un agente malicioso
pueda provocar dichas "perdidas" de manera intencional. (Simil a, por
ejemplo la diferencia entre un sistema que por mal funcinamiento cada
tanto se resetea vs. la posibilidad de un atacante de causar dicho reset
de manera intencional a gusto y placer).

En principio (mas alla del sinnumero de papers, articulos, y
presentaciones que se han hecho en torno al control de congestion TCP y
demás), la realidad es que lo que TCP provee a la aplicacion es un
"flujo de bytes 'confiable'". Por mas que se haya trabajado mucho en
torno a lo que es performance de TCP, no hay garantia alguna al respecto
(al final del dia, módulo agregados off-band, IP en sí es 'best effort').

Otro punto a considerar es que de algun modo hemos estado bastante (mal)
acostumbrados a asumir que "todo es TCP", y que uno tiene que poder
entender la sintaxis/semantica de todo lo que se transporta via IP,
cuando no necesaramiente eso tiene que ser así (mas alla de que *lo es*,
y seguramente lo segura siendo). Diversas realidades (politicas de
seguridad aplicadas por firewalls, y el despliegue de NATs, entre otros)
han hecho que a la practica la sintaxis/semantica del protocolo de
transporte deba ser "conocida" -- a tal punto que uno lo da por hecho.
Pero esto es mas bien una conecuencia de las realidades mencionadas, que
el producto de algun "principio" de diseño/operacion al que
necesariamente uno deba apegarce.

En ocasiones, existen problemas de conectividad justamente causados por
la visibilidad de la metadata. Ejemplo algunas cajas (creo recordar
alguna de Cisco) que sobreescribian los numeros e secuencia TCP (para
aleatorizarlos), pero que no hacían absolutamente nada con las opciones
SACK (cuyos numeros de secuencia quedaban sin reescribirse). -- En
dichos casos, si el protocolo e transporte estuviera cifrado, entonces
los midleboxes no tendrian posibilidad de romper el protocolo de
transporte de semejante manera.


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