File: rfc3040.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 (1795 lines) | stat: -rw-r--r-- 63,257 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






Network Working Group                                          I. Cooper
Request for Comments: 3040                                 Equinix, Inc.
Category: Informational                                         I. Melve
                                                                 UNINETT
                                                            G. Tomlinson
                                                          CacheFlow Inc.
                                                            January 2001


             Internet Web Replication and Caching Taxonomy

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo specifies standard terminology and the taxonomy of web
   replication and caching infrastructure as deployed today.  It
   introduces standard concepts, and protocols used today within this
   application domain.  Currently deployed solutions employing these
   technologies are presented to establish a standard taxonomy.  Known
   problems with caching proxies are covered in the document titled
   "Known HTTP Proxy/Caching Problems", and are not part of this
   document.  This document presents open protocols and points to
   published material for each protocol.

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1     Base Terms . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2     First order derivative terms . . . . . . . . . . . . . . .  6
   2.3     Second order derivatives . . . . . . . . . . . . . . . . .  7
   2.4     Topological terms  . . . . . . . . . . . . . . . . . . . .  7
   2.5     Automatic use of proxies . . . . . . . . . . . . . . . . .  8
   3.      Distributed System Relationships . . . . . . . . . . . . .  9
   3.1     Replication Relationships  . . . . . . . . . . . . . . . .  9
   3.1.1   Client to Replica  . . . . . . . . . . . . . . . . . . . .  9
   3.1.2   Inter-Replica  . . . . . . . . . . . . . . . . . . . . . .  9
   3.2     Proxy Relationships  . . . . . . . . . . . . . . . . . . . 10
   3.2.1   Client to Non-Interception Proxy . . . . . . . . . . . . . 10



Cooper, et al.               Informational                      [Page 1]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   3.2.2   Client to Surrogate to Origin Server . . . . . . . . . . . 10
   3.2.3   Inter-Proxy  . . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 11
   3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 12
   3.2.4   Network Element to Caching Proxy . . . . . . . . . . . . . 12
   4.      Replica Selection  . . . . . . . . . . . . . . . . . . . . 13
   4.1     Navigation Hyperlinks  . . . . . . . . . . . . . . . . . . 13
   4.2     Replica HTTP Redirection . . . . . . . . . . . . . . . . . 14
   4.3     DNS Redirection  . . . . . . . . . . . . . . . . . . . . . 14
   5.      Inter-Replica Communication  . . . . . . . . . . . . . . . 15
   5.1     Batch Driven Replication . . . . . . . . . . . . . . . . . 15
   5.2     Demand Driven Replication  . . . . . . . . . . . . . . . . 16
   5.3     Synchronized Replication . . . . . . . . . . . . . . . . . 16
   6.      User Agent to Proxy Configuration  . . . . . . . . . . . . 17
   6.1     Manual Proxy Configuration . . . . . . . . . . . . . . . . 17
   6.2     Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 17
   6.3     Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 18
   6.4     Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 18
   7.      Inter-Proxy Communication  . . . . . . . . . . . . . . . . 19
   7.1     Loosely coupled Inter-Proxy Communication  . . . . . . . . 19
   7.1.1   Internet Cache Protocol (ICP)  . . . . . . . . . . . . . . 19
   7.1.2   Hyper Text Caching Protocol  . . . . . . . . . . . . . . . 20
   7.1.3   Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 21
   7.1.4   Cache Pre-filling  . . . . . . . . . . . . . . . . . . . . 22
   7.2     Tightly Coupled Inter-Cache Communication  . . . . . . . . 22
   7.2.1   Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 22
   8.      Network Element Communication  . . . . . . . . . . . . . . 23
   8.1     Web Cache Control Protocol (WCCP)  . . . . . . . . . . . . 23
   8.2     Network Element Control Protocol (NECP)  . . . . . . . . . 24
   8.3     SOCKS  . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   9.      Security Considerations  . . . . . . . . . . . . . . . . . 25
   9.1     Authentication . . . . . . . . . . . . . . . . . . . . . . 26
   9.1.1   Man in the middle attacks  . . . . . . . . . . . . . . . . 26
   9.1.2   Trusted third party  . . . . . . . . . . . . . . . . . . . 26
   9.1.3   Authentication based on IP number  . . . . . . . . . . . . 26
   9.2     Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 26
   9.2.1   Trusted third party  . . . . . . . . . . . . . . . . . . . 26
   9.2.2   Logs and legal implications  . . . . . . . . . . . . . . . 27
   9.3     Service security . . . . . . . . . . . . . . . . . . . . . 27
   9.3.1   Denial of service  . . . . . . . . . . . . . . . . . . . . 27
   9.3.2   Replay attack  . . . . . . . . . . . . . . . . . . . . . . 27
   9.3.3   Stupid configuration of proxies  . . . . . . . . . . . . . 28
   9.3.4   Copyrighted transient copies . . . . . . . . . . . . . . . 28
   9.3.5   Application level access . . . . . . . . . . . . . . . . . 28
   10.     Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
           References . . . . . . . . . . . . . . . . . . . . . . . . 28
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
           Full Copyright Statement . . . . . . . . . . . . . . . . . 32



Cooper, et al.               Informational                      [Page 2]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


