File: rfc3234.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 (1515 lines) | stat: -rw-r--r-- 62,329 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






Network Working Group                                       B. Carpenter
Request for Comments: 3234                IBM Zurich Research Laboratory
Category: Informational                                          S. Brim
                                                           February 2002


                    Middleboxes: Taxonomy and Issues

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 (2002).  All Rights Reserved.

Abstract

   This document is intended as part of an IETF discussion about
   "middleboxes" - defined as any intermediary box performing functions
   apart from normal, standard functions of an IP router on the data
   path between a source host and destination host.  This document
   establishes a catalogue or taxonomy of middleboxes, cites previous
   and current IETF work concerning middleboxes, and attempts to
   identify some preliminary conclusions.  It does not, however, claim
   to be definitive.























Carpenter & Brim             Informational                      [Page 1]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


Table of Contents

   1. Introduction and Goals.........................................  3
   1.1. Terminology..................................................  3
   1.2. The Hourglass Model, Past and Future.........................  3
   1.4. Goals of this Document.......................................  4
   2. A catalogue of middleboxes.....................................  5
   2.1 NAT...........................................................  6
   2.2 NAT-PT........................................................  7
   2.3 SOCKS gateway.................................................  7
   2.4 IP Tunnel Endpoints...........................................  8
   2.5. Packet classifiers, markers and schedulers...................  8
   2.6 Transport relay...............................................  9
   2.7. TCP performance enhancing proxies............................ 10
   2.8. Load balancers that divert/munge packets..................... 10
   2.9. IP Firewalls................................................. 11
   2.10. Application Firewalls....................................... 11
   2.11. Application-level gateways.................................. 12
   2.12. Gatekeepers/ session control boxes.......................... 12
   2.13. Transcoders................................................. 12
   2.14. Proxies..................................................... 13
   2.15. Caches...................................................... 14
   2.16. Modified DNS servers........................................ 14
   2.17. Content and applications distribution boxes................. 15
   2.18. Load balancers that divert/munge URLs....................... 16
   2.19. Application-level interceptors.............................. 16
   2.20. Application-level multicast................................. 16
   2.21. Involuntary packet redirection.............................. 16
   2.22. Anonymisers................................................. 17
   2.23. Not included................................................ 17
   2.24. Summary of facets........................................... 17
   3. Ongoing work in the IETF and elsewhere......................... 18
   4. Comments and Issues............................................ 19
   4.1. The end to end principle under challenge..................... 19
   4.2. Failure handling............................................. 20
   4.3. Failures at multiple layers.................................. 21
   4.4. Multihop application protocols............................... 21
   4.5. Common features.............................................. 22
   5. Security Considerations........................................ 22
   6. Acknowledgements............................................... 23
   7. References..................................................... 23
   Authors' Addresses................................................ 26
   Acknowledgement................................................... 26
   Full Copyright Statement.......................................... 27







Carpenter & Brim             Informational                      [Page 2]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


1. Introduction and Goals

1.1. Terminology

   The phrase "middlebox" was coined by Lixia Zhang as a graphic
   description of a recent phenomenon in the Internet.  A middlebox is
   defined as any intermediary device performing functions other than
   the normal, standard functions of an IP router on the datagram path
   between a source host and destination host.

   In some discussions, especially those concentrating on HTTP traffic,
   the word "intermediary" is used.  For the present document, we prefer
   the more graphic phrase.  Of course, a middlebox can be virtual,
   i.e., an embedded function of some other box.  It should not be
   interpreted as necessarily referring to a separate physical box.  It
   may be a device that terminates one IP packet flow and originates
   another, or a device that transforms or diverts an IP packet flow in
   some way, or a combination.  In any case it is never the ultimate
   end-system of an applications session.

   Normal, standard IP routing functions (i.e., the route discovery and
   selection functions described in [RFC 1812], and their equivalent for
   IPv6) are not considered to be middlebox functions; a standard IP
   router is essentially transparent to IP packets.  Other functions
   taking place within the IP layer may be considered to be middlebox
   functions, but functions below the IP layer are excluded from the
   definition.

   There is some discrepancy in the way the word "routing" is used in
   the community.  Some people use it in the narrow, traditional sense
   of path selection based on IP address, i.e., the decision-making
   action of an IP router.  Others use it in the sense of higher layer
   decision-making (based perhaps on a URL or other applications layer
   string).  In either case it implies a choice of outbound direction,
   not the mere forwarding of a packet in the only direction available.
   In this document, the traditional sense is always qualified as "IP
   routing."

1.2. The Hourglass Model, Past and Future

   The classical description of the Internet architecture is based
   around the hourglass model [HOURG] and the end-to-end principle
   [Clark88, Saltzer].  The hourglass model depicts the protocol
   architecture as a narrow-necked hourglass, with all upper layers
   riding over a single IP protocol, which itself rides over a variety
   of hardware layers.





