Analisi delle intestazioni di estensione IPv6 contenenti estensioni sconosciute

113

Sto scrivendo un filtro di rete molto semplice e sto arrivando a dove voglio analizzare le intestazioni IPv6 per abbinare cose come i tipi ICMPv6, i numeri di porta TCP / UDP, ecc.

Quindi sto leggendo approfonditamente il formato del pacchetto IPv6 , e sono tipo ... beh ... ho dovuto leggerlo più e più volte per assicurarmi di averlo letto correttamente. Mi sembra che devi iniziare con l'intestazione fissa di 40 byte e guardare il suo prossimo campo di intestazione. Quindi devi guardare il campo di intestazione successivo dell'intestazione successiva e così via, come un elenco collegato, fino a raggiungere la fine. Se c'è un carico utile, seguirà.

Il problema è che non c'è alcun campo di lunghezza né nell'intestazione fissa né nelle intestazioni di estensione. Devi avere una tabella dei tipi di intestazione delle estensioni e delle loro dimensioni in modo da poter inseguire questo elenco collegato fino alla fine.

Questo mi colpisce come un disegno strano, forse persino da cervello di lepre. E se riscontro un tipo di intestazione di estensione non riconosciuto? Cosa faccio? Non ne conosco la lunghezza. Immagino di dover eliminare il pacchetto e bloccarlo, poiché in un filtro di rete consentire il passaggio del pacchetto consentirebbe a un utente malintenzionato di eludere il filtro di rete includendo un tipo di intestazione fasullo. Ma ciò significa che se il protocollo viene esteso, ogni singolo pezzo di software di analisi dell'intestazione IPv6 mai scritto deve essere aggiornato simultaneamente se si desidera utilizzare la nuova estensione.

Quindi come posso analizzare le intestazioni IPv6 se non conosco le estensioni che stanno utilizzando? Come posso saltare un'intestazione per un'estensione sconosciuta, poiché non ne conosco la lunghezza?

networking ip ipv6

— AdamIerymenko
fonte

10

Sulla base di questa domanda sembra che non sia stupido e sì, sto leggendo bene: è (nel mondo reale) impossibile aggiungere una nuova intestazione di estensione a IPv6. stackoverflow.com/questions/9847923/...

— AdamIerymenko

10

E sì, sembra anche che il calcolo della lunghezza dell'intestazione richieda un attraversamento dell'elenco collegato: stackoverflow.com/questions/14762193/… Non fraintendetemi. IPv6 è fantastico e molto necessario. Ma questo sembra ancora testardo.

— AdamIerymenko

3

La specifica (collegata nel commento in alto) dice che i router non dovrebbero guardare le intestazioni, quindi non dovrebbe importare quali intestazioni aggiungi. Solo il nodo di destinazione dovrebbe guardare le intestazioni.

— Anders E. Andersen

2

Solo una nota: "cervello di lepre" è un'ortografia abbastanza confusa e dovrebbe essere preferito "cervello di lepre" (fonte: tfd )

— pzkpfw

2

Nella misura in cui esiste una sola ortografia corretta, che è "cervello di lepre".

— Alan B

33

Se ti imbatti in qualcosa che non puoi analizzare, devi prendere la tua decisione o eseguire la tua azione in base a ciò che hai già analizzato.

Il design è in questo modo perché in IPv6, ciascuna intestazione di estensione "avvolge" il resto del pacchetto. Se vedi l'intestazione di routing, quindi un'intestazione di cui non hai mai sentito parlare, quindi il payload, non puoi analizzare il payload. Il significato del payload dipende in linea di principio dall'intestazione che non sai come interpretare.

I router possono instradare tali pacchetti, perché tutto ciò di cui hanno bisogno è l'intestazione di routing. I gadget di ispezione approfondita dei pacchetti e simili hanno bisogno di sapere molto, ma del resto è comunque il loro destino.

Modificato per aggiungere: questo design significa che i middlebox possono cambiare solo ciò che sanno. Se un middlebox vede un'intestazione che non conosce, ha solo due opzioni: Rifiuta o trasmetti. In IPv4 potrebbe anche rimuovere l'estensione sconosciuta e trasferire il resto. IMO questa proprietà rende il design più piuttosto che meno estensibile.