1. Introduction

   Since its introduction in 1990, the World-Wide Web has evolved from a
   simple client server model into a complex distributed architecture.
   This evolution has been driven largely due to the scaling problems
   associated with exponential growth.  Distinct paradigms and solutions
   have emerged to satisfy specific requirements.  Two core
   infrastructure components being employed to meet the demands of this
   growth are replication and caching.  In many cases, there is a need
   for web caches and replicated services to be able to coexist.

   This memo specifies standard terminology and the taxonomy of web
   replication and caching infrastructure deployed in the Internet
   today.  The principal goal of this document is to establish a common
   understanding and reference point of this application domain.

   It is also expected that this document will be used in the creation
   of a standard architectural framework for efficient, reliable, and
   predictable service in a web which includes both replicas and caches.

   Some of the protocols which this memo examines are specified only by
   company technical white papers or work in progress documents.  Such
   references are included to demonstrate the existence of such
   protocols, their experimental deployment in the Internet today, or to
   aid the reader in their understanding of this technology area.

   There are many protocols, both open and proprietary, employed in web
   replication and caching today.  A majority of the open protocols
   include DNS [8], Cache Digests [21][10], CARP [14], HTTP [1], ICP
   [2], PAC [12], SOCKS [7], WPAD [13], and WCCP [18][19].  These
   protocols, and their use within the caching and replication
   environments, are discussed below.

2. Terminology

   The following terminology provides definitions of common terms used
   within the web replication and caching community.  Base terms are
   taken, where possible, from the HTTP/1.1 specification [1] and are
   included here for reference.  First- and second-order derivatives are
   constructed from these base terms to help define the relationships
   that exist within this area.

   Terms that are in common usage and which are contrary to definitions
   in RFC 2616 and this document are highlighted.







Cooper, et al.               Informational                      [Page 3]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


2.1 Base Terms

   The majority of these terms are taken as-is from RFC 2616 [1], and
   are included here for reference.

   client (taken from [1])
      A program that establishes connections for the purpose of sending
      requests.

   server (taken from [1])
      An application program that accepts connections in order to
      service requests by sending back responses.  Any given program may
      be capable of being both a client and a server; our use of these
      terms refers only to the role being performed by the program for a
      particular connection, rather than to the program's capabilities
      in general.  Likewise, any server may act as an origin server,
      proxy, gateway, or tunnel, switching behavior based on the nature
      of each request.

   proxy (taken from [1])
      An intermediary program which acts as both a server and a client
      for the purpose of making requests on behalf of other clients.
      Requests are serviced internally or by passing them on, with
      possible translation, to other servers.  A proxy MUST implement
      both the client and server requirements of this specification.  A
      "transparent proxy" is a proxy that does not modify the request or
      response beyond what is required for proxy authentication and
      identification.  A "non-transparent proxy" is a proxy that
      modifies the request or response in order to provide some added
      service to the user agent, such as group annotation services,
      media type transformation, protocol reduction, or anonymity
      filtering.  Except where either transparent or non-transparent
      behavior is explicitly stated, the HTTP proxy requirements apply
      to both types of proxies.

   Note: The term "transparent proxy" refers to a semantically
   transparent proxy as described in [1], not what is commonly
   understood within the caching community.  We recommend that the term
   "transparent proxy" is always prefixed to avoid confusion (e.g.,
   "network transparent proxy").  However, see definition of
   "interception proxy" below.

   The above condition requiring implementation of both the server and
   client requirements of HTTP/1.1 is only appropriate for a non-network
   transparent proxy.






Cooper, et al.               Informational                      [Page 4]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   cache (taken from [1])
      A program's local store of response messages and the subsystem
      that controls its message storage, retrieval, and deletion.  A
      cache stores cacheable responses in order to reduce the response
      time and network bandwidth consumption on future, equivalent
      requests.  Any client or server may include a cache, though a
      cache cannot be used by a server that is acting as a tunnel.

   Note: The term "cache" used alone often is meant as "caching proxy".

   Note: There are additional motivations for caching, for example
   reducing server load (as a further means to reduce response time).

   cacheable (taken from [1])
      A response is cacheable if a cache is allowed to store a copy of
      the response message for use in answering subsequent requests.
      The rules for determining the cacheability of HTTP responses are
      defined in section 13.  Even if a resource is cacheable, there may
      be additional constraints on whether a cache can use the cached
      copy for a particular request.

   gateway (taken from [1])
      A server which acts as an intermediary for some other server.
      Unlike a proxy, a gateway receives requests as if it were the
      origin server for the requested resource; the requesting client
      may not be aware that it is communicating with a gateway.

   tunnel (taken from [1])
      An intermediary program which is acting as a blind relay between
      two connections.  Once active, a tunnel is not considered a party
      to the HTTP communication, though the tunnel may have been
      initiated by an HTTP request.  The tunnel ceases to exist when
      both ends of the relayed connections are closed.

   replication
      "Creating and maintaining a duplicate copy of a database or file
      system on a different computer, typically a server."  - Free
      Online Dictionary of Computing (FOLDOC)

   inbound/outbound (taken from [1])
      Inbound and outbound refer to the request and response paths for
      messages: "inbound" means "traveling toward the origin server",
      and "outbound" means "traveling toward the user agent".

   network element
      A network device that introduces multiple paths between source and
      destination, transparent to HTTP.




Cooper, et al.               Informational                      [Page 5]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


2.2 First order derivative terms

   The following terms are constructed taking the above base terms as
   foundation.

   origin server (taken from [1])
      The server on which a given resource resides or is to be created.

   user agent (taken from [1])
      The client which initiates a request.  These are often browsers,
      editors, spiders (web-traversing robots), or other end user tools.

   caching proxy
      A proxy with a cache, acting as a server to clients, and a client
      to servers.

      Caching proxies are often referred to as "proxy caches" or simply
      "caches".  The term "proxy" is also frequently misused when
      referring to caching proxies.

   surrogate
      A gateway co-located with an origin server, or at a different
      point in the network, delegated the authority to operate on behalf
      of, and typically working in close co-operation with, one or more
      origin servers.  Responses are typically delivered from an
      internal cache.

      Surrogates may derive cache entries from the origin server or from
      another of the origin server's delegates.  In some cases a
      surrogate may tunnel such requests.

      Where close co-operation between origin servers and surrogates
      exists, this enables modifications of some protocol requirements,
      including the Cache-Control directives in [1].  Such modifications
      have yet to be fully specified.

      Devices commonly known as "reverse proxies" and "(origin) server
      accelerators" are both more properly defined as surrogates.

   reverse proxy
      See "surrogate".

   server accelerator
      See "surrogate".