Carpenter & Brim             Informational                      [Page 3]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   The end-to-end principle asserts that some functions (such as
   security and reliability) can only be implemented completely and
   correctly end-to-end, with the help of the end points.  The end-to-
   end principle notes that providing an incomplete version of such
   functions in the network itself can sometimes be useful as a
   performance enhancement, but not as a substitute for the end-to-end
   implementation of the function.  The references above, and [RFC
   1958], go into more detail.

   In this architecture, the only boxes in the neck of the hourglass are
   IP routers, and their only function is to determine routes and
   forward packets (while also updating fields necessary for the
   forwarding process).  This is why they are not classed as
   middleboxes.

   Today, we observe deviations from this model, caused by the insertion
   in the network of numerous middleboxes performing functions other
   than IP forwarding.  Viewed in one way, these boxes are a challenge
   to the transparency of the network layer [RFC 2775].  Viewed another
   way, they are a challenge to the hourglass model: although the IP
   layer does not go away, middleboxes dilute its significance as the
   single necessary feature of all communications sessions.  Instead of
   concentrating diversity and function at the end systems, they spread
   diversity and function throughout the network.

   This is a matter of concern for several reasons:

   *  New middleboxes challenge old protocols.  Protocols designed
      without consideration of middleboxes may fail, predictably or
      unpredictably, in the presence of middleboxes.

   *  Middleboxes introduce new failure modes; rerouting of IP packets
      around crashed routers is no longer the only case to consider.
      The fate of sessions involving crashed middleboxes must also be
      considered.

   *  Configuration is no longer limited to the two ends of a session;
      middleboxes may also require configuration and management.

   *  Diagnosis of failures and misconfigurations is more complex.

1.4. Goals of this Document

   The principle goal of this document is to describe and analyse the
   current impact of middleboxes on the architecture of the Internet and
   its applications.  From this, we attempt to identify some general
   conclusions.




Carpenter & Brim             Informational                      [Page 4]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   Goals that might follow on from this work are:

   *  to identify harmful and harmless practices,

   *  to suggest architectural guidelines for application protocol and
      middlebox design,

   *  to identify requirements and dependencies for common functions in
      the middlebox environment,

   *  to derive a system design for standardisation of these functions,

   *  to identify additional work that should be done in the IETF and
      IRTF.

   An implied goal is to identify any necessary updates to the
   Architectural Principles of the Internet [RFC 1958].

   The document initially establishes a catalogue of middleboxes, and
   cites previous or current IETF work concerning middleboxes, before
   proceeding to discussion and conclusions.

2. A catalogue of middleboxes

   The core of this document is a catalogue of a number of types of
   middlebox.  There is no obvious way of classifying them to form a
   hierarchy or other simple form of taxonomy.  Middleboxes have a
   number of facets that might be used to classify them in a
   multidimensional taxonomy.

   DISCLAIMER: These facets, many of distinctions between different
   types of middlebox, and the decision to include or exclude a
   particular type of device, are to some extent subjective.  Not
   everyone who commented on drafts of this document agrees with our
   classifications and descriptions.  We do not claim that the following
   catalogue is mathematically complete and consistent, and in some
   cases purely arbitrary choices have been made, or ambiguity remains.
   Thus, this document makes no claim to be definitive.

   The facets considered are:

   1. Protocol layer.  Does the box act at the IP layer, the transport
      layer, the upper layers, or a mixture?

   2. Explicit versus implicit.  Is the middlebox function an explicit
      design feature of the protocol(s) in use, like an SMTP relay? Or
      is it an add-on not foreseen by the protocol design, probably
      attempting to be invisible, like a network address translator?



Carpenter & Brim             Informational                      [Page 5]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   3. Single hop versus multi-hop.  Can there be only one box in the
      path, or can there be several?

   4. In-line versus call-out.  The middlebox function may be executed
      in-line on the datapath, or it may involve a call-out to an
      ancillary box.

   5. Functional versus optimising.  Does the box perform a function
      without which the application session cannot run, or is the
      function only an optimisation?

   6. Routing versus processing.  Does the box simply choose which way
      to send the packets of a session, or does it actually process them
      in some way (i.e., change them or create a side-effect)?

   7. Soft state versus hard state.  If the box loses its state
      information, does the session continue to run in a degraded mode
      while reconstructing necessary state (soft state), or does it
      simply fail (hard state)?

   8. Failover versus restart.  In the event that a hard state box
      fails, is the session redirected to an alternative box that has a
      copy of the state information, or is it forced to abort and
      restart?

   One possible classification is deliberately excluded: "good" versus
   "evil".  While analysis shows that some types of middlebox come with
   a host of complications and disadvantages, no useful purpose would be
   served by simply deprecating them.  They have been invented for
   compelling reasons, and it is instructive to understand those
   reasons.

   The types of box listed below are in an arbitrary order, although
   adjacent entries may have some affinity.  At the end of each entry is
   an attempt to characterise it in terms of the facets identified
   above.  These characterisations should not be interpreted as rigid;
   in many cases they are a gross simplification.

   Note: many types of middlebox may need to perform IP packet
   fragmentation and re-assembly.  This is mentioned only in certain
   cases.

2.1 NAT

   Network Address Translator.  A function, often built into a router,
   that dynamically assigns a globally unique address to a host that
   doesn't have one, without that host's knowledge.  As a result, the
   appropriate address field in all packets to and from that host is



Carpenter & Brim             Informational                      [Page 6]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   translated on the fly.  Because NAT is incompatible with application
   protocols with IP address dependencies, a NAT is in practice always
   accompanied by an ALG (Application Level Gateway - see below).  It
   also touches the transport layer to the extent of fixing up
   checksums.

   NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993,
   RFC 3022, RFC 3027, etc.]

   The experimental RSIP proposal complements NAT with a dynamic tunnel
   mechanism inserting a stateful RSIP server in place of the NAT
   [RSIP].

   {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
   processing, 7 hard, 8 restart}

