I. 서 론

지금까지 IETF Mobile IP WG(Working Group)에서는 수 차례에 걸쳐 Mobile IPv6 드래프트에 대한 수정, 개선작업을 해오면서 최종 표준안(RFC)을 만들고자 하였으나, 최근 보안문제가 새롭게 대두되면서 새로운 국면을 맞고 있다고 할 수 있다. 즉, 기존의 Mobile IPv6 드래프트에는 이동환경에서 이동단말이 이동하여 대응노드로 바인딩 업데이트 메시지를 전송할 때, IPsec을 이용하여 메시지를 보호하는 것을 기본으로 하였으나, IPng WG에서도 문제가 되었듯이 글로벌 PKI를 기본으로 하는 IPsec의 도입은 현실적으로 어려움이 있고, 실제로 Mobile IPv6에서 대응노드와 이동노드가 수시로 키를 교환해야 하는 상황에서는 IPsec의 이용은 확장성 및 성능면에서 매우 비효율적이라는 것이 현재의 분석이다.

이러한 보안문제가 해결될 때까지는 최종적인 표준문서(RFC)로의 제정이 지연될 것으로 예상되며, 현재 문제를 해결하고자 하는 다각적인 노력이 진행되고 있다. 최근 여러 개인 드래프트들을 통해서 다각적인 해결 방안이 제시되었으나, 각 방법들의 장단점들 때문에 어떤 방안을 적용할 지에 대해서는 논란의 여지가 많은 상황이다. 이런 상황에서 WG에서는 Mobile IPv6 Design Team을 구성하였고 이후 충분한 논의를 통해 모아진 의견은 Recommendation을 통하여 정리하였고, 다시 토론을 통하여 결론을 정리하였다.

본 문서에서는 현재 Mobile IP WG에서 논의되고 있는 보안 이슈들과 함께, Mobile IPv6 Design Team의 논의 결과와 최근의 논의를 중심으로 만들어진 문서인 16 버전의 드래프트와 이전버전과의 차이를 비교, 분석하였다.

II. Mobile IPv6 보안 이슈

Mobile WG에서는 Mobile IPv6 보안 문제가 제기되면서, 이를 해결하기 위해 Mobile IPv6 Design Team(DT)을 결성하였다. DT는 다음 네 가지 이슈들에 대한 의견을 모으고 솔루션을 찾기 위해 구성되었으며, Mobile WG에서는 몇 주 동안 다음 이슈들을 시작으로 하여 더불어 파생하는 다른 이슈들에 대해서 심층적으로 논의하고 있다.

첫번째 이슈는 이동환경에서 Home Address Option(HAO)를 사용할 때 발생할 수 있는 공격을 어떻게 막을 것인가에 대한 것이고, 둘째는 라우팅 헤더를 사용함으로써 발생할 수 있는 공격을 어떻게 막을 것인가에 대한 것이고, 셋째는 바인딩 업데이트를 수행할 때 발생할 수 있는 공격으로부터 안전하게 바인딩 업데이트를 수행할 수 있는 방법에 관한 것이고 마지막으로, 바인딩을 위한 시그널링 메시지를 전송할 때, 피기백킹 기능을 계속 가능하도록 할 것인지에 대한 것이다.

본 장에서는 위 네 가지 이슈들에 대해서 세부적으로 조사하여 문제의 심각성을 파악하고 DT에서 권고하는 해결 방안들을 분석하고자 한다.

1. Home Address Option(HAO) 문제[1]

HAO를 사용할 경우 발생할 수 있는 보안상의 문제점은 공격자가 DoS(Denial of Service) 공격에 HAO를 사용할 수 있다는 것이다. 정확히 말하자면, HAO는 공격자가 자신의 위치를 숨길 수 있는 방법을 제공한다.

DoS 공격의 기본 시나리오는 다음과 같다. 우선 공격자(attacker)는 공격대상(victim)을 선택한 후, 도달 가능한 다른 IPv6 노드 또는 노드 집합(reflector)을 선택한다. 공격자는 자신의 주소를 IPv6 패킷 헤더의 소스주소와 목적지 주소를 각각 자신의 주소와 reflector 주소로 설정하고, HAO에는 victim의 주소를 넣어 패킷을 전송한다. Reflector는 도착한 IPv6 패킷을 처리하여 응답 메시지를 전송하는데, 수신한 패킷에 HAO을 갖고 있으므로 Mobile IPv6에서 정의하는 HAO 처리방식에 따라서, 소스주소와 HAO의 주소를 교체한다. 따라서, reflector는 victim으로부터 패킷이 보내졌다고 판단하므로, 응답 패킷을 victim으로 전송한다. Victim은 소스주소가 reflector인 패킷을 받게 되고 원래 송신자인 attacker의 주소는 알지 못한다. 따라서 reflector는 의미 없는 패킷들을 수신하게 되고 이 패킷들은 통신 자원을 소모 시킴으로써, reflector의 정상적인 다른 통신을 방해하는 것이다.

