Aller au contenu principal

5. Initialisation de l'association (Association Initialization)

5.1. Établissement normal d'une association (Normal Establishment of an Association)​

Un point de terminaison SCTP A qui souhaite établir une association avec un autre point de terminaison SCTP Z DOIT envoyer un chunk INIT. Si Z accepte l'association, il DOIT répondre avec un paquet contenant un chunk INIT ACK. L'établissement de l'association est discuté plus en détail ci-dessous.

5.1.1. Gestion des paramètres de flux (Handle Stream Parameters)​

Dans le chunk INIT ou INIT ACK, l'expéditeur PEUT demander au destinataire d'utiliser des types d'adresse spécifiques en incluant un paramètre "Types d'adresse pris en charge (Supported Address Types)" dans la section de paramètres optionnels/de longueur variable. L'expéditeur DEVRAIT inclure ce paramètre s'il ne prend pas en charge tous les types d'adresse ou s'il souhaite limiter son pair à l'utilisation de certains types d'adresse.

Un destinataire d'un INIT ou INIT ACK DOIT envoyer toutes les communications ultérieures en utilisant l'un des types d'adresse spécifiés dans la liste ou le type d'adresse auquel l'INIT ou l'INIT ACK a été envoyé (s'il n'est pas répertorié).

Si le destinataire ne prend pas en charge ou souhaite éviter tout type d'adresse attendu par l'expéditeur, il PEUT abandonner l'association et DEVRAIT envoyer une erreur "Type d'adresse non pris en charge (Unsupported Address Type)".

Note : Si un INIT ou INIT ACK contient un paramètre "Types d'adresse pris en charge (Supported Address Types)", le destinataire DOIT utiliser uniquement l'un des types d'adresse trouvés dans le paramètre ou le type d'adresse auquel l'INIT/INIT ACK a été envoyé, même si le destinataire est capable d'utiliser d'autres types d'adresse.

Dans un chunk INIT ou INIT ACK, l'expéditeur indique sa capacité de flux via les paramètres "Nombre de flux sortants (Number of Outbound Streams, OS)" et "Nombre de flux entrants (Number of Inbound Streams, MIS)" qu'il inclut.

Le destinataire DEVRAIT utiliser la valeur que l'expéditeur indique dans le champ OS de l'INIT ou de l'INIT ACK comme nombre maximum de ses propres flux entrants (c'est-à-dire le MIS du destinataire). L'expéditeur utilise le paramètre MIS pour limiter le nombre de flux sur lesquels le pair peut envoyer des messages utilisateur.

Dans l'INIT ou l'INIT ACK, le nombre de flux sortants (OS) et le nombre de flux entrants (MIS) de l'expéditeur NE DOIVENT PAS être 0.

Si un destinataire reçoit un INIT ou INIT ACK où la valeur OS ou MIS est 0, le destinataire DEVRAIT abandonner l'association, envoyer un chunk ABORT et PEUT signaler l'erreur "Paramètre obligatoire invalide (Invalid Mandatory Parameter)".

Le destinataire DOIT également limiter son utilisation des flux sortants au nombre réel reçu dans le champ MIS de l'INIT ou de l'INIT ACK. En d'autres termes, après l'établissement de l'association, un point de terminaison utilisera ce qui suit :

Nombre de flux sortants pour envoyer des messages utilisateur = 
    minimum(OS local, MIS du pair)

Nombre de flux entrants pour recevoir des messages utilisateur = 
    minimum(MIS local, OS du pair)

5.1.2. Gestion des paramètres d'adresse (Handle Address Parameters)​

Pendant l'initialisation (avant d'envoyer l'INIT ou l'INIT ACK), l'expéditeur DEVRAIT inclure toutes ses adresses dans l'INIT ou l'INIT ACK en utilisant le paramètre d'adresse IPv4 optionnel et/ou le paramètre d'adresse IPv6. L'omission de ce paramètre optionnel indique que le point de terminaison n'a qu'une seule adresse, l'adresse source utilisée pour envoyer l'INIT ou l'INIT ACK.

Avant d'envoyer un chunk INIT, un point de terminaison DEVRAIT toujours entrer dans l'état COOKIE-WAIT.

Note : L'absence d'adresses dans un chunk INIT ne signifie pas que le point de terminaison expéditeur n'accepte pas d'autres adresses. Au contraire, l'absence d'adresses indique que l'expéditeur ne souhaite pas être écouté, mais il acceptera les messages envoyés depuis n'importe quelle adresse de son pair.

Si le destinataire ne prend pas en charge l'un des types d'adresse fournis par l'expéditeur dans l'INIT ou l'INIT ACK, il DEVRAIT abandonner l'association et PEUT envoyer une cause d'erreur "Type d'adresse non pris en charge (Unsupported Address Type)".

