Zum Hauptinhalt springen

8. Fehlerverwaltung (Fault Management)

SCTP bietet robuste Fehlererkennungs- und Wiederherstellungsmechanismen, um zuverlässige Kommunikation unter Netzwerkfehlerbedingungen zu gewährleisten.

8.1. Endpunkt-Fehlererkennung (Endpoint Failure Detection)​

SCTP-Endpunkte müssen in der Lage sein, den vollständigen Ausfall ihres Peer-Endpunkts zu erkennen.

8.1.1. Fehlerzählung auf Assoziationsebene​

Jede SCTP-Assoziation verwaltet einen Assoziationsfehlerzähler (Association Error Counter):

  • Wenn der Fehlerzähler einer Zieladresse den Schwellenwert erreicht, gilt die Assoziation als fehlgeschlagen
  • Wenn die Assoziation fehlschlägt, SOLLTE der Endpunkt dies der oberen Schicht melden

8.1.2. Endpunkt-Fehlerbedingungen​

Ein Endpunkt gilt als ausgefallen, wenn:

  1. Alle Zieladressen als inaktiv markiert sind
  2. Die Gesamtfehlerzahl der Assoziation den Schwellenwert Association.Max.Retrans überschreitet

Association.Max.Retrans: Empfohlener Standardwert sind 10 Neuübertragungsversuche.

8.1.3. Fehlerreaktion​

Wenn ein Endpunktfehler erkannt wird:

1. Senden neuer Daten an diesen Endpunkt stoppen
2. Assoziationsfehler der oberen Schicht melden
3. Transmission Control Block (TCB) zerstören
4. Optional: ABORT-Chunk senden, um Peer zu benachrichtigen

8.2. Pfadfehlererkennung (Path Failure Detection)​

SCTP kann Ausfälle einzelner Transportpfade erkennen, ohne die gesamte Assoziation zu beeinträchtigen (wenn andere aktive Pfade verfügbar sind).

8.2.1. Fehlerzählung auf Pfadebene​

Jede Ziel-Transportadresse verwaltet einen Pfadfehlerzähler (Path Error Counter):

  • Bei jedem Übertragungsfehler erhöht
  • Bei erfolgreicher Übertragung oder Empfang von HEARTBEAT ACK auf 0 zurückgesetzt

8.2.2. Pfadfehlerbedingungen​

Ein Pfad gilt als inaktiv, wenn:

  1. Aufeinanderfolgende Übertragungsfehler Path.Max.Retrans erreichen
  2. Aufeinanderfolgende HEARTBEAT-Fehler Path.Max.Retrans erreichen

Path.Max.Retrans: Empfohlener Standardwert sind 5 Neuübertragungsversuche.

8.2.3. Pfadzustandsverwaltung​

Pfadzustände:

  • Active (Aktiv): Pfad verfügbar für Datenübertragung
  • Inactive (Inaktiv): Pfad vorübergehend nicht verfügbar

Zustandsübergänge:

Active -> Inactive: 
  - Aufeinanderfolgende Fehler erreichen Path.Max.Retrans

Inactive -> Active:
  - Gültigen HEARTBEAT ACK empfangen
  - Erfolgreiche Datenübertragung mit Bestätigung

8.2.4. Pfadfehlerreaktion​

Wenn der primäre Pfad ausfällt:

1. Pfad als inaktiv markieren
2. Einen anderen aktiven Pfad als neuen primären Pfad auswählen
3. Unbestätigte Daten auf neuem primären Pfad neu übertragen
4. Inaktiven Pfad weiterhin mit HEARTBEAT überwachen

Pfadauswahlstrategie:

  • Kürzlich erfolgreiche Pfade bevorzugen
  • RTT und Stauungszustand des Pfads berücksichtigen
  • Verfügbare Pfade im Round-Robin-Verfahren zur Lastverteilung (optional)

8.3. Pfad-Heartbeat (Path Heartbeat)​

Der HEARTBEAT-Mechanismus wird verwendet, um die Erreichbarkeit von Zieladressen aktiv zu überwachen.

8.3.1. HEARTBEAT-Senderegeln​

Ein Endpunkt SOLLTE periodisch HEARTBEAT an jede inaktive Zieladresse senden:

Sendeintervall:

HB.interval: Empfohlener Standardwert sind 30 Sekunden
Konfigurierbarer Bereich: 1 Sekunde bis mehrere Minuten

Sendebedingungen:

  • Ziel hat innerhalb der HB.interval-Zeit keine Daten gesendet
  • Ziel ist derzeit inaktiv (häufiger prüfen)

HEARTBEAT-Inhalt:

- Heartbeat Information TLV
  - Sendezeitstempel
  - Zieladressinformationen
  - Optional: Senderspezifische Informationen

8.3.2. HEARTBEAT ACK-Verarbeitung​

Beim Empfang von HEARTBEAT ACK:

1. RTT berechnen = aktuelle Zeit - Sendezeitstempel
2. RTO des Ziels aktualisieren
3. Ziel als aktiv markieren
4. Pfadfehlerzähler auf 0 zurücksetzen

8.3.3. HEARTBEAT-Timeout-Verarbeitung​

Wenn HEARTBEAT ACK nicht innerhalb der RTO-Zeit empfangen wird:

