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 unicast estándar , el enrutador reenvía el paquete desde el origen para avanzar por el árbol de distribución y evitar bucles de enrutamiento. En cambio, el estado de reenvío multicast del enrutador funciona de forma más lógica, organizando tablas basadas en la ruta inversa, desde el receptor hasta la raíz del árbol de distribución en el origen del multicast. Este enfoque se conoce como reenvío por ruta inversa.
RPF de multidifusión
El protocolo RPF de multidifusión, generalmente denominado simplemente RPF, se utiliza junto con un protocolo de enrutamiento de multidifusión como el Protocolo de descubrimiento de origen de multidifusión (MDS) o el Protocolo de multidifusión independiente del protocolo (IPM) 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 de destino, como en el enrutamiento de unidifusión. Esto se logra mediante una tabla de enrutamiento de multidifusión dedicada o, alternativamente, la tabla de enrutamiento de unidifusión del enrutador.
Cuando un paquete multicast ingresa a la interfaz de un enrutador, este consulta la lista de redes accesibles a través de dicha interfaz (es decir, verifica las rutas por las que el paquete podría haber llegado). Si el enrutador encuentra una entrada de enrutamiento coincidente para la dirección IP de origen del paquete multicast, la verificación RPF se realiza correctamente y el paquete se reenvía a todas las demás interfaces que participan en ese grupo multicast. Si la verificación RPF falla, el paquete se descarta. Por lo tanto, el reenvío del paquete se decide en función de la ruta inversa, en lugar de la ruta directa. Al reenviar únicamente los paquetes que ingresan 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. Dado que un mismo paquete de multidifusión puede llegar al mismo enrutador a través de múltiples interfaces, la verificación RPF es fundamental para decidir si se reenvían o no los paquetes. Si el enrutador reenvía todos los paquetes que llegan a la interfaz A a la interfaz B y también todos los que llegan a la interfaz B a la interfaz A, y ambas interfaces reciben el mismo paquete, se creará un bucle de enrutamiento donde los paquetes se reenviarán en ambas direcciones hasta que expiren sus TTL IP . Es mejor evitar los bucles de enrutamiento, ya que consumen recursos de red innecesariamente.
Los supuestos subyacentes de una verificación RPF son que,
- La tabla de enrutamiento unicast es correcta y estable y,
- La ruta utilizada desde un remitente hasta un enrutador y la ruta inversa desde el enrutador de vuelta al remitente son simétricas.
Si la primera suposición es falsa, la comprobación RPF fallará, ya que depende de la tabla de enrutamiento unicast del enrutador como alternativa. Si la segunda suposición es falsa, la comprobación RPF rechazaría el tráfico multicast en todas las rutas excepto la más corta desde el remitente al enrutador, lo que daría lugar a un árbol multicast no óptimo. En los casos en que los enlaces son unidireccionales, el método de ruta inversa puede fallar por completo.
RPF Unicast
Unicast RPF (uRPF), tal como se define en RFC 3704, es una evolución del concepto de que el tráfico proveniente de redes no válidas conocidas no debe aceptarse en interfaces de las que nunca debería haberse originado. La idea original, tal como se ve en RFC 2827, era bloquear el tráfico en una interfaz si provenía de direcciones IP falsificadas. Es razonable suponer que muchas organizaciones simplemente no permiten la propagación de direcciones privadas en sus redes a menos que estén en uso explícito. Esto es una gran ventaja para la infraestructura 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 ataques DoS , DDoS y escaneo de redes para ocultar el origen del escaneo. [ 2 ]
uRPF amplía esta idea utilizando la información 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 función principal, lo que ayuda a restringir aún más las posibles direcciones de origen que deberían ser visibles en una interfaz. Los paquetes solo se reenvían si provienen de la mejor ruta de un enrutador hacia el origen del paquete. Los paquetes que llegan a una interfaz desde subredes válidas, como lo indica la entrada correspondiente en la tabla de enrutamiento, se reenvían. Los paquetes con direcciones de origen que no se pueden alcanzar 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, donde los paquetes fluyen en ambas direcciones por la misma ruta, y redes de terminales conectadas mediante un único enlace, esta suposición es válida y uRPF puede implementarse sin mayores problemas. El uso de uRPF lo más cerca posible del origen real del tráfico también detiene el tráfico falsificado antes de que pueda consumir ancho de banda o llegar a un enrutador que no esté configurado para RPF y, por lo tanto, lo redirija incorrectamente.
Lamentablemente, en la red troncal de Internet, el enrutamiento suele ser asimétrico y las tablas de enrutamiento no siempre indican la mejor ruta para que un origen llegue a un enrutador. Las tablas de enrutamiento especifican la mejor ruta de ida, y solo en el caso simétrico esta ruta equivale a la mejor ruta de vuelta. Al implementar uRPF, es importante tener en cuenta la posible asimetría para evitar el filtrado accidental de tráfico legítimo.
El RFC 3704 ofrece más detalles sobre cómo extender el reenvío estricto de ruta inversa para incluir algunos casos más flexibles que aún pueden ser beneficiosos, al tiempo que permiten al menos cierta asimetría.
Modo estricto
En modo estricto, cada paquete entrante se prueba con la FIB y, si la interfaz de entrada no es la mejor ruta inversa, la comprobación del paquete fallará. Por defecto, los paquetes que fallan se descartan. [ a ]
Modo factible
En modo factible, la FIB mantiene rutas alternativas hacia una dirección IP determinada. Si la interfaz de entrada coincide con alguna de las rutas asociadas a la dirección IP, el paquete se reenvía. De lo contrario, se descarta.
Modo suelto
En modo flexible, la dirección de origen de cada paquete entrante se compara con la FIB. El paquete se descarta solo si la dirección de origen no es accesible a través de ninguna interfaz de ese enrutador. [ a ]
Filtrado frente a reenvío
RPF se suele interpretar como filtrado de ruta inversa , especialmente en el enrutamiento unicast. Esta es una interpretación alternativa comprensible del acrónimo, ya que cuando RPF se utiliza con enrutamiento unicast, como en la RFC 3704, el tráfico se permite o se deniega según el resultado de la comprobación RPF. La idea es que el tráfico se deniega si no supera la comprobación RPF y, por lo tanto, se filtra. Si bien uRPF se utiliza como mecanismo de filtrado de entrada , se ve afectado por el reenvío de ruta inversa .
Los filtros de ruta inversa se utilizan normalmente para deshabilitar el enrutamiento asimétrico, donde una aplicación IP tiene rutas de enrutamiento de entrada y salida diferentes. Su objetivo es evitar que un paquete que entra por una interfaz salga por las otras interfaces. El filtrado de ruta inversa es una característica del kernel de Linux . [ 3 ]
Véase también
Notas
Referencias
- ↑ "Reenvío de ruta inversa" . Juniper Networks . 2010. Consultado el 12 de mayo de 2021 .
- ↑ "Comprensión del reenvío de ruta inversa Unicast" . Cisco Systems . Consultado el 12 de mayo de 2021 .
- ↑ "rp_filter y seguridad de Linux LPIC-3" . theurbanpenguin.com . 27 de agosto de 2020. Archivado del original el 24 de octubre de 2020. Consultado el 12 de mayo de 2021 .
Enlaces externos
- Enrutamiento