Cooper, et al.               Informational                      [Page 6]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


2.3 Second order derivatives

   The following terms further build on first order derivatives:

   master origin server
      An origin server on which the definitive version of a resource
      resides.

   replica origin server
      An origin server holding a replica of a resource, but which may
      act as an authoritative reference for client requests.

   content consumer
      The user or system that initiates inbound requests, through use of
      a user agent.

   browser
      A special instance of a user agent that acts as a content
      presentation device for content consumers.

2.4 Topological terms

   The following definitions are added to describe caching device
   topology:

   user agent cache
      The cache within the user agent program.

   local caching proxy
      The caching proxy to which a user agent connects.

   intermediate caching proxy
      Seen from the content consumer's view, all caches participating in
      the caching mesh that are not the user agent's local caching
      proxy.

   cache server
      A server to requests made by local and intermediate caching
      proxies, but which does not act as a proxy.

   cache array
      A cluster of caching proxies, acting logically as one service and
      partitioning the resource name space across the array.  Also known
      as "diffused array" or "cache cluster".







Cooper, et al.               Informational                      [Page 7]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   caching mesh
      a loosely coupled set of co-operating proxy- and (optionally)
      caching-servers, or clusters, acting independently but sharing
      cacheable content between themselves using inter-cache
      communication protocols.

2.5 Automatic use of proxies

   Network administrators may wish to force or facilitate the use of
   proxies by clients, enabling such configuration within the network
   itself or within automatic systems in user agents, such that the
   content consumer need not be aware of any such configuration issues.

   The terms that describe such configurations are given below.

   automatic user-agent proxy configuration
      The technique of discovering the availability of one or more
      proxies and the automated configuration of the user agent to use
      them.  The use of a proxy is transparent to the content consumer
      but not to the user agent.  The term "automatic proxy
      configuration" is also used in this sense.

   traffic interception
      The process of using a network element to examine network traffic
      to determine whether it should be redirected.

   traffic redirection
      Redirection of client requests from a network element performing
      traffic interception to a proxy.  Used to deploy (caching) proxies
      without the need to manually reconfigure individual user agents,
      or to force the use of a proxy where such use would not otherwise
      occur.

   interception proxy (a.k.a. "transparent proxy", "transparent cache")
      The term "transparent proxy" has been used within the caching
      community to describe proxies used with zero configuration within
      the user agent.  Such use is somewhat transparent to user agents.
      Due to discrepancies with [1] (see definition of "proxy" above),
      and objections to the use of the word "transparent", we introduce
      the term "interception proxy" to describe proxies that receive
      redirected traffic flows from network elements performing traffic
      interception.

      Interception proxies receive inbound traffic flows through the
      process of traffic redirection.  (Such proxies are deployed by
      network administrators to facilitate or require the use of
      appropriate services offered by the proxy).  Problems associated
      with the deployment of interception proxies are described in the



Cooper, et al.               Informational                      [Page 8]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      document "Known HTTP Proxy/Caching Problems" [23].  The use of
      interception proxies requires zero configuration of the user agent
      which act as though communicating directly with an origin server.

3. Distributed System Relationships

   This section identifies the relationships that exist in a distributed
   replication and caching environment.  Having defined these
   relationships, later sections describe the communication protocols
   used in each relationship.

3.1 Replication Relationships

   The following sections describe relationships between clients and
   replicas and between replicas themselves.

3.1.1 Client to Replica

   A client may communicate with one or more replica origin servers, as
   well as with master origin servers.  (In the absence of replica
   servers the client interacts directly with the origin server as is
   the normal case.)

      ------------------     -----------------     ------------------
      | Replica Origin |     | Master Origin |     | Replica Origin |
      |     Server     |     |    Server     |     |     Server     |
      ------------------     -----------------     ------------------
               \                    |                      /
                \                   |                     /
                 -----------------------------------------
                                    |                 Client to
                             -----------------        Replica Server
                             |     Client    |
                             -----------------

   Protocols used to enable the client to use one of the replicas can be
   found in Section 4.

3.1.2 Inter-Replica

   This is the relationship between master origin server(s) and replica
   origin servers, to replicate data sets that are accessed by clients
   in the relationship shown in Section 3.1.1.








Cooper, et al.               Informational                      [Page 9]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      ------------------     -----------------     ------------------
      | Replica Origin |-----| Master Origin |-----| Replica Origin |
      |     Server     |     |    Server     |     |     Server     |
      ------------------     -----------------     ------------------

   Protocols used in this relationship can be found in Section 5.

3.2 Proxy Relationships

   There are a variety of ways in which (caching) proxies and cache
   servers communicate with each other, and with user agents.

3.2.1 Client to Non-Interception Proxy

   A client may communicate with zero or more proxies for some or all
   requests.  Where the result of communication results in no proxy
   being used, the relationship is between client and (replica) origin
   server (see Section 3.1.1).

      -----------------     -----------------     -----------------
      |     Local     |     |     Local     |     |     Local     |
      |     Proxy     |     |     Proxy     |     |     Proxy     |
      -----------------     -----------------     -----------------
               \                    |                      /
                \                   |                     /
                 -----------------------------------------
                                    |
                             -----------------
                             |     Client    |
                             -----------------

   In addition, a user agent may interact with an additional server -
   operated on behalf of a proxy for the purpose of automatic user agent
   proxy configuration.

   Schemes and protocols used in these relationships can be found in
   Section 6.

