During IKE_SA_INIT you negotiate cryptographic algorithms which I assume (correct me if I am wrong) are very similar to a TLS cipher suite (symmetric crypto algorithm and a hash function). You also do a Diffie-Hellman exchange which I assume is not specified in the SAi1/SAr1 because you always do DH in IKEv2.
Sì, sono simili. Ma non ci sono suite di crittografia fisse in IKE (ad esempio, algoritmi di diversi tipi di trasformazione possono essere combinati liberamente in una proposta - con alcune eccezioni, come non negoziare algoritmi di integrità quando vengono proposti algoritmi in modalità AEAD).
Il gruppo DH viene anche negoziato con payload SA (trasformazione tipo 4), anche se l'iniziatore invia già un carico utile KE con il suo valore di DH pubblico per un gruppo specifico. Quindi, se l'iniziatore propone più di un gruppo DH, deve assumere quale gruppo il rispondente potrebbe selezionare (il rispondente potrebbe, ovviamente, utilizzare il carico utile KE come strong suggerimento verso il gruppo che dovrebbe essere selezionato, ma potrebbe preferire la propria configurazione o non supportare nemmeno il gruppo proposto). Se l'ipotesi dell'iniziatore è sbagliata e il rispondente seleziona un gruppo DH diverso, risponderà con una notifica INVALID_KE_PAYLOAD contenente il gruppo selezionato. L'iniziatore deve quindi inviare un'altra richiesta IKE_SA_INIT con un payload KE adeguatamente aggiornato (e possibilmente un payload SA aggiornato).
What I dont get why you would want to negotiate cipher suites again. RFC 7293 tells me that
All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.
quindi qual è il punto delle offerte SA nella richiesta CREATE_CHILD_SA?
Quella citazione si riferisce al traffico IKE, che viene crittografato dopo che il materiale chiave è stato stabilito con lo scambio DH durante IKE_SA_INIT . Ma per trasportare il traffico tramite IPsec è necessario negoziare effettive IPsec / Child SA all'interno di IKE SA. Gli algoritmi utilizzati per IKE e Child SA possono essere diversi, in realtà ogni Child SA negoziata potrebbe teoricamente utilizzare algoritmi diversi (che in genere potrebbero non essere il caso, ma l'utilizzo di algoritmi diversi per IKE e Child SA è decisamente comune, ad esempio AES-GCM per IPsec e AES / SHA-2 per IKE). Ecco perché gli algoritmi sono negoziati in CREATE_CHILD_SA exchange.
Lo scambio CREATE_CHILD_SA è anche usato per rekey IKE e Child SAs, e mentre teoricamente potrebbero essere negoziati diversi algoritmi (fondamentalmente viene creata una nuova SA per sostituire quella esistente) RFC 7296, sezione 2.8 scoraggia questo:
Note that, when rekeying, the new
Child SA SHOULD NOT have different Traffic Selectors and algorithms
than the old one.
Tieni presente che, a meno che non sia implementato RFC 6023 , una prima Child SA sia già stata creata con IKE_AUTH scambio. Gli algoritmi utilizzati per questa SA sono negoziati con payload SA durante IKE_AUTH (SAi2 / SAr2 in RFC 7296 ). Tuttavia, poiché non esiste uno scambio DH separato per esso (le chiavi per questo SA sono sempre derivate dal materiale chiave IKE), nessun gruppo DH sarà negoziato, RFC 7296, sezione 1.2 :
Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
Thus, the SA payloads in the IKE_AUTH exchange cannot contain
Transform Type 4 (Diffie-Hellman group) with any value other than
NONE. Implementations SHOULD omit the whole transform substructure
instead of sending value NONE.
Se tale Child IS viene successivamente reinserita, un gruppo DH può essere opzionalmente negoziato per stabilire un nuovo materiale chiave indipendente dal materiale chiave IKE. Poiché nessuna trasformazione DH era contenuta nei payload SA iniziali utilizzati per questa Child SA, gli errori di configurazione relativi ai gruppi DH per questa Child SA possono essere rilevati solo quando viene reimpostato per la prima volta e falliscono.