대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 Mobile IPv6 표준화 및 기술 동향
등록일 조회수 6066
첨부파일  

Mobile IPv6 표준화 및 기술 동향

Mobile IPv6 기술은 네트워크 계층에서 단말의 이동성을 지원하고자 하는 기술로서 현재 매우 활발한 표준화가 진행중인 분야이다. 본 고에서는 단말의 이동성 측면에서의 프로토콜 진화과정, Mobile IPv6환경에서의 보안 취약성과 이에 대한 보호 방안 그리고 현재 IETF에서 Mobile IPv6 보안과 관련된 주요 이슈를 살펴보고자 한다.

목 차
I. 서론
II. 이동프로토콜의 진화
III. MIPv6 환경의 보안 취약성
IV. MIPv6 보안 방안
V. MIPv6 보안 표준화 이슈
VI. 결론

I. 개 요

IETF Internet area의 mip6 워킹그룹은 IPv6 네트워크 계층에서의 단말의 이동성을 지원하고자 하는 프로토콜 제정 그룹으로서, IPv6 호스트가 자신의 영구적인 홈 주소를 갖고 인터넷을 움직일 수 있도록 하는 라우팅 기술을 제공하는 것이 목표이다. Mobile IPv6기술은 IP layer 상위의 프로토콜에 투명하게 동작하며, 활성화된 TCP 연결과 UDP 포트 바인딩의 끊김없이 IPv6 호스트의 이동성을 제공하는 기술이다. 이동통신의 양대 표준 기구인 3GPP와 3GPP2의 표준에서는 이동인터넷 환경의 표준으로 Mobile IPv6를 채택하였다. 이는 Mobile IPv6 기술이 갖는 특징들 즉, 이동통신의 최대 약점이라고 할 수 있는 정보보호 기능의 안정적인 제공, 충분한 주소공간의 확보로 인한 각종 전자제품의 효율적인 네트워크화, 플러그&플레이 방식의 자동 네트워킹 방식 지원 그리고 최적화된 라우팅 패스 설정을 통한 효율적인 네트워킹 제공 등의 장점 때문이라 볼 수 있다. 현재 Mobile IPv6관련 주요 이슈는 보안문제에 집중되어 있는 상황이다 .

본 고에서는 Mobile IPv6 표준화 및 기술 동향을 살펴보고자 한다. 우선 단말의 이동성 측면에서의 프로토콜 진화과정을 기술하고, Mobile IPv6환경에서의 보안 취약성과 이에 대한 보호 방안에 대해 분석하였다. 마지막으로 IETF mip6 워킹그룹에서 최근 이슈화되고 있는 Bootstrapping, Mobike 그리고 IPv6 접속망의 보안 문제를 해결하기 위한 SEND 프로토콜 등에 대한 동향과 전망을 기술하였다.

II. 이동프로토콜의 진화

최근들어 유선망에 고정된 호스트들이 연결되던 고전적 형태의 인터넷은 유선망과 무선망이 연동되고 노드가 망 사이를 옮겨 다니며 통신을 수행하는 이동노드를 지원할 수 있도록 진화하고 있다. 인터넷에서 이러한 단말의 이동성을 지원하기 위해서 개발된 프로토콜이 Mobile IP이다. 계속되는 절에서는 IPv4와 IPv6망에서 단말의 이동성을 지원하기 위해 개발된 Mobile IPv4와 Mobile IPv6에 대해서 간략하게 살펴본다.

1. Mobile IPv4

Mobile IPv4는 IPv4망에서 노드의 이동성을 지원한다. 즉, Mobile IPv4 프로토콜을 이용한다면 IPv4 노드는 기존에 수행하고 있던 통신의 끊김없이 망 사이를 자유롭게 이동할 수 있게 된다. Mobile IPv4에서는 이동노드(Mobile Node: MN)의 홈 링크에 위치하여 이동노드 대신 패킷을 수신하여 이동노드가 위치한 링크로 패킷을 전달해 주는 홈 에이전트(Home Agent: HA)와 이동노드가 방문한 링크에서 홈 에이전트로부터 전송된 패킷을 받아 이동노드로 전달하는 FA(Foreign Agent)가 필요하다. (그림 1)은 이러한 Mobile IPv4의 동작을 개략적으로 보여준다. IPv4 프로토콜 자체는 설계 당시에 이동성이나 확장성 등을 고려하지 않고 설계가 되었다. 따라서 노드의 이동을 지원하는 데에 있어서 부자연스러우며, 다음과 같은 사항들이 주요 문제로 지적되고 있다.

