1. Le protocole ICMP

Tout d'abord, une première question, le protocole ICMP est-il un protocole de niveau 3 (couche réseau) ou bien de niveau 4 (couche session) ?

Tout dépend de la sensibilité de la personne mais aussi des messages ICMP considérés :

  • le protocole ICMP est le protocole de signalisation du protocole IP, à ce titre, il fait partie de la couche IP et c'est donc un protocole de niveau 3 ;
  • le contenu des messages ICMP contient aussi bien des informations de niveau 3 (network unreachable) ou des informations de niveau 4 (service unavailable). À ce titre, il peut être considéré comme niveau 3 ou niveau 4 suivant les informations transportées ;
  • le protocole ICMP est porté par le protocole IP. À ce titre, si on se réfère l'encapsulation des trames définie par le modèle OSI, il doit être considéré comme un protocole de niveau 4.

Comme on peut le voir, la position du protocole ICMP dans la pile de protocoles OSI est une histoire de point de vue. Personnellement, j'ai tendance à le considérer comme un protocole de niveau 4.

Le protocole ICMP est défini par la RFC 792 qui a rendu obsolète la RFC 777.

De même que l'IPv4 définit son protocole ICMP, l'IPv6, définit aussi un protocole ICMP appelé ICMPv6. La RFC qui définit ICMPv6 est la RFC 4443 qui a rendu obsolète la RFC 2463 et la RFC 1885.

Ce document ne traite que du protocole ICMP dans sa version 4.

1.1. Format d'une trame

Le format général d'un paquet ICMP est le suivant :

 
Sélectionnez

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Data                                                     |
   |...                                                            |
   |...                                                            |
   +---------------------------------------------------------------+

Les différents champs que l'on peut trouver sont les suivants :

  • le champ "Type" correspond au type de message ICMP. Nous verrons plus loin les différents types de messages ICMP ;
  • le champ "Code" sert à affiner le type du message ICMP. Nous verrons plus loin les différents codes ICMP en fonction des différents types de messages ICMP ;
  • le champ "Checksum" est la somme de contrôle. Ce champ est le complément à 1 sur 16 bits de la somme des compléments à 1 des octets de la trame ICMP en commençant par le champ Type ICMP. Lors du calcul de ce champ, celui-ci est initialisé à zéro. Cet algorithme peut être remplacé dans le futur. Il est défini dans la RFC 1071 ;
  • le champ "Data" contient les données du message ICMP. L'interprétation de son contenu doit se faire en fonction du type de message ICMP.

1.2. Les types de messages ICMP

Comme on a commencé à le voir dans le paragraphe précédent, il existe plusieurs types de messages ICMP. La RFC 792 définit les types suivants :

Le type "Echo Reply" (valeur 0)

Ce message ICMP est la réponse à un message "Echo". C'est ce message qui est analysé par l'utilitaire "ping" pour connaitre le délai d'acheminement.

Le type "Destination Unreachable" (valeur 3)

C'est le message le plus important dans l'analyse du diagnostic d'un problème de connexion.

Une machine tente d'ouvrir une connexion à destination d'une autre machine, la connexion échoue et la machine émettrice peut recevoir un message "Destination Unreacheable" pour l'aider à diagnostiquer la cause de cet échec de connexion.

