Passa al contenuto principale

5. Inizializzazione dell'associazione (Association Initialization)

5.1. Stabilimento normale di un'associazione (Normal Establishment of an Association)​

Un endpoint SCTP A che desidera stabilire un'associazione con un altro endpoint SCTP Z DEVE inviare un chunk INIT. Se Z accetta l'associazione, DEVE rispondere con un pacchetto contenente un chunk INIT ACK. Lo stabilimento dell'associazione viene ulteriormente discusso di seguito.

5.1.1. Gestione dei parametri di stream (Handle Stream Parameters)​

Nel chunk INIT o INIT ACK, il mittente PUÒ richiedere al destinatario di utilizzare tipi di indirizzo specifici includendo un parametro "Tipi di indirizzo supportati (Supported Address Types)" nella sezione dei parametri opzionali/a lunghezza variabile. Il mittente DOVREBBE includere questo parametro se non supporta tutti i tipi di indirizzo o desidera limitare il suo peer all'uso di determinati tipi di indirizzo.

Un destinatario di un INIT o INIT ACK DEVE inviare tutte le comunicazioni successive utilizzando uno dei tipi di indirizzo specificati nell'elenco o il tipo di indirizzo a cui è stato inviato INIT o INIT ACK (se non elencato).

Se il destinatario non supporta o desidera evitare qualsiasi tipo di indirizzo previsto dal mittente, PUÒ interrompere l'associazione e DOVREBBE inviare un errore "Tipo di indirizzo non supportato (Unsupported Address Type)".

Nota: Se un INIT o INIT ACK contiene un parametro "Tipi di indirizzo supportati (Supported Address Types)", il destinatario DEVE utilizzare solo uno dei tipi di indirizzo trovati nel parametro o il tipo di indirizzo a cui è stato inviato INIT/INIT ACK, anche se il destinatario è in grado di utilizzare altri tipi di indirizzo.

In un chunk INIT o INIT ACK, il mittente indica la sua capacità di stream attraverso i parametri "Numero di stream in uscita (Number of Outbound Streams, OS)" e "Numero di stream in entrata (Number of Inbound Streams, MIS)" che include.

Il destinatario DOVREBBE utilizzare il valore che il mittente indica nel campo OS dell'INIT o INIT ACK come numero massimo dei propri stream in entrata (cioè, il MIS del destinatario). Il mittente utilizza il parametro MIS per limitare il numero di stream sui quali il peer può inviare messaggi utente.

Nell'INIT o INIT ACK, il numero di stream in uscita (OS) e il numero di stream in entrata (MIS) del mittente NON DEVONO essere 0.

Se un destinatario riceve un INIT o INIT ACK in cui il valore OS o MIS è 0, il destinatario DOVREBBE interrompere l'associazione, inviare un chunk ABORT e PUÒ segnalare l'errore "Parametro obbligatorio non valido (Invalid Mandatory Parameter)".

Il destinatario DEVE anche limitare l'uso degli stream in uscita al numero effettivo ricevuto nel campo MIS dell'INIT o INIT ACK. In altre parole, dopo che l'associazione è stata stabilita, un endpoint utilizzerà quanto segue:

Numero di stream in uscita per inviare messaggi utente = 
    minimum(OS locale, MIS del peer)

Numero di stream in entrata per ricevere messaggi utente = 
    minimum(MIS locale, OS del peer)

5.1.2. Gestione dei parametri di indirizzo (Handle Address Parameters)​

Durante l'inizializzazione (prima di inviare INIT o INIT ACK), il mittente DOVREBBE includere tutti i suoi indirizzi nell'INIT o INIT ACK utilizzando il parametro di indirizzo IPv4 opzionale e/o il parametro di indirizzo IPv6. L'omissione di questo parametro opzionale indica che l'endpoint ha un solo indirizzo, l'indirizzo di origine utilizzato per inviare INIT o INIT ACK.

Prima di inviare un chunk INIT, un endpoint DOVREBBE sempre entrare nello stato COOKIE-WAIT.

Nota: L'assenza di indirizzi in un chunk INIT non significa che l'endpoint mittente non accetti altri indirizzi. Al contrario, l'assenza di indirizzi indica che il mittente non desidera essere ascoltato, ma accetterà messaggi inviati da uno qualsiasi degli indirizzi del suo peer.

Se il destinatario non supporta nessuno dei tipi di indirizzo forniti dal mittente nell'INIT o INIT ACK, DOVREBBE interrompere l'associazione e PUÒ inviare una causa di errore "Tipo di indirizzo non supportato (Unsupported Address Type)".

