NAT Traversal의 종결자, ICE

시작하며
UC 엔지니어들에게 NAT Traversal은 망의 복잡도 증가시키고 B2B 서비스와 같은 상호 연동에 고민거리로 항상 남는 기술입니다. NAT Traversal 은 IPv4가 사라지고 IPv6가 오면 사라지는 기술이라고 이야기를 많이 했었는 데 IPv6는 올 기미도 않보입니다. NAT는 단순한 주소 부족 이유 보다는 보안상의 이유로 더 많이 사용하기 때문에- IPv4 만큼은 아니겠지만- NAT Traversal  이슈는 여전히 남아 있을 듯합니다.  

UC 엔지니어들은 NAT Traversal과 관련된 문제를 많이 다루기 때문에 넥스퍼트 블로그에 NAT Traversal과 관련된 글들이 많습니다. 관련된 글은 맨 아래에 링크로 정리하였으니 참조하시기 바랍니다. 

수 년전부터 시스코와 마이크로소프트의 UC 솔루션들이 본격적으로 ICE를 지원하기 시작하면서 엔지니어들이 ICE에 관심을 갖기 시작했지만, 상용화가 많이 되지 않아 여전히 어렵게 느껴집니다. 이 글에서는 ICE에 대한 기본적인 이해와 세부 기술인 TURN과 STUN에 대해 살펴보겠습니다.  

이 죽일놈의 NAT, 무엇이 문제 인가?
SIP와 같은 Offer/ Answer 프로토콜은 NAT환경에서 운영하기 어렵습니다. SIP 프로토콜의 목적은 미디어 패킷을 송수신하기 위한 플로우를 설립하는 것이 목적으로 IP 주소와 포트 넘버를 Application Layer에서 직접 전달합니다. 하지만 라우터나 방화벽같은 장비들은 L3나 L4 레벨의 패킷 헤더만을 인식하므로 SIP와 같은 어플리케이션 헤더에 있는 IP 주소와 포트에 관심이 없습니다. NAT (Network Address Translation)을 수행하는 대부분의 장비들이 바로 L3 및 L4에 위치합니다. 아래 그림은 SIP 어플리케이션의 호 설립을 위한  INVITE 메세지의 헤더를 표시한 것입니다.  

 SIP 헤더에는 다수의 IP 주소와 포트가 표시되어 있으며, 특히 SDP는 미디어의 속성과 코덱정보 그리고 미디어가 직접 송수신될 주소를 명기하므로 실시간 음성이나 영상 통화에 문제를 일으키는 것입니다. 문제는 호 설정 실패에서 단방향 묵음 또는 양방향 묵음 등의 다양한 현상을 일으키게 됩니다. 아래에는 SIP헤더에 사설 IP 주소가 명기되면 어떤 문제를 일으키는 지 간단히 살펴보겠습니다.  

• 사설 IP가 적용된 Via헤더 
  INVITE 메세지에 대한 200 OK 메세지는 Via 헤더의 주소로 응답합니다. Via 헤더는 SIP Proxy서버에 의해 삽입되므로  Via 헤더에 명기된 주소로 보내지는 200 OK는 SIP Proxy서버에 도달하지 못하므로 호 설정이 되지 않습니다. 
  
  
• 사설 IP가 적용된 Contact헤더
  Contact 헤더는 새로운 요청이 발생할 때 사용하는 헤더입니다. 수신자가 직접 전화를 끝을 경우에 BYE 메세지를 전송할 때 바로 Contact 헤더를 이용하지만, 송신자는 전화가 통화중에 상대방이 전화를 끊었는 지를 알지 못합니다. 이 BYE 메세지도 SIP Proxy 서버를 경유하게 하기 위해서는 Route 나 Record-route 헤더를 삽입하면 되지만, NAT환경하에서는 마찬가지 문제입니다.    
  
  

지금은 어플리케이션 레벨에서 직접적인 IP 주소 사용을 제한하지만, SIP는 이미 오래전에 만들어진 프로토콜이므로 어쩔 수 없이 IP 주소와 포트를 직접 명기합니다. 따라서, NAT 문제를 해결하기 위한 다양한 방식이 함께 발전해 왔습니다. 

