File: rfc1919.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1963 lines) | stat: -rw-r--r-- 87,374 bytes parent folder | download | duplicates (5)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963






Network Working Group                                          M. Chatel
Request for Comments: 1919                                    Consultant
Category: Informational                                       March 1996


                Classical versus Transparent IP Proxies

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   Many modern IP security systems (also called "firewalls" in the
   trade) make use of proxy technology to achieve access control.  This
   document explains "classical" and "transparent" proxy techniques and
   attempts to provide rules to help determine when each proxy system
   may be used without causing problems.

Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Direct communication (without a proxy) . . . . . . . . . . . 3
   2.1.  Direct connection example  . . . . . . . . . . . . . . . . 3
   2.2.  Requirements of direct communication . . . . . . . . . . . 5
   3.    Classical application proxies  . . . . . . . . . . . . . . 5
   3.1.  Classical proxy session example  . . . . . . . . . . . . . 6
   3.2.  Characteristics of classical proxy configurations  . . .  12
   3.2.1.  IP addressing and routing requirements . . . . . . . .  12
   3.2.2.  IP address hiding  . . . . . . . . . . . . . . . . . .  14
   3.2.3.  DNS requirements . . . . . . . . . . . . . . . . . . .  14
   3.2.4.  Software requirements  . . . . . . . . . . . . . . . .  15
   3.2.5.  Impact of a classical proxy on packet filtering  . . .  15
   3.2.6.  Interconnection of conflicting IP networks . . . . . .  16
   4.  Transparent application proxies  . . . . . . . . . . . . .  19
   4.1.  Transparent proxy connection example . . . . . . . . . .  20
   4.2.  Characteristics of transparent proxy configurations  . .  26
   4.2.1.  IP addressing and routing requirements . . . . . . . .  26
   4.2.2.  IP address hiding  . . . . . . . . . . . . . . . . . .  28
   4.2.3.  DNS requirements . . . . . . . . . . . . . . . . . . .  28
   4.2.4.  Software requirements  . . . . . . . . . . . . . . . .  29
   4.2.5.  Impact of a transparent proxy on packet filtering  . .  30
   4.2.6.  Interconnection of conflicting IP networks . . . . . .  31
   5.  Comparison chart of classical and transparent proxies  . .  31
   6.  Improving transparent proxies  . . . . . . . . . . . . . .  32
   7.  Security Considerations  . . . . . . . . . . . . . . . . .  34



Chatel                       Informational                      [Page 1]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  34
   9.  References . . . . . . . . . . . . . . . . . . . . . . . .  35

1. Background

   An increasing number of organizations use IP security systems to
   provide specific access control when crossing network security
   perimeters. These systems are often deployed at the network boundary
   between two organizations (which may be part of the same "official"
   entity), or between an organization's network and a large public
   internetwork such as the Internet.

   Some people believe that IP firewalls will become commodity products.
   Others believe that the introduction of IPv6 and of its improved
   security capabilities will gradually make firewalls look like stopgap
   solutions, and therefore irrelevant to the computer networking scene.
   In any case, it is currently important to examine the impact of
   inserting (and removing) a firewall at a network boundary, and to
   verify whether specific types of firewall technologies may have
   different effects on typical small and large IP networks.

   Current firewall designs usually rely on packet filtering, proxy
   technology, or a combination of both. Packet filtering (although hard
   to configure correctly in a security sense) is now a well documented
   technology whose strengths and weaknesses are reasonably understood.
   Proxy technology, on the other hand, has been deployed a lot but
   studied little. Furthermore, many recent firewall products support a
   capability called "transparent proxying". This type of feature has
   been subject to much more marketing attention than actual technical
   analysis by the networking community.

   It must be remembered that the Internet's growth and success is
   strongly related to its "open" nature. An Internet which would have
   been segmented from the start with firewalls, packet filters, and
   proxies may not have become what it is today. This type of discussion
   is, however, outside the scope of this document, which just attempts
   to provide an understandable description of what are network proxies,
   and of what are the differences, strengths, and weaknesses of
   "classical" and "transparent" network proxies.  Within the context of
   this document, a "classical" proxy is the older (some would say old-
   fashioned) type of proxy of the two.

   Also note that in this document, the word "connection" is used for an
   application session that uses TCP, while the word "session" refers to
   an application dialog that may use UDP or TCP.






Chatel                       Informational                      [Page 2]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


2. Direct communication (without a proxy)

   In the "normal" Internet world, systems do not use proxies and simply
   use normal TCP/IP to communicate with each other. It is important
   (for readers who may not be familiar with this) to take a quick look
   at the operations involved, in order to better understand what is the
   exact use of a proxy.

   2.1 Direct connection example

      Let's take a familiar network session and describe some details of
      its operation. We will look at what happens when a user on a
      client system "c.dmn1.com" sets up an FTP connection to the server
      system "s.dmn2.com". The client system's IP address is
      c1.c2.c3.c4, the server's IP address is s1.s2.s3.s4.

       +---------------+      +----------+      +---------------+
       |               |     /    IP      \     |               |
       |  c.dmn1.com   |----+  network(s)  +----|  s.dmn2.com   |
       | (c1.c2.c3.c4) |     \            /     | (s1.s2.s3.s4) |
       +---------------+      +----------+      +---------------+


      The user starts an instance of an FTP client program on the client
      system "c.dmn1.com", and specifies that the target system is
      "s.dmn2.com". On command-line systems, the user typically types:

          ftp s.dmn2.com

      The client system needs to convert the server's name to an IP
      address (if the user directly specified the server by address,
      this step is not needed).

      Converting the server name to an IP address requires work to be
      performed which ranges between two extremes:

       a) the client system has this name in its hosts file, or has
          local DNS caching capability and successfully retrieves the
          name of the server system in its cache. No network activity
          is performed to convert the name to an IP address.

       b) the client system, in combination with DNS name servers,
          generate DNS queries that eventually propagate close to the
          root of the DNS tree and back down the server's DNS branch.
          Eventually, a DNS server which is authoritative for the
          server system's domain is queried and returns the IP
          address associated with "s.dmn2.com" (depending on the case,
          it may return this to the client system directly or to an



Chatel                       Informational                      [Page 3]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


          intermediate name server). Ultimately, the client system
          obtains a valid IP address for s.dmn2.com. For simplicity,
          we assume the server has only one IP address.

       +---------------+     +--------+     +---------------+
       |               |    /   IP     \    |               |
       |  c.dmn1.com   |---+ network(s) +---|  s.dmn2.com   |
       | (c1.c2.c3.c4) |    \          /    | (s1.s2.s3.s4) |
       +---------------+     +--------+     +---------------+
          A  |                /          \
          |  | address for   /            \
          |  | s.dmn2.com?  /              \
          |  |             /                \
          |  |            /                  \
          |  |     +--------+ s.dmn2.com?  +--------+
          |  +---->|  DNS   |------------->|  DNS   |
          |        | server |              | server |
          +--------|   X    |<-------------|   Y    |
       s1.s2.s3.s4 +--------+  s1.s2.s3.s4 +--------+

      Once the client system knows the IP address of the server system,
      it attempts to establish a connection to the standard FTP
      "control" TCP port on the server (port 21). For this to work, the
      client system must have a valid route to the server's IP address,
      and the server system must have a valid route to the client's IP
      address. All intermediate devices that behave like IP gateways
      must have valid routes for both the client and the server. If
      these devices perform packet filtering, they must ALL allow the
      specific type of traffic required between C and S for this
      specific application.

       +---------------+                    +---------------+
       |  c.dmn1.com   |                    |  s.dmn2.com   |
       | (c1.c2.c3.c4) |                    | (s1.s2.s3.s4) |
       +---------------+                    +---------------+
         | |                                    |   |
         | | route to S              route to C |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to C                             | | route to S
         | |                                        | |
         | |      C          S                 C    | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               S                C          S