Un destinatario di un INIT o INIT ACK DEVE registrare tutte le informazioni sugli indirizzi fornite (comunque ottenute, incluso dall'intestazione IP, dal parametro di indirizzo IPv4 e/o dal parametro di indirizzo IPv6) e utilizzare tali informazioni per determinare il suo insieme di indirizzi di trasporto.

Se il mittente include un parametro "Indirizzo nome host (Host Name Address)", il destinatario DEVE immediatamente inviare un chunk ABORT e PUÒ includere una causa di errore "Indirizzo non risolvibile (Unresolvable Address)".

Nota: L'uso del parametro "Indirizzo nome host (Host Name Address)" è deprecato. Un destinatario DEVE ignorare qualsiasi parametro "Indirizzo nome host (Host Name Address)" in un INIT o INIT ACK e DOVREBBE inviare un chunk ABORT in risposta.

Un endpoint che invia un INIT ACK dovrebbe creare uno State Cookie e posizionarlo nel parametro State Cookie dell'INIT ACK. Vedere la sezione 5.1.3 per l'utilizzo dello State Cookie.

Lo State Cookie dovrebbe contenere le seguenti informazioni minime richieste:

  • Informazioni ottenute dal chunk INIT ricevuto (incluso l'Initiate Tag e i parametri opzionali/a lunghezza variabile)
  • Il momento in cui è stato creato lo State Cookie
  • Una durata di vita (il tempo in cui il cookie è valido)
  • Un metodo per autenticare l'integrità e l'autenticità dello State Cookie (ad esempio, un codice di autenticazione del messaggio (MAC))

Nota di implementazione: Lo State Cookie può essere utilizzato per memorizzare informazioni aggiuntive sullo stato dell'associazione in fase di stabilimento. Ciò consente a un endpoint di posticipare l'allocazione delle risorse (TCB) durante lo stabilimento dell'associazione. Questa ottimizzazione è chiamata "Approccio Cookie (Cookie Approach)" e può prevenire semplici attacchi di denial-of-service.

Un'implementazione che invia un INIT ACK DOVREBBE rendere lo State Cookie sufficientemente robusto per proteggere contro un attaccante che indovina State Cookie validi. Una tecnica raccomandata consiste nell'includere nello State Cookie:

  • Un nonce casuale (unico per istanza di associazione)
  • Un timestamp
  • L'indirizzo di origine del peer
  • La porta di origine del peer
  • L'indirizzo di destinazione locale
  • La porta di destinazione locale
  • Un MAC che copre tutti i campi sopra indicati

La chiave segreta necessaria per creare questo MAC DOVREBBE essere creata quando lo stack SCTP è inizializzato e dovrebbe essere aggiornata periodicamente. Questa chiave DEVE essere mantenuta segreta a chiunque al di fuori delle parti comunicanti.

L'inclusione di questi valori nel parametro State Cookie dell'INIT ACK consente la validazione dello State Cookie restituito nel chunk COOKIE ECHO. Il processo di validazione è descritto nella sezione 5.1.4.

Inoltre, il mittente PUÒ includere qualsiasi altro dato necessario per generare lo State Cookie utilizzato per convalidare il cookie restituito in COOKIE ECHO e per stabilire l'associazione.

Nota: Il calcolo del MAC DEVE includere il timestamp per garantire che un cookie riprodotto non possa essere utilizzato come strumento di attacco denial-of-service.

Quando un endpoint riceve uno State Cookie in un chunk COOKIE ECHO, DEVE validare quel cookie secondo quanto segue:

  1. Verificare che il MAC dello State Cookie sia valido. Se il MAC non è valido, scartare silenziosamente il pacchetto.

  2. Verificare che lo State Cookie non sia obsoleto. Se lo State Cookie è obsoleto, l'endpoint DOVREBBE inviare un chunk ERROR con il codice di causa impostato su "Stale Cookie Error" e scartare silenziosamente il pacchetto. L'obsolescenza dello State Cookie può essere regolata utilizzando il parametro "Cookie Preservative". Vedere la sezione 5.1.3.

  3. Verificare che l'indirizzo di origine e i numeri di porta corrispondano ai valori memorizzati nello State Cookie. Se non corrispondono, scartare silenziosamente il pacchetto.

Se lo State Cookie è valido, l'endpoint DOVREBBE creare un'associazione con quel peer e inviare un chunk COOKIE ACK al mittente. L'endpoint dovrebbe quindi spostare quell'associazione nello stato ESTABLISHED.

Un'implementazione DEVE proteggere l'integrità e l'autenticità dello State Cookie utilizzando una tecnica come descritta di seguito o una tecnica equivalente.

La tecnica raccomandata consiste nell'includere un codice di autenticazione del messaggio (MAC) nello State Cookie. Il MAC DOVREBBE essere calcolato utilizzando una chiave segreta nota al mittente ma sconosciuta a qualsiasi potenziale attaccante.

L'algoritmo MAC DOVREBBE essere almeno altrettanto sicuro di HMAC-SHA-1 come definito in [RFC2104] e [RFC3174].

Per creare e verificare il MAC, è necessaria una chiave segreta. Questa chiave segreta DOVREBBE essere modificata periodicamente (ad esempio, ogni poche ore) per limitare la capacità di un attaccante di dedurre la chiave osservando il traffico legittimo.

Durante i cambiamenti della chiave segreta, un'implementazione DOVREBBE mantenere la vecchia chiave per un periodo di tempo (almeno il doppio della durata del cookie) per consentire la validazione dei cookie creati con la vecchia chiave.

5.1.6. Un esempio di stabilimento normale dell'associazione (An Example of Normal Association Establishment)​

Nel caso più semplice, lo stabilimento normale dell'associazione di un endpoint A che richiede di avviare un'associazione verso l'endpoint Z sarebbe come segue:

Endpoint A                                     Endpoint Z

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

A questo punto, l'associazione è ESTABLISHED su entrambi i lati.

Passaggi dettagliati:

A) L'endpoint A invia un chunk INIT all'endpoint Z, indicando il suo desiderio di stabilire un'associazione. Nel chunk INIT, l'endpoint A DEVE fornire il suo Verification Tag (da utilizzare in tutti i pacchetti provenienti da Z), il TSN iniziale che supporta, il numero di stream in uscita (OS), il numero massimo di stream in entrata (MIS) e i suoi altri indirizzi di trasporto (se presenti).

B) Dopo aver ricevuto l'INIT, l'endpoint Z DOVREBBE rispondere con un chunk INIT ACK. Nell'INIT ACK, Z DEVE fornire il suo Verification Tag, il suo TSN iniziale, il suo OS, MIS e i suoi indirizzi di trasporto (se applicabile). Inoltre, Z DEVE creare uno State Cookie e includerlo nell'INIT ACK.

