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?
fuente
Respuestas:
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.
fuente
Desde RFC 2460 :
fuente
With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.Incorrecto, porque:
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ó )
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.
fuente
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.
fuente