Chatel                       Informational                      [Page 4]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      The actual application work for the FTP session between the client
      and server is done with a bidirectional flow of TCP packets
      between the client's and server's IP addresses.

      The FTP protocol uses a slightly complex protocol and TCP
      connection model which is, luckily, not important to the present
      discussion. This allows slightly shortening this document...

   2.2 Requirements of direct communication

      Based on the preceding discussion, it is possible to say that the
      following is required for a direct session between a client and
      server to be successful:

       a) If the client uses the NAME of the server to reference it,
          the client must either have a hardcoded name-to-address
          binding for the server, or it must be able to resolve the
          server name (typically using DNS). In the case of DNS, this
          implies that the client and server must be part of the same
          DNS architecture or tree.

       b) The client and server must be part of the same internetwork:
          the client must have a valid IP route towards the server,
          the server must have a valid IP route towards the client,
          and all intermediate IP gateways must have valid routes
          towards the client and server ("IP gateway" is the RFC
          standard terminology; people often use the term "IP router"
          in computer rooms).

       c) If there are devices on the path between the client and
          server that perform packet filtering, all these devices must
          permit the forwarding of packets between the IP address of
          the client and the IP address of the server, at least for
          packets that fit the protocol model of the FTP application
          (TCP ports used, etc.).

3. Classical application proxies

   A classical application proxy is a special program that knows one (or
   more) specific application protocols. Most application protocols are
   not symetric; one end is considered to be a "client", one end is a
   "server".

   A classical application proxy implements both the "client" and
   "server" parts of an application protocol. In practice, it only needs
   to implement enough of the client and server protocols to accomplish
   the following:




Chatel                       Informational                      [Page 5]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


   a) accept client sessions and appear to them as a server;

   b) receive from a client the name or address of the final target
      server (this needs to be passed over the "client-proxy" session
      in a way that is application-specific);

   c) setup a session to the final server and appear to be a client
      from the server's point of view;

   d) relay requests, responses, and data between the client and
      server;

   e) perform access controls according to the proxy's design
      criteria (the main goal of the proxy, after all).

   The functional goal of the proxy is to relay application data between
   clients and servers that may not have direct IP connectivity. The
   security goal of the proxy is to do checks and types of access
   controls that typical client and server software do not support or
   implement.

   The following information will make it clear that classical proxies
   can offer many hidden benefits to the security-conscious network
   designer, at the cost of deploying client software with proxy
   capabilities or of educating the users on proxy use.

   Client software issues are now easier to handle, given the increasing
   number of popular client applications (for Web, FTP, etc.) that offer
   proxy support. Designers developing new protocols are also more
   likely to plan proxy capability from the outset, to ensure their
   protocols can cross the many existing large corporate firewalls that
   are based at least in part on classical proxy technology.

   3.1 Classical proxy session example

      We will repeat our little analysis of an FTP session. This time,
      the FTP session is passing through a "classical" application proxy
      system. As is often the case (although not required), we will
      assume that the proxy system has two IP addresses, two network
      interfaces, and two DNS names.

      The proxy system is running a special program which knows how to
      behave like an FTP client on one side, and like an FTP server on
      the other side. This program is what people call the "proxy". We
      will assume that the proxy program is listening to incoming
      requests on the standard FTP control port (21/tcp), although this
      is not always the case in practice.




Chatel                       Informational                      [Page 6]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +---------------+      +----------+
       |               |     /    IP      \
       |  c.dmn1.com   |----+  network(s)  +----------+
       | (c1.c2.c3.c4) |     \            /           |
       +---------------+      +----------+    +-----------------+
                                              | (p1.p2.p3.p4)   |
                                              | proxy1.dmn3.com |
                                              |                 |
                                              | proxy2.dmn4.com |
                                              | (p5.p6.p7.p8)   |
       +---------------+      +----------+    +-----------------+
       |               |     /    IP      \           |
       |  s.dmn2.com   |----+  network(s)  +----------+
       | (s1.s2.s3.s4) |     \            /
       +---------------+      +----------+


      The user starts an instance of an FTP client program on the client
      system "c.dmn1.com", and MUST specify that the target system is
      "proxy1.dmn3.com". On command-line systems, the user typically
      types:

          ftp proxy1.dmn3.com

      The client system needs to convert the proxy's name to an IP
      address (if the user directly specified the proxy by address, this
      step is not needed).

      Converting the proxy name to an IP address requires work to be
      performed which ranges between two extremes:

       a) the client system has this name in its hosts file, or has
          local DNS caching capability and successfully retrieves the
          name of the proxy system in its cache. No network activity
          is performed to convert the name to an IP address.

       b) the client system, in combination with DNS name servers,
          generate DNS queries that eventually propagate close to the
          root of the DNS tree and back down the proxy's DNS branch.
          Eventually, a DNS server which is authoritative for the
          proxy system's domain is queried and returns the IP
          address associated with "proxy1.dmn3.com" (depending on the
          case, it may return this to the client system directly or
          to an intermediate name server). Ultimately, the client
          system obtains a valid IP address for proxy1.dmn3.com.






Chatel                       Informational                      [Page 7]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +---------------+          +--------+
       |               |         /   IP     \
       |  c.dmn1.com   |--------+ network(s) +------------+
       | (c1.c2.c3.c4) |         \          /             |
       +---------------+          +--------+      +-----------------+
        A  |                     /          \     | (p1.p2.p3.p4)   |
        |  | address for        /            \    | proxy1.dmn3.com |
        |  | proxy1.dmn3.com?  /              \   |    ...          |
        |  |                  /                \  +-----------------+
        |  |                 /                  \
        |  |                /                    \
        |  |         +--------+ proxy1.dmn3.com?  +--------+
        |  +-------->|  DNS   |------------------>|  DNS   |
        |            | server |                   | server |
        +------------|   X    |<------------------|   Y    |
         p1.p2.p3.p4 +--------+    p1.p2.p3.p4    +--------+

      Once the client system knows the IP address of the proxy system,
      it attempts to establish a connection to the standard FTP
      "control" TCP port on the proxy (port 21). For this to work, the
      client system must have a valid route to the proxy's IP address,
      and the proxy system must have a valid route to the client's IP
      address. All intermediate devices that behave like IP gateways
      must have valid routes to both the client and the proxy. If these
      devices perform packet filtering, they must ALL allow the specific
      type of traffic required between C and P1 for this specific
      application (FTP).

      Finally, the proxy system must accept this incoming connection,
      based on the client's IP address (the purpose of the proxy is
      generally to do access control, after all).

       +---------------+                   |      ...        |
       |  c.dmn1.com   |                   | proxy1.dmn3.com |
       | (c1.c2.c3.c4) |                   |  (p1.p2.p3.p4)  |
       +---------------+                   +-----------------+
         | |                                    |   |
         | | route to P1             route to C |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to C                             | | route to P1
         | |                                        | |
         | |      C          P1                C    | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               P1               C          P1



