Muchos documentos indican que en QUIC resuelve el problema de suplantación de IP mediante un token generado por el servidor. Específicamente, el servidor emite un token para que el cliente pueda usarlo para identificarse, luego el servidor solo responderá a aquellos con tokens válidos.
Pero, ¿no puede el atacante simplemente hacer una copia IP de la conexión inicial? ¿No lograría eso el mismo efecto de la suplantación IP del servidor DNS o NTP?
Pero, ¿no puede el atacante simplemente hacer una copia IP de la conexión inicial? ¿No lograría eso el mismo efecto de la suplantación IP del servidor DNS o NTP?
El problema con la suplantación de IP en DNS o NTP no es que la respuesta volverá a la dirección IP falsificada en lugar del remitente real porque esto también es cierto si falsifica la dirección IP en un TCP SYN. El problema, en cambio, es que a menudo la respuesta es mucho mayor que la solicitud y, por lo tanto, un atacante puede usar un ancho de banda pequeño con direcciones IP falsificadas para provocar un ataque de gran ancho de banda contra la IP falsificada (es decir, ataque de amplificación).
TCP resuelve este problema teniendo solo una pequeña respuesta a una pequeña solicitud para que nada se amplifique. Desafortunadamente, no puedo encontrar fácilmente información sobre el tamaño real del token de dirección de origen en QUIC, pero espero que se consideren los ataques de amplificación.
EDIT: gracias a paj28 por apuntar a un artículo donde se aborda el problema de la amplificación en QUIC más detalles: ... el cliente hola siempre será mayor o igual al tamaño de la respuesta del servidor ... . Esto significa que los ataques de amplificación como el problema principal de la suplantación de IP no funcionarán.
¿Depende de lo que quiere decir con "problema de falsificación de IP"?
El protocolo QUIC pertenece a la transport layer en lugar de la capa de red .
La mitigación de los efectos de la suplantación de identidad se puede hacer en la capa de transporte, tal como se hizo en TCP, el cliente necesita enviar y recibir paquetes para abrir un flujo de datos. Si el 3-way-hand-shake no está completo, el cliente no podrá hablar con la aplicación. Pero esto realmente no resuelve el problema. La suplantación de IP todavía está teniendo lugar.
Creo que el "problema de suplantación de IP" no se puede solucionar en la capa de transporte, ya que no se relaciona con la forma en que los paquetes viajan de A a B en Internet.
Si una aplicación de puede recibir datos de direcciones IP falsificadas, y el protocolo de transporte subyacente no protege la aplicación. A continuación, consulte la respuesta de Steffen Ullrich para obtener más información sobre cómo hacerlo. Hacer posibles ataques de amplificación.
No podemos evitar que el atacante nos envíe paquetes con direcciones de origen falsificadas (el ISP de los atacantes puede evitar que los envíen, pero ese es otro problema), solo podemos mitigar los efectos.
Hay dos escenarios principales contra los que debemos protegernos.
La introducción del token resuelve ambos problemas. El spoofer puede enviar paquetes "iniciales" durante todo el día, pero no puede realizar ninguna otra acción porque nunca reciben el token.
Lea otras preguntas en las etiquetas ip-spoofing protocols