Liaison Ethernet, du modèle aux protocoles

15/01/2016
Auteurs : FLORENT OUCHET
Publication 3EI 3EI 2016-83
OAI : oai:www.see.asso.fr:1044:2016-83:14880
DOI :
contenu protégé  Document accessible sous conditions - vous devez vous connecter ou vous enregistrer pour accéder à ou acquérir ce document.
- Accès libre pour les ayants-droit
 

Résumé

Liaison Ethernet, du modèle aux protocoles

Métriques

32
4
1.32 Mo
 application/pdf
bitcache://f23936bb72de5a4b8e2e8aa55a16f672302da61f

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1044:2016-83/14880</identifier><creators><creator><creatorName>FLORENT OUCHET</creatorName></creator></creators><titles>
            <title>Liaison Ethernet, du modèle aux protocoles</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2016</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Fri 15 Jan 2016</date>
	    <date dateType="Updated">Mon 25 Jul 2016</date>
            <date dateType="Submitted">Fri 20 Jul 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">f23936bb72de5a4b8e2e8aa55a16f672302da61f</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>25380</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 36 Liaison Ethernet, du modèle aux protocoles FLORENT OUCHET ENS Rennes Campus de Ker Lann Avenue Robert Schuman 35170 Bruz 1. Introduction Rares sont les protocoles d’échanges de données ayant connus la même progression et la même histoire qu’Ethernet. Depuis les premières inventions dans les années 1970 et jusqu’aux dernières innovations et montées en débit, Ethernet n’a cessé d’être amélioré et fait toujours l’objet de nombreuses recherches et améliorations. Son objectif principal est de faire communiquer plusieurs applications s’exécutant sur différentes machines connectées sur un ou plusieurs réseaux. Les mêmes mécanismes d’acheminement, appelés protocoles, utilisés à échelle réduite (réseau local) sont les mêmes que ceux utilisés à l’échelle de la planète (réseau internet). 2. Le modèle OSI Ethernet n’est pas un standard unique, c’est un ensemble de normes spécifiant le fonctionnement de ses différents protocoles, habituellement classés d’après un modèle en couches dénommé "modèle OSI" représenté dans la Figure 1. Cet empilement de protocoles reflète l’accumulation de leurs fonctionnalités respectives : transfert sans fil, fiabilité des échanges, sécurisation… Chaque protocole n’est qu’un accord reconnu (un standard) permettant à différentes applications ou à différentes machines de communiquer, même réalisées en des technologies différentes. Figure 1 : couche dans le modèle OSI d'une transmission Cet article est construit comme l’explication du fonctionnement des différentes couches en commençant par les couches proches l’utilisateur (agissant sur l’application de couche 7) pour finir par les couches proches du matériel (couches 1 et 2). Au niveau de l’émetteur, tout message émis par une application va être transformé au fur et à mesure de sa traversée des différentes couches et les opérations inverses seront réalisées au niveau du récepteur lors de sa remontée vers la couche applicative afin de retrouver les informations émises. 3. Echanges d’informations entre applications Lors de la consultation d’une page web, lors de la connexion d’une application de messagerie ou lors de l’envoi d’un message électronique, une application cliente s’exécutant sur le poste de l’utilisateur envoie et/ou reçoit des données depuis une application distante. Celle-ci s’exécute habituellement sur une des nombreuses machines d’une ferme de serveurs. Les données échangées entre les applications cliente et serveur transitent alors par le réseau pour arriver au destinataire. Plusieurs techniques de connexions peuvent être utilisées selon la nature du lien séparant les deux machines physiques. Mais toutes ces opérations sont réalisées par les couches 1 à 6 de façon tout à fait transparentes. La couche applicative (couche 7) est très dépendante du type de service recherché : un navigateur web communiquera avec un serveur web par le biais du protocole HTTP, une messagerie email communiquera avec un serveur email grâce aux protocoles IMAP ou POP… Ces protocoles applicatifs peuvent être vus comme des langages structurés où les applications communiquent par phrases décrivant les différentes actions à réaliser. Résumé : cet article vise à présenter les principes de fonctionnement des principaux protocoles au cœur du fonctionnement d’Ethernet, en utilisant des outils de descriptions tels que SysML. 7 6 5 4 3 2 1 7 6 5 4 3 2 1 Couche 7 : application Couche 6 : présentation Couche 5 : session Couche 4 : transport Couche 3 : réseau Couche 2 : liaison Couche 1 : physique médium machine émettrice machine réceptrice transfert du message Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 37 3.1. Protocole applicatif HTTP Par exemple un navigateur web enverra la commande de la Figure 2 pour demander le contenu d’une page web. Cette demande est habituellement appelée requête. Elle peut se décoder sous la forme "Je veux récupérer la page /index.php selon le protocole version HTTP version 1.1, sur le serveur www.monsite.com. Je suis Mozilla Firefox, mon utilisateur préfère la langue française, mais je peux aussi accepter l’anglais si le français n’est pas disponible. Le format attendu est une page HTML ou une page XHTML ou un fichier XML car je sais afficher ces formats". Figure 2 : message de demande page HTML (requête HTTP) A la réception de ce message le serveur répond toujours selon le protocole HTTP avec le contenu de la Figure 3 contenant des informations sur l’état de la demande ainsi que le contenu de la page demandée, ici en HTML. Figure 3 : message contenant la page HTML (réponse HTTP) Cette réponse indique que "le contenu est conforme à la version 1.1 du protocole, la requête s’est exécutée sans erreur (200 OK – si la page demandée n’existe pas pour ce site, l’erreur serait 404 Not Found), le contenu correspond à la page demandée à l’adresse http://www.monsite.com/index.php à la date spécifiée (utile pour le cache du navigateur), au format HTML en utilisant un alphabet international UTF-8." Le contenu de cette page représente en 127 octets un titre, un contenu texte et une image à afficher. En réceptionnant et en décodant ce contenu, le navigateur peut immédiatement afficher le texte puis envoyer une seconde requête au serveur pour récupérer l’image. La requête de l’image est de la forme présentée dans la Figure 4 et le serveur répond en indiquant des informations sur l’état de la demande suivie du contenu de l’image (fichier binaire). Figure 4 : message de demande d’image (requête HTTP) Cette échange supplémentaire et les délais de traitements/transferts associés expliquent l’affichage progressif des pages où les images s’affichent au fur- et-à-mesure, surtout lorsque le débit de la liaison est lent. Ces échanges simples ont permis la création de nombreuses applications clientes différentes, capables de communiquer de façons transparentes avec de nombreuses applications serveurs, quelques soient leurs technologies ou leurs modèles. Il existe cependant toujours quelques incompatibilités avec certaines applications serveurs ou clientes ne respectant que partiellement le protocole tel que défini officiellement1 . Comme le protocole HTTP, la plupart des protocoles applicatifs (y compris les protocoles de messagerie IMAP ou POP ou les protocoles de transferts de fichiers FTP…) fonctionnent avec des échanges de textes et de contenus au format bien spécifiés, facilement interprétable. 3.2. Uniformisation des jeux de caractères La principale difficulté dans la cohabitation de ces échanges de texte réside dans l’héritage historique des tables de caractères (charset) où une valeur numérique différente pouvait identifier des caractères distincts à différents endroits du globe. Un des objectifs de la couche 6 (présentation) est de résoudre ces incompatibilités en convertissant les caractères reçus vers la table de caractères locale à la machine. Cette spécificité historique tend à s’estomper actuellement avec l’utilisation intensive des jeux de caractères internationaux assurant la représentation numérique unique de tous caractères, quel que soit le langage local de la machine. Cette standardisation s’appelle Unicode et a notamment créé la représentation UTF-8 la plus répandue. Des applications utilisant directement cette représentation peuvent se passer de couche 6 (exemple dans la Figure 3). 1 https://tools.ietf.org/html/rfc7230 à https://tools.ietf.org/html/rfc7237 GET /index.php HTTP/1.1 Host: www.monsite.com User-Agent: Mozilla/5.0 Firefox/43.0 Accept: text/html,application/xhtml+xml,application/xml Accept-Language: fr-FR, en-US HTTP/1.1 200 OK Location: http://www.monsite.com/index.php Content-Type: text/html; charset=UTF-8 Date: Sat, 09 Jan 2016 09:10:03 GMT Content-Length: 127 Titre de ma mage Contenu de la page avec une image GET /image.png HTTP/1.1 Host: www.monsite.com User-Agent: Mozilla/5.0 Firefox/43.0 Accept: image/png,image/* Accept-Language: fr-FR, en-US Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 38 4. Création et sécurisation d’une transmission Ces échanges applicatifs, souvent en texte, sont néanmoins des données sensibles : les messages reçus doivent être interprétés dans l’ordre d’émission (notions de répétabilité et déterminisme) et les échanges entre les deux applications devraient ne pas pouvoir être interprétés par un tiers écoutant sur le réseau (confidentialité). 4.1. Sécurisation de la transmission Il existe depuis de nombreuses années des mécanismes de protection, généralement basés sur des algorithmes de cryptages à clés. Dans le modèle OSI, cette étape est réalisée par la couche 5. Cela signifie que l’établissement d’une communication cryptée est un processus quasiment transparent au niveau de l’application, une fois réceptionné par la couche 5 et décrypté, le message transmis à l’application du récepteur est le même que celui transmis par l’application émettrice. Deux principaux challenges sont à relever pour obtenir une liaison parfaitement sécurisée :  les clés de décryptage doivent être échangées sans pouvoir être interceptées, sinon un tiers écoutant sur réseau pourrait les intercepter et décrypter les messages ;  l’identité du serveur doit être vérifiée de façon indépendante, un tiers de confiance doit confirmer formellement l’identité du serveur avec lequel la connexion est établie. Le premier challenge est levé par l’utilisation de clés asymétriques propres à chaque machine. Les deux clés du jeu sont appelées clé publique pour celle transmise à l’autre machine et clé privée pour celle restant secrète et jamais transmise. Un message crypté avec la clé privée d’un jeu ne peut être décrypté qu’avec la clé publique de ce même jeu et inversement. Chaque machine (serveur et client) dispose d’un jeu unique, la liaison cryptée fait donc intervenir quatre clés distinctes et seulement les deux clés publiques sont échangées entre les machines. La Figure 5 représente les échanges effectués lors de l’établissement d’une liaison cryptée de type SSL. Ce diagramme de séquence représente les différents acteurs actifs lors de cet échange. Les actions propres des couches 5 et 7 pour chaque machine sont bien différentes, elles ont par conséquent été représentées comme des acteurs propres. Les échanges entre les couches 5 et 7 sont internes à la machine et sont des appels de fonctions, les échanges entre les couches 5 des deux machines se font nécessairement par le réseau. Le message 1 issu de la couche applicative (donc souvent du texte clair) est transmis à la couche suivante par appel de fonctions. A réception de celui-ci, une négociation est lancée entre les couches sessions des deux machines afin d’établir la liaison la plus robuste supportée par les deux systèmes. Le client commence par envoyer dans le message 2 la liste de l’ensemble des algorithmes et des longueurs de clés qu’il supporte. Le serveur répond dans le message 3 en précisant le protocole et la longueur de clé utilisée par la suite. Les principaux algorithmes actuels sont RSA (approche mathématique basée sur le reste de divisions entières par de très grands nombres stockés dans les clés), AES (successions de permutations et de mélanges bit-à-bits de la clé et du message) et ECC (approche mathématique basée sur des courbes Figure 5 : protocole de sécurisation et de transmission pour un canal crypté (couche 5) Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 39 elliptique) pouvant s’exécuter sur des clés de longueur 256 à 4096 bits. Plus une clé est longue, plus il est difficile d’écouter et de décrypter les messages sans connaître préalablement les clés utilisées. La transmission de la clé publique du serveur dans le troisième message permet de valider l’identité de celui-ci. En effet les clés de cryptages sont obtenues auprès d’organismes spécialisés qui agissent ensuite comme entité de certification sur les clés qu’elles ont émises. Elles les valident tant qu’elles ne sont pas trop âgées ou qu’elles n’ont pas été déclarées volées. Ce système est basé sur la confiance : seuls quelques organismes sont réputés fiables pour délivrer et certifier ces jeux de clés. La liste de ces organismes sûrs (identifiés par des certificats racines) est mise à jour régulièrement au niveau du système d’exploitation et/ou des applications (navigateurs web). Les échanges 4 et 5 entre le client et l’autorité de certification font bien entendu appel à des mécanismes cryptographiques afin que la validation de l’identité du serveur soit sécurisée : la vérification d’identité est signée numériquement par le biais d’un algorithme de hachage (de type SHA-3) utilisant l’empreinte digitale de l’organisme de certification, connue partiellement du client pour vérification. L’étape suivante (échange 6) est la transmission de la clé publique du client au serveur afin que celui-ci puisse décrypter ultérieurement les messages du client. Après ces six premières étapes permettant de créer la liaison, les étapes suivantes correspondent aux échanges de données utiles à l’application. Plusieurs échanges successifs peuvent être réalisés entre les machines avant de négocier à nouveau une sécurisation de la connexion. Cette renégociation passe par une régénération périodique des clés locales du client dans le but d’éviter que celles-ci puissent être devinées par un tiers écoutant le réseau. Chaque message est crypté deux fois avant d’être transmis : une première fois en se basant sur la clé publique distante puis une seconde fois en se basant sur la clé privée locale. A l’autre extrémité le décryptage commencera par la clé publique distante puis mettra en œuvre la clé privée locale afin de réobtenir le message applicatif en clair. Ce double cryptage permet d’assurer la sécurité des échanges même après le premier transfert de la clé publique du serveur en clair. Cependant, pour que la procédure de sécurisation et les échanges entre les applications soient sûrs, il est nécessaire de s’assurer du bon ordre des paquets entre l’émission et la réception. 4.2. Liaisons non sécurisées En cas d’absence de cryptage sur une liaison, la couche 5 peut être considérée comme un passage direct des données de la couche 6 vers la couche 4 en émission et inversement en réception. 4.3. Transmission déterministe de l’information De par la structure maillée du réseau mondial, il existe plusieurs chemins possibles entre deux points. En considérant une liaison, l’ordre de réception des paquets sur une machine peut être différent de l’ordre d’émission par l’autre machine si les chemins pris par les paquets sont différents. Ce phénomène inévitable à grande échelle peut également survenir localement en cas de congestion de certaines lignes (utilisation automatique d’itinéraires de délestages). La réception dans le désordre, en double ou les éventuelles pertes de paquets sont généralement inacceptables du point de vue de l’application (couche 7) et de la négociation des liaisons sécurisées (couche 5). La couche 4 répond à ce besoin de déterminisme dans le transport des messages en insérant des mécanismes d’ordonnancement et d’acquittement des paquets afin de s’assurer de leur bonne transmission. Ces opérations sont opérées par le protocole TCP dont le principe de fonctionnement est donné dans le diagramme de séquence de la Figure 6. La couche 4 est représentée comme un acteur indépendant de par son fonctionnement propre distinct de celui de l’application et des autres couches. Néanmoins pour simplifier le schéma, uniquement l’acteur le plus proche (couche 5) est représenté puisque tout message ou toute action de la couche 7 doit nécessairement passer par cet intermédiaire. Les échanges entre les couches 4 et 5 sont des appels de fonctions internes aux machines, les échanges entre les couches 4 des deux machines se font nécessairement par le réseau. Quatre phases temporelles sont séparées par des lignes horizontales pointillées et correspondent aux principales opérations réalisées détaillées dans les sous-parties suivantes. 4.3.1. Ouverture de la connexion Afin de s’assurer de la capacité du serveur à accepter les premiers envois, une phase préliminaire de négociation ouvre la connexion. Cette ouverture doit avoir lieu préalablement à l’envoi du premier message de données (par exemple préalablement à la trame 2 de la Figure 5 correspondant à la première trame de sécurisation négociée). A ce stade il convient de préciser deux notions utilisées jusqu’à présent sans définition : un client est une application présente ponctuellement sur le réseau Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 40 et qui demande à se connecter à une application serveur, généralement présente et active tout le temps sur le réseau. Les applications client et serveur sont différentes, elles ne font pas appel aux mêmes fonctions lors de l’ouverture de la connexion car leurs rôles lors de l’ouverture sont différents. Au démarrage du serveur, l’application va créer un port, lui attribuer un identifiant et lancer l’écoute sur ce port. Ce sont les rôles des fonctions socket, bind et listen de la Libc. L’équivalent est implémenté par le constructeur de la classe java ServerSocket et de la classe Python SocketServer.TCPServer. Il est également possible d’utiliser les fonctions bind et listen de la classe Python client/serveur Socket.Socket. A l’issu de cette première étape (premier échange dans la Figure 6), le port du serveur est identifié comme ouvert, disponible pour d’éventuelles connexions, à l’attente de clients. Lorsqu’un client souhaite se connecter (échange 2), l’application utilise la fonction connect de la Libc, ou la fonction Python Socket.connect ou de la classe java Socket. Dans les paramètres de connexion il est nécessaire de spécifier l’adresse du serveur (son adresse IP ou son adresse sur le réseau) et l’identifiant du port auquel le client souhaite se connecter (celui spécifié lors de la création du serveur). Cet appel déclenche l’émission d’un paquet sur le réseau adressé au serveur (échange 3). Dans la terminologie TCP, ce paquet est une synchronisation (SYN). Si le serveur n’existe pas où s’il n’accepte pas assez rapidement, l’appel de la fonction connect échoue informant l’application que la transmission n’est pas possible. Le serveur accepte explicitement le nouveau client (échange 4 étant un acquittement ACK). Les deux échanges réseaux 5 et 6 notifient les deux applications de la disponibilité de la connexion (échanges 7 et 8). La différence entre le client et le serveur s’estompe dès que la liaison est établie (phases suivantes). 4.3.2. Envoi sans erreur Les protocoles applicatifs (couche 7) utilisés par les deux applications spécifient la direction d’envoi des données. Dans la plupart des protocoles, comme dans cette figure, le client fait le premier envoi. La situation est strictement symétrique dans le cas contraire. L’application souhaitant recevoir des données appelle la fonction recv de la Libc (échange 9). Pour les langages orientés objets tels que Python et java, des fonctions équivalentes (recv ou read) existent dans les instances des classes créées pour ouvrir le port. Pour émettre les données, l’application utilise la fonction send de la Libc, ou des instances des mêmes classes. Cet appel (échange 10) déclenche l’émission Figure 6 : échanges déterministes à l'aide du protocole TCP (couche 4) Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 41 d’un paquet sur le réseau (échange 11) identifiant clairement la plage de données envoyées (les x=N premiers octets) et reçues (y=0 octet de la part du serveur à cet instant). La réception de ces N octets déclenche le retour de la fonction recv (échange 12). La couche 4 du récepteur acquitte la bonne réception de ces données en envoyant un paquet (échange 13) indiquant la bonne réception des x=N premiers octets, tout en confirmant n’avoir rien envoyé pour le moment (y=0). L’émetteur est informé que les données ont été correctement reçues et l’application peut retourner de la fonction d’envoi (échange 14). 4.3.3. Envoi avec répétition Les échanges suivants mettent en évidence le comportement de la couche 4 dans un cas plus complexe. Les deux machines ont échangé leurs rôles, le client passe en réception (échange 15) et le serveur envoie une réponse (échange 16) dont le nombre d’octets dépasse la capacité d’envoi en un seul paquet. Uniquement dans le cas du protocole TCP, la couche 4 de l’émetteur réalise automatiquement la segmentation des données en découpant les données envoyées en plusieurs paquets (échange 17 et 19) dont la taille est conforme avec le canal (généralement environ 1ko à chaque paquet). Ces paquets sont contigus, le premier contient les octets y=1 à M, le suivant les y=M+1 à L. La couche 4 du récepteur acquitte les paquets de données dès leurs réceptions : l’échange 18 acquitte les y=M premiers octets reçus et l’échange 21 les y=L précédents octets reçus. Ces acquittements contiennent également l’information x=N inchangée permettant au serveur de valider le fait que le client n’ait émis aucune nouvelle donnée à cet instant (donc pas de paquet manquant). Cette couche 4 en réception réassemble les paquets reçus pour reformer un seul bloc de L octets et informe l’application de leur réception en permettant le retour de la fonction recv. Cependant, l’échange 21 n’aboutit pas à cause d’un problème réseau lié aux différents problèmes possibles dans les couches inférieures qui seront décrits par la suite. La couche 4 de l’émetteur ne reçoit donc pas l’acquittement des octets y=M+1 à L et les réémet à nouveau (échange 22) après un temps d’attente (généralement quelques dixièmes de seconde, adaptable dynamiquement selon la liaison). La réception de ce paquet superflu par la couche 4 du client ne provoque pas d’erreurs. Ces octets ont déjà été reçus et transmis à l’application (y=L lors de l’échange 19 reçu précédemment) ; ils sont ignorés. Simplement l’acquittement des y=L premiers octets est envoyé à nouveau (échange 23), en reprécisant toujours x=N. La réception de cet acquittement informe la couche 4 du serveur que l’intégralité des y=L octets a bien été reçue, cette information est transmise à l’application (échange 24). Cet exemple a mis en évidence le rôle de la réémission automatique des paquets par le protocole TCP pour corriger les erreurs courantes de transmission (pertes, duplication de paquets). Les compteurs présents dans chaque paquet échangé permettent également de réordonner les données reçues avant leur transfert à l’application. Le transfert est donc parfaitement déterministe. 4.3.4. Fermeture de la connexion La fermeture de la connexion a un double rôle : libérer les ressources locales (mémoire de réception…) et informer la machine distante que l’application locale ni acceptera ni n’enverra de nouvelles données. L’application client ou serveur initient indifféremment cette fermeture en appelant la fonction close de la Libc ou de l’instance du port (Python et java). Chaque trame de demande de fermeture est explicitement acquittée afin d’informer leur expéditeur de leur bonne réception. En cas de non-acquittement, la trame de demande de fermeture est renvoyée. 4.3.5. Performance de TCP Le protocole TCP nécessite de nombreux échanges de paquets afin d’ouvrir, de maintenir ou de fermer une connexion. Cela induit des délais importants dans les transmissions rendant ce protocole difficilement compatible avec les contraintes de temps réel. Pour ne pas encombrer inutilement le réseau, tous les paquets contenant des données ne sont pas acquittés individuellement. Les acquittements sont émis régulièrement (toutes les 100 ms ou tous les N paquets, cela dépend de l’implémentation) et valident tous les octets reçus depuis le dernier acquittement. Afin de ne pas bloquer les applications pendant des temps d’attentes trop long, le nombre de réémission des différents paquets est borné (généralement à 3 essais). La couche 4 peut fermer la connexion de force en cas d’échecs répétés, informant également l’application. 4.4. Transmission non-déterministe Pour pallier aux inconvénients temporels (lenteur) et de débit (nombreux échanges) du protocole TCP, il existe un protocole de couche 4 en version allégée : le protocole UDP. Celui-ci ne réalise ni la segmentation, ni le tri par ordre chronologique des octets reçus, ni l’acquittement des données transmises, ni les phases d’ouvertures et de fermetures (Figure 7). Les Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 42 applications utilisant ce protocole doivent être conçues pour être robustes aux pertes et aux retards dans la réception des paquets. 4.5. Identification des applications Les deux méthodes de transmissions vues précédemment font appel à un identifiant de port pour acheminer les différents paquets entrants vers la bonne application. Cet identifiant est codé sur 16-bit, chaque machine dispose d’environ 216 ports à transfert déterministes (TCP) et de 216 ports à transfert non- déterministes (UDP). Certains identifiants de ports sont associés par défaut à des services prédéfinis2 : le port TCP 80 est habituellement associé aux applications serveur exécutant le protocole HTTP sans sécurisation, le port TCP 443 aux serveurs exécutant le protocole HTTP en version sécurisée… Cette partie a décrit le fonctionnent de protocoles applicatifs haut-niveau et les techniques actuelles de sécurisations des échanges sans rentrer dans les détails d’acheminement des paquets sur des distances pouvant atteindre plusieurs milliers de kilomètres. 5. Routage des paquets dans un réseau Un réseau est défini comme l’interconnexion de plusieurs sous-réseaux reliés par une ou plusieurs passerelles (gateway). Chaque sous-réseau est constitué d’un ensemble de machines reliées par plusieurs commutateurs (switch). On ne s’intéressera pas ici au cas du relais (hub) qui est maintenant une technologie désuète. Les mécanismes d’orientations des paquets sont différents à l’intérieur d’un sous-réseau et entre plusieurs sous-réseaux (donc à l’échelle d’un réseau) et sont réalisés par la couche 3 du modèle OSI (réseau). 2 https://fr.wikipedia.org/wiki/Liste_de_ports_logiciels 5.1. Identification des machines Chaque machine est identifiée sur le réseau par son adresse IP. Dans le cas du protocole IPv4 historique, cette adresse est constituée de 4 octets, par exemple "192.168.1.100" en décimal. Le protocole IPv6 en cours de déploiement définit ces adresses sur 16 octets, par exemple en hexadécimal une adresse complète est "2a00:1450:4013:0c01:0000:0000:0000:005e". Chaque interface physique (carte réseau) est identifiée par son adresse MAC sur 6 octets, par exemple "0A-00-27-00-00-00" en hexadécimal. Habituellement les adresses utilisées pour accéder aux serveurs sont des noms de domaines, par exemple www.monsite.com. Ce nom est d’abord résolu en adresse IP par le biais du protocole DNS à l’aide d’un serveur applicatif dédié. L’adresse IP de ce serveur fait partie de la configuration réseau de chaque machine. De la même manière, il est possible de retrouver l’adresse MAC vers une machine identifiée par son adresse IP en utilisant le protocole ARP. 5.2. Routage à l’intérieur d’un sous-réseau A l’intérieur d’un sous-réseau, les communications se font directement en adressant les paquets aux adresses physiques MAC des cartes réseaux. La Figure 8 met en évidence le fonctionnement de ces deux protocoles DNS et ARP pour établir une liaison directe. Lorsque le client envoie un paquet (échange 1) à destination d’un serveur désigné par son nom de domaine, il est nécessaire d’obtenir l’adresse IP correspondant à ce serveur. Pour cela il faut d’abord pouvoir communiquer avec le DNS, dont l’adresse DNS=IP_S fait partie de la configuration réseau de la machine client. Cette communication nécessite d’obtenir l’adresse MAC_S de cette machine. Figure 7 : échanges non-déterministes à l'aide du protocole UDP (couche 4) Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 43 Dans la phase 1 de cette figure, la machine cliente utilise le protocole ARP afin de demander à toutes les machines laquelle correspond à l’adresse IP_D (échanges 2 et 3). Seule l’interface physique correspondant vers cette adresse IP_D répond (échange 4). Pendant la phase 2, la couche 3 du client peut alors communiquer vers la carte physique MAC_D de ce DNS et transmettre la demande de résolution (échange 5). Le serveur répond à cette demande dans l’échange 6 en indiquant l’adresse IP_S. Pendant la phase 3 (ARP identique à la phase 1), la couche 3 du client recherche maintenant l’adresse physique correspondant à cette adresse IP_S (échanges 7 et 8) et le serveur répond dans l’échange 9. La communication est alors possible directement entre les interfaces physiques du client et du serveur (échanges 10 et 11 de la phase 4). Pour des raisons de performances, les couches 3 de toutes les machines implémentent des caches évitant de déclencher ces mécanismes de résolution lents à chaque envoi de paquet. Chaque entrée de ce cache est ajoutée d’après les échanges précédents et est conservée pendant quelques minutes. Tous les paquets échangés sur le réseau contiennent les adresses IP et les adresses MAC de la machine émettrice et de la machine réceptrice. L’observation des échanges 2 et 3, adressés à toutes les machines, permet de déterminer que l’adresse MAC_C est associée à l’adresse IP_C. Le DNS (dans l’échange 4) et le serveur (dans l’échange 13) se servent de cette information pour adresser directement les paquets à l’adresse physique MAC_C pour accéder à la machine client IP_C. A l’intérieur d’un sous-réseau, toutes les machines sont connectées à un ou plusieurs commutateurs (switch). Ces appareils réalisent un routage dynamique des paquets en observant également les échanges de paquets. En observant les adresses d’émission des paquets entrants, le commutateur détermine dynamiquement le port de connexion de chaque adresse MAC présente dans le sous-réseau. En retour, les paquets adressés à cette adresse MAC seront envoyés exclusivement sur ce port. Ce routage dynamique des paquets permet de connecter simplement plusieurs machines en observant leurs adresses physiques MAC, à condition que ces adresses soient uniques à l’échelle d’un sous-réseau. Néanmoins, cette structure n’est pas adaptable lorsque plusieurs milliers de machines sont présentes dans le même sous-réseau : les nombreuses diffusions multiples du protocole ARP congestionne complètement le sous-réseau et les commutateurs n’ont pas assez de mémoire cache pour mémoriser toutes les adresses MAC présentes. 5.3. Routage entre plusieurs sous-réseaux A une échelle plus grande, un réseau est constitué par l’interconnexion de plusieurs sous-réseaux reliés par des passerelles. Dans cette architecture, une plage d’adresses IP contiguë est attribuée à chaque sous- réseau. Par exemple chaque modem-routeur ADSL/fibre grand public actuel gère par défaut un sous-réseau local contenant les adresses IPv4 de 192.168.1.1 à 192.168.1.254 (l’adresse 255 est réservée pour les diffusions). Ce sous-réseau permet de connecter directement jusqu’à 254 machines locales en utilisant le routage dynamique vu précédemment. Tous les accès à d’autres adresses IP extérieures se font par l’intermédiaire de la liaison ADSL/fibre. Le modem réalise la fonction de passerelle en étant l’intermédiaire de communication vers toutes les adresses IP externes au sous-réseau local. Au niveau des protocoles de résolution, cette structure est possible en agissant au niveau de la couche 3. Lorsqu’une machine d’un sous-réseau souhaite communiquer avec une machine dont l’adresse IP n’appartient pas au sous-réseau local (non Figure 8 : résolutions d'un nom de domaine (protocole DNS) et d'une adresse IP (protocole ARP) Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 44 compris dans la plage d’adresses IP locales), le paquet sera adressé à l’adresse MAC de la passerelle à destination finale de l’adresse IP souhaitée. La passerelle, connectée également à un sous- réseau du fournisseur d’accès internet recherche l’adresse MAC permettant d’accéder à l’adresse IP externe. L’adresse MAC de destination du paquet sera réécrite en conséquence avant que la passerelle ne l’émette vers le second sous-réseau. Si cette adresse IP n’appartient pas à ce deuxième sous-réseau, le paquet sera redirigé vers une seconde passerelle et ainsi de suite3 jusqu’à arriver dans le sous-réseau de l’adresse IP de destination. Dans ce sous-réseau final, le protocole ARP fait la dernière liaison. Différents mécanismes sont utilisés pour trouver la passerelle vers un autre sous-réseau :  La passerelle par défaut peut être configurée dans les paramètres de la liaison réseau. Tout paquet devant sortir du sous-réseau est alors adressé à l’adresse MAC correspondant à cette passerelle (modem).  Des règles statiques de routage peuvent être spécifiées au niveau des passerelles ou des machines afin de spécifier l’intermédiaire requis pour chaque plage d’adresse IP de destination.  Des règles dynamiques de routage peuvent être découvertes automatiquement en se basant sur le protocole RIP.  Les règles de routage peuvent s’adapter à l’état de congestion des différents liens entre les passerelles en créant des itinéraires dynamiques de délestages en se basant sur le protocole OSPF. 6. Emission des paquets sur un canal Les couches 1 (physique) et 2 du modèle OSI sont spécifiques au matériel, elles décrivent comment envoyer les informations sur le médium (fils, fibre optique, ondes radios dans l’air…). A ces couches, le transfert d’informations entre un émetteur et un ou plusieurs récepteurs est en réalité une transmission de puissance en tenant compte des temps de propagation de l’onde. 6.1. Couche 1 (physique) Plus spécifiquement la couche 1 décrit comment l’information (bits) est transmise et reçue en niveaux de puissances envoyés sur le médium (tensions, intensités lumineuses…). Cette opération est généralement opérée par des circuits mixtes 3 Les commandes "tracert adresse" sous Windows ou "traceroute adresse" sous Linux permettent d’afficher les intermédiaires vers une adresse analogiques/numériques spécialisés (appelés PHY en référence à la couche physique). Matériellement, les PHY comportent des composants tels que des amplificateurs, des transformateurs et des récepteurs de puissance (résistances bouchons) dont les gammes de puissances vont de quelques milliwatts (transmissions filaires à courte distance) à une dizaine de watts (transmissions radio ou par fibre optique à longue distance). L’interface reliant la couche 1 à la couche 2 est souvent standardisée sous la forme d’un bus MII (Figure 9) permettant, en théorie, l’interchangeabilité de la couche 1 en fonction du médium support de la communication : Wi-Fi, filaire ou optique. On retrouve à l’interface entre ces deux couches des signaux indiquant les données envoyées/reçues, mais aussi des informations sur le niveau de réception et les éventuelles erreurs de transmission et de réception. Figure 9 : signaux d'un bus Media-Independant-Interface (datasheet LAN8710A) 6.2. Couche 2 (accès et fiabilité des échanges) Ces informations supplémentaires sur l’état de la transmission sont utilisées par la couche 2 afin de garantir un accès sûr au médium. Un mécanisme d’arbitrage temporel est nécessaire afin d’éviter les accès simultanés sur le médium et donc la confusion entre les messages. Ethernet filaire utilise pour cela le principe du CSMA/CD (CD pour Collision Detection) pour partager à la volée et en dynamique un câble entre plusieurs nœuds. Le médium est sondé avant toute émission. Une fois constatée l’absence de transmission en cours, l’interface émet son message tout en restant à l’écoute d’éventuels autres messages pouvant être reçus mais décalés temporellement à cause des temps de propagation. Si une interface constate une collision en observant un niveau de puissance anormalement élevé, tous les messages en cours de transmission sont alors détruits (marqués impropres) par l’émission d’un motif spécial. Liaison Ethernet, du modèle aux protocoles La Revue 3EI n°83 Janvier 2016 Thème 45 Pour éviter d’éventuels conflits à la retransmission, chacun des nœuds recommence son émission après un temps d’attente aléatoire. Ce mécanisme CSMA/CD existe mais n’est quasiment plus d’actualité car toutes les transmissions filaires actuelles sont commutées en mode point-à-point. Chaque médium a donc un seul et unique émetteur et un seul et unique récepteur. Son sens de transmission est négocié automatiquement à la mise sous tension (autoswitch matériel dans chaque nœud permettant de s’adapter aux câbles droits et aux câbles croisés), il n’y a donc plus de collision sur l’Ethernet filaire actuel. A l’inverse, les conflits sont nombreux en Ethernet transmis par onde radio (Wi-Fi) car le médium unique est partagé entre les différents nœuds. Ce problème est effectivement résolu par l’arbitrage CSMA/CA (CA pour Collision Avoidance) : chaque nœud négocie avec ses semblables une réservation temporelle du canal avant la transmission : les autres nœuds prennent acte de l’occupation du canal et évitent de transmettre pendant ce créneau. Des collisions sont néanmoins possibles lors des courtes phases de réservation, ce qui ralentit le débit maximal atteignable lorsque beaucoup de nœuds sont connectés et souhaitent envoyer des paquets. La couche 2 permet également la vérification de la validité des bits reçus en insérant lors de l’émission des séquences de démarrage et une checksum permettant à tous les récepteurs de vérifier l’exactitude des bits reçus dans des conditions normales de transmission. Chaque paquet envoyé sur un médium est assorti d’une somme de contrôle permettant de détecter d’éventuelles erreurs de transmissions. 7. Conclusion Ethernet est un ensemble de protocoles et de standards largement reconnus permettant l’échange sûr de données entre plusieurs machines distantes. L’utilisation successive des différents protocoles présents dans chaque couche du modèle OSI peut garantir la réception, la confidentialité et l’exactitude des données transmises. Intrinsèquement tous ces algorithmes sont égalitaires, c’est-à-dire qu’aucune application ou aucune machine n’est privilégiée plus qu’une autre sur le réseau. Cette notion de neutralité est un principe fondateur d’internet, concept construit sur un réseau Ethernet à l’échelle de la planète. Acronymes utilisés :  ARP "Address Resolution Protocol" résolution d’une adresse IP vers une adresse physique MAC  CSMA "Carrier Sense Multiple Access" mécanisme vérifiant l’inutilisation d’un canal avant toute émission  DNS "Domain Name System" protocole résolvant un nom de domaine en adresse IP  HTML "Hyper Text Markup Language" langage textuel amélioré avec des balises permettant de changer le style du texte ou l’affichage d’images  HTTP "Hyper Text Transmit Protocol" protocole applicatif permettant à un navigateur web d’échanger avec un serveur web (couche 7)  IMAP "Internet Message Access Protocol" protocole applicatif de lecture et de stockage distant d’emails (couche 7)  IP "Internet Protocol" protocole de routage des paquets se basant sur une adresse IP, désigne également ces adresses logiques  Libc bibliothèque standard du langage C, permettant d’accéder au réseau  MAC "Media Access Control" adresse physique permettant d’identifier de manière uniquement un équipement dans un sous-réseau  OSI "Open Systems Interconnection" abstraction habituellement utilisé pour modéliser le fonctionnement des différents protocoles actifs pendant un échange sur un réseau  OSPF "Open Shortest Path First" protocole de routage déterminant automatiquement les routes les plus rapides vers différentes plages d’IP  POP "Post Office Protocol" protocole applicatif de téléchargement d’emails (couche 7)  RIP "Routing Information Protocol" protocole de routage déterminant automatiquement les routes les plus courtes vers différentes plages d’IP  SHA-x "Secure Hash Algorithm" algorithme de calcul d’empreintes d’identifications, actuellement SHA-3 est le plus robuste  SSL "Secure Socket Layer" protocole de sécurisation par échange de clés (couche 5)  TCP "Transmission Control Protocol" protocole s’assurant du bon ordre et de la bonne réception des messages (couche 4)  UDP "User Datagram Protocol" protocole ne s’assurant pas du bon ordre et de la bonne réception des messages (couche 4)  UTF-8 "Unicode Transformation Format – 8 bits" table de caractères établissant une correspondance entre des valeurs numériques sur 1, 2, 3 ou 4 octets et toutes les lettres, tous les chiffres, tous les symboles usuels de tous les alphabets