Chatel                       Informational                      [Page 8]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      The actual application work for the FTP session between the client
      and proxy is done with a bidirectional flow of TCP packets between
      the client's and proxy's IP addresses.

      For this to work, the proxy FTP application MUST fully support the
      FTP protocol and look identical to an FTP server from the client's
      point of view.

      Once the client<->proxy session is established, the final target
      server name must be passed to the proxy, since, when using a
      "classical" application proxy, a way MUST be defined for the proxy
      to determine the final target system. This can be achieved in
      three ways:

       a) The client system supplies the name or address of the final
          target system to the proxy in a method that is compatible
          with the specific application protocol being used (in our
          example, FTP). This is generally considered to be the main
          problem with classical proxies, since for each application
          being proxied, a method must be defined for passing the
          name or address of the final target system. This method
          must be compatible with every variant of client application
          that implements the protocol (i.e. the target-passing
          method must fit within the MINIMUM functionalities required
          by the specific application protocol).

          For the FTP protocol, the generally popular method for
          passing the final server name to the proxy is as follows:

          When the proxy prompts the FTP client for a username, the
          client specifies a string of the form:

                target_username@target_system_name
                or
                target_username@target_ip_address

          The proxy will then know what is the final target system.
          The target_username (and the password supplied by the
          client) will be forwarded "as is" by the proxy to the final
          target system.

          A well-known example of an FTP proxy that behaves in this way
          is the "ftp-gw" program which is part of the Trusted
          Information System's firewall toolkit, available by anonymous
          FTP at ftp.tis.com. Several commercial firewalls also support
          this de-facto standard.





Chatel                       Informational                      [Page 9]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       b) If there is only one possible final destination, the proxy
          may be configured to know this destination in advance.
          Since the IP address of the client system is known when the
          proxy must make this decision, the proxy can (if required)
          select a different destination based on the IP address of
          the client.

       c) The client software may also support capabilities that allow
          it to present to the user the illusion of a direct session
          (the user just specifies the final target system, and the
          client software automatically handles the problem of
          reaching to the proxy system and passing the name or address
          of the final target system in whatever mutually-acceptable
          form).

          A well-known example of a system that provides modified
          client software, proxy software, and that provides the
          illusion of transparency is NEC's SOCKS system, available by
          anonymous FTP at ftp.nec.com.

          Alternatively, several FTP client applications support the
          "username@destination_host" de-facto standard implemented
          (for example) by the "ftp-gw" proxy application.

      Once the FTP proxy application knows the name or IP address of the
      target system, it can choose to do two things:

       a) Setup a session to the final target system, the more
          frequent case.

       b) Decide (based on some internal configuration data) that it
          cannot reach the final target system directly, but must go
          through another proxy. This is rare today, but may become
          temporarily common due to the current shortage of IP
          network numbers which encourages organizations to deploy
          "hidden" network numbers which are already assigned
          elsewhere. Sessions between systems which have the same
          IP network number but which belong to different actual
          networks may require going through two proxy systems.
          This is discussed in more detail in section 3.2.6,
          "Interconnection of conflicting IP networks".

      If the FTP proxy decides to connect directly to the target system,
      and what it has is the target system name, it will need to convert
      the target system name into an IP address. If this process
      involves DNS resolution, something like the following will happen:





Chatel                       Informational                     [Page 10]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +-----------------+
       | proxy1.dmn3.com |
       |  (p1.p2.p3.p4)  |          +--------+
       |                 |         /   IP     \
       | proxy2.dmn4.com |--------+ network(s) +------------+
       |  (p5.p6.p7.p8)  |         \          /             |
       +-----------------+          +--------+      +---------------+
        A  |                     /          \       | (s1.s2.s3.s4) |
        |  | address for        /            \      | s.dmn2.com    |
        |  | s.dmn2.com?       /              \     |               |
        |  |                  /                \    +---------------+
        |  |                 /                  \
        |  |                /                    \
        |  |         +--------+   s.dmn2.com?     +--------+
        |  +-------->|  DNS   |------------------>|  DNS   |
        |            | server |                   | server |
        +------------|   X    |<------------------|   Y    |
         s1.s2.s3.s4 +--------+    s1.s2.s3.s4    +--------+

      Once the proxy system knows the IP address of the server system,
      it attempts to establish a connection to the standard FTP
      "control" TCP port on the server (port 21). For this to work, the
      proxy system must have a valid route to the server's IP address,
      and the server system must have a valid route to at least one of
      the proxy's IP address. All intermediate devices that behave like
      IP gateways must have valid routes to both the proxy and the
      server. If these devices perform packet filtering, they must ALL
      allow the specific type of traffic required between the proxy and
      S for this specific application.






















Chatel                       Informational                     [Page 11]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +-----------------+
       | proxy1.dmn3.com |
       |  (p1.p2.p3.p4)  |
       |                 |                 +----------------+
       | proxy2.dmn4.com |                 |  s.dmn2.com    |
       |  (p5.p6.p7.p8)  |                 | (s1.s2.s3.s4)  |
       +-----------------+                 +----------------+
         | |                                    |   |
         | | route to S             route to P2 |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to P2                            | | route to S
         | |                                        | |
         | |      P2         S                 P2   | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               S                P2         S


      The actual FTP application work between the proxy and server is
      done with a bidirectional flow of TCP packets between the proxy's
      and server's IP addresses.

      What actually happens BETWEEN THE CLIENT AND SERVER?  They both
      send replies and responses to the proxy, which forwards data to
      the "other" end. When one party opens a data connection and sends
      a PORT command to the proxy, the proxy allocates its own data
      connection and sends its PORT command to the "other" end. The
      proxy also copies data across the connections created in this way.

   3.2 Characteristics of classical proxy configurations

      Several IP internetworks may be linked using only classical proxy
      technology. It is currently popular to link two specific IP
      internetworks in this way: the Internet and some organization's
      "private" IP network. Such a proxy-based link is often the key
      component of a firewall.

      When this is done, several benefits and problems are introduced
      for network administrators and users.

      3.2.1 IP addressing and routing requirements.

         The proxy system must be able to address all client and server
         systems to which it may provide service. It must also know
         valid IP routes to all these client and server systems.



