SCTP

Nouveautés

Multi-homing

Le Multi-homing découle du mode associé de SCTP. À l'initialisation d'une connexion SCTP, la liste des adresses IP disponnibles des machines sont échangées. Ainsi, de multiples connexions peuvent être établies.

Prenons l'exemple suivant, un client et un serveur communique via SCTP. Lorsque la liste des adresses IP est connu des deux côtés, un chemin primaire est choisi par défaut

multi_homing.gif

Avec TCP la communication est établie entre les interfaces C0 et S0. Et, avec SCTP la machine cliente est associée à la machine serveur, c'est à dire que les interfaces : C0 et C1 sont associées avec S0 et S1. Ici, deux connexions sont créées : C0-S0 et C1-S1, la première via ethernet et la seconde via 802.11.

Observation d'une panne :

multiHomingBreakdown.png

Si une coupure réseau survient, dans le cas de TCP, la connexion est rompue, et la communication aussi.

Avec SCTP c'est différent, la connexion C0-S0 est bien coupée, mais C1-S1 est toujours fonctionnelle. Ainsi, la communication continue.


Au final, le multi-homing permet d'obtenir :

Multi-streaming

Le multi-streaming est une technologie permettant de pouvoir gérer plusieurs flux de données sur une seule connexion.

Là où le multi-homing permet d'utiliser plusieurs connexions entre deux machines, le multi-streaming permet d'utiliser plusieurs stream sur une seule connexion.

multi_streaming.gif

Dans l'illustration ci-dessus, nous avons à gauche une connexion SCTP et à droite une connexion TCP.

Classiquement, TCP envoie les paquets les uns derrière les autres. Mais, si une perte survient, alors toute la communication est affectée, le slow start recommence et donc le débit diminue.

Dans le cas de SCTP, les données sont transférées sur plusieurs flux. Ainsi, même si une perte de paquet est observée, uniquement un stream sera impacté et verra son débit chuter. Mais, les autres continueront à progresser dans le slow start, et donc à augmenter leur débit.

Ainsi, grâce au multi-streaming, SCTP permet de diminuer l'impact de la perte d'un paquet sur la bande passante par rapport à TCP.

De plus, cette fonctionnalités est très intéressante en termes de performances car ouvrir plusieurs connexion avec TCP demande plus de ressources que d'utiliser autant de flux avec SCTP.

4-way handshacking

Dans cette partie nous allons étudier la solution mise en place par SCTP pour contrecarrer les attaques SYN de type DOS auxquelles TCP est vulnérable.

Attaque SYN (DOS)

Rappelons qu'une connexion TCP est réalisée en trois temps :

Dans ce handshacking en trois temps il y a deux failles. Premièrement les ressources du serveur pour la connexion sont allouées à l'étape 2. Deuxièmement, c'est le client, qui au final, crée la connexion puisque c'est lui qui envoie le dernier paquet.

synAttack.png

Ci-dessus nous pouvons observer une attaque SYN de type DOS (Deny Of Service). Le client demande des connexions au serveur sans jamais les valider, mais ce dernier alloue malgré tout des ressources pour les futures communications. Ainsi, il se retrouve rapidement saturé et devient incapable de répondre à une requête régulière.

Pour remédier à ce problème, SCTP initialise une association en 4 temps, c'est le 4-way handshacking.

sctpVsTcpHandshacking.gif

Sur l'image ci-dessus, nous avons à gauche le handshacking de SCTP et à droite celui de TCP.

Les étapes du 4-way handshacking sont les suivantes :

Avec SCTP, la différence réside dans le fait que c'est le serveur qui à le dernier mot, c'est lui valide l'association. Ainsi, méme si une attaque de type SYN est tentée, en aucun cas les ressources du serveur ne seront impactées.

SACK

SACK ou Selective ACKnowledgement est le paquet utilisé par SCTP pour acquitter ses trames. Mais avant d'expliquer son fonctionnement, intéressons nous à la structure d'un paquet SCTP.

Structe d'un paquet SCTP

packet.png

Ci-dessus nous observons un paquet SCTP. En rouge, les informations communes à tous les paquets, en gris les données/messages appelés chunk dans SCTP.

Décrivons ces champs :

Les champs suivants correspondent aux chunks, dans chaque paquet il y en a au moins un :

Structure d'un SACK

Voici la partie variable du chunk SACK (les champs communs ne sont pas représentés : port source/destination, tag, checksum) :

sack.png

Les parties intéressantes sont en bleu et gris. La partie bleue indique le nombre de chunk perdus et leur numéro, la partie grise contient les mêmes informations concernant les chunk dupliqués.

En comparaison d'un ACK, un SACK contient plus de donnés mais il est bien plus efficace. En effet, en cas de perte de plusieurs paquets, un ACK indiquera uniquement le premier paquet perdu alors qu'un SACK sera capable de tous les indiquer.

Cas pratique

Soit A, B, C, D, E, F, G et H des paquets envoyés en même temps (étape 4 du slow start). Les paquets A, C et D sont perdus, ils sont alors réémis selon l'algorithme du slow start : 1 paquet, puis 2, 4, ...

Réémission avec ACK : A - BC - DEFG.

Réémission avec SACK : A - BC.

Qu'observons nous?
A chaque fois ACK indique le prochain paquet à envoyer mais au fur et à mesure que le slow start progresse, les paquets suivants sont envoyés. Ainsi, dans ce cas les paquets C, E, F et G sont retransmis inutilement. Et, dans le cas de SACK seul les paquets perdus sont retransmis car SACK demande uniquement la réémission des paquets perdus.

Ainsi, en cas de perte de paquets l'acquittement SACK permet d'éviter d'encombrer le réseau avec des données déjà transmises, et donc d'augmenter le débit (par rapport à ACK).