1 – Définition du protocole ICMP

Le protocole ICMP (Internet Control Message Protocol) permet de gérer les informations relatives aux erreurs du protocole IP. Il ne permet pas de corriger ces erreurs, mais d’en informer les différents émetteurs des Datagrammes en erreurs. Chaque pile IP, que ce soit des routeurs ou des stations de travail, gèrent l’entête ICMP par défaut.

Ce protocole est considéré comme faisant partie de l’ensemble des protocoles TCP/IP. Cependant, contrairement à TCP et UDP, il se situe en couche 3 et donc, il est encapsulé dans IP. Le mot « Encapsulation » relate clairement la confusion du placement d’ICMP dans les 7 couches OSI.

Les messages d’erreur ICMP sont transportés sur le réseau sous forme de Datagramme, comme n’importe quelle donnée. Ainsi, les messages d’erreurs peuvent eux-mêmes être sujet aux erreurs. Toutefois, en cas d’erreur sur un message ICMP, aucune trame d’erreur n’est délivrée pour éviter un effet « boule de neige ».

Vous trouverez tous les détails du protocole ICMP dans la RFC 792.

2 – Structure de l’entête ICMP

Voici la structure de l’entête ICMP basé sur 8 octets.

Les deux champs Identifiant et Numéro de séquence ne sont présent que dans le cas d’un paquet de type Ping sinon les champs reste présent mais en tant que bourrage et donc non utilisés.

3 – Définition des différents champs

3.1 – Type et Code

Les champs Type et Code sont codés respectivement sur 8 bits ce qui donne un totale de 2 octets. Ils représentent la définition de message d’erreur contenu. Voici la liste des principales combinaison entre les champs Type et Code :

• type=00 et code=00 : Réponse à une demande d’écho
• type=03 et code=00 : Réseau inaccessible
• type=03 et code=01 : Hôte inaccessible
• type=03 et code=02 : Protocole inaccessible
• type=03 et code=03 : Port inaccessible
• type=03 et code=04 : Fragmentation nécessaire mais interdite
• type=03 et code=05 : Echec de routage par la source
• type=03 et code=06 : Réseau de destination inconnu
• type=03 et code=07 : Hôte de destination inconnue
• type=03 et code=08 : Machine source isolée
• type=03 et code=09 : Réseau de destination interdit administrativement
• type=03 et code=10 : Hôte de destination interdite administrativement
• type=03 et code=11 : Réseau inaccessible pour ce type de service
• type=03 et code=12 : Hôte inaccessible pour ce type de service
• type=03 et code=13 : Communication interdite par un filtre
• type=03 et code=14 : Host Precedence Violation
• type=03 et code=15 : Precedence cutoff in efect
• type=04 et code=00 : Volume de donnée trop importante
• type=05 et code=00 : Redirection pour un hôte
• type=05 et code=01 : Redirection pour un hôte et pour un service donné
• type=05 et code=02 : Redirection pour un réseau
• type=05 et code=03 : Redirection pour un réseau et pour un service donné
• type=08 et code=00 : Demande d’écho
• type=09 et code=00 : Avertissement routeur
• type=10 et code=00 : Sollicitation routeur
• type=11 et code=00 : Durée de vie écoulée avant d’arrivée à destination
• type=11 et code=01 : Temps limite de réassemblage du fragment dépassé
• type=12 et code=00 : Entête IP invalide
• type=12 et code=01 : Manque d’une option obligatoire
• type=12 et code=02 : Mauvaise longueur
• type=13 et code=00 : Requête pour un marqueur temporel
• type=14 et code=00 : Réponse pour un marqueur temporel
• type=15 et code=00 : Demande d’adresse réseau
• type=16 et code=00 : Réponse d’adresse réseau
• type=17 et code=00 : Demande de masque de sous réseau
• type=18 et code=00 : Réponse de masque de sous réseau

3.1.1 – Type=0,8 – Le Ping

Le principe du Ping étant, à la base, de valider la présence d’un Hote IP. Pour cela, l’application Ping utilisera la séquence 8-0 afin d’émettre une demande d’écho. Les données reçues dans un message d’écho doivent être réémises dans la réponse. Ainsi, si le message de retour correspond à l’émission, on en déduit que l’Hote est présent. De plus, on peux en déduire d’autres services, tel que le temps de réponse, la taille paquet maximum la durée de vie et etc.

L’ identificateur et le numéro de séquence peuvent être utilisés par l’émetteur du message d’écho afin d’associer facilement l’écho et sa réponse. Par exemple, l’identificateur peut être utilisé comme l’est un port pour TCP ou UDP, identifiant ainsi une session. Et le numéro de séquence peut être incrémenté pour chaque message d’écho envoyé. L’hôte de destination respectera ces deux valeurs pour le retour.

3.1.2 – Type=3 – Destination non valide

Ce type de message est émis dans le cas où un routeur ou un hôte ne puisse pas router un paquet.

3.1.3 – Type=4 – Volume de donnée trop importante

Un routeur ou hôte peut être amené à détruire un Datagramme s’il manque de mémoire pour bufferiser. Dans ce cas, le routeur émettra un message à destination de la source du Datagramme détruit, un paquet ICMP de type 4.

Cela peut ce produire dans un second cas. Quand le Datagramme arrive trop rapidement pour qu’il puisse être traité le message ICMP peut donc constituer une demande de diminution de débit de transfert.

3.1.4 – Type=5 – Redirection

Ces types de messages sont émis afin d’indiquer que le chemin emprunté n’est pas le bon pour la destination demandé. La réception de ce type de message d’erreur peut être interprétée par la modification de la table de routage locale. C’est plus communément appelé « ICMP Redirect ».

3.1.5 – Type=9,10 – découverte de routeur

Au démarrage d’une station, plutôt que de configurer manuellement les routes statiques, surtout si elle sont susceptibles de changer et que le nombre de stations est grands, il peut être intéressant de faire de la découverte automatique de routeurs. Pour cela, il y a deux possibilités. La première est l’envoi régulier de messages ICMP de type 9 « Avertissement routeur » d’annonces de routes par les routeurs. La seconde possibilité est qu’une station sollicite les routeurs avec un message de type 10 « Sollicitation routeur ».

La découverte de routeur n’est pas un protocole de routage, son objectif est bien moins ambitieux , juste obtenir une route par défaut. 

Vous trouverez tous les détails du « découverte de routeur » dans la RFC 1256.

3.1.6 – Type=11 – Temps excédé

Lorsqu’un routeur traitant un Datagramme est amené à mettre à jour le champ Durée de Vie de l’entête IP et que ce champ atteint une valeur zéro, le Datagramme sera détruit. Le routeur peut alors envoyer un message d’erreur « Time To Live expiré ». Ce message ICMP peux être émis aussi dans le cas où le temps de réassemblage expire et le Datagramme ne peux donc être reconstitué à temps.

3.1.7 – Type=12 – Erreur d’entête

Si un routeur rencontre un problème avec un paramètre d’entête IP l’empêchant de finir son traitement, le datagramme sera alors détruit. Un message d’erreur de type 12 sera donc alors émis.

3.1.8 – Type=13,14 – Marqueur temporel

Le but de ce type de message est de s’échanger des données temporelles pour, par exemple, synchroniser les horloges.

3.1.9 – Type=15,16,17,18 – Demande d’information

Ce type de message est envoyé vers une adresse constituée du numéro de réseau dans le champ source de l’entête IP et un champ destinataire à 0. La pile IP qui répondra pourra alors envoyer une réponse avec les adresses entièrement renseignées.

3.2 – Checksum

Le champ Checksum est codé sur 16 bits et représente la validité du paquet de la couche 3 ICMP. Pour pouvoir calculer le Checksum, il faut positionner le champ du checksum a 0. Ce calcul est strictement le même que celui du protocole IGMP.

Voici un exemple de fonction permettant le calcul du checksum ICMP.

unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
     {
     unsigned long checksum=0;
     // ********************************************************
     // Complément à 1 de la somme des complément à 1 sur 16 bits
     // ********************************************************
     while(taille>1)
         {
         if (liberation==TRUE)
             liberation_du_jeton(); // Rend la main à la fenêtre principale
         checksum=checksum+*data++;
         taille=taille-sizeof(unsigned short);
         }
 
     if(taille)
         checksum=checksum+*(unsigned char*)data;
 
     checksum=(checksum>>16)+(checksum&0xffff);
     checksum=checksum+(checksum>>16);
 
     return (unsigned short)(~checksum);
     }
 
 unsigned short calcul_du_checksum_icmp(bool liberation, struct icmp icmp_tampon,char data_tampon[65535])
       {
       char tampon[65535];
       unsigned short checksum;
 
       // ********************************************************
       // Initialisation du checksum
       // ********************************************************
       icmp_tampon.checksum=0; // Doit être à 0 pour le calcul
 
       // ********************************************************
       // Calcul du ICMP
       // ********************************************************
       memcpy(tampon,(unsigned short *)&icmp_tampon,sizeof(struct icmp));
       memcpy(tampon+sizeof(struct icmp),data_tampon,strlen(data_tampon));
       checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(struct icmp)+strlen(data_tampon));
 
       return(checksum);
       }

3.3 – Identifiant

Le champ identifiant est codé sur 16 bits et définit l’identifiant de l’émetteur. Pour cela, il est conseillé d’assigner le numéro du processus assigné (PID) à l’application lors de l’exécution. Cela permet de le rendre unique inter application. Cela ressemble beaucoup aux numéros de port pour les protocole TCP et UDP.

3.4 – Numéro de séquence

Le champ Séquence est codé sur 16 bits et permet au récepteur, d’identifier si il manque un paquet. Le plus classique étant une incrémentation linéaire de 1. Ainsi, si le récepteur reçoit la séquence 1 puis 3, il peut en déterminer une perte d’un paquet. Néanmoins, ce n’est pas normalisé, donc personne n’à la garantie que l’émetteur utilisera cette méthode. Cela peut aussi permettre à l’émetteur d’envoyer multiples paquets et de pouvoir distinguer les retours.

4 – Les vidéos

• 4.1 - What is ICMP ?

  Cette video en anglais vous présente le protocole ICMP (Internet Control Message Protocol). The core internet protocol suite (IP, TCP, and UDP) is primarily concerned with moving data between computers on the internet. But it also includes another protocol that is entirely dedicated to control traffic: the Internet Control Message Protocol (ICMP). Despite the fact that ICMP is not concerned with carrying data, it does enable several tools that we can use to find out more about the internet’s structure.

  

• 4.2 - UDP and ICMP with Wireshark

  Cette video en anglais vous présente les protocoles UDP (User Datagram Protocol) et ICMP (Internet Control Message Protocol) dans Wireshark. UDP stands for User Datagram Protocol. This is another layer 4 protocol, commonly called a 'connectionless protocol', that is used on lots of modern networks to make the transmission of data fast! The weird thing about UDP is it doesn't have a start handshake and a cutoff process like with TCP. Since UDP doesn't have the whole packet handshake that TCP does, you'd think that it wouldn't work right, but it actually HELPS other protocols streamline data in a fast pace. A UDP header packet is super small and only has four parts. First you have the Bit Offset, the source port / destination port, the packet length, and the checksum.. The source and destination are self-explanatory. The packet length is in bytes and the checksum ensures the data is intact when it arrives. Next we have ICMP. This stands for the Internet Control Message Protocol. This protocol works with TCP/IP, and tells you if a device, service or route is available on a TCP/IP network. ICMP packet headers have a Type, a Code, a Checksum, and a Variable. The Type is the type of ICMP message based on RFC code. The Code is the subclass of ICMP message, also part of the RFC code. Checksum makes sure the content is intact, and Variable is a bit that changes depending on the type and code. This IANA website shows you all the known types and codes you might run into when dealing with an ICMP packet. If there is a problem with a connection, it may have to do with this packet. Using the Type and the Code, you can determine what went wrong and where. I also wanted to mention a bit about why ICMP exists for other reasons. First, it's great for the ping utility. In command prompt, type ping 10.71.31.1 (your target) to see an echo/ping request and response. You can also see what happens when you run Ping and check it in Wireshark. ICMP packets are also a part of trace routing. Trace routing is when you ID the path that some data takes from one device to another. It'll tell you how many routers it had to go through to get to it's destination. If you find an ICMP packet that has a TTL value is set to 1 (that's time to live), that means it only had to travel through one router. In a traceroute, the packet will return to the original source with a type of 11 and a code of 0. This means the destination was unreachable due to the TTL being exceeded during transit. You might find some people call this a double-headed packet because there is an extra IP header inside it. This data is from the original echo request. You'll see this pattern continue until the destination host is reached by the packet. The route can also be seen in CMD with tracert 8.8.8.8. Let me know what you think. Send me a comment below or email us at tips@hak5.org. And be sure to check out our sister show, Hak5,org for more great stuff just like this. I'll be there, reminding you to trust your technolust.

  

• 4.3 - Présentation ludique et basique du protocole ICMP

  Cette vidéo en Anglais présente basiquement et de manière ludique, le protocole ICMP (Internet Control Message Protocol).

  

• 4.4 - Protocole ICMP animée et en musique

  Vidéo présentant, de manière très dynamique, le protocole ICMP. ICMP is defined by IETF RFC792 and 950. ICMPv6 is defined by RFC 2461, 2463. Related protocol IP, TCP, IGMP, SNMP, DNS, TFTP and NFS. ICMP is a required element of IP implementations. ICMP is a control protocol, meaning that it designed to not carry application data, but rather information about the status of the network itself.

  

• 4.5 - Cours numéro 3 sur ICMP - Travaux pratiques cas 2

  Voici une vidéo présentant des cas pratiques du protocole ICMP.

  

• 4.6 - Cours numéro 3 sur ICMP - Travaux pratiques cas 1

  Voici une vidéo présentant des cas pratiques du protocole ICMP.

  

• 4.7 - Cours numéro 3 sur ICMP - Unreaschable et Redirect

  Voici une vidéo présentant le protocole ICMP et tout particulièrement les messages Unreaschable et Redirect.

• 4.8 - Cours numéro 2 sur ICMP - Commande Traceroute

  Voici une vidéo présentant le protocole ICMP et tout particulièrement le traceroute avec le TTL (Time To Live).

  

• 4.9 - Cours numéro 1 sur ICMP - Commande Ping

  Voici une vidéo présentant le protocole ICMP et tout particulièrement le ping en echo reply.

  

• 4.10 - Protocole ICMP et Ping

  Présentation du protocole ICMP et des ses champs associés. Le cas concret du ping en echo request sera plus spécifiquement détaillé.

  

• 4.11 - Introduction to ICMP redirection

  Vidéo expliquant en anglais le fonctionnement spécifique de ICMPredirect.

  

5 – Suivi du document

Création et suivi de la documentation par _SebF

Modification de la documentation par Julien LEGRAND

• Correction du chapitre 3.1 sur le code 0 « réponse à une demande d’écho »

6 – Discussion autour de l’entête ICMP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de l’entête ICMP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :