La configuration automatique presente un certain nombre d'avantage, mais peut également conduire à une paralysie du réseau, si un équipement non autorisé répond aux Sollicitations de Routeurs (RS) émis par les équipements d'un lien. Ils vont soit créer une adresse qui n'est pas routage et si ils l'utilisent ne recevront jamais de réponse, soit prendre ce faux routeur comme routeur par défaut. Cette configuration résulte le plus souvent d'une erreur de configuration que d'une attaque. Elle n'est pas complètement nouvelle; en IPv4 le fait d'installer un faux serveur DHCP retournant des valeurs inexacte peut conduire au même résultat. Néanmoins, plusieurs techniques sont en cours de standardisation à l'IETF pour augmenter la sécurité sur le réseau. Le groupe SEND (SEcure Neighbor Discovery) a développer une solution cryptographique à base de certificats pour authentifier les deux équipements (celui qui fait la demande et le routeur qui y répond). Le groupe SAVI (Source Address Validation Improvement) travaille au niveau des équipements d'interconnexion (commutateurs) pour autoriser ou non certaines adresses.

SEND

Le protocole IPsec ne peut pas servir directement pour authentifier les communications avec un équipement qui est en train d'acquérir son adresse car il a besoin dans un premier temps de pouvoir récupérer les clés qui vont servir à l'échange. A moins de les préconfigurer, il faut un adresse IP pour cette acquisition. Le protocole SEND résout cet oxymore en se basant sur des certificats.

Rappel sur les certificats

En cryptographie, on différencie les clés symétriques qui sont connues des deux extrémités et qui servent aussi bien à chiffrer qu'à déchiffrer l'information, et les clés asymétriques, l'une des clés sert à coder l'information et l'autre à la décoder. Un équipement peut décider de garder la première secrète et de divulger la seconde. Ainsi tous les équipements la connaissant seront capable de déchiffrer le message, mais seul l'émetteur à la possibilité d'envoyer de tel message, car il est pratiquement impossible de découvrir la clé privée à partir de la clé publique. Il faut aussi que les possesseurs de la clé publique aient la garantie que celle-ci provient bien de l'émetteur, sinon une attaque Man in the Middle peut se produire. Un attaquant se faisant passer pour la source, utilise la clé publique de la source pour déchiffrer les messages et les rechiffre en utilisant ses propres clés. Pour éviter ce genre d'attaques, les autorités de certification (CA: Certification Authority) ont été définies.

Elles possèdent des clés publiques connues du tous (par exemple préconfigurées dans les navigateurs). Quand une machine ou un site produit une clé publique, celle-ci va être signée par l'autorité de certification en utilisant sa clé privée (en fait, la signature consiste a faire à hash des données contenant la clé publique à authentifier puis à chiffrer le résultat). Une machine qui souhaite vérifier une clé publique, va effectuer la même opération. Elle va calculer le hash suivant le même algorithme et déchiffrer la signature en utilisant la clé publique de l'autorité de certification. Si les deux résultats coincident, la clé publique est authentifié par la CA. La chaîne de certification peut être plus complexe et hiérarchique et les certificats permettent de valider d'autres certificats.

A noter que contrairement à la création d'un certificat qui demande une communication avec le CA, la vérification d'un certificat peut se faire hors-ligne puisque la clé publique du CA est déjà préconfigurée dans l'équipement. De plus, le transport d'un certificat peut se faire de manière ouverte (sans chiffrement) puisque la signature protège contre tout risque de modification des données.

La norme X.509 définit le format des certificats

SAVI