Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this document? Why not share!

Tcp ip

on

  • 5,125 views

tcpip

tcpip

Statistics

Views

Total Views
5,125
Views on SlideShare
5,125
Embed Views
0

Actions

Likes
2
Downloads
58
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tcp ip Tcp ip Document Transcript

  • Cours d’introduction ` TCP/IP a Fran¸ois Laissus c Version du 25 f´vrier 2009 e
  • ii Copyright c 1999 - 2009 — $Rev: 131 $ — Fran¸ois Laissus c Avant propos Les sources de ce document sont d´velopp´es, g´r´es et conserv´es grˆce e e ee e a aux services de FreeBSD1 , remarquable syst`me d’exploitation OpenSource ! e Les divers fichiers qui composent le source sont ´dit´s ` l’aide de l’´diteur e e a e de texte vi ; l’historique des modifications est confi´ aux bons soins de l’outil e subversion (gestionnaire de versions). L’ensemble du processus de fabrica- tion est pilot´ par une poign´e de fichiers Makefile (commande make). e e La mise en forme s’effectue grˆce au logiciel L TEX. Les figures sont des- a A sin´es sous “ X Window Systems ”(X11) ` l’aide du logiciel xfig et int´gr´es e a e e directement dans le document final sous forme de PostScript encapsul´. Les e listings des exemples de code C ont ´t´ fabriqu´s ` l’aide du logiciel a2ps et ee e a inclus dans le document final ´galement en PostScript encapsul´. e e La sortie papier a ´t´ imprim´e en PostScript sur une imprimante de type ee e laser, avec dvips. La version pdf est une transformation du format PostScript ` l’aide du logiciel dvipdfm, enfin la version HTML est traduite directement a en HTML ` partir du format L TEX ` l’aide du logiciel latex2html. a A a Tous les outils ou formats utilis´s sont en acc`s ou usage libre, c’est ` dire e e a sans versement de droit ` leurs auteurs respectifs. Qu’ils en soient remerci´s a e pour leurs contributions inestimables au monde informatique libre et ouvert ! Je remercie ´galement Jean-Jacques Dh´nin et les nombreux lecteurs e e que je ne connais qu’au travers de leur e-mails, d’avoir bien voulu prendre le temps de relire l’int´gralit´ de ce cours et de me faire part des innombrables e e erreurs et coquilles typographiques qu’il comporte, merci encore ! Ce support de cours est en consultation libre ` cette url : a HTML http://www.laissus.fr/cours/cours.html Ou ` t´l´charger au format PDF : a ee HTTP http://www.laissus.fr/cours/cours.pdf FTP ftp://ftp.laissus.fr/pub/cours/cours.pdf D’autres formats (.ps,.dvi,. . .) sont accessibles dans ce r´pertoire : e HTTP http://www.laissus.fr/pub/cours/ FTP ftp://ftp.laissus.fr/pub/cours/ 1 http://www.freebsd.org/
  • iii Copyright c 1999 - 2009 — $Rev: 131 $ — Fran¸ois Laissus cHistorique des principaux changements ` A ce jour(25/02/2009), ce document existe et est accessible sur l’Internetdepuis le milieu des ann´es 90. De tr`s nombreux internautes l’ont t´l´charg´ e e ee eet m’ont renvoy´ leurs commentaires. Il ´tait donc plus que temps de garder e eune trace des principales modifications et restructurations afin que ces lec-teurs fid`les puissent suivre les modifications et, peut ˆtre, t´l´charger une e e eenouvelle version en connaissance de cause !Version du 25 F´vrier 2009 Restructuration de l’ensemble en quatre parties princi- e pales (A,B,C, D) et un index g´n´ral. Ajout d’une partie “ R´seaux IP avanc´s ”. e e e e Ajout d’un chapitre sur SNMP et d’un chapitre sur le routage dynamique. Ajout d’un changelog, cette page. . . Le .pdf est maintenant r´actif, les urls, les renvois de pages, le sommaire, les listes e de tableaux et figures. Nombreuses corrections et mises ` jour de tous les chapitres depuis la version du a 14 octobre 2007.
  • iv
  • Table des mati`res ePr´face e xxiA Introduction ` la pile ARPA a 1I R´seaux locaux e 3 1 Pr´ambule . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . 3 2 G´n´ralit´s - LANs . . . . . . . . . . . . . . . . . e e e . . . . . . . 3 2.1 G´n´ralit´s . . . . . . . . . . . . . . . . . e e e . . . . . . . 3 2.2 Mod`le de communication OSI . . . . . . e . . . . . . . 4 3 R´seaux locaux . . . . . . . . . . . . . . . . . . . e . . . . . . . 7 3.1 Qu’est-ce qu’un LAN ? . . . . . . . . . . . . . . . . . . 7 3.2 WAN - MAN . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Communications inter-r´seaux . . . . . . . e . . . . . . . 8 4 Couche 2 - Liaison (Data Link) . . . . . . . . . . . . . . . . . 9 4.1 Caract´ristiques d’Ethernet . . . . . . . . e . . . . . . . 9 4.1.1 Quelques principes fondamentaux . . . . . . . 9 4.1.2 Format d’une “ Frame Ethernet ” . . . . . . . 10 4.1.3 Adresses IEEE 802.3 ou Ethernet . . . . . . . 11 4.1.4 Unicast, multicast et broadcast . . . . . . . . 12 4.2 Diff´rences Ethernet - 802.2/802.3 . . . . . e . . . . . . . 13 5 Interconnexion - Technologie ´l´mentaire . . . . . ee . . . . . . . 14 5.1 Raccordement . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1 10Base5 . . . . . . . . . . . . . . . . . . . . . 15 5.1.2 10Base2 . . . . . . . . . . . . . . . . . . . . . 15 5.1.3 10BaseT . . . . . . . . . . . . . . . . . . . . . 16 5.1.4 Fibre optique . . . . . . . . . . . . . . . . . . 16 5.1.5 Conclusion . . . . . . . . . . . . . . . . . . . 17 5.2 R´p´teur . . . . . . . . . . . . . . . . . . . e e . . . . . . . 17 5.3 Concentrateur . . . . . . . . . . . . . . . . . . . . . . . 18 5.4 Ponts . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.5 Commutateurs . . . . . . . . . . . . . . . . . . . . . . 20 5.6 Passerelles — Routeurs . . . . . . . . . . . . . . . . . . 22 6 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 23II Introduction ` IP a 25
  • vi ` TABLE DES MATIERES 1 TCP/IP et l’Internet - Un peu d’histoire . . . . . . . . . . . . 25 2 Caract´ristiques de TCP/IP . . . . . . . e . . . . . . . . . . . . 27 3 Comparaison TCP/IP — ISO . . . . . . . . . . . . . . . . . . 28 3.1 Couche “ Application Layer ” . . . . . . . . . . . . . . 29 3.2 Couche “ Transport Layer ” . . . . . . . . . . . . . . . 29 3.3 Couche “ Internet Layer ” . . . . . . . . . . . . . . . . 30 3.4 Couche “ Network Access ” . . . . . . . . . . . . . . . 30 4 Encapsulation d’IP . . . . . . . . . . . . . . . . . . . . . . . . 30 5 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 III Anatomie d’une adresse IP 33 1 Adressage IP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 1.1 Unicit´ de l’adresse . . . . . . . . . e . . . . . . . . . . . 33 1.2 D´livrance des adresses IPv4 . . . . e . . . . . . . . . . . 34 2 Anatomie d’une adresse IP . . . . . . . . . . . . . . . . . . . . 35 2.1 D´composition en classes . . . . . . e . . . . . . . . . . . 35 2.2 Adresses particuli`res . . . . . . . . e . . . . . . . . . . . 37 2.3 Sous-r´seaux . . . . . . . . . . . . . e . . . . . . . . . . . 38 2.4 CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.5 Pr´cisions sur le broadcast . . . . . e . . . . . . . . . . . 41 3 Adressage multicast . . . . . . . . . . . . . . . . . . . . . . . . 42 3.1 Adresse de groupe multicast . . . . . . . . . . . . . . . 42 3.2 Adresse multicast et adresse MAC . . . . . . . . . . . . 43 4 Conclusion et bibliographie . . . . . . . . . . . . . . . . . . . . 44 IV Protocole IP 47 1 Datagramme IP . . . . . . . . . . . . . . . . . . . . . . . . . . 47 1.1 Structure de l’en-tˆte . . . . . . . e . . . . . . . . . . . . 47 1.2 Network Byte Order . . . . . . . . . . . . . . . . . . . 48 1.3 Description de l’en-tˆte . . . . . . e . . . . . . . . . . . . 49 1.4 Fragmentation IP - MTU . . . . . . . . . . . . . . . . 52 1.4.1 Fragmentation . . . . . . . . . . . . . . . . . 52 1.4.2 R´assemblage . . . . . . e . . . . . . . . . . . . 53 2 Protocole ARP . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.1 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . 55 2.2 Format du datagramme . . . . . . . . . . . . . . . . . 57 2.3 Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 58 3 Protocole RARP . . . . . . . . . . . . . . . . . . . . . . . . . 58 4 Protocole ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.1 Le syst`me de messages d’erreur . e . . . . . . . . . . . . 59 4.2 Format des messages ICMP . . . . . . . . . . . . . . . 60 4.3 Quelques types de messages ICMP . . . . . . . . . . . . 61 5 Protocole IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.1 Description de l’en-tˆte . . . . . . e . . . . . . . . . . . . 63 5.2 Fonctionnement du protocole . . . . . . . . . . . . . . 64
  • `TABLE DES MATIERES vii 5.3 Fonctionnement du Mbone . . . . . . . . . . . . . . . . 65 6 Routage IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1 Table de routage . . . . . . . . . . . . . . . . . . . . . 67 6.2 Routage statique . . . . . . . . . . . . . . . . . . . . . 69 6.2.1 Algorithme de routage . . . . . . . . . . . . . 70 6.3 Routage dynamique . . . . . . . . . . . . . . . . . . . . 71 6.3.1 RIP — “ Routing Information Protocol ” . . 72 6.3.2 OSPF — “ Open Shortest Path First ” . . . . 73 6.4 D´couverte de routeur et propagation de routes . . e . . 73 6.5 Message ICMP “ redirect ” . . . . . . . . . . . . . . . 74 6.6 Interface de “ loopback ” . . . . . . . . . . . . . . . . 75 7 Finalement, comment ¸a marche ? . . . . . . . . . . . . . . c . . 76 8 Conclusion sur IP . . . . . . . . . . . . . . . . . . . . . . . . . 78 9 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 79V Protocole UDP 81 1 UDP – User Datagram Protocol . . . . . . . . . . . . . . . . . 81 1.1 Identification de la destination . . . . . . . . . . . . . . 81 1.2 Description de l’en-tˆte . . . . . . . . . . . . . . . . e . . 83 1.3 Ports r´serv´s — ports disponibles . . . . . . . . . e e . . 85 1.3.1 Attribution des ports “ancienne m´thode” e . . 86 1.3.2 Attribution des ports “nouvelle m´thode” e . . 86 2 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 87VI Protocole TCP 89 1 TCP – Transmission Control Protocol . . . . . . . . . . . . . . 89 1.1 Caract´ristiques de TCP . . . . . . e . . . . . . . . . . . 89 1.2 Description de l’en-tˆte . . . . . . . e . . . . . . . . . . . 91 2 D´but et clˆture d’une connexion . . . . . e o . . . . . . . . . . . 94 2.1 ´ Etablissement d’une connexion . . . . . . . . . . . . . 94 2.2 Clˆture d’une connexion . . . . . . o . . . . . . . . . . . 95 2.2.1 Clˆture canonique . . . . o . . . . . . . . . . . 95 2.2.2 Clˆture abrupte . . . . . . o . . . . . . . . . . . 96 3 Contrˆle du transport . . . . . . . . . . . o . . . . . . . . . . . 97 3.1 M´canisme de l’acquittement . . . e . . . . . . . . . . . 97 3.2 Fenˆtres glissantes . . . . . . . . . e . . . . . . . . . . . 98 4 Compl´ments sur le fonctionnement de TCP e . . . . . . . . . . . 100 4.1 Algorithme de Nagle . . . . . . . . . . . . . . . . . . . 100 4.2 D´part lent . . . . . . . . . . . . . e . . . . . . . . . . . 101 4.3 ´ Evitement de congestion . . . . . . . . . . . . . . . . . 101 5 Paquets captur´s, comment´s . . . . . . . e e . . . . . . . . . . . 102 6 Conclusion sur TCP . . . . . . . . . . . . . . . . . . . . . . . 105 7 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
  • viii ` TABLE DES MATIERES B R´seaux IP avanc´s e e 107 VII Routage dynamique d’IP 109 1 Introduction & rappels . . . . . . . . . . . . . . . . . . . . . . 109 1.1 IGP, EGP, Syst`me autonome . . . . . . . . . e . . . . . 110 1.2 ´ Vecteur de distances vs Etat de liens . . . . . . . . . . 111 2 Routage avec RIP . . . . . . . . . . . . . . . . . . . . . . . . . 113 2.1 En fonctionnement . . . . . . . . . . . . . . . . . . . . 114 2.1.1 Horizon partag´ ou Split horizon . . e . . . . . 116 2.1.2 Mises ` jour d´clench´es ou Triggered a e e updates 117 2.2 Le protocole RIPv1 vs RIPv2 . . . . . . . . . . . . . . 118 2.3 Algorithme Bellman-Ford . . . . . . . . . . . . . . . . 120 2.3.1 M´trique . . . . . . . . . . . . . . . e . . . . . 120 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 120 2.4.1 Points forts . . . . . . . . . . . . . . . . . . . 120 2.4.2 Points faibles . . . . . . . . . . . . . . . . . . 120 3 Routage avec OSPF . . . . . . . . . . . . . . . . . . . . . . . 121 3.1 Grandes lignes de fonctionnement . . . . . . . . . . . . 121 3.2 RIP vs OSPF . . . . . . . . . . . . . . . . . . . . . . . 122 3.3 Principe de propagation des ´tats . . . . . . . e . . . . . 124 3.3.1 Valeur des ´tats de liens . . . . . . . e . . . . . 127 3.4 Calcul du plus court chemin . . . . . . . . . . . . . . . 127 3.5 Hi´rarchie de routeurs . . . . . . . . . . . . . e . . . . . 127 3.6 Fonctionnement ` l’int´rieur d’une zone . . . . a e . . . . . 129 3.6.1 Voisinage et adjacence . . . . . . . . . . . . . 130 3.7 Protocole HELLO . . . . . . . . . . . . . . . . . . . . . 131 3.7.1 Cinq types de paquets . . . . . . . . . . . . . 131 3.7.2 En-tˆte standard des paquets OSPF e . . . . . 133 3.7.3 En-tˆte des paquets HELLO . . . . . e . . . . . 133 4 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 ´ e VIII El´ments de r´seaux e 137 1 Hˆtes ou services virtuels . . . . . . . . . . . . . . . o . . . . . . 137 2 Tunnel IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 2.1 Tunnel IP avec l’interface gif . . . . . . . . . . . . . . 140 2.2 IPsec et VPN . . . . . . . . . . . . . . . . . . . . . . . 143 2.2.1 IPsec dans quel but ? . . . . . . . . . . . . . . 143 2.2.2 IPsec en r´sum´ . . . . . . . . . . e e . . . . . . 144 2.2.3 Comment utiliser IPsec ? . . . . . . . . . . . . 145 2.2.4 Impl´mentation d’IPsec . . . . . . e . . . . . . 147 3 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 4 Translation d’adresses . . . . . . . . . . . . . . . . . . . . . . 148 4.1 NAPT sur un routeur de type PC avec natd . . . . . . 150 4.1.1 Interactions entre natd et le noyau . . . . . . 151 4.2 Translation d’adresses vers le r´seau priv´ . e e . . . . . . 152
  • `TABLE DES MATIERES ix 4.3 NAPT sur un routeur CISCO . . . . . . . . . . . . . . 153 5 Filtrage IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 5.1 Filtrage IP sur un routeur CISCO . . . . . . . . . . . . 154 5.2 Le cas d’ipfw de FreeBSD . . . . . . . . . . . . . . . . 154 6 Exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . 157 7 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 160C Protocoles applicatifs 163IX Serveur de noms - DNS 165 1 G´n´ralit´s sur le serveur de noms . . . . . . . . . e e e . . . . . . . 165 1.1 Bref historique . . . . . . . . . . . . . . . . . . . . . . 165 1.2 Syst`me hi´rarchis´ de nommage . . . . . e e e . . . . . . . 166 1.2.1 Domaine & zone . . . . . . . . . . . . . . . . 167 1.2.2 Hi´rarchie des domaines . . . . . e . . . . . . . 168 2 Fonctionnement du DNS . . . . . . . . . . . . . . . . . . . . . 169 2.1 Convention de nommage . . . . . . . . . . . . . . . . . 169 2.1.1 “ Completion ” . . . . . . . . . . . . . . . . . 170 2.2 Le “ Resolver ” . . . . . . . . . . . . . . . . . . . . . . 170 2.3 Strat´gie de fonctionnement . . . . . . . . e . . . . . . . 172 2.3.1 Interrogation locale . . . . . . . . . . . . . . . 172 2.3.2 Interrogation distante . . . . . . . . . . . . . 173 2.3.3 Interrogation par “ procuration ” . . . . . . . 174 2.4 Hi´rarchie de serveurs . . . . . . . . . . . e . . . . . . . 175 2.5 Conversion d’adresses IP en noms . . . . . . . . . . . . 175 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 177 3 Mise ` jour dynamique . . . . . . . . . . . . . . . a . . . . . . . 177 4 S´curisation des ´changes . . . . . . . . . . . . . . e e . . . . . . . 178 4.1 TSIG/TKEY pour s´curiser les transferts . e . . . . . . . 178 4.1.1 TSIG . . . . . . . . . . . . . . . . . . . . . . 179 4.1.2 TKEY . . . . . . . . . . . . . . . . . . . . . . 179 4.2 DNSSEC pour s´curiser les interrogations e . . . . . . . 179 5 Attaque DNS par amplification . . . . . . . . . . . . . . . . . 180 6 Format des “ Resource Record ” . . . . . . . . . . . . . . . . . 182 6.1 RR de type SOA . . . . . . . . . . . . . . . . . . . . . . 183 6.2 RR de type NS . . . . . . . . . . . . . . . . . . . . . . 183 6.3 RR de type A . . . . . . . . . . . . . . . . . . . . . . . 184 6.4 RR de type PTR . . . . . . . . . . . . . . . . . . . . . . 184 6.5 RR de type MX . . . . . . . . . . . . . . . . . . . . . . 184 6.6 RR de type CNAME . . . . . . . . . . . . . . . . . . . . 185 6.7 Autres RR. . . . . . . . . . . . . . . . . . . . . . . . . . 185 7 BIND de l’ISC . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 7.1 Architecture du daemon “ named ” . . . . . . . . . . . 186 8 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
  • x ` TABLE DES MATIERES X Courrier ´lectronique e 189 1 G´n´ralit´s sur le courrier ´lectronique . . . . . . . . . . e e e e . . . 189 1.1 M´taphore du courrier postal - L’enveloppe . . . e . . . 190 1.2 Adresse ´lectronique . . . . . . . . . . . . . . . . e . . . 190 2 Format d’un “ E-mail ” - RFC 822 . . . . . . . . . . . . . . . 191 2.1 Quelques champs couramment rencontr´s dans les e en- tˆtes . . . . . . . . . . . . . . . . . . . . . . . . . e . . . 192 3 Protocole SMTP - RFC 821 . . . . . . . . . . . . . . . . . . . 195 3.1 Protocole SMTP . . . . . . . . . . . . . . . . . . . . . . 195 3.2 Principales commandes de SMTP . . . . . . . . . . . . 197 3.2.1 Commande HELO . . . . . . . . . . . . . . . 197 3.2.2 Commande MAIL . . . . . . . . . . . . . . . 198 3.2.3 Commande RCPT . . . . . . . . . . . . . . . 198 3.2.4 Commande DATA . . . . . . . . . . . . . . . 198 3.2.5 Commande QUIT . . . . . . . . . . . . . . . 198 3.3 Propagation du courrier ´lectronique . . . . . . . e . . . 199 3.4 Courriers ind´sirables - Le spam . . . . . . . . . . e . . . 201 3.4.1 Caract´riser le spam . . . . . . . . . . . e . . . 201 3.4.2 ´ Eviter le spam . . . . . . . . . . . . . . . . . 202 4 Exemple de MTA - “ Sendmail ” et son environnement . . . . 205 4.1 Relations avec le DNS . . . . . . . . . . . . . . . . . . 205 4.2 Relations avec le syst`me d’exploitation . . . . . e . . . 206 4.3 Le cas de POP . . . . . . . . . . . . . . . . . . . . . . 210 4.4 Le cas de IMAP . . . . . . . . . . . . . . . . . . . . . . 211 5 Configuration du Sendmail . . . . . . . . . . . . . . . . . . . . 212 5.1 Configuration ` l’aide de M4 . . . . . . . . . . . . a . . . 212 5.2 Configuration manuelle . . . . . . . . . . . . . . . . . . 214 5.2.1 R`gles de r´´criture . . . . . . . . . . . e ee . . . 214 5.2.2 Exemple de sortie de debug . . . . . . . . . . 217 6 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 XI Instrumentalisation de r´seaux avec SNMP e 221 1 N´cessit´ d’un outil . . . . . . . . . . . . . . . . . . . . . e e . . . 221 1.1 Probl´matique de l’ISO . . . . . . . . . . . . . . . e . . . 221 1.2 Syst`me de gestion de r´seau . . . . . . . . . . . e e . . . 222 1.3 SNMP — Simple Network Management Protocol . . . 223 1.4 Historique du protocole SNMP . . . . . . . . . . . . . 224 1.5 Vocabulaire et architecture . . . . . . . . . . . . . . . . 224 1.6 Diff´rentes versions . . . . . . . . . . . . . . . . . e . . . 226 1.6.1 Trois composantes pour SNMP . . . . . . . . 226 1.6.2 Conclusion . . . . . . . . . . . . . . . . . . . 227 2 SMI — Structure of Management Information . . . . . . . . . 228 3 MIB — Management Information Base . . . . . . . . . . . . . 228 3.1 OID — Objet Identifier . . . . . . . . . . . . . . . . . 230 3.2 Types de donn´es ´l´mentaires . . . . . . . . . . . e ee . . . 231
  • `TABLE DES MATIERES xi 4 La MIB-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 5 Protocole SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 234 5.1 Communaut´ . . . . . . e . . . . . . . . . . . . . . . . . 235 5.2 PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 5.3 SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 237 6 L’outil NET-SNMP . . . . . . . . . . . . . . . . . . . . . . . . 238 6.1 snmptranslate . . . . . . . . . . . . . . . . . . . . . . 238 6.2 snmpget . . . . . . . . . . . . . . . . . . . . . . . . . 242 6.3 snmpgetnext . . . . . . . . . . . . . . . . . . . . . . 242 6.4 snmpwalk . . . . . . . . . . . . . . . . . . . . . . . . 242 6.5 snmptable . . . . . . . . . . . . . . . . . . . . . . . . 243 6.6 snmpset . . . . . . . . . . . . . . . . . . . . . . . . . 243 6.7 Approche graphique . . . . . . . . . . . . . . . . . . . 244 7 Glossaire des acronymes SNMP . . . . . . . . . . . . . . . . . 247 8 Liens & Bibliographie . . . . . . . . . . . . . . . . . . . . . . . 248D Sockets BSD et architecture de serveurs 249XII G´n´ralit´s sur les sockets de Berkeley e e e 251 1 G´n´ralit´s . . . . . . . . . . . . . . . . . . . . . . e e e . . . . . . 251 2 Pr´sentation des sockets . . . . . . . . . . . . . . . e . . . . . . 252 3 ´ Etude des primitives . . . . . . . . . . . . . . . . . . . . . . . 253 3.1 Cr´ation d’une socket . . . . . . . . . . . . . e . . . . . . 253 3.1.1 Valeur retourn´e par socket . . . . e . . . . . . 255 3.2 Sp´cification d’une adresse . . . . . . . . . . e . . . . . . 256 3.2.1 Sp´cification d’un num´ro de port . e e . . . . . . 256 3.2.2 Sp´cification d’une adresse IP . . . e . . . . . . 256 3.2.3 La primitive bind . . . . . . . . . . . . . . . 256 3.2.4 Les structures d’adresses . . . . . . . . . . . . 257 3.2.5 Valeur retourn´e par bind . . . . . e . . . . . . 258 3.3 Connexion ` une adresse distante . . . . . . a . . . . . . 259 3.3.1 Mode connect´ . . . . . . . . . . . e . . . . . . 259 3.3.2 Mode datagramme . . . . . . . . . . . . . . . 259 3.3.3 Valeur retourn´e par connect : . . e . . . . . . 260 3.4 Envoyer des donn´es . . . . . . . . . . . . . e . . . . . . 260 3.4.1 Envoi en mode connect´ . . . . . . e . . . . . . 260 3.4.2 Envoi en mode datagramme . . . . . . . . . . 261 3.5 Recevoir des donn´es . . . . . . . . . . . . . e . . . . . . 262 3.5.1 Reception en mode connect´ . . . . e . . . . . . 262 3.5.2 Recevoir en mode datagramme . . . . . . . . 262 3.6 Sp´cifier une file d’attente . . . . . . . . . . e . . . . . . 263 3.7 Accepter une connexion . . . . . . . . . . . . . . . . . 263 3.8 Terminer une connexion . . . . . . . . . . . . . . . . . 264 4 Sch´ma g´n´ral d’une session client–serveur . . . . e e e . . . . . . 265
  • xii ` TABLE DES MATIERES 5 Exemples de code “ client ” . . . . . . . . . . . . . . . . . . . 267 5.1 Client TCP “ DTCPcli ” . . . . . . . . . . . . . . . . . 267 5.2 Client UDP “ DUDPcli ” . . . . . . . . . . . . . . . . . 271 6 Conclusion et Bibliographie . . . . . . . . . . . . . . . . . . . 273 XIII Compl´ments sur les sockets Berkeley e 275 1 R´servation des ports . . . . . . . . . . . . . . . . . . . . . . . 275 e 1.1 R´servation de port — Ancienne m´thode . . . . . . . 276 e e 1.2 R´servation de port — Nouvelle m´thode . . . . . . . . 276 e e 2 Ordre des octets sur le r´seau . . . . . . . . . . . . . . . . . . 277 e 3 Op´rations sur les octets . . . . . . . . . . . . . . . . . . . . . 278 e 4 Conversion d’adresses . . . . . . . . . . . . . . . . . . . . . . . 279 4.1 Conversion d’adresse - IPv4 seul . . . . . . . . . . . . . 279 4.2 Conversion d’adresse - Compatible IPv4 et IPv6 . . . . 279 5 Conversion hˆte – adresse IPv4 . . . . . . . . . . . . . . . . . 280 o 5.1 Une adresse IP ` partir d’un nom d’hˆte . . . . . . . . 280 a o 5.2 Un nom d’hˆte ` partir d’une adresse IP . . . . . . . . 282 o a 6 Conversion N◦ de port – service . . . . . . . . . . . . . . . . . 282 6.1 Le num´ro ` partir du nom . . . . . . . . . . . . . . . 282 e a 6.2 Le nom ` partir du num´ro . . . . . . . . . . . . . . . 284 a e 7 Getaddrinfo, pour IPv4 et IPv6 . . . . . . . . . . . . . . . . 285 7.1 La fonction getaddrinfo . . . . . . . . . . . . . . . . . 285 7.1.1 Prototype de getaddrinfo . . . . . . . . . . 285 7.1.2 Description des arguments . . . . . . . . . . . 286 7.1.3 La structure addrinfo . . . . . . . . . . . . . 286 7.1.4 En r´sum´ . . . . . . . . . . . . . . . . . . . . 287 e e 7.1.5 Exemple d’usage ` la place de gethostbyname 288 a 7.1.6 Exemple d’usage ` la place de getservbyname 290 a 7.1.7 En r´sum´ . . . . . . . . . . . . . . . . . . . . 290 e e 8 Conversion nom de protocole – N◦ de protocole . . . . . . . . 291 9 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 10 Exemples de mise en application . . . . . . . . . . . . . . . . . 293 10.1 Ancienne m´thode (usage de gethostbyname) . . . . . 293 e 10.2 Nouvelle m´thode (usage de getaddrinfo) . . . . . . . 298 e 11 Conclusion et bibliographie . . . . . . . . . . . . . . . . . . . . 300 XIV ´ e El´ments de serveurs 301 1 Type de serveurs . . . . . . . . . . . . . . . . . . . . . . . . . 301 1.1 Serveurs it´ratif et concourant . e . . . . . . . . . . . . . 301 1.2 Le choix d’un protocole . . . . . . . . . . . . . . . . . . 302 1.2.1 Mode connect´ . . . . e . . . . . . . . . . . . . 302 1.2.2 Mode datagramme . . . . . . . . . . . . . . . 303 1.3 Quatre mod`les de serveurs . . e . . . . . . . . . . . . . 303 2 Technologie ´l´mentaire . . . . . . . . ee . . . . . . . . . . . . . 307 2.1 Gestion des “ tˆches esclaves ” . a . . . . . . . . . . . . . 307
  • `TABLE DES MATIERES xiii 2.2 fork, vfork et rfork . . . . . . . . . . . . . . . . . . . . 308 2.3 Processus l´gers, les “ threads ” . . . . . e . . . . . . . . 309 2.4 Programmation asynchrone . . . . . . . . . . . . . . . 311 2.5 La primitive select . . . . . . . . . . . . . . . . . . . 312 2.6 La primitive poll . . . . . . . . . . . . . . . . . . . . . 314 3 Fonctionnement des daemons . . . . . . . . . . . . . . . . . . 315 3.1 Programmation d’un daemon . . . . . . . . . . . . . . 315 3.2 Daemon syslogd . . . . . . . . . . . . . . . . . . . . . 316 3.3 Fichier syslog.conf . . . . . . . . . . . . . . . . . . . 318 3.4 Fonctions syslog . . . . . . . . . . . . . . . . . . . . . 318 4 Exemple de “ daemon ” inetd . . . . . . . . . . . . . . . . . . 320 4.1 Pr´sentation de inetd . . . . . . . . . . e . . . . . . . . 320 5 Exemple de code serveur . . . . . . . . . . . . . . . . . . . . . 322 5.1 Guide de lecture du source serv2prot.c . . . . . . . . 322 6 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 325XV Anatomie d’un serveur Web 327 1 Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . 327 1.1 Exemple d’´change avec http . . . . . e . . . . . . . . . 328 1.2 Structure d’un ´change . . . . . . . . . e . . . . . . . . . 328 2 URIs et URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 2.1 Scheme http . . . . . . . . . . . . . . . . . . . . . . . . 332 3 Architecture interne du serveur Apache . . . . . . . . . . . . . 334 3.1 Environnement d’utilisation . . . . . . . . . . . . . . . 334 3.2 Architecture interne . . . . . . . . . . . . . . . . . . . 336 3.2.1 Gestion des processus . . . . . . . . . . . . . 337 3.2.2 Prise en main des requˆtes . . e . . . . . . . . . 342 3.2.3 Deux types de CGIs . . . . . . . . . . . . . . 343 4 Principe de fonctionnement des CGIs . . . . . . . . . . . . . . 347 4.1 CGI — M´thode GET, sans argument e . . . . . . . . . 347 4.2 CGI — M´thode GET, avec arguments e . . . . . . . . . 348 4.3 CGI — M´thode POST . . . . . . . . e . . . . . . . . . 349 4.4 Ecriture d’une CGI en Perl . . . . . . . . . . . . . . . 350 5 Conclusion – Bibliographie . . . . . . . . . . . . . . . . . . . . 351E Index g´n´ral & Annexes e e 353A Programme serv2prot.c 367
  • xiv ` TABLE DES MATIERES
  • Table des figures I.01 Mod`le en 7 couches de l’OSI . . . . . . . . . e . . . . . . . . . 6 I.02 Exemple de LANs . . . . . . . . . . . . . . . . . . . . . . . . . 7 I.03 trame Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 10 I.04 Diff´rences Ethernet 802.2/802.3 . . . . . . . . e . . . . . . . . . 13 I.05 Interconnexion - Technologie ´l´mentaire . . . ee . . . . . . . . . 14 I.06 Prise vampire . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 I.07 Technologie de liaison . . . . . . . . . . . . . . . . . . . . . . . 17 I.08 Plusieurs r´p´teurs mais toujours le mˆme lan e e e . . . . . . . . . 18 I.09 Concentrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 I.10 Dialogue sans pont . . . . . . . . . . . . . . . . . . . . . . . . 19 I.11 Dialogue avec pont . . . . . . . . . . . . . . . . . . . . . . . . 19 I.12 Commutateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 I.13 Fonction routage . . . . . . . . . . . . . . . . . . . . . . . . . 22 I.14 Traduction de protocoles . . . . . . . . . . . . . . . . . . . . . 22 II.01 Comparaison ISO-ARPA . . . . . . . . . . . . . . . . . . . . 28 II.02 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . 29 II.03 Encapsulation d’IP . . . . . . . . . . . . . . . . . . . . . . . 31 III.01 D´composition en classes . . . . . e . . . . . . . . . . . . . . 35 III.02 Sous-r´seaux . . . . . . . . . . . . e . . . . . . . . . . . . . . 38 III.03 Puissances de 2 . . . . . . . . . . . . . . . . . . . . . . . . . 38 III.04 Adresses de multicast . . . . . . . . . . . . . . . . . . . . . 42 III.05 Adresse physique de multicast . . . . . . . . . . . . . . . . . 43 III.06 Usage combin´ des adresses logique e et physique . . . . . . . 44 IV.01 Structure du datagramme IP . . . . . . . . . . . . . . . . . 47 IV.02 “ Big endian ” vs “ Little endian ” . . . . . . . . . . . . . . 48 IV.03 Fragmentation IP . . . . . . . . . . . . . . . . . . . . . . . . 52 IV.04 Fragment ` transmettre . . . . . . a . . . . . . . . . . . . . . 53 IV.05 R´sum´ de la fragmentation . . . . e e . . . . . . . . . . . . . . 54 IV.06 Question ARP . . . . . . . . . . . . . . . . . . . . . . . . . 55 IV.07 R´ponse ARP . . . . . . . . . . . . e . . . . . . . . . . . . . . 56 IV.08 Datagramme ARP . . . . . . . . . . . . . . . . . . . . . . . 57 IV.09 Message ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 60 IV.10 Format d’un message ICMP . . . . . . . . . . . . . . . . . . 60 IV.11 “ Echo request ” vs “ Echo reply ” . . . . . . . . . . . . . . 61
  • xvi TABLE DES FIGURES IV.12 En-tˆte IGMP . . . . . . . . . . . . . . e . . . . . . . . . . . 63 IV.13 Fonctionnement IGMP . . . . . . . . . . . . . . . . . . . . . 64 IV.14 Table de routage . . . . . . . . . . . . . . . . . . . . . . . . 67 IV.15 Situation r´seau lors du netstat . . . . e . . . . . . . . . . . 69 IV.16 Exemple de nuage avec routage statique . . . . . . . . . . . 70 IV.17 Exemple pour routage dynamique . . . . . . . . . . . . . . . 71 IV.18 Topologie pour routage dynamique . . . . . . . . . . . . . . 72 IV.21 ICMP “ redirect ” . . . . . . . . . . . . . . . . . . . . . . . 74 IV.22 Interface de “ loopback ” . . . . . . . . . . . . . . . . . . . 75 IV.23 Illustration du routage direct et indirect . . . . . . . . . . . 76 V.01 Num´ro de port comme num´ro e e de service . . . . . . . . . . 82 V.02 UDP encapsul´ dans IP . . . . e . . . . . . . . . . . . . . . . 83 V.03 Structure de l’en-tˆte UDP . . e . . . . . . . . . . . . . . . . 84 V.04 Cas du checksum non nul . . . . . . . . . . . . . . . . . . . 84 VI.01 TCP encapsul´ dans IP . . . . e . . . . . . . . . . . . . . . . 89 VI.02 Structure de l’en-tˆte TCP . . e . . . . . . . . . . . . . . . . 91 VI.03 ´ Etablissement d’une connexion . . . . . . . . . . . . . . . . 94 VI.04 Clˆture d’une connexion . . . . o . . . . . . . . . . . . . . . . 95 VI.05 ´ Emission d’un rst . . . . . . . . . . . . . . . . . . . . . . . . 96 VI.06 M´canisme de l’acquittement . e . . . . . . . . . . . . . . . . 97 VI.07 Principe de la fenˆtre glissante e . . . . . . . . . . . . . . . . 98 VI.08 D´tail de la fenˆtre glissante . . e e . . . . . . . . . . . . . . . . 99 VI.09 Exemple de fenˆtre glissante . . e . . . . . . . . . . . . . . . . 104 VII.01 Un AS, le monde ext´rieur, le monde int´rieur ! . . . . . . . 111 e e VII.02 La route vers H depuis R a une m´trique de 2 et passe par R1113 e VII.03 Fonctionnement ´l´mentaire . . . . . . . . . . . . . . . . . . 115 ee VII.04 L’“ horizon partag´ ” ne r´sout pas tout ! . . . . . . . . . . 116 e e VII.05 RIP est transport´ par UDP/IP . . . . . . . . . . . . . . . . 118 e VII.06 Format d’un message RIPv2 . . . . . . . . . . . . . . . . . . 118 VII.07 Relation d’ordre entre deux LSP . . . . . . . . . . . . . . . 125 VII.08 Propagation des LSP par inondation ou “ flooding ” . . . . 126 VII.09 Organisation en zones – Hi´rarchie de routeurs . . . . . . . 128 e VII.10 Propagation d’un LSP, sans et avec un DR . . . . . . . . . . 129 VII.11 Organisation globale de l’en-tˆte du protocole OSPF . . . . 132 e VII.12 En-tˆte standard de 24 octets . . . . . . . . . . . . . . . . . 133 e VII.13 En-tˆte du paquet HELLO . . . . . . . . . . . . . . . . . . 134 e VIII.01 Serveur HTTP virtuel . . . . . . . . . . . . . . . . . . . . 137 VIII.02 Tunnel IP - Principe . . . . . . . . . . . . . . . . . . . . . 139 VIII.03 Tunnel IP - cas concrˆt e . . . . . . . . . . . . . . . . . . . . 141 VIII.04 En-tˆtes d’IPsec . . . . e . . . . . . . . . . . . . . . . . . . . 145 VIII.05 Association 1 . . . . . . . . . . . . . . . . . . . . . . . . . 145 VIII.06 Association 2 . . . . . . . . . . . . . . . . . . . . . . . . . 146
  • TABLE DES FIGURES xvii VIII.07 Association 3 . . . . . . . . . . . . . . . . . . . . . . . . . 146 VIII.08 Association 4 . . . . . . . . . . . . . . . . . . . . . . . . . 146 VIII.04 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 VIII.10 R translate dynamiquement des couples (adresse IP, num´ro de port) . . . . . . . . . . . . . . . . . . . . . . . e . . . 148 VIII.11 Machine NAPT en routeur . . . . . . . . . . . . . . . . . . 150 VIII.12 Interactions entre natd et le noyau de FreeBSD . . . . . . 151 VIII.13 Static Nat . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 VIII.14 Configuration multiservices . . . . . . . . . . . . . . . . . . 153 VIII.15 Configuration simple de filtrage . . . . . . . . . . . . . . . 155 VIII.16 Translation d’adresse et filtrage IP . . . . . . . . . . . . . . 157 IX.01 Organisation hi´rarchique des domaines e . . . . . . . . . . . 169 IX.02 Le “ resolver ” dans son environnement . . . . . . . . . . . 171 IX.03 Subdivision hi´rarchique des domaines . e . . . . . . . . . . . 172 IX.03 Interrogation locale . . . . . . . . . . . . . . . . . . . . . . . 172 IX.05 Interrogation distante . . . . . . . . . . . . . . . . . . . . . 174 IX.06 R´ponse ` une requˆte non formul´e . . e a e e . . . . . . . . . . . 180 IX.07 Attaque DNS par amplification . . . . . . . . . . . . . . . . 181 IX.08 BIND de l’ISC . . . . . . . . . . . . . . . . . . . . . . . . . 186 X.01 Format d’un e-mail . . . . . . . . . . . . . . . . . . . . . . . 192 X.02 MUA - MSA - MTA - LDA - OS . . . . . . . . . . . . . . . 199 X.03 Trajet d’un mail . . . . . . . . . . . . . . . . . . . . . . . . 200 X.04 MX primaire et secondaires . . . . . . . . . . . . . . . . . . 205 X.05 Relation entre Sendmail et le syst`me d’exploitation e . . . . 206 X.06 Le cas de POP . . . . . . . . . . . . . . . . . . . . . . . . . 210 X.07 Concentration du mail sur un “ mailhub ” . . . . . . . . . . 213 X.08 R`gles de r´´criture . . . . . . . . . . . . . . . . . . e ee . . . . 215 XI.01 Agent et Manager dans une relation de type client-serveur . 224 XI.02 La racine de l’arbre des OIDs . . . . . . . . . . . . . . . . . 230 XI.03 Des agents et un Manager . . . . . . . . . . . . . . . . . . . 234 XI.04 Format des messages SNMP . . . . . . . . . . . . . . . . . . 235 XI.05 Exemple d’interrogation d’un agent avec l’outil mbrowse . . 244 XI.06 Synth`se graphique des compteurs ifInOctets et e ifOutOctets sur 24h . . . . . . . . . . . . . . . . . . . . . . . 245 XI.07 Exemple d’´cran de surveillance avec tkined . . . . . . . e . 247 XII.01 Les sockets, une famille de primitives . . . . . . . . . . . . . 251 XII.02 Relation pile IP, num´ro de port et process ID e . . . . . . . . 252 XII.03 Structures d’adresses . . . . . . . . . . . . . . . . . . . . . . 258 XII.04 Relation client–serveur en mode connect´ . . e . . . . . . . . 265 XII.05 Relation client–serveur en mode non connect´ e . . . . . . . . 266 XIII.01 Ordre des octets sur le r´seau . . . . . . . . . . . . . . . . . 277 e
  • xviii TABLE DES FIGURES XIV.01 Quatre types de serveurs . . . . . . . . . . . . . . . . . . . 303 XIV.02 Ex´cution avec et sans threads e . . . . . . . . . . . . . . . . 309 XIV.03 Syslogd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 XIV.04 Inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 XV.01 Structure d’un message HTTP . . . . . . . . . . . . . . . . 329 XV.02 Environnement syst`me . . . . . . . e . . . . . . . . . . . . . 334 XV.03 Algorithme de gestion des processus . . . . . . . . . . . . . 340 XV.04 Usage de la “score board” . . . . . . . . . . . . . . . . . . . 342 XV.05 Deux type de CGIs . . . . . . . . . . . . . . . . . . . . . . . 343
  • Liste des tableaux I.01 Quelques valeurs du champs type de l’en-tˆte IP . . . . . . . . 11 e I.02 Exemples de “ Organizationally Unique Identifier ” (OUI) . . 12 III.01 Adresses IP des r´seaux priv´s . . . . . . . . e e . . . . . . . . 34 III.02 Adresses IP avec une signification particuli`re e . . . . . . . . 37 III.03 Partitionnement d’une classe C en quatre sous r´seaux e . . . 38 III.04 D´tail des quatre sous r´seaux d’un /26 . . . e e . . . . . . . . 39 III.05 Adresses IP priv´es, notation du CIDR . . . . e . . . . . . . . 40 III.06 Agr´gations r´gionales des blocs IP . . . . . . e e . . . . . . . . 41 III.07 Quelques adresses multicasts du LAN . . . . . . . . . . . . 42 IV.01 Bits du champ TOS . . . . . . . . . . . . . . . . . . . . . . 49 IV.02 En-tˆte des fragments IP vs en-tˆte datagramme original . . 54 e e IV.03 Quelques drapeaux de routage de la commande netstat -r 69 V.01 Extrait succinct du fichier /etc/services . . . . . . . . . . 85 VI.01 Drapeaux du champ CODE (en-tˆte TCP) . . . . . . . . . . 92 e VII.01 Quelques valeurs d’´tats de liens pour OSPF . . . . . . . . . 127 e X.01 Quelques champs couramment rencontr´s dans un tˆte de e e mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 XI.01 Extrait de la MIB II concernant l’OID tcpConnTable . . . . 229 XI.02 Extrait du d´but de la MIB-2 . . . . . . . . . . . . . . . . . 233 e XI.03 Extrait de la MIB-2 concernant le d´but du goupe “ system ”241 e XII.01 Exemples de familles de protocoles pour une socket . . . . . 254 XII.02 Exemples de type de sockets . . . . . . . . . . . . . . . . . . 254 XII.03 Exemples de protocoles associ´s ` une socket . . . . . . . . 255 e a XIII.01 Exemples de codes de retours des primitives syst`mes pour e le r´seau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 e XIV.01 Typologie des applicatifs qui utilisent syslog . . . . . . . . 319 XIV.02 Criticit´ des messages de log . . . . . . . . . . . . . . . . . 319 e XV.01 Codes de retour du protocole HTTP . . . . . . . . . . . . . 330
  • xx LISTE DES TABLEAUX XV.02 Configuration du mod`le “ pre-forked ” d’Apache . . . . . . 335 e
  • Pr´face e Attention ! Ce document n’est qu’un support decours, c’est ` dire qu’il ne remplace pas les documents acit´s dans la bibliographie qui termine chacun des cha- epitres qui le composent. ´ Evidement imparfaites, pleines d’erreurs involontaires, et surtout in-compl`tes, ces pages r´clament avant tout votre indulgence de lecteur bien- e eveillant : “ Rien n’est constant, tout change ” comme le disait d´j` Lao Tseu, ea400 ans avant JC. Que dirait-il alors aujourd’hui, concernant les r´seaux ! ! e Ces cours s’accompagnent de travaux pratiques dont le texte ne figure pasici, ils sont initialement con¸us pour les ´tudiants du Mast`re de Syst`mes c e e e 2 ´d’Informations Ouverts (SIO) de l’Ecole Centrale Paris, afin de les aider ` ala compr´hension th´orique et pratique des r´seaux TCP/IP. e e e Ce support est en acc`s libre, c’est ` dire mis ` la dis- e a aposition de tous pour un usage personnel ou collectif,sans but lucratif. Sa revente, s’il y a lieu, ne peut ˆtre eenvisag´e que pour couvrir les frais induits par sa re- eproduction. Enfin, sa redistribution sous quelque formeque ce soit, ne peut se concevoir sans cette pr´face. e Ne pas h´siter ` me contacter en cas de doute sur l’usage : e a Fran¸ois Laissus <fr.laissus@laissus.fr> c En aucun cas l’auteur ne pourra ˆtre tenu responsable des cons´quences e ede l’usage de ce document, qui est fourni tel quel et sans garantie d’aucunesorte. L’usage des informations contenues est donc plac´ sous la responsabilit´ e epleine et enti`re du lecteur. e Enfin, si vous pensez que la lecture de ce support vous a apport´ quelque echose, que vous avez une remarque ` me faire, ou tout simplement me com- aplimenter (¸a fait toujours plaisir quoi que l’on puisse en dire ! :) sentez-vous clibres de m’envoyer un courrier ´lectronique, je suis toujours ravi d’apprendre eque ce travail a pu servir ! Enfin merci de votre int´rˆt pour ce document, j’esp`re que vous y trou- ee everez ce que vous cherchez ! 2 http://www.mastere-sio.ecp.fr/
  • xxii Pr´face e
  • Premi`re partie eIntroduction ` la pile ARPA a
  • Chapitre I R´seaux locaux e1 Pr´ambule e Ce cours n’est pas un cours g´n´ral sur les r´seaux mais une pr´sentation e e e eminimale de cette technologie pour pouvoir aborder le cours de concepts etprogrammation TCP/IP sous UNIX. TCP/IP est le protocole le plus r´pandu dans le monde grˆce ` l’Internet. e a a En 1980 il ne comptait que quelques dizaines d’hˆtes, en juin 1996 ce onombre ´tait de 12 millions de machines, r´parties en pr`s de 500 000 r´seaux e e e e(Par comparaison, en f´vrier 1995, les mˆmes chiffres ´taient 4 850 000 ma- e e echines pour plus de 71 000 r´seaux locaux). e En janvier 2003, le nombre de machines1 directement accessibles sur ler´seau ´tait de 180 000 000 selon l’ISC2 . Depuis on ne compte plus tant e ela croissance est importante. . .Pour la france l’AFNIC propose ´galement e 3quelques statisques . . .Il n’existe pas de “ botin ” g´n´ral du r´seau, par e e econtre Bill Cheswick des Bell labs l’a cartographi´, et le r´sultat est fascinant : e e http://www.cheswick.com/ches/map/gallery/index.html2 G´n´ralit´s - LANs e e e2.1 G´n´ralit´s e e e Un r´seau informatique met en relation des ordinateurs, comme un r´seau e et´l´phonique met en relation des personnes. ee Des ordinateurs sont dits “ en r´seaux ” d`s lors qu’ils partagent une e etechnologie qui leur permet de communiquer ensemble. Le plus souvent cette technologie se mat´rialise physiquement par une eliaison avec un cˆble conducteur. Sur ce type de support, un signal ´lectrique a e 1 Source http://www.isc.org/ds/ 2 Internet Software consortium 3 http://www.nic.fr/statistiques/
  • 4 R´seaux locaux e v´hicule les messages informatiques. Il existe d’autres types de supports en e pleine expansion comme les liaisons par ondes hertziennes, rayon laser, infra- rouge. . . Sans connaissance pr´alable concernant les r´seaux informatiques on peut e e imaginer quantit´ d’interrogations ` partir de cette hypoth`se de raccorde- e a e ment : – Comment reconnaitre un correspondant ? – Comment dialoguer avec ? – Comment diffuser l’information ` plusieurs correspondants ? a – Comment ´viter la cacophonie ? e – Il y a t–il une hi´rarchie des machines ? e – Il y a t–il un chef d’orchestre ? – ... Toutes ces questions (et bien d’autres) trouveront une r´ponse dans ce e cycle de cours. Ces r´ponses sont g´n´ralement formul´es dans un “ pro- e e e e tocole ”, une sorte de mode d’emploi des r´seaux. Il y a des centaines de e protocoles diff´rents sur l’Internet, certains sont tr`s populaires, d’autres ab- e e solument pas. 2.2 Mod`le de communication OSI e Le concept de base de tout ce cours est celui de la “ commutation de paquets ”, une vieille id´e de l’informatique4 contrairement ` l’approche par e a circuits virtuels plus utilis´e en t´l´phonie. e ee Les donn´es ` transmettre d’une machine ` une autre sont fragment´es e a a e ` l’´mission en petit blocs de quelques centaines d’octets munis de l’adresse a e du destinataire, envoy´es sur le r´seau et r´-assembl´es ` la r´ception pour e e e e a e reproduire les donn´es d’origine. e Ce concept facilite le partage des possibilit´s physiques du r´seaux (bande e e passante) et est parfaitement adapt´ pour une impl´mentation sur machines e e s´quentielles travaillant en temps partag´ (plusieurs communications peuvent e e alors avoir lieu simultan´ment et sur une mˆme machine). e e Partant de ce concept, un mod`le d’architecture pour les protocoles de e communication a ´t´ d´velopp´ par l’ISO (International Standards Organisa- ee e e tion) entre 1977 et 1984. Ce mod`le sert souvent de r´f´rence pour d´crire la e ee e structure et le fonctionnement des protocoles de communication, mais n’est pas une contrainte de sp´cification. e Ce mod`le se nomme OSI comme “ Open Systems Interconnection Re- e ference Model ”. Les constituants de ce mod`le sont si largement employ´s e e qu’il est difficile de parler de r´seaux sans y faire r´f´rence. e ee e e ` Le mod`le OSI est constitu´ de sept couches. A chaque couche est as- soci´e une fonction bien pr´cise, l’information traverse ces couches, chacune e e y apporte sa particularit´.e Cette forme d’organisation n’est pas dˆe au hasard, c’est celle sur la- u 4 Con¸u par l’Am´ricain Paul Baran et publi´ en 1964 c e e
  • G´n´ralit´s - LANs e e e 5quelle les informaticiens ont beaucoup travaill´ dans les ann´es soixantes e epour d´finir les caract´ristiques des syst`mes d’exploitation. e e e Une couche ne d´finit pas un protocole, elle d´limite un service qui peut e eˆtre r´alis´ par plusieurs protocoles de diff´rentes origines. Ainsi chaquee e e ecouche peut contenir tous les protocoles que l’on veut, pourvu que ceux-cifournissent le service demand´ ` ce niveau du mod`le. ea e Un des int´rˆts majeurs du mod`le en couches est de s´parer la notion de ee e ecommunication, des probl`mes li´s ` la technologie employ´e pour v´hiculer e e a e eles donn´es. ePour m´moire (figure I.01) : e7 La couche application (Application layer) est constitu´e des programmes e d’application ou services, qui se servent du r´seau. Ils ne sont pas e forc´ment accessibles ` l’utilisateur car ils peuvent ˆtre r´serv´s ` un e a e e e a usage d’administration.6 La couche de pr´sentation (Pr´sentation layer) met en forme les donn´es e e e suivant les standards locaux ou particuliers ` l’application. Comme, a par exemple passer d’une repr´sentation “ big endian ” ou ` une e a repr´sentation “ little endian ” ou encore plus complexe comme celle e d´crite pas les “ XdR ” (eXternal Data Representation) et qui autorise e la transmission de types abstraits de donn´es (structures complexes, e arbres, listes chain´es, la liste n’est pas limitative. . .). e De nos jour c’est de plus en plus le XML5 qui occupe cet espace fina- lement assez peu norm´. e5 La couche de session (Session layer) effectue l’aiguillage entre les divers services (7) qui communiquent simultan´ment ` travers le mˆme ordi- e a e nateur connect´ et le mˆme r´seau. Deux utilisateurs d’une mˆme ma- e e e e chine peuvent utiliser la mˆme application sans risque d’inter-actions e parasites.4 La couche de transport (Transport layer) garantie que le destinataire ob- tient exactement l’information qui lui a ´t´ envoy´e. Cette couche met ee e par exemple en œuvre des r`gles de renvoi de l’information en cas d’er- e reur de r´ception. e3 La couche r´seau (Network layer) isole les couches hautes du mod`le qui e e ne s’occupent que de l’utilisation du r´seau, des couches basses qui ne e s’occupent que de la transmission de l’information.2 La couche de donn´e (Data link layer) effectue le travail de transmission e des donn´es d’une machine ` une autre. e a1 La couche Physique (Physical layer) d´finit les caract´ristiques du mat´riel e e e n´cessaire pour mettre en øeuvre le signal de transmission, comme des e tensions, des fr´quences, la description d’une prise. . . e 5 http://www.w3.org/XML/
  • 6 R´seaux locaux e Mod`le en 7 couches de l’OSI e Protocole Application Application Présentation Protocole Présentation Session Protocole Session S S Transport Protocole Transport T S S T Protocole Réseau Réseau R T S S T R Liaison Protocole Liaison L R T S S T R L Protocole Physique Physique L R T S S T R L figure I.01 — Mod`le en 7 couches de l’OSI e Du niveau 7 de l’application, au niveau 4 du transport, l’information circule dans ce que l’on appelle un “ message ”, au niveau 3 elle se nomme “ packet ”, puis “ frame ” au niveau 2 et “ signal ” au niveau 1. Chaque couche ne voit et ne sait communiquer qu’avec la couche qui la pr´c`de et celle qui la suit, avec le cas particulier des couches 1 et 7. e e L’int´rˆt de travailler en couches est que lorsque les modalit´s d’´changes ee e e entre chacune d’entres elles sont pr´cis´ment d´crites, on peut changer l’im- e e e pl´mentation et les sp´cificit´s de la couche elle-mˆme sans que cela affecte e e e e le reste de l’´difice. e C’est sur ce principe qu’est bˆtie la suite de protocoles d´sign´e par a e e TCP/IP Quand deux applications A et B discutent entre-elles via le r´seau, les e informations circulent de la couche 7 vers la couche 2 quand l’application A envoie de l’information sur le r´seau, et de la couche 2 vers la couche 7 pour e que l’application B re¸oive l’information de A. c Le principe de base de cette discussion repose sur le fait que chaque couche du mod`le de la machine A est en relation uniquement avec son homologue e du mˆme niveau de la machine B. e Quand l’information descend de la couche 7 vers la couche 1, chaque couche “ en-capsule ” les donn´es re¸ues avant de les transmettre. Ainsi le e c volume d’informations s’est accrˆ de quelques centaines d’octets arriv´ ` la u ea couche 1. De mani`re sym´trique, quand l’information remonte de la couche phy- e e sique vers la couche Application, chaque couche pr´l`ve les octets qui lui sont ee propres, ainsi l’application B ne voit-elle que les octets envoy´s par l’appli- e cation A, sans le d´tail de l’acheminement. e
  • 3 R´seaux locaux e 73 R´seaux locaux e Le probl`me intuitif et pratique qui se pose est de relier entre elles par un ecˆble toutes les machines qui veulent communiquer : c’est impossible d’abord apour des raisons techniques, le monde est vaste, puis de politique d’emploides ressources du r´seau, tel r´seau qui sert ` l’enseignement ne doit pas pas e e aperturber le fonctionnement de tel processus industriel. La cons´quence est que les r´seaux se d´veloppent d’abord en local, autour e e ed’un centre d’int´rˆt commun, avant de se tourner (parfois) vers l’ext´rieur. ee e3.1 Qu’est-ce qu’un LAN ? Le terme “ r´seau local ” n’est pas clairement d´fini, cependant tout le e emonde s’accorde ` baptiser de la sorte un r´seau, d`s lors qu’on lui reconnait a e eles caract´ristiques suivantes : e – Cohabitation de plusieurs protocoles, – Un mˆme m´dia (mˆme cˆble par exemple) qui raccorde de multiples e e e a machines, peut ˆtre de caract´ristiques diff´rentes, e e e – Une bande passante ´lev´e, partag´e par tous les hˆtes e e e o – La capacit´ de faire du “ broadcasting ” et du “ multicasting ”, e – Une extension g´ographique de moins en moins limit´e, e e – Un nombre de machines raccord´es limit´, e e – Des relations entre les machines plac´es sur un mode d’´galit´, (et non e e e par exemple sur un mode Maˆ ıtre/Esclave comme dans un r´seau dont e la topologie serait en ´toile), e – Une mise en œuvre qui reste du domaine priv´, c’est ` dire qui ne e a d´pend pas d’un op´rateur officiel de t´l´communications. e e ee Notez que les notions de “ bande passante ” et “ nombre limit´ ” (etc. . .) esont volontairement qualitatives. Elles ´voluent rapidement avec le temps. e Machine sur le LAN figure I.02 — Exemple de LANs Exemple de types de technologies utilis´es dans les LANs : e – Token ring
  • 8 R´seaux locaux e – IEEE 802 LANs – Ethernet et Fast-Ethernet – FDDI (anneau en fibre optique) – ATM – 802.11(a,b,g,. . .) – ... 3.2 WAN - MAN Un WAN (Wide Area Network) d´signe des ordinateurs connect´s entre e e diff´rentes villes (Metropolitan Area Network) ou pays. La technologie uti- e lis´e est traditionnellement moins performante que celle d’un LAN, c’est par e exemple une ligne t´l´phonique lou´e fonctionnant ` 64 kbps, une liaison ee e a RNIS, ou encore une liaison transatlantique ` 1Mbits/secondes. a Les am´liorations technologiques apport´es aux LANs permettent de les e e ´tendre de plus en plus g´ographiquement, celles apport´es aux WAN aug- e e e mentent consid´rablement les bandes passantes, ces deux tendances font que e la distinction entre ces deux types de r´seaux est de moins en moins claire. e 3.3 Communications inter-r´seaux e Les r´seaux sont appel´s ` communiquer entres eux et quand cela se e e a produit on parle de communications inter-r´seaux (“ internetworking ”). e Le rˆle d’une communication inter-r´seaux est de gommer les ´ventuelles o e e diff´rences de technologie d’´change pour permettre ` deux r´seaux, ou plus, e e a e le partage de ressources communes, l’´change d’informations. e Un moyen de faire communiquer deux r´seaux distincts passe par l’utili- e sation de “ gateway ” ou passerelle. Un tel dispositif est parfois appel´ routeur (router), mais c’est un abus e de langage. Les hommes se connectent sur les ordinateurs Les ordinateurs se connectent sur un r´seau e Les r´seaux s’inter-connectent dans un “ internet ” e
  • 4 Couche 2 - Liaison (Data Link) 94 Couche 2 - Liaison (Data Link) La couche 2 la plus populaire est surement celle que l’on nomme abusive-ment “ Ethernet ”, du nom du standard publi´ en 1982 par DEC, Intel Corp. eet Xerox. Cette technique repose sur une m´thode d’acc`s et de contrˆle dite e e oCSMA/CD (“ Carrier Sense, Multiple Access with Collision Detection ”). Elle est devenue tellement populaire qu’on parle d’un cˆble Ethernet, ad’une adresse Ethernet, d’une liaison Ethernet. . . Plus tard l’IEEE (“ Institute of Electrical and Electronics Engineers ”)6 sous l’instance de son commit´ 802, publia un ensemble de standards el´g`rement diff´rents, les plus connus concernant la couche 2 sont 802.2 e e e(Contrˆle logique de la liaison – LLC7 ) et 802.3 (CSMA/CD) o Dans le monde TCP/IP, l’encapsulation des datagrammes IP est d´criteedans la RFC 894 [Hornig 1984] pour les r´seaux Ethernet et dans la RFC 1042 e[Postel et Reynolds 1988] pour les r´seaux 802. e En r`gle g´n´rale, toute machine utilisant TCP/IP sur ce type de r´seaux e e e edoit : 1. ˆtre capable d’envoyer et de recevoir un paquet conforme ` la RFC 894, e a 2. ˆtre capable de recevoir des paquets conformes aux deux standards, e 3. Par contre il est seulement souhaitable que cette machine soit capable d’envoyer des paquets conformes ` la RFC 1042. a Par d´faut le standard est donc celui de la RFC 894, si une machine peut efaire les deux, cela doit ˆtre configurable. e De nos jours la couche 802.11 (r´seau sans fil - wifi) voit sa popularit´ e ecroˆ ıtre tr`s vite. Elle est bas´e sur une m´thode d’acc`s assez proche, le e e e eCSMA/CA (“ Carrier Sense, Multiple Access with Collision Avoidance ”).En effet les collisions ne peuvent pas toujours ˆtre d´tect´es car les hˆtes ne e e e osont pas n´cessairement ` port´e radio directe. Les ´changes, quand ils ne e a e esont pas de type “ point ` point ”, passent par un interm´diaire nomm´ en a e eg´n´ral “ point d’acc`s ” ce qui complique le protocole, et donc la trame, par e e erapport au CSMA/CD.4.1 Caract´ristiques d’Ethernet e4.1.1 Quelques principes fondamentaux 1. Le support de transmission est un Segment = bus = cˆble coaxial. Il a n’y a pas de topologie particuli`re (boucle, ´toile, etc. . .). e e 2. Un ´quipement est raccord´ sur un cˆble par un “ transceiver ” : e e a “ Transmitter + receiver = transceiver ” (coupleur ou transducteur). On parle alors d’une station Ethernet, celle-ci a une adresse unique. 6 http://www.ieee.org/ 7 “ Logical Link Control ”
  • 10 R´seaux locaux e 3. Sur le cable circulent des trames, autant de paquets de bits. Il n’y a pas de multiplexage en fr´quence, pas de “ full duplex ” 8 . Une trame ´mise e e par une station est re¸ue par tous les coupleurs du r´seau Ethernet, elle c e contient l’adresse de l’´metteur et celle du destinataire. e 4. Un coupleur doit ˆtre ` l’´coute des trames qui circulent sur le cˆble. Un e a e a coupleur connait sa propre adresse, ainsi si une trame lui est destin´e e il la prend, sinon il n’en fait rien. 5. Une station qui veut ´mettre attend que toutes les autres stations se e taisent. Autrement dit, si le cˆble est libre elle envoie sa trame, sinon a elle attend. Si deux stations ´mettent en mˆme temps il y a collision. Les deux e e trames sont alors inexploitables, les deux (ou plus) stations d´tectent e ce fait et re´mettent ult´rieurement leur paquet en attente. e e 6. Un r´seau Ethernet est donc un r´seau ` caract`re probabiliste car il n’y e e a e a pas de chef d’orchestre pour synchroniser les ´missions. Cette absence e conduit ` dire que c’est un r´seau ´galitaire, une sorte de r´union sans a e e e animateur entre personnes polies En conclusion, la technologie Ethernet est simple, sa mise en œuvre se fait ` faible coˆt. Points ` retenir : a u a – Simplicit´ et faible coˆt e u – Peu de fonctions optionnelles – Pas de priorit´ e – Pas de contrˆle sur l’attitude des voisins o – D´bit d’au moins 10Mb/s (jusqu’` 1000Mb/s th´orique). e a e – Performances peu d´pendantes de la charge, sauf en cas de collisions e trop importantes. 4.1.2 Format d’une “ Frame Ethernet ” Encapsulation Ethernet (RFC 894) Données encapsulées 8 6 6 2 46 à 1500 4 Type des données Checksum Adresse de la source Adresse de la destination Préambule de synchronisation figure I.03 — trame Ethernet 8 les cartes Ethernet modernes utilisent 4 fils au lieu de deux et offrent ansi des possi- bilit´s de “ full duplex ” que n’avaient pas leurs ancˆtres des ann´es 80 e e e
  • Couche 2 - Liaison (Data Link) 11 Quelques consid´rations en vrac : e – Dˆ au d´bit global de 10Mbits/seconde, le d´bit est de 10 bits par u e e micro-seconde (en gros un facteur 1000 avec un cpu). – Une trame a une longueur minimale (72) et une longueur maximale (1526). Si les donn´es ne sont pas assez longues (46 octets) des carac- e t`res de remplissage sont ajout´s (“ padding ”). e e – Les octets circulent du premier octet du pr´ambule au dernier octet du e CRC. A l’int´rieur de chaque octet le premier bit envoy´ est celui de poids e e faible, etc.. – Le pr´ambule et le SFD (“ Start Frame Delimiter ”) servent ` la syn- e a chronisation. – Adresses d’origine et de destination sont celles respectivement de la machine ´mettrice et de la machine destinatrice. e Remarque importante : il faut connaˆ l’adresse de son correspondant ıtre ` pour pouvoir lui envoyer un paquet ! A ce stade de l’expos´ on ne sait e pas encore comment faire quand on ignore cette information. – Le champ “ type ” est deux octets qui d´signent le type des donn´es e e encapsul´es : e Type Donn´es e 0800 IP 0806 ARP 0835 RARP 6000 DEC 6009 DEC 8019 DOMAIN ... ...4.1.3 Adresses IEEE 802.3 ou Ethernet Pour ces deux standards, l’adresse est cod´e sur 6 octets soit 48 bits. ePour un hˆte sur un r´seau, cette adresse est ce que l’on appelle son adresse o ephysique (“ hardware addresse ”) par opposition ` son adresse logique qui ainterviendra lors de l’examen de la couche 3. En fait cette adresse est divis´e en deux parties ´gales, les trois premiers e eoctets d´signent le constructeur, c’est le OUI (“ Organizationally Unique eIdentifier ”) distribu´ par l’IEEE 9 les trois derniers d´signent le num´ro de e e ecarte, dont la valeur est laiss´e ` l’initiative du constructeur qui poss`de le e a epr´fixe. e L’IEEE assure ainsi l’unicit´ de l’attribution des num´ros de construc- e e 24 10teurs, par tranches de 2 cartes Chaque constructeur assure l’unicit´ du num´ro de chaque carte fa- e e 9 http://standards.ieee.org/regauth/oui/index.shtml 10 La liste ` jour est accessible ` cette url http://standards.ieee.org/regauth/oui/ a aoui.txt ou ` la fin de la RFC 1700 (page 172) “ Ethernet vendors address components ” a
  • 12 R´seaux locaux e briqu´e. Il y a au maximum 224 cartes par classe d’adresses. e Cette unicit´ est primordiale car le bon fonctionnement d’un LAN requiert e que toutes les stations aient une adresse physique diff´rente. Dans le cas e contraire le r´seau et les applications qui l’utilisent auront un comportement e impr´visible le rendant impraticable. e Nous aurons l’occasion de rencontrer ` nouveau ce soucis d’unicit´ de a e l’adresse physique lorsque nous examinerons les protocoles ARP et RARP (cf cours ARP/RARP pages 55 et 58) et avec CARP (“ Common Address Redundancy Protocol ”) lorsque nous parlerons des hˆtes virtuels, page 137. o Exemple d’adresse physique en repr´sentation hexad´cimale : e e 08:00:09:35:d5:0b 08:00:09 est attribu´ ` la firme Hewlett-Packard ea 35:d5:0b est l’adresse de la carte D’autres constructeurs, captur´s au hasard des r´seaux : e e 00:11:24 Apple Computer 00:00:0C Cisco Systems, Inc. 00:06:5B Dell Computer Corp. 08:00:20 Sun Microsystems AA:00:04 Digital Equipment Corporation 00:10:5A 3Com Corporation ... ... 4.1.4 Unicast, multicast et broadcast Dans la pluspart des technologies de LAN, toutes les stations peuvent ´couter toutes les trames qui leur parviennent. Beaucoup d’entres elles ne e leur sont pas destin´es, et s’il fallait que le syst`me d’exploitation qui g`re e e e l’interface r´seau s’interrompt ` chaque fois pour les examiner, il ne serait pas e a tr`s utilisable pour les applications de l’utilisateur, parceque tout le temps e interrompu par ces ´vˆnements r´seau. e e e Pour ´viter cette situation, le logiciel embarqu´ dans l’interface r´seau est e e e param´tr´ (par le syst`me d’exploitation) pour filtrer les paquets non voulus e e e car non n´cessaires au bon fonctionnement en r´seau. Ce param`trage peut e e e changer d’une station ` une autre. a Il est ´galement possible de ne pas filtrer, c’est une propri´t´ utilis´e e ee e par les analyseurs de trames, comme par exemple l’outil tcpdump. La carte fonctionne alors en mode dit “ promiscuous ”, qui n’est donc pas son mode de fonctionnement standard. Le filtrage s’appuie sur trois types d’adressages : unicast L’adresse MAC est constitu´e de la combinaison de 48 bits qui la e rend unique. Ce mode d’adressage est typique d’´changes entre deux e stations uniquement. C’est l’essentiel du trafic sur un LAN. Le filtrage peut s’effectuer en ne retenant que les trames qui ont l’adresse MAC de la station locale et donc ´carter les autres trames de type unicast. e
  • Couche 2 - Liaison (Data Link) 13broadcast Tous les bits de l’adresse MAC sont ` 1. a Toutes les stations d’un r´seau sont destinatrices de tels paquets, que e leur filtrage doit laisser passer, avec les inconvients cit´s pr´c´demment. e e e Ce mode d’adressage ne devrait ˆtre utilis´ par les protocoles qu’unique- e e ment quand il n’est pas possible de faire autrement. Par exemple pour obtenir une information que seule une station inconnue sur le LAN poss`de. C’est le cas des protocoles ARP et RARP (cf cours ARP/- e RARP pages 55 et 58) Utilis´ abusivement, le broadcast est une gˆne. e emulticast Il existe un pr´fixe particulier 01:00:5E, non d´di´e ` un e e e a constructeur car dit de “ multicast ”, que nous examinerons dans le cas d’IP page 42. Ce mode de d’adressage est r´serv´ le plus g´n´ralement ` la d´couverte e e e e a e passive (par l’´coute de messages d’avertissement) ou ` la recherche e a (par l’´mission de messages de sollicitation) de voisins de LAN ayant e des propri´t´s particuli`res. ee e Le filtrage des sollicitations et leurs r´ponses peut ˆtre configur´ ` la e e ea carte sur chaque station, en fonction des imp´ratifs et besoins de fonc- e tionnement. Ce mode de fonctionnement est assez ´conome des ressources du r´seau, e e puisqu’une seule station ´met une information qui est trait´e par toutes e e celles qui sont int´ress´es, et elles seules. e e Toutes les adresses qui ne sont ni du type broadcast ni du type multicastsont du type unicast.4.2 Diff´rences Ethernet - 802.2/802.3 e MAC LLC SNAP Données dest. source 1 1 1 3 2 38 à 1492 6 6 2 4 dest. source RFC 894 figure I.04 — Diff´rences Ethernet 802.2/802.3 e – On remarque que le champ “ taille ” de la trame 802.3 est ` la place a du champ “ type ” de la trame Ethernet. La diff´renciation s’effectue e ` partir de la valeur de ces deux octets. On remarque ´galement que a e le commit´ 802 a choisi de subdiviser la couche 2 ISO en deux sous e couches : MAC et LLC.
  • 14 R´seaux locaux e – Tous les num´ros de protocole sont sup´rieurs ` 150011 qui est la lon- e e a gueur maximale des donn´es encapsul´es. Donc une valeur inf´rieure e e e ou ´gale ` ce seuil indique une trame 802.3. e a MAC = “ Medium Access Control ” Cette couche est concern´e par la gestion de l’adresse physique de la e technologie de LAN employ´e (comme “ token-ring ” par exemple) e LLC = “ Logical Link Control ” D´finit ce qui est n´cessaire aux multiples couches sup´rieures possibles e e e pour utiliser et partager les ressources du lan en mˆme temps. e Le commit´ 802.2 a ´galement pr´vu plusieurs options, dont deux prin- e e e cipalement utilis´es : e LLC type 1 Les trames sont d´livr´es en mode datagramme c’est ` dire selon e e a le principe du “ best effort ” (on fait au mieux sans garantie de r´sultat). e LLC type 2 Les trames sont d´livr´es avec une garantie de bon acheminement. e e L’usage du LLC de type 2 entraˆ l’ajout de champs dans l’en- ıne tˆte pour num´roter les paquets, ajouter des acquittements, des e e synchronisations, etc. . .C’est le protocole HDLC comme “ High- level Data Link Control ”. Un travail qui est normalement d´volu ` la couche de transport et e a qui donc parasite beaucoup la lisibilit´ de l’ensemble. e 5 Interconnexion - Technologie ´l´mentaire ee LLC MAC Cable transceiver Bus Carte de coupleur Ethernet station Cable coaxial Couche réseau Couche liaison Couche physique figure I.05 — Interconnexion - Technologie ´l´mentaire ee 11 Le plus petit num´ro de protocole est celui d’IP : 0800 hexad´cimal. Ce qui fait en e e d´cimal : 8 × 162 + 0 × 161 + 0 × 160 = 2048 e
  • Interconnexion - Technologie ´l´mentaire ee 15 L’interconnexion ne se limite pas au niveau Ethernet. Quelques notions de technologie de base et donc tr`s succintes sont en´cessaires pour bien comprendre la suite de ce cours. e5.1 Raccordement Figure I.06 l’hˆte est raccord´ ` o e a Réseau locall’aide d’une prise de type “ vampire ” Prise "vampire"et d’un “ transceiver ”. Transceiver Dans cette technologie de rac-cordement, le support est un groscˆble jaune, dit encore “ Thick Ether- anet ” ou Ethernet standard, ou encore Carte réseau10Base5 (10 comme 10Mbits/s, Basecomme “ Baseband ”, 5 comme 500 Bus informatiquem`tres). e figure I.06 — Prise vampire5.1.1 10Base5Quelques particularit´s du 10Base5 : e – Longueur maxi est 500 m`tres, pour un maximum de 100 stations. e – C’est une “ vieille ” technologie tr`s bien normalis´e mais d´pass´e. e e e e – Pas de perturbation quand on ajoute une station : la pose d’une nou- velle prise n’interrompt pas la continuit´ du r´seau. e e – Coˆt non n´gligeable. u e – D´placement d’une station non ais´, en plus on perd la prise vampire, e e elle reste sur le cˆble. a Pour les cˆblages rapides on pr´f`re le 10Base2 ou “ Thin Ethernet ” ou a eeencore Ethernet fin (2 comme 200 m`tres). e5.1.2 10Base2Quelques particularit´s du 10Base2 : e – Longueur maxi de 185 m`tres avec un maximum de 30 stations. e – La topologie impose de mettre les stations en s´rie avec un minimum e de 0.5 m`tre entre chaque. e – Le raccord se fait avec un “ transceiver ” en T (BNC bien connu des ´lectroniciens). e – Il faut un bouchon de 50 ohms ` chaque extr´mit´ du r´seau (2). a e e e – Technique tr`s bon march´, souple, les cartes int`grent le transducteur. e e e – Il faut rompre la continuit´ du r´seau pour ajouter une nouvelle sta- e e tion, ce qui l’empˆche de fonctionner durant l’op´ration. C’est un in- e e
  • 16 R´seaux locaux e conv´nient de taille sur un r´seau tr`s utilis´. e e e e – Cette technique est en outre assez sensible aux perturbations ´lectro- e magn´tiques. e Les d´savantages du 10Base2 imposent g´n´ralement l’usage du 10BaseT e e e dans toute structure d´passant quelques machines (5 ` 10). Le 10BaseT r`gle e a e d´finitivement le probl`me de l’ajout ou du retrait d’une machine sur le LAN e e (T comme “ Twisted Pair ” ou paires torsad´es). e Cette technique impose l’usage d’une boite noire r´seau nomm´e e e “ HUB ”12 ou moyeu. Celle-ci simule la continuit´ dans le cas du retrait e d’une station. 5.1.3 10BaseT Quelques particularit´s du 10BaseT : e – Une double paire torsad´e de cˆble suffit. e a – La longueur maximale entre le moyeu et la station est de 100 m`tres.e – Le moyeu impose une architecture en ´toile. e – Le raccordement au transducteur se fait ` l’aide d’une prise du type a RJ45, tr`s fragile (ne pas marcher dessus ! :). Le raccordement du HUB e (page 18) au reste du r´seau se fait par 10Base2, en fibre optique, ou e tout simplement par chaˆ ınage avec un autre HUB (“ Daisy chain ”). – Cette technique est d’une tr`s grande souplesse d’utilisation elle impose e n´anmoins l’acquisiton de HUB, tr`s peu on´reux de nos jours. e e e – Cette technique des paires torsad´es est tr`s sensible aux perturbations e e ´lectromagn´tiques. ´lectromagn´tiques. e e e e Aujourd’hui le 100BaseT ´quipe la majeur partie des ´quipements pro- e e fessionnels, 100 comme 100 Mbits/s. Enfin la fibre optique est utilis´e de plus en plus souvent pour effectuer e les liaisons point ` point. a 5.1.4 Fibre optique Quelques particularit´s de la fibre optique : e – La plus utilis´e est la fibre multimode 62.5/125.0 µm e – Usage d’un transducteur optique pour assurer la transformation entre le signal lumineux (un laser) et le signal ´lectrique. e – La distance maximale entre deux points est 1,5 km. – La fibre est insensible aux perturbations ´lectromagn´tiques, elle per- e e met en outre le cˆblage de site important (plusieurs km2 ). a – La fibre permet d’atteindre des vitesses de transmission sup´rieures e aux 10Mbits/100Mbits/1000Mbits maintenant courants sur des paires de fils en cuivre. – Les nouvelles technologies issues des recherches les plus r´centes pro- e mettent des fibres multifr´quences (1024 canaux par fibre) avec pour e 12 Voir au paragraphe 5.3 page 18
  • Interconnexion - Technologie ´l´mentaire ee 17 chaque canal une bande passante de plusieurs giga-octets. Ces nou- veaux m´dias auront une bande passante de plusieurs t´ra-octets par e e secondes. . . – Son principal d´savantage est un coˆt ´lev´ au m`tre (de l’ordre d’une e u e e e dizaine d’ pour un cˆble d’un m`tre cinquante) et la n´cessit´ d’avoir a e e e des transducteurs au raccordement de tous les appareils contenant de l’´lectronique (serveur, switch, routeur). Un tel module peut coˆter de e u l’ordre de 500 ` 1000  . . . a5.1.5 Conclusion Construire un r´seau local consiste ` juxtaposer des composants de base e atr`s bien maitris´, une sorte de m´cano car tous les supports sont mixables. e e e Ne plus installer les technologies les plus anciennes 10Base5, 10Base2 oumˆme 10BaseT, pr´f´rer l’usage du 100BaseT ou du 1000BaseT qui sont e eedevenus un standard courant du pr´cablage. e En effet le cˆblage constitue les fondations d’un r´seau, le faire propre- a ement d’embl´ ´vite une source continuelle d’ennuis pas la suite ! Les besoins eeen bande passante d’aujourd’hui ne pr´figurent sans doute pas encore les be- esoins de demain (vid´o haute d´finition sur tous les postes. . .), il faut donc e epr´voir tr`s large d`s la conception initiale. e e e Machine A Machine B Réseau physique Ethernet vs 802.2/802.3 Raccordement ==> dérivation du réseau figure I.07 — Technologie de liaison5.2 R´p´teur e e ` A une technologie particuli`re correspond forc´ment des limitations dues e eaux lois de la physique. Par exemple en technologie Ethernet la longueurmaximale d’un brin ne peut pas exc´der 180 m`tres. Pour pallier ` cette e e ad´ficience on utilise des r´p´teurs (“ repeaters ”). e e e
  • 18 R´seaux locaux e R´p´teurs : e e Répéteur R Brins physiques R différents mais meme LAN R figure I.08 — Plusieurs r´p´teurs mais toujours le mˆme lan e e e – Agit uniquement au niveau de la couche 1 ISO, c’est un “ amplificateur de ligne ” avec ses avantages et aussi l’inconv´nient de transmettre le e bruit sans discernement : il n’y a aucun filtrage sur le contenu. – Relie deux brins d’une mˆme technologie en un seul LAN car les trames e sont reproduites ` l’identique. a – En 10Base5, l’usage d’un r´p´teur fait passer la limite des 500 m`tres e e e ` 1000 m`tres... a e – Il n’y a aucune administration particuli`re, sinon de brancher la boite e noire ` un emplacement jug´ pertinent. a e – C’est un ´l´ment “ bon march´ ”. ee e 5.3 Concentrateur Un concentrateur (ou “ HUB ”, figure I.09 — Concentateur moyeu) : " Backbone " – Est aussi nomm´ ´toile ou mul- ee tir´p´teur. e e – Les HUB n’ont pas d’adresse Ethernet, sauf certains mod`les e HUB ´volu´s, g´rables ` distance e e e a (TELNET,SNMP,. . .). On parle alors de “ hubs intelli- gents ” parcequ’ils permettent d’associer des ports entres-eux. Prises RJ45 Stations à raccorder au réseau local
  • Interconnexion - Technologie ´l´mentaire ee 19 Un hub assure la continuit´ du r´seau sur chacune de ses prises, que l’on e ey branche ou pas un hˆte. En cela il agit uniquement au niveau de la couche o1 ISO. Il ne limite pas le nombre de collisions et n’am´liore pas l’usage de ela bande passante. Son seul int´rˆt est de donc permettre le branchement ou eele d´branchement des stations sans perturber le fonctionnement global du er´seau. e Les hubs peuvent ˆtre chaˆ es entres-eux ; souvent ils sont reli´s au back- e ın´ ebone local par une autre technologie que la paire torsad´e (fibre optique. . .). e Dans le cas de “ hubs intelligents ” les ports sont associ´s les uns aux eautres par groupes de fonctionnement.5.4 Ponts La technologie CSMA/CD atteint vite ses limites quand le r´seau est en- ecombr´. Une am´lioration possible quand on ne peut pas changer de technolo- e egie (augmentation du d´bit) est d’utiliser un ou plusieurs ponts (“ bridges ”) epour regrouper des machines qui ont entre-elles un dialogue privil´gi´. e eDialogue entre deux stations, sans pont : A B C D E Le dialogue entre A et B perturbe l’éventuel dialogue entre D et E. figure I.10 — Dialogue sans pont De nos jours le pont en tant que tel est de moins en moins utilis´ par econtre le principe de son fonctionnement se retrouve, entres autres, dansles commutateurs (paragraphe suivant) et dans les points d’acc`s sans fil e(“ wireless ”).Dialogue entre deux stations, avec pont : A B Pont intelligent C D E P Meme réseau local figure I.11 — Dialogue avec pont On peut remarquer que les ´changes locaux ` chaque branche du pont e as’effectuent au mieux des possibilit´ de la bande passante, le pont a donc e
  • 20 R´seaux locaux e multipli´ par deux la capacit´ globale du trafic r´seau vis ` vis de certains e e e a ´changes. e Un pont : – Agit au niveau de la couche 2 ISO, donc au niveau de la trame physique. Son action est plus que physique elle est aussi logique puisqu’il y a lecture et interpr´tation des octets v´hicul´s. Le r´sultat de ce travail e e e e logique (apprentissage) consiste ` isoler le trafic sur certains tron¸ons a c d’un LAN. A ` cause de ce travail on parle g´n´ralement de “ ponts e e intelligents ” ou de “ ponts transparents ” car la phase d’apprentissage est automatique ! – R´duit le taux de collisions en r´duisant le trafic inutile, donc am´liore e e e l’usage de la bande passante. Sur la figure I.11 les machines A et B peuvent dialoguer sans pertuber le dialogue entre les machines D et E. Par contre dans le cas d’un dialogue entre A et E le pont ne sert ` rien. a – Moins cher qu’un routeur et plus rapide (services rendus moins com- plets). – Relie deux segments (ou plus) en un seul LAN, les trames transmises sont reproduites ` l’identique. a – Un pont contient un cpu, il est en g´n´ral administrable ` distance car e e a on peut agir sur la table de filtrages (ajout, contraintes de filtrages, etc...). Dans ce cas un pont a une adresse Ethernet. – Les ponts interdisent que les r´seaux aient des boucles, un protocole e nomm´ STP (“ Spanning Tree Protocol ”) d´sactive automatiquement e e le ou les ponts qui occasionne(nt) un bouclage des trames. – Il existe des ponts entre Ethernet et Token-ring, on parle alors de “ ponts ` translations ”. a – Attention, un pont ne s’occupe que des adresses de type unicast, il ne filtre pas les types broadcast et multicast. – On peut remarquer que dans le cas de figure ou le trafic est strictement contenu d’un cot´ et de l’autre du pont, alors la bande passante globale e du LAN est multipli´e par deux. Bien sˆr cette remarque n’est plus e u valable d`s lors qu’une trame franchit le pont. e 5.5 Commutateurs Aligner des stations sur un mˆme r´seau local constitue une premi`re e e e ´tape simple et de faible coˆt pour un r´seau local d’entreprise. Le revers e u e d’une telle architecture est que le nombre de collisions croˆ tr`s vite avec ıt e le trafic, d’o` une baisse tr`s sensible de la rapidit´ des ´changes dˆe ` ce u e e e u a gaspillage de la bande passante. L’usage de ponts peut constituer une premi`re solution mais elle n’est pas e totalement satisfaisante dans tous les cas de figure, comme nous avons pu le remarquer au paragraphe pr´c´dent. e e Depuis plus d’une dizaine d’ann´es est apparue une technologie nomm´e e e “ Intelligent Switching Hub ” (ISH) – commutateur intelligent – qui utilise
  • Interconnexion - Technologie ´l´mentaire ee 21le concept de commutation parall`le et qui a r´volutionn´ l’organisation des e e er´seaux locaux. e D’aspect ext´rieur ces ´quipements se pr´sentent comme un hub mais ont e e een interne un cpu suffisamment puissant et un bus interne de donn´es suffi- esamment rapide pour mettre en œuvre une logique de commutation raffin´e. e Lorsqu’une trame se pr´sente sur l’un des ports du commutateur elle est e(ou n’est pas) re-rout´e vers un autre port en fonction de l’adresse physique edu destinataire. Il existe plusieurs diff´rences entre un pont et un commuta- eteur : – Un commutateur peut mettre simultan´ment plusieurs ports en rela- e tion, sans que le d´bit de chacun en souffre. Par exemple un commu- e tateur de 8 ports en 100BaseT peut supporter quatre connexions port source/port destination simultan´es ` 100 Mbit/s chacune, ce qui donne e a un d´bit global de 400 Mbit/s qui doit pouvoir ˆtre support´ par le bus e e e interne ou “ fond de panier ”. D’un point de vue plus th´orique, un commutateur ` N ports ` 100 e a a Mbit/s chacun a un d´bit maximum de N × 100/2 = 50 × N M bit/s. e – Si une trame est ` destination d’un port d´j` occup´, le commutateur a ea e la m´morise pour la d´livrer sitˆt le port disponible. e e o – Un commutateur fonctionne comme un pont pour ´tablir sa carte des e adresses mais il peut aussi travailler ` partir d’une table pr´configur´e. a e e – Un commutateur peut fonctionner par port (une seule station Ethernet par port) ou par segment (plusieurs stations Ethernet par port). Avec un commutateur, il est ais´ d’organiser un r´seau en fonction de e ela port´e des serveurs des postes clients associ´s. La figure I.12 illustre ce e eprincipe : Serveurs S1 S2 généraux Commutateur intelligent Hub Client 1 Serveur Client 2 local figure I.12 — Commutateur Le trafic r´seau entre le “ client 1 ” et le serveur “ S2 ” ne perturbe pas e
  • 22 R´seaux locaux e le trafic entre le “ client 2 ” et le serveur “ S1 ”. De mˆme le trafic entre le e “ client 1 ” et le “ serveur local ” n’est pas vu du “ client 2 ”. Les commutateurs ´tiquettent les trames avec un identificateur du VLAN e auquel elles appartiennent. Cette ´tiquette se r´sume par deux octets ajout´s e e e dans la trame, selon les recommandations du comit´ 802 (norme 802.1Q). e 5.6 Passerelles — Routeurs Pour raccorder deux LANs non forc´ment contigus il faut faire appel ` e a ce que l’on d´signe “ une passerelle ” (“ gateway ”). Son rˆle est de prendre e o une d´cision sur la route ` suivre et de convertir le format des donn´es pour e a e ˆtre compatible avec le r´seau ` atteindre (en fonction de la route). e e a Souvent, et c’est le cas avec TCP/IP, la fonction de conversion n’est pas utilis´e, la fonction de routage donne alors son nom ` l’appareil en question e a (´ponyme), qui devient un “ routeur ” (“ router ”). e Le probl`me du routage entre A et B : e B G G G A Plusieurs chemins sont possibles pour aller de A à B, d’où la nécessité d’une stratégie. figure I.13 — Fonction routage La fonction passerelle consiste aussi en traduction de protocoles : A B G G G X25 Ethernet Modem Token ring Liaison rtc figure I.14 — Traduction de protocoles Un routeur : – Agit au niveau de la couche 3. Il prend des d´cisions de destination. e
  • 6 Bibliographie 23 – Poss`de au moins deux interfaces r´seau (pas forc´ment identiques). e e e – Contient un cpu et un programme tr`s ´volu´, il est administrable ` e e e a distance. – Remplit ´galement les fonctions d’un pont (B-routeur) mais les brins e ainsi reli´s ne forment en g´n´ral plus un LAN car les adresses physiques e e e contenues dans les trames ne servent plus ` identifier le destinataire. Il a faut une autre adresse qui d´pend de la pile au-dessus (exemple adresse e IP). Il existe cependant des possibilit´s de simuler un mˆme LAN bien e e que les trame traversent un routeur (cf cours ARP (page 55)).6 BibliographiePour en savoir plus :RFC 0894 S C. Hornig, “ Standard for the transmission of IP datagrams over Ethernet networks ”, 04/01/1984. (Pages=3) (Format=.txt)RFC 1042 S J. Postel, J. Reynolds, “ Standard for the transmission of IP datagrams over IEEE 802 networks ”, 02/01/1988. (Pages=15) (Format=.txt) (Obsoletes RFC0948) – Radia Perlman — “ Interconnections – Briges and Routeurs ” — Addison–Wesley – Radia Perlman — “ Interconnections Second Edition ” – Briges, Rou- teurs, Switches, and Internetworking Protocoles — Addison–Wesley
  • 24 R´seaux locaux e
  • Chapitre II Introduction ` IP a1 TCP/IP et l’Internet - Un peu d’histoire ´ En 1969 aux Etats Unis, l’agence gouvernementale DARPA lance un pro-jet de r´seau exp´rimental, bas´ sur la commutation de paquets. Ce r´seau, e e e enomm´ ARPANET, fut construit dans le but d’´tudier les technologies de e ecommunications, ind´pendamment de toute contrainte commerciale1 e Un grand nombre de techniques de communication par modems datentde cette ´poque. e L’exp´rience d’ARPANET est alors si concluante que toutes les organi- esations qui lui sont rattach´es l’utilisent quotidiennement pour pour leurs emessages de service. En 1975, le r´seau passe officiellement du stade exp´rimental au stade e eop´rationnel. e Le d´veloppement d’ARPANET ne s’arrˆte pas pour autant, les bases des e eprotocoles TCP/IP sont d´velopp´s ` ce moment, donc apr`s que ARPANET e e a esoit op´rationnel. e En Juin 1978 Jon Postel2 d´finit IPv4 et en 1981 IP est standardis´ dans e ela RFC 791 [J. Postel 1981]. En 1983 les protocoles TCP/IP sont adopt´s comme un standard mi- elitaire et toutes les machines sur le r´seau commencent ` l’utiliser. Pour e afaciliter cette reconversion, la DARPA demande ` l’universit´ de Berkeley a ed’impl´menter ces protocoles dans leur version (BSD) d’unix. Ainsi com- emence le mariage entre ce syst`me d’exploitation et les protocoles TCP/IP. e L’apport de l’Universit´ de Berkeley est majeur, tant au niveau th´orique e e(concept des sockets) qu’au niveau de l’utilisateur, avec des utilitaires tr`s ehomog`nes qui s’int`grent parfaitement au paradigme d’usage existant (rcp, e e 1 Lanc´ en France en 1972, le projet “ Cyclades ”, sous la responsabilit´ de Louis Pouzin, e e´tait ´galement bas´ sur la commutation de paquets et l’usage de datagrammes. Il reliaite e equelques grands centres universitaires en France (Lille, Paris, Grenoble,. . .) et en Europe.Il est rest´ op´rationnel jusqu’en 1978, date ` laquelle faute de cr´dit il a ´t´ abandonn´ e e a e ee eau profit de X25, pr´f´r´ par les op´rateurs de t´l´coms nationaux. eee e ee 2 Jon Postel est d´c´d´ le 16 Octobre 1998 ` l’ˆge de 55 ans, c’est le premier pionner e e e a ade l’Internet d´c´d´, on peut consulter par exemple : http://www.isi.edu/postel.html e e e
  • 26 Introduction ` IP a rsh, rlogin. . .). Depuis cette ´poque, un nouveau terme est apparu pour d´signer cette e e interconnexion de r´seaux, l’Internet, avec un “ i ” majuscule. e Le succ`s de cette technologie est alors tr`s important et suscite un e e int´rˆt croissant de la part d’acteurs tr`s divers, et en particulier La “ Na- ee e tional Science Foundation ” qui y voit un int´rˆt majeur pour la recherche ee scientifique et soutient donc ce nouveau moyen de mettre en communication tous les chercheurs. Depuis 1990, ARPANET n’est plus, pourtant le terme Internet demeure il d´signe maintenant un espace de communication qui englobe la plan`te tout e e enti`re. Des millions de sites partout sur la surface du globe y sont connect´s. e e Depuis 1994, l’Internet s’est ouvert au commerce, surtout avec l’ap- parition en 1991 d’un nouvel outil de consultation, le “ World Wide Web ” ou “ Web ” et ses interfaces populaires : Mosaic3 , Netscape, Mozilla, Firefox, Konqueror. . . La liste n’est pas exhaustive ! Depuis 1995, pour faire face ` sa popularit´ fortement croissante et aux a e demandes de transactions s´curis´es, le protocole ´volue et une nouvelle ver- e e e sion, la version 6 (IPng puis tout simplement IPv6), est d´finie et en cours e de d´ploiement exp´rimental. e e Les protocoles d´sign´s par TCP/IP ont ´galement envahi les r´seaux e e e e locaux eux-mˆmes, car il est plus facile d’utiliser les mˆmes protocoles en e e interne et en externe. Pour les utilisateurs, l’acc`s ` l’Internet est possible ` l’aide d’une collec- e a a tion de programmes sp´cialis´s si faciles ` utiliser que l’on peut ignorer tout e e a (ou presque) de leur fonctionnement interne. Seul les programmeurs d’applications r´seaux et les administrateurs de e syst`mes ont besoin d’en connaˆ les arcanes. e ıtre Les services r´seaux les plus populaires sont principalement : e – Le courrier ´lectronique qui permet l’´change de messages entres usa- e e gers. – Les innombrables forums de discussion (“ news ”). – Le transfert de fichiers entre machines (“ ftp ” et ses d´riv´s comme e e “ fetch ”, “ wget ”, “ curl ”. . .). – Le “remote login ”, ou ses ´quivalents crypt´s (“ ssh ”, qui permet ` un e e a utilisateur de se connecter sur un site distant, depuis son poste local. – Les serveurs inter-actifs. Les “ anciens ” se nommaient archie, gopher, veronica, wais... D´sormais ils sont rendus obsol`tes par le “ web ” e e (protocole http). – Puis maintenant la radio, la vid´oconf´rence, la r´alit´ virtuelle avec le e e e e VRML, le “ chat ”, les bourses d’´changes point ` point, les “ blogs ” e a forme ´volu´e des pages personnelles, etc . . . e e ... En conclusion de ce paragraphe sur l’historique on peut dire que l’Internet est une collection apparemment anarchique (il n’y a pas de structure hi´- e 3 http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html
  • 2 Caract´ristiques de TCP/IP e 27rarchique et centralis´e) de r´seaux inter-connect´s et appartenant ` divers e e e apropri´taires. e On distingue trois niveaux : les r´seaux au sein des organisations (lans), eles r´seaux r´gionaux et les r´seaux de transit. e e e Le site de l’Association Fnet indique quelques pointeurs int´ressants sur e 4l’historique de l’Internet (en anglais).2 Caract´ristiques de TCP/IP e Le succ`s de TCP/IP, s’il vient d’abord d’un choix du gouvernement eam´ricain, s’appuit ensuite sur des caract´ristiques int´ressantes : e e e 1. C’est un protocole ouvert, les sources (C) en sont disponibles gratui- tement et ont ´t´ d´velopp´s ind´pendamment d’une architecture par- ee e e e ticuli`re, d’un syst`me d’exploitation particulier, d’une structure com- e e merciale propri´taire. Ils sont donc th´oriquement transportables sur e e n’importe quel type de plate-forme, ce qui est prouv´ de nos jours. e 2. Ce protocole est ind´pendant du support physique du r´seau. Cela per- e e met ` TCP/IP d’ˆtre v´hicul´ par des supports et des technologies a e e e aussi diff´rents qu’une ligne s´rie, un cˆble coaxial Ethernet, une liai- e e a son lou´e, un r´seau token-ring, une liaison radio (satellites, “ wireless ” e e 802.11a/b/g), une liaison FDDI 600Mbits, une liaison par rayon laser, infrarouge, xDSL, ATM, fibre optique, la liste des supports et des tech- nologies n’est pas exhaustive. . . 3. Le mode d’adressage est commun ` tous les utilisateurs de TCP/IP a quelle que soit la plate-forme qui l’utilise. Si l’unicit´ de l’adresse est e respect´e, les communications aboutissent mˆme si les hˆtes sont aux e e o antipodes. 4. Les protocoles de hauts niveaux sont standardis´s ce qui permet des e d´veloppements largement r´pandus et inter-op´rables sur tous types e e e de machines. La majeurs partie des informations relatives ` ces protocoles sont publi´es a edans les RFCs (Requests For Comments). Les RFCs contiennent les derni`res eversions des sp´cifications de tous les protocoles TCP/IP, ainsi que bien ed’autres informations comme des propositions d’am´liorations des outils ac- etuels, la description de nouveaux protocoles, des commentaires sur la gestiondes r´seaux, la liste n’est pas exhaustive. e 4 http://www.fnet.fr/history/
  • 28 Introduction ` IP a 3 Comparaison TCP/IP — ISO La suite de protocoles d´sign´e par TCP/IP, ou encore “ pile ARPA ”, e e est construite sur un mod`le en couches moins complet que la proposition e de l’ISO. Quatre couches sont suffisantes pour d´finir l’architecture de ce e protocole. 4 Couche Application (Application layer). 3 Couche Transport (Transport layer). 2 Couche Internet (Internet layer). 1 Couche interface r´seau (Network access layer). e 0 Mat´riel (n’est pas une couche comprise dans le protocole). e Application Présentation 4 Application Session 3 Transport Pile Transport 2 Arpa Internet 1 Réseau Interface Liaison 0 Matériel Physique figure II.01 — Comparaison ISO-ARPA La figure II.01 met en comparaison les fonctionnalit´s des couches du e mod`le OSI et celles des protocoles TCP/IP. e La figure II.02 elle, donne une vue d’ensemble de l’architecture logicielle avec quelques protocoles d’applications de la famille IP. Ils sont tr`s nom- e breux, non repr´sent´s tous ici, et il s’en faut de beaucoup car il en existe des e e centaines. La lecture du fichier /etc/services, pr´sent sur toute machine e de la famille des Unix, donne un aper¸u des principaux services enregistr´s c e aupr`s de l’IANA. Quand nous aurons expliqi´ la notion “ port ” (cf page e e 81) cette lecture sera plus facile. . .Donc patience ! IP “ Internet Protocol ” SCTP “ Stream Control Transmission Protocol ” TCP “ Transmission Control Protocol ” UDP “ User Datagram Protocol ”
  • Comparaison TCP/IP — ISO 29 nfs Application xdr http smtp dns snmp rpc SCTP TCP UDP Transport arp Internet IP igmp icmp rarp + Interface fibre Infra Couche matérielle Ethernet ATM Wifi ... optique rouge non comprise dans Arpa figure II.02 — Architecture logicielle Les chapitres qui suivent donnent l’occasion d’examiner SMTP, DNS,SNMP, SCTP, TCP, UDP, ARP, RARP, IP, IGMP et ICMP !3.1 Couche “ Application Layer ” Au plus haut niveau les utilisateurs invoquent les programmes qui per-mettent l’acc`s au r´seau. e e Chaque programme d’application interagit avec la couche de transportpour envoyer ou recevoir des donn´es. En fonction des caract´ristiques de e el’´change le programme a choisi un mode de transmission ` la couche de e atransport. La plus grande proportion des applications laissent ` la couche de trans- aport le soin d’effectuer le travail de “ Session ”, n´anmoins il est possible epour certaines applications de court-circuiter cette fonctionnalit´ pour agir edirectement au niveau “ R´seau ”, comme on peut l’observer sur la figure eII.02 ` droite. a3.2 Couche “ Transport Layer ” La principale tˆche de la couche de transport est de fournir la communi- acation d’un programme d’application ` un autre. Une telle communication aest souvent qualifi´e de “ point ` point ”. e a Cette couche peut avoir ` r´guler le flot de donn´es et ` assurer la fiabilit´ a e e a edu transfert : les octets re¸us doivent ˆtre identiques aux octets envoy´s. C’est c e epourquoi cette couche doit g´rer des “ checksums ” et savoir re-´mettre des e epaquets mal arriv´s.e Cette couche divise le flux de donn´es en paquets (terminologie de l’ISO) eet passe chacun avec une adresse de destination au niveau inf´rieur. e De plus, et c’est surtout valable pour les syst`mes d’exploitation multi- etˆches multi-utilisateurs (Unix,. . .), de multiples processus appartenant ` a ades utilisateurs diff´rents et pour des programmes d’applications diff´rents, e eacc`dent au r´seau au mˆme moment, ce qui implique la capacit´ de multi- e e e eplexer et de d´multiplexer les donn´es, suivant qu’elles vont vers le r´seaux e e e
  • 30 Introduction ` IP a ou vers les applications (“ Session ”). 3.3 Couche “ Internet Layer ” Cette couche re¸oit des data-grammes en provenance de la couche r´seau, c e qu’elle doit analyser pour d´terminer s’ils lui sont adress´s ou pas. Dans e e le premier cas elle doit “ d´capsuler ” son en-tˆte du data-gramme pour e e transmettre les donn´es ` la couche de transport et au bon protocole de e a cette couche (TCP, UDP...), dans le deuxi`me cas elle les ignore. e Cette couche prend aussi en charge la communication de machine ` ma- a chine. Elle accepte des requˆtes venant de la couche de transport avec une e identification de la machine vers laquelle le paquet doit ˆtre envoy´. e e Elle utilise alors l’algorithme de routage (page 70) pour d´cider si le pa- e quet doit ˆtre envoy´ vers une passerelle ou vers une machine directement e e accessible. Enfin cette couche g`re les datagrammes des protocoles ICMP et IGMP. e 3.4 Couche “ Network Access ” Le protocole dans cette couche d´finit le moyen pour un syst`me de e e d´livrer l’information ` un autre syst`me physiquement reli´. Il d´finit com- e a e e e ment les data-grammes IP sont transmis. La d´finition de ceux-ci reste e ind´pendante de la couche r´seau, ce qui leur permet de s’adapter ` chaque e e a nouvelle technologie au fur et ` mesure de leur apparition. a Avant de s’int´resser au d´tail des data-grammes IP, nous allons examiner e e le probl`me de l’adressage IP, dans le chapitre suivant. e 4 Encapsulation d’IP A B Application Application Message Transport Transport Paquet Internet Internet Datagramme Network Network Trame Réseau physique
  • 5 Bibliographie 31 figure II.03 — Encapsulation d’IP Comme nous l’avons d´crit avec le mod`le des couches OSI, les couches e eIP fonctionnent par encapsulations progressives. Chaque couche en-capsule la pr´c´dente avec les informations de contrˆle e e oqu’elle destine ` la couche de mˆme niveau sur la machine distante. a e Cet ajout est nomm´ “ header ” (en-tˆte) parce-qu’il est plac´ en tˆte des e e e edonn´es ` transmettre. e a Application | datas | Transport | Header | datas | Internet | Header | Header | datas | Network | Header | Header | Header | datas | La taille des “ headers ” d´pend des protocoles utilis´s. Pour la couche e eIP le protocole comporte en standard 5 mots de 32 bits, mˆme chose pour la e 5couche TCP .5 BibliographiePour en savoir plus :RFC 0791 S J. Postel, “ Internet Protocol ”, 09/01/1981. (Pages=45) (Format=.txt) (Obsoletes RFC0760)La Recherche Num´ro sp´cial Internet num´ro 238 de f´vrier 2000 e e e e 5 5 mots de 32 bits = 5 × 4 octets = 20 octets
  • 32 Introduction ` IP a
  • Chapitre IIIAnatomie d’une adresse IP1 Adressage IP Nous avons dit que l’Internet est un r´seau virtuel, construit par intercon- enexion de r´seaux physiques via des passerelles. Ce chapitre parle de l’adres- esage, le maillon essentiel des protocoles TCP/IP pour rendre transparents lesd´tails physiques des r´seaux et faire apparaitre l’Internet comme une entit´ e e ehomog`ne. e1.1 Unicit´ de l’adresse e Un syst`me de communication doit pouvoir permettre ` n’importe quel e ahˆte de se mettre en relation avec n’importe quel autre. Afin qu’il n’y ait opas d’ambigu¨ e pour la reconnaissance des hˆtes possibles, il est absolument ıt´ on´cessaire d’admettre un principe g´n´ral d’identification. e e e Lorsque l’on veut ´tablir une communication, il est intuitivement indis- epensable de poss´der trois informations : e 1. Le nom de la machine distante, 2. Son adresse, 3. La route ` suivre pour y parvenir. a Le nom dit “ qui ” est l’hˆte distant, l’adresse nous dit “ o` ” il se trouve o uet la route “ comment ” on y parvient. En r`gle g´n´rale les utilisateurs pr´f`rent des noms symboliques pour e e e eeidentifier les machines tandis que les processeurs de ces mˆmes machines ne ecomprennent que les nombres exprim´s au format binaire. e Les adresses IP (version 4) sont standardis´es sous forme d’un nombre ede 32 bits qui permet ` la fois l’identification de chaque hˆte et du r´seau a o eauquel il appartient. Le choix des nombres composants une adresse IP n’estpas laiss´ au hasard, au contraire il fait l’objet d’une attention particuli`re e enotamment pour faciliter les op´rations de routage. e Nous ´ludons la correspondance entre ce nombre et une ´ventuelle e erepr´sentation symbolique, c’est l’objet du serveur de noms, une application eexamin´e page 165. e
  • 34 Anatomie d’une adresse IP Chaque adresse IP contient donc deux informations ´l´mentaires, une ee adresse de r´seau et une adresse d’hˆte. La combinaison des deux d´signe e o e de mani`re unique une machine et une seule sur l’Internet, sous r´serve que e e cette adresse ait ´t´ attribu´e par un organisme ayant pouvoir de le faire ! ee e 1.2 D´livrance des adresses IPv4 e On distingue deux types d’adresses IP : Les adresses priv´es que tout administrateur de r´seau peut s’attribuer e e librement pourvu qu’il(elle) ne cherche pas ` les router sur l’Internet a les adresses publiques d´livr´es par une structure mondiale qui en assure e e l’unicit´. Ce dernier point est capital pour assurer l’efficience du rou- e tage, comme nous le comprendrons en d´taillant le fonctionnement d’IP, e ` partir de la page 47. a Les adresses ` utiliser sur les r´seaux priv´s sont d´crites par la RFC 1918 : a e e e 10.0.0.01 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255 Les adresses publiques (souvent une seule), sont le plus g´n´ralement four- e e 2 nies par le FAI . Qu’elles soient d´livr´es de mani`re temporaire ou attribu´es e e e e pour le long terme, elles doivent ˆtre uniques sur le r´seau. La question est e e donc de savoir de qui le FAI les obtient. C’est L’ICANN ou “ Internet Corporation for Assigned Names and Num- bers3 ” qui est charg´ au niveau mondial de la gestion de l’espace d’adressage e IP. Il d´finit les proc´dures d’attribution et de r´solution de conflits dans l’at- e e e tribution des adresses, mais d´l`gue le d´tail de la gestion de ces ressources ee e ` des instances r´gionales puis locales, dans chaque pays, appel´es RIR ou a e e “ Regional Internet Registries ”. Il y a actuellement cinq “ Regional Internet Registries ” op´rationnels : e 4 5 l’APNIC pour la r´gion Asie-Pacifique, l’ARIN pour l’Am´rique, le e e RIPE NCC6 pour l’Europe, l’AfriNIC7 pour l’Afrique enfin LACNIC8 pour l’Am´rique Latine. e Pour ce qui nous concerne en Europe c’est donc le RIPE NCC (R´seaux e IP europ´en Network Coordination Centre) qui d´livre les adresses que nous e e utilisons. Les adresses IP sont allou´es ` l’utilisateur final qui en fait la demande e a par un “ Local Internet Registry ”, ou LIR, autoris´ par le RIPE NCC. e 2 Fournisseur d’Acc`s Internet e 3 http://www.icann.org 4 http://www.apnic.net 5 http://www.arin.net/ 6 http://www.ripe.net/ 7 http://www.afrinic.net/ 8 http://lacnic.net/
  • 2 Anatomie d’une adresse IP 35Un LIR est g´n´ralement un FAI ou une grande organisation (entreprise e emultinationale). Il est sous l’autorit´ de l’instance r´gionale de gestion de e el’adressage. Ainsi pour un utilisateur (quelle que soit sa taille) changer deFAI implique aussi de changer de plan d’adressage IP, lorsque celles-ci ont´t´ allou´es statiquement par le LIR. Les adresses IP sont alors restitu´esee e epuis r´-attribu´es ` d’autres utilisateurs. e e a On compte plus de 2000 de LIRs offrant leurs services en Europe se-lon le RIPE NCC9 . Le chiffre a forcement augment´ depuis 2003, avec el’´largissement des fronti`res europ´ennes. e e e2 Anatomie d’une adresse IP Une adresse IP est un nombre de 32 bits que l’on a coutume de repr´senter esous forme de quatre entiers de huit bits, s´par´s par des points (para- e egraphe 1.2). La partie r´seau de l’adresse IP vient toujours en tˆte, la partie hˆte est e e odonc toujours en queue. L’int´rˆt de cette repr´sentation est imm´diat quand on sait que la partie ee e er´seau et donc la partie hˆte sont presque toujours cod´es sur un nombre e o eentier d’octets. Ainsi, on a principalement les trois formes suivantes :Classe A Un octet r´seau, trois octets d’hˆtes. e oClasse B Deux octets r´seau, deux octets d’hˆtes. e oClasse C Trois octets r´seau, un octet d’hˆte. e o2.1 D´composition en classes e Classe Nombre de réseaux/machines Pour distinguer les classes A, B, 1.x.y.z à 127.x.y.z C, D et E il faut examiner les bits de A 127 réseaux 16 777 216 machines (2^24) poids fort de l’octet de poids fort : 128.0.x.y à 191.255.x.y Si le premier bit est 0, l’adresse B 16 384 réseaux (2^14) est de classe A. On dispose de 7 bits 65536 machines (2^16) pour identifier le r´seau et de 24 bits e 192.0.0.z à 223.255.255.z C 2 097 152 réseaux (2^21) pour identifier l’hˆte. On a donc les o 256 machines (2^8) r´seaux de 1 ` 127 et 224 hˆtes pos- e a o sibles, c’est ` dire 16 777 216 ma- a D 224.0.0.0 à 239.255.255.255 chines diff´rentes (de 0 ` 16 777 215). e a Les lecteurs attentifs auront re- E 240.0.0.0 à 247.255.255.255 marqu´ que le r´seau 0 n’est pas uti- e e lis´, il a une signification particuli`re e e figure III.01 — (“ tous les r´seaux ”). Plus de d´tails e e D´composition en classes e au paragraphe 2.2. 9 http://www.ripe.net/ripe/docs/ar2003.html
  • 36 Anatomie d’une adresse IP De mˆme, la machine 0 n’est pas utilis´e, tout comme la machine ayant e e le plus fort num´ro dans le r´seau (tous les bits de la partie hˆte ` 1, ici e e o a 16 777 215), ce qui r´duit de deux unit´s le nombre des machines nommables. e e Il reste donc seulement 16 777 214 machines adressables dans une classe A ! Si les deux premiers bits sont 10 , l’adresse est de classe B. Il reste 14 bits pour identifier le r´seau et 16 bits pour identifier la machine. Ce e 14 qui fait 2 = 16 384 r´seaux (128.0 ` 191.255) et 65 534 (65 536 − 2) e a machines. Si les trois premiers bits sont 110 , l’adresse est de classe C. Il reste 21 bits pour identifier le r´seau et 8 bits pour identifier la machine. Ce e 21 qui fait 2 = 2 097 152 r´seaux (de 192.0.0 ` 223.255.255) et 254 e a (256 − 2) machines. Si les quatre premiers bits de l’adresse sont 1110 , il s’agit d’une classe d’adressage sp´ciale, la classe D. Cette classe est pr´vue pour e e faire du “ multicast ”, ou multipoint. (RFC 1112 [S. Deering, 1989]), contrairement aux trois premi`res classes qui sont d´di´es ` l’“ unicast ” e e e a ou point ` point. a Ces adresses forment une cat´gorie ` part, nous en reparlons au para- e a graphe 3. Si les quatre premiers bits de l’adresse sont 1111 , il s’agit d’une classe exp´rimentale, la classe E. La RFC 1700 pr´cise “ Class E ad- e e dresses are reserved for future use ” mais n’indique pas de quel futur il s’agit. . . Enfin, pour conclure ce paragraphe, calculons le nombre d’hˆtes adres- o sables th´oriquement ` l’aide des classes A, B et C : e a 10 127 × 16777212 + 16384 × 65534 + 2097152 × 254 = 3737091588 Ce total, pour ˆtre plus exact, doit ˆtre amput´ des 17 890 780 hˆtes des e e e o 11 r´seaux priv´s pr´vus dans la RFC 1918 , soit donc tout de mˆme au total e e e e 3 719 200 808 hˆtes adressables en utilisant IPv4 ! o 10 Sous shell, tapez : echo "127*16777212+16384*65534+2097152*254"|bc 11 16777212 + 16 × 65534 + 256 × 254 = 17890780
  • Anatomie d’une adresse IP 372.2 Adresses particuli`res eCertaines adresses IP ont une signification particuli`re ! e Par convention le num´ro 0 d’hˆte n’est pas attribu´. Si une adresse IP e o econtient cette zone nulle cela signifie que l’on adresse le r´seau lui-mˆme et e eaucun hˆte en particulier, donc en r`gle g´n´rale l’hˆte lui-mˆme. o e e e o e De mˆme, pour toutes les pile Arpa l’adresse 127.0.0.1 indique la ma- echine elle-mˆme (“ localhost ” – Voir chapitre IP page 47), ind´pendamment e edes autres adresses r´seaux ´ventuellement attribu´es ` n’importe lequel de e e e ases interfaces. ` A l’inverse, si tous les bits de la partie hˆte sont ` 1, cela d´signe toutes o a eles machines du r´seaux, c’est ce que l’on appele une adresse de “ broadcast ”, ec’est ` dire une information adress´e ` tout le monde. a e a On ´vite au maximum l’usage d’une telle adresse IP sur les r´seaux, pour e edes raisons d’efficacit´ (encombrement de la bande passante). eQuelques exemples d’adresses avec une signification particuli`re : e 0.0.0.0 Hˆte inconnu, sur ce r´seau o e 0.0.0.1 L’hˆte 1 de ce r´seau o e 255.255.255.255 Tous les hˆtes o 138.195.52.1 L’hˆte 52.1 du r´seau 138.195.0.0 o e 138.195.0.0 Cet hˆte sur le 138.195.0.0 o 193.104.1.255 Tous les hˆtes du 193.104.1.0 o 127.0.0.1 Cet hˆte (boucle locale). o Remarque : les deux premi`res adresses, avec un num´ro de r´seau ´gal ` e e e e a0, ne peuvent figurer que comme adresse source dans des cas bien particulierscomme le d´marrage d’une station (cf chapitre IP page 47 et les travaux epratiques associ´s). e
  • 38 Anatomie d’une adresse IP 2.3 Sous-r´seaux e En 1984 un troisi`me niveau de hi´rarchie est mis en place : le “ subnet ” e e ou sous-r´seau. pour permettre aux administrateurs de g´rer plus finement e e de grands r´seaux. La RFC 950 [J. Mogul, J. Postel, 1985] donne plus de e pr´cisions, la RFC 1878 [T. Pummill & B. Manning, 1995] est une table de e tous les sous-r´seaux possibles. e Hostid de Dans la figure III.02 ci-contre, les la classe C bits 6 et 7 de la partie “ host ” sont 31 24 23 16 15 8 76 5 0 utilis´s pour caract´riser un sous- e e 193 104 1 r´seau. e hostid (6 bits) Quelques r´visions des propri´t´s e ee réduit des 2 bits Netid de la du subnet id des puissances de 212 sont souvent la classe C n´cessaires pour bien assimiler ce pa- e subnet id (2 bits) ragraphe. La figure suivante en rap- netmask (les 2 bits de poids fort) : 255.255.255.192 = 0xFFFFFFC0 pelle les valeurs pour les huit premiers exposants : figure III.02 — Sous-r´seaux e figure III.03 — Puissances de 2 Le “ subnet ” utilise les bits 7 6 5 4 3 2 1 0 de poids fort de la partie hˆte de o 128 64 32 16 8 4 2 1 l’adresse IP, pour d´signer un r´seau. e e Le nombre de bits employ´s est laiss´ e e Décomposition unique : ` l’initiative de l’administrateur. a 255 = 128 + 64 + 32 + 16 +8 + 4 + 2 + 1 Nous avons d’une part 27 + 26 = 192, et d’autre part 25 + 24 + 23 + 22 + 2 + 20 = 6313 . Ce qui permet de caract´riser 4 sous-r´seaux de 62 machines 1 e e (63 moins l’adresse de broascast, le “ 0 ” n’´tant pas compt´). Le calcul des e e masques et des adresses de diffusion est expliqu´ dans le tableau suivant : e Num´ro du r´seau e e “ Netmask ” “ Broadcast ” Adressage hˆte o 193.104.1.00 255.255.255.192 00 + 63 = 63 .1 ` .62 a 193.104.1.64 255.255.255.192 64 + 63 = 127 .65 ` .126 a 193.104.1.128 255.255.255.192 128 + 63 = 191 .129 ` .190 a 193.104.1.192 255.255.255.192 192 + 63 = 255 .193 ` .254 a 12 et plus g´n´ralement de la d´composition d’un nombre en ses facteurs premiers. . . e e e 13 Donc 64 valeurs possibles de 0 ` 63 a
  • Sous-r´seaux e 39 Soit un total de 62 × 4 = 248 hˆtes possibles pour cette classe C avec un o 14masque de sous-r´seau , au lieu des 254 hˆtes sans. e o La machine d’adresse 1 sur chaque sous-r´seau, aura comme adresse IP : e Sous-r´seau Adresse e D´composition e 00 193.104.1.1 00 + 1 = 1 01 193.104.1.65 64 + 1 = 65 10 193.104.1.129 128 + 1 = 129 11 193.104.1.193 192 + 1 = 193 Si vous pensez avoir tout compris, le remplissage du tableau suivant dansle cas de la classe C 192.168.192.0 et avec 3 bits pour d´finir les sous-r´seaux e ene devrait pas vous poser de probl`me. . . e Num´ro e Num´ro e Adresse Premi`re Derni`re e e du subnet du r´seau e de broadcast machine machine 000(0) 192.168.192. 192.168.192. 001(1) 192.168.192. 192.168.192. 010(2) 192.168.192. 192.168.192. 011(3) 192.168.192. 192.168.192. 100(4) 192.168.192. 192.168.192. 101(5) 192.168.192. 192.168.192. 110(6) 192.168.192. 192.168.192. 111(7) 192.168.192. 192.168.192.`A toutes ces adresses il faudra appliquer le masque de sous-r´seau : e 0xFFFFFF soit encore 255.255.255. Remarque : On pourra v´rifer que la perte d’espace d’adressage pour eadresser des hˆtes se calcule avec la relation (2n −1)×2, o` n est le nombre de o ubits du masque. Ainsi avec 3 bits de masque de sous-r´seau, la perte d’espace ed’adressage s’´l`ve ` 14 hˆtes ! Les 254 possibilit´s (256 moins 0 et 255) de ee a o enum´rotation de la classe C se r´duisent ` 240, amput´es de 31, 32, 63, 64, e e a e95, 96, 127, 128, 159, 160, 191, 192, 223 et 224. 14 “ netmask ”
  • 40 Anatomie d’une adresse IP 2.4 CIDR En 1992 la moiti´ des classes B ´taient allou´es, et si le rythme avait e e e continu´, au d´but de 1994 il n’y aurait plus eu de classe B disponible et e e l’Internet aurait bien pu mourrir par asphyxie ! De plus la croissance du nombre de r´seaux se traduisait par un usage “ aux limites ” des routeurs, e proches de la saturation car non pr´vus au d´part pour un tel volume de e e routes (voir les RFC 1518 et RFC 1519). Deux consid´rations qui ont conduit l’IETF a mettre en place le “ Class- e less InterDomain Routing ” ou CIDR ou encore routage Internet sans classe, bas´ sur une constatation de simple bon sens : e – S’il est courant de rencontrer une organisation ayant plus de 254 hˆtes, o il est moins courant d’en rencontrer une de plus de quelques milliers. Les adresses allou´es sont donc des classes C contig¨es, attribu´es par e u e r´gion ou par continent. En g´n´rale, 8 ` 16 classes C mises bout ` e e e a a bout suffisent pour une entreprise. Ces blocs de num´ros sont souvent e appell´s “ supernet ”. e Ainsi par exemple il est courant d’entendre les administrateurs de r´seaux parler d’un “ slash 22 ” (/22) pour d´signer un bloc de quatre e e classes C cons´cutives. . . e – Il est plus facile de pr´voir une table de routage pour un bloc de r´seaux e e contig¨es que d’avoir ` le faire pour une multitude de routes indivi- u a duelles. En plus cette op´ration all`ge la longueur des tables. e e Plus pr´cisement, trois caract´ristiques sont requises pour pouvoir utiliser e e ce concept : 1. Pour ˆtre r´unies dans une mˆme route, des adresses IP multiples e e e doivent avoir les mˆmes bits de poids fort (seuls les bits de poids plus e faible diff`rent)de poids faibles diff`rent. e e 2. Les tables de routages et algorithmes doivent prendre en compte un masque de 32 bits, ` appliquer sur les adresses. a 3. Les protocoles de routage doivent ajouter un masque 32 bits pour chaque adresse IP (Cet ajout double le volume d’informations) trans- mise. OSPF, IS-IS, RIP-2, BGP-4 le font. Ce masque se manifeste concrˆtement comme dans la re´criture du e e tableau du paragraphe 1.2 : 10.0.0.0 10.255.255.255 10/8 172.16.0.0 172.31.255.255 172.16/12 192.168.0.0 192.168.255.255 192.168/16 Le terme “ classless ” vient de ce fait, le routage n’est plus bas´ uni- e quement sur la partie r´seau des adresses. e
  • Pr´cisions sur le broadcast e 41Les agr´gations d’adresses sont ventil´es selon le tableau suivant15 : e e Multir´gionales e 192.0.0.0 193.255.255.255 Europe 194.0.0.0 195.255.255.255 Autres 196.0.0.0 197.255.255.255 Am´rique du Nord e 198.0.0.0 199.255.255.255 Am´rique centrale, e Am´rique du Sud e 200.0.0.0 201.255.255.255 Zone Pacifique 202.0.0.0 203.255.255.255 Autres 204.0.0.0 205.255.255.255 Autres 206.0.0.0 207.255.255.2552.5 Pr´cisions sur le broadcast e Tout d’abord il faut pr´ciser qu’une adresse de broadcast est forc´ment e eune adresse de destination, elle ne peut jamais apparaˆ comme une adresse ıtresource dans un usage normal des r´seaux. eQuatre formes possibles de broadcast :“ Limited broadcast ” (255.255.255.255) Une telle adresse ne peut ser- vir que sur le brin local et ne devrait jamais franchir un routeur. Ce n’est malheureusement pas le cas (pr´cisions en cours). e L’usage de cette adresse est normalement limit´e ` un hˆte en phase e a o d’initialisation, quand il ne connait rien du r´seau sur lequel il est e connect´.e“ Net-directed broadcast ” Tous les bits de la partie hˆte sont ` 1. Un o a routeur propage ce type de broadcast, sur option.“ Subnet-directed broadcast ” C’est le mˆme cas que ci-dessus mais e avec une adresses IP comportant des subnets.“ All-subnets-directed broadcast ” C’est le cas o` tous les bits des sub- u nets et hˆtes sont ` 1. Ce cas possible th´oriquement est rendu obsol`te o a e e depuis la RFC 922 (1993). 15 Ce tableau est tr`s synth´tique, pour une information plus d´taill´e et ` jour consultez e e e e ale site de l’IANA http://www.iana.org/assignments/ipv4-address-space
  • 42 Anatomie d’une adresse IP 3 Adressage multicast En r`gle g´n´rale l’adressage multicast est employ´ pour s’adresser en une e e e e seule fois ` un groupe de machines. a Dans le cas d’un serveur vid´o/audio, cette approche induit une ´conomie e e de moyen et de bande passante ´vidente quand on la compare ` une d´marche e a e “ unicast ” : un seul datagramme est rout´ vers tous les clients int´ress´s au e e e lieu d’un envoi massif d’autant de datagrammes qu’il y a de clients. Les adresses de type “ multicast ” ont donc la facult´ d’identifier un e groupe de machines qui partagent un protocole commun par opposition ` un a groupe de machines qui partagent un r´seau commun. e La plupart des adresses multicast allou´es le sont pour des applications e particuli`res comme par exemple la d´couverte de routeurs (que nous verrons e e ult´rieurement lors du routage IP) ou encore la radio ou le t´l´phone/vid´o e ee e sur Internet (“ Mbone ”). Parmi les plus souvent utilis´es16 sur un lan : e 224.0.0.1 Toutes les machines sur ce sous-r´seau e 224.0.0.2 Tous les routeurs sur ce sous-r´seau e 224.0.0.5 Tous les routeurs OSPF (page 121) 224.0.0.9 Tous les routeurs RIPv2 (page 113) 224.0.0.22 Protocole IGMP (page 63) 3.1 Adresse de groupe multicast Si une adresse multicast d´marre avec les bits 1110 par contre pour les 28 e bits suivants son organisation interne diff`re de celle des classes A, B et C. e "Multicast group address" 1 1 1 0 4 bits 28 bits "Multicast group ID" figure III.04 — Adresses de multicast – Les 28 bits n’ont pas de structure particuli`re par contre on continue ` e a utiliser la notation d´cimale point´e : 224.0.0.0 ` 239.255.255.255. e e a – Un groupe d’hˆtes qui partagent un protocole commun utilisant une o adresse multicast commune peuvent ˆtre r´partis n’importe o` sur le e e u r´seau. e – L’appartenance ` un groupe est dynamique, les hˆtes qui le d´sirent a o e rejoignent et quittent le groupe comme ils veulent. – Il n’y a pas de restriction sur le nombre d’hˆtes dans un groupe et o un hˆte n’a pas besoin d’appartenir ` un groupe pour lui envoyer un o a message. 16 Pour plus de pr´cisions on pourra se reporter page 56 de la RFC 1700 e
  • Adresse multicast et adresse MAC 433.2 Adresse multicast et adresse MAC Une station Ethernet quelconque doit ˆtre configur´e pour accepter le e emulticast, c’est ` dire pour accepter les trames contenant un datagramme amunis d’une adresse IP de destination qui est une adresse multicast. Cette op´ration sous entend que la carte r´seau sait faire le tri entre les e etrames. En effet les trames multicast ont une adresse MAC particuli`re : elles ecommencent forc´ment par les trois octets 01:00:5E17 . Ceux-ci ne d´signent e epas un constructeur en particulier mais sont poss´d´s par l’ICANN (ex e eIANA). Restent trois octets dont le bit de poids fort est forc´ment ` 0 pour e ad´signer les adresses de multicast (contrainte de la RFC 1700), ce qui conduit eau sch´ma suivant : e 5 bits non insérables dans l’adresse MAC. 0 7 8 15 16 23 24 31 1 1 10 01 : 00 : 5E Les 23 bits de poids faible du "group Id" de l’adresse 0 00 0 0 0 01 0 0 0 0 0 0 0 0 01 01 1 1 1 0 0 figure III.05 — Adresse physique de multicast Du fait qu’il n’y a pas assez de place dans l’adresse MAC pour faire tenirles 28 bits du groupe multicast, cette adresse n’est pas unique. On peut mˆme epr´ciser que pour chaque trame comportant une adresse multicast il y a 25 eadresses IP de groupes multicast possibles ! Ce qui signifie que si les 23 bits de poids faible ne suffisent pas ` discri- aminer la trame il faudra faire appel au pilote de p´riph´rique ou ` la couche e e aIP pour lever l’ambigu¨ e.ıt´ Quand une trame de type multicast est lue par la station Ethernet puispar le pilote de p´riph´rique, si l’adresse correspond ` l’une des adresses e e ade groupe multicast pr´alablement configur´es, le datagramme franchit la e ecouche IP et une copie des donn´es est d´livr´e aux processus qui ont “ joint e e ele groupe multicast ”. La question est de savoir comment les trames de type multicast atteignentjustement cette station Ethernet ? La r´ponse se trouve dans un protocole enomm´ IGMP et que nous examinerons dans le prochain chapitre concernant eIP, page 63. 17 Cf RFC 1700 page 171
  • 44 Anatomie d’une adresse IP 4 Conclusion et bibliographie Pour conclure ce chapitre sur l’adressage IP, il faut nous donner quelques pr´cisions suppl´mentaires. e e Jusqu’` pr´sent nous avons d´sign´ un hˆte par son adresse IP. Cette a e e e o d´marche n’est pas exacte si on consid`re par exemple le cas d’une passerelle, e e connect´e physiquement ` au moins deux r´seaux diff´rents, avec une adresse e a e e IP dans chacun de ces r´seaux. e On dira donc maintenant qu’une adresse IP identifie non pas un hˆte mais o un interface. La r´ciproque n’est pas vraie car un mˆme interface peut collec- e e tionner plusieurs adresses IP. Toutes permettent d’atteindre cet interface, on parle alors d’“ alias IP ”, d’“ hˆtes virtuels ” et de “ r´seaux virtuels ”. . .Nous o e aurons l’occasion de revenir sur ces notions ` la fin de ce cours (page 137). a On dit d’une machine ayant au moins deux adresses IP qu’elle est du type “ multi-homed ”. En g´n´ral une passerelle qui met en relation n r´seaux poss`de n adresses e e e e IP diff´rentes (une dans chaque r´seau), mais ce n’est pas une obligation (nous e e verrons quelle peut en ˆtre l’utilit´ ` la fin de ce cours). e ea A B Application Application Messages identiques Transport Paquets identiques Transport Passerelle G Internet Internet Internet Réseau Réseau Réseau Réseau physique Réseau physique 1 2 figure III.06 — Usage combin´ des adresses logique et physique e La figure III.06 met en situation deux hˆtes, A et B, en relation via une o passerelle G. Si les “ messages ” et les “ paquets ” sont identiques, par contre les “ datagrammes ” et les “ trames ” diff`rent puisqu’il ne s’agit plus du e mˆme r´seau physique. D`s que nous aurons examin´ le fonctionnement de e e e e la couche IP nous reviendrons sur cette figure pour en expliquer le fonction- nement (voir page 76).
  • Conclusion et bibliographie 45Pour en savoir plus :RFC 0950 S J. Mogul, J. Postel, “ Internet standard subnetting proce- dure ”, 08/01/1985. (Pages=18) (Format=.txt) (STD 5)RFC 1112 S S. Deering, “ Host extensions for IP multicasting ”, 08/01/1989. (Pages=17) (Format=.txt) (Obsoletes RFC0988) (STD 5)RFC 1518 “ An Architecture for IP Address Allocation with CIDR ” Y. Rekhter, T. Li. September 1993. (Format : TXT=72609 bytes) (Sta- tus : PROPOSED STANDARD)RFC 1519 PS V. Fuller, T. Li, J. Yu, K. Varadhan, “ Classless Inter- Domain Routing (CIDR) : an Address Assignment and Aggregation Strategy ”, 09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338)RFC 1466 I E. Gerich, “ Guidelines for Management of IP Address Space ”, 05/26/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1366)RFC 1467 “ Status of CIDR Deployment in the Internet. ” C. Topolcic. August 1993. (Format : TXT=20720 bytes) (Obsoletes RFC1367) (Status : INFORMATIONAL)RFC 1700 “ Assigned Numbers. ” J. Reynolds, J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD)RFC 1878 “ Variable Length Subnet Table For IPv4. ” T. Pummill & B. Manning. December 1995. (Format : TXT=19414 bytes) (Obsoletes RFC1860) (Status : INFOR- MATIONAL)RFC 1918 “ Address Allocation for Private Internets. ” Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE)Quelques ouvrages qui font autorit´ : e – W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley – Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice–Hall – Christian Huitema - Le routage dans l’Internet - EYROLLES
  • 46 Anatomie d’une adresse IP
  • Chapitre IV Protocole IP1 Datagramme IP IP est l’acronyme de “ Internet Protocol ”, il est d´fini dans la RFC 791 eet a ´t´ con¸u en 1980 pour remplacer NCP (“ Network Control Protocol ”), ee cle protocole de l’Arpanet. Presque trente ans apr`s sa premi`re impl´mentation, ses limitations se e e efont de plus en plus p´nalisantes pour les nouveaux usages sur les r´seaux. e eAvant de le jeter aux orties, posons-nous la question de qui pouvait pr´voir e` cette ´poque o` moins de mille ordinateurs ´taient reli´s ensembles, quea e u e etrois d´cennies plus tard des dizaines de millions d’hˆtes l’utiliseraient comme e oprincipal protocole de communication ? Sa long´vit´ est donc remarquable et il convient de l’analyser de pr`s e e eavant de pouvoir le critiquer de mani`re constructive. e1.1 Structure de l’en-tˆte e Les octets issus de la couche 31 28 27 24 23 16 15 0de transport et encapsul´s ` l’aide e a SERVICE En−tete standard (5 mots de 4 octets) VERS HLEN TOTAL LENGTHd’un en-tˆte IP avant d’ˆtre pro- e e TYPEpag´s vers la couche r´seau (Ether- e e IDENTIFICATION FLAGS FRAGMENTnet par exemple), sont collectivement (3bits) OFFSET (13 bits)nomm´s “ datagramme IP ”, da- e TTL PROTO HEADER CHECKSUMtagramme Internet ou datagrammetout court. Ces datagrammes ont SOURCE IP ADDRESSune taille maximale li´e aux ca- eract´ristiques de propagation du sup- e DESTINATION IP ADDRESSport physique, c’est le “ MaximumTransfer Unit ” ou MTU. IP OPTIONS PADDING figure IV.01 — Structure du data-gramme IP DATA ....
  • 48 Protocole IP Quelques caract´ristiques en vrac du protocole IP : e – IP est le support de travail des protocoles de la couche de transport, UDP, TCP et SCTP. – IP ne donne aucune garantie quant au bon acheminement des donn´es e qu’il envoie. Il n’entretient aucun dialogue avec une autre couche IP distante, on dit aussi qu’il d´livre les datagramme “ au mieux ”. e – Chaque datagramme est g´r´ ind´pendamment des autres data- ee e grammes mˆme au sein du transfert des octets d’un mˆme fichier. Cela e e signifie que les datagrammes peuvent ˆtre m´lang´s, dupliqu´s, perdus e e e e ou alt´r´s ! ee Ces probl`mes ne sont pas d´tect´s par IP et donc il ne peut en informer e e e la couche de transport. – Les octets sont lus et transmis au r´seau en respectant le “ Network e Byte Order ” ou NBO (cf paragraphe 1.2) quelle que soit l’architecture cpu de l’hˆte. o – L’en-tˆte IP minimale fait 5 mots de 4 octets, soit 20 octets. S’il y a e des options la taille maximale peut atteindre 60 octets. 1.2 Network Byte Order Sur la figure IV.01 les bits les plus significatifs de chaque mot de quatre octets sont ` gauche (31. . .). Ils sont d’ailleurs transmis sur le r´seau dans a e cet ordre1 , c’est un standard, c’est le “ Network Byte Order ”. Toutes les architectures de CPU ne sont pas bˆties sur le mˆme mod`le : a e e 15 87 0 Un mot de deux octets : 0 1 Bits de poids fort (MSB) : 15 Bits de poids faible (LSB) : 0 "Big endian" "Little endian" ... ... A+1 octet 1 octet 0 A octet 0 octet 1 HP (hppa), Intel(i386) Croissance Sun (sparc) Digital(vax) des adresses Ibm, Apple (ppc) mémoire Motorola (68k) figure IV.02 — “ Big endian ” vs “ Little endian ” 1 Le lecteur ayant un acc`s aux sources d’une pile IP pourra aller consulter directe- e ment la structure de l’en-tˆte, par exemple le fichier /usr/src/sys/netinet/ip.h sur e une machine FreeBSD
  • Description de l’en-tˆte e 49 Les termes “ Big endian ” et “ Little endian ” indiquent quelle est laterminaison (“ end ”) de deux octets que l’on ´crit en premier le poids fort e(“ big ”), c’est aussi le sens de l’´criture humaine, ou le poids faible (“ little ”). e1.3 Description de l’en-tˆte eVERS 4 bits qui sp´cifient la version du protocol IP. L’objet de ce champ est la e v´rification que l’´metteur et le destinataire des datagrammes sont bien e e en phases avec la mˆme version. Actuellement c’est la version 4 qui est e principalement utilis´ sur l’Internet, bien que quelques impl´mentations e e de la version 6 existent et soient d´j` en exp´rimentation2 . ea eHLEN 4bits qui donnent la longueur de l’en-tˆte en mots de 4 octets. La e taille standard de cette en-tˆte fait 5 mots, la taille maximale fait : e (23 + 22 + 21 + 20 ) × 4 = 60 octets3TOTAL LENGTH Donne la taille du datagramme, en-tˆte plus donn´es. S’il y e e fragmentation (voir plus loin) il s’agit ´galement de la taille du fragment e (chaque datagramme est ind´pendant des autres). e La taille des donn´es est donc ` calculer par soustraction de la taille de e a l’en-tˆte. e 16 bits autorisent la valeur 65535. . .La limitation vient le plus souvent du support physique (MTU) qui impose une taille plus petite, sauf sur les liaisons de type “ hyperchannel ”.TYPE OF SERVICE vs DSCP/ECN Historiquement dans la RFC 791 ce champ est nomm´ TYPE OF SERVICE et joue potentiellement deux rˆles se- e o lon les bits examin´s (pr´s´ance et type de service). Pratiquement, la e ee pr´s´ance ne sert plus et la RFC 1349 d´finit 4 bits utiles sur les huit ee e (3 ` 6). Ceux-ci indiquent au routeur l’attitude ` avoir vis ` vis du a a a datagramme. Par exemple, des datagrammes d’un transfert de fichier (ftp) peuvent avoir ` laisser passer un datagramme rep´r´ comme contenant des ca- a ee ract`res frapp´s au clavier (session telnet). e e 0x00 - Service normal Transfert banal 0x10 bit 3,D Minimiser le d´lai e Session telnet 0x08 bit 4,T Maximiser le d´bit e Transfert ftp 0x04 bit 5,R Maximiser la qualit´ ICMP e 0x02 bit 6,C Minimiser le coˆt u “ news ” (nntp) L’usage de ces bits est mutuellement exclusif. Les nouveaux besoins de routage on conduit l’IETF a revoir la d´finition e de ce champ dans la RFC 3168. Celle ci partage les huit bits en deux parties, les premiers bits d´finissent le DSCP ou “ Differentiated Ser- e vices CodePoints ” qui est une version beaucoup plus fine des quatre 2 Nous examinerons les caract´ristiques de la version 6 d’IP ` la fin de ce cycle de cours e a 3 On encore plus simple (24 − 1) × 4
  • 50 Protocole IP bits ci-dessus. Les deux derniers bits d´finissent l’ECN ou “ Explicit e Congestion Notification ” qui est un m´canisme permettant de pr´venir e e les congestions, contrairement au m´canisme plus ancien bas´ sur les e e messages ICMP de type “ source quench ” (voir page 61) qui tente de r´gler le flux en cas de congestion. e Il faut noter que les protocoles de routage qui tiennent compte de l’´tat e des liaisons (OSPF,IS-IS. . .) sont susceptibles d’utiliser ce champ. Enfin la RFC 3168 indique que ces deux ´critures du champ ne sont e pas compatibles entre elles. . . IDENTIFICATION, FLAGS et FRAGMENT OFFSET Ces mots sont pr´vus pour e contrˆler la fragmentation des datagrammes. Les donn´es sont frag- o e ment´es car les datagrammes peuvent avoir ` traverser des r´seaux avec e a e des MTU plus petits que celui du premier support physique employ´. e Consulter la section suivante Fragmentation IP. TTL “ Time To Live ” 8 bits, 255 secondes maximum de temps de vie pour un datagramme sur le net. Pr´vu ` l’origine pour d´compter un temps, ce champ n’est qu’un comp- e a e teur d´cr´ment´ d’une unit´ ` chaque passage dans un routeur. e e e ea Couramment la valeur de d´part est 32 ou mˆme 64. Son objet est e e d’´viter la pr´sence de paquets fantˆmes circulant ind´finiment. . . e e o e Si un routeur passe le compteur ` z´ro avant d´livrance du datagramme, a e e un message d’erreur — ICMP (consultez le paragraphe 4) — est renvoy´ e ` l’´metteur avec l’indication du routeur. Le paquet en lui-mˆme est a e e perdu. PROTOCOL 8 bits pour identifier le format et le contenu des donn´es, un peu e comme le champ “ type ” d’une trame Ethernet. Il permet ` IP d’adres- a ser les donn´es extraites ` l’une ou l’autre des couches de transport. e a Dans le cadre de ce cours, nous utiliserons essentiellement ICMP(1), IGMP(2), IP-ENCAP(4), TCP(6), UDP(17), ESP(50), AH(51), et OSPF(89). La table de correspondance entre le symbole et le num´ro du protocole e est pr´sente sur tout syst`me d’exploitation digne de ce nom, dans le e e fichier /etc/protocols. HEADER CHECKSUM 16 bits pour s’assurer de l’int´grit´ de l’en-tˆte. Lors du e e e calcul de ce “ checksum ” ce champ est ` 0. a A la r´ception de chaque paquet, la couche calcule cette valeur, si elle ne e correspond pas ` celle trouv´e dans l’en-tˆte le datagramme est oubli´ a e e e (“ discard ”) sans message d’erreur. SOURCE ADDRESS Adresse IP de l’´metteur, ` l’origine du datagramme. e a DESTINATION ADDRESS Adresse IP du destinataire du datagramme. IP OPTIONS 24 bits pour pr´ciser des options de comportement des e couches IP travers´es et destinatrices. Les options les plus courantes e concernent :
  • Description de l’en-tˆte e 51 – Des probl`mes de s´curit´ e e e – Des enregistrements de routes – Des enregistrements d’heure – Des sp´cifications de route ` suivre e a – ... Historiquement ces options ont ´t´ pr´vues d`s le d´but mais leur ee e e e impl´mentation n’a pas ´t´ termin´e et la plupart des routeurs filtrants e ee e bloquent les datagrammes IP comportant des options.PADDING Remplissage pour aligner sur 32 bits. . . En conclusion partielle que peut-on dire du travail de la couche IP ? 1. Il consiste ` router les datagrammes en les acheminant “ au mieux ”, a on verra plus loin de quelle mani`re. C’est son travail principal. e 2. Il peut avoir ` fragmenter les donn´es de taille sup´rieure au MTU du a e e support physique ` employer. a
  • 52 Protocole IP 1.4 Fragmentation IP - MTU La couche de liaison (Couche 2 “ Link ”) impose une taille limite, le “ Maximum Transfer Unit ”. Par exemple cette valeur est de 1500 pour une trame Ethernet, elle peut ˆtre de 256 avec SLIP (“ Serial Line IP ”) sur e liaison s´rie (RS232. . .). e Dans ces conditions, si la couche IP doit transmettre un bloc de donn´es e de taille sup´rieure au MTU ` employer, il y a fragmentation ! e a Par exemple, un bloc de 1481 octets sur Ethernet sera d´compos´ en un e e datagramme de 1480 (1480 + 20 = 1500) et un datagramme de 1 octet ! Il existe une exception ` cette op´ration, due ` la pr´sence active du bit a e a e “ Don’t Fragment bit ” du champ FLAGS de l’en-tˆte IP. La pr´sence ` 1 de e e a ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. C’est une situation de blocage, la couche ´mettrice est tenue e au courant par un message ICMP (cf paragraphe 4 page 59) “ Fragmenta- tion needed but don’t fragment bit set ” et bien sˆr le datagramme n’est pas u transmis plus loin. A G1 802.2 (1492) X25 (256) B G2 Ethernet (1500) figure IV.03 — Fragmentation IP 1.4.1 Fragmentation – Quand un datagramme est fragment´, il n’est r´assembl´ que par la e e e couche IP destinatrice finale. Cela implique trois remarques : 1. La taille des datagrammes re¸us par le destinataire final est direc- c tement d´pendante du plus petit MTU rencontr´. e e 2. Les fragments deviennent des datagrammes ` part enti`re. a e 3. Rien ne s’oppose ` ce qu’un fragment soit ` nouveau fragment´. a a e – Cette op´ration est absolument transparente pour les couches de trans- e port qui utilisent IP.
  • Fragmentation IP - MTU 53 – Quand un datagramme est fragment´, chaque fragment comporte la e mˆme valeur de champ IDENTIFICATION que le datagramme initial. e S’il y a encore des fragments, un des bits du champ FLAGS est positionn´ e ` 1 pour indiquer “ More fragment ” ! a Ce champ a une longueur de 3 bits. FRAGMENT OFFSET contient l’offset du fragment, relativement au data- gramme initial. Cet offset est cod´ sur 13 bits. e Offset : données transmises Ce qui reste à transmettre Le fragment à transmettre figure IV.04 — Fragment ` transmettre a Pour tous les fragments : – Les donn´es doivent faire un multiple de 8 octets, sauf pour le dernier e fragment, ´videment. e – Le champ TOTAL LENGTH change. – Chaque fragment est un datagramme ind´pendant, susceptible d’ˆtre e e ` son tour fragment´. a e Pour le dernier fragment : – FLAGS est remis ` z´ro. a e – Les donn´es ont une taille quelconque. e1.4.2 R´assemblage e – Tous les datagrammes issus d’une fragmentation deviennent des data- grammes IP comme (presque) les autres. – Ils arrivent ` destination, peut ˆtre dans le d´sordre, dupliqu´s. IP doit a e e e faire le tri. – il y a suffisamment d’information dans l’en-tˆte pour r´assembler les e e fragments ´pars. e – Mais si un fragment manque, la totalit´ du datagramme est perdu car e aucun m´canisme de contrˆle n’est impl´ment´ pour cela dans IP. e o e e C’est la raison principale pour laquelle il faut absolument ´viter de fragmenter un datagramme IP ! eLa figure IV.05 r´sume l’op´ration de fragmentation d’un datagramme IP. e e
  • 54 Protocole IP Datagramme 5 datagrammes différents initial H H1 H2 H3 H4 H5 0 N multiple entier de 8 N−1 N 2N 3N 4N M, reste de la division entière de L par 8. L octets à transmettre figure IV.05 — R´sum´ de la fragmentation e e H1 H2 H3 H4 H5 IDENTIFICATION I I I I I FLAG MF MF MF MF 0 OFFSET 0 N 2×N 3×N 4×N TOTAL LENGTH H +N H +N H +N H +N H +M HEADER CHECKSUM C1 C2 C3 C4 C5 Notez les variations de certains champs de l’en-tˆte : e 1. IDENTIFICATION est le mˆme pour tous e 2. FLAG est 0 pour le dernier datagramme 3. OFFSET croˆ de la taille du fragment, ici N. ıt 4. TOTAL LENGTH est g´n´ralement diff´rent pour le dernier fragment, sauf e e e cas particulier. 5. HEADER CHECKSUM change ` chaque fois car l’OFFSET change (rappel : a il ne tient pas compte des donn´es). e
  • 2 Protocole ARP 552 Protocole ARP ARP est l’acronyme de “ Address Resolution Protocol ”, il est d´finie dans ela RFC 826. – Le probl`me ` r´soudre est issu de la constatation qu’une adresse IP e a e n’a de sens que pour la suite de protocole TCP/IP ; celle-ci ´tant e ind´pendante de la partie mat´rielle il faut avoir un moyen d’´tablir e e e un lien entre ces deux constituants. – La norme Ethernet (vs IEEE) suppose l’identification unique de chaque carte construite et vendue4 . – Sur une mˆme liaison physique (lire plus loin “ mˆme LAN ”), Ether- e e net par exemple, deux machines peuvent communiquer ⇐⇒ elles connaissent leurs adresses physiques respectives. On suppose qu’une machine connait sa propre adresse physique par un moyen qui n’est pas d´crit ici (ne fait pas partie du protocole). e Remarque importante : Cette information n’a pas de sens dans le cadre d’une liaison de type “ point ` point ” avec un protocole tel que ppp. a – Lors du premier ´change entre 2 machines d’un mˆme LAN, si les e e adresses physiques ne sont pas d´j` connues (on verra pourquoi plus ea loin), la solution ` ce probl`me passe par l’usage du protocole ARP. a e – L’usage de ARP est compl`tement transparent pour l’utilisateur. e2.1 Fonctionnement A demande à toutes les stations : étant donné l’adresse IP de B, que vaut son adresse physique ? A X B Y Broadcast Ethernet (vs IEEE) figure IV.06 — Question ARP Sur la figure IV.06 la station Ethernet A (IA , PA ) a besoin de connaitrel’adresse physique de la station Ethernet B (IB , PB ), pour ce faire elle envoieun datagramme de format sp´cial (cf paragraphe suivant), d´di´ ` ARP, qui e e ealui permet de poser la question (“ Arp question ”) ` l’ensemble des machines aactives. L’adresse de la machine qui doit r´pondre ´tant l’objet de la ques- e etion, son adresse (champ destinataire) est donc remplac´e par une adresse de e“ broadcast ” (48 bits ` 1). a Toutes les machines du LAN ´coutent cet ´change et peuvent mettre ` e e ajour leur table de conversion (adresse IP adresse Ethernet) pour la machineA. 4 cf chapitre I “ R´seaux locaux ” e
  • 56 Protocole IP Le “ broadcast ”, coˆteux en bande passante, est ainsi utilis´ au maximum u e de ses possibilit´s. Sur la figure IV.07 la r´ponse de B est du type “ unicast ”. e e Remarque : quand une station Ethernet ne r´pond plus (cf ICMP) il y a e suppression de l’association adresse IP - adresse MAC. Réponse unicast. A X B Y B répond directement à A en lui communiquant son adresse physique. figure IV.07 — R´ponse ARP e Si la station B ne r´pond pas, la station continuera ` poser la question ` e a a intervals r´guliers pendant un temps infini. . . e Il n’est pas besoin d’utiliser ARP pr´alablement ` chaque ´change, car e a e heureusement le r´sultat est m´moris´. e e e En r`gle g´n´rale la dur´e de vie d’une adresse en m´moire est de l’ordre e e e e e de 20 minutes et chaque utilisation remet ` jour ce compteur. a La commande arp -a sous Unix permet d’avoir le contenu de la table de la machine sur laquelle on se trouve, par exemple : $ arp -a soupirs.chezmoi.fr (192.168.192.10) at 8:0:9:85:76:9c espoirs.chezmoi.fr (192.168.192.11) at 8:0:9:85:76:bd plethore.chezmoi.fr (192.168.192.12) at 8:0:9:a:f9:aa byzance.chezmoi.fr (192.168.192.13) at 8:0:9:a:f9:bc ramidus.chezmoi.fr (192.168.192.14) at 0:4f:49:1:28:22 permanent desiree.chezmoi.fr (192.168.192.33) at 8:0:9:70:44:52 pythie.chezmoi.fr (192.168.192.34) at 0:20:af:2f:8f:f1 ramidus.chezmoi.fr (192.168.192.35) at 0:4f:49:1:36:50 permanent gateway.chezmoi.fr (192.168.192.36) at 0:60:8c:81:d5:1b Enfin, et c’est un point tr`s important, du fait de l’utilisation de “ broad- e cast ” physiques, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous ´voquerons succinte- e ment ` la fin de ce paragraphe. a
  • Protocole ARP 572.2 Format du datagramme 31 16 15 0 HARDWARE TYPE PROTOCOL TYPE HLEN 1 HLEN 2 OPERATION SENDER HA (0 à 3) SENDER HA (4,5) SENDER ADR (0,1) SENDER ADR (2,3) TARGET HA (0,1) TARGET HA (2 à 5) TARGET ADR (0 à 3) figure IV.08 — Datagramme ARP Le datagramme ci-dessus est encapsul´ dans une trame physique du type e 50x0806 .HARDWARE TYPE pour sp´cifier le type d’adresse physique dans les champs e SENDER HA et TARGET HA, c’est 1 pour Ethernet.PROTOCOL TYPE pour sp´cifier le type d’adresse logique dans les champs e SENDER ADR et TARGET ADR, c’est 0x0800 (mˆme valeur que dans la e trame Ethernet) pour des adresses IP.HLEN 1 pour sp´cifier la longueur de l’adresse physique (6 octets pour Ether- e net).HLEN 2 pour sp´cifier la longueur de l’adresse logique (4 octets pour IP). eOPERATION ce champ pr´cise le type de l’op´ration, il est n´cessaire car la e e e trame est la mˆme pour toutes les op´rations des deux protocoles qui e e l’utilisent. Question R´ponse e ARP 1 2 RARP 3 4SENDER HA adresse physique de l’´metteur eSENDER ADR adresse logique de l’´metteur eTARGET HA adresse physique du destinataireTARGET ADR adresse logique du destinataire 5 voir ou revoir la figure II.02 du chapitre d’introduction ` IP (page 25) a
  • 58 Protocole IP 2.3 Proxy ARP Le proxy ARP permet l’extension du lan ` des hˆtes qui ne lui sont a o pas directement physiquement reli´s, mais qui s’y rattachent par exemple au e travers d’une passerelle. Un exemple tr`s courant est celui d’un hˆte qui acc`de ` un r´seau via un e o e a e dialup (rtc, num´ris,. . .). Le NetID de son adresse IP peut alors ˆtre le mˆme e e e que celui du r´seau rejoint, comme s’il y ´tait physiquement raccord´. Ce e e e subterfuge est rendu possible apr`s configuration ad´quate de la passerelle e e de raccordement. 3 Protocole RARP RARP est l’acronyme de “ Reverse Address Resolution Protocol ”, il est d´fini dans la RFC 903 (BOOTP et DHCP en sont des alternatives avec plus de e possibilit´s). e – Normalement une machine qui d´marre obtient son adresse IP par lec- e ture d’un fichier sur son disque dur (ou depuis sa configuration fig´e e dans une m´moire non volatile). e – Pour certains ´quipements cette op´ration n’est pas possible voire e e mˆme non souhait´e par l’administrateur du r´seau : e e e – Terminaux X Windows – Stations de travail “ diskless ” – Imprimante en r´seau e – “ Boites noires ” sans capacit´ autonome de d´marrage e e – PC en r´seau e – ... – Pour communiquer en TCP/IP une machine a besoin d’au moins une adresse IP, l’id´e de ce protocole est de la demander au r´seau. e e – Le protocole RARP est adapt´ de ARP : l’´metteur envoie une requˆte e e e RARP sp´cifiant son adresse physique dans un datagramme de mˆme e e format que celui de ARP et avec une adresse de “ broadcast ” physique. Le champ OPERATION contient alors le code de “ RARP question ” – Toutes les stations en activit´ re¸oivent la requˆte, celles qui sont ha- e c e bilit´s ` r´pondre (serveurs RARP) compl`tent le datagramme et le ren- e a e e voient directement (“ unicast ”) ` l’´metteur de la requˆte puisqu’elle a e e connaissent son adresse physique. Sur une machine Unix configur´e en serveur RARP les correspondances e entres adresses IP et adresses physiques sont enregistr´es dans un fichier e nomm´ g´n´ralement /etc/bootptab. e e e
  • 4 Protocole ICMP 594 Protocole ICMP ICMP est l’acronyme de “ Internet Control Message Protocol ”, il esthistoriquement d´fini dans la RFC 950. e Nous avons vu que le protocole IP ne v´rifie pas si les paquets ´mis sont e earriv´s ` leur destinataire dans de bonnes conditions. e a Les paquets circulent d’une passerelle vers un autre jusqu’` en trouver aune qui puisse les d´livrer directement ` un hˆte. Si une passerelle ne peut e a orouter ou d´livrer directement un paquet ou si un ´venement anormal arrive e esur le r´seau comme un trafic trop important ou une machine indisponible, eil faut pouvoir en informer l’hˆte qui a ´mis le paquet. Celui-ci pourra alors o er´agir en fonction du type de probl`me rencontr´. e e e ICMP est un m´canisme de contrˆle des erreurs au niveau IP, mais la e ofigure II.02 du chapitre d’introduction ` IP (page 25) montre que le niveau aApplication peut ´galement avoir un acc`s direct ` ce protocole. e e a4.1 Le syst`me de messages d’erreur e Dans le syst`me que nous avons d´crit, chaque passerelle et chaque hˆte e e oop`re de mani`re autonome, route et d´livre les datagrammes qui arrivent e e esans coordination avec l’´metteur. e Le syst`me fonctionne parfaitement si toutes les machines sont en ordre ede marche et si toutes les tables de routage sont ` jour. Malheureusement ac’est une situation id´ale. . . e Il peut y avoir des rupture de lignes de communication, des machinespeuvent ˆtre ` l’arrˆt, en pannes, d´connect´es du r´seau ou incapables de e a e e e erouter les paquets parcequ’en surcharge. Des paquets IP peuvent alors ne pas ˆtre d´livr´s ` leur destinataire et e e e ale protocol IP lui-mˆme ne contient rien qui puisse permettre de d´tecter cet e e´chec de transmission.e C’est pourquoi est ajout´ syst´matiquement un m´canisme de gestion des e e eerreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP6 etporte le num´ro de protocole 1. e Ainsi, quand un message d’erreur arrive pour un paquet ´mis, c’est la ecouche IP elle-mˆme qui g`re le probl`me, la plupart des cas sans en informer e e eles couches sup´rieures (certaines applications utilisent ICMP7 ). e Initialement pr´vu pour permettre aux passerelles d’informer les hˆtes sur e odes erreurs de transmission, ICMP n’est pas restreint aux ´changes passerelles- ehˆtes, des ´changes entres hˆtes sont tout ` fait possibles. o e o a Le mˆme m´canisme est valable pour les deux types d’´changes. e e e 6 voir ou revoir la figure II.02 du chapitre d’introduction ` IP (page 25) a 7 Mˆme figure qu’au point pr´c´dent e e e
  • 60 Protocole IP 4.2 Format des messages ICMP Chaque message ICMP traverse le r´seau dans la partie DATA d’un da- e tagramme IP : En−tete IP Message ICMP figure IV.09 — Message ICMP La cons´quence directe est que les messages ICMP sont rout´s comme e e les autres paquets IP au travers le r´seau. Il y a toutefois une exception : e il peut arriver qu’un paquet d’erreur rencontre lui-mˆme un probl`me de e e transmission, dans ce cas on ne g´n`re pas d’erreur sur l’erreur ! e e Il est important de bien voir que puisque les messages ICMP sont encap- sul´s dans un datagramme IP, ICMP n’est pas consid´r´ comme un protocole e ee de niveau plus ´lev´. e e La raison de l’utilisation d’IP pour d´livrer de telles informations, est que e les messages peuvent avoir ` traverser plusieurs r´seaux avant d’arriver ` leur a e a destination finale. Il n’´tait donc pas possible de rester au niveau physique e du r´seau (` l’inverse de ARP ou RARP). e a La figure IV.10 d´crit le format du message ICMP : e 31 24 23 16 15 0 TYPE CODE CHECKSUM EN−TETE du message original .. figure IV.10 — Format d’un message ICMP Chaque message ICMP a un type particulier qui caract´rise le probl`me e e qu’il signale. Un en-tˆte de 32 bits est compos´ comme suit : e e TYPE contient le code d’erreur. CODE compl`te l’information du champ pr´c´dent. e e e CHECKSUM est utilis´ avec le mˆme m´canisme de v´rification que pour les e e e e datagrammes IP mais ici il ne porte que sur le message ICMP (rappel : le checksum de l’en-tˆte IP ne porte que sur son en-tˆte et non sur les e e donn´es v´hicul´es). e e e En addition, les messages ICMP donnent toujours l’en-tˆte IP et les 64 pre- e miers bits (les deux premiers mots de quatre octets) du datagramme qui est ` a l’origine du probl`me, pour permettre au destinataire du message d’identifier e quel paquet est ` l’origine du probl`me. a e
  • Protocole ICMP 614.3 Quelques types de messages ICMP Ce paragraphe examine quelques uns des principaux types de messagesICMP, ceux qui sont le plus utilis´s. Il existe onze valeurs de TYPE diff´rentes. e e“ Echo Request (8), Echo reply (0) ” Une machine envoie un message ICMP “ echo request ” pour tester si son destinataire est accessible. N’importe quelle machine qui re¸oit une telle requˆte doit formuler un c e 8 message ICMP “ echo reply ” en retour Ce m´canisme est extrˆmement utile, la plupart des impl´mentations e e e le propose sous forme d’un utilitaire (ping sous Unix). Echo request(8) IP IP Echo reply(0) A B Y figure IV.11 — “ Echo request ” vs “ Echo reply ”“ Destination Unreachable (3) ” Quand une passerelle ne peut pas d´livrer un datagramme IP, elle envoie un message ICMP “ destination e unreachable ” ` l’´metteur. a e Dans ce cas le champ CODE compl`te le message d’erreur avec : e 0 “ Network unreachable ” 1 “ Host unreachable ” 2 “ Protocol unreachable ” 3 “ Port unreachable ” 4 “ Fragmentation needed and DF set ” 5 “ Source route failed ”“ Source Quench (4) ” Quand un datagramme IP arrive trop vite pour une passerelle ou un hˆte, il est rejet´. o e Un paquet arrive “ trop vite ” quand la machine qui doit le lire est congestionn´e, trop de trafic ` suivre.. . . e a Dans ce cas la machine en question envoie un paquet ICMP “ source quench ” qui est interpr´t´ de la fa¸on suivante : ee c L’´metteur ralenti le rythme d’envoi de ses paquets jusqu’` ce qu’il e a cesse de recevoir ce message d’erreur. La vitesse est donc ajust´e par e une sorte d’apprentissage rustique. Puis graduellement il augmente le d´bit, aussi longtemps que le message “ source quench ” ne revient pas e . 8 Pour des raisons de s´curit´ certaines machines peuvent ne pas r´pondre. e e e
  • 62 Protocole IP Ce type de paquet ICMP a donc tendance ` vouloir r´guler le flux des da- a e tagrammes au niveau IP alors que c’est une fonctionnalit´ de la couche e de transport (TCP). C’est donc une s´rieuse entorse ` la r`gle d’ind´pendance des couches. e a e e “ Redirect (5) ” Les tables de routage (Voir le paragraphe 6) des stations restent assez statiques durant de longues p´riodes. Le syst`me d’exploi- e e tation les lit au d´marrage sur le syst`me de fichiers et l’administrateur e e en change de temps en temps les ´l´ments. ee Si entre deux modifications une destination change d’emplacement, la donn´e initiale dans la table de routage peut s’av´rer incorrecte. e e Les passerelles connaissent de bien meilleures routes que les hˆtes eux- o mˆmes, ainsi quand une passerelle d´tecte une erreur de routage, elle e e fait deux choses : 1. Elle envoie ` l’´metteur du paquet un message ICMP “ redirect ” a e 2. Elle redirige le paquet vers la bonne destination. Cette redirection ne r`gle pas les probl`mes de routage car elle est li- e e mit´e aux interactions entres passerelles et hˆtes directement connect´s. e o e La propagation des routes aux travers des r´seaux multiples est un e autre probl`me. e Le champ CODE du message ICMP peut avoir les valeurs suivantes : 0 “ Redirect datagram for the Net ” 1 “ Redirect datagram for the host ” 2 ... “ Router solicitation (10) vs Router advertisement (9) ” Il s’agit d’obtenir ou d’annoncer des routes, nous verrons cela plus en d´tail e dans le paragraphe 6.4. “ Time exceeded (11) ” Chaque datagramme contient un champ TTL dit “ TIME TO LIVE ” appell´ aussi “ hop count ”. e Afin de pr´venir le cas ou un paquet circulerait ` l’infini d’une passerelle e a ` une autre, chaque passerelle d´cr´mente ce compteur et rejette le a e e paquet quand le compteur arrive ` z´ro et envoie un message ICMP ` a e a l’´metteur pour le tenir au courant. e
  • 5 Protocole IGMP 635 Protocole IGMP IGMP, l’acronyme de “ Internet Group Management Protocol ”, est histo-riquement d´fini dans l’Annexe I de la RFC 1112. e Sa raison d’ˆtre est que les datagrammes ayant une adresse multicast9 esont ` destination d’un groupe d’utilisateurs dont l’´metteur ne connait ni le a enombre ni l’emplacement. L’usage du multicast ´tant par construction d´di´ e e e 10aux applications comme la radio ou la vid´o sur le r´seau , donc consomma- e etrices de bande passante, il est primordial que les routeurs aient un moyen desavoir s’il y a des utilisateurs de tel ou tel groupe sur les LANs directementaccessibles pour ne pas encombrer les bandes passantes associ´es avec des eflux d’octets que personne n’utilise plus !5.1 Description de l’en-tˆte e IGMP est un protocole de communication entre les routeurs susceptibles detransmettre des datagrammes multicast et des hˆtes qui veulent s’enregistrer odans tel ou tel groupe. IGMP est encapsul´ dans IP11 avec le protocole num´ro e e2. Comme le montre la figureRomanchapter.12, sa taille est fixe (contrairement ` ICMP) : seulement 2 mots ade 4 octets. 31 28 27 24 23 16 15 0 Vers. Type Inutilisé Checksum sur 16 bits Adresse du groupe sur 32 bits figure IV.12 — En-tˆte IGMP eVersion Version 1.Type Ce champ prend deux valeurs, 1 pour dire qu’il s’agit d’une question (query d’un routeur), 2 pour dire qu’il s’agit de la r´ponse d’un hˆte. e oInutilis´ . . . eChecksum Le checksum est calcul´ comme celui d’ICMP. eAdresse C’est l’adresse multicast (classe D) ` laquelle appartient l’hˆte qui a o r´pond. e 9 Voir page 42 10 La premi`re exp´rience ` grande ´chelle du multicast fut sans doute la conf´rence de e e a e el’IETF en mars 1992. Le papier ftp ://venera.isi.edu/ietf-audiocast-article.psrelate cette exp´rience. e 11 voir ou revoir la figure II.02 du chapitre I d’introduction ` IP (page 25) a
  • 64 Protocole IP 5.2 Fonctionnement du protocole La RFC 1112 pr´cise que les routeurs multicast envoient des messages e de questionnement (Type=Queries) pour reconnaˆ quels sont les ´ventuels ıtre e hˆtes appartenant ` quel groupe. Ces questions sont envoy´es ` tous les hˆtes o a e a o des LANs directement raccord´s ` l’aide de l’adresse multicast du groupe e a 12 224.0.0.1 encapsul´ dans un datagramme IP ayant un champ TTL=1. Tous e les hˆtes susceptibles de joindre un groupe multicast ´coutent ce groupe par o e hypoth`se. e Les hˆtes, dont les interfaces ont ´t´ correctement configur´es, r´pondent o ee e e ` une question par autant de r´ponses que de groupes auxquels ils ap- a e partiennent sur l’interface r´seau qui a re¸u la question. Afin d’´viter une e c e “ tempˆte de r´ponses ” chaque hˆte met en œuvre la strat´gie suivante : e e o e 1. Un hˆte ne r´pond pas imm´diatement ` la question re¸ue. Pour chaque o e e a c groupe auquel il appartient, il attend un d´lais compris entre 0 et 10 e secondes, calcul´ al´atoirement ` partir de l’adresse IP unicast de l’in- e e a terface qui a re¸u la question, avant de renvoyer sa r´ponse. La figure c e Romanchapter.13 montre un tel ´change, remarquez au passage la va- e leur des adresses. 2. La r´ponse envoy´e est ´cout´e par tous les membres du groupe appar- e e e e tenant au mˆme LAN. Tout ceux qui s’appr´taient ` envoyer une telle e e a r´ponse au serveur en interrompent le processus pour ´viter une redite. e e Le routeur ne re¸oit ainsi qu’une seule r´ponse pour chaque groupe, et c e pour chaque LAN, ce qui lui suffit pour justifier le routage demand´. e Type= Report Src=IPA TTL=1 A Groupe=Adr. groupe M. Dst=Adr. groupe M. TTL=1 Src= IPG Type=Query G Dst=224.0.0.1 Groupe=0.0.0.0 IP IGMP figure IV.13 — Fonctionnement IGMP Il y a deux exceptions ` la strat´gie ci-dessus. La premi`re est que si une a e e question est re¸ue alors que le compte ` rebours pour r´pondre ` une r´ponse c a e a e est en cours, il n’est pas interrompu. La deuxi`me est qu’il n’y a jamais de d´lai appliqu´ pour l’envoi de da- e e e tagramme portant l’adresse du groupe de base 224.0.0.1. Pour rafraˆıchir leur connaissance des besoins de routage les routeurs en- voient leurs questions avec une fr´quence tr`s faible de l’ordre de la minute, e e 12 “ tous les hˆtes du LAN ” o
  • Protocole IGMP 65afin de pr´server au maximum la bande passante du r´seau. Si aucune r´ponse e e ene leur parvient pour tel ou tel groupe demand´ pr´c´dement, le routage s’in- e e eterrompt. Quand un hˆte rejoint un groupe, il envoie imm´diatement une r´ponse o e e(type=report) pour le groupe (les) qui l’int´resse, plutˆt que d’attendre une e oquestion du routeur. Au cas o` cette r´ponse se perdrait il est recommand´ u e ed’effectuer une r´´mission dans un court d´lai. ee eRemarques : 1. Sur un LAN sans routeur pour le multicast, le seul trafic IGMP est celui des hˆtes demandant ` rejoindre tel ou tel groupe. o a 2. Il n’y a pas de report pour quitter un groupe. 3. La plage d’adresses multicast entre 224.0.0.0 et 224.0.0.225 est d´di´e aux applications utilisant une valeur de 1 pour le champ TTL e e (administration et services au niveau du LAN). Les routeurs ne doivent pas transmettre de tels datagrammes. 4. Il n’y a pas de message ICMP sur les datagrammes ayant une adresse de destination du type multicast. En cons´quence les applications qui utilisent le multicast (avec une e adresse sup´rieure ` 224.0.0.225) pour d´couvrir des services, doivent e a e avoir une strat´gie pour augmenter la valeur du champ TTL en cas de e non r´ponse. e5.3 Fonctionnement du Mbone Pr´cisions en cours. . . e
  • 66 Protocole IP 6 Routage IP Ce paragraphe d´crit de mani`re succincte le routage des datagrammes. e e Sur l’Internet, ou au sein de toute entit´ qui utilise IP, les datagrammes ne e sont pas rout´s par des machines Unix, mais par des routeurs dont c’est la e fonction par d´finition. Ils sont plus efficaces et plus perfectionn´s pour cette e e tˆche par construction, et surtout autorisent l’application d’une politique de a routage (“ routing policy ”) ce que la pile IP standard d’une machine Unix ne sait pas faire. Toutefois il est courant dans les “ petits r´seaux ”, ou quand e le probl`me ` r´soudre reste simple, de faire appel ` une machine Unix pour e a e a 13 ce faire . Dans ce paragraphe nous examinons le probl`me du routage de mani`re e e synth´tique, nous l’aborderons plus en d´tail les aspects techniques du rou- e e tage dynamique au chapitre VII, page 109. Le routage des datagrammes se fait au niveau de la couche IP, et c’est son travail le plus important. Toutes les machines multiprocessus sont th´oriquement capables d’effectuer cette op´ration. e e La diff´rence entre un “ routeur ” et un “ hˆte ” est que le premier est e o capable de transmettre un datagramme d’un interface ` un autre et pas le a deuxi`me. e Cette op´ration est d´licate si les machines qui doivent dialoguer sont e e connect´es ` de multiples r´seaux physiques. e a e D’un point de vue id´al ´tablir une route pour des datagrammes de- e e vrait tenir compte d’´l´ments comme la charge du r´seau, la taille des da- ee e tagrammes, le type de service demand´, les d´lais de propagation, l’´tat des e e e liaisons, le trajet le plus court. . . La pratique est plus rudimentaire ! Il s’agit de transporter des datagrammes aux travers de multiples r´seaux e physiques, donc aux travers de multiples passerelles. On divise le routage en deux grandes familles : Le routage direct Il s’agit de d´livrer un datagramme ` une machine rac- e a cord´e au mˆme LAN. e e L’´metteur trouve l’adresse physique du correspondant (ARP), encap- e sule le datagramme dans une trame et l’envoie. Le routage indirect Le destinataire n’est pas sur le mˆme LAN comme e pr´c´dement. Il est absolument n´cessaire de franchir une passerelle e e e connue d’avance ou d’employer un chemin par d´faut. e En effet, toutes les machines ` atteindre ne sont pas forc´ment sur le a e mˆme r´seau physique. C’est le cas le plus courant, par exemple sur e e l’Internet qui regroupe des centaines de milliers de r´seaux diff´rents. e e Cette op´ration est beaucoup plus d´licate que la pr´c´dente car il faut e e e e s´lectionner une passerelle. e 13 On peut consulter par exemple http://www.freebsd.org/$sim$picobsd/, o` le site u du projet Zebra de GNU http://www.zebra.org/
  • Table de routage IP 67 Parceque le routage est une op´ration fondamentalement orient´e e e“ r´seau ”, le routage s’appuie sur cette partie de l’adresse IP du destina- etaire. La couche IP d´termine celle-ci en examinant les bits de poids fort qui econditionnent la classe d’adresse et donc la segmentation “ network.host ”.Dans certain cas (CIDR) le masque de sous r´seau est aussi employ´. e e Muni de ce num´ro de r´seau, la couche IP examine les informations e econtenues dans sa table de routage :6.1 Table de routage Sous Unix toutes les op´rations de routage se font grˆce ` une table, dite e a a“ table de routage ”, qui se trouve dans le noyau lui-mˆme. La figure IV.14 er´sume la situation : e Démons Commande Commande DHCP de routage route netstat ICMP Algorithme Couche IP de routage Table de routage figure IV.14 — Table de routage Cette table est tr`s fr´quemment utilis´e par IP : sur un serveur plusieurs e e ecentaines de fois par secondes. Comment est-elle cr´e ? e Au d´marrage avec la commande route, invoqu´e dans les scripts de e elancement du syst`me, et en fonctionnement : e – Au coup par coup avec la commande route, ` partir du shell (admi- a nistrateur syst`me uniquement). e – Dynamiquement avec les d´mons de routage “ routed ” ou “ gated ” e (la fr´quence de mise ` jour est typiquement de l’ordre de 30 sec.). e a
  • 68 Protocole IP – Par des messages “ ICMP redirect ”. La commande netstat -rn permet de la visualiser au niveau de l’inter- face utilisateur (“ Application layer ”) : $ netstat -rn Routing tables Internet: Destination Gateway Flags default 192.168.192.36 UGS 127.0.0.1 127.0.0.1 UH 192.168.192/27 link#1 UC 192.168.192.10 8:0:9:85:76:9c UHLW 192.168.192.11 8:0:9:85:76:bd UHLW 192.168.192.12 8:0:9:88:8e:31 UHLW 192.168.192.13 8:0:9:a:f9:bc UHLW 192.168.192.14 0:4f:49:1:28:22 UHLW 192.168.192.15 link#1 UHLW 192.168.192.32/27 link#2 UC 192.168.192.33 8:0:9:70:44:52 UHLW 192.168.192.34 0:20:af:2f:8f:f1 UHLW 192.168.192.35 0:4f:49:1:36:50 UHLW 192.168.192.36 link#2 UHLW On peut m´moriser cette table comme ´tant essentiellement compos´e e e e d’une colonne origine, d’une colonne destination. De plus, chaque route qui d´signe une passerelle (ici la route par d´faut) e e doit s’accompagner d’un nombre de sauts (“ hop ”), ou encore m´trique, qui e permet le choix d’une route plutˆt qu’une autre en fonction de cette valeur. o Chaque franchissement d’un routeur compte pour un saut. Dans la table ci-dessus, la m´trique de la route par d´faut est 1. e e Remarque : la sortie de la commande netstat -rn ci-dessus a ´t´ sim- ee 14 plifi´e. e Les drapeaux (“ flags ”) les plus courants : C c La route est g´n´r´e par la machine, ` l’usage. e ee a D La route a ´t´ cr´e dynamiquement (d´mons de routage). ee e e G La route d´signe une passerelle, sinon c’est une route directe. e H La route est vers une machine, sinon elle est vers un r´seau. e L D´signe la conversion vers une adresse physique (cf ARP). e M La route a ´t´ modifi´e par un “ redirect ”. ee e S La route a ´t´ ajout´e manuellement. ee e U La route est active. W La route est le r´sultat d’un clˆnage. e o 14 Des colonnes Refs, Use et Netif
  • Routage statique 69 La figure IV.15 pr´cise l’architecture du r´seau autour de la machine sur e elaquelle a ´t´ ex´cut´ le netstat. ee e e Subnet 000 .14 .35 Subnet 001 .36 M R link 1 link 2 figure IV.15 — Situation r´seau lors du netstat e6.2 Routage statique Comme nous avons pu le deviner au paragraphe pr´c´dent, les routes sta- e etiques sont celles cr´es au d´marrage de la machine ou ajout´es manuellement e e epar l’administeur syst`me, en cours de fonctionnement. e Le nombre de machines possibles ` atteindre potentiellement sur l’In- aternet est beaucoup trop ´lev´ pour que chaque machine puisse esp´rer en e e econserver l’adresse, qui plus est, mˆme si cela ´tait concevable, cette infor- e emation ne serait jamais ` jour donc inutilisable. a Plutˆt que d’envisager la situation pr´c´dente on pr´f`re restreindre o e e eel’´tendue du “ monde connu ” et utiliser la “ strat´gie de proche en proche ” e epr´c´dement cit´e. e e e Si une machine ne peut pas router un datagramme, elle connait (ou estsuppos´e connaˆ e ıtre) l’adresse d’une passerelle suppos´e ˆtre mieux inform´e e e epour transmettre ce datagramme. Dans l’exemple de sortie de la commande netstat du paragraphe 6.1,on peut reconnaˆ que l’administrateur syst`me n’a configur´ qu’une seule ıtre e e 15route “ manuellement ” , toutes les autres lignes ont ´t´ d´duites par la ee ecouche IP elle-mˆme. e La figure IV.16 met en situation plusieurs r´seaux et les passerelles qui eles relient. Voici une version tr`s simplifi´e des tables de routage statiques e epr´sentes sont les machines A, B, R1 et R2 : eMachine A default : 192.168.192.251Machine B default : 10.1.1.1Routeur R1 10 : 172.16.10.3Routeur R2 192.168.192 : 172.16.10.1 15 Ce n’est pas tout ` fait exact, nous verrons pourquoi au paragraphe concernant l’in- aterface de “ loopback ” (6.6).
  • 70 Protocole IP .251 .10.1 R1 172.16 .10.3 192.168.192 R2 .1.1.1 .1 A 1.1.23 10 B figure IV.16 — Exemple de nuage avec routage statique 6.2.1 Algorithme de routage Cet algorithme simplifi´ r´sume les op´rations de la couche IP pour choi- e e e sir une destination, en fonction de sa table de routage. Cette op´ration est e essentiellement bas´e sur le num´ro de r´seau, IN , extrait de l’adresse IP, ID . e e e M d´signe la machine sur laquelle s’effectue le routage. e Si IN est un num´ro de r´seau auquel M est directement reli´e : e e e – Obtenir l’adresse physique de la machine destinatrice – Encapsuler le datagramme dans une trame physique et l’envoyer di- rectement. Sinon Si ID apparait comme une machine ` laquelle une route sp´ciale est a e attribu´e, router le datagramme en fonction. e Sinon Si IN apparait dans la table de routage, router le datagramme en fonction. Sinon S’il existe une route par d´faut router le datagramme vers la e passerelle ainsi d´sign´e. e e Sinon D´clarer une erreur de routage (ICMP). e
  • Routage dynamique 716.3 Routage dynamique Si la topologie d’un r´seau offre la possibilit´ de plusieurs routes pour e eatteindre une mˆme destination, s’il est vaste et complexe, sujet ` des chan- e agements fr´quents de configuration. . .Le routage dynamique est alors un bon emoyen d’entretenir les tables de routages et de mani`re automatique. e Il existe de nombreux protocoles de routage dynamique dont certains sontaussi anciens que l’Internet. N´anmoins tous ne conviennent pas ` tous les e atypes de probl`me, il en existe une hi´rarchie. e e Sch´matiquement on peut imaginer l’Internet comme une hi´rarchie de e erouteurs. Les routeurs principaux (“ core gateways ”) de cette architectureutilisent entres-eux des protocoles comme GGP (“ Gateway to Gateway Pro-tocol ”), l’ensemble de ces routeurs forment ce que l’on nomme l’“ InternetCore ”. En bordure de ces routeurs principaux se situent les routeurs quimarquent la fronti`re avec ce que l’on nomme les “ Autonomous systems ”, ec’est ` dire des syst`mes de routeurs et de r´seaux qui poss`dent leurs a e e em´canismes propres de propagation des routes. Le protocole utilis´ par ces e erouteurs limitrophes est souvent EGP (“ Exterior Gateway Protocol ”) ouBGP (“ Border Gateway Protocol ”). Internet Core GGP Core Gateway Core Gateway EGP,BGP RIP,OSPF External gateways Autonomous Autonomous System System figure IV.17 — Exemple pour routage dynamique Au sein d’un syst`me autonome on utilise un IGP (“ Interior Gateway eProtocol ”) c’est ` dire un “ protocole de gateways int´rieurs ”. Les protocoles a eles plus couramment employ´s sont RIP (“ Routing Information Protocol ”) equi est simple ` comprendre et ` utiliser, ou encore OSPF (“ Open Shortest a aPath First ”) plus r´cent, plus capable mais aussi beaucoup plus complexe ` e acomprendre dans son mode de fonctionnement, ou encore IS-IS de la coucheISO de l’OSI.
  • 72 Protocole IP 6.3.1 RIP — “ Routing Information Protocol ” RIP est apparu avec la version BSD d’Unix, il est document´ dans lae RFC 1058 (1988 - Version 1 du protocole) et la RFC 1388 (1993 - Version 2 du protocole). Ce protocole est bas´ sur des travaux plus anciens men´s par e e la firme Xerox. RIP utilise le concept de “ vecteur de distance ”, qui s’appuie sur un algorithme de calcul du chemin le plus court dans un graphe. Le graphe est celui des routeurs, la longueur du chemin est ´tablie en nombre de sauts e (“ hop ”), ou m´trique, entre la source et la destination, c’est ` dire en e a comptant toutes les liaisons. Cette distance est exprim´e comme un nombre e entier variant entre 1 et 15 ; la valeur 16 est consid´r´e comme l’infini et ee indique une mise ` l’´cart de la route. a e Chaque routeur ´met dans un datagramme portant une adresse IP de e broadcast, ` fr´quence fixe (environ 30 secondes), le contenu de sa table de a e routage et ´coute celle des autres routeurs pour compl´ter sa propre table. e e Ainsi se propagent les tables de routes d’un bout ` l’autre du r´seau. Pour a e ´viter une “ tempˆtes de mises ` jours ”, le d´lais de 30 secondes est augment´ e e a e e d’une valeur al´atoire comprise entre 1 et 5 secondes. e Si une route n’est pas annonc´e au moins une fois en trois minutes, la e distance devient “ infinie ”, et la route sera retir´e un peu plus tard de la e table (elle est propag´e avec cette m´trique). e e L’adresse IP utilis´e est une adresse de multipoint (“ multicast ”) comme e nous verrons au paragraphe 6.4 Depuis la d´finition de RIPv2 les routes peuvent ˆtre accompagn´es du e e e masque de sous r´seau qui les caract´rise. Ainsi on peut avoir la situation e e suivante : Subnet 192.168.192.224 (netmask 0xFFFFFFE0) R1 Subnet 192.168.10.0 R2 R4 Subnet 192.168.11.0 R3 Subnet 192.168.192.64 (netmask 0xFFFFFFE0) figure IV.18 — Topologie pour routage dynamique Apr`s propagation des routes, la table de routage du routeur R1 pourrait e bien ressembler ` : a
  • D´couverte de routeur et propagation de routes e 73 Source Destination Coˆt u 192.168.192.224 R1 1 192.168.10.0 R1 1 192.168.11.0 R2 2 192.168.192.64 R3 3 Avec une route par d´faut qui est le routeur R2. La constitution de cette etable n’est possible qu’avec RIPv2 ´tant donn´ l’existence des deux sous- e er´seaux de la classe C 192.168.192. eLe fonctionnement de ce protocole est d´taill´ page 113 e e6.3.2 OSPF — “ Open Shortest Path First ” Contrairement ` RIP, OSPF n’utilise pas de vecteur de distances mais abase ses d´cisions de routage sur le concept d’“ ´tats des liaisons ”. Celui- e eci permet un usage beaucoup plus fin des performances r´elles des r´seaux e etravers´s, parceque cette m´trique est changeante au cours du temps. Si on e eajoute ` cela une m´thode de propagation tr`s rapide des routes par inon- a e edation, sans boucle et la possibilit´ de chemin multiples, OSPF, bien que ebeaucoup plus complexe que RIP, a toutes les qualit´s pour le remplacer, emˆme sur les tous petits r´seaux. e e OSPF doit son nom ` l’algorithme d’Edsger W. Dijkstra16 de recherche adu chemin le plus court d’abord lors du parcours d’un graphe. Le “ Open ”vient du fait qu’il s’agit d’un protocole ouvert de l’IETF, dans la RFC 2328. . .Le fonctionnement de ce protocole est d´taill´ page 121 e e6.4 D´couverte de routeur et propagation de routes e Au d´marrage d’une station, plutˆt que de configurer manuellement les e oroutes statiques, surtout si elle sont susceptibles de changer et que le nombrede stations est grand, il peut ˆtre int´ressant de faire de la “ d´couverte e e eautomatique de routeurs ” (RFC 1256). ` A intervals r´guliers les routeurs diffusent des messages ICMP de type 9 e(“ router advertisement ”) d’annonces de routes. Ces messages ont l’adressemulticast 224.0.0.1, qui est a destination de tous les hˆtes du LAN. o Toutes les stations capables de comprendre le multicast (et convenable-ment configur´es pour ce faire) ´coutent ces messages et mettent ` jour leur e e atable. Les stations qui d´marrent peuvent solliciter les routeurs si l’attente est etrop longue (environ 7 minutes) avec un autre message ICMP, de type 10(“ router sollicitation ”) et avec l’adresse multicast 224.0.0.2 (` destination ade tous les routeurs de ce LAN). La r´ponse du ou des routeurs est du type e“ unicast ”, sauf si le routeur s’apprˆtait ` ´mettre une annonce. e ae 16 http://www.cs.utexas.edu/users/EWD/
  • 74 Protocole IP ` A chaque route est associ´ un niveau de pr´f´rence et une dur´e de va- e ee e lidit´, d´finis par l’administrateur du r´seau. Une validit´ nulle indique un e e e e routeur qui s’arrˆte et donc une route qui doit ˆtre supprim´e. e e e Si entre deux annonces une route change, le m´canisme de “ ICMP redi- e rect ”, examin´ au paragraphe suivant, corrige l’erreur de route. e La d´couverte de routeur n’est pas un protocole de routage, son objectif e est bien moins ambitieux : obtenir une route par d´faut. e Il est int´ressant de noter sur les machines FreeBSD c’est le d´mon de e e 17 routage routed qui effectue ce travail ` la demande a 6.5 Message ICMP “ redirect ” La table de routage peut ˆtre modifi´e dynamiquement par un message e e ICMP (IV). La situation est celle de la figure IV.21. Station Datagramme 1 ICMP redirect Datagramme 2 R1 R2 figure IV.21 — ICMP “ redirect ” – La station veut envoyer un datagramme et sa table de routage lui com- mande d’utiliser la route qui passe par le routeur R1. – Le routeur R1 re¸oit le datagramme, scrute sa table de routage et c s’apper¸oit qu’il faut d´sormais passer par R2. Pour se faire : c e 1. Il re-route le datagramme vers R2, ce qui ´vite qu’il soit ´mis deux e e fois sur le LAN. 2. Il envoie un message “ ICMP redirect ” (type 5) ` la station, lui a indiquant la nouvelle route vers R2. Ce travail s’effectue pour chaque datagramme re¸u de la station. c – D`s que la station re¸oit le message “ ICMP redirect ” elle met ` jour sa e c a table de routage. La nouvelle route est employ´e pour les datagrammes e qui suivent (vers la mˆme direction). e La route modifi´e est visible avec la commande netstat -r, elle figure e avec le drapeau ’M’ (modification dynamique). Pour des raisons ´videntes de s´curit´, cette possibilit´ n’est valable que e e e e sur un mˆme LAN. e 17 ` A condition d’activer avec router enable=YES dans le fichier /etc/rc.conf.
  • Interface de “ loopback ” 756.6 Interface de “ loopback ” Toutes les impl´mentations d’IP supportent une interface de type e“ loopback ”. L’objet de cette interface est de pouvoir utiliser les outilsdu r´seau en local, sans passer par un interface r´seau r´el (associ´ ` une e e e e acarte physique). La figure IV.22 ci-contre, montre Internetque la couche IP peut utiliser, se- IPlon le routage, l’interface standard dur´seau, o` l’interface de loopback. e u Le routage est ici bien sˆr bas´ u esur l’adresse IP associ´e ` chacune e ades interfaces. Cette association est Réseaueffectu´e sur une machine Unix ` e al’aide de la commande ifconfig, qui´tablit une correspondance entre une Pilote de "loopback"pilote de p´riph´rique (rep´r´ par son e e ee Pilote de carte réseaufichier sp´cial) et une adresse IP. e Réseau physique Dans le cas du pilote de loopback,l’adresse est standardis´e ` n’importe e aquelle adresse valide du r´seau 127 e figure IV.22 — Interface de(page 37). “ loopback ” La valeur courante est 127.0.0.1, d’o` l’explication de la ligne ci-dessous ud´j` rencontr´e (page 67) dans le cadre de la table de routage : ea e Routing tables Internet: Destination Gateway Flags Netif ... 127.0.0.1 127.0.0.1 UH lo0 ... Dans toutes les machines Unix modernes cette configuration est d´j` eapr´vue d’embl´e dans les scripts de d´marrage. e e e Concr`tement, tout dialogue entre outils clients et serveurs sur une mˆme e emachine est possible et mˆme souhaitable sur cet interface pour am´liorer les e eperformances et parfois la s´curit´18 . e e L’exemple d’usage le plus marquant est sans doute celui du serveur denoms (voir page 165) qui tient compte explicitement de cet interface dans saconfiguration. 18 Nous verrons ult´rieurement (cf chapitre VIII) que le filtrage IP sur le 127/8 est aussi eais´ que sur n’importe quel autre r´seau e e
  • 76 Protocole IP 7 Finalement, comment ¸a marche ? c Dans ce paragraphe nous reprenons la figure III.06 (page 44) et nous y apportons comme ´tait annonc´ une explication du fonctionnement qui tienne e e compte des protocoles principaux examin´s dans ce chapitre. Pour cela nous e utilisons deux r´seaux priv´s de la RFC 1918 : 192.168.10.0 et 192.168.20.0 e e et nous faisons l’hypoth`se que la passerelle fonctionne comme une machine e Unix qui ferait du routage entre deux de ses interfaces ! A R B Internet Internet Internet Réseau Réseau Réseau .109 ifA ifR1 ifR2 ifB .69 .249 .249 192.168.10.0 192.168.20.0 figure IV.23 — Illustration du routage direct et indirect Ce tableau r´sume l’adressage physique et logique de la situation : e Interface Adresse MAC Adresse IP ifA 08:00:20:20:cf:af 192.168.10.109 ifB 00:01:e6:a1:07:64 192.168.20.69 ifR1 00:06:5b:0f:5a:1f 192.168.10.249 ifR2 00:06:5b:0f:5a:20 192.168.20.249 Nous faisons en outre les hypoth`ses suivantes : e 1. Les caches “ arp ” des machines A, B et R sont vides 2. La machine A a connaissance d’une route vers le r´seau 192.168.20 e passant par 192.168.10.249 et r´ciproquement la machine B voit le e r´seau 192.168.10.0 via le 192.168.20.249 e 3. La machine A a connaissance de l’adresse IP de la machine B La machine A envoie un datagramme ` la machine B, que se a passe t-il sur le r´seau ? e ´ Etape 1 La machine A applique l’algorithme de routage (page 70) et s’ap- per¸oit que la partie r´seau de l’adresse de B n’est pas dans le mˆme c e e LAN (192.168.10/24 et 192.168.20/20 diff`rent). e L’hypoth`se 2 entraine qu’une route route existe pour atteindre ce e r´seau, passant par R. L’adresse IP de R est dans le mˆme LAN, e e A peut donc atteindre R par un routage direct. La cons´quence de e l’hypoth`se 1 implique que pour atteindre R directement il nous faut e d’abord d´terminer son adresse physique. Le protocole ARP (page 55) e doit ˆtre utilis´. e e
  • Finalement, comment ¸a marche ? c 77 A envoie en cons´quence une trame ARP (page 57 comportant les e ´l´ments suivants : ee SENDER HA 08:00:20:20:cf:af SENDER ADR 192.168.10.109 TARGET HA ff:ff:ff:ff:ff:ff TARGET ADR 192.168.10.249 Avec un champ OPERATION qui contient la valeur 1, comme “ question ARP ”. Remarquez qu’ici l’adresse IP destination est celle de R !´Etape 2 R r´pond ` la “ question ARP ” par une “ r´ponse ARP ” e a e (OPERATION contient 2) et un champ compl`t´ : ee SENDER HA 00:06:5b:0f:5a:1f SENDER ADR 192.168.10.249 TARGET HA 08:00:20:20:cf:af TARGET ADR 192.168.10.109´Etape 3 A est en mesure d’envoyer son datagramme ` B en passant par R. a Il s’agit de routage indirect puisque l’adresse de B n’est pas sur le mˆme e LAN. Les adresses physiques et logiques se r´partissent maintenant e comme ceci : IP SOURCE 192.168.10.109 IP TARGET 192.168.20.69 MAC SOURCE 08:00:20:20:cf:af MAC TARGET 00:06:5b:0f:5a:1f Remarquez qu’ici l’adresse IP destination est celle de B !´Etape 4 R a re¸u le datagramme depuis A et ` destination de B. Celle-ci c a est sur un LAN dans lequel R se trouve ´galement, un routage direct e est donc le moyen de transf´rrer le datagramme. Pour la mˆme raison e e qu’` l’´tape 1 R n’a pas l’adresse MAC de B et doit utiliser ARP pour a e obtenir cette adresse. Voici les ´l´ments de cette “ question ARP ” : ee SENDER HA 00:06:5b:0f:5a:20 SENDER ADR 192.168.20.249 TARGET HA ff:ff:ff:ff:ff:ff TARGET ADR 192.168.20.69´Etape 5 Et la “ r´ponse ARP ” : e SENDER HA 00:01:e6:a1:07:64 SENDER ADR 192.168.20.69 TARGET HA 00:06:5b:0f:5a:20 TARGET ADR 192.168.20.249´Etape 6 Enfin, dans cette derni`re ´tape, R envoie le datagramme en pro- e e venance de A, ` B : a
  • 78 Protocole IP IP SOURCE 192.168.10.109 IP TARGET 192.168.20.69 MAC SOURCE 00:06:5b:0f:5a:20 MAC TARGET 00:01:e6:a1:07:64 Remarque, comparons avec le datagramme de l’´tape 3. Si les adresses e IP n’ont pas chang´, les adresses MAC, diff`rent compl`tement ! e e e Remarque : Si A envoie un deuxi`me datagramme, les caches ARP ont e les adresses MAC utiles et donc les ´tape 1, 2, 4 et 5 deviennent inutiles. . . e 8 Conclusion sur IP Apr`s notre tour d’horizon sur IPv4 nous pouvons dire en conclusion que e son espace d’adressage trop limit´ n’est pas la seule raison qui a motiv´ les e e travaux de recherche et d´veloppement d’IPv6 : e 1. Son en-tˆte comporte deux probl`mes, la somme de contrˆle (checksum) e e o doit ˆtre calcul´e ` chaque traitement de datagramme, chaque routeur e e a doit analyser le contenu du champ option. 2. Sa configuration n´cessite au moins trois informations que sont e l’adresse, le masque de sous r´seau et la route par d´faut. e e 3. Son absence de s´curit´ est insupportable. Issu d’un monde ferm´ o` la e e e u s´curit´ n’´tait pas un probl`me, le datagramme de base n’offre aucun e e e e service de confidentialit´, d’int´grit´ et d’authentification. e e e 4. Son absence de qualit´ de service ne r´pond pas aux exigences des e e protocoles applicatifs modernes (t´l´phonie, vid´o, jeux interactifs en ee e r´seau, . . .). Le champ TOS n’est pas suffisant et surtout est interpr´t´ e ee de mani`re inconsistante par les ´quipements. e e
  • 9 Bibliographie 799 BibliographiePour en savoir plus :RFC 791 “ Internet Protocol. ” J. Postel. Sep-01-1981. (Format : TXT=97779 bytes) (Obsoletes RFC0760) (Status : STANDARD)RFC 826 “ Ethernet Address Resolution Protocol : Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ether- net hardware. ” D.C. Plummer. Nov-01-1982. (Format : TXT=22026 bytes) (Status : STANDARD)RFC 903 “ Reverse Address Resolution Protocol. ” R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. Jun-01-1984. (Format : TXT=9345 bytes) (Status : STANDARD)RFC 950 “ Internet Standard Subnetting Procedure. ” J.C. Mogul, J. Pos- tel. Aug-01-1985. (Format : TXT=37985 bytes) (Updates RFC0792) (Status : STANDARD)RFC 1112 “ Host extensions for IP multicasting. ” S.E. Deering. Aug-01- 1989. (Format : TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status : STANDARD)RFC 1256 “ ICMP Router Discovery Messages. S. Deering. ” Sep-01-1991. (Format : TXT=43059 bytes) (Also RFC0792) (Status : PROPOSED STANDARD) – W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley – Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice–Hall – Craig Hunt - TCP/IP Network Administration - O´Reilly & Associates, Inc. – Christian Huitema - Le routage dans l’Internet - EYROLLES
  • 80 Protocole IP
  • Chapitre V Protocole UDP1 UDP – User Datagram Protocol UDP est l’acronyme de “User Datagram Protocol”, il est d´fini dans la eRFC 768 [Postel 1980]. Les donn´es encapsul´es dans un en-tˆte UDP sont des e e e“paquets UDP”.1.1 Identification de la destination Rappel : Au niveau de la couche Internet les datagrammes sont rout´s ed’une machine ` une autre en fonction des bits de l’adresse IP qui identifient le anum´ro de r´seau. Lors de cette op´ration aucune distinction n’est faite entre e e eles services ou les utilisateurs qui ´mettent ou recoivent des datagrammes, ie etous les datagrammes sont m´lang´s. e e La couche UDP ajoute un m´canisme qui permet l’identification du service e(niveau Application). En effet, il est indispensable de faire un tri entre lesdivers applications (services) : plusieurs programmes de plusieurs utilisateurspeuvent utiliser simultan´ment la mˆme couche de transport et il ne doit pas e ey avoir de confusion entre eux. Pour le syst`me Unix les programmes sont identifi´s de mani`re unique e e epar un num´ro de processus, mais ce num´ro est ´ph´m`re, non pr´visible ` e e e e e e adistance, il ne peut servir ` cette fonction. a L’id´e est d’associer la destination ` la fonction qu’elle remplie. Cette e aidentification se fait ` l’aide d’un entier positif que l’on baptise port. a – Le syst`me d’exploitation local a ` sa charge de d´finir le m´canisme e a e e qui permet ` un processus d’acc´der ` un port. a e a – La plupart des syst`mes d’exploitation fournissent le moyen d’un acc`s e e synchrone ` un port. Ce logiciel doit alors assurer la possibilit´ de g´rer a e e la file d’attente des paquets qui arrivent, jusqu’` ce qu’un processus a (Application) les lise. A l’inverse, l’OS, “ Operating System ”, bloque un processus qui tente de lire une donn´e non encore disponible. e Pour communiquer avec un service distant il faut donc avoir connaissance
  • 82 Protocole UDP de son num´ro de port, en plus de l’adresse IP de la machine elle-mˆme. e e On peut pr´voir le num´ro de port en fonction du service ` atteindre, e e a c’est l’objet du paragraphe 1.3. La figure V.01 explicite la notion de port. La couche IP s´pare les data- e 1 grammes SCTP, TCP et UDP grˆce au champ PROTO de son en-tˆte, l’associa- a e tion du protocole de transport et du num´ro de port identifie un service sans e ambigu¨ e. ıt´ Conceptuellement on s’apper¸oit alors que rien ne s’oppose ` ce qu’un c a mˆme service (Num´ro de port) soit attribu´ conjointement aux trois proto- e e e coles (en pointill´s sur la figure). Cette situation est d’ailleurs courante dans e la r´alit´ des serveurs. e e Port 1 Port 2 Port 3 Application Message Transport UDP TCP SCTP Paquet UDP Internet IP figure V.01 — Num´ro de port comme num´ro de service e e 1 Cf description page 47
  • Description de l’en-tˆte e 831.2 Description de l’en-tˆte e Un paquet UDP est con¸u pour ˆtre encapsul´ dans un datagramme IP c e eet permettre un ´change de donn´es entre deux applications, sans ´change e e epr´liminaire. Ainsi, si les donn´es ` transmettre n’obligent pas IP ` frag- e e a amenter (cf page 52), un paquet UDP g´n`re un datagramme IP et c’est tout ! e e Header IP Paquet UDP = données d’IP PROTO = UDP figure V.02 — UDP encapsul´ dans IP e – UDP apporte un m´canisme de gestion des ports, au dessus de la couche e Internet. – UDP est simplement une interface au dessus d’IP, ainsi l’´mission e des messages se fait-elle sans garantie de bon acheminement. Plus g´n´ralement, tous les d´fauts d’IP recens´s au chapitre pr´c´dent sont e e e e e e applicables ` UDP. a Plus particuli`rement, les paquets ` destination d’une application UDP e a sont conserv´s dans une pile de type FIFO. Si l’application destina- e trice ne les “consomme” pas assez rapidement, les plus anciens paquets risquent d’ˆtre ´cras´s par les plus r´cents. . .Un risque suppl´mentaire e e e e e (par rapport aux propri´t´s d’IP d´j` connues) de perte de donn´es. ee ea e – Il n’y a aucun retour d’information au niveau du protocole pour ap- porter un quelconque moyen de contrˆle sur le bon acheminement des o donn´es. e C’est au niveau applicatif qu’il convient de prendre en compte cette lacune. – UDP est aussi d´sign´ comme un mode de transport “non connect´”, e e e ou encore mode datagramme, par opposition ` TCP ou SCTP que nous a examinerons dans les prochains chapitres. Parmis les utilisations les plus courantes d’UDP on peut signaler le serveurde noms2 , base de donn´es r´partie au niveau mondial, et qui s’accomode e etr`s bien de ce mode de transport. e En local d’autres applications tr`s utiles comme tftp ou nfs sont e´galement susceptibles d’employer UDP.e 2 DNS — RFC 1035— Ce service utilise UDP dans le cas d’´changes de petits paquets ed’informations (≤ 512 octets) sinon il utilise TCP
  • 84 Protocole UDP La figure V.03 d´crit la structure de l’en-tˆte. e e 31 1615 0 UDP SOURCE PORT UDP DESTINATION PORT MESSAGE LENGTH CHECKSUM DATA .... ... figure V.03 — Structure de l’en-tˆte UDP e UDP SOURCE PORT Le num´ro de port de l’´metteur du paquet. Ce champ e e est optionnel, quand il est sp´cifi´ il indique le num´ro de port que le e e e destinataire doit employer pour sa r´ponse. La valeur z´ro (0) indique e e qu’il est inutilis´, le port 0 n’est donc pas celui d’un service valide. e UDP DESTINATION PORT Le num´ro de port du destinataire du paquet. e MESSAGE LENGTH C’est la longueur du paquet, donc comprennant l’en-tˆte e et le message. – La longueur minimal est 8 – La longueur maximale est 65 535 − H(IP ). Dans le cas courant (IP sans option) cette taille maximale est donc de 65 515. CHECKSUM Le checksum est optionnel et toutes les impl´mentations ne l’uti- e lisent pas. S’il est employ´, il porte sur un pseudo en-tˆte constitu´ de e e e la mani`re suivante : e 31 24 23 16 15 87 0 Source Address Destination Address zero Protocol UDP length UDP source port UDP destination port UDP length CHECKSUM DATA figure V.04 — Cas du checksum non nul Ce pseudo en-tˆte est pr´vu initialement pour apporter une protection e e en cas de datagrammes mal rout´s ! e
  • Ports r´serv´s — disponibles e e 851.3 Ports r´serv´s — ports disponibles e e Le num´ro de port est un entier 16 bits non sign´, les bornes sont donc e e[0, 65535], par construction. Nous avons vu pr´c´dement que le port 0 n’est e epas exploitable en tant que d´signation de service valide, donc le segment er´ellement exploitable est [1, 65535]. e Toute machine qui utilise la pile TCP/IP se doit de connaˆ un certain ıtrenombre de services bien connus, rep´r´s par une s´rie de ports bien connus ou ee e“well known port numbers”, pour pouvoir dialoguer avec les autres machinesde l’Internet (vs Intranet). Sur une machine Unix, cette liste de services estplac´e dans le fichier /etc/services et lisible par tous les utilisateurs et etoutes les applications. En effet, comme nous l’examinerons en d´tail dans le cours de program- emation, un service (comprendre un programme au niveau applicatif) quid´marre son activit´ r´seau (et qui donc est consid´r´ comme ayant un rˆle e e e ee ode serveur) s’attribue le (les) num´ro(s) de port qui lui revient (reviennent) econform´ment ` cette table. e a Nom Port Proto Commentaire echo 7 tcp echo 7 udp ftp-data 20 tcp #File Transfer [Default Data] ftp-data 20 udp #File Transfer [Default Data] ftp 21 tcp #File Transfer [Control] ftp 21 udp #File Transfer [Control] ssh 22 tcp #Secure Shell Login ssh 22 udp #Secure Shell Login smtp 25 tcp mail #Simple Mail Transfer smtp 25 udp mail #Simple Mail Transfer domain 53 tcp #Domain Name Server domain 53 udp #Domain Name Server http 80 tcp www www-http #World Wide Web HTTP http 80 udp www www-http #World Wide Web HTTP pop3 110 tcp #Post Office Protocol - Version 3 pop3 110 udp #Post Office Protocol - Version 3 imap 143 tcp #Interim Mail Access Protocol imap 143 udp #Interim Mail Access Protocol https 443 tcp #Secure World Wide Web HTTP https 443 udp #Secure World Wide Web HTTP Le tableau de la figure V.05 pr´sente quelques uns des ports bien connus eplus connus les plus utilis´s, il y en a quantit´ d’autres. . . e e 3 Une autorit´, l’IANA , centralise et diffuse l’information relative ` tous e a 3 “Internet Assigned Numbers Authority”
  • 86 Protocole UDP les nombres utilis´s sur l’Internet via une RFC. La derni`re en date est la e e RFC 1700, elle fait plus de 200 pages ! Par voie de cons´quence cette RFC concerne aussi les num´ros de ports. e e 1.3.1 Attribution des ports “ancienne m´thode” e Historiquement les ports de 1 ` 255 sont r´serv´s aux services bien connus, a e e plus r´cemment, ce segment ` ´t´ ´largi ` [1, 1023]. Aucune application ne e aeee a peut s’attribuer durablement et au niveau de l’Internet un num´ro de port e dans ce segment, sans en r´f´rrer ` l’IANA, qui en contrˆle l’usage. ee a o ` A partir de 1024 et jusqu’` 65535, l’IANA se contente d’enregistrer les a demandes d’usage et signale les ´ventuels conflits. e 1.3.2 Attribution des ports “nouvelle m´thode” e Devant l’explosion du nombre des services enregistr´s l’IANA a modifi´ e e 4 la segmentation qui pr´c`de. D´sormais les num´ros de ports sont class´s e e e e e selon les trois cat´gories suivantes : e 1. Le segment [1, 1023] est toujours r´serv´s aux services bien connus. e e Les services bien connus sont d´sign´s par l’IANA et sont mis en œuvre e e par des applications qui s’ex´cutent avec des droits privil´gi´s (root sur e e e une machine Unix) 2. Le segment [1024, 49151] est celui des services enregistr´s. e Ils sont ´num´r´s par l’IANA et peuvent ˆtre employ´s par des proces- e ee e e sus ayant des droits ordinaires. Par exemple : Nom Port Proto Commentaire bpcd 13782 tcp VERITAS NetBackup bpcd 13782 udp VERITAS NetBackup 3. Le segment [49152, 65535] est celui des attributions dynamiques et des services priv´s ; nous en examinerons l’usage dans le cours de pro- e grammation. 4 http://www.iana.org/assignments/port-numbers
  • 2 Bibliographie 872 BibliographiePour en savoir plus :RFC 768 “User Datagram Protocol.” J. Postel. Aug-28-1980. (Format : TXT=5896 bytes) (Status : STANDARD)RFC 1035 “Domain names - concepts and facilities.” P.V. Mockapetris. Nov-01-1987. (Format : TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status : STANDARD)RFC 1700 “ASSIGNED NUMBERS.” J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD)RFC 1918 “Address Allocation for Private Internets.” Y. Rekhter, B. Mos- kowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE)Sans oublier : – W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley — 1994 – Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice–Hall
  • 88 Protocole UDP
  • Chapitre VI Protocole TCP1 TCP – Transmission Control Protocol TCP est l’acronyme de “ Transmission Control Protocol ”, il est d´fini edans la RFC 793 [Postel 1981c]. Les donn´es encapsul´es dans un en-tˆte e e eTCP sont des “ paquets TCP ”. Header IP Segment TCP = données IP PROTO = TCP figure VI.01 — TCP encapsul´ dans IP e1.1 Caract´ristiques de TCP e TCP est bien plus compliqu´1 qu’UDP examin´ au chapitre pr´c´dent, il e e e eapporte en contrepartie des services beaucoup plus ´labor´s. e eCinq points principaux caract´risent ce protocole : e 1. TCP contient un m´canisme pour assurer le bon acheminement des e donn´es. Cette possibilit´ est absolument indispensable d`s lors que e e e les applications doivent transmettre de gros volumes de donn´es et de e fa¸on fiable. c Il faut pr´ciser que les paquets de donn´es sont acquitt´s de bout en e e e bout et non de point en point. D’une mani`re g´n´rale le r´seau assure e e e e l’acheminement et les extr´mit´s le contrˆle (Dave Clark). e e o 2. Le protocole TCP permet l’´tablissement d’un circuit virtuel entre e les deux points qui ´changent de l’information. On dit aussi que TCP e 1 Une simple comparaison du volume des RFC initiales est parlante : 85 pages pour TCP,3 pour UDP !
  • 90 Protocole TCP fonctionne en mode connect´ (par opposition ` UDP qui est en mode e a non connect´ ou encore mode datagramme). e – Avant le transfert les 2 applications se mettent en relation avec leurs OS2 respectifs, les informent de leurs d´sirs d’´tablir ou de recevoir e e une communication. – Pratiquement, l’une des deux applications doit effectuer un appel que l’autre doit accepter. – Les protocoles des 2 OS communiquent alors en s’envoyant des mes- sages au travers du r´seau pour v´rifier que le transfert est possible e e (autoris´) et que les deux applications sont prˆtes pour leurs rˆles. e e o – Une fois ces pr´liminaires ´tablis, les modules de protocole informent e e les applications respectives que la connexion est ´tablie et que le e transfert peut d´buter. e – Durant le transfert, le dialogue entre les protocoles continue, pour v´rifier le bon acheminement des donn´es. e e Conceptuellement, pour ´tablir une connexion — un circuit virtuel — e il faut avoir r´unis les ´l´ments du quintuplet : e ee Le protocole C’est TCP mais il y pourrait y avoir d’autres transports qui assurent le mˆme service. . . e IP locale Adresse de la machine qui ´met. e Port local Le num´ro de port associ´ au processus. Il est impos´ ou e e e est d´termin´ automatiquement comme nous le verrons dans le e e cours de programmation. IP distante Adresse de la machine distante. Port distant Le num´ro de port associ´ au service ` atteindre. Il est e e a obligatoire de le connaˆ pr´cisement. ıtre e L’ensemble de ces cinq ´l´ments d´finit un circuit virtuel unique. Que ee e l’un d’eux change et il s’agit d’une autre connexion ! 3. TCP a la capacit´ de m´moriser3 des donn´es : e e e – Aux deux extr´mit´s du circuit virtuel, les applications s’envoient e e des volumes de donn´es absolument quelconques, allant de 0 octet ` e a des centaines (ou plus) de Mo. ` – A la r´ception, le protocole d´livre les octets exactement comme ils e e ont ´t´ envoy´s. ee e – Le protocole est libre de fragmenter le flux de donn´es en paquets e de tailles adapt´es aux r´seaux travers´s. Il lui incombe cependant e e e d’effectuer le r´assemblage et donc de stocker temporairement les e fragments avant de les pr´senter dans le bon ordre ` l’application. e a 4. TCP est ind´pendant vis ` vis des donn´es transport´es, c’est un e a e e flux d’octets non structur´ sur lequel il n’agit pas. e 2 “ Operating System ” 3 dans un buffer
  • Description de l’en-tˆte e 91 5. TCP simule une connexion en “ full duplex ”. Pour chacune des deux applications en connexion par un circuit virtuel, l’op´ration qui consiste e ` lire des donn´es peut s’effectuer ind´pendamment de celle qui consiste a e e ` en ´crire. a e Le protocole autorise la clˆture du flot dans une direction tandis que o l’autre continue ` ˆtre active. Le circuit virtuel est rompu quand les a e deux parties ont clos le flux.1.2 Description de l’en-tˆte e La figure suivante montre la structure d’un en-tˆte TCP. Sa taille normale eest de 20 octets, ` moins que des options soient pr´sentes. a e 31 19 16 15 87 0 TCP SOURCE PORT TCP DESTINATION PORT SEQUENCE NUMBER ACKNOWLEDGEMENT NUMBER OFF RESERVED CODE WINDOW CHECKSUM URGENT POINTER OPTIONS PADDING DATA ... figure VI.02 — Structure de l’en-tˆte TCP eTCP SOURCE PORT Le num´ro de port de l’application locale. eTCP DESTINATION PORT Le num´ro de port de l’application distante. eSEQUENCE NUMBER C’est un nombre qui identifie la position des donn´es ` e a transmettre par rapport au segment original. Au d´marrage de chaque e connexion, ce champ contient une valeur non nulle et non facilement pr´visible, c’est la s´quence initiale ou ISN4 e e TCP num´rote chaque octet transmis en incr´mentant ce nombre 32 bits e e non sign´. Il repasse ` 0 apr`s avoir atteint 232 − 1 (4 294 967 295). e a e Pour le premier octet des donn´es transmis ce nombre est incr´ment´ e e e de un, et ainsi de suite. . .ACKNOWLEDGEMENT NUMBER C’est un num´ro qui identifie la position du der- e nier octet re¸u dans le flux entrant. c Il doit s’accompagner du drapeau ACK (voir plus loin).OFF pour OFFSET, il s’agit d’un d´placement qui permet d’atteindre les e donn´es quand il y a des options. Cod´ sur 4 bits, il s’agit du nombre e e de mots de 4 octets qui composent l’en-tˆte. Le d´placement maximum e e 4 est donc de 60 octets (2 − 1 × 4 octets). Dans le cas d’un en-tˆte e sans option, ce champ porte la valeur 5. 10 mots de 4 octets sont donc possibles pour les options. 4 “ Initial Sequence Number ”
  • 92 Protocole TCP RESERVED Six bits r´serv´s pour un usage futur ! e e CODE Six bits pour influer sur le comportement de TCP en caract´risant e l’usage du segment : URG Le champ “ URGENT POINTER ” doit ˆtre exploit´. e e ACK Le champ “ ACNOWLEDGMENT NUMBER ” doit ˆtre exploit´. e e PSH C’est une notification de l’´metteur au r´cepteur, pour e e lui indiquer que toutes les donn´es collect´es doivent ˆtre e e e transmises ` l’application sans attendre les ´ventuelles a e donn´es qui suivent. e RST Re-initialisation de la connexion SYN Le champ “ SEQUENCE NUMBER ” contient la valeur de d´but de connexion. e FIN L’´metteur du segment a fini d’´mettre. e e En fonctionnement normal un seul bit est activ´ ` la fois mais ce n’est ea pas une obligation. La RFC 1024 [Postel 1987] d´crit l’existence de e paquets tcp d´nomm´s “ Christmas tree ” ou “ paquet kamikaze ” e e comprenant les bits SYN+URG+PSH+FIN ! WINDOW Le flux TCP est control´ de part et d’autre pour les octets com- e pris dans une zone bien d´limit´e et nomm´e “ fenˆtre ”. La taille e e e e de celle-ci est d´finie par un entier non sign´ de 16 bits, qui en limite e e donc th´oriquement la taille ` 65 535 octets (ce n’est pas compl`tement e a e exact, voir plus loin l’option wscale). Chaque partie annonce ainsi la taille de son buffer de r´ception. Par e construction, l’´metteur n’envoie pas plus de donn´es que le r´cepteur e e e ne peut en accepter. Cette valeur varie en fonction de la nature du r´seau et surtout de la e bande passante devin´e ` l’aide de statistiques sur la valeur du RTT. e a Nous y reviendrons au paragraphe 4. CHECKSUM Un calcul qui porte sur la totalit´ du segment, en-tˆte et donn´es. e e e URGENT POINTER Ce champ n’est valide que si le drapeau URG est arm´. Ce e pointeur contient alors un offset ` ajouter ` la valeur de SEQUENCE a a NUMBER du segment en cours pour d´limiter la zone des donn´es urgentes e e ` transmettre ` l’application. a a Le m´canisme de transmission ` l’application d´pend du syst`me d’ex- e a e e ploitation. OPTIONS C’est un param`trage de TCP. Sa pr´sence est d´tect´e d`s lors que e e e e e l’OFFSET est sup´rieur ` 5. e a Les options utilis´es : e
  • Description de l’en-tˆte e 93 mss La taille maximale du segment5 des donn´es applicatives que e l’´metteur accepte de recevoir. Au moment de l’´tablissement e e d’une connexion (paquet comportant le flag SYN), chaque par- tie annonce sa taille de MSS. Ce n’est pas une n´gociation. Pour e de l’Ethernet la valeur est 1460 ( = M T U − 2 × 20). timestamp pour calculer la dur´e d’un aller et retour (RTT ou e “ round trip time ”). wscale Facteur d’´chelle (“ shift ”) pour augmenter la taille de la e fenˆtre au del` des 16 bits du champ WINDOW (> 65535). e a Quand cette valeur n’est pas nulle, la taille de la fenˆtre est de e 65535 × 2shif t . Par exemple si “ shift ” vaut 1 la taille de la fenˆtre e est de 131072 octets soit encore 128 ko. nop Les options utilisent un nombre quelconque d’octets par contre les paquet TCP sont toujours align´s sur une taille de mot de quatre e octets ; ` cet effet une option “ No Operation ” ou nop, cod´e sur a e 1 seul octet, est pr´vue pour compl´ter les mots. e ePADDING Remplissage pour se caler sur un mot de 32 bits.DATAS Les donn´es transport´es. Cette partie est de longueur nulle ` e e a l’´tablissement de la connexion, elle peut ´galement ˆtre nulle par choix e e e de l’application. 5 MSS=“ Maximum Segment Size ”
  • 94 Protocole TCP 2 D´but et clˆture d’une connexion e o 2.1 ´ Etablissement d’une connexion L’´tablissement d’une connexion TCP s’effectue en trois temps, comme le e sch´ma de la figure 3 l’explicite. e Emetteur Récepteur SYN (seq=x) SYN (seq=y) ACK (seq=x+1) ACK(seq=y+1) Temps ´ figure VI.03 — Etablissement d’une connexion On suppose que l’´metteur du premier paquet avec le bit SYN a connais- e sance du couple (adresse IP du r´cepteur, num´ro de port du service sou- e e hait´). e L’´metteur du premier paquet est ` l’origine de l’´tablissement du circuit e a e virtuel, c’est une attitude g´n´ralement qualifi´e de “ cliente ”. On dit aussi e e e que le client effectue une “ ouverture active ” (active open). Le r´cepteur du premier paquet accepte l’´tablissement de la connexion, e e ce qui suppose qu’il ´tait prˆt ` le faire avant que la partie cliente en prenne e e a l’initiative. C’est une attitude de “ serveur ”. On dit aussi que le serveur effectue une “ ouverture passive ” (passive open). 1. Le client envoie un segment comportant le drapeau SYN, avec sa s´quence initiale (ISN = x). e 2. Le serveur r´pond avec sa propre s´quence (ISN = y), mais il doit e e ´galement acquitter le paquet pr´c´dent, ce qu’il fait avec ACK (seq = e e e x + 1). 3. Le client doit acquitter le deuxi`me segment avec ACK (seq = y + 1). e
  • Clˆture d’une connexion o 95 Une fois achev´e cette phase nomm´e “ three-way handshake ”, les deux e eapplications sont en mesure d’´changer les octets qui justifient l’´tablissement e ede la connexion.2.2 Clˆture d’une connexion o2.2.1 Clˆture canonique o Un ´change de trois segments est n´cessaire pour l’´tablissement de la e e econnexion ; il en faut quatre pour qu’elle s’ach`ve de mani`re canonique (“ or- e ederly release ”). Emetteur Récepteur close FIN (seq=x) Envoi d’un EOF à ACK (seq = x + 1) l’application Flux de données du récepteur vers l’émetteur FIN (seq = y) close Envoi d’un EOF à ACK (seq = y + 1) Temps l’application Dernier segment de la connexion figure VI.04 — Clˆture d’une connexion o La raison est qu’une connexion TCP est “ full-duplex ”, ce qui implique queles donn´es circulent ind´pendamment dans un sens et dans l’autre. Les deux e edirections doivent donc pouvoir ˆtre interrompues ind´pendamment l’une de e el’autre. L’application qui envoie un paquet avec le drapeau FIN indique ` la couche aTCP de la machine distante qu’elle n’enverra plus de donn´e. La machine edistante doit acquitter ce segment, comme il est indiqu´ sur la figure VI.04, een incr´mentant d’une unit´ le “ sequence number ”. e e La connexion est v´ritablement termin´e quand les deux applications ont e eeffectu´ ce travail. Il y a donc ´change de 4 paquets pour terminer la con- e enexion.
  • 96 Protocole TCP Au total, sans compter les ´changes propres au transfert des donn´es, les e e deux couches TCP doivent g´rer 7 paquets, il faut en tenir compte lors de la e conception des applications ! Sur la figure on constate que le serveur continue d’envoyer des donn´es e bien que le client ait termin´ ses envois. Le serveur a d´tect´ cette attitude e e e par la r´ception d’un caract`re de EOF (en C sous Unix). e e Cette possibilit´ a son utilit´, notamment dans le cas des traitements dis- e e tants qui doivent s’accomplir une fois toutes les donn´es transmises, comme e par exemple pour un tri. 2.2.2 Clˆture abrupte o Au lieu d’un ´change de quatre paquets comme pr´c´dement, un e e e m´canisme de reset est pr´vu pour terminer une connexion au plus vite (abor- e e tive release). Ce type d’arrˆt est typiquement g´r´ par la couche TCP elle-mˆme quand e ee e l’application est brutalement interrompue sans avoir effectu´ un appel ` e a la primitive close(2), comme par exemple lors d’un appel ` la primitive a abort(2), ou apr`s avoir rencontr´ une exception non prise en compte (“ core e e dump ”. . .). L’extremit´ qui arrˆte brutalement la connexion ´met un paquet assorti e e e du bit RST, apr`s avoir (ou non) envoy´ les derniers octets en attente6 . Ce e e paquet clˆt l’´change. Il ne re¸oit aucun acquittement. o e c L’extr´mit´ qui re¸oit le paquet de reset (bit RST), transmet les ´ventuelles e e c e derni`res donn´es ` l’application et provoque une sortie d’erreur du type e e a “ Connection reset par peer ” pour la primitive de lecture r´seau. Comme e c’est le dernier ´change, si des donn´es restaient ` transmettre ` l’application e e a a qui a envoy´ le RST elles peuvent ˆtre d´truites. e e e Emetteur Récepteur RST ´ figure VI.05 — Emission d’un rst 6 Voir dans le cours de programmation, l’option SO LINGER
  • 3 Contrˆle du transport o 973 Contrˆle du transport o Le bon acheminement des donn´es applicatives est assur´ par un e em´canisme d’acquittement des paquets, comme nous avons d´j` pu l’exa- e eaminer partiellement au paragraphe pr´c´dent. e e3.1 M´canisme de l’acquittement e Emetteur Récepteur Paquet i Horloge RTT ACK Paquet i+1 figure VI.06 — M´canisme de l’acquittement e – Au d´part du Paquet i une horloge se d´clenche. Si cette horloge d´passe e e e une valeur limite avant r´ception de l’ACK le Paquet i est retransmis e Cette valeur limite est bas´e sur la constante MSL7 qui est un choix e d’impl´mentation, g´n´ralement de 30 secondes ` 2 minutes. Le temps e e e a maximum d’attente est donc de 2 × M SL. – Le temps qui s’´coule entre l’´mission d’un paquet et la r´ception de son e e e 8 acquittement est le RTT , il doit donc ˆtre inf´rieur ` 2 × M SL. Il est e e a courant sur l’Internet actuel d’avoir un RTT de l’ordre de la seconde. Il faut noter que le RTT est la somme des temps de transit entre chaque routeur et du temps pass´ dans les diverses files d’attente sur les rou- e teurs. – L’´metteur conserve la trace du Paquet i pour ´ventuellement le ren- e e voyer. Si on consid`re des d´lais de transmission de l’ordre de 500 ms (voire plus), e eun tel m´canisme est totalement inadapt´ au transfert de flux de donn´es. e e eOn peut aussi remarquer qu’il sous-emploie la bande passante du r´seau. e 7 “ Maximum Segment Lifetime ” 8 “ Round Trip Time ”, calcul´ ` l’aide de l’option “ timestamp ” - voir page 93 ea
  • 98 Protocole TCP 3.2 Fenˆtres glissantes e Cette attente de l’acquittement est p´nalisante, sauf si on utilise un e 9 m´canisme de “ fenˆtres glissantes ”, comme le sugg`re la figure VI.07 : e e e Emetteur Récepteur Paquet i Paquet i+1 Paquet i+2 Durée maximale Paquet i+3 d’attente pour l’acquittement ACK(i) sur le Paquet i Paquet i+4 figure VI.07 — Principe de la fenˆtre glissante e – Avec ce principe, la bande passante du r´seau est beaucoup mieux e employ´e. e – Si l’un des paquets doit ˆtre re´mis, la couche TCP du destinataire aura e e toute l’information pour le replacer dans le bon ordre. ` – A chaque paquet est associ´e une horloge comme sur la figure VI.06. e – Le nombre de paquets ` envoyer avant d’attendre le premier acquitte- a ment est fonction de deux param`tres : e 1. La largeur de la fenˆtre pr´cis´e dans le champ WINDOW de l’en-tˆte. e e e e Des valeurs courantes sont de l’ordre de 4096, 8192 ou 16384. Elle change dynamiquement pour deux raisons : (a) L’application change la taille du “ buffer de la socket ”10 qui correspond ` la taille de cette fenˆtre. a e (b) Chaque acquittement ACK envoy´ est assorti d’une nouvelle e valeur de taille de la fenˆtre, permettant ainsi ` l’´metteur e a e d’ajuster ` tout instant le nombre de segment qu’il peut en- a voyer simultan´ment. Celle valeur peut ˆtre nulle, comme par e e exemple lorsque l’application cesse de lire les donn´es re¸ues. e c C’est ce m´canisme qui assure le contrˆle de flux de TCP. e o 9 “ sliding windows ” 10 voir le cours de programmation
  • Fenˆtres glissantes e 99 2. La taille maximale des donn´es, ou MSS11 vaut 512 octets par e d´faut. C’est la plus grande taille du segment de donn´es que TCP e e enverra au cours de la session. Le datagramme IP a donc une taille ´gale au MSS augment´e de e e 40 octets (20 + 20), en l’absence d’option de TCP. Cette option apparait uniquement dans un paquet assorti du dra- peau SYN, donc ` l’´tablissement de la connexion. a e Comme de bien entendu cette valeur est fortement d´pendante du e 12 support physique et plus particuli`rement du MTU . e Sur de l’Ethernet la valeur maximale est 1500−2×20 = 1460, avec des trames l’encapsultation 802.3 de l’IEEE un calcul similaire conduit ` une longueur de 1452 octets. a Chaque couche TCP envoie sa valeur de MSS en mˆme temps que le e paquet de synchronisation, comme une option de l’en-tˆte. Cette e valeur est calcul´e pour ´viter absolument la fragmentation de IP e e au d´part des datagrammes. e Fenêtre possible pour le destinataire (dernier acquittement) MSS accepté par le destinataire Fenêtre utilisable 1 2 3 4 5 6 7 8 9 10 ... Déjà envoyés, Envoyés, Peuvent être Ne peuvent pas encore ACK reçus. ACK non reçus. envoyés être envoyés, il faut attendre que la fenêtre se déplace. figure VI.08 — D´tail de la fenˆtre glissante e e Le d´bit obtenu d´pend de la taille de la fenˆtre et bien sˆr de la bande e e e upassante disponible. On con¸oit ais´ment qu’entre la situation de la figure c eVI.06 et celle de la figure VI.07 l’usage de la bande passante s’am´liore. Par econtre l’agrandissement de la taille de la fenˆtre ne se con¸oit que jusqu’` une e c alimite optimale au dela de laquelle des paquets sont perdus parcequ’envoy´s etrop rapidement pour ˆtre re¸us par le destinataire. Or, pour fonctionner de e cmani`re optimale, TCP se doit de limiter au maximum la perte de paquets et edonc leur r´´mission. ee 11 “ Maximum Segment Size ” - Cf page 93 12 “ Maximum Transfer Unit ” - Cf page 52
  • 100 Protocole TCP Cette taille limite optimale de la largeur de la fenˆtre est, comme on e peut le deviner, fonction de la bande passante th´orique du r´seau et surtout e e de son taux d’occupation instantann´. Cette derni`re donn´e est fluctuante, e e e aussi TCP doit-il asservir continuement les tailles de fenˆtre pour en tenir e compte. 4 Compl´ments sur le fonctionnement de TCP e L’usage du protocole TCP diff`re consid´rablement en fonction des appli- e e cations mises en œuvre et des r´seaux ` parcourir. e a D’apr`s [W. Richard Stevens], 10% des donn´es ´chang´es sur le e e e e r´seau concernent des applications interactives et 90% des applications qui e ´changent des flux de donn´es. e e Si le protocole TCP reste le mˆme pour tous, les algorithmes qui le pilotent e s’ajustent en fonction de l’usage. Pour le trafic en volume (“ bulk data ”), TCP tente d’utiliser des paquets les plus larges possibles pour maximiser le d´bit, alors que le trafic interactif e utilise des paquets quasiment vides ´mis le plus souvent ` la fr´quence de e a e frappe des utilisateurs ou au rythme des mouvements d’une souris. Un exemple typique est celui de l’application telnet pour laquelle les caract`res sont envoy´s un ` un dans un paquet diff´rent, chaque caract`re e e a e e ´tant ` l’origine de quatre paquets : ´mission d’un caract`re, acquittement, e a e e retour de l’´cho du caract`re, acquittement. e e Si ce comportement n’est absolument pas p´nalisant sur un r´seau rapide e e (LAN) par contre d`s que la bande passante commence ` ˆtre statur´e il e a e e est pr´f´rable de regrouper un maximum d’octets (deux ou trois en pratique) ee dans un seul paquet pour en diminuer le nombre. C’est ce que fait l’algorithme de Nagle. 4.1 Algorithme de Nagle Pour r´duire le trafic de ces “ tinygrams ” (RFC 896), l’algorithme de e Nagle (1984) dit qu’une connexion TCP ne peut pas attendre plus d’un ac- quittement. Deux cas se pr´sentent donc : e 1. Le r´seau est lent. Dans ce cas TCP accumule dans un mˆme buffer les e e octets en partance. D`s r´ception de l’acquittement il y a ´mission du e e e contenu du buffer en un seul paquet. 2. Le r´seau est rapide. Les acquittements arrivent rapidement les agr´gats e e d’octets peuvent tendre vers un seul caract`re par paquet. e La qualit´ lent/rapide du r´seau est calcul´e ` partir du “ timestamp ” e e e a envoy´ dans les options de TCP et qui est ´tabli d`s le premier ´change (puis e e e e re´valu´e statistiquement par la suite). e e L’´l´gance de cet algorithme est qu’il est tr`s simple et qu’il s’auto-r´gule ee e e suivant le d´lais de propagation. e
  • D´part lent e 101 Certaines applications d´sactivent cet algorithme13 comme le serveur eApache ou le syst`me de multi-fenˆtrage X11. e e4.2 D´part lent e Un paquet est re´mis parcequ’il arrive corrompu ou parcequ’il n’arrive ejamais. Une r´´mission entraine un blocage de l’avancement de la “ fenˆtre ee eglissante ”, p´nalisant pour le d´bit (cf conclusion du chapitre page 105). e e TCP consid`re qu’un paquet perdu est la cons´quence d’un routeur (ou e eplus) congestionn´, c’est ` dire pour lequel les files d’attente ne sont pas e aassez larges pour absorber tous les paquets entrants14 Dans ce contexte, on comprend bien qu’il vaut mieux ne pas envoyer latotalit´ du contenu de la fenˆtre d`s le d´but de la connexion. Au contraire, e e e eTCP utilise un algorithme nomm´ “ slow start ” qui asservit l’´mission des e epaquets au rythme de la r´ception de leurs acquittements, plutˆt que de les e o´mettre d’un coup aussi rapidement que l’autorise le syst`me ou le d´bite e eth´orique du r´seau. e e Ainsi, au d´but de chaque connexion ou apr`s une p´riode de calme e e e(“ idle ”) l’´metteur envoie un premier paquet de taille maximale (le “ mss ” edu destinataire), et attend son acquittement. Quand celui-ci est re¸u, il en- cvoie deux paquets, puis quatre, et ainsi de suite jusqu’` atteindre l’ouverture amaximale de la fenˆtre.e Durant cette progression, si des paquets sont perdus, il y a congestionsuppos´e sur l’un des routeurs franchis et l’ouverture de la fenˆtre est r´duite e e epour retrouver un d´bit qui minimise le taux de retransmission. e L’ouverture de la fenˆtre est nomm´e fenˆtre de congestion ou encore e e e“ congestion window ”.4.3 ´ Evitement de congestion Le contrˆle du flux ´voqu´ pr´c´dement, pour ´viter la congestion des o e e e e erouteurs, est impl´ment´ ` l’aide d’une variable (cwnd) nomm´e “ congestion e ea ewindow ” que l’on traduit par fenˆtre de congestion. e Concr`tement, le nombre maximum de segments de donn´es (×M SS en e eoctets) que l’´metteur peut envoyer avant d’en recevoir le premier acquit- etement est le minimum entre cette variable (cwnd) et la taille de la fenˆtre eannonc´e par le r´cepteur ` chaque acquittement de paquet. e e a Le contenu de cette variable est pilot´ par les algorithmes de d´part lent e e— “ slow start ”, voir 4.2 — et d’´vitement de congestion (“ congestion eavoidance ”) examin´ ici. e La limite de croissance de la variable cwnd est la taille de la fenˆtre an- enonc´e par le r´cepteur. Une fois la capacit´ de d´bit maximale atteinte, e e e esi un paquet est perdu l’algorithme d’´vitement de congestion en diminue e 13 ` l’aide de l’option TCP NODELAY a 14 Ce cas arrive fr´quemment quand un routeur s´pare un r´seau rapide d’un r´seau lent e e e e
  • 102 Protocole TCP lin´airement la valeur (contrairement au “ slow start ” qui l’augmente expo- e nentiellement). 5 Paquets captur´s, comment´s e e Le premier exemple montre un ´change de paquets de synchronisa- e tion (SYN) et de fin (FIN) entre la machine clnt.chezmoi et la machine srv.chezmoi. L’´tablissement de la connexion se fait ` l’aide de la commande e a telnet sur le port discard (9) du serveur srv.chezmoi. La machine qui est ` l’origine de l’´tablissement de la connexion est dite cliente, et celle qui a e est suppos´e prˆte ` r´pondre, serveur. Pour information, le service discard e e a e peut ˆtre consid´r´ comme l’´quivalent du fichier /dev/null sur le r´seau : e ee e e les octets qu’on lui envoie sont oubli´s (“ discard ”). e L’utilisateur tape :Simultan´ment e la $ telnet srv discardcapture des paquets Trying...est lanc´e, e parexemple dans une Connected to srv.chezmoi.autre fenˆtre xterm. e Escape character is ’^]’. telnet> quit Connection closed. Et l’outil d’analyse r´seau15 permet la capture pour l’observation des e ´changes suivants. Le num´ro qui figure en tˆte de chaque ligne a ´t´ ajout´ e e e ee e manuellement, le nom de domaine “ chezmoi ” a ´t´ retir´, le tout pour ee e faciliter la lecture : 0 13:52:30.274009 clnt.1159 > srv.discard: S 55104001:55104001(0) win 8192 <mss 1460> 1 13:52:30.275114 srv.discard > clnt.1159: S 2072448001:2072448001(0) ack 55104002 win 4096 <mss 1024> 2 13:52:30.275903 clnt.1159 > srv.discard: . ack 1 win 8192 3 13:52:33.456899 clnt.1159 > srv.discard: F 1:1(0) ack 1 win 8192 4 13:52:33.457559 srv.discard > clnt.1159: . ack 2 win 4096 5 13:52:33.458887 srv.discard > clnt.1159: F 1:1(0) ack 2 win 4096 6 13:52:33.459598 clnt.1159 > srv.discard: . ack 2 win 8192 Plusieurs remarques s’imposent : 1. Pour am´liorer la lisibilit´ les num´ros de s´quences “ vrais ” ne sont in- e e e e diqu´s qu’au premier ´change. Les suivants sont relatifs. Ainsi le ack 1 e e de la ligne 2 doit ˆtre lu 2072448002 (2072448001 + 1). e ` chaque ´change la valeur entre parenth`ses indique le nombre d’octets A e e ´chang´s. e e 15 tcpdump que nous aurons l’occasion d’utiliser en TP
  • Exemples de flux 103 2. Les tailles de fenˆtre (win) et de segment maximum (mss) ne sont pas e identiques. Le telnet du client fonctionne sur HP-UX alors que le serveur telnetd fonctionne sur une machine BSD. 3. La symbole > qui marque le sens du transfert. 4. Le port source 1159 et le port destination discard. 5. Les flags F et S. L’absence de flag, rep´r´ par un point. ee Le deuxi`me exemple montre une situation de transfert de fichier avec e 16l’outil ftp . Il faut remarquer que l’´tablissement de la connexion TCP est ici ` l’ini- e atiative du serveur, ce qui peut laisser le lecteur perplexe. . .L’explication estsimple. En fait le protocole ftp fonctionne avec deux connexions TCP, lapremi`re, non montr´e ici, est ´tablie du client vers le serveur, suppos´ ` e e e e al’´coute sur le port 21. Elle sert au client pour assurer le contrˆle du transfert. e oLorsqu’un transfert de fichier est demand´ via cette premi`re connexion, le e eserveur ´tablit une connexion temporaire vers le client. C’est cette connexion eque nous examinons ici. Elle est clotur´e d`s que le dernier octet demand´ e e eest transf´rr´. e eExtrait du fichier /etc/services, concernant ftp :ftp-data 20/tcp #File Transfer [Default Data]ftp-data 20/udp #File Transfer [Default Data]ftp 21/tcp #File Transfer [Control]ftp 21/udp #File Transfer [Control] Dans cette exemple nous pouvons suivre le fonctionnement du m´canisme edes fenˆtres glissantes. Les lignes ont ´t´ num´rot´es manuellement et la date e ee e eassoci´e ` chaque paquet supprim´e. e a e0 srv.20 > clnt.1158: S 1469312001:1469312001(0) win 4096 <mss 1024> [tos 0x8]1 clnt.1158 > srv.20: S 53888001:53888001(0) ack 1469312002 win 8192 <mss 1460>2 srv.20 > clnt.1158: . ack 1 win 4096 [tos 0x8]3 srv.20 > clnt.1158: P 1:1025(1024) ack 1 win 4096 [tos 0x8]4 clnt.1158 > srv.20: . ack 1025 win 81925 srv.20 > clnt.1158: . 1025:2049(1024) ack 1 win 4096 [tos 0x8]6 srv.20 > clnt.1158: . 2049:3073(1024) ack 1 win 4096 [tos 0x8]7 clnt.1158 > srv.20: . ack 3073 win 81928 srv.20 > clnt.1158: . 3073:4097(1024) ack 1 win 4096 [tos 0x8]9 srv.20 > clnt.1158: P 4097:5121(1024) ack 1 win 4096 [tos 0x8]10 srv.20 > clnt.1158: P 5121:6145(1024) ack 1 win 4096 [tos 0x8]11 clnt.1158 > srv.20: . ack 5121 win 819212 srv.20 > clnt.1158: P 6145:7169(1024) ack 1 win 4096 [tos 0x8]13 srv.20 > clnt.1158: P 7169:8193(1024) ack 1 win 4096 [tos 0x8]14 clnt.1158 > srv.20: . ack 7169 win 8192 16 du nom du protocole applicatif utilis´ : “ File Transfer Protocol ” e
  • 104 Protocole TCP 15 srv.20 > clnt.1158: P 8193:9217(1024) ack 1 win 4096 [tos 0x8] 16 srv.20 > clnt.1158: P 9217:10241(1024) ack 1 win 4096 [tos 0x8] 17 clnt.1158 > srv.20: . ack 9217 win 8192 18 srv.20 > clnt.1158: P 10241:11265(1024) ack 1 win 4096 [tos 0x8] 19 srv.20 > clnt.1158: P 11265:12289(1024) ack 1 win 4096 [tos 0x8] 20 clnt.1158 > srv.20: . ack 11265 win 8192 ... ... ... 21 srv.20 > clnt.1158: P 1178625:1179649(1024) ack 1 win 4096 [tos 0x8] 22 clnt.1158 > srv.20: . ack 1178625 win 8192 23 srv.20 > clnt.1158: P 1212417:1213441(1024) ack 1 win 4096 [tos 0x8] 24 srv.20 > clnt.1158: P 1213441:1214465(1024) ack 1 win 4096 [tos 0x8] 25 srv.20 > clnt.1158: P 1214465:1215489(1024) ack 1 win 4096 [tos 0x8] 26 clnt.1158 > srv.20: . ack 1213441 win 8192 27 clnt.1158 > srv.20: . ack 1215489 win 8192 28 srv.20 > clnt.1158: P 1215489:1215738(249) ack 1 win 4096 [tos 0x8] 29 srv.20 > clnt.1158: F 1215738:1215738(0) ack 1 win 4096 [tos 0x8] 30 clnt.1158 > srv.20: . ack 1215739 win 8192 31 clnt.1158 > srv.20: F 1:1(0) ack 1215739 win 8192 32 srv.20 > clnt.1158: . ack 2 win 4096 [tos 0x8] Remarques : 1. Le P symbolise le drapeau PSH. La couche TCP qui re¸oit un tel paquet c est inform´e qu’elle doit transmettre ` l’application toutes les donn´es e a e re¸ues, y compris celles transmises dans ce paquet. c Le positionnement de ce drapeau est ` l’initiative de la couche TCP a ´mettrice et non ` l’application. e a 2. Le type de service (“ Type Of service ” tos 0x8) est demand´ par e l’application pour maximiser le d´bit (consulter le cours IP page 49). e Données à transmettre, par segment de 1024 octets Numéros des lignes 1024 3 4 5,6 7 8,9,10 12,13 11 15,16 14 18,19 17 20 figure VI.09 — Exemple de fenˆtre glissante e
  • 6 Conclusion sur TCP 1056 Conclusion sur TCP Le protocole TCP a ´t´ con¸u ` une ´poque o` l’usage de la commande ee c a e uligne ´tait universel, et les applications graphiques utilisant le r´seau tr`s e e erares. . . ! Une trentaine d’ann´es plus tard, on peut faire le constat pratiquement einverse : les applications textes interactives (beaucoup de petits messagesapplicatifs) disparaissent au profit d’applications moins interactives et quisont plus orient´es flux de donn´es (vid´o, audio, t´l´phonie. . .) avec des e e e ee´changes plus volumineux et des besoins en transport qui ont ´volu´.e e e Le principe de la fenˆtre glissante, si performant qu’il soit pour assurer ele bon acheminement des donn´es, est bloquant pour certaines applications ecomme le web. En effet, si le paquet de donn´es de tˆte n’est pas acquitt´, les e e esuivants, mˆme re¸us, sont en attente avant d’ˆtre d´livr´s ` l’application. e c e e e a Si la r´ponse comporte par exemple de nombreuses zones graphiques eet textuelles diff´rentes la fluidit´ de la consultation est consid´rablement e e eamoindrie, et tenter de la compenser en ´tablissant un grand nombre de econnexions simultann´es pour r´cup´rer individuellement les ´l´ments de e e e eela page, consomme beaucoup de ressources syst`me et r´seaux (celles de e el’´tablissement des connexions) qui ne compense que partiellement ce soucis. e L’ind´pendance de TCP vis ` vis de la structure des donn´es est ´galement e a e eun inconv´nient dans certaines applications comme la t´l´phonie pour la- e eequelle la notion de messages successifs est bien plus int´ressante. e Depuis le d´but des ann´es 2000 l’IETF met au point le protocole SCTP e equi fournit des services similaires ` ceux de TCP, en abandonne certains et aapporte les nouvelles fonctionnalit´s adapt´es aux nouveaux besoins. e e7 BibliographieRFC 793 “ Transmission Control Protocol. ” J. Postel. Sep-01-1981. (For- mat : TXT=177957 bytes) (Status : STANDARD)RFC 1025 “ TCP and IP bake off. ” J. Postel. Sep-01-1987. (Format : TXT=11648 bytes) (Status : UNKNOWN)RFC 1700 “ ASSIGNED NUMBERS. ” J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD)Sans oublier : – W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley – Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice–Hall – McKusick – Bostic – Karels – Quaterman — “ The Design and im- plementation of the 4.4 BSD Operating System ” (chapitre 13) — Addison–Wesley — 1996
  • 106 Protocole TCP
  • Deuxi`me partie eR´seaux IP avanc´s e e
  • Chapitre VII Routage dynamique d’IP1 Introduction & rappels La notion de routage est inh´rente au fonctionnement du datagramme IP e(examin´ page 47). e Le routage des datagrammes IP n’est rien d’autre que l’op´ration qui econsiste ` trouver une route pour les conduire vers la destination, c’est ` dire a al’adresse du champ destination de l’en-tˆte (page 49). e Un premier examen du routage nous a conduit ` distinguer le routage adirect, sur un mˆme lan et associ´ ` l’usage des services du protocole ARP e ea(Voir page 55) puis le routage indirect, appell´ ainsi parcequ’il fait appel aux eservices d’une ou plusieurs passerelles avant d’atteindre la destination. Dansles deux cas la d´cision de routage porte sur la partie r´seau de l’adresse IP e edu destinataire, ou encore le netid. Le routage indirect se subdivise en deux cat´gories : le routage sta- etique, qui implique l’usage d’une passerelle par d´faut et enfin le routage edynamique, sujet qui concerne ce chapitre. L’id´e d’une route statique est s´duisante par sa facilit´ de mise en œuvre e e epour l’organisation des “ petits r´seaux ”. Elle se r´sume le plus souvent ` e e aajouter une simple ligne dans la configuration de l’appareil ` raccorder au ar´seau, et cette information vitale peut mˆme ˆtre r´cup´r´e automatique- e e e e eement ` l’aide de protocoles comme BOOTP ou DHCP ! aSur un routeur cisco1 ,la ligne de configuration : ip route 0.0.0.0 0.0.0.0 138.195.52.129 Indique que tous les datagrammes non routables directement doivent ˆtre eenvoy´s ` l’adresse 138.195.52.129. Une seule route par d´faut peut ˆtre e a e ed´finie pour une pile IP comme il a ´t´ expliqu´ lors de l’analyse de l’algo- e ee erithme de routage page 70. Cette disposition tr`s simple est bien commode car elle ´vite de se poser e edes questions compliqu´es sur le choix de la route, en d´l´guant ` d’autres ce e ee atravail d´licat. En effet, il faudra bien ` un certain moment du trajet suivi par e a 1 http://www.cisco.com
  • 110 Routage dynamique d’IP les datagrammes, qu’un dispositif particulier, ´tymologiquement un routeur, e prenne une d´cision face ` des possibilit´s multiples. e a e Ce routeur plus intelligent sera probablement celui qui permet ` vos da- a tagrammes de rejoindre l’internet si vous appartenez ` une entit´ qui a son a e autonomie (voir plus loin), ou le routeur du prestataires FAI pour un parti- culier, ou une plus petite entit´, abonn´ ` un service xDSL quelconque. e ea La pr´sence de plusieurs routes possibles pour rejoindre une destination e implique de facto l’usage d’un protocole de routage dynamique. Une route statique privil´gie une seule route et ignore les autres. L’existence de plusieurs e routes est une n´cessit´ pour assurer la redondance du service, voire mˆme e e e l’´quilibrage du trafic sur plusieurs liens. e 1.1 IGP, EGP, Syst`me autonome e Au commencement, l’Arpanet ´tait un seul r´seau g´r´ de mani`re ho- e e ee e mog`ne, du moins par un ensemble de personnes d´pendantes de la mˆme e e e entit´ administrative, ce qui permettait d’en orienter le d´veloppement de la e e mˆme mani`re partout. Le protocole de routage dynamique ´tait un ancˆtre e e e e du protocole RIP ´tudi´ dans ce chapitre. Ce protocole, comme on va le voir, e e implique que les routeurs s’´changent continuement des informations sur les e meilleures routes ` employer. Sans entrave, chaque routeur finit par avoir une a route pour atteindre tout le monde, partout ! L’extension de ce r´seau ` des entit´s tr`s diff´rentes entres elles, a conduit e a e e e les architectes r´seaux de l’´poque ` cr´er la notion de syst`me autonomes e e a e e (autonomous systems ou AS dans le texte), afin de permettre ` chacun dea d´velopper son r´seau interne sans risque d’en diffuser le contenu ` l’ext´rieur e e a e (soucis de confidentialit´ et de s´curit´). e e e Un syst`me autonome se caract´rise par un num´ro, ou num´ro d’AS, sur e e e e 16 bits dont l’attribution d´pend de l’IANA et de ses d´l´gations, par exemple e ee autonomous-system 2192 que l’on pourrait retrouver dans la configuration d’un external gateway de la figure VII.01. Cette nouvelle architecture entraine des changements dans l’usage des protocoles de routage. Certains sont plus adapt´s que d’autres ` router des e a blocs d’adresses IP conform´ment ` des politiques de routage (routing po- e a licy) internationales, ce sont les EGP comme external gateway protocol. Leur ancˆtre se nomme d’ailleurs EGP, il est remplac´ aujourd’hui par BGP (Bor- e e der Gateway Protocol). ` A l’int´rieur du syst`me autonome, les protocoles de routages sont des e e IGP comme Interior Gateway Protocol et ne sont plus du tout adapt´s ` la e a gestion de l’internet moderne. Par contre ils r´pondent plus ou moins bien e au besoin des r´seaux internes si compliqu´s et vastes soient-ils. Ces IGP e e ´changent bien entendu des routes avec les EGP, le routage ne serait pas e possible sans cela.
  • ´Vecteur de distances vs Etat de liens 111 Internet Core GGP Core Gateway Core Gateway EGP,BGP RIP,OSPF External gateways Autonomous Autonomous System System figure VII.01 — Un AS, le monde ext´rieur, le monde int´rieur ! e e Ce chapitre de cours examine deux IGP tr`s classiques, RIP et OSPF ! eSi ces deux protocoles se rencontrent tr`s fr´quemment sur les r´seaux, ils e e ediff`rent beaucoup dans leurs propri´t´s comme nous allons le voir. . . e ee1.2 ´ Vecteur de distances vs Etat de liens RIP Routing Information Protocol et OSPF Open Shortest PathFirst sont construits sur des approches diff´rentes. e Les algorithmes de routage ` vecteur de distances (bas´s sur l’algo- a erithme de Bellman-Ford) conduisent les routeurs ` transmettre ` leurs voisins a ar´seaux imm´diats une copie de leur table de routage. Ces tables se modi- e efient au fur et ` mesure de leur propagation, car chaque route est associ´e ` a e aune m´trique qui croˆ par d´faut d’une unit´ au passage de chaque routeur e ıt e e(le routeur voisin accessible sur le mˆme LAN est associ´ ` une m´trique de e ea e1, etc. . .). Le choix de la meilleure route est ´tabli par chaque routeur en econsid´rant la valeur minimale de cette m´trique pour toutes les routes qui e eaboutissent ` la mˆme destination. Seule la meilleure route est propag´e, les a e eautres sont oubli´es. e Pour ces consid´rations on dit que le calcul de la route est distribu´ et par e econs´quence chaque routeur n’a pas la connaissance de la topologie globale edu r´seau : il n’en connait qu’une version interpr´t´e par ses voisins. e ee Les algorithmes ` ´tats de liens bˆtissent les tables de routages a e adiff´remment. Chaque routeur est responsable de la reconnaissance de tous eses voisins, plus ou moins lointains, ` qui il envoie une liste compl`te des a enoms et des coˆts (en terme de bande passante, par d´faut) contenu dans u eune base de donn´es ` sa charge et qui repr´sente l’int´gralit´ de tous les e a e e erouteurs du nuage avec lesquels il doit travailler.
  • 112 Routage dynamique d’IP Chaque routeur a donc une connaissance exhaustive de la topologie du “ nuage ” dans lequel il se situe et c’est ` partir de cette repr´sentation qu’il a e calcule ses routes ` l’aide d’un algorithme connu de recherche du plus court a chemin dans un graphe : celui de Dijkstra2 2 http://www.cs.utexas.edu/users/EWD/
  • 2 Routage avec RIP 1132 Routage avec RIP RIP est l’acronyme de Routing Information Protocol. C’est le protocolehistorique de routage d’Arpanet3 , d´fini dans la RFC 1058 (historique) de e1988. Il est amusant de constater que l’´criture de cette RFC vient de el’analyse fonctionelle du dæmon routed pr´sent sur les machines BSD de el’´poque4 . e Le principe de fonctionnement de RIP est bas´ sur le calcul distribu´ e edu chemin le plus court dans un graphe, selon l’algorithme Bellman-Ford5d´crit ` la fin des ann´es 1950. e a e Le terme chemin le plus court d´signe implicitement l’usage d’une em´trique pour comparer les longueurs. Ici, la m´trique est basiquement le e enombre de sauts (hops) entre deux routeurs. Pour tout routeur, les r´seaux edirectement rattach´s sont accessibles avec un nombre de saut ´gal ` 1 (par e e ad´faut). La m´trique pour s’atteindre soit-mˆme ´tant toujours 0 par hy- e e e epoth`se. e Les routes qui sont propag´es d’un routeur ` un autre voient leur m´trique e a eaugmenter de 1 (ou plus) ` chaque franchissement d’un routeur. En pratique aon ne d´passe gu`re une profondeur de quelques unit´s, sinon le protocole de- e e evient inefficace comme on le verra au paragraphe suivant. Plus pr´cisement, eune route assortie de la m´trique 16 est consid´r´e comme infinie, donc e eed´signe une destination (devenue) inaccessible. e Cette limitation du protocole laisse quand mˆme aux architectes d’in- efrastructures r´seaux la possibilit´ de concevoir des r´seaux s´par´s les uns e e e e edes autres par un maximum de 15 routeurs. . .Au del` de cette limite il faut aforc´ment envisager l’usage d’un autre protocole ! e N R R1 R2 N métrique == 2 N métrique == 1 H figure VII.02 — La route vers H depuis R a une m´trique de 2 et passe par R1 e Sur la figure VII.02 Le routeur R peut atteindre l’hˆte H avec une route odont la m´trique est 2 et qui passe par le routeur R1. e Il faut bien noter qu’avec RIP, chaque routeur n’est en relation qu’avecses voisins directs, c’est ` dire ceux avec lesquels il partage un LAN6 . Typi- aquement un routeur qui fait du RIP a au moins deux interfaces (elles peuvent 3 “ old ARPANET routing ” 4 Il l’est encore de nos jours ! 5 http://brassens.upmf-grenoble.fr/IMSS/mamass/graphecomp/bellmannFord.htm pour une explication tr`s visuelle et soign´e du fonctionnement de l’algorithme e e 6 Cf page 7
  • 114 Routage dynamique d’IP ˆtre virtuelles), donc voit deux LANs. Ici R1 a un rˆle central et incontour- e o nable car ni R ni R2 ne s’´changent directement des routes. e Pour cette raison, les routes sont globalement issues d’un calcul dis- tribu´. Pour chaque routeur l’´tablissement de sa table de routage s’effectue e e ` partir des informations fournies par les routeurs de son voisinage, c’est ` a a dire ceux qu’il peut atteindre par un routage directe (cf page 66). La connaissance des routes acquises par chaque routeur ne s’effectue qu’au travers du r´sultat des calculs de routes effectu´s par ses voisins, calculs qu’il e e confrontera ` sa propre table de routage et ` son propre calcul de route (le a a choix d’une route plus courte ` l’aide de la m´trique annonc´e), puis diffusera a e e ` son tour. Par ce principe, dans la figure VII.02, R1 a connaissance du r´seau a e N indirectement grˆce aux annonces de routes diffus´es par R2. a e Le terme vecteurs de distances est employ´ parceque la propagation e des routes s’effectue sous la forme de vecteurs : “ Pour atteindre telle destination, il faut passer par ce routeur et la m´trique associ´e e e vaut cette valeur ”. Donc une direction et une m´trique, d’o` l’analogie e u avec un vecteur. Le moyen de propagation des tables de routes est un broadcast IP (adresse 255.255.255.255 Limited broadcast pour RIPv1) ou des annonces multicast (adresse 224.0.0.9 si on utilise RIPv27 ). 2.1 En fonctionnement 1. Au d´marrage, chaque routeur a connaissance des r´seaux auxquels il e e est directement rattach´, ainsi que du coˆt associ´ ` chacune de ses e u e a liaisons (1 par d´faut). e Le coˆt de la liaison locale, c’est ` dire celle du routeur vers lui-mˆme, u a e est “ 0 ” alors que celle pour atteindre n’importe quel autre point est “ infini ” (valeur 16 par d´faut). e Le routeur envoie un paquet de questionnement (request packet) ` ses a voisins pour constituer sa table de routage initiale. La RFC 2453 pr´cise que celle-ci contient 5 informations pour chaque e entr´e : e (a) L’adresse IPv4 de la destination, (b) La m´trique pour atteindre cette destination, e (c) L’adresse IPv4 de premi`re passerelle (next router) ` utiliser, e a (d) Un drapeau qui indique si la route a chang´ r´cemment (route e e change flag) (e) Deux chronom`tres associ´s ` la route, l’un pour signifier que la e e a route n’est plus utilisable (timeout), l’autre pour compter le temps 7 Rappellons (cf page 42) que les adresses du groupe 224.0.0.0/24 ont un TTL de 1 et donc ne sont pas rout´es en dehors du LAN e
  • Routage avec RIP 115 durant lequel une route non utilisable doit ˆtre maintenue dans la e table avant d’ˆtre supprim´e et l’espace m´moire utilis´ recycl´ e e e e e (garbage-collection). 2. En fonctionnement chaque routeur transmet son vecteur de distance ` a ses voisins directs (LAN) soit par un broadcast, soit par un multicast. Le port de destination est toujours 520 ; Cet ´vˆnement a lieu p´riodiquement (30 secondes) o` d`s que quelque e e e u e chose change dans la table de routage (Triggered updates page 117), ou encore ` r´ception d’un paquet de demande de route, par exemple par a e un hˆte d’un r´seau directement raccord´ (voir page 73) ; o e e 3. Chaque routeur calcule son propre vecteur de distance, le coˆt mini- u mum est le crit`re de s´lection. Ce calcul intervient d`s que : e e e Le routeur re¸oit un vecteur de distance qui diff`re avec ce qu’il a d´j` c e ea en m´moire, e Le constat de la perte de contact (link ou absence de r´ception des e annonces) avec un voisin. 4. Quand une route n’a pas ´t´ rafraˆ ee ıchie depuis 180 secondes (6 paquets de broadcast non re¸us) sa m´trique prend la valeur infinie (16) puis c e elle est d´truite (deuxi`me chronom`tre d´fini pr´c´demment). e e e e e e Le fonctionnement de RIP a un cot´ “ magique ” et pourtant l’algorithme econverge vers un ´tat stable, c’est d´montr´ ! e e e Examinons-en le fonctionnement ´l´mentaire sur un r´seau th´orique de ee e etrois routeurs align´s lors d’un d´marrage “ ` froid ” : e e a R1 R2 R3 N1 N2 figure VII.03 — Fonctionnement ´l´mentaire ee`A l’instant 0 Chaque routeur d´couvre les r´seaux qui lui sont directement e e rattach´s et se connait lui-mˆme, c’est ` dire qu’il connait sa ou ses e e a adresses IP. On peut le formaliser par un triplet (Destination, gateway, m´trique), pour R1 ¸a donne (R1,local,0)8 ; e c ◦ R1 annonce (R1,local,0) sur N1 ◦ R2 annonce (R2,local,0) sur N1 et N2 ◦ R3 annonce (R3,local,0) sur N2En final Chacun annonce ses routes de mani`re asynchrone, met ` jour e a sa table de routage et annonce celle-ci, tout ¸a de mani`re un peu c e asynchrone. On examine les tables de routages une fois ces ´changes e stabilis´s. e 8 Notons au passage qu’une route peut ˆtre formul´e vers un hˆte ou un r´seau, in- e e o ediff´rement e
  • 116 Routage dynamique d’IP ◦ R2 re¸oit les annonces de route en provenance de R1 et R3. Il ajoute c le coˆt de la liaison et obtient en final une table qui ressemble ` : u a (R2,local,0) (R1,R1,1) (R2,R2,1), ◦ De la mˆme mani`re R1 enrichit sa table avec deux routes : (R2,R2,1) e e et (R3,R2,2). Pour R3 de mani`re sym´trique : (R2,R2,1), (R1,R2,2). e e Que se passe t-il maintenant si R3 devient inaccessible (coupure r´seau, e hˆte arrˆt´. . .) ? o ee Basiquement R2 devrait supprimer la route vers R3. Il n’en fait rien pour l’instant puisque R1 annonce une route (R3,R2,2). R2 d´cide donc qu’il existe e une route (R3,R1,3) et annonce sa nouvelle table. R1 ayant re¸u une route modifi´e de R2 modifie sa propre route qui c e devient (R3,R2,4) et ainsi de suite dans une boucle infernale qui tend ` a compter jusqu’` l’infini. For heureusement le calcul s’arrˆtera ` 16 par d´faut, a e a e R1 et R2 conclueront alors que R3 n’est pas (plus) accessible et finiront par retirer la route de leur table ! On peut aisement se rendre compte de la stupidit´ de cette d´marche e e ainsi (et c’est surtout ce qu’on lui reproche) de la perte de temps engendr´e. e D’o` les am´liorations apport´es : u e e 2.1.1 Horizon partag´ ou Split horizon e Le concept est simple, il suffit de constater (toujours dans la figure VII.03) qu’il est stupide si R1 route via R2 des paquets pour R3, d’essayer pour R2 de router ces paquets vers R1. Donc R1 ne doit pas annoncer ` R2 des routes passant par R2. Les routes a annonc´es ne sont donc plus identiques sur chaque r´seau mais tiennent e e compte des destinations qui sont atteintes via chacune de ces liaisons pour ´viter ce type d’annonce. e R1 R3 H R2 figure VII.04 : L’“ horizon partag´ ” ne r´sout pas tout ! e e Il existe une variante plus efficace encore, qui consiste, pour R1, ` an-a noncer ` R2 la route (R3,R2,16), donc une route infinie. R2 ne pourra donc a pas utiliser cette route pour atteindre R3 via R1. Il n’y a pas de boucle de comptage ` l’infini et R2 concluera tout de suite ` l’inaccessibilit´ de R3. Ces a a e deux astuces r´unies sont rep´r´es dans la RFC sous le terme split horizon e ee with poisoned reverse.
  • Routage avec RIP 117 La figure VII.03 repr´sente donc un cas th´orique facile. En pratique, un e edes int´rˆts du routage dynamique ´tant d’avoir plusieurs routes possibles ee epour atteindre une destination, on aura plutˆt la situation de la figure VII.04 oce qui am`ne au cas de figure suivant : e Supposons que l’hˆte H devienne inaccessible, la technique ci-dessus oempˆchera R3 de tenter de router les datagrammes vers R1 et R2, mais, edu fait du caract`re asynchrone des mises ` jours, R1 ayant re¸u de R3 le e a cfait que H est inaccessible peut conclure que R2 est le meilleur chemin avecun coˆt de 3 et cette fausse information peut se propager ` R3 via R2 et le u acomptage ` l’infini est reparti. . . a Pour y rem´dier le protocole comporte un dispositif de mises ` jours e ad´clench´es : e e2.1.2 Mises ` jour d´clench´es ou Triggered updates a e e L’´ventualit´ d’une situation de comptage ` l’infini ´voqu´e dans le e e a e econtexte de la figure VII.04 peut ˆtre endigu´e par ce dispositif. e e Seules des mises ` jours tr`s rapides peuvent conduirent R1 et R2 ` a e aconverger vers la conclusion que la distance vers H est devenue infinie. La r`gle initiale est que quand un routeur change la m´trique d’une route, e eil doit envoyer un message de mise ` jour aussi vite que possible ` tous a ases voisins imm´diats. Ce message ne contient que ce qui a chang´ et non e el’int´gralit´ de la table. e e Mises ` jour rapides ne signifient pas pour autant “ tempˆtes de pa- a equets sur le r´seau ”, d’une part parceque le principe de l’horizon partag´ est e econserv´, et que d’autre part, une temporisation al´atoire (de 1 ` 5 secondes) e e alimite la fr´quence d’´mission de chaque mise ` jour. Durant ce laps de temps e e ala r´ception d’une mise ` jour peut ˆtre ´galement prise en compte et donc e a e eentrainer un changement des routes ´tablies. e La diff´rence entre ce dipositif et les annonces r´guli`res tient ` sa e e e afr´quence d’´mission et au contenu restreint aux seules routes dont la e em´trique a chang´. e e La RFC 2453 conclue toutefois “ However, counting to infinity is stillpossible ”. Qui n’est vraiment pas tr`s satisfaisant. . . e
  • 118 Routage dynamique d’IP 2.2 Le protocole RIPv1 vs RIPv2 RIP est encapsul´ dans paquet UDP avec 520 comme port de destination : e En−tete RIP (4 octets) IP UDP message RIP 20 8 4 octets + 25 routes x 20 octets = 504 octets figure VII.05 — RIP est transport´ par UDP/IP e ´ Etant donn´ le mode de propagation des annonces de routes, le choix du e protocole UDP est tout ` fait appropri´. Cependant, la RFC 2453 sp´cifie a e e que le nombre maximum de routes est limit´ ` 25, comme il faut 20 octets ea (figure VII.06) pour d´crire une route, la partie utile du datagramme fait e au plus 4 + 25 × 20 = 504 octets et le datagramme complet 532 octets au maximum, le risque de fragmentation est nul sur des lans et via les liaisons point ` point modernes (PPP par exemple). a Par contre, s’il faut propager plus de 25 routes, il faut envisager l’´mission e d’autant de datagramme que n´cessaire ! e ` A l’int´rieur du message RIP de la figure VII.03 les octets s’organisent e de la mani`re suivante : e 0 7 8 15 16 31 * commande version Domaine 4 octets toujours présents * Famille d’adresse Id. de route Adresse IPv4 * 20 octets (pour chaque Masque de sous−réseau route ajoutée) * Adresse IPv4 du prochain routeur Métrique (*) champ laissé vide en RIPv1 figure VII.06 — Format d’un message RIPv2 Le format d’un message RIP laisse plein d’espace vide (surtout quand il s’agit de RIPv1 — les champs marqu´s d’une ∗ sur la figure). L’alignement e des champs sur des mots de 32 bits en est ` l’origine. a
  • Routage avec RIP 119Commande 1 pour signifier une demande, request, et 2 pour une r´ponse, e reply. D’autres commandes existent mais elles sont obsol`tes ou non e document´es dans la RFC. . . eVersion 1 pour RIPv1 et 2 pour RIPv2.Domaine (RIPv2) Pour pouvoir faire tourner simultan´ment sur une mˆme e e machine plusieurs instances du daemon routed, ce champs contient un identifiant (PID. . .) qui permet de discriminer la provenance des routes.Famille d’adresse (Address familly identifier - AFI) Famille d’adresse, comme pour une socket (cf page 253) donc AF INET pour IPv4. Ce champ peut ´galement contenir la valeur hexad´cimale 0xffff e e pour indiquer qu’il s’agit un bloc d’authentification. Dans ce cas l’identifiant de route contient la valeur 2 et les 16 octets qui suivent un mot de passe en clair, align´ ` gauche et compl´t´ par des z´ros ! ea ee e Rien n’est d´fini dans la RFC 2453 pour ˆtre plus confidentiel. . . e eIdentifiant de route (Route tag - RIPv2) C’est un “ traceur ” pour identifier une route qui provient d’un autre IGP voire d’un autre EGP et qui est propag´e par RIP. eAdresse IPv4 Il s’agit de la destination ` atteindre par le routeur qui ´met a e cette annonce.Masque de sous-r´seau (RIPv2) Le masque de sous-r´seau ` appliquer e e a au champ qui pr´c`de. C’est un des apports principaux de RIPv2 par e e rapport ` RIPv1. aAdresse IPv4 du prochain routeur (Next hop - RIPv2) En fonctionnement normal l’adresse 0.0.0.0 signifie que la route passe par celui qui l’annonce. Ici il s’agit d’une autre adresse IPv4, diff´rente e de celle de l’annonceur. Celui-ci n’utilise pas RIP (sinon il ferait l’an- nonce lui-mˆme), mais sans doute un autre protocole de routage. e Ce cas de figure arrive ` la fronti`re entre deux r´seaux, quand par a e e exemple un routeur interne annonce une meilleure route via un routeur du mˆme lan. eM´trique Il s’agit de l’annonce de la m´trique, de 0 (hˆte local) ` 16 (infini e e o a non accessible) en pratique.En r´sum´, les apports de RIPv2 sont les suivants : e e 1. Transmission d’un masque de sous-r´seau avec chaque route. Ce point e est majeur parcequ’il permet d’utiliser RIP avec des r´seaux compor- e tant des sous-r´seaux ; e 2. Authentification (tr`s insuffisante puisque le mot de passe circule en e clair). Le constructeur Cisco a ajout´ des extension permettant l’usage e de MD5, c’est mieux ; 3. Indication d’un prochain routeur qui n’est pas celui qui annonce la route ;
  • 120 Routage dynamique d’IP 4. Indication de routes de provenances externes, ou Route tag ; 5. Usage de l’adresse multicast 244.0.0.9 pour propager des routes (plutˆt qu’un limited broadcast IP, plus perturbateur parceque lu par o tous les hˆtes. o 2.3 Algorithme Bellman-Ford Pour le fonctionnement de l’algorithme nous invitons le lecteur ` consul- a ter l’excellente simulation mise ` disposition par l’Universit´ Pierre Mend`s a e e France de Grenoble, ` cette url (cliquer sur le bouton “ Appliquette ”) : a http://brassens.upmf-grenoble.fr/IMSS/mamass/graphecomp/bellmannFord.htm 2.3.1 M´trique e Dans les r´seaux simples, le plus courant est d’utiliser le nombre de sauts, e hop, c’est ` dire le nombre de routeurs ` franchir pour arriver ` destination. a a a Les r´seaux plus complexe, on privil´gira une m´trique bas´e sur le d´lais, e e e e e par exemple. 2.4 Conclusion L’apparition des protocoles ` ´tats de liens n’a pas empˆch´ son a e e e d´veloppement, la RFC 2453 de 1998, d´crit RIPv2 encore en usage dans e e bon nombre de (petits) r´seaux. e 2.4.1 Points forts ◦ Simplicit´ de mise en œuvre ; e ◦ Simplicit´ du protocole permettant une compr´hension ais´e des e e e ´change ; e ◦ Robustesse des impl´mentations. e 2.4.2 Points faibles ◦ Limitation ` une profondeur de 15 ; a ◦ Probl`me de la vitesse de convergence (lente) de l’algorithme, et du e comptage ´ventuel jusqu’` la route infinie ; e a ◦ La m´trique n’est pas adapt´e ` des r´seaux dont les nœuds sont s´par´s e e a e e e par des liaisons utilisant des bandes passantes disparates ; ◦ L’authentification de l’´metteur des donn´es est tr`s pauvre en fonc- e e e tionnalit´ et pas du tout “ secure ” ; e ◦ La topologie des r´seaux RIP reste ` un seul niveau (pas de hi´rarchie e a e par exemple entre l’ar`te centrale d’un r´seau (backbone) et des r´seaux e e e terminaux.
  • 3 Routage avec OSPF 1213 Routage avec OSPF L’origine du protocole OSPF, et de la technologie de routage par “ ´tats edes liaisons ”, datent du tout d´but des ann´es 1980, pour faire face aux e einsuffisances du protocole ` vecteurs de distances, constat´es sur les r´seaux a e eArpanet et Cyclades. Son d´veloppement est dˆ aux efforts du groupe OSPF e ude l’IETF.3.1 Grandes lignes de fonctionnement Les explications qui suivent font l’hypoth`se d’un r´seau IP qui supporte e ela propagation de trames avec une adresse de destination de type multicast9 ,autrement dit ne traite pas le cas des r´seaux sans diffusion ce type ou encore eNBMA (Non Broadcast Multi-Access networks).Basiquement un protocole ` ´tats de liens a un fonctionnement simple : ae 1. Chaque routeur est responsable de la reconnaissance de ses voisins (et donc de leur nom) directs, c’est ` dire accessibles sur un des LANs a directement raccord´s ; e 2. Chaque routeur ´tablit un paquet nomm´ link state packet (LSP) qui e e contient la liste des noms et des coˆts (paragraphe 3.3.1) dans la u m´trique choisie pour atteindre chacun de ses voisins ; e 3. Le LSP est propag´ ` tous les routeurs et chacun conserve le plus e a r´cent LSP re¸u des autres routeurs dans une base de donn´es (link- e c e state database). Chaque routeur du nuage travaille ainsi ` partir des a mˆmes donn´es, une sorte de carte globale des ´tats ; e e e 4. Chaque routeur a la responsabilit´ par ses propres moyens (puissance e CPU) du calcul du chemin ` coˆt minimum (shortest path) ` partir de a u a lui-mˆme et pour atteindre tous les nœuds du r´seau ; e e 5. Les changements de topologie du nuage (comme la perte de connectivit´ e sur un interface) de routeurs sont rapidement d´tect´s, annonc´s au e e e voisinage, et pris en compte pour recalculer les routes. En r´sum´ un tel protocole a deux grandes activit´s, la premi`re est de e e e epropager ses ´tats et d’´couter ceux de ces voisins au sein de l’AS, c’est ce e equ’on appelle le flooding, en fran¸ais proc´d´ par inondation, la deuxi`me c e e eest de calculer des routes ` partir de tous les ´tats de liens re¸us. Ce calcul a e cest effectu´ ` l’aide de l’algorithme de Dijkstra de recherche du plus court eachemin dans un graphe. Pour les r´seaux complexes, OSPF permet le groupement de routeurs en ezones distinctes, areas, qui ´tablissent des nuages autonomes qui routent les edatagrammes entres eux, mais ne laissent pas filtrer leur trafic interne deLSP. Se d´gage ainsi une hi´rarchie de routeurs, ceux qui sont au milieu de e e 9 Page 42
  • 122 Routage dynamique d’IP la zone, ceux qui en sont ` la fronti`re et assurent les ´changes avec les autres a e e zones, enfin ceux qui assurent les ´changent avec les EGP (comme BGP) pour e le trafic externe ` l’AS. a Tous les ´changes sont authentifi´s. Par ce biais, seulement les routeurs e e pr´vus dans la configuration participent au routage. La technique d’authen- e tification peut diff´rer d’une zone ` une autre (cf paragraphe 3.7.2) e a Enfin, les ´changes de donn´es sont structur´es autour d’un protocole e e e nomm´ HELLO. Ce protocole applicatif est v´hicul´ par deux adresses e e e multicast (page 42) qui lui sont attribu´es : principalement 224.0.0.5 et e 224.0.0.6 dans certains cas, voir le paragraphe 3.6). Le protocole est encap- sul´ directement dans les datagrammes IP, et le champ PROTO contient la e valeur 89 (fichier /etc/protocols). 3.2 RIP vs OSPF Le choix de l’un ou de l’autre est assujeti ` l’examen de ce qui les a diff´rencie, que l’on r´sume dans les X points suivants : e e 1. RIP est limit´ ` 15 sauts (hop), qui limite de facto la structure du nuage ea de routeurs ; 2. Il faut utiliser RIPv2 car RIPv1 ne supporte la notion de masque de sous-r´seau (Variable Length Subnet Mask ou VLSM) ; e 3. Plus le nuage est important et les liaisons moins performantes (comme sur un WAN) plus la diffusion p´riodique des tables de routages e consomme des ressources (bande passante) ; 4. RIP converge beaucoup plus lentement qu’OSPF. La cons´quencee d’un changement de la topologie peut mettre plusieurs minutes ` ˆtre ae compl`tement int´gr´e, mˆme avec l’usage des adresses multicast, des e e e e mises ` jours d´clench´es et du concept d’horizon partag´ ; a e e e 5. Le principe fondateur, nombre de sauts, ne tient pas compte des d´lais e de propagation, le plus court chemin en terme de nombre de sauts ne d´signe pas n´cessairement le chemin qui offre le meilleur d´bit, sauf si e e e toutes les liens qui le composent sont de la mˆme technologie (Ethernet e 100BT par exemple) ; 6. L’absence de la possibilit´ d’une structuration des routeurs RIP en e zones ne permet pas une structuration intelligente des grands r´seaux, e surtout quand ils sont organis´s avec des classes d’adresses que l’on e puisse agr´ger entres elles en supernet (page 40) ; e 7. RIP n’a aucun m´canisme fiable d’authentification des annonces, ainsi e n’importe quel hˆte du r´seau peut empoisonner l’ensemble avec des o e routes farfelues (ou malveillantes, ou les deux. . .) ; 8. Le calcul des routes est distribu´ pour RIP, chaque routeur n’ayant e qu’une vue partielle du nuage, alors que pour OSPF chaque routeur de
  • RIP vs OSPF 123 la zone a une vue compl`te de l’´tat de tous les liens et ´tablit lui-mˆme e e e e le calcul des routes en se pla¸ant ` la racine du graphe de destination. c aEn synth`se OSPF est plus performants sur les points suivants : e 1. Pas de limitation en nombre de sauts, cette donn´e n’entre pas en ligne e de compte puisque ce sont des ´tats de liens qui sont propag´s ; e e 2. Les ´tats de liens sont envoy´s avec une adresse de destination multi- e e cast, et seules des mises ` jour des ´tats qui changent sont envoy´es. a e e La bande passante est pr´serv´e au maximum ; e e 3. OSPF converge tr`s vite, du fait de son m´canisme de propagation e e rapide (flooding) des ´tats ; e 4. Le calcul du plus court chemin peut conduire ` des routes de mˆme a e valeur et OSPF est capable de g´rer alors efficacement l’´quilibre de la e e charge (load balancing) entre tous ces cheminements possibles ; 5. L’organisation des grands r´seaux en zones est compl`tement possibles, e e ce qui d’une part r´duit le trafic des ´tats de liens et d’autre part permet e e des regroupement plus logiques bas´s sur les classes d’adresses IP ; e 6. Les informations ´chang´es entres routeurs peuvent ˆtre authentifi´es e e e e selon plusieures m´thodes, voir paragraphe 3.7.2 ; e 7. Les routes peuvent ˆtre ´tiquett´es, ainsi les routes en provenance des e e e EGP seront trac´es et trait´es sp´cifiquement. e e e
  • 124 Routage dynamique d’IP 3.3 Principe de propagation des ´tats e L’´tablissement des tables de routages d´pend de la compl´tude d’une e e e table appel´e link-state database, base de donn´es d’´tats de liens, pr´sente e e e e ` l’identique sur chaque routeur de la zone. Cette table est aliment´e par les a e ´tats de liens, Link State Packet (LSP), que s’envoient les routeurs entres e eux. Or cette distribution d´pend du routage. . . e Contrairement ` ce que l’on pourrait en d´duire, il n’y a pas de probl`me a e e de pr´c´dence entre ces deux op´rations, car la strat´gie de distribution re- e e e e pose sur l’usage d’une adresse de multicast, valable uniquement dans un LAN (page 42) donc qui ne d´pend pas de l’´tat de la table de routage ! e e Chaque changement d’´tat sur un lien doit ˆtre signal´ au plus vite ` tous e e e a les voisins except´ celui qui a signal´ le changement. C’est un proc´d´ par e e e e inondation, ou flooding dans la litt´rature. e Intuitivement ce mod`le de propagation semble rapide mais g´n`re po- e e e tentiellement un nombre exponentiel de copies de chaque paquet. . . Pour ´viter une tempˆte pr´visible de LSP, l’id´e initiale des concepteurs e e e e consiste ` ajouter ` chaque LSP un num´ro de s´quence : a a e e ◦ Chaque routeur conserve un trace du dernier num´ro de s´quence uti- e e lis´. Quand il g´n`re un nouveau LSP il incr´mente cette valeur ; e e e e ◦ Quand un routeur re¸oit un LSP depuis un voisin, il compare son c num´ro de s´quence avec celui ´ventuellement d´j` pr´sent dans sa e e e ea e base de donn´es. e – Si le num´ro est plus ancien, il oublie le paquet, e – Si le num´ro est plus r´cent il remplace ´ventuellement celui d´j` e e e ea pr´sent en m´moire. e e Ce dispositif tend ` mod´rer la tempˆte de mises ` jour mais induit a e e a d’autres interrogations : 1. Que faire quand on arrive ` la valeur maximale du compteur (mˆme a e avec des registre 64bits ¸a arrive un jour) ? Plus g´n´ralement comment c e e d´terminer la relation d’ordre entre deux LSP de valeur a et b ? e 2. Que se passe t-il quand un routeur red´marre ? e Il annonce des LSP avec un num´ro de s´quence plus petit que ceux e e d´j` en circulation et qui donc seront ignor´s, mˆme si plus pertinents. ea e e Cette constatation est voisine de la situation de deux parties d’un mˆme e r´seau, s´par´es ` la suite d’une rupture de connectivit´e et qui se e e e a e retrouvent mais apr`s que l’un des compteurs soit repass´ par 0 ? e e
  • Principe de propagation des ´tats e 125Qui am`nent les r´ponses suivantes : e e 1. Le num´ro de s´quence est un compteur, avec une valeur minimale e e et maximale finie. Quand la valeur maximale est atteinte, il repasse par z´ro, exactement comme un counter de SMI (page 228, chapitre e concernant SNMP). Ensuite, pour ´tablir une relation d’ordre entre les LSP, la r`gle suivante e e est adopt´e : e b n/2 n/2 n/2 + a n/2 + b a a b n . n . 0, 1, 2.. 0, 1, 2.. Zone où b serait plus Zone où a serait plus ancien que a récent que b figure VII.07 — Relation d’ordre entre deux LSP On peut d´clarer que le LSP b est plus r´cent que a si les conditions : e e n n |a − b| < |a − b| > 2 ou encore 2 a<b a>b sont r´unies. C’est ce que sch´matise graphiquement la figure VII.07 e e ci-dessus ; 2. Pour r´pondre ` la deuxi`me interrogation, on introduit une nouvelle e a e donn´e : l’ˆge du LSP. e a C’est une valeur num´rique (cod´e sur 16 bits selon la RFC 2328) po- e e sitionn´e non nulle par le routeur qui ´met le LSP. e e ◦ Chaque routeur qui re¸oit un LSP doit d´cr´menter l’ˆge d’au moins c e e a 1 unit´ et continuera ainsi dans le temps jusqu’` la valeur 0, e a ` a ◦ A l’ˆge 0 le LSP ne doit plus ˆtre transmis mais peut participer e encore au calcul des routes, ◦ N’importe quel LSP (en terme de num´ro de s´quence) qui arrive e e avec un ˆge non nul peut remplacer un LSP d’ˆge nul. a aEn r´sum´ : e e ◦ Quand un routeur R g´n`re un LSP, son num´ro de s´quence doit e e e e ˆtre plus grand de 1 (modulo n, cette derni`re valeur ´tant la valeur e e e 32 maximale du compteur lui mˆme, par exemple 2 −1) que la pr´c´dente e e e s´quence g´n´r´e. L’ˆge doit ˆtre positionn´ ` une valeur maximale. e e ee a e ea
  • 126 Routage dynamique d’IP ◦ Quand un routeur autre que R re¸oit le LSP, il l’accepte en remplace- c ment de tout LSP avec un plus petit num´ro de s´quence (donc plus e e ancien). ◦ Si l’ˆge du LSP stock´ ´tait 0, le nouvel LSP le remplace de mani`re a ee e inconditionnelle : on ne peut propager un LSP d’ˆge nul. a ◦ Le v´ritable algorithme est plus complexe, voir la RFC 2328 page 143, e The flooding procedure. Etape 1 : A B C G D E F Etape 2 : A B C G D E F Etape 3 : A B C G D E F figure VII.08 — Propagation des LSP par inondation ou “ flooding ” La figure VII.08 montre un exemple simple de propagation d’un chan- gement d’´tat initi´ par le nœud C. En trois ´tapes tous les routeurs sont e e e ` l’´tape 2 on peut remarquer que les routeurs B,F et G mis au courant. A e s’interdisent de renvoyer le LSP ` C, son ´metteur. On remarque ´galement a e e que F et G s’envoient le mˆme paquet, mais celui issu de F a un ˆge plus e a ancien, il sera donc oubli´ imm´diatement, comme celui issu de G, pour la e e mˆme raison. e Le Nœud E re¸oit le mˆme LSP depuis B et F, le premier arriv´ sera c e e pris en compte, le deuxi`me oubli´. Mˆme remarque pour D ` la fin de la e e e a troisi`me ´tape. e e
  • Valeur des ´tats de liens e 127 La dur´e totale de ces trois ´tapes est pratiquement celle n´cessaire pour e e epropager les datagrammes (donc fortement d´pendante de la bande pas- esante), de quelques milli-secondes ` quelques centaines de milli-secondes, adonc !3.3.1 Valeur des ´tats de liens e Le coˆt des liens, nomm´ ´galement la m´trique, agit directement sur le u ee echoix d’une route plutˆt qu’une autre comme on le voit dans le paragraphe oqui suit.Le constructeur Cisco pr´conise10 une formule qui est reprise partout : e 100000000 cost = bande passante en bps bps signifie bits per second. Ce qui signifie qu’une liaison Ethernet ` a10Mbits (dix milions de bits par seconde, un milion d’octets par secondes) aun coˆt de 108 /107 = 10. uLe petit tableau ci-dessous indique quelques valeurs pour des d´bit connus : e M´dia e Coˆt u Liaison s´rie 56kbps e 1785 T1 (s´rie 1544 kbps) e 64 E1 (s´rie 2048 kbps) e 48 Token ring 4Mbps 25 Ethernet 10Mbps 10 Token ring 16Mbps 6 Ethernet 100Mbps 1 ... ... Bien entendu on peut toujours imposer manuellement sa propre valeur decoˆt d’une liaison, pour influencer le routage ! u3.4 Calcul du plus court chemin Pour le fonctionnement de l’algorithme de Dijkstra nous invitons le lec-teur ` consulter l’excellente simulation mise ` disposition par l’Universit´ a a ePierre Mend`s France de Grenoble, ` cette url (cliquer sur le bouton “ Ap- e apliquette ”) :http://brassens.upmf-grenoble.fr/IMSS/mamass/graphecomp/dijkstra.htm3.5 Hi´rarchie de routeurs e Les r´seaux ` administrer peuvent ˆtre vastes et complexes, dans ces e a econditions il est souvent pertinent de les regrouper en sous-ensembles. La 10 http://www.cisco.com/warp/customer/104/1.html
  • 128 Routage dynamique d’IP conception d’OSPF permet de le faire, il s’agit d’un concept nomm´ zone ou e (area) et qui se traduit par une hi´rarchisation du routage. e Outre la structuration plus claire du r´seau global en sous r´seaux, l’avan- e e tage de cette approche est ´galement de diminuer le nombre de routes sur e lequel porte le calcul de plus court chemin, et aussi de diminuer le trafic des mises ` jour, non n´gligeable sur un r´seau vaste et complexe. a e e La RFC pr´cise qu’une zone doit faire le lien avec toutes les autres, il e s’agit forc´ment de la zone 0, qui joue donc le rˆle de l’arˆte centrale (OSPF e o e Backbone). De cette structuration d´coule le fait que tous les routeurs n’ont pas e le mˆme rˆle, certain sont au milieu d’une zone et d’autres ` la fronti`re e o a e entre deux zones, voire mˆme ` la fronti`re entre le nuage OSPF et d’autres e a e m´canismes de routage, vers d’autres AS : e Area 2 Area 3 IR IR ABR BR Area 0 (Backbone OSPF) Autre routeur (RIP) ASBR Autre AS (BGP) ABR Area 1 figure VII.09 — Organisation en zones – Hi´rarchie de routeurs e La RFC pr´cise quatre types de routeurs dans ce cas de figure : e Internal routers (IR) C’est le cas le plus simple d’un routeur au milieu d’un nuage ` l’int´rieur d’une zone. Il n’a qu’une seule base d’´tats de a e e liens qu’il met ` jour avec les autres routeurs de son voisinage ; a Area border routers (ABR) Ces routeurs se trouvent attach´s ` au moins e a deux zones. Ils poss`dent autant de bases de donn´es d’´tats de liens e e e qu’ils ont d’interfaces connect´s ` des zones diff´rentes. Ces bases e a e diff`rent car elles concernent des nuages diff´rents. Elles doivent ˆtre e e e propag´es vers la zone 0 sous forme d’une route r´sum´e (summarized) e e e
  • Fonctionnement ` l’int´rieur d’une zone a e 129 qui utilise au mieux les possibilit´ du CIDR. Bien entendu cela suppose e que les r´seaux puissent ˆtre aggr´g´s entres eux ; e e e eBackbone routers (BR) Il s’agit de routeurs qui sont raccord´s au moins e ` la zone 0. LA RFC n’est pas claire sur leur signification exacte. . . aAutonomous system boundary routeurs (ASBR) C’est le (les) rou- teur(s) qui marque(nt) la fronti`re d’influence de l’IGP. Il peut ˆtre en e e relation avec n’importe quel autre protocole de routage, par exemple RIP et BGP sur la figure VII.09 avec lesquelles il ´tablit des passerelles e et ´change des routes. Les usagers de l’IGP ont besoin d’´changes avec e e l’ext´rieur (autres r´seaux, autres AS). e e3.6 Fonctionnement ` l’int´rieur d’une zone a e Le fonctionnement du m´canisme d’inondation ` l’int´rieur d’une zone, e a etel que nous l’avons succintement d´crit au paragraphe 3.3, induit que lors ede la diffusion d’un LSP chaque routeur propage le changement d’´tat re¸u e c 2` son voisinage r´seau. Ce comportement induit un trafic en N , si N est lea enombre de routeurs sur le LAN en question. OSPF essaie de r´duire ce nombre ` seulement N en faisant jouer un rˆle e a oparticulier ` l’un des routeurs, le routeur d´sign´, ou Designated Router (DR). a e eCelui-ci re¸oit les mises ` jours car il ´coute sur une autre adresse multicast, c a e224.0.0.6 (tous les routeurs OSPF d´sign´s) et si besoin est propage ` nouveau e e acette information vers les autres routeurs du LAN, avec ce coup-ci l’adresse224.0.0.5 (tous les routeurs OSPF). Se pose imm´diatement la question de la panne ´ventuelle du routeur e e a e `DR, celle-ci bloquerait la mise ` jour des bases d’´tats de liens. A cet effet unrouteur d´sign´ de sauvegarde est ´galement ´lu, c’est le Backup Designated e e e eRouter, mis ` jour en mˆme temps que le DR mais qui reste muet sur le a er´seau tant que le protocole HELLO n’a pas d´tect´ un dysfonctionnement e e edu DR. R DR BDR figure VII.10 — Propagation d’un LSP, sans et avec un DR Sur la figure VII.10, sch´ma de gauche, le routeur R propage un nouvel eLSP ` tous ses voisins, puis chacun propage ce qu’il a re¸u vers les voisins a c
  • 130 Routage dynamique d’IP pour lesquels il n’a rien re¸u. Le nombre de paquets est alors en th´orie celui c e 11 N −1 du nombre de paires possibles , soit encore : N × 2 , 10 pour cet exemple. Pour le sch´ma de droite, le routeur DR a re¸u un LSP et le diffuse aux e c trois routeurs concern´s. Notons que le BDR ne fait rien, il a ´galement re¸u e e c la mise ` jour mais s’abstient de toute action tant que le DR est op´rationnel. a e Avant de pouvoir ´tablir une hi´rarchie entres eux et d’´changer efficace- e e e ment des ´tats de liens, les routeurs doivent d´terminer qui sont leurs voisins, e e autrement dit la topologie du r´seau qui les entoure. e 3.6.1 Voisinage et adjacence La RFC 2328 d´finit une progression selon 8 ´tats (7 pour les r´seaux avec e e e propagation par multicast) pour chaque routeur OSPF, avant de pouvoir ´changer efficacement avec ses voisins. Il est utile d’en avoir connaissance e pour diagnostiquer une situation. L’´tablissement (ou non) de ces ´tats repose sur la structuration du pro- e e tocole HELLO, qui se d´cline en cinq types de paquets diff´rents, nous les e e examinons au paragraphe 3.7 Down C’est l’´tat initial, pr´alable ` tout ´tablissement d’une conversation e e a e avec le voisinage. Il indique qu’aucune activit´ de voisinage n’a ´t´ e ee d´tect´e depuis un moment ; e e Init Les routeurs envoient des paquets de type Hello ` fr´quence r´guli`re a e e e (environ 10 secondes). La r´ception d’un tel paquet suffit pour passer e ` cet ´tat. a e Dans la liste des voisins transmise dans le paquet le routeur n’apparaˆıt pas, la communication reste uni-directionnelle ; Two-way Un routeur entre dans cet ´tat s’il se voit dans le paquet Hello e propag´ par un voisin. La communication est alors bi-directionnelle. e Cet ´tat est la relation de voisinage la plus basique. e Pour pouvoir ´changer des ´tats de liens et construire des routes, chaque e e routeur doit former une contigu¨ e (adjacency) avec chacun de ses voi- ıt´ sins. C’est une relation avanc´e entre routeurs OSPF. Elle s’´tablit en e e commen¸ant par l’´tat suivant ; c e ExStart C’est le premier pas pour constituer une contigu¨ e de routeurs ıt´ entre deux voisins. Le but de cette ´tape est de d´cider qui sera le maˆ e e ıtre et l’esclave dans la relation. Des paquets de type DataBase Description paquet (cf page 131) sont ´chang´es, et le routeur ayant la plus forte e e valeur de RID (Router ID) gagne. Cette derni`re valeur est fonction de e l’adresse IP la plus ´lev´e pour tous les interfaces du routeur, et d’un e e coefficient configur´ manuellement (non d´mocratique) ; e e 11 C’est le nombre de paires du triangle de Pascal http://fr.wikipedia.org/wiki/ Triangle_de_Pascal
  • Protocole HELLO 131Exchange Les routeurs s’´changent l’int´gralit´ de leur base d’´tats de liens e e e e ` l’aide de paquets DBD ; a `Loading A ce stade les routeurs terminent de compl´ter leur table de liens. e Les ´tats qui ont besoin d’ˆtre rafraˆ e e ıchis font l’objet de requˆtes ` l’aide e a de paquets de type Link-state request (LSR) auxquels sont r´ponduse des paquets de type Link-state update (LSU) (Voir paragraphe 3.7) qui contiennent les LSP, appel´s LSA en pratique, cœur du fonctionnement e du protocole. Les LSU sont acquitt´s par des Link-state acknowledgment (LSAck) ; eFull Une fois atteint cet ´tat, l’adjacence d’un routeur avec un voisin est e compl`te. Chaque routeur conserve une liste de ses voisins dans une e base de donn´es adjacency database. e3.7 Protocole HELLO Le protocole HELLO est en charge de l’´tablissement et du maintien des erelations de voisinage entre routeurs. Il s’assure ´galement que les commu- enications entre chaque voisin sont bi-directionnelles. Comme nous l’avonspr´cis´ en introduction ce paquet est encapsul´ dans un datagramme IP, e e edonc en lieu et place d’un protocole de transport (qu’il ne remplace pas). Des paquets de type HELLO sont envoy´s ` fr´quence p´riodique sur tous e a e eles interfaces des routeurs. Les communications sont rep´r´es comme ´tant ee ebi-directionnelles si un routeur se reconnait dans la liste (des voisins connus)´mise dans le paquet HELLO d’un voisin. Le protocole sert ´galement `e e al’´lection du Routeur D´sign´ (DR). e e e Sur les r´seaux permettant le multicast, chaque routeur s’annonce lui- emˆme en envoyant p´riodiquement des paquets HELLO. Ce dispositif permet e eaux routeurs voisins de se connaˆ dynamiquement, de v´rifier continuelle- ıtre ement l’accessibilit´ des voisins d´j` connus. e ea3.7.1 Cinq types de paquets Le protocole HELLO se compose principalement d’un en-tˆte de 6 mots ede 4 octets (24 octets) et d’un compl´ment qui d´pend du type de paquet. e eCe type est d´fini d`s le premier mot de l’en-tˆte. e e eHello (type 1) Ce paquet ´tablit et maintient les relations de voisinage e (adjacency information) ;DataBase Description paquet (type 2) (DBD) Sert ` d´crire le a e contenu des bases de donn´es d’´tats de liens des routeurs OSPF lors e e de l’´tablissement d’une contigu¨ e de routeurs. De multiples paquets e ıt´ de ce type peuvent ˆtre envoy´s pour d´crire l’int´gralit´ de la base de e e e e e donn´es ; eLink-state request (type 3) (LSR) Une fois ´chang´e la descriptions de e e la base d’´tats, un routeur peut s’apercevoir qu’une partie des liens sont e
  • 132 Routage dynamique d’IP p´rim´s (date de fraˆ e e ıcheur). Ce type 3 est alors utilis´ pour requ´rir du e e voisin une mise ` jour. De multiples paquets peuvent ˆtre envoy´s ; a e e Link-state update (type 4) (LSU) Ces paquets sont utilis´s par le e proc´d´ d’inondation pr´sent´ au paragraphe 3.3. Chacun d’eux trans- e e e e porte une collection de LSP (on les nomme ´galement LSA) ` desti- e a nation du voisinage imm´diat. Pour rendre la proc´dure d’inondation e e efficace ces paquets doivent ˆtre explicitement acquitt´s par des paquets e e de type 5 ; Link-state acknowledgment (type 5) (LSAck) Chaque LSA envoy´ est e acquitt´ par l’´mission d’un paquet de type 5. Plusieurs acquittements e e peuvent ˆtre combin´s dans un seul paquet. e e L’adresse IP de destination peut prendre une valeur multicast ou uni- cast. Type 1 24 octets pour la partie fixe 5 Type 1 : Hello Type 4 : LSU 2 3 4 Type 2 : BDD Type 5 : LSAck Type 3 : LSR figure VII.11 — Organisation globale de l’en-tˆte du protocole OSPF e
  • En-tˆte standard des paquets OSPF e 1333.7.2 En-tˆte standard des paquets OSPF eTous les paquets OSPF d´marrent par un en-tˆte standard de 24 octets : e e 31 24 23 16 15 0 Version# Type Packet length En−tete standard (6 mots de 4 octets) Router ID Area ID Checksum AuType Authentication Authentication (Selon valeur de ’Type’) .... figure VII.12 — En-tˆte standard de 24 octets eVersion La valeur 2 est requise, c’est la version du protocole.Type Une valeur comprise entre 1 et 5 qui d´termine la partie variable de e l’en-tˆte. ePacket length Longueur du paquet en octets, y compris l’en-tˆte. eRouteur ID C’est l’identifiant du routeur (RID).Area ID C’est le num´ro de la zone. La repr´sentation d´cimale point´e est e e e e utilis´e, par exemple pour la zone backbone ce champ vaut 0.0.0.0. eChecksum Il porte sur la totalit´ du paquet moins cette zone et les 8 octets e du champ Authentication.AuType Tous les ´changes sont authentifi´s. Ce champ en d´crit la e e e m´thode. Trois valeurs sont pr´vues par la RFC : e e AuType Description 0 Pas d’authentification 1 Mot de passe en clair sur le r´seau e 2 Crypto ` partir d’un secret partag´ a eAuthentication 64 bits qui sont utilis´s selon la valeur du champ pr´c´dent. e e e3.7.3 En-tˆte des paquets HELLO e Un paquet de type 1 (Hello) est envoy´ p´riodiquement sur tous les inter- e efaces des routeurs qui participent au nuage OSPF. L’objectif est de maintenir
  • 134 Routage dynamique d’IP les relations de voisinages et d’adjacences comme vu pr´c´dement. C’est une e e sorte de Keep-alive pour les besoins du protocole. Les octets de la figure VII.13 sont ` placer en continuit´ de ceux de la a e figure VII.12, pour former un en-tˆte de 24 + 24 = 48 octets minimum. La e taille s’accroˆ ensuite de quatre octets par RID suppl´mentaire de voisin. ıt e 31 16 15 0 Network Mask Hello Interval Options Rtr Prio Router Dead Interval Designated Router Backup Designated Router Neighbor ... figure VII.13 — En-tˆte du paquet HELLO e Network Mask Le masque de sous r´seau associ´ ` l’interface. e ea Options Les options du routeur. Cinq bits sont utilis´s seulement pour e d´crire des possibilit´s annexes au fonctionnement global. e e Hello Interval Le nombre de secondes entre deux paquets de ce type. Rtr Prio La priorit´ de ce routeur. C’est une valeur positionn´e manuelle- e e ment dans la configuration et qui a un impact direct sur le r´sultat de e l’´lection des DR et BDR. Une valeur 0 n’a aucun impact, alors que e 255 assure quasiment le routeur d’ˆtre DR. e Router Dead Interval Le nombre de secondes avant de d´clarer inattei- e gnable un routeur devenu silencieux. Designated Router C’est l’adresse IP du DR pour ce LAN. Ce champ est ` 0.0.0.0 s’il n’y en a pas. a Backup Designated Router Idem pour le BDR. Neighbor Il s’agit de la liste des RID (Router ID) des voisins connus et de qui on a re¸u r´cemment (c’est ` dire avec un d´lai inf´rieur ` la valeur c e a e e a du champ Router Dead Interval) un paquet de type 1. La description des 4 autres types de paquets se trouve ` l’annexe a A.3 de la RFC.
  • 4 Bibliographie 1354 BibliographiePour en savoir plus :RFC 1058 “ Routing Information Protocol. ” C.L. Hedrick. June 1988. (Format : TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Sta- tus : HISTORIC)RFC 1247 “ OSPF Version 2. ” J. Moy. July 1991. (Format : TXT=433332, PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status : DRAFT STANDARD)RFC 2328 “ OSPF Version 2. ” J. Moy. April 1998. (Format : TXT=447367 bytes) (Obsoletes RFC2178) (Also STD0054) (Status : STANDARD)RFC 2453 “ RIP Version 2. ” G. Malkin. November 1998. (Format : TXT=98462 bytes) (Obsoletes RFC1723) (Also STD0056) (Status : STANDARD)Sites web :CISCO OSPF Design Guide http://www.cisco.com/warp/customer/104/1. htmlAlgorithme de Bellman-Ford http://brassens.upmf-grenoble.fr/IMSS/ mamass/graphecomp/bellmannFord.htmAlgorithme de Dijkstra http://brassens.upmf-grenoble.fr/IMSS/mamass/ graphecomp/dijkstra.htmOuvrages de r´f´rences : ee ◦ W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley ◦ Christian Huitema - Le routage dans l’Internet - EYROLLES ◦ Radia Perlman — “ Interconnections Second Edition ” – Briges, Rou- ters, Switches, and Internetworking Protocoles — Addison–Wesley
  • 136 Routage dynamique d’IP
  • Chapitre VIII ´ e El´ments de r´seaux e1 Hˆtes ou services virtuels o HTTP HTTP HTTP HTTP A B C D ipC ipD ipA ipB ipWWW Traffic HTTP Consolidation possible sur un seul hote figure VIII.01 — Serveur(s) HTTP virtuel(s) La machine B (d’adresse IP fixe ipB) h´berge par exemple le service eHTTP d’adresse ip ipWWW. Cette op´ration est rendue possible si le esyst`me d’exploitation de B autorise la notion d’alias IP. e Si les machines A, C et D ex´cutent ´galement un serveur HTTP, elles e epeuvent potentiellement prendre le relais de la machine B, d`s lors que el’adresse ipWWW aura ´t´ retir´e de la machine B pour ˆtre reconfigur´e ee e e esur l’une d’entres elles. Cette op´ration peut se faire manuellement ou via un outil d’administra- etion. Elle permet de faire transiter tr`s rapidement des services d’une machine e` une autre, sans rupture ou presque de la continuit´. Vu des clients il s’agita etoujours de la mˆme machine, mais elle est virtuelle puisqu’elle n’existe pas ephysiquement. Les syst`mes d’exploitations modernes facilitent la construction de ma- e
  • 138 ´ e El´ments de r´seaux e chines virtuelles. FreeBSD a un m´canisme tr`s adapt´ nomm´ “ jail1 ”, e e e e autrement dit une prison. C’est une version tr`s am´lior´e de la primitive e e e unix chroot. Les “ jails ” permettent de virtualiser ` la demande les services a puisqu’ils peuvent ˆtre d´marr´s ou stopp´s ` la demande. e e e e a Solaris 10, poss`de un m´canisme qui fonctionne de la mˆme e e e 2 mani`re. . .Nomm´ “ zone ”. e e Aussi bien les zones de Solaris que les jails de FreeBSD peuvent utiliser des alias IP pour assurer leur autonomie sur le r´seau, mais ces deux m´canismes e e manquent ` ce jour d’une virtualisation compl`te de la stack IP qui leur a e permettrait d’avoir une route par d´faut dans chaque instance virtuelle du e syst`me, ce qui les rendrait beaucoup plus ind´pendants de l’hˆte h´bergeur e e o e et autoriserait des configurations beaucoup plus souples. La consolidation des hˆtes A, B,C et D (et potentiellement en nombre bien o plus grand encore) est possible de nos jours sur une seule machine. L’´norme e mont´e en puissance des processeurs multi-cores et de l’´volution des archi- e e tectures SMP3 d’une part, et d’autre part la maturit´ des technologies de e 4 virtualisation des syst`mes d’exploitation e Cette op´ration permet d’´viter l’´parpillement des “ petits serveurs ” e e e au profit de machines sur lesquelles on peut concentrer un effort de mainte- nance mat´rielle plus grand tout en r´alisant mˆme une ´conomie d’´chelle e e e e e pour le mat´riel. Au niveau de la maintenance des syst`mes d’exploitation e e l’effort d’administration reste le mˆmes, puisque proportionnel au nombre e d’instances en exploitation.. 1 http://docs.freebsd.org/44doc/papers/jail/jail.html 2 http://www.sun.com/software/whitepapers/solaris10/grid_containers.pdf 3 http://www.sun.com/smi/Press/sunflash/2005-01/sunflash.20050118.1.xml 4 Les produits commerciaux sont bien connus, l’OpenSource n’est pas en reste avec le projet XEN http://www.cl.cam.ac.uk/research/srg/netos/xen/
  • 2 Tunnel IP 1392 Tunnel IP A Encapsulation d’IP dans IP B figure VIII.02 — Tunnel IP - Principe Le tunnel permet d’encapsuler un protocole dans un autre de mˆme niveau eou sup´rieur. Pr´c´demment, page 30, nous avons d´j` analys´ l’encapsula- e e e ea etion des couches de la pile Arpa selon une progression naturelle de fonction-nalit´s. Ici, si le principe d’encapsulation est conserv´, la logique initiale de e econstruction, elle, est bouscul´e. Par exemple on peut envisager d’encapsuler eIP dans de multiple protocole autres qu’Ethernet, comme PPP5 , IP, dansune couche de transport comme TCP, voire mˆme dans une couche applica- etive comme HTTP. Ce dernier exemple peut paraˆ “ contre nature ” et ıtrepourtant cela fonctionne. . . Construire un tunnel a un coˆt : d’une part celui de la perte d’es- upace de donn´es dans le datagramme (il faut loger un ou plusieurs en-tˆtes e esuppl´mentaires et le MTU reste constant lui !) et d’autre part celui du trai- etement suppl´mentaire (d´capsulation, analyse) engendr´ par l’ajout de ces e e enouveaux en-tˆtes.e En r´sum´, construire un tunnel se traduit par une perte d’espace pour e eles donn´es dans les datagrammes et par une consommation accrue de ecycles cpus pour traiter les en-tˆtes suppl´mentaires. Heureusement le gain e een fonctionnalit´s pour le r´seau est substanciel, comme les exemples qui e evont suivre tˆchent de l’illustrer ! a Les tunnels qui transitent par une couche de transport sont g´r´s par eeune application (par exemple sshd ou httptunnel). Aussi le trafic de da-tagrammes remonte au niveau applicatif pour redescendre au niveau IP, cequi a l’avantage de pouvoir ˆtre mis en œuvre par un utilisateur n’ayant pas en´cessairement les droits de l’administrateur6 , mais par contre, outre une econsommation suppl´mentaire de cycles cpu et des changements de contexte einh´rents ` l’architecture logicielle7 , a l’inconv´nient d’ˆtre d´di´ ` un seul e a e e e ea 5 “ Point to Point Protocol ”, lui -mˆme ´ventuellement encapsul´ dans de l’Ethernet e e e(PPPoE RFC 2516) ou de l’ATM (PPPoA pour l’ADSL, RFC 2364) 6 Pour encapsuler IP dans IP par exemple, il faut pouvoir ´crire directement dans IP ece qui n´cessite une socket en mode raw et donc un uid 0 ` l’ex´cution e a e 7 Rappelons que les processus applicatifs standards s’ex´cutent en mode utilisateur, eet que les transferts entre la couche de transport (dans le noyau) et la couche applicatives’effectuent via un jeu de primitives du syst`me, voir la description des sockets de Berkeley epage 251
  • 140 ´ e El´ments de r´seaux e port (par exemple celui d’une application non crypt´e comme pop au travers e une liaison ssh. Il faut noter que depuis la version 4.3 d’OpenSSH les tunnels sont possibles, non limit´s ` un seul port)8 . e a Encapsuler IP dans IP a l’avantage de rester g´n´raliste du point de vue e e des applications. Sur la figure VIII.02 le tunnel IP encapsule donc de l’IP dans lui mˆme. Pour les routeurs qui acheminent ce trafic il s’agit de datagrammes e IP avec le type 4 (cf le fichier /etc/protocols au lieu des types 1 (icmp) 6 (tcp) ou 17 (udp) plus habituels. 2.1 Tunnel IP avec l’interface gif La figure Romanchapter.03 illustre l’encapsulation d’IP dans IP grˆce ` l’usage du a a “ generic tunnel interface ”9 . Il s’agit d’un pseudo-device (pas d’inter- face r´el associ´ au device), qui permet d’encapsuler de l’IP (version 4 ou 6) e e dans de l’IP (version 4 ou 6)10 . Le but de cet exemple de tunnel est de montrer un routage de data- grammes issus d’un r´seau priv´, le 192.168.2.0/24 (RFC 1918), depuis la e e machine B (IPB ), vers la machine A (IPA ) et qui traverse un r´seau public e rout´ quelconque, non nomm´ sur la figure, de telle sorte que A soit int´gr´e e e e e au LAN 192.168.2.0/24. ◦ Par hypoth`se la machine A sait comment router vers le e 192.168.2.0/24. Un de ses interfaces r´seaux peut ˆtre surcharg´ avec e e e une adresse dans cette classe C. ◦ Le r´seau 192.168.249.0/30 sert de r´seau d’interconnexion entre les e e deux machines. Concr`tement, il s’agit d’attribuer une adresse IP ` e a chacun des pseudo-devices, qui ne soit pas d´j` dans l’un des r´seaux ea e attach´s ` chacune des machines. e a Conceptuellement, il serait parfaitement possible d’utiliser, par exemple, des adresses dans le 192.168.2.0/24, mais l’auteur pr´f`re ee l’usage d’un r´seau d’interconnexion qui permet de bien s´parer fonc- e e tionnellement les adresses IP qui constituent le tunnel en lui-mˆme de e celles qui sont amen´es ` l’emprunter. e a De plus, si on souhaite (et c’est une quasi obligation quand on utilise des tunnels) ajouter un filtrage IP sur la machine B, il est beaucoup plus ais´ pour la conception des r`gles de filtrage de consid´rer l’origine e e e des datagrammes ayant une adresse source dans le 192.168.2.0/24 uniquement derri`re le filtre. e 8 La mise en œuvre d’un tunnel au travers http pour contourner le filtrage en sortie d’un site n’est absolument pas recommand´e par l’auteur de ces pages et laiss´e ` la compl`te e e a e responsabilit´ du lecteur e 9 “ man gif ” sous FreeBSD, NetBSD, OpenBSD ou Mac OS X 10 Nous avons d´j` rencontr´ un tel interface virtuel avec l’interface de “ loopback ” lo0 ea e page 75
  • Tunnel IP avec l’interface gif 141 Examinons maintenant quelle pourrait ˆtre la configuration sp´cifique ` e e ace tunnel, Sur la machine A :ifconfig gif0 createifconfig gif0 inet tunnel IP(A) IP(B)ifconfig gif0 inet 192.168.249.1 192.168.249.2 netmask 0xfffffffcroute add -net 192.168.2.0 192.168.249.2 Notez l’ajout de la route sp´cifique vers le r´seau non directement rac- e ecord´. Puis, ex´cution des op´rations sym´triques sur la machine B : e e e eifconfig gif0 createifconfig gif0 inet tunnel IP(B) IP(A)ifconfig gif0 inet 192.168.249.2 192.168.249.1 netmask 0xfffffffc A B 192.168.249.1 gif0 192.168.249.2 gif0 .200 fxp0 hem0 192.168.2.0/24 192.168.2.229 192.168.2.218 IP(A) IP(B) Datagrammes IPv4 non routables encapsulés dans des datagrammes IPv4 routables. figure VIII.03 — Tunnel IP - cas concrˆt e Notez que la premi`re ligne de configuration pr´cise la source et la desti- e enation r´elle des datagrammes alors que la deuxi`me indique l’adresse locale e eet distante des extr´mit´s du tunnel. C’est une ´criture particuli`re, adapt´e e e e e eau pilote de l’interface gif0 pour la configuration des tunnels.Sur la machine B, on peut voir le r´sultat de la configuration comme ¸a : e c$ ifconfig gif0gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 tunnel inet IP(B) --> IP(A) inet 192.168.249.2 -> 192.168.249.1 netmask 0xfffffffc$ netstat -f inet -rn...192.168.249.1 192.168.249.2 UH 0 9779 - gif0Et sur la machine A (remarquez la plus petite valeur de MTU) :$ ifconfig gif0gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 tunnel inet IP(A) --> IP(B) inet 192.168.249.1 -> 192.168.249.2 netmask 0xfffffffc$ netstat -f inet -rn...192.168.2.0/24 192.168.249.2 UGS 0 83 gif0192.168.249.2 192.168.249.1 UH 1 8941 gif0
  • 142 ´ e El´ments de r´seaux e Enfin, si on examine11 sur les interfaces hme0 puis gif0 de B le passage des datagrammes d’un ping, envoy´s depuis A vers 192.168.2.200, l’obser- e vation pratique rejoint la th´orie : on retrouve bien sur l’interface du tunnel e (gif0) l’en-tˆte 2, d´capsul´ de son en-tˆte 1. Le datagramme est alors dis- e e e e ponible au niveau de la pile IP de B pour ˆtre rout´ (routage direct12 ici) e e vers 192.168.2.200. Le tableau qui suit r´sume le contenu des en-tˆtes observ´es : e e e En-tˆte 1 e En-tˆte 2 e Src IPA 192.168.249.1 Sur l’interface hme0 Dst IPB 192.168.2.200 Code ipencap(4) icmp En-tˆte e Src 192.168.249.1 Sur l’interface gif0 Dst 192.168.2.200 Code icmp Remarques : Attention, les routeurs filtrants doivent ˆtre sp´cialement configur´s pour e e e 13 laisser passer ce type de trafic . Les “ core gateway ” le laissent passer. Il est int´ressant de noter que le d´ploiement d’IPv6 est d’abord bas´ sur e e e l’encapsulation de trames de la version 6 dans des trames de la version 4, en attendant que tous les routeurs soient capables de router IPv6 nativement. Enfin pour conclure, est-il n´cessaire de pr´ciser que mˆme encap- e e e sul´s dans IP, nos datagrammes n’en sont pas moins lisibles par des e yeux indiscrˆts ? Pour s’en pr´munir il nous faut examiner une technologie e e compl´tementaire. . . Dans le paragraphe suivant ! e 11 Avec tcpdump -i hme0 puis tcpdump -i gif0 par exemple 12 Cf page 66 13 Pour un routeur de type cisco qui prot´gerait la machine B, il faudrait ajouter des e r`gles du genre “permit ipinip host IPB IPA” et “permit ipinip host IPA IPB” e
  • IPsec et VPN 1432.2 IPsec et VPN IPsec est un protocole de s´curit´ inclus dans la couche IP elle-mˆme. Il e e eest d´fini dans la RFC 2401. Ce paragraphe aborde bri`vement la question e edu point de vue du protocole et de sa place dans la pile Arpa, tout en lais-sant volontairement dans un certain flou les aspects li´s ` la cryptographie, e a 14clairement absents des objectifs de ce cours .2.2.1 IPsec dans quel but ? IPsec est un point de passage oblig´ pour tout administrateur de r´seau e equi souhaite mettre en place une politique de s´curit´. D’ailleurs, pour faire e ele lien avec le paragraphe qui pr´c`de, pr´cisons qu’IPsec encapsul´ dans IP e e e e(formellement, un tunnel) porte un nom, le VPN (“ Virtual Private Net-work ”) ! Nous avons examin´ comment un tunnel accroˆ l’´tendue d’un e ıt er´seau au travers d’autres r´seaux. Ajouter Ipsec introduit, entre autres, une e edimension de s´curit´ tr`s utilis´e pour relier des machines - ou des r´seaux e e e e e- physiquement localis´s n’importe o` il y a un acc`s IP, en r´seaux virtuels e u e es´curis´s ! C’est pour cette raison qu’Ipsec est un artefact incontournable de e ela panoplie s´curitaire sur les r´seaux. e e Nous aurions pu conclure le chapitre sur IP page 47 par cette constatationque le protocole IP est lisible par tout le monde y compris par les indiscrˆts et eque quasiment n’importe quel “ bricoleur ” peut forger de faux datagrammes(“ fake datagrams ”) pour empoisonner un r´seau, voire d´tourner les services e ed’une machine. Ainsi, tout ce qui renforce la s´curit´ IP est une bonne chose, e esurtout ` l’heure des r´seaux “ wifi ” dont les limites de port´e ne sont pas a e emaˆ ıtrisables.IPsec renforce la s´curit´ d’IP sur plusieurs points : e eConfidentialit´ Les donn´es d’IP (protocole de transport et donn´es ap- e e e plicatives) sont crypt´es, donc normalement non inspectables avec tout e outil d’analyse de r´seau accessible sur le r´seau lui-mˆme. e e eAuthentification La source du datagramme ne peut ˆtre qu’un seul e ´metteur, et non un interm´diaire non pr´vu. e e eInt´grit´ La totalit´ des donn´es est prot´g´e par une somme de contrˆle e e e e e e o (checksum), travail normalement d´volu ` la couche de transport mais e a qui au niveau d’IP permet d’´carter tout datagramme qui aurait ´t´ e ee modifi´ pendant son transport. eDispositif “ anti-rejeux ” pour ´viter les attaques du type “ man-in-the- e middle ” consistants ` capturer un ou plusieurs datagrammes (crypt´s) a e dans le but de les envoyer ` nouveau pour b´n´ficier du mˆme effet a e e e produit que l’envoi initial. 14 Les RFCs donn´es page 160 sont le bon point de d´part pour se documenter sur les e easpects cryptographiques d’IPsec
  • 144 ´ e El´ments de r´seaux e 2.2.2 IPsec en r´sum´ e e Ipsec (RFC 2401) est un assemblage de quatre protocoles : ESP (“ Encapsulating Security Payload ”) est d´fini par la RFC 2406. Il e assure la confidentialit´ par l’usage d’algorithmes de cryptage comme e “ DES ” (RFC 2405) , “ 3DES ” (RFC 2451), “ CAST-128 ” (RFC 2144) ou encore “ blowfish ” (RFC 2451), la liste n’est pas exhaustive. . . Il faut juste noter qu’il s’agit d’algorithmes bas´s sur l’existence un secret e partag´ (manuellement dans un fichier ou cr´e dynamiquement avec e e IKE, voir plus bas) entre les parties qui ´changent des messages, et e non sur l’´change d’une clef publique. Cette remarque a un impact sur e la mani`re avec laquelle on doit les configurer ! e AH (“ Authentication Header ”) est d´fini par la RFC 2402. Il assure e l’authentification, c’est ` dire qu’il cherche ` certifier que les deux a a couches IP qui dialoguent sont bien celles qu’elles pr´tendent ˆtre, puis e e l’int´grit´ des donn´es par le calcul d’un checksum. Il faut noter que e e e ce dernier travail empi`te largement sur les attributions de la couche e de transport mais se justifie compte-tenu des exigences inh´rentes au e fonctionnement d’IPsec. IPcomp (“ IP payload compression ”) sert ` compresser les donn´es avant de a e les crypter. Son action est rendue n´cessaire pour tenter de compenser e la perte de la place occup´e par les en-tˆtes ajout´s. Bien entendu e e e IPcomp peut ˆtre utilis´ seul. e e IKE (“ Internet Key Exchange ”) est d´fini par la RFC 2409. Ce protocole e n’est pas formellement indispensable au bon fonctionnement d’IPsec mais lui apporte un m´canisme d’´change de clefs, au d´marrage des e e e ´changes et au cours du temps. Ainsi la clef de chiffrement n’est plus e d´finie de mani`re statique dans un fichier mais change continuellement e e au cours du temps, ce qui est meilleur du point de vue de la s´curit´. e e Du point de vue de l’administration syst`me et r´seau, la mise en place e e 15 de ce protocole passe par l’usage d’un daemon , par exemple racoon, et par une ouverture de port UDP (isakmp/500) suppl´mentaire dans le e filtrage du r´seau. Une n´gociation d´crite dans la RFC 2409 se d´roule e e e e entre les hˆtes qui doivent dialoguer, ce qui peut entrainer une certaine o latence au d´but des ´changes. e e Les 32 bits de l’adresse IP de destination16 permettent th´oriquement e d’exprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de figures sont tous th´oriquement possibles, les impl´mentations d’IPsec ne e e supportent que l’unicast. La cons´quence est importante sur le d´ploiement e e d’IPsec, il est effectu´ “ point ` point ” plutˆt que g´n´ralis´ pour tout un e a o e e e r´seau. e 15 Voir page 315 pour le fonctionnement des daemons 16 R´vision possible page 35 e
  • IPsec et VPN 145 Ce travail est inclus dans ce quiest nomm´ “ politique de s´curit´ ” e e e figuredans la RFC 2401. Romanchapter.04 — Pour AH comme pour ESP, En-tˆtes d’IPsec el’ajout de donn´es vient se placer e Standard IP TCP DATAentre l’en-tˆte IP et les donn´es. e e code=6(tcp)Les deux protocoles peuvent ˆtre uti- e Avec AH IP AH TCP DATAlis´s ensembles ou s´parement, c’est e e code=51(ah) Donnéesun choix qui rel`ve de la politique e authentifiéesde s´curit´. Pour en tenir compte, e ela n´gociation qui a lieu lors de e Avec ESP IP ESP TCP DATA ESP Authl’´tablissement d’IPsec repose sur ce e code=50(esp) Donnéesque la RFC appelle des SA (“ Secu- encryptéesrity Association ”). authentifiées Une SA est formellement un tri- AH + ESP IP AH ESP TCP DATA ESP Authplet unique constitu´ d’un index e code=6(tcp)unique , le SPI code=50(esp) code=51(ah) (“ Security Parameter Index ”) sorte de num´ro d’identification IP esuppl´mentaire17 inclus dans l’en-tˆte AH ou ESP, de l’adresse IP du des- e etinataire et du protocole ESP ou d’AH. Si les deux protocoles doivent ˆtre eutilis´s, il faut n´gocier deux SAs. e e2.2.3 Comment utiliser IPsec ? Aux deux protocoles AH et ESP, s’ajoutent deux mani`res d’utiliser IP- esec, soit directement d’une machine ` une autre, on parle alors de “ mode atransport ” soit encore en l’encapsulant dans un tunnel comme vu au para-graphe 2 page 139 et on parle de “ mode tunnel ”, plus connu sous le vocable“ VPN ”. La RFC 2401 indique que toute impl´mentation se r´clamant d’IPsec doit e esupporter les 4 associations qui suivent. La s´curit´ entre deux hˆtes qui e e o figure VIII.05 — Association 1supporte IPsec, au travers l’Internet,en mode transport ou en mode tun- Internetnel. Les datagrammes peuvent avoir * H1 * H2les structures suivantes : Mode transport [IP1][AH][Transport][Data] [IP1][ESP][Transport][Data] intranet intranet [IP1][AH][ESP][Transport][Data] Mode tunnel H=hote [IP2][AH][IP1][Transport][Data] *=Supporte IPsec [IP2][ESP][IP1][Transport][Data] AH et/ou ESP 17 Voir page 50
  • 146 ´ e El´ments de r´seaux e Remarque : En mode tunnel pour ce premier cas il n’y a pas d’obligation du support d’AH et ESP simultan´ment. Quand ils sont appliqu´s tous les e e deux, il faut d’abord appliquer ESP, puis AH aux datagrammes. figure VIII.06 — Association 2 Le mode tunnel est le seul requis ici. Nous avons donc une struc- Internet ture de datagramme qui a ces * G1 * G2 formes possibles : Mode tunnel [IP2][AH][IP1][Transport][Data] [IP2][ESP][IP1][Transport][Data] H1 H2 intranet intranet G=passerelle H=hote AH et/ou ESP *=Supporte IPsec C’est la combinaison des deux figure VIII.07 — Association 3 premiers cas, on ajoute la s´curit´ e e * * entre les hˆtes terminaux ` celle d´j` o a ea G1 G2 apport´e par les routeurs. e La propagation du trafic de type ISAKMP (protocole IKE) au travers les routeurs est un plus. * H1 * H2 intranet intranet Internet G=passerelle H=hote AH et/ou ESP *=Supporte IPsec figure VIII.08 — Ce dernier cas est celui d’un poste isol´e Association 4 qui se raccorde par exemple ` l’intranet a de son entreprise via un modem ou un Hote isolé * dialup/ppp * acc`s IP non sˆr, et qui utilise un proto- e u H1 G1 cole non crypt´ comme AppleTalk, ou e PoP, par exemple. Le mode tunnel est seul requis entre l’hˆte H1 et la passerelle G1. Ensuite, o Internet H2 entre H1 et H2 on revient au premier cas. AH et/ou ESP intranet G=passerelle H=hote *=Supporte IPsec
  • IPsec et VPN 1472.2.4 Impl´mentation d’IPsec e L’impl´mentation d’IPsec sur les machines FreeBSD et NetBSd est issue edu projet KAME18 et est ainsi fortement li´ au d´veloppement de la pile e eIPv6. Les protocoles AH, ESP et IPcomp sont inclus dans le noyau directement.La gestion des clefs s’effectue via une commande externe, setkey qui piloteune table de gestion des clefs situ´e elle aussi dans le noyau, grˆce ` des e a asocket de type PF KEY Les clefs sont soit plac´es de mani`re semi-d´finitive dans le fichier de e e econfiguration d’ipsec lui-mˆme (par exemple /etc/ipsec.conf soit confi´e e eaux bons soins d’un programme externe qui se charge de les cr´e et de les epropager ` l’aide du protocole IKE. Quelques daemons savent faire cela, no- atamment racoon du projet KAME. Si nous reconsid´rons la figure VIII.03 les machines A et B jouent le rˆle e odes passerelles G1 et G2 de la figure VIII.06 (association 2). Les fichiers deconfiguration IPsec (AH et ESP) pourraient ˆtre : eSur la machine Aspdadd IP(A) IP(B) any -P out ipsec esp/tunnel/192.168.249.1-192.168.249.2/require ah/tunnel/192.168.249.1-192.168.249.2/require;spdadd IP(B) IP(A) any -P in ipsec esp/tunnel/192.168.249.2-192.168.249.1/require ah/tunnel/192.168.249.2-192.168.249.1/require; spdadd est une instruction de la commande setkey. Il faut d´finir sa epolitique de s´curit´, c’est ` dire ce que l’on souhaite en entr´e (in), en e e a esortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnelici) avec l’entr´e et la sortie du tunnel, enfin un niveau d’usage (require ici eindique que tous ´changes doivent utiliser IPsec). eSur la machine Bspdadd IP(B) IP(A) any -P out ipsec esp/tunnel/192.168.249.2-192.168.249.1/require ah/tunnel/192.168.249.2-192.168.249.1/require;spdadd IP(A) IP(B) any -P in ipsec esp/tunnel/192.168.249.1-192.168.249.2/require ah/tunnel/192.168.249.1-192.168.249.2/require; La clef de cryptage ne figure pas dans ce fichier car l’exemple utilise IKEpour cela, ` l’aide de l’outil racoon. a Enfin, un excellent document de configuration se trouve sur le site duprojet NetBSD : http://www.netbsd.org/Documentation/network/ipsec/ 18 http://www.kame.net/
  • 148 ´ e El´ments de r´seaux e 3 Proxy P figure VIII.09 — Proxy Le propos d’un proxy est de concentrer le trafic r´seau via une seule e machine pour toute une vari´t´ de protocoles (telnet, http, smtp, . . .). Il ee existe des proxy sp´cialis´s sur tel ou tel protocole, qui effectuent donc des e e tˆches potentiellement tr`s complexes (par exemple squid pour http) ou a e tr`s g´n´raux et donc moins performants sur chaque protocole (cf nat au e e e paragraphe suivant). Tout le trafic r´seau qui passe par un proxy s’y arrˆte pour en repartir. Les e e conditions de ce “ rebond ” peuvent ˆtre param`tr´es par des r`gles d’acc`s, e e e e e ce qui en fait un ´l´ment utile en s´curit´ des r´seaux (voir la RFC 1919). ee e e e Section en chantier, pr´cisions en cours. . . e 4 Translation d’adresses La p´nurie d’adresses IP est ` l’origine du besoin de translation des e a adresses. Son principe se trouve d´crit dans la RFC 1631. e Un tel dispositif se situe g´n´ralement ` la fronti`re entre un r´seau de e e a e e type priv´ et un autre de type publique. Le cas le plus g´n´ral est lorsque le e e e r´seau publique est l’internet lui-mˆme, et le r´seau priv´ celui d’une entit´ e e e e e quelconque abonn´e aux services d’acc`s r´seau d’un FAI, mais ce n’est pas e e e une obligation conceptuelle. Réseau publique C R S Réseau privé figure VIII.10 — R translate dynamiquement des couples (adresse IP, num´ro de port) e Sur la figure 10 le r´seau priv´ comporte plus d’hˆtes que d’adresses IP e e o fournies dans le r´seau publique. Pour pouvoir se d´velopper en s’affranchis- e e sant de cette contrainte, l’usage de la translation d’adresses et de ports — NAT et PAT, ou encore NAPT comme “ Network Address Port Translation ” — est incontournable parce que le r´seau priv´ est bˆti avec des adresses non e e a
  • Translation d’adresse 149routables (cf page 34) de la RFC 1918, potentiellement illimit´es ` l’´chelle e a ed’une entit´ priv´e, mˆme grande. . . e e e R dispose de quelques adresses (un pool d’une adresse au minimum) rou-tables sur le r´seau publique, qu’il peut assigner aux hˆtes du r´seau priv´ e o e e(C) qui initient une connexion vers le r´seau publique (S). Cette assignation epeut ˆtre dynamique ou statique. e Un datagramme qui part de C vers S a une adresse source non exploitablesur le r´seau publique. R maintient une table, si C n’est pas d´j` associ´ ` une e ea eaadresse routable du pool allou´ ` R, celui-ci lui en attribue une et modifie ` la ea avol´e l’adresse source du datagramme, de telle sorte que le retour de S puisse eˆtre rout´ convenablement jusqu’` R. Puis R modifie l’adresse de destinatione e adu datagramme pour lui donner l’adresse de C, sur le r´seau priv´. e e Si on fait l’hypoth`se que la plupart des hˆtes du r´seau priv´ n’´tablissent e o e e epas simultan´ment des connexions vers le r´seau publique, le pool d’adresses e epubliques peut rester beaucoup plus petit que le nombre d’hˆtes du r´seau o epriv´. Mais cette hypoth`se est fragile consid´rant les besoins toujours plus e e egrands d’acc´der ` l’information r´partie. e a e Ce premier m´canisme se compl`te alors d’un second qui est le NAPT. En e eplus de traduire l’adresse IP ` la vol´e, R attribue ´galement un num´ro de a e e eport diff´rent. Ce dispositif autorise l’usage simultann´ d’une mˆme adresse e e eIP publique par des milliers d’hˆtes du r´seau priv´. o e e Le fonctionnement de la translation d’adresse et de port engendre unepropri´t´ int´ressante pour R : il ne laisse passer aucun paquet du r´seau ee e epublique vers le r´seau priv´ qui ne soit pas la r´ponse ` une sollicitation e e e avenue du r´seau priv´, c’est donc en standard un fonctionnement ` sens e e aunique. Cette propri´t´ peut ˆtre remise en question, voir le paragraphe 4.2. ee e Enfin, du fait du changement d’adresse source ` l’aller puis d’adresse ade destination au retour du datagramme, le NAPT rend impossible l’usaged’IPSEC (page 143) entre une machine quelconque du r´seau publique et l’in- eterface de R dans ce r´seau et sur laquelle s’effectue le travail de translation e(il a modification de l’en-tˆte, ce contre quoi justement IPSEC est sens´ nous e eprot´ger. . .). Le seul moyen dans ce cas de figure est de passer par l’usage ed’un tunnel, comme vu paragraphe 2 (page 139). Tous les routeurs modernes ont les fonctions de translation d’adresses etde ports incluses dans leurs fonctionnalit´s standards. e
  • 150 ´ e El´ments de r´seaux e 4.1 NAPT sur un routeur de type PC avec natd Natd est l’outil logiciel libre bien connu des administrateurs r´seaux. Il e 19 fonctionne selon le mod`le de la figure 11 . e Adresses IP Adresses IP NAPT B privées 193.104.1.1 publiques if_int if_ext 10.33.93.1 193.104.112.163 Internet A 10.33.96.5 figure VIII.11 — Machine NAPT en routeur Dans la figure 11, la machine “ NAPT ” est par hypoth`se configur´e en e e routeur. Elle repr´sente la route par d´faut pour la machine A. e e Natd convertit les adresses IP ` la vol´e. Un datagramme voit ses adresses a e sources (et ´ventuellement de destination, voir plus loin) changer dynamique- e ment. Examinons en d´tail les composantes d’une connexion ´tablie depuis e e A vers B, donc lors d’un trafic “ sortant ” vis ` vis de R. a Pour la machine A ◦ La machine A s’adresse directement ` la machine 193.104.112.163 en a utilisant son routeur par d´faut. e ◦ L’utilisateur de la machine A “ voit ” la connexion soit la forme : {tcp, IP Hˆte A, port A, IP Hˆte B, port B} o o Pour la machine B ◦ La machine B voit une connexion arriver en provenance de “ NAPT ”. ◦ La machine B n’a pas connaissance de la machine A, elle dialogue avec la machine NAPT selon : {tcp, IP Hˆte B, port B, IP Hˆte NAT, port A’} o o Pour la machine NAPT ◦ La machine NAPT a connaissance des 2 r´seaux, elle translate dyna- e miquement les adresses et les ports dans les deux sens. ◦ La machine NAPT fait le travail d’un proxy transparent pour la couche 3 ISO puisque chaque connexion s’y arrˆte puis en repart sans configu- e ration particuli`re de la part de l’administrateur de A ou de B. e ◦ La translation (ou “ IP masquerading ”) s’effectue dynamiquement selon l’adresse demand´e. e 19 Les impl´mentation commerciales que l’on trouve dans les routeurs, si elles ne se e configurent pas de la mˆme mani`re, ont des propri´t´s tr`s voisines en fonctionnement e e ee e
  • Translation d’adresse 151 ◦ La translation d’adresse s’effectue pour les datagrammes qui traversent l’interface if ext. Le dialogue entre cette machine et les autres ma- chines du r´seau “ priv´ ”, via l’interface if int ne fait pas l’objet e e d’une translation d’adresse. ◦ La situation de la machine A est plutˆt celle d’un poste client car o e e ˆ non vu de l’ext´rieur de son r´seau. Etre serveur est toutefois possible comme il l’est expliqu´ avec l’usage de natd au paragraphe ??. e4.1.1 Interactions entre natd et le noyau L’usage de natd sur un PC est un travail consommateur de ressourcescpu parceque les datagrammes font l’objet de deux recopies et de deux chan-gements de contexte suppl´mentaires : ils sont trait´s par un processus qui e es’ex´cute en mode utilisateur. Sur la figure 12 le processus natd ouvre une esocket en mode raw pour communiquer directement avec la couche IP : divertInOut = socket (PF INET, SOCK RAW, IPPROTO DIVERT) ; Le noyau IP, muni du m´canisme ad´quat 20 redirige tout le trafic en- e etrant et sortant d’un interface r´seau, vers un num´ro de port convenu ` la e e aconfiguration, par exemple le port 6668, ` ajouter dans /etc/services : a natd 6668/divert # Network Address Translation socket Natd lit tous les datagrammes et ne retient pour traitements que ceux quisont ` destination du port d´di´. a e e Processus natd Noyau 6668 Règles de translation (/etc/natd.conf) Interface placé sous la gestion de natd if_int if_ext figure 12 — Interactions entre natd et le noyau de FreeBSD Compte tenu du fichier de configuration, les adresses IP des datagrammesainsi que les num´ros de ports sont re´crits et reinject´s dans le noyau IP qui e e eles traite comme d’autres datagrammes (routage, filtrage. . .). 20 Par exemple pour FreeBSD il faut ajoute l’option IPDIVERT dans la configuration dunoyau
  • 152 ´ e El´ments de r´seaux e 4.2 Translation d’adresses vers le r´seau priv´ e e Les figures qui pr´c`dent ne concernent que les connexions sortantes du e e r´seau priv´, mais on peut envisager l’inverse. Bien entendu vu du r´seau e e e publique on ne voit que les adresses du pool attribu´ au routeur R. Le e m´canisme de translation de port permet ´ventuellement de ventiler les e e connexions entrantes vers une ou plusieurs machines priv´es. Le crit`re dis- e e criminant est le num´ro de port demand´. e e On distingue deux attitudes, soit tout le flux entrant est redirig´ sur une e seule machine, soit il est est effectu´ en fonction du port, donc du service e demand´. e ` La litt´rature appelle ce cas le “ static nat ”. A l’insu des utilisateurs de e la machine “ NAPT ” du r´seau publique, tout le trafic IP (c’est ainsi qu’il e faut comprendre l’adresse IP 0.0.0.0) est renvoy´ sur la machine S, et celle-ci e n’est pas “ visible ” du r´seau public. e Hote accessible Partie privée du Hote distant réseau Partie publique du NAPT réseau R IP(S) if_ext S Internet figure VIII.13 — “ Static Nat ”
  • Translation d’adresse 153La configuration du natd pourrait ˆtre : e natd -interface if ext -redirect address IP(S) 0.0.0.0 La figure 14 nous montre un exemple de trafic ´clat´ en fonction du service e edemand´, ce qui permet une gestion beaucoup fine des ressources du r´seau. e e Une demande de connexion de l’hˆte distant R sur la machine NAT et oau port 80 va ˆtre r´achemin´e vers la machine interne HTTP et sur le port e e eque l’on souhaite, par exemple 8080. Mˆme remarque pour les deux autres services pr´sent´s. e e e La machine HTTP voit la connexion en provenance de la machine R soussa forme exacte : {tcp, IP Hˆte R, Port R, IP Hˆte HTTP, 8080} o o La machine R ne voit que la partie “ publique ” de la connexion : {tcp, IP Hˆte R, Port R, IP Hˆte NAT, 80} o oLa configuration NAPT pourrait ressembler ` : a # # Configuration multiservices # redirect_port tcp http:8080 80 redirect_port tcp smtp:25 25 redirect_port tcp dns:domain domain redirect_port udp dns:domain domain Hote accessible Hote distant Partie privée du réseau Partie publique du http NAPT réseau R smtp dns Internet figure 14 — Configuration multiservices4.3 NAPT sur un routeur CISCO Voir en travaux pratiques. . .
  • 154 ´ e El´ments de r´seaux e 5 Filtrage IP Le propos du filtrage IP est d’appliquer des r`gles de filtrage ` un flux de e a datagrammes IP afin de prendre une d´cision qui est le plus souvent binaire : e laisser passer ou ne pas laisser passer avec en option de conserver une trace de passage (des logs). Par son usage on cherche ` prot´ger un site ou une machine d’un flux a e de datagrammes pour lesquels on suspecte que tous ne sont pas envoy´s par e des utilisateurs bienveillants. Le filtre s’efforce d’´liminer le trafic ind´sirable e e ` partir de consid´rations ` priori, mais il ne repr´sente pas la panac´e en a e a e e mati`re de s´curit´ sur les r´seaux, autrement dit il ne faut pas penser qu’un e e e e filtre IP suffit ` r`gler tous les probl`mes de s´curit´ d’un site ou d’un hˆte. a e e e e o En effet, ` partir du moment o` le filtre laisse passer certains data- a u grammes, mˆme ` priori innocents, une porte est ouverte au d´tournement e a e de l’usage initial du service offert. Dans ces conditions il faut se rendre ` a 21 l’´vidence : il n’y a pas de s´curit´ absolue sur le r´seau ! e e e e Dans la litt´rature, un routeur filtrant est nomm´ “ FireWall ”, qu’il faut e e traduire en “ pare-feux ”. Le filtrage IP est une caract´ristique essentielle de tout routeur digne de e ce nom ! Il est aussi possible de faire du filtrage IP avec les Unix libres, c’est cette approche qui est choisie dans les paragraphes qui suivent parcequ’accessible ` toutes les bourses. . . a Si les d´tails de mise en œuvre diff`rent d’une impl´mentation ` une autre, e e e a le fond du probl`me reste le mˆme. L’impl´mentation choisie ici est ipfw, le e e e filtre natif de FreeBSD22 . Il existe d’autres filtre, notamment ipf, encore une fois le principe reste toujours le mˆme. e 5.1 Filtrage IP sur un routeur CISCO Voir en travaux pratiques. . . 5.2 Le cas d’ipfw de FreeBSD Le filtre IP en question est impl´ment´ dans le noyau, il est activ´ e e e d`s lors que l’options IPFIREWALL est ajout´e dans le noyau. On peut e e ´galement y adjoindre l’option IPFIREWALL VERBOSE pour le rendre ba- e vard23 , ce qu’appr´cient par dessus tout les administrateurs r´seaux, soucieux e e d’avoir une connaissance pr´cise de la nature du trafic sur leurs r´seaux. . . e e Le filtre est un module du noyau, charg´ au d´marrage, et qui se param`tre e e e ` l’aide de la commande ipfw. Celle-ci est utilis´e dans les scripts de d´mar- a e e rage pour dicter au noyau les r`gles de filtrage, lues dans un fichier nomm´ e e 21 Les seuls r´seaux sˆrs sont isol´s du monde ext´rieur dans une cage de Faraday. . . e u e e 22 http://www.freebsd.org 23 Via syslogd
  • Filtrage IP 155par defaut /etc/rc.firewall. les scripts de d´marrage pour dicter au noyau eles r`gles de filtrage, e ´ Etablir des r`gles de filtrage IP sous-entend avoir une connaissance ex- ehaustive de tous les ´l´ments qui s’y rattachent : ee ◦ Nom des interfaces r´seaux impliqu´es e e ◦ Protocoles r´seaux employ´s (tcp, udp, icmp,. . .) e e ◦ Protocoles applicatifs autoris´s (smtp, domain, http. . .) e ◦ Adresses IP, num´ro de ports, masque de sous-r´seaux e e ◦ Sens du trafic par rapport aux interfaces ci-dessus Il est assez ais´ de mettre en place un filtrage simple, par contre cette eop´ration peut devenir complexe d`s lors qu’on utilise des protocoles appli- e ecatifs compliqu´s, mettant en jeux une strat´gie d’utilisation des ports et des e eadresses non triviale. Consid´rons un site simple, comme celui de la figure VIII.15. La machine eC acc`de depuis l’ext´rieur ` la machine S, prot´g´e par le filtrage IP activ´ e e a e e esur la machine R, qui agit donc en tant que routeur filtrant. Réseau protégé Réseau publique R Interface C ed1 ipfw 193.104.1.225 193.104.1.1 193.104.1.228 http S Internet dns Interface smtp ed0 ntp figure VIII.15 — Configuration simple de filtrage Adaptons-y les r`gles du mod`le de base, extraites du fichier e e/etc/rc.firewall de la configuration standard d’une machine FreeBSDr´cente (c’est un script shell). L’examen de ces r`gles nous permet de e ed´couvrir la nature du trafic autoris´ ou non. e e
  • 156 ´ e El´ments de r´seaux e 1 # −−− Interface externe 2 oif="ed0" 3 onet="193.104.1.0" 4 omask="255.255.255.224" 5 oip="193.104.1.1" 6 7 # −−− Interface interne 8 iif="ed1" 9 inet="193.104.1.224" 10 imask="255.255.255.224" 11 iip="193.104.1.225" 12 13 # −−− Ne pas laisser passer le ‘‘spoofing’’ 14 ipfw add deny all from ${inet}:${imask} to any in via ${oif} 15 ipfw add deny all from ${onet}:${omask} to any in via ${iif} 16 17 # −−− Ne pas router les adresses de la RFC1918 18 ipfw add deny all from 192.168.0.0:255.255.0.0 to any via ${oif} 19 ipfw add deny all from any to 192.168.0.0:255.255.0.0 via ${oif} 20 ipfw add deny all from 172.16.0.0:255.240.0.0 to any via ${oif} 21 ipfw add deny all from any to 172.16.0.0:255.240.0.0 via ${oif} 22 ipfw add deny all from 10.0.0.0:255.0.0.0 to any via ${oif} 23 ipfw add deny all from any to 10.0.0.0:255.0.0.0 via ${oif} 24 25 # −−− Laisser passer les connexions TCP existantes 26 ipfw add pass tcp from any to any established 27 28 # −−− Permettre l’arrivée du courrier SMTP 29 ipfw add pass tcp from any to 193.104.1.228 25 setup 30 31 # −−− Permettre l’accès au serveur HTTP 32 ipfw add pass tcp from any to 193.104.1.228 80 setup 33 34 # −−− Rejetter et faire des logs de toutes les autres demandes de connexion 35 ipfw add deny log tcp from any to any in via ${oif} setup 36 37 # −−− Permettre l’établissement des autres connexions (via $iif). 38 ipfw add pass tcp from ${inet}:${imask} to any setup in via ${iif} 39 40 # −−− Permettre le trafic UDP/DOMAIN vers/depuis les serveurs DNS externes 41 ipfw add pass udp from any 53 to any 53 42 43 # −−− Permettre le trafic NTP vers/depuis les serveurs de dates 44 ipfw add pass udp from any 123 to any 123 45 46 # −−− Permettre le passage de tous les paquets ICMP 47 ipfw allow icmp from any to any 48 49 # −−− Tout ce qui n’est pas explicitement autorisé est 50 # implicitement interdit (cf comportement par défaut d’ipfw). 51 ipfw deny ip from any to any Quelques consid´rations : e ◦ Les r`gles sont parcourues de la premi`re ` la derni`re, si aucune e e a e convient, l’action par d´faut consiste ` bloquer le trafic (peut ˆtre e a e chang´e). e ◦ D`s qu’une r`gle convient, elle est appliqu´e et le filtrage s’arrˆte. e e e e ◦ Le filtrage IP consomme des ressources cpu, donc pour am´liorer les e performances il vaut mieux placer en tˆte de liste les r`gles employ´es e e e le plus couramment. Il faut remarquer que la machine 193.104.1.228 est visible depuis l’ext´rieure et utilise une adresse officiellement rout´e. e e Une tentative d’acc`s sur un service non autoris´ se traduit par un mes- e e
  • 6 Exemple complet 157sage d’erreur (syslogd). Par exemple supposons que l’utilisateur de la station“ C ” ex´cute la commande suivante : e telnet 193.104.1.228Il va obtenir le message : telnet : Unable to connect to remote host : Connection timed out Tandis que l’administrateur du r´seau 193.104.1.0 va constater la tenta- etive d’intrusion par le message : ipfw : 3310 Deny TCP Adr.IP H^te C :2735 193.104.1.228 :23 in via o ed0 Par contre, si l’intrusion consiste ` d´tourner l’usage du service SMTP, a el’administrateur du r´seau 193.104.1.0 ne verra rien par ce biais puisque el’acc`s SMTP est autoris´ sur la machine 193.104.1.22824 e e6 Exemple complet Dans cette partie nous examinons le cas de la configuration de la figureVIII.16, synth`se des figures eRomanchapter.13,Romanchapter.14 etRomanchapter.15. C’est une configuration tr`s employ´e du fait de la distri- e ebution parcimonieuse d’adresses IP par les fournisseurs d’acc`s. e Réseau privé Réseau publique non visible de l’extérieur NAPT R Interface C ed1 ipfw 193.104.1.225 193.104.1.1 193.104.1.228 http S dns Internet Interface smtp ed0 ntp figure VIII.16 — Translation d’adresse et filtrage IP Le propos est de mettre en place un routeur filtrant effectuant en plus latranslation d’adresses IP. La juxtaposition des deux services induit peu dechangements dans la configuration des r`gles de filtrage. e 24 Toute ressemblance avec la configuration r´elle de ce r´seau ne peut ˆtre que fortuite e e e
  • 158 ´ e El´ments de r´seaux e Commen¸ons par les r`gles de filtrage : c e 1 # −−− Interface externe 2 oif="ed0" 3 onet="193.104.1.0" 4 omask="255.255.255.224" 5 oip="193.104.1.1" 6 7 # −−− Interface interne 8 iif="ed1" 9 inet="193.104.1.224 10 imask="255.255.255.224" 11 iip="193.104.1.225" 12 # 13 # −−− Usage de ’natd’ pour transformer tout ce qui passe sur l’interface 14 # "ed0" donc le subnet public. 15 ipfw add divert 8668 all from any to any via ${oif} 16 17 # −−− Ne pas laisser passer le ‘‘spoofing’’ 18 ipfw add deny all from ${inet}:${imask} to any in via ${oif} 19 ipfw add deny all from ${onet}:${omask} to any in via ${iif} 20 21 # −−− Ne pas router les adresses de la RFC1918 22 ipfw add deny all from 192.168.0.0:255.255.0.0 to any via ${oif} 23 ipfw add deny all from any to 192.168.0.0:255.255.0.0 via ${oif} 24 ipfw add deny all from 172.16.0.0:255.240.0.0 to any via ${oif} 25 ipfw add deny all from any to 172.16.0.0:255.240.0.0 via ${oif} 26 ipfw add deny all from 10.0.0.0:255.0.0.0 to any via ${oif} 27 ipfw add deny all from any to 10.0.0.0:255.0.0.0 via ${oif} 28 29 # −−− Laisser passer les connexions TCP existantes 30 ipfw add pass tcp from any to any established 31 32 # −−− Permettre l’arrivée du courrier SMTP 33 ipfw add pass tcp from any to 193.104.1.228 25 setup 34 35 # −−− Permettre le trafic TCP/DOMAIN 36 ipfw add pass tcp from any to 193.104.1.228 53 setup 37 38 # −−− Permettre l’accès au serveur HTTP 39 ipfw add pass tcp from any to 193.104.1.228 80 setup 40 41 # −−− Rejetter et faire des logs de tout autre demande de connexion 42 ipfw add deny log tcp from any to any in via ${oif} setup 43 44 # −−− Permettre l’établissement des autres connexions (via $iif). 45 ipfw add pass tcp from ${inet}:${imask} to any setup in via ${iif} 46 47 # −−− Permettre le trafic UDP/DOMAIN vers/depuis les ’forwarders’ 48 ipfw add pass udp from any 53 to 193.104.1.228 53 49 ipfw add pass udp from 193.104.1.228 53 to any 53 50 51 # −−− Permettre le trafic DTP/NTP 52 ipfw add pass udp from any 123 to 193.104.1.228 123 53 ipfw add pass udp from 193.14.1.228 123 to any 123 54 55 # −−− Permettre le passage des paquets ICMP (ping, traceroute...) 56 ipfw add pass icmp from any to any via ${oif} icmptype 0,3,8,11 57 ipfw add pass udp from any 32768−65535 to any 32768−65535 out xmit ${oif} 58 ipfw add log icmp from any to any in recv ${oif} 59 ipfw add pass icmp from any to any via ${iif} 60 61 # −−− Tout ce qui n’est pas explicitement autorisé est 62 # implicitement interdit (cf comportement par défaut d’ipfw). 63 ipfw deny ip from any to any 64
  • Exemple complet 159 Dans le principe l’hˆte 193.104.1.228 n’est plus visible de l’ext´rieur, o eles services sont en apparence h´berg´s par la machine R qui se charge de e ere-router les datagrammes en modifiant dynamiquement l’adresse de desti-nation. Dans l’ordre des op´rations, la translation d’adresses est effectu´e avant e ele filtrage IP. Ce sont donc des adresses IP modifi´es qui sont introduites edans les r`gles de filtrage ! e Terminons avec la configuration de natd. Voici le contenu du fichier/etc/natd.conf pour cette situation : redirect_port tcp 193.104.1.228:80 80 redirect_port tcp 193.104.1.228:25 25 redirect_port tcp 193.104.1.228:53 53 redirect_port udp 193.104.1.228:53 53 redirect_port udp 193.104.1.228:123 123 O` l’on s’apper¸oit que la configuration n’a pratiquement pas chang´ u c efondamentalement ormis par l’introduction de la r`gle : e ipfw add divert 6668 all from any to any via ${oif} Qui indique au filtre que tout ce qui provient de l’interface “ oif ” est ` alire sur le port 6668, donc a d´j` subit la translation d’adresse avant d’ˆtre ea esoumis au filtrage IP. Ainsi une demande de connexion sur le port 25 de lamachine 193.104.1.1 sera transform´e en une demande de connexion sur le eport 25 de la machine 193.104.1.228, qui est autoris´. e Pour l’utilisateur de la station “ C ” la machine 193.104.1.228 n’estplus visible, seule la machine d’adresse 193.104.1.1 semble cumuler tous lesservices !
  • 160 Protocole TCP 7 Bibliographie RFC 1631 “ The IP Network Address Translator (NAT). ” K. Egevang & P. Francis. May 1994. (Format : TXT=22714 bytes) (Status : INFOR- MATIONAL) RFC 1918 “ Address Allocation for Private Internets. ” Y. Rekhter, B. ˜ Moskowitz, D. Karrenberg, G. J.de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) RFC 1825 “ Security Architecture for the Internet Protocol. ” R. Atkinson. August 1995. (Format : TXT=56772 bytes) (Obsoleted by RFC2401) (Status : PROPOSED STANDARD) RFC 2364 “ PPP Over AAL5. ” G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format : TXT=23539 bytes) (Status : PROPO- SED STANDARD) RFC 2401 “ Security Architecture for the Internet Protocol. ” S. Kent, R. Atkinson. November 1998. (Format : TXT=168162 bytes) (Obso- letes RFC1825) (Updated by RFC3168) (Status : PROPOSED STAN- DARD) RFC 2402 “ IP Authentication Header. ” S. Kent, R. Atkinson. November 1998. (Format : TXT=52831 bytes) (Obsoletes RFC1826) (Status : PROPOSED STANDARD) RFC 2406 “ IP Encapsulating Security Payload (ESP). ” S. Kent, R. Atkinson. November 1998. (Format : TXT=54202 bytes) (Obsoletes RFC1827) (Status : PROPOSED STANDARD) RFC 2409 “ The Internet Key Exchange (IKE). ” D. Harkins, D. Carrel. November 1998. (Format : TXT=94949 bytes) (Status : PROPOSED STANDARD) RFC 2516 “ A Method for Transmitting PPP Over Ethernet (PPPoE). ” L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format : TXT=32537 bytes) (Status : INFORMA- TIONAL) RFC 3168 “ The Addition of Explicit Congestion Notification (ECN) to IP. ” K. Ramakrishnan, S. Floyd, D. Black. September 2001. (For- mat : TXT=170966 bytes) (Obsoletes RFC2481) (Updates RFC2474, RFC2401, RFC0793) (Status : PROPOSED STANDARD) RFC 1919 “ Classical versus Transparent IP Proxies ”. M. Chatel. March 1996. (Format : TXT=87374 bytes) (Status : INFORMATIONAL)
  • Bibliographie 161Sans oublier : ◦ W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley ◦ “ Firewalls and Internet Security ” - William R. Cheswick, Steven M. Bellovin - Addison-Wesley 1994. ◦ “ Building Internet Firewalls ” - D. Brent Chapman and Elizabeth D. Zwicky - O´Reilly - 1995. Steven M. Bellovin - Addison-Wesley 1994.
  • 162 Protocole TCP
  • Troisi`me partie eProtocoles applicatifs
  • Chapitre IX Serveur de noms - DNS1 G´n´ralit´s sur le serveur de noms e e e S’il est obligatoire d’attribuer au moins une adresse IP ` une pile ARPA apour pouvoir l’interconnecter en r´seau avec d’autres piles de mˆme nature, e een revanche, lui attribuer un nom symbolique n’est absolument pas n´cessaire eau bon fonctionnement de ses trois couches basses. Ce nommage symbolique est simplement beaucoup plus naturel pour noscerveaux humains que la manipulation des adresses IP, mˆme sous forme ed´cimale point´e (adresses IP page 33). Il n’intervient donc qu’au niveau e eapplicatif, ainsi la majeure partie des applications r´seaux font usage de enoms symboliques avec, de mani`re sous-jacente, une r´f´rence implicite ` e ee aleur(s) correspondant(s) num´rique(s). e Ce chapitre explore les grandes lignes du fonctionnement de ce que l’onnomme le “ serveur de noms ”, lien entre cette symbolique et l’adressage IPqui lui est associ´ . e Pour terminer cette introduction, il n’est pas innocent de pr´ciser que le eserveur de noms est en g´n´ral le premier service mis en route sur un r´seau, e e etout simplement parceque beaucoup de services le requi`rent pour accepter ede fonctionner (le courrier ´lectronique en est un exemple majeur). C’est la eraison pour laquelle l’usage d’adresses IP sous la forme d´cimale point´e reste e ede mise lors de la configuration des ´l´ments de commutation et de routage1 . ee1.1 Bref historique Au d´but de l’histoire de l’Internet, la correspondance entre le nom (les enoms s’il y a des synonymes ou “ alias ”) et l’adresse (il peut y en avoirplusieurs associ´es ` un seul nom) d’une machine est plac´e dans le fichier e a e/etc/hosts, pr´sent sur toutes les machines unix dot´es d’une pile Arpa. e e Ci-apr`s le fichier en question, pr´lev´ (et tronqu´ partiellement) sur une e e e e 2machine FreeBSD ` jour. On y remarque qu’il ne contient plus que l’adresse a 1´ Eviter un blocage dˆ ` l’interrogation des serveurs de noms ua 2 www.freebsd.org
  • 166 Serveur de noms - DNS de “ loopback ” en ipv6 et ipv4. # $FreeBSD$ # # Host Database # # This file should contain the addresses and aliases for local hosts that # share this file. Replace ’my.domain’ below with the domainname of your # machine. # # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain Au d´but des ann´es 1980 c’est le NIC3 qui g`re la mise ` jour continuelle e e e a de cette table (HOSTS.TXT), avec les inconv´nients suivants : e ◦ Absence de structure claire dans le nommage d’o` de nombreux conflits u entre les noms des stations. Par exemple entre les dieux de la mythologie grecque, les plan`tes du syst`me solaire, les h´ros historiques ou de e e e bandes dessin´es. . . e ◦ Centralisation des mises ` jour, ce qui entraine : a 1. Une lourdeur du processus de mise ` jour : il faut passer par un a interm´diaire pour attribuer un nom ` ses machines. e a 2. Un trafic r´seau (ftp) en forte croissance (N 2 si N est le nombre e de machines dans cette table) et qui devient rapidement ing´rable e au vu des bandes passantes de l’´poque (quelques kilo bits par e seconde), et surtout jamais ` jour compte tenu des changements a continuels. D’apr`s Douglas E. Comer, au milieu des ann´es 1980 (1986) la liste e e officielle des hˆtes de l’Internet contient 3100 noms et 6500 alias ! o La forte croissance du nombre des machines, a rendu obsol`te e cette approche. 1.2 Syst`me hi´rarchis´ de nommage e e e L’espace de noms, pr´alablement non structur´, est d´sormais r´organis´ e e e e e de mani`re hi´rarchique, sous forme d’un arbre (et non d’un graphe). e e Cette organisation entraine une hi´rarchisation des noms de machines et e des autorit´s qui ont le pouvoir de les nommer, de les maintenir. e Chaque nœud de l’arbre porte un nom, la racine n’en a pas. Les machines, feuilles de l’arbre, sont nomm´es ` l’aide du chemin parcouru de la feuille e a (machine) ` la racine (non nomm´e). a e 3 “ Network Information Center ” (http://www.internic.net/)
  • Syst`me hi´rarchis´ de nommage e e e 167 Le s´parateur entre chaque embranchement, ou nœud, est le point ed´cimal. Voici un exemple de nom de machine : e www.sio.ecp.fr Derri`re ce nom il faut imaginer un point (.) qui est omis la plupart du etemps car il est implicite4 . La lecture s’effectue naturellement de gauche ` adroite, par contre la hi´rarchie de noms s’observe de droite ` gauche. e a1.2.1 Domaine & zone Le r´seau peut ˆtre consid´r´ comme une hi´rarchie de domaines. L’espace e e ee edes noms y est organis´ en tenant compte des limites administratives ou eorganisationnelles. Chaque nœud, appel´ un domaine, est baptis´ par une e echaˆ de caract`res et le nom de ce domaine est la concat´nation de toutes ıne e eles ´tiquettes de nœuds lues depuis la racine, donc de droite ` gauche. Par e aexemple : fr Domaine fr ecp.fr Domaine ecp.fr sous domaine du fr sio.ecp.fr Domaine sio.ecp.fr sous domaine de ecp.fr Par construction, tout nœud est un domaine, mˆme s’il est terminal, c’est e` dire n’a pas de sous domaine. Un sous domaine est un domaine ` part enti`rea a eet, except´e la racine, tout domaine est un sous domaine d’un autre. e Bien que le serveur de noms, “ Domain Name Server ” fasse r´f´renceeeexplicitement au concept de domaine, pour bien comprendre la configurationd’un tel service il faut ´galement comprendre la notion de “ zone ”. e Une zone est un point de d´l´gation dans l’arbre DNS, autrement dit une eezone concerne un sous arbre du DNS dont l’administration lui est propre.Ce sous arbre peut comprendre plusieurs niveaux, c’est ` dire plusieurs sous adomaines. Une zone peut ˆtre confondue avec le domaine dans les cas les plus esimples. Dans les exemples ci-dessus, on peut parler de zone sio.ecp.fr puisquecelle-ci est g´r´e de mani`re autonome par rapport ` la zone ecp.fr. ee e a Le serveur de noms est concern´ par les “ zones ”. Ses fichiers de confi- eguration5 pr´cisent la port´e de la zone et non du domaine. e e Chaque zone doit avoir un serveur principal (“ master ”) qui d´tient eses informations d’un fichier configur´ manuellement ou semi manuellement e(DNS dynamique). Plusieurs serveurs secondaires (“ slave ”) recoivent unecopie de la zone via le r´seau et pour assurer la continuit´ du service (par la e eredondance des serveurs). Le fait d’administrer une zone est le r´sultat d’une d´l´guation de pouvoir e eede l’administrateur de la zone parente et se concr´tise par la responsabilit´ e ede configurer et d’entretenir le champ SOA (“ start of authority ”, page 183)de la-dite zone. 4 Sauf justement dans les fichiers de configuration du serveur de noms, voir plus loin 5 named.boot vs named.conf
  • 168 Serveur de noms - DNS 1.2.2 Hi´rarchie des domaines e Cette organisation du nommage pallie aux inconv´nients de la premi`re e e m´thode : e ◦ Le NIC g`re le plus haut niveau de la hi´rarchie, appel´ aussi celui des e e e “ top levels domains ” (TLD). ◦ Les instances r´gionales du NIC g`rent les domaines qui leur sont e e d´volus. Par exemple le “ NIC France ” 6 g`re le contenu de la zone .fr. e e Le nommage sur deux lettres des pays est issu de la norme ISO 31667 . ◦ Chaque administrateur de domaine (universit´s, entreprises, associa- e tions, entit´s administratives,. . .) est en charge de son domaine et des e sous domaines qu’il cr´e. Sa responsabilit´ est nomminative vis ` vis e e a du NIC. On dit aussi qu’il a l’autorit´ sur son domaine (“ authoritative e 8 for the domain ”) Racine non nommée Sens de lecture arpa com edu gov int mil net org ae fr zw Zimbabwe Emirats Domaines du niveau le plus élevé (TLD) Arabes in−addr Domaines du second niveau Unis ecp 138 Contour de zone cti sio 195 Domaines génériques Domaines nationaux 10 52 52.10.195.138.in−addr.arpa. 6 http://www.nic.fr/ 7 On peut les voir en d´tail ` cette adresse http://www.nw.com/zone/ e a iso-country-code 8 Une base de donn´es sur les administrateurs de DNS est entretenue par les NICs, c’est e la base “ whois ”, interrogeable par l’utilitaire du mˆme nom. Consulter le site http: e //www.ripe.net/ pour plus d’informations, ´galement “ man whois ” sur une machine e unix
  • 2 Fonctionnement du DNS 169 figure IX.01 — Organisation hi´rarchique des domaines e ◦ Les ´ventuels conflits de nommage sont ` la charge des administrateurs e a de domaine. Du fait de la hi´rarchisation, des machines de mˆme nom e e peuvent se trouver dans des domaines diff´rents sans que cela pose le e moindre probl`me. e Le nom “ www ” est de loin le plus employ´ 9 , pourtant il n’y a aucune e confusion possible entres ces machines, comme par exemple entres les machines www.ecp.fr et www.sio.ecp.fr. ◦ Chaque domaine entretient une base de donn´es sur le nommage de e ses machines. Celle-ci est mise ` disposition de tous les utilisateurs du a r´seau. e Chaque site raccord´ de mani`re permanente proc`de de cette mani`re, e e e e ainsi il n’y a pas une base de donn´es pour l’Internet mais un ensemble e structur´ de bases de donn´es reli´es entres elles et formant une gigan- e e e tesque base de donn´es distribu´e. e e2 Fonctionnement du DNS2.1 Convention de nommage La RFC 1034 pr´cise que les noms de machines sont d´velopp´s un peu e e ecomme les noms d’un syst`me de fichiers hi´rarchis´s (Unix,. . .) et utilisent e e eles caract`res ascii 7 bits assortis des contraintes suivantes : e ◦ Le “ . ” est le s´parateur e ◦ Chaque nœud ne peut faire que 63 caract`res au maximum ; “ le bon e usage ” les limite ` 12 caract`res et commen¸ant par une lettre. a e c ◦ Les majuscules et minuscules sont indiff´renci´es. e e ◦ Les chiffres [0-9] et le tiret peuvent ˆtre utilis´s, le soulign´ ( ) est un e e e abus d’usage. ◦ Le point “ . ” et le blanc “ ” sont proscrits. ◦ Les chaˆ ınes de caract`res comme “ NIC ” ou d’autres acronymes bien e connus sont ` ´viter absolument, mˆme encadr´es par d’autres ca- a e e e ract`res. e ◦ Les noms complets ne doivent pas faire plus de 255 caract`res de long. e Il y a des noms “ relatifs ” et des noms “ absolus ”, comme des cheminsdans un syst`me de fichiers. L’usage du “ . ” en fin de nom, qui indique un enommage absolu10 , est r´serv´ ` certains outils comme ping ou traceroute e eaet aux fichiers de configuration du serveur de noms. En r`gle g´n´rale il n’est e e epas utile de l’employer. 9 901 961 instances en janvier 2003 contre 1 203 856 instances en janvier 2002, selonle site du “ Network Wizards Internet Domain Suvey ” (www.nw.com), “ Top 100 HostNames ” 10 FQDN, comme “ Fully Qualified Domain Name ”
  • 170 Serveur de noms - DNS 2.1.1 “ Completion ” Sur un mˆme r´seau logique on a coutume de ne pas utiliser le nom e e complet des machines auxquelles on s’adresse couramment et pourtant ¸a c fonctionne ! La raison est que le “ resolver ”, partie du syst`me qui est en charge e de r´soudre les probl`mes de conversion entre un nom de machine et son e e adresse IP, utilise un m´canisme de compl´tion (“ domain completion ”) e e pour compl´ter le nom de machine simplifi´, jusqu’` trouver un nom plus e e a complet que le serveur de noms saura reconnaˆ dans sa base de donn´es. ıtre e Le “ resolver ” connait par hypoth`se le ou les noms de domaine (lus dans e le fichier de configuration /etc/resolv.conf) qui concernent la machine locale. Une station de travail n’en a g´n´ralement qu’un seul alors qu’un e e serveur peut en comporter plusieurs, par exemple si on souhaite consolider toute une palette de services pour plusieurs domaines sur une mˆme machine. e Exemple d’un tel fichier : domain sio.ecp.fr search sio.ecp.fr., ecp.fr. nameserver 138.195.52.68 nameserver 138.195.52.69 nameserver 138.195.52.132 Plus g´n´ralement ce nom de domaine se pr´sente sous forme d1 .d2 ...dn . e e e Ainsi, en pr´sence d’un nom symbolique x, le “ resolver ” teste pour chaque i, e i ∈ {1, 2, . . . , n} l’existence de x.di .di+1 ...dn et s’arrˆte si celle-ci est reconnue. e Dans le cas contraire la machine en question n’est pas atteignable. Exemple, avec le domaine ci-dessus : a) machine = www (requˆte) e www.sio.ecp.fr =⇒ Succ`s ! e b) machine = www.sio (requˆte) e ´ www.sio.sio.ecp.fr =⇒ Echec ! www.sio.ecp.fr =⇒ Succ`s ! e 2.2 Le “ Resolver ” Le “ resolver ” d´signe un ensemble de fonctions11 plac´es dans la bi- e e blioth`que standard (gethostbyname vu en cours de programmation invoque e les fonctions du “ resolver ”) qui font l’interface entre les applications et les serveurs de noms. Par construction les fonctions du “ resolver ” sont com- pil´es avec l’application qui les utilise (physiquement dans la libc, donc e accessibles par d´faut). e 11 res query, res search, res mkquery, res send, res init, dn comp, dn expand - Faire “ man resolver ” sur une machine unix
  • Le “ Resolver ” 171 Le “ resolver ” applique la strat´gie locale de recherche, d´finie par l’admi- e enistrateur de la machine, pour r´soudre les requˆtes de r´solution de noms. e e ePour cela il s’appuie sur son fichier de configuration /etc/resolv.conf et surla strat´gie locale (voir paragraphe suivant) d’emploi des possibilit´s (serveur e ede noms, fichier /etc/nsswitch.conf, NIS,. . .). Application Code utilisateur /etc/resolv.conf Requete UDP Serveur(s) "Resolver" de noms distant(s) Reponse UDP figure IX.02 — Le “ resolver ” dans son environnement Le fichier /etc/resolv.conf pr´cise au moins le domaine local assorti ede directives optionnelles.
  • 172 Serveur de noms - DNS 2.3 Strat´gie de fonctionnement e La figure IX.03 illustre le fait que chaque serveur de noms a la maˆ ıtrise de ses donn´es mais doit interroger ses voisins d`s qu’une requˆte concerne e e e une zone sur laquelle il n’a pas l’autorit´ de nommage. e Ainsi, un hˆte du domaine “ R2 ” qui veut r´soudre une adresse du o e domaine “ R1 ” doit n´cessairement passer par un serveur interm´diaire e e pour obtenir l’information. Cette d´marche s’appuie sur plusieurs strat´gies e e possibles, que nous examinons dans les paragraphes suivants. Subdivistion hiérarchiques des domaines Domaine R1 Domaines Domaine R2 figure IX.03 — Subdivision hi´rarchique des domaines e 2.3.1 Interrogation locale La figure ci-dessous illustre la recherche d’un nom dans le domaine local. 1 Serveur de Processus noms local 2 figure IX.04 — Interrogation locale
  • Strat´gie de fonctionnement e 173 Un processus (“ browser ” http par exemple) recherche l’adresse d’unnom de serveur. Sur les machines Unix cela se traduit par l’appel ` la fonc- ation gethostbyname. Cette fonction est syst´matiquement pr´sente dans la e ebiblioth`que standard (libc) et est donc accessible potentiellement ` tout e aex´cutable lors d’une compilation. e La fonction gethostbyname fait syst´matiquement appel au “ resolver ” ed´j` cit´. C’est donc toujours en passant par ce m´canisme que les processus ea e eacc`dent ` l’espace de noms. Le “ resolver ” utilise une strat´gie g´n´rale ` e a e e e ala machine (donc qui a ´t´ choisie par son administrateur) pour r´soudre de ee etelles requˆtes : e 1. Interrogation du serveur de noms (DNS) si pr´sent e 2. Utilisation des services type “ YP ” (NIS) si configur´s e 3. Utilisation du fichier /etc/hosts Cette strat´gie est param`trable en fonction du constructeur. Le e ensswitch sous HP-UX12 ou Solaris13 permet de passer de l’un ` l’autre en acas d’indisponibilit´, le fichier /etc/nsswitch.conf sous FreeBSD effectue eun travail assez proche. Enfin, quelle que soit l’architecture logicielle le “ resolver ” est configur´ e` l’aide du fichier /etc/resolv.conf.aSur la figure IX.04 : 1. Le processus demande l’adresse IP d’un serveur. Le “ resolver ” envoie la demande au serveur local. 2. Le serveur local re¸oit la demande, parcequ’il a l’autorit´ sur le domaine c e demand´ (le sien), il r´pond directement au “ resolver ”. e e2.3.2 Interrogation distante 1. Un processus demande l’adresse IP d’une machine. Le “ resolver ” en- voie sa requˆte au serveur local. e 2. Le serveur local re¸oit la requˆte et dans ce deuxi`me cas il ne peut pas c e e r´pondre directement car la machine n’est pas dans sa zone d’autorit´. e e Pour lever l’ind´termination il interroge alors un serveur racine pour e avoir l’adresse d’un serveur qui a l’autorit´ sur la zone demand´e par e e le processus. 3. Le serveur racine renvoie l’adresse d’un serveur qui a officiellement l’au- torit´ sur la zone e 4. Le serveur local interroge ce nouveau serveur distant. 5. Le serveur distant renvoie l’information demand´e au serveur local. e 6. Le serveur local retourne la r´ponse au “ resolver ” e 12 Unix de “ Hewlett-Packard ” 13 Unix de “ Sun Microsystems ”
  • 174 Serveur de noms - DNS Serveur de noms racine 2 3 1 4 Processus Serveur de Serveur de noms local noms distant 6 5 L figure IX.05 — Interrogation distante Remarques importantes : ◦ Un m´canisme de cache acc´l`re le processus ci-dessus : Si un processus e ee redemande la mˆme machine distante on se retrouve dans le cas d’une e interrogation “ locale ”, du moins pendant la dur´e de validit´ des e e donn´es (cf page 186). e ◦ Si un processus demande une machine du mˆme domaine que la e pr´c´dente (mais pas du mˆme nom ! :), les ´tapes 2 et 3 deviennent e e e e inutiles et le serveur local interroge alors directement le serveur distant. La dur´e de vie de l’adresse du serveur distant est elle aussi assortie e d’une date limite d’utilisation. ◦ Dans le cas g´n´ral les serveurs racines ne voient pas plus de 1 ou deux e e niveaux en dessous. Ainsi, si un processus demande A.B.C.D.net : 1. Le serveur racine donne l’adresse d’un serveur pour D 2. Le serveur pour D donnera peut ˆtre l’adresse d’un serveur pour e C et ainsi jouera le rˆle de serveur racine de l’´tape pr´c´dente. o e e e ◦ On dit ´galement que le serveur L de la figure IX.05 fonctionne en mode e r´cursif. e 2.3.3 Interrogation par “ procuration ” Le processus de recherche d´crit au paragraphe pr´c´dent ne convient pas e e e dans tous les cas, notamment vis ` vis des deux crit`res suivants : a e 1. S´curit´ d’un domaine e e 2. Conservation de la bande passante 1. La figure Romanchapter.05 montre le serveur local qui interroge directement les ser- veurs distants, cette d´marche pose des probl`mes de s´curit´ dans le cas e e e e d’un domaine au sein duquel seuls un ou deux serveurs sont autoris´s. e
  • Hi´rarchie de serveurs e 175 Par exemple le serveur de noms du domaine sio.ecp.fr n’interrogepas directement le serveur racine, il passe par le serveur officiel qui estpiston.ecp.fr (138.195.33.3). 2. Le trafic destin´ au serveur de noms peut consommer une partie non en´gligeable de la bande passante, c’est pourquoi il peut ˆtre strat´gique de e e econcentrer les demandes vers un seul serveur r´gional et donc de b´n´ficier e e eau maximum de l’effet de cache d´crit pr´c´dement. e e e2.4 Hi´rarchie de serveurs e Si tous les serveurs de noms traitent de donn´es d’un format identique, eleur position dans l’arborescence leur conf`re un statut qui se nomme : eserveur racine (“ root name server ”) Un serveur ayant autorit´ sur la e racine de l’espace de nommage. Actuellement il y a 13 serveurs de ce type, nomm´s [A-M].ROOT-SERVERS.NET14 eserveur primaire (“ master ”) Un serveur de noms qui a l’autorit´ pour un e ou plusieurs domaines (est d´tenteur d’autant de SOA – Voir page 183). e Il lit ses donn´es dans un fichier stock´ sur disque dur, ` son d´marrage. e e a e L’administrateur du (des) domaine(s) met ` jour les informations des a domaines concern´s depuis cette machine. eserveur secondaire (“ slave ”) Dans le cas d’une panne ou d’un en- gorgement du serveur primaire, les serveurs secondaires re¸oivent en c pr´vision une copie de la base de donn´es. e e ◦ Strat´giquement il est pr´f´rable de les placer en dehors du domaine, e ee sur le r´seau d’un autre FAI. Il peut y avoir autant de serveurs secon- e daires que souhait´, de l’ordre de trois ou quatre est souvent recontr´. e e ◦ Au d´marrage ils re¸oivent les informations du serveur primaire, ou e c ils les lisent sur leur disque dur s’ils ont eu le temps de les y stocker au pr´c´dent arrˆt du serveur, et si elles sont encore valides. e e e Par exemple, le serveur PISTON.ECP.FR a comme serveurs secon- daires NS2.NIC.FR, SOLEIL.UVSQ.FR, MANOUL.CTI.ECP.FR.2.5 Conversion d’adresses IP en nomsOn dit aussi questions inverses (“ inverse queries ” vs “ reverse queries ”). Cette possibilit´ est indiqu´e comme optionnelle dans la RFC 1034 mais e eest n´anmoins bien commode voire mˆme fr´quement requise pour le client e e er´seau de services comme le courrier ´lectronique, l’´tablissement de sessions e e e` distance avec ssh ou mˆme les serveurs de fichiers anonymes (ftp). Sia eune machine est enregistr´e dans le TLD in-addr.arpa, c’est un indicateur efavorable quant ` la qualit´ d’administration du r´seau qui l’h´berge, mais a e e ene prouve rien quant aux bonnes intentions de son (ses) utilisateur(s). 14 fichier named.root, par exemple dans le r´pertoire /etc/namedb e
  • 176 Serveur de noms - DNS Il faut ajouter que le bon usage sur les r´seaux est de pr´voir une entr´e e e e dans la zone reverse pour toutes les machines utiles et utilis´es d’un r´seau e e accessible de l’Internet. Le contraire provoque bien souvent la grogne (` juste a titre) des administrateurs. ` Il faut reconsid´rer la figure IX.01. A gauche de la figure on distingue e un domaine un peu particulier “ in-addr.arpa ”. Toutes les adresses sont exprim´es dans le “ top level domain ” : e in-addr.arpa Du fait de la lecture inverse de l’arbre, les adresses IP sont exprim´es en e “ mirroir ” de la r´alit´. Par exemple pour la classe B de l’ecp : e e 195.138.in-addr.arpa (Classe B 138.195) Le fonctionnement par d´l´gation est calqu´ sur celui utilis´ pour les noms ee e e symboliques (c’est la justification de son insertion dans la figure ChapterRoman.01). Ainsi, on peut obtenir la liste des serveurs ayant autorit´ e sur la zone 195.138.in-addr.arpa en questionnant d’abord les serveurs du TLD in-addr.arpa puis ceux pour la zone 138.in-addr.arpa, et ainsi de suite. . . Chaque administrateur de zone peut aussi ˆtre en charge de l’administra- e tion des “ zones reverses ”, portion du domaine “ arpa ”, des classes d’adresses dont il dispose pour nommer ses machines, s’il en re¸oit la d´l´gation. Il faut c ee bien noter que cette d´l´gation est une op´ration ind´pendante de celle qui ee e e a lieu pour les autres domaines. Notons ´galement que la notion de sous r´seau (cf page 38) n’est pas e e applicable au domaine “ in-addr.arpa ”, ce qui signifie que les adresses selon les contours naturels des octets. Ainsi, pour les clients de fournisseurs d’acc`s n’ayant comme adresses IP e officielles que celles d´limit´es par un masque de sous r´seau large seulement e e e que de quelques unit´s (< 254), la gestion de la zone reverse reste du domaine e du prestataire (FAI) et non du client.
  • Conclusion 1772.6 ConclusionQu’est-ce qu’un DNS ? Un serveur de noms repose sur trois constituants : 1. Un espace de noms et une base de donn´es qui associe de mani`re e e structur´e des noms ` des adresses IP. e a 2. Des serveurs de noms, qui sont comp´tents pour r´pondre sur une ou e e plusieurs zones. 3. Des “ resolver ” capables d’interroger les serveurs avec une strat´gie e d´finie par l’administrateur du syst`me. e eTCP ou UDP ? Le port 53 “ bien connu ” pour le serveur de noms est pr´vu pour fonc- etionner avec les deux protocoles. ◦ Normalement la majeure partie du trafic se fait avec UDP, mais si la taille d’une r´ponse d´passe les 512 octets, un drapeau de l’en-tˆte du e e e protocole l’indique au client qui reformule sans question en utilisant TCP. ◦ Quand un serveur secondaire d´marre son activit´, il effectue une con- e e nexion TCP vers le serveur primaire pour obtenir sa copie de la base de donn´es. En g´n´ral, toutes les trois heures (c’est une valeur courante) e e e il effectue cette d´marche. e3 Mise ` jour dynamique a La mise ` jour dynamique de serveur de noms (RFC 2136) est une fonc- ationnalit´ assez r´cente sur le r´seau, elle permet comme son nom l’indique e e ede mettre ` jour la base de donn´e r´partie. a e e Aussi bien au niveau du r´seau local qu’` l’´chelle de l’Internet il s’agit le e a eplus souvent de faire correspondre un nom de machine fixe avec une adresse ipchangeante. C’est typiquement le cas d’un tout petit site qui a enregistr´ son edomaine chez un vendeur quelconque et qui au gr´ des changements d’adresse eip (attribu´e dynamiquement par exemple avec DHCP15 ) par son fournisseur ed’acc`s, met ` jour le serveur de noms pour ˆtre toujours accessible. e a e Avec comme mot clef “ dyndns ”, les moteurs de recherche indiquentl’existence de sites commerciaux ou ` caract`re associatif, qui proposent cette a efonctionnalit´.e 15 Cf http://www.isc.org/products/DHCP/
  • 178 Serveur de noms - DNS 4 S´curisation des ´changes e e Le serveur de noms est la clef de voˆte des r´seaux, et c’est en mˆme temps u e e un de ses talons d’Achille parceque les programmes que nous employons quo- tidiennement utilisent sans discernement l’information acquise du r´seau. En e effet, qu’est-ce qui vous assure que le site web de votre banque sur lequel vous venez de taper votre mot de passe est bien le vrai site officiel de cet ´tablissement ? L’apparence de la page de garde ? e Typiquement il y a deux situations de vuln´rabilit´ : e e 1. Dialogue serveur ` serveur, notament lors de transferts de zones a 2. Interrogation d’un serveur par un resolveur Pour faire confiance en ce que vous dit le serveur de noms interrog´ il faut e d’une part que vous soyez certains d’interroger la bonne machine et d’autre part que celle-ci soit d´tentrice d’une information incontestable. e C’est une chaˆ de confiance, comme toujours en s´curit´, qui re- ıne e e monte par construction du fonctionnement du serveur de noms interrog´ e par votre application (comme nous l’avons examin´ dans les paragraphes qui e pr´c`dent) jusqu’aux serveurs racines. e e La version ISC (consultez le paragraphe 7) du programme BIND utilise deux strat´gies diff´rentes, selon les cas ci-dessus. Dans le premier cas il s’agit e e d’un m´canisme nomm´ TSIG/TKEY, dans le deuxi`me DNSSEC. e e e TSIG/TKEY utilisent une clef sym´trique, donc partag´e par les deux e e serveurs (cette clef leur est connue par des m´canismes diff´rents). DNSSEC e e utilise un m´canisme bas´ sur le principe d’un ´change de clefs publiques. e e e Outre les dysfonctionnements dˆs ` une information erron´e on observe u a e 16 ´galement des attaques de type “ d´ni de service ” utilisant le fonctionnant e e intrins`que du protocole (voir plus loin5). e 4.1 TSIG/TKEY pour s´curiser les transferts e L’usage d’une clef sym´trique indique qu’il s’agit d’un secret partag´ entre e e 2 serveurs. La mˆme clef sert au chiffrement et au d´chiffrement des donn´es. e e e Le bon usage veut que l’on d´die une clef ` un certain type de transaction (par e a exemple le transfert d’une zone) entre deux serveurs donn´s. Cette mani`re e e de proc´der se traduit donc rapidement par un grand nombre de clefs ` g´rer e a e ce qui interdit un d´ploiement g´n´ralis´ sur l’Internet. e e e e Pour ´viter de trop longs temps de chiffrement, ce ne sont pas les donn´es e e ` transf´rer qui sont chiffr´es (de plus elles ne sont pas confidentielles), mais a e e leur empreinte (“ fingerprints ”) avec un algorithme de type MD5 ou SHA117 . 16 http://fr.wikipedia.org/wiki/Dunhboxvoidb@xbgroupletunhbox voidb@xsetbox@tempboxahbox{eglobalmathchardefaccent@spacefactor spacefactor}accent19eegroupspacefactoraccent@spacefactorni_de_service 17 Ne pas h´siter ` faire un man md5 ou man sha1 sur une machine Unix pour en savoir e a plus !
  • DNSSEC pour s´curiser les interrogations e 179Cette empreinte, seule, est crypt´e. e Le serveur qui re¸oit un tel paquet sign´, calcule l’empreinte du paquet c eavec le mˆme algorithme, d´chiffre celle jointe avec la clef secr`te partag´e e e e eet compare les deux empreintes. Le r´sultat de cette comparaison dit si les edonn´es sont valides ou non. e L’int´rˆt de ces transferts sign´s est que les serveurs secondaires sont ee ecertains de mettre ` jour leur zones avec des donn´es qui proviennent bien a edu d´tenteur du SOA et qui sont absolument semblables ` ce qui a ´t´ ´mis. e a eee4.1.1 TSIG TSIG comme “ Transaction SIGnature ” est la m´thode d´crite dans e ela RFC 2845 et bas´e sur l’usage d’une clef sym´trique. La g´n´ration e e e ede cette clef peut ˆtre manuelle ou automatis´e avec le programme e e“ dnssec-keygen ”. ´ La propagation de cette clef est manuelle (scp. . .Eviter absolumentl’usage de tout protocole diffusant un mot de passe en clair sur le r´seau), edonc mise en place au coup par coup. TSIG sert ´galement ` la mise ` jour dynamique (“ dynamic update ”), e a ala connaissance de la clef par le client sert ` la fois ` l’authentifier et ` signer a a a 18les donn´es . e4.1.2 TKEY TKEY, d´crit dans la RFC 2930, rend les mˆmes services que TSIG tout e een ´vitant le transport du secret (TSIG). Cette caract´ristique est bas´e e e esur le calcul la clef sym´trique automatiquement avec l’algorithme de Diffie- eHellman plutˆt que par un ´change “ manuel ”19 . o e Par contre, cet algorithme ` base du tandem clef publique – clef priv´e a esuppose l’ajout d’un champ KEY dans les fichiers de configuration du serveur.Comme d’ailleurs le m´canisme suivant. . . e4.2 DNSSEC pour s´curiser les interrogations eDNSSEC d´crit dans la RFC 2535 permet : e 1. La distribution d’une clef publique (champ KEY) 2. La certification de l’origine des donn´es e 3. L’authentification des transactions (transferts, requˆtes) e Mis en place, le DNSSEC permet de construire une chaˆ de confiance, ınedepuis le “ top level ” jusqu’au serveur interrog´ par votre station de travail. e 18 cf le programme nsupdate et la RFC 2136 19 On peut trouver une explication de cet algorithme sur ce site : http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
  • 180 Serveur de noms - DNS 5 Attaque DNS par amplification Le fonctionnement repose sur UDP, protocole pour lequel l’en-tˆte e (page 84) est facilement falsifiable, notamment sur l’adresse de retour. Il est ainsi tr`s facile d’envoyer une requˆte ` un serveur, avec une adresse de e e a retour qui est celle d’une machine victime plutˆt que la sienne : o Serveur de noms IPs IPx IPv Requete avec Réponse à une Machine IPv comme adresse requete non Machine assaillante de retour posée par IPv victime figure IX.06 — R´ponse ` une requˆte non formul´e e a e e Sur la figure IX.06 la machine d’adresse IPv re¸oit un message du serveur c de noms d’adresse IPs, non sollicit´. Il est bien ´vident qu’un seul message e e de ce type reste sans effet, cependant : 1. Le volume en octets de la r´ponse peut ˆtre consid´rablement plus e e e important que celui de la requˆte, notamment si le serveur de noms est e configur´ par l’assaillant. Par exemple d’un facteur 5 ou 10. e 2. L’assaillant peut envoyer un tr`s grand nombre de requˆtes ` des ser- e e a veurs ouverts en mode r´cursif pour toute requˆte ne portant pas sur e e les domaines sur lequels ils ont autorit´. e La machine victime est alors submerg´e par un flot de r´ponses qui sa- e e turent compl`tement ses acc`s r´seaux, c’est une une attaque DNS par am- e e e plification20 et qui provoque un d´ni de service sur le site qui la subit. e Le sch´ma d’ensemble d’une telle attaque est r´sum´ sur la figure IX.07. e e e La machine assaillante (elles peuvent ˆtre nombreuses, des centaines de e milliers) bombardent les serveurs (S1, S2,. . .Sn) de fausses requˆtes. e Ces serveurs sont utilis´s parcequ’ils combinent deux propri´t´s e ee int´ressantes : e 1. Ils sont ouverts aux requˆtes ext´rieures mˆme et surtout celles qui ne e e e portent pas sur leurs donn´es. Cette propri´t´ est h´rit´e de l’´poque e ee e e e ou l’Internet ´tait encore un r´seau d’universitaires et d’informaticiens. e e Cette proprit´ devrait tendre ` disparaˆ e a ıtre, mais c’est loin d’ˆtre encore e 20 http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
  • Attaque DNS par amplification 181 le cas21 puisque la configuration standard des outils l’autorise et que les comp´tences techniques ne sont pas assez nombreuses. e 2. Ils utilisent un cache DNS. L’effet de ce cache est que mˆme si la ma- e chine “ source ” est isol´e du r´seau, les enregistrements lus, pourvu e e qu’ils soient assortis d’un temps de vie suffisant (TTL, page 183) peuvent continuer d’ˆtre exploit´s. e e Serveur de noms ‘‘ source ’’ S1 S2 S3 S4 S5 Sn IPs IPx IPv Requete avec Réponse à une Machine IPv comme adresse requete non Machine assaillante de retour posée par IPv victime figure IX.07 — Attaque DNS par amplificationQuelques remarques : 1. Le serveur de noms “ source ” n’est pas n´cessairement complice, c’est e tout simplement un serveur avec de gros enregistrements. 2. Les serveurs S1 ` Sn sont utilis´s ` leur insu mais une configuration a e a soigneuse peut ´viter cet abus d’usage. e 3. Une fois attaqu´ le serveur victime ne peut pas faire grand chose. Ses e services ne sont plus accessibles car le r´seau est satur´. e e 4. La parade avec un serveur de type Bind de l’ISC (page 186) consiste ` explicitement limiter l’ouverture ext´rieure du serveur aux seules a e donn´es sur lesquelles il a autorit´ 22 . e e L’acc`s aux donn´es dans le cache doit ´galement ˆtre prot´g´ car e e e e e e d’autres techniques existent pour peupler les caches, par exemple en- voyer un mail qui n´cessite l’interrogation du serveur source. e 21 Un test sur son serveur depuis une machine hors de son r´seau local est possible ` e acette url http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl 22 Directives allow-recursion et allow-query-cache du fichier de configuration
  • 182 Serveur de noms - DNS 6 Format des “ Resource Record ” Comme pour toute base de donn´es, le serveur de nom a un format pour e ses champs, ou “ Resource Record ”, RR dans la suite de ce texte, d´fini ` e a l’origine dans la RFC 1035. En pratique toutes les distributions (commerciales ou libres) du serveur de noms conservent ce format de base de donn´es, la mise en œuvre du serveur e seule change (fichier de configuration du daemon). Un serveur de noms a autorit´ (responsabilit´ du SOA) sur une ou plusieurs e e zones, celles-ci sont rep´r´es dans ses fichiers de configuration (named.conf ee ou named.boot selon les versions). S’il est serveur primaire d’une ou plusieurs zones, le contenu de ces zones est inscrit dans des fichiers ASCII ; leur syntaxe est succintement d´crite dans le paragraphe suivant. e S’il est serveur secondaire, le fichier de configuration indique au server de quelle(s) zone(s) il est secondaire (il peut ˆtre secondaire d’un grand nombre e de zones) et donc o` (adresse IP) il devra aller chercher cette information. u Cette action se traduit par ce que l’on nomme un “ transfert de zone ”. Ce transfert est effectu´ automatiquement ` la fr´quence pr´vue par l’adminis- e a e e trateur du champ SOA et donc connue d`s le premier transfert. En cas de e changement sur le serveur principal, celui-ci avertit (“ Notify ”) ses serveurs secondaires de la n´cessit´ de recharger la zone pour ˆtre ` jour. e e e a Le propos de ce qui suit n’est pas de se substituer ` une documenta- a tion nombreuse et bien faite sur le sujet, mais d’apporter quelques ´l´ments ee fondamentaux pour en aider la lecture. Le constituant de base d’un serveur de noms est une paire de fichiers ASCII contenant les enregistrements, les “ Resource Record ”. Ceux-ci sont en g´n´ral ´crits sur une seule ligne de texte (sauf pour e e e le champ SOA qui s’´tale sur plusieurs lignes. Le marqueur de fin de ligne e (CR+LF) est aussi celui de la fin de l’enregistrement. Le contenu g´n´ral e e d’un tel enregistrement a la forme suivante (les accolades indique des donn´es e optionnelles) : {name} {ttl} addr-class Record Type Record Specific data Cinq enregistrements, ou “ Resource Record ”, ou en RR, sont absolument fondamentaux pour faire fonctionner un serveur de noms : SOA, NS, A, MX et PTR.
  • RR de type SOA 1836.1 RR de type SOA $(ORIGIN) sio.ecp.fr. name {ttl} addr−class SOA Origin Person in charge @ IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. ( 2007100801 ; Serial 10800 ; Refresh (3h) 3600 ; Retry (1H) 3600000 ; Expire (5w6d16h) 86400 ) ; Minimum ttl (1D) SOA est l’acronyme de “ Start Of Authority ” et d´signe le d´but e eoblig´ et unique d’une zone. Il doit figurer dans chaque fichier db.domain et edb.adresse Le nom de cette zone est ici rep´r´ par le caract`re @ qui signifie ee ela zone courante, rep´r´e par la ligne au dessus “ $(ORIGIN) sio.ecp.fr. ”. eeLa ligne aurait ´galement pu s’´crire : e e sio.ecp.fr. IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. (...) Un probl`me concernant cette zone devra ˆtre signal´ par e-mail ` e e e ahostmaster@sio.ecp.fr (notez le “.” qui s’est transform´ en “@”). e Les param`tres de ce SOA sont d´crits sur plusieurs lignes, regroup´es e e eentres parenth`ses. Le caract`re “ ;” marque le d´but d’un commentaire, qui e e es’arrˆte ` la fin de ligne. e aLes points en fin de noms sont n´cessaires. e Le num´ro de s´rie doit changer ` chaque mise ` jour de la zone (sur le ser- e e a aveur principal). Le Refresh indique la fr´quence, en secondes, ` laquelle les e aserveurs secondaires doivent consulter le primaire pour ´ventuellement lancer eun transfert de zone (si le num´ro de s´rie est plus grand). Le Retry indique e ecombien de secondes un serveur secondaire doit attendre un transfert avantde le d´clarer impossible. Le Expire indique le nombre de secondes maxi- emum pendant lesquelles un serveur secondaire peut se servir des donn´es du eprimaire en cas d’´chec du transfert. Minimum ttl est le nombre de secondes epar d´faut pour le champ TTL si celui-ci est omis dans les RR. e6.2 RR de type NS Il faut ajouter une ligne de ce type (“ Name Server ”) pour chaqueserveur de noms pour le domaine. Notez bien que rien dans la syntaxe nepermet de distinguer le serveur principal de ses secondaires.Dans le fichier db.domaine : {name} {ttl} addr−class NS Name servers name IN NS ns−master.sio.ecp.fr. IN NS ns−slave1.sio.ecp.fr. IN NS ns−slave2.sio.ecp.fr.
  • 184 Serveur de noms - DNS Dans le fichier qui renseigne la zone “ reverse ”, par exemple db.adresse, on trouvera : 52.195.138.in−addr.arpa. IN NS ns−master.sio.ecp.fr. 52.195.138.in−addr.arpa. IN NS ns−slave1.sio.ecp.fr. 52.195.138.in−addr.arpa. IN NS ns−slave2.sio.ecp.fr. 6.3 RR de type A Le RR de type A, ou encore “ Address record ” attribue une ou plusieurs adresses ` un nom, c’est donc celui qui est potentiellement le plus fr´quement a e utilis´. Il doit y avoir un RR de type A pour chaque adresse d’une machine. e {name} {ttl} addr−class A address gw−sio IN A 138.195.52.2 IN A 138.195.52.33 IN A 138.195.52.65 6.4 RR de type PTR Le RR de type PTR, ou encore “ PoinTeR record ” permet de sp´cifier les adresses pour la r´solution inverse, donc dans le domaine sp´cial e e e IN-ADDR.ARPA. Notez le “.” en fin de nom qui interdit la compl´tion (il s’agit e bien du nom FQDN). name {ttl} addr−class PTR real name 2 IN PTR gw−sio.sio.ecp.fr. 33 IN PTR gw−sio.sio.ecp.fr. 65 IN PTR gw−sio.sio.ecp.fr. 6.5 RR de type MX Le RR de type MX, ou encore “ Mail eXchanger ” concerne les relations entre le serveur de noms et le courrier ´lectronique. Nous examinerons son e fonctionnement ult´rieurement dans le chapitre sur le courrier ´lectronique e e (cf page 205). sio.ecp.fr. IN MX 10 smtp.ecp.fr. sio.ecp.fr. IN MX 20 mailhost.laissus.fr.
  • RR de type CNAME 1856.6 RR de type CNAME Le RR de type CNAME, ou encore “ canonical name ” permet de distin-guer le nom officiel d’une machine de ses surnoms. www.sio.ecp.fr. IN CNAME msio−bipro.cti.ecp.fr. Dans l’exemple ci-dessus, la machine www.sio.ecp.fr est un surnom dela machine msio-bipro.cti.ecp.fr. Le fait que ces deux appellations soientdans la mˆme zone (ecp.fr.) n’aide en rien au bon fonctionnement du dis- epositif. La machine msio-bipro pourrait ˆtre h´berg´e n’importe o` ailleurs e e e usur un autre r´seau dans une autre zone. . . ! e Cette possibilit´ est tr`s employ´e pour constituer des machines virtuelles, e e ecomme nous le verrons au chapitre VIII.6.7 Autres RR. . . Il existe d’autres RR, entres autres HINFO , TXT, WKS et KEY, non trait´s edans cette pr´sentation parcequ’ils n’apportent rien ` la compr´hension du e a efonctionnement du serveur de noms. Le lecteur est fortement incit´ ` se e areporter au “ Name Server Operations Guide ” pour plus d’informations.
  • 186 Serveur de noms - DNS 7 BIND de l’ISC L’Internet Software Consortium23 est une organisation non commerciale qui d´veloppe et favorise l’emploi de l’outil “ Open Source ” comme BIND e (acronyme de “ Berkeley Internet Name Domain ”). Cette version libre du serveur de nom est la plus employ´e sur les machines e Unix du r´seau, ce qui justifie que l’on s’y int´resse. Elle fournit une version e e du daemon “ named ” et un “ resolver ” int´gr´ dans la libc. On peut e e ais´ment installer ce logiciel sur ` peu pr`s toutes les impl´mentations d’unix e a e e connues (cf le fichier INSTALL du r´pertoire src). e named nsupdate Réseau tcp/ip Transferts de zones, queries Mise à jour dynamique de RRs Signaux Syslog named rndc named.conf localhost.rev db.192.168.192 named.root db.terminal /var/run/named.pid /var/run/ndc /var/tmp/* Contour logique du serveur de noms figure IX.08 — BIND de l’ISC 7.1 Architecture du daemon “ named ” La figure IX.06 montre le sch´ma g´n´ral de l’organisation logicielle du e e e daemon “ named ”. Au d´marrage celui-ci lit sa configuration dans un fichier qui peut se e nommer named.boot ou named.conf selon que l’on est en version 4.9.11, 8.3.6 ou 9.2.9 et les suivantes du logiciel24 . named.conf C’est le fichier de configuration lu au d´marrage. Sa structure e d´pend de la version du logicielle, heureusement dans les deux cas la e s´mantique reste proche ! e 23 http://www.isc.org/ 24 taper “ named -v ” pour les discerner entre-elles
  • 8 Bibliographie 187named.root Ce fichier contient la liste des serveurs de la racine, leur nom et adresse IP.localhost.rev Ce fichier contient la base de donn´e du “ localhost ”. Per- e sonne ne poss`de en particulier le r´seau 127, donc chacun doit le g´rer e e e pour lui-mˆme. L’absence de ce fichier n’empˆche pas le serveur de e e fonctionner, mais ne lui permet pas de r´soudre 127.0.0.xx (o` xx est e u le num´ro de la machine courante, souvent 1). edb.terminal Exemple de fichier de base de donn´es pour le domaine fac- e tice terminal.fr qui est utile durant les travaux pratiques. Ce fichier permet la convertion des noms en adresses IP.db.192.168.192 Ce fichier contient la base de donn´es de la zone “ reverse ” e pour le domaine terminal.fr, c’est ` dire le fichier qui permet au a logiciel de convertir les adresses IP en noms.rndc ou “ name server control utility ” est comme son nom l’indique un outil d’administration du programme named lui-mˆme. C’est une e alternative ` l’usage direct des signaux. Le canal de communication a entre les deux programmes est une socket unix AF UNIX vs AF LOCAL (cf cours de programmation page 251). Un certain nombre de signaux modifient le comportement du serveur, ilsseront examin´s en travaux pratiques, tout comme les fichiers lus ou ´crits e edans les r´pertoires /var/run et /var/tmp/. e Enfin la fl`che vers syslog signifie que named utilise ce service pour laisser eune trace de son activit´ (cf cours sur l’architecture des serveurs). e Enfin, le BOG, c’est ` dire le “ Bind Operations Guide ”, d´taille le a econtenu des champs de la base de donn´es des versions 4.x et 8.x. Pour la eversion 9.x est distribu´e avec “ BIND 9 Administrator Reference Manual ” eune documentation ´galement tr`s bien faite. e e8 Bibliographie Quand on “ sait d´j` ”, la page de man de “ named ” suffit ` v´rifier un ea a epoint obscur ! Sinon il existe une documentation tr`s fournie sur le sujet, avec enotamment : ◦ Kein J. Dunlap & Michael J. Karels — “ Name Server Operations Guide ” — Ce document est accessible sur le serveur de l’Internet Software Consortium 25 ◦ By the Nominum BIND Development Team — “ BIND 9 Administrator Reference Manual ” — Version 9.1.3 26 ◦ Douglas E. Comer — “ Internetworking with TCP/IP – Volume I” (chapter 18) — Prentice All — 1988 25 On trouve le BOG dans la distribution de “ bind ” ` cette adresse : http://www.isc. aorg/products/BIND/ 26 on trouve ´galement la derni`re version de ce document sur le site de l’ISC e e
  • 188 Serveur de noms - DNS ◦ Paul Albitz & Cricket Liu — “ DNS and BIND ” — O’Reilly & Asso- ciates, Inc. — 1992 ◦ “ Installing and Administering ARPA Services ” — Hewlett Packard — 1991 ◦ W. Richard Stevens — “ TCP/IP Illustrated Volume I ” (chapter 14) — Prentice All — 1994 Et pour en savoir encore plus. . . RFC 1034 “ Domain names - concepts and facilities ”. P.V. Mockape- tris. Nov-01-1987. (Format : TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status : STANDARD) RFC 1035 “ Domain names - implementation and specification ”. P.V. Mockapetris. Nov-01-1987. (Format : TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137) (Status : STAN- DARD) RFC 1101 “ DNS encoding of network names and other types ”. P.V. Mockapetris. Apr-01-1989. (Format : TXT=28677 bytes) (Updates RFC1034, RFC1035) (Status : UNKNOWN) RFC 1123 “ Requirements for Internet hosts - application and support ”. R.T. Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD) RFC 1713 “ Tools for DNS debugging ”. A. Romao. November 1994. (For- mat : TXT=33500 bytes) (Also FYI0027) (Status : INFORMATIO- NAL) RFC 2136 “ Dynamic Updates in the Domain Name System (DNS UP- DATE) ”. P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format : TXT=56354 bytes) (Updates RFC1035) (Updated by RFC3007) (Status : PROPOSED STANDARD) RFC 2535 “ Domain Name System Security Extensions ”. D. Eastlake 3rd. March 1999. (Format : TXT=110958 bytes) (Obsoletes RFC2065) (Updates RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445) (Status : PRO- POSED STANDARD) RFC 2845 “ Secret Key Transaction Authentication for DNS (TSIG) ” P. Vixie, O. Gudmundsson, B. Wellington. May 2000. (Format : TXT=32272 bytes) (Updates RFC1035) (Status : PROPOSED STAN- DARD) RFC 2930 “ Secret Key Establishment for DNS (TKEY RR) ” D. Eastlake 3rd. September 2000. (Format : TXT=34894 bytes) (Status : PROPO- SED STANDARD)
  • Chapitre X Courrier ´lectronique e1 G´n´ralit´s sur le courrier ´lectronique e e e e Le courrier ´lectronique, ou “ mail ” est l’un des deux services les plus epopulaires sur le r´seau, avec le web. e C’est aussi l’un des plus vieux services du r´seau, bien avant que le er´seau existe sous la forme que l’on pratique aujourd’hui1 . La pr´face de e ela [RFC 822], document fondamental parmi les documents fondamentauxpour ce chapitre, laisse supposer l’existence de nombreux formats d’´changes e´lectroniques sur l’Arpanet, et ce avant 1977.e Sa popularit´ repose sur sa grande souplesse et rapidit´ d’emploi. Il per- e emet aussi bien les ´changes professionnels que les ´changes priv´s ; son mode e e ed’adressage donne la possibilit´ d’envoyer un courrier ` une personne comme e a` une liste de personnes ou encore ` un automate capable de rediffuser versa aun groupe (“ mailing-list ”). De nombreux outils d´velopp´s, ` l’origine essentiellement sur le syst`me e e a eUnix, autour de ce concept ouvrent un vaste champs de possibilit´s aux utili- esateurs de tous les syst`mes d’exploitation, comme la ventilation des courriers epar th`me, le renvoi automatique, le r´pondeur (pendant les absences), l’acc`s e e e` sa boite aux lettres depuis des endroits diff´rents, la r´ception de fax,. . .Laa e eliste ne peut pas ˆtre exhaustive ! e C’est souvent pour avoir l’usage du courrier ´lectronique que les entit´s e e(s’il en reste) non encore reli´es ` l’Internet franchissent le pas. L’usage des e aautres services arrivent plus tard, si besoin est. 1 Un historique int´ressant http://www.fnet.fr/history/ e
  • 190 Courrier ´lectronique e 1.1 M´taphore du courrier postal - L’enveloppe e Un courrier postal (ou de surface, “ s-mail ”) a fondamentalement besoin de l’adresse du destinataire et de l’adresse de l’´metteur (pour la r´ponse). e e L’usage du timbre et de l’enveloppe r´pondent ` d’autres crit`res. e a e Une fois dans la boˆ aux lettres, l’enveloppe est rout´e de la poste locale ıte e vers la poste la plus proche du destinataire, pour ˆtre finalement d´livr´e par e e e un facteur. Pour un courrier ´lectronique les besoins sont quasiment iden- e tiques ! Le concept d’enveloppe est conserv´, il s’agit de l’adresse de l’´metteur e e du courrier et de celle(s) du (des) destinataire(s), propag´es de mani`re bien e e s´par´e du corps du message afin que le protocole SMTP qui joue le rˆle du e e o service postale (Voir page 195) puisse router et finalement d´livrer le courrier e ` son (ses) destinataire(s). a Il existe de tr`s nombreux outils pour lire/´crire un mail, des outils pour e e jouer le rˆle du bureau de poste et/ou du facteur. Sous Unix le facteur est le o syst`me lui-mˆme, le bureau de poste un programme nomm´ “ sendmail2 ”. e e e Il existe d’autres alternatives non abord´es dans ce document, comme le e programme “ qmail3 ” ou encore le programme “ postfix4 ”. 1.2 Adresse ´lectronique e Tous les courriers ´lectroniques ont un destinataire pr´cis´ par son adresse e e e 5 ´lectronique, ou “ E-mail ”. Celle-ci pr´cise le nom du destinataire et le site e e o` il re¸oit son courrier ´lectronique. u c e Le nom du destinaire est une chaˆ de caract`res. Traditionnellement ıne e et pour des raisons techniques, sur le syst`me Unix, le login de l’utilisateur e peut ˆtre ´galement le nom de sa boite aux lettres. Cette possibilit´ est de e e e moins en moins vraie ` mesure que d’autres syst`mes avec d’autres logiques a e de fonctionnement existent ´galement sur le r´seau (notamment la lecture du e e mail via un interface html ou encore lorsque le mail est d´livr´ directement e e dans une une base de donn´es et non d´livr´ dans un fichier). e e e Par exemple, il est assez fr´quent de voir employer le nom complet e (pr´nom et nom de famille) pour d´signer l’interlocuteur distant. La conver- e e sion ultime entre cette convention et la boˆ aux lettres de l’utilisateur est ıte l’affaire du “ bureau de poste le plus proche ”, c’est ` dire le programme a “ sendmail ” pour ce document (voir plus loin au paragraphe 4). Le caract`re “ @ ” (lire “ at ”) s´pare l’identificateur du destinataire de e e la destination. 2 Version 8.13.5 en septembre 2005 — http://www.sendmail.org/ 3 http://www.qmail.org/ 4 http://postfix.eu.org/start.html 5 Terme francis´ en “ m`l ”, ou “ couriel ” pour les documents administratifs. . . ;-) e e
  • 2 Format d’un “ E-mail ” - RFC 822 191 La destination est peut ˆtre vide (il s’agit alors d’un destinataire sur ela machine courante, ou d’un synonyme (“ alias ”) que le sendmail localsait traiter), ˆtre un nom de machine du domaine local, le nom d’un autre edomaine ou d’une machine sur un autre domaine.Les adresses suivantes ont un format valide :user1 Destinataire local.user2@nom de machine Destinataire sur une machine du domaine courant (rappellez-vous, il existe un m´canisme de compl´tion dans le “ resol- e e ver ” page 170 !).user3@nom de machine.domaine Destinataire sur une machine particuli`re e d’un domaine particulier (non forc´ment local). euser4@domaine Destinataire sur un domaine particulier (mˆme remarque e que ci-dessus). On devine ais´ment que le fonctionnement du courrier ´lectronique sur e eune machine distante est fortement li´e au bon fonctionnement du serveur ede noms (chapitre IX). Qui plus est, lorsque seul un nom de domaine est pr´cis´ ` droite du e e acaract`re “ @ ”, une information manque apparemment quant ` la machine e asusceptible de recevoir le mail. Le lecteur en quˆte de plus de pr´cisions trouvera une description exhaus- e etive de la syntaxe d’une adresse au paragraphe 6 de la [RFC 822].2 Format d’un “ E-mail ” - RFC 822 Les octets qui composent un courrier ´lectronique ob´issent ` une struc- e e ature bien d´finie par la [RFC 822] de David H. Crocker : un en-tˆte et un e e 6corps de message, s´par´s par une ligne blanche (deux CRLF qui se suivent). e e Le contenu de l’en-tˆte dans son int´gralit´ n’est pas toujours spon- e e etan´ment montr´ par les outils qui nous permettent de lire et d’envoyer du e ecourrier ´lectronique. Une option est toujours accessible pour ce faire, comme e“ h ” sous mutt 7 . Une partie de l’en-tˆte est g´n´r´e automatiquement par le programme e e eequi se charge du transfert (le paragraphe suivant nous dira qu’il s’agit d’unMTA), une autre est ajout´e par le programme qui permet de composer le email, le MUA, une autre enfin est tap´e par l’utilisateur lui-mˆme. e eL’en-tˆte est constitu´ de lignes construites sur le mod`le : e e e identificateur : [ valeur ] CRLF 6 Il s’agit respectivement des caract`res 13 et 10 de la table ASCII - cf “ man ascii ” e 7 http://www.mutt.org/ — le MUA (Mail User Agent) pr´f´r´ de l’auteur :-) eee
  • 192 Courrier ´lectronique e L’identificateur ne peut pas contenir le caract`re “ : ” parcequ’il sert de e s´parateur avec la partie droite. Il est constitu´ de caract`res ASCII cod´s e e e e sur 7 bits et imprimables (c’est ` dire comprise dans le segment [33, 126]), a except´ l’espace. e Valeur est optionnelle. L’usage des majuscules ou des minuscules est indiff´renci´. e e En−tête ajoutée En−tête automatiquement Données (DATA) du protocole SMTP En−tête ajoutée par l’utilisateur Ligne blanche ajoutée automatiquement Le message Corps (peut être vide) figure X.01 — Format d’un e-mail L’ordre d’apparition de ces champs est quelconque. Seule l’organisation de la figure X.01 doit ˆtre globalement respect´e. Le lecteur soucieux d’une e e description exhaustive de ce en quoi peut ˆtre constitu´ un en-tˆte pourra se e e e repporter au paragraphe 4.1 de la RFC (SYNTAX). Certains champs de l’en-tˆte proviennent de la configuration du MTA, e d’autres sont cr´es en interne par le MTA lui-mˆme, d’autres enfin sont g´r´es e e ee par le MUA, donc accessible ` l’utilisateur final. a 2.1 Quelques champs couramment rencontr´s dans les e en-tˆtes e Type d’information Noms des champs Destinataire(s) du courrier To, Cc, Bcc Origine du courrier From, Reply-To Identification du courrier Message-ID Cheminement du courrier Received, Priority Nature du contenu Content-Transfer-Encoding, Content-Type Divers Date, Subject Champs ´tendus e X-
  • Quelques champs couramment rencontr´s dans les en-tˆtes e e 193To (The primary recipients) Il s’agit du (des) destinataire(s) principaux du message (“ recipient ”). Ce champ peut ´ventuellement ˆtre vide, e e le MTA prend alors une d´cision param`trable pour le compl´ter. La e e e valeur undisclosed-recipient : ; est courante dans ce cas.Cc (Carbon copy) Ce champ est dans le fonctionnement un doublon de To, mais l’usage en nuance le sens : c’est une copie pour information qui est transmise au(x) destinataire(s) list´(s). eBcc (Blind carbon copy) Une copie du message est transmise au(x) des- tinataire(s) list´(s), sans que les destinaitaires principaux des champs e To et Cc en soit inform´s. eFrom (The sender) il s’agit de l’´metteur du message. Le plus souvent e il s’agit d’une seule personne, quand ce champ en liste plusieurs (le s´parateur est la virgule “ , ”) le champ Sender doit pr´ciser l’adresse e e de celui qui a effectivement envoy´ le message. eReply-To (Alternative reply address) Ce champ pr´cise une adresse al- e ternative ` celle du champ From pour l’envoi de la r´ponse. Cette a e disposition est utilis´e par les robots de gestion des mailing-list, pour e distinguer l’auteur du message et le destinataire de la r´ponse. eMessage-ID (Unique identifier for message) Ce champ est cens´ iden- e tifi´ de mani`re unique le message. Il est fabriqu´ d`s sa soumission au e e e e premier MTA (MSA). Il est constitu´ traditionnellement de la mani`re e e suivante : nombre de secondes.identificateur de queue@domaine nombre de secondes Correspond ` la date courante en secondes cal- a 8 cul´es depuis le 01/01/1970 e identificateur de queue Identifie la queue locale sur laquelle ce mail est d´pos´ en entr´e. e e e domaine C’est le domaine d’´mission du message. e Exemple : Message-ID: <20051104121857.GC44788@laissus.fr>Received (Trace routing of mail) C’est une trace du routage suivi par le message, depuis sa soumission jusqu’` sa d´livrance finale. Chaque a e MTA ajoute un champ de ce type. Le cheminement est ` suivre en a commen¸ant en fin de l’en-tˆte. c e Chaque champ est constitu´ au minimum de from, le nom canonique e de la machine de qui le MTA a re¸u le message, de by le nom canonique c du MTA qui a re¸u le message et ajout´ ce champ et enfin de la date c e de la transaction. 8 “ Epoch ” pour les unixiens !
  • 194 Courrier ´lectronique e Exemple : Received: from mailhost.sio.ecp.fr (mailhost.sio.ecp.fr [138.195.52.34]) by leopard.ecp.fr (Postfix) with ESMTP id A6C1D37C91 for <fr.laissus@laissus.fr>; Thu, 3 Nov 2005 13:56:58 +0100 (CET) Priority (Determine timeouts in the queue) En fonction d’une valeur qui est urgent, normal ou non-urgent les messages qui ne peuvent ˆtre d´livr´s imm´diatement sont plac´s dans une file d’attente dont la e e e e e date d’expiration est d’autant plus courte que le message est urgent. L’´metteur du message re¸oit d’abord un avertissement puis une erreur e c si le message n’est pas d´livr´ quand arrive la date d’expiration. e e Content-Transfer-Encoding (Auxiliary MIME encoding) Indique comment est encod´ le corps du message pour supporter les caract`res e e hors jeu ascii 7 bits (SMTP ne transporte que des caract`res 7 bits). e Des valeurs courantes sont base64, quoted-printable, 8bit,.... Content-Type (The nature of the body of the message) Ce champ indique comment est constitu´ le corps du message. Par d´faut il est e e suppos´ ˆtre constitu´ que de caract`res 8 bits dont le bit de poids fort ee e e est sans signification (7 bits effectifs). Pour ´crire e les caract`res e accentu´s e du fran¸ais, c par exemplen il faut avoir un champ de cette forme Content-Type: text/plain; charset=ISO-8859-1 Dans ce cas, le corps du message ne contient que du texte. Le cas contraire est celui d’un message qui contient des pi`ces jointes, une e balise introduite en suppl´ment dans l’en-tˆte va servir ` s´parer les e e a e diff´rentes parties du message comme dans : e Content-Type: multipart/mixed; boundary="opJtzjQTFsWocga" La chaine “ opJtzjQTFsWocga ” sert alors de marqueur pour rep´rer e chaque partie du mail (corps du message et pi`ces jointes). e Date (The origin date) C’est la date ` laquelle le message a ´t´ envoy´ a ee e initialement. Ce champ est obligatoire. Subject (Topic of the message) C’est une courte chaˆ de caract`res ıne e qui r´sume le message. Les MUA montre ce champ pour permettre une e meilleure s´lection des messages avant de les lire. e MIME-Version (This message conforms to MIME standards) Ni- veau de MIME pour l’encodage du corps de message (voir page 197). X- C’est un en-tˆte sp´cifiquement ajout´ par le MUA ou par un processus e e e de la chaˆ de traitement du courrier. Un exemple parmi tellement ıne d’autre : X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 Ajout´ par un m´canisme ext´rieur au MTA, qui agit contre le spam, e e e et nomm´ le Greylisting9 e 9 http://projects.puremagic.com/greylisting/whitepaper.html
  • 3 Protocole SMTP - RFC 821 1953 Protocole SMTP - RFC 821 Le protocole SMTP, ou “ Simple Mail Transfer Protocol ” a comme objetle transport du courrier ´lectronique de mani`re fiable et efficace. Il est d´fini e e edans la [RFC 821] de Jonathan B. Postel. Ind´pendant par sa conception d’un quelconque sous-syst`me de trans- e eport, il est principalement aujourd’hui encapsul´ dans des paquets TCP ` e adestination du port 25 (cf le fichier /etc/services). Dans un pass´ pas si loin- etain l’acc`s r´seau de beaucoup de sites se r´sumait au courrier ´lectronique e e e eencapsul´ dans des trames du protocole UUCP10 , donc sur liaison s´rie via e emodem !3.1 Protocole SMTP SMTP est un protocole ASCII (7 bits, “ human readable ”). La partiecliente de la transaction se connecte sur le port 25 du serveur et envoiedes commandes auxquelles le serveur r´pond par des codes num´riques qui e eindiquent le statut de la prise en compte de la commande. C’est pourquoi il est ais´ de se connecter sur un MTA avec un simple e 11telnet :$ telnet localhost 25Connected to localhost.Escape character is ’^]’.220 host.mondomain.fr ESMTP Sendmail 8.12.6; Mon, 20 Jan 2003 15:34:45 +0100 (CET)NOOP250 2.0.0 OKQUIT221 2.0.0 host.mondomain.fr closing connectionConnection closed by foreign host. Dans cet exemple le MTA est le programme Sendmail 12 , qui r´pond ` la e aconnexion par un code 220 pour dire que le service est op´rationnel (“ service eready ”), suivi du nom de la machine, de la banni`re du programme, de la eversion de sa configuration, et de sa date courante. Puis l’utilisateur a tap´ la commande NOOP qui n’a d’autre effet que de eforcer le serveur ` r´pondre et renvoyer un code (250) pour dire que tout va a ebien. Enfin L’utilisateur a tap´ QUIT pour finir proprement la transaction. La er´ponse du serveur est un code 221 pour signifier la fin canonique de la econnexion. 10 http://fr.wikipedia.org/wiki/Unix_to_Unix_Copy_Protocol 11 Attention toutefois de ne pas abuser de cette pratique car de nombreuses attaques desites ont d´marr´ par le pass´ ` l’aide un d´tournement de sendmail. Les administrateurs e e ea er´seaux sont donc attentifs au trafic sur le port 25 ; il est pr´f´rable de r´server ce genre e ee ede tests uniquement sur son propre site. 12 http://www.sendmail.org/
  • 196 Courrier ´lectronique e Dans un deuxi`me essai nous utilisons l’option -v du programme mail, e pour visualiser les ´changes entre le MUA (machine athome.mondomain.fr) e et le MTA local (machine mailhub.mondomain.fr). Essayons : $ sendmail -v user@mondomain.fr Subject: test Ca passe ? . <<<--- A taper pour marquer la fin du mail dans ce mode. EOT user@mondomain.fr... Connecting to mailhub.mondomain.fr. via relay... 220 mailhub.mondomain.fr HP Sendmail (1.37.109.4/user-2.1) ready at Mon, 26 Jan 98 14:08:57 +0100 >>> HELO athome.mondomain.fr 250 mailhub.mondomain.fr Hello athome.mondomain.fr, pleased to meet you >>> MAIL From:<user@mondomain.fr> 250 <user@mondomain.fr>... Sender ok >>> RCPT To:<user@mondomain.fr> 250 <user@mondomain.fr>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 Ok user@mondomain.fr... Sent (Ok) Closing connection to mailhub.mondomain.fr. >>> QUIT 221 mailhub.mondomain.fr closing connection Et le courrier re¸u, lu aussi avec mail : c Message 208/208 User Lambda Jan 26, 98 02:09:06 pm +0100 From user@mondomain.fr Mon Jan 26 14:09:08 1998 Received: from mailhub.mondomain.fr by athome.mondomain.fr with SMTP (8.8.7/8.8.7/f la.2.1) id OAA27655; Mon, 26 Jan 1998 14:09:08 +0100 (CET) Received: from athome.mondomain.fr by mailhub.mondomain.fr with SMTP (1.37.109.4/fl a-2.1) id AA06996; Mon, 26 Jan 98 14:08:57 +0100 From: User Lambda <user@mondomain.fr> Received: by athome.mondomain.fr Date: Mon, 26 Jan 1998 14:09:06 +0100 (CET) Message-Id: <199801261309.OAA27653@athome.mondomain.fr> To: user@mondomain.fr Subject: test Ca passe ? Manifestement, ¸a passe ! :) c Il est ´galement int´ressant d’observer ` ce niveau que les caract`res du e e a e courrier ont ´t´ consid´rablement enrichis par un en-tˆte volumineux (rela- ee e e tivement). En effet, chaque nœud travers´ (MTA), ajoute un champ “ Received ” e permettant apr`s coup de suivre le trajet du courrier. Les autres champs e
  • Protocole SMTP 197comme Date :, Subject : ou Message-Id : sont ajout´s dans l’en-tˆte par e ele MUA de l’´crivain du message. e Cette partie de l’en-tˆte ajout´e par le MUA d’origine est souvent des- e etin´e ` piloter le comportement du MUA du destinataire du message plus e aque pour ˆtre lue. Cette attitude s’est g´n´ralis´e au point de devenir assez e e e ecompliqu´e et ˆtre formalis´e dans un ensemble de r`gles baptis´es MIME e e e e ecomme “ Multipurpose Internet Mail Extensions ” ([RFC 2184]). La fonction la plus r´pandue et la plus simple de MIME est d’autoriser el’usage des caract`res accentu´s (codage sur 8 bits ou plus) ` l’int´rieur du e e a ecorps du message (l’en-tˆte SMTP reste cod´e sur 7 bits). L’utilisateur voit e ealors apparaˆ des lignes suppl´mentaires comme celles-ci : ıtre eX-Mime-Autoconverted: from 8bit to quoted-printable by bidule.domain id SAA23150X-MIME-Autoconverted: from quoted-printable to 8bit by mamachine.ici id QAA29283 Le “ quoted-printable ” est une forme possible du codage des caract`res eaccentu´s, d´finie dans la [RFC 822]. Le plus souvent on trouve des lignes e ecomme celles-ci : Mime-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfert-Encoding: quoted-printable Content-ID: Content-ID: <Pine.FBSD.3.14.1592654.19971998X.domain> Content-Description: arlg.c D’autres formes de MIME peuvent conduire ` l’ex´cution d’un pro- a egramme ext´rieur au MUA, ce qui constitue une dangereuse faille potentielle edans la s´curit´ des r´seaux, donc ` ´viter. e e e ae3.2 Principales commandes de SMTP Exp´rimentalement nous avons d´couvert quelques uns des mots r´serv´s e e e edu protocole : HELO, MAIL, RCPT, DATA, QUIT. Une impl´mentation mini- emale de SMTP en comprend deux autres en plus : RSET et NOOP. C’est doncun protocole assez simple, du moins dans sa version de base. Les codes de retour sont organis´s sur trois chiffres, le premier chiffre edonne le sens g´n´ral de la r´ponse, tr`s succintement ce qui d´bute par 1,2 e e e e eou 3 a une signification positive, 4 ou 5 signifie une erreur. Une informationplus d´taill´e se trouve ` l’annexe E de la RFC. e e a Les cinq commandes d´couvertes pr´c´dement s’utilisent toujours dans e e ecet ordre. Examinons succintement leur usage :3.2.1 Commande HELOSynopsis : HELO <espace> <domaine> <CRLF> Cette commande est utilis´e pour identifier l’´metteur du mail. L’argu- e ement qui suit, domain est le nom de la machine ou du domaine d’o` provient ula connexion.
  • 198 Courrier ´lectronique e En r´ponse le serveur envoie une banni`re dans laquelle il s’identifie et e e donne la date courante. Cette information est optionnelle, ce qui compte c’est le code de retour pour confirmer l’aptitude au travail du serveur ! 3.2.2 Commande MAIL Synopsis : MAIL <espace> FROM : <chemin inverse> <CRLF> Cette commande d´bute un transfert de mail. En argument sont transmis e (chemin inverse) l’adresse e-mail de l’´metteur et la liste des machines qui e ont relay´ le mail courant. La premi`re machine est la plus r´cente. Cette in- e e e formation est utilis´e pour renvoyer, s’il y a lieu, une notification de probl`me e e ` l’´metteur du mail. a e Par exemple : MAIL FROM:<@mailhub.ici:@mailhost.labas:Lambda@mondomain.fr> 3.2.3 Commande RCPT Synopsis : RCPT <espace> TO : <destinataire> <CRLF> Cette commande est la deuxi`me ´tape dans la proc´dure d’envoi d’un e e e mail. Il y a une commande de ce type par destinataire du courrier (“ reci- pient ”). Par exemple : RCPT TO:<Lambda@mondomain.fr> Il est int´ressant de noter que les arguments de cette commande et ceux e de la pr´c´dente (MAIL) forment l’enveloppe du mail (exp´diteur et des- e e e tinataire) comme nous en avons signal´ l’existence conceptuelle page 190. e 3.2.4 Commande DATA Synopsis : DATA <CRLF> Apr`s r´ception de la commande, le serveur lit les lignes de texte en pro- e e venance du client jusqu’` rencontrer la s´quence <CRLF>.<CRLF> qui a e marque la fin du message. Il faut remarquer que celui-ci comprend l’int´gralit´ e e de la figure X.01. 3.2.5 Commande QUIT Synopsis : QUIT <CRLF> Marque la fin de la session et entraine la clˆture de la connexion. o
  • Protocole SMTP 1993.3 Propagation du courrier ´lectronique e SMTP est d´fini comme un protocole de transfert, donc un moyen pour erouter et d´livrer le message ` son (ses) destinataire final (finaux). e a MUA LDA utilisateur MTA MTA MSA OS OS SMTP ou ESMTP MUA utilisateur figure X.02 — MUA - MSA - MTA - LDA - OSMUA “ Mail User Agent ” ou encore “ mailer ”, c’est le programme qui permet de lire et ´crire le corps du courrier et de param´trer quelques e e ´l´ments de l’en-tˆte, principalement l’adresse du destinaire, et le sujet ee e du message. Il existe un tr`s grand nombre de MUAs sous Unix, il est cou- e rant de rencontrer mail, mailx, elm, pine, mutt, mh, eudora, kmail, thundermail, sylpheed... Il y en a pour tous les goˆts ! uMSA “ Mail Submission Agent ”, c’est une “ nouveaut´ ” d´finie par la e e [RFC 2476] et qui joue le rˆle d’interface entre le MUA et le MTA. o L’objet du MSA est de s´parer les fonctions de transfert du courrier e et d’acceptation de nouveaux courriers ´mis depuis les MUA. Cette e s´paration des tˆches am´liore deux aspects : e a e La s´curit´ Les nouveaux mails sont soumis ` un daemon qui ne e e a n’ex´cutent pas avec les droits du root13 . e La conformit´ aux standards Les messages proviennent de MUAs e qui ne respectent pas forc´ment tous les pr´requis de formulation e e des en-tˆtes. e Le rˆle du MSA est de v´rifier et de compl`ter ces en-tˆtes avant o e e e de soumettre les mails au MTA pour le routage.MTA “ Mail Transfer Agent ”, c’est le programme que prend en charge le transfert du courrier. Sous Unix c’est un daemon. Par exemple : MMDF, Smail, Zmailer, sendmail, postfix, qmail... 13 SUID bit
  • 200 Courrier ´lectronique e Les MTAs ´coutent le r´seau sur le port 25 et dialoguent entre-eux avec e e le protocole SMTP (ESMTP14 ). LDA “ Local Delivery Agent ”, c’est l’entit´ qui d´livre effectivement le e e mail, soit dans une boite au lettres soit dans une base de donn´es, par e exemple une base Cyrus15 . OS “ Operating System ”, le syst`me d’exploitation sur lequel fonctionnent e ces programmes. La figure X.2 illustre la possibilit´ la plus simple d’´change entre deux e e MTA : la connexion directe. Cela signifie que le MTA de la station ´mettrice e contacte le MTA de la station r´ceptrice et lui d´livre directement le message. e e La vie “ r´elle ” est plus compliqu´e car elle tient compte de l’organisation e e hi´rarchique des r´seaux et surtout de la s´curit´ qui est un aspect devenu e e e e important sur l’Internet. Cela se traduit par un emploi g´n´ralis´ de machines e e e relais ou “ mailhub ”. B@domaine2 MTA MTA ‘‘relay mail’’ Utilisateur A MUA SMTP/ au travail. TCP/IP Station de l’utilisateur A Stockage temporaire tant que le MTA du domaine 2 est inacessible. Wild Internet ! SMTP/ TCP/IP Utilisateur B MUA au travail. MTA ‘‘relay mail’’ MTA Stockage à long Station de l’utilisateur B terme sur le disque dur de la station. Stockage temporaire tant que la station de B est inacessible. figure X.03 — Trajet d’un mail Une telle machine concentre tous les courriers ´lectroniques d’un site, vers e l’ext´rieur et inversement. Elle a des avantages, notamment : e 14 Extented SMTP 15 http://asg.web.cmu.edu/cyrus/
  • Courriers ind´sirables - Le spam e 201 ◦ Avoir une politique de s´curit´ concentr´e sur un petit nombre de ma- e e e 16 chines expos´es , plutˆt que sur toutes les stations du r´seau : le rou- e o e teur filtrant n’autorise les acc`s ext´rieurs que sur le port smtp(25) de e e ces quelques machines d´di´es. e e ◦ Avoir une politique centralis´e pour le filtrage des contenus ind´sirables e e (virus) et des ´metteurs suspects (spams). e ◦ Limiter le nombre de configurations compliqu´es de sendmail ` un pe- e a tit nombre de machines. Les stations des utilisateurs peuvent se conten- ter d’une configuration standard plus facile ` distribuer et ` adapter a a automatiquement. ◦ Permettre de masquer plus facilement les machines internes du r´seau e vis ` vis de l’ext´rieur. En clair, les courriers auront l’air de provenir a e de cette machine plutˆt que de la station d’un utilisateur sur le r´seau o e interne. L’adresse de l’´metteur aura la forme : e user@domaine au lieu de : user@machine.domaine. ◦ Permettre le stockage interm´diaire du courrier en attente d’une e d´livrance : les stations des utilisateurs ne sont pas toujours en fonc- e tionnement. Cette architecture est th´orique, en pratique il peut y avoir une hi´rarchie e ede “ relay mail ” plus compliqu´e. Par exemple une grappe de machines edistinctes suivant que le courrier entre ou sort du site, une arborescence demachines relais quand l’entreprise est elle-mˆme r´partie sur plusieurs sites e eg´ographiques et ne poss`de qu’une liaison vers l’ext´rieur,. . . e e e3.4 Courriers ind´sirables - Le spam e Le spam est l’aspect tr`s d´sagr´able du courrier ´lectronique. e e e e Par “ spam ” on d´signe ces innombrables courriers, le plus souvent ` e acaract`re commercial, qui envahissent nos boites aux lettres ´lectroniques. e eCertaines estimations tablent sur au moins 30% de spam dans le trafic mailmondial et cette estimation est r´guli`rement revue ` la hausse. e e a Deux questions se posent, comment le caract´riser et surtout comment el’´viter ? e3.4.1 Caract´riser le spam e 1. Un contenu commercial, publicitaire, financier, ou qui tente de retenir l’attention du lecteur ` partir d’une histoire dont l’issue est toujours a p´cuniaire et au d´triment du destinataire. e e 16 Ce qui n’exclue pas bien entendu d’avoir une politique de s´curit´ pour le mail sur le e er´seau interne e
  • 202 Courrier ´lectronique e 2. Une importante liste de destinataires. Le champ Cc : peut contenir par exemple des centaines de destinataires. 3. Un en-tˆte de message truqu´. Par exemple le champ Message-ID : e e qui est cens´ identifier le message de mani`re unique est absent ou e e incoh´rent (page 193). e 4. Un grand nombre d’exemplaires du mˆme message envoy´ dans un court e e laps de temps. Cette caract´ristique ne concerne pas le contenu du mail e mais la mani`re avec laquelle il est envoy´. C’est le MTA qui re¸oit les e e c demandes de connexions qui peut d´tecter cette caract´ristiques. e e 5. Utilisation de l’adresse d’un destinataire sans son consentement expli- cite pour ce type d’envoi. 6. Usage d’un site “ open mail relay ” pour l’´mission. L’´metteur du mail e e peut alors usurper le nom du domaine d’´mission. e Pour m´moire, un site “ open mail relay ” autorise un RCPT qui ne e d´signe pas un destinataire pour lequel la d´livrance des mails est au- e e toris´e sur ce site. Le site sert alors en quelque sorte de tremplin pour e le mail, avec un effet de dissimulation du site ´metteur v´ritable. Les e e versions modernes des MTA interdisent cette possibilit´ par d´faut. e e 7. Champs To et From de l’en-tˆte invalides e Comme par exemple l’utilisation comme adresse e-mail d’origine du mail celle d’un utilisateur n’ayant strictement rien ` voir avec le message a (c’est l’enveloppe qui compte pour la d´livrance du mail). e 8. Le contenu du mail contient un virus, soit dans le corps du message soit dans une pi`ce jointe. Par abus ce genre de mail est parfois trait´ e e comme du spam. 3.4.2 ´ Eviter le spam C’est une question ouverte. . . S’il est ´vident que l’œil humain reconnait un tel courrier de mani`re e e quasi infaillible, il n’en est pas de mˆme pour la machine. e Il n’existe pas de m´thode de lutte unique et infaillible. Un bon r´sultat e e (plus de 99% du trafic de spam bloqu´) peut cependant ˆtre atteint en pas- e e sant par l’usage d’une palette d’outils et de dispositifs ext´rieurs. Toutefois e l’ensemble de ce dispositif a un coˆt non n´gligeable en terme de cycles cpu u e consomm´s pour un mail d´livr´, d’une part, et d’autre part en terme de e e e coˆt de maintenance car l’architecture logicielle qui en d´coule est complexe u e et demande du temps de sp´cialiste de bon niveau pour sa maintenance. e Tout d’abord, une bonne partie de l’origine du spam vient du fait que le protocole SMTP lui-mˆme est beaucoup trop permissif. e Con¸u ` une ´poque o` le r´seau ´tait constitu´ sur la base de la confiance c a e u e e e et de la collaboration entre sites honorables, il n’est plus adapt´ ` ce qu’est ea devenu le r´seau. La faille la plus navrante est que l’enveloppe transmise lors e
  • Courriers ind´sirables - Le spam e 203de l’´change protocolaire n’est pas n´cessairement identique ` ce qui figure e e adans l’en-tˆte du mail. L’exemple qui suit illustre cette faille : etelnet mailhost.mondomain.fr 25Connected to mailhost.mondomain.fr.Escape character is ’^]’.220 mailhost.mondomain.fr ESMTPHELO UnSiteQuelconque.com250 mailhost.mondomain.fr Hello UnSiteQuelconque.com, pleased to meet youMAIL From:<>250 2.1.0 <>... Sender okRCPT To:<lambda@mondomain.fr>250 2.1.5 <lambda@mondomain.fr>... Recipient okDATA354 Enter mail, end with "." on a line by itselfFrom:<NePasRepondre@XXX.com>To:<TuPeuxToujoursEssayer@YYY.com>Unsollicited Bulk Email (UBE) orUnsollicited Commercial Email (UCE).. Et le mail sera d´livr´ dans la boite aux lettres de l’utilisateur “ lambda ” e eavec des champs From : et To : compl`tement inexploitables ! e Pour ´viter la d´livrance de ce mail, la configuration du MTA de e emondomain.fr pourrait mettre en place une protection agissant en troistemps : lors de l’´tablissement de la connexion, lors de la r´ception e ede l’enveloppe puis ` la r´ception du message lui-mˆme. a e e Le protocole SMTP ne comprend pas d’accus´ de r´ception. Si l’honnˆte e e eutilisateur de ce protocole envoie un courrier rout´ silencieusement, par er- ereur, dans une boite aux lettres de courriers ind´sirables (en g´n´ral non lus e e eet souvent supprim´s automatiquement), c’est regrettable et d’autant plus epr´judiciable que le contenu du mail est important. Il est donc bien plus effi- ecace de refuser le message tant que la connexion avec le MTA qui l’´met est emaintenue, car quel que soit le contenu de l’enveloppe (les Reply-to et Fromsont peut ˆtre faux ou inexistants), le MTA qui route ce mail est ` l’autre e about de la connexion et est suppos´, par construction, ˆtre le mieux plac´ e e epour pr´venir l’auteur du mail que la transaction actuelle est refus´e. e e Autrement dit, il est bien pr´f´rable d’effectuer le tri en temps r´el plutˆt ee e oqu’en temps diff´r´ lors de la d´livrance dans la boite de l’utilisateur ou apr`s ee e erapatriement (voir page 210) des mails par son MUA. Si l’origine du mail est honnˆte, l’´metteur sera tout de suite pr´venu e e e(mail d’erreur) et pourra agir en cons´quence, dans le cas contraire le spam- emeur r´ceptionnera autant de messages d’erreurs que de spams envoy´s (un e erˆve. . .) ce qui ne manquera pas de le gˆner consid´rablement. Nous ne le e e eplaindrons pas.
  • 204 Courrier ´lectronique e ` e A l’´tablissement de la connexion le MTA peut v´rifier que le taux de e demandes de connexions n’exc`de pas un certain ratio (par exemple e pas plus de 30 connexions TCP par minutes). Les ´l´ments de la connexion (voir page 90) fournissent l’adresse IP et ee le port d’origine. L’adresse IP doit pouvoir ˆtre r´solue dans le tld in-addr.arpa, le cas e e contraire est r´dhibitoire. e L’adresse IP peut ˆtre tout simplement r´fut´e localement, tout comme e e e le domaine (au sens du DNS). L’adresse IP peut ˆtre ´galement r´fut´e apr`s interrogation des e e e e e DNSBL (“ Domain Name Services BlackList ”) qui sont des bases de donn´es de sites reconnus comme ´tant ` l’origine de spams ou connus e e a comme “ open mail relay ”. ` A la r´ception de l’enveloppe le MTA peut demander une authentifica- e tion de l’´metteur (login et mot de passe) du mail. e Le MTA peut ´galement consulter une base locale de champs From et e To refus´s.e Il existe un m´canisme assez ing´nieux et r´cent, nomm´ le “ GreyLis- e e e e ting17 ” qui stoppe bon nombre de spams en sp´culant sur le fait que les e spammeurs sont des gens press´s et que leur mails sont envoy´s en tr`s e e e grand nombre (des centaines de milliers d’unit´s) et le plus vite pos- e sible. En cons´quence, si l’´tablissement du protocole SMTP ne fonc- e e tionne pas du premier coup, la plupart d’entre eux se d´couragent et e ne r´essaient pas (contrairement ` ce que le protocole SMTP pr´voit). e a e Ce dispositif consiste donc ` faire patienter tout le monde (sauf peut a ˆtre une liste d’adresses de correspondants ou de domaines r´put´s e e e fiables) et seuls ceux qui respectent le procotole ` la lettre finissent a par pouvoir transmettre leur mail, d’autant plus que s’ils ont patient´ e une fois ils sont plac´s dans une liste d’acc`s sans d´lai pendant un e e e temps programmable (par exemple 24h). En pratique la connexion est coup´e apr`s ´mission d’un message d’erreur qui invite ` recommencer e e e a ult´rieurement. e ` A la r´ception du corps du mail des filtres peuvent ˆtre appliqu´s sur e e e l’en-tˆte pour en v´rifier la consistance, sur le corps du message pour e e r´agir sur la pr´sence de tels ou tels mots clefs (de tels filtres ont en e e g´n´ral un fonctionnement statistique bas´ sur l’apprentissage d’une e e e base de spams et d’une base de non-spams et sont enrichis conti- nuellement avec les messages ind´sirables) enfin les pi`ces jointes sont e e extraites du courrier et examin´es ` l’aide d’un dispositif de recon- e a naissance des virus (une base de virus doit ˆtre mise ` jour tr`s e a e r´guli`rement). e e 17 http://projects.puremagic.com/greylisting/whitepaper.html
  • 4 Exemple de MTA - “ Sendmail ” et son environnement 2054 Exemple de MTA - “ Sendmail ” et son environnement4.1 Relations avec le DNS Comme nous l’avons ´voqu´ au paragraphe 1.2 page 190, la relation entre e ele MTA et le DNS est ´troite. Sendmail a besoin du serveur de noms pour eles op´rations suivantes : e Qui reçoit le mail pour le domaine D ? Sendmail DNS Voici la liste des machines ayant un RR de type MX pour ce domaine et avec leur préférence respective Échec ! Échec ! Succès ! Sendmail Sendmail Sendmail machineA.domaineD machineB.domaineD machineC.domaineX MTA pouvant récupérer le courrier pour le domaine D figure X.04 — MX primaire et secondaires 1. Transformer le nom de la machine distante en adresse IP 2. Canoniser le nom de la machine locale. 3. Canoniser le nom de la machine qui se connecte 4. D´terminer quelles sont les machines susceptibles de recevoir du cour- e rier pour le domaine ` atteindre. a Le quatri`me point est le plus crucial. Si le DNS du domaine ` atteindre e a(une adresse est toujours mise sous la forme “ nom@domain ”) ne d´signe epas de machine capable de recevoir le courrier, le mail ne passera jamais pource domaine. Le champ RR (“ Resource Record ”) correspondant est du type MX(“ Mail Exchanger ”). Il sp´cifie une liste d’hˆtes pond´r´s par des e o eepr´f´rences, ` qui on peut envoyer du courrier. La pond´ration indique l’ordre ee a e` suivre pour les tentatives de connexions : il faut commencer par la valeurala plus basse. Si cette liste est explor´e de bout en bout sans succ`s il y a e e´chec de la transmission du courrier.e
  • 206 Courrier ´lectronique e S’il y a ´chec de la r´´mission, le mail est conserv´ un certain temps, puis e ee e est finalement rejet´ s’il y a persistance de l’´chec. Le r´sultat est mat´rialis´ e e e e e dans un fichier nomm´ dead.letter e Figure X.4, Le contenu du champ RR renvoy´ par le DNS pourrait avoir e la constitution suivante : ; ;[name] [ttl][class] MX preference mail exchanger ; domaineD IN MX 10 machineA.domaineD IN MX 20 machineB.domaineD IN MX 30 machineC.domaineX Il est important de remarquer qu’une machine baptis´e “ MX ” par le e DNS n’est pas forc´ment localis´e dans le domaine pour lequel elle re¸oit le e e c courrier, c’est mˆme souvent le cas pour les machines “ relay ”. C’est le cas e de la troisi`me ligne, machineC.domaineX e 4.2 Relations avec le syst`me d’exploitation e Sendmail a de multiples relations avec le syst`me d’exploitation. La figure e X.5 en fait un r´sum´ : e e UUCP X.400 SMTP/ESMTP syslogd Outil externe pour délivrer le (gestion des logs) mail aux utilisateurs Programme(s) Sendmail externe(s) de traitement (avant Socket locale (UNIX) la délivrance) Fichiers de configuration : $HOME/.forward /etc/mail/sendmail.cf /etc/mail/submit.cf /var/mail/userX /etc/mail/aliases /etc/mail/access /etc/mail/local−host−names /etc/mail/mailertable /etc/mail/virtusertable File d’attente des messages en /etc/mail/userdb /var/spool/mqueue figure X.05 — Relation entre Sendmail et le syst`me d’exploitation e L’activit´ op´rationnelle de sendmail est consign´e ` l’aide de syslog18 , e e e a ce qui explique la pr´sence de la ligne suivante trouv´e dans le fichier e e /etc/syslog.conf : mail.info /var/log/maillog 18 ´e Chapitre III du cours de programmation — El´ments de serveurs
  • Relations avec le syst`me d’exploitation e 207UUCP, X.400, SMTP Sont autant de moyens de propager le courrier. Ces sup- ports peuvent cohabiter au sein d’une mˆme configuration ; autant de e “ Mailer ” s´lectionn´s en fonction de l’adresse du destinataire (cf e e sendmail.cf)./etc/mail/sendmail.cf Est le fichier de configuration de sendmail qui fonctionne en tant que MTA. Sa pr´sence est indispensable. e La configuration standard livr´e est en g´n´rale ` adapter aux e e e a imp´ratifs de fonctionnement du r´seau local. Voir ` ce propos le para- e e a graphe 5 page 212./etc/mail/submit.cf Est le fichier de configuration de sendmail en tant que MSA. Sa pr´sence est optionnelle si le fichier pr´c´dent indique e e e explicitement le contraire./etc/mail/aliases est une base de synonymes. Quand sendmail re¸oit un c courrier, il tente de reconnaˆ le nom du destinataire dans cette base ıtre et si c’est le cas de lui appliquer la transformation prescrite. Un certain nombre d’alias sont requis par la [RFC 1123], d’autres sont conseill´s par la [RFC 2142]. Un court extrait du-dit fichier : e # Basic system aliases -- these MUST be present MAILER-DAEMON: postmaster postmaster: root # Well-known aliases -- these should be filled in! root: user info: root marketing: root sales: root support: root www: webmaster webmaster: root ... Cela signifie par exemple que chaque fois q’un courrier est envoy´ au e “ postmaster ” de ce site, sendmail transforme “ postmaster ” en “ root ”, puis “ root ” en “ user ”. Si cette derni`re chaˆ ne fait e ıne pas l’objet d’une autre transformation par cette table, il s’agit d’un utilisateur de la machine courante. L’entretien de la table des alias est de la responsabilit´ de l’admi- e nistrateur de la machine. La table des alias d’un domaine est un fi- chier strat´gique qu’il convient de mettre ` jour soigneusement (droits e a d’acc`s, utilisateurs inexistants, boucles. . .). e ` A chaque changement dans cette table l’administrateur doit fabriquer une table d’acc`s rapides (“ hash table ”) ` l’aide de la commande e a “ sendmail -bi ” souvent li´e ` “ newaliases ” e a/etc/mail/access C’est un fichier qui regroupe des autorisations sp´cifiques d’acc`s ou de rejet des mails entrants. Par exemple : e e
  • 208 Courrier ´lectronique e MonNouveauDomain.tld RELAY Connect:microsoft.com REJECT Acceptera de relayer tout mail pour le domaine MonDomain.tld mais rejetera tout mail en provenance du domaine suivant. /etc/mail/local-host-names Ce fichier collecte tous les noms sous lesquels la machine qui ex´cute le MTA est connue ce qui ´vite que celui rejette e e le mail en refusant de le relayer. /etc/mail/mailertable Un MTA peut accepter d’effectuer le routage du courrier pour un grand nombre de domaines. Ce fichier permet d’effec- tuer un routage en fonction du domaine, par exemple : un.autre.domain.tld smtp:autre.machine.tld mon.domain.a.moi local: /etc/mail/virtusertable Ce fichier permet d’effectuer des r´´critures ee d’adresses d’un domaine vers un autre domaine avec plus de possibilit´s e d’expression que le fichier des aliases. Par exemple : @MonAncienDomaine.tld %1-old@MonNouveauDomaine.tld webmaster@MonNouveauDomaine.tld wbm-new@AutreDomaine.tld Dans la premi`re ligne le %1 est remplac´ dynamiquement par tout e e ce qui pr´c`de le @ de @MonAncienDomaine.tld ce qui permettra par e e exemple d’effectuer un tri au moment de la d´livrance des messages, e entre ceux envoy´s pour le nouveau domaine et l’ancien. e /etc/mail/userdb Cette table, “ User Database ” permet au sendmail d’ef- fectuer une traduction de chaˆ sur les noms des utilisateurs pour ıne les courriers sortants. Cette disposition permet de traduire un nom de login en “ Prenom.Nom ”, donc d’avoir une adresse de retour de la forme “ Prenom.Nom@domaine ” ce qui fait toujours plus chic ! /var/spool/mqueue Dans ce r´pertoire sont stock´s les mails en attente e e d’une d´livrance. Il peuvent y rester plusieurs jours (c’est un param`tre e e de la configuration du sendmail), on peut visualiser cette file d’attente avec la commande mailq. Si un grand nombre de courriers sont en attente, et ¸a peut ˆtre le c e cas pour les machines relais, la section du disque dur qui supporte cette partition (ici /var) doit faire l’objet d’un dimensionnement en cons´quence, sous peine d’obliger sendmail ` refuser les mails faute de e a place disque. /var/mail/userX Chaque utilisateur de la machine locale (il peut ne pas y en avoir sur un serveur) a une boˆ aux lettres (“ mail box ”) ıte rep´r´e comme un fichier ayant comme nom son login. Par exemple ee /var/spool/mail/root. Ce fichier est mis ` jour automatiquement par le MTA local en cas a d’arriv´e de courrier. e
  • Relations avec le syst`me d’exploitation e 209 De mˆme que pour le r´pertoire de file d’attente, le r´pertoire des boˆ e e e ıtes aux lettres des utilisateurs doit faire l’objet d’une attention particuli`re e de la part de l’administrateur ; la prolif´ration des “ documents at- e tach´s ” aux courriers ´lectroniques est un fl´aux contre lequel il est e e e difficile de se pr´munir sauf ` agrandir perp´tuellement la taille de la e a e partition /var. . . ! :(${HOME}/.forward Avant d’ˆtre finalement d´livr´ dans la boˆ aux lettres e e e ıte de l’utilisateurs, sendmail lit le contenu de ce fichier, ${HOME} ´tant le e r´pertoire racine des fichiers de l’utilisateur en question. e Le fichier .forward est la base personnelle d’alias pour chaque utilisa- teur, ¸a permet de renvoyer son courrier vers d’autres sites, voire aussi c d’effectuer des transformations avant de stocker les mails (procmail). Si le .forward contient la chaˆ suivante : moi@ailleurs.tld Tous les ıne courriers envoy´ ` cette utilisateurs sont renvoy´s ` l’adresse indiqu´e. ea e a e Ou encore : "|exec /usr/local/bin/procmail" Qui permet d’invoquer l’usage du programme procmail, celui-ci est un tr`s puissant filtre qui permet de faire un tri des courriers ´lectroniques e e avec des expressions r´guli`res (indispensable pour g´rer de multiples e e e abonnements ` des “ mailing-lists ”). Par exemple, avec la configuration a virtusertable ci-dessus, pour forcer la d´livrance des mails adress´s e e ` @MonAncienDomaine.tld dans un fichier sp´cial plutˆt que la boite a e o par d´faut, on pourrait ´crire un fichier .procmailrc de configuration e e contenant les lignes suivantes : :0 H: * ^To[ :]+.*-old@MonNouveauDomaine.tld ${HOME}/Mail/RougnesSocket locale Sendmail peut communiquer avec des programmes ext´rieurs e par le biais d’une socket locale (UNIX). Le dialogue est facilit´ par une e biblioth`que nomm´e MILTER19 li´e ` sendmail lors de sa compilation. e e e a L’id´e est qu’il est plus int´ressant de refuser ´ventuellement un mail e e e d`s que les premiers ´l´ments du protocole SMTP (ou ult´rieurement en e ee e examinant le corps du message) sont connus, plutˆt que d’attendre que o la connexion soit close et que le mail soit d´livr´. De ce fait, l’´metteur, e e e quel qu’il soit (honnˆte utilisateur ou spammeur) sera imm´diatement e e pr´venu que son mail est refus´ et pourra agir en cons´quence. e e e De nombreux outils sont capable de fonctionner avec sendmail et son interface MILTER, liste non exhaustive : MIMEDefang20 , Clamav21 , milter-greylist22 ,. . . 19 http://www.milter.org 20 http://www.mimedefang.org/ 21 http://www.clamav.net/ 22 http://hcpnet.free.fr/milter-greylist/
  • 210 Courrier ´lectronique e Outil externe de d´livrance Le message prˆt ` ˆtre d´livr´ est confi´ par e e ae e e e sendmail aux bons soins d’un programme ext´rieur. Si la d´livrance e e s’effectue dans une boite aux lettres unix (un fichier au format mailbox qui porte comme nom le login de l’utilisateur et est situ´ g´n´ralement e e e dans le r´pertoire /var/mail/), ce programme se nomme local.mail e en standard. Il peut ˆtre remplac´ par d’autres, notamment par le e e programme procmail d´j` cit´, si on souhaite effectuer un filtrage ea e suppl´mentaire ` ce niveau du traitement, par exemple pour mettre e a dans une boite aux lettres sp´ciale les mails consid´r´s comme ´tant du e ee e spam en laissant ` l’utilisateur le soin de les d´truire par lui-mˆme. a e e Enfin on peut remarquer qu’aucun signal n’est pr´vu pour indiquer ` e a sendmail qu’il faut relire son fichier de configuration, c’est voulu par le concepteur. Lors de la mise au point de ce fichier, il faut arrˆter puis le e 23 relancer manuellement . 4.3 Le cas de POP POP est l’acronyme de “ Post Office Protocol ”, il permet l’acc`s ` un e a serveur de courrier depuis des clients PC sous Windows, voire mˆme des e stations unix distantes, par exemple via ppp, qui ne sont pas configur´es e pour faire un trafic SMTP entrant. POP dans sa version 3 est d´fini par la e [RFC 1939]. Envoi : SMTP Serveur POP Client POP MTA Popd MUA SMTP Lecture: POP3 Boite aux lettres de l’utilisateur (mail box) figure X.06 — Le cas de POP Les clients POP sont l´gions sur les PCs et sur les stations de travail sous e Unix. Pour celles-ci citons : kmail24 , mh, pine, elm, mutt, gnus pour emacs, ou encore sylpheed et thunderbird. La liste n’est pas exhaustive, loin s’en faut. 23 Par exemple sur une machine NetBSD/FreeBSD en tapant /etc/rc.d/sendmail restart 24 De l’environnement de bureau KDE - http://www.kde.org/
  • Relations avec le syst`me d’exploitation e 211 POP est un protocole tr`s simple qui fonctionne parfaitement mais qui en’est pas d´nu´ de d´fauts : e e e 1. L’authentification (login/password) est bien souvent ´chang´e en e e “ clair ” sur le r´seau e 2. Sur l’architecture Unix, l’utilisateur doit avoir un compte sur la ma- chine serveur (Une base de donn´es des utilisateurs est toutefois pos- e sible) 3. Les messages doivent ˆtre r´cup´r´s sur le poste client pour ˆtre mani- e e ee e pul´s (en POP3 un double peut rester sur le serveur) e 4. La boite aux lettres ne peut ˆtre consult´e que par un seul client ` la e e a fois Ces points deviennent vite r´dhibitoires quand le poste client doit acc´der e eau serveur au travers d’un r´seau non sˆr, et surtout lorsque le d´tenteur de e u ela boite aux lettres veut consulter ses mails depuis des postes diff´rents. Ce ecas de figure est de plus la r´alit´ de toute personne qui se d´place et souhaite e e eun contact mail permanent avec ses correspondants. C’est pourquoi d’autres solutions se sont d´velopp´es et sont de plus en e eplus utilis´es : les messageries accessibles via un browser web (webmail), edonc qui utilisent comme support le protocole HTTP (voir page 327), ou unrempla¸ant du procole POP, le protocole IMAP ! c4.4 Le cas de IMAP Bien que largement d´ploy´ que depuis quelques ann´es, le protocole e e eIMAP — “ Internet Message Access Protocol ” — a ´t´ d´velopp´ ` l’univer- ee e easit´ de Stanford en 1986. C’est actuellement la version 4rev1 qui est utilis´e, e ed´finie dans la [RFC 3501]. e L’architecture pr´sent´e figure X.06 reste valable, pratiquement il suffit e ed’y remplacer le mot “ POP ” par “ IMAP25 ” ! Les fonctionnalit´s sont plus riches et surtout pallient aux inconv´nients e elist´s pour POP. En clair, les points n´gatifs list´s pour POP sont tous r´gl´s. e e e e eImap est con¸u pour pouvoir acc´der ` ses boites aux lettres depuis de mul- c e atiples machines, n’importe o` sur le r´seau, alors que POP est plus adapt´ ` u e eaune machine unique.Voici ses objectifs principaux : ˆ 1. Etre compatible avec les standards, MIME par exemple 2. Permettre l’acc`s et la gestion des mails depuis plus d’une machine e 3. Fournir un mode de fonctionnement en-ligne et hors-ligne 4. Supporter les acc`s concourrants aux mˆmes boites aux lettres e e ˆ 5. Etre ind´pendant du stockage des mails (fichiers ou base de donn´es, e e par exemple) 25 Consultez http://www.imap.org/ pour plus d’informations
  • 212 Courrier ´lectronique e Un excellent comparatif des deux protocoles est accessible ici : http://www.imap.org/papers/imap.vs.pop.brief.html 5 Configuration du Sendmail Le programme sendmail s’appuie sur un ensemble de r`gles de e r´´critures (figure X.05 page 206) par d´faut regroup´es dans les fichiers ee e e /etc/mail/sendmail.cf et /etc/mail/submit.cf. La plupart des cas de la vie courante se traitent sans avoir besoin de modifier manuellement ces deux fichiers. L’usage d’un jeux de macros m426 tr`s complet et puissant suffit pour g´n´rer les configurations ci-dessus, apr`s e e e e l’´criture d’un fichier de requˆtes de quelques lignes. M4 g´n`re ensuite les e e e e fichiers attendus ` partir de ces requˆtes, et d’un mod`le (“ template ”) a e e install´ avec le programme sendmail. e Il faut noter qu’un certain nombre d’administrateurs syst`me, form´s ` e e a la “ vieille ´cole ”, aiment bien conserver la maˆ e ıtrise totale de ce qu’ils pro- duisent et pr´f`rent donc ´crire eux-mˆmes manuellement leurs r`gles, ces ee e e e macros ne leur sont donc pas destin´es ! e 5.1 Configuration ` l’aide de M4 a Le point d’entr´e pour utiliser cet outil est une documentation livr´e avec e e la distribution du programme sendmail et nomm´e : e <pr´fixe d’installation>/cf/README e Consid´rons la situation r´seau de la figure X.07. Le courrier au e e d´part de la station, soumis par exemple au MSA local, doit ˆtre rout´ e e e syst´matiquement vers une machine nomm´e mailhub.mondomain.fr, et qui e e concentre tout le trafic local sortant, d’o` d’ailleurs son nom de “ mailhub ”. u Celle-ci est cens´e savoir router le mail qu’elle re¸oit, mais ce n’est pas notre e c pr´occupation ici. e MUA MTA/MSA Poursuite du trajet du mail après décision de routage Station MTA Trajet du mail sortant de Serveur local la station. ou ‘‘ mailhub ’’ 26 Macro processeur bien connu dans le monde Unix
  • Configuration du Sendmail 213 figure X.07 — Concentration du mail sur un “ mailhub ” Le fichier de configuration pour la station pourrait ˆtre : e 1 divert(0) 2 VERSIONID(‘mondomain−fla−04−05−2005’)dnl 3 OSTYPE(freebsd5)dnl 4 define(‘confSMTP_LOGIN_MSG’,‘$j −−− STATION LAMBDA −−− $b’)dnl 5 dnl 6 FEATURE(always_add_domain)dnl 7 MASQUERADE_AS(mondomaine.fr)dnl 8 FEATURE(allmasquerade)dnl 9 dnl 10 define(‘MAIL_HUB’,‘smtp:mailhub.mondomain.fr.’)dnl 11 define(‘SMART_HOST’,‘smtp:mailhub.mondomain.fr.’)dnl 12 dnl 13 MAILER(smtp)dnlEt ce fichier (config.mc) est utilis´ de cette mani`re : e e m4 m4/cf.m4 config.mc > sendmail.cf Pour g´n´rer en final le fichier attendu, dont le nombre de lignes exc`dent e e e1400 ! Il faut noter que le MSA se configurent de mani`re similaire, ` partir e ade son propre fichier de configuration.Ligne 1 C’est la d´finition d’un canal de sortie pour m4 (cf man m4). eLigne 2 C’est une ´tiquette (“ tag ”) ins´r´e dans le fichier g´n´r´ et qui e ee e ee servira ` l’identifier, par exemple avec la commande ident si l’´tiquette a e est un identifiant de rcs ou cvs. Remarque : dnl est un mot clef de m4, au mˆme titre que divert, et e qui signifie qu’on peut ignorer (discard) tous les caract`res jusqu’au e prochain retour ` la ligne (nl). aLigne 3 C’est un identifiant du syst`me d’exploitation pour que m4 puisse e faire les choix adapt´s (choix des chemins standards par exemple). eLigne 4 D´finition de la banni`re de HELO du protocole SMTP. $j est une e e variable qui contient le nom canonique (FQDN - Voir page 169)) de la machine hˆte. La banni`re de HELO smtp de la station ressemblera ` o e a ¸a : c 220 stationYXZ.mondomain.fr ESMTP --- STATION LAMBDA --- (date du jour)Ligne 6 Ajout syst´matique du nom de domaine, mˆme et surtout pour les e e courriers locaux (donc dans le domaine local par d´faut). eLigne 7 et 8 Ces deux lignes entrainent la r´´criture des adresses ee From de telle sorte quelles se pr´sentent toujours sous la e forme <untel@mondomain.fr> au lieu de leur forme par d´faut e <untel@station.mondomain.fr> qui est nuisible au retour du cour- rier car la machine station.mondomain.fr n’est tr`s vraisemblable- e ment pas atteignable directement depuis le r´seau global sur son port e 25.
  • 214 Courrier ´lectronique e Ligne 10 Tout le mail local doit ˆtre envoy´ ` la machine e e a mailhub.mondomain.fr. Ligne 11 Tout le mail autre que local doit ˆtre envoy´ ` la machine e e a mailhub.mondomain.fr. Ligne 13 Normalement inutile dans le cas pr´sent (pas de “ delivery ” sur e cette machine). Pour conclure, sendmail comme tous les outils, ´volue plusieurs fois e par an. Si ` chaque version il est n´cessaire de reconstruire manuellement a e son fichier sendmail.cf il est probable que votre emploi du temps va ˆtre e s´rieusement amput´ d’un temps pr´cieux. . .Mieux vaut avoir juste ` taper e e e a “ make ” dans le bon r´pertoire pour reconstruire un fichier de configuration e tout beau tout propre ! 5.2 Configuration manuelle Cette section est une extraction libre et incompl`te du para- e graphe 5 du document intitul´ “ Sendmail Installation and Opera- e tion Guide ”, disponible dans toute distribution de la V8. On peut ´galement trouver ce document dans la section “ System Manager’s Manual ” e (SMM) des syst`mes BSD27 . e Le fichier de configuration (sendmail.cf est organis´ comme une s´rie de e e lignes, le premier caract`re de chacune d’elles en pr´cise le type. Une ligne e e vide ou qui d´bute par un # est ignor´e (commentaire), une ligne qui d´bute e e e par un espace ou une tabulation est la continuation de la pr´c´dente. e e 5.2.1 R`gles de r´´criture e ee Les r`gles de r´´critures sont rep´rables comme ces lignes qui d´marrent e ee e e par un S (d´but d’un paquet de r`gles) ou un par un R (simple r`gle). e e e Les paquets de r`gles (organisation d’ensemble figure X.7 ) ont comme e but essentiel d’analyser puis de prendre les bonnes d´cisions en fonction des e adresses trouv´es dans l’en-tˆte. C’est une d´marche purement formelle. e e e Ces r`gles utilisent une syntaxe dense qui rebute g´n´ralement les admi- e e e nistrateurs. Il faut imaginer qu’elles sont int´gralement analys´es chaque fois e e que le programme sendmail est invoqu´, c’est ` dire en gros pour chaque e a e-mail entrant ou sortant. Elles doivent donc ˆtre faciles ` analyser, mˆme e a e par un cpu de modeste performance (ou tr`s charg´, ce qui revient finalement e e au mˆme). e L’ensemble fonctionne comme un syst`me de production, c’est ` dire e a qui consomme des r`gles lues s´quentiellement et les applique ` un jeux de e e a donn´es initiales, ici une ou plusieurs adresses ´lectroniques. e e La partie gauche (ou lhs28 ) sert de d´clencheur (“ pattern matching ”) e 27 pour FreeBSD, NetBSD ou OpenBSD ¸a se trouve dans le r´pertoire /usr/share/- c e doc/smm/08.sendmailop/ 28 “ left hand side ”
  • Configuration du Sendmail 215pour une r`gle. e La partie droite (ou rhs29 ) est d´clench´e si le motif de la partie gauche est e ereconnu dans le flux de donn´es. Le r´sultat produit, s’il existe, est reinject´ e e edans le syst`me de production et ce jusqu’` ´puisement des possibilit´s. e ae e La figure X.7 donne un aper¸u du fonctionnement de l’automate, les cchiffres (0,1,2,3,4) sont autant de “ ruleset ”, comprendre des paquets der`gles qui sont regroup´es ensembles parcequ’elles traitent d’un objectif com- e emun. 0 Adresse résolue 1 S Adresse 3 D 4 Message 2 R D : Ajout du domaine de l’émetteur S : Reécrite spécifique au ‘‘mailer’’, pour l’émission R : Idem S mais pour la réception. figure X.08 — R`gles de r´´criture e ee Les r`gles sont num´rot´es, le premier chiffre dit ` quel paquet elles ap- e e e apartiennent. Le paquet de r`gles 0 sert essentiellement ` d´terminer le “ mailer ” c’est e a e` dire le moyen d’envoyer le courrier (SMTP, ESMTP, UUCP. . .).a Les paquets de r`gles 1 et 2 sont appliqu´s respectivement ` l’en-tˆte des e e a emessages qui sortent (“ send ”) ou qui entrent (“ receive ”). Le paquet de r`gles 3 est appliqu´ syst´matiquement ` toutes les adresses. e e e a Le paquet de r`gles 4 est appliqu´ ` toutes les adresses dans le message, e eatypiquement pour passer d’une forme interne ` une forme externe. a Le paquet de r`gles 5, non repr´sent´ sur l’automate, sert ` traiter les e e e aadresses locales apr`s que les aliases aient ´t´ appliqu´s. e ee e Les paquets de r`gles sont rep´r´s par la lettre S, qui en balise le nom, e eecomme dans :######################################### Ruleset 0 -- Parse Address #########################################Sparse=0Quant aux r`gles, elles d´marrent toutes avec la lettre R, comme dans : e e 29 “ right hand side ”
  • 216 Courrier ´lectronique e R$* $: $>Parse0 $1 initial parsing R<@> $#local $: <@> special case error msgs R$* $: $>ParseLocal $1 handle local hacks R$* $: $>Parse1 $1 final parsing Deux remarques s’imposent : 1. Chaque ligne forme une r`gle, sur le mod`le : e e Rlhs rhs commentaire 2. Le s´parateur de champ entre les trois partie de ces r`gles est la tabu- e e lation (une au minimum) L’adresse postmaster@mondomain.fr, par exemple, quand elle se pr´sente devant le paquet de r`gles 0 qui d´marre ci-dessus, a ´t´ mise sous e e e ee une forme canonique par d’autres r`gles appliqu´es pr´alablement (notament e e e dans la “ ruleset 3 ”) : postmaster < @ mondomain . fr . > Le “ pattern matching ” va tenter de rapprocher cette suite de mots ou tokens de la partie gauche des r`gles (lhs) pour d´terminer celles qui peuvent e e ˆtre d´clench´es. e e e Dans la partie gauche $ s’applique ` toute suite de tokens, mˆme vide. a e Donc la premi`re ligne convient. La deuxi`me ne le pourrait pas car la chaˆ e e ıne “ postmaster ” pr´c`de le caract`re “ < ” et le “ @ ” est suivi de “ mon- e e e domain . fr . ”. La troisi`me et la quatri`me r`gle sont ´galement d´clenchables mais e e e e e pr´sentement l’ordre d’apparition est ´galement l’ordre de d´clenchement, e e e cette possiblit´ sera donc examin´e ´ventuellement plus tard. e e e La partie droite de la premi`re r`gle commence par $ : $>Parse0 ce qui e e signifie l’appel d’un autre paquet de r`gles que l’on pourra trouver plus loin e dans le fichier sendmail.cf : # # Parse0 -- do initial syntax checking and eliminate local addresses. # This should either return with the (possibly modified) input # or return with a #error mailer. It should not return with a # #mailer other than the #error mailer. # SParse0 Le $1 signifie que l’on ne transmet que le premier des tokens reconnus dans la partie gauche (“ postmaster ” dans l’exemple). . .
  • Configuration du Sendmail 2175.2.2 Exemple de sortie de debug Il est utile d’avoir ce sch´ma en tˆte quand on d´bogue les r`gles : avec e e e el’option -bt de sendmail on peut suivre la progression de la transformation,r`gle par r`gle. e eADDRESS TEST MODE (ruleset 3 NOT automatically invoked)Enter <ruleset> <address>> 3,0 postmaster@mondomain.frrewrite: ruleset 3 input: postmaster @ mondomain . frrewrite: ruleset 96 input: postmaster < @ mondomain . fr >rewrite: ruleset 96 returns: postmaster < @ mondomain . fr . >rewrite: ruleset 3 returns: postmaster < @ mondomain . fr . >rewrite: ruleset 0 input: postmaster < @ mondomain . fr . >rewrite: ruleset 199 input: postmaster < @ mondomain . fr . >rewrite: ruleset 199 returns: postmaster < @ mondomain . fr . >rewrite: ruleset 98 input: postmaster < @ mondomain . fr . >rewrite: ruleset 98 returns: postmaster < @ mondomain . fr . >rewrite: ruleset 198 input: postmaster < @ mondomain . fr . >rewrite: ruleset 90 input: < mondomain . fr > postmaster < @ mondomain . fr . >rewrite: ruleset 90 input: mondomain . < fr > postmaster < @ mondomain . fr . >rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . >rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . >rewrite: ruleset 95 input: < mailhub . mondomain . fr > postmaster < @ mondomain . fr . >rewrite: ruleset 95 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . >rewrite: ruleset 198 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . >rewrite: ruleset 0 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . >>Plus en TP. . .
  • 218 Courrier ´lectronique e 6 Bibliographie Pour en savoir davantage, on pourra consulter “ les bons auteurs ” sui- vants : ◦ Eric Allman — “ Sendmail Installation and Operation Guide ” — docu- ment au format PostScript jointe ` toutes les distributions de la V8.xx. a ◦ Bryan Costales with Eric Allman & Neil Rickert — “ Sendmail ” — ´ OReilly & Associates Inc. — 1994 ◦ “ Installing and Administering ARPA Services ” — Hewlett–Packard — 1991 ◦ Douglas E. Comer — “ Internetworking with TCP/IP – Volume I ” (chapter 19) — Prentice All — 1988 ◦ W. Richard Stevens — “ TCP/IP Illustrated Volume I ” (chapter 28) — Prentice All — 1994 Et pour en savoir encore plus. . . RFC 821 “ Simple Mail Transfer Protocol. ” J. Postel. Aug-01-1982. (For- mat : TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Sta- tus : STANDARD) RFC 822 “ Standard for the format of ARPA Internet text messages. ” D. Crocker. Aug-13-1982. (Format : TXT=109200 bytes) (Obsoletes RFC0733) (Updated by RFC1123, RFC1138, RFC1148, RFC1327) (Also STD0011) (Status : STANDARD) RFC 974 “ Mail routing and the domain system. ” C. Partridge. Jan-01- 1986. (Format : TXT=18581 bytes) (Status : STANDARD) RFC 1123 “ Requirements for Internet hosts - application and support. R.T. ” Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD) RFC 1652 “ SMTP Service Extension for 8bit-MIMEtransport. ” Klensin, N. Freed, M. Rose, E. Stefferud & D. Crocker. July 1994. (Format : TXT=11842 bytes) (Obsoletes RFC1426) (Status : DRAFT STAN- DARD) RFC 1939 “ Post Office Protocol - Version 3. ” J. Myers & M. Rose. May 1996. (Format : TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957) (Also STD0053) (Status : STANDARD) RFC 2060 “ Internet Message Access Protocol - Version 4rev1. ” M. Crispin. December 1996. (Format : TXT=166513 bytes) (Obsoletes RFC1730) (Status : PROPOSED STANDARD) RFC 2184 “ MIME Parameter Value and Encoded Word Extensions : Cha- racter Sets, Languages, and Continuations. ” N. Freed, K. Moore. Au- gust 1997. (Format : TXT=17635 bytes) (Updates RFC2045, RFC2047, RFC2183) (Status : PROPOSED STANDARD) RFC 2476 “ Message Submission. ” R. Gellens, J. Klensin. December 1998. (Format : TXT=30050 bytes) (Status : PROPOSED STANDARD)
  • Bibliographie 219RFC 2821 “ Simple Mail Transfer Protocol. ” J. Klensin, Ed.April ˙ 2001. (Format : TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) (Status : PROPOSED STANDARD) ˙RFC 2822 “ Internet Message Format. ” P. Resnick, Ed.April 2001. (For- mat : TXT=110695 bytes) (Obsoletes RFC0822) (Status : PROPOSED STANDARD)
  • 220 Courrier ´lectronique e
  • Chapitre XI Instrumentalisation der´seaux avec SNMP e1 N´cessit´ d’un outil e e La majeure partie des activit´s informatiques d´pendent du bon fonc- e etionnement des r´seaux et des services associ´s. Leurs nombres et leur com- e eplexit´ ne cessent de s’accroˆ e ıtre, mais bien souvent le personnel responsablede l’´volution et du bon fonctionnement de l’ensemble ne voit pas ses effectifs ehumains ´voluer dans le mˆme sens, du moins aussi rapidement que le parc e ede machines ` administrer ! a Or, le bon fonctionnement d’un grand r´seau ne peut d´pendre pour seule e ecomposante que de l’effort intellectuel d’individus ou de groupe d’individus,fussent-ils comp´tents et d´vou´s. Il faut des outils ! e e e1.1 Probl´matique de l’ISO e L’ISO, s’est pench´ sur la question et a segment´ le probl`me de la gestion e e etechnique de r´seau en cinq points : eLa gestion des pannes (Fault management) Il s’agit de d´tecter les e pannes, de les localiser et d’y rem´dier en minimisant l’impact de la e perte de fonctionnalit´ sur le reste du syst`me d’information. e e La panne n’est pas une erreur, mais un grand nombre d’erreurs peuvent conduire ` d´clarer une panne. Par exemple la croissance anormale du a e nombre de collisions sur un r´seau, l’engorgement d’un disque. . . eLa comptabilisation de l’usage des ressources (Accounting manage- ment) Il s’agit d’archiver et de mettre en ordre tous les compteurs g´n´r´s par les applicatifs et les couches r´seaux afin de pouvoir tirer e ee e un enseignement de l’usage des ressources. L’aspect confidentiel de ces donn´es doit ˆtre pris en compte. e eLa gestion des configurations (Configuration and name management) Il s’agit de la mise en œuvre et de la configuration de tous les ´quipements e qui inter-agissent sur le r´seau. e
  • 222 Gestion de r´seaux avec SNMP e L’audit des performances (Performance management) Il s’agit d’avoir une approche quantitative sur le fonctionnement du r´seau afin de pou- e voir r´pondre ` des questions aussi basiques que : e a 1. Quel est le niveau actuel d’utilisation ? 2. Il y a t-il un (des) trafic(s) excessif(s) ? 3. Le d´bit nominal est-il r´duit ` une valeur inacceptable ? e e a 4. O` sont les goulots d’´tranglement ? u e 5. Quelle est l’´volution du temps de r´ponse ? e e La gestion de la s´curit´ (Security management) Il s’agit de maintenir e e coh´rent et effectif l’ensemble des protections sur les autorisations e d’acc`s et donn´es sensibles collect´es. e e e Les logs (syslog) sont un point important de la gestion de la s´curit´. e e En conclusion, les buts d’une gestion technique efficace d’un r´seau sont e multiples : il s’agit d’offrir aux usagers un service de qualit´, de permettre e les ´volutions du syst`me d’information en y incluant de nouvelles fonction- e e nalit´s, d’optimiser l’usage des ressources et de minimiser les coˆts d’exploi- e u tation ou d’investissement. 1.2 Syst`me de gestion de r´seau e e Un syst`me de gestion de r´seau (Network Management System) est une e e collection d’outils pour la surveillance et le contrˆle afin de permettre ` un o a op´rateur d’effectuer la plupart des op´rations de gestion depuis un interface e e le plus simple et ergonomique possible ! C’est un ensemble de logiciels (Network Management Entity) associ´s e ´ventuellement ` des mat´riels sp´cifiques, qui sont d´ploy´s sur tous les e a e e e e composants du syst`me d’information. e Un NMS est donc con¸u pour donner une image unifi´e du r´seau, quelle c e e que soit son ´tendue et son h´t´rog´n´it´. Le logiciel utilis´ pour visualiser e ee e e e e l’image du r´seau est un NMA (Network Management Application). e Un NME : ◦ Collecte des donn´es sur l’activit´ r´seau e e e ◦ Conserve ces donn´es dans une base e ◦ R´pond aux requˆtes du NMA, notamment sur les points suivants : e e 1. Transmission des donn´es collect´es e e 2. Changement d’un param`tre de configuration e 3. Fourniture de statut de composants logiciels ou mat´riels e 4. G´n´ration de tests e e ◦ Envoi des messages d’alerte (trap) en cas de d´tection d’´vˆnements e e e exceptionnels. Au moins un nœud du r´seau est d´sign´ comme ´tant le manager, et e e e e supportant le NMA. Cette architecture n’est pas n´cessairement centralis´, e e la supervision du r´seau peut s’effectuer par secteurs. e
  • N´cessit´ d’un outil e e 2231.3 SNMP — Simple Network Management Protocol SNMP est un terme un peu g´n´rique qui d´signe ` la fois un protocole e e e ar´seau applicatif bien pr´cis, une collection de sp´cifications pour le mana- e e egement de r´seau et la d´finition de structures de donn´es ainsi que leurs e e econcepts associ´s. e SNMP est n´ en 1988 de la n´cessit´ de disposer d’un outil de supervision e e edu r´seau d`s lors que celui-ci comporte un grand nombre d’hˆtes qui inter- e e oagissent, stations, serveurs, ´l´ments de routage ou de commutation ou encore eeboites noires. Leur nombre grandissant sur les LANs (des machines en clusterspar exemples) implique d’avoir un outil qui permette “ d’expliquer ” le r´seau. eCe besoin est moins ´vident quand tout va bien, mais il suffit parfois d’un esimple petit grain de sable. . . Dans ces moments l`, disposer d’un outil qui ad´livre une information de synth`se est indispensable ! e e Les logs, au sens de syslog (paragraphe 3.2 page 316) , mˆme concentr´s, e efiltr´s, et tri´s ne d´livrent une information parfois trop verbeuse et en e e etout cas structur´e diff´remment selon les applications ou les noyaux. Les e e´vˆnements r´seaux y sont le plus souvent absents, sauf dans le cas tr`s par-e e e e 1ticulier de d´mons qui surveillent le r´seau, arpwatch en est un exemple. e eLe tri par niveau de criticit´ ne retire rien ou presque au fait que c’est une einformation brute qu’il faut filtrer pour en extraire l’information pertinente. L’architecture d’un r´seau g´r´ avec SNMP comporte essentiellement e eedeux entit´s : le manager et l’agent, ou encore le client et le serveur. Le eclient (manager) interroge le serveur pour r´colter de l’information ou confi- egurer une valeur, le serveur (agent) est capable de pr´venir le client en cas ed’´vˆnements exceptionnels (traps). e e Enfin, n’importe quelle machine munie d’une stack IP est susceptible desupporter SNMP, depuis le calepin ´lectronique, en passant par la borne wifi eet jusqu’au mainframe.En quelques mots, SNMP permet : ◦ De cartographier le r´seau e ◦ De fournir un panel tr`s complet de r´sultats de mesures pour chaque e e hˆte o ◦ De mesurer en temps r´el la consommation de ressources d’une appli- e cation ◦ De signaler les dysfonctionnements ◦ De changer certains param`tres r´seaux de fonctionnement e eAvantages : ◦ Protocole est simple et facile d’utilisation ◦ Permet une gestion centralis´e d’un parc e ◦ Dispose d’un mod`le extensible e ◦ Est ind´pendant de l’architecture mat´rielle e e 1 Site officiel http://www-nrg.ee.lbl.gov/
  • 224 Gestion de r´seaux avec SNMP e Station de management Agent SNMP NMA NME SNMP SNMP Requetes MIBs :161 MIBs Réponses Réseau UDP/IP :162 Envoi de "trap" figure XI.01 — Agent et Manager dans une relation de type client-serveur 1.4 Historique du protocole SNMP Avant 1987/1988 il n’y a rien d’autre qu’ICMP pour recevoir de l’info entres routeurs et hˆtes. Le couple (echo request,echo reply) est le plus o utilis´ pour maintenir un ´tat des machines accessibles. e e Le point de d´part est SGMP (“ Simple Gateway Monitoring Protocol ” e RFC 1028 de novembre 1987) mais trop orient´ sur la gestion des routeurs. e Du cot´ de l’OSI d’autres tentatives avec CMIS et CMIP (“ Common Ma- e nagement Information Service & Protocol ”) SNMP est sorti en 1988, comme une version am´lior´e de SGMP. Les e e RFCs fondatrices sont les 1155, 1156 et 1157 conserv´es actuellement au e rang d’historiques bien que tous les ´quipements soient th´oriquement encore e e compatibles SNMPv1 (mˆme s’ils r´pondent ` un niveau de version SNMP e e a plus r´cent, c’est ` dire 2 ou 3). e a 1.5 Vocabulaire et architecture Un syst`me d’exploitation peut ˆtre vu comme une vaste collection de e e compteurs et d’horloges auxquels SNMP nous permet d’acc´der ` distance e a pour les lire et les modifier (certaines, sous r´serve d’y avoir acc`s). e e Afin que les agents et les managers soient inter-op´rables les variables e sont collectionn´es selon une repr´sentation arborescente tr`s structur´e et e e e e standardis´e, ce sont les MIBs (“ Management Information Base ”). On les e retrouve partout o` SNMP est support´. Ainsi, une mˆme information se u e e nomme de la mˆme mani`re quelle que soit l’impl´mentation de SNMP et e e e ind´pendamment de sa valeur qui est fonction du contexte. C’est donc tr`s e e commode pour automatiser les traitements (scripts de collecte et de sur- veillance. . .) dans un r´seau qui est h´t´rog`ne la plupart du temps ! e ee e
  • N´cessit´ d’un outil e e 225 Les feuilles de cet arbre sont les variables et on y acc`de en connaissant le echemin ` priori depuis la racine, un peu ` la mani`re d’un syst`me de fichiers, a a e esauf qu’ici les chemins sont codifi´s ` l’avance. e a Actuellement c’est la MIB-2 qui est la plus r´pandue (RFC 1213), elle er´pond parfaitement aux besoins ´lementaires. Si un appareil ou un syst`me e e ea des besoins sp´cifiques il est toujours possible d’ajouter des branches au etronc commun, un embranchement est pr´vu pour cela, on parle alors d’une eextension “ vendor ”. Tous les vendeurs d’hˆtes r´seaux pr´voient des MIBs pour leurs o e e´quipements (“ mibs vendors ” donc), d`s lors qu’ils sont accessibles via ipe e(routeurs, commutateurs, ponts, hˆtes, imprimantes, boites noires diverses) omˆme si celle-ci n’est pas montr´e ` l’utilisateur final. Telle borne wifi d’un e e ac´l`bre constructeur informatique “ ` la pomme ”, utilise SNMP pour se ee aconfigurer mais l’utilisateur ne le voit pas, c’est masqu´ par un interface eutilisateur convivial. La figure XI.01 pr´sente la relation entre les deux entit´s logicielles qui e edans le cas de SNMP se nomment :Agent SNMP, ou NME (le serveur) C’est un logiciel qui s’ex´cute sur e l’appareil que l’on souhaite administrer ` distance. Il r´pond aux a e requˆtes du gestionnaire, et g´n`re des alarmes (traps) si besoin est. e e e La configuration d’un agent est en g´n´ral assez simple (par rapport ` e e a celle d’un logiciel Manager).Manager NMA (le client) C’est le logiciel qui s’ex´cute sur la station e d’administration. Sa configuration est forc´mement plus d´licate que e e celle de l’agent parcequ’il n´cessite une adaptation au r´seau local qui e e est toujours un cas particulier. Il existe de nombreux logiciels HP Open- View, SUN Net Manager , IBM Netview, Spectrum, ISM OpenMaster, SNMPc.. . . L’Open Source n’est pas en reste et sans ˆtre aussi complet, l’outil e “ tkined ” est d´j` tr`s satisfaisant pour l’essentiel des besoins (voir la ea e recopie d’´cran page 247). eSonde RMON (alternative de serveur) La figure 01 est en fait in- compl`te dans le cadre d’une architecture de supervision globale de e r´seau : si chaque agent sur chaque hˆte peut r´pondre individuelle- e o e ment sur les ´vˆnements r´seau le concernant, il manque un maillon e e e plus global qui fasse la supervision du r´seau en lui-mˆme, le v´ritable e e e “ networking management ”. Cet ´l´ment existe, c’est ce qu’on appelle ee une sonde RMON, ou encore “ Remote Monitoring ”. C’est une entit´ logicielle, comme un agent SNMP. Elle s’appuie sur e une extension de la MIB de base. On la trouve principalement sur les ´l´ments de commutation ou de routage, l` o` se concentre le trafic ee a u r´seau, mais on peut la trouver sur un hˆte ´galement, par exemple sur e o e un serveur critique. L’Open Source nous en fournit un tr`s bel exemple avec le logiciel e
  • 226 Gestion de r´seaux avec SNMP e ntop2 . La repr´sentation des donn´es dans les variables n’est pas laiss´e au ha- e e e sard des besoins des d´veloppeurs mais est structur´e selon une sp´cification e e e appell´ SMI “ Structure of Management Information ”, d´finie par la e e RFC 1155, qui dit par exemple qu’un entier positif va de 0 ` 232 − 1. Pour a ˆtre ind´pendant du formalisme local de la plateforme (probl´matique de la e e e couche 6 OSI). 1.6 Diff´rentes versions e Enfin cet ´change de donn´es prend place dans un protocol r´seau qui e e e est d´fini par les RFC 1155 ` 1157, nomm´ “ Simple Network Management e a e Procotol ” (version 1). Beaucoup de travail dans les rfc depuis. . . Actuellement il y a 3 versions de SNMP, v1, v2c et v3. La v1 est support´e e pour des raison “ historiques ”, la v2 est la plus couramment support´e par les e appareillages. Elle pose quelques soucis que tente de r´gler la v3 (notamment e la s´curisation de l’authentification). e La premi`re version souffrait d’un certain nombre de lacunes au niveau du e protocole et de la s´curit´ que la deuxi`me version (SNMPv2c “ Community- e e e based SNMPv2 ”) d´finie par les RFC 1901 ` 1908, tente de combler. Rien e a n’est malheureusement fait cot´ s´curit´ dans cette deuxi`me version mais e e e e des am´liorations sont apport´es aux mibs standards et au protocole. e e Plus r´cemment un nouveau cadre de travail a ´t´ d´velopp´, qui s’af- e ee e e franchit compl`tement de la notion de “ communaut´ ”, obstacle ` l’usage e e a de SNMP en ´criture, et qui introduit des am´liorations significatives de la e e s´curit´ (RFC 3411 ` 3418). e e a L’inertie des habitudes retarde son d´ploiement g´n´ralis´, ainsi que la e e e e n´cessit´ de continuer ` g´rer des appareils ne le supportant pas (encore). e e a e 1.6.1 Trois composantes pour SNMP D’apr`s la RFC 1213 (MIB II) le cadre de travail de SNMP repose sur e trois composantes : SMI d´finit les types d’objets utilis´s dans les mibs. C’est une sorte de e e m´ta mod`le de donn´es. Par exemple pour d´finir une adresse physique e e e e (MAC) PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. 2 http://www.ntop.org/
  • N´cessit´ d’un outil e e 227La MIB d´crit une collection structur´e des ressources ` g´rer. Une res- e e a e source ` g´rer est repr´sent´e par un objet. a e e eLe protocole SNMP qui r´git le contenu des dialogues clients/serveurs e c’est ` dire l’interrogation des donn´es structur´es par la MIB. a e e1.6.2 Conclusion le protocole SNMP est simple dans sa conception ce qui permet sond´ploiement sur de tr`s nombreux appareils h´t´rog`nes mis en r´seau. e e ee e e En pratique la situation est moins simple du fait de la coexistence de 3versions des MIB non toutes support´es par tous les hˆtes du r´seau. e o e La configuration de la station d’administration demande du temps, uneconnaissance tr`s approfondie de la topologie du r´seau ` administrer, et e e abeaucoup de comp´tences techniques. C’est un travail ` haute valeur ajout´e ! e a e
  • 228 Gestion de r´seaux avec SNMP e 2 SMI — Structure of Management Informa- tion La RFC 1155 fondatrice pose le cadre de travail ` l’int´rieur duquel on a e peut bˆtir les MIBs. En effet, la SMI pr´cises les types de donn´es et les a e e ressources qui peuvent ˆtre sp´cifi´es dans une MIB. e e e Les donn´es ont ´t´ pr´vues simples, le tableau (par exemple pour e ee e repr´senter un ensemble de connexions tcp tcpConnTable) et la liste (les e ´l´ments d’un quintuplet tcp tcpConnEntry) sont les formes les plus com- ee plexes pr´vues. e Ces structures de donn´es sont remplies avec les 5 types suivants : e networkaddress Il s’agit d’une zone pouvant contenir une adresse r´seau, e avec comme format possible IpAddress (ipv4 32 bits). counter C’est un compteur qui prend sa valeur maxi ` 232 − 1 (on reconnait a un entier 32 bits non sign´) et qui ne peut pas ˆtre d´cr´ment´. Quand e e e e e il atteind sa valeur maxi il repasse ` 0. a gauge C’est un compteur, qui a la mˆme valeur maximale que le pr´c´dent e e e mais qui au contraire peut ˆtre d´cr´ment´. Par contre il ne repasse e e e e pas automatiquement ` 0 en cas de valeur maximale atteinte. a timeticks Le nombre de secondes ´coul´es depuis epoch, c’est ` dire le 1er e e a janvier 1970. opaque C’est un flux d’octets banalis´s qui permet d’encoder tout ce qui ne e rel`ve pas des types pr´c´dents, une sorte de fourre-tout en quelque e e e sorte. . . Toutes les ressources auxquelles on souhaite acc´der d´crites dans un e e document qui est une MIB. 3 MIB — Management Information Base Les MIBs sont des fichiers au format ascii qui d´crivent dans le d´tail e e chacune des ressources ` quantifier. Ces ressources sont des ´l´ments simples a ee (scalaire ou tableaux ` deux dimensions). Chaque unit´ de description se a e nomme un “ objet ” (sans aucun rapport avec la programmation du mˆme e nom). Une MIB est une collection structur´e de tous ces objets. Un mˆme e e objet est accessible de la mˆme mani`re partout sur le r´seau. e e e Le propos d’une MIB peut ˆtre celui de respecter un standard ouvert, e d´crit alors par une RFC et distribu´ librement, ou d’ˆtre sp´cifique pour un e e e e type particulier d’appareil et de constructeur (“ mibs vendor ”). Sa diffusion est alors ` l’initiative de son auteur. a Le contenu d’une MIB est toujours d´crit ` l’aide d’un langage formel e a 3 nomm´ ASN.1 utilis´ g´n´ralement pour d´finir des structures de donn´es e e e e e e 3 d´velopp´ et standardis´ par le CCITT (X.208) et l’ISO (ISO 8824) e e e
  • MIB — Management Information Base 229applicatives complexes (couche 6 du mod`le de l’OSI) et qui est ind´pendant e ede tout langage de programmation. Un extrait de la MIB II (RFC 1213) concernant le d´but de la description ede l’objet tcpConnTable, ` savoir la table des connexions tcp, celle l` mˆme a a eque l’on peut observer avec la commande netstat -p tcp. 1 −− the TCP Connection table 2 3 −− The TCP connection table contains information about this 4 −− entity’s existing TCP connections. 5 6 tcpConnTable OBJECT−TYPE 7 SYNTAX SEQUENCE OF TcpConnEntry 8 ACCESS not−accessible 9 STATUS mandatory 10 DESCRIPTION 11 "A table containing TCP connection−specific 12 information." 13 ::= { tcp 13 } 14 15 tcpConnEntry OBJECT−TYPE 16 SYNTAX TcpConnEntry 17 ACCESS not−accessible 18 STATUS mandatory 19 DESCRIPTION 20 "Information about a particular current TCP 21 connection. An object of this type is transient, 22 in that it ceases to exist when (or soon after) 23 the connection makes the transition to the CLOSED 24 state." 25 INDEX { tcpConnLocalAddress, 26 tcpConnLocalPort, 27 tcpConnRemAddress, 28 tcpConnRemPort } 29 ::= { tcpConnTable 1 } Ce petit exemple montre que l’identification d’un objet repose sur cinqchamps : 1. Le nom de l’objet, tcpConnTable qui balise le d´but de la d´finition e e 2. (SYNTAX) La syntaxe d’usage. Ici une liste d’objets tcpConnEntry. On y reconnaˆ sans peine les ´l´ments du quintuplet vus en cours TCP. ıtra ee 3. (ACCESS) L’acc`s (lecture, ´criture, lecture-´criture, pas accessible). Ici e e e On ne peut ni lire ni ´crire dans cet objet. e 4. (STATUS) L’´tat de l’objet, valeur ` prendre dans obligatoire e a (MANDATORY), obsol`te ou optionnel. e 5. (DESCRIPTION) Un texte qui d´crit ce que repr´sente l’objet. e e Les lignes qui d´butent par un “ – ” sont des commentaires. e Enfin on peut remarquer que ce bloc de texte se termine par::= { tcp 13 } qui signifie que cet objet est le treizi`me fils de l’objet p`re e etcp. Tous les objets de toutes les MIBs (propri´taires ou non) sont organis´s e edans un seul arbre, donc avec une seule racine commune. Pour identifier unobjet dans cet ensemble, on parle de son OID.
  • 230 Gestion de r´seaux avec SNMP e 3.1 OID — Objet Identifier Le nommage des objets utilise une repr´sentation arborescente dont la e racine est fig´e mais qui est extensible ` volont´. Le nommage d’un objet e a e passe par la d´finition (en ASN.1) d’un “ Objet IDentifier ” ou OID, qui e peut s’apparenter au “ path ” d’un fichier. Ce chemin peut s’exprimer de mani`re symbolique, par exemple e .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 ou encore dans une repr´sentation num´rique absolument ´quivalente .1.3.6.1.2.1.1.1 e e e En pratique on pourra le plus fr´quemment faire r´f´rence seulement ` e ee a sysDescr.04 . La racine de l’arbre est ` gauche, contrairement, par exemple, a au syst`me de nommage du DNS qui place la racine ` droite. e a En effet un OID est une s´quence d’entiers, parcours dans l’arbre de la e racine jusqu’` la feuille terminale. Chaque noeud travers´ est ´tiquett´ par a e e e un nombre et un bref texte descriptif. Bien entendu l’unicit´ de l’´tiquettage e e ` un niveau donn´ de l’arbre est primordial pour son bon fonctionnement. a e La racine n’est pas nomm´e, d’o` le point (.) ` gauche des deux ´critures e u a e qui pr´c`dent. e e ` A ce jour deux entit´s se partagent les trois noeuds du premier niveau de e l’arbre : l’ISO et le CCITT6 , le troisi`me noeud s’explique par une entit´ 5 e e mixte des deux et nomm´e “ joint-iso-ccitt ”. e root ccitt(0) iso(1) joint−iso−ccitt(2) org(3) dod(6) internet(1) directory(1) mgmt(2) experimental(3) private(4) security(5) snmpv2(6) mib−2(1) enterprises(1) Internet SMI figure XI.02 — La racine de l’arbre des OIDs Sous le noeud de l’iso un sous arbre est pr´vu pour d’autres organisations, e l’une d’elle est le d´partement de la d´fense US (dod). La RFC 1155 pose e e le fait qu’un sous arbre du dod est allou´ ` l’IAB (Internet Activity Board), ea sans doute une trace des origines militaires de la pile Arpa. Et voila pourquoi les OIDs standards sont plac´s sous le noeud nomm´ e e 4 Notez la pr´sence du “ 0 ” en fin de chaˆ qui ne fait pas partie du nommage mais e ıne est un artifice ` l’interrogation pour indiquer qu’il s’agit d’une feuille de l’arbre et non par a exemple la base d’un tableau 5 International Organization for Standardisation 6 International Telegraph and Telephone Consultative Committee
  • MIB — Management Information Base 231mib-2(1) et que le pr´fixe le plus commun est .1.3.6.1.2.1, indices des enoeuds p`res travers´s ` partir de la racine ! e e aDirectory(1) R´serv´ pour l’OSI e emgmt(2) L’administration de ce sous arbre est d´l´gu´ ` l’IANA7 et est donc ee ea r´git par des RFCs ! eExperimental(3) Utilis´ pour identifier des objets utilis´s pour des e e d´ploiements exp´rimentaux sur l’Internet. D´l´gu´ ` l’IANA. e e ee eaPrivate(4) Comme son nom l’indique ce sous arbre est celui des d´l´gations ee priv´es. Le sous arbre enterprise(1) permet aux entreprises d’y placer e leurs MIBs, apr`s s’ˆtre enregistr´es aupr`s de l’IANA. e e e e...3.2 Types de donn´es ´l´mentaires e ee Le type des objets utilis´s dans les MIBs est limit´ ` un sous ensemble des e eatypes disponibles dans ASN.1, mais suffisant pour exprimer les compteurs,les tables et les identificateurs que l’on trouve dans la m´moire d’un syst`me e ed’exploitation.INTEGER De nombreux compteurs du syst`me d’exploitation utilisent un tel e type, comme par exemple ceux des statistiques extraites du noyau par la commande netstat -s -p ip.OCTETS STRINGS Pour d´finir une chaˆ de caract`res comme une suite de e ıne e 0 ou plus octets de 8 bits.NULL Pour dire qu’il n’y a pas de valeur.OBJECT IDENTIFIER Pour d´finir les objets (OID). eSEQUENCE Se rapproche de la notion de structure du langage C, autrement dit pour grouper plusieurs types dans un seul.SEQUENCE-OF Introduit la notion de vecteur. Bien que ces types de donn´es puissent ressembler ` ceux de tel ou tel e alangage de programmation, leur repr´sentation interne diff`re tr`s certaine- e e e 8ment puisqu’elle respecte les “ Basic Encoding Rules ”, ou BER, afin d’ˆtre eabolument portables sur tout type de plateforme. BER est une m´thode d’en- ecodage des valeurs pour tous les types d´finis par ASN.1, sous forme d’une echaˆ d’octets et bas´e sur l’usage d’un triplet de valeurs (type, longueur, ıne evaleur) ou TLV. Ainsi par exemple les chaˆ ınes de caract`res ne sont pas termin´es par e eun caract`re null (Ascii 0) comme dans le langage C mais sont encod´es e edirectement avec leur longueur. 7 Internet Assigned Numbers Authority 8 d´velopp´ et standardis´ par le CCITT (X.209) et l’ISO (ISO 8825) e e e
  • 232 Gestion de r´seaux avec SNMP e 4 La MIB-2 la mib standard la plus courante est la MIB-2 d´finie dans la RFC 1213, e c’est un sur-ensemble de la mib d’origine (MIB-I) d´finie dans la RFC 1156. e Cette mib regroupe les compteurs les plus courants associ´s ` une pile Arpa et e a d’autres comme ceux associ´s ` la technologie Token-Ring, FDDI, Microsoft e a Lan Manager, DECnet, pour information. La racine du sous-arbre concern´e est clairement mgmt, c’est ` dire e a .1.3.6.1.2 et le noeud concern´ est mib-2(1) qui est l’OID d´fini ligne e e 15. Puis viennent les 10 sous arbres d´crits plus avant dans cette mib : e system(1) Le groupe system fournit des informations d’ordre g´n´ral sur le e e system lui-mˆme, comme l’e-mail d’un contact, la valeur de l’“ uptime ” e ou encore la location physique de l’appareil. interfaces(2) Le groupe interfaces regroupe toutes les informations sur les interfaces physiques ou virtuels pr´sents, leur type, le fabricant, leur e caract´ristiques et enfin les statistiques d’usage. e at(3) Ce groupe est une seule table de correspondances entre les adresses physiques et logiques. Pour une pile Arpa il s’agit de la table des adresses physique(MAC), telle qu’elle peut ˆtre extraite par la com- e mande arp -an. ip(4) Le groupe ip contient toutes informations relatives ` ce protocole a (adresse, netmask), notamment la table de routage et tous les comp- teurs auxquels on peut acc´der ` l’aide de netstat -s -p ip. e a icmp(5) Le groupe icmp contient toutes les informations relatives ` ce pro- a tocole. Le compteur du nombre d’“ echo request ” est par exemple accessible, tout comme il peut l’ˆtre avec un netstat -s -p icmp. e Tous les messages sont associ´s ` deux compteurs. e a tcp(6) Le groupe tcp contient toutes les informations relatives ` ce proto- a cole, par exemple celles que l’on peut obtenir ` l’aide d’un netstat -s a -p tcp plus d’autres comme la liste des connexions en cours avec leur ´tat. e udp(7) Le groupe udp regroupe toutes les informations relative ` ce pro-a tocole (netstat -s p -udp). G`re ´galement la liste des applications e e utilisant ce protocole. egp(8) Le groupe egp regroupe les informations relatives au protocole de routage “ Exterior Gateway Protocol ”. transmission(10) Le groupe transmission regroupe des interfaces d´j` ea d´finies dans le Interfaces(2). mais selon d’autres crit`res, comme e e par exemple les protocoles support´s.e snmp(11) Ce groupe donne des informations sur l’impl´mentation ete l’ex´cution de SNMP lui-mˆme, c’est ` dire le nombre de message en- e e a trants, sortants, la r´partition du type de requˆtes re¸ues, ´mises. e e c e
  • La MIB-2 233Voici un extrait du d´but de cette mib : e 1 RFC1213−MIB DEFINITIONS ::= BEGIN 2 3 IMPORTS 4 mgmt, NetworkAddress, IpAddress, Counter, Gauge, 5 TimeTicks 6 FROM RFC1155−SMI 7 OBJECT−TYPE 8 FROM RFC−1212; 9 10 −− This MIB module uses the extended OBJECT−TYPE macro as 11 −− defined in [14]; 12 13 −− MIB−II (same prefix as MIB−I) 14 15 mib−2 OBJECT IDENTIFIER ::= { mgmt 1 } 16 17 −− textual conventions 18 19 DisplayString ::= 20 OCTET STRING 21 −− This data type is used to model textual information taken 22 −− from the NVT ASCII character set. By convention, objects 23 −− with this syntax are declared as having 24 25 −− 26 −− SIZE (0..255) 27 28 PhysAddress ::= 29 OCTET STRING 30 −− This data type is used to model media addresses. For many 31 −− types of media, this will be in a binary representation. 32 −− For example, an ethernet address would be represented as 33 −− a string of 6 octets. 34 35 −− groups in MIB−II 36 37 system OBJECT IDENTIFIER ::= { mib−2 1 } 38 39 interfaces OBJECT IDENTIFIER ::= { mib−2 2 } 40 41 at OBJECT IDENTIFIER ::= { mib−2 3 } 42 43 ip OBJECT IDENTIFIER ::= { mib−2 4 } 44 45 icmp OBJECT IDENTIFIER ::= { mib−2 5 } 46 47 tcp OBJECT IDENTIFIER ::= { mib−2 6 } 48 49 udp OBJECT IDENTIFIER ::= { mib−2 7 } 50 51 egp OBJECT IDENTIFIER ::= { mib−2 8 } 52 53 −− historical (some say hysterical) 54 −− cmot OBJECT IDENTIFIER ::= { mib−2 9 } 55 56 transmission OBJECT IDENTIFIER ::= { mib−2 10 } 57 58 snmp OBJECT IDENTIFIER ::= { mib−2 11 } 59
  • 234 Gestion de r´seaux avec SNMP e 5 Protocole SNMP le protocole SNMP est du type client/serveur classique. Un vocabulaire sp´cifique : le serveur est nomm´ “ Agent SNMP ” alors que le client est un e e “ Manager ” ou encore “ Network Management Software ” (NMS). Le serveur (agent) ´coute les requˆtes du client (manager) sur le port 161 e e (UDP) et peut lui envoyer des messages d’exception (trap) sur son port 162. Le choix du transport UDP est justifi´ par le trafic de petits datagrammes e (la RFC 1157 “ An implementation of this protocol need not accept messages whose length exceeds 484 octets ”. Les besoins ont ´volu´ mais ce choix initial e e perdure. Aux parties applicatives la tˆche de faire le travail d’une couche de a transport si besoin est (gestion d’un “ time-out ” et de la re´mission des e datagrammes manquants). Le client (manager), interroge ` son rythme les agents sur leur port 161 et a ´coute sur le port 162 (UDP) les ´ventuels messages d’exceptions envoy´s par e e e ces mˆmes agents. Il faut noter que le protocole permet non seulement la lec- e ture de variables mais aussi leur modification, ce qui pose des probl`mes d’au- e thentification et de confidentialit´, non r´solus avec SNMPv1 et SNMPv2. e e En effet, ce qui fait office de m´canisme d’authentification est une chaˆ de e ıne caract`res qui circule “ en clair ” sur le r´seau, c’est la fameuse “ commu- e e naut´ ” dont la valeur par d´faut sur les ´quipement est traditionnellement e e e “ public ”. La plupart du temps on se borne donc ` l’aspect “ read only ” du protocole a et seulement pour des ´changes sur des r´seaux qui devraient ˆtre prot´g´s, e e e e e par exemple cantonn´s sur un vlan d’administration sur lequel ne circule e aucun trafic applicatif inutile et surtout auquel aucun utilisateur standard n’acc`de. e Agent Agent Agent Agent :161(UDP) :161 :161 :161 get−request :162 (UDP) Trap get−next−request set−request get−response get−bulk−request Manager figure XI.03 — Des agents et un Manager
  • Protocole SNMP 2355.1 Communaut´ e La communaut´ SNMP est une relation entre un agent et les stations ed’administration qui l’interrogent. Cette unique chaˆ de caract`res d´finit ıne e e` la fois l’authentification et le contrˆle d’acc`s.a o e Il peut y avoir autant de communaut´s que d’agents, c’est au manager ed’en conserver la liste. Chaque message d’une station d’administration vers un agent comportele nom de la communaut´ et donc permet ` l’agent d’authentifier la source e ade la requˆte. Ce mode d’authentification n’est bien sˆr plus adapt´ aux e u econtraintes de s´curit´ qu’impose l’exploitation moderne des r´seaux. e e e Le minimum pour exploiter malgr´ tout SNMPv2 est d’avoir au moins etrois communaut´s diff´rentes : une pour la lecture (GET), une pour l’´criture e e e(SET) et une troisi`me pour les traps. e5.2 PDUs Que ce soit pour des requˆtes, des r´ponses aux requˆtes, ou l’envoi d’un e e etrap, SNMPv2 s’appuie sur un message dont le format est d´crit succintement edans la figure 04 : Message SNMP En−tete standard Get/Set/Trap Com− IP UDP Version Protocol Data Unit (PDU) munauté ID PDU type requete 0 0 (variable, valeur) GetRequest, GetNextRequest, SetRequest, Trap, InformRequest ID Statut Index (variable, valeur) PDU type requete d’erreur d’erreur Response ID non max PDU type requete (variable, valeur) repeaters repetitions GetBulkRequest figure XI.04 — Format des messages SNMPLa partie standard de l’en-tˆte, comporte deux champs : eVersion Il s’agit de la version du protocole, 1, 2 ou 3.Communaut´ Une chaˆ d’octets qui identifie la communaut´, “ public ” e ıne e par d´faut. . . e
  • 236 Gestion de r´seaux avec SNMP e Ensuite le message est compos´ d’une partie dont la longueur et le contenu e sont assez variables, selon les op´rations. C’est ce qu’on appelle le PDU e (“ Protocol Data Unit ”). Il y en a sept possibles. En effet, le protocole de base (SNMPv1) pr´voit cinq types de requˆtes : e e GetRequest C’est une question du manager ` l’agent. Une liste de a couples (variable,valeur) est fournie. Les valeurs sont positionn´es ` e a unSpecified. GetNextRequest Cette requˆte est assez voisine de la pr´c´dente ` ceci pr`s e e e a e que l’OID exact de la variable est d´termin´ en prenant le plus proche e e dans l’ordre lexicographique (d’ou le sens de “ next ”). SetRequest C’est une demande du manager ` l’agent pour positionner une a certaine valeur ` chacune des variables list´es. a e GetResponse C’est la r´ponse ` toutes les requˆtes Get/Set qui pr´c`dent. e a e e e Trap Envoy´ depuis l’agent vers le manager, associ´ ` une liste de couples e ea (variable,valeur). Il n’y a pas de r´ponse ` un trap. e a Auquels SNMPv2 en ajoute deux autres : GetBulkRequest Pour r´cup´rer des donn´es de grande taille, c’est ` dire e e e a des morceaux complets de l’arbre. Les deux champs non repeaters et max repetitions servent alors ` param`trer les limites de ce transfert, a e dans la limite de la taille d’un message. InformRequest Sert ` la communication entre managers. Une station d’ad- a ministration envoie des donn´es vers une autre station qui centralise les e informations contenues dans la MIB “ manager to manager ”. Le mes- sage a le mˆme format qu’un Get. Ce type de message est une sorte de e m´canisme de traps entre managers (configuration d’alarmes, ensemble e d’´vˆnements choisis). e e Ainsi le champ PDU type peut-il prendre l’une de ces sept valeurs et conduire ` autant de PDUs diff´rents, en taille et en signification. a e Chaque champ de l’en-tˆte SNMP ` une taille variable, selon e a l’impl´mentation des OIDs de la MIB. e PDU type Valeur ` prendre dans la liste get-request, get-next-request, a get-bulk-request, response, set-request, inform-request, snmpv2-trap. RequestID C’est un num´ro de requˆte, la r´ponse doit porter le mˆme e e e e num´ro que celui de la requˆte. e e Error-status Une valeur non nulle indique une erreur pendant le traitement de la requˆte. e Error-index Quand error-status n’est pas nul, ce champ identifie le num´ro d’ordre du couple (variable,valeur) qui pose probl`me. Le pre- e e mier a 1 comme index. (variable,valeur) Il s’agit de couple, la variable est un OID et la valeur est celle associ´e ` l’OID. e a
  • Protocole SNMP 2375.3 SNMPv3
  • 238 Gestion de r´seaux avec SNMP e 6 L’outil NET-SNMP D’abord nomm´ UCD-SNMP au d´but des ann´es 1990 ` l’universit´ de e e e a e Carnegie-Mellon, le projet s’est transform´ en NET-SNMP au d´but des ann´ees e e e 2000 et est maintenant la base de nombreux outils open-source ou non. Sa fiabilit´ est telle qu’un OS industriel tel que Solaris 109 n’h´site pas ` le e e a placer dans son “ core OS ” : #solaris10$ /usr/sfw/sbin/snmpd -version NET-SNMP version: 5.0.9 Web: http://www.net-snmp.org/ Email: net-snmp-coders@lists.sourceforge.net L’outil net-snmp est d’abord un outil d’administrateur syst`me donc e est essentiellement compos´ de commandes ` taper dans un shell. Il existe e a d’autres approches plus graphiques, nous donnerons quelques pistes dans le paragraphe suivant. Commandes pour interroger un agent : snmpget, snmpgetnext, snmpwalk snmptable,snmpdelta Commande pour positionner une valeur : snmpset Un daemon pour recevoir les notifications : snmptrapd Un agent : snmpd Nous allons mettre en œuvre quelques exemples d’usage de ces outils avec certains des OIDs de la MIB-2. On suppose que la machine localhost est accessible avec public comme valeur pour la communaut´ d’acc`s en mode e e lecture seule. 6.1 snmptranslate Dans sa forme la plus simple cette commande prend un OID et affiche la valeur textuelle correspondante. Prenons le cas de l’uptime c’est ` dire a au sens de SNMP le nombre de centi`mes de seconde ´coul´es depuis que la e e e partie r´seau a ´t´ initialis´e. Son nom textuel est SNMPv2-MIB::sysUpTime. e ee e $ snmptranslate -On SNMPv2-MIB::sysUpTime .1.3.6.1.2.1.1.3 $ snmptranslate -Of SNMPv2-MIB::sysUpTime.0 .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance On peut ´galement utiliser une expression r´guli`re : e e e 9 http://www.sun.com
  • L’outil NET-SNMP 239$ snmptranslate -TB sys.*TimeSNMPv2-MIB::sysORUpTimeSNMPv2-MIB::sysUpTimeDISMAN-EVENT-MIB::sysUpTimeInstanceHOST-RESOURCES-MIB::hrSystemUptimeMais aussi l’utiliser pour obtenir plus d’information sur l’OID :$ snmptranslate -On -Td SNMPv2-MIB::sysUpTime.1.3.6.1.2.1.1.3sysUpTime OBJECT-TYPE -- FROM SNMPv2-MIB, RFC1213-MIB SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized."::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 3 }$ snmptranslate -IR -Tp SNMPv2-MIB::system+--system(1) | +-- -R-- String sysDescr(1) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- ObjID sysObjectID(2) +-- -R-- TimeTicks sysUpTime(3) | | | +--sysUpTimeInstance(0) | +-- -RW- String sysContact(4) | Textual Convention: DisplayString | Size: 0..255 +-- -RW- String sysName(5) | Textual Convention: DisplayString | Size: 0..255 +-- -RW- String sysLocation(6) | Textual Convention: DisplayString | Size: 0..255 +-- -R-- INTEGER sysServices(7) | Range: 0..127 +-- -R-- TimeTicks sysORLastChange(8) | Textual Convention: TimeStamp | +--sysORTable(9) | +--sysOREntry(1) | Index: sysORIndex | +-- ---- INTEGER sysORIndex(1) | Range: 1..2147483647 +-- -R-- ObjID sysORID(2) +-- -R-- String sysORDescr(3) | Textual Convention: DisplayString
  • 240 Gestion de r´seaux avec SNMP e | Size: 0..255 +-- -R-- TimeTicks sysORUpTime(4) Textual Convention: TimeStamp Le lecteur curieux d’en savoir plus pourra essayer la commande snmptranslate -IR -Tp ! L’extrait suivant de la MIB montre le d´but de la e description du groupe system.
  • L’outil NET-SNMP 241 1 −− the System group 2 3 −− Implementation of the System group is mandatory for all 4 −− systems. If an agent is not configured to have a value 5 −− for any of these variables, a string of length 0 is 6 −− returned. 7 8 sysDescr OBJECT−TYPE 9 SYNTAX DisplayString (SIZE (0..255)) 10 ACCESS read−only 11 STATUS mandatory 12 DESCRIPTION 13 "A textual description of the entity. This value 14 should include the full name and version 15 identification of the system’s hardware type, 16 software operating−system, and networking 17 software. It is mandatory that this only contain 18 printable ASCII characters." 19 ::= { system 1 } 20 21 sysObjectID OBJECT−TYPE 22 SYNTAX OBJECT IDENTIFIER 23 ACCESS read−only 24 STATUS mandatory 25 DESCRIPTION 26 "The vendor’s authoritative identification of the 27 network management subsystem contained in the 28 entity. This value is allocated within the SMI 29 enterprises subtree (1.3.6.1.4.1) and provides an 30 easy and unambiguous means for determining ‘what 31 kind of box’ is being managed. For example, if 32 vendor ‘Flintstones, Inc.’ was assigned the 33 subtree 1.3.6.1.4.1.4242, it could assign the 34 identifier 1.3.6.1.4.1.4242.1.1 to its ‘Fred 35 Router’." 36 ::= { system 2 } 37 38 sysUpTime OBJECT−TYPE 39 SYNTAX TimeTicks 40 ACCESS read−only 41 STATUS mandatory 42 DESCRIPTION 43 "The time (in hundredths of a second) since the 44 network management portion of the system was last 45 re−initialized." 46 ::= { system 3 } 47 48 sysContact OBJECT−TYPE 49 SYNTAX DisplayString (SIZE (0..255)) 50 ACCESS read−write 51 STATUS mandatory 52 DESCRIPTION 53 "The textual identification of the contact person 54 for this managed node, together with information 55 on how to contact this person." 56 ::= { system 4 } 57 58
  • 242 Gestion de r´seaux avec SNMP e 6.2 snmpget Cette commande correspond ` l’op´ration la plus ´l´mentaire du protocole a e ee SNMP, aller chercher l’information relative ` un OID pr´cis sur un agent. a e $ snmpget -v 2c -c public localhost SysUpTimeInstance DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (33310293) 3 days, 20:31:42.93 $ snmpget -v 2c -c public localhost SNMPv2-MIB::sysLocation SNMPv2-MIB::sysLocation = No Such Instance currently exists at this OID Une erreur courante avec cette commande est d’oublier l’index (“ instance subidentifier ”) de la donn´e demand´e. Le cas le plus courant est pour les e e donn´es de type scalaire, il n’y a qu’une seule valeur alors il ne semble pas e n´cessaire de pr´ciser un index. Cet index est toujours un simple z´ro (0) e e e comme l’exemple ci-dessous le montre. $ snmpget -v 2c -c public localhost SNMPv2-MIB::sysLocation.0 SNMPv2-MIB::sysLocation.0 = STRING: S110 Ce point de d´tail technique s’av`re vite lassant, c’est pourquoi on utilise e e plus fr´quemment la commande suivante. . . e 6.3 snmpgetnext $ snmpgetnext -v 2c -c public localhost SNMPv2-MIB::sysUpTime.0 SNMPv2-MIB::sysContact.0 = STRING: Francois Laissus La commande renvoie la valeur associ´e ` l’OID (ou aux OIDs) suivant, e a ainsi on a l’impression que l’exemple ci-dessus est difficilement utilisable en pratique ! En fait il n’en est rien et l’exemple suivant devrait dissiper cette fausse impression : $ snmpgetnext -v 2c -c public localhost SNMPv2-MIB::sysUpTime DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (34853433) 4 days, 0:48:54.33 Un usage tr`s employ´ de cette commande est de l’utiliser avec une OID e e incompl`te, par exemple sans l’index (“ instance subidentifier ”) et l’agent e en d´termine la prochaˆ instance compl`te associ´e ` sa valeur. C’est une e ıne e e a sorte de m´canisme rudimentaire de compl´tion. e e 6.4 snmpwalk Cette commande effectue des requˆte de type get-next pour explorer toute e l’arborescence des sous-arbres li´s ` un OID. Par exemple : e a $ snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.5 IP-MIB::icmpInMsgs.0 = Counter32: 205413 IP-MIB::icmpInErrors.0 = Counter32: 0 IP-MIB::icmpInDestUnreachs.0 = Counter32: 205039
  • L’outil NET-SNMP 243IP-MIB::icmpInTimeExcds.0 = Counter32: 43IP-MIB::icmpInParmProbs.0 = Counter32: 0IP-MIB::icmpInSrcQuenchs.0 = Counter32: 0IP-MIB::icmpInRedirects.0 = Counter32: 0IP-MIB::icmpOutDestUnreachs.0 = Counter32: 203947... Permet d’acc´der d’un seul coup ` toutes les compteurs relatifs ` SNMP e a a(la sortie a ´t´ tronqu´e). Le lecteur pourra essayer l’OID 1.3.6 en argu- ee ement. . .6.5 snmptable Comme son nom le sugg`re, cette commande est plutˆt utilis´e pour ma- e o enipuler des tables. Ici il s’agit de la liste des interfaces et de leurs compteursassoci´s. e$ snmptable -v 2c -c public -Os -Cw 80 localhost ifTableSNMP table: ifTable ifIndex ifDescr ifType ifMtu ifSpeed ifPhysAddress ifAdminStatus 1 em0 ethernetCsmacd 1500 1000000000 0:6:5b:f:5a:31 up 2 em1 ethernetCsmacd 1500 1000000000 0:6:5b:f:5a:32 down 3 lo0 softwareLoopback 16384 0 upSNMP table ifTable, part 2 ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ifInDiscards up 0:0:00:00.00 2318958978 2767895021 2 0 down 0:0:00:00.00 0 0 0 0 up 0:0:00:00.00 90441064 717640 0 0SNMP table ifTable, part 3 ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts 0 0 2137908126 2767886776 0 0 0 0 0 0 0 0 90441687 717644 0SNMP table ifTable, part 4 ifOutDiscards ifOutErrors ifOutQLen ifSpecific 0 0 ? ? 0 0 ? ? 0 0 ? ?6.6 snmpset Pour changer la valeur d’une donn´e, donc d´conseill´ en SNMPv2. e e e
  • 244 Gestion de r´seaux avec SNMP e 6.7 Approche graphique Ce premier exemple graphique montre un outil open-source nomm´ e 10 mbrowse simple et bien commode pour interroger n’importe quel agent ` a partir d’un interface graphique assez intuitif. figure XI.05 — Exemple d’interrogation d’un agent avec l’outil mbrowse Dans un deuxi`me exemple, il s’agit d’extraire le contenu de la table e ifTable, comme nous avons pu le faire pr´c´demment avec snmptable, e e ce coup-ci avec la commande snmpwalk, puis de traiter graphiquement le r´sultat. e $ snmpwalk -c public -v2c gw ifTable IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifDescr.1 = STRING: fxp0 IF-MIB::ifDescr.2 = STRING: plip0 IF-MIB::ifDescr.3 = STRING: lo0 10 http://www.kill-9.org/mbrowse/
  • L’outil NET-SNMP 245IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)IF-MIB::ifType.2 = INTEGER: para(34)IF-MIB::ifType.3 = INTEGER: softwareLoopback(24)IF-MIB::ifMtu.1 = INTEGER: 1500IF-MIB::ifMtu.2 = INTEGER: 1500IF-MIB::ifMtu.3 = INTEGER: 16384IF-MIB::ifSpeed.1 = Gauge32: 100000000IF-MIB::ifSpeed.2 = Gauge32: 0IF-MIB::ifSpeed.3 = Gauge32: 0IF-MIB::ifPhysAddress.1 = STRING: 0:2:b3:3d:22:5IF-MIB::ifPhysAddress.2 = STRING:IF-MIB::ifPhysAddress.3 = STRING:...IF-MIB::ifInOctets.1 = Counter32: 29017357...IF-MIB::ifOutOctets.1 = Counter32: 3117625... O` l’on s’apper¸oit que cette machine a trois interfaces, nomm´es respec- u c etivement fxp0, plip0 et lo0. On voit ´galement que le mtu de l’interface ede loopback (lo0) est de 16384 octets et que l’interface fxp0 est le seul quitravaille r´ellement au vu des compteurs qui lui sont associ´s, 29017357 oc- e etets en entr´e et 3117625 en sortie, depuis que la machine est en route (voir esysUpTime). Bien entendu cette approche manuelle est trop lourde pour ˆtre utilis´e e etelle que pour surveiller un r´seau ! Il est indispensable d’utiliser des outils ecapables de faire la synth`se de tous ces compteurs, par exemple pour les epr´senter sous forme graphique. L’outil mrtg11 est capable de produire tr`s e esimplement un tel graphique avec jusqu’` une ann´e d’historique pour n’im- a eporte quel interface : figure XI.06 — Synth`se graphique des compteurs ifInOctets et ifOutOctets sur e 24h Il existe d’autres MIBs, notamment applicatives comme celle d´finie par ela RFC 1611 qui concerne le serveur de noms et celle d´finie par la RFC 2790 equi concernes les ressources de l’hˆte lui-mˆme (espace disque, charge...) et o eque l’on peut surveiller ´galement avec l’outil mrtg. Il est ainsi ais´ de faire e edes graphiques d’usage de la m´moire, des disques, de la charge de la machine, eetc. . . 11 http://oss.oetiker.ch/mrtg/
  • 246 Gestion de r´seaux avec SNMP e
  • 7 Glossaire des acronymes SNMP 247 La page pr´c´dente est un exemple d’´cran de surveillance d’un r´seau e e e eaujourd’hui compl`tement d´mantel´, et obtenu ` l’aide de l’outil open-source e e e atkined !7 Glossaire des acronymes SNMPAgent C’est le logiciel embarqu´ dans l’hˆte r´seau, quel qu’il soit. Il fonc- e o e tionne en mode serveur et est ` l’´coute en UDP sur le port 161 (snmp) a e Il est ´galement susceptible d’envoyer des “ traps ” vers le port 162 du e ou des manager(s).ASN1 “ Abstract Syntax Notation One ” est une norme internationale 12 dont la vocation premi`re est la sp´cification de donn´es utilis´es dans e e e e les protocoles de communication.BER “ Basic Encoding Rules ” M´thode d’encodage des valeurs pour tous e les types d´finis dans ASN.1. eManager Le logiciel de supervision. Il interroge les agents dans une relation de type client – serveur dont il assume la partie cliente. Le manager est destinataire des “ traps ”, qu’il r´ceptionne en UDP sur le port 162 e (snmptrap).MIB “ Management Information Base ”. C’est la description de tous les composants logiciels ou mat´riels surveill´s par l’agent. Chaque com- e e posant est d´sign´ par son OID. La MIB est ´crite ` l’aide du langage e e e a ASN.1 et selon une SMI bien pr´cise. C’est un arbre, dont les nœu ds e et les feuilles sont rep´r´s de mani`re unique par un chiffre. ee eNMA “ Network Management Application ”. Est une autre mani`re, non e sp´cifique ` SNMP, de d´signer le manager. e a eNME “ Network Management Entity ”. Est une autre mani`re, non e sp´cifique ` SNMP, de d´signer l’agent. e a eNMS “ Network Management Software ”. Synonyme de NMA.OID “ Object IDentifier ”. C’est la d´signation unique d’un objet dans la e structure en arbre de la MIB.PDU “ Protocol Data Unit ”. Il s’agit des paquets r´seau, structur´s selon e e le d´tail du protocol applicatif SNMP. eRMON “ Remote Network Monitoring ”. Il s’agit d’un agent particulier dont l’objet est la surveillance du r´seau lui mˆme et non un hˆte en e e o particulier. On d´signe souvent ces agents sous la terminologie de sonde e RMON.SMI “ Structure of Management Information ”. C’est la description du contenu et du formatage des donn´es d’une MIB. e 12 http ://asn1.elibel.tm.fr/fr/
  • 248 Gestion de r´seaux avec SNMP e SNMP “ Simple Network Management Protocol ”. C’est le nom du proto- cole r´seau qui sert ` interroger les agents/sondes RMON. e a Trap C’est un message d’exception envoy´ depuis l’agent vers le port 162 e du (des) manager(s). 8 Liens & Bibliographie Quelques RFCs minimales et en nombre non exhaustif ! RFC 1115, 1156, 1157, 1213, 1901 ` 1908, 3411 ` 3418 a a Des urls : ◦ Pour ASN.1 http://www.asn1.org/ http://asn1.elibel.tm.fr/ http://www.itu.int/ITU-T/asn1/ ◦ Pour SNMP lui-mˆme : e http://www.snmplink.org/ http://www.faqs.org/faqs/snmp-faq/part1/index.html http://www.faqs.org/faqs/snmp-faq/part2/index.html http://www.net-snmp.org/wiki/index.php/Tutorials http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNM ◦ Quelques outils en vrac : Net-Snmp http://net-snmp.sourceforge.net/ Mrtg http://oss.oetiker.ch/mrtg/ Scotty http://wwwhome.cs.utwente.nl/~schoenw/scotty/ Mbrowse http://www.kill-9.org/mbrowse/ Quelques ouvrages de r´f´rence : ee ◦ William Stalling — “ SNMPv1, SNMPv2, SNMPv3 and RMON 1 and 2 ” (third Edition) — Addison–Wesley 1999. ◦ Douglas R. Mauro and Kevin J. Schmidt — “ Essential SNMP ” — O’Reilly 2001. ◦ W. Richard Stevens — “ TCP/IP Illustrated, Volume 1 - The proto- cols ” — Addison-Wesley
  • Quatri`me partie eSockets BSD et architecture de serveurs
  • Chapitre XII G´n´ralit´s sur les sockets de e e eBerkeley1 G´n´ralit´s e e e La version BSD 4.1c d’Unix pour VAX, en 1982, a ´t´ la premi`re ` inclure ee e aTCP/IP dans le noyau du syst`me d’exploitation et ` proposer une interface e a 1de programmation de ces protocoles : les sockets . Les sockets sont ce que l’on appelle une API (“ Application ProgramInterface ”) c’est ` dire une interface entre les programmes d’applications aet la couche transport, par exemple TCP ou UDP. N´anmoins les sockets ene sont pas li´es ` TCP/IP et peuvent utiliser d’autres protocoles comme e aAppleTalk, X´rox XNS, etc. . . e Application Programmes applicatifs API = sockets Transport Noyau du système Internet Réseau Pilotes de périphériques Matériel figure XII.01 — Les sockets, une famille de primitives Les deux principales API pour Unix sont les sockets Berkeley et les TLISystem V. Ces deux interfaces ont ´t´ d´velopp´es en C. ee e e Les fonctionnalit´s des sockets que nous allons d´crire, sont celles appa- e erues ` partir de la version 4.3 de BSD Unix, en 1986. Il faut noter que les a 1 Pour un historique tr`s int´ressant de cette p´riode on pourra consulter http://www. e e eoreillynet.com/pub/a/network/2000/03/17/bsd.html
  • 252 Sockets de Berkeley constructeurs de stations de travail comme HP, SUN2 , IBM, SGI, ont adopt´ e ces sockets, ainsi sont-elles devenues un standard de fait et une justification de leur ´tude. e Pour conforter ce point de vue il n’est pas sans int´rˆt d’ajouter que toutes ee les applications majeures (named, dhcpd, sendmail, ftpd, apache,. . .) “ Open Sources ” de l’Internet, utilisent cette API. Enfin, et avant d’entrer dans le vif du sujet, le sch´ma ci-dessous rappelle e ◦ les relations entre pile ARPA, N de port et processus. Application Processus Application utilisateurs ... Noyau ... Transport Mécanisme Transport de gestion des ports Internet (session). Internet Réseau Réseau figure XII.02 — Relation pile IP, num´ro de port et process ID e 2 Pr´sentation des sockets e Les cr´ateurs des sockets ont essay´ au maximum de conserver la e e s´mantique des primitives syst`mes d’entr´es/sorties sur fichiers comme open, e e e read, write, et close. Cependant, les m´canismes propres aux op´rations e e sur les r´seaux les ont conduits ` d´velopper des primitives compl´mentaires e a e e (par exemple les notions de connexion et d’adresse IP n’existent pas lorsque l’on a besoin d’ouvrir un fichier !). Quand un processus ouvre un fichier (open), le syst`me place un pointeur e sur les structures internes de donn´es correspondantes dans la table des des- e cripteurs ouverts de ce processus et renvoie l’indice utilis´ dans cette table. e Par la suite, l’utilisateur manipule ce fichier uniquement par l’interm´diaire e de l’indice, aussi nomm´ descripteur de fichier. e Comme pour un fichier, chaque socket active est identifi´e par un petit e entier appel´ descripteur de socket. Unix place ce descripteur dans la mˆme e e 2 Les applications natives de ce constructeur utilisent les TLI, par contre il est possible d’utiliser les sockets dans toutes les applications que l’on recompile soi-mˆme, elles sont e pr´sentes dans des biblioth`ques pr´cis´es lors de la compilation des sources e e e e
  • ´3 Etude des primitives 253table que les descripteurs de fichiers, ainsi une application ne peut-elle pasavoir un descripteur de fichier et un descripteur de socket de mˆme valeur. e Pour cr´er une socket, une application utilisera la primitive socket et enon open, pour les raisons que nous allons examiner. En effet, il seraittr`s agr´able si cette interface avec le r´seau conservait la s´mantique des e e e eprimitives de gestion du syst`me de fichiers sous Unix, malheureusement eles entr´es/sorties sur r´seau mettent en jeux plus de m´canismes que les e e eentr´es/sorties sur un syst`me de fichiers, ce n’est donc pas possible. e eIl faut consid´rer les points suivants : e 1. Dans une relation du type client-serveur les relations ne sont pas sy- m´triques. D´marrer une telle relation suppose que le programme sait e e quel rˆle il doit jouer. o 2. Une connexion r´seau peut ˆtre du type connect´e ou non. Dans le e e e premier cas, une fois la connexion ´tablie le processus origine discute e uniquement avec le processus destinataire. Dans le cas d’un mode non connect´, un mˆme processus peut envoyer plusieurs data-grammes ` e e a plusieurs autres processus sur des machines diff´rentes. e 3. Une connexion est d´finie par un quintuplet (cf cours TCP page 89) e qui est beaucoup plus compliqu´ qu’un simple nom de fichier. e 4. L’interface r´seau supporte de multiples protocoles comme XNS, IPX, e APPLETALK3 , la liste n’est pas exhaustive. Un sous syst`me de gestion e de fichiers sous Unix ne supporte qu’un seul format. En conclusion de ce paragraphe on peut dire que le terme socket d´signe, ed’une part un ensemble de primitives, on parle des sockets de Berkeley, etd’autre part l’extr´mit´ d’un canal de communication (point de communi- e ecation) par lequel un processus peut ´mettre ou recevoir des donn´es. Ce e epoint de communication est repr´sent´ par une variable enti`re, similaire ` e e e aun descripteur de fichier.3 ´ Etude des primitives Ce paragraphe est consacr´ ` une pr´sentation des primitives essentielles ea epour programmer des applications en r´seaux. Pour ˆtre bien complet il est e efortement souhaitable de consulter les pages de manuels associ´es aux primi- etives et la documentation cit´e en fin de chapitre page 273. e3.1 Cr´ation d’une socket e La cr´ation d’une socket se fait par l’appel syst`me socket. e e 3 L’inspection du fichier /usr/include/sys/socket.h sous FreeBSD 6.x en expliciteune petite quarantaine
  • 254 Sockets de Berkeley #include <sys/types.h> /* Pour toutes les primitives */ #include <sys/socket.h> /* de ce chapitre il faut */ #include <netinet/in.h> /* inclure ces fichiers. */ int socket(int PF, int TYPE, int PROTOCOL) ; PF Sp´cifie la famille de protocole (“ Protocol Family ”) ` utiliser avec la e a socket. On trouve (extrait) par exemple sur FreeBSD 4 7.0 : PF INET : Pour les sockets IPv4 PF INET6 : Pour les sockets IPv6 PF LOCAL : Pour rester en mode local (pipe). . . PF UNIX : Idem AF LOCAL PF ROUTE : Acc`s ` la table de routage e a PF KEY : Acc`s ` une table de clefs (IPsec) e a PF LINK : Acc`s ` la couche “ Link ” e a Mais il existe d’autres impl´mentations notamment avec les proto- e coles5 : PF APPLETALK : Pour les r´seaux Apple e PF NS : Pour le protocole Xerox NS PF ISO : Pour le protocole de l’OSI PF SNA : Pour le protocole SNA d’IBM PF IPX : Protocole Internet de Novell PF ATM : “ Asynchronous Transfert Mode ” ... : ... Le pr´fixe PF est la contraction de “ Protocol Family ” On peut e ´galement utiliser le pr´fixe AF, pour “ Address Family ”. Les deux e e nommages sont possibles ; l’´quivalence est d´finie dans le fichier d’en- e e tˆte socket.h. e TYPE Cet argument sp´cifie le type de communication d´sir´. En fait avec e e e la famille PF INET, le type permet de faire le choix entre un mode connect´, un mode non connect´ ou une intervention directe dans la e e couche IP : SOCK STREAM : Mode connect´ e Couche transport SOCK DGRAM : Mode non connect´ e Idem SOCK RAW : Dialogue direct avec la couche IP Faut-il repr´ciser que seules les sockets en mode connect´ permettent e e les liaisons “ full-duplex ” ? PROTOCOL Ce troisi`me argument permet de sp´cifier le protocole ` uti- e e a 6 liser. Il est du type UDP ou TCP le plus couramment . 4 www.freebsd.org 5 On en compte 38 sur une machine FreeBSD 7.0 (22/10/2008) 6 il en existe au mois un autre pour les sockets de type PF INET et PF INET6, nomm´ e SCTP et qui n’est pas (encore) trait´ dans ce cours e
  • ´Etude des primitives 255 IPPROTO TCP : TCP IPPROTO SCTP : SCTP IPPROTO UDP : UDP IPPROTO RAW, IPPROTO ICMP : uniquement avec SOCK RAW PROTOCOL est typiquement mis ` z´ro car l’association de la famille de a e protocole et du type de communication d´finit explicitement le proto- e cole de transport : PF INET + SOCK STREAM =⇒ TCP = IPPROTO TCP PF INET + SOCK DGRAM =⇒ UDP = IPPROTO UDP C’est une constante d´finie dans le fichier d’en-tˆtes e e /usr/include/netinet/in.h et qui refl`te le contenu du fichier e syst`me /etc/protocols. e3.1.1 Valeur retourn´e par socket e La primitive socket retourne un entier qui est le descripteur de la socketnouvellement cr´´e par cet appel. ee Par rapport ` la connexion future cette primitive ne fait que donner le apremier ´l´ment du quintuplet : ee {protocole, port local, adresse locale, port ´loign´, adresse ´loign´e} e e e e Si la primitive renvoie -1, la variable globale errno donne l’indice du mes-sage d’erreur idoine dans la table sys errlist, que la biblioth`que standard e 7sait parfaitement exploiter .Remarque importante : Comme pour les entr´es/sorties sur fichiers, un appel syst`me fork du- e eplique la table des descripteurs de fichiers ouverts du processus p`re dans le eprocessus fils. Ainsi les descripteurs de sockets sont ´galement transmis. e Le bon usage du descripteur de socket partag´ entre les deux processus eincombe donc ` la responsabilit´ du programmeur. a e Enfin, quand un processus a fini d’utiliser une socket il appelle la primitiveclose avec en argument le descripteur de la socket : close(descripteur de socket) ; Si un processus ayant ouvert des sockets vient ` s’interrompre pour une araison quelconque, en interne la socket est ferm´e et si plus aucun processus en’a de descripteur ouvert sur elle, le noyau la supprime. 7 cf man errno ou la page de manuel de perror(3)
  • 256 Sockets de Berkeley 3.2 Sp´cification d’une adresse e Il faut remarquer qu’une socket est cr´´e sans l’adresse de l’´metteur - ee e comprendre le couple (num´ro de port, adresse IP) - ni celle du destinataire. e Il y a deux couples ` pr´ciser, celui cot´ client et l’autre cot´ serveur. La a e e e primitive bind effectue cette op´ration pour la socket de l’hˆte local. e o 3.2.1 Sp´cification d’un num´ro de port e e L’usage d’un num´ro de port est obligatoire. Par contre le choix de sa e valeur est largement conditionn´ par le rˆle que remplit la socket : client e o versus serveur. S’il s’agit d’un serveur, l’usage d’une valeur de port “ bien connue ” est essentiel pour ˆtre accessible syst´matiquement par les clients (par exemple e e le port 25 pour un serveur SMTP ou 80 pour un serveur HTTP). ` A l’inverse, le codage de la partie cliente d’une application r´seau ne e n´cessite pas une telle pr´caution (sauf contrainte particuli`re dˆe au pro- e e e u tocole de l’application elle-mˆme) parceque le num´ro de port associ´ ` la e e e a socket cliente est communiqu´ au serveur via l’en-tˆte de la couche de trans- e e port choisie, d`s la prise de contact par le r´seau. e e Le serveur utilise alors la valeur lue dans l’en-tˆte pour r´pondre ` la e e a requˆte du client, quel que soit le choix de sa valeur initiale. L’´tablissement e e de cette valeur par le client peut donc ˆtre le r´sultat d’un automate, e e ´ventuellement d´brayable. e e 3.2.2 Sp´cification d’une adresse IP e Pour des raisons ´videntes de communication, il est n´cessaire de pr´ciser e e e l’adresse IP du serveur avec lequel on souhaite ´tablir un trafic r´seau. e e Par contre, concernant le choix sa propre adresse IP, c’est ` dire celle qui a va servir d’adresse pour le retour des datagrammes, un comportement par d´faut peut ˆtre choisi lors de la construction de la socket, qui consiste ` e e a laisser au noyau du syst`me le soin d’en choisir la valeur la plus appropri´e. e e Pour une machine unix standard mise en r´seau, c’est le cas par exemple e d’une station de travail, celle-ci poss`de au moins deux adresses IP : une sur e le r´seau local et une autre sur l’interface de loopback (cf page 75). La socket e est alors associ´e aux deux adresses IP, voire plus si la machine est du type e “ multi-homed ” (page 44). On peut ´galement choisir pour sa socket un comportement plus s´lectif, e e consistant ` n’´couter que sur une seule des adresses IP de la station. a e 3.2.3 La primitive bind La primitive bind effectue ce travail d’associer une socket ` una couple (adresse IP, num´ro de port) associ´s dans une structure de type e e sockaddr in, pour IPv4. Mais la primitive bind est g´n´raliste, ce qui e e
  • Sp´cification d’une adresse e 257explique que son prototype fasse ´tat d’une structure g´n´rique nomm´e e e e esockaddr, plutˆt qu’` une structure d´di´e d’un protocole particulier (IPv4 o a e eici). int bind(int sockfd, struct sockaddr *myaddr, socklen t addrlen) ; socket : Usage du descripteur renvoy´ par socket. e myaddr : La structure qui sp´cifie l’adresse locale que l’on veut e associer ` la socket pr´alablement ouverte. a e addrlen : Taille en octets de la structure qui contient l’adresse. sockaddr est constitu´e (dans sa forme POSIX) de deux octets qui rap- epellent la famille de protocole, suivis de 14 octets qui d´finissent l’adresse en eelle-mˆme. e3.2.4 Les structures d’adresses Avec la pr´sence de plus en plus effective d’IPv6, les impl´mentations e eles plus r´centes tiennent compte des recommandations de la RFC 34938 , eajoutent un champ sa len d’une longueur de 8 bits et font passer de 16 ` 8 abits la taille du champ sa family pour ne pas augmenter la taille globale dela structure.struct sockaddr { /* La structure */ uint8_t sa_len ; /* generique */ sa_family_t sa_family ; char sa_data[14] ;} ; sa len indique taille de la structure en octets, il est pr´sent au mˆme em- e eplacement dans toutes les variantes de cette structure et contient 16 (octets)pour une structure de type sockaddr in, ou 28 octets pour une structure detype sockaddr in6 (IPv6). Pour la famille PF INET (IPv4) cette structure se nomme sockaddr in,et est d´finie de la mani`re suivante : e estruct in_addr { unsigned long s_addr ; /* 32 bits Internet */} ;struct sockaddr_in { uint8_t sin_len ; /* Taille de la structure == 16 octets */ sa_family_t sin_family ; /* PF_INET (IPv4) */ in_port_t sin_port ; /* Numero de port sur 16 bits / NBO */ struct in_addr sin_addr ; /* Adresse IP sur 32 bits / NBO */ char sin_zero[8] ; /* Inutilises */} ; 8 Basic Socket Interface Extensions for IPv6
  • 258 Sockets de Berkeley struct sockaddr struct sockaddr_in struct sockaddr_in6 sa_len sin_len sin6_len sa_family sin_family sin6_family sin_port sin6_port sin_addr ... 16 octets sa_data Structure d’adresse 28 sin_zero pour octets IPv6 ... La structure générique socket IPv4 Socket IPv6 figure XII.03 — Structures d’adresses La primitive bind ne permet pas toutes les associations de num´ros dee port, par exemple si un num´ro de port est d´j` utilis´ par un autre processus, e ea e ou encore si l’adresse internet est invalide. Trois utilisations typiques de la primitive : 1. En r`gle g´n´ral les serveurs fonctionnent avec des num´ros de port e e e e bien connus (cf /etc/services). Dans ce cas bind indique au syst`me e “ c’est mon adresse, tout message re¸u ` cette adresse doit m’ˆtre ren- c a e voy´ ”. En mode connect´ ou non, les serveurs ont besoin de pr´ciser e e e cette information avant de pouvoir accepter les requˆtes des clients. e 2. Un client peut pr´ciser sa propre adresse, en mode connect´ ou non. e e 3. Un client en mode non connect´ a besoin que le syst`me lui assigne e e une adresse particuli`re, ce qui autorise l’usage des primitives read et e write traditionnellement d´di´es au mode connect´. e e e 3.2.5 Valeur retourn´e par bind e Bind retourne 0 si tout va bien, -1 si une erreur est intervenue. Dans ce cas la variable globale errno est positionn´e ` la bonne valeur. e a Cet appel syst`me compl`te l’adresse locale et le num´ro de port du quin- e e e tuplet qui qualifie une connexion. Avec bind+socket on a la moiti´ d’une e connexion, ` savoir un protocole, un num´ro de port et une adresse IP : a e {protocole, port local, adresse locale, port ´loign´, adresse ´loign´e} e e e e
  • Connexion ` une adresse distante a 2593.3 Connexion ` une adresse distante a Prendre l’initiative de l’´tablissement d’une connexion est typique de la ed´marche d’un client r´seau.. e e La primitive connect permet d’´tablir la connexion avec une socket dis- etante, suppos´e ` l’´coute sur un port connu ` l’avance de la partie cliente. e a e aSon usage principal est d’utiliser une socket en mode “ connect´ ”. L’usage ed’une socket en mode datagramme est possible mais a un autre sens (voirplus loin) et est moins utilis´. eLa primitive connect a le prototype suivant :int connect(int sockfd,const struct sockaddr *servaddr,socklen t addrlen) ; sockfd : Le descripteur de socket renvoy´ par la pri- e mitive socket. servaddr : La structure qui d´finit l’adresse du destina- e taire, du mˆme type que pour bind. e addrlen : La longueur de l’adresse, en octets.3.3.1 Mode connect´ e Pour les protocoles orient´s connexion, cet appel syst`me rend la main au e ecode utilisateur une fois ´tabli le circuit virtuel entre les deux piles TCP/IP. eDurant cette phase, des paquets sont ´chang´s comme nous avons pu d´j` e e eal’examiner page 89 dans le cas de TCP. Tant que cette connexion n’est pas compl`tement ´tablie au niveau de la e ecouche de transport, la primitive connect reste en mode noyau, et est doncbloquante vis ` vis du code de l’application. a Dans le cas g´n´ral, les clients n’ont pas besoin de faire appel ` bind e e aavant d’invoquer connect, la d´finition de la socket locale est compl´t´e e eeautomatiquement : le port est attribu´ automatiquement selon une d´marche e ed´crite page 276, et l’adresse IP est l’une de celles de l’interface qu’emprunte ele datagramme pour son routage initial9 .3.3.2 Mode datagramme Dans le cas d’un client en mode datagramme, un appel ` connect n’est apas faux mais il ne sert ` rien au niveau protocolaire, il redonne aussitˆt a ola main au code utilisateur. Le seul int´rˆt que l’on peut y trouver est que eel’adresse du destinataire est alors fix´e et que l’on peut alors utiliser les pri- emitives read, write, recv et send, traditionnellement r´serv´es au mode e econnect´. e 9 Est-il n´cessaire de rappeler qu’un interface peut comporter plusieurs adresses IP et equ’il peut y avoir plusieurs interfaces reseau sur un mˆme hˆte. . . ? e o
  • 260 Sockets de Berkeley 3.3.3 Valeur retourn´e par connect : e En cas d’erreur elle renvoie la valeur -1 et positionne la variable globale errno ` la valeur idoine, par exemple ` ETIMEOUT, s’il n’y a pas eu de r´ponse a a e ` l’´mission des paquets de synchronisation (cf page 94). Bien d’autres erreurs a e li´es ` des probl`mes du r´seau sont ` consulter dans la section ERRORS de la e a e e a page de manuel. Un code 0 indique que la connexion est ´tablie sans probl`me e e particulier. Tous les ´l´ments du quintuplet sont en place : ee {protocole, port local, adresse locale, port ´loign´, adresse ´loign´e} e e e e 3.4 Envoyer des donn´es e Une fois qu’un programme d’application a cr´´ une socket, il peut l’utiliser ee pour transmettre des donn´es. Il y a cinq primitives possibles pour ce faire : e send, write, writev, sendto, sendmsg 3.4.1 Envoi en mode connect´ e Send, write et writev fonctionnent uniquement en mode connect´, e parce-qu’elles n’offrent pas la possibilit´ de pr´ciser l’adresse du destinataire. e e Les diff´rences entre ces trois primitives sont mineures. e ssize t write(int descripteur, const void *buffer, size t longueur) ; Quand on utilise write, le descripteur d´signe l’entier renvoy´ par la e e primitive socket. Le buffer contient les octets ` transmettre, et longueur a leur cardinal. Tous les octets ne sont pas forc´ment transmis d’un seul coup, et ce n’est e pas une condition d’erreur. En cons´quence il est absolument n´cessaire de e e tenir compte de la valeur de retour de cette primitive, n´gative ou non. e La primitive writev est sensiblement la mˆme que write simplement elle e permet d’envoyer un tableau de structures du type iovec plutot qu’un simple buffer, l’argument vectorlen sp´cifie le nombre d’entr´es dans iovector : e e ssize t writev(int descriptor, const struct iovec *iovector, int vectorlen) ; La primitive send ` la forme suivante : a int send(int s, const void *msg, size t len, int flags) ; s D´signe l’entier renvoy´ par la primitive socket. e e
  • Envoyer des donn´es e 261msg Donne l’adresse du d´but de la suite d’octets ` transmettre. e alen Sp´cifie le nombre d’octets ` transmettre. e aflags Ce drapeau permet de param`trer la transmission du data-gramme, e notamment si le buffer d’´criture est plein ou si l’on d´sire, par exemple e e et avec TCP, faire un envoi en urgence (out-of-band) : 0 : Non op´rant, c’est le cas le plus courant. e MSG OOB : Pour envoyer ou recevoir des messages out-of-band. MSG PEEK : Permet d’aller voir quel message on a re¸u sans le lire, c c’est ` dire sans qu’il soit effectivement retir´ des buffers a e internes (ne s’applique qu’` recv (page 262). a3.4.2 Envoi en mode datagramme Les deux autres primitives, sendto et sendmsg donnent la possibilit´ ed’envoyer un message via une socket en mode non connect´. Toutes deux er´clament que l’on sp´cifie le destinataire ` chaque appel. e e a ssize t sendto(int s,const void *msg,size t len,int flags, const struct sockaddr *to, socklen t tolen) ; Les quatre premiers arguments sont exactement les mˆmes que pour send, eles deux derniers permettent de sp´cifier une adresse et sa longueur avec une estructure du type sockaddr, comme vu pr´c´demment avec bind. e e Le programmeur soucieux d’avoir un code plus lisible pourra utiliser ladeuxi`me primitive : essize t sendmsg(int sockfd, const struct msghdr *messagestruct,int flags) ; O` messagestruct d´signe une structure contenant le message ` envoyer u e asa longueur, l’adresse du destinataire et sa longueur. Cette primitive est tr`s ecommode ` employer avec son pendant recvmsg car elle travaille avec la amˆme structure. e
  • 262 Sockets de Berkeley 3.5 Recevoir des donn´es e Sym´triquement aux cinq primitives d’envoi, il existe cinq primitives de e r´ception : read, readv, recv, recvfrom, recvmsg. e 3.5.1 Reception en mode connect´ e La forme conventionnelle read d’Unix n’est possible qu’avec des sockets en mode connect´ car son retour dans le code utilisateur ne s’accompagne e d’aucune pr´cision quant ` l’adresse de l’´metteur. Sa forme d’utilisation est : e a e ssize t read(int descripteur, void *buffer,size t longueur) ; Bien sur, si cette primitive est utilis´e avec les sockets BSD, le descripteur e est l’entier renvoy´ par un appel pr´c´dent ` la primitive socket. buffer et e e e a longueur sp´cifie respectivement le buffer de lecture et la longueur de ce que e l’on accepte de lire. Chaque lecture ne renvoie pas forc´ment le nombre d’octets demand´s, e e mais peut ˆtre un nombre inf´rieur. e e Mais le programmeur peut aussi employer le readv, avec la forme : ssize t readv(int descripteur, const struct iovec *iov, int vectorlen) ; Avec les mˆme caract´ristiques que pour le readv. e e En addition aux deux primitives conventionnelles, il y a trois primitives nouvelles pour lire des messages sur le r´seau : e ssize t recv(int s, void *buf, size t len, int flags) ; s : L’entier qui d´signe la socket. e buf : Une adresse o` l’on peut ´crire, en m´moire. u e e len : La longueur du buffer. flags : Permet au lecteur d’effectuer un contrˆle sur les paquets lus. o 3.5.2 Recevoir en mode datagramme ssize t recvfrom(int s, void *buf,size t len, int flags,struct sockaddr *from, socklen t *fromlen) ; Les deux arguments additionnels par rapport ` recv sont des pointeurs a vers une structure de type sockaddr et sa longueur. Le premier contient l’adresse de l’´metteur. Notons que la primitive sendto fournit une adresse e dans le mˆme format, ce qui facilite les r´ponses. e e La derni`re primitive recvmsg est faite pour fonctionner avec son homo- e logue sendmsg : ssize t recvmsg(int sockfd, struct msghdr *messagestruct,int flags) ; La structure messagestruct est exactement la mˆme que pour sendmsg e ainsi ces deux primitives sont faites pour fonctionner de paire.
  • Sp´cifier une file d’attente e 2633.6 Sp´cifier une file d’attente e Imaginons un serveur en train de r´pondre ` un client, si une requˆte e a earrive d’un autre client, le serveur ´tant occup´, la requˆte n’est pas prise en e e ecompte, et le syst`me refuse la connexion. e La primitive listen est l` pour permettre la mise en file d’attente des ademandes de connexions. Elle est g´n´ralement utilis´e apr`s les appels de socket et de bind et e e e eimm´diatement avant le accept. e int listen(int sockfd, int backlog) ; sockfd : l’entier qui d´crit la socket. e backlog : Le nombre de connexions possibles en attente (quelques dizaines). La valeur maximale est fonction du pa- ram`trage du noyau. Sous FreeBSD la valeur maximale e par d´faut est de 128 (sans param`trage sp´cifique du e e e noyau), alors que sous Solaris 10, “ There is currently no backlog limit ”. Le nombre de fois o` le noyau refuse une connexion u est comptabilis´ et accessible au niveau de la ligne de e commande via le r´sultat de l’ex´cution de la com- e e mande netstat -s -p tcp (chercher “ listen queue overflow ”). Ce param`tre est important ` suivre dans e a le cas d’un serveur tr`s sollicit´. e e3.7 Accepter une connexion Accepter une connexion est typique de la d´marche d’un serveur sur le er´seau. e nous l’avons examin´, un serveur utilise les primitives socket, bind et elisten pour se pr´parer ` recevoir les connexions. Il manque cependant ` e a ace trio le moyen de dire au protocole “ j’accepte d´sormais les connexions eentrantes ”. La primitive accept est le chaˆınon manquant ! Quand le serveur invoque cette primitive, le noyau est pr´venu que le eprocessus est en attente d’un ´vˆnement r´seau le concernant. Le retour dans e e ele code de l’application ne fait que sous deux conditions, r´ception d’une edemande de connexion ou r´ception d’un signal par le processus. e int accept(int sockfd, struct sockaddr *addr, socklen t *addrlen) ;Qui s’utilise comme suit :int newsock ;newsock = accept(sockfd, addr, addrlen) ;sockfd descripteur de la socket, renvoy´ par la primitive du mˆme nom. e e
  • 264 Sockets de Berkeley addr Un pointeur sur une structure du type sockaddr. addlen Un pointeur sur un entier. Quand une connexion arrive, les couches sous-jacentes du protocole de transport remplissent la structure addr avec l’adresse du client qui fait la demande de connexion. Addrlen contient alors la longueur de cette adresse. Cette valeur peut ˆtre modifi´e par le noyau lorsque la primitive est uti- e e lis´e avec des sockets d’autres type pour lesquelles la taille de la structure e d’adresse est variable (sockaddr un pour les sockets locales par exemple), ce qui justifie un pointeur l` o` nous ne pourrions attendre qu’un simple a u passage d’argument par valeur. Puis le syst`me cr´e une nouvelle socket par clonage de celle transmise et e e pour laquelle il renvoie un descripteur, r´cup´r´ ici dans newsock. Par cet ar- e ee tifice, la socket originale reste disponible pour d’´ventuelles autres connexions e (elle est clon´e avant que le quintuplet soit complet). e En conclusion, lorsqu’une demande de connexion arrive, l’appel ` la pri- a mitive accept redonne la main au code utilisateur. 3.8 Terminer une connexion Dans le cas du mode connect´ on termine une connexion avec la primitive e close ou shutdown. int close(descripteur) ; La primitive bien connue sous Unix peut ˆtre aussi employ´e avec un des- e e cripteur de socket. Si cette derni`re est en mode connect´, le syst`me assure e e e que tous les octets en attente de transmission seront effectivement transmis dans de bonnes conditions. Normalement cet appel retourne imm´diatement, e cependant le kernel peut attendre le temps de la transmission des derniers octets (transparent). Le moyen le plus classique de terminer une connexion est de passer par la primitive close, mais la primitive shutdown permet un plus grand contrˆle o sur les connexions en “ full-duplex ”. int shutdown(int sockfd, int how) ; Sockfd est le descripteur ` fermer, how permet de fermer partiellement le a descripteur suivant les valeurs qu’il prend : 0 Aucune donn´e ne peut plus ˆtre re¸ue par la socket. e e c 1 Aucune donn´e ne peut plus ˆtre ´mise. e e e 2 Combinaison de 0 et de 1 (´quivalent de close). e Enfin, pour une socket en mode connect´, si un processus est interrompu e de mani`re inopin´e (r´ception d’un signal de fin par exemple), un “ reset ” e e e (voir page 92) est envoy´ ` l’hˆte distant ce qui provoque la fin brutale de la ea o connexion. Les octets ´ventuellement en attente sont perdus. e
  • 4 Sch´ma g´n´ral d’une session client–serveur e e e 2654 Sch´ma e g´n´ral e e d’une session client– serveur Il est temps de donner un aper¸u de la structure d’un serveur et d’un cclient, mettant en œuvre les APIs vus dans ce chapitre, et de rapprocher les´vˆnements r´seaux de ceux observables sur le syst`me et dans le processuse e e equi s’ex´cute. eRelation client–serveur en mode connect´ : e Serveur Client fd=socket() bind(fd)Etats de la socket : Etats de la socket : listen(fd) fd=socket() LISTEN fd2=accept(fd) Etablissement de SYN_RCVD connect(fd) SYN_SENT la connexion ESTABLISHED ESTABLISHED write(fd) read(fd2) Echanges applicatifs write(fd2) read(fd) FIN_WAIT_1 Fermeture de la CLOSE_WAIT FIN_WAIT_2 close(fd2) close(fd) LAST_ACK TIME_WAIT connexion CLOSED figure XII.04 — Relation client–serveur en mode connect´ e Il faut ´tablir une comparaison entre cette figure et les figures VI.03 epage 94 et VI.04 page 95. Les sockets cot´ client ou cot´ serveur, si elles e eparticipent ` l’´tablissement d’un canal de communication sym´trique en a e efonctionnement, ne passent pas par les mˆmes ´tats, de leur cr´ation jus- e e equ’au recyclage des octets qui les composent. La RFC 793 pr´cise 11 ´tats pour une socket et la figure ci-dessus les met e een situation de mani`re simplifi´e. Ces ´tats peuvent ˆtre visualis´s avec la e e e e ecommande netstat -f inet [-a], dans la colonne state de la sortie.LISTEN La socket du serveur est en attente passive d’une demande de con- nexion (ouverture passive).SYN-SENT C’est l’´tat de la socket cliente qui a envoy´ le premier paquet de e e demande d’une connexion avec un flag SYN mais non encore acquitt´ e (ouverture active).SYN-RCVD La socket du serveur ` re¸u un paquet de demande de connexion, a c l’acquitte et envoi sa propre demande de connexion. Elle attend l’ac- quittement de sa demande.
  • 266 Sockets de Berkeley ESTABLISHED Les demandes de connexions sont acquitt´es aux deux e extr´mit´s. La connexion est ´tablie. La totalit´ du trafic TCP ap- e e e e plicatif s’effectue dans cet ´tat. Sa dur´e est ind´finie, la clˆture est ` e e e o a l’initiative des applications. FIN-WAIT-1 Celui qui est ` l’initiative de l’envoi du premier paquet de de- a mande de fin est dans cet ´tat (fermeture active). e FIN-WAIT-2 On a re¸u l’acquittement ` la demande de fin de connexion. c a TIME-WAIT La socket ´tait en FIN-WAIT-2 et a re¸u la demande de fin de la e c socket distante. On doit attendre le temps suffisant pour ˆtre certain e que la socket distante a bien re¸u l’acquittement (re-´mission sinon). c e Cet ´tat peut donc ˆtre long dans le temps, 2×M SL pr´cise la RFC 793. e e e Cette constante peut aller de quelques dizaines de secondes ` une ou a deux minutes selon les impl´mentations. e CLOSE-WAIT La socket ´tait en ESTABLISHED et a re¸u une demande de fin. e c Cet ´tat perdure jusqu’` ce que la socket envoie ` son tour une demande e a a de fin (fermeture passive). CLOSING Si la r´ponse ` une demande de fin s’accompagne imm´diatement e a e de la demande de fin de la socket locale, cet ´tat remplace FIN-WAIT-1 e et FIN-WAIT-2. LAST-ACK La derni`re demande de fin est en attente du dernier acquittement. e ´ CLOSED Etat de fin. Les octets de la socket vont ˆtre recycl´s. e e L’´tat TIME-WAIT est support´ par celui qui clˆt la connexion. Les archi- e e o tectures de serveurs pr´f`rent une clˆture ` l’initiative du serveur, ce qui se ee o a comprend du point de vue de l’efficacit´ (rester maˆ de la dur´e de la com- e ıtre e munication), mais le fonctionnement interne du protocole TCP implique ce temps d’attente. Sur un serveur tr`s charg´ les sockets dans cet ´tat peuvent e e e ˆtre en tr`s grand nombre (des dizaines de milliers. . .) bloquant ainsi les e e nouvelles connexions entrantes. Relation client–serveur en mode non connect´ : e Serveur Client fd=socket() fd=socket() bind(fd) bind(fd) sendto(fd) recvfrom(fd) échanges applicatifs sendto(fd) recvfrom(fd) close(fd) close(fd) figure XII.05 — Relation client–serveur en mode non connect´ e
  • 5 Exemples de code “ client ” 2675 Exemples de code “ client ” L’objectif de ces deux exemples est de montrer le codage en C et le fonc-tionnement d’un client du serveur de date (RFC 867, “ daytime protocol ”)pr´sent sur toute machine unix10 . e Ce serveur fonctionne en mode connect´ ou non, sur le port 13 qui lui est er´serv´ (/etc/services). Ici le serveur est une machine portant l’adresse IP e e192.168.52.232. La connaissance de l’adresse IP du client n’est absolumentpas utile pour la compr´hension de l’exemple. e En mode TCP le simple fait de se connecter provoque l’´mission de la echaˆ ascii contenant la date vers le client et sa d´connexion. ıne e En mode UDP il suffit d’envoyer un datagramme quelconque (1 caract`re) eau serveur puis d’attendre sa r´ponse. e5.1 Client TCP “ DTCPcli ”Exemple d’usage :$ ./DTCPcli 192.168.52.232Date(192.168.52.232) = Wed Dec 10 20:59:46 2003 Une capture des trames r´seau ´chang´es lors de l’ex´cution de cette e e e ecommande se trouve page 270.ligne 29 D´claration de la structure saddr du type sockaddr in, ` utiliser e a avec IPv4. Attention, il s’agit bien d’une structure et non d’un pointeur de structure.ligne 35 La variable sfd, re¸oit la valeur du descripteur de socket. Celle-ci c est d´di´e au protocole TCP. e eligne 39 Le champ sin family de la structure saddr indique que ce qui suit (dans la structure) concerne IPv4.ligne 40 Le champ sin port est affect´ ` la valeur du num´ro de port sur ea e lequel ´coute le serveur. Il faut remarquer l’usage de la fonction htons e (en fait une macro du pr´-processeur cpp) qui s’assure que ce num´ro e e de port respecte bien le NBO (“ Network Byte Order ”), car cette valeur est directement recopi´e dans le champ PORT DESTINATION e du protocole de transport employ´ (voir page 84 pour UDP et page 91 e pour TCP). Nous en dirons plus sur htons au chapitre suivant. Si le processeur courant est du type “ little endian ” (architecture Intel par exemple) les octets sont invers´s (le NBO est du type “ big en- e dian ”). Vous croyez ´crire 13 alors qu’en r´alit´ pour le r´seau vous e e e e avez ´crit 3328 (0x0D00) ce qui bien ´videment ne conduit pas au mˆme e e e r´sultat, sauf si un serveur de date ´coute ´galement sur le port 3328, e e e non conventionnel donc tr`s peu probable ` priori. e a 10 Son activation est ´ventuellement ` faire ` partir du serveur de serveur inetd, page 320 e a a
  • 268 Sockets de Berkeley En r´sum´, si le programmeur n’utilise pas la fonction htons, ce code e e n’est utilisable que sur les machines d’architecture “ big endian ”. 1 /* $Id: DTCPcli.c 92 2009−02−12 17:39:44Z fla $ 2 * 3 * Client TCP pour se connecter au serveur de date (port 13 − RFC 867). 4 * La syntaxe d’utilisation est : DTCPcli <adresse ip sous forme décimale> 5 * 6 */ 7 8 #include <stdio.h> 9 #include <stdlib.h> 10 #include <string.h> 11 #include <unistd.h> 12 #include <sysexits.h> 13 14 #include <sys/types.h> 15 #include <sys/socket.h> 16 #include <sys/param.h> 17 #include <netinet/in.h> 18 #include <arpa/inet.h> 19 20 #define USAGE "Usage:%s adresse IP du serveurn" 21 #define MAXMSG 1024 22 #define NPORT 13 23 24 int 25 main(int argc, char *argv[]) 26 { 27 int n, sfd ; 28 char buf[MAXMSG] ; 29 struct sockaddr_in saddr ; 30 31 if (argc != 2) { 32 (void)fprintf(stderr,USAGE,argv[0]) ; 33 exit(EX_USAGE) ; 34 } 35 if ((sfd = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP)) < 0) { 36 perror("socket") ; 37 exit(EX_OSERR) ; 38 } 39 saddr.sin_family = AF_INET ; 40 saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */ 41 if(inet_pton(AF_INET,argv[1],&saddr.sin_addr) != 1) { 42 (void)fprintf(stderr,"Address «%s» is not parseable !n",argv[1] ) ; 43 exit(EX_DATAERR) ; 44 } 45 if (connect(sfd,(struct sockaddr *)&saddr,sizeof saddr) < 0) { 46 perror("connect") ; 47 exit(EX_OSERR) ; 48 } 49 if ((n = read(sfd, buf,MAXMSG−1)) < 0) { 50 perror("read") ; 51 exit(EX_OSERR) ; 52 } 53 buf[n] = ’0’ ; 54 (void)printf("Date(%s) = %sn",argv[1],buf) ; 55 exit(EX_OK) ; /* close(sfd) implicite */ 56 } Source du client “ DTCPcli.c ” ligne 41 Le champ s addr de la structure sin addr se voit affect´ de e l’adresse IP. C’est donc l’´criture de quatre octets (IPv4), pouvant com- e
  • 5 Exemples de code “ client ” 269 porter un caract`re ascii 0, donc interpr´table comme le caract`re de e e e fin de chaˆ du langage C. ıne C’est pourquoi ` cet endroit on ne peut pas employer les habituelles a fonctions de la biblioth`que standard (celles qui commencent par str). e Ici le probl`me se complique un peu dans la mesure o` l’on dispose e u au d´part d’une adresse IP sous sa forme d´cimale point´e. La gestion e e e d’erreur prot`ge le code des erreurs de syntaxe ` la saisie. e a La fonction inet pton g`re parfaitement ce cas de figure. Nous en e dirons plus ` son sujet au chapitre suivant. aligne 45 Appel ` la primitive connect pour ´tablir la connexion avec le a e serveur distant. Quand celle-ci retourne dans le code du programme, soit la connexion a ´chou´ et il faut traiter l’erreur, soit la connexion e e est ´tablie. L’´change pr´liminaire des trois paquets s’est effectu´ dans e e e e de bonnes conditions (page 94). Du point de vue TCP, les cinq ´l´ments du quintuplet qui caract´risent ee e la connexion sont d´finis (page 90). e Sur la capture des paquets de la page 270 nous sommes arriv´s ` la e a ligne 6, c’est ` dire l’envoi de l’acquittement par le client du paquet de a synchronisation envoy´ par le serveur (ligne 3 et 4). e Il faut noter que bien que nous ayons transmis la structure saddr par adresse (caract`re &) et non par valeur, la primitive connect ne modifie e pas son contenu pour autant. Notons ´galement l’usage du “ cast ” du C pour forcer le type du e pointeur (le prototype de la primitive exige ` cet endroit un pointeur a de type sockaddr).ligne 49 Appel ` la primitive read pour lire le r´sultat en provenance du a e serveur, ` l’aide du descripteur sfd. a Sur la capture d’´cran on voit ligne 8 (et 9) l’envoi de la date en pro- e venance du serveur, d’une longueur de 26 caract`res. e Ce nombre de caract`res effectivement lus est affect´ ` la variable n. e ea Ce nombre ne peut exc´der le r´sultat de l’´valuation de e e e M AXM SG − 1, qui correspond ` la taille du buffer buf moins 1 a caract`re pr´vu pour ajouter le caract`re 0 de fin de chaˆ e e e ıne. En effet, celui-ci fait partie de la convention de repr´sentation des e chaˆ ınes de caract`res du langage C. Rien ne dit que le serveur qui e r´pond ajoute un tel caract`re ` la fin de sa r´ponse. Le contraire est e e a e mˆme certain puisque la RFC 867 n’y fait pas mention. e Remarque : le buffer buf est largement surdimensionn´ compte tenu e de la r´ponse attendue. La RFC 867 ne pr´voit pas de taille maximum e e si ce n’est implicitement celle de l’expression de la date du syst`me en e anglais, une quarantaine d’octets au maximum.ligne 53 Ajout du caract`re de fin de chaˆ en utilisant le nombre de ca- e ıne ract`res renvoy´s par read. e e
  • 270 Sockets de Berkeley ligne 55 La sortie du programme induit une clˆture de la socket cot´ client. o e Cot´ serveur elle est d´j` ferm´e (s´quence write + close) comme on e ea e e peut le voir ligne 8 (flag FP, page 92) ci-apr`s dans la capture du trafic e entre le client et le serveur. Remarque : rien n’est explicitement pr´vu dans le code pour ´tablir la e e socket cot´ client, ` savoir l’association d’un num´ro de port et d’une adresse e a e IP. En fait c’est la primitive connect qui s’en charge. L’adresse IP est celle de la machine. Le num´ro de port est choisi dans la zone d’attribution auto- e matique comme nous l’avons examin´ page 85. e Il existe bien entendu une possibilit´ pour le programme d’avoir connais- e sance de cette information : la primitive getsockname. 1 23:03:29.465183 client.2769 > serveur.daytime: S 2381636173:2381636173(0) 2 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 299093825 0> (DF) 3 23:03:29.465361 serveur.daytime > client.2769: S 3179731077:3179731077(0) 4 ack 2381636174 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 5 4133222 299093825> (DF) 6 23:03:29.465397 client.2769 > serveur.daytime: . ack 1 win 57920 7 <nop,nop,timestamp 299093826 4133222> (DF) 8 23:03:29.466853 serveur.daytime > client.2769: FP 1:27(26) ack 1 win 57920 9 <nop,nop,timestamp 4133223 299093826> (DF) 10 23:03:29.466871 client.2769 > serveur.daytime: . ack 28 win 57894 11 <nop,nop,timestamp 299093826 4133223> (DF) 12 23:03:29.467146 client.2769 > serveur.daytime: F 1:1(0) ack 28 win 57920 13 <nop,nop,timestamp 299093826 4133223> (DF) 14 23:03:29.467296 serveur.daytime > client.2769: . ack 2 win 57920 15 <nop,nop,timestamp 4133223 299093826> (DF) Trafic “ daytime ” TCP, captur´ avec tcpdump e Un autre exemple d’interrogation, mais avec un autre hˆte du mˆme LAN o e mais sur lequel le service daytime n’est pas en fonctionnement : $ ./DTCPcli 192.168.52.232 connect: Connection refused 1 16:13:21.612274 IP client.57694 > serveur.daytime: S 2248945646:2248945646(0) 2 win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop, 3 timestamp 360942290 0> 4 16:13:21.612648 IP serveur.daytime > client.57694: R 0:0(0) ack 2248945647 win 0 Trafic “ daytime ” TCP (reset), captur´ avec tcpdump e L’envoi d’un reset (drapeau R) envoy´ par le serveur en guise de r´ponse e e est bien visible ligne 4.
  • 5 Exemples de code “ client ” 2715.2 Client UDP “ DUDPcli ”1 /* $Id: DUDPcli.c 92 2009−02−12 17:39:44Z fla $2 *3 * Client UDP pour se connecter au serveur de date (port 13 − RFC 867).4 * La syntaxe d’utilisation est : DUDPcli <adresse ip sous forme décimale>5 *6 */7 #include <stdio.h>8 #include <stdlib.h>9 #include <string.h>10 #include <unistd.h>11 #include <sysexits.h>1213 #include <sys/types.h>14 #include <sys/socket.h>15 #include <sys/param.h>16 #include <netinet/in.h>17 #include <arpa/inet.h>1819 #define USAGE "Usage:%s adresse IP du serveurn"20 #define MAXMSG 102421 #define NPORT 132223 int24 main(int argc, char *argv[])25 {26 int n, sfd ;27 char buf[MAXMSG] ;28 struct sockaddr_in saddr ;2930 if (argc != 2) {31 (void)fprintf(stderr,USAGE,argv[0]) ;32 exit(EX_USAGE) ;33 }34 if ((sfd = socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)) < 0) {35 perror("socket") ;36 exit(EX_OSERR) ;37 }38 saddr.sin_family = AF_INET ;39 saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */40 if (inet_pton(PF_INET,argv[1],&saddr.sin_addr) != 1) {41 (void)fprintf(stderr,"Address «%s» is not parseable !n",argv[1] ) ;42 exit(EX_DATAERR) ;43 }44 buf[0] = ’0’ ;45 if (sendto(sfd,buf,1,0,(struct sockaddr *)&saddr, sizeof saddr) != 1) {46 perror("sendto") ;47 exit(EX_OSERR) ;48 }49 if ((n=recv(sfd,buf,MAXMSG−1,0)) < 0) {50 perror("recv") ;51 exit(EX_OSERR) ;52 }53 buf[n] = ’0’ ;54 (void)printf("Date(%s) = %sn",argv[1],buf) ;55 exit(EX_OK) ; /* close(sfd) implicite */56 } Source du client “ DUDPcli.c ”Exemple d’usage :$ ./DUDPcli 192.168.52.232Date(192.168.52.232) = Wed Dec 10 20:56:58 2003
  • 272 Sockets de Berkeley ligne 34 Ouvertude d’une socket UDP, donc en mode non connect´. e ligne 45 Envoit d’un caract`re (NULL) au serveur, sans quoi il n’a aucun e moyen de connaˆ notre existence. ıtre ligne 38, 39 et 40 Le remplissage de la structure saddr est identique ` a celui de la version TCP. ligne 49 R´ception de caract`res en provenance du r´seau. e e e Il faut remarquer que rien n’assure que les octets lus sont bien en pro- venance du serveur de date interrog´.e Nous aurions pu utiliser la primitive recvfrom dont un des arguments est une structure d’adresse contenant justement l’adresse de la socket qui envoie le datagramme (ici la r´ponse du serveur). e Le raisonnement sur la taille du buffer est identique ` celui de la version a TCP. La capture de trames suivante montre l’extrˆme simplicit´ de l’´change e e e en comparaison avec celle de la version utilisant TCP ! 1 2 3 4 23:23:17.668689 client.4222 > serveur.daytime: udp 1 5 23:23:17.670175 serveur.daytime > client.4222: udp 26 Trafic “ daytime ” UDP, captur´ avec tcpdump e Un autre essai avec la machine 192.168.52.233 qui ne r´pond pas plus e sur le port 13 en UDP : 1 16:29:42.090816 IP client.55822 > serveur.daytime: UDP, length: 1 2 16:29:42.091205 IP serveur > client: icmp 36: serveur udp port daytime 3 unreachable Trafic “ daytime ” UDP (icmp), captur´ avec tcpdump e Et le code client reste bloqu´ en lecture, malgr´ l’envoi d’un code ICMP e e qui n’est pas interpr´t´ par d´faut par recv. . .Pour ´viter une telle situation ee e e de blocage, il faudrait configurer la socket en lui ajoutant un d´lai au del` e a 11 duquel elle retourne dans le code du client avec un code sp´cifique d’erreur . e 11 voir la page de manuel de setsockopt assortie du param`tre SO RCVTIMEO e
  • 6 Conclusion et Bibliographie 2736 Conclusion et BibliographieEn conclusion on peut ´tablir le tableau suivant : e Protocole Adresses locale Adresse ´loign´e e e ◦ ◦ et N de port. et N de port. Serveur orient´ connexion e socket bind listen, accept Client orient´ connexion e socket connect Serveur non orient´ connexion e socket bind recvfrom Client non orient´ connexion e socket bind sendtoRFC 867 “ Daytime Protocol ”. J. Postel. May-01-1983. (Format : TXT=2405 bytes) (Also STD0025) (Status : STANDARD)RFC 793 “ Transmission Control Protocol. ” J. Postel. September 1981. (Format : TXT=172710 bytes) (Updated by RFC3168) (Also STD0007) (Status : STANDARD)RFC 3493 “ Basic Socket Interface Extensions for IPv6 ”. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (For- mat : TXT=82570 bytes) (Obsoletes RFC2553) (Status : INFORMA- TIONAL) Pour en savoir davantage, outre les pages de man des primitives cit´es edans ce chapitre, on pourra consulter les documents de r´f´rence suivants : ee ◦ Stuart Sechrest — “ An Introductory 4.4BSD Interprocess Communi- cation Tutorial ” — Re imprim´ dans “ Programmer’s Supplementary e Documents ” — O’Reilly & Associates, Inc. — 199412 ◦ W. Richard Stevens — “ Unix Network Programming ” — Prentice All — 1990 ◦ W. Richard Stevens — “ Unix Network Programming ” — Second edition — Prentice All — 1998 ◦ W. Richard Stevens – Bill Fenner, Andrew M. Rudoff — “ Unix Net- work Programming ” — Third Edition — Addison Wesley — 2003 ◦ Douglas E. Comer – David L. Stevens — “ Internetworking with TCP/IP – Volume III ” (BSD Socket version) — Prentice All — 1993 ◦ Stephen A. Rago — “ Unix System V Network Programming ” — Addison–Wesley — 1993Et pour aller plus loin dans la compr´hension des m´canismes internes : e e ◦ W. Richard Stevens — “ TCP/IP Illustrated Volume 2 ” — Prentice All — 1995 ◦ McKusick – Bostic – Karels – Quaterman — “ The Design and imple- mentation of the 4.4 BSD Operating System ” — Addison–Wesley — 1996 12 On peut ´galement e trouver ce document dans le r´pertoire e/usr/share/doc/psd/20.ipctut/ des OS d’inspiration Berkeley 4.4
  • 274 Sockets de Berkeley
  • Chapitre XIII Compl´ments sur les sockets eBerkeley1 R´servation des ports e Au chapitre pr´c´dent nous avons utilis´ la primitive bind pour assigner e e eune adresse ` une socket, dans ce paragraphe nous pr´cisons comment choisir a ele num´ro de port qui va bien, selon le type d’application envisag´. Nous avons e ed´j` examin´ ce point dans les grandes lignes page 85. ea eIl y a deux mani`res d’assigner un N◦ de port ` une socket : e a 1. Le processus sp´cifie le num´ro. C’est typiquement ce que fait un ser- e e veur. On suppose bien ´videment que les clients sont au courant ou e qu’ils disposent d’un m´canisme qui peut les renseigner (cf cours sur e les RPC). 2. Le processus laisse le syst`me lui assigner automatiquement un num´ro e e de port. C’est typiquement ce que fait un client, sauf cas contraire exig´ e par le protocole d’application (cf cours sur les “ remote execution ”). En r`gle g´n´rale le d´veloppeur d’application ne s’attribue pas au hasard e e e eun (ou plus) num´ro de port. Il doit respecter quelques contraintes comme ene pas utiliser les ports d´j` attribu´s. Ceux-ci figurent dans une RFC par- ea eticuli`re. La derni`re en date est la RFC 1700 [Reynolds & Postel 1994]) au e eparagraphe “ WELL KNOWN PORT NUMBERS ”. Plus simplement, surtoute machine Unix ` jour, une liste de ces ports se trouve dans le fichier a/etc/services 1 . Cod´ sur deux octets non sign´s, le num´ro de port permet 65536 possibi- e e elit´s de 0 ` 65535. Cette ´chelle est fragment´e de deux mani`res, l’ancienne e a e e eou la nouvelle m´thode. Toutes les applications sur tous les syst`mes d’ex- e eploitation n’ont pas encore adopt´ la nouvelle approche, les deux vont donc ecohabiter un certain temps, ne serait-ce qu’` cause d’applications plus an- aciennes non encore mises ` jour. . . a 1 http://www.iana.org/assignments/port-numbers pour se tenir au courant des´volutions de cette listee
  • 276 Compl´ments sur les sockets Berkeley e 1.1 R´servation de port — Ancienne m´thode e e Port N◦ 0 Ce num´ro n’est pas utilisable pour une application, c’est une e sorte de “ jocker ” qui indique au syst`me que c’est ` lui de compl´ter e a e automatiquement le num´ro (voir plus loin de 1024 ` 5000). e a Port de 1 ` 255 Pour utiliser cette zone il faut avoir les droits du root a ` l’ex´cution (U ID = 0) pour que le bind ne retourne pas une er- a e reur. Les serveurs “ classiques ” (domain, ftp, smtp, telnet, ssh, http, snmp...) se situent tous dans cette partie. Ports de 256 ` 511 Jadis consid´r´ comme une “ r´serve ” des serveurs a ee e officiels commencent ` s’y installer, faute de place dans la zone a pr´c´dente. Il faut ´galement avoir un U ID = 0 pour utiliser un num´ro e e e e de port dans cette zone. Port de 512 ` 1023 Une fonction rresvport permet l’attribution automa- a tique d’un num´ro de port dans cette zone, pour des applications ayant e un U ID = 0. Par exemple, c’est dans cette zone qu’inetd (cf cours sur les serveurs) attribue des ports automatiquement pour les outils en “ r ” de Berkeley (rlogin, rcp, rexec, rdist,...). Port de 1024 ` 5000 Zone d’attribution automatique par bind. Lorsque a l’utilisateur (non root) utilise 0 comme num´ro, c’est le premier e port libre qui est employ´. Si tous les utilisateurs peuvent s’attribuer e “ manuellement ” un num´ro dans cette zone, il vaut mieux ´viter de e e le faire, la suivante est pr´vue pour cela. e 5001 ` 65535 Zone “ libre ” attention cependant car de tr`s nombreux a e serveurs y ont un port r´serv´, et pas des moindres comme le serveur e e X11 sur le port 6000 ! 1.2 R´servation de port — Nouvelle m´thode e e Port N◦ 0 Ce num´ro n’est pas utilisable pour une application, c’est une e sorte de “ jocker ” qui indique au syst`me que c’est ` lui de compl´ter e a e automatiquement le num´ro (voir plus loin de 49152 ` 65535). e a Port de 1 ` 1023 Pour utiliser cette zone il faut avoir les droits du root a ` l’ex´cution pour que le bind ne retourne pas une erreur. Les ser- a e veurs “ classiques ” (domain, ftp, smtp, telnet, ...) se situent tous dans cette partie. Port de 1024 ` 49151 est la zone des services enregistr´s par l’IANA et a e qui fonctionnent avec des droits ordinaires. Port de 49152 ` 65535 est la zone d’attribution automatique des ports, a pour la partie cliente des connexions (si le protocole n’impose pas une valeur particuli`re) et pour les tests de serveurs locaux. e
  • 2 Ordre des octets sur le r´seau e 2772 Ordre des octets sur le r´seau eNous reprenons ici un point d´j` ´voqu´ page 48 : eae e 15 87 0 Un mot de deux octets : 0 1 Bits de poids fort (MSB) : 15 Bits de poids faible (LSB) : 0 "Big endian" "Little endian" ... ... A+1 octet 1 octet 0 A octet 0 octet 1 HP (hppa), Intel(i386) Croissance Sun (sparc) Digital(vax) des adresses Ibm, Apple (ppc) mémoire Motorola (68k) figure XIII.01 — Ordre des octets sur le r´seau e Le probl`me de l’ordre des octets sur le r´seau est d’autant plus crucial e eque l’on travaille dans un environnement avec des architectures h´t´rog`nes. ee e La couche R´seau (page 30) ne transforme pas les octets de la couche In- eternet (page 30) qui elle mˆme ne modifie pas ceux de la couche de Transport2 e(page 29). Pour cette raison, le num´ro de port inscrit dans l’en-tˆte TCP (vs UDP) e ede l’´metteur est exploit´ tel quel par la couche de transport du r´cepteur e e eet donc il convient de prendre certaines pr´cautions pour s’assurer que les ecouches de mˆme niveau se comprennent. e D’un point de vue plus g´n´ral, les r´seaux imposent le “ poids fort ” avant e e ele “ poids faible ”, c’est le “ Network Byte Order ”. Les architectures quitravaillent naturellement avec cette repr´sentation n’ont donc th´oriquement e epas besoin d’utiliser les fonctions qui suivent, de mˆme pour les applications equi doivent dialoguer avec d’autres ayant la mˆme architecture mat´rielle. e eN´anmoins ´crire du code “ portable ” consiste ` utiliser ces macros dans e e atous les cas3 ! Pour se souvenir de ces fonctions, il faut connaˆ ıtre la signification desquatre lettres utiles : s “ short ” Entier court sur 16 bits, un num´ro de port par exemple. e l “ long ” Entier long sur 32 bits, une adresse IP par exemple. h “ host ” La machine sur laquelle s’ex´cute le programme. e n “ network ” Le r´seau sur lequel on envoie les donn´es. e e 2 Nous n’abordons pas ici la question de la transmission de donn´es h´t´rog`nes au e ee eniveau applicatif, elle sera examin´e dans le cours sur les XDR e 3 Pour les machines qui respectent naturellement le NBO, comme les stations HP (pro-cesseur risc) ou SUN (processeur sparc), IBM (processeur ppc) ces fonctions sont desmacros “ vides ” contrairement ` toutes les architectures de type i386 a
  • 278 Compl´ments sur les sockets Berkeley e D’o` les protoptypes : u #include <sys/types.h> u long htonl (u long) ; /* host to network --- long */ u short htons (u short) ; /* host to network --- short */ u long ntohl (u long) ; /* network to host --- long */ u short ntohs (u short) ; /* network to host --- short */ Par exemple, pour affecter le num´ro de port 13 (service “ daytime ”) au e champ sin port d’une structure de type sockaddr in : saddr.sin port = htons(13) ; Cette ´criture est valable quelle que soit l’architecture sur laquelle elle e est compil´e. S’il avait fallu se passer de la macro htons sur une architecture e Intel (“ little endian ”), pour l’affection du mˆme num´ro de port, il eut fallu e e ´crire : e saddr.sin port = 0x0D00 ; /* 0D hexad´cimal == 13 d´cimal */ e e 3 Op´rations sur les octets