Chatel                       Informational                     [Page 12]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         Client and server systems must be able to address the proxy
         system, and must know a valid IP route to the proxy system. If
         the proxy system has several IP addresses (and often, several
         physical network interfaces), the client and server systems
         need only to be able to access ONE of the proxy system's IP
         addresses.

         Note that client and server systems that use the proxy for
         communication DO NOT NEED valid IP addressing or routing
         information for systems that they reach through the proxy.

         In this sense, it can be said that systems separated by a
         classical proxy are isolated from each other in an IP
         addressing sense and in an IP routing sense.

         On the other hand, the classical proxy system (if running a
         standard TCP/IP software stack) needs to have a single coherent
         view of IP addressing and routing. If such a proxy system
         interconnects two IP networks and two systems use the same IP
         network/subnetwork number (one system on each network), the
         proxy will only be able to address one of the systems.

         This restriction can be removed by chaining classical proxies
         (this is described later in section 3.2.6, "Interconnection of
         conflicting IP networks").

         Using a classical proxy for interconnection of IP
         internetworks, it is also possible, with care, to achieve a
         desirable "fail-safe" feature: no valid routing entries need to
         exist for an internetwork which should be reached only through
         the proxy (routing updates that could add such entries shout be
         BLOCKED). If the proxy suddenly starts to behave like an IP
         router, only one-way attacks become possible.

         In other words, assume an attacker has control of the remote
         internetwork and has found a way to cause the proxy to route IP
         packets, or has found a way to physically bypass the proxy.

         The attacker may inject packets, but the attacked internal
         systems will be unable to reply to those packets. This
         certainly does not make attacks infeasible (as exemplified by
         certain holiday-period events in recent years), but it still
         makes attacks more difficult.








Chatel                       Informational                     [Page 13]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      3.2.2 IP address hiding

         Application "sessions" that go through a classical proxy are
         actually made of two complete sessions:

             a) a session between the client and the proxy
             b) a session between the proxy and the server

         A device on the path sees only the client<->proxy traffic or
         the proxy<->server traffic, depending where it is located. If
         the two sessions actually pass through the same physical
         network, a device on that network may see both traffics, but
         may have difficulty establishing the relationship between the
         two sessions (depending on the specific application and
         activity level of the network).

         A by-product of a classical proxy's behavior is commonly known
         as "address hiding". Equipments on some side of a classical
         proxy cannot easily determine what are the IP addresses used on
         another side of the proxy.

         Address hiding is generally viewed as a Good Thing, since one
         of the purposes of deploying proxies is to disclose as little
         information about an internetwork as possible.

         People who are in charge of gathering network statistics, and
         who do not have access to the proxy system's reports (if any)
         may consider address hiding to be a Bad Thing, since the proxy
         obscures the actual client/server relationships where the proxy
         was inserted.  All IP activity originates and terminates on the
         proxy itself (or appears to do so).

         In the same way, server software that accepts connections that
         have gone through a classical proxy do not see the IP address
         of the incoming client, unless this information is included in
         the application protocol (and even if it is, in many cases, the
         proxy will replace this information with its own address for
         the protocol to be consistent). This makes server access
         control unusable if it is based on client IP address checks.

      3.2.3 DNS requirements

         In most classical-proxy configurations, client systems pass the
         desired server name (or address) to the proxy system WITHOUT
         INTERPRETING IT. Because of this, the client system DOES NOT
         REQUIRE to be able to resolve the name of the server system in
         order to access it through a classical proxy. It only needs to
         be able to resolve the name of the proxy (if referencing the



Chatel                       Informational                     [Page 14]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         proxy system by name).

         Because of this, it can be said that a classical proxy system
         can offer DNS isolation. If two IP internetworks use completely
         separate DNS trees (each with their own DNS root servers),
         client software in one IP internetwork may still reference a
         server name in the other IP internetwork by passing its name to
         the classical proxy.

         The classical proxy itself will not be able alone to resolve
         DNS names in both environments (if running standard DNS
         resolution software), since it will need to point to one or the
         other of the two DNS "universes".

         A well-known technique called "split-brain DNS" can be used to
         relax this restriction somewhat, but such a technique
         ultimately involves prioritizing one DNS environment over
         another. If a DNS query can return a valid answer in both
         environments, only one of the answers will be found by the
         proxy.

      3.2.4 Software requirements

         A classical proxy application is a fairly simple piece of
         software, often simpler than either a real client
         implementation or a real server implementation.  Such a program
         may run on any system that supports normal TCP/IP connections,
         and often does not require "system" or "superuser" privilege.

         Classical proxy connections have no impact on normal server
         software; the proxy looks like a normal client in most respects
         except for its IP address and its "group" nature. All
         connections from the network on the other side of the proxy
         appear to come from the proxy, which poses problems if access
         control by client system is desired.

         Normal client software may access a classical proxy if the user
         is willing or able to go through the extra steps necessary to
         indicate the final server to the proxy (whatever they are).
         Alternatively, modified (or newer) client software may be used
         that knows how to negotiate transparently with the proxy.

      3.2.5 Impact of a classical proxy on packet filtering

         If packet filtering is needed around a classical proxy, the
         packet filtering rules tend to be simplified, since the only
         traffic needed and allowed will originate from or terminate on
         the proxy (in an IP sense).



Chatel                       Informational                     [Page 15]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         If the proxy starts behaving like an IP router, or if it is
         physically bypassed, such filtering rules, if deployed
         generally within an IP internetwork, will tend to prevent any
         direct traffic flow between the "internal" internetwork and
         "external" internetworks that are supposed to be only reachable
         through the application proxy.

      3.2.6 Interconnection of conflicting IP networks

         By chaining classical proxies, it is possible to achieve some
         interconnection of IP networks that have a high level of
         conflict. In practice, this type of setup resolves IP
         addressing conflicts much better than DNS conflicts. But DNS
         conflicts are currently less of a problem because the DNS
         "address space" is almost infinitely large (has anybody
         calculated the possible DNS address space based on the RFC-
         standard maximum host name length?).

         Even though RFC 1597 was never more than an informational RFC,
         many organizations have been quietly following its suggestions,
         for lack of an easier solution. Now assume two organizations
         each use class A network number 10 on their network. Suddenly,
         they need to interconnect.  What can they do?

         First possibility: one side changes network number (not as hard
         as people think if properly planned, but this still represents
         some work)

         Second possibility: they merge the two numbers by renumbering
         partially on each side to remove conflicts (actually harder to
         do, but has the political advantage that both sides have to do
         some work)

         Third possibility: they communicate through chained classical
         proxies:


            +--------+     +--------+   +--------+     +--------+
           /  Org. 1  \    | Proxy  |   | Proxy  |    /  Org. 2  \
          +  dmn1.com  +---+ system +---+ system +---+  dmn2.com  +
           \  net 10  /    |    1   |   |   2    |    \  net 10  /
            +--------+     +--------+   +--------+     +--------+


         Both proxy 1 and 2 are standard systems running normal TCP/IP
         software stacks. Their configuration is not typical, however:





Chatel                       Informational                     [Page 16]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


             a) The link between proxy 1 and proxy 2 may use any IP
                network number that is not used (or not needed) on
                either side. Nothing on Org.1 and Org.2's networks
                need to have an IP route to this network.

             b) Proxy 1 has an IP route for network 10 that points to
                Organization 1's network, and does DNS resolution
                (if required) using dmn1.com's name servers.

             c) Proxy 2 has an IP route for network 10 that points to
                Organization 2's network, and does DNS resolution
                (if required) using dmn2.com's name servers.

             d) Proxy 1 and proxy 2 only require a host IP route to
                each other for communication.

             e) For this to be convenient, the classical proxy
                applications must support the automatic selection of
                a destination based on the client IP address.

             f) On proxy system 1, the proxy software treats incoming
                sessions from proxy system 2 in the normal way: the
                "client" (proxy system 2) will be prompted in an
                application-specific way for the final destination.
                However, incoming sessions from Org.1 addresses are
                immediately and automatically forwarded to proxy
                system 2.

                Proxy system 2 is configured similarly (that is,
                connections coming from proxy 1 are prompted for a
                target server name, connections from Org.2 addresses
                are immediately and automatically forwarded to
                proxy 1.

         From a user's point of view, the behavior of such a chained
         proxy system is not very different from a single classical
         application proxy:

             a) A user on a client system with address 10.1.2.3
                on Org.1's network wishes to do an anonymous FTP to
                "server.dmn2.com".

             b) The user starts an FTP towards proxy 1. Proxy 1 sees
                an incoming connection from an address in network 10,
                so it immediately relays the connection to proxy 2.

             c) Proxy 2 sees a connection coming from proxy 1, so it
                prompts the client. The user sees the username prompt



