Aller au contenu principal

8. Gestion des pannes (Fault Management)

SCTP fournit des mécanismes robustes de détection et de récupération de pannes pour assurer une communication fiable en cas de défaillance du réseau.

8.1. Détection de défaillance du point de terminaison (Endpoint Failure Detection)​

Les points de terminaison SCTP doivent être capables de détecter la défaillance complète de leur point de terminaison pair.

8.1.1. Comptage des erreurs au niveau de l'association​

Chaque association SCTP maintient un compteur d'erreurs d'association (Association Error Counter) :

  • Lorsque le compteur d'erreurs d'une adresse de destination atteint le seuil, l'association est considérée comme défaillante
  • Lorsque l'association échoue, le point de terminaison DEVRAIT le signaler à la couche supérieure

8.1.2. Conditions de défaillance du point de terminaison​

Un point de terminaison est considéré comme défaillant lorsque :

  1. Toutes les adresses de destination sont marquées comme inactives
  2. Le nombre total d'erreurs de l'association dépasse le seuil Association.Max.Retrans

Association.Max.Retrans : Valeur par défaut recommandée de 10 tentatives de retransmission.

8.1.3. Réponse à la défaillance​

Lorsqu'une défaillance du point de terminaison est détectée :

1. Arrêter l'envoi de nouvelles données vers ce point de terminaison
2. Signaler l'échec de l'association à la couche supérieure
3. Détruire le bloc de contrôle de transmission (TCB)
4. Optionnel : Envoyer un chunk ABORT pour notifier le pair

8.2. Détection de défaillance de chemin (Path Failure Detection)​