Un destinataire d'un INIT ou INIT ACK DOIT enregistrer toutes les informations d'adresse fournies (quelle que soit la manière dont elles ont été obtenues, y compris à partir de l'en-tête IP, du paramètre d'adresse IPv4 et/ou du paramètre d'adresse IPv6) et utiliser ces informations pour déterminer son ensemble d'adresses de transport.

Si l'expéditeur inclut un paramètre "Adresse de nom d'hôte (Host Name Address)", le destinataire DOIT immédiatement envoyer un chunk ABORT et PEUT inclure une cause d'erreur "Adresse non résolvable (Unresolvable Address)".

Note : L'utilisation du paramètre "Adresse de nom d'hôte (Host Name Address)" est obsolète. Un destinataire DOIT ignorer tout paramètre "Adresse de nom d'hôte (Host Name Address)" dans un INIT ou INIT ACK et DEVRAIT envoyer un chunk ABORT en réponse.

Un point de terminaison envoyant un INIT ACK devrait créer un State Cookie et le placer dans le paramètre State Cookie de l'INIT ACK. Voir la section 5.1.3 pour l'utilisation du State Cookie.

Le State Cookie devrait contenir les informations minimales requises suivantes :

  • Les informations obtenues du chunk INIT reçu (y compris l'Initiate Tag et les paramètres optionnels/de longueur variable)
  • L'heure à laquelle le State Cookie a été créé
  • Une durée de vie (le temps pendant lequel le cookie est valide)
  • Une méthode d'authentification de l'intégrité et de l'authenticité du State Cookie (par exemple, un code d'authentification de message (MAC))

Note d'implémentation : Le State Cookie peut être utilisé pour stocker des informations supplémentaires sur l'état de l'association en cours d'établissement. Cela permet à un point de terminaison de différer l'allocation de ressources (TCB) pendant l'établissement de l'association. Cette optimisation est appelée "Approche par Cookie (Cookie Approach)" et peut empêcher les attaques simples par déni de service.

Une implémentation envoyant un INIT ACK DEVRAIT protéger suffisamment le State Cookie pour empêcher un attaquant de deviner des State Cookies valides. Une technique recommandée consiste à inclure dans le State Cookie :

  • Un nonce aléatoire (unique par instance d'association)
  • Un horodatage
  • L'adresse source du pair
  • Le port source du pair
  • L'adresse de destination locale
  • Le port de destination local
  • Un MAC couvrant tous les champs ci-dessus

La clé secrète nécessaire pour créer ce MAC DEVRAIT être créée lors de l'initialisation de la pile SCTP et devrait être actualisée périodiquement. Cette clé DOIT être gardée secrète pour toute personne en dehors des parties communicantes.

L'inclusion de ces valeurs dans le paramètre State Cookie de l'INIT ACK permet la validation du State Cookie renvoyé dans le chunk COOKIE ECHO. Le processus de validation est décrit dans la section 5.1.4.

De plus, l'expéditeur PEUT inclure toute autre donnée nécessaire pour générer le State Cookie utilisé pour valider le cookie renvoyé dans COOKIE ECHO et pour établir l'association.

Note : Le calcul du MAC DOIT inclure l'horodatage pour garantir qu'un cookie rejoué ne peut pas être utilisé comme outil d'attaque par déni de service.

Lorsqu'un point de terminaison reçoit un State Cookie dans un chunk COOKIE ECHO, il DOIT valider ce cookie selon ce qui suit :

  1. Vérifier que le MAC du State Cookie est valide. Si le MAC est invalide, rejeter silencieusement le paquet.

  2. Vérifier que le State Cookie n'est pas périmé. Si le State Cookie est périmé, le point de terminaison DEVRAIT envoyer un chunk ERROR avec le code de cause défini sur "Stale Cookie Error" et rejeter silencieusement le paquet. La péremption du State Cookie peut être ajustée à l'aide du paramètre "Cookie Preservative". Voir la section 5.1.3.

  3. Vérifier que l'adresse source et les numéros de port correspondent aux valeurs stockées dans le State Cookie. S'ils ne correspondent pas, rejeter silencieusement le paquet.

Si le State Cookie est valide, le point de terminaison DEVRAIT créer une association avec ce pair et envoyer un chunk COOKIE ACK à l'expéditeur. Le point de terminaison devrait ensuite déplacer cette association vers l'état ESTABLISHED.

Une implémentation DOIT protéger l'intégrité et l'authenticité du State Cookie en utilisant une technique telle que décrite ci-dessous ou une technique équivalente.

La technique recommandée consiste à inclure un code d'authentification de message (MAC) dans le State Cookie. Le MAC DEVRAIT être calculé à l'aide d'une clé secrète connue de l'expéditeur mais inconnue de tout attaquant potentiel.

L'algorithme MAC DEVRAIT être au moins aussi sûr que HMAC-SHA-1 tel que défini dans [RFC2104] et [RFC3174].

Pour créer et vérifier le MAC, une clé secrète est nécessaire. Cette clé secrète DEVRAIT être modifiée périodiquement (par exemple, toutes les quelques heures) pour limiter la capacité d'un attaquant à déduire la clé en observant le trafic légitime.

Pendant les changements de clé secrète, une implémentation DEVRAIT conserver l'ancienne clé pendant une période (au moins deux fois la durée de vie du cookie) pour permettre la validation des cookies créés avec l'ancienne clé.

5.1.6. Un exemple d'établissement d'association normal (An Example of Normal Association Establishment)​

Dans le cas le plus simple, l'établissement d'association normal d'un point de terminaison A demandant à démarrer une association vers le point de terminaison Z ressemblerait à ceci :

Point de terminaison A                         Point de terminaison Z

INIT    ----[INIT ACK avec State Cookie]----->
        <----------[COOKIE ECHO]-------------
        ----------[COOKIE ACK]--------------->

À ce stade, l'association est ESTABLISHED aux deux extrémités.

Étapes détaillées :

A) Le point de terminaison A envoie un chunk INIT au point de terminaison Z, indiquant son désir d'établir une association. Dans le chunk INIT, le point de terminaison A DOIT fournir sa balise de vérification (à utiliser dans tous les paquets provenant de Z), le TSN initial qu'il prend en charge, le nombre de flux sortants (OS), le nombre maximal de flux entrants (MIS) et ses autres adresses de transport (le cas échéant).

B) Après avoir reçu l'INIT, le point de terminaison Z DEVRAIT répondre avec un chunk INIT ACK. Dans l'INIT ACK, Z DOIT fournir sa balise de vérification, son TSN initial, son OS, son MIS et ses adresses de transport (le cas échéant). De plus, Z DOIT créer un State Cookie et l'inclure dans l'INIT ACK.