Ce message ICMP contient des codes supplémentaires qui permettent d'affiner le diagnostic :

  • net unreachable (code 0) : ce message est envoyé par un routeur lorsqu'il ne sait pas comment router un paquet à destination d'un réseau inconnu ;
  • host unreachable (code 1) : ce message est envoyé par le dernier routeur lorsqu'il ne peut pas joindre la machine cible ;
  • protocol unreachable (code 2) : ce message est envoyé par la machine cible lorsqu'elle n'implémente pas le protocole de niveau 3 demandé dans la couche OSI ;
  • port unreachable (code 3) : ce message est envoyé par la machine cible lorsqu'elle ne dispose pas de serveur à l'écoute sur le service demandé ;
  • fragmentation needed and DF set (code 4) : ce message est envoyé par un routeur lorsqu'il doit fragmenter un paquet et que ce paquet interdit explicitement (par choix de l'émetteur) cette fragmentation. Le routeur n'a alors d'autre choix que de rejeter le paquet ;
  • source route failed (code 5) : ce message est envoyé par un routeur lorsque des options spécifiques de routage par la source sont spécifiées par l'émetteur du paquet et que ce routage spécifique et demandé échoue ;
  • destination network unknown (code 6) : ce message est envoyé par un routeur lorsqu'il ne connait pas le réseau de destination ;
  • destination host unknown (code 7) : ce message est envoyé par un routeur lorsqu'il ne connait pas la machine de destination ;
  • source host isolated (code 8) : ce message est envoyé par un routeur lorsque son filtrage lui interdit de router ce paquet ;
  • network administratively prohibited (code 9) : ce message est envoyé par un routeur lorsque le réseau de destination est administrativement interdit d'accès ;
  • host administratively prohibited (code 10) : ce message est envoyé par un routeur lorsque la machine de destination est administrativement interdite d'accès ;
  • network unreachable for TOS (code 11) : ce message est envoyé par un routeur lorsque le réseau de destination est interdit pour des raisons de qualité de service ;
  • host unreachable for TOS (code 12) : ce message est envoyé par un routeur lorsque la machine de destination est interdite pour des raisons de qualité de service ;
  • communication administratively prohibited (code 13) : ce message est envoyé par un routeur lorsque toute communication est administrativement interdite.

Le type "Source Quench" (valeur 4)

Ce message est envoyé par un routeur lorsqu'il ne dispose plus de suffisamment de ressources (mémoire, CPU) pour traiter le paquet reçu. Le paquet est simplement rejeté (pour protéger le routeur) et un message ICMP de ce type est retourné.

Le type "Redirect" (valeur 5)

Ce message ICMP est envoyé par un routeur à l'émetteur du paquet pour signaler (à titre d'information) à cet émetteur qu'il existe une meilleure route pour cette destination. Le paquet est tout de même routé par le routeur même si ce n'est pas la meilleure route.

Les codes supplémentaires retournés dans le message peuvent être :

  • Redirect Datagram for the Network (0) ;
  • Redirect Datagram for the Host (1) ;
  • Redirect Datagram for the TOS & network (2) ;
  • Redirect Datagram for the TOS & host (3).

Le type "Echo" (valeur 8)

Ce message ICMP est envoyé par un émetteur à destination d'une cible pour tester la connectivité réseau entre ces deux points. C'est ce message qui est envoyé par l'utilitaire "ping".

Le type "Router Advertisement" (valeur 9)

Il s'agit de message ICMP envoyés périodiquement par les routeurs sur leurs interfaces multicast pour annoncer l'adresse IP du routeur sur ce réseau.

Le type "Router Solicitation" (valeur 10)

Il s'agit d'un message ICMP envoyé par une machine pour solliciter les routeurs du réseau afin qu'ils répondent par un message "Router Advertisement".

Le type "Time Exceeded" (valeur 11)

Ce message est envoyé par un routeur lorsque la durée de vie d'un paquet est dépassée.

Ce message ICMP contient des code supplémentaires qui permettent d'affiner le diagnostic :

  • time to live exceeded in transit (0) : tout paquet est envoyé avec une durée de vie maximale. Si le routage fait que la durée de vie du paquet expire, le paquet est rejeté par le routeur et un paquet ICMP de ce type est renvoyé.
  • fragment reassembly time exceeded (1) : tout paquet est envoyé avec une durée de vie maximale. Si le réassemblage du paquet (qui peut être un processus très long car un paquet intermédiaire peut avoir été perdu) fait que la durée de vie du paquet expire, celui-ci est rejeté par la machine cible et un paquet ICMP de ce type est renvoyé.

Le type "Parameter Problem" (valeur 12)

Ce message ICMP est envoyé quand un paramètre dans un paquet reçu pose problème ou est invalide.

Les codes supplémentaires retournés dans le message peuvent être :

  • Pointer indicates the error (0) ;
  • Missing a required option (1) ;
  • Bad length (2).