3.2.2 Client to Surrogate to Origin Server

   A client may communicate with zero or more surrogates for requests
   intended for one or more origin servers.  Where a surrogate is not
   used, the client communicates directly with an origin server.  Where
   a surrogate is used the client communicates as if with an origin
   server.  The surrogate fulfills the request from its internal cache,
   or acts as a gateway or tunnel to the origin server.





Cooper, et al.               Informational                     [Page 10]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


            --------------  --------------   --------------
            |   Origin   |  |   Origin   |   |   Origin   |
            |   Server   |  |   Server   |   |   Server   |
            --------------  --------------   --------------
                          \        |        /
                           \       |       /
                           -----------------
                           |   Surrogate   |
                           |               |
                           -----------------
                                   |
                                   |
                             ------------
                             |  Client  |
                             ------------

3.2.3 Inter-Proxy

   Inter-Proxy relationships exist as meshes (loosely coupled) and
   clusters (tightly coupled).

3.2.3.1 (Caching) Proxy Meshes

   Within a loosely coupled mesh of (caching) proxies, communication can
   happen at the same level between peers, and with one or more parents.

                        ---------------------  ---------------------
             -----------|    Intermediate   |  |    Intermediate   |
             |          | Caching Proxy (D) |  | Caching Proxy (E) |
             |(peer)    ---------------------  ---------------------
       --------------             | (parent)       / (parent)
       |   Cache    |             |         ------/
       | Server (C) |             |        /
       --------------             |       /
      (peer) |            -----------------       ---------------------
             -------------| Local Caching |-------|    Intermediate   |
                          |   Proxy (A)   | (peer)| Caching Proxy (B) |
                          -----------------       ---------------------
                                  |
                                  |
                              ----------
                              | Client |
                              ----------

   Client included for illustration purposes only






Cooper, et al.               Informational                     [Page 11]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   An inbound request may be routed to one of a number of intermediate
   (caching) proxies based on a determination of whether that parent is
   better suited to resolving the request.

   For example, in the above figure, Cache Server C and Intermediate
   Caching Proxy B are peers of the Local Caching Proxy A, and may only
   be used when the resource requested by A already exists on either B
   or C.  Intermediate Caching Proxies D & E are parents of A, and it is
   A's choice of which to use to resolve a particular request.

   The relationship between A & B only makes sense in a caching
   environment, while the relationships between A & D and A & E are also
   appropriate where D or E are non-caching proxies.

   Protocols used in these relationships can be found in Section 7.1.

3.2.3.2 (Caching) Proxy Arrays

   Where a user agent may have a relationship with a proxy, it is
   possible that it may instead have a relationship with an array of
   proxies arranged in a tightly coupled mesh.

                              ----------------------
                         ----------------------    |
                     ---------------------    |    |
                     |  (Caching) Proxy  |    |-----
                     |      Array        |----- ^ ^
                     --------------------- ^ ^  | |
                         ^            ^    | |--- |
                         |            |-----      |
                         --------------------------

   Protocols used in this relationship can be found in Section 7.2.

3.2.4 Network Element to Caching Proxy

   A network element performing traffic interception may choose to
   redirect requests from a client to a specific proxy within an array.
   (It may also choose not to redirect the traffic, in which case the
   relationship is between client and (replica) origin server, see
   Section 3.1.1.)










Cooper, et al.               Informational                     [Page 12]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      -----------------     -----------------     -----------------
      | Caching Proxy |     | Caching Proxy |     | Caching Proxy |
      |     Array     |     |     Array     |     |     Array     |
      -----------------     -----------------     -----------------
                \                   |                     /
                 -----------------------------------------
                                    |
                              --------------
                              |  Network   |
                              |  Element   |
                              --------------
                                    |
                                   ///
                                    |
                               ------------
                               |  Client  |
                               ------------

   The interception proxy may be directly in-line of the flow of traffic
   - in which case the intercepting network element and interception
   proxy form parts of the same hardware system - or may be out-of-path,
   requiring the intercepting network element to redirect traffic to
   another network segment.  In this latter case, communication
   protocols enable the intercepting network element to stop and start
   redirecting traffic when the interception proxy becomes
   (un)available.  Details of these protocols can be found in Section 8.

4. Replica Selection

   This section describes the schemes and protocols used in the
   cooperation and communication between client and replica origin web
   servers.  The ideal situation is to discover an optimal replica
   origin server for clients to communicate with.  Optimality is a
   policy based decision, often based upon proximity, but may be based
   on other criteria such as load.

4.1 Navigation Hyperlinks

   Best known reference:
      This memo.

   Description:
      The simplest of client to replica communication mechanisms.  This
      utilizes hyperlink URIs embedded in web pages that point to the
      individual replica origin servers.  The content consumer manually
      selects the link of the replica origin server they wish to use.





Cooper, et al.               Informational                     [Page 13]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Security:
      Relies on the protocol security associated with the appropriate
      URI scheme.

   Deployment:
      Probably the most commonly deployed client to replica
      communication mechanism.  Ubiquitous interoperability with humans.

   Submitter:
      Document editors.

4.2 Replica HTTP Redirection

   Best known reference:
      This memo.

   Description:
      A simple and commonly used mechanism to connect clients with
      replica origin servers is to use HTTP redirection.  Clients are
      redirected to an optimal replica origin server via the use of the
      HTTP [1] protocol response codes, e.g., 302 "Found", or 307
      "Temporary Redirect".  A client establishes HTTP communication
      with one of the replica origin servers.  The initially contacted
      replica origin server can then either choose to accept the service
      or redirect the client again.  Refer to section 10.3 in HTTP/1.1
      [1] for information on HTTP response codes.

   Security:
      Relies entirely upon HTTP security.

   Deployment:
      Observed at a number of large web sites.  Extent of usage in the
      Internet is unknown.

   Submitter:
      Document editors.

