Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validación de origen BGP

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

La validación de origen ayuda a evitar la publicidad involuntaria de rutas. A veces, los administradores de red 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 que 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 autenticar los prefijos BGP especificados. Para autenticar un prefijo, el enrutador (altavoz BGP) consulta la base de datos de asignaciones validadas de prefijo a AS, que se descargan del servidor de caché, y se asegura de que el prefijo se originó a partir de un AS esperado.

Nota:

Cuando se habilita la autenticación RPKI, Junos OS abre el puerto TCP 2222 automáticamente 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) para el protocolo de enrutador

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

  • Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Estado de validación de origen del prefijo BGP Comunidad extendida (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 RFC 3779, Extensiones X.509 para direcciones IP e identificadores AS.

El RPKI consiste en una colecció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 memoria caché local de toda la colección de repositorios distribuidos sincronizando regularmente cada elemento de la memoria caché local con el punto de publicación del repositorio original.

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

Un registro de 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 para comprobar que un holder de bloque de dirección IP autorizó un AS para originar enrutadores 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 de RV.

El valor máximo de longitud 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 de la familia de direcciones (32 para IPv4 y 128 para IPv6). La longitud máxima define el prefijo de la dirección IP para que el AS esté autorizado para anunciar.

Por ejemplo, si el prefijo de la 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 a anunciar exactamente el prefijo especificado en el RV.

Como otro ejemplo, un 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 está representado por el número del extremo derecho del atributo AS_PATH. La validación de origen funciona mediante la comparación del AS de origen en una actualización de enrutamiento con el AS de origen autorizado publicado en los registros del RV.

Se sabe que la seguridad que ofrece solo la validación de origen es débil frente a un agresor determinado porque no hay protección frente a un atacante que suplantase al AS de origen. Dicho esto, la validación de origen proporciona una protección útil contra anuncios accidentales.

Aunque la validación de origen podría implementarse haciendo que cada enrutador participe directamente en el RPKI, esto se considera demasiado intensivo en recursos (porque se requieren muchas operaciones de criptografía de clave pública para validar los datos de RPKI), así como operacionalmente intensivo para establecer y mantener una configuración RPKI en cada enrutador. Por esta razón, un servidor de caché de RPKI independiente realiza validaciones de claves públicas y genera una base de datos validada de mapeos de prefijo a AS. La base de datos validada se descarga en un enrutador cliente a través de una conexión TCP segura. Por lo tanto, el enrutador requiere poca información sobre la infraestructura RPKI y no tiene requisitos de criptografía de clave pública, aparte de la contraseña de transporte cifrada. Posteriormente, el enrutador utiliza los datos descargados para validar las actualizaciones de rutas recibidas.

Al configurar sesiones de servidor, puede agruparlas y configurar los parámetros de sesión para cada sesión del grupo. El enrutador intenta periódicamente establecer un número máximo configurable de conexiones a los servidores de caché. Si la configuración de la conexión falla, periódicamente se realiza un nuevo intento de conexión.

Mientras tanto, después de aplicar la política de importación de validación a la sesión BGP, la validación de la ruta se realiza independientemente del estado de la sesión de caché (arriba o abajo) y de la base de datos de RV (vacía o no vacía). Si la base de datos de 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 de 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 último número de serie de la base de datos y solicita que la caché RPKI transmita todas las entradas de RV que pertenecen a esa versión de la base de datos.

Cada mensaje entrante restablece un temporizador de vivacidad para el servidor de caché RPKI. Después de aprender todas las actualizaciones, el enrutador realiza comprobaciones periódicas de vivacidad basadas en un intervalo configurable. Esto se hace enviando una unidad de datos de protocolo de consulta 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 fin de datos (EOD), que también actualiza el estado de vivacidad del servidor de caché y restablece un temporizador de duración de registro.

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

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

  • Invalid: indica que se encontró el prefijo, pero que el AS correspondiente recibido del par EBGP no es el AS que aparece en la base de datos o que la longitud del prefijo en el mensaje de actualización del BGP es mayor que la longitud máxima permitida en la base de datos.

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

  • Sin verificar: indica que el origen del prefijo no se verifica en la base de datos. Esto se debe a que la base de datos se rellenó y la validación no se requiere en la directiva de importación de BGP, aunque la validación de origen está habilitada o la validación de origen no está habilitada para los pares BGP.

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

Nota:

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

Interacción de 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 de RV que el enrutador descarga del servidor de caché RPKI. Después de llenar la base de datos de RV con registros de RV, la base de datos de RV examina la tabla de enrutamiento RIB-Local para determinar si hay algún prefijo en RIB-Local que pueda verse afectado 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 desencadena una reevaluación BGP de las políticas de importación de BGP (no de las políticas de exportación).

Figura 2 muestra el proceso.

Figura 2: BGP y validación de rutas

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

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

Figura 3: Importación y exportación de políticas de enrutamientoImportación y exportación de políticas de enrutamiento

Cuando se configura una directiva de importación de validación de ruta, la configuración de la directiva utiliza una validation-database condición de coincidencia. Esta condición de coincidencia desencadena una consulta en la base de datos de RV para el estado de validación de un prefijo en una instancia de enrutamiento determinada. La operación predeterminada es consultar la base de datos de validación que coincida 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 de BGP, la from validation-database condición desencadena una búsqueda en la base de datos de RV del enrutador. Se realiza una acción si el estado de validación es válido. La acción consiste en aceptar la ruta y establecer el valor de la validation-state tabla de enrutamiento en válido.

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

La validación del prefijo solo se realiza para actualizaciones de BGP externas (EBGP). Dentro de un AS, es probable que no desee que se ejecute ninguna sesión de RPKI en cada enrutador interno de 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 hablantes de 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 conocidas para la validación de rutas:

  • origin-validation-state-valid

  • origin-validation-state-invalid

  • origin-validation-state-unknown

La siguiente directiva 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 directiva 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 interrupciones y validación de origen

Cuando se configura la validación de origen en un enrutador que tiene dos motores de enrutamiento y se habilita el enrutamiento activo sin interrupciones , tanto el motor de enrutamiento principal como el motor de enrutamiento en espera tienen una copia de la base de datos de RV. Estas dos bases de datos de RV permanecen sincronizadas entre sí.

El router no mantiene dos sesiones idénticas con el servidor RPKI. El protocolo RPKI-RTR solo se ejecuta 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 activamente 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á inactiva en el motor de enrutamiento en espera, la base de datos de RV replicada contiene registros de RV. Cuando el motor de enrutamiento en espera cambia y se convierte en el motor de enrutamiento principal, ya tiene una base de datos de RV completamente llena.

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

Marcar un intervalo de prefijos como nunca permitido

El modelo de validación de rutas tiene una deficiencia importante: Solo proporciona actualizaciones positivas. Puede anunciar cuál 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 originó en un AS dado. Esta funcionalidad se puede proporcionar hasta cierto punto mediante una solución alternativa de AS 0.

La implementación de Junos OS no intenta restringir sus entradas desde la memoria caché. Por ejemplo, un registro del RV con un AS de origen 0 se instala y se hace coincidir al igual que cualquier otro. Esto habilita una solución para marcar un intervalo de prefijos como jamás autorizados para anunciarse porque el AS 0 no es válido. El AS en el registro del 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 la 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 de otra empresa, BGP no tiene ningún método integrado para reconocer el error y responder de una manera que evite interrupciones del servicio.

Supongamos, por ejemplo, que un administrador de una red de clientes anuncia por error una ruta (digamos 10.65.153.0/24) que dirige el tráfico al AS 1 del proveedor de servicios del cliente. Esta ruta /24 es una ruta más específica que la utilizada por el proveedor de contenido real (10.65.152.0/22) que dirige el tráfico al AS 2. Debido a la forma en que funcionan 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 franca predeterminada (DFZ) llevan la ruta secuestrada. A la larga se restaura la ruta del AS correcta a los pares del BGP, pero, mientras tanto, se esperan interrupciones del servicio.

Dado que BGP se basa en un modelo de confianza transitivo, la validación entre el cliente y el proveedor es importante. En el ejemplo anterior, el operador de telecomunicaciones del AS 1 no validó el anuncio defectuoso para 10.65.153.0/24. Mediante la aceptación de este anuncio y el volver a anunciarlo a sus pares y proveedores, el AS 1 propagaba la ruta equivocada. Los enrutadores que recibieron esta ruta del AS 1 lo seleccionaron porque era una ruta más específica. El proveedor de contenido real estaba anunciando 10.65.152.0/22 antes de que ocurriera 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 BGP, se eligió el /24, completando efectivamente el secuestro.

Incluso con la detección y reacción rápidas del proveedor de contenido y la cooperación con otros proveedores, el servicio para su prefijo puede interrumpirse durante muchos minutos hasta varias horas. La duración exacta de la interrupción depende de su punto de vista en Internet. Cuando ocurren este tipo de eventos, hay un renovado interés en las soluciones a esta vulnerabilidad. BGP es fundamental para las relaciones con los proveedores y no desaparecerá pronto. En este ejemplo se muestra una solución que usa la validación de origen. Esta solución se basa en extensiones criptográficas para BGP y un modelo 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 la validación de origen para BGP

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

Requisitos

Este ejemplo tiene los siguientes requisitos de hardware y software:

  • Servidor de caché de infraestructura de clave pública de recursos (RPKI), que utiliza software de terceros para autenticar los prefijos BGP.

  • Junos OS versión 12.2 o posterior ejecutándose 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 involuntariamente 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 característica utiliza un servidor de caché para autenticar prefijos o rangos de prefijos.

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

En este ejemplo se usa la configuración predeterminada de 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 de jerarquía le permite configurar registros estáticos en un dispositivo de enrutamiento, sobrescribiendo así los registros recibidos de un servidor de caché RPKI.

Por ejemplo:

Puede configurar una directiva de enrutamiento que funcione en función del estado de validación de un prefijo de ruta. Puede utilizar un atributo community para anunciar y recibir el estado de validación de un prefijo entre pares BGP externos (EBGP) y BGP internos (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 validation-state community entre pares de IBGP.

Figura 4 muestra la topología de ejemplo.

Figura 4: Topología para validación de origenTopologí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) del servidor de caché mediante el protocolo definido en el borrador de Internet draft-ietf-sidr-rpki-rtr-19, The RPKI/Router Protocol para enviar los registros de RV. El protocolo RPKI-Router se ejecuta sobre 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 BGP denominada validation-state, 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] jerarquía.

