El reenvío de ruta inversa (RPF) es una técnica utilizada en los enrutadores modernos con el fin de garantizar el reenvío sin bucles de paquetes de multidifusión en el enrutamiento de multidifusión y para ayudar a prevenir la suplantación de direcciones IP en el enrutamiento de unidifusión . [1]
En el enrutamiento IP de unidifusión estándar, el enrutador reenvía el paquete lejos del origen para avanzar a lo largo del árbol de distribución y evitar bucles de enrutamiento. Por el contrario, el estado de reenvío de multidifusión del enrutador se ejecuta de manera más lógica al organizar tablas basadas en la ruta inversa, desde el receptor hasta la raíz del árbol de distribución en el origen de la multidifusión. Este enfoque se conoce como reenvío de ruta inversa.
El RPF de multidifusión, normalmente denominado simplemente RPF, se utiliza junto con un protocolo de enrutamiento de multidifusión, como el protocolo de descubrimiento de origen de multidifusión o el protocolo de multidifusión independiente para garantizar el reenvío sin bucles de paquetes de multidifusión. En el enrutamiento de multidifusión, la decisión de reenviar el tráfico se basa en la dirección de origen y no en la dirección de destino como en el enrutamiento de unidifusión. Para ello, utiliza una tabla de enrutamiento de multidifusión dedicada o, alternativamente, la tabla de enrutamiento de unidifusión del enrutador.
Cuando un paquete de multidifusión ingresa a la interfaz de un enrutador, el enrutador busca la lista de redes a las que se puede acceder a través de esa interfaz (es decir, verifica las rutas por las cuales podría haber llegado el paquete). Si el enrutador encuentra una entrada de enrutamiento coincidente para la dirección IP de origen del paquete de multidifusión, la verificación RPF pasa y el paquete se reenvía a todas las demás interfaces que participan en ese grupo de multidifusión. Si la verificación de RPF falla, el paquete se descarta. Como resultado, el reenvío del paquete se decide basándose en la ruta inversa del paquete en lugar de en la ruta directa. Al reenviar únicamente los paquetes que llegan a la interfaz que también contiene la entrada de enrutamiento para el origen del paquete, se evitan los bucles.
Esto es de vital importancia en topologías de multidifusión redundantes. Debido a que el mismo paquete de multidifusión podría llegar al mismo enrutador a través de múltiples interfaces, la verificación de RPF es parte integral de la decisión de reenviar paquetes o no. Si el enrutador reenvió todos los paquetes que vienen en la interfaz A a la interfaz B y también reenvió todos los paquetes que vienen en la interfaz B a la interfaz A y ambas interfaces reciben el mismo paquete, esto creará un bucle de enrutamiento donde los paquetes se reenviarán en ambas direcciones hasta sus TTL de IP caducan. Es mejor evitar los bucles de enrutamiento, ya que consumen innecesariamente recursos de la red.
Los supuestos subyacentes de una verificación RPF son que,
Si la primera suposición es falsa, la verificación de RPF fallará porque depende de la tabla de enrutamiento de unidifusión del enrutador como alternativa. Si la segunda suposición es falsa, la verificación RPF rechazaría el tráfico de multidifusión en todos los caminos excepto en el más corto desde el remitente al enrutador, lo que conduciría a un árbol de multidifusión no óptimo. En los casos en que los enlaces son unidireccionales, el enfoque del camino inverso puede fallar por completo.
Unicast RPF (uRPF), tal como se define en RFC 3704, es una evolución del concepto de que el tráfico de redes no válidas conocidas no debe aceptarse en interfaces desde las que nunca debería haberse originado. La idea original, como se ve en RFC 2827, era bloquear el tráfico en una interfaz si proviene de direcciones IP falsificadas. Es una suposición razonable que muchas organizaciones simplemente no permitan la propagación de direcciones privadas en sus redes a menos que estén explícitamente en uso. Esto es un gran beneficio para la columna vertebral de Internet, ya que bloquear paquetes de direcciones de origen obviamente falsas ayuda a reducir la suplantación de direcciones IP que se usa comúnmente en DoS , DDoS y escaneo de red para ofuscar el origen del escaneo. [2]
uRPF amplía esta idea al utilizar el conocimiento que todos los enrutadores deben tener en su base de información de enrutamiento (RIB) o base de información de reenvío (FIB) para realizar su trabajo principal, para ayudar a restringir aún más las posibles direcciones de origen que deben verse en una interfaz. Los paquetes sólo se reenvían si provienen de la mejor ruta de un enrutador hasta el origen del paquete. Los paquetes que llegan a una interfaz provienen de subredes válidas, como lo indica la entrada correspondiente en la tabla de enrutamiento. Los paquetes con direcciones de origen a las que no se pudo acceder a través de la interfaz de entrada se pueden descartar sin interrumpir el uso normal, ya que probablemente provienen de una fuente mal configurada o maliciosa.
En casos de enrutamiento simétrico, enrutamiento en el que los paquetes fluyen en ambas direcciones a través de la misma ruta y redes de terminales conectadas a través de un solo enlace, esta es una suposición segura y uRPF se puede implementar sin muchos problemas anticipados. El uso de uRPF lo más cerca posible de la fuente real de tráfico también detiene el tráfico falsificado antes de que tenga alguna posibilidad de usar ancho de banda o llegar a un enrutador que no está configurado para RPF y, por lo tanto, se reenvía de manera inapropiada.
Desafortunadamente, a menudo ocurre en la red troncal de Internet más grande que el enrutamiento es asimétrico y no se puede confiar en que las tablas de enrutamiento apunten a la mejor ruta para que una fuente llegue a un enrutador. Las tablas de enrutamiento especifican la mejor ruta directa y solo en el caso simétrico eso equivale a la mejor ruta inversa. Al implementar uRPF, es importante ser consciente del potencial de asimetría para evitar el filtrado accidental de tráfico legítimo.
RFC 3704 brinda más detalles sobre cómo extender el reenvío estricto de ruta inversa para incluir algunos casos más relajados que aún pueden ser beneficiosos y al mismo tiempo permitir al menos cierta asimetría.
En modo estricto, cada paquete entrante se prueba con la FIB y, si la interfaz entrante no es la mejor ruta inversa, la verificación del paquete fallará. De forma predeterminada, los paquetes fallidos se descartan. [a]
En modo factible, la FIB mantiene rutas alternativas a una dirección IP determinada. Si la interfaz entrante coincide con cualquiera de las rutas asociadas con la dirección IP, entonces el paquete se reenvía. De lo contrario, el paquete se descarta.
En modo suelto, la dirección de origen de cada paquete entrante se prueba con la FIB. El paquete se descarta solo si no se puede acceder a la dirección de origen a través de ninguna interfaz en ese enrutador. [a]
RPF a menudo se interpreta como filtrado de ruta inversa , particularmente cuando se trata de enrutamiento de unidifusión. Esta es una interpretación alternativa comprensible del acrónimo en el sentido de que cuando se utiliza RPF con enrutamiento de unidifusión como en RFC 3704, el tráfico se permite o deniega según la aprobación o el fracaso de la verificación de RPF. La idea es que el tráfico se deniega si no pasa la verificación RPF y, por lo tanto, se filtra. Si bien uRPF se utiliza como mecanismo de filtrado de ingreso , se ve afectado por el reenvío de ruta inversa .
Los filtros de ruta inversa se utilizan normalmente para deshabilitar el enrutamiento asimétrico cuando una aplicación IP tiene una ruta de enrutamiento entrante y saliente diferente. Su intención es evitar que un paquete que ingresa a una interfaz salga a través de otras interfaces. El filtrado de ruta inversa es una característica del kernel de Linux . [3]