Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document fournit une vue d'ensemble du protocole TCP multichemin (MPTCP), de son impact sur l'inspection de flux et des produits Cisco qui sont et ne sont pas affectés par ce protocole.
Les hôtes connectés à Internet ou dans un environnement de data center sont souvent connectés par plusieurs chemins. Cependant, lorsque le protocole TCP est utilisé pour le transport de données, la communication est limitée à un seul chemin réseau. Il est possible que certains chemins entre les deux hôtes soient congestionnés, alors que d’autres chemins sont sous-utilisés. Une utilisation plus efficace des ressources réseau est possible si ces chemins multiples sont utilisés simultanément. En outre, l'utilisation de plusieurs connexions améliore l'expérience utilisateur, car elle offre un débit plus élevé et une résilience améliorée contre les pannes de réseau.
Le protocole MPTCP est un ensemble d’extensions du protocole TCP standard qui permet de séparer un flux de données unique et de le transporter sur plusieurs connexions. Reportez-vous à RFC6824 : Extensions TCP pour le fonctionnement à chemins multiples avec plusieurs adresses pour plus d'informations.
Comme l'illustre ce schéma, MPTCP est capable de séparer le flux de 9 Mbits/s en trois sous-flux différents sur le noeud expéditeur, qui est ensuite agrégé de nouveau dans le flux de données d'origine sur le noeud récepteur.
Les données qui entrent dans la connexion MPTCP agissent exactement comme par le biais d'une connexion TCP régulière ; les données transmises ont garanti une livraison dans l'ordre. Puisque MPTCP ajuste la pile réseau et fonctionne au sein de la couche transport, il est utilisé de manière transparente par l'application.
MPTCP utilise des options TCP afin de négocier et d'orchestrer la séparation et le réassemblage des données sur les sous-flux multiples. L'option TCP 30 est réservée par l'IANA (Internet Assigned Numbers Authority) pour une utilisation exclusive par MPTCP. Référez-vous à Paramètres TCP (Transmission Control Protocol) pour plus d'informations. Lors de l'établissement d'une session TCP régulière, une option MP_CAPABLE est incluse dans le paquet SYN (Synchronize initial). Si le répondeur prend en charge et choisit de négocier MPTCP, il répond également avec l'option MP_CAPABLE dans le paquet SYN-accuse (ACK). Les clés échangées dans cette connexion seront utilisées ultérieurement afin d'authentifier la jointure et la suppression d'autres sessions TCP dans ce flux MPTCP.
Lorsque cela est jugé nécessaire, l'hôte A peut initier des sous-flux supplémentaires provenant d'une autre interface ou adresse vers l'hôte B. Comme pour le sous-flux initial, les options TCP sont utilisées afin d'indiquer le désir de fusionner ce sous-flux avec l'autre sous-flux. Les clés échangées dans l'établissement initial du sous-flux (avec un algorithme de hachage) sont utilisées par Host-B afin de confirmer que la demande de jointure est effectivement envoyée par Host-A. Le sous-flux secondaire 4-tuple (IP source, IP de destination, port source et port de destination) est différent de celui du sous-flux principal ; ce flux peut emprunter un chemin différent à travers le réseau.
L'hôte A a plusieurs interfaces et il est possible que l'hôte B ait plusieurs connexions réseau. L’hôte B apprend implicitement les adresses A1 et A2 en raison des sous-flux d’approvisionnement de l’hôte A à partir de chacune de ses adresses destinées à B1. Il est possible que Host-B annonce son adresse supplémentaire (B2) à Host-A afin que d'autres sous-flux soient effectués vers B2. Ceci est effectué via l'option TCP 30. Comme le montre ce diagramme, l'hôte B annonce son adresse secondaire (B2) à l'hôte A, et deux sous-flux supplémentaires sont créés. Étant donné que MPTCP fonctionne au-dessus de la couche réseau de la pile OSI (Open System Interconnection), les adresses IP annoncées peuvent être IPv4, IPv6 ou les deux. Il est possible que certains des sous-flux soient transportés par IPv4 simultanément lorsque d'autres sous-flux sont transportés par IPv6.
Un flux de données donné à MPTCP par l'application doit être segmenté et distribué par l'expéditeur sur les différents sous-flux. Il doit ensuite être réassemblé dans le flux de données unique avant d'être remis à l'application.
Le protocole MPTCP inspecte les performances et la latence de chaque sous-flux et ajuste dynamiquement la distribution des données afin d'obtenir le débit agrégé le plus élevé. Lors du transfert de données, l'option d'en-tête TCP inclut des informations sur les numéros de séquence/accusé de réception MPTCP, le numéro de séquence/accusé de réception de sous-flux actuel et une somme de contrôle.
De nombreux périphériques de sécurité peuvent supprimer ou remplacer les options TCP inconnues par une valeur NOOP (No Option). Si le périphérique réseau fait cela au paquet SYN TCP sur le sous-flux initial, l'annonce MP_CAPABLE est supprimée. Par conséquent, il apparaît au serveur que le client ne prend pas en charge le protocole MPTCP et qu’il revient à un fonctionnement TCP normal.
Si l'option est conservée et que MPTCP est capable d'établir plusieurs sous-flux, l'analyse des paquets en ligne par les périphériques réseau risque de ne pas fonctionner de manière fiable. En effet, seules des parties du flux de données sont transportées vers chaque sous-flux. L'effet de l'inspection de protocole sur le protocole MPTCP peut varier de rien à toute interruption de service. L'effet varie selon le type et la quantité de données inspectées. L'analyse des paquets peut inclure la passerelle de couche application (ALG ou fixup) du pare-feu, la traduction d'adresses réseau (NAT) ALG, la visibilité et le contrôle des applications (AVC), la reconnaissance des applications réseau (NBAR) ou les services de détection des intrusions (IDS/IPS). Si l'inspection des applications est requise dans votre environnement, il est recommandé d'activer la suppression de l'option TCP 30.
Si le flux ne peut pas être inspecté en raison du chiffrement ou si le protocole est inconnu, alors le périphérique en ligne ne devrait avoir aucun impact sur le flux MPTCP.
Ces produits sont affectés par MPTCP :
Chaque produit est décrit en détail dans les sections suivantes de ce document.
Par défaut, le pare-feu Cisco ASA remplace les options TCP non prises en charge, qui incluent l'option MPTCP 30, par l'option NOOP (option 1). Afin d'autoriser l'option MPTCP, utilisez cette configuration :
tcp-map my-mptcp
tcp-options range 30 30 allow
class-map my-tcpnorm
match any
policy-map my-policy-map
class my-tcpnorm
set connection advanced-options my-mptcp
service-policy my-policy-map global
L'ASA prend en charge l'inspection de nombreux protocoles. L'effet que le moteur d'inspection peut avoir sur l'application varie. Il est recommandé que, si une inspection est requise, la carte TCP décrite précédemment ne soit PAS appliquée.
Étant donné que le FTD effectue une inspection approfondie des paquets pour les services IPS/IDS, il n'est pas recommandé de modifier le tcp-map pour autoriser l'option TCP à passer.
CBAC ne supprime pas les options TCP du flux TCP. Le protocole MPTCP établit une connexion via le pare-feu.
Cisco IOS et IOS-XE ZBFW ne suppriment pas les options TCP du flux TCP. Le protocole MPTCP établit une connexion via le pare-feu.
Par défaut, le périphérique ACE supprime les options TCP des connexions TCP. La connexion MPTCP revient aux opérations TCP régulières.
Le périphérique ACE peut être configuré pour autoriser les options TCP via la commande tcp-options, comme décrit dans la section Configuration du traitement des options TCP par ACE du Guide de sécurité vA5(1.0), Cisco ACE Application Control Engine. Cependant, cela n'est pas toujours recommandé, car les sous-flux secondaires peuvent être équilibrés avec différents serveurs réels et la jointure échoue.
En règle générale, tout périphérique qui n'inspecte pas les flux TCP ou les informations de couche 7 ne modifie pas les options TCP et doit donc être transparent pour MPTCP. Ces périphériques peuvent inclure :