Analizar encabezados de extensión IPv6 que contienen extensiones desconocidas

Estoy escribiendo un filtro de red muy simple y llego a donde quiero analizar los encabezados IPv6 para que coincidan con cosas como tipos ICMPv6, números de puerto TCP / UDP, etc.

Así que estoy leyendo sobre el formato de paquete IPv6 en profundidad, y creo que ... bueno ... tuve que leerlo una y otra vez para asegurarme de que lo estaba leyendo correctamente. Me parece que debe comenzar con el encabezado fijo de 40 bytes y mirar su siguiente campo de encabezado. Luego, debe mirar el siguiente campo de encabezado del siguiente encabezado, y así sucesivamente, como una lista vinculada, hasta llegar al final. Si hay carga útil, seguirá.

El problema es que no hay ningún campo de longitud ni en el encabezado fijo ni en los encabezados de extensión. Debe tener una tabla de tipos de encabezados de extensión y sus tamaños para que pueda perseguir esta lista vinculada hasta el final.

Esto me parece un diseño extraño, posiblemente incluso descabellado. ¿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 permitir 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 pieza del software de análisis de encabezados IPv6 que se haya escrito debe actualizarse simultáneamente si se va a utilizar la nueva extensión.

Entonces, ¿cómo puedo analizar los encabezados IPv6 si no conozco las extensiones que están usando? ¿Cómo puedo omitir un encabezado para una extensión desconocida si no conozco su longitud?

Si se encuentra con algo que no puede analizar, debe 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 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 pasar. En IPv4 también podría eliminar la extensión desconocida y pasar el resto. En mi opinión, esta propiedad hace que el diseño sea más extensible que menos.

¿Qué sucede si encuentro un tipo de encabezado de extensión no reconocido?

Desde RFC 2460 :

Si, como resultado del procesamiento de un encabezado, se requiere que un nodo pase al siguiente encabezado, pero el nodo no reconoce el valor del encabezado siguiente 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 de 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 encabezado siguiente 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:

1. Solo el host de destino puede rechazar en función de los encabezados de extensiones no reconocidas (con la única excepción mencionada en la pregunta que vinculó )

2. Si su nuevo encabezado de extensión es de alguna manera opcional (es mejor que lo sea), recibirá un error ICMP sobre eso y podrá intentarlo de nuevo sin él.

La actualización RFC 6564 cubre este caso. Presenta exactamente el escenario que usted describe y presenta un formato para los nuevos encabezados de extensión (si alguna vez se definen) con los que los middleboxes como el suyo podrán trabajar, al menos parte del tiempo.

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, lidiar con opciones de destino desconocidas.