Le type "Timestamp" (valeur 13)

Ce message ICMP permet de connaitre un peu plus précisément le délai d'acheminement entre deux machines puisque la résolution de temps utilisée est de une milliseconde.

Le type "Timestamp Reply" (valeur 14)

Ce message est la réponse ICMP à un message "Timestamp Message".

Le type "Information Request" (valeur 15)

Ce message ICMP est utilisé pour découvrir le numéro de réseau sur lequel on se situe (pour les machines qui ne sont pas configurées comme les stations diskless ou les terminaux X).

Le type "Information Reply" (valeur 16)

Ce message est la réponse ICMP au message "Information Request Message".

Les messages ICMP "Information Request Message" et "Information Reply Message" sont rendus obsolètes par l'utilisation des protocoles RARP et BOOTP.

Le type "Address Mask Request" (valeur 17)

Il s'agit d'un message ICMP envoyé par une machine pour connaitre le masque du réseau local.

Le type "Address Mask Reply" (valeur 18)

Il s'agit de la réponse ICMP au message "Address Mask Request".

2. Les programmes utilisant ICMP

Il existe différents programmes ou fonctionnalités qui tirent parti des facilités offertes par le protocole ICMP. Ces programmes sont :

  • Ping ;
  • nmap ;
  • Bing ;
  • Path MTU Discovery ;
  • Traceroute.

2.1. Le programme "ping"

Le programme "ping" est un programme qui utilise les paquets ICMP de type "Echo" et "Echo reply".

Cet utilitaire permet de savoir si une machine est présente sur le réseau en lui envoyant un paquet ICMP Echo. En recevant ce paquet, la machine répond par un paquet ICMP Echo Reply.

Si l'on ne reçoit pas de réponse, bien souvent cela signifie que la machine n'est pas présente sur le réseau (mais il peut y avoir aussi d'autres causes à cette absence de réponse).

L'utilitaire "ping" permet aussi de spécifier la taille des données ICMP que l'on va envoyer et comme il affiche le temps entre l'émission du paquet et la réponse, il est possible de déduire la bande passante entre ces deux machines.

Comme l'utilitaire "ping" affiche le nombre de paquet émis et le nombre de paquets reçus, il est aussi possible de porter un jugement sur la qualité de la ligne entre ces deux machines.

2.2. Le programme "nmap"

"nmap" est un programme de découverte et d'analyse des machines d'un réseau développé par Fyodor (alias Gordon Lyon).

Une des fonctionnalités, entre autres, de ce programme est sa faculté à découvrir les services ouverts sur une machine cible. Pour cela, il envoie une demande d'ouverture de session avec un service TCP ou UDP supposé actif sur la machine cible et si la réponse est un paquet ICMP dont le type est "Destination Unreachable" et dont le code est "port unreachable", cela signifie que ce service n'est pas actif.

2.3. Le programme "bing"

"bing" est un utilitaire qui permet de mesurer la bande passante réelle entre deux points distants d'un réseau.

Il part du principe que si l'on connait le temps de transit (et donc par conséquent la bande passante) entre la machine locale et le point A et le temps de transit entre la machine locale et le point B, il est possible de déduire la bande passante entre le point A et le point B.

"bing" mesure la bande passante réelle et pas la bande passante disponible, pour cela, il envoie des paquets ICMP "Echo" de taille différente aux deux extrémités A et B et analyse le temps transit des paquets et de leur réponse pour en déduire la bande passante.

Il semble que cet utilitaire soit un peu tombé dans les oubliettes maintenant.

2.4. Le programme "Path MTU discovery"

Le MTU, c'est-à-dire Maximum Transmission Unit, est la taille maximale que peut avoir un paquet entre deux points d'un réseau. Si un paquet plus grand que cette taille doit être envoyé, il doit alors être fractionné en plusieurs plus petits paquets.

"Path MTU discovery" est un programme qui recherche le plus petit MTU entre la machine locale et une destination quelconque. Le but de cette découverte est d'envoyer des paquets qui ne dépassent pas cette taille afin d'éviter le processus toujours long et couteux de fragmentation et défragmentation de paquets.

Pour cela, le programme envoie un paquet d'une taille arbitraire en positionnant le bit DF (Don't Fragment) dans l'entête IP et analyse une éventuelle réponse. Si cette réponse est un paquet ICMP "Destination Unreachable" dont le code vaut 4 (pour "fragmentation needed and DF set"), cela signifie que la taille initiale du paquet nécessite une fragmentation et donc que le MTU du chemin complet est plus petit.

