Vue d’ensemble de SCTP

SCTP Services

SCTP fournit les services suivants :

• Protocole d’accès au serveur agrégé (ASAP)

• Contrôle d’appel indépendant du support (BICC)

• Segment de placement direct des données (segment DDP)

• Contrôle de session de flux de placement direct des données (flux DDP)

• Diamètre dans un bloc de données DTLS/SCTP (Diameter-DTLS)

• Diamètre dans un bloc de données SCTP (Diameter-SCTP)

• Extensions DPNSS/DASS 2 au protocole IUA (DUA)

• Endpoint Handlescape Redundancy Protocol (ENRP)

• Protocole H.248 (H248)

• Protocole H.323 (H323)

• Couche d’adaptation de l’utilisateur RNIS (IUA)

• Couche d’adaptation pair-à-pair (M2PA) de l’utilisateur MTP2

• Couche d’adaptation utilisateur MTP2 (M2UA)

• Couche d’adaptation utilisateur MTP3 (M3UA)

• Autres protocoles de charge utile SCTP configurés non spécifiés (autres)

• Q.IPC

• Réservés au

• Protocole d’application S1 (S1AP)

• Configuration SIMCO (Simple Middlebox)

• Couche d’adaptation de l’utilisateur (SUA) SCCP

• TALI (Transport Adapter Layer Interface)

• V5.2 Couche d’adaptation utilisateur (V5UA)

• Protocole d’application X2 (X2AP)

Limitations et contraintes de SCTP

Le SCTP présente les limitations et contraintes suivantes :

• Adresses IP

  • Seul le NAT IP statique est pris en charge ; Les paquets d’interface (d’un côté : client ou serveur) entrants doivent appartenir à la même zone.

• Politiques

  • La stratégie dynamique n’est pas prise en charge. Vous devez configurer toutes les stratégies pour les sessions SCTP.

  • Lorsque les stratégies sont supprimées, les sessions et les associations associées sont effacées.

  • Vous configurez une stratégie pour autoriser le trafic SCTP de toutes les adresses IP clientes vers toutes les adresses IP de serveur, et une autre stratégie pour autoriser le trafic SCTP de toutes les adresses IP de serveur vers les adresses IP clientes. Si une stratégie a un profil SCTP, le même profil SCTP est nécessaire pour la stratégie inverse.

  • Si vous configurez des stratégies différentes pour chaque session appartenant à une association, il y aura plusieurs stratégies liées à une association, et la gestion des paquets SCTP (abandon, limite de débit, etc.) utilise le profil attaché à la stratégie de la session SCTP de gestion.

  • Les applications utilisées dans les stratégies de sécurité pour autoriser le trafic SCTP ALG ne peuvent pas être configurées à l’aide de l’option application-protocol ignore . Cette condition s’applique même si le contrôle SCTP ALG n’est pas configuré.

• L’activation/désactivation de SCTP est contrôlée par la configuration ou non d’un profil SCTP.

  • Si aucun profil n’est attaché à une stratégie, les paquets SCTP sont transférés sans inspection.

  • Si un profil avec l’option nat-only est attaché à une stratégie, seule la traduction NAT est effectuée sur les paquets SCTP correspondant à la stratégie. Si l’option n’est pas définie sur nat-only un profil, la traduction NAT et l’inspection SCTP sont effectuées sur chaque paquet SCTP correspondant à la stratégie.

  • Si vous désactivez SCTP, toutes les associations sont supprimées et les paquets SCTP suivants sont transmis ou abandonnés conformément à la stratégie.

  • Si vous activez SCTP, toutes les sessions SCTP existantes doivent être effacées, sinon le trafic correspondant aux anciennes sessions sera transféré sans aucune inspection du module SCTP.

    Si vous souhaitez activer SCTP à nouveau, toutes les communications SCTP en cours d’exécution seront abandonnées, car aucune association n’existe. Les nouvelles communications SCTP permettent d’établir une association et d’effectuer les inspections.

    Note:

    Effacez les anciennes sessions SCTP lorsque SCTP est réactivé ; Cela évitera tout impact causé par les anciennes sessions SCTP sur les nouvelles communications SCTP.

  • Si vous ajoutez un profil SCTP à une stratégie existante, vous devez effectuer l’une des opérations suivantes : effacer les sessions associées ou supprimer l’ancienne stratégie et en créer une nouvelle.

  • Si vous modifiez la valeur du délai d’expiration dans le profil SCTP, l’établissement de liaison configuré et la valeur du délai d’expiration dans les associations existantes ne changeront pas.