C) Après avoir reçu l'INIT ACK contenant le State Cookie, le point de terminaison A DEVRAIT répondre avec un chunk COOKIE ECHO. Le chunk COOKIE ECHO DOIT contenir le State Cookie reçu dans l'INIT ACK. De plus, le point de terminaison A PEUT envoyer des données utilisateur groupées avec le COOKIE ECHO dans le même paquet.

D) Après avoir reçu le COOKIE ECHO, le point de terminaison Z validera le State Cookie. S'il est valide, Z créera l'association et répondra avec un chunk COOKIE ACK. De plus, Z PEUT envoyer des données utilisateur groupées avec le COOKIE ACK dans le même paquet.

E) Après avoir reçu le COOKIE ACK, le point de terminaison A changera son état d'association de COOKIE-ECHOED à ESTABLISHED. A peut maintenant envoyer et recevoir des données utilisateur sur l'association établie.

À tout moment pendant la durée de vie d'une association, un point de terminaison peut recevoir des chunks INIT, INIT ACK, COOKIE ECHO ou COOKIE ACK inattendus ou en double. Cette section décrit comment gérer ces chunks.

5.2.1. INIT reçu dans l'état CLOSED (INIT Received in CLOSED State)​

Si un point de terminaison est dans l'état CLOSED et reçoit un chunk INIT, il DEVRAIT répondre avec un INIT ACK comme décrit dans la section 5.1.

Si un point de terminaison est dans l'état COOKIE-WAIT ou COOKIE-ECHOED et reçoit un chunk INIT dont l'Initiate Tag ne correspond pas à sa balise de vérification de pair enregistrée, le point de terminaison DEVRAIT rejeter l'ancien TCB (le cas échéant) et répondre avec un INIT ACK au nouveau chunk INIT.

Si un point de terminaison est dans l'état COOKIE-WAIT ou COOKIE-ECHOED et reçoit un chunk INIT dont l'Initiate Tag correspond à sa balise de vérification de pair enregistrée, le point de terminaison DEVRAIT répondre avec un INIT ACK mais ne pas changer son état. Cette situation peut se produire lorsque le pair n'a pas reçu ou a perdu l'INIT ACK.

Si un point de terminaison est dans l'état CLOSED ou COOKIE-WAIT et reçoit un INIT ACK, le point de terminaison DEVRAIT envoyer un chunk ABORT et PEUT inclure une cause d'erreur "Out of the Blue" (voir la section 3.3.10).

Si un point de terminaison est dans l'état COOKIE-WAIT et reçoit un INIT ACK dont le champ Initiate Tag ne correspond pas à sa propre balise, le point de terminaison DEVRAIT entrer dans l'état CLOSED, détruire le TCB et envoyer un chunk ABORT.

