Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validación del origen del BGP

Descripción de la validación de origen para BGP

La validación de origen ayuda a evitar la publicidad involuntaria de las rutas. A veces, los administradores de redes anuncian erróneamente rutas a redes que no controlan. Puede resolver este problema de seguridad configurando la validación de origen (también conocida como enrutamiento seguro entre dominios). La validación de origen es un mecanismo mediante el cual los anuncios de ruta se pueden autenticar como originados en un sistema autónomo (AS) esperado. La validación de origen utiliza uno o más servidores de caché de infraestructura de clave pública de recursos (RPKI) para realizar la autenticación para prefijos BGP especificados. Para autenticar un prefijo, el enrutador (altavoz BGP) consulta la base de datos de asignaciones de prefijo a AS validadas, que se descargan desde el servidor de caché, y garantiza que el prefijo se originó en un AS esperado.

Nota:

Cuando habilita la autenticación RPKI, Junos OS abre el puerto TCP 2222 de forma automática sin previo aviso. Puede aplicar un filtro para bloquear y proteger este puerto.

Junos OS admite la validación de origen para prefijos IPv4 e IPv6.

Figura 1 muestra una topología de ejemplo.

Figura 1: Topología de ejemplo para validación de origenTopología de ejemplo para validación de origen

Estándares compatibles

La implementación de validación de origen de Junos OS admite las siguientes RFC y borradores:

  • RFC 6810, la infraestructura de clave pública de recursos (RPKI) al protocolo de enrutador

  • RFC 6811, Validación de origen del prefijo BGP

  • Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Comunidad extendida de estado de validación de origen del prefijo BGP (soporte parcial)

    La comunidad extendida (estado de validación de origen) se admite en la política de enrutamiento de Junos OS. No se admite el cambio especificado en el procedimiento de selección de ruta.

Cómo funciona la validación de origen

La RPKI y la validación de origen utilizan certificados X.509 con extensiones especificadas en las extensiones RFC 3779, X.509 para direcciones IP e identificadores de AS.

La RPKI consta de una recopilación distribuida de información. Cada entidad de certificación publica sus certificados de entidad final (EE), listas de revocación de certificados (CRL) y objetos firmados en una ubicación determinada. Todos estos repositorios forman un conjunto completo de información que está disponible para cada servidor de caché RPKI.

Cada servidor de caché RPKI mantiene una caché local de toda la colección de repositorios distribuidos sincronizando regularmente cada elemento de la caché local con el punto de publicación del repositorio original.

En el enrutador, las entradas de la base de datos se formatean como registros de validación de ruta (RV). Un registro rv es un triple (prefijo, longitud máxima, AS de origen). Hace coincidir cualquier ruta cuyo prefijo coincida con el prefijo RV, cuya longitud de prefijo no supere la longitud máxima dada en el registro de RV, y cuyo AS de origen sea igual al AS de origen dado en el registro rv.

Un registro rv es una versión simplificada de una autorización de origen de ruta (ROA). Un ROA es un objeto firmado digitalmente que proporciona un medio de verificar que un titular de bloque de dirección IP autorizó un AS para originar rutas a uno o más prefijos dentro del bloque de direcciones. Los ROA no se utilizan directamente en la validación de rutas. El servidor de caché exporta una versión simplificada del ROA al enrutador como un registro rv.

El valor de longitud máxima debe ser mayor o igual que la longitud del prefijo autorizado y menor o igual que la longitud (en bits) de una dirección IP en la familia de direcciones (32 para IPv4 y 128 para IPv6). La longitud máxima define el prefijo de dirección IP que el AS está autorizado para anunciar.

Por ejemplo, si el prefijo de dirección IP es 200.4.66/24 y la longitud máxima es 26, el AS está autorizado a anunciar 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 y 200.4.66.192/26. Cuando la longitud máxima no está presente, el AS solo está autorizado para anunciar exactamente el prefijo especificado en el RV.

Como otro ejemplo, una RV puede contener el prefijo 200.4.66/24 con una longitud máxima de 26, así como el prefijo 200.4.66.0/28 con una longitud máxima de 28. Este RV autorizaría al AS a anunciar cualquier prefijo que comience con 200.4.66 con una longitud de al menos 24 y no mayor que 26, así como el prefijo específico 200.4.66.0/28.

El origen de una ruta se representa mediante el número de AS más a la derecha del atributo AS_PATH. La validación de origen funciona comparando el AS de origen en una actualización de enrutamiento con el AS de origen autorizado publicado en los registros de RV.