가. Triangle Routing

외부 네트워크에 위치한 MN은 통신하려는 상대노드에게 직접 패킷을 전송할 수 있다. 그러나 상대노드가 외부 네트워크에 위치한 이동노드로 패킷을 전달할 때에는 이동노드의 홈 네트워크에 위치한 홈 에이전트를 거쳐 터널링되어 전달된다. 이와 같이 상대노드가 전송한 패킷이 이동노드로 직접 전달되지 못하고 항상 홈 에이전트를 거쳐서 전달되는 현상을 Triangle Routing이라고 하며, 이는 통신의 효율성을 떨어뜨린다.

나. Ingress Filtering

보안상의 이유로 최근의 많은 라우터들은 ingress filtering이라는 정책을 수행하도록 구성되고 있다. Ingress filtering은 합당하지 않은 발신지 주소를 가진 패킷이 포워딩되지 않도록 차단하는 기능이다. 만약 FA가 ingress filtering을 수행하고 있을 때 이동노드가 자신의 홈 주소를 발신지로 하여 패킷을 전송한다면 홈 주소는 이동노드가 위치한 네트워크에 속한 주소가 아니므로 FA는 패킷을 폐기해 버린다. Mobile IPv4에서 ingress filtering을 수행하는 라우터를 통과하여 이동노드가 패킷을 전달하기 위해서 이동노드는 CoA(Care of Address)를 발신지 주소로 하여 역터널링된 패킷을 생성하여 전송하여야 한다.

2. Mobile IPv6

Mobile IPv6의 동작은 근본적으로 Mobile IPv4에서의 동작과 비슷하지만 Mobile IPv4를 통해 얻어진 경험과 IPv6가 제공하는 특징들을 반영하도록 설계되어 좀 더 자연스럽고 효과적으로 IPv6 노드의 이동성을 지원할 수 있다.

IPv6 노드가 홈 링크를 벗어나 다른 링크에 접속되면 해당 노드는 Mobile IPv4에서와 마찬가지로 방문한 링크에서 사용할 임시주소인 CoA를 얻게 되며, 이 주소를 자신의 홈 링크상에 위치한 홈 에이전트에게 등록한다. CoA를 홈 에이전트에 등록한 후에 이동노드의 홈 주소를 목적지로 가지는 패킷이 전달되면 홈 에이전트가 이동노드를 대신하여 패킷을 수신한다. 홈 에이전트는 수신한 패킷을 CoA를 목적지로 터널링하여 이동노드가 위치한 링크로 전달하며, 이동노드는 터널링 헤더를 제거하고 원래 패킷을 얻어낸다. 반대로 이동노드가 상대노드로 패킷을 전송할 경우에 최초의 패킷전송은 홈 에이전트로의 역터널링을 거쳐서 상대노드로 전달된다. 이때 상대노드는 RR(Return Routability)라는 방식을 통해 MN의 CoA를 등록하며, 상대노드에 CoA가 등록된 이후에는 두 노드가 홈 에이전트를 거치지 않고 직접 통신을 수행할 수 있다. (그림 2)는 Mobile IPv6의 동작을 개략적으로 보여주고 있다.


Mobile IPv6의 기본 동작 및 개념은 외부 네트워크에서 사용할 임시주소인 CoA를 홈네트워크에 존재하는 라우터에 등록하여 노드의 이동성을 지원한다는 점에서 Mobile IPv4와 근본적으로 비슷하지만 다음과 같은 몇 가지 큰 차이를 가진다.

가. FA가 불필요

Mobile IPv4에서는 일반적으로 FA의 주소를 이동노드의 CoA로 사용하며 FA는 해당 링크에서 이동노드를 대신하여 패킷을 수신한 후 이동노드에게 전달하는 이동성 서비스를 제공해 준다. 만약 FA를 사용하지 않는다면 각 링크는 이동노드가 CoA로 사용할 IPv4 address pool을 유지, 관리해야 하는데 부족한 IPv4 주소를 고려한다면 바람직한 방법이 아니다. 하지만 Mobile IPv6는 충분한 주소 공간을 가지고 있으며, IPv6 노드는 주소를 자동 생성할 수 있다. 따라서 Mobile IPv6에서는 FA와 같은 별도의 에이전트를 통해서 이동성을 제공하지 않고 이동노드가 직접 CoA를 생성하여 사용한다.

나. Routing optimization