• ALG (Application Layer Gateway) 
• Middlebox Control Protocol (RFC 3303)
• Original Simple Traversal of UDP Through NAT (STUN, RFC 3489, updated by RFC 5389) 
• Session Traversal Utilities for NAT ( STUN, RFC 5389) 
• Realm Specific IP (RFC 3102, RFC 3103)
• SDP Extensions (RFC 4566)
• SBC (Session Border Controller)

아쉽게도 위의 기술들은 모두 장단점을 가지고 있어서 모든 네트워크에 접합하지 않아 네트워크의 복잡도를 증가시킵니다. 요즘 주목받는 ICE는 모든 네트워크 상황에 적용 가능한 단일 솔루션으로 각광받고 있습니다. 

ICE 란 무엇인가? (RFC 5245 Introduction 부분)
ICE (Interactive Connectivity Establishment)는 RFC  5245 : A protocol for Network Address Translator (NAT) Traversal for Off/Answer Protocols로 제안된 권고안으로 두 대의 단말이 서로 상대방과 통신하기 위한 최적의 경로를 찾을 수 있도록 도와주는 프레임워크입니다. ICE는 STUN (Session Traversal Utilities for NAT, RFC 5389)와 TURN (Traversal Using Relay NAT, RFC 5766) 을 활용하여 Offer / Answer Model의 프로토콜에 적용할 수 있습니다. SIP는 Offer / Answer Model의 프로토콜입니다. 

RFC 5245 ICE는 Offer / Answer 모델에 의해 생성되는 UDP 기반 미디어 스트림을 위한 NAT Traversal 기술이지만, TCP와 같은 전송 프로토콜에도 적용할 수 있습니다. ICE는 SDP Offer 안에 다수의 IP주소와 포트를 포함하도록 하여 양 단말이 직접 단대단 (Peer-to-peer) 연결성 (Connectivity) 확인한 후에 미디어를 전송하도록 합니다. 만일 커넥티비티 체크 (Connectivity Check)를 통해 직접 연결할 수 없다면, TURN을 이용합니다. . 

ICE의 동작 방식 및 정의에 대해 살펴보았지만, 무슨 말인지 전혀 이해를 못하시겠다는 분들은 걱정팔 필요없습니다. 이 글은 위의 두 단락을 이해하기 위해 아래에 주절이 주절이 설명하는 것입니다.^^ 먼저 ICE가 이용하는 STUN과 TURN에 살펴보겠습니다. 

STUN (Session Traversal Utilities for NAT)

STUN은 클라인언트-서버 프로토콜로 STUN 서버와 STUN Client 간의 통신을 다룹니다. STUN Client는 NAT 장비 뒤에 위치하며, STUN 서버는 공인 IP 망에 위치합니다. 기본적인 통신은 STUN 클라이언트가 요청을 하고, STUN 서버가 응답하는 형식입니다.  

STUN 클라이언트는 자신의 실제 공인 IP 주소를 알수 없으므로 STUN 서버에게 "나의 공인 IP 주소는 무엇인가?""라고 요청하면,  STUN Server는 Layer 3/4 IP 주소와 포트 넘버를 STUN 패킷의 페이로드 내의 IP주소와 포트넘버와 비교한 후에 자신의 데이타 베이스에 두 주소를 바인딩합니다. STUN 서버는 "너의 공인  IP 주소는 이거다"라고 바인딩한 정보를 STUN 클라이언트에게 응답합니다. 

좀 더 유식한 표현을 이용한다면, STUN Client는 Reflexive Transport Address 또는 Mapped Address를 STUN 서버를 통해 확인한후 SIP 헤더의 주소를 STUN Client가 직접 공인 IP 주소로 바꾸어 보내 줍니다. 

따라서, 통신하려는 두 클라이언트가 모두 NAT 환경에 있다면 STUN은 동작하지 않습니다. 또한, NAT 장비가 Symmetric NAT를 수행할 경우도 마찬가지입니다. Symmetric NAT는 클라이언트가 서로 다른 목적지로 패킷을 전송할 경우에 NAT 매핑 테이블이 매번 바뀌기 때문입니다. NAT의 종류 및 동작 방식에 대해서는 맨 아래에 링크된 민형애비님의 "NAT의 종류"라는 글을 참조하시기 바랍니다. 여기서는 설명을 생략합니다.   

 