Chatel                       Informational                     [Page 17]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


                and types (assuming FTP proxies that behave like TIS's
                ftp-gw):

                     anonymous@server.dmn2.com

                This will be resolved IN THE CONTEXT OF Org. 2'S
                NETWORK. The user can then complete the dialog and
                use the FTP connection.

             d) Note that this setup will work even if the client and
                server have the EXACT SAME IP ADDRESS (10.1.2.3 in
                our example).

             If the proxy applications support selecting another
             proxy based on the destination supplied by the client,
             and if DNS domains are unique, more than two conflicting
             IP networks can be linked in this way! Here is an
             example configuration:

             a) Four IP networks that all use network 10 are linked
                by four proxy systems. The four proxy systems share a
                common, private IP network number and physical link
                (LAN or WAN).

             b) A user on organization 1's network wishes to access
                a server on network 3. The user connects to its local
                proxy (proxy 1) and supplies that target system name.

             c) Proxy 1 determines, based on a configuration rule,
                that the target system name is reachable by using
                proxy 3. So it connects to proxy 3 and passes the
                target system name.

             d) Proxy 3 determines that the target system name is
                local (to itself) and connects to it directly.


             Security Implications of chained proxies

             Obviously, when such "chained" configurations are built,
             access control rules and logging based on a
             final-client/final-server combination are difficult to
             enforce, since the first proxy in the chain sees a
             final-client/proxy relationship and the last proxy in
             the chain sees a proxy/final-server relationship.

             Doing better than this requires that the proxies be
             capable of passing the "original-client" and



Chatel                       Informational                     [Page 18]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


             "final-destination" information back and forth in the
             proxy chain for access control and/or logging purposes.
             This requires the proxies to trust each other, and
             requires the network path to be trusted (forging this
             information becomes an excellent attack).

             Even if these problems were to be solved reliably, the
             original goal of the proxy chains was to solve an IP
             and possibly a DNS conflict. The "original-client" and
             "final-destination" values may not have the same
             meaning everywhere in the overall setup. Tagging the
             information with a "universe-name" may help, assuming
             it is possible to define unique universe names in the
             first place. Obviously this topic requires more study.

4. Transparent application proxies

   The most visible problem of classical application proxies is the need
   for proxy-capable client programs and/or user education so that users
   know how to use the proxies.

   When somebody thought of modifying proxies in such a way that normal
   user procedures and normal client applications would still be able to
   take advantage of the proxies, the transparent proxy was born.

   A transparent application proxy is often described as a system that
   appears like a packet filter to clients, and like a classical proxy
   to servers. Apart from this important concept, transparent and
   classical proxies can do similar access control checks and can offer
   an equivalent level of security/robustness/performance, at least as
   far as the proxy itself is concerned.

   The following information will make it clear that small organizations
   that wish to use proxy technology for protection, that wish to rely
   entirely on one proxy system for network perimeter security, that
   want a minimal (or zero) impact on user procedures, and that do not
   wish to bother with proxy-capable clients will tend to prefer
   transparent proxy technology.

   Organizations with one or more of the following characteristics may
   prefer deploying classical proxy technology:

   a) own a substantial internal IP router network, and wish to
      avoid adding "external" routes on the network
   b) wish to deploy "defence in depth", such as internal firewalls,
      packet filtering on the internal network
   c) wish to keep their DNS environment fully isolated from the
      "other side" of their proxy system, or that fear that their



Chatel                       Informational                     [Page 19]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      internal DNS servers may be vulnerable to data-driven attacks
   d) use some IP networks that are in conflict with the "other side"
      of their proxy system
   e) wish to use proxy applications that are easily portable
      to different operating system types and/or versions
   f) wish to deploy multiple proxy systems interconnecting them
      to the SAME remote network without introducing dynamic
      routing for external routes on the internal network

   4.1 Transparent proxy connection example

      Let us go through an FTP sesssion again, through a "transparent"
      proxy this time. We assume that the proxy system has two IP
      addresses, two network interfaces, and two DNS names.

      The proxy system is running a special program which knows how to
      behave like an FTP client on one side, and like an FTP server on
      the other side. This program is what people call the "proxy". This
      program, being a transparent proxy, also has a very special
      relationship with the TCP/IP implementation of the proxy system.
      This relationship may be built in several ways, we will describe
      only one such possible way.

      We will assume that the proxy program is listening to incoming
      requests on the standard FTP control port (21/tcp), although this
      is not always the case in practice.


       +---------------+      +----------+
       |               |     /    IP      \
       |  c.dmn1.com   |----+  network(s)  +----------+
       | (c1.c2.c3.c4) |     \            /           |
       +---------------+      +----------+    +-----------------+
                                              | (p1.p2.p3.p4)   |
                                              | proxy1.dmn3.com |
                                              |                 |
                                              | proxy2.dmn4.com |
                                              | (p5.p6.p7.p8)   |
       +---------------+      +----------+    +-----------------+
       |               |     /    IP      \           |
       |  s.dmn2.com   |----+  network(s)  +----------+
       | (s1.s2.s3.s4) |     \            /
       +---------------+      +----------+








Chatel                       Informational                     [Page 20]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      The user starts an instance of an FTP client program on the client
      system "c.dmn1.com", and specifies a destination of "s.dmn2.com",
      just like if it was reachable directly.  On command-line systems,
      the user typically types:

          ftp s.dmn2.com

      The client system needs to convert the server's name to an IP
      address (if the user directly specified the server by address,
      this step is not needed).

      Converting the server name to an IP address requires work to be
      performed which ranges between two extremes:

       a) the client system has this name in its hosts file, or has
          local DNS caching capability and successfully retrieves the
          name of the proxy system in its cache. No network activity
          is performed to convert the name to an IP address.

       b) the client system, in combination with DNS name servers,
          generate DNS queries that eventually propagate close to the
          root of the DNS tree and back down the server's DNS branch.
          Eventually, a DNS server which is authoritative for the
          server system's domain is queried and returns the IP
          address associated with "s.dmn2.com" (depending on the
          case, it may return this to the client system directly or
          to an intermediate name server). Ultimately, the client
          system obtains a valid IP address for s.dmn2.com.























Chatel                       Informational                     [Page 21]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +---------------+          +--------+
       |               |         /   IP     \
       |  c.dmn1.com   |--------+ network(s) +------------+
       | (c1.c2.c3.c4) |         \          /             |
       +---------------+          +--------+      +-----------------+
        A  |                     /                | (p1.p2.p3.p4)   |
        |  | address for        /      +-----+    | proxy system    |
        |  | s.dmn2.com?       /      /       \   | (p5.p6.p7.p8)   |
        |  |                  /      /         \  +-----------------+
        |  |                 /      /           \         |
        |  |                /      / s.dmn2.com? |        |
        |  |         +--------+   /              |   +--------+
        |  +-------->|  DNS   |--+   +-------+   |  /   IP     \
        |            | server |     /         \  | + network(s) +
        +------------|   X    |<---+           + |  \          /
         s1.s2.s3.s4 +--------+     s1.s2.s3.s4| |   +--------+
                                               | |        |
                                               | +        |
                                               |  \   +--------+
                                               +   +->|  DNS   |
                                                \     | server |
                                                 +----|   Y    |
                                                      +--------+

       NOTE: In practice, DNS servers that are authoritative for
             s.dmn2.com are highly likely to be located on the OTHER
             side of the proxy system. This means that DNS queries
             from the inside to the outside MUST be able to cross the
             proxy system. If the proxy system wishes to provide
             "address hiding", it must make these DNS queries
             (originating from the inside) appear to come from the
             proxy itself. This can be achieved by using a BIND-based
             DNS server (which has some proxy capabilities) or some
             simpler DNS proxy program.  For full RFC compliance,
             the proxy system must be able to relay TCP-based queries
             just like UDP-based queries, since some client systems
             are rumored to ONLY use TCP for DNS queries.

             The proxy system must be able to detect and block several
             classes of attacks based on DNS which (if nothing else)
             may cause denial of service:

             a) attempts from the outside to return corrupt cache
                entries to an internal DNS server
             b) attempts to return DNS bindings which have no
                relationship to the actual DNS query (some DNS
                servers are vulnerable to this). The attacker's goal
                may be to prime the cache of internal DNS servers with



