Informazioni sui dettagli di SPI in IKE e IPsec

Naviga le tue risposte
4

Attualmente sto imparando IKE e IPsec per un esame. Ho un sacco di informazioni su come vengono utilizzati i parametri dei parametri di sicurezza (SPI) in entrambi i protocolli, ma sto avendo qualche problema a capire la coerenza.

Innanzitutto, in IKE, entrambe le parti condividono il proprio SPI con l'altra controparte. Immagino che questi saranno entrambi gli SPI usati per le due Security Associations (SA), perché ogni SA è solo unidirezionale, giusto?

Quindi, nel capitolo IPsec, le cose iniziano a diventare più complicate. Leggendo diverse fonti, ho una teoria su come funziona esattamente, ma non sono sicuro che la mia teoria sia giusta. RFC 4301 dice:

SPI: An arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet should be bound. [...]

In IKE, ciascuna parte condivide uno SPI con l'altra parte. Questo significa che l'SPI di una festa imposta è lo SPI utilizzato per la SA in arrivo, non quella in uscita?

Questo spiegherebbe un'altra domanda che ho per quanto riguarda la registrazione di una nuova SA nel Database SA (SAD)

  • SAD_ADD viene utilizzato quando IKE sa già quale SPI desidera utilizzare per un SA.
  • SAD_GETSPI viene utilizzato per ottenere un SPI non utilizzato (in questo caso il SAD restituisce un SPI non utilizzato, poiché ovviamente sa quali sono gli SPI utilizzati e quali no). Inoltre inserisce già una SA incompleta. Il SAD_UPDATE viene quindi utilizzato per impostare l'SPI mancante alla SA precedentemente inserita.

Inoltre le mie note dicono che l'iniziatore usa il metodo SAD_ADD mentre il rispondente usa SAD_GETSPI e SAD_UPDATE . Questo avrebbe senso, se il rispondente è quello che crea uno SPI e l'iniziatore aggiunge solo questo SPI al suo database. Questo deve essere unico per lui insieme con l'indirizzo IP del rispondente. La mia teoria è giusta?

Tuttavia non capisco perché venga usato il metodo SAD_UPDATE . Per me questo sembra ridondante:

  • SAD_GETSPI : "Voglio inserire un SA x , che SPI posso usare? Risposta: Ecco un SPI inutilizzato: y . Inoltre, ho già inserito x nel mio Database, dimmi solo quali Dovrei inserire SPI. "
  • SAD_UPDATE : "Aggiorna SA x , imposta SPI su y ."
posta Misch 23.04.2014 - 10:35
fonte

1 risposta

8

