Présentation du protocole de gestion des clés IKE
IKE est un protocole de gestion des clés qui crée des SAdynamiques ; il négocie les SA pour IPsec. Une configuration IKE définit les algorithmes et les clés utilisés pour établir une connexion sécurisée avec une passerelle de sécurité homologue.
IKE effectue les opérations suivantes :
Négocie et gère les paramètres IKE et IPsec
Authentifie l’échange sécurisé de clés
Fournit une authentification mutuelle par les pairs au moyen de secrets partagés (pas de mots de passe) et de clés publiques
Protection de l’identité (en mode principal)
L’IKE se produit en deux phases. Dans un premier temps, il négocie les attributs de sécurité et établit des secrets partagés pour former l’IKE SA bidirectionnel. Dans un second temps, des SA IPsec entrantes et sortantes sont établies. L’IKE SA sécurise les échanges dans un second temps. IKE génère également du matériel de clé, fournit une confidentialité persistante parfaite et échange des identités.
À partir de Junos OS version 14.2, lorsque vous effectuez une promenade SNMP de l’objet jnxIkeTunnelEntry dans la table jnxIkeTunnelTable, un message d’erreur Request failed: OID not increasing peut être généré. Ce problème se produit uniquement lorsque des associations de sécurité IKE (IKE SA) Internet Key Exchange simultanées sont créées, ce qui se produit lorsque les deux extrémités de la SA lancent des négociations IKE SA en même temps. Lorsqu’un parcours MIB SNMP est effectué pour afficher des IKE SA, l’outil snmpwalk s’attend à ce que les identificateurs d’objet (OID) soient dans l’ordre croissant. Toutefois, dans le cas de SA IKE simultanées, les OID de la table SNMP peuvent ne pas être dans l’ordre croissant. Ce comportement est dû au fait que les ID de tunnel, qui font partie des OID, sont attribués en fonction de l’initiateur de la SA IKE, qui peut se trouver d’un côté ou de l’autre du tunnel IKE.
Voici un exemple de marche MIB SNMP effectuée sur des SA IKE simultanées :
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
La comparaison d’OID échoue lorsque le chemin SNMP est l’ID de tunnel (47885 et 47392). Lors d’une exécution SNMP, il n’est pas possible de garantir que les ID de tunnel sont dans l’ordre croissant, car les tunnels peuvent être initiés d’un côté ou de l’autre.
Pour contourner ce problème, la procédure MIB walk SNMP contient une option, -Cc, permettant de désactiver la vérification de l’augmentation des OID. Voici un exemple de marche MIB effectuée sur la table jnxIkeTunnelEntry avec l’option -Cc :
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
Request failed: OID not increasing peut être généré.