5.1. Traffic Selector Authorization
5.1. Traffic Selector Authorization
IKEv2 s'appuie sur les informations de la PAD (Peer Authorization Database, base de données d'autorisation des pairs) pour déterminer quels types de Child SA un pair est autorisé à créer. Ce processus est décrit à la section 4.4.3 de [IPSECARCH]. Lorsqu'un pair demande la création d'une Child SA avec certains sélecteurs de trafic (Traffic Selectors), la PAD doit contenir des « Child SA Authorization Data » reliant l'identité authentifiée par IKEv2 et les adresses autorisées pour les sélecteurs de trafic.
Par exemple, la PAD peut être configurée de sorte que l'identité authentifiée « sgw23.example.com » soit autorisée à créer des Child SA pour 192.0.2.0/24, ce qui signifie que cette passerelle de sécurité est un « représentant » valide pour ces adresses. L'IPsec hôte à hôte exige des entrées similaires, par exemple liant « fooserver4.example.com » à 198.51.100.66/32, ce qui signifie que cette identité est un « propriétaire » ou « représentant » valide de l'adresse concernée.
Comme indiqué dans [IPSECARCH], « il est nécessaire d'imposer ces contraintes à la création des child SA pour empêcher un pair authentifié de usurper des identifiants associés à d'autres pairs légitimes ». Dans l'exemple ci-dessus, une PAD correctement configurée empêche sgw23 de créer des Child SA avec l'adresse 198.51.100.66 et empêche fooserver4 de créer des Child SA avec des adresses de 192.0.2.0/24.
Il est important de noter que le simple envoi de paquets IKEv2 avec une adresse particulière n'implique pas la permission de créer des Child SA avec cette adresse dans les sélecteurs de trafic. Par exemple, même si sgw23 pouvait usurper son adresse IP en 198.51.100.66, il ne pourrait pas créer des Child SA correspondant au trafic de fooserver4.
La spécification IKEv2 ne précise pas exactement comment l'attribution d'adresses IP au moyen des charges utiles de configuration interagit avec la PAD. Notre interprétation est la suivante : lorsqu'une passerelle de sécurité attribue une adresse via des charges utiles de configuration, elle crée aussi une entrée PAD temporaire reliant l'identité du pair authentifié et la nouvelle adresse interne attribuée.
Il a été reconnu que la configuration correcte de la PAD peut être difficile dans certains environnements. Par exemple, si l'IPsec est utilisé entre deux hôtes dont les adresses sont attribuées dynamiquement par DHCP (Dynamic Host Configuration Protocol), il est extrêmement difficile de garantir que la PAD indique le bon « propriétaire » pour chaque adresse IP. Il faudrait un mécanisme pour transmettre de façon sûre les attributions depuis le serveur DHCP et les lier aux identités authentifiées par IKEv2.
En raison de cette limitation, certains fournisseurs ont configuré leurs PAD pour autoriser un pair authentifié à créer des Child SA dont les sélecteurs de trafic contiennent la même adresse que celle utilisée pour les paquets IKEv2. Dans les environnements où l'usurpation d'IP est possible (c'est-à-dire presque partout), cela permet en pratique à tout pair de créer des Child SA avec n'importe quels sélecteurs de trafic. Ce n'est pas une configuration appropriée ni sûre dans la plupart des cas. Voir [H2HIPSEC] pour une analyse approfondie de cette question et des limites générales de l'IPsec hôte à hôte.