En itérant ainsi plusieurs fois ou alors par dichotomie, il est possible de connaitre le plus petit MTU sur le chemin.

2.5. Le programme "traceroute"

"traceroute" est un programme qui permet de connaitre la liste des différents routeurs empruntés entre la machine locale et une destination quelconque.

Pour cela, le programme envoie un paquet TCP ou UDP ou ICMP avec un TTL (Time To Live) au niveau IP qui commence à 1 et qui est incrémenté jusqu'à ce que l'on atteigne la destination (bien souvent limité à 30 sauts au maximum).

En effet, lorsqu'un paquet est traité par un routeur, le TTL de ce paquet est diminué de 1. Lorsque ce TTL arrive à 0, le routeur retourne à l'émetteur un paquet ICMP dont le type est "Time Exceeded". En analysant la réponse reçue, on en déduit l'adresse IP du routeur qui a envoyé ce paquet.

En itérant successivement le processus, il est ainsi possible de connaitre la liste des routeurs empruntés.

3. Les faiblesses d'ICMP

ICMP est un protocole qui a été inventé il y a de nombreuses années avec la genèse d'IP dans un contexte technique et un besoin de sécurité très différent de celui d'aujourd'hui.

3.1. Les failles introduites par ICMP

ICMP est un protocole qui peut aussi apporter des failles, je parle ici de failles du protocole, pas de son implémentation.

Ces failles ont été décrites par le professeur argentin Fernando Gont :

  • la faille "Hard ICMP Errors" qui donne la possibilité de fermer une connexion TCP ;
  • la faille "Source Quenching" qui peut faire ralentir le débit d'une connexion ;
  • la faille "Path MTU Discovery" qui peut faire passer la taille des paquets à 68 octets, ce qui ralentit également une connexion.

3.2. ICMP et les firewall

En général, ICMP est un protocole qui ne franchit pas les firewall car il permet de donner énormément d'information à un agresseur externe. C'est pour cela que la plupart des firewall maintenant refusent de générer des paquets ICMP.

Il est ainsi bien souvent impossible de "pinguer" un firewall, il n'y aura pas de réponse.

Si on fait une commande "traceroute" au travers d'un firewall, bien souvent la seule réponse obtenue pour ce point du réseau est une absence de réponse.

D'ailleurs maintenant, en général, les firewall pour se cacher sur le réseau ne diminuent plus le TTL d'un paquet IP afin de ne pas montrer leurs présence.

3.3. ICMP et la translation d'adresse

Dans la plupart des paquets ICMP, dans les données, on retrouve l'entête IP du paquet initial qui a généré le problème et nécessité l'envoi d'un paquet ICMP.

Dans le cas de translation d'adresse (NAT), cet entête IP du paquet initial n'est absolument pas modifié par l'équipement de translation en retour et cela peut donner :

  • soit des données très difficiles à comprendre et à analyser ;
  • soit une mine d'informations pour un agresseur potentiel externe. En effet, il est possible de deviner le plan d'adressage interne derrière le mécanisme de translation d'adresse.

4. Conclusions

Voilà, ce rapide tour d'horizon du protocole ICMP est maintenant terminé et j'espère qu'il aura permis de démystifier un peu les mécanismes mis en place autour du protocole IP pour aider à diagnostiquer les problèmes.

N'hésitez pas à apporter votre pierre à l'édifice en apportant vos remarques et commentaires dans la discussion prévue à cet effet : 2 commentaires

4.1. Remerciements

Je tiens à remercier jacques_jean et Djug pour l'aide qu'ils m'ont apportée lors de la relecture de ce document.