Cette section décrit le comportement lorsqu'un point de terminaison reçoit un chunk COOKIE ECHO dans des états autres que CLOSED et COOKIE-ECHOED.

Note d'implémentation : Un point de terminaison peut recevoir un chunk COOKIE ECHO à tout moment pendant la durée de vie de l'association, généralement en raison d'une retransmission du pair ou d'un délai réseau.

Si un point de terminaison reçoit un chunk COOKIE ECHO et qu'un TCB existe pour la même association, le point de terminaison DEVRAIT le gérer selon l'une des actions suivantes :

A) Si l'état actuel est ESTABLISHED, le point de terminaison DEVRAIT rejeter silencieusement le COOKIE ECHO. Alternativement, si le pair inclut une balise de vérification incorrecte dans le COOKIE ECHO, le point de terminaison PEUT envoyer un chunk ABORT.

B) Si l'état actuel est SHUTDOWN-ACK-SENT, le point de terminaison DEVRAIT rejeter silencieusement le COOKIE ECHO.

Dans tous les autres cas, le point de terminaison DEVRAIT traiter le COOKIE ECHO comme une tentative d'établissement d'une nouvelle association selon les règles de la section 5.2.4, mais utiliser toutes les informations du TCB existant pour optimiser le processus d'établissement de l'association.

Si un point de terminaison reçoit un chunk COOKIE ACK en dehors de l'état COOKIE-ECHOED, il DEVRAIT rejeter silencieusement le chunk.

Si un point de terminaison reçoit un chunk ERROR contenant une cause d'erreur "Stale Cookie" après avoir envoyé un chunk COOKIE ECHO et que le point de terminaison est dans l'état COOKIE-ECHOED, le point de terminaison PEUT tenter de rétablir l'association en utilisant un nouveau chunk INIT.

Si le point de terminaison choisit de réessayer, il DEVRAIT inclure un paramètre "Cookie Preservative" dans le nouveau chunk INIT avec une valeur définie sur le champ Measure of Staleness spécifié dans l'erreur "Stale Cookie" reçue.

Si le point de terminaison choisit de ne pas réessayer, il DEVRAIT entrer dans l'état CLOSED et signaler le problème à sa couche supérieure.

5.3. Autres problèmes d'initialisation (Other Initialization Issues)​

5.3.1. Sélection du port par défaut (Selection of Default Port)​

Un point de terminaison SCTP DEVRAIT prendre en charge la réception et l'envoi de paquets SCTP vers le port UDP 9899 (le port par défaut pour l'encapsulation SCTP sur UDP).

5.3.2. Coexistence IPv4/IPv6 (IPv4/IPv6 Coexistence)​

Une implémentation DEVRAIT prendre en charge l'utilisation d'adresses IPv4 et IPv6 comme recommandé dans [RFC4213].

5.3.3. Identifiant d'association SCTP (SCTP Association Identifier)​

Chaque association SCTP est identifiée de manière unique par une paire de balises de vérification :

  • La balise de vérification locale (fournie par le pair dans son INIT ou INIT ACK)
  • La balise de vérification du pair (envoyée dans l'INIT ou l'INIT ACK local)

Cette paire de balises est utilisée pour démultiplexer les paquets SCTP reçus.

5.4. Vérification du chemin (Path Verification)​

Pendant le fonctionnement normal, un point de terminaison SCTP DOIT utiliser le mécanisme de pulsation (heartbeat) pour vérifier l'accessibilité des chemins de son pair.

Pendant l'initialisation (après avoir envoyé l'INIT ACK), un point de terminaison DEVRAIT utiliser le mécanisme de pulsation pour vérifier que toutes les adresses reçues dans l'INIT ou l'INIT ACK sont accessibles.

Cette vérification DEVRAIT commencer immédiatement après que l'association entre dans l'état ESTABLISHED.

Note d'implémentation : Si un point de terminaison reçoit un INIT ou INIT ACK contenant plusieurs adresses IP, il DEVRAIT tenter de vérifier toutes les adresses fournies en envoyant des HEARTBEAT à chaque adresse.

Les adresses qui ne répondent pas aux HEARTBEAT pendant le processus de vérification DEVRAIENT être marquées comme inactives et ne devraient pas être utilisées dans la transmission de données normale, sauf si elles sont ultérieurement prouvées actives (par HEARTBEAT ou transmission de données).

Ce chapitre continue...

Pour un contenu plus détaillé du chapitre 5 (y compris la gestion spécifique des erreurs, les mécanismes de temporisation et les considérations liées à la sécurité), veuillez consulter le texte complet de la RFC 4960.

Dernière mise à jour le