Tech Study/Network2024. 12. 4. 19:24

 

할당(Allocations)

각 할당은 개념적으로 아래의 상태 정보로 구성된다.
- relayed transport address(es)
- 5-tuple
- 인증 정보
- relayed transport address 별
  - 만료 시간(time-to-expiry)
  - 권한 목록
  - 채널 바인딩 목록

relayed transport address는 서버 모든 할당에 대해 유일해야 한다.
서버는 인증 정보 중 password를 암호화하여 저장해야 한다. (RFC8489 계승)
암호화 방식을 클라이언트와 서버 모두 SHA-256을 지원한다면 요청 정보에 SHA-256만을 명시해야 한다.
만료 시간은 10분이 기본이며, 요청 정보에 다른 만료 시간을 이용할 수도 있다.

할당 생성(Creating an Allocation)

Allocate 메소드 사용에 대한 규격 기술

할당 요청(Sending an Allocate Request)

RFC의 기술 내용을 요구 사양서 형식으로 요약 나열한다.

  • 현 시점에선 클라이언트-서버 프로토콜은 UDP로 단일화 하는 것을 추천한다.
  • 클라이언트는 TURN서버를 선택해야 하는데 RFC8155, RFC5928, RFC7350에 기술된 방식을 권장한다.
  • 클라이언트는 할당 요청에 항상 REQUEST-TRANPORT 속성을 포함해야 하며, 속성값은 현 시점에는 항상 UDP이다.
  • 클라이언트가 IPv4, IPv6 중 원하는 주소 family가 있을 경우 REQUESTED-ADDRESS-FAMILY 속성에 원하는 형식 값을 포함하여 요청한다.
  • 클라이언트는 2개 이상의 REQUESTED-ADDRESS-FAMILY 속성을 넣어선 안된다.
  • 클라이언트는 RESERVATION-TOKEN 속성이 포함된 경우에는 REQUESTED-ADDRESS-FAMILY 속성을 포함해선 안된다.
  • RESERVATION-TOKEN 속성은 기존 예약된 할당의 주소 값을 받기 위해 쓰인다.
  • 클라이언트가 IPv4, IPv6 두 가지 주소를 모두 획득하고자 한다면 ADDITIONAL-ADDRESS-FAMILY 속성을 추가한다. 속성 값은 항상 0x02(IPv6)로 설정한다.
  • 클라이언트는 REQUESTED-ADDRESS-FAMILY와 ADDITIONAL-ADDRESS-FAMILY를 동시에 포함하면 안된다.
  • 클라이언트는 RESERVATION-TOKEN 속성이 포함된 경우에는 ADDITIONAL-ADDRESS-FAMILY 속성을 포함해선 안된다.
  • 클라이언트는 EVEN-PORT 속성이 포함되고 속성값 중 R비트가 1로 설정되었을 경우, ADDITIONAL-ADDRESS-FAMILY 속성을 포함해선 안된다.
  • 클라이언트가 할당 요청 시 만료시간을 임의 설정하고자 한다면 LIFETIME 속성을 포함할 수도 있다.
  • 클라이언트가 할당 생성 후, 그 것을 이용할 때 DONT-FRAGMENT 속성을 포함하고자 한다면 먼저 할당 요청에 DONT-FRAGMENT 속성을 포함하여 요청하길 권장한다. 이를 통해 서버가 해당 속성을 지원하는지 확인할 수 있다.
  • 클라이언트가 짝수 포트를 할당 받고자 한다면 EVEN-PORT 속성을 포함시킨다. EVEN-PORT 속성 값에 R비트를 1로 설정한 경우, 서버는 짝수 포트 할당한 뒤 뒤이은 포트를 추가로 예약해 둔다. 클라이언트의 바로 다음 할당 요청은 이 예약된 포트를 할당 받게 된다.
  • 클라이언트가 RESERVATION-TOKEN을 포함할 경우, EVEN-PORT 속성은 생략해야 한다.

 

할당 요청 수신(Receiving an Allocate Request)

서버에서 할당 요청을 수신했을 때의 동작 명세.

할당 성공 시 아래의 속성은 항상 포함

  • XOR-RELAYED-ADDRESS : 릴레이 주소가 xor된 값
  • LIFETIME : 할당의 만료 시간
  • XOR-MAPPED-ADDRESS : STUN(RFC8489) Binding 메소드 결과와 동일. 즉, 클라이언트가 바인딩한 외부IP를 회신.

할당 성공 시 RESERVATION-TOKEN 속성은 이 할당에 연관된 두번째 릴레이 주소가 예약된 경우 포함됨

 

할당 성공 응답 수신(Receiving an Allocate Success Response)

서버로부터 할당 성공 응답을 받은 경우, 클라이언트는 응답에 포함된 릴레이 주소(relayed transport address)의 family가 사용 가능한 종류인지 확인해야 하고, 사용이 가능하지 않은 경우 생성된 '할당'을 직접 제거해야 한다. 그리고, 서버와의 불일치가 해결될 때까지 다른 '할당'을 생성하면 안된다. (※ 분석자 주: 이 명세는 '해결(fix)'의 의미가 모호하다. 추후 다른 내용이 있다면 덧붙인다.)

성공 응답에 ADDRESS-ERROR-CODE 속성이 포함된 경우에는 에러 응답으로 간주해야 한다. ADDRESS-ERROR-CODE의 코드에 따라 아래 실패 응답 수신 섹션의 안내대로 행동한다.

성공 응답 내에 STUN의 XOR-MAPPED-ADDRESS 속성도 포함이 되기 때문에 클라이언트에서 활용 가능하다.

 

할당 실패 응답 수신(Receiving an Allocate Error Response)

STUN의 에러 응답과 포맷이 동일하다. 아래에 에러 코드와 필수/권장 대응을 목록화하여 기술한다.
(※ 분석자 주: STUN과 마찬가지로 HTTP의 그 것과 다소 유사하다.)

 

408 (Request timed out)

서버 처리에 시간적 문제가 생긴 경우. 클라이언트는 전송 프로토콜을 바꾸는 등의 재시도를 해 볼 수 있다.

300 (Try Alternate)

HTTP의 3xx와 유사한 리다이렉션 상태다. 클라이언트는 이 에러 응답의 ALTERNATE-SERVER 속성의 주소를 참조하여 재시도하길 권한다.

400 (Bad Request)

HTTP의 400 코드와 유사하다. 클라이언트는 요청에 문제가 없었는지 점검해 보는 게 좋다.

401 (Unauthorized)

HTTP의 401 코드와 유사하다. 클라이언트는 인증 정보에 문제가 없었는지 점검해 보는 게 좋다.

403 (Forbidden)

HTTP의 403 코드와 유사하다. 클라이언트는 문제가 해결되기 전엔 더이상 재시도를 하지 않는게 좋다.

420 (Unknown Attribute)

STUN(RFC8489)과 동일한 에러 코드인데, 이 규격에서는 특별히 DONT-FRAGMENT 속성 지원 여부에 대한 에러이다. TURN에서는 이 에러를 받은 경우 서버에서 DONT-FRAGMENT를 지원하지 않는다고 인지해야 한다.

437 (Allocation Mismatch)

클라이언트의 특정 주소를 통해 이미 '할당'이 존재하는 경우. 이 경우 클라이언트는 자신의 주소를 바꿔가며(포트를 바꾸는 식으로) 3회 정도 재시도하는 것을 권한다. 3회 실패 시 해당 서버에 최소 2분 후에 새로운 시도를 하기를 권한다.

438 (Stale Nonce)

Nonce 값이 오래된 경우. RFC8489 참조

440 (Address Family not Supported)

REQUESTED-ADDRESS-FAMILY 또는 ADDITIONAL-ADDRESS-FAMILY 속성을 포함한 '할당' 요청에 대해 해당 family를 지원하지 않을 때. 이 경우 클라이언트는 응답한 서버에 해당 family 획득 요청을 더이상 하지 않아야 한다.

441 (Wrong Credentials)

인증 요청 정보가 틀린 경우. 인증 관련 정보가 정상화되기 전까지 재시도 하지 않는 것이 좋다.

442 (Unsupported Transport Address)

REQUESTED-TRANSPORT 속성값이 지원하지 않는 값일 경우. 이 경우 동일 요청을 재시도하지 않도록 한다. udp로 설정해서 요청한 경우에 이 에러를 받았다면 서버가 비정상인 상태이다.

486 (Allocation Quota Reached)

해당 클라이언트의 '할당' 요청을 더이상 허용하지 않는 경우. 클라이언트는 재시도 전에 1분 이상 기다리는 것을 고려해야 한다.

508 (Insufficient Capacity)

서버에서 더이상 릴레이 주소를 확보할 수 없는 경우. 클라이언트가 EVEN-PORT나 RESERVATION-TOKEN 속성을 이용했을 경우, 이 속성을 제거하거나 수정해서 바로 재시도 할 수 있다. 그 외에는 1분 이상 대기 후 재시도하도록 한다.

그 외

클라이언트가 대응하지 못하는 에러 코드는 RFC8489에 기술된대로 처리하도록 한다.

Posted by JMAN