1. Pfadfehlerzähler erhöhen
2. Wenn Fehleranzahl >= Path.Max.Retrans:
   - Pfad als inaktiv markieren
   - Wenn primärer Pfad, neuen primären Pfad auswählen
3. HEARTBEAT weiter senden, um Wiederherstellung zu prüfen

8.3.4. On-Demand-HEARTBEAT​

Zusätzlich zu periodischen HEARTBEATs KANN ein Endpunkt On-Demand-HEARTBEAT senden, wenn:

  • Aktualisierung der Adressliste des Peers empfangen
  • Verdacht, dass Pfad wiederhergestellt sein könnte
  • Schnelle Überprüfung der Pfaderreichbarkeit erforderlich

8.4. Behandlung von "Out of the Blue"-Paketen (Handle "Out of the Blue" Packets)​

"Out of the Blue"-Pakete sind SCTP-Pakete, die von einem Endpunkt empfangen werden und keiner bekannten Assoziation entsprechen.

8.4.1. Identifizierung von Out of the Blue-Paketen​

Ein Paket gilt als "Out of the Blue", wenn:

  1. Verification Tag keiner vorhandenen Assoziation entspricht
  2. Quelladresse und Port keiner vorhandenen Assoziation entsprechen
  3. Zielport stimmt überein, aber keine entsprechende Assoziation existiert

8.4.2. Behandlungsregeln für Out of the Blue-Pakete​

Empfang eines unerwarteten INIT-Chunks:

Wenn Endpunkt im CLOSED-Zustand ist:
  - Mit INIT ACK gemäß normaler Prozedur antworten
Sonst:
  - Stillschweigend verwerfen

Empfang eines unerwarteten ABORT-Chunks:

- Wenn T-Bit gesetzt ist:
  - Mit Verification Tag des Pakets verifizieren
- Stillschweigend akzeptieren und verwerfen

Empfang eines unerwarteten SHUTDOWN COMPLETE-Chunks:

- T-Bit verifizieren
- Stillschweigend akzeptieren und verwerfen

Empfang anderer unerwarteter Chunks:

ABORT-Chunk senden:
  - Verification Tag des empfangenen Pakets verwenden
  - Fehlerursache: "Out of the Blue"
  - T-Bit auf 1 setzen

8.4.3. ABORT-Chunk-Senden​

Beim Senden eines ABORT-Chunks als Antwort auf ein Out of the Blue-Paket:

ABORT-Chunk-Format:
  - Chunk Type = 6
  - T bit = 1
  - Verification Tag = Verification Tag des empfangenen Pakets
  - Fehlerursache (optional):
    - Cause Code = 8 (Out of the Blue)
    - Cause Info = Kopie des empfangenen Pakets

8.4.4. Sicherheitsüberlegungen​

Sicherheitsmaßnahmen bei der Behandlung von Out of the Blue-Paketen:

  1. Antwortrate begrenzen: Vermeidung der Verwendung für Amplifikationsangriffe
  2. Quelladresse verifizieren: Legitimität der Quelladresse validieren, wenn möglich
  3. Anomalien protokollieren: Häufige Out of the Blue-Pakete protokollieren, um Angriffe zu erkennen

8.5. Verification Tag-Verwendung (Verification Tag Usage)​

Der Verification Tag ist SCTPs wichtiger Sicherheitsmechanismus zur Verhinderung von Paketfälschung und Injektionsangriffen.

8.5.1. Verification Tag-Regeln​

Beim Senden von Paketen:

- Initiate Tag verwenden, der vom Peer in INIT oder INIT ACK bereitgestellt wurde
- Als Verification Tag-Feld im SCTP-Common-Header

Beim Empfangen von Paketen:

- Verifizieren, dass Verification Tag mit lokalem Tag übereinstimmt
- Paket verwerfen, wenn nicht übereinstimmend (außer Sonderfälle)

Sonderfälle:

  • INIT-Chunk: Verification Tag muss 0 sein
  • SHUTDOWN COMPLETE und ABORT: Kann T-Bit verwenden, um anzugeben, welcher Tag zu verwenden ist

8.5.2. Verifikationsfehlbehandlung​

Beim Empfang eines Pakets mit falschem Verification Tag:

Wenn INIT-Chunk:
  - Gemäß Abschnitt 8.4 behandeln
Wenn ABORT oder SHUTDOWN COMPLETE mit T-Bit=1:
  - Mit Verification Tag aus Paket verifizieren
Sonst:
  - Paket stillschweigend verwerfen
  - Keine Antwort senden

Zusammenfassung​

SCTPs Fehlerverwaltungsmechanismen bieten mehrschichtige Robustheit:

  1. Multi-Path-Redundanz: Ausfall eines einzelnen Pfads beeinträchtigt Assoziation nicht
  2. Aktive Überwachung: HEARTBEAT-Mechanismus erkennt Pfadzustand aktiv
  3. Schnelles Failover: Wechselt sofort zu Backup-Pfad bei Fehlererkennung
  4. Verteidigungsmechanismus: Verification Tag verhindert böswillige Paketinjektion
  5. Konfigurierbare Schwellenwerte: Ermöglicht Anpassung der Fehlererkennungsempfindlichkeit basierend auf Netzwerkbedingungen

Diese Mechanismen gewährleisten gemeinsam SCTPs Zuverlässigkeit und Verfügbarkeit unter verschiedenen Netzwerkfehlerszenarien.

Letztes Update am