Mobile IPv4에서는 상대노드가 외부링크에 위치한 이동노드로 패킷을 전달하기 위해서 이동노드의 홈링크에 위치한 홈 에이전트를 반드시 경유해야 했다. Mobile IPv6에서도 상대노드가 외부링크에 위치한 이동노드로 패킷을 최초로 전달할 때에는 홈 에이전트를 경유해야 한다. 하지만 이동노드의 CoA가 홈 에이전트와 상대노드에 등록된 후에는 이동노드와 상대노드의 통신은 홈 에이전트를 경유하지 않고 직접 이루어질 수 있다.

다. Ingress filtering

Mobile IPv6에서 이동노드는 해당 링크에 속해 있는 주소인 CoA를 발신지로 하여 전송한다. Ingress filtering을 수행하는 라우터를 통과하여 목적지까지 전달될 수 있다.

III. MIPv6 환경의 보안 취약성

이동 프로토콜이 IPv6 네트워크로 진화함에 따라 Mobile 워킹그룹에서는 Mobile IPv6에 대한 보안 문제가 제기되었다. 문제점으로 지적된 보안 이슈들은 크게 3가지로 구분되며 해당 보안 이슈들은 다음과 같다.

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

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

이러한 문제점을 해결하기 위해 대응노드에서 HAO를 갖고 있는 패킷을 수신했을 때, 바인딩 정보 혹은 IPsec SA(Security Association)가 존재하는 경우에만 HAO를 처리하도록 제한하는 방식을 사용한다.

두번째 보안 이슈로서, 라우팅 헤더는 Mobile IPv6에서 이동노드로 패킷을 전송할 때 상위계층에 투명하게 통신할 수 있도록 지원하기 위해서 사용된다. 또한, 소스 라우팅에 사용되기 때문에 트래픽 엔지니어링 또는 멀티호밍 같은 환경에서 라우팅 헤더를 이용해서 동적으로 ISP를 선택할 수 있다. 그러나, 현재 Mobile IPv6에서 사용하도록 한 Type 0의 라우팅 헤더는 호스트나 라우터에서 모두 처리 가능하며, 여러 개의 주소를 담아서 전송될 수 있기 때문에 reflection attack에 이용될 수 있다. 이 문제점에 대한 해결방안으로서, 기존의 라우팅 헤더를 사용하지 말고 새로운 Destination option, 새로운 확장 헤더 또는 새로운 라우팅 헤더 타입을 정의하여 사용하는 방식이 사용된다.

세번째 보안 이슈로서 바인딩 업데이트에 있어서 발생할 수 있는 보안 문제를 2가지 경우로 구분하여 설명하면 다음과 같다. 첫번째로 이동노드가 홈 에이전트로 바인딩 업데이트 메시지를 전송할 때, attacker는 어떤 이동노드에 대해 현재 위치한 곳과 다른 곳에 위치해 있다는 정보를 줄 수 있고, 홈 에이전트가 이 정보를 받아들인다면, 이동노드는 패킷을 받지 못하는 반면 다른 노드가 원하지 않는 패킷을 수신하게 된다. 두번째로, 대응노드로 바인딩 업데이트 메시지를 전송할 때, 악의를 가진 이동노드가 자신의 HoA를 victim의 HoA로 설정하여 거짓 정보를 알릴 경우, 대응 노드가 이 정보를 받아들인다면, 대응노드에서 victim으로 전송하고자 하는 패킷은 이동노드를 거치게 되므로 이동노드는 availability와 confidentiality를 모두 위협한다. 악의를 가진 이동노드가 자신의 CoA(Care-of Address)를 거짓으로 알리는 경우, 대응노드는 이동노드로 보내는 패킷을 모두 거짓 CoA로 전송하여 DoS 공격을 할 수 있다. 대응노드로 의미 없는 바인딩 업데이트 메시지를 한꺼번에 많이 전송할 경우에는 대응노드에서 그 메시지가 invalid함을 눈치채기 전에 자원을 고갈시켜 의미 있는 패킷들을 처리할 수 없게 만든다(DoS 공격). 또한 attacker는 오래된 바인딩 업데이트 메시지를 replay 하여 패킷들을 이동노드의 예전 위치로 전달시켜 이동 단말이 패킷을 수신하지 못하게 만들 수 있다.

이런 공격들을 막기 위해서 이동노드가 바인딩 업데이트 메시지를 전달할 때 홈 에이전트로는 IPsec ESP(Encapsulation Security Payload)를 사용하여 패킷을 보호하고, 대응노드로 바인딩 업데이트 메시지를 전송할 때에는 보안을 위한 기본 메커니즘으로 RR(Return Routability)을 이용하여 HoA와 CoA가 도달 가능한지를 확인한 후 메시지를 전송하는 방식을 적용하였다. IV장에서는 이 두가지 보안 방안에 대해 자세히 기술하고자 한다.