Se sabe que la seguridad proporcionada por la validación de origen por sí sola es débil contra un atacante determinado porque no hay protección contra un atacante que suplanta el AS de origen. Dicho esto, la validación de origen proporciona protección útil contra anuncios accidentales.

Aunque la validación de origen se podría implementar haciendo que cada enrutador participe directamente en la RPKI, esto se considera demasiado intensivo en recursos (ya que se requieren muchas operaciones de criptografía de clave pública para validar los datos de RPKI), así como como un uso intensivo operacional para configurar y mantener una configuración RPKI en cada enrutador. Por esta razón, un servidor de caché RPKI independiente realiza validaciones de clave pública y genera una base de datos validada de asignaciones de prefijo a AS. La base de datos validada se descarga en un enrutador cliente mediante una conexión TCP segura. Por lo tanto, el enrutador requiere poca información acerca de la infraestructura RPKI y no tiene requisitos de criptografía de clave pública, excepto la contraseña de transporte cifrado. Posteriormente, el enrutador utiliza los datos descargados para validar las actualizaciones de ruta recibidas.

Cuando configure sesiones de servidor, puede agrupar las sesiones y configurar parámetros de sesión para cada sesión del grupo. El enrutador intenta configurar periódicamente un número máximo configurable de conexiones a servidores de caché. Si se produce un error en la configuración de la conexión, se realiza un nuevo intento de conexión periódicamente.

Mientras tanto, después de aplicar la política de importación de validación a la sesión del BGP, la validación de ruta se realiza independientemente del estado de la sesión de caché (arriba o abajo) y de la base de datos RV (vacía o no vacía). Si la base de datos rv está vacía o ninguna de las sesiones del servidor de caché está activa, el estado de validación de cada ruta se establece en desconocido, ya que no existe ningún registro RV para evaluar un prefijo BGP recibido.

El período de intento de reintento es configurable. Después de conectarse correctamente a un servidor de caché, el enrutador consulta el número de serie de la base de datos más reciente y solicita que la caché RPKI transmita todas las entradas rv que pertenecen a esa versión de la base de datos.

Cada mensaje entrante restablece un temporizador de vida real para el servidor de caché RPKI. Después de que se aprenden todas las actualizaciones, el enrutador realiza comprobaciones periódicas de la vida en función de un intervalo configurable. Esto se hace mediante el envío de una unidad de datos de protocolo de consulta en serie (PDU) con el mismo número de serie que el servidor de caché informó en su última PDU de notificación. El servidor de caché responde con cero o más actualizaciones y una PDU de final de datos (EOD), que también actualiza el estado de vida útil del servidor de caché y restablece un temporizador de duración de registro.

Cuando se recibe un prefijo de un par de BGP externo (EBGP), una política de importación lo examina y se marca como válido, no válido, desconocido o no comprobado:

  • Válido: indica que el prefijo y el par de AS se encuentran en la base de datos.

  • No válido: indica que se encuentra el prefijo, pero el AS correspondiente recibido del par EBGP no es el AS que aparece en la base de datos, o la longitud del prefijo en el mensaje de actualización del BGP es más larga que la longitud máxima permitida en la base de datos.

  • Desconocido: indica que el prefijo no está entre los prefijos o intervalos de prefijos de la base de datos.

  • No verificada: indica que el origen del prefijo no se verifica en la base de datos. Esto se debe a que la base de datos se relló y no se llamó a la validación en la política de importación del BGP, aunque la validación de origen está habilitada o la validación de origen no está habilitada para los pares del BGP.

Si hay coincidencias potenciales para la ruta en la base de datos de validación, la ruta debe coincidir con una de ellas para que sea válida. De lo contrario, no es válido. Cualquier coincidencia es adecuada para hacer que la ruta sea válida. No es necesario que sea el mejor partido. Solo si no hay coincidencias potenciales, la ruta se considera desconocida. Para obtener más información acerca de la lógica de base de datos de asignación de prefijo a AS, consulte sección 2 del borrador de Internet draft-ietf-sidr-pfx-validate-01, Validación del origen del prefijo BGP.

Nota:

La validación de RPKI solo está disponible en la instancia principal. Si configura la validación de RPKI para una instancia de enrutamiento, se producirá un error en la validación de RPKI con el siguiente mensaje RV instance is not runningde error.

Interacción del BGP con la base de datos de validación de rutas

La base de datos de validación de ruta (RV) contiene una colección de registros rv que el enrutador descarga desde el servidor de caché RPKI. Después de que la base de datos de RV se llena con registros rv, la base de datos RV escanea la tabla de enrutamiento RIB-Local para determinar si hay prefijos en RIB-Local que puedan verse afectados por los registros de RV en la base de datos. (RIB-Local contiene las rutas IPv4 e IPv6 que se muestran en el resultado del show route protocol bgp comando.)