4.3 DNS Redirection

   Best known references:

      *  RFC 1794 DNS Support for Load Balancing Proximity [8]

      *  This memo

   Description:
      The Domain Name Service (DNS) provides a more sophisticated client
      to replica communication mechanism.  This is accomplished by DNS



Cooper, et al.               Informational                     [Page 14]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      servers that sort resolved IP addresses based upon quality of
      service policies.  When a client resolves the name of an origin
      server, the enhanced DNS server sorts the available IP addresses
      of the replica origin servers starting with the most optimal
      replica and ending with the least optimal replica.

   Security:
      Relies entirely upon DNS security, and other protocols that may be
      used in determining the sort order.

   Deployment:
      Observed at a number of large web sites and large ISP web hosted
      services.  Extent of usage in the Internet is unknown, but is
      believed to be increasing.

   Submitter:
      Document editors.

5. Inter-Replica Communication

   This section describes the cooperation and communication between
   master- and replica- origin servers.  Used in replicating data sets
   between origin servers.

5.1 Batch Driven Replication

   Best known reference:
      This memo.

   Description:
      The replica origin server to be updated initiates communication
      with a master origin server.  The communication is established at
      intervals based upon queued transactions which are scheduled for
      deferred processing.  The scheduling mechanism policies vary, but
      generally are re-occurring at a specified time.  Once
      communication is established, data sets are copied to the
      initiating replica origin server.

   Security:
      Relies upon the protocol being used to transfer the data set.  FTP
      [4] and RDIST are the most common protocols observed.

   Deployment:
      Very common for synchronization of mirror sites in the Internet.

   Submitter:
      Document editors.




Cooper, et al.               Informational                     [Page 15]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


5.2 Demand Driven Replication

   Best known reference:
      This memo.

   Description:
      Replica origin servers acquire content as needed due to client
      demand.  When a client requests a resource that is not in the data
      set of the replica origin server/surrogate, an attempt is made to
      resolve the request by acquiring the resource from the master
      origin server, returning it to the requesting client.

   Security:
      Relies upon the protocol being used to transfer the resources. FTP
      [4], Gopher [5], HTTP [1] and ICP [2] are the most common
      protocols observed.

   Deployment:
      Observed at several large web sites.  Extent of usage in the
      Internet is unknown.

   Submitter:
      Document editors.

5.3 Synchronized Replication

   Best known reference:
      This memo.

   Description:
      Replicated origin servers cooperate using synchronized strategies
      and specialized replica protocols to keep the replica data sets
      coherent.  Synchronization strategies range from tightly coherent
      (a few minutes) to loosely coherent (a few or more hours). Updates
      occur between replicas based upon the synchronization time
      constraints of the coherency model employed and are generally in
      the form of deltas only.

   Security:
      All of the known protocols utilize strong cryptographic key
      exchange methods, which are either based upon the Kerberos shared
      secret model or the public/private key RSA model.

   Deployment:
      Observed at a few sites, primarily at university campuses.

   Submitter:
      Document editors.



Cooper, et al.               Informational                     [Page 16]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Note:
      The editors are aware of at least two open source protocols - AFS
      and CODA - as well as the proprietary NRS protocol from Novell.

6. User Agent to Proxy Configuration

   This section describes the configuration, cooperation and
   communication between user agents and proxies.

6.1 Manual Proxy Configuration

   Best known reference:
      This memo.

   Description:
      Each user must configure her user agent by supplying information
      pertaining to proxied protocols and local policies.

   Security:
      The potential for doing wrong is high; each user individually sets
      preferences.

   Deployment:
      Widely deployed, used in all current browsers.  Most browsers also
      support additional options.

   Submitter:
      Document editors.

6.2 Proxy Auto Configuration (PAC)

   Best known reference:
      "Navigator Proxy Auto-Config File Format" [12]

   Description:
      A JavaScript script retrieved from a web server is executed for
      each URL accessed to determine the appropriate proxy (if any) to
      be used to access the resource.  User agents must be configured to
      request this script upon startup.  There is no bootstrap
      mechanism, manual configuration is necessary.

      Despite manual configuration, the process of proxy configuration
      is simplified by centralizing it within a script at a single
      location.

   Security:
      Common policy per organization possible but still requires initial
      manual configuration.  PAC is better than "manual proxy



Cooper, et al.               Informational                     [Page 17]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      configuration" since PAC administrators may update the proxy
      configuration without further user intervention.

      Interoperability of PAC files is not high, since different
      browsers have slightly different interpretations of the same
      script, possibly leading to undesired effects.

   Deployment:
      Implemented in Netscape Navigator and Microsoft Internet Explorer.

   Submitter:
      Document editors.

6.3 Cache Array Routing Protocol (CARP) v1.0

   Best known references:

      *  "Cache Array Routing Protocol" [14] (work in progress)

      *  "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]

      *  "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
         [16]

   Description:
      User agents may use CARP directly as a hash function based proxy
      selection mechanism.  They need to be configured with the location
      of the cluster information.

   Security:
      Security considerations are not covered in the specification works
      in progress.

   Deployment:
      Implemented in Microsoft Proxy Server, Squid.  Implemented in user
      agents via PAC scripts.

   Submitter:
      Document editors.

6.4 Web Proxy Auto-Discovery Protocol (WPAD)

   Best known reference:
      "The Web Proxy Auto-Discovery Protocol" [13] (work in progress)

   Description:
      WPAD uses a collection of pre-existing Internet resource discovery
      mechanisms to perform web proxy auto-discovery.