Chatel                       Informational                     [Page 22]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


                interesting entries, including entries for internal
                DNS names that point to external IP addresses...
             c) data-driven stuff similar in style to the "syslog
                buffer overrun" type attacks.

      Once the client system knows the IP address of the server system,
      it attempts to establish a connection to the standard FTP
      "control" TCP port on the server (port 21). For this to work, the
      client system must have a valid route for the server's IP address
      THAT LEADS TO THE PROXY SYSTEM, and the proxy system must have a
      valid route for the client's IP address and the server's IP
      address. All intermediate devices that behave like IP gateways
      must have valid routes for the client, the server, and usually the
      proxy. If these devices perform packet filtering, they must ALL
      allow the specific type of traffic required between C and S for
      this specific application.


                                                A
                                    route to S  |
                                                |
                                           +-----------------+
       +---------------+                   |  (p5.p6.p7.p8)  |
       |  c.dmn1.com   |                   | proxy system    |
       | (c1.c2.c3.c4) |                   |  (p1.p2.p3.p4)  |
       +---------------+                   +-----------------+
         | |                                    |   |
         | | route to S             route to C  |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to C                             | | route to S
         | |                                        | |
         | |      C          S                 C    | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               S                C          S

      At the start of the FTP session, a TCP packet with a source
      address of C and a destination address of S travels to the proxy
      system, expecting to cross it just like a normal IP gateway.

      This is when the transparent proxy shows its magic:

      The proxy's TCP/IP software stack sees this incoming packets (and
      subsequent ones) for a destination address that is NOT one of its
      own addresses. Based on some criteria (a configuration file, for



Chatel                       Informational                     [Page 23]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      example), it decides NOT to forward or drop the packet (which are
      the only two choices an RFC-standard TCP/IP implementation would
      have). The proxy system accepts the packet as if it was directed
      to one of its own IP addresses.

      In our example, the incoming packet is a TCP packet. Since
      standard TCP/IP stacks store both a LOCAL and REMOTE IP address
      field for each TCP connection, the transparent proxy may set the
      LOCAL IP address field to the IP address that the client wants to
      reach (s1.s2.s3.s4 in our example). The standard TCP/IP stack
      probably needs to be modified to do this. UDP examples, although
      not connection-based, could be handled in similar ways.

      Once this is done, the actual FTP proxy application is invoked
      since an incoming connection to TCP port 21 has occurred. It can
      determine what is the final target destination instantly, since
      the LOCAL IP address field of the connection contains the target
      server's IP address.  There is no need for the proxy application
      to ask the client what is the final target system.

      Since the FTP proxy application knows the IP address of the target
      system, it can choose to do two things:

       a) Setup a session to the final target system, the more
          frequent case.

       b) Decide (based on some internal configuration data) that it
          cannot reach the final target system directly, but must go
          through a "classical" proxy. This seems technically
          feasible, although no real transparent proxy system is
          known to offer this capability. The actual value of such
          a feature (if available) would need to be studied.

      If the FTP proxy decides to connect directly to the target system,
      it has the target system's IP address. It may choose to do a
      reverse lookup on the target IP address to obtain a target system
      name (possibly needed for access control). If this process
      involves DNS resolution, something like the following will happen:













Chatel                       Informational                     [Page 24]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +-----------------+
       | proxy1.dmn3.com |
       |  (p1.p2.p3.p4)  |          +--------+
       |                 |         /   IP     \
       | proxy2.dmn4.com |--------+ network(s) +------------+
       |  (p5.p6.p7.p8)  |         \          /             |
       +-----------------+          +--------+      +---------------+
        A  |                     /          \       | (s1.s2.s3.s4) |
        |  | name for           /            \      | s.dmn2.com    |
        |  | s1.s2.s3.s4?      /              \     |               |
        |  |                  /                \    +---------------+
        |  |                 /                  \
        |  |                /                    \
        |  |         +--------+   s1.s2.s3.s4?    +--------+
        |  +-------->|  DNS   |------------------>|  DNS   |
        |            | server |                   | server |
        +------------|   X    |<------------------|   Y    |
         s.dmn2.com  +--------+    s.dmn2.com     +--------+


      Once this is done and if the connection is allowed, the proxy
      attempts to establish a connection to the standard FTP "control"
      TCP port on the target server (port 21), using a technique
      identical to a "classical" proxy. For this to work, the proxy
      system must have a valid route to the server's IP address, and the
      server system must have a valid route to at least one of the
      proxy's IP address. All intermediate devices that behave like IP
      gateways must have valid routes to both the proxy and the server.
      If these devices perform packet filtering, they must ALL allow the
      specific type of traffic required between the proxy and S for this
      specific application.




















Chatel                       Informational                     [Page 25]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


       +-----------------+
       | proxy1.dmn3.com |
       |  (p1.p2.p3.p4)  |
       |                 |                 +----------------+
       | proxy2.dmn4.com |                 |  s.dmn2.com    |
       |  (p5.p6.p7.p8)  |                 | (s1.s2.s3.s4)  |
       +-----------------+                 +----------------+
         | |                                    |   |
         | | route to S             route to P2 |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to P2                            | | route to S
         | |                                        | |
         | |      P2         S                 P2   | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               S                P2         S


      The rest of the transparent proxy's operation is very similar to
      what would happen with a classical proxy.

   4.2 Characteristics of transparent proxy configurations

      Transparent proxy technology can be used to build the key
      component of a "firewall", in a way quite similar to the way
      classical proxy technology may be used. Several important details
      of the architecture must be different, however.

      4.2.1 IP addressing and routing requirements

         The transparent proxy system must be able to address all client
         and server systems to which it may provide service. It must
         also know valid IP routes to all these client and server
         systems.

         Server systems must be able to address the proxy system, and
         must know a valid IP route to the proxy system. If the proxy
         system has several IP addresses (and often, several physical
         network interfaces), the server systems need only to be able to
         access ONE of the proxy system's IP addresses.

         Client systems MUST HAVE valid IP addressing and routing
         information for systems that they reach through the proxy. For
         example, in the common case where a transparent proxy is being
         used to interconnect a private network and the Internet, the



Chatel                       Informational                     [Page 26]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         private network will effectively need to use a default route
         that points to the transparent proxy system. This is a specific
         need of transparent proxy configurations.

         Interconnecting two internetworks with multiple transparent
         proxies (for load sharing or fail-over) can be accomplished by
         using different techniques from what would be done for
         classical proxies:

             a) with multiple classical proxies to the same remote
                network, clients can be configured to access different
                proxies manually, or DNS-based techniques, such as
                DNS load-balancing may be used to make clients
                access a different proxy at different times.

             b) with multiple transparent proxies to the same remote
                network, the internal network must be able to provide
                dynamic routing towards the proxies (routing updates
                may need to be supplied by the proxies themselves).
                Client systems (depending on topology) may not need
                to see the route changes, but internal backbone
                routers probably do.

         It is clear that internetworks linked by a transparent proxy
         cannot be fully isolated from each other in an IP addressing
         and routing sense. The network on which client systems are
         located must have effective valid routing entries to the remote
         internetwork; these routing entries must point to the proxy.

         The transparent proxy system (if running a vaguely standard
         TCP/IP software stack) needs to have a single coherent view of
         IP addressing and routing. If a proxy system interconnects two
         IP networks and two systems use the same IP network/subnetwork
         number (one system on each internetwork), the proxy will only
         be able to address one of the systems. Even if the proxy is
         able to manage multiple conflicting IP universes (if, for
         example, one instance of a complete TCP/IP stack and its data
         structures is bound to each of the proxy network interfaces),
         the client systems will still have a problem: Why should it
         send packets with this network number to the proxy since this
         network number exists also on the internal internetwork?

         Chaining transparent proxies does not seem at first glance to
         solve IP conflicts like it does for classical proxies.

         From a "security" fail-safe point of view, the transparent
         proxy has an undesirable characteristic: the network being
         protected must have valid routing entries to the remote



