| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2024

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (132)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR의 5G 특화망 솔루션 (my5G)  Updated   |   뉴젠스의 5G 특화망 구축 및 운영 서비스  NEW  

  스폰서채널 서비스란?
banner
banner
STUN(RFC 5780)을 이용한 NAT Behavior Discovery
RFC 5780: NAT Behavior Discovery using STUN
October 15, 2013 | By 유창모 (cmyoo@netmanias.com)
코멘트 (0)
13

 NAT 문서 모두 보기 

 

지난 시간을 통해 RFC 3489에서 정의하고 있는 NAT 타입 조사(NAT Behavior Discovery) 알고리즘에 대해 설명을 드렸는데요. 오늘은 RFC 5780의 NAT 타입 조사 알고리즘에 대해서 알아 보도록 하겠습니다.

 
지난 시간과 마찬가지로 본 내용을 이해하기 위해서는 아래 블로그글을 반드시 먼저 읽어 보시기 바랍니다.
 
 
STUN Protocol

 

STUN 프로토콜은 참 간단하게 설계 되어 있습니다. 단말(STUN Client)은 서버(STUN Server)로 Binding Request 메시지를 보내고, 서버는 그 응답으로 Binding Response 메시지를 단말로 보냅니다. 이게 전부입니다.

NAT 타입(Mapping & Filtering Behavior)을 검출하기 위해 서버는 2개의 Public IP 주소와 2개의 소스 포트(보통 3478, 3479)를 가지고 있어야 하며, 하나를 Primary IP/Port(예: 1.1.1.1:3478), 다른 하나를 Alternate IP/Port(예: 2.2.2.2:3479)라 부릅니다.

그리고 이 두 메시지에는 아래와 같은 Attribute들이 실리게 됩니다.

 

[Client -> Server] Binding Request message's Attribute

  • CHANGE-REQUEST: Filtering Behavior를 조사하기 위해 사용되는 attribute로, "Change IP" flag와 "Change Port" flag로 구성됩니다. 단말에서 이 flag를 0으로 하여 보내면, 서버는 단말이 전송한 Binding Request 메시지의 Destination IP/Port를 그대로 Binding Response 메시지의 Source IP/Port(예: 1.1.1.1:3478)로 사용하고, 만약 flag가 1로 되어 있으면 서버가 가지고 있는 다른 IP/Port(예: 2.2.2.2:3479)를 사용하여 응답하게 됩니다.
[Client <- Server] Binding Response message's Attribute
  • MAPPED-ADDRESS: 서버가 수신한 Binding Request 메시지의 Source IP/Port 값이 본 attribute에 실립니다. 만약 NAT가 존재하지 않는다면 이 필드의 값은 단말의 Source IP/Port가 될 것이고, NAT가 존재한다면 NAT에 의해 변경된 값이 들어갈 것입니다.
  • RESPONSE-ORIGIN: 서버가 전송하는 Binding Response 메시지의 Source IP/Port 정보가 이 attribute에 실립니다. 
  • OTHER-ADDRESS: 서버는 2개의 IP/Port를 가진다고 말씀드렸는데요. 이 attribute에는 서버가 수신한 Binding Request 메시지의 Destination IP/Port(서버의 IP/Port)와 다른 값의 (서버가 소유한) IP/Port가 실리게 됩니다.
  • XOR-MAPPED-ADDRESS: MAPPED-ADDRESS와 동일한 값이 XOR 연산으로 변형되어 실리게 됩니다. 이를 수신한 단말은 역시 XOR 연산을 통해 MAPPED-ADDRESS의 값을 알아 냅니다. 어떤 NAT의 경우 잘못된 ALG 구현으로 인해 Payload(Binding Request/Response 필드) 내에 IP 헤더와 동일한 IP 주소 값이 존재하면 이를 변경하는 경우가 있어 MAPPED-ADDRESS의 값이 훼손될 수 있습니다. 이와 같이 잘못된 ALG 구현으로 인한 NAT 타입 검출 오류를 방지하고자 XOR-MAPPED-ADDRESS를 정의하였습니다. 그래서 RFC 5780에서는 MAPPED-ADDRESS의 값을 사용하지는 않습니다. 다만 RFC 3489와의 하위 호환성을 위해 유지하고 있습니다.
 