2.2 NAT-PT

   NAT with Protocol Translator.  A function, normally built into a
   router, that performs NAT between an IPv6 host and an IPv4 network,
   additionally translating the entire IP header between IPv6 and IPv4
   formats.

   NAT-PT itself depends on the Stateless IP/ICMP Translation Algorithm
   (SIIT) mechanism [RFC 2765] for its protocol translation function.
   In practice, SIIT and NAT-PT will both need an associated ALG and
   will need to touch transport checksums.  Due to the permitted absence
   of a UDP checksum in IPv4, translation of fragmented unchecksummed
   UDP from IPv4 to IPv6 is hopeless.  NAT-PT and SIIT also have other
   potential fragmentation/MTU problems, particularly when dealing with
   endpoints that don't do path MTU discovery (or when transiting other
   middleboxes that break path MTU discovery).  ICMP translation also
   has some intractable difficulties.

   NAT-PT is a Proposed Standard from the NGTRANS WG [RFC 2766].  The
   Dual Stack Transition Mechanism adds a second related middlebox, the
   DSTM server [DSTM].

   {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
   processing, 7 hard, 8 restart}

2.3 SOCKS gateway

   SOCKSv5 [RFC 1928] is a stateful mechanism for authenticated firewall
   traversal, in which the client host must communicate first with the
   SOCKS server in the firewall before it is able to traverse the
   firewall.  It is the SOCKS server, not the client, that determines
   the source IP address and port number used outside the firewall.  The



Carpenter & Brim             Informational                      [Page 7]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   client's stack must be "SOCKSified" to take account of this, and
   address-sensitive applications may get confused, rather as with NAT.
   However, SOCKS gateways do not require ALGs.

   SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.

   {1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6
   routing, 7 hard, 8 restart}

2.4 IP Tunnel Endpoints

   Tunnel endpoints, including virtual private network endpoints, use
   basic IP services to set up tunnels with their peer tunnel endpoints
   which might be anywhere in the Internet.  Tunnels create entirely new
   "virtual" networks and network interfaces based on the Internet
   infrastructure, and thereby open up a number of new services.  Tunnel
   endpoints base their forwarding decisions at least partly on their
   own policies, and only partly if at all on information visible to
   surrounding routers.

   To the extent that they deliver packets intact to their destinations,
   tunnel endpoints appear to follow the end-to-end principle in the
   outer Internet.  However, the destination may be completely different
   from what a router near the tunnel entrance might expect.  Also, the
   per-hop treatment a tunneled packet receives, for example in terms of
   QoS, may not be what it would have received had the packet traveled
   untunneled [RFC2983].

   Tunnels also cause difficulties with MTU size (they reduce it) and
   with ICMP replies (they may lack necessary diagnostic information).

   When a tunnel fails for some reason, this may cause the user session
   to abort, or an alternative IP route may prove to be available, or in
   some cases the tunnel may be re-established automatically.

   {1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
   processing, 7 hard, 8 restart or failover}

2.5. Packet classifiers, markers and schedulers

   Packet classifiers classify packets flowing through them according to
   policy and either select them for special treatment or mark them, in
   particular for differentiated services [Clark95, RFC 2475].  They may
   alter the sequence of packet flow through subsequent hops, since they
   control the behaviour of traffic conditioners.






Carpenter & Brim             Informational                      [Page 8]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   Schedulers or traffic conditioners (in routers, hosts, or specialist
   boxes inserted in the data path) may alter the time sequence of
   packet flow, the order in which packets are sent, and which packets
   are dropped.  This can significantly impact end-to-end performance.
   It does not, however, fundamentally change the unreliable datagram
   model of the Internet.

   When a classifier or traffic conditioner fails, the user session may
   see any result between complete loss of connectivity (all packets are
   dropped), through best-effort service (all packets are given default
   QOS), up to automatic restoration of the original service level.

   {1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6
   processing, 7 soft, 8 failover or restart}

2.6 Transport relay

   Transport relays are basically the transport layer equivalent of an
   ALG; another (less common) name for them is a TLG.  As with ALGs,
   they're used for a variety of purposes, some well established and
   meeting needs not otherwise met.  Early examples of transport relays
   were those that ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET
   and allowed Chaosnet-only hosts to make outgoing connections from
   Chaosnet onto TCP/IP.  Later there were some uses of TCP-TP4 relays.
   A transport relay between IPv6-only and IPv4-only hosts is one of the
   tools of IPv6 transition [TRANS64].  TLGs are sometimes used in
   combination with simple packet filtering firewalls to enforce
   restrictions on which hosts can talk to the outside world or to
   kludge around strange IP routing configurations.  TLGs are also
   sometimes used to gateway between two instances of the same transport
   protocol with significantly different connection characteristics; it
   is in this sense that a TLG may also be called a TCP or transport
   spoofer.  In this role, the TLG may shade into being an optimising
   rather than a functional middlebox, but it is distinguished from
   Transport Proxies (next section) by the fact that it makes its
   optimisations only by creating back-to- back connections, and not by
   modification or re-timing of TCP messages.

   Terminating one TCP connection and starting another mid-path means
   that the TCP checksum does not cover the sender's data end-to-end.
   Data corruptions or modifications may be introduced in the processing
   when the data is transferred from the first to the second connection.
   Some TCP relays are split relays and have even more possibility of
   lost data integrity, because the there may be more than two TCP
   connections, and multiple nodes and network paths involved.  In all
   cases, the sender has less than the expected assurance of data
   integrity that is the TCP reliable byte stream service.  Note that




Carpenter & Brim             Informational                      [Page 9]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   this problem is not unique to middleboxes, but can also be caused by
   checksum offloading TCP implementations within the sender, for
   example.

   In some such cases, other session layer mechanisms such as SSH or
   HTTPS would detect any loss of data integrity at the TCP level,
   leading not to retransmission as with TCP, but to session failure.
   However, there is no general session mechanism to add application
   data integrity so one can detect or mitigate possible lack of TCP
   data integrity.

   {1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 functional
   (mainly), 6 routing, 7 hard, 8 restart}

2.7. TCP performance enhancing proxies

   "TCP spoofer" is often used as a term for middleboxes that modify the
   timing or action of the TCP protocol in flight for the purposes of
   enhancing performance.  Another, more accurate name is TCP
   performance enhancing proxy (PEP).  Many TCP PEPs are proprietary and
   have been characterised in the open Internet primarily when they
   introduce interoperability errors with standard TCP.  As with TLGs,
   there are circumstances in which a TCP PEP is seen to meet needs not
   otherwise met.  For example, a TCP PEP may provide re-spacing of ACKs
   that have been bunched together by a link with bursty service, thus
   avoiding undesireable data segment bursts.  The PILC (Performance
   Implications of Link Characteristics) working group has analyzed
   types of TCP PEPs and their applicability [PILCPEP].  TCP PEPs can
   introduce not only TCP errors, but also unintended changes in TCP
   adaptive behavior.

   {1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising,
   6 routing, 7 hard, 8 restart}

2.8. Load balancers that divert/munge packets.

   There is a variety of techniques that divert packets from their
   intended IP destination, or make that destination ambiguous.  The
   motivation is typically to balance load across servers, or even to
   split applications across servers by IP routing based on the
   destination port number.  Except for rare instances of one-shot UDP
   protocols, these techniques are inevitably stateful as all packets
   from the same application session need to be directed to the same
   physical server.  (However, a sophisticated solution would also be
   able to handle failover.)

   To date these techniques are proprietary and can therefore only be
   applied in closely managed environments.



Carpenter & Brim             Informational                     [Page 10]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   {1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6
   routing, 7 hard, 8 restart}

2.9. IP Firewalls

   The simplest form of firewall is a router that screens and rejects
   packets based purely on fields in the IP and Transport headers (e.g.,
   disallow incoming traffic to certain port numbers, disallow any
   traffic to certain subnets, etc.)

   Although firewalls have not been the subject of standardisation, some
   analysis has been done [RFC 2979].

   Although a pure IP firewall does not alter the packets flowing
   through it, by rejecting some of them it may cause connectivity
   problems that are very hard for a user to understand and diagnose.

   "Stateless" firewalls typically allow all IP fragments through since
   they do not contain enough upper-layer header information to make a
   filtering decision.  Many "stateful" firewalls therefore reassemble
   IP fragments (and re-fragment if necessary) in order to avoid leaking
   fragments, particularly fragments that may exploit bugs in the
   reassembly implementations of end receivers.

   {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
   routing, 7 hard, 8 restart}

2.10. Application Firewalls

   Application-level firewalls act as a protocol end point and relay
   (e.g., an SMTP client/server or a Web proxy agent).  They may

      (1) implement a "safe" subset of the protocol,

      (2) perform extensive protocol validity checks,

      (3) use an implementation methodology designed to minimize the
          likelihood of bugs,

      (4) run in an insulated, "safe" environment, or

      (5) use some combination of these techniques in tandem.

   Although firewalls have not been the subject of standardisation, some
   analysis has been done [RFC 2979].  The issue of firewall traversal
   using HTTP has been discussed [HTTPSUB].





Carpenter & Brim             Informational                     [Page 11]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   {1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5
   functional, 6 processing, 7 hard, 8 restart}

2.11. Application-level gateways

   These come in many shapes and forms.  NATs require ALGs for certain
   address-dependent protocols such as FTP; these do not change the
   semantics of the application protocol, but carry out mechanical
   substitution of fields.  At the other end of the scale, still using
   FTP as an example, gateways have been constructed between FTP and
   other file transfer protocols such as the OSI and DECnet (R)
   equivalents.  In any case, such gateways need to maintain state for
   the sessions they are handling, and if this state is lost, the
   session will normally break irrevocably.

   Some ALGs are also implemented in ways that create fragmentation
   problems, although in this case the problem is arguably the result of
   a deliberate layer violation (e.g., mucking with the application data
   stream of an FTP control connection by twiddling TCP segments on the
   fly).

   {1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line,
   5 functional, 6 processing, 7 hard, 8 restart}

2.12. Gatekeepers/ session control boxes

   Particularly with the rise of IP Telephony, the need to create and
   manage sessions other than TCP connections has arisen.  In a
   multimedia environment that has to deal with name lookup,
   authentication, authorization, accounting, firewall traversal, and
   sometimes media conversion, the establishment and control of a
   session by a third-party box seems to be the inevitable solution.
   Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and
   MEGACO controllers [RFC 3015].

   {1 Application layer, 2 explicit, 3 multihop, 4 in-line or call-out,
   5 functional, 6 processing, 7 hard, 8 restart?}

2.13. Transcoders

   Transcoders are boxes performing some type of on-the-fly conversion
   of application level data.  Examples include the transcoding of
   existing web pages for display on hand-held wireless devices, and
   transcoding between various audio formats for interconnecting digital
   mobile phones with voice-over-IP services.  In many cases, such
   transcoding cannot be done by the end-systems, and at least in the
   case of voice, it must be done in strict real time with extremely
   rapid failure recovery.



