Los
índices de parámetros de seguridad (SPI) pueden significar cosas diferentes cuando se refieren a las asociaciones de seguridad (SA) IKE e IPsec:
-
Para IKE dos SPI de 64 bits identifican de forma única a una IKE SA. Con IKEv2 la solicitud IKE_SA_INIT solo tendrá el SPI iniciador único localmente establecido en el encabezado IKE, el SPI del respondedor es cero . El respondedor establecerá eso en un valor igualmente localmente único en su respuesta. Los dos SPI solo cambiarán cuando IKE SA se modifique.
Los dos campos en el encabezado IKE que ahora se llaman SPI iniciador / respondedor se llamaron anteriormente Cookie de iniciador / respondedor en RFC 2408 (ISAKMP). Esto podría ser confuso, ya que IKEv2 utiliza las cargas de notificación de COOKIE para impedir ataques de denegación de servicio .
-
Para IPsec , un SPI de 32 bits identifica de manera semi-única una IPsec SA. Dado que estos SA son unidireccionales, el encabezado ESP / AH contiene solo el SPI del SA entrante del destino (a diferencia del encabezado IKE que siempre contiene ambos SPI). Dado que los SPI son localmente únicos, esto y la dirección de destino suele ser suficiente para identificar de forma única una SA. Pero podría ser problemático, por ejemplo. si dos clientes detrás del mismo NAT asignan el mismo SPI local cuando se conectan a la misma puerta de enlace VPN. La combinación de SPI y dirección de destino sería la misma en el lado público del NAT, por lo que se requiere encapsulación UDP . Los puertos UDP permiten que el NAT dirija los paquetes entrantes al cliente correcto. Del mismo modo, la puerta de enlace debe tomar medidas para diferenciar las dos SA para que se use la SA correcta al enviar el tráfico a cada cliente.
¿Significa esto que el SPI que establece una parte es el SPI utilizado para las SA entrantes, no el saliente?
Sí, cada par envía el SPI de su SA entrante al otro par.
Además, mis notas dicen que el iniciador usa el método SAD_ADD mientras que el respondedor usa SAD_GETSPI y SAD_UPDATE .
El proceso de establecer una SA de IPsec usando, por ejemplo, un intercambio de CREATE_CHILD_SA en IKEv2 se podría visualizar aproximadamente de esta manera:
Initiator Responder
SAD_GETSPI (inbound SA) -----------> {select algorithms and derive keys}
SAD_ADD (outbound SA)
SAD_GETSPI (inbound SA)
{derive keys} <----------- SAD_UPDATE (inbound SA)
SAD_UPDATE (inbound SA)
SAD_ADD (outbound SA)
- El iniciador envía el SPI de su SA entrante junto con una propuesta de algoritmos criptográficos y, si se utiliza el secreto perfecto hacia adelante, su factor Diffie-Hellman, al respondedor.
- El respondedor selecciona los algoritmos adecuados y deriva las claves (opcionalmente usando DH) y procede a instalar los SA.
- Luego devuelve su SPI entrante junto con los algoritmos seleccionados (y opcionalmente su factor DH) al iniciador, que ahora puede instalar las SA en su lado.
Además, los dos pares intercambian selectores de tráfico que especifican el tráfico de red que debe cubrir la SA establecida.
SAD_UPDATE : "Actualice SPI x, configure SPI en y".
Eso no es lo que SAD_UPDATE hace. En realidad, no cambia el SPI en absoluto, sino todos (o algunos) de los otros aspectos del SA, y estos son principalmente los algoritmos y claves de cifrado / integridad (pero también pueden incluir otras cosas, como encapsulation o el tamaño de la ventana anti-repetición).
La razón por la que normalmente desea llamar a SAD_GETSPI y SAD_UPDATE en lugar de simplemente SAD_ADD para las SA entrantes (incluso en el respondedor, donde toda la información estaría disponible) es que el SAD generalmente es administrado por el operador El núcleo del sistema, mientras que los demonios IKE operan en la zona de usuario. Y por lo tanto, llamar a SAD_GETSPI asegurará que el SPI sea realmente localmente único. Lo cual podría no estar garantizado si, por ejemplo, dos daemons IKE (para IKEv1 e IKEv2) o incluso herramientas para administrar manualmente las SA (como ip xfrm o setkey ) se usan simultáneamente en un sistema.
Pero es imaginable que en algunos sistemas podría haber una simplificación que permitiría a un respondedor llamar a SAD_ADD sin especificar un SPI, y el SAD asignaría uno, instalaría el SA y devolvería el nuevo SPI. Pero eso requeriría un manejo especial para este caso en particular por parte del demonio de claves (de lo contrario, podría simplemente llamar a SAD_ADD para las SA salientes y a SAD_GETSPI/SAD_UPDATE para las SA entrantes, sin importar si lo hace como iniciador o respondedor).
RFC 2367 (PF_KEYv2) proporciona más información sobre estas operaciones.