SCTP peut détecter les défaillances de chemins de transport individuels sans affecter l'ensemble de l'association (si d'autres chemins actifs sont disponibles).

8.2.1. Comptage des erreurs au niveau du chemin​

Chaque adresse de transport de destination maintient un compteur d'erreurs de chemin (Path Error Counter) :

  • Incrémenté à chaque échec de transmission
  • Réinitialisé à 0 en cas de transmission réussie ou de réception de HEARTBEAT ACK

8.2.2. Conditions de défaillance de chemin​

Un chemin est considéré comme inactif lorsque :

  1. Les échecs de transmission consécutifs atteignent Path.Max.Retrans
  2. Les échecs HEARTBEAT consécutifs atteignent Path.Max.Retrans

Path.Max.Retrans : Valeur par défaut recommandée de 5 tentatives de retransmission.

8.2.3. Gestion de l'état du chemin​

États du chemin :

  • Active (Actif) : Chemin disponible pour la transmission de données
  • Inactive (Inactif) : Chemin temporairement indisponible

Transitions d'état :

Active -> Inactive : 
  - Les échecs consécutifs atteignent Path.Max.Retrans

Inactive -> Active :
  - Réception d'un HEARTBEAT ACK valide
  - Transmission de données réussie avec accusé de réception

8.2.4. Réponse à la défaillance de chemin​

Lorsque le chemin principal échoue :

1. Marquer le chemin comme inactif
2. Sélectionner un autre chemin actif comme nouveau chemin principal
3. Retransmettre les données non acquittées sur le nouveau chemin principal
4. Continuer à surveiller le chemin inactif avec HEARTBEAT

Stratégie de sélection de chemin :

  • Privilégier les chemins récemment réussis
  • Considérer le RTT et l'état de congestion du chemin
  • Alterner les chemins disponibles pour répartir la charge (optionnel)

8.3. Pulsation de chemin (Path Heartbeat)​

Le mécanisme HEARTBEAT est utilisé pour surveiller activement l'accessibilité des adresses de destination.

8.3.1. Règles d'envoi HEARTBEAT​

Un point de terminaison DEVRAIT envoyer périodiquement HEARTBEAT à chaque adresse de destination inactive :

Intervalle d'envoi :

HB.interval : Valeur par défaut recommandée de 30 secondes
Plage configurable : 1 seconde à plusieurs minutes

Conditions d'envoi :

  • La destination n'a pas envoyé de données dans le temps HB.interval
  • La destination est actuellement inactive (sonder plus fréquemment)

Contenu HEARTBEAT :

- Heartbeat Information TLV
  - Horodatage d'envoi
  - Informations sur l'adresse de destination
  - Optionnel : Informations spécifiques à l'expéditeur

8.3.2. Traitement HEARTBEAT ACK​

Lors de la réception de HEARTBEAT ACK :

1. Calculer RTT = temps actuel - horodatage d'envoi
2. Mettre à jour le RTO de la destination
3. Marquer la destination comme active
4. Réinitialiser le compteur d'erreurs de chemin à 0

8.3.3. Traitement du délai d'attente HEARTBEAT​

Si HEARTBEAT ACK n'est pas reçu dans le temps RTO :

1. Incrémenter le compteur d'erreurs de chemin
2. Si nombre d'erreurs >= Path.Max.Retrans :
   - Marquer le chemin comme inactif
   - Si chemin principal, sélectionner un nouveau chemin principal
3. Continuer à envoyer HEARTBEAT pour sonder la récupération

8.3.4. HEARTBEAT à la demande​

Outre les HEARTBEAT périodiques, un point de terminaison PEUT envoyer des HEARTBEAT à la demande lorsque :

  • Réception de la mise à jour de la liste d'adresses du pair
  • Suspicion que le chemin a pu récupérer
  • Besoin de vérifier rapidement l'accessibilité du chemin

8.4. Gestion des paquets "Out of the Blue" (Handle "Out of the Blue" Packets)​

Les paquets "Out of the Blue" sont des paquets SCTP reçus par un point de terminaison qui ne correspondent à aucune association connue.

8.4.1. Identification des paquets Out of the Blue​

Un paquet est considéré comme "Out of the Blue" lorsque :

  1. La balise de vérification ne correspond à aucune association existante
  2. L'adresse et le port source ne correspondent à aucune association existante
  3. Le port de destination correspond mais aucune association correspondante n'existe

8.4.2. Règles de gestion des paquets Out of the Blue​

Réception d'un chunk INIT inattendu :

Si le point de terminaison est dans l'état CLOSED :
  - Répondre avec INIT ACK selon la procédure normale
Sinon :
  - Rejeter silencieusement

Réception d'un chunk ABORT inattendu :

- Si le bit T est défini :
  - Vérifier en utilisant la balise de vérification du paquet
- Accepter silencieusement et rejeter

Réception d'un chunk SHUTDOWN COMPLETE inattendu :

- Vérifier le bit T
- Accepter silencieusement et rejeter

Réception d'autres chunks inattendus :

Envoyer un chunk ABORT :
  - Utiliser la balise de vérification du paquet reçu
  - Cause d'erreur : "Out of the Blue"
  - Bit T défini à 1

8.4.3. Envoi de chunk ABORT​

Lors de l'envoi d'un chunk ABORT en réponse à un paquet Out of the Blue :

Format du chunk ABORT :
  - Chunk Type = 6
  - T bit = 1
  - Verification Tag = Balise de vérification du paquet reçu
  - Cause d'erreur (optionnelle) :
    - Cause Code = 8 (Out of the Blue)
    - Cause Info = Copie du paquet reçu

8.4.4. Considérations de sécurité​

Mesures de sécurité lors de la gestion des paquets Out of the Blue :

  1. Limitation du taux de réponse : Éviter d'être utilisé pour des attaques par amplification
  2. Vérification de l'adresse source : Valider la légitimité de l'adresse source si possible
  3. Journalisation des anomalies : Enregistrer les paquets Out of the Blue fréquents pour détecter les attaques

8.5. Utilisation de la balise de vérification (Verification Tag Usage)​

La balise de vérification est le mécanisme de sécurité clé de SCTP pour empêcher la falsification et les attaques par injection de paquets.

8.5.1. Règles de balise de vérification​

Lors de l'envoi de paquets :

- Utiliser l'Initiate Tag fourni par le pair dans INIT ou INIT ACK
- Comme champ Verification Tag dans l'en-tête commun SCTP

Lors de la réception de paquets :

- Vérifier que la balise de vérification correspond à la balise locale
- Rejeter le paquet s'il ne correspond pas (sauf cas spéciaux)

Cas spéciaux :

  • Chunk INIT : La balise de vérification doit être 0
  • SHUTDOWN COMPLETE et ABORT : Peut utiliser le bit T pour indiquer quelle balise utiliser

8.5.2. Gestion des échecs de vérification​

Lors de la réception d'un paquet avec une balise de vérification incorrecte :

Si chunk INIT :
  - Gérer selon la section 8.4
Si ABORT ou SHUTDOWN COMPLETE avec bit T=1 :
  - Vérifier en utilisant la balise de vérification du paquet
Sinon :
  - Rejeter silencieusement le paquet
  - Ne pas envoyer de réponse

Résumé​

Les mécanismes de gestion des pannes de SCTP fournissent une robustesse à plusieurs niveaux :

  1. Redondance multi-chemins : La défaillance d'un seul chemin n'affecte pas l'association
  2. Surveillance active : Le mécanisme HEARTBEAT détecte activement l'état des chemins
  3. Basculement rapide : Bascule immédiatement vers le chemin de secours en cas de détection de défaillance
  4. Mécanisme de défense : La balise de vérification empêche l'injection de paquets malveillants
  5. Seuils configurables : Permet d'ajuster la sensibilité de détection de défaillance en fonction des conditions réseau

Ces mécanismes garantissent ensemble la fiabilité et la disponibilité de SCTP dans divers scénarios de défaillance réseau.

Dernière mise à jour le