RFC 8656 - Traversal Using Relays around NAT (TURN) 기초 분석 2

 

동작 개요(Overview of Operation)

홀펀칭이 불가능한 Symmetric NAT(규격 상으로는 Address/Port Dependent Mapping NAT) 사이에 TURN 클라이언트와 TURN 서버 간의 통신 및 TURN 서버의 릴레이를 통한 TURN 클라이언트와 상대 peer 들 간의 통신 방법을 전체적으로 설명

 

전송(L4) 프로토콜(Transports)

기본적으로 UDP를 이용. TURN 클라이언트/서버 간에는 UDP/TCP/TLS/DTLS를 모두 지원하는 것을 명시했으나 TURN서버/피어 간 프로토콜은 UDP만 지원.
이렇게 한 이유는 TURN 클라이언트와 서버 간에 relay 자원 할당을 위해 시그널링을 할 때 중간에서 파이어월 등 때문에 UDP 자체가 차단되어 시그널링부터 성립이 되지 않는 걸 막기 위함. 하지만, 피어 쪽으로는 UDP만 지원되므로 실세계의 네트워크는 일반적으로 대칭적임을 고려하면(예를 들면 자신 뿐만 아니라 상대방도 UDP가 막혀 있을 가능성) 약간 애매한 규격이다.

 

할당(Allocations)

클라이언트에 '할당'하는 일종의 자원. 즉, 릴레이를 수행하기 위한 자원이다. Allocate라는 STUN 확장 메시지를 통해 진행하며 이 때 STUN과 마찬가지로 간단한 보안 기능을 제공하는 것까지가 규격이다. 렝이 데이터 자체의 보안은 사용자가 직접 책임져야 한다. '할당'이 생성되고 나면 10분 주기로 만료가 발생한다. 만료를 막기 위해 Allocate를 또 하거나, Refresh라는 확장 명령어를 이용한다. 규격에서는 Refresh를 추천한다. 만료시간 10분은 규격에 명시된 값이다. 클라이언트에서 burden이 아닐 충분히 긴 시간으로 정했다고 한다. 
'할당' 제거를 위해서는 Refresh 명령어에 lifetime이라는 값을 0으로 하여 요청하면 된다.
규격에는 TURN서버에서 클라이언트 식별을 위해 5-tuple을 기본으로 명시했지만, 서버 구현자가 다른 식별자를 이용하는 것을 막지는 않는다.

 

권한(Permission)

'할당'을 이용할 수 있는 peer를 제한하는 방법을 요약. STUN 확장 메시지인 CreatePermission 또는 ChannelBind 메시지를 이용하며 특정 peer가 접근할 수 있도록 권한을 설정하고 이 권한은 5분 내에 갱신되지 않으면 제거되며, 인위적으로 제거하는 방법은 없다. 제거를 원한다면 5분을 기다려야 하는데, 이는 NAT 규격의 행동양식과 유사하다.

 

송신 방식(Send Mechanism)

TURN 클라이언트에서 상대방에게 데이터를 송신하는 방법이 두가지가 있음을 기술. 하나는 STUN 확장 메소드인 Send 및 Data 메소드를 이용하고, 다른 하나는 channel이라는 규격을 이용한다.
여기서는 Send/Data를 설명. Send는 클라이언트에서 보낼 때 사용하는 메소드이고, Data는 상대방으로부터 데이터가 도착했을 때 알림 받는 메소드이다.

채널(Channels)

위에 기술한 Send/Data는 36바이트의 STUN고정헤더 오버헤드가 있어 ChannelBind를 통해 특정 peer와의 4바이트 숫자로 된 채널을 맺고, 非STUN 메소드인 ChannelData에 오로지 4바이트의 채널번호만 헤더로 붙여서 데이터를 송수신하는 방식이다. 이 부분이 경제적이라는 뉘앙스로 기술되어 있는데, 오늘날에는 사실 퇴색된 장점이 아닐까 한다. 당장, 웹 스트리밍 서비스만 하더라도 무지막지한 네트워킹 오버헤드를 당연하다는 듯이 얹어 놓고 있음에도 서비스에 큰 무리가 없지 않은가(게다가 TCP).

 

비특권 TURN 서버(Unpivileged TURN Servers)

본 규격은 OS의 특수권한을 받지 않더라도 서버 운영에 문제가 없도록 디자인된 규격이다. 즉, L3 이하 계층에 대한 제어가 없이도 TURN 서버 구현에 지장이 없음을 기술하였다.

 

IP 단편화 회피(Avoiding IP Fragmentation)

긴 지문을 할애하여 기술한 부분. 단편화를 피하기 위해 단일 datagram이 충분히 작은 사이즈여야 한다는 것을 강조함. 가이드라인으로 500바이트를 제시함.

 

RTP 지원(RTP Support)

classic RTP에 대한 하위호완성 제공을 명시함

 

Happy Eyeballs for TURN

IPv4/v6 듀얼스택 커넥션 방법 지원을 기술함. must 규격은 아님