• Limitation de débit SCTP

  • Toute modification de la configuration de limitation de débit n’affectera pas le trafic ultérieur des associations existantes. Elle s’appliquera aux associations nouvellement créées.

  • La valeur décimale du protocole pris en charge est comprise entre 0 et 63. Cette valeur inclut 48 protocoles attribués par l’IANA et 16 protocoles non attribués.

  • Un maximum de 80 adresses sont limitées dans un profil.

  • Un maximum de 10 protocoles sont limités en débit pour une adresse dans un profil.

  • La valeur limite de débit prise en charge est comprise entre 1 et 12000.

• Blocage du protocole de charge utile SCTP

  • Toute modification de la configuration bloquant le protocole a un impact immédiat sur le trafic ultérieur des associations existantes.

  • La valeur décimale du protocole pris en charge est comprise entre 0 et 63. Cette valeur inclut 48 protocoles attribués par l’IANA et 16 protocoles non attribués.

• Un point de terminaison SCTP prend également en charge NAT-PT dans les deux directions, d’un format d’adresse IPv4 à un format d’adresse IPv6, et vice versa. Le module SCTP ne prend pas en charge le multihébergement mixte IPv4 ou IPv6 et le NAT mélangé IPv4 ou IPv6.

• Pour que le NAT statique fonctionne, les paquets d’interfaces (d’un côté : côté client ou côté serveur) qui arrivent doivent appartenir à la même zone.

• Pour les cas multihome, seul le paramètre d’adresse IPv4 dans INIT ou INIT_ACK est pris en charge.

• Seul le NAT statique est pris en charge pour SCTP.

• Seules les associations SCTP établies sont synchronisées avec les sessions homologues.

• Les sessions SCTP ne sont pas supprimées avec des associations ; Ils expirent au bout de 30 minutes, ce qui est la valeur par défaut. La valeur du délai d’attente est configurable et peut être modifiée.

• Si le processus d’établissement de liaison à 4 voies n’est pas géré sur un nœud et qu’il est géré à la place sur deux nœuds (par exemple, deux sessions sur deux nœuds en mode actif/actif) ou si le cluster est en basculement avant la fin de l’établissement de liaison à 4 voies, l’association ne sera pas établie avec succès.

• La mise à niveau logicielle unifiée en service (ISSU) vers des versions antérieures de Junos OS n’est pas prise en charge.

• L’analyse des messages M3UA/SCCP est cochée, mais l’inspection dynamique M3UA/SCCP n’est pas cochée.

• Seule la norme UIT-T Rec. Q.711-Q.714 (07/96) est prise en charge. Les normes ANSI, ETSI, chinoises et autres ne sont pas prises en charge.

• Seule la norme RFC 4960 est prise en charge.

• L’affinité de session VPN ne prend pas en charge le protocole de tunnelisation GPRS (GTP) et le protocole SCTP (Stream Control Transmission Protocol).

Présentation des fonctionnalités SCTP

Voici les caractéristiques importantes de SCTP :

• Prise en charge du multihébergement où l’un ou les deux points de terminaison d’une connexion peuvent être constitués de plusieurs adresses IP. Cela permet un basculement transparent entre les chemins réseau redondants.

• La livraison de données par blocs au sein d’un flux indépendant élimine les blocages inutiles en tête de ligne.

• Fonctionnalité de sélection et de surveillance des chemins pour sélectionner un chemin de transmission de données principal et tester la connectivité du chemin de transmission.

• Les mécanismes de validation et d’accusé de réception protègent contre les attaques par flooding et signalent les blocs de données dupliqués ou manquants.

• Amélioration de la détection des erreurs pour les trames Ethernet jumbo.

Comprendre la prise en charge de l’architecture Central Point pour SCTP

Une association SCTP (Stream Control Transmission Protocol) est une connexion entre deux points de terminaison SCTP. Chaque point de terminaison SCTP identifie l’association à l’aide d’une balise. Lors d’une configuration d’association SCTP, deux points de terminaison SCTP échangent leurs propres balises pour la réception de paquets. Lors de l’échange de paquets entre deux points de terminaison SCTP, l’adresse source et l’adresse de destination peuvent changer au cours du cycle de vie de l’association.

