Passa al contenuto principale

RFC 5880 - Rilevamento di Inoltro Bidirezionale (BFD)

  • Stato: Proposed Standard
  • Pubblicato: giugno 2010
  • Stream: IETF
  • Errata: Nessun errata

Abstract​

Questo documento descrive un protocollo destinato a rilevare guasti nel percorso bidirezionale tra due motori di inoltro, includendo interfacce, collegamenti dati e, nella misura del possibile, gli stessi motori di inoltro, con una latenza potenzialmente molto bassa. Opera indipendentemente dai media, dai protocolli dati e dai protocolli di routing.

Status of This Memo​

Questo è un documento Standards Track di Internet.

Questo documento è un prodotto dell'Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli Standard Internet sono disponibili nella Sezione 2 di RFC 5741.

Le informazioni sullo stato corrente di questo documento, eventuali errata e come fornire feedback possono essere ottenute presso http://www.rfc-editor.org/info/rfc5880.

Copyright (c) 2010 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

Questo documento è soggetto a BCP 78 e alle Disposizioni Legali dell'IETF Trust relative ai Documenti IETF (http://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i vostri diritti e le restrizioni relative a questo documento. I componenti di codice estratti da questo documento devono includere il testo della Simplified BSD License come descritto nella Sezione 4.e delle Disposizioni Legali del Trust e sono forniti senza garanzia come descritto nella Simplified BSD License.

Contents​

6.7. Authentication (Autenticazione)​

BFD include supporto opzionale per l'autenticazione dei pacchetti di controllo BFD. Quando l'autenticazione è in uso, tutti i pacchetti di controllo BFD DEVONO essere autenticati, e i pacchetti che falliscono la validazione dell'autenticazione DEVONO essere scartati.

L'autenticazione viene eseguita includendo una sezione di autenticazione alla fine del pacchetto di controllo BFD. Il formato della sezione di autenticazione varia in base al tipo di autenticazione in uso, come descritto nelle sezioni 4.2, 4.3 e 4.4.

I tipi di autenticazione definiti in questo documento sono:

  • Type 0: Reserved (Riservato)
  • Type 1: Simple Password (Password semplice)
  • Type 2: Keyed MD5 (MD5 con chiave)
  • Type 3: Meticulous Keyed MD5 (MD5 meticoloso con chiave)
  • Type 4: Keyed SHA1 (SHA1 con chiave)
  • Type 5: Meticulous Keyed SHA1 (SHA1 meticoloso con chiave)
  • Types 6-255: Reserved for future use (Riservati per uso futuro)

I tipi di autenticazione "meticolosi" (Meticulous) forniscono una protezione più forte contro attacchi di riproduzione (replay attacks) rispetto ai tipi non meticolosi, richiedendo che il numero di sequenza sia strettamente incrementale. Le differenze specifiche sono descritte nelle sezioni seguenti.