TURN (Traversal Using Relays around NAT, RFC 5766) 
TURN 프로토콜은 NAT 상황에 놓인 호스트가 릴레이 서버를 활용하여 상호 통신하도록 하며, ICE의 일부로 사용될 수 있도록 디자인 되었습니다.  아래 그림은 RFC 5766에서 TURN을 설명하는 그림입니다. 이보다 더 좋은 자료를 찾기가 어렵네요

TURN 클라이언트는 NAT 장비 뒷단에 위치하며,  TURN 서버는 인터넷망에 위치합니다. TURN 클라이언트가 통신하고자 하는 대상은 Peer이며, Peer A은 NAT 환경에 Peer B는 공인환경에 있습니다. TURN 클라이언트는 패킷을 Peer A와 Peer B로 전송하기 위해 직접 통신을 하지 않고 TURN Server를 경유하여 보냅니다. 

TURN 클라이언트가 TURN 메세지를 TURN 서버로 자신의 Host Transport address (사설망 내의 IP주소와 포트)를 포함하여 전송합니다. TURN 서버의 주소는 수동 설정이나 기타 다양한 방식으로 취득한다고 가정합니다.  TURN 서버는 TURN 메세지 내의 Host Transport address와 L3 / L4의 Server-reflexive transport address를 차이를 확인하고, 응답을 TURN 클라이언트의 L3 / L4 server-reflexive transport address로 전송합니다. NAT 장비는 당연히 자신의 NAT 매핑 테이블에 있는 정보에 따라 TURN 응답 메세지를 클라이언트의 Host Transport address로 전송할 것입니다.  

TURN 서버는 Relay 서버의 Relay Transport address를 할당(allocation)하는 것이 역할이며, 일반적으로 Relay Transport address는 TURN 서버의 주소입니다.

STUN과 TURN 초간단 정리
STUN은 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정을 명시한 프로토콜이고, TURN은 단말이 패킷 릴레이를 위한 서버를 할당 받기 위한 과정을 명시한 프로토콜입니다. STUN 서버는 주소 바인딩을 하고, TURN 서버는 릴레이 주소를 할당(allocation)합니다. 

프로토콜의 전체적인 구조를 알지 못해도 NAT Traversal관련해서 이야기할 때 알아듣기 위한 최소한의 이해입니다. 이제 부터 ICE의 구체적인 동작 방식에 대해 살펴보겠습니다. 

ICE의 이해 - ICE Candidate Gathering
ICE를 실행하기 위해서 클라이언트는 모든 통신 가능한 주소를 식별해야 합니다. 아래 그림에서 보듯이 처음에 클라이언트는 STUN 메세지를 TURN 서버로 요청 및 응답하는 과정에서 다음의 주소를 확인할 수 있습니다.

• Relayed Address : TURN서버가 패킷 릴레이를 위해 할당(allocation)하는 주소 (Relayed Candidate)
• Server Reflexive Address : NAT 장비가 매핑한 클라이언트의 공인망 주소 (Server Reflexive Candidate)
• Local Address : 클라이언트의 사설 주소 (Host Candidate), 랜과 무선랜 등의 다수의 인터페이스가 있을 경우에 모든 주소가 후보가 됩니다. 

Candidate는 IP 주소와 포트의 조합으로 표시된 주소이며, 아래 그림에서 대문자는 IP 주소를, 소문자는 포트를 의미합니다. TURN 서버는 Relayed Candidate 와 Server Reflexive Candidate 값을 응답하지만, STUN 서버는 Server Reflexive Candidate 값만을 응답할 것입니다.   

 

여기서 주소의 상관관계를 짚고 넘어가야 합니다. 클라이언트 또는 에이전트가 NAT 장비 뒤에 있다면, 3개의 주소는 모두 다른 주소가 되겠지만, 공인망에 있다면, Server Relexive Address와 Local Address는 동일할 것입니다. 

확보된 Candidate를 이용하여 다양한 연결이 가능하겠지만, 기본적으로는 위의 그림과 같이 3개의 연결을 가능합니다.  

• Direct Connection : Host Candidate 간의 직접 미디어를 송수신 
• Server Reflexive Connection : Server Reflexive Candidate를 이용한 미디어 송수신
• TURN Relay Connection : Relay Candidate를 이용한 미디어 송수신

기본적이라는 의미는 Local 주소끼리만 통신하는 것이 아니라 Local Address 와 Server Reflexive Address와도 Connection을 맺을 수 있다는 것입니다. 

ICE의 이해 - Connectivity Checks
이제 송신 클라이언트는 확보된 3개의 주소를 이용하여 우선순위를 정한 후 시그널링 채널을 이용하여 수신 클라이언트에게 Candidate를 SDP내에 포함시켜 전송합니다. 수신 클라이언트도 마찬가지로 Candidate Gathering을 통해 3개의 Candidate 주소를 확보한 후에 SDP로 송신 클라이언트에게 전송합니다.  아래그림과 같이 INVITE with SDP와 200 OK with SDP로 Offer / Answer 로 교환될 때 Candidate가 교환되는 것입니다.

실제 SDP 메세지는 아래는 아래와 같습니다. 우리가 알고 있는 m=과 c=에 기본적인 주소가 있지만,  a=candidate 에 관련된 Candidate 주소가 명시됩니다. 이 주소는 RTP 및 RTCP를 위한 주소입니다. 

이제 송신 클라이언트와 수신 클라이언트는 이용한 가능한 Candidate를 확인하기 우해 STUN 요청과 응답 매커니즘인 4-way Handshake로  Connectivity Checks를 진행합니다. 

Connectivity Checks 는 두 단말간에 직접 STUN 요청과 응답을 이용하므로 만일 기존의 Server Reflexive Address와 틀릴 경우에는 새롭게 업데이트하고 이를 Peer Reflexive Candidate라고 합니다. 이 과정은 실제 미디어가 흘러갈 수 있는 지를 확인하는 것이므로 사용할 RTP 및 RTCP 포트에 대해 진행합니다.

아래 그림은 실제 Connectivity Checks를 위해 모든 주소에 대해 확인하는 것을 표시한 것입니다. 

3 개의 주소에 대해 각각 연결을 확인하다가 아래 그림처럼 연결이 확인이 되면 실제 RTP 및 RTCP 패킷을 전송하여 통화가 가능하게 됩니다. 

마치며
ICE는 표준화가 완료되었으며  마이크로소프트와 시스코과 같은 제조사에서 적극적으로 도입하고 있습니다. ICE를 구현하기 위해서는 TURN 서버 역활을 할 제품과 음성 및 영상 단말에 ICE 클라이언트 기능이 적용되어야 합니다. 시스코의 경우는  VCS와 Cisco Expressway에 TURN 서버 기능을 도입하였으며, 영상 단말은 이미 ICE가 적용되었습니다. 

NAT Traversal을 고민하는 분들은 제일 먼저 제품이 ICE를 지원하는 지를 살펴볼 필요가 있습니다.   

여담
1년전 부터 시스코 제품들이 ICE를 지원하면서 관심을 가졌지만, 막상 정리할려고 보니 적당한 자료를 찾는 것이 어려워서 결국 SIP의 이해와 마찬가지로 RFP 문서를 기반으로 썼습니다. 좀 더 깊은 이해를 필요로 하시는 분들은 RFP 문서를 탐독하시고, 저는 개발자가 아니므로 필요한 정보만 얻기 위해 앞부분만을 읽었습니다. ^^ 

참고자료
RFC 5247 : http://tools.ietf.org/html/rfc5245
RFC 5245 : http://tools.ietf.org/html/rfc5245
RFC 5766 : http://tools.ietf.org/html/rfc5766
RFC 3489 : http://tools.ietf.org/html/rfc3489
http://hacks.mozilla.or.kr/2013/08/as/complete/

NAT Traversal과 관련된 넥스퍼트의 글들
수 년간에 걸쳐 다수의 필진들이 경험한 NAT Traveral에 관한 다양한 경험들이 녹아 있는 글입니다. 읽기 편하게 순서대로 링크하였습니다.  

출처: http://www.nexpert.net/424 [NExpert]