Carpenter & Brim             Informational                     [Page 12]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   Not all media translators are mandatory.  They may simply be an
   optimisation.  For example, in the case of multicast, if all the
   low-bandwidth receivers sit in one "corner" of the network, it would
   be inefficient for the sender to generate two streams or send both
   stream all the way across the network if the "thin" one is only
   needed far away from the sender.  Generally, media translators are
   only useful if the two end systems don't have overlapping codecs or
   if the overlapping set is not a good network match.

   {1 Application layer, 2 explicit or implicit, 3 single hop, 4 in-
   line, 5 functional, 6 processing, 7 hard?, 8 restart or failover}

2.14. Proxies

   HTTP1.1 [RFC 2616] defines a Web proxy as follows:

      "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."

   A Web proxy may be associated with a firewall, when the firewall does
   not allow outgoing HTTP packets.  However, HTTP makes the use of a
   proxy "voluntary": the client must be configured to use the proxy.

   Note that HTTP proxies do in fact terminate an IP packet flow and
   recreate another one, but they fall under the definition of
   "middlebox" given in Section 1.1 because the actual applications
   sessions traverse them.

   SIP proxies [RFC 2543] also raise some interesting issues, since they
   can "bend" the media pipe to also serve as media translators.  (A
   proxy can modify the session description so that media no longer
   travel end-to-end but to a designated intermediate box.)

   {1 Application layer, 2 explicit (HTTP) or implicit (interception), 3
   multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}.






Carpenter & Brim             Informational                     [Page 13]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   Note: Some so-called Web proxies have been implemented as
   "interception" devices that intercept HTTP packets and re-issue them
   with their own source address; like NAT and SOCKs, this can disturb
   address-sensitive applications.  Unfortunately some vendors have
   caused confusion by mis-describing these as "transparent" proxies.
   Interception devices are anything but transparent.  See [WREC] for a
   full discussion.

2.15. Caches

   Caches are of course used in many shapes and forms in the Internet,
   and are in principle distinct from proxies.  Here we refer mainly to
   content caches, intended to optimise user response times.  HTTP makes
   provision for proxies to act as caches, by providing for both
   expiration and re-validation mechanisms for cached content.  These
   mechanisms may be used to guarantee that specific content is not
   cached, which is a requirement for transient content, particularly in
   transactional applications.  HTTP caching is well described in
   Section 13 of [RFC 2616], and in the HTTP case caches and proxies are
   inextricably mixed.

   To improve optimisation, caching is not uniquely conducted between
   the origin server and the proxy cache directly serving the user.  If
   there is a network of caches, the nearest copy of the required
   content may be in a peer cache.  For this an inter-cache protocol is
   required.  At present the most widely deployed solution is Internet
   Cache Protocol (ICP) [RFC 2186] although there have been alternative
   proposals such as [RFC 2756].

   It can be argued that caches terminate the applications sessions, and
   should not be counted as middleboxes (any more than we count SMTP
   relays).  However, we have arbitrarily chosen to include them since
   they do in practice re-issue the client's HTTP request in the case of
   a cache miss, and they are not the ultimate source of the application
   data.

   {1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop,
   4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}

2.16. Modified DNS servers

   DNS servers can play games.  As long as they appear to deliver a
   syntactically correct response to every query, they can fiddle the
   semantics.  For example, names can be made into "anycast" names by
   arranging for them to resolve to different IP addresses in different
   parts of the network.  Or load can be shared among different members
   of a server farm by having the local DNS server return the address of




Carpenter & Brim             Informational                     [Page 14]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   different servers in turn.  In a NAT environment, it is not uncommon
   for the FQDN-to-address mapping to be quite different outside and
   inside the NAT ("two-faced DNS").

   Modified DNS servers are not intermediaries in the application data
   flow of interest.  They are included here because they mean that
   independent sessions that at one level appear to involve a single
   host actually involve multiple hosts, which can have subtle effects.
   State created in host A.FOR.EXAMPLE by one session may turn out not
   to be there when a second session apparently to the same host is
   started, because the DNS server has directed the second session
   elsewhere.

   If such a DNS server fails, users may fail over to an alternate DNS
   server that doesn't know the same tricks, with unpredicatble results.

   {1 Application layer, 2 implicit, 3 multihop, 4 in-line (on DNS query
   path), 5 functional or optimising, 6 processing, 7 soft, 8 failover}

2.17. Content and applications distribution boxes

   An emerging generalisation of caching is content distribution and
   application distribution.  In this model, content (such as static web
   content or streaming multimedia content) is replicated in advance to
   many widely distributed servers.  Further, interactive or even
   transactional applications may be remotely replicated, with some of
   their associated data.  Since this is a recent model, it cannot be
   said that there is an industry standard practice in this area.  Some
   of the issues are discussed in [WREC] and several new IETF activities
   have been proposed in this area.

   Content distribution solutions tend to play with URLs in one way or
   another, and often involve a system of middleboxes - for example
   using HTTP redirects to send a request for WWW.EXAMPLE.COM off to
   WWW.EXAMPLE.NET, where the latter name may be an "anycast" name as
   mentioned above, and will actually resolve in DNS to the nearest
   instance of a content distribution box.

   As with caches, it is an arbitrary choice to include these devices,
   on the grounds that although they terminate the client session, they
   are not the ultimate origin of the applications data.

   {1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line
   or call-out, 5 optimising, 6 routing or processing, 7 soft, 8
   restart?}






Carpenter & Brim             Informational                     [Page 15]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


2.18. Load balancers that divert/munge URLs

   Like DNS tricks, URL redirects can be used to balance load among a
   pool of servers - essentially a local version of a content
   distribution network.  Alternatively, an HTTP proxy can rewrite HTTP
   requests to direct them to a particular member of a pool of servers.

   These devices are included as middleboxes because they divert an
   applications session in an arbitrary way.

   {1 Application layer, 2 explicit, 3 single hop, 4 in-line, 5
   functional, 6 routing, 7 soft, 8 restart}