6.7.1. Enabling and Disabling Authentication (Abilitazione e disabilitazione dell'autenticazione)​

L'autenticazione può essere abilitata o disabilitata dinamicamente durante una sessione BFD. Questo viene realizzato tramite una sequenza di Poll iniziata dal sistema che desidera cambiare lo stato dell'autenticazione.

Per abilitare l'autenticazione, il sistema che la abilita DEVE inviare pacchetti di controllo BFD con il bit Poll (P) impostato e la sezione di autenticazione inclusa (con il bit A impostato). Tutti i pacchetti di controllo BFD successivi inviati da questo sistema DEVONO includere la sezione di autenticazione.

Il sistema che riceve i pacchetti con autenticazione abilitata DEVE rispondere con pacchetti di controllo BFD che hanno il bit Final (F) impostato e che includono la sezione di autenticazione. Una volta che il sistema che ha iniziato il cambio riceve il pacchetto Final con autenticazione, l'autenticazione è considerata abilitata per la sessione e tutti i pacchetti successivi DEVONO essere autenticati.

Per disabilitare l'autenticazione, il processo è simile ma inverso. Il sistema che disabilita l'autenticazione DEVE inviare pacchetti di controllo BFD con il bit Poll (P) impostato e senza la sezione di autenticazione (con il bit A cancellato), ma questi pacchetti DEVONO includere un'autenticazione valida finale per garantire che il cambio sia legittimo. Il sistema remoto risponde con un pacchetto con il bit Final (F) impostato e senza autenticazione. Una volta che questo scambio è completato, l'autenticazione è considerata disabilitata.

È importante notare che durante la transizione (cioè, durante la sequenza di Poll), entrambi i sistemi DEVONO accettare pacchetti sia con che senza autenticazione, purché quelli con autenticazione siano validi. Questo consente una transizione fluida senza interruzione della sessione.

Se l'autenticazione fallisce su un pacchetto ricevuto, il pacchetto DEVE essere scartato silenziosamente. Non vengono generate risposte di errore e lo stato della sessione non viene modificato.

6.7.2. Simple Password Authentication (Autenticazione con password semplice)​

L'autenticazione con password semplice è progettata per fornire una protezione di base contro l'iniezione accidentale o casuale di pacchetti di controllo BFD da parte di sistemi non autorizzati. Non fornisce una protezione crittografica forte e non dovrebbe essere utilizzata in ambienti dove la sicurezza è una preoccupazione seria.

Con l'autenticazione con password semplice, la password è inclusa in chiaro nel pacchetto di controllo BFD. La password è una stringa di caratteri da 1 a 16 byte. Il sistema ricevente confronta la password ricevuta con la password configurata per quella sessione. Se le password corrispondono, il pacchetto è considerato autenticato. Se non corrispondono, il pacchetto DEVE essere scartato.

Il formato della sezione di autenticazione per la password semplice è descritto nella sezione 4.2.

L'uso dell'autenticazione con password semplice è soggetto alle seguenti regole:

  1. La password DEVE essere configurata su entrambi i sistemi che partecipano alla sessione BFD.

  2. La password può essere modificata dinamicamente utilizzando il meccanismo di cambio dell'Auth Key ID descritto di seguito.

  3. Il sistema ricevente DEVE scartare qualsiasi pacchetto in cui la password ricevuta non corrisponde alla password configurata per quella sessione.

  4. La password è trasmessa in chiaro e può essere intercettata da chiunque abbia accesso al collegamento. Pertanto, questo metodo di autenticazione NON DOVREBBE essere utilizzato su collegamenti non sicuri.

Cambio della password:

Per cambiare la password, viene utilizzato il campo Auth Key ID. Più coppie di Auth Key ID e password possono essere configurate su ciascun sistema. Quando un sistema desidera cambiare la password, inizia a trasmettere pacchetti con un nuovo Auth Key ID e la password corrispondente. Il sistema ricevente, che ha la stessa coppia di Auth Key ID e password configurata, accetterà i pacchetti con il nuovo Auth Key ID. Una volta che il primo sistema conferma che il sistema remoto sta utilizzando il nuovo Auth Key ID, può cessare di supportare il vecchio Auth Key ID.

Questo meccanismo consente un cambio della password senza interruzione della sessione BFD.

6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication (Autenticazione MD5 con chiave e MD5 meticoloso con chiave)​

Nota: L'uso dell'autenticazione basata su MD5 è fortemente sconsigliato a causa delle debolezze crittografiche note di MD5. Tuttavia, è documentato qui per compatibilità con le implementazioni esistenti.

L'autenticazione MD5 con chiave fornisce una protezione crittografica più forte rispetto alla password semplice, utilizzando l'algoritmo MD5 [MD5] per calcolare un digest di autenticazione basato sul contenuto del pacchetto e una chiave segreta condivisa.

Il formato della sezione di autenticazione per MD5 con chiave è descritto nella sezione 4.3.

Keyed MD5 Authentication (Autenticazione MD5 con chiave):

Quando si utilizza Keyed MD5 (Type 2), il numero di sequenza viene incrementato occasionalmente. Questo fornisce una protezione limitata contro attacchi di riproduzione, ma non richiede una sincronizzazione stretta del numero di sequenza tra i sistemi.

Meticulous Keyed MD5 Authentication (Autenticazione MD5 meticolosa con chiave):

Quando si utilizza Meticulous Keyed MD5 (Type 3), il numero di sequenza DEVE essere incrementato di uno per ogni pacchetto di controllo BFD successivo trasmesso per una sessione. Questo fornisce una protezione più forte contro attacchi di riproduzione.

Calcolo del digest:

Il digest MD5 viene calcolato come segue:

  1. Il campo Auth Key/Digest viene impostato a zero (padding con zeri fino a 16 byte se necessario).
  2. La chiave di autenticazione condivisa viene aggiunta alla fine del pacchetto di controllo BFD.
  3. Il digest MD5 viene calcolato sull'intero pacchetto risultante (inclusa la chiave).
  4. Il digest risultante (16 byte) viene inserito nel campo Auth Key/Digest.
  5. La chiave viene rimossa (non viene trasmessa).

Validazione del digest:

Il sistema ricevente esegue lo stesso calcolo utilizzando la chiave condivisa configurata localmente e confronta il digest calcolato con il digest ricevuto. Se corrispondono, il pacchetto è considerato autenticato. Se non corrispondono, il pacchetto DEVE essere scartato.

Gestione del numero di sequenza:

Per Keyed MD5, il sistema ricevente DEVE accettare il pacchetto se il numero di sequenza ricevuto è maggiore dell'ultimo numero di sequenza accettato, o se la differenza tra il numero di sequenza ricevuto e l'ultimo numero di sequenza accettato è minore di 3 * Detect Mult * (periodo di trasmissione massimo).

Per Meticulous Keyed MD5, il sistema ricevente DEVE accettare il pacchetto solo se il numero di sequenza ricevuto è maggiore dell'ultimo numero di sequenza accettato. Questa è una verifica molto più stretta che fornisce una protezione migliore contro attacchi di riproduzione.

Cambio della chiave:

Il cambio della chiave viene gestito in modo simile al cambio della password semplice, utilizzando il campo Auth Key ID. Questo consente un cambio della chiave senza interruzione della sessione BFD.

6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication (Autenticazione SHA1 con chiave e SHA1 meticoloso con chiave)​

L'autenticazione SHA1 con chiave fornisce una protezione crittografica più forte rispetto a MD5, utilizzando l'algoritmo SHA-1 [FIPS-180-2] per calcolare un hash di autenticazione basato sul contenuto del pacchetto e una chiave segreta condivisa.

Il formato della sezione di autenticazione per SHA1 con chiave è descritto nella sezione 4.4.

Keyed SHA1 Authentication (Autenticazione SHA1 con chiave):

Quando si utilizza Keyed SHA1 (Type 4), il numero di sequenza viene incrementato occasionalmente. Questo fornisce una protezione limitata contro attacchi di riproduzione, ma non richiede una sincronizzazione stretta del numero di sequenza tra i sistemi.

Meticulous Keyed SHA1 Authentication (Autenticazione SHA1 meticolosa con chiave):

Quando si utilizza Meticulous Keyed SHA1 (Type 5), il numero di sequenza DEVE essere incrementato di uno per ogni pacchetto di controllo BFD successivo trasmesso per una sessione. Questo fornisce una protezione più forte contro attacchi di riproduzione.

Calcolo dell'hash:

L'hash SHA1 viene calcolato come segue:

  1. Il campo Auth Key/Hash viene impostato a zero (padding con zeri fino a 20 byte se necessario).
  2. La chiave di autenticazione condivisa viene aggiunta alla fine del pacchetto di controllo BFD.
  3. L'hash SHA1 viene calcolato sull'intero pacchetto risultante (inclusa la chiave).
  4. L'hash risultante (20 byte) viene inserito nel campo Auth Key/Hash.
  5. La chiave viene rimossa (non viene trasmessa).

Validazione dell'hash:

Il sistema ricevente esegue lo stesso calcolo utilizzando la chiave condivisa configurata localmente e confronta l'hash calcolato con l'hash ricevuto. Se corrispondono, il pacchetto è considerato autenticato. Se non corrispondono, il pacchetto DEVE essere scartato.

Gestione del numero di sequenza:

Per Keyed SHA1, il sistema ricevente DEVE accettare il pacchetto se il numero di sequenza ricevuto è maggiore dell'ultimo numero di sequenza accettato, o se la differenza tra il numero di sequenza ricevuto e l'ultimo numero di sequenza accettato è minore di 3 * Detect Mult * (periodo di trasmissione massimo).

Per Meticulous Keyed SHA1, il sistema ricevente DEVE accettare il pacchetto solo se il numero di sequenza ricevuto è maggiore dell'ultimo numero di sequenza accettato. Questa è una verifica molto più stretta che fornisce una protezione migliore contro attacchi di riproduzione.

Cambio della chiave:

Il cambio della chiave viene gestito in modo simile al cambio della password semplice e al cambio della chiave MD5, utilizzando il campo Auth Key ID. Più coppie di Auth Key ID e chiave possono essere configurate su ciascun sistema, consentendo un cambio della chiave senza interruzione della sessione BFD.

Raccomandazione:

L'autenticazione SHA1 è preferibile rispetto a MD5 a causa della maggiore forza crittografica di SHA-1. Tuttavia, per applicazioni che richiedono il massimo livello di sicurezza, dovrebbe essere considerato l'uso di algoritmi più moderni quando disponibili in future estensioni di questo protocollo.

6.8. Functional Specifics (Specifiche funzionali)​

Questa sezione contiene le specifiche funzionali dettagliate per l'implementazione di BFD. Include le variabili di stato, i meccanismi di negoziazione dei timer, e le procedure specifiche per la gestione dei pacchetti BFD.

Le sezioni seguenti forniscono una descrizione dettagliata di ciascun aspetto funzionale del protocollo, incluso il pseudocodice per le operazioni critiche.

Si noti che tutte le variabili di stato menzionate in queste sezioni sono descritte in dettaglio nella sezione 6.8.1. Le procedure descritte qui fanno riferimento a queste variabili utilizzando la notazione bfd.VariableName.

6.8.2. Timer Negotiation (Negoziazione dei timer)​

I sistemi BFD negoziano gli intervalli di trasmissione e ricezione dei pacchetti di controllo per adattarsi alle capacità di entrambi i sistemi. Questo consente a sistemi con capacità diverse di cooperare efficacemente.

Intervallo di trasmissione:

L'intervallo effettivo di trasmissione per i pacchetti di controllo BFD trasmessi da un sistema è determinato come segue:

Intervallo di trasmissione effettivo = max(bfd.DesiredMinTxInterval, bfd.RemoteMinRxInterval)

In altre parole, un sistema DEVE trasmettere pacchetti di controllo BFD a una velocità non superiore al minimo tra ciò che desidera trasmettere (bfd.DesiredMinTxInterval) e ciò che il sistema remoto può ricevere (bfd.RemoteMinRxInterval).

Jitter:

Per evitare la sincronizzazione indesiderata di pacchetti BFD tra più sessioni, DOVREBBE essere applicato un jitter casuale all'intervallo di trasmissione effettivo. Il jitter DOVREBBE essere tra lo 0% e il 25% dell'intervallo di trasmissione effettivo. In altre parole, il tempo effettivo tra le trasmissioni di pacchetti successivi dovrebbe essere:

Tempo tra trasmissioni = Intervallo di trasmissione effettivo - (jitter casuale * Intervallo di trasmissione effettivo * 0.25)

Dove jitter casuale è un valore casuale tra 0.0 e 1.0.

Il jitter viene applicato per prevenire che molteplici sessioni BFD si sincronizzino involontariamente, il che potrebbe causare congestione o altri problemi di prestazioni.

Cambio dell'intervallo:

Quando i parametri dei timer cambiano (ad esempio, quando bfd.DesiredMinTxInterval o bfd.RemoteMinRxInterval cambiano), il nuovo intervallo di trasmissione effettivo DEVE essere calcolato e utilizzato per le trasmissioni successive. Tuttavia, il cambio dell'intervallo di trasmissione DEVE essere coordinato utilizzando una sequenza di Poll (vedi sezione 6.8.3) per garantire che entrambi i sistemi siano consapevoli del cambio.

Modalità Demand:

In modalità Demand, quando un sistema ha cessato la trasmissione periodica di pacchetti di controllo BFD, l'intervallo di trasmissione non è applicabile fino a quando non viene iniziata una sequenza di Poll.

Funzione Echo:

Quando la funzione Echo è attiva, l'intervallo di trasmissione dei pacchetti Echo è determinato localmente e non viene negoziato con il sistema remoto. Tuttavia, il sistema DEVE rispettare il valore bfd.RemoteMinEchoRxInterval ricevuto dal sistema remoto, che indica l'intervallo minimo tra i pacchetti Echo che il sistema remoto può supportare.

6.8.3. Timer Manipulation (Manipolazione dei timer)​

Quando un sistema desidera modificare i parametri dei timer (ad esempio, bfd.DesiredMinTxInterval, bfd.RequiredMinRxInterval, o bfd.DetectMult), DEVE utilizzare una sequenza di Poll per coordinare il cambio con il sistema remoto. Questo garantisce che entrambi i sistemi siano consapevoli del cambio e possano adattare i loro comportamenti di conseguenza.

Procedura per modificare i parametri dei timer:

  1. Il sistema che desidera modificare un parametro DEVE impostare il nuovo valore nel campo appropriato del pacchetto di controllo BFD.

  2. Il sistema DEVE impostare il bit Poll (P) nel pacchetto di controllo BFD per iniziare una sequenza di Poll.

  3. Il sistema DEVE continuare a utilizzare i valori dei parametri precedenti per il calcolo degli intervalli di trasmissione e rilevamento fino a quando non riceve un pacchetto di controllo BFD con il bit Final (F) impostato dal sistema remoto.

  4. Una volta ricevuto il pacchetto con il bit Final, il sistema può iniziare a utilizzare i nuovi valori dei parametri per i calcoli successivi.

Regole importanti:

  • Un sistema NON DEVE modificare i parametri dei timer durante una sequenza di Poll già in corso. Deve attendere che la sequenza di Poll corrente sia completata prima di iniziare una nuova sequenza per modificare altri parametri.

  • Se più parametri devono essere modificati simultaneamente, possono essere modificati tutti nella stessa sequenza di Poll.

  • Il sistema remoto, quando riceve un pacchetto con il bit Poll impostato, DEVE rispondere con un pacchetto con il bit Final impostato che riflette i suoi valori correnti dei parametri (che possono essere cambiati anche dal sistema remoto).

  • Durante la sequenza di Poll, entrambi i sistemi DEVONO accettare pacchetti che utilizzano sia i vecchi che i nuovi parametri, per consentire una transizione fluida.

Esempio:

Se un sistema desidera aumentare il suo bfd.DesiredMinTxInterval da 100ms a 1000ms:

  1. Il sistema imposta bfd.DesiredMinTxInterval a 1000000 microsec ondi (1000ms).
  2. Il sistema invia un pacchetto di controllo BFD con il nuovo valore nel campo Desired Min TX Interval e con il bit Poll (P) impostato.
  3. Il sistema continua a trasmettere a 100ms (o all'intervallo negoziato basato su 100ms) fino a quando non riceve una risposta con il bit Final.
  4. Quando riceve il pacchetto con il bit Final, il sistema può iniziare a trasmettere all'intervallo negoziato basato su 1000ms.

Questo meccanismo garantisce che il sistema remoto sia consapevole del cambio prima che diventi effettivo, prevenendo falsi rilevamenti di guasti dovuti a cambiamenti inattesi negli intervalli di trasmissione.

6.8.4. Calculating the Detection Time (Calcolo del tempo di rilevamento)​

Il tempo di rilevamento (Detection Time) è il periodo entro il quale un sistema DEVE ricevere almeno un pacchetto di controllo BFD dal sistema remoto, altrimenti la sessione verrà dichiarata Down. Il tempo di rilevamento viene calcolato in modo diverso a seconda che il sistema sia in modalità asincrona o in modalità Demand.

In modalità asincrona:

Quando un sistema non è in modalità Demand (cioè, bfd.RemoteDemandMode è 0), il tempo di rilevamento viene calcolato come segue:

bfd.DetectTime = bfd.RemoteDetectMult * bfd.DesiredMinTxInterval

Dove:

  • bfd.RemoteDetectMult è il moltiplicatore di rilevamento ricevuto dal sistema remoto (dal campo Detect Mult).
  • bfd.DesiredMinTxInterval è l'intervallo minimo di trasmissione che il sistema remoto ha dichiarato di voler utilizzare.

In altre parole, il sistema si aspetta di ricevere un pacchetto di controllo BFD dal sistema remoto entro un tempo pari al moltiplicatore di rilevamento moltiplicato per l'intervallo di trasmissione del sistema remoto.

Tuttavia, se il sistema remoto ha segnalato bfd.RequiredMinRxInterval maggiore di zero, il tempo di rilevamento DEVE essere calcolato come:

bfd.DetectTime = bfd.RemoteDetectMult * max(bfd.RemoteDesiredMinTxInterval, bfd.RequiredMinRxInterval)

Questo assicura che il tempo di rilevamento tenga conto sia della velocità di trasmissione del sistema remoto sia della capacità di ricezione del sistema locale.

In modalità Demand:

Quando un sistema è in modalità Demand (cioè, bfd.RemoteDemandMode è 1), il rilevamento dei guasti NON si basa sulla ricezione di pacchetti di controllo BFD periodici. Invece, il sistema DEVE utilizzare qualche altro meccanismo (come la funzione Echo o un meccanismo di rilevamento esterno) per determinare lo stato della connettività.

Se viene utilizzata una sequenza di Poll in modalità Demand, il sistema DEVE attendere un tempo ragionevole per la risposta, ma questo tempo non è strettamente definito dal protocollo BFD.

Aggiornamento del Detection Timer:

Ogni volta che viene ricevuto un pacchetto di controllo BFD valido in modalità asincrona, il Detection Timer DEVE essere resettato a bfd.DetectTime. Se il Detection Timer scade senza ricevere un pacchetto valido, la sessione DEVE essere dichiarata Down.

Caso speciale:

Se bfd.RequiredMinRxInterval del sistema locale è zero, questo indica che il sistema locale non desidera ricevere pacchetti di controllo BFD periodici. In questo caso, il sistema NON DEVE utilizzare un timer di rilevamento basato sulla ricezione dei pacchetti di controllo BFD. Il sistema potrebbe invece fare affidamento sulla funzione Echo o su altri meccanismi per il rilevamento dei guasti.

6.8.5. Detecting Failures with the Echo Function (Rilevamento di guasti con la funzione Echo)​

Quando la funzione Echo è attiva, un sistema può rilevare guasti nel percorso verso il sistema remoto monitorando la ricezione dei pacchetti Echo BFD che ha inviato e che sono stati riflessi dal sistema remoto.

Meccanismo di rilevamento:

Quando un sistema utilizza la funzione Echo, invia pacchetti Echo BFD al sistema remoto a intervalli regolari. Il sistema remoto riflette questi pacchetti indietro al mittente. Il sistema mittente monitora la ricezione di questi pacchetti riflessi.

Il sistema DEVE mantenere un timer (chiamato Echo Detection Timer) per monitorare la ricezione dei pacchetti Echo. Se un numero specificato di pacchetti Echo consecutivi non viene ricevuto entro il tempo previsto, il sistema DEVE dichiarare la sessione Down.

Calcolo del tempo di rilevamento Echo:

Il tempo di rilevamento per la funzione Echo è determinato localmente dal sistema che invia i pacchetti Echo, poiché solo quel sistema conosce la velocità alla quale sta inviando i pacchetti Echo. Il tempo di rilevamento DOVREBBE essere basato sul numero di pacchetti Echo mancanti consecutivi tollerati moltiplicato per l'intervallo di trasmissione Echo.

Ad esempio, se un sistema invia pacchetti Echo ogni 50ms e desidera dichiarare la sessione Down dopo aver perso 3 pacchetti consecutivi, il tempo di rilevamento Echo sarebbe 150ms.

Coordinazione con i pacchetti di controllo:

Quando la funzione Echo è attiva, il sistema PUÒ ridurre la frequenza di trasmissione dei pacchetti di controllo BFD, poiché la funzione Echo fornisce il rilevamento dei guasti. Tuttavia, i pacchetti di controllo BFD DOVREBBERO continuare a essere trasmessi a una velocità bassa per mantenere la sincronizzazione dello stato della sessione tra i due sistemi.

Verifica della capacità del sistema remoto:

Prima di attivare la funzione Echo, un sistema DEVE verificare che il sistema remoto supporti la funzione Echo esaminando il valore bfd.RemoteMinEchoRxInterval. Se questo valore è zero, il sistema remoto non supporta la funzione Echo (o non desidera ricevere pacchetti Echo), e il sistema locale NON DEVE inviare pacchetti Echo.

Se bfd.RemoteMinEchoRxInterval è maggiore di zero, il sistema locale PUÒ attivare la funzione Echo, ma DEVE trasmettere pacchetti Echo a un intervallo non inferiore a bfd.RemoteMinEchoRxInterval.

Gestione dei guasti rilevati:

Se il sistema rileva un guasto attraverso la funzione Echo (cioè, l'Echo Detection Timer scade), il sistema DEVE:

  1. Impostare bfd.SessionState a Down.
  2. Impostare bfd.LocalDiag a 2 (Echo Function Failed).
  3. Cessare la trasmissione di pacchetti Echo.
  4. Aumentare la frequenza di trasmissione dei pacchetti di controllo BFD al valore appropriato per la modalità asincrona.
  5. Segnalare la transizione di stato ai protocolli client.

Vantaggi della funzione Echo:

La funzione Echo ha il vantaggio di testare veramente solo il percorso di inoltro sul sistema remoto, potenzialmente riducendo il jitter del round-trip e consentendo tempi di rilevamento più aggressivi. Può anche rilevare alcune classi di guasti che potrebbero non essere altrimenti rilevate, come guasti nel processamento dei pacchetti da parte del sistema remoto.

6.8.6. Reception of BFD Control Packets (Ricezione dei pacchetti di controllo BFD)​

Quando viene ricevuto un pacchetto di controllo BFD, vengono eseguite le seguenti procedure. Se il pacchetto viene scartato in base a queste procedure, NON DEVE essere elaborato ulteriormente.

Le seguenti verifiche DEVONO essere eseguite su tutti i pacchetti di controllo BFD ricevuti, prima di ulteriori elaborazioni. Se una qualsiasi di queste verifiche fallisce, il pacchetto ricevuto DEVE essere scartato:

  • Se il campo Version non è uguale a 1, il pacchetto DEVE essere scartato.

  • Se il campo Length è minore della lunghezza minima richiesta per il tipo di pacchetto (24 byte per i pacchetti senza autenticazione, più la lunghezza della sezione di autenticazione se presente), il pacchetto DEVE essere scartato.

  • Se il campo Detect Mult è zero, il pacchetto DEVE essere scartato.

  • Se il bit Multipoint (M) è impostato a 1, il pacchetto DEVE essere scartato.

  • Se il campo My Discriminator è zero, il pacchetto DEVE essere scartato.

  • Se il campo Your Discriminator è zero e lo stato non è Down o AdminDown, il pacchetto DEVE essere scartato.

  • Se il campo Your Discriminator è diverso da zero, deve corrispondere al valore bfd.LocalDiscr o il pacchetto DEVE essere scartato.

Se il bit Authentication Present (A) è impostato:

  • Se non è stato configurato alcun tipo di autenticazione per questa sessione, il pacchetto DEVE essere scartato.

  • Se il campo Auth Type non corrisponde al tipo di autenticazione configurato per questa sessione, il pacchetto DEVE essere scartato.

  • Se il pacchetto fallisce la validazione dell'autenticazione in base al tipo di autenticazione specificato, il pacchetto DEVE essere scartato. Vedi le sezioni 6.7.2, 6.7.3 e 6.7.4 per i dettagli della validazione dell'autenticazione.

Se il bit Authentication Present (A) non è impostato:

  • Se l'autenticazione è configurata per la sessione, il pacchetto DEVE essere scartato.

Una volta che il pacchetto ha superato le verifiche sopra, le seguenti azioni vengono eseguite:

  • Se bfd.RemoteDiscr è zero e il campo Your Discriminator non è zero, impostare bfd.RemoteDiscr al valore del campo Your Discriminator.

  • Se bfd.RemoteDiscr è diverso da zero e il campo My Discriminator non è uguale a bfd.RemoteDiscr, il pacchetto DEVE essere scartato.

  • Se è ricevuto lo stato AdminDown, bfd.SessionState DEVE essere impostato a Down, e bfd.LocalDiag DEVE essere impostato a 3 (Neighbor Signaled Session Down). Il Detection Timer DEVE essere cancellato.

  • Se è ricevuto lo stato Down, bfd.SessionState DEVE essere impostato a Down, e bfd.LocalDiag DEVE essere impostato a 3 (Neighbor Signaled Session Down). Il Detection Timer DEVE essere cancellato.

  • Se lo stato ricevuto è Init e bfd.SessionState è Down o AdminDown, la sessione DEVE avanzare allo stato Init, e il Detection Timer DEVE essere avviato con il valore calcolato di bfd.DetectTime.

  • Se lo stato ricevuto è Init o Up, e bfd.SessionState è Init, la sessione DEVE avanzare allo stato Up.

  • Se lo stato ricevuto è Up, bfd.SessionState è Up, e il Detection Timer non è in esecuzione, avviare il Detection Timer con il valore calcolato di bfd.DetectTime.

  • Se lo stato ricevuto è diverso da AdminDown, il Detection Timer DEVE essere reimpostato al valore calcolato di bfd.DetectTime.

  • Aggiornare bfd.RemoteSessionState con il valore del campo State ricevuto.

  • Aggiornare bfd.RemoteDemandMode con il valore del bit Demand (D) ricevuto.

  • Aggiornare bfd.RemoteMinRxInterval con il valore del campo Required Min RX Interval ricevuto.

  • Aggiornare bfd.RemoteMinEchoRxInterval con il valore del campo Required Min Echo RX Interval ricevuto.

  • Ricalcolare il tempo di trasmissione in base ai nuovi valori ricevuti (vedi sezione 6.8.2).

Queste procedure garantiscono che i pacchetti vengano validati correttamente e che lo stato della sessione venga aggiornato in modo appropriato in risposta ai pacchetti ricevuti.

6.8.7. Transmitting BFD Control Packets (Trasmissione dei pacchetti di controllo BFD)​

I pacchetti di controllo BFD vengono trasmessi per vari motivi: periodicamente per il rilevamento dei guasti in modalità asincrona, in risposta a una sequenza di Poll, o per segnalare cambiamenti di stato o parametri.

Trasmissione periodica in modalità asincrona:

Quando una sessione BFD è in modalità asincrona (cioè, non in modalità Demand), il sistema DEVE trasmettere periodicamente pacchetti di controllo BFD all'intervallo negoziato come descritto nella sezione 6.8.2.

La trasmissione periodica DEVE avvenire negli stati Down, Init e Up. La trasmissione NON DEVE avvenire nello stato AdminDown.

Trasmissione in risposta a una sequenza di Poll:

Quando viene ricevuto un pacchetto di controllo BFD con il bit Poll (P) impostato, il sistema DEVE trasmettere un pacchetto di controllo BFD con il bit Final (F) impostato il prima possibile, indipendentemente da qualsiasi trasmissione periodica programmata. Questo pacchetto DEVE riflettere i valori correnti di tutti i parametri della sessione.

Contenuto dei pacchetti trasmessi:

I campi del pacchetto di controllo BFD DEVONO essere impostati come segue:

  • Version (Vers): Impostato a 1.

  • Diagnostic (Diag): Impostato al valore di bfd.LocalDiag.

  • State (Sta): Impostato al valore di bfd.SessionState.

  • Poll (P): Impostato a 1 se il sistema sta iniziando una sequenza di Poll, altrimenti 0.

  • Final (F): Impostato a 1 se il sistema sta rispondendo a un pacchetto ricevuto con il bit Poll impostato, altrimenti 0. Si noti che un pacchetto NON DEVE avere sia il bit Poll che il bit Final impostati.

  • Control Plane Independent (C): Impostato in base all'implementazione (se il BFD è implementato nel piano di inoltro o meno).

  • Authentication Present (A): Impostato a 1 se l'autenticazione è in uso per questa sessione, altrimenti 0.

  • Demand (D): Impostato a 1 se il sistema desidera operare in modalità Demand, la sessione è Up, e il sistema remoto ha anche segnalato Up. Altrimenti impostato a 0.

  • Multipoint (M): Impostato a 0.

  • Detect Mult: Impostato al valore di bfd.DetectMult.

  • Length: Impostato alla lunghezza appropriata del pacchetto, in byte. Deve essere un multiplo di 4.

  • My Discriminator: Impostato al valore di bfd.LocalDiscr.

  • Your Discriminator: Impostato al valore di bfd.RemoteDiscr, o 0 se il valore non è ancora noto.

  • Desired Min TX Interval: Impostato al valore di bfd.DesiredMinTxInterval.

  • Required Min RX Interval: Impostato al valore di bfd.RequiredMinRxInterval.

  • Required Min Echo RX Interval: Impostato al valore di bfd.RequiredMinEchoRxInterval.

Se l'autenticazione è in uso (bit A impostato), la sezione di autenticazione appropriata DEVE essere inclusa e popolata in base al tipo di autenticazione (vedi sezioni 6.7.2, 6.7.3 e 6.7.4).

Modalità Demand:

In modalità Demand, dopo che la sessione è Up e il bit Demand è stato impostato in entrambe le direzioni, il sistema PUÒ cessare la trasmissione periodica di pacchetti di controllo BFD. Tuttavia, il sistema DEVE trasmettere pacchetti di controllo BFD quando:

  1. Inizia una sequenza di Poll (per verificare la connettività o segnalare un cambio di parametri).
  2. Riceve un pacchetto di controllo BFD con il bit Poll impostato (deve rispondere con Final).
  3. I parametri della sessione cambiano.

Intervallo di trasmissione:

L'intervallo di trasmissione effettivo è calcolato come descritto nella sezione 6.8.2, e DOVREBBE includere un jitter casuale per evitare la sincronizzazione con altre sessioni.

6.8.8. Reception of BFD Echo Packets (Ricezione dei pacchetti Echo BFD)​

Quando un sistema riceve un pacchetto Echo BFD, il sistema DEVE semplicemente riflettere il pacchetto ricevuto indietro al mittente, con gli indirizzi sorgente e destinazione a livello di collegamento scambiati.

Il sistema che riflette il pacchetto Echo NON DEVE modificare il contenuto del payload del pacchetto. Il sistema NON DEVE ispezionare il contenuto del payload (oltre a quanto necessario per elaborare il pacchetto a livello di collegamento).

Procedura di riflessione:

Quando viene ricevuto un pacchetto Echo BFD:

  1. Il sistema DEVE scambiare gli indirizzi MAC sorgente e destinazione (o gli indirizzi equivalenti a livello di collegamento appropriato).

  2. Se il pacchetto è incapsulato in IP:

    • Gli indirizzi IP sorgente e destinazione DEVONO essere scambiati.
    • Il campo TTL (Time To Live) per IPv4 o Hop Limit per IPv6 DEVE essere impostato a 255.
    • La checksum IP e UDP DEVE essere ricalcolata.

  3. Il pacchetto DEVE essere ritrasmesso immediatamente sull'interfaccia da cui è stato ricevuto.

Considerazioni:

  • Un sistema NON DEVE fare affidamento sulla ricezione di pacchetti Echo che ha effettivamente inviato. Tutti i pacchetti Echo ricevuti DEVONO essere trattati come candidati per la riflessione, indipendentemente dal fatto che il sistema abbia mai inviato pacchetti Echo al sistema remoto.

  • Se il sistema non supporta la funzione Echo (cioè, ha impostato bfd.RequiredMinEchoRxInterval a zero), DOVREBBE ancora riflettere i pacchetti Echo ricevuti, ma non è obbligatorio farlo.

  • Il sistema DEVE essere in grado di riflettere i pacchetti Echo alla velocità indicata in bfd.RequiredMinEchoRxInterval. Se il sistema non può supportare la velocità richiesta, DEVE impostare bfd.RequiredMinEchoRxInterval a un valore che può supportare, o a zero se non può supportare la funzione Echo del tutto.

Nota di sicurezza:

I pacchetti Echo possono essere sfruttati per attacchi di amplificazione o riflessione. Le implementazioni DOVREBBERO considerare l'uso di rate limiting o altre misure di protezione per mitigare tali rischi, pur assicurando che i pacchetti Echo legittimi possano essere riflessi alla velocità richiesta.

Demultiplexing:

Se necessario, il sistema mittente DOVREBBE includere un Magic Number o altro identificatore nel payload del pacchetto Echo per facilitare il demultiplexing dei pacchetti Echo ricevuti di ritorno. Tuttavia, il sistema che riflette i pacchetti NON DEVE ispezionare o fare affidamento su tale identificatore.

6.8.9. Transmission of BFD Echo Packets (Trasmissione dei pacchetti Echo BFD)​

Un sistema PUÒ trasmettere pacchetti Echo BFD una volta che una sessione BFD è nello stato Up, a condizione che il sistema remoto abbia segnalato che supporta la funzione Echo (cioè, bfd.RemoteMinEchoRxInterval è maggiore di zero).

Formato dei pacchetti Echo:

Il formato e il contenuto dei pacchetti Echo BFD sono principalmente lasciati all'implementazione, con le seguenti linee guida:

  • Il pacchetto Echo DEVE contenere informazioni sufficienti per consentire al sistema mittente di demultiplexare il pacchetto ricevuto di ritorno alla sessione BFD corretta.

  • È RACCOMANDATO che il pacchetto Echo includa un Magic Number o un identificatore simile per facilitare il demultiplexing.

  • È RACCOMANDATO che il pacchetto Echo includa qualche forma di autenticazione o validazione dell'integrità, per proteggersi da pacchetti Echo spoofati.

  • Il pacchetto Echo DOVREBBE contenere informazioni temporali o di sequenza per consentire al sistema mittente di determinare se il pacchetto è stato ricevuto in tempo.

Intervallo di trasmissione Echo:

L'intervallo di trasmissione per i pacchetti Echo è determinato localmente dal sistema che li invia. Tuttavia:

  • Il sistema DEVE rispettare il valore bfd.RemoteMinEchoRxInterval e NON DEVE trasmettere pacchetti Echo più frequentemente di questo intervallo.

  • Come con i pacchetti di controllo BFD, DOVREBBE essere applicato un jitter casuale all'intervallo di trasmissione Echo per evitare sincronizzazione indesiderata. Il jitter DOVREBBE essere tra lo 0% e il 25% dell'intervallo di trasmissione Echo.

Incapsulamento:

I pacchetti Echo DEVONO essere incapsulati in modo tale da essere indistinguibili, a livello di collegamento, dagli altri pacchetti BFD inviati tra gli stessi due sistemi. Questo implica:

  • Gli indirizzi MAC sorgente e destinazione (o equivalenti a livello di collegamento) DEVONO essere gli stessi degli altri pacchetti BFD.
  • Gli indirizzi IP sorgente e destinazione DEVONO essere gli stessi degli altri pacchetti BFD.
  • Il VLAN Tag, se presente, DEVE essere lo stesso degli altri pacchetti BFD.

Porta UDP:

Un pacchetto Echo BFD PUÒ utilizzare qualsiasi numero di porta UDP sorgente e destinazione. Tuttavia:

  • Il mittente DOVREBBE selezionare una porta che non sia in uso per altri scopi su questo sistema, per minimizzare la possibilità che i pacchetti di ritorno vengano consumati da altri processi.

  • La porta UDP scelta DOVREBBE essere inclusa nelle informazioni di demultiplexing nel payload del pacchetto Echo.

Avvio e cessazione:

La trasmissione di pacchetti Echo PUÒ iniziare una volta che:

  1. La sessione BFD è nello stato Up.
  2. Il sistema remoto ha segnalato il supporto per la funzione Echo (bfd.RemoteMinEchoRxInterval > 0).
  3. Il sistema locale desidera utilizzare la funzione Echo.

La trasmissione di pacchetti Echo DEVE cessare quando:

  1. La sessione BFD lascia lo stato Up.
  2. Il sistema remoto segnala che non supporta più la funzione Echo (bfd.RemoteMinEchoRxInterval = 0).
  3. Il sistema locale decide di non utilizzare più la funzione Echo.

Coordinazione con i pacchetti di controllo:

Quando la funzione Echo è attiva, il sistema PUÒ ridurre la frequenza di trasmissione dei pacchetti di controllo BFD (aumentando bfd.DesiredMinTxInterval), poiché il rilevamento dei guasti è gestito dai pacchetti Echo. Tuttavia, i pacchetti di controllo DOVREBBERO continuare a essere inviati per mantenere la sincronizzazione dello stato della sessione.