Resumen

  • RFC 3704 explica por qué el RPF estricto puede descartar un paquete legítimo: la interfaz de entrada no coincide con la interfaz que la mejor ruta usaría para volver a su origen.
  • El RPF factible admite rutas alternativas conocidas si se anuncian de manera coherente; el RPF flexible tolera más asimetría, pero renuncia a buena parte de la evidencia sobre la dirección de origen.

El router evaluó el camino de vuelta

Un sitio está conectado a dos proveedores. Envía un paquete por el segundo, con una dirección de origen que puede utilizar. Más adelante, un router lo recibe por la interfaz de ese proveedor y consulta su tabla: la mejor ruta hacia esa dirección vuelve por el primer proveedor. El RPF estricto lo descarta. No ha identificado quién originó el paquete; solo ha comparado la interfaz de llegada con su propia vista de las rutas.

Publicado en marzo de 2004 como Best Current Practice 84, RFC 3704 actualizó RFC 2827, la recomendación anterior para filtrar tráfico al entrar en una red. La meta de limitar la suplantación de direcciones seguía vigente; lo que complicaba su aplicación eran el multihoming y los caminos asimétricos. El trayecto real de ida no tiene por qué coincidir con el que el sistema de enrutamiento elegiría para volver.

Una lista de prefijos permitidos por interfaz ofrece un criterio predecible, pero puede quedar desactualizada si se mantiene a mano. El RPF estricto hace una comprobación dinámica: busca el origen en la FIB y acepta el paquete únicamente si llegó por la interfaz de la mejor ruta. Es sencillo en un borde simétrico. También puede eliminar tráfico legítimo si la ruta de vuelta es asimétrica, falta en la tabla o no fue aceptada por la política del proveedor.

Más rutas, otra condición

El RPF factible añade rutas alternativas al conjunto de caminos que pueden validar un paquete. En vez de consultar únicamente la mejor ruta de la FIB, puede usar otras rutas conservadas en una tabla de enrutamiento o específica para RPF. Así evita rechazar un paquete válido solo porque otra ruta sea ahora la preferida.

Pero esa lista no equivale a todos los caminos posibles. RFC 3704 exige que los anuncios relevantes lleguen de manera coherente a los routers que hacen la comprobación. Un proveedor puede no recibir un prefijo que otro sí conoce por culpa de una política o una route-map. Si se filtra el anuncio, también puede filtrarse el paquete. Una regla local depende entonces de decisiones de control distribuidas entre dominios administrativos.

El RPF flexible pregunta si existe alguna ruta hacia el origen, sin comprobar por qué interfaz apunta. Tolera asimetría, pero una dirección suplantada que sí esté enrutada puede pasar. Una ruta por defecto debilita aún más el criterio, salvo que la implementación la trate de forma especial. Por eso RFC 3704 limita su utilidad como filtro entre cliente y proveedor; lo considera más apropiado para rechazar direcciones no enrutadas aguas arriba o como verificación de que otra red aplica algún filtrado.

El documento también propone coordinar las rutas: conseguir que cada proveedor anuncie los prefijos del cliente, a menudo mediante espacio independiente del proveedor y BGP; dirigir cada prefijo asignado por un proveedor solo hacia ese proveedor; o generar listas desde bases de datos de clientes. Cada alternativa desplaza la tarea entre routers, redes y operadores. Ninguna convierte la presencia de una ruta en prueba de identidad.

La verificación más específica ocurre cerca del origen. Un router más distante puede establecer, como mucho, que el origen podría pertenecer a un prefijo alcanzable. Filtrar en varios niveles puede mejorar la trazabilidad, pero no prueba quién atacó ni cuánto se ha desplegado el control. RFC 8704, publicada en 2020, actualizó RFC 3704 con técnicas de RPF factible mejorado: evidencia de que el equilibrio seguía siendo difícil, no de que todos los operadores lo adoptaran.

La pregunta útil no es si el modo estricto o flexible es siempre mejor. Es qué sabe el control: la mejor ruta de retorno, varias rutas alternativas o simplemente que existe alguna ruta. El resultado depende de la tabla y del punto de entrada. RFC 3704 convirtió la integridad de las rutas en una responsabilidad compartida.

Fuentes