Resumen

  • El uRPF estricto puede rechazar tráfico asimétrico legítimo y el laxo pierde direccionalidad; RFC 8704 define conjuntos factibles específicos para cada interfaz.
  • El método hereda la calidad de BGP, los filtros de prefijos y los datos de relaciones. No autentica contratos ni demuestra despliegues reales.

Análisis

Validar una dirección de origen significa decidir si un paquete podía llegar legítimamente por esa interfaz. En un borde con un solo enlace, la tabla de reenvío puede responder con claridad. En un entorno multihomed, la ruta de regreso seleccionada puede no coincidir con la de entrada. La dirección aporta evidencia, pero la mejor ruta no contiene toda la autorización.

BCP 38 fijó el objetivo del filtrado de entrada: detener cerca del origen el tráfico con direcciones falsificadas y mejorar su trazabilidad. RFC 3704 describió varias técnicas. El uRPF estricto busca el origen en la FIB y exige que la interfaz de llegada sea la elegida para regresar. Es sencillo y sólido con rutas simétricas, pero puede descartar tráfico válido cuando la política o el multihoming producen asimetría.

El uRPF laxo evita muchos falsos positivos preguntando solo si existe una ruta. Así pierde la dirección: un prefijo accesible en algún lugar de la tabla puede seguir siendo imposible en la interfaz donde apareció.

RFC 8704 cambia ese compromiso. Define una lista RPF por interfaz con los prefijos de origen permitidos. El algoritmo A amplía la lista más allá del único mejor camino, pero no hasta toda la tabla. Si el router recibió por una interfaz una ruta originada por un AS, otros prefijos debidamente verificados de ese AS pueden considerarse factibles en esa interfaz.

La ampliación tiene condiciones. RFC 8704 parte de rutas examinadas mediante filtros de prefijos y, cuando se use, validación de origen. Una ruta aprendida de la parte equivocada no se vuelve fiable por entrar en una lista. La frontera depende de la calidad de las rutas y de la relación que el operador atribuye a la adyacencia.

Para topologías cliente-proveedor difíciles, el algoritmo B permite flexibilidad adicional en un cono de clientes identificado. Puede admitir fuentes legítimas indirectas, pero aumenta la dependencia de datos comerciales correctos. Un cono obsoleto o un peer mal clasificado ensancha el límite más allá de lo autorizado.

Los ROA y los datos IRR pueden complementar la lista. Mejoran la evidencia de origen, pero no demuestran por sí mismos que una interfaz concreta esté autorizada. Autorizar el origen y autorizar la interfaz son afirmaciones distintas.

El coste incluye más estado RPF, actualización durante transitorios BGP, investigación de descartes y control de excepciones. Las fuentes no prueban compatibilidad universal, despliegue por una red concreta ni una reducción medida de falsos positivos.

SAVNET confirma que el problema sigue abierto: los mecanismos existentes pueden aceptar tráfico falsificado o bloquear tráfico legítimo. Su carta describe trabajo futuro, no una arquitectura disponible hoy.

Fuentes