3.15. Configuration Payload

Le Configuration payload, désigné CP dans le présent document, sert à échanger des informations de configuration entre pairs IKE. L'échange permet à un IRAC de demander une adresse IP interne à un IRAS et d'échanger d'autres informations du type de celles qu'on obtiendrait avec le Dynamic Host Configuration Protocol (DHCP) si l'IRAC était directement connecté à un LAN.

Le Configuration payload est défini comme suit :

                    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                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 22 : Format du Configuration payload

Le type de charge utile pour le Configuration payload est quarante-sept (47).

CFG Type (1 octet) - Le type d'échange représenté par les Configuration Attributes. Les valeurs du tableau suivant ne sont à jour qu'à la date de publication du RFC 4306. D'autres valeurs ont pu être ajoutées depuis. Les lecteurs doivent consulter [IKEV2IANA] pour les valeurs les plus récentes.

CFG Type	Valeur
CFG_REQUEST	1
CFG_REPLY	2
CFG_SET	3
CFG_ACK	4

RESERVED (3 octets) - DOIT être envoyé à zéro ; DOIT être ignoré à la réception.
Configuration Attributes (longueur variable) - Structures type-longueur-valeur (TLV) propres au Configuration payload, définies ci-dessous. Il peut y avoir zéro ou plusieurs Configuration Attributes dans cette charge utile.

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                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 23 : Format du Configuration attribute

Reserved (1 bit) - Ce bit DOIT être à zéro et DOIT être ignoré à la réception.
Attribute Type (15 bits) - Identifiant unique pour chaque type de Configuration Attribute.
Length (2 octets, entier non signé) - Longueur en octets de la valeur.
Value (0 octet ou plus) - Valeur à longueur variable de ce Configuration Attribute. Les types d'attribut suivent.

Les valeurs du tableau suivant ne sont à jour qu'à la date de publication du RFC 4306 (sauf INTERNAL_ADDRESS_EXPIRY et INTERNAL_IP6_NBNS, supprimés par le RFC 5996). D'autres valeurs ont pu être ajoutées. Voir [IKEV2IANA].

Attribute Type	Valeur	Multi-valeur	Longueur
INTERNAL_IP4_ADDRESS	1	YES*	0 ou 4 octets
INTERNAL_IP4_NETMASK	2	NO	0 ou 4 octets
INTERNAL_IP4_DNS	3	YES	0 ou 4 octets
INTERNAL_IP4_NBNS	4	YES	0 ou 4 octets
INTERNAL_IP4_DHCP	6	YES	0 ou 4 octets
APPLICATION_VERSION	7	NO	0 ou plus
INTERNAL_IP6_ADDRESS	8	YES*	0 ou 17 octets
INTERNAL_IP6_DNS	10	YES	0 ou 16 octets
INTERNAL_IP6_DHCP	12	YES	0 ou 16 octets
INTERNAL_IP4_SUBNET	13	YES	0 ou 8 octets
SUPPORTED_ATTRIBUTES	14	NO	Multiple de 2
INTERNAL_IP6_SUBNET	15	YES	17 octets

* Ces attributs peuvent être multi-valués en retour seulement si plusieurs valeurs ont été demandées.

INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Une adresse sur le réseau interne, parfois appelée adresse nœud rouge ou adresse privée ; PEUT être une adresse privée sur Internet. Dans un message de demande, l'adresse indiquée est une adresse demandée (ou une adresse de longueur zéro si aucune adresse spécifique n'est demandée). Si une adresse spécifique est demandée, cela indique souvent qu'une connexion antérieure utilisait cette adresse et que le demandeur souhaite la réutiliser. Avec IPv6, un demandeur PEUT fournir les octets de poids faible d'adresse souhaités. Plusieurs adresses internes PEUVENT être demandées via plusieurs attributs d'adresse interne. Le répondant NE PEUT envoyer qu'au plus le nombre d'adresses demandées. INTERNAL_IP6_ADDRESS comprend deux champs : le premier est une adresse IPv6 de 16 octets, le second est une longueur de préfixe d'un octet comme défini dans [ADDRIPV6]. L'adresse demandée reste valide tant que cette IKE SA (ou ses successeurs après rekey) qui l'a demandée est valide. Voir la section 3.15.3.
INTERNAL_IP4_NETMASK - Le masque de réseau du réseau interne. Un seul masque est autorisé dans les messages de demande et de réponse (par ex. 255.255.255.0), et il DOIT être utilisé uniquement avec un attribut INTERNAL_IP4_ADDRESS. INTERNAL_IP4_NETMASK dans un CFG_REPLY signifie à peu près la même chose qu'un INTERNAL_IP4_SUBNET portant la même information (« envoyer le trafic vers ces adresses par moi »), mais implique aussi une limite de lien. Par exemple, le client peut utiliser sa propre adresse et le masque pour calculer l'adresse de diffusion du lien. Un attribut INTERNAL_IP4_NETMASK vide peut être inclus dans un CFG_REQUEST pour demander cette information (la passerelle peut l'envoyer même sans demande). Des valeurs non vides pour cet attribut dans un CFG_REQUEST n'ont pas de sens et NE DOIVENT PAS être incluses.
INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Spécifie l'adresse d'un serveur DNS dans le réseau. Plusieurs serveurs DNS PEUVENT être demandés. Le répondant PEUT répondre avec zéro ou plusieurs attributs de serveur DNS.
INTERNAL_IP4_NBNS - Spécifie l'adresse d'un serveur de noms NetBios (WINS) dans le réseau. Plusieurs serveurs NBNS PEUVENT être demandés. Le répondant PEUT répondre avec zéro ou plusieurs attributs de serveur NBNS.
INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Indique à l'hôte d'envoyer toute demande DHCP interne à l'adresse contenue dans l'attribut. Plusieurs serveurs DHCP PEUVENT être demandés. Le répondant PEUT répondre avec zéro ou plusieurs attributs de serveur DHCP.
APPLICATION_VERSION - La version ou les informations d'application de l'hôte IPsec. Chaîne de caractères ASCII imprimables NON terminée par un caractère nul.
INTERNAL_IP4_SUBNET - Les sous-réseaux protégés que ce périphérique de bord protège. L'attribut comprend deux champs : une adresse IP et un masque de réseau. Plusieurs sous-réseaux PEUVENT être demandés. Le répondant PEUT répondre avec zéro ou plusieurs attributs de sous-réseau. Voir la section 3.15.2.
SUPPORTED_ATTRIBUTES - Dans une Request, cet attribut DOIT être de longueur zéro et demande au répondant de renvoyer tous les attributs qu'il prend en charge. La réponse contient un attribut avec un ensemble d'identifiants d'attribut de 2 octets chacun. La longueur divisée par 2 (octets) donne le nombre d'attributs pris en charge dans la réponse.
INTERNAL_IP6_SUBNET - Les sous-réseaux protégés que ce périphérique de bord protège. Deux champs : adresse IPv6 sur 16 octets et longueur de préfixe d'un octet selon [ADDRIPV6]. Plusieurs sous-réseaux PEUVENT être demandés. Le répondant PEUT répondre avec zéro ou plusieurs attributs de sous-réseau. Voir la section 3.15.2.

Le présent document ne recommande aucune méthode précise permettant à une implémentation de décider quelles informations envoyer dans une réponse ; en particulier, aucune méthode spécifique n'est recommandée pour qu'un IRAS détermine quel serveur DNS renvoyer à un IRAC demandeur.

La paire CFG_REQUEST et CFG_REPLY permet à un point d'extrémité IKE de demander des informations à son pair. Si un attribut du Configuration payload CFG_REQUEST n'est pas de longueur zéro, il est pris comme suggestion pour cet attribut. Le Configuration payload CFG_REPLY PEUT renvoyer cette valeur ou une nouvelle ; il PEUT aussi ajouter de nouveaux attributs et omettre certains demandés. Les attributs non reconnus ou non pris en charge DOIVENT être ignorés dans les demandes et les réponses.

La paire CFG_SET et CFG_ACK permet de pousser des données de configuration vers le pair. Le Configuration payload CFG_SET contient les attributs que l'initiateur souhaite que son pair modifie. Le répondant DOIT renvoyer un Configuration payload s'il a accepté des données de configuration, et ce payload DOIT contenir les attributs acceptés avec des données de longueur zéro. Les attributs non acceptés NE DOIVENT PAS figurer dans le Configuration payload CFG_ACK. Si aucun attribut n'est accepté, le répondant DOIT renvoyer soit un payload CFG_ACK vide, soit une réponse sans payload CFG_ACK. Aucun usage défini n'existe actuellement pour l'échange CFG_SET/CFG_ACK, bien qu'ils puissent servir avec des extensions basées sur des Vendor ID. Une implémentation de cette spécification PEUT ignorer les payloads CFG_SET.

3.15.2. Signification de INTERNAL_IP4_SUBNET et INTERNAL_IP6_SUBNET

Les attributs INTERNAL_IP4/6_SUBNET peuvent indiquer des sous-réseaux supplémentaires, atteignables via la passerelle qui annonce les attributs et nécessitant une ou plusieurs SA distinctes. Ils peuvent aussi exprimer la politique de la passerelle sur le trafic devant transiter par elle ; le client peut choisir d'envoyer le reste du trafic (couvert par TSr mais pas par INTERNAL_IP4/6_SUBNET) via la passerelle ou directement vers la destination. Le trafic vers les adresses listées dans INTERNAL_IP4/6_SUBNET devrait transiter par la passerelle qui annonce les attributs. S'il n'existe pas de Child SA dont les Traffic Selectors couvrent l'adresse concernée, de nouvelles SA doivent être créées.

Par exemple, avec deux sous-réseaux 198.51.100.0/26 et 192.0.2.0/24, si la demande du client contient :

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)