2.19. Application-level interceptors

   Some forms of pseudo-proxy intercept HTTP packets and deliver them to
   a local proxy server instead of forwarding them to the intended
   destination.  Thus the destination IP address in the packet is
   ignored.  It is hard to state whether this is a functional box (i.e.,
   a non-standard proxy) or an optimising box (i.e., a way of forcing
   the user to use a cache).  Like any non-standard proxy, it has
   undefined consequences in the case of dynamic or non-cacheable
   content.

   {1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5
   functional or optimising, 6 routing, 7 hard, 8 restart}

2.20. Application-level multicast

   Some (mainly proprietary) applications, including some approaches to
   instant messaging, use an application-level mechanism to replicate
   packets to multiple destinations.

   An example is given in [CHU].

   {1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5
   functional, 6 routing, 7 hard, 8 restart}

2.21. Involuntary packet redirection

   There appear to be a few instances of boxes that (based on
   application level content or other information above the network
   layer) redirect packets for functional reasons.  For example, more
   than one "high speed Internet" service offered in hotel rooms
   intercepts initial HTTP requests and diverts them to an HTTP server
   that demands payment before opening access to the Internet.  These
   boxes usually also perform NAT functions.




Carpenter & Brim             Informational                     [Page 16]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   {1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6
   routing, 7 hard, 8 restart}

2.22. Anonymisers

   Anonymiser boxes can be implemented in various ways that hide the IP
   address of the data sender or receiver.  Although the implementation
   may be distinct, this is in practice very similar to a NAT plus ALG.

   {1 multi-layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5
   functional, 6 processing, 7 hard, 8 restart}

2.23. Not included

   Some candidates suggested for the above list were excluded for the
   reasons given below.  In general, they do not fundamentally change
   the architectural model of packet delivery from source to
   destination.

   Bridges and switches that snoop ARP, IGMP etc.  These are below the
   IP layer, but use a layer violation to emulate network layer
   functions.  They do not change IP layer functions.

   Wiretaps and snoopers in general - if they are working correctly,
   they have no impact on traffic, so do not require analysis.

   Mobile IP home agents are intended to assist packet delivery to the
   originally desired destination, so they are excluded on the same
   grounds as standard routers.

   Relays in interplanetary networks - although these would certainly
   appear to be middleboxes, they are not currently deployed.

2.24. Summary of facets

   By tabulating the rough classifications above, we observe that of the
   22 classes of middlebox described:

   17 are application or multi-layer
   16 are implicit (and others are explicit OR implicit)
   17 are multi-hop
   21 are in-line; call-out is rare
   18 are functional; pure optimisation is rare
   Routing & processing are evenly split
   16 have hard state
   21 must restart session on failure





Carpenter & Brim             Informational                     [Page 17]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   We can deduce that current types of middlebox are predominantly
   application layer devices not designed as part of the relevant
   protocol, performing required functions, maintaining hard state, and
   aborting user sessions when they crash.  Indeed this represents a
   profound challenge to the end-to-end hourglass model.

3. Ongoing work in the IETF and elsewhere

   Apart from work cited in references above, current or planned work in
   the IETF includes:

   MIDCOM - a working group with focus on the architectural framework
   and the requirements for the protocol between a requesting device and
   a middlebox and the architectural framework for the interface between
   a middlebox and a policy entity [MIDFRAME, MIDARCH].  This may
   interact with session control issues [SIPFIRE].

   Work is also proceeding outside the MIDCOM group on middlebox
   discovery [MIDDISC].

   WEBI (Web Intermediaries) - a working group that addresses specific
   issues in the world wide web infrastructure (as identified by the
   WREC working group), by providing generic mechanisms which are useful
   in several application domains (e.g., proxies, content delivery
   surrogates).  Specific mechanisms will be Intermediary Discovery and
   Description and a Resource Update Protocol.

   Intermediaries are also an important focus in the development of XML
   Protocol by the World-Wide Web Consortium, who have published an
   interesting analysis [XMLPI].

   OPES (Open Pluggable Extension Services) - a proposed  working group
   whose output will enable construction of services executed on
   application data by participating transit intermediaries.  Caching is
   the most basic intermediary service, one that requires a basic
   understanding of application semantics by the cache server.

   CDI (Content Distribution Internetworking) is a potential working
   group for allowing cooperation between different Content Distribution
   Networks and cache clusters [CDNP].

   RSERPOOL (Reliable Server Pooling) is a working group that will
   define architecture and requirements for management and access to
   server pools, including requirements from a variety of applications,
   building blocks and interfaces, different styles of pooling, security
   requirements and performance requirements, such as failover times and
   coping with heterogeneous latencies.




Carpenter & Brim             Informational                     [Page 18]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


4. Comments and Issues

   A review of the list in Section 2 suggests that middleboxes fit into
   one or more of three broad categories:

   1) mechanisms to connect dissimilar networks to enable cross-protocol
      interoperability;

   2) mechanisms to separate similar networks into zones, especially
      security zones;

   3) performance enhancement.

   As observed in [RFC 2775], the rise of middleboxes puts into question
   the general applicability of the end-to-end principle [RFC 1958].
   Middleboxes introduce dependencies and hidden points of failure that
   violate the fate-sharing aspect of the end-to-end principle.  Can we
   define architectural principles that guarantee robustness in the
   presence of middleboxes?

