Qu’est-ce qu’un flux de trafic réseau ?

Les flux de trafic réseau (flux) sont utiles pour construire une compréhension grossière du trafic sur un réseau informatique, fournissant une unité pratique pour la mesure et / ou le traitement du trafic.Les flux

peuvent être mesurés pour comprendre ce que les hôtes parlent sur le réseau, avec des détails sur les adresses, les volumes et les types de trafic. Cette vue du réseau peut être utile pour le dépannage, la détection des incidents de sécurité, la planification et la facturation

Mais qu’est-ce qu’un flux exactement et comment est-il défini ?

Cette question semble triviale à répondre, mais lorsque nous creusons plus profondément, nous trouvons des nuances et des cas de coin qui rendent les flux intéressants, et finalement difficiles à définir.

Contexte

Pour vraiment comprendre les flux, nous devons commencer par un contexte.

Les réseaux ont démarré en circuit commuté. Lorsqu’un hôte voulait communiquer avec un autre hôte, il a demandé au réseau de configurer un circuit. Une fois le flux d’informations terminé, le circuit a été démoli.

Figure 1 – Exemple de réseau à commutation de circuits

Les réseaux à commutation de circuits ont leur héritage dans les réseaux téléphoniques. Ils présentent un certain nombre d’inconvénients, notamment une faible évolutivité et une faible utilisation des capacités.

Une alternative était nécessaire pour construire ce qui est finalement devenu les réseaux Internet à commutation de paquets. Les messages sont découpés en morceaux de taille variable qui sont adressés individuellement et envoyés sous forme de paquets sur le réseau.

Figure 2 – Exemple de réseau à commutation de paquets

L’hôte récepteur réassemble la charge utile des paquets dans le message. Remarque: les paquets peuvent également contenir des informations de contrôle, telles que le contrôle de flux et les chemins ne doivent pas nécessairement être symétriques.

La définition des flux dans un réseau à commutation de circuits est facile car le circuit est un flux et suit un protocole d’établissement et de désactivation (circuit = flux); cependant, dans un réseau à commutation de paquets, les choses sont moins évidentes.

Imaginez une seconde que vous êtes au point d’observation A dans le réseau à commutation de circuits de la figure 1, vous verriez:

Figure 3 – Zoom sur le réseau à commutation de circuits

Deux flux seraient observés – des circuits entre les hôtes 3 & 4 et les hôtes 5 & 6. L’observation des flux dans un réseau à commutation de circuits est relativement facile car le réseau est impliqué dans la mise en place des circuits, connaît donc leur état et les points d’extrémité.

Imaginez maintenant que vous êtes au point d’observation A dans le réseau à commutation de paquets de la figure 2 à la place, vous verriez:

Figure 4 – Zoom sur le réseau à commutation de paquets

Soudain, les choses sont moins claires. Il y a un paquet venant de l’hôte 5 destiné à l’hôte 6. En supposant que nous observions pendant un certain temps, nous voyons plus de paquets arriver et partir. L’observation des flux sur un réseau à commutation de paquets prend du temps et nécessite l’enregistrement et l’analyse des informations sur les paquets.

Première Tentative (naïve) de Définir un flux

En utilisant notre connaissance des réseaux à commutation de paquets, une première tentative de réponse “qu’est-ce qu’un flux” pourrait être:

Un flux est une séquence de paquets transportant des informations entre deux hôtes

Cette définition ressemble à:

Figure 5 – Première tentative de Définition d’un flux

Il y a cependant un problème. Que se passe-t-il s’il y a plus d’un type de communication entre les hôtes, par exemple A a une connexion SSH et HTTPS à B? Les paquets SSH et HTTPS font-ils partie du même flux ? Intuitivement, nous disons non, ce sont des sessions différentes, et même des protocoles entièrement différents. Nous pouvons faire mieux

Deuxième tentative de définir

Que diriez-vous d’utiliser les informations de protocole des en-têtes de paquets comme propriétés communes pour identifier les paquets dans les flux? Cela séparera différents types de connexion en différents flux.

Une grande proportion de paquets sur un réseau est susceptible d’être un protocole de couche 3 IP, avec TCP ou UDP comme protocole de transport de couche 4. Il est donc raisonnable d’envisager d’utiliser les paramètres TCP et UDP comme clés de flux des en-têtes de paquets.

Nous utiliserons 5 paramètres à partir des en-têtes de paquets; IP source, IP de destination, protocole, port source TCP ou UDP et port de destination TCP ou UDP sous forme de liste ordonnée, communément appelée 5-tuple, comme propriétés communes pour mapper les paquets aux flux.

