Comment configurer un tunnel IPsec sur un routeur Cisco d'agence, en adressage dynamique, et sur une liaison de type RNIS

par Hervé Schauer (05/12/2000)

Contexte
Problèmes de l'authentification mutuelle
Problèmes des certificats
Problèmes des montées et descentes de tunnels IPsec
Solution pour le tunnel sur RNIS
Solution pour avoir la date et l'heure
Glossaire, Références et Remerciements


Contexte


Soit une configuration de type classique avec :

 Un site central avec une connexion permanente à l'Internet
 Des routeurs d'agences

souhaitant dialoguer de manière chiffrée avec des tunnels IPsec.



Les routeurs d'agence sont des petits routeurs de type Cisco 800 par exemple.
La connexion de ces routeurs est dynamique, au travers d'un ISP local en
RNIS. L'adressage IP de ces routeurs est aussi dynamique, c'est aussi vrai
si la connexion RNIS est remplacée par une connexion ADSL ou une connexion
câble. Le tunnel IPsec est établi sur l'interface RNIS du routeur.

Sur le routeur central, le tunnel est établi sur l'interface externe ou
sur l'interface de loopback qui peut être dans un adressage plus
stable que l'interface externe.

Problème de l'authentification mutuelle

Sur les routeurs Cisco, pour réaliser l'authentification des équipements pour monter des tunnels IPsec, il est possible d'utiliser :

 Les secrets partagés préalables (Pre-Shared-Keys) ;
 Les clés publiques (chiffrement RSA) ;
 Les certificats X.509 (signature RSA).


Les secrets partagés posent trois problèmes :

 Les secrets partagés ne permettent pas une gestion à grande échelle
     de nombreuses agences.
 L'identifiant est l'adresse IP de l'interface de connexion. Dans notre
     cas où l'adressage est dynamique, c'est inutilisable.
 Le mot de passe est en clair dans la configuration du routeur Cisco.
     La commande "show conf" permet de voir le mot de passe en clair.
     Compte-tenu de la situation en agence du routeur, c'est un risque
     inacceptable.


Les clés publiques posent également un problème d'échelle : les clés 
publiques de tous les interlocuteurs devant être fournies manuellement au
routeur, une gestion à grande échelle de nombreuses agences n'est pas 
possible.

Les certificats X.509 ne sont pas sujets aux restrictions précédentes 
car :

Ils ne sont pas liés à l'adresse IP utilisée par le routeur 
Ils sont échangés en ligne pendant la négociation IKE.


Problèmes des certificats

Les certificats X.509 posent deux problèmes :

La gestion des certificats;
La nécessité pour le routeur d'agence de connaître la date et l'heure pour vérifier le certificat du routeur central.


La gestion des certificats impose de disposer d'une autorité de certification.
Cisco propose le protocole SCEP (Simple Certificate Enrollment
Protocol), décrit sur

http://www.ieng.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm.
Le protocole SCEP impose l'utilisation d'un produit
commercial, il n'existe pas d'implémentation de référence librement
accessible, ni d'implémentation en logiciel libre.

Problèmes des montées et descentes de tunnels IPsec

La coupure de la ligne RNIS dès qu'il n'y a plus de trafic, et la
reconnections dès qu'il y a du trafic, provoquent un nombre élevé de
demandes de montées de tunnels depuis les routeurs d'agence.

Le même routeur d'agence peut redemander une ouverture de tunnel
plusieurs fois par jour avec des adresses IP différentes.
Le problème est que lorsque la ligne RNIS est raccrochée, le tunnel IPsec
n'est pas fermé proprement par IOS : il n'y a pas d'envoi de message
SA delete.
Il est donc possible que lorsque le routeur d'agence se reconnecte, le routeur
central utilise encore la SA précédente alors que le routeur d'agence
n'en a plus. Si le routeur d'agence a du trafic à envoyer, il renégocie
les SA, sinon il reçoit du trafic sans connaître le SPI
et on a l'erreur :
%CRYPTO-4-RECVD_PKT_INV_SPI

Solution pour le tunnel sur RNIS

La solution aux montées et descentes de tunnels IPsec
est de faire correspondre la durée de vie des SA au trafic
sur la ligne. Pour cela Cisco a ajouté une fonction propriétaire de
keepalive dans le protocole d'échange de clés IKE, disponible depuis
IOS 11.3(6)T ou 12.0.
crypto isakmp keepalive  

Avec les valeurs par défaut, le routeur va envoyer un keepalive
toutes les 600 secondes pour vérifier que son interlocuteur est là. Si celui-ci
ne réponds pas, il réessaye toutes les 2 secondes, 5 fois (valeurs en dur).
Cependant l'utilisation des keepalive
va garder la ligne RNIS connectée en permanence. La solution serait
alors de filtrer les keepalive, mais ceux-ci ne sont pas distinguables
des autres paquets IKE. Il faudrait alors enlever IKE de
l'ACL de l'interface de dialup afin que le
trafic IKE ne déclenche plus la connexion RNIS. Mais dans ce cas
on ne peut plus établir la ligne sur la réception de trafic à chiffrer.

