Resumen

  • RFC 2267 propuso comprobar en la interfaz del proveedor hacia el cliente que cada paquete usara un prefijo de origen permitido para esa red.
  • BCP 38 convirtió la recomendación en una buena práctica en 2000. Un paquete que pasa el filtro apunta a un límite de red, no identifica al dispositivo ni a la persona que lo generó.

La dirección que veía la víctima podía ser falsa

Un servidor recibe intentos de conexión desde direcciones que no llevan a ningún sitio. Envía respuestas inútiles y el emisor cambia el campo de origen. En otros paquetes puede aparecer una dirección real que pertenece a una red ajena al ataque. Si el servidor afectado bloquea ese origen aparente, quizá también deje sin servicio a sistemas legítimos de esa red inocente.

Ese problema aparece en la RFC 2267. El destinatario puede leer la dirección escrita en el paquete, pero no tiene una forma directa de comprobar quién la eligió. Mejorar el sistema operativo permite resistir más intentos; no le revela a una víctima distante si el origen fue falsificado. El memo presenta esas defensas como complementarias y propone comprobar el paquete antes, cerca de la red que lo puso en circulación.

El proveedor podía comparar el paquete con su enlace

Supongamos que un proveedor agrega las rutas de varias redes conectadas. En la interfaz que conduce a un cliente concreto, ya conoce qué prefijos están autorizados para esa conexión. El ejemplo de la RFC deja pasar los paquetes cuyo origen está dentro del prefijo del cliente y rechaza los que dicen proceder de otro lugar. También recomienda registrar los descartes para que los administradores puedan revisar actividad sospechosa.

No se trata de consultar un registro global de titulares de direcciones. La comprobación usa una relación local: qué prefijos puede enviar este cliente por este enlace. Antes de que el paquete avance por la red del proveedor, su campo de origen se compara con esa lista. Si no encaja, el descarte ocurre cerca del punto donde el tráfico entró, en vez de dejar a la víctima con otra dirección dudosa que investigar.

El cambio es de ubicación y de responsabilidad. Sin esa comprobación, la víctima tiene que interpretar un campo que el emisor controla y puede terminar perjudicando al titular inocente de la dirección aparente. Con filtrado en el borde del proveedor, la red que transporta el tráfico del cliente puede rechazar fuentes que no corresponden a esa conexión. Si el ataque todavía usa un prefijo permitido, la investigación al menos puede empezar dentro de una red identificable, no en cualquier lugar de Internet.

No es una prueba de ruta de retorno

La RFC 2267 distingue su propuesta de otra comprobación: consultar si la ruta de vuelta hacia la dirección de origen saldría por la misma interfaz por la que llegó el paquete. Los autores no recomendaron convertir esa prueba en una regla general porque las rutas asimétricas la harían problemática. Su filtro compara el origen con los prefijos legítimos del cliente en esa interfaz.

Ambas decisiones se ejecutan en una entrada, pero responden a preguntas distintas. La prueba de retorno sigue la dirección que indica la tabla de rutas; la lista de prefijos verifica qué puede originar el cliente conectado. La RFC 3704 abordó después los mecanismos de filtrado en redes multihomed y actualizó la RFC 2827. Sus modos strict, feasible y loose de RPF tienen una cobertura propia; no son el tema de este artículo.

Una excepción móvil muestra el coste de la regla

Una dirección puede ser legítima para un nodo móvil y, aun así, resultar inesperada en la red a la que se conectó temporalmente. RFC 2267 señaló ese caso de Mobile IP: el tráfico de salida podía conservar la dirección de origen de la red habitual del nodo. Un filtro que solo permitiera el prefijo local del proveedor visitado podría descartarlo. El memo remitió al túnel inverso, descrito después en la RFC 2344, para enviar el paquete al agente local antes de sacarlo a Internet.

El filtro no decide si el usuario actúa de buena fe; comprueba una relación entre enlace y prefijo. Un servicio válido que necesite otro origen requiere un camino o una política que haga compatible ese paquete con la frontera. Las RFC no afirman que toda movilidad se rompa ni que deban eliminarse todas las excepciones. Dejan claro que la excepción debe hacerse visible en la regla operativa.

De memo informativo a BCP 38

RFC 2267 se publicó en enero de 1998 como documento informativo. En mayo de 2000, la RFC 2827 la sustituyó con el mismo título, “Network Ingress Filtering”, y el número BCP 38. La recomendación central permaneció: los proveedores debían filtrar en la entrada el tráfico del cliente para impedir que usara fuentes que su red no tuviera legítimamente asignadas o anunciadas.

El cambio de categoría documental no demuestra qué ocurrió en los routers. RFC 2827 establece una buena práctica, pero no indica qué proveedores instalaron filtros, en cuántos enlaces ni con qué cobertura. RFC 2267 dice que algunos ya empezaban a aplicar la técnica; no aporta un censo. Conviene separar el texto publicado, la política del proveedor, la regla cargada en una interfaz, el paquete descartado y la investigación que sigue al evento.

El alcance del filtro también es limitado. Puede rechazar prefijos falsificados que quedan fuera del conjunto permitido. No impide que un atacante use la dirección de otro equipo dentro del prefijo autorizado, ni bloquea una inundación enviada desde una dirección válida. Tampoco demuestra qué máquina transmitió el paquete, quién la controlaba o con qué intención actuó. Un registro de descarte puede localizar una decisión de red; no identifica por sí solo a su autor.

La aportación histórica fue práctica: la víctima dejó de ser el único lugar donde intentar interpretar una fuente engañosa. RFC 2267 situó una comprobación verificable en el borde que une a un proveedor con el cliente, donde podía mantenerse la relación entre enlace y prefijos. BCP 38 dio continuidad a la recomendación. En cada conexión, su resultado seguía dependiendo de que la política local estuviera bien configurada, instalada y activa.

Fuentes

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering (BCP 38)
  3. RFC 1812 — Requirements for IP Version 4 Routers
  4. RFC 2002 — IP Mobility Support
  5. RFC 2344 — Reverse Tunneling for Mobile IP
  6. RFC 3704 — Ingress Filtering for Multihomed Networks (BCP 84)