3.15. Configuration Payload (Payload di configurazione)

Il Configuration payload, indicato come CP in questo documento, serve a scambiare informazioni di configurazione tra peer IKE. Lo scambio consente a un IRAC di richiedere un indirizzo IP interno a un IRAS e di scambiare altre informazioni del tipo che si otterrebbero con il Dynamic Host Configuration Protocol (DHCP) se l'IRAC fosse collegato direttamente a una LAN.

Il Configuration payload è definito come segue:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C| RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CFG Type    |                    RESERVED                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Configuration Attributes                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 22: Formato del Configuration payload

Il tipo di payload per il Configuration payload è quarantasette (47).

CFG Type (1 ottetto) - Il tipo di scambio rappresentato dai Configuration Attributes. I valori nella tabella seguente sono aggiornati alla data di pubblicazione del RFC 4306. Valori successivi in [IKEV2IANA].

CFG Type	Valore
CFG_REQUEST	1
CFG_REPLY	2
CFG_SET	3
CFG_ACK	4

RESERVED (3 ottetti) - DEVE essere inviato a zero; DEVE essere ignorato in ricezione.
Configuration Attributes (lunghezza variabile) - Strutture tipo-lunghezza-valore (TLV) specifiche del Configuration payload, definite sotto. Possono esserci zero o più Configuration Attributes in questo payload.

3.15.1. Configuration Attributes

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|         Attribute Type      |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 23: Formato del Configuration attribute

Reserved (1 bit) - Questo bit DEVE essere zero e DEVE essere ignorato in ricezione.
Attribute Type (15 bit) - Identificatore univoco per ciascun tipo di Configuration Attribute.
Length (2 ottetti, intero senza segno) - Lunghezza in ottetti del valore.
Value (zero o più ottetti) - Valore a lunghezza variabile di questo Configuration Attribute. I tipi di attributo seguono.

I valori nella tabella seguente sono aggiornati alla data di pubblicazione del RFC 4306 (INTERNAL_ADDRESS_EXPIRY e INTERNAL_IP6_NBNS rimossi dal RFC 5996). Valori successivi in [IKEV2IANA].

Attribute Type	Valore	Multi-valore	Lunghezza
INTERNAL_IP4_ADDRESS	1	YES*	0 o 4 ottetti
INTERNAL_IP4_NETMASK	2	NO	0 o 4 ottetti
INTERNAL_IP4_DNS	3	YES	0 o 4 ottetti
INTERNAL_IP4_NBNS	4	YES	0 o 4 ottetti
INTERNAL_IP4_DHCP	6	YES	0 o 4 ottetti
APPLICATION_VERSION	7	NO	0 o più
INTERNAL_IP6_ADDRESS	8	YES*	0 o 17 ottetti
INTERNAL_IP6_DNS	10	YES	0 o 16 ottetti
INTERNAL_IP6_DHCP	12	YES	0 o 16 ottetti
INTERNAL_IP4_SUBNET	13	YES	0 o 8 ottetti
SUPPORTED_ATTRIBUTES	14	NO	Multiplo di 2
INTERNAL_IP6_SUBNET	15	YES	17 ottetti

* Questi attributi possono essere multi-valore in risposta solo se sono stati richiesti più valori.

INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Un indirizzo sulla rete interna, talvolta detto indirizzo red node o privato; PUÒ essere un indirizzo privato su Internet. In un messaggio di richiesta, l'indirizzo indicato è quello richiesto (o lunghezza zero se non si richiede un indirizzo specifico). Una richiesta specifica suggerisce spesso una connessione precedente con quell'indirizzo e il desiderio di riutilizzarlo. Con IPv6, il richiedente PUÒ fornire gli ottetti bassi desiderati. Più indirizzi interni POSSONO essere richiesti con più attributi indirizzo interno. Il rispondente PUÒ inviare al massimo il numero di indirizzi richiesti. INTERNAL_IP6_ADDRESS ha due campi: indirizzo IPv6 di 16 ottetti e lunghezza prefisso di un ottetto come in [ADDRIPV6]. L'indirizzo richiesto è valido finché è valida questa IKE SA (o le sue successive dopo rekey) che lo ha richiesto. Vedere la sezione 3.15.3.
INTERNAL_IP4_NETMASK - La maschera di rete della rete interna. È consentita una sola maschera nelle richieste e risposte (es. 255.255.255.0) e DEVE essere usata solo con INTERNAL_IP4_ADDRESS. INTERNAL_IP4_NETMASK in CFG_REPLY equivale grosso modo a INTERNAL_IP4_SUBNET con le stesse informazioni («inviare il traffico verso questi indirizzi attraverso me»), ma implica anche un confine di link. Il client può usare indirizzo e maschera per calcolare il broadcast del link. Un attributo INTERNAL_IP4_NETMASK vuoto in CFG_REQUEST può richiedere questa informazione (il gateway può inviarla anche senza richiesta). Valori non vuoti in CFG_REQUEST non hanno senso e NON DEVONO essere inclusi.
INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifica l'indirizzo di un server DNS nella rete. Più server DNS POSSONO essere richiesti. Il rispondente PUÒ rispondere con zero o più attributi server DNS.
INTERNAL_IP4_NBNS - Indirizzo di un NetBios Name Server (WINS) nella rete. Più server NBNS POSSONO essere richiesti. Il rispondente PUÒ rispondere con zero o più attributi NBNS.
INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Indica all'host di inviare le richieste DHCP interne all'indirizzo nell'attributo. Più server DHCP POSSONO essere richiesti. Il rispondente PUÒ rispondere con zero o più attributi server DHCP.
APPLICATION_VERSION - Versione o informazioni applicative dell'host IPsec. Stringa di caratteri ASCII stampabili NON terminata da null.
INTERNAL_IP4_SUBNET - Le sottoreti protette da questo dispositivo perimetrale. Due campi: indirizzo IP e maschera. Più sottoreti POSSONO essere richieste. Il rispondente PUÒ rispondere con zero o più attributi sottorete. Vedere la sezione 3.15.2.
SUPPORTED_ATTRIBUTES - In una Request, questo attributo DEVE avere lunghezza zero e chiede al rispondente di elencare tutti gli attributi supportati. La risposta contiene un attributo con identificatori da 2 ottetti ciascuno. La lunghezza divisa per 2 dà il numero di attributi supportati.
INTERNAL_IP6_SUBNET - Sottoreti protette da questo dispositivo. Indirizzo IPv6 di 16 ottetti e lunghezza prefisso di un ottetto come in [ADDRIPV6]. Più sottoreti POSSONO essere richieste. Vedere la sezione 3.15.2.

Questo documento non raccomanda metodi specifici per determinare quali informazioni inviare in risposta, né come un IRAS scelga quale server DNS restituire a un IRAC richiedente.

La coppia CFG_REQUEST e CFG_REPLY consente a un endpoint IKE di richiedere informazioni al peer. Se un attributo nel Configuration payload CFG_REQUEST non ha lunghezza zero, è una suggestione per quell'attributo. Il Configuration payload CFG_REPLY PUÒ restituire quel valore o uno nuovo, aggiungere attributi o omettere richieste. Attributi non riconosciuti o non supportati DEVONO essere ignorati in richieste e risposte.

La coppia CFG_SET e CFG_ACK consente di inviare dati di configurazione al peer. Il Configuration payload CFG_SET contiene attributi che l'iniziatore vuole modificare sul peer. Se il rispondente ha accettato dati, DEVE restituire un Configuration payload con gli attributi accettati e dati di lunghezza zero. Gli attributi non accettati NON DEVONO comparire nel CFG_ACK. Se nulla è accettato, il rispondente DEVE restituire un CFG_ACK vuoto o una risposta senza CFG_ACK. Non ci sono usi definiti per CFG_SET/CFG_ACK al momento; possono essere usati con estensioni basate su Vendor ID. Un'implementazione PUÒ ignorare i payload CFG_SET.

3.15.2. Significato di INTERNAL_IP4_SUBNET e INTERNAL_IP6_SUBNET