La solution est de filtrer sur l'adresse source. Lorsque IKE est le
premier paquet, l'interface externe du routeur n'a pas encore d'adresse
IP, et donc l'adresse IP source est "0.0.0.0". Il suffit d'autoriser
dans l'ACL de l'interface de dialup le protocole IKE, mais uniquement
depuis l'adresse source "0.0.0.0". Le trafic IKE dû aux
keepalive par la suite ayant comme adresse source l'adresse de
l'interface, il ne provoquera pas la connexion RNIS si celle-ci est
déconnectée.
interface bri0
    ip address negotiated
    dialer-group 1
!
dialer-list 1 protocol ip list 100
!
access-list 100 permit udp host 0.0.0.0 eq isakmp
access-list 100 permit udp host 192.70.106.165 eq isakmp
access-list 100 permit esp any host 192.70.106.165


Solution pour avoir la date et l'heure

La nécessité de connaître la date et l'heure pour vérifier les certificats
est un problème, car, par souci de rentabilité extrême sur les routeurs
d'entrée de gamme de Cisco, ceux-ci sont dépourvus d'horloge. Lorsque l'on
redémarre le routeur, sa date est le 1er janvier 1993. Il refusera de valider
les certificats émis en l'an 2000... La solution est d'apporter de
l'extérieur l'heure sur le routeur. Cela est possible avec une horloge externe
par l'interface série, mais c'est très coûteux.
interface aux 0
    ntp ref-clock

C'est aussi possible avec NTP.
Pour mettre le routeur à l'heure avec NTP il suffit de configurer NTP
et d'interdire le chiffrement du trafic NTP. NTP n'a pas besoin d'être
chiffré, car il intègre son propre mécanisme d'authenticité (non-configuré
dans l'exemple).
ntp server 192.70.106.165 source bri0


Le routeur n'ayant pas d'horloge, au démarrage il peut arriver dans certaines
version qu'il refuse son propre certificat si le besoin du tunnel IPsec lance 
IKE en même temps que NTP, avant d'avoir la date juste.
La solution est de systématiquement récupérer son certificat auprès de
l'autorité de certification. Cela permet aussi d'économiser l'espace
mémoire.
crypto ca certificate query
Lorsque le routeur s'allume, NTP est lancé et le routeur se met à l'heure,
le routeur récupère son certificat, et ensuite lance IKE.

Le problème est alors que NTP va faire sans arrêt du trafic et garder la ligne
RNIS connectée.

Au démarrage du routeur, le trafic NTP n'est pas nécessairement le premier
trafic, et donc l'utilisation du filtrage sur l'adresse source 
"0.0.0.0" comme avec IKE ne marche pas. Dans ce cas la solution est 
une ACL sur le temps : si la date est inférieure au 1er Janvier 2000 on 
autorise NTP, sinon on filtre le trafic NTP.
interface bri0
    ip address negotiated
    dialer-group 1
!
dialer-list 1 protocol ip list 101
!
Time-range NTP_startup end 12:00 1 January 2000
!
access-list 101 permit udp any eq ntp host 192.70.106.165 eq ntp time-range NTP_startup
access-list 101 deny any any

Au démarrage, la date est le 1er Janvier 1993 donc NTP provoque la connexion
de la ligne RNIS, après 3 paquets NTP l'horloge du routeur est synchronisée
et l'ACL ne laisse plus passer NTP.


Glossaire, Références et Remerciements

ACL :
 Access-Control-List, liste de contrôle d'accès : ensemble de
      sélections d'adresse IP source, adresse IP destination, protocole,
      port source, et port destination, afin de sélectionner des trafics
      particuliers :"access-list" sur Cisco.
SA :
 Security Association, Association de Sécurité, voir

http://www.hsc.fr/ressources/veille/ipsec/papier/papier.html.fr#112
SPI :
 Security Parameter Index, Index des Paramètres de Sécurité, voir

http://www.hsc.fr/ressources/veille/ipsec/papier/papier.html.fr#112


Références

 IPsec : présentation technique :
     
     http://www.hsc.fr/ressources/veille/ipsec/papier/,
     Ghislaine Labouret, 12/98
 Designing Secure Networks: Dos and Don'ts,
     Cisco Networkers session 3201, 09/00


Remerciements

à Olivier Dupont de Cisco pour avoir eu l'idée de l'ACL sur le temps pour NTP
à Ghislaine Labouret, pour les tests, sa relecture et ses précieux conseils