Chatel                       Informational                     [Page 27]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         network(s). If the proxy fails (starts behaving like a non-
         filtering IP router) or is physically bypassed, it is likely
         that the internal network will be immediately able to reply to
         "attacker" packets. The attacker does not need to modify
         routing tables or to spoof internal IP addresses.

         This is important for organizations that do not wish to place
         ALL their confidence and protection into a proxy system (for
         whatever reason).

      4.2.2 IP address hiding

         Application "sessions" that go through a transparent proxy are
         actually made of two complete sessions:

             a) a session between the client and the address of the
                server, the session being "intercepted" by the proxy
             b) a session between the proxy and the server

         A device on the path sees either the client<->server traffic or
         the proxy<->server traffic, depending where it is located. The
         client<-"server" traffic is actually generated by the
         transparent proxy. The two sessions SHOULD NEVER pass through
         the same physical network, since in that case (due to the
         routing requirements) a total bypass of the proxy at the IP
         routing level may easily occur without being detectable.

         Like classical proxies, transparent proxies accomplish a form
         of IP address hiding. Client IP addresses are hidden from the
         servers, since the servers see a session being initiated by the
         proxy. Server IP addresses are NOT hidden from the clients
         however, so that the illusion of transparency may be
         maintained.

         This difference implies that internal (client-side) network
         statistics at the IP level will accurately reflect what outside
         destinations are being accessed.  This can be useful for
         analyzing traffic patterns.

      4.2.3 DNS requirements

         In transparent proxy configurations, client systems MUST be
         able to resolve server names belonging to remote networks. This
         is critical since the proxy will determine the target server
         from the destination IP address of the packets arriving from
         the client. Because of this, the "client" internetwork needs to
         have some form of DNS interconnection to the remote network. If
         internal client and name server IP addresses must be hidden



Chatel                       Informational                     [Page 28]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         from the outside, these DNS queries must also be proxied.

         Of course, remote host name/address relationships may be stored
         locally on the client systems, but it is well known that such
         an approach does not scale...

         Because of this, it can be said that a transparent proxy system
         cannot offer DNS isolation. If two IP internetworks use
         completely separate DNS trees (each with their own DNS root
         servers), client software in one IP internetwork will not have
         a way of finding name/address relationships in the "other" DNS
         tree, and this information must be obtained in order to pass
         the desired address to the transparent proxy.

         The classical proxy itself (if running standard DNS resolution
         software) will not be able alone to resolve DNS names in both
         environments, since it will need to point to one or the other
         of the two DNS "universes".  Running multiple instances of DNS
         resolution software can allow the proxy to do this, however.

         Because of the requirement placed on some form of DNS
         communication through the proxy, it is critical for the proxy
         to be able to protect ITSELF, internal clients, and internal
         name servers from data-driven attacks at the DNS level.

      4.2.4 Software requirements

         The big advantage of transparent proxies is that normal client
         software may access remote servers with no modifications and no
         changes to user procedures.

         The transparent proxy application itself may not need to be
         more complicated than a classical proxy application.

         However, the proxy TCP/IP software stack cannot be a fully-
         standard (well, today's standard at least) TCP/IP stack, and
         requires specific extensions:

             a) the ability to specify ranges of IP addresses that
                do not belong to the proxy itself, but for which
                "intercept" processing will occur: if packets arrive
                at the proxy with a destination IP address in those
                ranges, the IP stack will not forward or drop the
                packets; it will pass them up to application layers.

             b) This mechanism requires that applications may obtain
                both the IP address from which the packets come, and
                the address to which the packets were going. Typical



Chatel                       Informational                     [Page 29]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


                IP stacks should already have the fields available
                to store the info; it is a matter of updating them
                properly for these "intercepted" packets.

             c) In the case of "intercepted" TCP packets, the TCP
                stack must support establishing TCP connections
                where the "local" IP address is not one of the
                proxy's IP address.

         Any TCP/IP software implementation should be modifiable to
         perform these tasks. If a standard API becomes widely available
         to drive these extensions, and if this API is generally
         implemented, transparent proxies may become "portable"
         applications.

         Until this occurs, it must be assumed that implementors have
         chosen different ways of accomplishing these functions, so that
         today's transparent proxy applications cannot be fully
         portable. It also remains to be seen how much work is needed to
         propagate these "extensions" to IPV6 software stacks.

      4.2.5 Impact of a transparent proxy on packet filtering

         The nature of a transparent proxy's functionality makes it
         difficult to deploy good packet filtering on the "inside" (or
         client-side) of the proxy. The proxy will "masquerade" as all
         the external systems. Because of this, internal packet filters
         WILL TYPICALLY NEED TO ALLOW IP traffic between internal and
         external IP addresses.

         Depending on the actual security policy of the network, it may
         be possible to do filtering based on protocol type and/or on
         TCP bits (to filter based on connection setup direction), but
         filtering that blocks external IP addresses CANNOT be deployed.

         If the proxy starts behaving like an IP router, or if
         physically bypassed, the practical limitations imposed on
         internal packet filtering imply that a lot of direct traffic
         between the inside and outside network will be allowed to flow.
         Furthermore, as we have seen previously, the internal network
         will have valid routing entries for external network numbers
         that point to the proxy.  If multiple proxies have been
         deployed, the internal network may even HAVE TO TRUST routing
         updates generated by the proxy.

         In general, if an internal network wishes to communicate with
         an external network through a transparent proxy, it MUST BE
         FUNDAMENTALLY DESIGNED TO COMMUNICATE DIRECTLY with that



Chatel                       Informational                     [Page 30]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


         external network. This is true at the IP addressing level, at
         the IP routing level, and at the DNS level.  A proxy security
         failure in this type of environment is likely to result in
         immediate, total, and undetected accessibility of the internal
         network by the external network.

      4.2.6 Interconnection of conflicting IP networks

         Unlike classical proxies, transparent proxies do not readily
         seem useful in solving IP addressing conflicts.

         If two internetworks use the same network number(s), systems
         and routers in each internetwork will have valid routes to
         these network numbers. If these routes are changed to point to
         a transparent proxy, traffic that is meant to stay within the
         same internetwork would start to flow towards the proxy. The
         proxy will not be able to distinguish reliably between traffic
         between systems of the same internetwork, and traffic which is
         meant to cross the proxy.

         A possible solution to this problem is described in section 6
         of this document, "Improving transparent proxies".