4.1. The end to end principle under challenge

   Many forms of middlebox are explicitly addressed at the IP level, and
   terminate a transport connection (or act as a final destination for
   UDP packets) in a normal way.  Although they are potential single
   points of failure, they do not otherwise interfere with the end to
   end principle [RFC 1958].  (This statement does not apply to
   transport relays or TCP spoofers; they do not terminate a transport
   connection at the expected destination in the normal way.)

   However, there is a general feeling that middleboxes that divert an
   IP packet from its intended destination, or substantively modify its
   content on the fly, are fundamentally different from those that
   correctly terminate a transport connection and carry out their
   manipulations at applications level.  Such diversion or modification
   violates the basic architectural assumption that packets flow from
   source to destination essentially unchanged (except for time-to-live
   and QOS-related fields).  The effects of such changes on transport
   and applications is unpredictable in the general case.  Much of the
   analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to
   RSIP, NAT-PT, DSTM, SOCKS, and involuntary packet redirectors.
   Interception proxies, anonymisers, and some types of load balancer
   can also have subtle effects on address-sensitive applications, when
   they cause packets to be delivered to or from a different address.
   Transport relays and TCP spoofers may deceive applications by
   delivering an unreliable service on a TCP socket.





Carpenter & Brim             Informational                     [Page 19]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   We conclude that:

      Although the rise of middleboxes has negative impact on the end to
      end principle at the packet level, it does not nullify it as a
      useful or desirable principle of applications protocol design.
      However, future application protocols should be designed in
      recognition of the likely presence of network address translation,
      packet diversion, and packet level firewalls, along the data path.

4.2. Failure handling

   If a middlebox fails, it is desirable that the effect on sessions
   currently in progress should be inconvenient rather than
   catastrophic.  There appear to be three approaches to achieve this:

      Soft state mechanisms.  The session continues in the absence of
      the box, probably with reduced performance, until the necessary
      session state is recreated automatically in an alternative box (or
      the original one, restarted).  In other words the state
      information optimises the user session but is not essential.  An
      example might be a true caching mechanism, whose temporary failure
      only reduces performance.

      Rapid failover mechanisms.  The session is promptly redirected to
      a hot spare box, which already has a copy of the necessary session
      state.

      Rapid restart mechanisms.  The two ends of the session promptly
      detect the failure and themselves restart the session via a spare
      box, without being externally redirected.  Enough session state is
      kept at each end to recover from the glitch.

   It appears likely that "optimising" middleboxes are suitable
   candidates for the soft state approach and for non-real-time data
   streams, since the consequence of failure of the box is not
   catastrophic for the user.  (Configured HTTP proxies used as caches
   are an awkward case, as their failure causes client failure.)  On the
   other hand, "functional" middleboxes must be present for the session
   to continue, so they are candidates for rapid failover or rapid
   restart mechanisms.  We conclude that:

      Middlebox design should include a clear mechanism for dealing with
      failure.








Carpenter & Brim             Informational                     [Page 20]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


4.3. Failures at multiple layers

   Difficulties occur when middlebox functions occur at different
   layers, for example the following situation, where B and C are not in
   the same physical box:

      Apps layer:     A ------------------------> C ------> D

      Lower layer:    A -----> B -------------------------> D

   When all is well, i.e., there is an IP path from A to B to C to D and
   both B and C are working, this may appear quite workable.  But the
   failure modes are very challenging.  For example, if there is a
   network failure between C and D, how is B instructed to divert the
   session to a backup box for C?.  Since C and B function at different
   protocol layers, there is no expectation that they will have
   coordinated failure recovery mechanisms.  Unless this is remedied in
   some general way, we conclude that

      Middlebox failure recovery mechanisms cannot currently assume they
      will get any help from other layers, and must have their own means
      of dealing with failures in other layers.

      In the long term future, we should be able to state clearly for
      each middlebox function what it expects from its environment, and
      make recommendations about which middlebox functions should be
      bound together if deployed.

4.4. Multihop application protocols

   We can also observe that protocols such as SMTP, UUCP, and NNTP have
   always worked hop-by-hop, i.e., via multiple middleboxes.  Nobody
   considers this to be an issue or a problem.  Difficulties arise when
   inserting a middlebox in an application protocol stream that was not
   designed for it.  We conclude that:

      New application protocol designs should include explicit
      mechanisms for the insertion of middleboxes, and should consider
      the facets identified in Section 2 above as part of the design.

   A specific challenge is how to make interactive or real-time
   applications ride smoothly over middleboxes.  This will put
   particular stress on the failure handling aspects.








Carpenter & Brim             Informational                     [Page 21]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


4.5. Common features

   Given that the IP layer - the neck of the hourglass - is no longer
   alone in its role supporting end-to-end connectivity, it would be
   desirable to define requirements and features that are common to
   middlebox intermediaries.  It would then be possible to implement
   middleboxes, and in particular the protocols that communicate with
   them, fully from the stance of supporting the end-to-end principle.
   Conceptually, this would extend the neck of the hourglass upwards to
   include a set of common features available to all (or many)
   applications.  In the context of middleboxes and multihop protocols,
   this would require common features addressing at least:

      Middlebox discovery and monitoring
      Middlebox configuration and control
      Call-out
      Routing preferences
      Failover and restart handling
      Security, including mutual authentication

   As far as possible, the solutions in these areas being developed in
   the IETF and W3C should be sufficiently general to cover all types of
   middlebox; if not, the work will be done several times.