— Arnt
fonte

97

E se riscontro un tipo di intestazione di estensione non riconosciuto?

Da RFC 2460 :

Se, come risultato dell'elaborazione di un'intestazione, è necessario un nodo per procedere all'intestazione successiva ma il valore Intestazione successiva nell'intestazione corrente non è riconosciuto dal nodo, dovrebbe scartare il pacchetto e inviare un messaggio di problema con i parametri ICMP alla fonte del pacchetto , con un valore Codice ICMP di 1 ("tipo di intestazione successiva non riconosciuto rilevato") e il campo Puntatore ICMP contenente l'offset del valore non riconosciuto all'interno del pacchetto originale. La stessa azione dovrebbe essere eseguita se un nodo rileva un valore di intestazione successiva pari a zero in un'intestazione diversa da un'intestazione IPv6.

— Oliver Charlesworth
fonte

15

Buona. Pensavo di stare impazzendo. Quindi sì, è davvero un design completamente estensibile ... almeno senza segnali in banda e altri hack. Questo è scusabile in un protocollo dell'applicazione in cui controlli entrambe le estremità e devi solo tenere conto delle nuove versioni della tua app, ma non in qualcosa progettato per durare per ... centinaia di anni?

— AdamIerymenko

8

Avere la capacità di ignorare intestazioni sconosciute porterebbe a problemi molto più complicati. (E se un proxy intermedio modificasse le intestazioni TCP senza la conoscenza di un'intestazione ESP incapsulante?) La semplicità batte "estensibile" in questo caso!

— jman

4

@Max IPv6 ha abbastanza letteralmente indirizzi sufficienti per assegnarne uno a ogni singolo atomo sulla Terra. Non c'è numero di tostapane connessi a Internet che esauriranno questo spazio.

— Tyler McHenry

8

@Max Non dirò che non avremo assolutamente mai bisogno di IPv7, ma con IPv6 abbiamo abbastanza spazio per gli indirizzi per dare a ogni millimetro cubo nell'atmosfera terrestre (130.000 km in su) un indirizzo unico ... 100.000 volte. Quindi, una volta che iniziamo a colonizzare altre galassie, potremmo avere qualcosa di cui preoccuparci, ma fino ad allora dovremmo essere abbastanza bravi.

— cincodenada

4

Manca un contesto:

With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

— Tobu

28

È (nel mondo reale) impossibile aggiungere una nuova intestazione di estensione a IPv6.

Sbagliato, perché:

Solo l'host di destinazione può rifiutare in base a intestazioni di estensioni non riconosciute (con quell'unica eccezione menzionata nella domanda che hai collegato )
Se la tua nuova intestazione di estensione è in qualche modo facoltativa (sarebbe meglio che lo fosse), riceverai un errore ICMP e potrai riprovare senza di essa.

— Andreas Klöckner
fonte

1

E sei certo che quel pacchetto ICMP passerà attraverso il NAT fino al mittente effettivo?

— Dexter

5

@Dexter ipv6 ucciderà NAT ... si spera

— Janus Troelsen

2

@Dexter: questi pacchetti ICMP devono arrivare per una serie di motivi. Ad esempio, se la MTU della pipe si è ridotta (forse l'incapsulamento del pacchetto è avvenuto a causa di PPPoE o una VPN) e il pacchetto inviato è troppo grande, verrà restituito un pacchetto ICMP dicendo che il pacchetto è troppo grande.

— Bill Lynch

4

@JanusTroelsen non tutti condividono le tue speranze.

— Dexter

4

L'aggiornamento RFC 6564 copre questo caso. Presenta esattamente lo scenario che descrivi e presenta un formato per qualsiasi nuova intestazione di estensione (se mai definita) con cui middlebox come il tuo sarà in grado di lavorare, almeno qualche volta.

Tieni presente che non si intende estendere IPv6 creando nuove intestazioni di estensione, ma aggiungendo nuove opzioni di destinazione. Dovrebbe essere banale, o almeno molto più semplice, gestire opzioni di destinazione sconosciute.

— Michael Hampton
fonte