IV. MIPv6 보안 방안

이동노드는 이동을 감지한 후 자신의 바인딩 정보를 홈 에이전트와 대응노드로 전송하게 된다. 이때, 홈 에이전트와는 SA를 갖고 IPsec ESP를 이용하여 데이터의 기밀성을 보장한다. 또한 정확한 패킷 ordering과 replay protection을 위해서 바인딩 업데이트 메시지의 시퀀스 넘버 필드의 길이를 16비트로 확장하였다. 또한, 대응노드로 바인딩 업데이트 메시지를 전송할 때에는 RR 메커니즘을 사용하여 여러 유형의 공격으로부터 메시지를 보호한다. 이어지는 절에서는 MIPv6에서 사용되는 2가지 보안 방안에 대해 설명한다.

1. IPsec

IPsec은 IP계층에서 기밀성과 인증 서비스를 제공하기 위하여 개발된 프로토콜이다. 현재 대다수의 IPsec구현은 IPv4에서 이루어지고 있으나 최근 IPv6도입의 필요성이 구체화되면서 IPv6에서의 IPsec구현에 대한 연구도 활성화되고 있는 추세이다. IPsec에 의해 제공되는 보안 서비스로는 접근제어(access control), 기밀성(confidentiality), 비연결형 무결성(connectionless integrity), 재현공격방지(anti-replay service), 원적지 인증(data origin authentication) 그리고 제한된 트래픽 흐름 기밀성(limited flow confidentiality)이 있다. IPsec의 기본문서체계와 패킷 구성 등의 내용은 주간기술동향 1064호[13]를 참조할 수 있다.

현재 Mobile IPv6에서는 이동성으로 발생하는 문제점을 극복하기 위해 홈 에이전트와 이동노드 사이의 보안 프로토콜로써 IPsec을 사용하고 있다. IPsec은 이동노드와 홈 도메인의 홈 에이전트 사이에 설정된 보안연계를 통하여 메시지를 인증할 수 있다. 이동노드와 홈 에이전트 사이에 제어 트래픽에 대한 보안 메커니즘이 적용되지 않는다면, 이동 노드와 대응 노드는 Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, DoS 공격에 취약할 것이다. 이러한 공격을 피하기 위해, 이동 IPv6 문서는 홈 에이전트와 이동 노드 사이의 제어 트래픽을 보호하기 위해 IPsec을 사용한다. 이 제어 트래픽은 IPv6 내의 이동 헤더 프로토콜에 의해 전달되는 다양한 메시지로 구성된다. 트래픽은 다음과 같다 :

- 이동 노드와 홈 에이전트 사이에 교환되는 바인딩 갱신과 응답 메시지

- 홈 에이전트를 통하여 대응 노드로 전달되는 HoTI, HoT RR 메시지

- 프리픽스 발견을 위해 이동 노드와 홈 에이전트 사이에 교환되는 ICMPv6 메시지

노드들은 또한 부가적으로 홈 에이전트를 통하여 전달되는 패이로드 트래픽을 보호할 수 있다. 멀티캐스트 그룹 멤버쉽 제어 프로토콜 혹은 상태보존형 주소 자동 설정 프로토콜이 지원된다면, 페이로드 데이터 보호 지원이 요구된다.

2. RR(Return Routability)

RR 프로토콜은 이동노드와 대응노드 사이에서 바인딩 갱신 및 바인딩 응답 메시지를 인증하기 위해서 사용되는 보안연계를 생성한다. 현재 RFC로 등록 예정인 draft-ietf-mobileip-ipv6-24 버전에서 RR의 사용을 명시하고 있으며, 좀 더 향상된 보안을 위해서 RR을 대체할 수 있는 새로운 프로토콜이 필요하다는 의견도 제기되고 있다.

대응노드로 바인딩 업데이트 메시지를 전송할 때에는 RR 메커니즘을 사용하여 여러 유형의 공격으로부터 메시지를 보호한다. RR 메커니즘의 기본 동작은 (그림 3)과 같다. RR 메커니즘을 수행하기 위해서 새로 정의된 메시지는 <표 1>에서 정리하였다.





위 메시지들은 각각 Mobility 헤더의 타입필드의 값에 따라서 데이터 필드에 담겨져 전송된다. 위 절차에 따라서 HoA와 CoA에 대해서 각각 reachability와 validity를 체크한 후, 바인딩 업데이트를 전송함으로써 바인딩 업데이트 권한을 가진 이동 노드를 인증할 수 있고, 안전하게 바인딩 업데이트 과정을 수행할 수 있다.

