RFC 10078: cuando la ruta se confunde con un permiso

Resumen

RFC 10078 separa dos datos que suelen cargarse sobre la tabla de reenvío: por dónde se alcanza un prefijo y qué direcciones puede usar como origen un cliente conectado.
uRPF estricto puede descartar tráfico legítimo por una ruta asimétrica o un prefijo oculto. uRPF flexible elimina la comprobación de interfaz, pero puede dejar pasar paquetes falsificados si su prefijo aparece en la tabla local.

Un cliente envía un paquete con una dirección que tiene permiso para usar. El router consulta la tabla de reenvío: el prefijo apunta a otra interfaz o no aparece. El paquete cae. El router respondió una pregunta válida; era la pregunta equivocada.

Ese es el problema de RFC 10078, publicado por el IETF como documento informativo en octubre de 2026. Trata la validación de direcciones de origen (SAV) dentro de un sistema autónomo, en interfaces externas que dan a hosts o redes cliente que no son AS vecinos. El cliente ni siquiera necesita ASN. Puede usar un prefijo asignado por el operador o traer el suyo.

La modalidad estricta de uRPF unicast comprueba en la base de información de reenvío (FIB) que exista una ruta que cubra la dirección de origen y que esa ruta salga por la misma interfaz por la que llegó el paquete. El chequeo es ordenado; la red puede ser menos ordenada. Un cliente con varias conexiones puede enviar por el router 1 mientras el sistema de rutas del proveedor espera el retorno de ese prefijo por el router 2. uRPF estricto toma la interfaz inesperada como prueba contra el paquete. El ejemplo del RFC termina con tráfico legítimo del cliente descartado.

La versión flexible quita la comparación de interfaz. Si la FIB local contiene un prefijo que cubre el origen, el paquete pasa. Así se rescata parte del tráfico asimétrico, pero se debilita otra defensa: también puede pasar un paquete falsificado cuya dirección pertenezca a cualquier prefijo presente en la tabla. Una modalidad confunde el camino de vuelta con el permiso; la otra confunde alcance general con permiso.

Los prefijos ocultos hacen más difícil el arreglo. Un host o cliente puede originar tráfico legítimo con una dirección que el protocolo de rutas interno del proveedor no conoce. El RFC cita Direct Server Return (DSR): la petición llega a un punto de servicio anycast, pero otro servidor de borde responde directamente usando la dirección del servicio como origen. El espacio del cliente que no se anuncia dentro de la red del proveedor crea el mismo desfase. Si falta el prefijo en la FIB, ambas modalidades de uRPF pueden descartar el paquete.

Una lista de control de acceso puede enumerar los prefijos permitidos, pero alguien debe enterarse de los cambios de autorización y actualizarla.

El documento fija cinco condiciones para los futuros mecanismos: mayor precisión; recopilación y actualización automáticas de la información SAV; despliegue incremental en parte de las interfaces elegibles; ninguna interferencia con la convergencia o el fast reroute cuando se distribuya información; y datos autenticados o confiables. Falta un registro de autorización de origen que el router pueda verificar y mantener al día. La FIB describe alcance. Convertirla también en el libro de permisos del cliente resulta cómodo hasta que los dos registros discrepan.

RFC 10078 no define ese registro, un protocolo para distribuirlo ni una solución terminada. Plantea el problema y sus requisitos. La prueba operativa es concreta: enviar tráfico legítimo por una ruta asimétrica y desde un prefijo oculto; después, probar fuentes falsificadas con prefijos presentes y ausentes de la FIB. Registrar qué regla decide cada caso, quién aporta la autorización, cómo llega el cambio al borde y qué sucede durante una modificación de ruta.