[RFC7296] IKEv2 IPsec SPI와 IKE SPI

 

IKE SA

 두 개의 IKE 64-bit SPI들은 유니크하게 IKE SA를 나타냅니다. IKEv2와 함께, IKE_SA_INIT request는 오직 IKE 헤더 안에 로컬하게 유니크한 initiater SPI set을 가집니다. 그 응답자는 해당 응답에서 로컬하게 고유 값으로 설정합니다. 두 개의 SPI는 IKE SA가 rekey할 때만 변경됩니다.

 

 IKE 헤더의 두 필드는 이제 initiator / responder SPI라고 불리는 IKE 2408 (ISAKMP)에서 이전에 initiator / responder 쿠키라고 했습니다. IKEv2는 COOKIE notification payload들을 사용하여 서비스 거부 공격을 방해하기 위해 혼란을 줄 수 있습니다.

 

 

IPSEC SA

 하나의 32-bit SPI는 반(?)-독특하게 IPsec SA를 나타냅니다. 이것들의 SA들은 단방향(unidirectional)성을 지닙니다.

그 때문에, ESP/AH 헤더는 목적지의 inbound SA에 대한 오직 SPI를 포함합니다. (IKE 헤더가 항상 두개 모두 SPI를 포함하는 것과 달리)

 

 SPI들은 로컬하게 독특하기 떄문에, SPI와 목적지 주소는 보통 독특하게 SA를 식별하는 데 충분합니다. 하지만, 그것은 문제가 있을 수 있습니다. 예를들어, 같은 NAT를 둔 두 개의 클라이어트가, 같은 로컬 SPI에 할당한 경우, (그들이 같은 VPN gateway를 연결한 상황에서)

 

 SPI 및 목적지 주소의 조합은 NAT의 공공 측면에서 동일합니다. 이는 UDP 캡슐화가 필요한 이유입니다.UDP 포트는 NAT가 inbound packet들을 알맞은 클라이언트로 가리키게 합니다. 비슷하게, gateway는 각 클라이언트에 트래픽을 보낼 때, 올바른 SA가 사용되도록 두개의 SAs를 차별화하기 위한 조치를 취해야합니다.

 

Q. 한 쪽에 설정한 SPI는 incoming SA를 위해 사용되는 SPI입니까? 아니면 outgoing SA를 위한겁니까?A. incoming SA를 위해 사용되는 SPI입니다. 각각의 peer는 그것의 inbound SA를 위한 SPI를 다른 피어에게 보냅니다.

 

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)

 

 추가적으로, 두개의 피어들은 TS(Traffic Selector)들을 교환합니다. 그것은 네트워크 트래픽(설립된 SA에 의해 커버할) 을 구체화한 것 입니다.

 

 SAD_UPDATE는, "SPI를 x로 업데이트 해주세요, SPI 를 y로 셋팅해주세요"

 

 저것은 SA_UPDATE 한게 아니다. 그건 사실, SPI를 바꾸지 않는다, 전혀. 하지만, SA의 다른 측면 중 모든 (또는 일부)이며, 이들은 주로 암호화 / 무결성 알고리즘과 키 (그러나 캡슐화와 같은 다른 것들을 포함할 수 도 있음)입니다.

 

 당신이 inbound SA들을 위해, 간단하게 SAD_ADD 대신에 정말로 SAD_GETSPI 그리고 SAD_UPDATE를 call하는 걸 원하는 이유는 (심지어 응답자에서 (모든 정보가 가능하다)) SAD가 보통 OS의 커널에서 관리되기 떄문입니다, 반면에 IKE 데몬은 User land에서 동작하죠.

 그러므로, SAD_GETSPI를 부르는 것은 SPI가 사실 지역적으로 독특하다는 걸 보장할 것입니다.

보장되지 않는 것 (만약 즉, 두 개의 IKE 데몬들 혹은 심지어 수작업으로 SA들을 관리하는 툴, (ip xfrm 혹은 setkey와 같은)은 병행적으로 시스템에 사용되는 것입니다.

 

 하지만, 어떤 시스템 위에서, SPI를 구체화하는 것 없이 응답자가 SAD_ADD를 부르는 걸 허용하는 단순화가 있을 수 있습니다, 그리고 SAD는 그러면 그것을 할당하고, SA를 설치하고, 그리고 새로운 SPI를 반환하죠.

 하지만, keying deamon에 의해, 이 특정한 케이스를 위해 특별한 핸들링을 요구합니다. (반면에, 그것은 심플하게 outbound SA들으 위해 SAD_ADD를 부를 수 있죠, 그리고 SAD_GETSPI/SAD_UPDATE 

 

 

참고자료

https://security.stackexchange.com/questions/56434/understanding-the-details-of-spi-in-ike-and-ipsec