V. MIPv6 보안 표준 핫이슈

1. SEND(Secure Neighbor Discovery)

차세대 인터넷 프로토콜 IPv6은 인접 탐색 프로토콜(Neighbor Discovery Protocol, 이하 ND라고 칭함)을 통하여 노드 주위에 있는 다른 노드와 라우터 등의 정보를 획득한다. ND 프로토콜은 “Neighbor Discovery for IP Version 6(IPv6)” (RFC2461)에 표준화되어 있다. 이 ND 프로토콜의 설계 기본 원칙은 호스트가 어떠한 사전 설정도 없이 인터넷이나 로컬 링크상에서 다른 호스트와 통신을 할 수 있도록 하는 Zero Configuration이 가능하도록 하는 것이다.

ND 프로토콜에서 주고 받는 시그널링 메시지로는 NS(Neighbor Solicitation), NA(Neighbor Advertisement), RS(Router Solicitation), RA(Router Advertisement), Redirect 메시지 등이 있는데, 이들은 로컬 호스트들을 위한 IP 주소와 MAC 주소, 라우터들의 IP 주소와 MAC 주소 및 라우팅 Prefix 정보 등 네트워크상의 중요한 로컬 토폴로지 정보들을 제공한다. RFC2461에는 이러한 ND의 시그널링 메시지를 안전하게 보호하기 위하여 IPsec AH를 쓰도록 제안하고 있으나, 구체적인 방법은 언급하고 있지 않다. 그러나, Bootstrapping 이후에 SA를 교환하면 문제가 없으나, Bootstrapping 과정중에 SA를 교환하면 IKE로 인해 chicken-and-egg 문제가 발생한다. 이와 같은 Bootstrapping 문제로 인하여 특별한 경우 오직 Manual Key만을 사용할 수 있어 이는 현실적으로 불가능하다.

이와 같은 문제를 해결하기 위해 IETF에서는 2002년 가을 SEND 워킹 그룹을 조직하였으며, 추가적인 Manual Key 과정없이 IPv6 ND에 보안 기능을 지원하는 프로토콜 확장을 목표로 하고 있다.

SEND 워킹 그룹은 다음과 같은 세가지 분야를 중심으로 연구중이다.

- 로컬 링크들을 위한 위험성 평가 및 신뢰 모델 개발

- 공개키가 인증 서비스를 제공받으면서 분배될 수 있도록 보장하는 프로토콜 개발

- IPsec AH/ESP 헤더 내에서 디지털 서명 값을 계산하기 위해 키 분배 프로토콜과 공개키 암호화 방식의 사용 방법 개발

현재 워킹 그룹은 예상치 못한 부작용에 대한 위험성을 줄이고, 빠른 표준화를 위해 좋은 보안 특성을 가지고 있는 이미 잘 알려진 보안 프로토콜을 활용하는 방안을 시도하고 있으며, 기존의 ND 프로토콜의 모든 기능을 방해하지 않고 보안 측면에서만 기능을 향상하는 것을 목표로 하고 있다. IPv6 ND 프로토콜에 보안 방안을 적용하려면 먼저 실제 네트워크에 적용 가능한 신뢰 모델을 정의하는 것이 중요하다. 정의된 신뢰 모델들은 크게 ND와 RD 프로토콜의 라우터 개입 여부에 따라 3가지로 분류한다.

(1) 인트라넷 모델(Corporate Intranet Model)

모든 노드들이 하나의 관리 도메인 하에 있으며, 비공개 그룹을 형성하는 모델이다.

(2) 운영자에 의해 관리되는 공중 무선 네트워크(Public Wireless Network with an operator)

호텔, 공항, 커피숍 내에서의 무선 LAN과 같이 공중 무선 네트워크를 관리하는 운영자가 있는 모델이다.

(3) 임시 네트워크 모델(Ad-hoc Network)

신뢰할 수 있는 운영자도 존재하지 않고, 모든 노드들이 서로 신뢰하지 않는 모델이다.



위 3가지 신뢰 모델 환경에서 요구되는 위험 요소를 도출하여 정리하면 <표 2>와 같다. <표 2>와 같은 위협을 해결하기 위해 SEND 워킹 그룹에서는 다양한 방법으로 안전하게 ND 메시지들을 보호할 수 있는 방법을 제시하고 있다.