DoS 공격을 막는 두 가지 기본 방식은 ingress filtering과 tracing기술이다. Ingress filtering은 소스 주소의 사용을 제한하여 잘못된 주소의 사용을 막는 방식이고 tracing 기술은 공격이 발생한 후에 사용될 수 있는 추적 기법이다. Ingress filtering 방식은 현재의 인터넷 망에서 부분적으로 전개되어 있고 차세대 인터넷 망에서도 지속될 것으로 기대되는 반면 tracing 기술은 아직 널리 분포되지 않아 당분간 사용하기 어렵고, 그 사용시기를 예측하기 힘들다. Tracing 방식을 사용하고자 하는 경우, victim은 진행상황을 파악하기 위해 일정 시간을 기다려야 하고 상대 ISP가 자신의 망을 attacker로부터 보호하기 위해 필터를 설치할 때까지 기다려야 하므로 시간 소비적인 방법이다. 또한, 현재 정의된 tracing 기술로는 DoS attack을 다룰 수 없다. 왜냐하면 일반 tracing 기술은 reflector와 victim에게만 ICMP trace 패킷을 전송하므로 victim은 reflector때문에 attacker의 위치를 알아낼 수 없기 때문이다.

또한, HAO의 정의에 따라서 HAO에 들어가는 주소는 패킷 소스가 위치한 망과 같을 필요가 없으므로, 일반적인 필터링 기법을 사용하는 ingress filtering으로는 이 공격을 막을 수가 없다. 이런 문제를 해결하고자 DT에서는 4가지 대안을 제시하였다.

첫째는 infrastructure-based ingress filtering기법을 사용하는 것이다. 이 방법은 AAA (Authentication, Authorization and Accounting)와 같은 글로벌 infrastructure로 지능적인 ingress filtering을 수행하도록 하는 것이다. 글로벌한 인프라가 필요한 이유는 특정 구역에만 설치된 경우에 일부의 사용자만이 이 개선된 ingress filtering을 사용할 수 있기 때문이다. 즉 인프라에 속하지 않은 사용자들은 Mobile IPv6를 사용하지 않을 것이기 때문에 Mobile IPv6의 전개를 지연시킬 수 있는 요인이 될 수 있으므로, 글로벌 인프라를 구축하지 않는다면 의미가 없다.

두번째 방법은 infrastructure-less ingress filtering 기법을 사용하는 것이다. 현재는 AAA와 같은 글로벌 인프라와 RR(Return Routability)/CGA(Cryptographically Generated Address) 방법들이 address ownership을 보장할 수 있는 유일한 방법으로 알려져 있는데, 이런 방법들을 사용하지 않고 address ownership을 보장할 수 있는 방법을 말한다. 기본 프로세싱은 다음과 같다. 우선, 이동단말은 대응노드로 소스주소가 HoA(Home Address)인 메시지를 전송하면 이 메시지를 라우터에서 가로채어 이동단말로 AR(Authentication Request)를 전송한다. 이동단말은 이 AR에 대해서 address ownership을 보장하기 위해서 라우터를 대응노드와 같다고 가정하고 RR이나 CGA 방법을 사용한 후, 메시지를 재전송하게 된다. 이 방법은 현재의 ingress filtering 모델을 확장하지 않고 사용할 수 있으며, 이론적으로 HAO를 제거하므로 패킷 사이즈가 줄어든다. 하지만 망의 추가적인 지원이 필요하므로 Mobile IPv6의 도입을 지연시킬 수 있으며 프리픽스별로 필터링 규칙을 갖는다면 라우터에서 각 이동단말이 사용할 수 있는 HAO를 추적하기 위해 단말별로 정보를 가져야 할 필요가 있어 확장성에 문제가 있다. 또한 라우터에서 추가적인 프로세싱이 요구되므로 이에 따른 지연이 발생할 수 있으며, 구조적으로 end-to-end 방식과 network-centric 방식 중에서 선택해야 하며 두 방식 모두 확장하기 어렵고 전개가 늦어질 수 있다.