Cooper, et al.               Informational                     [Page 18]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      The only goal of WPAD is to locate the PAC URL [12].  WPAD does
      not specify which proxies will be used.  WPAD supplies the PAC
      URL, and the PAC script then operates as defined above to choose
      proxies per resource request.

      The WPAD protocol specifies the following:

      *  how to use each mechanism for the specific purpose of web proxy
         auto-discovery

      *  the order in which the mechanisms should be performed

      *  the minimal set of mechanisms which must be attempted by a WPAD
         compliant user agent

      The resource discovery mechanisms utilized by WPAD are as follows:

      *  Dynamic Host Configuration Protocol DHCP

      *  Service Location Protocol SLP

      *  "Well Known Aliases" using DNS A records

      *  DNS SRV records

      *  "service: URLs" in DNS TXT records

   Security:
      Relies upon DNS and HTTP security.

   Deployment:
      Implemented in some user agents and caching proxy servers.  More
      than two independent implementations.

   Submitter:
      Josh Cohen

7. Inter-Proxy Communication

7.1 Loosely coupled Inter-Proxy Communication

   This section describes the cooperation and communication between
   caching proxies.

7.1.1 Internet Cache Protocol (ICP)

   Best known reference:
      RFC 2186  Internet Cache Protocol (ICP), version 2 [2]



Cooper, et al.               Informational                     [Page 19]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Description:
      ICP is used by proxies to query other (caching) proxies about web
      resources, to see if the requested resource is present on the
      other system.

      ICP uses UDP.  Since UDP is an uncorrected network transport
      protocol, an estimate of network congestion and availability may
      be calculated by ICP loss.  This rudimentary loss measurement
      provides, together with round trip times, a load balancing method
      for caches.

   Security:
      See RFC 2187 [3]

      ICP does not convey information about HTTP headers associated with
      resources.  HTTP headers may include access control and cache
      directives.  Since proxies ask for the availability of resources,
      and subsequently retrieve them using HTTP, false cache hits may
      occur (object present in cache, but not accessible to a sibling is
      one example).

      ICP suffers from all the security problems of UDP.

   Deployment:
      Widely deployed.  Most current caching proxy implementations
      support ICP in some form.

   Submitter:
      Document editors.

   See also:
      "Internet Cache Protocol Extension" [17] (work in progress)

7.1.2 Hyper Text Caching Protocol

   Best known reference:
      RFC 2756 Hyper Text  Caching Protocol (HTCP/0.0) [9]

   Description:
      HTCP is a protocol for discovering HTTP caching proxies and cached
      data, managing sets of HTTP caching proxies, and monitoring cache
      activity.

      HTCP requests include HTTP header material, while ICPv2 does not,
      enabling HTCP replies to more accurately describe the behaviour
      that would occur as a result of a subsequent HTTP request for the
      same resource.




Cooper, et al.               Informational                     [Page 20]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Security:
      Optionally uses HMAC-MD5 [11] shared secret authentication.
      Protocol is subject to attack if authentication is not used.

   Deployment:
      HTCP is implemented in Squid and the "Web Gateway Interceptor".

   Submitter:
      Document editors.

7.1.3 Cache Digest

      Best known references:

      *  "Cache Digest Specification - version 5" [21]

      *  "Summary Cache: A Scalable Wide-Area Web Cache Sharing
         Protocol" [10] (see note)

   Description:
      Cache Digests are a response to the problems of latency and
      congestion associated with previous inter-cache communication
      mechanisms such as the Internet Cache Protocol (ICP) [2] and the
      Hyper Text Cache Protocol [9].  Unlike these protocols, Cache
      Digests support peering between caching proxies and cache servers
      without a request-response exchange taking place for each inbound
      request.  Instead, a summary of the contents in cache (the Digest)
      is fetched by other systems that peer with it.  Using Cache
      Digests it is possible to determine with a relatively high degree
      of accuracy whether a given resource is cached by a particular
      system.

      Cache Digests are both an exchange protocol and a data format.

      Security:
      If the contents of a Digest are sensitive, they should be
      protected.  Any methods which would normally be applied to secure
      an HTTP connection can be applied to Cache Digests.

      A 'Trojan horse' attack is currently possible in a mesh: System A
      A can build a fake peer Digest for system B and serve it to B's
      peers if requested.  This way A can direct traffic toward/from B.
      The impact of this problem is minimized by the 'pull' model of
      transferring Cache Digests from one system to another.







Cooper, et al.               Informational                     [Page 21]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      Cache Digests provide knowledge about peer cache content on a URL
      level.  Hence, they do not dictate a particular level of policy
      management and can be used to implement various policies on any
      level (user, organization, etc.).

   Deployment:
      Cache Digests are supported in Squid.

      Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic
      networks

   Submitter:
      Alex Rousskov for [21], Pei Cao for [10].

   Note: The technology of Summary Cache [10] is patent pending by the
   University of Wisconsin-Madison.

7.1.4 Cache Pre-filling

   Best known reference:
      "Pre-filling a cache - A satellite overview" [20] (work in
      progress)

   Description:
      Cache pre-filling is a push-caching implementation.  It is
      particularly well adapted to IP-multicast networks because it
      allows preselected resources to be simultaneously inserted into
      caches within the targeted multicast group.  Different
      implementations of cache pre-filling already exist, especially in
      satellite contexts.  However, there is still no standard for this
      kind of push-caching and vendors propose solutions either based on
      dedicated equipment or public domain caches extended with a pre-
      filling module.

   Security:
      Relies on the inter-cache protocols being employed.

   Deployment:
      Observed in two commercial content distribution service providers.

   Submitter:
      Ivan Lovric

7.2 Tightly Coupled Inter-Cache Communication

7.2.1 Cache Array Routing Protocol (CARP) v1.0

   Also see Section 6.3



