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

 

채널 (Channels)

클라이언트와 서버 간에 릴레이 데이터를 주고 받는 방식 중 하나. (다른 하나는 여기 참조)

• Send/Data 메시지를 이용하면 36바이트의 STUN 고정 헤더가 필요한데, 이 방식을 이용하면 단 4바이트 헤더만 이용하여 경제적
• 非STUN 규격
• 채널 번호 범위는 아래 규칙을 따름
  • 0x0000 ~ 0x3FFF : 비허용 영역
  • 0x4000 ~ 0x4FFF : 허용 영역 (4096개)
  • 0x5000 ~ 0xFFFF : 예약 영역 (실질적 비허용 영역)
• 채널 번호 제한 이유
  • 채널 데이터 송수신 시 TURN메시지와 다른 메시지의 충돌을 피하기 위함
  • 채널 데이터는 2바이트 채널 번호가 가장 앞에 옴. 위 규칙에 따라 첫 바이트는 64(0x40) ~ 79(0x4F)만 가능
  • 규격에는 위의 규칙으로 충돌을 피하는 프로토콜을 나열함
    • 0~3 : STUN
    • 16~19 : ZRTP
    • 20~63 : DTLS
    • 64~79 : TURN Channel
    • 128~191 : RTP/RTCP
    • 192~255 : Reserved
  • 즉, 메시지의 첫 바이트를 통해 프로토콜 핸들링을 달리 할 수 있도록(mux/demux) 편의 제공
• 채널 바인딩이 존재할 경우에는 peer당 한개씩만 존재해야 함
• 채널 바인딩은 모든 peer와 진행할 필요 없음
• 채널 바인딩은 클라이언트에서만 가능
• 채널 바인딩 시점은 할당 생성 후 언제든 가능
• 채널 해제는 명시적으로는 불가능
• 채널 정보는 채널번호, peer 주소, 만료 시간으로 이루어짐
• 채널 만료 시간은 10분으로 고정
• 채널 만료로 해제된 경우 해당 채널 번호를 재활용 가능하지만 클라이언트 만료 뒤 5분을 기다린 후 시도해야 함
• UDP 클라이언트인 경우(역전 가능성), 채널 바인딩 요청과 동시에 ChannelData 메시지를 수신할 준비가 되어 있어야 함
• UDP 클라이언트는 채널 바인딩 응답 수신 전 ChannelData 메시지를 사용할 수도 있지만, 응답 수신까지 기다리거나 Send 메시지를 이용하길 권함

 

채널 바인딩 요청 (Sending a ChannelBind Request)

ChannelBind 명령은 채널을 생성하거나 채널의 만료시간을 갱신하는데 쓰임

• 이 명령에는 CHANNEL-NUMBER, XOR-PEER-ADDRESS 속성이 모두 존재해야 함
• XOR-PEER-ADDRESS 주소 값은 릴레이 주소와 동일한 family여야 함

 

채널 바인딩 요청 수신 (Receiving a ChannelBind Request)

서버에서 ChannelBind 명령을 수신했을 때의 절차를 기술

• 정상 처리 가능 여부 확인
  • 메시지 확인 후 아래의 경우 400에러 응답해야 함
    • CHANNEL-NUMBER, XOR-PEER-ADDRESS 속성이 모두 포함되지 않음
    • 채널 번호가 0X4000 ~ 0X4FFF 구간을 벗어남
    • 채널 번호가 다른 주소에 이미 바인딩 됨
    • 요청한 peer address가 이미 채널 바인딩 됨
  • 메시지의 XOR-PEER-ADDRESS 주소값이 릴레이 주소와 family가 다르면 443에러 응답해야 함
  • 서버 자체 주소 제한 시스템이 있어 이에 저촉될 경우 403에러 응답 가능
  • 서버에 채널 바인딩할 자원이 부족할 경우 508에러 응답해야 함
• 요청 정상 처리 시에는 채널 바인딩을 생성하거나 만료 시간 갱신을 진행
• 요청 정상 처리 시 해당 peer address에 대한 권한(permission)도 함께 생성 혹은 갱신해야 함

 

채널 바인딩 응답 수신 (Receiving a ChannelBind Response)

클라이언트가 성공 응답을 수신했다면 해당 채널에 ChannelData를 이용하여 데이터 전송 가능

에러 응답을 받았을 때는 상황에 따라 '할당'을 제거하고 새로 생성하기를 권장

 

ChannelData 명세 (The ChannelData Message)

채널 상에서 데이터를 주고 받을 때 쓰이는 非STUN 메시지 규약

헤더는 4바이트로 2바이트 채널번호, 2바이트 데이터길이로 이루어져 있다.

payload는 헤더에 명시된 길이만큼의 크기의 데이터가 붙는다.

0바이트 데이터도 가능하다.

 

ChannelData 보내기 (Sending a ChannelData Message)

클라이언트가 peer에게 데이터를 보낼 때는 아래 방법 모두 가능

• STUN규격인 Send
• 채널을 통한 非STUN규격인 ChannelData

서버는 제약이 있음

• 채널이 맺어진 경우에는 클라이언트로 항상 ChannelData만 송신 가능
  • 채널이 맺어졌더라도 ICMP 알림에 대해서는 STUN규격인 Data 메소드만 이용 가능
• peer 방향으로는 채널 여부와 관계 없이 UDP 데이터그램만 송수신

바이트 정렬 관련

• TCP/TLS의 경우 ChannelData 메시지는 4바이트 align이 되어 있어야 함 (padding 발생 시 length 필드에는 반영해선 안됨)
• UDP는 4바이트 align 불필요하나 처리되어 있을 수 있으므로 검사 필요

 

ChannelData 받기 (Receiving a ChannelData Message)

채널로부터 ChannelData를 수신한 경우

• ChannelData 헤더의 첫바이트를 통해 프로토콜 멀티플렉싱 진행
• ChannelData의 Length 필드의 값에 비해 payload가 부족할 경우 버림
• 모르는 채널일 경우 버림
• 모르는 peer일 경우 버림
• 문제 없는 메시지일 경우
  • 클라이언트는 payload와 peer 주소를 취하여 애플리케이션 처리
  • 서버에서 ChannelData를 받은 경우에는 UDP 데이터그램으로 변환하여 명시된 peer에게 전송

 

Peer의 데이터 릴레이하기 (Relaying Data from the Peer)

서버는 peer로부터는 UDP 데이터그램을 직접 수신한다. 
이 때, 채널이 맺어진 peer일 경우 ChannelData로 변환하여 클라이언트에게 전송한다.
다만, ICMP 메시지인 경우에는 채널이 있다해도 Data 메소드로 클라이언트에게 전송해야 한다.