C) Dopo aver ricevuto l'INIT ACK contenente lo State Cookie, l'endpoint A DOVREBBE rispondere con un chunk COOKIE ECHO. Il chunk COOKIE ECHO DEVE contenere lo State Cookie ricevuto nell'INIT ACK. Inoltre, l'endpoint A PUÒ inviare dati utente raggruppati con il COOKIE ECHO nello stesso pacchetto.

D) Dopo aver ricevuto il COOKIE ECHO, l'endpoint Z convaliderà lo State Cookie. Se valido, Z creerà l'associazione e risponderà con un chunk COOKIE ACK. Inoltre, Z PUÒ inviare dati utente raggruppati con il COOKIE ACK nello stesso pacchetto.

E) Dopo aver ricevuto il COOKIE ACK, l'endpoint A cambierà il suo stato di associazione da COOKIE-ECHOED a ESTABLISHED. A può ora inviare e ricevere dati utente sull'associazione stabilita.

In qualsiasi momento durante la vita di un'associazione, un endpoint può ricevere chunk INIT, INIT ACK, COOKIE ECHO o COOKIE ACK imprevisti o duplicati. Questa sezione descrive come gestire questi chunk.

5.2.1. INIT ricevuto nello stato CLOSED (INIT Received in CLOSED State)​

Se un endpoint è nello stato CLOSED e riceve un chunk INIT, DOVREBBE rispondere con un INIT ACK come descritto nella sezione 5.1.

Se un endpoint è nello stato COOKIE-WAIT o COOKIE-ECHOED e riceve un chunk INIT il cui Initiate Tag non corrisponde al suo Verification Tag del peer registrato, l'endpoint DOVREBBE scartare il vecchio TCB (se presente) e rispondere con un INIT ACK al nuovo chunk INIT.

Se un endpoint è nello stato COOKIE-WAIT o COOKIE-ECHOED e riceve un chunk INIT il cui Initiate Tag corrisponde al suo Verification Tag del peer registrato, l'endpoint DOVREBBE rispondere con un INIT ACK ma non cambiare il suo stato. Questa situazione può verificarsi quando il peer non ha ricevuto o ha perso l'INIT ACK.

Se un endpoint è nello stato CLOSED o nello stato COOKIE-WAIT e riceve un INIT ACK, l'endpoint DOVREBBE inviare un chunk ABORT e PUÒ includere una causa di errore "Out of the Blue" (vedere la sezione 3.3.10).

