Étude des anomalies TCP

Tout flux TCP traversant un réseau peut être sujet à la duplication d’un certain nombre de ses paquets, à la perte d’autres paquets et à l’arrivée dans un ordre différent de celui de l’émission d’autres paquets. Tous ces phénomènes sont appelés, dans [Mell06], anomalies TCP. Il est à signaler que grâce aux numéros de séquence et d’acquittement, présents dans tout paquet TCP, les systèmes

terminaux peuvent remettre les données reçues dans l’ordre à l’application destinataire, détecter la duplication de paquets ou leur perte et provoquer la retransmission des paquets perdus⁸.

Les études métrologiques, notamment [Paxs97 et Mell06], montrent que les anomalies TCP sont relativement fréquentes dans les réseaux IP. En effet, dans [Mell06], les auteurs ont défini une méthode de classification des anomalies TCP basée sur des heuristiques et l’ont implémenté dans l’outil Tstat [Tstat] avant de l’utiliser pour l’analyse de traces de mesures passives et d’affirmer que 5% des segments TCP entrants présentent une anomalie ; alors que dans l’autre sens, ce pourcentage atteint 8% des segments TCP.

En utilisant l’outil Tstat [Tstat], nous avons étudié des anomalies TCP présentes dans le trafic collecté sur le réseau RNU. Le Tableau 3.8 donne, pour la trace T4, le pourcentage des segments TCP enregistrés en ordre par la sonde de mesure, ainsi que celui des segments TCP arrivés en désordre. Ces valeurs sont supérieures à ceux de [Mell06]. De plus, elles montrent l’importance des congestions que subissent les connexions TCP transitant par le réseau RNU, puisque prés de 8% des segments TCP ont du être retransmis à cause des congestions.

% Segments TCP en désordre Trace % Segments

TCP en ordre

Duplication Routage Congestion Autres

T4_10h 87,37 0,10 0,28 7,91 4,34

Tableau 3.8 : Analyse des anomalies TCP

8. Conclusion

L’analyse du trafic RNU a mis en évidence la grande variabilité de ses caractéristiques. En effet, le volume du trafic (mesuré en nombre d’octets, de paquets ou de flux) et sa répartition (par numéro de port ou type d’application) varient selon le moment de la journée confirmant ainsi les études métrologiques précédentes (cf chapitre 1).

Plus précisément, les variations du volume du trafic dans RNU concernent une multitude d’échelles de temps. En effet, il existe une dépendance à long terme dans le processus d’arrivée des paquets, composant ce trafic; de plus le niveau de cette dépendance varie beaucoup au cours de la journée. Ce qui a pour effet de compliquer la mise en place d’un modèle de trafic pour les arrivées des paquets.

8

En effet, le numéro de séquence permet d’identifier le nombre octets envoyés par l'émetteur, tandis que le numéro d'acquittement permet d’identifier le nombre octets de données acquittées par celui-ci. Ainsi le numéro d’acquittement au niveau de l’émetteur doit être synchronisé avec le numéro de séquence du récepteur et inversement.

Chapitre3 : Mesures dans RNU

Concernant les arrivées des flux, nous avons remarqué une absence de LRD, ce qui nous permet de proposer une modélisation du processus d’arrivée des flux par une loi de type Poisson.

La présence de LRD a des implications importantes sur le dimensionnement des nœuds de l’Internet : les liaisons Internet et les files d’attentes dans les routeurs doivent être surdimensionnés sans quoi le taux de pertes des paquets serait important et causerait une détérioration de la qualité de service offerte par le réseau. Plus concrètement, le débit d’une liaison doit être de 2 à 3 fois la valeur moyenne du débit calculée sur une fenêtre de 5mn. Cette règle est malheureusement non

appliquée au niveau du RNU.

Par ailleurs, l’analyse de la répartition du trafic RNU par flux, a montré l’existence d’une majorité de flux souris générant peu de trafic, à coté d’une minorité de flux éléphants responsables de la quasi totalité du trafic. Les flux éléphants, par le volume de trafic qu’ils génèrent, peuvent saturer les liens du réseau. Alors que les flux souris, malgré le faible volume de leur trafic, peuvent dégrader considérablement les performances des équipements du réseau, notamment ceux qui maintiennent un état pour chaque flux actif (les pare-feu sont les plus touchés). Ainsi, nous estimons qu’une gestion de réseau efficace ne peut se limiter à la surveillance des flux éléphants (comme préconisé dans [Floy03]) mais nécessite aussi la surveillance des flux souris. Cela peut se faire en utilisant par exemple l’outil Netflow.

En outre, l’analyse de la répartition des connexions TCP par classe d’application, a montré que la plupart des flux souris sont en réalité des connexions TCP anormales puisqu’elles ne transportent aucune charge utile et utilisent les ports « Windows ». Or ces ports n’ont pas d’utilisation légitime en dehors des réseaux locaux où ils servent au partage de fichiers et d’imprimantes, à l’appel de procédures distantes et la découverte du voisinage réseau. Sur les liens de l’Internet, la présence d’un tel trafic résulte de la propagation de vers informatiques sur le réseau RNU. D’où la nécessité de filtrer ce trafic au niveau de tous les routeurs du réseau RNU. Ce filtrage doit s’effectuer le plus prés possible des sources de ce trafic c’est à dire au niveau de tous les routeurs des institutions universitaires. Un tel filtrage permettrait de limiter le trafic indésirable dans RNU sans toutefois

pouvoir l’éliminer en totalité car les ports utilisés par un tel trafic sont très variables au cours du temps.

D’autre part, l’analyse des connexions TCP par type, a montré l’importance des balayages de ports puisqu’ils constituent au moins 42% des connexions. Ces derniers sont dus principalement aux propagations des vers informatiques sur le réseau RNU.

Bien que, les ingénieurs et les techniciens du CCK fussent déjà confrontés à la propagation massive des vers informatiques et à des attaques de dénis de service dans le réseau RNU, ils ne disposaient pas d’outils efficaces pour les détecter et les différencier des congestions et des pannes physiques de liens. En effet, suite aux réclamations des utilisateurs se plaignant de la dégradation des

performances du réseau, ils procèdent généralement par élimination et font recours à des outils adhoc pour diagnostiquer les causes de la dégradation de QoS observée.

Dans le chapitre suivant, nous proposons une méthode pour la détection d’anomalies à partir de métriques de volume collectées périodiquement au niveau de tous les liens du réseau surveillé. La méthode proposée est par la suite exploitée pour la détection et la caractérisation des anomalies de trafic affectant le réseau RNU.