networking - reservadas - Analizar encabezados de extensión IPv6 que contienen extensiones desconocidas
encabezado ipv6 version (4)
Estoy escribiendo un filtro de red muy simple y estoy llegando a donde quiero analizar los encabezados de IPv6 para que coincidan con cosas como los tipos de ICMPv6, los números de los puertos TCP / UDP, etc.
Así que estoy leyendo sobre el formato del paquete IPv6 en profundidad, y estoy como ... bueno ... tuve que leerlo una y otra vez para asegurarme de que realmente lo estaba leyendo bien. Me parece que debes comenzar con el encabezado fijo de 40 bytes y ver su próximo campo de encabezado. Luego debe mirar el siguiente campo de encabezado del próximo encabezado, y así sucesivamente, como una lista vinculada, hasta que llegue al final. Si hay carga útil, seguirá.
El problema es que no hay campo de longitud en el encabezado fijo o en los encabezados de extensión. Debe tener una tabla de tipos de encabezado de extensión y sus tamaños para que pueda seguir esta lista vinculada hasta el final.
Esto me parece un diseño extraño, posiblemente incluso con cerebro de liebre. ¿Qué sucede si encuentro un tipo de encabezado de extensión no reconocido? ¿Qué debo hacer? No sé su longitud. Supongo que tengo que tirar el paquete y bloquearlo, ya que en un filtro de red que permite el paso del paquete permitiría a un atacante evadir el filtro de red al incluir un tipo de encabezado falso. Pero eso significa que si el protocolo se extiende alguna vez, cada una de las partes del software de análisis de encabezado IPv6 que se haya escrito debe actualizarse simultáneamente si se va a usar la nueva extensión.
Entonces, ¿cómo puedo analizar los encabezados IPv6 si no sé las extensiones que están usando? ¿Cómo puedo omitir un encabezado para una extensión desconocida, ya que no sé su longitud?
¿Qué sucede si encuentro un tipo de encabezado de extensión no reconocido?
De RFC 2460 :
Si, como resultado del procesamiento de un encabezado, se requiere que un nodo pase al siguiente encabezado pero el nodo siguiente no reconoce el valor del siguiente encabezado en el encabezado actual, debe descartar el paquete y enviar un mensaje de problema de parámetro ICMP a la fuente del paquete , con un valor de Código ICMP de 1 ("Tipo de encabezado siguiente no reconocido encontrado") y el campo Puntero ICMP que contiene el desplazamiento del valor no reconocido dentro del paquete original. Se debe realizar la misma acción si un nodo encuentra un valor de Next Header de cero en cualquier encabezado que no sea un encabezado IPv6.
Es (en el mundo real) imposible agregar un nuevo encabezado de extensión a IPv6.
Incorrecto, porque:
Solo el host de destino puede rechazar basándose en encabezados de extensiones no reconocidas (con esa única excepción mencionada en la pregunta que enlazó )
Si su nuevo encabezado de extensión es de alguna manera opcional (es mejor que lo sea), recibirá un error ICMP al respecto y podrá volver a intentarlo sin él.
La actualización RFC 6564 cubre este caso. Expone exactamente el escenario que describes y presenta un formato para los nuevos encabezados de extensión (si hay alguno definido) con los que las middleboxes como la tuya podrán trabajar, al menos algunas veces.
Tenga en cuenta que no se pretende extender IPv6 creando nuevos encabezados de extensión, sino agregando nuevas Opciones de destino. Debería ser trivial, o al menos mucho más fácil, para tratar con opciones de destino desconocidas.
Si se encuentra con algo que no puede analizar, tiene que tomar una decisión o realizar su acción en función de lo que ya ha analizado.
El diseño es así porque en IPv6, cada encabezado de extensión "envuelve" el resto del paquete. Si ve el encabezado de enrutamiento, luego un encabezado del que nunca ha oído hablar, luego la carga útil, entonces no puede analizar la carga útil. El significado de la carga útil depende, en principio, del encabezado que no sabes cómo interpretar.
Los enrutadores pueden enrutar dichos paquetes, porque todo lo que necesitan es el encabezado de enrutamiento. Los dispositivos de inspección profunda de paquetes y cosas por el estilo necesitan saber mucho, pero ese es su destino de todos modos.
Editado para agregar: Este diseño significa que los middleboxes solo pueden cambiar lo que saben. Si un middlebox ve un encabezado que no conoce, entonces solo tiene dos opciones: Rechazar o transmitir. En IPv4 también podría eliminar la extensión desconocida y pasar el resto. IMO esta propiedad hace que el diseño sea más extenso que menos extensible.