Se un endpoint è nello stato COOKIE-WAIT e riceve un INIT ACK il cui campo Initiate Tag non corrisponde al proprio Tag, l'endpoint DOVREBBE entrare nello stato CLOSED, distruggere il TCB e inviare un chunk ABORT.

Questa sezione descrive il comportamento quando un endpoint riceve un chunk COOKIE ECHO in stati diversi da CLOSED e COOKIE-ECHOED.

Nota di implementazione: Un endpoint può ricevere un chunk COOKIE ECHO in qualsiasi momento durante la vita dell'associazione, tipicamente a causa di ritrasmissione del peer o ritardo di rete.

Se un endpoint riceve un chunk COOKIE ECHO e esiste un TCB per la stessa associazione, l'endpoint DOVREBBE gestirlo secondo una delle seguenti azioni:

A) Se lo stato corrente è ESTABLISHED, l'endpoint DOVREBBE scartare silenziosamente il COOKIE ECHO. In alternativa, se il peer include un verification tag errato nel COOKIE ECHO, l'endpoint PUÒ inviare un chunk ABORT.

B) Se lo stato corrente è SHUTDOWN-ACK-SENT, l'endpoint DOVREBBE scartare silenziosamente il COOKIE ECHO.

In tutti gli altri casi, l'endpoint DOVREBBE trattare il COOKIE ECHO come un tentativo di stabilire una nuova associazione secondo le regole della sezione 5.2.4, ma utilizzare qualsiasi informazione nel TCB esistente per ottimizzare il processo di stabilimento dell'associazione.

Se un endpoint riceve un chunk COOKIE ACK al di fuori dello stato COOKIE-ECHOED, DOVREBBE scartare silenziosamente il chunk.

Se un endpoint riceve un chunk ERROR contenente una causa di errore "Stale Cookie" dopo aver inviato un chunk COOKIE ECHO e l'endpoint è nello stato COOKIE-ECHOED, l'endpoint PUÒ tentare di ristabilire l'associazione utilizzando un nuovo chunk INIT.

Se l'endpoint sceglie di riprovare, DOVREBBE includere un parametro "Cookie Preservative" nel nuovo chunk INIT con un valore impostato sul campo Measure of Staleness specificato nell'errore "Stale Cookie" ricevuto.

Se l'endpoint sceglie di non riprovare, DOVREBBE entrare nello stato CLOSED e segnalare il problema al suo livello superiore.

5.3. Altri problemi di inizializzazione (Other Initialization Issues)​

5.3.1. Selezione della porta predefinita (Selection of Default Port)​

Un endpoint SCTP DOVREBBE supportare la ricezione e l'invio di pacchetti SCTP alla porta UDP 9899 (la porta predefinita per l'incapsulamento SCTP su UDP).

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

Un'implementazione DOVREBBE supportare l'uso di indirizzi IPv4 e IPv6 come raccomandato in [RFC4213].

5.3.3. Identificatore di associazione SCTP (SCTP Association Identifier)​

Ogni associazione SCTP è identificata univocamente da una coppia di Verification Tag:

  • Il Verification Tag locale (fornito dal peer nel suo INIT o INIT ACK)
  • Il Verification Tag del peer (inviato nell'INIT o INIT ACK locale)

Questa coppia di Tag viene utilizzata per demultiplexare i pacchetti SCTP ricevuti.

5.4. Verifica del percorso (Path Verification)​

Durante il normale funzionamento, un endpoint SCTP DEVE utilizzare il meccanismo di heartbeat per verificare la raggiungibilità dei percorsi del suo peer.

Durante l'inizializzazione (dopo aver inviato l'INIT ACK), un endpoint DOVREBBE utilizzare il meccanismo di heartbeat per verificare che tutti gli indirizzi ricevuti nell'INIT o INIT ACK siano raggiungibili.

Questa verifica DOVREBBE iniziare immediatamente dopo che l'associazione entra nello stato ESTABLISHED.

Nota di implementazione: Se un endpoint riceve un INIT o INIT ACK contenente più indirizzi IP, DOVREBBE tentare di verificare tutti gli indirizzi forniti inviando HEARTBEAT a ciascun indirizzo.

Gli indirizzi che non riescono a rispondere agli HEARTBEAT durante il processo di verifica DOVREBBERO essere contrassegnati come inattivi e non dovrebbero essere utilizzati nella trasmissione dati normale, a meno che non vengano successivamente dimostrati attivi (tramite HEARTBEAT o trasmissione dati).

Questo capitolo continua...

Per contenuti più dettagliati del capitolo 5 (inclusa la gestione specifica degli errori, i meccanismi di timeout e le considerazioni relative alla sicurezza), consultare il testo completo di RFC 4960.

Ultimo aggiornamento il