5. Security Considerations

   Security risks are specific to each type of middlebox, so little can
   be said in general.  Of course, adding extra boxes in the
   communication path creates extra points of attack, reduces or
   eliminates the ability to perform end to end encryption, and
   complicates trust models and key distribution models.  Thus, every
   middlebox design requires particular attention to security analysis.
   A few general points can be made:

   1. The interference with end-to-end packet transmission by many types
      of middlebox is a crippling impediment to generalised use of IPSEC
      in its present form, and also invalidates transport layer security
      in many scenarios.

   2. Middleboxes require us to move definitively from a two-way to an
      N-way approach to trust relationships and key sharing.

   3. The management and configuration mechanisms of middleboxes are a
      tempting point of attack, and must be strongly defended.

   These points suggest that we need a whole new approach to security
   solutions as the middlebox paradigm ends up being deployed in lots of
   different technologies, if only to avoid each new technology



Carpenter & Brim             Informational                     [Page 22]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   designing a end-to-end security solution appropriate to its
   particular impact on the data stream.

   Additionally, content caches and content distribution mechanisms
   raise the issue of access control for content that is subject to
   copyright or other rights.  Distributed authentication, authorisation
   and accounting are required.

6. Acknowledgements

   Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom,
   Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on
   early versions of this document.  Rob Austein and Allison Mankin
   drafted the text on transport relays and TCP spoofers, and Rob
   Austein made other substantial contributions.  Participants in the
   MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including
   Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker,
   Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen,
   Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave
   invaluable input.  Mark Nottingham brought the W3C work to our
   attention.  Melinda Shore suggested using a facet-based
   categorization.  Patrik Faltstrom inspired section 4.3.

7. References

   [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

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

   [RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

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

   [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
              and W. Weiss, "An Architecture for Differentiated
              Service", RFC 2475, December 1998.

   [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [RFC 2616] 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.



Carpenter & Brim             Informational                     [Page 23]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

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

   [RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February
              2000.

   [RFC 2979] Freed, N., "Behavior of and Requirements for Internet
              Firewalls", RFC 2979, October 2000.

   [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

   [RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
              and J. Segers, "Megaco Protocol 1.0", RFC 3015, November
              2000.

   [RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022, January
              2001.

   [RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027, January
              2001.

   [CHU]      Y. Chu, S. Rao, and H. Zhang, A Case for End System
              Multicast, SIGMETRICS, June 2000.
              http://citeseer.nj.nec.com/chu00case.html

   [CLARK88]  The Design Philosophy of the DARPA Internet Protocols,
              D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4,
              August 1988, pages 106-114 (reprinted in ACM CCR Vol 25,
              Number 1, January 1995, pages 102-111).

   [CLARK95]  "Adding Service Discrimination to the Internet", D.D.
              Clark, Proceedings of the 23rd Annual Telecommunications
              Policy Research Conference (TPRC), Solomons, MD, October
              1995.



Carpenter & Brim             Informational                     [Page 24]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   [CDNP]     M. Day, et al., "A Model for Content Internetworking
              (CDI)", Work in Progress.

   [DSTM]     J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A.
              Durand, "Dual Stack Transition Mechanism (DSTM)", Work in
              Progress.

   [H323]     ITU-T Recommendation H.323: "Packet Based Multimedia
              Communication Systems".

   [HOURG]    "Realizing the Information Future: The Internet and
              Beyond", Computer Science and Telecommunications Board,
              National Research Council, Washington, D.C., National
              Academy Press, 1994. However, the "hourglass" metaphor was
              first used by John Aschenbrenner in 1979, with reference
              to the ISO Open Systems Interconnection model.

   [HTTPSUB]  Moore, K., "On the use of HTTP as a Substrate", BCP 56,
              RFC 3205, February 2002.

   [MIDARCH]  E. Lear, "A Middlebox Architectural Framework", Work in
              Progress.

   [MIDDISC]  E. Lear, "Requirements for Discovering Middleboxes", Work
              in Progress.

   [MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
              Rayhan, "Middlebox Communication: Framework and
              Requirements", Work in Progress.

   [PILCPEP]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, June 2001.

   [RSIP]     Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
              "Realm Specific IP: Framework", RFC 3102, October 2001.

   [SALTZER]  End-To-End Arguments in System Design, J.H. Saltzer,
              D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November
              1984, pp 277-288.

   [SIPFIRE]  S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T.
              Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury,
              "Framework Draft for Networked Appliances Using the
              Session Initiation Protocol", Work in Progress.






Carpenter & Brim             Informational                     [Page 25]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


   [SOCKS6]   Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
              RFC 3089, April 2001.

   [TRANS64]  "Overview of Transition Techniques for IPv6-only to Talk
              to IPv4-only Communication", Work in Progress.

   [WREC]     Cooper, I, Melve, I. and G. Tomlinson, "Internet Web
              Replication and Caching Taxonomy", RFC 3040, January 2001.

   [XMLPI]    Intermediaries and XML Protocol, Mark Nottingham, Work in
              Progress at http://lists.w3.org/Archives/Public/xml-dist-
              app/2001Mar/0045.html

Authors' Addresses

   Brian E. Carpenter
   IBM Zurich Research Laboratory
   Saeumerstrasse 4 / Postfach
   8803 Rueschlikon
   Switzerland

   EMail: brian@hursley.ibm.com


   Scott W. Brim
   146 Honness Lane
   Ithaca, NY 14850
   USA

   EMail: sbrim@cisco.com





















Carpenter & Brim             Informational                     [Page 26]

RFC 3234            Middleboxes: Taxonomy and Issues       February 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Carpenter & Brim             Informational                     [Page 27]