2.19. Richiesta di un indirizzo interno su una rete remota
2.19. Richiesta di un indirizzo interno su una rete remota
Verificatosi più comunemente nello scenario endpoint-to-security-gateway, un endpoint può aver bisogno di un indirizzo IP nella rete protetta dal security gateway e può aver bisogno che quell'indirizzo sia assegnato dinamicamente. Una richiesta per tale indirizzo temporaneo può essere inclusa in qualsiasi richiesta di creazione di una Child SA (inclusa la richiesta implicita nel messaggio 3) includendo un payload CP. Notare, tuttavia, che è usuale assegnare un solo indirizzo IP durante lo scambio IKE_AUTH. Quell'indirizzo persiste almeno fino all'eliminazione della IKE SA.
Questa funzione fornisce l'allocazione di indirizzo a un IPsec Remote Access Client (IRAC) che cerca di tunnelizzare in una rete protetta da un IPsec Remote Access Server (IRAS). Poiché lo scambio IKE_AUTH crea una IKE SA e una Child SA, l'IRAC DEVE richiedere l'indirizzo controllato dall'IRAS (e opzionalmente altre informazioni riguardanti la rete protetta) nello scambio IKE_AUTH. L'IRAS può procurare un indirizzo per l'IRAC da qualsiasi numero di fonti come un server DHCP/BOOTP (Bootstrap Protocol) o il proprio pool di indirizzi.
Initiator Responder
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr}
In tutti i casi, il payload CP DEVE essere inserito prima del payload SA. Nelle variazioni del protocollo dove ci sono multipli scambi IKE_AUTH, i payload CP DEVONO essere inseriti nei messaggi contenenti i payload SA.
CP(CFG_REQUEST) DEVE contenere almeno un attributo INTERNAL_ADDRESS (o IPv4 o IPv6) ma PUÒ contenere qualsiasi numero di attributi aggiuntivi che l'iniziatore vuole restituiti nella risposta.
Per esempio, messaggio dall'iniziatore al risponditore:
CP(CFG_REQUEST)= INTERNAL_ADDRESS() TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
NOTA: I selettori di traffico contengono (protocollo, intervallo di porte, intervallo di indirizzi).
Messaggio dal risponditore all'iniziatore:
CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
Tutti i valori restituiti saranno dipendenti dall'implementazione. Come si può vedere nell'esempio sopra, l'IRAS PUÒ anche inviare altri attributi che non erano inclusi in CP(CFG_REQUEST) e PUÒ ignorare gli attributi non obbligatori che non supporta.
Il risponditore NON DEVE inviare un CFG_REPLY senza aver prima ricevuto un CP(CFG_REQUEST) dall'iniziatore, perché non vogliamo che l'IRAS esegua una ricerca di configurazione non necessaria se l'IRAC non può processare la REPLY.
Nel caso in cui la configurazione dell'IRAS richieda che CP sia usato per una data identità IDi, ma l'IRAC ha mancato di inviare un CP(CFG_REQUEST), l'IRAS DEVE far fallire la richiesta, e terminare la creazione della Child SA con un errore FAILED_CP_REQUIRED. Il FAILED_CP_REQUIRED non è fatale per la IKE SA; esso causa semplicemente il fallimento della creazione della Child SA. L'iniziatore può correggere questo avviando in seguito una nuova richiesta di payload Configuration. Non ci sono dati associati all'errore FAILED_CP_REQUIRED.