Cadena de clave de autenticación BGP frente a clave de autenticación


7

Encontré un pequeño comportamiento en una caja de enebro con la que estaba trabajando hoy.

Estábamos migrando de un Cisco ASR a un MX y todos nuestros pares de intercambio de Internet que tenían configurada la autenticación no aparecieron. Recibimos mensajes de registro en el MX480 que implicaban que nuestra autenticación local no estaba configurada, aunque lo estaba. (Consulte la siguiente configuración labbed)

group R01-DSN-PEERS {
    type external;
    authentication-algorithm md5;
    authentication-key-chain STUPID;
    neighbor 192.168.100.1 {
        peer-as 6996;
    }
}

key-chain STUPID {
    key 0 {
        secret "$9$uEns1crM8xbY45Qt0O1cS"; ## SECRET-DATA
        start-time "2015-1-1.01:01:00 +0000";
    }
}

El lado opuesto, descubrí que se parecía a:

router bgp 6996
neighbor 192.168.100.0 password _secret_stuff_

NOTA: Sí, el vecino opuesto se configuró correctamente, esto es solo para darle una idea: el ASR previamente instalado tenía el par establecido.

Terminamos haciéndolo funcionar configurando la autenticación directamente en el vecino, sin un llavero, ver a continuación:

group R01-DSN-PEERS {
    type external;
    neighbor 192.168.100.1 {
        authentication-key "$9$041sISlWL7w2oTzpOBISy"; ## SECRET-DATA
        peer-as 6996;
    }
}

Genial, ahora lo tenemos funcionando: no teníamos ningún apego particular al uso de llaveros.

Decidí analizar completamente esto y extraer capturas de paquetes para ver cuál era la diferencia en las opciones de TCP / BGP. A continuación se presentan cada uno de los escenarios que probé (todo es Juniper, no tengo una caja de Cisco en el laboratorio):

  1. El par ingresó ESTABLECIDO:

    • cadena de clave de autenticación en el grupo BGP de ambos pares.
    • algoritmo de autenticación en el grupo BGP de ambos pares.

Al usar la cadena de clave de autenticación, etc., la captura de paquetes no me dio las opciones de autenticación de TCP que esperaría (puedo proporcionar capturas completas si es necesario):

cap-1

  1. El par ingresó ESTABLECIDO:

    • clave de autenticación en el par BGP dentro del grupo en ambos enrutadores.

Esto es lo que esperaría usando la autenticación MD5:

cap-2

Como puede ver, MD5 se llama explícitamente en la captura.

Ahora, como mencioné, no nos importa si usamos llaveros o no, fue muy curioso cuando no configuré las configuraciones, (ver más abajo): no entrarían ESTABLECIDAS aunque pareciera que deberían:

  1. Compañeros aleteados entre ACTIVE / CONNECT

    • Par 1: clave de autenticación en el par BGP dentro del grupo.
    • Par 2: cadena de clave de autenticación establecida en el par BGP dentro del grupo.
    • Par 2: algoritmo de autenticación establecido en el par BGP dentro del grupo.

Con todo, ¿qué podría explicar la diferencia en las capturas para las "mismas" opciones? Si alguien necesita información aclaratoria, házmelo saber.

Respuestas:


5

Bueno, me las arreglé para resolver esto.

La conclusión es:

  • El uso de cadenas de clave de autenticación utiliza la "Opción de autenticación mejorada de TCP"
  • El uso de la clave de autenticación utiliza la "Opción de firma TCP MD5"

De https://tools.ietf.org/html/draft-bonica-tcp-auth-06

12.4.  Backwards Compatibility

   On any particular TCP connection, use of the TCP Enhanced
   Authentication Option precludes use of the TCP MD5 Signature Option.

Simplemente no puede mezclar las dos opciones TCP diferentes.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.