Este proceso activa una reevaluación del BGP de las políticas de importación del BGP (no de exportación).

Figura 2 muestra el proceso.

Figura 2: Validación de BGP y ruta

Las políticas de importación se aplican a RIB-In. Otra forma de entender esto es que las políticas de importación se aplican a las rutas que se muestran en el resultado del show route receive-protocol bgp comando, mientras que las políticas de exportación se aplican a las rutas que muestra el show route advertising-protocol bgp comando.

Como se muestra en Figura 3, se utilizan políticas de enrutamiento de importación para controlar qué rutas coloca el BGP en la tabla de enrutamiento y exportar políticas de enrutamiento para controlar qué rutas anuncia el BGP desde la tabla de enrutamiento a sus vecinos.

Figura 3: Políticas de importación y exportación de enrutamientoPolíticas de importación y exportación de enrutamiento

Cuando configure una política de importación de validación de ruta, la configuración de la política utiliza una validation-database condición de coincidencia. Esta condición de coincidencia activa una consulta en la base de datos rv para el estado de validación de un prefijo en una instancia de enrutamiento dada. La operación predeterminada es consultar la base de datos de validación que coincide con la instancia de enrutamiento. Si no se encuentra ninguna instancia de validación de ruta, se consulta la instancia principal.

En la siguiente política de importación del BGP, la from validation-database condición activa una búsqueda en la base de datos rv del enrutador. Se realiza una acción si el estado de validación es válido. La acción es aceptar la ruta y establecer la validation-state en la tabla de enrutamiento en válida.

Atributo de la comunidad para anunciar el estado de validación de RPKI a los vecinos del IBGP

La validación de prefijo solo se realiza para actualizaciones de BGP externas (EBGP). En un AS, es probable que no desee que se ejecute una sesión RPKI en todos los enrutadores internos del BGP (IBGP). En su lugar, necesita una forma de llevar el estado de validación a través de la malla de IBGP para que todos los altavoces IBGP tengan información coherente. Esto se logra llevando el estado de validación en una comunidad extendida no transitiva. El atributo community anuncia y recibe el estado de validación de un prefijo entre vecinos de IBGP.

Junos OS admite las siguientes comunidades extendidas bien conocidas para la validación de rutas:

  • origen-validación-estado-válido

  • origen-validación-estado-inválido

  • origen-validación-estado-desconocido

La siguiente política de importación de BGP de ejemplo se configura en el enrutador que tiene una sesión con un servidor RPKI.

Enrutador con sesión RPKI

La siguiente política de importación de BGP de ejemplo se configura en un enrutador par IBGP que no tiene una sesión con un servidor RPKI.

Enrutador par IBGP sin sesión RPKI

Enrutamiento activo sin interrupción y validación de origen

Cuando configure la validación de origen en un enrutador que tenga motores de enrutamiento duales y el enrutamiento activo sin interrupción está habilitado, los motores de enrutamiento principal y en espera tienen una copia de la base de datos rv. Estas dos bases de datos de RV permanecen sincronizadas entre sí.

El enrutador no mantiene dos sesiones idénticas con el servidor RPKI. El protocolo RPKI-RTR se ejecuta solo en el motor de enrutamiento principal. En el motor de enrutamiento en espera, la sesión del servidor de caché RPKI siempre está inactiva.

El motor de enrutamiento principal mantiene activa la base de datos de RV a través de su sesión con el servidor RPKI. Esta base de datos se replica en el motor de enrutamiento en espera. Aunque la sesión está en el motor de enrutamiento en espera, la base de datos de RV replicada contiene registros rv. Cuando el motor de enrutamiento en espera cambia y se convierte en el motor de enrutamiento principal, ya tiene una base de datos rv completamente poblada.

Para ver el contenido de las dos bases de datos, use los show validation database comandos y show validation replication database .

Marcar un intervalo de prefijo como nunca permitido

El modelo de validación de ruta tiene una deficiencia importante: Solo ofrece actualizaciones positivas. Puede declarar qué AS es el propietario legítimo de un prefijo. Sin embargo, no puede transmitir explícitamente una actualización negativa, como en: Este prefijo nunca se origina en un AS determinado. Esta funcionalidad se puede proporcionar hasta cierto punto mediante una solución alternativa del AS 0.