Gli indici dei parametri di sicurezza (SPI) possono significare cose diverse quando si fa riferimento a IKE e IPsec Security Associations (SA):

  • Per IKE due SPI a 64 bit identificano in modo univoco una SA IKE. Con IKEv2 la richiesta di IKE_SA_INIT avrà solo l'SPI dell'iniziatore localmente univoco impostato nell'intestazione IKE, lo SPI del rispondente è zero . Il rispondente lo imposterà a un valore localmente unico nella sua risposta. I due SPI cambiano solo quando IKE SA viene reimpostato.

    I due campi nell'intestazione IKE che ora sono denominati SPI iniziatore / risponditore erano precedentemente chiamati cookie iniziatore / risponditore in RFC 2408 (ISAKMP). Ciò potrebbe creare confusione poiché IKEv2 utilizza i payload della notifica COOKIE per contrastare gli attacchi denial of service .

  • Per IPsec un SPI a 32 bit identifica semi-un IPsec SA in modo univoco. Poiché queste SA sono unidirezionali, l'intestazione ESP / AH contiene solo l'SPI della SA in entrata della destinazione (diversamente dall'intestazione IKE che contiene sempre entrambi gli SPI). Poiché gli SPI sono localmente unici, questo e l'indirizzo di destinazione sono in genere sufficienti per identificare univocamente un SA. Ma potrebbe essere problematico, ad es. se due client dietro lo stesso NAT allocano lo stesso SPI locale quando si connettono allo stesso gateway VPN. La combinazione di SPI e indirizzo di destinazione sarebbe la stessa sul lato pubblico del NAT, motivo per cui è richiesto incapsulamento UDP . Le porte UDP consentono al NAT di indirizzare i pacchetti in entrata al client giusto. Allo stesso modo, il gateway deve adottare misure per differenziare le due SA in modo che venga utilizzata la SA corretta quando si invia traffico a ciascun client.

Does this mean, that the SPI a party sets is the SPI used for the incoming SA, not the outgoing one?

Sì, ogni peer invia lo SPI della sua SA in entrata all'altro peer.

Additionally my notes say that the initiator uses the SAD_ADD method while the responder uses SAD_GETSPI and SAD_UPDATE.

Il processo di creazione di un IPsec SA utilizzando ad es. uno scambio CREATE_CHILD_SA in IKEv2 potrebbe essere approssimativamente visualizzato in questo modo: 

Initiator                               Responder
SAD_GETSPI (inbound SA)  ----------->   {select algorithms and derive keys}
                                        SAD_ADD (outbound SA)
                                        SAD_GETSPI (inbound SA)
{derive keys}            <-----------   SAD_UPDATE (inbound SA) 
SAD_UPDATE (inbound SA)
SAD_ADD (outbound SA)
  1. L'iniziatore invia l'SPI della sua SA in entrata insieme a una proposta di algoritmi crittografici e, se viene utilizzata la perfetta segretezza inoltrata, il suo fattore Diffie-Hellman, al rispondente.
  2. Il rispondente seleziona gli algoritmi adatti e ricava le chiavi (facoltativamente usando DH) e procede all'installazione delle SA.
  3. Quindi restituisce il suo SPI in ingresso insieme agli algoritmi selezionati (e facoltativamente il suo fattore DH) all'iniziatore, che ora è in grado di installare le SA al suo fianco.

Inoltre, i due peer scambiano selettori di traffico che specificano il traffico di rete che deve essere coperto dalla SA stabilita.

SAD_UPDATE: "Please update SPI x, set SPI to y."

Questo non è ciò che SAD_UPDATE fa. In realtà non cambia affatto SPI, ma piuttosto tutti (o alcuni) degli altri aspetti della SA, e questi sono principalmente algoritmi e chiavi di crittografia / integrità (ma possono anche includere altre cose, come incapsulamento o le dimensioni della finestra anti-replay).

Il motivo per cui di solito vuoi chiamare SAD_GETSPI e SAD_UPDATE invece di semplicemente SAD_ADD per SA in ingresso (anche sul risponditore, dove tutte le informazioni sarebbero disponibili) è che il SAD è solitamente gestito dal gestore kernel del sistema, mentre i daemon IKE operano in userland. Pertanto, chiamando SAD_GETSPI assicurerai che l'SPI sia in realtà localmente unico. Quale potrebbe non essere garantito se ad es. due daemon IKE (per IKEv1 e IKEv2) o persino strumenti per gestire manualmente le SA (come ip xfrm o setkey ) vengono utilizzati contemporaneamente su un sistema.

Ma è immaginabile che su alcuni sistemi ci possa essere una semplificazione che consentirebbe a un rispondente di chiamare SAD_ADD senza specificare uno SPI, e il SAD ne allocherà uno, installerà l'SA e restituirà il nuovo SPI. Ma ciò richiederebbe una gestione speciale per questo caso particolare da parte del daemon keying (altrimenti potrebbe semplicemente chiamare SAD_ADD per le SA in uscita e SAD_GETSPI/SAD_UPDATE per le SA in ingresso, non importa se lo fa come iniziatore o risponditore).

RFC 2367 (PF_KEYv2) fornisce ulteriori informazioni su queste operazioni.

    
risposta data 23.04.2014 - 16:29
fonte

Leggi altre domande sui tag

criteri delle prestazioni di sicurezza nelle revisioni dei dipendenti Se un utente malintenzionato ha la capacità di modificare i dati trasferiti tramite una connessione Internet, può influire su TLS?