Cooper, et al.               Informational                     [Page 22]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Best known references:

      *  "Cache Array Routing Protocol" [14] (work in progress)

      *  "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]

      *  "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
         [16]

   Description:
      CARP is a hashing function for dividing URL-space among a cluster
      of proxies.  Included in CARP is the definition of a Proxy Array
      Membership Table, and ways to download this information.

      A user agent which implements CARP v1.0 can allocate and
      intelligently route requests for the URLs to any member of the
      Proxy Array.  Due to the resulting sorting of requests through
      these proxies, duplication of cache contents is eliminated and
      global cache hit rates may be improved.

   Security:
      Security considerations are not covered in the specification works
      in progress.

   Deployment:
      Implemented in caching proxy servers.  More than two independent
      implementations.

   Submitter:
      Document editors.

8. Network Element Communication

   This section describes the cooperation and communication between
   proxies and network elements.  Examples of such network elements
   include routers and switches.  Generally used for deploying
   interception proxies and/or diffused arrays.

8.1 Web Cache Control Protocol (WCCP)

   Best known references:
      "Web Cache Control Protocol" [18][19] (work in progress)

      Note: The name used for this protocol varies, sometimes referred
      to as the "Web Cache Coordination Protocol", but frequently just
      "WCCP" to avoid confusion





Cooper, et al.               Informational                     [Page 23]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Description:
      WCCP V1 runs between a router functioning as a redirecting network
      element and out-of-path interception proxies.  The protocol allows
      one or more proxies to register with a single router to receive
      redirected traffic.  It also allows one of the proxies, the
      designated proxy, to dictate to the router how redirected traffic
      is distributed across the array.

      WCCP V2 additionally runs between multiple routers and the
      proxies.

   Security:
      WCCP V1 has no security features.
      WCCP V2 provides optional authentication of protocol packets.

   Deployment:
      Network elements: WCCP is deployed on a wide range of Cisco
      routers.
      Caching proxies: WCCP is deployed on a number of vendors' caching
      proxies.

   Submitter:
      David Forster
      Document editors.

8.2 Network Element Control Protocol (NECP)

   Best known reference:
      "NECP: The Network Element Control Protocol" [22] (work in
      progress)

   Description:
      NECP provides methods for network elements to learn about server
      capabilities, availability, and hints as to which flows can and
      cannot be serviced.  This allows network elements to perform load
      balancing across a farm of servers, redirection to interception
      proxies, and cut-through of flows that cannot be served by the
      farm.

   Security:
      Optionally uses HMAC-SHA-1 [11] shared secret authentication along
      with complex sequence numbers to provide moderately strong
      security.  Protocol is subject to attack if authentication is not
      used.

   Deployment:
      Unknown at present; several network element and caching proxy
      vendors have expressed intent to implement the protocol.



Cooper, et al.               Informational                     [Page 24]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Submitter:
      Gary Tomlinson

8.3 SOCKS

   Best known reference:
      RFC 1928 SOCKS Protocol Version 5 [7]

   Description:
      SOCKS is primarily used as a caching proxy to firewall protocol.
      Although firewalls don't conform to the narrowly defined network
      element definition above, they are a integral part of the network
      infrastructure.  When used in conjunction with a firewall, SOCKS
      provides a authenticated tunnel between the caching proxy and the
      firewall.

   Security:
      An extensive framework provides for multiple authentication
      methods.  Currently, SSL, CHAP, DES, 3DES are known to be
      available.

   Deployment:
      SOCKS is widely deployed in the Internet.

   Submitter:
      Document editors.

9. Security Considerations

   This document provides a taxonomy for web caching and replication.
   Recommended practice, architecture and protocols are not described in
   detail.

   By definition, replication and caching involve the copying of
   resources.  There are legal implications of making and keeping
   transient or permanent copies; these are not covered here.

   Information on security of each protocol referred to by this memo is
   provided in the preceding sections, and in their accompanying
   documentation.  HTTP security is discussed in section 15 of RFC 2616
   [1], the HTTP/1.1 specification, and to a lesser extent in RFC 1945
   [6], the HTTP/1.0 specification.  RFC 2616 contains security
   considerations for HTTP proxies.








Cooper, et al.               Informational                     [Page 25]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Caching proxies have the same security issues as other application
   level proxies.  Application level proxies are not covered in these
   security considerations.  IP number based authentication is
   problematic when a proxy is involved in the communications.  Details
   are not discussed here.

9.1 Authentication

   Requests for web resources, and responses to such requests, may be
   directed to replicas and/or may flow through intermediate proxies.
   The integrity of communication needs to be preserved to ensure
   protection from both loss of access and from unintended change.

9.1.1 Man in the middle attacks

   HTTP proxies are men-in-the-middle, the perfect place for a man-in-
   the-middle-attack.  A discussion of this is found in section 15 of
   RFC 2616 [1].

9.1.2 Trusted third party

   A proxy must either be trusted to act on behalf of the origin server
   and/or client, or it must act as a tunnel.  When presenting cached
   objects to clients, the clients need to trust the caching proxy to
   act on behalf on the origin server.

   A replica may get accreditation from the origin server.

9.1.3 Authentication based on IP number

   Authentication based on the client's IP number is problematic when
   connecting through a proxy, since the authenticating device only has
   access to the proxy's IP number.  One (problematic) solution to this
   is for the proxy to spoof the client's IP number for inbound
   requests.

   Authentication based on IP number assumes that the end-to-end
   properties of the Internet are preserved.  This is typically not the
   case for environments containing interception proxies.

9.2 Privacy

9.2.1 Trusted third party

   When using a replication service, one must trust both the replica
   origin server and the replica selection system.





Cooper, et al.               Informational                     [Page 26]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Redirection of traffic - either by automated replica selection
   methods, or within proxies - may introduce third parties the end user
   and/or origin server must to trust.  In the case of interception
   proxies, such third parties are often unknown to both end points of
   the communication.  Unknown third parties may have security
   implications.

   Both proxies and replica selection services may have access to
   aggregated access information.  A proxy typically knows about
   accesses by each client using it, information that is more sensitive
   than the information held by a single origin server.