La implementación de Junos OS no intenta restringir sus entradas de la caché. Por ejemplo, se instala un registro de RV con AS de origen 0 y se hace coincidir con el de cualquier otro. Esto permite que una solución alternativa marque un intervalo de prefijos como nunca permitido anunciarse, ya que el AS 0 no es un AS válido. El AS en el registro de RV nunca coincide con el AS recibido del par EBGP. Por lo tanto, cualquier prefijo coincidente se marca como no válido.

Caso de uso y beneficio de validación de origen para BGP

Si un administrador de un sistema autónomo (AS) comienza a anunciar la totalidad o parte de la red asignada a otra empresa, el BGP no tiene un método integrado para reconocer el error y responder de manera que se eviten interrupciones del servicio.

Suponga, por ejemplo, que un administrador de una red de cliente anuncia por error una ruta (digamos 10.65.153.0/24) que dirige el tráfico al proveedor de servicios del cliente AS 1. Esta ruta /24 es una ruta más específica que la que usa el proveedor de contenido real (10.65.152.0/22) que dirige el tráfico al AS 2. Debido al funcionamiento de los enrutadores, la mayoría de los enrutadores seleccionan la ruta más específica y envían tráfico al AS 1 en lugar del AS 2.

El prefijo secuestrado se ve ampliamente en Internet a medida que los enrutadores de tránsito propagan la información de ruta actualizada. Las rutas no válidas se pueden distribuir ampliamente a través de Internet, ya que los enrutadores de la zona libre predeterminada (DFZ) llevan la ruta secuestrada. Con el tiempo, la ruta del AS correcta se restaura a los pares del BGP, pero, mientras tanto, se esperan interrupciones del servicio.

Dado que el BGP se basa en un modelo de confianza transitiva, la validación entre el cliente y el proveedor es importante. En el ejemplo anterior, el proveedor de servicios AS 1 no validó el anuncio defectuoso para 10.65.153.0/24. Al aceptar este anuncio y volver a anunciarlo a sus pares y proveedores, el AS 1 propagaba la ruta equivocada. Los enrutadores que recibieron esta ruta del AS 1 la seleccionaron porque era una ruta más específica. El proveedor de contenido real anunciaba 10.65.152.0/22 antes de que se produjera el error. El /24 era un anuncio más pequeño (y más específico). De acuerdo con el proceso habitual de selección de ruta del BGP, el /24 fue entonces elegido, completando efectivamente el robo.

Incluso con la detección y reacción rápidas del proveedor de contenido y la cooperación con otros proveedores, el servicio de su prefijo se puede interrumpir durante muchos minutos hasta varias horas. La duración exacta de la interrupción depende de su punto de vista en Internet. Cuando se producen este tipo de eventos, hay un renovado interés en las soluciones a esta vulnerabilidad. El BGP es fundamental para las relaciones con los proveedores y no se irá pronto. En este ejemplo, se muestra una solución que utiliza la validación de origen. Esta solución se basa en extensiones criptográficas al BGP y en un modelo de cliente-servidor distribuido que evita sobrecargar las CPU del enrutador.

La validación de origen ayuda a superar la vulnerabilidad de la confianza transitiva al permitir que un proveedor limite los anuncios que acepta de un cliente. La mecánica implica la comunicación de políticas de enrutamiento basadas en un atributo de comunidad bgp extendido.

Ejemplo: Configuración de validación de origen para BGP

En este ejemplo, se muestra cómo configurar la validación de origen entre pares del BGP garantizando que los anuncios de ruta recibidos se envían (originan) desde el sistema autónomo esperado (AS). Si se valida el AS de origen, una política puede especificar que los prefijos se anuncien.

Requisitos

En este ejemplo, se tienen los siguientes requisitos de hardware y software:

  • Servidor de caché de infraestructura de clave pública de recursos (RPKI), mediante el uso de software de terceros para autenticar prefijos BGP.

  • Junos OS versión 12.2 o posterior que se ejecuta en el dispositivo de enrutamiento que se comunica con el servidor de caché a través de una conexión TCP.

Descripción general

A veces, las rutas se anuncian involunriamente debido a un error del operador. Para evitar este problema de seguridad, puede configurar el BGP para validar el AS de origen y rechazar estos anuncios no válidos. Esta función utiliza un servidor de caché para autenticar prefijos o intervalos de prefijos.

Las siguientes instrucciones de configuración habilitan la validación del AS de origen:

En este ejemplo, se utiliza la configuración predeterminada para los parámetros de validación.

La mayoría de las instrucciones de configuración disponibles son opcionales. La configuración necesaria es la siguiente:

El [edit routing-options validation static] nivel jerárquico le permite configurar registros estáticos en un dispositivo de enrutamiento, por lo que sobrescribe los registros recibidos de un servidor de caché RPKI.