NAT Mapping Behavior

 

아래는 RFC 5780에서 설명하고 있는 NAT Mapping Behavior Discovery 알고리즘입니다. 본 내용을 바탕으로 NAT의 Mapping  Behavior 타입 별로 시험 과정을 나누어 설명 드리도록 하겠습니다.


4.3  Determining NAT Mapping Behavior

 

This will require at most three tests.  In test I, the client performs the UDP connectivity test.  The server will return its alternate address and port in OTHER-ADDRESS in the binding response.  If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run. The client examines the XOR-MAPPED-ADDRESS attribute.  If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint-Independent.

 

In test II, the client sends a Binding Request to the alternate address, but primary port.  If the XOR-MAPPED-ADDRESS in the Binding Response is the same as test I the NAT currently has Endpoint-Independent Mapping.  If not, test III is performed: the client sends a Binding Request to the alternate address and port.  If the XOR-MAPPED-ADDRESS matches test II, the NAT currently has Address-Dependent Mapping; if it doesn't match it currently has Address and Port-Dependent Mapping.


 

■ Test (Discovery) Procedure

 

  • Test I을 통해 NAT의 존재 유무 확인
  • Test II를 통해 Endpoint-Independent Mapping NAT 식별
  • Test III를 통해 Address-Dependent Mapping NAT 혹은 Address and Port-Dependent Mapping NAT 식별
 
■ NAT가 없는 경우

 

■ Test I

  • 단말은 서버의 Primary IP:Primary Port(1.1.1.1:3478)로 Binding Request 메시지를 전송하고 그 응답으로 Binding Response 메시지를 수신합니다.
  • 그리고 단말은 아래 2개의 필드를 비교하여 그 값이 동일하면 단말과 인터넷 사이에 NAT가 없다고 판단합니다.
    • [a] Binding Request 메시지: IP 헤더 소스 정보 = 10.1.1.1.:40000
    • [b] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 10.1.1.1:40000
  • 서버는 Binding Request 메시지의 소스 정보[a]를 Binding Response 메시지의 XOR-MAPPED-ADDRESS[b]에 실어 단말로 전송하므로 이 2개의 값이 같다는 것은 NAT가 존재하지 않아 주소/포트 변환이 일어나지 않았다는 의미입니다.
 
■ Endpoint-Independent Mapping NAT(EIM-NAT)인 경우

 

■ Test I

  • 단말은 서버의 Primary IP:Primary Port(1.1.1.1:3478)로 Binding Request 메시지를 전송하고 그 응답으로 Binding Response 메시지를 수신합니다.
  • 그리고 단말은 아래 2개의 필드를 비교하여 그 값이 같지 않으면 단말과 인터넷 사이에 NAT가 존재한다고 판단하고 Test II를 진행합니다.
    • [a] Binding Request 메시지: IP 헤더 소스 정보 = 10.1.1.1.:40000
    • [b] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:40000
■ Test II
  • 단말은 서버로 Binding Request 메시지를 전송하는데 Test I과 다른 점은 Destination IP 주소로 Alternate IP를 사용한다는 것입니다. 즉, Alternate IP:Primary Port(2.2.2.2:3478)로 Binding Request 메시지를 송신하고 그 응답으로 Binding Response 메시지를 수신합니다. 
  • 그리고 단말은 아래 2개의 필드를 비교하여 그 값이 동일하면 EIM-NAT(Endpoint-Independent Mapping NAT)가 존재한다고 판단합니다.
    • [b] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:40000 
    • [c] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:40000
  • 즉, 서로 다른 Destination IP(1.1.1.1 or 2.2.2.2)로 전송한 2개의 패킷이 동일한 External IP:Port(5.5.5.1:40000)로 매핑되었으므로 EIM-NAT입니다.

 

■ Address-Dependent Mapping NAT(ADM-NAT)인 경우

 

■ Test I

  • EIM-NAT 시험과 동일
■ Test II
  • EIM-NAT 시험과 동일한 Binding Request 메시지를 전송하고 그 응답으로 Binding Response 메시지를 수신하여,
  • 단말은 아래 2개의 필드를 비교하여 그 값이 같지 않으면 EIM-NAT가 아니라고 판단하고 Test III를 진행합니다.
    • [b] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:40000 
    • [c] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:50000
■ Test III
  • 단말은 서버의 Alternate IP:Alternate Port(2.2.2.2:3479)로 Binding Request 메시지를 전송하고 그 응답으로 Binding Response 메시지를 수신합니다.
  • 그리고 단말은 아래 2개의 필드를 비교하여 그 값이 동일하면 ADM-NAT(Address-Dependent Mapping NAT)가 존재한다고 판단합니다.
    • [c] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:50000
    • [d] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:50000
  • 즉, 동일 Destination IP(2.2.2.2)에 서로 다른 Destination Port(3478 or 3479)로 전송한 2개의 패킷이 동일한 External IP:Port(5.5.5.1:50000)로 매핑되었으므로 ADM-NAT입니다.
 

■ Address and Port-Dependent Mapping NAT(APDM-NAT)인 경우

 

■ Test I

  • ADM-NAT 시험과 동일
 Test II
  • ADM-NAT 시험과 동일
■ Test III
  • ADM-NAT 시험과 동일한 Binding Request 메시지를 전송하고 그 응답으로 Binding Response메시지를 수신하며,
  • 단말은 아래 2개의 필드를 비교하여 그 값이 같지 않으면 APDM-NAT(Address and Port-Dependent Mapping NAT)가 존재한다고 판단합니다.
    • [c] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:50000 
    • [d] Binding Response 메시지: XOR-MAPPED-ADDRESS attribute = 5.5.5.1:60000
  • 즉, 동일 Destination IP(2.2.2.2)에 서로 다른 Destination Port(3478 or 3479)로 전송한 2개의 패킷이 서로 다른 External IP:Port(5.5.5.1:50000 and 5.5.5.1:60000)으로 매핑되었으므로 APDM-NAT입니다.

 

 

NAT Filtering Behavior

 

아래는 RFC 5780에서 설명하고 있는 NAT Filtering Behavior Discovery 알고리즘입니다. 


4.4  Determining NAT Filtering Behavior

 

In test I, the client performs the UDP connectivity test.  The server will return its alternate address and port in OTHER-ADDRESS in the binding response.  If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run.

 

In test II, the client sends a binding request to the primary address of the server with the CHANGE-REQUEST attribute set to change-port and change-IP.  This will cause the server to send its response from its alternate IP address and alternate port.  If the client receives a response, the current behavior of the NAT is Endpoint-Independent Filtering.

 

If no response is received, test III must be performed to distinguish between Address-Dependent Filtering and Address and Port-Dependent Filtering.  In test III, the client sends a binding request to the original server address with CHANGE-REQUEST set to change-port.  If the client receives a response, the current behavior is Address-Dependent Filtering; if no response is received, the current behavior is Address and Port-Dependent Filtering.


 

■ Test (Discovery) Procedure

 

 

  • Test II를 통해 Endpoint-Independent Filtering NAT 식별
  • Test III를 통해 Address-Dependent Filtering NAT 혹은 Address and Port-Dependent Filtering NAT 식별

 

■ Endpoint-Independent Filtering NAT(EIF-NAT)인 경우

 

■ Test I

  • 단말은 서버의 Primary IP:Primary Port(1.1.1.1:3478)로 Binding Request 메시지를 전송하고 이 때의 CHANGE-REQUEST attribute의 Change IP와 Change Port flag는 모두 0입니다. 그리고 당연히 응답으로 Binding Response 메시지를 수신합니다.
■ Test II
  • 이번에는 단말이 CHANGE-REQUEST attribute의 Change IP와 Change Port의 flag를 모두 1로 하여 Binding Request 메시지를 서버로 전송합니다.
  • 이를 수신한 서버는 수신된 패킷의 Primary IP:Primary Port(1.1.1.1:3478)와 다른 주소/포트인 Alternate IP:Alternate Port(2.2.2.2:3479)를 소스 정보로 하여 Binding Response 메시지를 단말로 전달합니다.
  • 만약 이 메시지가 수신되었다면 단말은 EIF-NAT(Endpoint-Independent Filtering NAT)가 존재한다고 판단합니다.
  • 즉, Outbound 패킷의 목적지 정보(1.1.1.1:3478)와 다른 소스 정보(2.2.2.2:3479)를 가진 Inbound 패킷을 허용(Allow)하였으므로 EIF-NAT입니다.

 

■ Address-Dependent Filtering NAT(ADF-NAT)인 경우

 

■ Test I

  • EIF-NAT 시험과 동일
■ Test II
  • EIF-NAT 시험과 동일한 Binding Request 메시지를 전송하고 그 응답을 수신하지 못하였습니다.
  • 따라서 단말은 EIM-NAT가 아니라고 판단을 하고 Test III 과정을 진행합니다.
■ Test III
  • 이번에는 단말이 CHANGE-REQUEST attribute의 Change Port flag만 1로 하여 Binding Request 메시지를 서버로 전송합니다.
  • 이를 수신한 서버는 수신된 패킷의 Primary IP:Primary Port(1.1.1.1:3478)와 동일 주소/다른 포트인 Primary IP:Alternate Port(1.1.1.1:3479)를 소스 정보로 하여 Binding Response 메시지를 단말로 전달합니다.
  • 만약 이 메시지가 수신되었다면 단말은 ADF-NAT(Address-Dependent Filtering NAT)가 존재한다고 판단합니다.
  • 즉, Outbound 패킷과 "동일 Destination IP & 다른 Port"를 소스 정보(1.1.1.1:3479)로 한 Inbound 패킷을 허용(Allow)하였으므로 ADF-NAT입니다.
 

■ Address and Port-Dependent Filtering NAT(APDF-NAT)인 경우

 

■ Test I

  • ADF-NAT 시험과 동일
■ Test II
  • ADF-NAT 시험과 동일
■ Test III
  • ADF-NAT 시험과 동일한 Binding Request 메시지를 전송하고 그 응답을 수신하지 못한 경우 단말은 APDF-NAT가 존재한다고 판단합니다.
  • 즉, 아래 두 종류의 Inbound 패킷을 모두 폐기(Deny)하였으므로 APDF-NAT입니다.
    • Outbound 패킷과 "다른 Destination IP & 다른 Port"를 소스 정보(2.2.2.2:3479)를 가진 Inbound 패킷
    • Outbound 패킷과 "동일 Destination IP & 다른 Port"를 소스 정보(1.1.1.1:3479)를 가진 Inbound 패킷
 

RFC 5780 NAT Behavior Discovery Tool 소개

 

□ Tool Name: STUNTMAN (STUN Server & Client)

□ URL: http://www.stunprotocol.org/

□ Test: ipTIME N2E를 대상으로 STUNTMAN을 이용하여 NAT Mapping & Filtering Behavior를 시험

□ Test Result: Endpoint-Independent Mapping & Address and Port-Dependent Filtering

 

 

요약

 

Mapping & Filtering Behavior 검사 방법을 요약하면,

  • NAT Mapping Behavior는 단말이 송신하는 Binding Request 메시지의 Primary/Alternate IP/Port 값을 변경하고, 그 응답으로 수신되는 Binding Response 메시지의 XOR-MAPPED-ADDRESS 값을 검사하여 Mapping Behavior를 판단하고,
  • NAT Filtering Behavior는 단말이 송신하는 Binding Request 메시지의 CHANGE-REQUEST flag를 변경하고, 그 응답의 도달 여부를 통해 Filtering Behavior를 판단합니다.

 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (1203)
5G (129) 5G 특화망 (42) AI (16) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (19) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (14) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (63) KT (46) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (15) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) O-RAN (2) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) Private 5G (53) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (42) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (3) 이음 5G (23)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2023년 6월 현재 넷매니아즈 회원은 55,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호