그 첫번째가 공개키의 사용인데, 기존의 ND 프로토콜에서 제시한 것과 달리 SEND 프로토콜에서는 IPsec을 사용하지 않는다. 이에 ND 메시지를 인증하거나 암호화하기 위하여 공개키 서명 메커니즘을 이용한다. 공개키에 대한 신뢰성은 확인 위임(Authorization Delegation) 절차 또는 주소 소유권 증명 메커니즘을 통해 제공된다, 다만, 보호되어야 할 메시지의 형태나 설정 기법 등에 의존해서 어떤 메커니즘을 사용할 지가 결정된다.

또한, 각 라우터들은 자신의 권한(Authority)에 대해 보증받을 수 있도록 신뢰 루트를 두어야 한다. 다시 말해, 호스트가 디폴트 라우터를 선택하기 전에 호스트와 라우터간에 적어도 하나의 공통 신뢰 루트를 두어야만 한다. 이와 같은 문제를 해결하기 위해 DCS(Delegation Chain Solicitation) 메시지와 DCA(Delegation Chain Advertisement) 메시지를 정의한다. 긴 인증서 사슬(Certificate Chain)을 RD 메시지를 통해 전송하는 대신, 이 메시지를 통해 신뢰 루트에 대한 인증서 사슬을 탐색한다.

다음은 기존의 보안 인프라가 존재하지 않는 환경에서 ND 메시지의 송신자가 요구자 주소(Claimed Address)의 소유권자임을 보장하기 위해 사용되는 CGA 주소가 있다. 이 CGA 주소는 Interface Identifier를 공개키와 임시 파라미터들을 이용하여 일방향 해쉬 함수 SHA-1로 압축하여 생성한다.

128bits IPv6 address = 64bits subnet prefix + 64bits interface identifier



generated by the hash value of public key

이와 같은 CGA 주소를 사용하기 위해서는 모든 노드들은 자신을 위해 필요한 공개키-개인키 쌍을 미리 보유하고 있어야 한다. 또한, CGA 주소의 소유권에 대한 서비스뿐만 아니라, 재연 공격 및 다른 보안 위험을 방어하기 위해 추가적인 보안 서비스가 필요하다.

CGA 주소에 대한 추가적인 보안 서비스를 제공하기 위해 서명 옵션, Timestamp 옵션, Nonce 옵션이 사용된다. 서명 옵션은 ND/RD 메시지를 보호하기 위해 공개키를 이용하여 메시지를 서명함으로써 송신자를 인증하고 메시지의 무결성을 제공한다.

또한, Timestamp 옵션과 Nonce 옵션은 재현 공격 방지를 위해 사용된다. 멀티캐스트 주소일 경우 Timestamp 옵션을 사용하고, 메시지가 Solicitation-Advertisement 쌍인 경우에는 Nonce 옵션을 사용한다.

위에서 제시한 SEND 프로토콜은 현재 3번째 드래프트가 나온 상태이다. ND 메시지를 보호하는 SEND 프로토콜이라고 하여도 SEND 메시지 자체에 대한 DoS 공격이나 링크 계층에 대한 공격에는 안전하지 못하며, 또한 데이터의 인증과 무결성만 제공할 뿐이지, 기밀성은 제공하지 못하고 있다. 그러므로, 향후 여러 분야에서 추가적인 많은 연구가 진행되어야 하겠다.

2. Bootstrapping

최근 MIP6 워킹그룹에서 워크 아이템으로 잡고 있는 주제 중 하나로 Mobile IPv6 기본 스펙에서 규정된 IPv6 이동성에 관련된 메커니즘을 향상시키는 것인데, 이중에 하나의 아이템이 Bootstrapping 에 관한 것이다. Bootstrapping 메커니즘이란 Mobile IPv6 프로토콜의 deployment 용이성을 높이기 위하여, 이동노드와 홈 에이전트 사이의 IPsec SA 를 이동노드가 새로운 링크에 접근하여 부팅 시에 동적으로 설정하는 것을 의미한다.

기존 Mobile IPv6 기본 스펙에서는 이동노드와 홈 에이전트 사이의 BU(Binding Update) 메시지를 보호하는 것을 필수기능으로 규정하고 있으며, 이를 위하여 매뉴얼 SA 설정을 필수 기능으로 규정하고 있다. 또한, 이동노드와 홈 에이전트 사이에 발생할 수 있는 재연 공격을 방지하기 위하여 IKEv1 을 사용하도록 권고하고 있다. 그러나, 매뉴얼 SA 설정과 IKEv1 에서는 이동노드의 홈 주소와 홈 에이전트의 주소가 정적으로 설정되었다는 것을 가정하고 있으며, 이러한 점은 홈 에이전트가 위치하고 있는 도메인의 네트워크 주소 변경 및 홈 에이전트의 부하분산을 위한 동적 홈 에이전트 발견 및 동적 홈 프리픽스 발견 등의 메커니즘을 제공하는데 문제점을 초래한다.