une réponse valide pourrait être (TSr et INTERNAL_IP4_SUBNET portent la même information) :

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))

Dans ces cas, INTERNAL_IP4_SUBNET n'apporte guère d'information utile.

Une autre réponse possible :

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)

Cela signifie que le client peut envoyer tout son trafic via la passerelle, mais la passerelle n'interdit pas au client d'envoyer directement à la destination le trafic non couvert par INTERNAL_IP4_SUBNET (sans passer par la passerelle).

Si la politique de la passerelle exige des SA séparées pour les deux sous-réseaux, une réponse comme celle-ci indique au client qu'un accès au second sous-réseau nécessite une SA distincte :

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 est aussi utile si le TSr du client ne couvre qu'une partie de l'espace d'adressage. Par exemple :

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)

La réponse de la passerelle pourrait être :

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)

Comme la signification de INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET dans les CFG_REQUEST est peu claire, ils ne peuvent pas être utilisés de façon fiable dans les CFG_REQUEST.

3.15.3. Configuration payloads pour IPv6

Les Configuration payloads pour IPv6 s'appuient sur les payloads IPv4 correspondants et ne suivent pas entièrement la « façon IPv6 habituelle ». En particulier, pas d'autoconfiguration IPv6 sans état ni messages de routeur, ni découverte de voisins. Un document additionnel traite la configuration IPv6 dans IKEv2, [IPV6CONFIG]. Pour l'instant expérimental, il pourrait à terme recevoir le même statut normatif que le présent document.

Un client peut recevoir une adresse IPv6 via le Configuration payload INTERNAL_IP6_ADDRESS. Un échange minimal peut ressembler à :

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)

Le client PEUT envoyer un attribut INTERNAL_IP6_ADDRESS non vide dans le CFG_REQUEST pour demander une adresse ou un identifiant d'interface spécifique. La passerelle vérifie d'abord si l'adresse est acceptable et, si oui, la renvoie. Sinon, elle tente d'utiliser l'identifiant d'interface avec un autre préfixe ; si cela échoue, elle en choisit un autre.

L'attribut INTERNAL_IP6_ADDRESS contient aussi un champ de longueur de préfixe. Dans un CFG_REPLY, cela correspond à l'attribut INTERNAL_IP4_NETMASK en IPv4.

Bien que simple, cette approche a des limites. Les tunnels IPsec configurés avec IKEv2 ne sont pas des « interfaces » complètes au sens de l'architecture d'adressage IPv6 [ADDRIPV6]. En particulier, ils n'ont pas nécessairement d'adresses lien-local, ce qui peut compliquer des protocoles qui les supposent, comme [MLDV2].

3.15.4. Échecs d'attribution d'adresse

Si le répondant rencontre une erreur en tentant d'attribuer une adresse IP à l'initiateur pendant le traitement d'un Configuration payload, il répond par une notification INTERNAL_ADDRESS_FAILURE. L'IKE SA est tout de même créée même si la Child SA initiale ne peut pas l'être à cause de cet échec. Si l'erreur survient dans un échange IKE_AUTH, aucune Child SA n'est créée. D'autres cas d'erreur plus complexes existent.

Si le répondant ne prend pas en charge les Configuration payloads, il peut ignorer tous les Configuration payloads. Ce type d'implémentation n'envoie jamais de notification INTERNAL_ADDRESS_FAILURE.

Si l'initiateur exige l'attribution d'une adresse IP, il traitera une réponse sans CFG_REPLY comme une erreur.

L'initiateur peut demander un type d'adresse (IPv4 ou IPv6) que le répondant ne prend pas en charge, même si ce dernier prend en charge les Configuration payloads. Le répondant ignore alors ce type et traite le reste de la demande comme d'habitude.

Si l'initiateur demande plusieurs adresses d'un type pris en charge et que certaines (mais pas toutes) échouent, le répondant ne renvoie que les adresses attribuées avec succès. INTERNAL_ADDRESS_FAILURE n'est envoyé que si aucune adresse ne peut être attribuée.

Si l'initiateur ne reçoit pas la ou les adresses IP exigées par sa politique, il PEUT conserver l'IKE SA et réessayer le Configuration payload dans un échange INFORMATIONAL séparé après un délai adapté, ou il PEUT détruire l'IKE SA en envoyant un Delete payload dans un échange INFORMATIONAL séparé puis relancer une IKE SA depuis le début après un délai. Ce délai ne doit pas être trop court (surtout si l'IKE SA repart de zéro), car ces erreurs peuvent ne pas se corriger rapidement ; plusieurs minutes sont raisonnables. Par exemple, une pénurie d'adresses côté répondant ne sera probablement résolue que lorsque d'autres clients libèrent des entrées dans le pool ou que le répondant agrandit son pool.