Le filtrage avec iptables

Comme déjà établi, TCP/IP est multicouche. Ceci indique que nous avons une fonctionnalité sur un niveau, et une autre à un autre niveau, etc. La raison pour laquelle nous avons toutes ces couches est très simple.

La raison principale est que l'architecture globale est très extensible. Nous pouvons ajouter de nouvelles fonctionnalités aux couches application, par exemple, sans avoir à réimplémenter l'ensemble du code TCP/IP, ou inclure une pile TCP/IP complète dans l'application. Ainsi il est inutile de réécrire chaque programme chaque fois que nous installons une nouvelle carte d'interface réseau. Chaque couche devrait avoir une connaissance minimum des autres, pour qu'elles restent séparées.

Il existe deux architectures de base lorsque nous parlons de couches. Une des deux est le modèle OSI (Open System Interconnect) et consiste en 7 couches. Nous les verrons superficiellement ici, nous nous intéresserons plus particulièrement aux couches TCP/IP. Cependant, sur un plan historique il est intéressant de le connaître, en particulier si vous travaillez avec plusieurs types de réseaux différents. Voir la liste dans le OSI Reference Model.

Modélisation OSI

• Couche Application
• Couche Présentation
• Couche Session
• Couche Transport
• Couche Réseau
• Couche Liaison
• Couche Physique

Un paquet que nous envoyons parcourt du sommet à la base cette liste, chaque couche ajoutant ses propres en-têtes au paquet, ce que nous appelons la phase d'encapsulation. Lorsque le paquet rejoint sa destination, il parcourt en sens inverse la liste et les en-têtes sont supprimés du paquet, un à un, chaque en-tête donnant à l'hôte de destination toute l'information nécessaire jusqu'à ce que le paquet joigne l'application ou le programme pour lequel il était destiné.

Le second et plus intéressant standard est le protocole TCP/IP, comme indiqué dans la liste. Il n'y a pas d'accord universel en ce qui concerne le nombre de couches dans l'architecture TCP/IP. Cependant, on considère généralement qu'il y a de 3 à 5 couches disponibles, nous en verrons 4 pour simplifier.

• Couche Application
• Couche Transport
• Couche Internet
• Couche Réseau

Comme vous pouvez le voir, l'architecture du protocole TCP/IP est très proche du modèle OSI. De même qu'avec le modèle OSI, nous ajoutons et soustrayons les en-têtes pour chaque couche.

Par exemple, utilisons une des analogies les plus communes pour les machines modernes en réseau, la lettre par courrier postal. Chaque chose est effectuée par étape, identique en TCP/IP.

Vous désirez envoyer une lettre à quelqu'un en lui demandant comment il va, et ce qu'il fait. Pour cela, vous devez poser des questions. Les questions seront situées à l'intérieur de la couche Application.

Après ceci vous écrirez les questions sur une feuille de papier que vous mettrez dans une enveloppe sur laquelle vous écrirez l'adresse de destination. Peut-être quelque chose comme :

Attn: John Doe

C'est l'équivalent de la couche Transport en TCP/IP.

À ce niveau nous écrivons l'adresse sur l'enveloppe, comme ceci :

V. Andersgardsgatan 2
41715 Gothenburg

Ça se passe dans l'analogie comme dans la couche Internet. La couche Internet contient les informations indiquant comment joindre le destinataire, ou l'hôte, dans un réseau TCP/IP. De la même façon qu'une enveloppe avec une adresse. C'est, en d'autres termes, l'équivalent de l'adresse IP (ex. IP 192.168.0.4).

L'étape finale est de poster l'enveloppe dans une boîte aux lettres. Ce qui équivaut à peu près à envoyer un paquet dans la couche Réseau. La couche Réseau contient les fonctions et les routines pour accéder au réseau physique par lequel le paquet sera transporté.

Quand finalement nous recevons la lettre, nous la retirerons de l'enveloppe (décapsulation). La lettre que nous recevons peut parfois demander une réponse ou non. Dans certains cas, il peut y avoir une réponse du destinataire, alors le destinataire devient expéditeur, et l'expéditeur devient destinataire.

Étant donné que iptables et Netfilter opèrent principalement sur les couches Internet et Transport, ce sont les couches sur lesquelles nous insisterons le plus dans ce chapitre. Sous la couche Internet, nous verrons presque exclusivement le protocole IP. Il existe quelques ajouts à ceci, par exemple, le protocole GRE, mais ils sont très rares. À cause de tous ces facteurs, nous nous concentrerons sur le protocole IP de la couche Internet, et TCP, UDP, ICMP de la couche Transport.

Le protocole IP réside dans la couche Internet, comme nous l'avons déjà dit. C'est le protocole dans la pile TCP/IP qui permet à votre machine, routeur, switch, etc. de savoir vers où un paquet spécifique est envoyé. Ce protocole est véritablement le cœur de toute la pile TCP/IP, et la base de tout sur Internet.

Le protocole IP encapsule le paquet de la couche Transport avec l'information du protocole de la couche Transport, ainsi que d'autres informations utiles. Tout ceci, bien sûr, est très précisément standardisé. Nous allons en parler dans ce chapitre.

Le protocole IP possède un couple de fonctionnalités de base qu'il doit être capable de traiter. Il doit être capable de définir le datagramme, lequel est le bloc de construction suivant créé par la couche Transport (ce qui en d'autres termes peut être TCP, UDP ou ICMP par exemple). Le Protocole IP définit aussi le système d'adressage Internet que nous utilisons aujourd'hui. Ceci indique que le protocole IP définit comment les hôtes peuvent se joindre entre eux, il indique aussi comment nous pouvons router les paquets, bien sûr. Les adresses dont nous parlons sont généralement appelées adresses IP. Usuellement, quand nous parlons d'adresses IP, nous parlons de chiffres avec des points (ex. 127.0.0.1). C'est principalement pour rendre l'adresse IP plus lisible pour l'œil humain, car l'adresse IP est actuellement un champ de 32 bits de 1 et de 0 (127.0.0.1 pourrait désormais être lu comme 01111111000000000000000000000001 dans l'en-tête IP).

Le protocole IP doit aussi pouvoir décapsuler et encapsuler le datagramme IP (donnée IP) et envoyer ou recevoir le datagramme d'une couche Réseau, ou d'une couche Transport. Ceci peut sembler évident, mais parfois ce ne l'est pas. Au sommet de tout ça, il possède deux fonctions qu'il doit exécuter correctement, ce qui est particulièrement intéressant pour le pare-feu et le routage. Le protocole IP est responsable du routage des paquets depuis un hôte vers un autre. La plupart du temps sur des réseaux uniques, c'est un processus simple. Nous avons deux options différentes, soit le paquet est destiné au réseau local, soit il passe par une passerelle. Mais lorsque vous commencez à travailler avec des pare-feux et des stratégies de sécurité conjointement avec de multiples interfaces réseau et différentes routes, ce peut être casse-tête pour les administrateurs. La dernière des responsabilités du protocole IP est qu'il doit fragmenter et réassembler les datagrammes qui ont préalablement été fragmentés, ou qui nécessitent d'être fragmentés pour s'adapter à la taille du paquet pour la topologie du réseau sur lequel nous sommes connectés. Si ces fragments de paquet sont suffisamment petits, ils peuvent causer d'horribles maux de tête aux administrateurs. Le problème est, qu'une fois qu'ils sont fragmentés, nous commençons à avoir des soucis pour lire même les en-têtes du paquet.

Le protocole IP est aussi un protocole en mode datagramme, ce qui indique que IP ne « négocie » pas une connexion. Un protocole orienté connexion, en d'autres termes, négocie une « connexion » (appelée poignée de main - établissement de connexion) et lorsque toutes les données ont été envoyées, stoppe la connexion. TCP est un exemple de ce genre de protocole, cependant, il est implémenté au sommet du protocole IP. Il y a plusieurs raisons pour lesquelles il n'est pas orienté connexion, mais parmi d'autres, l'établissement de connexion n'est pas nécessaire à ce moment ce qui ne ferait qu'ajouter du temps système. Comme vous pouvez le voir, envoyer une requête et ensuite attendre un moment pour la réponse est préférable à envoyer un paquet pour dire que nous voulons établir une connexion, ensuite recevoir la réponse nous disant que la connexion est ouverte, et finalement accuser réception que nous sommes au courant que la connexion est ouverte, et alors envoyer la requête, et après renvoyer un autre paquet pour couper la connexion et attendre une autre réponse.

IP est également connu comme un protocole incertain, c'est-à-dire qu'il ne permet pas de savoir si un paquet a été reçu ou non. Il reçoit simplement un paquet depuis la couche transport et le passe à la couche réseau, et ne fait rien de plus. Il peut recevoir un paquet en retour, lequel passe de la couche réseau au protocole IP et ensuite à la couche transport. Cependant, il ne vérifie pas si c'est un paquet en réponse ou si le paquet a été reçu dans un autre but. La même chose s'applique en termes d'incertitude IP comme pour le mode datagramme, ce qui nécessitera l'envoi d'un paquet supplémentaire en retour pour chaque paquet envoyé. Par exemple, considérons une consultation de table DNS. Nous envoyons une requête DNS au serveur de nom. Si nous ne recevons pas de réponse, nous savons que quelque chose ne fonctionne pas et renvoyons une requête de consultation, mais dans l'usage normal nous envoyons une requête et obtenons une réponse en retour. Ajouter de la fiabilité à ce protocole signifierait que la requête nécessite deux paquets (une requête et une confirmation que le paquet a été reçu) et ensuite deux paquets pour la réponse (une réponse et un accusé réception comme quoi le paquet a été reçu). En d'autres termes, nous doublons le nombre de paquets nécessaires, et bien sûr doublons le nombre de données à transmettre.

Comme vous avez pu le comprendre dans l'introduction sur le protocole IP, un paquet IP contient différentes parties dans l'en-tête. Celui-ci est méticuleusement divisé en plusieurs parties, et chaque partie est aussi petite que possible pour faire ce travail, ceci pour limiter le temps système au minimum. Vous verrez la configuration exacte d'un en-tête IP dans l'image Section 2.3, « En-Têtes IP »En-Têtes IP.

Le protocole IP est décrit principalement dans RFC 791 - Internet Protocol. Cependant, cette RFC est aussi mise à jour par la RFC 1349 - Type of Service in the Internet Protocol Suite, rendue obsolète par RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, mise à jour par RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP et RFC 3260 - New Terminology and Clarifications for Diffserv.