이러한 문제점을 해결하기 위한 Dynamic Bootstrapping 방식은 올해 서울에서 개최된 제59차 IETF mip6 워킹그룹에서 다시 활발히 논의가 되었으며, 미국 DoCoMo 연구소의 James Kempf 에 의해서 다음과 같은 4가지 방식의 Dynamic Bootstrapping 적용 시나리오가 제안되었다.

- 기존에 전혀 IPsec SA 가 존재하지 않는 환경에서의 새로운 SA 설정

- 이동노드의 홈 네트워크에 존재하는 SA 를 활용하여 Mobile IPv6 를 위한 SA 를 설정하는 방안

- 이동노드가 홈 네트워크는 아니지만 다른 환경에서 활용할 수 있는 SA 를 이용하여 Mobile IPv6 를 위한 SA 를 설정하는 방안

- 이동노드가 이미 홈 에이전트로 설정된 SA 를 활용하여 다른 홈 에이전트와의 통신을 위한 Mobile IPv6 를 위한 SA 를 설정하는 방안

이와 같이, Mobile IPv6 의 deployment 가속화에 많은 영향을 미칠 bootstrapping 문제가 현재 IETF mip6 워킹그룹을 중심으로 활발하게 논의되고 있으며, 해당 워킹그룹에서 올해 8월중에 IESG 에 Bootstrapping solution 을 제출하는 것을 목표로 하고 있는 만큼 주목할 만한 분야이다.

3. Mobike

다양하게 진화하는 네트워크 환경의 생성과 통합으로 인해 기존 유선환경은 물론이고 여러 네트워크가 통합된 구조에서 멀티홈잉이나 이동성으로 인해 여러 가지 보안 요구 사항들이 생기기 시작하였다. 이러한 배경 하에 IETF는 제59차 서울회의에서 IPsec의 키관리 프로토콜인 IKE 버전 2를 대상으로 Mobike 워킹그룹을 신설하여 표준화 활동을 시작하게 되었다. Mobike는 한 호스트가 다수의 IP를 소유하는 경우나 IPsec환경에서 로밍이나 단말의 이동성으로 인해 IP 주소의 변경이 발생하는 경우, 이를 지원하기 위한 IKEv2 프로토콜을 확장하기 위해 구성되었다.

실제적으로 주요 서비스 관점에서 보면 단말의 이동성으로 인해 발생하는 VPN 연결이나 멀티홈잉을 지원하기 위한IPsec 엔드의 변경을 추구한다는 점에서mobile IP서비스와는 차이점을 가진다고 볼 수 있다. 간단히 요약하면 Mobike는 다음의 경우를 지원하기 위해 IKEv2를 확장하기 위한 IETF 워킹그룹이다.

- 한 호스트당 multiple IP 주소가 존재

- IPsec환경에서 로밍이나 mobility로 인해 IP주소 변경이 발생

현재까지 표준화 초기단계로써 나와있는 RFC나 워킹그룹 드래프트는 없으며 개인 드래프트만 3편이 발표되었다.

Mobike가 요구하는 주요 시나리오는 앞서 언급했듯이VPN 서비스라고 볼 수 있다. 단말의 이동성 혹은 멀티홈잉으로 인해 VPN연결의 변경이 요구될 시 그러한 환경을 지원하도록 하고 있다. 이번 IETF 제59차 회의에서는 mobike의 기본 프로토콜 규격 및 프로토콜 설계 시의 고려사항에 관한 논의가 주를 이루었으며, 다음과 같은 제목으로 발표되었다.

가. Address Management for IKEv2

본 주제에서는 mobike 워킹그룹에서 표방하고 있는 목적의 달성을 위한 mobike 기본 프로토콜의 개발에 대한 내용이 다루어졌으며, 이는 IKEv2에서 주소 관리의 목적과 multihoming 및 mobility를 위한 요구사항, 그리고 mobike 기본 프로토콜에 대한 개략적인 제안을 포함하고 있다. 현재 버전 4까지 업데이트가 된 상태인데 개략적으로 제안된 프로토콜은 IKEv2의 NAT traversal 메커니즘에 기초를 두고 있으며, 되도록이면 IKEv2 프로토콜의 변경을 최소화하는 방향으로 프로토콜을 개발하고 있다. 하지만 아직까지 IKEv2가 draft 상태임을 감안하여 IKEv2의 표준화 과정을 지켜보면서 개발이 이루어질 것으로 예상된다.