5. Comparison chart of classical and transparent proxies

   For those who do not like longish discussions of technical details,
   here is a one-page summary of the strengths/weaknesses/differences of
   classical and transparent proxies:

    -----------------------------------------------------------------
   | Issue             |   Classical Proxy   |  Transparent Proxy   |
   |-------------------+---------------------+----------------------|
   | IP addressing     | systems/gateways on | systems/gateways on  |
   |                   | each network need   | the "client" network |
   |                   | to address the proxy| need to address the  |
   |                   |                     | remote networks      |
   |                   |                     |                      |
   | IP routing        | systems/gateways on | systems/gateways on  |
   |                   | each network need a | the "client" network |
   |                   | valid routing entry | also need routing    |
   |                   | for the proxy       | entries for remote   |
   |                   |                     | entries              |
   |                   |                     |                      |
   | IP address hiding | systems on each side| systems on the       |
   |                   | of the proxy are    | "client" side are    |
   |                   | hidden from each    | hidden from the      |
   |                   | other               | other sides          |
   |                   |                     |                      |



Chatel                       Informational                     [Page 31]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


   | DNS               | full isolation      | resolution of outside|
   |                   | possible            | names by inside      |
   |                   |                     | systems is required  |
   |                   |                     |                      |
   | Proxy software    | runs on standard    | requires special     |
   |    requirements   | TCP/IP stack;       | TCP/IP stack;        |
   |                   | can be portable     | not 100% portable    |
   |                   |                     |                      |
   | Client software   | requires proxy-     | nothing more than for|
   |    requirements   | capable software    | a direct connection  |
   |                   | or user education   |                      |
   |                   |                     |                      |
   | User requirements | must use proxy-     | nothing more than for|
   |                   | capable software or | a direct connection  |
   |                   | know how to use the |                      |
   |                   | proxy               |                      |
   |                   |                     |                      |
   | Packet filtering  | can filter out      | cannot filter out    |
   |                   | "external" addresses| "external" addresses |
   |                   |                     |                      |
   | IP address        | can be done with    | no obvious way to    |
   |    conflict       | chained proxies that| get this to work     |
   |    resolution     | support auto-connect|                      |
    ----------------------------------------------------------------

6. Improving transparent proxies

   The main issues with transparent proxies seem to revolve around the
   need to force "client" systems to directly access external addresses.
   To some people, this characteristic makes a transparent proxy look
   too much like a complicated packet filter. Can this problem be
   solved?

   The first possibility that comes to mind is to use the flexibility of
   the DNS protocol to build new tricks. If we restrict the "internal"
   clients so that they MUST ALWAYS use DNS to resolve external host
   names AND THAT THEY MUST NEVER store permanent copies of external
   host addresses, the following technique would become theoretically
   possible (this is a very painful restriction, by the way):

   a) arrange for all internal queries for external DNS names to
      go to the transparent proxy system (this can be done in a
      number of ways).

   b) arrange for a routing entry to exist for a class A network
      number that is not used on the internal network. This IMPLIES
      that the internal network may not be part of the Internet. This
      routing entry will point to the transparent proxy system. For



Chatel                       Informational                     [Page 32]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      the purpose of our discussion, this special network number will
      be X.0.0.0.

   c) when an internal system generates a query for an external
      address, the query (if no answer is cached on the internal
      network) will reach the proxy system. Assuming the query is to
      obtain the IP address corresponding to a domain name, the proxy
      will go through the following algorithm:

      - try to find a valid binding for this external domain name in
        its local cache

      - if not found, it will ITSELF launch an external DNS query
        for the domain name. When (and if) it receives a valid reply,
        it creates a local cache entry containing:

            Time To Live of the reply
            Expiry Time of the cache entry (based on the current time)
            External domain name
            External IP address
            Dynamically allocated IP address of the form X.x1.x2.x3.

        and returns to the client the dynamically allocated IP address
        in the range X.0.0.0, NOT THE REAL ONE.

      - the client may (or may not) store the IP address returned in
        its cache, and will then attempt to connect to the
        dynamically allocated IP address. This traffic will arrive at
        the proxy because of the routing setup.

      - The transparent proxy intercepts the traffic and can identify
        the actual desired target it should connect to based on the
        dynamically allocated IP address supplied by the client.

   Such an approach, if workable, could improve many characteristics of
   transparent proxies and may even make transparent proxies capable of
   handling IP network number conflicts.

   However, the algorithm above leaves many difficult questions
   unsolved. Here is a list (by no means exhaustive) of these questions:

   a) What is the percentage of client DNS resolver and DNS server
      implementations that conform to the RFC specifications in their
      handling of the Time-To-Live field?

   b) How should the proxy handle other types of DNS queries for
      external domain names (inverse queries, queries for other
      resource record types)?



Chatel                       Informational                     [Page 33]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


   c) A client program may perform a DNS query once for an external
      name and then use the response for a long time (a large file
      transfer, or a permanent management session, for example).
      Should the proxy update the Expiry Time of cache entries based
      on the passing IP traffic, and if so, using what algorithm?

   d) What new types of attacks would such a system introduce or
      make possible?

   e) What data structures and resources (memory, disk) would be
      needed for an efficient implementation if the proxy must sustain
      a high rate of DNS queries for external names, and where a large
      number of different external names are referenced? The class A
      network number is used basically to reference cache entries.
      Would a 24-bit address space be sufficient for practical use?

   f) What happens with the cache (and the functionality) if the proxy
      crashes or reboots?

   Such a system would probably exhibit two types of intermittent
   failures:

   a) a client system is still using the result of an external name
      query (some X.x1.x2.x3 address dynamically allocated by the
      proxy), but this binding no longer exists in the proxy's cache.
      The client attempts a connection to this address, which fails.

   b) a client's name cache contains a binding for X.x1.x2.x3, but the
      proxy has already reused this address for a different external
      host name. The client attempts a connection to this address,
      sees no obvious errors, but reaches a different system from the
      expected one.

   If somebody has ever implemented such a scheme, information and live
   experience in deploying it would be useful to the IP networking
   community.

7. Security Considerations

   Most of this document is concerned with security implications of
   classical and transparent proxy technology.

8. Acknowledgements

   I could not have written this document without the support of Digital
   Equipment Corporation for whom I work as a consultant.





Chatel                       Informational                     [Page 34]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


9. References

   [1] Cheswick, W., Bellovin, S., "Firewalls and Internet Security:
       Repelling the Wily Hacker", Addison-Wesley, 1994.

   [2] Chapman, B., Zwicky, E., "Building Internet Firewalls",
       O'Reilly and Associates, Inc., September 1995.

   [3] Comer, D., "Internetworking with TCP/IP volume 1: Principles,
       Protocols, and Architecture", Prentice-Hall, 1991.

   [4] Comer, D., Stevens, D., "Internetworking with TCP/IP volume 2:
       "Design, Implementation, and Internals", Prentice-Hall, 1991.

   [5] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
       STD 9, RFC 959, USC/Information Sciences Institute, October
       1985.

   [6] Huitema, C., "An experiment in DNS Based IP Routing", RFC 1383,
       INRIA, December 1992.

   [7] Rekhter Y., Moskowitz B., Karrenberg D., de Groot, G.,
       "Address Allocation for Private Internets", RFC 1597,
       IBM Corp., Chrysler Corp, RIPE NCC, March 1994.

   [8] The TIS firewall toolkit's documentation, available on
       Trusted Information System's anonymous FTP site, ftp.tis.com.

   [9] Many discussions in the last 18 months on the firewalls-digest
       mailing list maintained by Great Circle Associates. The
       archives of the list are maintained at ftp.greatcircle.com.

Author's Address

   Marc Chatel
   9, avenue Jean Monnet
   74940 ANNECY-LE-VIEUX
   FRANCE

   EMail: mchatel@pax.eunet.ch
   or at Digital Equipment:
   Marc.Chatel@aeo.mts.dec.com









Chatel                       Informational                     [Page 35]