La session de flux SCTP utilise une balise de connexion pour distribuer plus précisément le trafic SCTP entre les SPU sur les périphériques SRX1500, SRX4100, SRX4200, SRX5400, SRX5600 et SRX5800 qui prennent en charge l’ALG SCTP. La balise de connexion est décodée à partir du vtag SCTP. Une session SCTP distincte sera créée pour chacun des trois premiers paquets, c’est-à-dire une session pour INIT, INIT-ACK et COOKIE-ECHO, respectivement. Étant donné que le trafic dans le sens inverse a sa propre session, la session ne peut plus correspondre à la session existante dans le sens aller et passer automatiquement. Par conséquent, à l’instar de la stratégie de direction directe, une stratégie explicite est nécessaire pour approuver le trafic SCTP dans la direction inverse. Dans ce scénario, la session de flux SCTP nécessite l’établissement d’une configuration de stratégie bidirectionnelle, même pour une connexion de base.

Prise en charge SCTP du routage et du transfert virtuels (VRF)

La fonctionnalité VRF (Virtual Routing and Forwarding) permet de gérer les adresses IP distantes. Client SCTP, avant d’initier une nouvelle association SCTP, il doit définir l’option socket pour l’index de la table de routage/l’index VRF, si l’interface de sortie vers le serveur SCTP est configurée à l’intérieur de VRF, l’autre association ne sera pas établie car le client SCTP utilisera l’instance de routage par défaut/globale pour l’établissement de l’association. Côté serveur SCTP, si l’option VRF index socket n’est pas définie sur le socket d’écoute, la demande d’association reçue sur tous les VRF sera acceptée, mais si l’option VRF index socket est définie sur le socket d’écoute, la demande d’établissement d’association arrivant sur ce VRF particulier ne sera prise en compte que sur ce VRF particulier.

L’application peut soit définir l’option de socket avec un indicateur personnalisé pour fournir un index de table de routage à SCTP afin de gérer l’association SCTP basée sur VRF, pour placer l’association dans cette association particulière, soit laisser le noyau SCTP choisir VRF pour l’association lors de l’établissement d’une négociation à 4 voies, en fonction de VRF dans lequel l’interface d’entrée est configurée.

Lorsqu’une association SCTP est établie sur une instance VRF, le noyau doit prendre en compte un paramètre supplémentaire, l’identifiant VRF unique, lors de la recherche d’associations uniques en utilisant les 4 tuples existants utilisés dans SCTP (IP source, port source, IP de destination, port de destination).

• Paquets SCTP entrants via VRF :

  Lorsqu'un paquet SCTP arrive sur une interface entrante, une recherche est effectuée à l'aide du 5-tuple (adresse IP source, port source, adresse IP de destination, port de destination et « ID VRF sur lequel le paquet a été reçu ») pour déterminer s'il existe une association SCTP existante présente dans le noyau.

• Paquets SCTP sortants via VRF :

  Pour chaque paquet SCTP envoyé par le noyau, l'ID VRF correspondant est obtenu à partir des données d'association à l'aide du 5-tuple (IP source, port source, IP de destination, port de destination et 'VRF ID sur lequel le paquet doit être envoyé').

Douille SCTP de style un à plusieurs

SCTP prend en charge deux styles de sockets : 1 à 1 (comparable à TCP) et 1 à Many (permettant plusieurs associations actives sur un seul socket). Ce dernier facilite la communication avec plusieurs points de terminaison homologues simultanément, en utilisant des identifiants d’association (assoc-id) pour les distinguer.

Les API système ci-dessous sont utilisées par l’application pour utiliser le socket de style SCTP 1 :1 ou 1 :N :

Appels système pour socket de style 1 à 1

• Rôle serveur : socket(), bind(), listen(), accept(), write()/read(), close()

• Rôle du client : socket(), connect(), write()/read(), close()

Le système demande 1 à plusieurs sockets de style

• Rôle serveur : socket(), bind(), listen(), recvmsg(), sendmsg(), close()

• Rôle du client : socket(), sendmsg(), recvmsg(), close()

Section d’en-tête commun

Tous les paquets SCTP nécessitent une section d’en-tête commune. Cette section occupe les 12 premiers octets du paquet. Le tableau 1 décrit les champs de la section d’en-tête commun :

Section Chunk de données

Section du bloc de données : cette section occupe la partie restante du paquet. Le tableau 2 décrit les champs de la section du bloc de données :

Le gestionnaire de ressources (RM) autorise 8 adresses IP sources et 8 adresses IP de destination lors d’une communication SCTP.