세번째 방법은 대응노드에서 HAO를 갖고 있는 패킷을 수신했을 때, 바인딩 정보 혹은 IPsec SA(Security Association)가 존재하는 경우에만 HAO 처리하도록 제한하는 것이다. 모든 대응노드에서 홈 어드레스의 validity를 체크한 후 HAO를 처리하도록 하는 방식으로 이동단말이 대응노드로 직접 패킷을 전송하기 위해서 대응노드는 이동단말의 상태정보를 갖고 있어야 하며 대응노드에서 authenticated state를 생성하지 않고서는 이동단말에서 대응노드로 패킷을 직접 전송하는 것은 불가능하다. 이 방식은 end-to-end 속성을 갖고 있으며 망에서 지원해야 할 별도의 기능이 필요 없다. 하지만 삼각경로 라우팅이 완전히 제거되어 필요한 경우에도 사용할 수 없게 될 것이며, 바인딩 캐시 엔트리의 속성을 변경해야 하는 단점이 있다. 즉, 현재 Mobile IPv6 규격에서는 바인딩 캐시 엔트리가 삭제되면 응답 패킷을 HA를 거쳐서 라우팅 되도록 지원하는 반면 이 방식에서는, 종료된 바인딩 캐시 엔트리에 해당하는 HAO를 가진 패킷을 수신할 경우 패킷을 버린다. 따라서, 이동단말이 이 사실을 알기 전까지 블랙홀에 빠지게 된다. 이 문제를 해결할 수 있는 방법으로 바인딩 캐시 엔트리와 매치하지 않는 HAO에 대해서 ICMP 에러 메시지를 생성하여 패킷 소스로 전송함으로써, 이 HAO로 인한 추가적인 reflection 문제의 발생을 막을 수 있다.

네번째 방법은 reflected 패킷에 추가적인 정보를 갖도록 처리하는 것이다. 대응노드는 reflected 패킷에 패킷을 생성한 소스 주소를 포함하도록 하기위해 HAO에 대응하는 목적지 옵션을 정의하여 이용하는 방법으로 이를 위해서 Mobile IPv6 표준규격을 수정하는 것은 어렵지 않다. 하지만 이 방식은 예방이 아니라 추적을 위한 것으로서 victim의 ISP는 attacker가 보낸 패킷을 IP 소스 주소를 이용하여 필터링하는 방법으로는 공격을 피할 수 없고 HAO 정보를 보고 필터링을 해야 제대로 걸러낼 수 있다. 즉, 예방이 가능하게 하려면 방화벽에 추가적인 기능을 구현해야 하고, HAO를 포함하는 패킷을 수신하였을 때, 이에 대응하는 옵션을 포함한 응답을 전송하도록 하거나 UDP 응용을 위해서 IPv6 소켓 API를 수정해야 할 필요가 있다.

DT에서는 위 문제에 대해서 세번째 방법을 권고하고 있다. 바인딩 정보 혹은 IPsec SAs가 존재하는 경우에 HAO를 처리하는 방식을 선택하는 것이 Mobile IPv6를 가장 빠르고 넓게 전개할 수 있기 때문이다. 또한, Mobile IPv6의 양방향 터널링과 경로 최적화 부분은 같은 RFC에서 동시에 진행 할 것을 권고하였으며, 경로 최적화는 모든 IPv6 노드에서 구현할 것을 권고하였다.

2. Unverified HAO 처리[2-4]

DT에서 권고하는 방식은 패킷 전송자가 HAO의 HoA에 대한 owner임을 verifying하지 않고 처리하는 것에 있어서 보안의 취약성이 나타남을 고려한 것으로서 Unverified HAO (UnvHAO)의 사용은 권고하지 않았다. 이에 대해서Charlie Perkins는 메일링 리스트를 통해 태그를 이용하여 UnvHAO를 처리하자는 새로운 제안을 하였으나 DT에서는 Mobile IPv6 기본 규격에서 대응노드는 UnvHAO를 처리하지 않아야 하고 UnvHAO 메시지에 대해서 새로운 종류의 error notification을 정의하여 에러 메시지로 응답할 수 있도록 하는 방법을 취하도록 결론지었다. 또한 이 에러메시지를 받은 이동단말은 홈 에이전트를 통해서 bi-directional 터널링으로 패킷을 전송하도록 확장할 것을 권고하였다.