나. Design of MOBIKE protocol

본 주제에서는 mobike 프로토콜의 설계에 있어서 고려되어야 할 사항들에 대해서 논의가 이루어졌으며, 이는 제59차 회의에서 처음으로 다루어진 내용이다. 여기서는 mobike가 필요한 상황을 크게 이동하는 laptop과 multihoming을 지원하는 SGW의 두 가지 시나리오로 나누어 고려하고 있으며, 이를 지원할 mobike 프로토콜의 설계 시 고려해야 할 사항들이 논의되었다. 현재 상황에서 고려되고 있는 몇 가지 주요 이슈로 SA 변경 범위(IKE SA 주소가 변경되었을 때, 모든 IPsec SA를 자동으로 변경할 것인지 아니면 각각의 변경 요청에 대해 IPsec SA를 변경할 것인지의 결정), 메시지 표현(IKEv2에서 정의한 메시지 포맷을 사용할지, 새로 정의한 포맷을 사용할 것인지의 결obike 프로토콜을 개발하고 제안된 이슈들을 결정하는 데에 있어서 논의된 환경보다 다양한 환경이 고려되어야 하며, 각 환경에 따라 제안된 이슈들에 대한 결정이 달라질 것이라는 의견 또한 제기되었다.

VI. 결 론

본 고에서는 Mobile IPv6 보안 기술 표준 동향을 기술하였다. 구체적으로는 단말의 이동성 측면에서의 프로토콜 진화과정, Mobile IPv6환경에서의 보안 취약성과 이에 대한 보호 방안 그리고 현재 IETF에서 Mobile IPv6 보안과 관련된 주요 이슈들을 살펴보았다.

Mobile IPv6 기술은 네트워크 계층에서 핸드오프를 지원하고자 하는 기술로서 현재 매우 활발히 표준화가 진행중이며, 산ㆍ학ㆍ연 각계에서도 많은 관심을 보이고 있는 기술이다. Mobile IPv6는 그 표준이 거의 마무리 단계에 와 있다고 볼 수 있으며 현재 보안 문제가 가장 큰 이슈로 논의되고 있는 실정이다. Mobile IPv6 기술은 향후 휴대 인터넷 망, All IP 망 등 차세대 인터넷 망에서 네트워크 계층에서의 핸드오프 지원을 위한 기술로서 채택될 가능성이 매우 높은 기술이다. 또한 VoIP기술, SIP(Session Initiation Protocol)와 같은 영상 통신 기술 등과 접목된 형태로 서비스가 가능한 후보 기술이기도 하여 향후 많은 수요가 있을 것으로 예측된다.

<참 고 문 헌>

[1] IETF Working Group, http://www.ietf.org
[2] C.Perkins, IP Mobility Support for IPv4, RFC 3344
[3] D.Johnson, C.Perkins, J.Arkko, Mobility Support in IPv6, draft-ietf-mobility-ipv6-24
[4] J. Kempf, J. Arkko, The Mobile IPv6 Bootstrapping Problem, draft-kempf-mip6-bootstrap-00.txt
[5] P.Nikander, J.Kempf, E.Nordmark, IPv6 Neighbor Discovery trust models and threats, draft-ietf-send-psreq-04.txt, 2003.10.
[6] T.Aura, Cryptographically Generated Addresses (CGA), draft-ietf-send-cga-04.txt.
[7] J.Arkko, J.Kempf, B.Sommerfeld, B.Zill, P. Nikander, “SEcure Neighbor Discovery(SEND),” draft-ietf-send-ndopt-03.txt, 2004.1.
[8] F. Dupont, Address Management for IKEv2, Draft-dupont-ikev2-addrmgmt-04.txt
[9] T. Kivinen , Design of MOBIKE protocol , draft-kivinen-mobike-protocol-00.txt
[10]. T. Kivinen , MOBIKE protocol, Draft-kivinen-mobike-protocol-00.txt
[11] 이경진, 이승윤, 박정수, 김용진, “Mobile IPv6 보안 문제와 해결방안,” IITA, 주간기술동향, 2002. 6.
[12] 유준석, 나재훈, 손승원, “Mobile IPv6 표준화 및 기술동향,” IITA, 주간기술동향, 2003.
[13] 권혁찬, 나재훈, 손승원, “IPv6 Security 동향,” IITA, 주간기술동향, 2003.

출처 : IITA IT정보센터
주간기술동향 통권 1146호 ( 2004.05.18 발행 )