Gli attributi INTERNAL_IP4/6_SUBNET possono indicare sottoreti aggiuntive raggiungibili tramite il gateway che annuncia gli attributi e che richiedono una o più SA separate. Possono anche esprimere la politica del gateway sul traffico che deve passare dal gateway; il client può scegliere se altro traffico (coperto da TSr ma non da INTERNAL_IP4/6_SUBNET) passa dal gateway o va diretto. Il traffico verso gli indirizzi elencati in INTERNAL_IP4/6_SUBNET dovrebbe passare dal gateway che annuncia gli attributi. Se non esiste Child SA i cui Traffic Selectors coprono l'indirizzo, occorrono nuove SA.

Esempio con due sottoreti 198.51.100.0/26 e 192.0.2.0/24:

CP(CFG_REQUEST) =
  INTERNAL_IP4_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)

Risposta valida (TSr e INTERNAL_IP4_SUBNET stessa informazione):

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
       (0, 0-65535, 192.0.2.0-192.0.2.255))

In questi casi INTERNAL_IP4_SUBNET non aggiunge informazione utile.

Altra risposta possibile:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

Il client può inviare tutto il traffico via gateway; il gateway accetta anche traffico fuori INTERNAL_IP4_SUBNET direttamente verso la destinazione.

Se la politica richiede SA separate per le due sottoreti:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

INTERNAL_IP4_SUBNET è utile anche se il TSr del client copre solo parte dello spazio:

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Possibile risposta:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Poiché il significato di INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET nei CFG_REQUEST è poco chiaro, non sono affidabili nei CFG_REQUEST.

3.15.3. Configuration payload per IPv6

I Configuration payload per IPv6 si basano sui corrispondenti IPv4 e non seguono pienamente il «modo IPv6 usuale». In particolare non si usano autoconfigurazione stateless IPv6, annunci router né neighbor discovery. Vedere [IPV6CONFIG] (sperimentale).

Un client può ricevere un indirizzo IPv6 con INTERNAL_IP6_ADDRESS. Scambio minimo:

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =
  INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

Il client PUÒ inviare INTERNAL_IP6_ADDRESS non vuoto in CFG_REQUEST. Il gateway verifica l'indirizzo; se non accettabile, prova l'identificatore di interfaccia con altro prefisso o ne sceglie un altro.

INTERNAL_IP6_ADDRESS include anche la lunghezza del prefisso; in CFG_REPLY corrisponde a INTERNAL_IP4_NETMASK in IPv4.

I tunnel IPsec con IKEv2 non sono «interfacce» complete nel senso dell'architettura di indirizzamento IPv6 [ADDRIPV6]; spesso mancano indirizzi link-local, complicando protocolli come [MLDV2].

3.15.4. Errori nell'assegnazione degli indirizzi

Se il rispondente incontra un errore assegnando un indirizzo IP all'iniziatore durante l'elaborazione di un Configuration payload, risponde con la notifica INTERNAL_ADDRESS_FAILURE. L'IKE SA viene comunque creata anche se la Child SA iniziale non può essere creata per questo errore. Se l'errore avviene in IKE_AUTH, non si crea Child SA. Esistono casi più complessi.

Se il rispondente non supporta affatto i Configuration payload, può ignorarli tutti. Tali implementazioni non inviano mai INTERNAL_ADDRESS_FAILURE.

Se l'iniziatore richiede obbligatoriamente un indirizzo IP, tratta come errore una risposta senza CFG_REPLY.

L'iniziatore può richiedere un tipo di indirizzo (IPv4 o IPv6) non supportato dal rispondente, che comunque supporta i Configuration payload. Il rispondente ignora quel tipo e elabora il resto come al solito.

Se alcune (non tutte) richieste multiple falliscono, il rispondente risponde solo con gli indirizzi assegnati con successo. INTERNAL_ADDRESS_FAILURE solo se non si può assegnare alcun indirizzo.

Se l'iniziatore non riceve gli indirizzi richiesti dalla policy, PUÒ mantenere l'IKE SA e riprovare il Configuration payload in uno scambio INFORMATIONAL separato dopo un timeout, oppure demolire l'IKE SA con un Delete payload e riprovare da capo. I timeout non devono essere troppo brevi (minuti). La penuria di indirizzi spesso si risolve solo quando altri client liberano il pool o il pool viene ampliato.