Dispositivo R0

Dispositivo R1

Dispositivo R2

Configuración del dispositivo R0

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de 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 a BGP.

    Aplique la validation política de importación para establecer el estado de validación y los atributos de comunidad BGP para todas las rutas importadas (o recibidas) desde 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 orientada al par del IBGP y en la interfaz de circuito cerrado.

    Nota:

    Si utiliza la dirección de interfaz de circuito cerrado en la instrucción IBGP neighbor , debe habilitar una IGP en la interfaz de circuito cerrado. De lo contrario, la sesión de IBGP no está establecida.

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

  5. Configure la política de enrutamiento que especifica los atributos que se van a modificar en función del estado de validación de cada ruta BGP.

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

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

Resultados

Desde el modo de configuración, ingrese los comandos show interfaces, show protocols, show policy-options y show routing-options para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Configuración del dispositivo R1

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de 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 el estado de validación y los atributos de 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 directiva de enrutamiento que especifica los atributos que se van a modificar en función del atributo de comunidad BGP de estado de validación de las rutas BGP recibidas del dispositivo R0.

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

Resultados

Desde el modo de configuración, ingrese los comandos show interfaces, show protocols, show policy-options y show routing-options para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Configuración del dispositivo R2

Procedimiento paso a paso

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

Para configurar el dispositivo R2:

  1. Configure las interfaces.

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

  2. Configure BGP.

  3. Configure la directiva de enrutamiento.

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

Resultados

Desde el modo de configuración, ingrese los comandos show interfaces, show protocols, show policy-options y show routing-options para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Verificación

Confirme que la configuración funcione correctamente.

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

Propósito

Compruebe que las rutas 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 comando show route.

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 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 seguimiento.

  • 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 como se esperaba.

Visualización de la información de validación

Propósito

Ejecute los distintos comandos de validación.

Acción