Figure 6 – Exemple 5 – tuple

Voici la tentative 2:

Un flux est une séquence de paquets transportant des informations entre deux hôtes, où les paquets ont des propriétés communes:

• Tous les paquets du flux partagent le même 5-tuple

Notre scénario ressemble maintenant à ceci:

Figure 7 – Deuxième tentative de Définir un Flux

Parfait, dites-vous. La vie est belle. Nous avons une définition pour un flux, rien de plus à voir ici But Mais accrochez-vous, qu’en est-il de la direction des paquets?

Troisième tentative – Bidirectionnelle

Un 5-tuple est unidirectionnel (unidirectionnel). Par défaut, il ne fera correspondre que les paquets voyageant dans une direction, car les paquets dans le sens inverse ont des adresses IP et des numéros de port transposés, et donc un hachage différent à 5 tuples.

Il y a de bonnes raisons de considérer les flux comme bidirectionnels plutôt qu’unidirectionnels, y compris la capacité de déterminer le comportement client / serveur et de calculer les temps d’aller-retour ainsi que d’améliorer la détection des incidents de sécurité tels que la numérisation.

Considérons une connexion TCP simple dans la figure 8 où les paquets rebondissent entre l’hôte A & B:

Figure 8 – Diagramme en échelle d’un flux TCP simple

Nous voyons une poignée de main TCP classique à 3 voies (SYN, SYN + ACK, ACK) suivie d’un échange de données. L’analyse des flux unidirectionnels à un point d’observation du réseau verrait deux flux distincts, un par direction, selon la figure 9:

Figure 9 – Échelles unidirectionnelles pour un flux TCP simple

Le problème avec la mesure de flux unidirectionnel est que nous manquons l’occasion de capturer des métadonnées importantes sur le flux. Bien sûr, chaque flux unidirectionnel peut stocker des métadonnées directionnelles pour les octets et les paquets dans cette direction. Cela peut inclure la synchronisation entre paquets (voir les points marqués à la figure 9). Mais nous manquons l’occasion de rassembler des métadonnées qui nécessitent de mesurer les paramètres de trafic dans les deux sens.

Considérez l’observation bidirectionnelle dans la figure 10:

Figure 10 – Échelle d’observations bidirectionnelles pour un flux TCP simple

Nous pouvons maintenant observer et mesurer la poignée de main TCP à 3 voies (points F1, B1, F2), et examiner d’autres mesures comme les temps de réponse.

Pour les flux bidirectionnels, nous avons besoin de deux 5-tuples, dont le second inverse l’ordre des tuples des adresses IP et des numéros de port. Voici un exemple de flux SSH en avant et en arrière 5-tuples:

Figure 11 – Inverser un 5-tuple

À droite, ce n’était pas trop difficile. Mais attendez, un petit détail se cache qui nécessite plus d’attention. Comment savons-nous quelle est la direction vers l’avant de l’écoulement? Nous déterminons la direction en fonction du premier paquet observé, qui est supposé se déplacer dans la direction client-serveur, mais cela ne sera pas fiable à 100% car les paquets pourraient être en panne et / ou l’observation pourrait commencer à travers un flux. Nous utiliserons cette méthode, mais nous devons nous rappeler lorsque nous examinons les résultats que ce n’est pas parfait.

Une méthode alternative consiste à inspecter les champs du protocole de transport. Dans TCP par exemple, la présence du seul indicateur SYN est un indicateur raisonnable que le paquet est le premier du flux.

Notre définition d’un flux est maintenant:

Un flux est une séquence de paquets transportant des informations entre deux hôtes où les paquets ont des propriétés communes:

• Tous les paquets du flux partagent le même 5-tuple ou 5-tuple transposé

Quatrième tentative – Y compris le trafic IP non TCP

Jusqu’à ce stade, nous avons supposé que le protocole de transport est TCP. Qu’en est-il des autres protocoles de transport IP?

UDP est le choix évident pour le deuxième protocole de transport le plus courant, en particulier avec l’augmentation du trafic en temps réel sur UDP ainsi que de nouveaux protocoles tels que QUIC. UDP s’intègre facilement dans le même modèle car il a des numéros de port source et de destination, selon l’exemple QUIC ci-dessous:

Figure 12 – Inverser un 5-tuple UDP (identique à TCP)

Le protocole de transmission de contrôle de flux (SCTP) est un autre protocole de transport qui utilise des numéros de port et fonctionne donc avec un 5-tuple.

Mais qu’en est-il des autres protocoles, IPSec par exemple ?

