1981 - ICMP (Internet Control Message)
Par Vincaria le jeudi 2 avril 2009, - Logiciels - Lien permanent
Dès septembre 1981, Jon
Postel publie le document RFC792
relatif au protocole ICMP
(Internet Control Message Protocol
.
Intercalé entre les documents RFC791 (Internet Protocol
) et RFC793
(Transmission Control Protocol
), il pose les bases d'un protocole
destinée au contrôle des échanges de paquets en mode commuté. Initialement, les
routeurs utilisaient le protocole GGP
(Gateway to Gateway
Protcol
) pour contrôler les flux de données transmis. Jon Postel souhaita
alors implémenter un protocole de contrôle plus simple et intégré directement
au coeur du protocole IP.
Agissant comme un protocole de niveau supérieur, ICMP est pourtant intégré au
protocole IP. Les messages ICMP sont utilisés par les équipements pour la
notification de tout erreur relatives à la gestion des flux de données. Par
ailleurs, le protocole n'est pas sûr
et ne garantit ni l'émission des
messages, ni leur réception. L'implémentation de mécanismes garantissant les
communications doit toujours être confiée aux protocoles des couches su
périeures, tels que TCP.
Le protocole ICMP diffère de ses cousins
TCP et UDP dans la mesure où
ces derniers sont utilisés pour émettre et recevoir des paquets de données
entre équipements finaux. ICMP assure quant à lui la gestion des messages
concernant deux équipements proches, comme par exemple des routeurs.
Les paquets ICMP sont encapsulés dans des paquets IP avec un entête spécifique
afin de permettre le renvoi du paquet vers l'équipement émetteur du paquet.
Lorsqu'un équipement traite un paquet IP, il décremente un champ de l'entête IP
nommé TTL
(Time To Live
). Si la valeur du champ TTL
équivaut à 0
, un message ICMP spécifique du type Time to live
exceeded in transit
est alors renvoyé à l'équipement qui a émis le paquet
lui indiquant que le paquet n'a pas pû être émis car sa durée de vie est
expirée.
Il est assez peu commun qu'une application logicielle utilise le protocole ICMP
puisqu'il est réservé au traitement des messages d'erreurs. Cependant, deux
outils bien connus des administrateurs système et réseau ont été spécifiquement
conçu dans ce cadre : il s'agit des outils nommés Ping
et
Traceroute
:
- Ping : utilisation des messages ICMP
Echo Request
etEcho Reply
- Traceroute : échange de paquets UDP et modification du champ
TTL
L'utilitaire Ping
a été développé en décembre 1983 par Mike Muuss, alors
chercheur au Laboratoire de Recherche Balistique
de l'armée américainen,
pour l'aide au diagnostic des problèmes réseau. Mike Muss l'a nommé ainsi par
analogie avec les impulsions sonores émises par les radars, dont le principe
est similaire, l'onde radar étant ici remplacée par un paquet ICMP. Le mot
Ping
est à présent aussi utilisé comme verbe (exemple: il ping mon
routeur
) mais aussi substantif (exemple: ton ping montre que le serveur
web est HS
).
Voici comment fonctionne l'outil : afin de savoir si un équipement du
réseau est joignable et si oui, pour connaitre le temps qu'il faut à un paquet
pour le joindre et revenir à la source, Ping
envoit un message ICMP du
type Echo Request
(écho demandé
) à l'équipement cible et attend
une réponse en retour du type Echo Response
(réponse à l'écho
).
L'outil mesure alors le nombre de paquets perdus et pour les paquets reçus le
temps mis par ces derniers pour faire l'aller-retour
.
Exemple d'utilisation de l'outil Ping
en émettant les messages ICMP à
destination du serveur web du MIT dont l'une
des adresses IP est 18.7.22.69 :
localhost# ping 18.7.22.69 PING 18.7.22.69 (18.7.22.69) 56(84) bytes of data. 64 bytes from 18.7.22.69: icmp_seq=1 ttl=240 time=84.1 ms 64 bytes from 18.7.22.69: icmp_seq=2 ttl=240 time=83.6 ms 64 bytes from 18.7.22.69: icmp_seq=3 ttl=240 time=82.9 ms 64 bytes from 18.7.22.69: icmp_seq=4 ttl=240 time=83.2 ms 64 bytes from 18.7.22.69: icmp_seq=5 ttl=240 time=83.1 ms --- 18.7.22.69 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4010ms rtt min/avg/max/mdev = 82.926/83.421/84.157/0.427 ms
Le résultat nous montre que :
- 5 paquets ont été émis et 5 paquets ont été reçus
- le pourcentage de paquets perdus est de 0%
- le temps total du test est de 4010 millisecondes
Par ailleurs, les temps d'aller-retour des messages ICMP sont les
suivants :
- temps aller-retour minimum : 82,926 millisecondes
- temps aller-retour moyen : 83,421 millisecondes
- temps aller-retour maximum : 84,157 millisecondes
- déviation moyenne des temps d'aller-retour : 0,427 millisecondes
L'utilitaire Traceroute
a été développé en décembre 1988 par Van
Jacobson pour l'aide au diagnostic des problèmes réseau, tout comme l'outil
Ping
. Comme ce dernier le mot Traceroute
est à présent aussi
utilisé comme verbe (exemple: il traceroute mon switch
) mais aussi
substantif (exemple: ton traceroute montre que le routage n'est pas
correct
).
L'outil permet de lister l'ensemble des équipements situés sur le réseau et qui
séparent la source et la cible. Ceci permet à l'utilisateur de connaitre sa
route
au travers du réseau et lui permet d'identifier les problématiques
de routage ou de blocage de paquets jusqu'à un site.
Voici comment fonctionne l'outil : il envoit des paquets UDP (certaines
versions utilisent des paquets TCP) en marquant le champ TTL} de leur entête
IP avec une valeur spécifique, puis attend les paquets ICMP de type {{Time to
live exceeded in transit
et Destination unreachable
qui sont émis en
retour.
En positionnant initialement la valeur TTL Time To Live
de chaque bloc
de paquets à 1
, Traceroute
force le premier équipement qui reçoit
ses paquets à renvoyer un message ICMP Time to live exceeded in transit
(puisque ce dernier décrement la valeur en traitant le bloc). Puis en
l'incrémentant successivement la valeur TTL à 2
, 3
, etc ..., il
force le 2ème équipement, puis le 3ème, etc ... à renvoyer des messages
ICMP.
Ainsi à chaque réception de message ICMP, il affiche l'équipement qui lui à
répondu et de fil en aiguille reconstitue le chemin complet des paquets jusqu'à
la cible. En mesurant le temps de chaque aller-retour, l'outil
Traceroute
peut également founir à l'utilisateur des statistiques de
latence
des équipements. Si un équipement ne répond pas dans le temps
imparti (appelé aussi Time-Out
), l'outil affiche le caractère astérisque
(*
) indiquant qu'il n'a pas de mesure.
Exemple d'utilisation de l'outil Traceroute
en émettant les messages
ICMP depuis l'Université
Carnegie Mellon à destination du serveur web du MIT dont l'une des adresses IP est
18.7.22.69 :
traceroute to 18.7.22.69 (18.7.22.69), 30 hops max, 38 byte packets 1 POD-C-CYH-VL4.GW.CMU.NET (128.2.4.48) 0.355 ms 0.994 ms 0.252 ms 2 CORE255-VL907.GW.CMU.NET (128.2.255.186) 0.337 ms 0.247 ms 0.240 ms 3 POD-I-CYH-VL987.GW.CMU.NET (128.2.255.250) 44.844 ms 199.384 ms 5.931 ms 4 bar-cmu-ge-4-0-0-2.3rox.net (192.88.115.185) 0.547 ms 14.157 ms 2.545 ms 5 leviathan-bar-te0-0-0-1-508.3rox.net (192.88.115.85) 0.903 ms 0.655 ms 0.638 ms 6 wash-psc10G.layer3.nlr.net (192.88.115.165) 7.205 ms 6.688 ms 6.473 ms 7 newy-wash-98.layer3.nlr.net (216.24.186.22) 12.449 ms 12.419 ms 11.874 ms 8 216.24.184.102 (216.24.184.102) 11.745 ms 11.703 ms 11.641 ms 9 W92-RTR-1-BACKBONE.MIT.EDU (18.168.0.25) 19.069 ms 21.824 ms 18.624 ms 10 WEB.MIT.EDU (18.7.22.69) 17.754 ms 17.227 ms 17.147 ms
Le résultat nous montre que :
- 9 équipements séparent la source et la cible
- le temps aller-retour minimum est de 17,147 millisecondes
- le temps aller-retour moyen est de 17,227 millisecondes
- le temps aller-retour maximum est de 17,754 millisecondes
Par ailleurs, les propriétaires des équipements traversés sont :
- L'Université Carnegie Mellon (cmu.net)
- L'opérateur Three Rivers Optical Exchange (3rox.net)
- L'opérateur National LambdaRail (nlr.net)
- L'Institut Technologique du Massachusetts (mit.edu)
La plupart des équipements de routage et de sécurité traitent les paquets ICMP
en priorité puisqu'ils concernent les erreurs de transmission. Ceci peut être
considéré comme un risque en terme de sécurité par certains administrateurs
puisque l'envoi de paquets ICMP en trop grand nombre peut engorger un
équipement. Il n'est donc pas rare de constater que certains équipements, même
s'ils sont bien connectés au réseau, ne répondent pas aux messages ICMP de type
Echo Request
.
Pour des raisons de sécurité, certains équipements refusent aussi de
transmettre à des équipements inconnus les messages ICMP attendus par
traceroute
. Bien que ce type de pratique soit assez critiqué, la volonté
de ne pas dévoiler à n'importe qui la topologie de son réseau l'emporte bien
souvent.