요약

  • 현대의 STUN(RFC 5389, RFC 8489)은 모듈형 도구로 기능하며, ICE(RFC 8445) 같은 상위 계층 프로토콜이 후보 교환과 피어 투 피어 연결성 검사에 사용하는 근거를 제공합니다.
  • STUN은 서버가 관찰한 반사 전송 주소(server-reflexive transport address), 즉 서버 관점의 관찰 결과를 보고할 뿐, 보편적인 도달 가능성이나 지속적인 신원을 보장하지 않습니다.
  • 도달 가능성, 동의, 보안 및 폴백은 STUN의 관찰 범위를 넘어, 이를 둘러싼 사용 책임으로 남아 있습니다.
  • 초기 STUN(RFC 3489)은 NAT 유형의 포괄적 분류와 주소 재사용을 목표로 했으나, 이 야심은 복잡성과 신뢰성 부족으로 이후 축소되었습니다.

패킷이 남긴 흔적

이야기는 단 하나의 패킷이 NAT를 통과하며 남기는 구체적인 흔적에서 시작됩니다. Network Address Translator(NAT) 뒤에서 작동하는 클라이언트 애플리케이션이 STUN(Session Traversal Utilities for NAT) Binding 요청을 시작합니다. 이 요청은 클라이언트가 아는 특정 로컬 IP 주소와 포트에서 전송됩니다. 패킷이 NAT를 통과하면서 NAT 장치는 출발지 IP 주소와 포트를 재작성하여 공용 전송 주소로 바꿉니다. 이 요청이 STUN 서버에 도착하면, 서버는 패킷을 받은 출발지 전송 주소를 기록합니다. 그런 다음 STUN 서버는 이 관찰된 출발지 전송 주소를XOR-MAPPED-ADDRESS속성에 담아 Binding 응답을 구성하고 클라이언트에게 되돌려 보냅니다^1^. 돌아온 이 주소는 특정 시점, 특정 트랜잭션에서 STUN 서버 관점에 따른 관찰 결과일 뿐입니다.

약속에 앞서 사용

ICE는 이러한 신중함을 절차로 만듭니다. [^5^ RFC 8445]에서 관찰된 주소는 증거가 아니라 후보로 입력됩니다. ICE는 STUN이 관찰한 단일 주소를 피어 투 피어 도달 가능성의 증거로 맹목적으로 신뢰하지 않습니다. 대신 ICE는 서버 반사 주소를 호스트 후보, (TURN을 통해 얻은) 릴레이 후보와 함께 하나의 "후보" 유형으로만 다룹니다. 그런 다음 ICE는 피어와 여러 후보 쌍을 교환하는 정교한 과정을 거치며, 이 쌍들을 통해 명시적인 피어 투 피어 연결성 검사를 수행합니다. 이 체계적 검사는 단일 관찰로부터 도달 가능성을 추론하는 대신 실제 도달 가능성을 확립합니다. 서로 다른 목적지, 다양한 프로토콜, NAT 장치 상태, 변화하는 방화벽 규칙 또는 대체 네트워크 경로는 특정 관찰 주소가 실제로 피어가 사용할 수 있는지 여부에 독립적으로 영향을 줄 수 있습니다.

단 하나의 STUN 응답만으로는 매핑의 수명, 모든 가능한 목적지에 대한 동작, 특정 방화벽 정책, 또는 원격 피어가 통신에 동의했는지 여부를 알 수 없습니다. STUN 내부의 인증 및 무결성 메커니즘은 정의된 교환을 보호하지만, 매핑된 튜플을 보편적 허가나 모든 잠재 피어에 대한 도달 가능성 보장으로 바꾸지는 못합니다. 따라서 후보 교환, 연결성 검사 수행, 동의 관리, 신선도 보장, 최적 경로 선택, 재전송 처리, 폴백 전략 구현, TURN 서버를 통한 릴레이 동작으로의 전환 결정 등에 대한 책임은 명시적으로 이를 둘러싼 사용에 있습니다.

야심이 달라진 이유

역사적으로 STUN은 [^2^ RFC 3489]에 문서화된 대로 더 야심적인 비전을 담고 있었습니다. 이 문서는 서버 반사 주소를 밝히는 것뿐 아니라 NAT 장치 유형(full-cone, restricted-cone, port-restricted-cone 등)을 분류하고 피어 투 피어 연결 통과를 위한 완전한 솔루션까지 제공하려 했습니다. 그 기저 전제는 NAT 유형을 이해하고 외부 매핑을 관찰하면 클라이언트가 자신의 주소가 다른 피어에게 어떻게 보일지 신뢰할 수 있게 예측하여 직접 연결을 쉽게 만들 수 있다는 것이었습니다. 이 접근은 단일 관찰을 보편적인 도달 가능성 선언으로 바꾸려는 것이었습니다.

그러나 실제 배포와 운영 경험은 상당한 한계를 드러냈습니다. 실세계 NAT 구현, 방화벽, 네트워크 토폴로지의 복잡성과 다양성 때문에 NAT 분류는 종종 신뢰할 수 없거나 오해를 낳았습니다. STUN을 통해 학습한 주소는 어떤 피어에는 사용 가능하지만 다른 피어에는 그렇지 않을 수 있고, 매핑 수명도 예측 불가능할 수 있습니다. 자립적인 통과 솔루션으로서 RFC 3489의 큰 비전은 불충분한 것으로 판명되었습니다. 이 비판적 재평가가 [^3^ RFC 5389]로 이어졌으며, 이 문서는 RFC 3489의 고전적 완전 솔루션 야심이 폐기된 이유를 명시적으로 문서화했습니다. RFC 5389는 STUN의 역할을 포괄적 통과 메커니즘에서 상위 수준 사용이 활용하는 기초 도구로 재배치했습니다. STUN 서버가 관찰한 주소는 귀중한 근거이지만, 지속적인 공개 신원도 아니고 임의의 피어가 같은 매핑을 통신에 사용할 수 있다는 보장도 아닙니다.

현재의 경계

현재 STUN 표준인 [^4^ RFC 8489]는 이 도구와 사용 사이의 더 좁고 집중된 경계를 유지합니다. RFC 8489는 서버 반사 전송 주소를 발견하는 핵심 메커니즘을 정의하고, 진단 목적의ERROR-CODE같은 다른 속성도 규정합니다. 결정적으로 RFC 8489는 상위 수준 프로토콜과 애플리케이션이 이 관찰 결과를 해석하고 활용할 책임이 있음을 명확히 합니다. 시점 결정, 다양한 속성 처리, STUN 서버 선택, 전송 프로토콜 선택에 관한 결정의 소유자는 바로 이들입니다.