9.2.2 Logs and legal implications

   Logs from proxies should be kept secure, since they provide
   information about users and their patterns of behaviour.  A proxy's
   log is even more sensitive than a web server log, as every request
   from the user population goes through the proxy.  Logs from replica
   origin servers may need to be amalgamated to get aggregated
   statistics from a service, and transporting logs across borders may
   have legal implications.  Log handling is restricted by law in some
   countries.

   Requirements for object security and privacy are the same in a web
   replication and caching system as it is in the Internet at large. The
   only reliable solution is strong cryptography.  End-to-end encryption
   frequently makes resources uncacheable, as in the case of SSL
   encrypted web sessions.

9.3 Service security

9.3.1 Denial of service

   Any redirection of traffic is susceptible to denial of service
   attacks at the redirect point, and both proxies and replica selection
   services may redirect traffic.

   By attacking a proxy, access to all servers may be denied for a large
   set of clients.

   It has been argued that introduction of an interception proxy is a
   denial of service attack, since the end-to-end nature of the Internet
   is destroyed without the content consumer's knowledge.

9.3.2 Replay attack

   A caching proxy is by definition a replay attack.




Cooper, et al.               Informational                     [Page 27]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


9.3.3 Stupid configuration of proxies

   It is quite easy to have a stupid configuration which will harm
   service for content consumers.  This is the most common security
   problem with proxies.

9.3.4 Copyrighted transient copies

   The legislative forces of the world are considering the question of
   transient copies, like those kept in replication and caching system,
   being legal.  The legal implications of replication and caching are
   subject to local law.

   Caching proxies need to preserve the protocol output, including
   headers.  Replication services need to preserve the source of the
   objects.

9.3.5 Application level access

   Caching proxies are application level components in the traffic flow
   path, and may give intruders access to information that was
   previously only available at the network level in a proxy-free world.
   Some network level equipment may have required physical access to get
   sensitive information.  Introduction of application level components
   may require additional system security.

10. Acknowledgements

   The editors would like to thank the following for their assistance:
   David Forster, Alex Rousskov, Josh Cohen, John Martin, John Dilley,
   Ivan Lovric, Joe Touch, Henrik Nordstrom, Patrick McManus, Duane
   Wessels, Wojtek Sylwestrzak, Ted Hardie, Misha Rabinovich, Larry
   Masinter, Keith Moore, Roy Fielding, Patrik Faltstrom, Hilarie Orman,
   Mark Nottingham and Oskar Batuner.

References

   [1]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [2]   Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
         Version 2", RFC 2186, September 1997.

   [3]   Wessels, D. and K. Claffy, "Application of Internet Cache
         Protocol (ICP), Version 2", RFC 2187, September 1997.





Cooper, et al.               Informational                     [Page 28]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   [4]   Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
         9, RFC 959, October 1985.

   [5]   Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
         D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436,
         March 1993.

   [6]   Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [7]   Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
         Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.

   [8]   Brisco, T., "DNS Support for Load Balancing", RFC 1794, April
         1995.

   [9]   Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
         (HTCP/0.0)", RFC 2756, January 2000.

   [10]  Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A
         Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of
         ACM SIGCOMM'98 pp. 254-265, September 1998.

   [11]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [12]  Netscape, Inc., "Navigator Proxy Auto-Config File Format",
         March 1996,
         <URL:http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-
         live.html>.

   [13]  Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web
         Proxy Auto-Discovery Protocol", Work in Progress.

   [14]  Valloppillil, V. and K. Ross, "Cache Array Routing Protocol",
         Work in Progress.

   [15]  Microsoft Corporation, "Cache Array Routing Protocol (CARP)
         v1.0 Specifications, Technical Whitepaper", August 1999,
         <URL:http://www.microsoft.com/Proxy/Guide/carpspec.asp>.

   [16]  Microsoft Corporation, "Cache Array Routing Protocol and
         Microsoft Proxy Server 2.0, Technical White Paper", August
         1998,
         <URL:http://www.microsoft.com/proxy/documents/CarpWP.exe>.

   [17]  Lovric, I., "Internet Cache Protocol Extension", Work in
         Progress.



Cooper, et al.               Informational                     [Page 29]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   [18]  Cieslak, M. and D. Forster, "Cisco Web Cache Coordination
         Protocol V1.0", Work in Progress.

   [19]  Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web
         Cache Coordination Protocol V2.0", Work in Progress.

   [20]  Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a
         cache - A satellite overview", Work in Progress.

   [21]  Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest
         specification - version 5", December 1998,
         <URL:http://www.squid-cache.org/CacheDigest/cache-digest-
         v5.txt>.

   [22]  Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig,
         P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson,
         "NECP: The Network Element Control Protocol", Work in Progress.

   [23]  Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems",
         Work in Progress.































Cooper, et al.               Informational                     [Page 30]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


Authors' Addresses

   Ian Cooper
   Equinix, Inc.
   2450 Bayshore Parkway
   Mountain View, CA  94043
   USA

   Phone: +1 650 316 6065
   EMail: icooper@equinix.com


   Ingrid Melve
   UNINETT
   Tempeveien 22
   Trondheim  N-7465
   Norway

   Phone: +47 73 55 79 07
   EMail: Ingrid.Melve@uninett.no


   Gary Tomlinson
   CacheFlow Inc.
   12034 134th Ct. NE, Suite 201
   Redmond, WA  98052
   USA

   Phone: +1 425 820 3009
   EMail: gary.tomlinson@cacheflow.com





















Cooper, et al.               Informational                     [Page 31]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Cooper, et al.               Informational                     [Page 32]