3. 피기백킹(Piggybacking) 문제[5,6]

Mobile IPv6 드래프트 15 버전에서는 바인딩 업데이트/요청/응답 메시지를 다른 패킷에 피기백킹으로 전송할 수 있도록 명시하고 있다. 하지만, 피기백킹으로 전송되는 바인딩 업데이트 메시지를 보호하기 위해서는 IPsec 규격과 구현에 수정이 필요하다.

이런 문제로 피기백킹을 구현함에 있어서 제한을 두는 것은 피기백킹의 상대적인 장점을 고려할 때 비효율적일 수 있다. 따라서 이러한 trade-off를 고려하여 피기백킹 구현을 어떻게 할 것인가에 대한 몇 가지 방법들이 제안되고 있으며 DT에서 권고하는 방식은 다음과 같다.

첫번째 방법은 Mobile IPv6에서 바인딩 업데이트 메시지의 피기백킹을 사용하지 않도록 명시하는 것이다. 피기백킹을 사용하지 않는다면 바인딩 업데이트 메시지를 보호하기 위해 IPsec을 사용할 때 규격이나 구현상으로 제약이 없어지지만 추후에 피기백킹 기능을 추가하는 경우에 모든 노드가 이 기능을 지원할 수 있는 것이 아니기 때문에 송/수신자간에 협상을 필요로 한다.

두번째 방법은 피기백킹을 항상 옵션으로 하도록 명시하는 것으로서, 링크의 종류에 따라서 스루풋과 레이턴시가 개선될 수 있지만, 개선 사항이 링크의 종류에 의존적이며, 피기백킹을 사용함으로써 역효과를 줄 수도 있다. 또한 이런 경우 바인딩 업데이트를 보호하기위해 IPsec을 사용하는 경우, IPsec 규격과 구현상에 확장이 필요하다.

세번째는 통신중인 두 노드간의 협상을 전제로 피기백킹을 옵션으로 명시하는 방법으로 이 방식은 두번째 방법에서 발생할 수 있는 문제, 즉 역효과를 내는 경우를 막을 수 있지만 피기백킹 사용을 협상하기 위한 시그널링을 명시할 필요가 있고 이동단말에서도 추가적인 동작이 요구된다.

DT에서는 IPsec의 확장을 필요로 하는 방법은 권고하지 않으며, IPsec을 사용할 경우라도 RR/CGA를 함께 사용할 것을 권고한다. RR/CGA 방식은 이동단말과 대응노드 사이에 RO (Route Optimization) 과정을 보호하기 위해 사용될 것이다. 바인딩 업데이트/요청/응답 메시지들과 RR/CGA 메시지들은 피기백킹이 아닌 새로운 메시지 집합으로 구현할 것을 권고한다.

4. 라우팅 헤더 문제[7,8]

라우팅 헤더는 Mobile IPv6에서 이동단말로 패킷을 전송할 때 상위계층에 투명하게 통신할 수 있도록 지원하기 위해서 사용된다. 또한, 소스 라우팅에 사용되기 때문에 트래픽 엔지니어링 또는 멀티호밍 같은 환경에서 라우팅 헤더를 이용해서 동적으로 ISP를 선택할 수 있다.

하지만, 현재 Mobile IPv6에서 사용하도록 한 Type 0의 라우팅 헤더는 호스트나 라우터에서 모두 처리 가능하며, 여러 개의 주소를 담아서 전송될 수 있기 때문에 reflection attack에 이용될 수도 있다. 대표적인 attack의 예는 그림에서 보는 바와 같다.

(그림 1)은 웹서버를 목적지로 하는 패킷은 통과시키고 호스트 1을 목적지로 하는 패킷은 막아내는 필터링 규칙을 갖는 방화벽을 attacker가 라우팅 헤더를 이용해 통과하는 예를 보이고 있다. 호스트 1은 목적지를 웹서버로 하고 라우팅 헤더에 호스트 2의 주소를 넣음으로써, 방화벽을 통과하여 웹서버로 패킷을 전달할 수 있고, 라우팅 헤더의 처리 규칙에 따라서 웹서버는 목적지 주소를 호스트 2로 바꿔 내부망에 있는 목적지로 전달할 수 있게 된다. 즉 호스트 1에서 보낸 패킷이 통과해서는 안될 방화벽을 통과하여 호스트 2로 전송되는 경우이다.