La mayoría de estos problemas de seguridad surgen cuando un host acepta el tráfico IPv6 asignado a IPv4 a través de la red , en lugar de aceptar el tráfico IPv4 y presentarlo a una aplicación en un socket IPv6 con una dirección asignada. Una aplicación puede no tener una buena manera de distinguir la diferencia y detectar un posible ataque en progreso. Por supuesto, ningún host debería aceptar direcciones mapeadas de la red, pero ¿desde cuándo los sistemas operativos se han comportado a la perfección?
RFC 4942 § 2.2 explica los problemas en profundidad:
La funcionalidad sobrecargada siempre es un arma de doble filo: puede producir algunos beneficios de implementación, pero a menudo también incurre en el precio que conlleva la ambigüedad.
Un ejemplo de esto son las direcciones IPv6 asignadas a IPv4 (:: ffff / 96): una representación de una dirección IPv4 como una dirección IPv6 dentro de un sistema operativo como se define en [RFC3493]. Desde la especificación original, el uso de direcciones mapeadas de IPv4 se ha extendido a un mecanismo de transición, el algoritmo de traducción de IC / ICMP sin estado (SIIT) [RFC2765], donde se usan potencialmente en las direcciones de los paquetes en el cable.
Por lo tanto, se vuelve difícil discernir sin ambigüedad si una dirección asignada IPv4 es realmente una dirección IPv4 representada en el formato de dirección IPv6 (comportamiento API básico) o una dirección IPv6 recibida del cable (que puede estar sujeto a falsificación de direcciones, etc.). (Comportamiento SIIT). Los problemas de seguridad que surgen del comportamiento ambiguo cuando se usan las direcciones asignadas de IPv4 en el cable incluyen:
-
Si un atacante transmite un paquete de IPv6 con :: ffff: 127.0.0.1 en el campo de dirección de origen de IPv6, podría pasar por alto los controles de acceso del nodo engañando a las aplicaciones para que crean que el paquete proviene del nodo. en sí (específicamente, la dirección de bucle de retorno de IPv4, 127.0.0.1). El mismo ataque podría realizarse utilizando la dirección de interfaz IPv4 del nodo.
-
Si un atacante transmite un paquete de IPv6 con direcciones asignadas de IPv4 en el campo de dirección de destino de IPv6 correspondiente a las direcciones de IPv4 dentro del perímetro de seguridad de un sitio (por ejemplo, :: ffff: 10.1.1.1), podría ser capaz de omita las reglas de filtrado de paquetes IPv4 y atraviese el firewall de un sitio.
-
Si un atacante transmite un paquete de IPv6 con direcciones asignadas de IPv4 en los campos de origen y destino de IPv6 a un protocolo que intercambia las direcciones de origen y de destino de IPv6, es posible que pueda usar un nodo como proxy para ciertos tipos de ataques. Por ejemplo, esto podría usarse para construir ataques de multiplicación de difusión y de escaneo de puerto TCP proxy.
Además, los casos especiales como estos, aunque brindan beneficios de implementación en algunas áreas, requieren una cantidad considerable de complejidad de código (por ejemplo, en las implementaciones de llamadas al sistema bind () y búsquedas DNS inversas) que probablemente no sean deseables pero pueden ser gestionado en este caso.
En la práctica, aunque los mecanismos de traducción de paquetes de SIIT están especificados para su uso en "Traductor de dirección de red - Traductor de protocolo (NAT-PT)" [RFC2766], NAT-PT utiliza un mecanismo diferente al de las direcciones IPv6 asignadas con IPv4 para comunicarse Direcciones IPv4 incrustadas en direcciones IPv6. Además, SIIT no se recomienda para su uso como un mecanismo de transición independiente. Dados los problemas que se han identificado, parece apropiado que las direcciones asignadas no se usen en el cable. Sin embargo, cambiar el comportamiento de la aplicación al desaprobar el uso de las direcciones asignadas en la interfaz del sistema operativo tendría un impacto significativo en los métodos de transferencia de aplicaciones como se describe en [RFC4038], y se espera que las direcciones IPv6 asignadas mediante IPv4 se sigan utilizando dentro de la API para ayudar a la portabilidad de la aplicación.
El uso del comportamiento básico de la API tiene algunas implicaciones de seguridad, ya que agrega complejidad adicional a los controles de acceso basados en direcciones. El principal problema que surge es que un socket IPv6 (AF_INET6) aceptará paquetes IPv4 incluso si el nodo no tiene ningún socket IPv4 (AF_INET) abierto. Esto debe ser tenido en cuenta por los desarrolladores de aplicaciones y puede permitir que un par de IPv4 malintencionado acceda a un servicio, incluso si no hay sockets IPv4 abiertos. Esto viola el principio de seguridad de "menos sorpresa".