Por ejemplo:

Puede configurar una política de enrutamiento que funcione según el estado de validación de un prefijo de ruta. Puede usar un atributo de comunidad para anunciar y recibir el estado de validación de un prefijo entre pares de BGP externo (EBGP) y BGP interno (IBGP). El uso de una política de enrutamiento puede ser más conveniente en algunos enrutadores que configurar una sesión con un servidor RPKI. En este ejemplo, se muestra el uso del atributo de comunidad de estado de validación entre pares del IBGP.

Figura 4 muestra la topología de ejemplo.

Figura 4: Topología para validación de origen Topología para validación de origen

En este ejemplo, el dispositivo R0 tiene una conexión IBGP al dispositivo R1 y una conexión EBGP al dispositivo R2. El dispositivo R0 recibe registros de validación de ruta (RV) desde el servidor de caché mediante el protocolo definido en el borrador de Internet draft-ietf-sidr-rpki-rtr-19, El protocolo RPKI/enrutador para enviar los registros de RV. El protocolo rpki-enrutador se ejecuta a través de TCP. El dispositivo R0 utiliza los registros de RV para crear una base de datos de RV local. En el dispositivo R1, el estado de validación se establece en función de la comunidad del BGP denominada estado de validación, que se recibe con la ruta.

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.

Dispositivo R0

Dispositivo R1

Dispositivo R2

Configuración del dispositivo R0

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo R0:

  1. Configure las interfaces.

  2. Configure BGP.

    Aplique la send-direct política de exportación para que las rutas directas se exporten desde la tabla de enrutamiento al BGP.

    Aplique la validation política de importación para establecer los atributos de estado de validación y comunidad bgp para todas las rutas importadas (o recibidas) de los pares EBGP del dispositivo R0.

    Configure una sesión de IBGP con el dispositivo R1. Configure una sesión de EBGP con el dispositivo R2.

  3. Configure OSPF (u otro protocolo de puerta de enlace interior [IGP]) en la interfaz que se enfrenta al par IBGP y en la interfaz de circuito cerrado.

    Nota:

    Si usa la dirección de interfaz de circuito cerrado en la instrucción IBGP neighbor , debe habilitar un IGP en la interfaz de circuito cerrado. De lo contrario, no se establece la sesión del IBGP.

  4. Configure la política de enrutamiento que exporta rutas directas desde la tabla de enrutamiento al BGP.

  5. Configure la política de enrutamiento que especifica los atributos que se modificarán según el estado de validación de cada ruta BGP.

  6. Configure la sesión con el servidor de caché RPKI.

  7. Configure el número del sistema autónomo (AS).

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Configuración del dispositivo R1

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo R1:

  1. Configure las interfaces.

  2. Configure BGP.

    Aplique la validation-ibgp política de importación para establecer los atributos de estado de validación y comunidad bgp para todas las rutas recibidas de los pares de IBGP del dispositivo R1.

    Configure una sesión de IBGP con el dispositivo R0.

  3. Configure OSPF.

  4. Configure la política de enrutamiento que especifica los atributos que se modificarán según el atributo de comunidad bgp de estado de validación de las rutas BGP recibidas del dispositivo R0.

  5. Configure el número del sistema autónomo (AS).

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Configuración del dispositivo R2

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo R2:

  1. Configure las interfaces.

    Varias direcciones se configuran en la interfaz de circuito cerrado para que sirvan como rutas con fines de demostración.

  2. Configure BGP.

  3. Configure la política de enrutamiento.

  4. Configure el número del sistema autónomo (AS).

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Verificación

Confirme que la configuración funciona correctamente.

Comprobación de que los atributos modificados se muestran en las tablas de enrutamiento

Propósito

Compruebe que las rutas del BGP en los dispositivos R0 y R1 tengan los estados de validación esperados y las preferencias locales esperadas.

Acción

Desde el modo operativo, ingrese el show route comando.

Significado

Las rutas tienen los estados de validación esperados y los valores de preferencia local, según la información recibida del servidor de caché RPKI.

Uso de operaciones de seguimiento

Propósito

Configure las operaciones de seguimiento para la validación de origen y supervise los resultados de una ruta recién anunciada.

Acción
  • En el dispositivo R0, configure el rastreo.

  • En el dispositivo R2, agregue una ruta agregando otra dirección en la interfaz de circuito cerrado.

  • En el dispositivo R0, compruebe el archivo de seguimiento.

Significado

La validación de ruta funciona según lo esperado.

Visualización de información de validación

Propósito

Ejecute los distintos comandos de validación.

Acción