8. Gestione dei guasti (Fault Management)
SCTP fornisce meccanismi robusti di rilevamento e recupero dei guasti per garantire comunicazioni affidabili in condizioni di guasto della rete.
8.1. Rilevamento del guasto dell'endpoint (Endpoint Failure Detection)
Gli endpoint SCTP devono essere in grado di rilevare il guasto completo del loro endpoint peer.
8.1.1. Conteggio degli errori a livello di associazione
Ogni associazione SCTP mantiene un contatore di errori dell'associazione (Association Error Counter):
- Quando il contatore di errori di un indirizzo di destinazione raggiunge la soglia, l'associazione è considerata fallita
- Quando l'associazione fallisce, l'endpoint DOVREBBE segnalarlo al livello superiore
8.1.2. Condizioni di guasto dell'endpoint
Un endpoint è considerato fallito quando:
- Tutti gli indirizzi di destinazione sono contrassegnati come inattivi
- Il conteggio totale degli errori dell'associazione supera la soglia Association.Max.Retrans
Association.Max.Retrans: Valore predefinito raccomandato di 10 tentativi di ritrasmissione.
8.1.3. Risposta al guasto
Quando viene rilevato un guasto dell'endpoint:
1. Interrompere l'invio di nuovi dati a quell'endpoint
2. Segnalare il fallimento dell'associazione al livello superiore
3. Distruggere il blocco di controllo della trasmissione (TCB)
4. Opzionale: Inviare chunk ABORT per notificare il peer
8.2. Rilevamento del guasto del percorso (Path Failure Detection)
SCTP può rilevare guasti di singoli percorsi di trasporto senza influenzare l'intera associazione (se altri percorsi attivi sono disponibili).
8.2.1. Conteggio degli errori a livello di percorso
Ogni indirizzo di trasporto di destinazione mantiene un contatore di errori del percorso (Path Error Counter):
- Incrementato ad ogni errore di trasmissione
- Reimpostato a 0 in caso di trasmissione riuscita o ricezione di HEARTBEAT ACK
8.2.2. Condizioni di guasto del percorso
Un percorso è considerato inattivo quando:
- Gli errori di trasmissione consecutivi raggiungono Path.Max.Retrans
- Gli errori HEARTBEAT consecutivi raggiungono Path.Max.Retrans
Path.Max.Retrans: Valore predefinito raccomandato di 5 tentativi di ritrasmissione.
8.2.3. Gestione dello stato del percorso
Stati del percorso:
- Active (Attivo): Percorso disponibile per la trasmissione dati
- Inactive (Inattivo): Percorso temporaneamente non disponibile
Transizioni di stato:
Active -> Inactive:
- Gli errori consecutivi raggiungono Path.Max.Retrans
Inactive -> Active:
- Ricezione di HEARTBEAT ACK valido
- Trasmissione dati riuscita con riconoscimento
8.2.4. Risposta al guasto del percorso
Quando il percorso primario fallisce:
1. Contrassegnare il percorso come inattivo
2. Selezionare un altro percorso attivo come nuovo percorso primario
3. Ritrasmettere i dati non riconosciuti sul nuovo percorso primario
4. Continuare a monitorare il percorso inattivo con HEARTBEAT
Strategia di selezione del percorso:
- Preferire percorsi recentemente riusciti
- Considerare RTT e stato di congestione del percorso
- Alternare percorsi disponibili per distribuire il carico (opzionale)
8.3. Heartbeat del percorso (Path Heartbeat)
Il meccanismo HEARTBEAT viene utilizzato per monitorare attivamente la raggiungibilità degli indirizzi di destinazione.
8.3.1. Regole di invio HEARTBEAT
Un endpoint DOVREBBE inviare periodicamente HEARTBEAT a ciascun indirizzo di destinazione inattivo:
Intervallo di invio:
HB.interval: Valore predefinito raccomandato di 30 secondi
Intervallo configurabile: da 1 secondo a diversi minuti
Condizioni di invio:
- La destinazione non ha inviato dati entro il tempo HB.interval
- La destinazione è attualmente inattiva (sondare più frequentemente)
Contenuto HEARTBEAT:
- Heartbeat Information TLV
- Timestamp di invio
- Informazioni sull'indirizzo di destinazione
- Opzionale: Informazioni specifiche del mittente
8.3.2. Elaborazione HEARTBEAT ACK
Alla ricezione di HEARTBEAT ACK:
1. Calcolare RTT = tempo corrente - timestamp di invio
2. Aggiornare l'RTO della destinazione
3. Contrassegnare la destinazione come attiva
4. Reimpostare il contatore di errori del percorso a 0
8.3.3. Elaborazione del timeout HEARTBEAT
Se HEARTBEAT ACK non viene ricevuto entro il tempo RTO:
1. Incrementare il contatore di errori del percorso
2. Se conteggio errori >= Path.Max.Retrans:
- Contrassegnare il percorso come inattivo
- Se percorso primario, selezionare nuovo percorso primario
3. Continuare a inviare HEARTBEAT per sondare il recupero
8.3.4. HEARTBEAT su richiesta
Oltre ai HEARTBEAT periodici, un endpoint PUÒ inviare HEARTBEAT su richiesta quando:
- Ricezione dell'aggiornamento dell'elenco indirizzi del peer
- Sospetto che il percorso possa essere stato recuperato
- Necessità di verifica rapida della raggiungibilità del percorso
8.4. Gestione dei pacchetti "Out of the Blue" (Handle "Out of the Blue" Packets)
I pacchetti "Out of the Blue" sono pacchetti SCTP ricevuti da un endpoint che non corrispondono a nessuna associazione nota.
8.4.1. Identificazione dei pacchetti Out of the Blue
Un pacchetto è considerato "Out of the Blue" quando:
- Il tag di verifica non corrisponde a nessuna associazione esistente
- L'indirizzo e la porta di origine non corrispondono a nessuna associazione esistente
- La porta di destinazione corrisponde ma non esiste un'associazione corrispondente
8.4.2. Regole di gestione dei pacchetti Out of the Blue
Ricezione di chunk INIT imprevisto:
Se l'endpoint è nello stato CLOSED:
- Rispondere con INIT ACK secondo la procedura normale
Altrimenti:
- Scartare silenziosamente
Ricezione di chunk ABORT imprevisto:
- Se il bit T è impostato:
- Verificare utilizzando il tag di verifica del pacchetto
- Accettare silenziosamente e scartare
Ricezione di chunk SHUTDOWN COMPLETE imprevisto:
- Verificare il bit T
- Accettare silenziosamente e scartare
Ricezione di altri chunk imprevisti:
Inviare chunk ABORT:
- Utilizzare il tag di verifica del pacchetto ricevuto
- Causa di errore: "Out of the Blue"
- Bit T impostato a 1
8.4.3. Invio di chunk ABORT
Quando si invia un chunk ABORT in risposta a un pacchetto Out of the Blue:
Formato chunk ABORT:
- Chunk Type = 6
- T bit = 1
- Verification Tag = Tag di verifica del pacchetto ricevuto
- Causa di errore (opzionale):
- Cause Code = 8 (Out of the Blue)
- Cause Info = Copia del pacchetto ricevuto
8.4.4. Considerazioni sulla sicurezza
Misure di sicurezza nella gestione dei pacchetti Out of the Blue:
- Limitazione del tasso di risposta: Evitare di essere utilizzati per attacchi di amplificazione
- Verifica dell'indirizzo di origine: Convalidare la legittimità dell'indirizzo di origine quando possibile
- Registrazione delle anomalie: Registrare pacchetti Out of the Blue frequenti per rilevare attacchi
8.5. Utilizzo del tag di verifica (Verification Tag Usage)
Il tag di verifica è il meccanismo di sicurezza chiave di SCTP per prevenire la falsificazione e gli attacchi di iniezione di pacchetti.
8.5.1. Regole del tag di verifica
Quando si inviano pacchetti:
- Utilizzare l'Initiate Tag fornito dal peer in INIT o INIT ACK
- Come campo Verification Tag nell'intestazione comune SCTP
Quando si ricevono pacchetti:
- Verificare che il tag di verifica corrisponda al tag locale
- Scartare il pacchetto se non corrisponde (eccetto casi speciali)
Casi speciali:
- Chunk INIT: Il tag di verifica deve essere 0
- SHUTDOWN COMPLETE e ABORT: Possono utilizzare il bit T per indicare quale tag utilizzare
8.5.2. Gestione del fallimento della verifica
Quando si riceve un pacchetto con tag di verifica errato:
Se chunk INIT:
- Gestire secondo la sezione 8.4
Se ABORT o SHUTDOWN COMPLETE con bit T=1:
- Verificare utilizzando il tag di verifica dal pacchetto
Altrimenti:
- Scartare silenziosamente il pacchetto
- Non inviare alcuna risposta
Riepilogo
I meccanismi di gestione dei guasti di SCTP forniscono robustezza multilivello:
- Ridondanza multi-percorso: Il guasto di un singolo percorso non influenza l'associazione
- Monitoraggio attivo: Il meccanismo HEARTBEAT rileva attivamente lo stato del percorso
- Failover rapido: Commuta immediatamente al percorso di backup al rilevamento del guasto
- Meccanismo di difesa: Il tag di verifica previene l'iniezione di pacchetti malevoli
- Soglie configurabili: Consente di regolare la sensibilità di rilevamento dei guasti in base alle condizioni di rete
Questi meccanismi insieme garantiscono l'affidabilità e la disponibilità di SCTP in vari scenari di guasto della rete.