Version - bits 0-3. C'est le numéro de version du protocole IP en binaire. IPv4 est nommé par 0100, tandis que IPv6 par 0110. Ce champ n'est généralement pas très utilisé pour le filtrage. La version décrite dans la RFC 791 est IPv4.

IHL (Longueur d'en-tête Internet) - bits 4-7. Ce champ nous indique la longueur de l'en-tête IP en 32 bits. Comme vous pouvez le voir, nous avons partagé l'en-tête (32 bits par ligne) dans l'image. Le champ Options est de longueur variable, ainsi nous ne pouvons jamais être absolument sûrs de la longueur totale de l'en-tête sans ce champ.

Type of Service, DSCP, ECN - bits 8-15. C'est une des zones les plus complexes de l'en-tête IP pour la simple raison qu'elle a été mise à jour trois fois. Elle a toujours eu la même utilisation de base, mais l'implémentation a changé plusieurs fois. En premier le champ fut appelé Type de Service. Le Bit 0-2 du champ fut appelé champ Précédence. Le Bit était de délai normal/bas, le Bit 4 de débit normal/haut, le Bit 5 de fiabilité normale/haute et le Bit 6-7 réservé pour un usage futur. Ceci est toujours en usage sur de nombreux sites qui ont du matériel ancien, ce qui cause toujours certains problèmes pour l'Internet. Parmi d'autres choses, le Bit 6-7 est spécifié pour être placé à 0. Dans les mises à jour ECN (RFC, nous partons du principe que ces bits réservés sont désormais placés à la valeur 0. Mais nombre de pare-feux et routeurs ont été programmés pour vérifier si ces bits sont placés à 1, et si les paquets le sont, le paquet est supprimé. Aujourd'hui, c'est clairement une violation de la RFC, mais vous ne pouvez pas faire grand-chose, excepté vous plaindre.

La seconde itération fut lorsque le champ a été modifié dans le champ DS comme spécifié dans la RFC 2474. DS pour Differentiated Services. Selon ce standard les bits 8-14 sont Differentiated Services Code Point (DSCP) et les deux bits restants (15-16) sont toujours inutilisés. Le champ DSCP est à peu près utilisé comme le champ ToS avant, pour marquer pour quel type de service ce paquet serait traité comme si le routeur en question ne faisait pas de différence entre eux. Un gros changement est que le matériel doit ignorer les bits inutilisés pour être pleinement conforme à la RFC 2474, ce qui signifie que nous sommes délivrés des disputes comme expliqué précédemment, aussi longtemps que les fabricants de matériel suivent cette RFC.

Le troisième, et pratiquement dernier, changement du champ ToS a été quand les deux bits inutilisés furent utilisés par ECN (Explicit Congestion Notification), comme défini dans la RFC 3168. ECN est utilisé pour permettre de savoir s'il existe une congestion des routeurs, avant il démarre la suppression des paquets, ainsi le nœud final pourra ralentir la transmission des données. Précédemment, la suppression de données était le seul moyen qu'avait un routeur pour annoncer qu'il était en surcharge, et les nœuds terminaux devaient faire un redémarrage lent pour chaque paquet supprimé, et ensuite accélérer de nouveau. Les deux bits sont appelés ECT (ECN Capable Transport) et CE (Congestion Experienced).

L'itération finale de l'ensemble est la RFC 3260 qui apporte quelques terminologies et clarifications nouvelles pour l'utilisation du système DiffServ. Elle n'améliore pas énormément de choses, sauf la terminologie. La RFC est également utilisée pour clarifier certains points qui ont été discutés entre développeurs.

Total Length - bits 16 - 31. Ce champ nous renseigne sur la taille des paquets en octets, incluant les en-têtes. La taille maximum est 65 535 octets. La taille minimum d'un paquet est de 576 octets, sans prendre en compte si le paquet arrive en fragments ou non. Il est recommandé d'envoyer des paquets plus gros que cette limite seulement s'il est garanti que l'hôte puisse les recevoir, selon la RFC 791. Cependant, actuellement la plupart des réseaux fonctionnent avec des tailles de paquets de 1500 octets. Ceci inclut la majorité des connexions ethernet et Internet.

Identification - bits 32 - 46. Ce champ est utilisé pour aider a réassembler les paquets fragmentés.

Fanions - bits 47 - 49. Ce champ contient des fanions mélangés appartenant à la fragmentation. Le premier bit est réservé, mais toujours inutilisé, et doit être placé à 0. Le second bit est placé à 0 si le paquet peut être fragmenté, et à 1 s'il ne peut pas être fragmenté. Le troisième et dernier bit peut être placé à 0 s'il était le dernier fragment, et à 1 s'il n'y a pas de fragments supplémentaires de ce même paquet.

Fragment Offset - bits 50 - 63. Le champ fragment décalé indique de quel datagramme le paquet dépend. Les fragments sont calculés sur 64 bits, et le premier fragment a un décalage zéro.

Durée de vie - bits 64 - 72. Le champ TTL (Time To Live) nous indique la durée de vie d'un paquet, ou combien de « sauts » (hops) il peut réaliser sur l'Internet. Chaque processus qui touche le paquet doit supprimer un point du champ TTL, et si le TTL atteint zéro, le paquet doit être détruit ou écarté. C'est un usage de base fonctionnant comme une sécurité, car si le paquet n'est pas supprimé/écarté il peut se transformer en boucle incontrôlable entre un ou plusieurs hôtes. Pour la destruction l'hôte renverra un message ICMP « Destination Unreachable » à l'expéditeur.

Protocole - bits 73 - 80. Dans ce champ le protocole du niveau de la couche suivante est indiqué. Par exemple, ce peut être TCP, UDP ou ICMP parmi d'autres. Tous ces nombres sont définis par la Internet Assigned Numbers Authority (IANA). Ces nombres peuvent être retrouvés sur le site Internet Assigned Numbers Authority.

Somme de contrôle d'en-tête - bits 81 - 96. C'est un contrôle de l'en-tête IP du paquet. Ce champ est recalculé au niveau de chaque hôte qui modifie l'en-tête, ce qui signifie à peu près chaque hôte que le paquet traverse, la modification se faisant le plus souvent au niveau du champ TTL.

Adresse de l'expéditeur - bits 97 - 128. C'est le champ adresse de la source. Elle est généralement écrite sur 4 octets, traduite du binaire en nombres décimaux avec des points entre eux. Par exemple, 127.0.0.1. Le champ permet au destinataire de connaître l'adresse d'expédition du paquet.

Adresse de destination - bits 129 - 160. Le champ adresse contient l'adresse de destination, et surprise, il est formaté de la même façon que l'adresse de l'expéditeur.

Options - bits 161 - 192 <> 478. Le champ options n'est pas optionnel, comme il pourrait le sembler. C'est un des champs les plus complexes dans les en-têtes IP. Le champ options contient divers réglages optionnels à placer dans l'en-tête, comme minuterie Internet, SACK ou enregistrement de route. Ces options sont toutes optionnelles, le champ options peut avoir des longueurs différentes, et donc l'en-tête IP complet. Cependant, nous calculons toujours l'en-tête IP sur 32 bits, nous devons toujours clore l'en-tête sur un même nombre, qui est un multiple de 32. Le champ peut contenir zéro ou plusieurs options.

Le champ options démarre avec un champ de 8 bits qui nous permet de savoir quelles options ont été utilisées dans le paquet. Les options sont toutes listées dans la table Tableau D.1, « TCP Options », dans l'annexe Annexe D,Annexe D. Options TCP. Pour plus d'informations sur les différentes options, lisez les RFC correspondantes. Pour une liste des options IP mises à jour, voir Internet Assigned Numbers Authority.

Remplissage - bits variables. C'est un champ de remplissage utilisé pour la fin de l'en-tête à la frontière des 32 bits. Le champ doit toujours être une ligne de zéros jusqu'à la fin.

Le protocole TCP réside au sommet du protocole IP. C'est un protocole architecture qui possède des fonctions natives pour vérifier si les données sont reçues correctement par les hôtes destinataires. Les buts principaux du protocole TCP sont de vérifier que les données sont envoyées et reçues de façon fiable, que les données sont transportées entre la couche Internet et la couche Application correctement, et que les paquets joignent le bon programme dans la couche application, et dans le bon ordre. Tout ceci est possible grâce aux en-têtes TCP du paquet.

Le protocole TCP considère les données comme un flux continu avec un signal de début et de fin. Le signal qui indique qu'un nouveau flux est en attente d'ouverture est appelé établissement de connexion SYN à trois voies dans TCP, et consiste en un paquet envoyé avec le bit SYN. Les réponses se font soit avec SYN/ACK soit avec SYN/RST pour permettre au client de savoir si la connexion a été acceptée ou refusée respectivement. Si le client reçoit un paquet SYN/ACK, il peut de nouveau répondre, cette fois avec un paquet ACK. À ce moment, la connexion est établie et les données peuvent être envoyées. Pendant l'établissement de connexion (handshake) initial, toutes les options spécifiques qui seront utilisées à travers la connexion TCP sont aussi négociées, comme ECN, SACK, etc.

Tandis que le flux de données est actif, nous avons d'autres mécanismes à voir. C'est la partie fiabilité de TCP. Ceci est réalisé de façon simple, en utilisant un numéro d'interclassement (sequence) dans le paquet. Chaque fois que nous envoyons un paquet, nous donnons une nouvelle valeur au numéro d'interclassement, et quand le destinataire reçoit le paquet, il envoie en retour un paquet ACK à l'expéditeur. Le paquet ACK accuse réception du paquet qui a été reçu correctement. Le numéro d'interclassement vérifie aussi que le paquet inséré dans un flux de données est en bon ordre.

Ensuite la connexion est fermée, ce qui est fait en envoyant un paquet FIN comme point final. Le destinataire répond alors en envoyant un paquet FIN/ACK. Plus aucune donnée ne peut alors être envoyée, mais l'expéditeur ou le destinataire peuvent toujours finir d'envoyer leurs données. Une fois que l'expéditeur ou le destinataire désirent clore la connexion complètement, ils envoient un paquet FIN en retour, et le correspondant répond avec un paquet FIN/ACK. Une fois cette procédure complète effectuée, la connexion est fermée proprement.

Comme nous le verrons plus tard, les en-têtes TCP contiennent des sommes de contrôle. La somme de contrôle consiste en une simple empreinte numérique du paquet. Avec cette empreinte numérique, nous pouvons avec une grande exactitude savoir si le paquet a été corrompu d'une façon ou d'une autre pendant le transit entre les hôtes.

Les en-têtes TCP doivent être capables d'exécuter toutes les tâches ci-dessus. Nous avons déjà expliqué quand et où certains de ces en-têtes sont utilisés, mais il y a encore d'autres zones que nous n'avons pas vues en détail. Ci-dessous vous avez une image de l'ensemble des en-têtes TCP. Il est formaté en 32 bits par ligne, comme vous pouvez le voir.

Port expéditeur - bit 0 - 15. C'est le port source du paquet. Le port source était à l'origine lié directement au processus du système d'expédition. Aujourd'hui, nous utilisons une empreinte numérique entre les adresses IP, et les ports source et destination pour pouvoir les lier en une seule application ou programme.

Port destinataire - bit 16 - 31. C'est le port de destination du paquet TCP. Avec le port source, il était lié à l'origine directement au processus du système de réception. Aujourd'hui, une empreinte numérique est utilisée, qui nous permet d'avoir davantage de connexions ouvertes en même temps. Quand un paquet est reçu, les ports source et destination sont renversés dans la réponse à l'hôte d'origine, ainsi le port de destination est maintenant le port source, et le port source devient le port de destination.

Numéro d'interclassement - bit 32 - 63. Le champ numéro d'interclassement est utilisé pour mettre en place un numéro sur chaque paquet TCP de façon que le flux TCP puisse être proprement ordonnancé (i.e. les paquets s'ordonnent dans le bon ordre). Le numéro d'interclassement est alors renvoyé dans le champ ACK pour accuser réception que le paquet a été correctement reçu.

Numéro d'accusé réception - bit 64 - 95. Ce champ est utilisé quand nous accusons réception d'un paquet spécifique qu'un hôte a reçu. Par exemple, nous recevons un paquet avec un numéro d'interclassement, et si tout est OK avec le paquet, nous répondons avec un paquet ACK et le numéro d'interclassement identique au numéro d'interclassement d'origine.

Décalage de données - bit 96 - 99. Ce champ indique la longueur de l'en-tête TCP, et où la partie données du paquet démarre. Il est codé sur 4 bits, et mesure l'en-tête TCP en 32 bits. L'en-tête se termine toujours sur une limite de 32 bits, même avec différentes options.

Réservé - bit 100 - 103. Ces bits sont réservés pour un usage futur. Dans la RFC 793 les bits CWR et ECE sont également inclus. Selon la RFC 793 les bits 100-105 (i.e. ceci et les champs CWR et ECE) doivent être placés à zéro pour être pleinement compatibles. Plus tard, nous verrons cela quand nous commencerons l'introduction de ECN. Ceci a causé nombre de désagréments à cause de machines Internet comme des pare-feux et routeurs qui suppriment des paquets. C'est toujours vrai lors de la rédaction de ces lignes.

CWR - bit 104. Ce bit a été rajouté dans la RFC 3268 et est utilisé par ECN. CWR pour Congestion Window Reduced, est utilisé par la partie des données envoyées au destinataire pour l'informer que la fenêtre d'encombrement a été réduite. Quand la fenêtre d'encombrement est réduite, nous envoyons moins de données par unité de temps, pour pouvoir assurer la charge totale du réseau.

ECE - bit 105. Ce bit a aussi été rajouté avec la RFC 3268, il est utilisé par ECN. ECE pour ECN Echo. Il est utilisé par la pile TCP/IP sur l'hôte destinataire qui permet à l'expéditeur de savoir si un paquet CE a été reçu. La même chose s'applique ici, comme pour le bit CWR, qui était à l'origine une partie du champ réservé et à cause de ça, certains matériels réseau supprimaient les paquets si les champs contenaient autre chose que des zéros. C'est actuellement toujours vrai pour beaucoup de matériels, malheureusement.

URG - bit 106. Ce bit nous indique si nous utilisons le champ Urgent Pointer ou non. S'il est placé à 0, pas d'utilisation de Urgent Pointer, s'il est placé à 1, utilisation de Urgent Pointer.

ACK - bit 107. Ce bit est placé dans un paquet pour indiquer qu'il s'agit d'une réponse à un autre paquet que nous avons reçu, et qui contient des données. Un paquet accusé réception est toujours envoyé pour indiquer que nous avons reçu le paquet, et qu'il ne contient pas d'erreurs. Si ce bit est placé, l'expéditeur des données d'origine vérifiera le numéro d'accusé réception pour voir quel paquet est actuellement en accusé réception, et ensuite videra les tampons.

PSH - bit 108. Le fanion PUSH est utilisé pour prévenir le protocole TCP sur des hôtes intermédiaires d'envoyer les données à l'utilisateur actuel, incluant l'implémentation TCP sur l'hôte destinataire. Ceci expédie toutes les données.

RST - bit 109. Le fanion RESET est placé pour indiquer à l'hôte de relancer la connexion TCP. Ceci est dû à divers scénarios, les principales raisons étant que la connexion a été coupée, la connexion n'existe pas, ou le paquet contient des erreurs.

SYN - bit 110. Le SYN (Synchronize Sequence Numbers) est utilisé pendant l'établissement initial de la connexion. Il est placé dans deux circonstances, le paquet initial qui ouvre la connexion, et le paquet SYN/ACK en réponse. Il ne doit jamais être utilisé en dehors de ces cas.

FIN - bit 111. Le bit FIN indique que l'hôte qui envoie le bit FIN n'a plus de données à expédier. Quand l'hôte voit le bit FIN, il répond avec un FIN/ACK. Une fois cela fait, l'expéditeur du bit FIN ne peut plus envoyer de données. Cependant, l'hôte peut continuer à expédier les données jusqu'à ce qu'il ait fini, il enverra ensuite un paquet FIN en retour, et attendra le FIN/ACK final, après ça la connexion est en état CLOSED.

Window - bit 112 - 127. Le champ fenêtre est utilisé par l'hôte destinataire pour dire à l'expéditeur combien de données il autorise à cet instant. Ceci est fait en envoyant un ACK en retour, qui contient un numéro d'interclassement nécessaire pour l'accusé réception, le champ fenêtre contient alors les numéros d'interclassement maximum acceptés que l'expéditeur peut utiliser avant de recevoir le prochain paquet ACK. Le paquet ACK suivant met à jour la fenêtre que l'expéditeur peut utiliser.

Checksum - bit 128 - 143. Ce champ contient la somme de contrôle de l'en-tête TCP complet. C'est un complément d'une somme de chaque mot de 16 bits dans l'en-tête. Si l'en-tête ne finit pas sur une limite de 16 bits, le bit additionnel est placé à zéro. Tandis que la somme de contrôle est calculée, le champ somme de contrôle est placé à zéro. La somme de contrôle couvre également un pseudo en-tête de 96 bits contenant la destination, adresse source, protocole, et longueur TCP. Ceci pour des raisons de sécurité.

Pointeur urgent - bit 144 - 159. Pointeur placé à la fin des données considérées comme urgentes. Si la connexion a d'importantes données qui doivent être exécutées le plus tôt possible par le destinataire, l'expéditeur peut placer un drapeau URG pour indiquer où les données urgentes finissent.

Options - bit 160 - **. Le champ Options est un champ de longueur variable qui contient des en-têtes optionnels. De façon basique, ce champ contient 3 sous-champs chaque fois. Un champ initial nous indique la longueur du champ Options, un second indique quelles options sont utilisées, et quand nous obtenons les options. Une liste complète de toutes les options TCP se trouve dans Annexe D,Annexe D. Options TCP.

Padding - bit **. Le champ remplissage complète l'en-tête TCP jusqu'à ce que tout l'en-tête atteigne la limite de 32 bits. Ceci assure que la partie données du paquet débute sur une limite de 32 bits, et qu'aucune donnée n'est perdue dans le paquet. Le remplissage ne contient toujours que des zéros.

Le User Datagram protocol (UDP protocol) est un protocole très basique et simple au sommet du protocole IP. Il a été développé pour permettre une transmission des données très simple sans détection d'erreur d'aucune sorte. Cependant, il est très bien adapté pour les applications de type requête/réponse, par exemple DNS, etc., car nous savons qu'à moins d'obtenir une réponse du serveur DNS, la requête sera perdue quelque part. Parfois il peut être utile de se servir du protocole UDP au lieu de TCP, comme lorsque nous voulons seulement une détection d'erreurs/pertes, mais sans faire attention à l'ordre d'interclassement des paquets. Ceci supprime quelques en-têtes présents dans le protocole TCP. Nous pouvons aussi faire d'autres choses, créer notre propre protocole au sommet de UDP qui ne contient que l'interclassement, mais pas d'erreur ni de perte.

Le protocole UDP est spécifié dans la RFC 768 - User Datagram Protocol. C'est une RFC très brève.

On peut dire que l'en-tête UDP est un en-tête TCP très basique et simplifié. Il contient la destination, le port source, la longueur d'en-tête et une somme de contrôle comme indiqué dans l'image ci-dessous.

Port source - bit 0-15. C'est le port source du paquet, décrivant où un paquet en réponse sera envoyé. Par exemple, quelquefois nous n'exigeons pas de paquet en réponse, le paquet peut alors être placé à zéro en port source. Dans la plupart des implémentations, il est placé à un nombre quelconque.

Port destination - bit 16-31. Le port de destination du paquet. Nécessaire pour tous les paquets, à l'opposé du port source d'un paquet.

Longueur - bit 32-47. Le champ longueur spécifie la taille de l'ensemble du paquet en octets, incluant les en-têtes et les données. Le plus petit paquet possible est de 8 octets.

Somme de contrôle - bit 48-63. La somme de contrôle est du même type que celle utilisée dans les en-têtes TCP, sauf qu'elle contient un ensemble de données différent. En d'autres termes, c'est un complément d'un complément de parties de l'en-tête IP, de l'ensemble de l'en-tête UDP, les données UDP et le remplissage avec des zéros, lorsque nécessaire.

Les messages ICMP sont utilisés pour les types d'erreurs basiques rapportées entre hôtes, ou entre hôte et passerelle. Entre passerelles, un protocole appelé GGP (Gateway to gateway protocol) ou passerelle à passerelle doit normalement être utilisé pour le rapport d'erreur. Comme nous l'avons déjà vu, le protocole IP n'a pas été conçu pour parfaire le maniement d'erreur, mais les messages ICMP résolvent une partie de ces problèmes. Le gros problème de ce point de vue est que les en-têtes des messages ICMP sont plutôt compliqués, et diffèrent de message en message. Cependant, ce n'est pas une grosse difficulté du point de vue filtrage la plupart du temps.

La forme de base du message contient l'en-tête IP standard, le type, le code et la somme de contrôle. Tous les messages ICMP contiennent ces champs. Le type spécifie le genre d'erreur du message de réponse, par exemple, destination injoignable, écho, réponse d'écho, ou message redirigé. Le code donne plus d'informations si nécessaire. Si le paquet est de type destination injoignable, il y a plusieurs valeurs possibles comme réseau injoignable, hôte injoignable, ou port injoignable. La somme de contrôle est simplement une somme pour l'ensemble du paquet.

Comme vous avez pu le noter, j'ai mentionné explicitement l'en-tête IP pour le paquet ICMP. C'est dû au fait que l'en-tête IP actuel est une partie intégrale du paquet ICMP, et que le protocole ICMP est au même niveau, dans un sens, que le protocole IP. ICMP utilise le protocole IP comme s'il était à un niveau plus haut, mais en même temps ce n'est pas le cas. ICMP est une partie intégrante de IP, et ICMP doit être présent dans chaque implémentation de IP.

Comme déjà expliqué, les en-têtes de type ICMP diffèrent légèrement du type IP. La plupart des types ICMP permettent de les grouper par leurs en-têtes. À cause de cela, nous verrons en premier l'en-tête de base, et ensuite chaque groupe de type spécifique.

Tous les paquets contiennent des valeurs de base des en-têtes IP comme nous l'avons vu précédemment.

• Version - Doit toujours être placé à 4.
• Longueur en-tête Internet - Longueur de l'en-tête en mots de 32 bits.
• Type de Service - Voir au-dessus. Doit être placé à 0, seule légitimité selon la RFC 792 - Internet Control Message Protocol.
• Longueur totale - Longueur totale de l'en-tête et de la partie données du paquet, comptée en octets.
• Décalages d'Identification de fanions et fragments - Issu du protocole IP.
• Durée de vie - Nombre de sauts que le paquet peut effectuer.
• Protocole - Quelle version de ICMP est utilisée (doit toujours être à 1).
• En-tête somme de contrôle. Voir l'explication IP.
• Adresse source - L'adresse de la source qui a envoyé le paquet. Ce n'est pas entièrement vrai, car le paquet peut avoir une autre adresse source, que celle située sur la machine en question. Les types ICMP peuvent produire cet effet, ce sera noté si nécessaire.
• Adresse de destination - L'adresse de destination du paquet.

Il existe aussi de nouveaux en-têtes utilisés par les types ICMP. Ce sont les suivants :

• Type - Le champ type contient le type ICMP du paquet. Par exemple les paquets ICMP Destination Injoignable auront un type 3 placé. Pour une liste complète des différents types ICMP voir Annexe C,Annexe C. Types ICMP. Ce champ contient 8 bits au total.
• Code - Tous les types ICMP contiennent différents codes. Certains types ont un code unique, tandis que d'autres ont plusieurs codes qu'ils peuvent utiliser. Par exemple, le type ICMP Destination Injoignable peut avoir au moins les codes 0, 1, 2, 3, 4 ou 5. Chaque code aura un comportement différent selon le contexte. Pour une liste complète des différents codes, voir Annexe C,Annexe C. Types ICMP. Ce champ est de 8 bits de longueur totale. Nous verrons les différents codes un peu plus en détail plus tard dans cette section.
• Somme de contrôle - La somme de contrôle est un champ de 16 bits contenant un complément de complément des en-têtes démarrant avec le type ICMP. Tandis que le calcul de la somme de contrôle s'effectue, le champ de celle-ci sera placé à zéro.

À ce point les en-têtes peuvent présenter un visage différent. Nous décrirons les types ICMP les plus communs un par un, avec un bref aperçu de leurs différents en-têtes et codes.

3-9-1. Écho requête/réponse ICMP▲

J'ai choisi de parler des paquets ICMP écho requête et réponse, ils sont très proches l'un par rapport à l'autre. La différence est que l'écho requête est de type 8, alors que l'écho réponse est de type 0. Quand un hôte reçoit un type 8, il répond avec un type 0.

Quand la réponse est envoyée, les adresses source et destination sont permutées. Après les deux changements effectués, la somme de contrôle est recalculée, et la réponse envoyée. Il y a un seul code pour les deux types, ils sont toujours placés à 0.

• Identifiant - Il est placé dans le paquet requête, et se retrouve en retour dans la réponse, il permet de synchroniser les différents pings de requête et de réponse.
• Numéro d'interclassement - Le numéro d'interclassement pour chaque hôte démarre généralement à 1 et est incrémenté de 1 pour chaque paquet.

Les paquets contiennent aussi une partie de données. Par défaut, la partie de données est généralement vide, mais elle peut contenir des données au hasard spécifiées par l'utilisateur.

3-9-2. Destination Injoignable ICMP▲

Les trois premiers champs montrés dans l'image sont les mêmes que ceux précédemment décrits. Le type Destination Injoignable possède six codes de base qui peuvent être utilisés, comme indiqué ci-dessous.

• Code 0 - Réseau injoignable - Vous indique si un réseau spécifique est actuellement injoignable.
• Code 1 - Hôte injoignable - Un hôte spécifique est actuellement injoignable.
• Code 2 - Protocole injoignable - Ce code vous indique si un protocole spécifique (TCP, UDP, etc.) ne peut être joint pour l'instant.
• Code 3 - Port injoignable - Si un port (ssh, http, ftp, etc.) n'est pas joignable vous obtenez ce message.
• Code 4 - Fragmentation nécessaire et placement de DF - Si le paquet nécessite d'être fragmenté pour être délivré, mais que le bit « Do not Fragment » est placé dans le paquet, la passerelle retourne ce message.
• Code 5 - Échec de la route source - Si la route source échoue pour quelque raison, ce message est retourné.
• Code 6 - Destination réseau inconnue - S'il n'y a pas de route vers un réseau spécifique, ce message est retourné.
• Code 7 - Destination hôte inconnue - S'il n'y a pas de route vers l'hôte spécifique, ce message est retourné.
• Code 8 - Hôte source isolé (obsolète) - Si l'hôte est isolé, ce message sera retourné. Ce code est obsolète aujourd'hui.
• Code 9 - Réseau de destination administrativement interdit - Si un réseau est bloqué au niveau de la passerelle et que votre paquet est incapable de le joindre à cause de ça, vous obtiendrez ce code ICMP en retour.
• Code 10 - Hôte de destination administrativement interdit - Si vous ne pouvez joindre l'hôte parce qu'il a été interdit administrativement (ex. administration du routage), vous obtenez ce message.
• Code 11 - Réseau injoignable pour TOS (Type de service) - Si un réseau est injoignable à cause d'un mauvais TOS placé dans votre paquet, ce code sera généré en retour.
• Code 12 - Hôte injoignable pour TOS - Si votre paquet est incapable de joindre l'hôte à cause du TOS du paquet, ce message sera renvoyé.
• Code 13 - Communication administrativement interdite par filtrage - Si le paquet est interdit pour une raison de filtrage (ex. pare-feu), vous obtenez le code 13 en retour.
• Code 14 - Violation de loi de précédence - Envoyé par le premier routeur pour notifier à un hôte connecté que la précédence utilisée n'est pas autorisée pour la combinaison spécifique source/destination.
• Code 15 - Effet de coupure de précédence - Le premier routeur peut envoyer ce message à un hôte si le datagramme reçu a un niveau de précédence trop bas.

Au sommet de tout ça, il existe également une petite partie « données », qui devrait être l'en-tête Internet et le datagramme IP d'origine en 64 bits. Si le protocole de niveau suivant contient des ports, etc. il est supposé que les ports seront disponibles dans les 64 bits supplémentaires.

3-9-3. Coupure de source▲

Un paquet coupure de source peut être envoyé à l'expéditeur d'un paquet ou d'un flux de paquets trop lent pour permettre de continuer à envoyer des données. Notez que la passerelle ou l'hôte que les paquets traversent peuvent aussi décharger les paquets sans prévenir, au lieu d'envoyer des paquets coupure de source.

Ces paquets ne contiennent pas d'en-têtes supplémentaires sauf la partie données, laquelle contient l'en-tête Internet plus les 64 bits du datagramme de données d'origine. Ceci est utilisé pour harmoniser le message de coupure source au processus correct, lequel envoie des données à travers la passerelle ou vers l'hôte de destination.

Tous les paquets coupure source ont leur type ICMP placé à 4. Ils n'ont pas de code sauf le 0.

Aujourd'hui, il existe de nouveaux moyens de notifier à l'expéditeur ou au destinataire qu'une passerelle ou un hôte sont en surcharge. Par exemple avec le système ECN (Explicit Congestion Notification).

3-9-4. Redirection▲

Le type redirection est envoyé dans un seul cas. Considérez ceci, vous avez un réseau (192.168.0.0/24) avec plusieurs clients et hôtes, et deux passerelles. Une passerelle sur un réseau 10.0.0.0/24, et une passerelle par défaut pour le reste de l'Internet. Maintenant considérez qu'un des hôtes soit sur le réseau 192.168.0.0./24 et n'ait pas de route vers 10.0.0.0/24, mais ait accès à la passerelle par défaut. Il envoie un paquet à la passerelle par défaut, laquelle bien sûr connaît le réseau 10.0.0.0/24. Cette passerelle par défaut peut déduire qu'il est plus facile d'envoyer le paquet directement à la passerelle 10.0.0.0/24, car ce paquet entrera et quittera la passerelle par la même interface. La passerelle par défaut enverra désormais un paquet ICMP Redirect unique à l'hôte, à travers la passerelle 10.0.0.0/24. L'hôte saura maintenant que la passerelle la plus proche est 10.0.0.0/24, et l'utilisera dans le futur.

L'en-tête principal du type Redirect est le champ Gateway Internet Address. Ce champ indique à l'hôte la passerelle correcte, qui sera réellement utilisée. Le paquet contient aussi l'en-tête IP du paquet original, et les premiers 64 bits de données dans le paquet d'origine, lequel est utilisé pour se connecter au processus qui envoie les données.

Le type Redirection possède 4 codes, qui sont les suivants.

• Code 0 - Redirection pour le réseau - Seulement utilisé pour rediriger l'ensemble du réseau (voir l'exemple ci-dessus).
• Code 1 - Redirection pour l'hôte - Seulement utilisé pour les redirections d'un hôte spécifique.
• Code 2 - Redirection pour TOS et réseau - Seulement utilisé pour rediriger un Type de Service spécifique et vers un ensemble réseau. Utilisé comme le code 0, mais aussi basé sur TOS.
• Code 3 - Redirection pour TOS et hôte - Seulement utilisé pour rediriger vers un Type de Service spécifique vers un hôte spécifique. utilisé comme le code 1, mais aussi basé sur le TOS.

3-9-5. TTL égale 0▲

Le type ICMP TTL égale 0 est également connu comme « Time Exceeded Message » et possède le type 11, il a aussi 2 codes ICMP disponibles. Si le champ TTL atteint 0 pendant le transit à travers une passerelle ou un fragment réassemblé sur l'hôte de destination, le paquet doit être supprimé. Pour notifier ce problème à l'hôte expéditeur, nous pouvons envoyer un paquet ICMP TTL égale 0. L'expéditeur peut augmenter le TTL des paquets sortants si nécessaire.

Le paquet contient seulement la partie supplémentaire des données. Le champ données contient l'en-tête Internet plus 64 bits de données du paquet IP. Comme précédemment mentionné, le type TTL égale 0 peut avoir deux codes.

• Code 0 - TTL égale 0 pendant le transit - Envoyé par l'expéditeur si le paquet TTL d'origine atteint 0 quand il est transféré par une passerelle.
• Code 1 - TTL égale 0 pendant le réassemblage - Envoyé si le paquet d'origine était fragmenté, et que le TTL atteint 0 pendant le réassemblage des fragments. Ce code doit être envoyé uniquement depuis le destinataire.

3-9-6. Paramètre problème▲

Le paramètre problème ICMP utilise le type 12 et possède deux codes qu'il peut utiliser indifféremment. Les messages du paramètre problème sont utilisés pour indiquer à l'hôte que la passerelle ou le destinataire ont des problèmes de compréhension sur des parties d'en-tête IP, ou nécessitent des options qui ont été omises.

Le type paramètre problème contient un en-tête spécial, qui est un pointeur vers le champ qui a causé l'erreur dans le paquet d'origine, si le code est à 0. Les codes suivants sont disponibles.

• Code 0 - Mauvais en-tête IP (catchall error) - Nous avons vu ce message d'erreur ci-dessus. Avec le pointeur ce code est utilisé pour indiquer quelle partie de l'en-tête IP contient l'erreur.
• Code 1 - Options obligatoires omises - Si une option IP obligatoire est omise, ce code est utilisé pour l'indiquer.

3-9-7. Horodatage requête/réponse▲

Le type horodatage est aujourd'hui obsolète, mais nous le verrons brièvement. La réponse et la requête ont un code unique (0). La requête est de type 13 tandis que la réponse est de type 14. Les paquets horodatage contiennent 3 fois 32 bits comptant les millisecondes depuis minuit en temps universel (UT).

Le premier horodatage est l'horodatage d'origine, qui contient la dernière information sur l'expéditeur du paquet. L'horodatage de réception est l'information sur le premier hôte qui a reçu le paquet et l'horodatage de transmission le dernier horodatage sur l'envoi du paquet.

Chaque message d'horodatage contient aussi les mêmes identifiants et numéros d'ordre que les paquets ICMP écho.

3-9-8. Requête/réponse information▲

Les types requête/réponse information sont obsolètes depuis que les protocoles au sommet du protocole IP peuvent maintenant jouer ce rôle lorsque nécessaire (DHCP, etc.). La requête information génère une réponse depuis n'importe quel hôte interrogé sur le réseau.

L'hôte qui désire recevoir l'information crée un paquet avec l'adresse source du réseau dans lequel il est lié (exemple, 192.168.0.0), et le réseau destinataire est placé à 0. La réponse contiendra l'information au sujet du masque de réseau et de l'adresse IP.

La requête information est lancée à travers un type ICMP 15 alors que la réponse est envoyée via un type 16.

Stream Control Transmission Protocol (SCTP) est un protocole relativement nouveau, mais qui se développe beaucoup et vient en complément des protocoles TCP et UDP. Il possède un aussi haut niveau de fiabilité que TCP, mais utilise moins de temps système.

SCTP possède des fonctionnalités très intéressantes. Pour ceux qui veulent en savoir plus, voir la RFC 3286 - An Introduction to the Stream Control Transmission Protocol et la RFC 2960 - Stream Control Transmission Protocol. Le premier document est une introduction à SCTP. Le second est la spécification du protocole, ce qui vous intéressera peut-être moins, sauf si vous êtes programmeur de ce protocole.

Ce protocole fut à l'origine développé pour la téléphonie sur IP, ou voix sur IP (VoIP), et possède certains attributs intéressants qui en proviennent. Le niveau de l'industrie VoIP requiert une très haute fiabilité, ce qui veut dire une grande faculté de récupération pour gérer les différentes sortes de problèmes. Ci-dessous une liste des fonctionnalités de base de SCTP.

• Envoi individuel avec propriétés de multidiffusion . Ceci indique que c'est un protocole « point-to-point », mais avec la possibilité d'utiliser plusieurs adressages pour le même destinataire. En d'autres termes, il peut utiliser différents chemins pour joindre le destinataire. TCP, en comparaison, coupe si le chemin s'interrompt, sauf si le protocole IP corrige cela.
• Transmission fiable. Il utilise les sommes de contrôle et SACK pour détecter les données corrompues, endommagées, dupliquées ou réordonnées. Il peut ensuite retransmettre les données si nécessaire. C'est à peu près comme TCP, mais SCTP est plus tolérant pour le réordonnancement des données et permet un captage plus rapide.
• Orienté message. Chaque message peut être mis en trames et donc vous pouvez garder la structure et ordonner le flux de données. TCP est orienté octet et tout ce que vous obtenez est un flux d'octets sans aucun ordre entre les différentes données. Vous avez donc besoin d'une couche d'abstraction dans TCP.
• Adaptatif au débit. Il est développé pour collaborer et coexister avec TCP au niveau de la bande passante. Il l'augmente ou la réduit en fonction des conditions de charge du réseau comme TCP. Il a aussi le même algorithme pour les démarrages lents quand les paquets sont perdus. ECN est également supporté.
• Rattachement multiple. Comme mentionné précédemment, SCTP est capable de mettre en place différents nÅ“uds terminaux directement dans le protocole, et donc de ne pas avoir à relayer sur la couche IP pour la récupération.
• Multiflux. Permet le multiflux simultané dans un même flux, d'où le nom Stream Control Transmission Protocol (Protocole de Contrôle de Transmission de Flux). Un flux unique peut, par exemple, être ouvert pour télécharger une simple page web, et ainsi les images et documents HTML seront chargés dans le même flux simultanément. Ou pourquoi pas un protocole de bases de données qui créera un contrôle de flux séparé et ensuite utilisera plusieurs flux pour recevoir les sorties des différentes requêtes simultanément.
• Initialisation de connexion. 4 paquets d'initialisation de connexion où les paquets 3 et 4 peuvent être utilisés pour envoyer des données. L'équivalent des témoins de synchronisation (NdT. syncookies) est implémenté par défaut pour éviter les attaques en Déni de Service (NdT.DoS). Résolution des collisions INIT pour éviter plusieurs connexions SCTP simultanées.

Cette liste pourrait être plus longue. La plupart de ces informations est tirée de la RFC 3286 - An Introduction to the Stream Control Transmission Protocol.

3-10-1. Initialisation et association▲

3-10-2. Envoi de données et contrôle de session▲

3-10-3. Arrêt et abandon▲

Ce sera une brève introduction aux en-têtes SCTP. SCTP possède beaucoup de types de paquets différents, et j'essaierai de suivre au plus près la RFC en les décrivant, avec une vue générale des en-têtes applicables à tous les paquets SCTP.

3-11-1. Format d'en-têtes génériques SCTP▲

C'est une vue générale de la façon dont est disposé un paquet SCTP. À la base, nous avons un premier en-tête commun avec une information décrivant l'ensemble du paquet, les ports source et destination, etc. Voir plus bas au sujet des en-têtes communs.

Après l'en-tête commun, un nombre variable de blocs est envoyé, jusqu'au maximum possible du MTU (NdT. Maximum Transmission Unit). Tous les blocs peuvent être groupés sauf INIT, INIT ACK et SHUTDOWN COMPLETE, lesquels ne doivent pas être groupés.

3-11-2. En-têtes communs et génériques SCTP▲

Chaque paquet SCTP contient l'en-tête commun comme vu précédemment. L'en-tête contient 4 champs différents et il est placé pour chaque paquet SCTP.

Port source - bit 0-15. Ce champ renseigne sur le port source du paquet, celui qui sera envoyé.

Port destination - bit 16-31. Port destination du paquet. C'est la même chose que pour les ports destination de TCP et UDP.

Repère de vérification - bit 32-63. Le repère de vérification est utilisé pour vérifier que le paquet provient du bon expéditeur. Il est toujours placé à la même valeur identique à la valeur reçue par les autres correspondants (repère d'initialisation) pendant la phase d'initialisation d'association, avec quelques exceptions.

• Un paquet SCTP contenant un bloc INIT doit avoir le repère de vérification placé à 0.
• Un bloc SHUTDOWN COMPLETE avec le bit-T placé doit avoir le repère de vérification copié depuis le repère de vérification du bloc SHUTDOWN-ACK.
• Les paquets contenant le bloc ABORT doivent voir un repère de vérification identique au repère de vérification du paquet responsable du ABORT.

Somme de contrôle - bit 64-95. Une somme de contrôle calculée pour l'ensemble du paquet SCTP basée sur l'algorithme Adler-32. Voir la RFC 2960 - Stream Control Transmission Protocol, index B pour plus d'informations au sujet de cet algorithme.

Tous les blocs SCTP ont une disposition spéciale qui fait qu'ils sont tous collés, comme on peut le voir ci-dessus. Ce n'est pas un en-tête réel, mais plutôt une formalisation de ce à quoi il ressemble.

Type - bit 0-7. Ce champ spécifie le bloc type du paquet, par exemple, est-ce un bloc INIT ou SHUTDOWN ? Chaque bloc type possède un numéro spécifique, comme est indiqué dans le tableau ci-dessous. Voici une liste complète des blocs type :

Tableau 2.1. Types SCTP

Numéro de bloc	Nom de bloc
0	Données utiles (DATA)
1	Initialisation (INIT)
2	Accusé réception d'initialisation (INIT ACK)
3	Accusé réception sélectif (SACK)
4	Requête de détection de collision (HEARTBEAT)
5	Accusé réception sur requête de détection de collision (HEARTBEAT ACK)
6	Abandon (ABORT)
7	Fermeture (SHUTDOWN)
8	Accusé réception de fermeture (SHUTDOWN ACK)
9	Erreur d'opération (ERROR)
10	Témoin d'état (COOKIE ECHO)
11	accusé réception de témoin (COOKIE ACK)
12	Réservé pour écho de notification de congestion explicite (ECNE)
13	Réservé pour fenêtre de congestion réduite (CWR)
14	Arrêt complet (SHUTDOWN COMPLETE)
15-62	Réservé pour l'IETF
63	IETF-Blocs d'extension définis
64-126	Réservé pour l'IETF
127	IETF - Blocs d'extension définis
128-190	Réservé pour l'IETF
191	IETF - Blocs d'extension définis
192-254	Réservé pour l'IETF
255	IETF - Blocs d'extension définis

Bloc fanions - bit 8-15. Le bloc fanion n'est en général pas utilisé, mais il est placé pour une utilisation future. Il existe des blocs fanions spécifiques ou bits d'information qui peuvent être nécessaires pour d'autres correspondants. Selon les spécifications, les fanions sont utilisés seulement dans les paquets DATA, ABORT et SHUTDOWN COMPLETE pour l'instant. Ceci peut changer dans l'avenir.

Souvent lorsque vous lisez une RFC, vous êtes confronté à certains vieux problèmes de provenance. La RFC 2960 - Stream Control Transmission Protocol en est un exemple, dans lequel elle spécifie que le bloc fanions devrait toujours être placée à 0 et ignoré à moins qu'il ne soit utilisé pour quelque chose. Ceci est écrit partout. Si vous faites du pare-feu ou du routage, prenez garde à ça, car les spécifications de champs peuvent changer dans le futur et causer des problèmes à votre pare-feu sans raison légitime. Ceci survenait avant avec l'implémentation de ECN dans les en-têtes IP par exemple. Voir la section Section 2.3, « En-Têtes IP »En-Têtes IP de ce chapitre.

Bloc longueur - bit 16-31. C'est le bloc longueur calculé en octets. Il contient tous les en-têtes, y compris le bloc type, le bloc fanions, et le bloc valeur. S'il n'y a pas de bloc valeur, le bloc longueur sera placé à 4 (octets).

Bloc valeur - bit 32-n. Spécifique pour chaque bloc et peut contenir plusieurs fanions et données appartenant au bloc type. Parfois il peut être vide, auquel cas le bloc longueur sera placé à 4.

3-11-3. Bloc SCTP ABORT▲

Le bloc ABORT est utilisé pour abandonner une association comme décrit dans la section Section 2.10.3, « Arrêt et abandon » de ce chapitre. ABORT apparaît lors d'une erreur irrécupérable dans l'association comme des en-têtes ou des données erronés.

Type - bit 0-7. Toujours placé à 6 pour ce bloc type.

Réservé - bit 8-14. Réservé pour de futurs blocs fanions, mais non utilisés pour l'instant. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations sur les blocs fanions.

Bit-T - bit 15. Si ce bit est placé à 0, l'expéditeur avait un TCB associé avec ce paquet qui a été détruit. Si l'expéditeur n'avait pas de TCB le bit-T devrait être placé à 1.

Longueur - bit 16-31. Place la longueur du bloc en octets en incluant les causes d'erreur.

3-11-4. Bloc SCTP COOKIE ACK▲

Le bloc COOKIE ACK est utilisé pendant l'initialisation de la connexion et jamais en dehors de cette phase dans la connexion. Il doit précéder tous les blocs DATA et SACK, mais peut être envoyé dans le même paquet comme premier de tous les paquets.

Type - bit 0-7. Toujours placé à 11 pour ce type.

Blocs fanions - bit 8-15. Non utilisés. Devraient toujours être placés à 0 selon la RFC 2960 - Stream Control Transmission Protocol. Vous devriez toujours vérifier ces comportements spécifiques établis par les RFC, car elles peuvent changer dans le futur, et même poser des problèmes à vos pare-feux. La chose est arrivée avec IP et ECN. Voir la section Section 2.11.2,« En-têtes communs et génériques SCTP » pour plus d'informations.

Longueur - bit 16-31.Devrait toujours être à 4 (octets) pour ce bloc.

3-11-5. Bloc SCTP COOKIE ECHO▲

Le bloc COOKIE ECHO est utilisé pendant l'initialisation de la connexion SCTP (par la partie qui répond au témoin envoyé par la partie en réponse dans le champ témoin du paquet INIT ACK.) Ils peuvent être envoyés ensemble avec les blocs DATA dans le même paquet, mais doivent précéder les blocs DATA dans tous les cas.

Type - bit 0-7. Le bloc type est toujours placée à 10.

Bloc fanions - bit 8-15. Ce champ n'est pas utilisé aujourd'hui. La RFC spécifie que les fanions devraient toujours êtres placés à 0, mais ceci peut poser des problèmes comme vous pouvez le voir dans le section Section 2.11.2, « En-têtes communs et génériques SCTP » ci-dessus, spécialement l'explication des blocs fanions.

Longueur - bit 16-31. Spécifie la longueur du bloc, incluant le type, le bloc fanions, les champs longueur et témoin en octets.

Témoin - bit 32n. Ce champ contient le témoin envoyé dans le bloc INIT ACK précédent. Il doit être identique au témoin envoyé par la partie correspondante pour pouvoir ouvrir la connexion. La RFC 2960 - Stream Control Transmission Protocol spécifie que le témoin devrait être aussi petit que possible pour assurer l'interopérabilité, ce qui est assez vague.

3-11-6. Bloc SCTP DATA▲

Les blocs DATA sont utilisés pour envoyer des données dans le flux et possèdent des en-têtes plutôt complexes par certains côtés, mais pas vraiment pires que les en-têtes TCP en général. Chaque bloc DATA peut faire partie d'un flux différent, car chaque connexion SCTP peut traiter plusieurs flux différents.

Type - bit 0-7. Le champ type devrait toujours être placé à 0 pour les blocs DATA.

Réservé - bit 8-12. Pas utilisé aujourd'hui. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bit-U - bit 13. Le bit U est utilisé pour indiquer s'il y a un bloc DATA désordonné. Si c'est le cas, le numéro d'interclassement du flux de données doit être ignoré par le destinataire et les données envoyées au niveau de la couche la plus haute sans délai ni essai de réordonnancement des blocs DATA.

Bit-B - bit 14. Le bit B est utilisé pour indiquer le début d'un bloc DATA fragmenté. Si ce bit est placé et le bit E (final) n'est pas placé, ceci indique que c'est le premier fragment d'un bloc qui a été fragmenté en plusieurs blocs DATA.

Bit E - bit 15. Le bit E indique la fin d'un bloc DATA fragmenté. Si ce fanion est envoyé sur un bloc, il signale au destinataire SCTP qu'il peut démarrer le réassemblage des fragments et les passer sur la couche la plus haute. Si le paquet possède les bits B et E placés à 0, il signale que le bloc est semi-fragmenté. Si les deux bits B et E sont placés à 1 ceci indique que le paquet est défragmenté et ne nécessite pas de réassemblage.

Longueur - bit 16-31. La longueur du bloc DATA complet calculé en octets, incluant le champ bloc type jusqu'à la fin du bloc.

TSN - bit 32-63. Le TSN (Transmission Sequence Number - numéro d'ordre d'interclassement de transmission) est envoyé dans le bloc DATA, et l'hôte destinataire utilise TSN pour accuser réception que le bloc est arrivé correctement en renvoyant un bloc ACK. C'est une donnée générale pour l'association SCTP complète.

Identifiant de flux - bit 64-79. L'identifiant de flux est envoyé avec le bloc DATA pour identifier avec quel flux le bloc DATA est associé. Ceci est utilisé depuis que SCTP peut transporter plusieurs flux dans une association unique.

Numéro d'ordre d'interclassement de flux - bit 80-95. C'est le numéro d'ordre d'interclassement du bloc du flux spécifique identifié par l'identifiant de flux. Le numéro d'ordre d'interclassement est spécifique pour chaque identifiant de flux. Si un bloc a été fragmenté, le numéro d'ordre d'interclassement doit être le même pour tous les fragments du bloc d'origine.

Identifiant de protocole données utiles - bit 96-127. Cette valeur est renseignée dans les couches les plus hautes, ou les applications utilisant le protocole SCTP pour identifier le contenu de chaque bloc DATA. Le champ doit toujours être envoyé. Si la valeur est placée à 0, c'est qu'elle n'était pas placée dans les plus hautes couches.

Donnée utilisateur - bit 128n. Donnée que transporte le bloc. Elle peut être variable en longueur, finissant par un octet identique. Ce sont les données à l'intérieur du flux comme spécifié par le numéro d'ordre d'interclassement N dans le flux S.

3-11-7. Bloc SCTP ERROR▲

Le bloc ERROR est envoyé pour informer le correspondant d'un problème dans le flux. Chaque bloc ERROR, peut contenir une ou plusieurs causes d'erreur, lesquelles sont détaillées dans la RFC 2960 - Stream Control Transmission Protocol. Je n'irai pas plus dans le détail que les blocs ERROR de base, car ça nécessite trop d'informations. Le bloc ERROR n'est pas fatal en lui-même, mais il détaille une erreur qui est survenue. Il peut cependant être utilisé avec un bloc ABORT pour informer le correspondant de l'erreur avant de couper la connexion.

Type - bit 0-7. Cette valeur est toujours placée à 9 pour les blocs ERROR.

Bloc fanions - bit 8-15. Non utilisé actuellement. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Longueur - bit 16-31. Spécifie la longueur du bloc en octets, incluant toutes les causes d'erreur.

Causes d'erreur - bit 32-n. Chaque bloc ERROR peut contenir une ou plusieurs causes d'erreur, lesquelles avertissent le correspondant d'un problème dans la connexion. Chaque cause d'erreur est d'un format spécifique, comme décrit dans la RFC 2960 - Stream Control Transmission Protocol. Nous n'irons pas plus loin ici, sauf pour indiquer qu'ils contiennent tous un code de cause, une longueur de cause et un champ d'information spécifique. Les causes d'erreur suivantes sont possibles :

Tableau 2.2. Causes d'erreur

Valeur cause	Code bloc
1	Identifiant de flux de données invalide
2	Paramètre de données obligatoires absent
3	Erreur de témoin
4	Hors service
5	Adresse non résolvable
6	Bloc Type inconnu
7	Paramètre de données obligatoires invalide
8	Paramètres non reconnus
9	Absence de données utilisateur
10	Témoin reçu pendant une fermeture

3-11-8. Bloc SCTP HEARTBEAT▲

Le bloc HEARTBEAT est envoyé par un des correspondants pour vérifier si une adresse finale SCTP est active. Envoyé aux différentes adresses négociées durant la phase d'initialisation de l'association pour vérifier qu'elles sont toujours actives.

Type - bit 0-7. Le type est toujours placé à 0 pour les blocs HEARTBEAT.

Bloc fanions - bit 8-15. Non utilisé aujourd'hui. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Longueur - bit 16-31. Longueur du bloc complet, incluant l'information Heartbeat TLV.

Information Heartbeat TLV - bit 32-n. C'est un paramètre de longueur variable comme défini dans la RFC 2960 - Stream Control Transmission Protocol. C'est un paramètre de données obligatoires pour les blocs HEARTBEAT qui contient trois champs, info type = 1, info longueur et un paramètre d'information Heartbeat spécifique expéditeur. Le dernier champ devrait être un champ d'information spécifique expéditeur, par exemple, le temps passé depuis l'envoi du Heartbeat jusqu'à l'adresse IP de destination. Ensuite il est retourné un bloc HEARTBEAT ACK.

3-11-9. Bloc SCTP HEARTBEAT ACK▲

Le HEARTBEAT ACK est utilisé pour accuser réception qu'un HEARTBEAT a été reçu et que la connexion fonctionne correctement. Le bloc est toujours envoyé à la même adresse IP à l'origine de la requête.

Type - bit 0-7. Toujours placé à 5 pour les blocs HEARTBEAT ACK.

Bloc fanions - bit 8-15. Non utilisé aujourd'hui. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bloc longueur - bit 16-31. La longueur du bloc HEARTBEAT ACK, incluant l'information Heartbeat TLV, calculé en octets.

Information Heartbeat TLV - bit 32-n. Ce champ doit contenir le paramètre Heartbeat Information envoyé au bloc HEARTBEAT d'origine.

3-11-10. Bloc SCTP INIT▲

Le bloc INIT est utilisé pour initialiser une nouvelle association avec un hôte destinataire, c'est le premier bloc à être envoyé par l'hôte qui initialise la connexion. Le bloc INIT contient plusieurs données obligatoires fixant les paramètres de longueur, et certains paramètres optionnels de longueur variable. Les paramètres de données obligatoires de longueur sont déjà dans les en-têtes ci-dessus, et correspondent au témoin d'émission, avertissement du crédit de fenêtre, nombre de flux sortants, nombre de flux entrants et TSN initial. Après ceci vient un couple de paramètres optionnels, lesquels seront présentés dans le paragraphe des paramètres optionnels ci-dessous.

Type - bit 0-7. Le champ type est toujours placé à 1 pour les blocs INIT.

Bloc fanions - bit 8-15. Non utilisé aujourd'hui. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bloc longueur - bit 16-31. Le bloc longueur est la longueur du paquet complet, incluant tout dans les en-têtes, ainsi que les paramètres optionnels.

Témoin d'émission - bit 32-63. Le témoin d'émission est placé dans le bloc INIT et doit être utilisé par le destinataire pour accuser réception de tous les paquets, dans le témoin de vérification de l'association établie. Le témoin d'émission peut prendre toutes les valeurs sauf 0. Si la valeur est à 0, le destinataire doit réagir en émettant un ABORT.

Avertissement de crédit d'ouverture de fenêtre (a_rwnd) - bit 64-95. C'est le tampon minimum de réception que l'expéditeur d'un bloc INIT allouera pour cette association, en octets. Ceci peut alors être utilisé par le destinataire d'un a_rwnd pour savoir combien de données il peut envoyer sans être en SACK. Cette fenêtre ne devrait pas être diminuée, mais elle peut l'être en envoyant un nouveau a_rwnd dans un bloc SACK.

Nombre de flux sortants - bit 96-111. Spécifie le nombre maximum de flux sortants que l'hôte expéditeur désire envoyer au destinataire. La valeur ne doit pas être 0, et si c'est le cas, le destinataire devra faire un ABORT sur l'association immédiatement. Il n'y a pas de négociation sur le nombre minimum de flux sortants, il est simplement placé au niveau le plus bas que le correspondant a placé dans l'en-tête.

Nombre de flux entrants - bit 112-127. Spécifie le nombre maximum de connexions entrantes que l'expéditeur permet pour créer l'association. Il ne doit pas être placé à 0, ou le destinataire devra faire un ABORT sur la connexion. Il n'y a pas de négociation sur le nombre minimum de flux entrants, il est simplement placé au niveau le plus bas que le correspondant a placé dans l'en-tête.

TSN Initial - bit 128-159. Cette valeur place le TSN (Transmit Sequence Number) que l'expéditeur utilisera lors de l'envoi des données. Le champ peut être mis à la même valeur que le repère d'initialisation.

Au sommet des données obligatoires de longueur d'en-têtes, il existe certains paramètres de longueurs variables, et au moins un des paramètres IPv4 et IPv6 ou nom d'hôte doit être placé. Un seul nom d'hôte doit être indiqué, et si le nom d'hôte est placé, aucun paramètre IPv4 ou IPv6 ne doit être placé. Des paramètres multiples IPv4 ou IPv6 peuvent être placés dans le même bloc INIT. Ces paramètres sont utilisés pour déterminer quelle adresse sera utilisée pour se connecter au destinataire dans l'association. Ci-dessous la liste complète des paramètres variables dans le bloc INIT :

Tableau 2.3. Paramètres variables INIT

Nom du paramètre	Statut	Valeur type
Adresse IPv4	Optionnelle	5
Adresse IPv6	Optionnelle	6
Protection témoin	Optionnelle	9
Adresse de nom d'hôte	Optionnelle	11
Types d'adresses supportées	Optionnelle	12
Réservé pour possibilité ECN	Optionnelle	32768

Ci-dessous nous décrivons les trois paramètres les plus communs utilisés dans le bloc INIT.

Le paramètre IPv4 est utilisé pour envoyer une adresse IPv4 au bloc INIT. L'adresse IPv4 peut être utilisée pour envoyer des données dans l'association. Des adresses IPv4 et IPv6 multiples peuvent être spécifiées dans une association SCTP unique.

Paramètre Type - bit 0-15. Toujours placé à 5 pour les paramètres d'adresses IPv4.

Longueur - bit 16-31. Toujours placé à 8 pour les paramètres d'adresses IPv4.

Adresse IPv4 - bit 32-63. Adresse IPv4 d'envoi de fin.

Ce paramètre est utilisé pour envoyer les adresses IPv6 dans le bloc INIT. Ces adresses peuvent servir à contacter le destinataire de cette association.

Type - bit 0-15. Toujours placé à 6 pour les paramètres IPv6.

Longueur - bit 16-31. Toujours placé à 20 pour les paramètres IPv6.

Adresse IPv6 - bit 32-159. Adresse IPv6 de l'expéditeur qui peut être utilisée pour la connexion par le destinataire.

Le paramètre Nom d'hôte est utilisé pour envoyer un nom d'hôte unique comme adresse. Le destinataire doit alors vérifier le nom d'hôte et utiliser certaines, ou toutes, les adresses qu'il reçoit de cet expéditeur. Si un paramètre Nom d'hôte est envoyé, aucun autre paramètre IPv4 ou IPv6 ou un autre Nom d'hôte ne doit être envoyé.

Type - bit 0-15. Toujours placé à 11 pour les paramètres Nom d'hôte.

Longueur - bit 16-31. Longueur du paramètre complet, y compris les champs types, longueur et Nom d'hôte. Le champ Nom d'hôte est de longueur variable. Elle est comptée en octets.

Nom d'hôte - bit 32-n. Paramètre de longueur variable contenant un nom d'hôte. Ce nom d'hôte est résolu par le destinataire qui reçoit les adresses qui pourront être utilisées pour contacter l'expéditeur.

3-11-11. Bloc SCTP INIT ACK▲

Le bloc INIT ACK est envoyé en réponse à un bloc INIT et contient à la base les mêmes en-têtes, mais avec les valeurs du destinataire du bloc INIT d'origine. De plus, il possède deux variables longueur supplémentaires, les paramètres état cookie et le paramètre non reconnu.

Type - bit 0-7. Cet en-tête est toujours placé à 2 pour les blocs INIT ACK.

Bloc fanions - bit 8-15. Non utilisé aujourd'hui. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bloc longueur - bit 16-31. Le bloc longueur représente la longueur de l'ensemble du paquet, y compris tout ce que contiennent les en-têtes, et les paramètres optionnels.

Repère d'émission - bit 32-63. Le destinataire du repère d'émission du bloc INIT ACK doit sauvegarder cette valeur et la copier dans le champ repère de vérification de chaque paquet qu'il envoie à l'expéditeur du bloc INIT ACK. Le repère d'émission ne doit pas être placé à 0, et si c'est le cas, le destinataire du bloc INIT ACK doit fermer la connexion par un ABORT.

Publication de réception de crédit de fenêtre (a_rwnd) - bit 64-95. Les tampons dédiés que l'expéditeur de ce bloc a placés pour le trafic, compté en octets. Les tampons dédiés ne devraient pas être inférieurs ou supérieurs à ces valeurs.

Nombre de flux sortants - bit 96-111. Combien de flux sortants l'expéditeur désire créer. Ne doit pas être à 0, sinon le destinataire du INIT ACK doit faire un ABORT sur l'association. Il n'y a pas de négociation sur le nombre minimum de flux sortants, c'est simplement placé au niveau le plus bas que chaque hôte a mis dans l'en-tête.

Nombre de flux entrants - bit 112-127. Combien de flux entrants l'expéditeur final consent à accepter. Ne doit pas être à 0, sinon le destinataire du INIT ACK devra faire un ABORT sur l'association. Il n'y a pas de négociation sur le nombre minimum des flux entrants, simplement placé au niveau le plus bas que chaque hôte a mis dans l'en-tête.

TSN Initial - bit 128-159. Numéro de séquence de transmission initial qui sera utilisé par la partie expéditrice de l'association au démarrage.

Après cela, le bloc INIT ACK continue avec des paramètres optionnels de longueur variable. Ces paramètres sont exactement les mêmes que pour le bloc INIT, à l'exception de l'ajout des paramètres état cookie et paramètre inconnu, et la suppression du paramètre Type d'Adresses Supportées. Cette liste ressemble à ceci :

Tableau 2.4. Variables des paramètres INIT ACK

Nom de paramètre	Statut	Type de valeur
Adresse IPv4	Optionnel	5
Adresse IPv6	Optionnel	6
État Cookie	Obligatoire	7
Paramètre inconnu	Optionnel	8
Conservateur de cookie	Optionnel	9
Nom adresse de l'hôte	Optionnel	11
Reservé pour ECN	Optionnel	32768

L'état cookie est utilisé dans l'INIT ACK pour envoyer un cookie au destinataire, et jusqu'à ce que ce destinataire ait répondu par un bloc COOKIE ECHO, l'association n'est pas garantie. Ceci pour prévenir une attaque SYN dans le protocole TCP.

Type - bit 0-15. Toujours placé à 7 pour tous les paramètres état cookie.

Longueur - bit 16-31. La taille du paramètre complet, y compris le type, la longueur et le champ état cookie en octets.

État Cookie - bit 31-n. Ce paramètre contient un cookie de longueur variable. Pour une description, voir la RFC 2960 - Stream Control Transmission Protocol.

3-11-12. Bloc SCTP SACK▲

Le bloc SACK est utilisé pour indiquer à l'expéditeur de blocs DATA quels blocs ont été reçus et à quel endroit il y a eu un trou dans le flux, basé sur les TSN reçus. Le bloc SACK accuse réception qu'il a reçu les données jusqu'à un certain point (paramètre TSN Ack cumulé), et ajoute ensuite des blocs Gap Ack pour toutes les données qu'il a reçues après le point TSN Ack cumulé. Un bloc SACK ne doit pas être envoyé plus d'une fois pour chaque bloc DATA qui est reçu.

Type - bit 0-7. Cet en-tête est toujours placé à 3 pour les blocs SACK.

Bloc fanions - bit 8-15. Non utilisé aujourd'hui. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bloc longueur - bit 16-31. Le bloc longueur est la longueur du bloc complet, y compris tous les en-têtes et tous les paramètres.

TSN Ack cumulé - bit 32-63. C'est le paramètre TSN Ack cumulé qui est utilisé pour accuser réception des données. Le destinataire du bloc DATA utilisera ce champ pour indiquer à l'expéditeur qu'il a reçu toutes les données jusqu'à cette étape de l'association. Ensuite, toutes les données qui n'ont pas été spécifiquement accusées de réception par les blocs Gap Ack seront, en gros, considérées comme perdues.

Avertissement de réception de crédit de fenêtre (a_rwnd) - bit 64-95. Le champ a_rwnd est le même que le a_rwnd des blocs INIT et INIT ACK, mais peut être utilisé pour augmenter ou diminuer la valeur a_rwnd. Voir la RFC 2960 - Stream Control Transmission Protocol à ce sujet.

Nombre de blocs Gap Ack - bit 96-111. Le nombre de Gap Ack listés dans ce bloc. Chaque Gap Ack prend plus de 32 bits dans le bloc.

Nombre de TSN dupliqués - bit 112-127. Le nombre de blocs DATA qui ont été dupliqués. Chaque TSN dupliqué est listé après les Gap Ack dans le bloc, et chaque TSN prend 32 bits.

Gap Ack Block #1 Start - bit 128-143. Premier Gap Ack Block dans le bloc SACK. S'il n'y a pas de trous dans les numéros TSN des blocs DATA reçus, il n'y aura pas de Gap Ack Block du tout. Cependant, si les blocs DATA sont reçus en désordre ou si certains blocs DATA sont perdus pendant le transfert vers le destinataire, il y aura des trous. Ces trous seront rapportés par les Gap Ack Block. Le point de démarrage du Gap Ack Block est calculé par l'ajout du paramètre Gap Ack Block Start à la valeur TSN cumulée.

Gap Ack Block #1 End - bit 144-159. Cette valeur rapporte la fin du premier Gap Ack Block du flux de données. Tous les blocs DATA avec le TSN entre le Gap Ack Block Start et le Gap Ack Block End ont été reçus. La valeur du Gap Ack Block End est ajoutée au TSN cumulé, comme le paramètre Start, pour obtenir le dernier TSN.

Gap Ack Block #N Start - bits variables. Pour chaque Gap Ack Block compté dans le paramètre nombre de Gap Ack Blocks, un Gap Ack Block est ajouté, jusqu'au N block final. C'est-à-dire, si le nombre de Gap Ack Blocks = 2, il y aura deux Gap Ack Blocks dans le bloc SACK. Il contient le même type de valeur que le Gap Ack Block #1 Start.

Gap Ack Block #N End - bits variables. Identique au Gap Ack Block #N Start, mais pour la fin du Gap.

TSN #1 dupliqué - bits variables. Ce champ rapporte un TSN dupliqué, ce qui indique que nous avons déjà reçu un bloc spécifique, mais que nous recevons de nouveau le même TSN plusieurs fois. Ceci étant dû soit à un problème de routeur (qui retransmet des données déjà envoyées) soit un cas de retransmission de l'expéditeur, ou encore d'autres possibilités. Chaque cas de TSN dupliqué devrait être rapporté. Par exemple, si 2 TSN dupliqués ont été reçus après le premier accusé réception, chacun de ces TSN dupliqués devrait être envoyé dans le message SACK suivant. Si un TSN dupliqué apparaît encore après le second ACK envoyé, les nouveaux TSN dupliqués seront ajoutés dans le message ACK suivant, et ainsi de suite.

TSN #X dupliqué - bits variables. C'est le dernier paramètre TSN dupliqué, qui contient le même type d'information que le premier paramètre.

3-11-13. Bloc SCTP SHUTDOWN▲

Le bloc SHUTDOWN apparaît quand un des points terminaux d'une connexion désire fermer l'association en cours. La partie qui envoie doit vider tous ses tampons avant d'expédier le bloc SHUTDOWN, et ne doit pas envoyer d'autres blocs DATA ensuite. Le destinataire doit également vider ses tampons d'envoi et ensuite expédier le bloc SHUTDOWN ACK correspondant.

Type - bit 0-7. Cet en-tête est toujours placé à 7 pour les blocs SHUTDOWN.

Bloc fanions - bit 8-15. Non utilisé actuellement. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bloc longueur - bit 16-31. Ce bloc est la longueur du paquet complet, incluant le paramètre TSN Ack cumulé. La longueur du bloc SHUTDOWN devrait toujours être à 8.

TSN Ack cumulé - bit 32-63. C'est le champ TSN Ack cumulé, le même que dans le bloc SACK. Le TSN Ack cumulé accuse réception du dernier TSN reçu dans la séquence de l'expéditeur. Ce paramètre ne doit pas, comme pour la suite du bloc SHUTDOWN, accuser réception des Gap Ack Blocks. L'absence de Gap Ack Block dans le bloc SHUTDOWN qui a été accusé de réception précédemment ne doit pas être interprétée comme si le bloc accusé de réception précédent était perdu.

3-11-14. Bloc SCTP SHUTDOWN ACK▲

Le bloc SHUTDOWN ACK est utilisé pour accuser réception d'un bloc SHUTDOWN reçu. Avant que le bloc SHUTDOWN ACK soit envoyé, toutes les données dans les tampons d'envoi doivent être expédiées, les tampons ne doivent plus accepter aucune donnée provenant de l'application. SCTP ne supporte pas les connexions semi-ouvertes à l'inverse de TCP.

Type - bit 0-7. Cet en-tête est toujours placé à 8 pour les blocs SHUTDOWN ACK.

Bloc fanions - bit 8-15. Non utilisé actuellement. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

Bloc longueur - bit 16-31. C'est la longueur du bloc complet. Cette longueur du bloc SHUTDOWN ACK devrait toujours être placée à 4.

3-11-15. Bloc SCTP SHUTDOWN COMPLETE▲

Le bloc SHUTDOWN COMPLETE est envoyé, par l'expéditeur du SHUTDOWN, en réponse au bloc SHUTDOWN ACK. Il est expédié pour accuser réception que l'association est totalement fermée.

Type - bit 0-7. Toujours placé à 7 pour les blocs SHUTDOWN COMPLETE.

Réservé - bit 8-14. Non utilisé actuellement. Voir Section 2.11.2, « En-têtes communs et génériques SCTP » pour plus d'informations.

T-bit - bit 15. Le T-bit n'est pas placé, pour indiquer que l'expéditeur a un TCB (Transmission Control Block) associé avec la connexion et qu'il est détruit. Si le T-bit était placé, il n'y aurait pas de TCB à détruire.

Longueur - bit 16-31. Toujours placé à 4 pour les blocs SHUTDOWN COMPLETE, car le bloc ne doit jamais être plus long, aussi longtemps que les standards l'admettent.

TCP/IP s'est accru en complexité quand il est devenu une partie du routage. Au début, la plupart des gens pensaient que la destination donnée par le routage était suffisante. Ces dernières années, c'est devenu de plus en plus complexe. Aujourd'hui, Linux peut router de façon basique chaque champ ou bit dans l'en-tête IP, mais également les en-têtes basés sur TCP, UDP ou ICMP. Ceci est appelé gestion de réseau à base de règles, ou routage avancé.

Il ne s'agit ici que d'un survol du routage. Quand nous envoyons un paquet depuis un expéditeur, le paquet est créé. Après ça, l'ordinateur regarde l'adresse de destination du paquet et la compare à sa table de routage. Si l'adresse de destination est locale, le paquet est envoyé directement via l'adresse MAC du matériel (Ndt. interface réseau). Si le paquet est de l'autre côté de la passerelle, il est envoyé via l'adresse MAC de la passerelle. Celle-ci regardera alors les en-têtes IP et verra l'adresse de destination du paquet. L'adresse de destination est consultée dans la table de routage, et le paquet envoyé à la passerelle suivante, etc. jusqu'à sa destination finale.

Comme vous pouvez le voir, ce routage est très basique. Avec le routage avancé, et la gestion de réseau à base de règles, ceci devient plus complexe. Nous pouvons router des paquets qui diffèrent dans leur adresse source par exemple, ou leur valeur TOS, etc.

Nous avons vu les points suivants.

• Structure TCP/IP.
• Fonctionnalité du protocole IP et en-têtes.
• Fonctionnalité du protocole TCP et en-têtes.
• Fonctionnalité du protocole UDP et en-têtes.
• Fonctionnalité du protocole ICMP et en-têtes.
• Destination TCP/IP par routage.

Tout ceci sera revu plus tard quand nous aborderons les tables de règles des pare-feux. Toutes ces informations s'imbriquent ensemble, pour permettre une meilleure configuration des pare-feux.