IPSec ESP (Encapsulation de la charge utile de sécurité) est un protocole qui n’inclut pas les numéros de port source / destination, nous devons donc nous rabattre sur un 3-tuple car il est peu probable que la compréhension de la charge utile du protocole soit pratique.

Figure 13 – 3-Tuple bidirectionnel

Notre définition d’un flux est maintenant:

Un flux est une séquence de paquets transportant des informations entre deux hôtes où les paquets ont des propriétés communes:

• Pour les protocoles de transport avec des numéros de port (c’est-à-dire TCP / UDP / SCTP):

Tous les paquets du flux partagent le même 5-tuple ou 5-tuple transposé

else:

Tous les paquets du flux partagent le même 3-tuple ou 3-tuple transposé

Il y a cependant un autre facteur à considérer – le temps.

Cinquième tentative – Expiration du flux

Un flux n’existe que pendant un certain temps. Il est possible que le même 5-tuple (ou 3-tuple) puisse être réutilisé à un moment différent, pour un flux différent, entre les mêmes hôtes.

Considérons deux hôtes où l’un initie de nombreuses nouvelles connexions TCP à l’autre. Chaque nouvelle connexion TCP obtient un nouveau port source, généralement incrémenté de 1 par rapport à l’allocation précédente. L’IANA alloue la plage 49152 à 65535 pour ces ports éphémères, ce qui donne 16384 ports. Au fil du temps, le port source TCP parcourra la plage et le port source d’origine sera réutilisé, et ce flux aura le même 5-tuple que le flux d’origine. Cela pose un problème, car ce n’est pas le même flux!

Pour résoudre ce problème, nous avons besoin que les flux soient expirés où aucun paquet n’est vu pendant plus d’un laps de temps spécifié. On recommence :

Un flux est une séquence de paquets transportant des informations entre deux hôtes où les paquets ont des propriétés communes:

• Pour les protocoles de transport avec des numéros de port (c’est-à-dire TCP/ UDP / SCTP):

Tous les paquets du flux partagent le même 5-tuple ou 5-tuple transposé

else:

Tous les paquets du flux partagent le même 3-tuple ou 3-tuple transposé

• Tous les temps inter-paquets sont inférieurs à la valeur de délai d’expiration arbitraire du flux

Sixième tentative – Paramètres arbitraires

Parfois, vous pouvez souhaiter que différents paramètres identifient les flux, ou ceux-ci peuvent vous être imposés par le type de matériel / logiciel du réseau.

Dans un routeur Cisco par exemple, les flux sont identifiés par un Tuple à 7 qui ajoute le type de service (ToS) et la sous-interface d’entrée au Tuple à 5 standard. Il peut également y avoir des situations où les champs de couche 2, tels que l’adresse MAC source ou de destination, peuvent avoir un sens en tant que clés de flux (bien que notez qu’ils ne sont significatifs que localement).

Il existe d’autres paramètres qui pourraient être utilisés comme propriétés communes pour l’identification des flux; c’est finalement à l’opérateur de décider et des capacités de l’équipement. Sur cette base, nous affinons davantage la définition:

Un flux est une séquence de paquets transportant des informations entre deux hôtes où les paquets ont des propriétés communes :

• Pour les protocoles de transport avec des numéros de port (c’est-à-dire TCP/UDP / SCTP):

Tous les paquets du flux partagent le même 5-tuple ou 5-tuple transposé

else:

Tous les paquets du flux partagent le même 3-tuple ou 3-tuple transposé

• Tous les temps inter-paquets sont inférieurs à la valeur de délai d’expiration arbitraire du flux
• Peut utiliser n’importe quel paramètre arbitraire comme clés de flux, y compris ToS, interface, etc.

Envelopper le tout

Nous avons montré que la production d’une seule définition de flux englobante est un problème difficile. La définition des flux est spécifique à la mise en œuvre, dépend des besoins des utilisateurs ainsi que des capacités de l’équipement réseau qui mesure les flux.

Dans la partie 2 de cet article de blog, nous examinerons d’autres considérations pour les flux tels que les étiquettes de flux IPv6, la fragmentation (problème IPv4 et IPv6..), le chiffrement, les paquets non IP et la façon dont les flux sont mesurés et utilisés dans d’autres systèmes tels que le SDN.

Voir: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf

Pour certains articles connexes, voir: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf et https://is.muni.cz/th/hilnn/cse2009.pdf

Pour les RFC pertinentes, voir: https://tools.ietf.org/html/rfc5103

Pour en savoir plus sur la normalisation de QUIC, voir: https://datatracker.ietf.org/wg/quic/about/

Voir : https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml