-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc5128.txt
1149 lines (943 loc) · 79.2 KB
/
rfc5128.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group P. Srisuresh
Request for Comments: 5128 Kazeon Systems
Category: Informational B. Ford
M.I.T.
D. Kegel
kegel.com
March 2008
네트워크 주소 변환기(NAT)를 통한 P2P(Peer-to-Peer) 통신의 상태
Status of This Memo
이 메모는 인터넷 커뮤니티에 대한 정보를 제공합니다. 어떤 종류의 인터넷 표준도 지정하지
않습니다. 메모 배포에 제한은 없습니다.
개요
이 메모는 현재 네트워크 주소 변환기(NAT)가 있는 상태에서 직접 통신을 설정하기 위해 응용
프로그램에서 사용 중인 것으로 알려진 다양한 방법을 문서화합니다. 이 메모는 주로 설명을 위한
것이지만 보안 고려 사항 섹션에서는 설명된 방법을 사용할 때 응용 프로그램이 실수로 생성할 수
있는 보안 취약점을 처리하는 방법에 대한 순전히 권고 사항을 제공합니다. 이 메모는 TCP 및
UDP 기반 애플리케이션에서 사용되는 NAT 순회 접근 방식을 다룹니다. 이 메모는 설명된 방법을
보증하는 것이 아니라 문서에서 캡처하려는 시도일 뿐입니다.
목차
1. Introduction and Scope (소개 및 범위)
2. Terminology and Conventions Used (사용된 용어 및 규약)
2.1. Endpoint
2.2. Endpoint Mapping
2.3. Endpoint-Independent Mapping
2.4. Endpoint-Dependent Mapping
2.5. Endpoint-Independent Filtering
2.6. Endpoint-Dependent Filtering
2.7. P2P Application
2.8. NAT-Friendly P2P Application
2.9. Endpoint-Independent Mapping NAT (EIM-NAT)
2.10. Hairpinning
3. Techniques Used by P2P Applications to Traverse NATs (NAT 통과를 위해 P2P 애플리케이션에서 사용하는 기술)
3.1. Relaying (중계))
3.2. Connection Reversal
3.3. UDP Hole Punching
3.3.1. Peers behind Different NATs (다른 NAT 뒤의 피어)
3.3.2. Peers behind the Same NAT (동일한 NAT 뒤에 있는 피어)
3.3.3. Peers Separated by Multiple NATs (여러 NAT로 분리된 피어)
3.4. TCP Hole Punching
3.5. UDP Port Number Prediction (UDP 포트 번호 예측)
3.6. TCP Port Number Prediction (TCP 포트 번호 예측)
4. Recent Work on NAT Traversal (NAT 순회에 대한 최근 작업)
5. Summary of Observations (관찰 요약)
5.1. TCP/UDP Hole Punching
5.2. NATs Employing Endpoint-Dependent Mapping
5.3. Peer Discovery
5.4. Hairpinning
6. Security Considerations (보안 고려 사항)
6.1. Lack of Authentication Can Cause Connection Hijacking (인증 부족으로 인한 커넥션 하이재킹 야기)
6.2. Denial-of-Service Attacks
6.3. Man-in-the-Middle Attacks
6.4. Security Impact from EIM-NAT Devices
7. Acknowledgments (감사의 말)
8. References (참조)
8.1. Normative References (규범적 참조)
8.2. Informative References (유용한 참조)
1. Introduction and Scope (소개 및 범위)
오늘날의 인터넷은 네트워크 주소 변환기(NATs)의 유비쿼터스 배치를 보았습니다. 배치에서 NAT
장치를 활용하는 다양한 NAT 장치 및 다양한 네트워크 토폴로지가 있습니다. 이러한 NAT 장치에
의해 설정된 비대칭 주소 지정 및 연결 체계는 원격 회의 및 멀티플레이어 온라인 게임과 같은
peer-to-peer(P2P) 애플리케이션 및 프로토콜에 고유한 문제를 발생시켰습니다. 이러한
문제는 IPv6 세계에서도 지속될 가능성이 높습니다. IPv6으로 전환하는 동안 IPv4 전용
노드가 IPv6 전용 노드[NAT-PT]와 통신할 수 있도록 하기 위해 일부 형태의 NAT가 필요할 수
있습니다[NAT-PT-HIST]. 미래의 "순수한 IPv6 세계"에도 NAT와 유사한 필터링 동작을
사용하지만 주소 변환[V6-CPE-SEC]이 없는 방화벽이 여전히 포함될 수 있습니다. 필터링 동작은
P2P 애플리케이션의 기능을 방해합니다. 이러한 이유로 NAT 통과를 위해 이 문서에 설명된 기술을
사용하는 IPv6 응용 프로그램은 NAT와 유사한 필터링 동작이 있는 일부 방화벽에서도 작동할 수
있습니다.
현재 배포된 NAT 장치는 클라이언트/서버 패러다임을 중심으로 설계되었으며, 사설 네트워크
내부의 상대적으로 익명인 클라이언트 시스템은 안정적인 IP 주소와 DNS 이름을 사용하여 공인
서버에 대한 연결을 시작합니다. 도중에 만나는 NAT 장치는 클라이언트 시스템에 동적 주소
할당을 제공합니다. NAT 장치 뒤에 있는 내부 호스트의 익명성(사설 IP 주소) 및 액세스
불가능성에 대한 환상은 나가는 연결만 시작하면 되는 웹 브라우저와 같은 응용 프로그램에서는
문제가 되지 않습니다. 이러한 익명성과 접근 불가능성에 대한 환상은 때때로 개인 정보 보호
혜택으로 인식됩니다. [RFC4941]의 섹션 2.2에 언급된 바와 같이, Small-Office-Home
-Office (SOHO) NAT를 사용하는 대부분의 경우 이러한 개인 정보 보호는 환상일 수
있습니다.
P2P 패러다임에서 일반적으로 "클라이언트"로 간주되는 인터넷 호스트는 피어 노드에 대한
세션을 시작할 뿐만 아니라 피어 노드가 시작한 세션도 수락합니다. 개시자와 응답자는 영구 IP
주소나 다른 형태의 공인 네트워크 존재를 갖지 않는 엔드포인트 없이 서로 다른 NAT 장치
뒤에 있을 수 있습니다. 예를 들어, 일반적인 온라인 게임 아키텍처는 자신을 등록하고 피어
호스트를 검색하기 위해 공개적으로 주소 지정이 가능한 랑데부 서버에 접속하는 모든 참여
애플리케이션 호스트를 포함합니다. 랑데부 서버와의 통신에 이어 호스트는 게임 플레이 중에
업데이트를 빠르고 효율적으로 전파하기 위해 서로 직접 연결을 설정합니다. 마찬가지로 파일
공유 응용 프로그램은 리소스 검색 또는 검색을 위해 잘 알려진 랑데부 서버에 연결할 수 있지만
데이터 전송을 위해 피어 호스트와 직접 연결을 설정할 수 있습니다. NAT 장치 뒤에 있는
호스트는 일반적으로 다른 피어에서 들어오는 TCP 또는 UDP 연결이 향할 수 있는 인터넷에서
영구적으로 볼 수 있는 공인 포트가 없기 때문에 NAT 장치는 피어 투 피어 연결에 문제를
일으킵니다. RFC 3235[NAT-APPL]는 이 문제를 간략하게 설명합니다.
[NAT-PMP], [NSIS-NSLP], [SOCKS], [RSIP], [MIDCOM] 및 [UPNP]와 같이 응용
프로그램과 NAT 장치 간의 명시적 신호를 포함하는 NAT 통과 전략은 이 문서의 범위를
벗어납니다. 사용 가능한 경우 이러한 기술은 문서에 설명된 기술을 보완합니다. [UNSAF]가
범위 내에 있습니다.
이 문서에서는 응용 프로그램이 NAT 장치를 직접 변경하지 않고 NAT 장치를 우회하여 작동하는
현재 알려진 방법을 요약합니다. 설명된 기술은 BEHAVE 문서([BEH-UDP], [BEH-TCP] 및
[BEH-ICMP]) 이전 버전입니다. 문서의 범위는 응용 프로그램의 엔드포인트 간에 양방향 통신을
설정하는 데 사용되는 현재 알려진 기술을 설명하는 것으로 제한됩니다. 실행 중인 세션과 관련된
시간 초과, RST 처리, keepalive 등에 대한 논의는 이 문서의 범위를 벗어납니다. 또한
범위는 TCP 및 UDP 기반 응용 프로그램에 대한 기술을 설명하는 것으로 제한됩니다. 이 문서의
목적은 일반적인 애플리케이션[BEH-APP] 또는 특정 클래스의 애플리케이션[ICE]에 대한 NAT
통과 문제에 대한 솔루션을 제공하는 것이 아닙니다.
2. Terminology and Conventions Used (사용된 용어 및 규약)
이 문서에서는 IP 주소 192.0.2.1, 192.0.2.128 및 192.0.2.254를 공인 IP 주소의
예로 사용합니다[RFC3330]. 이러한 주소는 모두 동일한 /24 네트워크에 있지만 이는
[RFC3330]에서 사용할 수 있는 예제 주소의 제한 사항입니다. 실제로 이러한 주소는 서로 다른
네트워크에 있습니다. 포트 사용에 대한 표기는 모든 클라이언트가 1-2000 범위의 포트를
사용하고 서버는 20000-21000 범위의 포트를 사용합니다. NAT 장치는 엔드포인트 매핑에 포트
30000 이상을 사용합니다.
NAT 분류 및 용어에 대한 정보는 [NAT-TERM]을 참조하십시오. NAT 유형이 앞에 붙거나 달리
명시적으로 언급되지 않는 한, 이 문서 전체에서 사용되는 NAT라는 용어는 기존 NAT[NAT-
TRAD]를 나타냅니다. 기존 NAT에는 기본 NAT와 네트워크 주소 포트 변환기(NAPT)의 두 가지
변형이 있습니다. 이 중에서 NAPT는 가장 일반적으로 배포되는 NAT 장치입니다. NAPT를
사용하면 여러 사설 호스트가 단일 공인 IP 주소를 동시에 공유할 수 있습니다.
P2P 애플리케이션과 관련된 문제는 내부 호스트가 단일 엔드포인트(사설 IP, 사설 포트)에서
외부 네트워크의 여러 개별 엔드포인트로 여러 동시 세션을 시작할 때 NAT가 작동하는 방식입니다.
[STUN]은 "Full Cone", "Restricted Cone", "Port Restricted Cone" 및
"Symmetric"이라는 용어를 사용하여 NAT 구현을 추가로 분류합니다. 불행하게도 이 용어는
많은 혼란의 원인이 되어 왔습니다. 이러한 이유로 이 문서는 NAT 구현을 구별하기 위해
[BEH-UDP]의 용어를 채택합니다.
아래 목록은 이 문서 전체에서 사용되는 용어입니다.
2.1. Endpoint
엔드포인트는 끝 호스트의 세션별 튜플입니다. 엔드포인트는 각 IP 프로토콜에 대해 다르게
표시될 수 있습니다. 예를 들어 UDP 또는 TCP 세션 엔드포인트는 (IP 주소, UDP/TCP
포트)의 튜플로 표시됩니다.
2.2. Endpoint Mapping
사설 영역의 호스트가 NAT 장치를 통해 공용 영역의 호스트로 나가는 세션을 시작하면 NAT 장치는
외부 호스트의 후속 응답 패킷을 NAT에서 수신할 수 있도록 사설 엔드포인트를 변환할 공인
엔드포인트를 할당하고, 번환되어 및 사설 endpoint로 전달됩니다. 사설 엔드포인트를 공인
엔드포인트로 또는 그 반대로 변환하기 위한 NAT 장치의 할당을 Endpoint Mapping이라고
합니다. NAT는 Endpoint Mapping을 사용하여 세션 기간 동안 변환을 수행합니다.
2.3. Endpoint-Independent Mapping
"Endpoint-Independent Mapping"은 다음과 같이 [BEH-UDP]에서 정의됩니다:
NAT는 동일한 내부 IP 주소 및 포트(X:x)에서 외부 IP 주소 및 포트로 전송되는 후속
패킷에 대해 포트 매핑을 재사용합니다.
2.4. Endpoint-Dependent Mapping
"Endpoint-Dependent Mapping"은 [BEH-UDP]에 정의된 "Address Dependent
Mapping"와 "Address and Port-Dependent Mapping"의 조합을 나타냅니다.
Address-Dependent Mapping
NAT는 외부 포트에 관계없이 동일한 내부 IP 주소 및 포트(X:x)에서 동일한 외부 IP
주소로 전송되는 후속 패킷에 대해 포트 매핑을 재사용합니다.
Address and Port-Dependent Mapping
NAT는 매핑이 여전히 활성 상태인 동안 동일한 내부 IP 주소 및 포트(X:x)에서 동일한
외부 IP 주소 및 포트로 전송되는 후속 패킷에 대해 포트 매핑을 재사용합니다.
2.5. Endpoint-Independent Filtering
"Endpoint-Independent Filtering"은 다음과 같이 [BEH-UDP]에서 정의됩니다:
NAT는 외부 IP 주소 및 포트 소스(Z:z)에 관계없이 내부 주소 및 포트 X:x로 향하지
않는 패킷만 필터링합니다. NAT는 X:x로 향하는 모든 패킷을 전달합니다. 즉, NAT의
내부에서 외부 IP 주소로 패킷을 보내는 것만으로도 모든 패킷이 내부 엔드포인트로
되돌아가도록 허용하기에 충분합니다.
"Endpoint-Independent Mapping"과 "Endpoint-Independent Filtering"의
조합을 사용하는 NAT 장치는 공인 네트워크의 모든 외부 엔드포인트에서 매핑된 공인 포트로
들어오는 트래픽을 허용합니다.
2.6. Endpoint-Dependent Filtering
"Endpoint-Dependent Filtering"은 [BEH-UDP]에서 정의된 "Address Dependent
Filtering"과 "Address and Port-Dependent Filtering"의 조합을 나타냅니다.
Address-Dependent Filtering
NAT는 내부 주소 X:x로 향하지 않는 패킷을 필터링합니다. 또한 NAT는 X:x가 이전에
Y:any로 패킷을 전송하지 않은 경우 내부 엔드포인트 X:x로 향하는 Y:y의 패킷을
필터링합니다(Y에서 사용하는 포트와 무관). 즉, 특정 외부 종단점으로부터 패킷을
수신하기 위해서는 내부 종단점이 특정 외부 종단점의 IP 주소로 먼저 패킷을 보내야
합니다.
Address and Port-Dependent Filtering
NAT는 내부 주소 X:x로 향하지 않는 패킷을 필터링합니다. 또한 NAT는 X:x가 이전에
Y:y로 패킷을 보내지 않은 경우 내부 엔드포인트 X:x로 향하는 Y:y의 패킷을
필터링합니다. 즉, 특정 외부 종단점으로부터 패킷을 받기 위해서는 내부 종단점이 먼저
그 외부 종단점의 IP 주소와 포트로 패킷을 보내야 합니다.
"Endpoint-Dependent Filtering"을 사용하는 NAT 장치는 공인 네트워크의 제한된 외부
엔드포인트 집합에서 매핑된 공인 포트로 들어오는 트래픽만 허용합니다.
2.7. P2P Application (P2P 애플리케이션)
P2P 애플리케이션은 동일한 엔드포인트를 사용하여 피어링 호스트로 나가는 세션을 시작하고
피어링 호스트에서 들어오는 세션을 수락하는 애플리케이션입니다. P2P 애플리케이션은 P2P
통신을 위해 여러 엔드포인트를 사용할 수 있습니다.
2.8. NAT-Friendly P2P Application (NAT 친화적 P2P 애플리케이션)
NAT 친화적인 P2P 애플리케이션은 피어링 노드가 하나 이상의 NAT로 연결된 개별 IP 주소
영역에 있는 경우에도 효과적으로 작동하도록 설계된 P2P 애플리케이션입니다.
P2P 애플리케이션이 피어링 세션을 설정하고 NAT 친화적인 상태를 유지하는 일반적인 방법 중
하나는 등록 및 피어 검색 목적으로 공인 주소 지정이 가능한 랑데뷰 서버를 사용하는 것입니다.
2.9. Endpoint-Independent Mapping NAT (EIM-NAT)
Endpoint-Independent Mapping NAT (EIM-NAT)는 엔드포인트 독립 매핑을 사용하는
NAT 장치입니다. EIM-NAT는 모든 유형의 필터링 동작을 가질 수 있습니다. BEHAVE 호환
NAT 장치는 EIM-NAT 장치의 좋은 예입니다. 주소 종속 매핑을 사용하는 NAT 장치는
EIM-NAT가 아닌 NAT 장치의 예입니다.
2.10. Hairpinning (헤어피닝)
Hairpinning은 [BEH-UDP]에서 다음과 같이 정의됩니다:
두 호스트(X1 및 X2라고 함)가 동일한 NAT 뒤에 있고 트래픽을 교환하는 경우 NAT는
X2':x2'라고 하는 X2의 NAT 외부에 주소를 할당할 수 있습니다. X1이 트래픽을
X2':x2'로 보내면 트래픽은 X1에서 X2로 릴레이해야 하는 NAT로 이동합니다. 이것을
Hairpinning이라고 합니다.
현재 배포된 모든 NAT가 Hairpinning을 지원하는 것은 아닙니다.
3. Techniques Used by P2P Applications to Traverse NATs (NAT 통과를 위해 P2P 애플리케이션에서 사용하는 기술)
이 섹션에서는 응용 프로그램 또는 프로토콜 설계자의 관점에서 기존 NAT 장치를 통해
peer-to-peer 통신을 구현하기 위해 현재 알려진 기술을 자세히 검토합니다.
3.1. Relaying (중계)
NAT 장치가 있는 상태에서 peer-to-peer 통신을 구현하는 가장 안정적이지만 가장 비효율적인
방법은 peer-to-peer 통신을 릴레이를 통한 클라이언트/서버 통신처럼 네트워크에 보이게
만드는 것입니다. 그림 1의 시나리오를 고려하십시오. 두 클라이언트 호스트 A와 B는 각각 잘
알려진 랑데뷰 서버 S에 대한 TCP 또는 UDP 연결을 시작했습니다. 랑데뷰 서버 S는 공인 주소
지정이 가능한 IP 주소를 가지며 등록, 검색 및 릴레이 목적으로 사용됩니다. NAT 뒤의 호스트는
서버에 등록됩니다. 피어 호스트는 NAT 뒤에 있는 호스트를 검색하고 서버를 사용하여 모든
end-to-end 메시지를 릴레이할 수 있습니다. 클라이언트는 별도의 사설 네트워크에 상주하며
각각의 NAT 장치는 클라이언트가 다른 클라이언트에 직접 연결을 시작하지 못하도록 합니다.
Registry, Discovery
Combined with Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
+--------------+ +--------------+
| |
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
그림 1: 릴레이 서버를 사용하여 피어와 통신
직접 연결을 시도하는 대신 두 클라이언트는 서버 S를 사용하여 메시지를 릴레이할 수 있습니다.
예를 들어 클라이언트 B에게 메시지를 보내기 위해 클라이언트 A는 이미 설정된 클라이언트/서버
연결을 따라 서버 S로 메시지를 보내고 서버 S는 B와의 기존 클라이언트/서버 연결을 사용하여
클라이언트 B로 메시지를 보냅니다.
이 방법은 두 클라이언트가 서버에 연결되어 있는 한 항상 작동한다는 장점이 있습니다. 도중
NAT 장치는 EIM-NAT일 필요가 없습니다. 릴레이의 명백한 단점은 서버의 처리 능력과
네트워크 대역폭을 소모하고 서버가 충분한 I/O 대역폭을 가지고 있고 토폴로지 측면에서 올바른
위치에 있더라도 피어링 클라이언트 간의 통신 대기 시간이 증가할 가능성이 있다는 것입니다.
TURN 프로토콜[TURN]은 상대적으로 안전한 방식으로 응용 프로그램에 구애받지 않는 세션 지향
패킷 릴레이를 구현하는 방법을 정의합니다.
3.2. Connection Reversal (연결 반전)
직접 통신을 위한 다음 연결 반전 기술은 피어 중 하나가 NAT 장치 뒤에 있고 다른 하나는
그렇지 않은 경우에만 작동합니다. 예를 들어 그림 2의 시나리오를 고려하십시오. 클라이언트
A는 NAT 뒤에 있지만 클라이언트 B는 공인 주소 지정이 가능한 IP 주소를 가지고 있습니다.
Rendezvous Server S에는 공인 주소 지정이 가능한 IP 주소가 있으며 등록 및 검색
목적으로 사용됩니다. NAT 뒤의 호스트는 엔드포인트를 서버에 등록합니다. 피어 호스트는 서버를
사용하여 NAT 뒤에 있는 호스트의 엔드포인트를 검색합니다.
Registry and Discovery
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:1234 | |
| |
| ^ P2P Session (A-B) ^ | P2P Session (B-A) | |
| | 192.0.2.254:1234 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | v 192.0.2.254:1234 v |
| |
+--------------+ |
| 192.0.2.1 | |
| | |
| NAT A | |
+--------------+ |
| |
| ^ Registry Session(A-S) ^ |
| | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | |
| |
| ^ P2P Session (A-B) ^ |
| | 192.0.2.254:1234 | |
| | 10.0.0.1:1234 | |
| |
Private Client A Public Client B
10.0.0.1:1234 192.0.2.254:1234
그림 2: Rendezvous 서버를 사용한 연결 반전
클라이언트 A는 사설 IP 주소 10.0.0.1을 가지고 있으며 응용 프로그램은 TCP 포트 1234를
사용하고 있습니다. 이 클라이언트는 공인 IP 주소 192.0.2.128 및 포트 20001에서
서버 S와 연결을 설정했습니다. NAT A는 자신의 공인 IP 주소 192.0.2.1에서 TCP 포트
62000을 할당하여 A와 S의 세션에 대한 임시 공인 엔드포인트 주소로 사용했습니다. 따라서
서버 S는 클라이언트 A가 포트 62000을 사용하는 IP 주소 192.0.2.1에 있다고 믿습니다.
그러나 클라이언트 B는 고유한 영구 IP 주소 192.0.2.254를 가지며 B의 응용 프로그램은
포트 1234에서 TCP 연결을 수락합니다.
이제 클라이언트 B가 클라이언트 A와 직접 통신 세션을 설정하려고 한다고 가정합니다. B는 먼저
클라이언트 A가 자신이 가지고 있다고 믿는 주소(즉, 10.0.0.1:1234) 또는 서버 S가 관찰한
A의 주소(즉, 192.0.2.1:62000)에서 클라이언트 A에 접속을 시도할 수 있습니다. 두 경우
모두 연결이 실패합니다. 첫 번째 경우 10.0.0.1은 공개적으로 라우팅할 수 있는 IP 주소가
아니기 때문에 IP 주소 10.0.0.1로 향하는 트래픽은 네트워크에서 단순히 삭제됩니다. 두 번째
경우 B의 TCP SYN 요청은 포트 62000으로 지정된 NAT A에 도착하지만 나가는 연결만
허용되기 때문에 NAT A는 연결 요청을 거부합니다.
A에 대한 직접 연결 설정을 시도하고 실패한 후 클라이언트 B는 서버 S를 사용하여 클라이언트
A에 대한 요청을 릴레이하여 클라이언트 B에 대한 "역방향" 연결을 시작할 수 있습니다.
클라이언트 A는 S를 통해 이 릴레이된 요청을 수신하면 B의 공인 IP 주소 및 포트 번호에서
클라이언트 B에 대한 TCP 연결을 엽니다. NAT A는 방화벽 내부에서 시작되기 때문에 연결
진행을 허용하고 클라이언트 B는 NAT 장치 뒤에 있지 않기 때문에 연결을 수신할 수 있습니다.
현재 다양한 peer-to-peer 애플리케이션이 이 기술을 구현합니다. 물론 주요 제한 사항은 통신
피어 중 하나만 NAT 장치 뒤에 있는 경우에만 작동한다는 것입니다. NAT 장치가 EIM-NAT인
경우 퍼블릭 클라이언트는 외부 서버 S에 연결하여 클라이언트-A에서 시작된 연결을 예상하고 해당
엔드포인트의 연결을 허용할 특정 공인 엔드포인트를 결정할 수 있습니다. NAT 장치가 EIM-NAT인
경우 퍼블릭 클라이언트는 외부 서버 S에 연결하여 클라이언트 A에서 시작된 연결을 예상하고 해당
엔드포인트로부터의 연결을 허용할 특정 공인 엔드포인트를 결정할 수 있습니다. NAT 장치가
EIM-NAT가 아닌 경우 퍼블릭 클라이언트는 클라이언트 A에서 시작된 연결을 예상하는 공인 퍼블릭
엔드포인트를 알 수 없습니다. 두 피어가 모두 NAT 뒤에 있을 수 있는 점점 더 일반적인 경우에
연결 반전 방법이 실패합니다. 연결 반전은 P2P 연결 문제에 대한 일반적인 해결책이 아닙니다.
"정방향" 또는 "역방향" 연결을 설정할 수 없는 경우 응용 프로그램은 종종 릴레이와 같은 다른
메커니즘으로 대체됩니다.
3.3. UDP Hole Punching (UDP 홀 펀칭)
UDP 홀 펀칭은 EIM-NAT의 속성에 의존하여 적절하게 설계된 P2P 애플리케이션이 NAT 장치를
통해 "구멍을 뚫고" 서로 간에 직접 연결을 설정할 수 있도록 합니다. 호스트 중 하나가
EIM-NAT가 아닌 NAT 뒤에 있는 경우 피어링 호스트는 연결을 시작할 매핑된 엔드포인트를
예측할 수 없습니다. 또한 비 EIM-NAT 뒤에 있는 호스트의 애플리케이션은 다른 외부 대상과의
통신을 위해 이미 설정된 엔드포인트 매핑을 재사용할 수 없으며 홀 펀칭 기술이 실패합니다.
이 기술은 RFC 3027 [NAT-PROT]의 섹션 5.1에서 간략하게 언급되었으며 [KEGEL]에서
처음 설명되었으며 일부 최근 프로토콜 [TEREDO, ICE]에서 사용되었습니다. "TCP 홀 펀칭"에
대한 자세한 내용은 섹션 3.4를 참조하십시오.
우리는 두 가지 특정 시나리오와 두 시나리오를 정상적으로 처리하도록 애플리케이션을 설계하는
방법을 고려할 것입니다. 일반적인 경우를 나타내는 첫 번째 상황에서 직접 P2P 통신을 원하는 두
클라이언트가 두 개의 서로 다른 NAT 뒤에 상주합니다. 두 번째에서 두 클라이언트는 실제로
동일한 NAT 뒤에 상주하지만 반드시 알 필요는 없습니다.
3.3.1. Peers behind Different NATs (다른 NAT 뒤의 피어)
그림 3의 시나리오를 고려하십시오. 클라이언트 A와 B는 둘 다 사설 IP 주소를 가지고 있으며
서로 다른 NAT 장치 뒤에 있습니다. Rendezvous Server S는 공개적으로 주소를 지정할 수
있는 IP 주소를 가지며 등록, 검색 및 제한된 릴레이 목적으로 사용됩니다. NAT 뒤의 호스트는
공인 엔드포인트를 서버에 등록합니다. 피어 호스트는 서버를 사용하여 NAT 뒤에 있는 호스트의
공인 엔드포인트를 검색합니다. 섹션 3.1과 달리 피어 호스트는 서버를 사용하여 종단 간 메시지
대신 연결 시작 제어 메시지만 중계합니다.
클라이언트 A와 B에서 실행 중인 P2P 애플리케이션은 UDP 포트 1234를 사용합니다. 랑데부
서버 S는 UDP 포트 20001을 사용합니다. A와 B는 각각 서버 S와의 UDP 통신 세션을
시작하여 NAT A가 자체 공인 UDP 포트를 할당하도록 합니다. A와 S의 세션에 대해 62000,
NAT B가 포트 31000을 S와 B의 세션에 각각 할당하도록 합니다.
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
그림 3: 직접 연결을 설정하기 위한 UDP 홀 펀칭
이제 클라이언트 A가 클라이언트 B와 직접 UDP 통신 세션을 설정하려고 한다고 가정해
보겠습니다. A가 단순히 UDP 메시지를 B의 공인 엔드포인트 192.0.2.254:31000으로 보내기
시작하면 NAT B는 일반적으로 이러한 들어오는 메시지를 버립니다(엔드포인트 독립적 필터링을
사용하지 않는 한). 소스 주소와 포트 번호가 원래 나가는 세션이 설정된 S의 주소와 일치하지 않기
때문입니다. 마찬가지로 B가 UDP 메시지를 A의 공인 엔드포인트로 보내기 시작하면 NAT A는
일반적으로 이러한 메시지를 버립니다.
A가 B의 공인 엔드포인트로 UDP 메시지를 보내기 시작하고 동시에 서버 S를 통해 B로 요청을
릴레이하여 B에게 A의 공인 엔드포인트로 UDP 메시지를 보내도록 요청한다고 가정합니다. B의 공인
엔드포인트(192.0.2.254:31000)로 향하는 A의 발신 메시지는 EIM-NAT A가 A의 사설
엔드포인트와 B의 공인 엔드포인트 간에 새로운 통신 세션을 열도록 합니다. 동시에 A의 공인
엔드포인트(192.0.2.1:62000)에 대한 B의 메시지는 EIM-NAT B가 B의 사설 엔드포인트와 A의
공인 엔드포인트 간에 새로운 통신 세션을 열도록 합니다. 새로운 UDP 세션이 각 방향으로 열리면
클라이언트 A와 B는 서버 S에 추가 부담 없이 서로 직접 통신할 수 있습니다. 피어 호스트에 대한
"소개" 서버와 같습니다.
UDP 홀 펀칭 기술에는 몇 가지 유용한 속성이 있습니다. NAT 장치 뒤에 있는 두 클라이언트
사이에 직접 P2P UDP 연결이 설정되면 해당 연결의 어느 쪽이든 "소개자"의 역할을 대신할 수
있고 상대방이 추가로 P2P 연결을 설정하도록 도울 수 있습니다. 초기 도입 서버 S의 부하를
최소화합니다. 애플리케이션은 뒤에 있는 NAT 장치의 종류를 감지하려고 시도할 필요가 없습니다.
위의 절차는 클라이언트 중 하나 또는 둘 모두가 NAT 장치 뒤에 있지 않은 경우 동등하게
peer-to-peer 통신 채널을 설정하기 때문입니다. UDP 홀 펀칭 기술은 하나 또는 두 개의
클라이언트가 둘 이상의 주소 변환 수준을 통해 공인 인터넷에서 멀리 떨어져 있는 다중 NAT에서도
자동으로 작동합니다.
3.3.2. Peers behind the Same NAT (동일한 NAT 뒤에 있는 피어)
이제 그림 4와 같이 두 클라이언트(아마도 무의식적으로)가 동일한 EIM-NAT 뒤에 상주하여 동일한
사설 IP 주소 공간에 있는 시나리오를 고려하십시오. 잘 알려진 Rendezvous Server S는
공개적으로 주소 지정이 가능한 IP 주소이며 등록, 검색 및 제한된 릴레이 목적으로 사용됩니다.
NAT 뒤의 호스트는 서버에 등록됩니다. 피어 호스트는 서버를 사용하여 NAT 뒤에 있는 호스트를
발견하고 서버를 사용하여 메시지를 릴레이합니다. 섹션 3.1과 달리 피어 호스트는 서버를 사용하여
모든 종단 간 메시지 대신 제어 메시지만 중계합니다.
클라이언트 A는 공통 EIM-NAT가 공인 포트 번호 62000을 할당한 서버 S와 UDP 세션을
설정했습니다. 클라이언트 B는 유사하게 EIM-NAT가 공인 포트 번호 62001을 할당한 S와 세션을
설정했습니다.
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT |
+--------------+
|
+-----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ |
| | 10.1.1.3:1234 | | 10.0.0.1:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
그림 4: 피어와 통신하기 위한 로컬 및 공인 엔드포인트 사용
A와 B가 위에서 설명한 UDP 홀 펀칭 기술을 사용하여 서버 S를 소개자로 사용하여 통신 채널을
설정한다고 가정합니다. 그런 다음 A와 B는 서버 S에서 관찰한 대로 서로의 공인 엔드포인트를
학습하고 해당 공인 엔드포인트에서 서로에게 메시지를 보내기 시작합니다. 두 클라이언트는
NAT가 내부 네트워크의 호스트가 외부 호스트뿐만 아니라 다른 내부 호스트와 변환된 UDP 세션을
열 수 있도록 허용하는 한 이러한 방식으로 서로 통신할 수 있습니다. 이러한 상황을 "헤어피닝
(Hairpinning)"이라고 합니다. 사설망에서 NAT에 도착한 패킷이 변환된 후 공중망으로
전달되지 않고 사설망으로 루프백되기 때문입니다.
예를 들어 위의 P2P session-try1을 고려하십시오. A가 UDP 패킷을 B의 공인 엔드포인트로
보낼 때 패킷은 처음에 소스 엔드포인트가 10.0.0.1:1234이고 대상 엔드포인트가
192.0.2.1:62001입니다. NAT는 이 패킷을 수신하고 소스 엔드포인트가
192.0.2.1:62000이고 대상 엔드포인트가 10.1.1.3:1234인 것으로 변환한 다음 B로
전달합니다.
NAT 장치가 헤어피닝을 지원하더라도 이 변환 및 전달 단계는 이 상황에서 분명히 불필요하며
NAT에 부담을 주는 것 외에도 A와 B 간의 대화에 대기 시간을 추가합니다. 이 문제에 대한
해결책은 간단하며 다음과 같이 설명됩니다.
A와 B가 처음에 Rendezvous 서버 S를 통해 주소 정보를 교환할 때 자신이 "관찰한" IP
주소와 포트 번호는 물론 S가 관찰한 공인 엔드포인트도 포함합니다. 그런 다음 클라이언트는
동시에 각 서버에 패킷을 보내기 시작합니다. 알고 있는 각각의 대체 주소에서 다른 주소를
선택하고 성공적인 통신으로 연결되는 첫 번째 주소를 사용합니다. 위의 그림 4와 같이 두
클라이언트가 동일한 NAT 뒤에 있는 경우 사설 엔드포인트로 향하는 패킷(P2P session-try
를 사용하여 시도한 것처럼)이 먼저 도착할 가능성이 높으므로 NAT를 포함하지 않는 직접 통신
채널이 생성됩니다. 두 클라이언트가 서로 다른 NAT 뒤에 있는 경우 사설 엔드포인트로 향하는
패킷은 서로에게 전혀 도달하지 못하지만 클라이언트는 각자의 공인 엔드포인트를 사용하여 연결을
설정하기를 바랍니다. 그러나 NAT가 서로 다른 경우 B의 사설 엔드포인트로 향하는 A의 메시지가
A의 사설 네트워크에서 관련 없는 다른 노드에 도달하거나 그 반대의 경우가 전적으로 가능하기
때문에 이러한 패킷이 어떤 식으로든 인증되는 것이 중요합니다.
[ICE] 프로토콜은 제안/응답 교환 중에 피어링 엔드 호스트 간에 여러 후보 엔드포인트(사설 및
공인 모두)가 통신한다는 점에서 이 기술을 효과적으로 사용합니다. 가장 효율적인 종단 간 연결을
제공하는 엔드포인트는 결국 종단 간 데이터 전송을 위해 선택됩니다.
3.3.3. Peers Separated by Multiple NATs (여러 NAT로 분리된 피어)
여러 NAT 장치가 포함된 일부 토폴로지에서는 두 클라이언트가 토폴로지에 대한 특정 지식 없이
그들 사이에 "최적" P2P 경로를 설정하는 것이 불가능합니다. 예를 들어 그림 5의 시나리오를
고려하십시오.
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT X |
| (Supporting |
| Hairpinning) |
+--------------+
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
+--------------+ +--------------+
| 192.168.1.1 | | 192.168.1.2 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
그림 5: 직접 통신 설정에서 Hairpinning 사용
NAT X가 다수의 고객을 몇 개의 공인 IP 주소로 멀티플렉싱하기 위해 대규모 인터넷 서비스
공급자(ISP)에 의해 배포된 EIM-NAT이고 NAT A와 B가 두 ISP 고객이 독립적으로 배포한
소규모 소비자 NAT 게이트웨이라고 가정합니다. 사설 홈 네트워크를 각각의 ISP 제공 IP 주소에
연결합니다. 서버 S와 NAT X에만 전역적으로 라우팅 가능한 IP 주소가 있습니다. NAT A와
NAT B에서 사용하는 "공인" IP 주소는 실제로 ISP의 주소 지정 영역에 사적인 반면 클라이언트
A와 B의 주소는 각각 NAT A와 B의 주소 지정 영역에 사설입니다. 이전 섹션에서와 마찬가지로
서버 S는 등록, 검색 및 제한 릴레이 목적으로 사용됩니다. 피어 호스트는 모든 종단 간 메시지
대신 서버를 사용하여 연결 시작 제어 메시지를 릴레이합니다.
이제 클라이언트 A와 B가 직접 P2P UDP 연결을 설정하려고 시도한다고 가정합니다. 최적의
방법은 클라이언트 A가 ISP의 주소 지정 영역에서 NAT B에 있는 클라이언트 B의 공인 주소
(192.168.1.2:31000)로 메시지를 보내고 클라이언트 B가 NAT B에 있는 A의 공인 주소, 즉
192.168.1.1:30000로 메시지를 보내는 것입니다. 불행하게도 A와 B는 이러한 주소를 알 수
있는 방법이 없습니다. 왜냐하면 서버 S는 클라이언트의 "전역" 공인 엔드포인트인
192.0.2.1:62000 및 192.0.2.1:62001만 보기 때문입니다. A와 B가 이러한 주소를 알 수
있는 방법이 있더라도 ISP의 사설 주소 지정 영역의 주소 할당이 클라이언트의 사설 영역의
관련되지 않은 주소 할당과 충돌할 수 있기 때문에 여전히 사용할 수 있다는 보장이 없습니다.
따라서 클라이언트는 P2P 통신을 위해 S에서 볼 수 있는 글로벌 공인 엔드포인트를 사용하고
NAT X를 사용하여 Hairpinning을 제공할 수밖에 없습니다.
3.4. TCP Hole Punching (TCP 홀 펀칭)
이 섹션에서는 EIM-NAT 장치 뒤에 있는 한 쌍의 노드 간에 직접 TCP 연결을 설정하는 데
사용되는 "TCP 홀 펀칭" 기술에 대해 설명합니다. UDP 홀 펀칭과 마찬가지로 TCP 홀 펀칭은
적절하게 설계된 P2P 애플리케이션이 NAT 장치를 통해 두 통신 호스트가 모두 NAT 장치 뒤에
있는 경우에도 "구멍을 뚫고" 서로 직접 연결을 설정할 수 있도록 EIM-NAT의 속성에 의존합니다.
이 기술은 "Simultaneous TCP Open"라고도 합니다.
대부분의 TCP 세션은 한 엔드포인트가 SYN 패킷을 보내는 것으로 시작하고 다른 쪽은 SYN-ACK
패킷으로 응답합니다. 그러나 두 엔드포인트가 동시에 서로에게 SYN 패킷을 전송하여 TCP 세션을
시작하는 것은 허용되며, 각 당사자는 이후에 별도의 ACK로 응답합니다. 이 절차는
"Simultaneous TCP Open" 기술로 알려져 있으며 원래 TCP 사양([TCP])의 그림 6에서
찾을 수 있습니다. 그러나 "Simultaneous TCP Open"은 NAT 장치를 포함한 많은 시스템에서
올바르게 구현되지 않습니다.
NAT 장치가 들어오는 TCP 연결을 시작하려고 시도하는 사설 네트워크 외부에서 TCP SYN 패킷을
수신하는 경우 NAT 장치는 일반적으로 SYN 패킷을 삭제하거나 TCP RST(연결 재설정) 패킷을
다시 전송하여 연결 시도를 거부합니다. SYN 시간 초과 또는 연결 재설정의 경우 응용 프로그램
엔드포인트는 피어가 끝에서 동일한 작업을 수행할 때까지 계속해서 SYN 패킷을 다시 보냅니다.
NAT 장치가 "Simultaneous TCP Open" 세션을 지원하는 경우를 고려해 보겠습니다. NAT
장치가 이미 활성화되었다고 믿는 TCP 세션에 해당하는 소스 및 대상 엔드포인트와 함께 SYN
패킷이 도착하면 NAT 장치는 패킷 통과를 허용합니다. 특히, NAT 장치가 최근에 동일한 주소와
포트 번호로 나가는 SYN 패킷을 보고 전송한 경우 세션이 활성화된 것으로 간주하고 들어오는
SYN을 허용합니다. 클라이언트 A와 B가 각 클라이언트의 발신 SYN이 상대 NAT 장치에 도달하기
전에 로컬 NAT 장치를 통과하도록 시간에 따라 다른 클라이언트와 발신 TCP 연결을 시작할 수
있는 경우 peer-to-peer TCP 연결이 작동합니다.
이 기술은 다음과 같은 이유로 항상 안정적으로 작동하지 않을 수 있습니다. 어느 한 노드의 SYN
패킷이 원격 NAT 장치에 너무 빨리 도착하면(피어링 노드가 SYN 패킷을 보낼 기회를 갖기 전에)
원격 NAT 장치는 SYN 패킷을 삭제하거나 RST 패킷으로 SYN을 거부할 수 있습니다. 이로 인해
로컬 NAT 장치가 새 NAT 세션을 즉시 닫거나 세션 종료 시간 초과([NAT-TERM]의 섹션 2.6
참조)를 시작하여 시간 초과 시 NAT 세션을 닫을 수 있습니다. 두 피어링 노드가 동시에 계속되는
SYN 재전송 시도를 시작하더라도 일부 원격 NAT 장치는 NAT 세션이 세션 종료 시간 초과 상태인
경우 들어오는 SYN을 허용하지 않을 수 있습니다. 이렇게 하면 TCP 연결이 설정되지 않습니다.
실제로 대부분의 NAT 장치(50% 이상)는 엔드포인트 독립적 매핑을 지원하고 원치 않는 수신
SYN에 대한 응답으로 ICMP 오류 또는 RST를 보내지 않습니다. 결과적으로 Simultaneous TCP
Open 기술은 대부분의 TCP 연결 시도([P2P-NAT], [TCP-CHARACT])에서 NAT 장치 간에
작동합니다.
3.5. UDP Port Number Prediction (UDP 포트 번호 예측)
엔드포인트 종속 매핑을 구현하는 일부 NAT가 있는 경우 P2P UDP 세션을 만들 수 있는 UDP 홀
펀칭 기술의 변형이 있습니다. 이 방법은 "N+1" 기법[BIDIR]이라고도 하며 Takeda
[SYM-STUN]가 자세히 탐구합니다. 이 방법은 NAT의 동작을 분석하고 향후 세션에 할당할 공인
포트 번호를 예측하는 방식으로 작동합니다. 할당된 공인 포트는 대부분의 NAT가 순서대로 매핑
포트를 할당하기 때문에 예측 가능한 경우가 많습니다.
그림 6의 시나리오를 고려하세요. 각각 별도의 NAT 뒤에 있는 두 클라이언트 A와 B는 랑데뷰 서버
S와 별도의 UDP 연결을 설정했습니다. 랑데뷰 서버 S에는 공인 주소 지정이 가능한 IP 주소가
있으며 등록 및 검색 목적으로 사용됩니다. NAT 뒤의 호스트는 엔드포인트를 서버에 등록합니다.
피어 호스트는 서버를 사용하여 NAT 뒤에 있는 호스트의 엔드포인트를 검색합니다.
Registry and Discovery
Server S
192.0.2.128:20001
|
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 192.0.2.1:62001 | | 192.0.2.254:31001 | |
| |
+---------------------+ +--------------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
| (Endpoint-Dependent | | (Endpoint-Dependent|
| Mapping) | | Mapping) |
+---------------------+ +--------------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
그림 6: 직접 연결을 설정하기 위한 UDP 포트 예측
NAT A는 UDP 포트 62000을 A와 S 사이의 통신 세션에 할당했고 NAT B는 포트 31000을 B와
S 사이의 세션에 할당했습니다. 서버 S와 통신함으로써 A와 B는 S에서 관찰한 대로 서로의 공인
엔드포인트를 학습합니다. 이제 클라이언트 A는 주소 192.0.2.254의 포트 31001로 UDP
메시지를 보내기 시작하고(포트 번호 증가에 주의) 클라이언트 B는 동시에 주소 192.0.2.1의 포트
62001로 메시지를 보내기 시작합니다. NAT A와 B가 순차적으로 새 세션에 포트 번호를 할당하고
A-S 및 B-S 세션이 시작된 후 많은 시간이 경과하지 않은 경우 A와 B 사이에 작동하는 양방향
통신 채널이 생성되어야 합니다. B에 대한 A의 메시지는 NAT A가 새 세션을 열도록 하며, NAT
A는 공인 포트 번호 62001을 할당할 것입니다. 왜냐하면 62001은 이전에 A와 S 사이의 세션에
할당한 포트 번호 62000 다음 순서이기 때문입니다. 마찬가지로 A에 대한 B의 메시지는 NAT B가
새 세션을 열도록 하며 여기에 포트 번호 31001을 할당합니다. 두 클라이언트가 각 NAT가 새
세션에 할당하는 포트 번호를 올바르게 추측했다면 양방향 UDP 통신 채널이 설정된 것입니다.
분명히 이 트릭이 실패할 수 있는 많은 요인이 있습니다. 두 NAT의 예상 포트 번호가 관련 없는
세션에서 이미 사용 중인 경우 NAT는 해당 포트 번호를 건너뛰고 연결 시도가 실패합니다. NAT가
때때로 또는 항상 비순차적으로 포트 번호를 선택하면 트릭이 실패합니다. NAT A(또는 B) 뒤에
있는 다른 클라이언트가 A(B)가 S와 연결을 설정한 후 B(A)에 첫 번째 메시지를 보내기 전에 외부
대상으로 나가는 새 UDP 연결을 열면 관련 없는 클라이언트는 실수로 원하는 포트 번호를
"도용"합니다. 따라서 이 트릭은 관련된 NAT 중 하나가 부하 상태일 때 작동할 가능성이 훨씬
적습니다.
실제로 이 트릭을 구현하는 애플리케이션은 NAT 중 하나가 엔드포인트 Endpoint-Independent
매핑을 사용하는 경우에도 여전히 작동해야 하므로 애플리케이션은 어느 쪽 끝에 어떤 종류의 NAT가
관련되어 있는지 미리 감지하고 그에 따라 동작을 수정해야 하므로 알고리즘의 복잡성과 네트워크의
일반적인 취약성이 증가합니다. 마지막으로 포트 번호 예측은 클라이언트가 둘 이상의 NAT 수준 뒤에
있고 클라이언트에 가장 가까운 NAT가 Endpoint-Independent 매핑을 사용하는 경우 작동할
가능성이 거의 없습니다.
3.6. TCP Port Number Prediction (TCP 포트 번호 예측)
이는 Address-Dependent 매핑을 사용하는 NAT에서 직접 P2P TCP 세션을 설정하는 "TCP 홀
펀칭" 기술의 변형입니다.
불행하게도 이 트릭은 앞에서 설명한 UDP 포트 번호 예측 트릭보다 훨씬 취약하고 타이밍에 민감할
수 있습니다. 첫째, NAT가 할당할 공인 포트를 예측하는 것이 잘못되었을 수 있습니다. 또한
클라이언트의 SYN이 상대 NAT 장치에 너무 빨리 도착하면 원격 NAT 장치가 RST 패킷으로 SYN을
거부할 수 있으므로 로컬 NAT 장치가 차례로 새 세션을 닫고 동일한 포트 번호를 사용하는 향후
SYN 재전송 시도가 무의미해집니다.
4. Recent Work on NAT Traversal (NAT 순회에 대한 최근 작업)
[P2P-NAT]는 NAT 순회를 위한 UDP 및 TCP 홀 펀칭 기술에 대해 자세히 설명합니다.
[P2P-NAT]는 또한 여러 상용 NAT 장치에서 테스트 프로그램 [NAT-CHECK]을 실행한 경험적
결과를 나열합니다. 결과는 UDP 홀 펀칭이 NAT 장치의 80% 이상에서 광범위하게 작동하는 반면
TCP 홀 펀칭은 테스트된 NAT 장치의 60% 이상에서 작동함을 나타냅니다. 결과는 또한 상용 NAT
장치에서 TCP 또는 UDP 헤어피닝이 아직 널리 사용되지 않는다는 것을 나타냅니다. 장치의 25%
미만이 헤어피닝에 대한 테스트([NAT-CHECK])를 통과했습니다. 공개적으로 사용 가능한 NAT
장치를 분류하는 경험적 테스트 결과는 [JENN-RESULT] 및 [SAIK-RESULT]를 참조할 수도
있습니다. [JENN-RESULT]는 서로 다른 IP 프로토콜에 걸친 테스트를 사용하여 NAT 분류
결과를 제공합니다. [SAIK-RESULT]는 TCP 동작 특성에 따라 NAT 장치를 분류하는 데에만
집중합니다.
[TCP-CHARACT] 및 [NAT-BLASTER]는 TCP 홀 펀칭에 중점을 두고 몇 가지 대체 접근
방식을 탐색하고 비교합니다. [NAT-BLASTER]는 관찰된 NAT 동작의 다양한 사례와
애플리케이션이 이를 처리할 수 있는 방법을 분석하는 분석적 접근 방식을 취합니다.
[TCP-CHARACT]는 TCP 홀 펀칭과 관련된 다양한 유형의 NAT 동작의 공통성을 측정하는 보다
경험적인 접근 방식을 채택합니다. 이 연구는 [P2P-NAT]에서 사용된 것보다 더 정교한 기술을
사용하여 현재 배포된 NAT의 최대 88%가 TCP 홀 펀칭을 지원할 수 있음을 발견했습니다.
[TEREDO]는 릴레이 기술을 사용하여 NAT 장치 뒤의 IPv4 노드를 NAT 장치 외부의 IPv6
노드에 연결하는 NAT 순회 서비스입니다. [TEREDO]는 UDP를 통해 NAT 장치를 거쳐 릴레이
노드로 패킷을 터널링하여 NAT 장치를 통한 피어 통신을 제공합니다. Teredo 릴레이는 사설
IPv4 노드에서 외부 영역의 노드로 또는 그 반대로 트래픽을 릴레이하는 Rendezvous 서버
역할을 합니다.
[ICE]는 멀티미디어 애플리케이션 클래스의 피어 노드 간에 미디어 세션을 설정하기 위한 NAT
순회 프로토콜입니다. [ICE]는 피어링 노드가 미디어 세션을 종료하는 데 사용되는 동일한 포트
번호에서 NAT(STUN) 프로토콜[STUN]을 통해 UDP 프로토콜의 단순 순회를 실행하도록
요구합니다. SIP([SIP])와 같은 시그널링 프로토콜을 사용하는 애플리케이션은 시그널링 세션
내 미디어 세션에 대한 NAT 순회 속성을 내장하고 피어 노드 간에 교환의 제공/응답 유형을
사용하여 NAT 장치에서 종단간 미디어 세션을 설정할 수 있습니다. [ICE-TCP]는 TCP 기반
미디어 세션을 위한 ICE의 확장입니다.
Instant Messaging 응용 프로그램을 포함하여 많은 온라인 게임 및 Media-over-IP 응용
프로그램은 피어 투 피어 연결 설정을 위해 문서에 설명된 기술을 사용합니다. 일부 애플리케이션은
등록, 검색, 로드 밸런싱을 위한 릴레이 기능 등을 위해 여러 개의 서로 다른 랑데부 서버를
사용할 수 있습니다. 예를 들어, 잘 알려진 media-over-IP 응용 프로그램 "Skype"는
로그인을 위해 중앙 공인 서버를 사용하고 종단 간 릴레이 기능을 위해 다른 공인 서버를
사용합니다.
5. Summary of Observations (관찰 요약)
5.1. TCP/UDP Hole Punching (TCP/UDP 홀 펀칭)
TCP/UDP 홀 펀칭은 NAT 뒤에 있는 두 노드 간에 직접 TCP/UDP 피어 투 피어 통신을
설정하는 가장 효율적인 기존 방법으로 보입니다. 이 기술은 다양한 기존 NAT와 함께
사용되었습니다. 그러나 애플리케이션은 직접 통신을 설정할 수 없는 경우 단순 릴레이로 대체할
준비가 필요할 수 있습니다.
TCP/UDP 홀 펀칭 기술은 traversing NAT가 EIM-NAT인 경우에만 작동한다는 점에서 주의해야
합니다. NAT 장치 경로가 EIM-NAT가 아닌 경우 응용 프로그램은 다른 외부 대상과의 통신을 위해
이미 설정된 엔드포인트 매핑을 재사용할 수 없으며 기술이 실패합니다. 그러나 인터넷에 배포된 많은
NAT 장치는 EIM-NAT 장치입니다. 따라서 TCP/UDP 홀 펀칭 기술을 광범위하게 적용할 수
있습니다[P2P-NAT]. 그럼에도 불구하고 배포된 NAT의 상당 부분은 엔드포인트 종속 매핑을
사용하며 TCP/UDP 홀 펀칭 기술을 지원하지 않습니다.
5.2. NATs Employing Endpoint-Dependent Mapping (Endpoint-Dependent Mapping을 사용하는 NAT)
Endpoint-Dependent Mapping을 사용하는 NAT는 나가는 연결만 시작하면 되는 웹
브라우저와 같은 클라이언트-서버 응용 프로그램에서는 문제가 되지 않았습니다. 그러나 최근에는
Instant Messaging 및 VoIP(Voice-over-IP)와 같은 P2P 애플리케이션이 널리 사용되고
있습니다. Endpoint-Dependent Mapping을 사용하는 NAT는 TCP/UDP 홀 펀칭과 같은
기술이 이러한 NAT 장치에서 작동하지 않기 때문에 P2P 애플리케이션에 적합하지 않습니다.
5.3. Peer Discovery (피어 검색)
응용 프로그램 피어는 동일한 NAT 도메인 내에 있거나 NAT 도메인 외부에 있을 수 있습니다.
모든 피어(NAT 도메인 내부 또는 외부)가 애플리케이션 엔드포인트를 검색하기 위해
애플리케이션은 랑데부 서버에 공인 엔드포인트 외에도 사설 엔드포인트를 등록하도록 선택할 수
있습니다.
5.4. Hairpinning (헤어피닝)
헤어피닝 지원은 EIM-NAT 뒤의 호스트가 공인(변환 가능) 엔드포인트를 통해 동일한 NAT 장치
뒤의 다른 호스트와 통신할 수 있도록 하는 데 매우 유용합니다. 헤어피닝 지원은 다중 수준 NAT
시나리오의 첫 번째 수준으로 배포된 대용량 NAT의 경우에 특히 유용합니다. 섹션 3.3.3에서
설명한 것처럼 1차 NAT가 헤어피닝도 지원하지 않는 한 동일한 1차 NAT를 사용하지만 다른 2차
NAT 뒤에 있는 호스트는 TCP/UDP 홀 펀칭 기술을 사용하여 서로 통신할 수 있는 방법이
없습니다. 모든 NAT 장치가 배포 시 엔드포인트 ID를 보존하는 경우에도 마찬가지입니다.
6. Security Considerations (보안 고려 사항)
이 문서는 본질적으로 새로운 보안 문제를 생성하지 않습니다. 그럼에도 불구하고 설명된 기술에는
보안 위험이 존재할 수 있습니다. 이 섹션에서는 응용 프로그램이 NAT 장치에서 직접 통신을
지원하려고 시도할 때 실수로 생성할 수 있는 보안 위험에 대해 설명합니다.
6.1. Lack of Authentication Can Cause Connection Hijacking (인증 부족으로 연결 하이재킹이 발생할 수 있음)
응용 프로그램은 적절한 인증 메커니즘을 사용하여 악의적인 연결 하이재킹 또는 서비스 거부
공격뿐만 아니라 다른 연결과의 우발적인 혼동으로부터 연결을 보호해야 합니다. 애플리케이션은
여러 개별 IP 주소 도메인과 효과적으로 상호 작용해야 하지만 일반적으로 이러한 주소 도메인을
정의하는 정확한 토폴로지 또는 관리 정책을 인식하지 못합니다. TCP/UDP 홀 펀칭을 통해 연결을
시도하는 동안 응용 프로그램은 의도한 호스트와 완전히 다른 호스트에 자주 도착할 수 있는 패킷을
보냅니다.
예를 들어 많은 소비자 수준 NAT 장치는 기본적으로 특정 주소 범위의 사이트 로컬 IP 주소를
전달하도록 구성된 Dynamic Host Configuration Protocol (DHCP) 서비스를 제공합니다.
예를 들어 특정 소비자 NAT 장치는 기본적으로 192.168.1.100으로 시작하는 IP 주소를
전달합니다. 해당 NAT 장치를 사용하는 대부분의 사설 홈 네트워크에는 해당 IP 주소를 가진
호스트가 있으며 이러한 네트워크 중 다수는 주소가 192.168.1.101인 호스트도 있을 것입니다.
한 사설 네트워크의 주소 192.168.1.101에 있는 호스트 A가 다른 사설 네트워크의
192.168.1.100에 있는 호스트 B와 UDP 홀 펀칭으로 연결을 설정하려고 하면 이 프로세스의
일부로 호스트 A는 검색 패킷을 주소 192.168로 보냅니다. 로컬 네트워크의 1.100, 호스트 B는
네트워크의 주소 192.168.1.101로 검색 패킷을 보냅니다. 두 호스트가 서로 다른 사설
네트워크에 있기 때문에 이러한 검색 패킷은 의도한 시스템에 도달하지 못하지만 이 응용 프로그램에서
사용하는 사용하는 표준 UDP 포트 번호에서 이러한 각 네트워크의 '일부' 컴퓨터에 도달할 가능성이
매우 높으며, 특히 응용 프로그램이 다른 컴퓨터에서도 실행 중이고 메시지를 제대로 인증하지 않는
경우 잠재적으로 혼란을 일으킬 수 있습니다.
따라서 aliasing으로 인한 이러한 위험은 악의적인 공격자가 없더라도 존재합니다. 예를 들어
호스트 A와 같은 하나의 엔드포인트가 실제로 악의적인 경우 적절한 인증 없이 공격자는 호스트 B가
공격자의 (주장된) 사설 주소와 동일한 IP 주소를 가진 사설 네트워크의 다른 호스트와 의도하지
않은 방식으로 연결하고 상호 작용하도록 할 수 있습니다. 두 엔드포인트 호스트 A와 B는 등록,
검색 및 제한된 릴레이 서비스를 제공하는 공인 랑데뷰 서버 S를 통해 서로를 발견했을 것으로
추정되며 S나 B 모두 A의 보고된 사설 주소를 확인할 수 있는 수단이 없으므로 응용 프로그램은
인증된 양방향 통신을 성공적으로 설정할 때까지 의심스러운 IP 주소라고 가정하도록 조언할 수
있습니다.
6.2. Denial-of-Service Attacks (서비스 거부 공격)
애플리케이션과 이를 지원하는 공인 서버는 서비스 거부 공격으로부터 스스로를 보호해야 하며
공격자가 다른 대상에 대한 서비스 거부 공격을 수행하는 데 사용할 수 없도록 해야 합니다.
스스로를 보호하기 위해 애플리케이션과 서버는 인증된 양방향 통신이 설정될 때까지 중요한 로컬
처리 또는 스토리지 리소스가 필요한 조치를 취하지 않아야 합니다. 서비스 거부 공격의 도구로
사용되는 것을 방지하려면 응용 프로그램과 서버는 의도한 대상과 인증된 양방향 통신이 설정될
때까지 새로 검색된 IP 주소로 보내는 트래픽의 양과 속도를 최소화해야 합니다.
예를 들어 공인 랑데부 서버에 등록하는 응용 프로그램은 사설 IP 주소 또는 여러 IP 주소를
가지고 있다고 주장할 수 있습니다. 상당한 양의 연결 시도를 집단적으로 유인할 수 있는 잘
연결된 호스트 또는 호스트 그룹(예: 인기 있는 콘텐츠 제공을 제공함으로써)은 대상 호스트 C에
단순히 C의 IP 주소를 포함함으로써 서비스 거부 공격을 실행할 수 있습니다. 랑데부 서버에
등록하는 자체 IP 주소 목록입니다. 랑데부 서버가 IP 주소를 확인할 수 있는 방법은 없습니다.
IP 주소는 다른 호스트가 네트워크-로컬 통신을 설정하는 데 유용한 합법적인 사설 네트워크 주소일
수 있기 때문입니다. 따라서 응용 프로그램 프로토콜은 이러한 집중 효과로 인해 발생할 수 있는
잠재적 손상을 방지하기 위해 확인되지 않은 IP 주소에 대한 트래픽의 크기 및 속도를 제한하도록
설계되어야 합니다.
6.3. Man-in-the-Middle Attacks (중간자 공격)
클라이언트와 공인 랑데부 서버 사이의 경로에 있는 모든 네트워크 장치는 NAT인 것처럼 가장하여
다양한 중간자 공격을 탑재할 수 있습니다. 예를 들어 호스트 A가 랑데뷰 서버 S에 등록을
시도하지만 네트워크 스누핑 공격자가 이 등록 요청을 관찰할 수 있다고 가정합니다. 그런 다음
공격자는 공격자 자신의 IP 주소와 같은 수정된 소스 IP 주소를 제외하고 클라이언트의 원래 요청과
동일한 요청으로 서버 S를 플러딩할 수 있습니다. 공격자가 공격자의 IP 주소를 사용하여
클라이언트를 등록하도록 서버를 설득할 수 있는 경우 공격자는 원래 클라이언트에서 서버로의 경로만
스누핑할 수 있었던 경우에도 서버 및 기타 호스트에서 원래 클라이언트로의 모든 향후 트래픽
경로에서 자신을 활성 구성 요소로 만들 수 있습니다.
클라이언트는 소스 IP 주소를 랑데부 서버에 인증하여 이 공격으로부터 자신을 보호할 수
없습니다. NAT 친화적이기 위해서는 응용 프로그램이 간섭하는 NAT가 소스 주소를 자동으로
변경하도록 허용해야 하기 때문입니다. 이것은 NAT 패러다임의 본질적인 보안 약점으로 보입니다.
이러한 공격에 대한 유일한 방어책은 클라이언트가 적절한 상위 수준 ID를 사용하여 통신의 실제
콘텐츠를 인증하고 잠재적으로 암호화하여 삽입된 공격자가 자신의 위치를 이용할 수 없도록 하는
것입니다. 그러나 모든 애플리케이션 수준 통신이 인증되고 암호화되더라도 이 공격은 클라이언트가
누구와 통신하는지 관찰하기 위한 트래픽 분석 도구로 여전히 사용될 수 있습니다.
6.4. Security Impact from EIM-NAT Devices (EIM-NAT 장치의 보안 영향)
엔드포인트 ID를 보존하도록 NAT 장치를 설계해도 NAT 장치가 제공하는 보안이 약화되지 않습니다.
예를 들어 Endpoint-Independent Mapping 및 Endpoint-Dependent Filtering을
사용하는 NAT 장치는 Endpoint-Dependent Mapping 및 Endpoint-Dependent
Filtering을 사용하는 NAT 장치보다 "무차별"하지 않습니다. Endpoint-Independent
Mapping을 사용하면서 Endpoint-Dependent Filtering을 사용하여 들어오는 트래픽을
적극적으로 필터링하면 NAT 장치가 원치 않는 들어오는 트래픽을 거부하는 원칙을 손상시키지
않으면서 애플리케이션에 친숙해질 수 있습니다.
Endpoint-Independent Mapping은 서로 다른 TCP/UDP 세션 간의 관계를 밝혀서 엔클레이브
내에서 실행되는 애플리케이션의 동작에 대해 NAT 장치에서 나오는 트래픽의 예측 가능성을 증가시킬
수 있습니다. 이러한 예측 가능성은 공격자가 다른 네트워크 또는 애플리케이션 수준의 취약점을
악용하는 데 유용할 수 있습니다. 특정 배포 시나리오의 보안 요구 사항이 너무 중요하여 이러한
미묘한 정보 채널이 문제가 되는 경우 NAT 장치가 처음부터 제한 없이 나가는 TCP/UDP 트래픽을
허용하도록 구성되지 않았을 수 있습니다. 특정 포트에서 또는 엄격하게 제어되는 애플리케이션 수준
게이트웨이를 통해 특정 애플리케이션에서 발생하는 통신을 허용하도록 구성된 NAT 장치는 이러한 배포
시나리오의 보안 요구 사항을 충족할 수 있습니다.
7. Acknowledgments (감사의 말)
저자는 이 문서의 초기 버전에 대해 귀중한 피드백을 제공한 Henrik Bergstrom,
David Anderson, Christian Huitema, Dan Wing, Eric Rescorla 및 기타 BEHAVE
작업 그룹 구성원에게 감사를 표합니다. 저자는 또한 이 문서의 기술 검토자가 되기로 동의한
Francois Audet, Kaushik Biswas, Spencer Dawkins, Bruce Lowekamp 및 Brian
Stucker에게도 감사를 표합니다.
8. References (참조)
8.1. Normative References (규범적 참조)
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.
8.2. Informative References (유용한 참조)
[BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application
Design Guidelines for Traversal through Network Address
Translators", Work in Progress, March 2007.
[BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha,
"NAT Behavioral Requirements for ICMP protocol", Work
in Progress, February 2008.
[BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", Work
in Progress, April 2007.
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working
Committee, "Bidirectional Peer-to-Peer Communication
with Interposing Firewalls and NATs", August 2001.
http://www.peer-to-peerwg.org/tech/nat/
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator
(NAT) Traversal for Offer/Answer Protocols", Work in
Progress, October 2007.
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)", Work in Progress,
July 2007.
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work
in Progress, July 2007.
[KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July
1999. http://www.alumni.caltech.edu/~dank/peer-nat.html
[MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture
and framework", RFC 3303, August 2002.
[NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[NAT-BLASTER] Biggadike, A., Ferullo, D., Wilson, G., and Perrig, A.,
"Establishing TCP Connections Between Hosts Behind
NATs", ACM SIGCOMM ASIA Workshop, April 2005.
[NAT-CHECK] Ford, B., "NAT check Program" available online as
http://midcom-p2p.sourceforge.net, February 2005.
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
Mapping Protocol (NAT-PMP)", Work in Progress, October
2006.
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,