aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/standard/rfc7068.txt
blob: 70fc24fab0022d4e5014bf593f5db2aa52f5c755 (plain) (blame)
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
Internet Engineering Task Force (IETF)                        E. McMurry
Request for Comments: 7068                                   B. Campbell
Category: Informational                                           Oracle
ISSN: 2070-1721                                            November 2013


                 Diameter Overload Control Requirements

Abstract

   When a Diameter server or agent becomes overloaded, it needs to be
   able to gracefully reduce its load, typically by advising clients to
   reduce traffic for some period of time.  Otherwise, it must continue
   to expend resources parsing and responding to Diameter messages,
   possibly resulting in a progressively severe overload condition.  The
   existing Diameter mechanisms are not sufficient for managing overload
   conditions.  This document describes the limitations of the existing
   mechanisms.  Requirements for new overload management mechanisms are
   also provided.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7068.
















McMurry & Campbell            Informational                     [Page 1]

RFC 7068         Diameter Overload Control Requirements    November 2013


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































McMurry & Campbell            Informational                     [Page 2]

RFC 7068         Diameter Overload Control Requirements    November 2013


Table of Contents

   1. Introduction ....................................................4
      1.1. Documentation Conventions ..................................4
      1.2. Causes of Overload .........................................5
      1.3. Effects of Overload ........................................6
      1.4. Overload vs. Network Congestion ............................6
      1.5. Diameter Applications in a Broader Network .................7
   2. Overload Control Scenarios ......................................7
      2.1. Peer-to-Peer Scenarios .....................................8
      2.2. Agent Scenarios ...........................................10
      2.3. Interconnect Scenario .....................................14
   3. Diameter Overload Case Studies .................................15
      3.1. Overload in Mobile Data Networks ..........................15
      3.2. 3GPP Study on Core Network Overload .......................16
   4. Existing Mechanisms ............................................17
   5. Issues with the Current Mechanisms .............................18
      5.1. Problems with Implicit Mechanism ..........................18
      5.2. Problems with Explicit Mechanisms .........................18
   6. Extensibility and Application Independence .....................19
   7. Solution Requirements ..........................................20
      7.1. General ...................................................20
      7.2. Performance ...............................................21
      7.3. Heterogeneous Support for Solution ........................22
      7.4. Granular Control ..........................................23
      7.5. Priority and Policy .......................................23
      7.6. Security ..................................................23
      7.7. Flexibility and Extensibility .............................24
   8. Security Considerations ........................................25
      8.1. Access Control ............................................25
      8.2. Denial-of-Service Attacks .................................26
      8.3. Replay Attacks ............................................26
      8.4. Man-in-the-Middle Attacks .................................26
      8.5. Compromised Hosts .........................................27
   9. References .....................................................27
      9.1. Normative References ......................................27
      9.2. Informative References ....................................27
   Appendix A. Contributors ..........................................29
   Appendix B. Acknowledgements ......................................29












McMurry & Campbell            Informational                     [Page 3]

RFC 7068         Diameter Overload Control Requirements    November 2013


1.  Introduction

   A Diameter [RFC6733] node is said to be overloaded when it has
   insufficient resources to successfully process all of the Diameter
   requests that it receives.  When a node becomes overloaded, it needs
   to be able to gracefully reduce its load, typically by advising
   clients to reduce traffic for some period of time.  Otherwise, it
   must continue to expend resources parsing and responding to Diameter
   messages, possibly resulting in a progressively severe overload
   condition.  The existing mechanisms provided by Diameter are not
   sufficient for managing overload conditions.  This document describes
   the limitations of the existing mechanisms and provides requirements
   for new overload management mechanisms.

   This document draws on the work done on SIP overload control
   ([RFC5390], [RFC6357]) as well as on experience gained via overload
   handling in Signaling System No. 7 (SS7) networks and studies done by
   the Third Generation Partnership Project (3GPP) (Section 3).

   Diameter is not typically an end-user protocol; rather, it is
   generally used as one component in support of some end-user activity.

   For example, a SIP server might use Diameter to authenticate and
   authorize user access.  Overload in the Diameter backend
   infrastructure will likely impact the experience observed by the end
   user in the SIP application.

   The impact of Diameter overload on the client application (a client
   application may use the Diameter protocol and other protocols to do
   its job) is beyond the scope of this document.

   This document presents non-normative descriptions of causes of
   overload, along with related scenarios and studies.  Finally, it
   offers a set of normative requirements for an improved overload
   indication mechanism.

1.1.  Documentation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as defined in [RFC2119], with the
   exception that they are not intended for interoperability of
   implementations.  Rather, they are used to describe requirements
   towards future specifications where the interoperability requirements
   will be defined.

   The terms "client", "server", "agent", "node", "peer", "upstream",
   and "downstream" are used as defined in [RFC6733].



McMurry & Campbell            Informational                     [Page 4]

RFC 7068         Diameter Overload Control Requirements    November 2013


1.2.  Causes of Overload

   Overload occurs when an element, such as a Diameter server or agent,
   has insufficient resources to successfully process all of the traffic
   it is receiving.  Resources include all of the capabilities of the
   element used to process a request, including CPU processing, memory,
   I/O, and disk resources.  It can also include external resources such
   as a database or DNS server, in which case the CPU, processing,
   memory, I/O, and disk resources of those elements are effectively
   part of the logical element processing the request.

   External resources can include upstream Diameter nodes; for example,
   a Diameter agent can become effectively overloaded if one or more
   upstream nodes are overloaded.

   A Diameter node can become overloaded due to request levels that
   exceed its capacity, a reduction of available resources (for example,
   a local or upstream hardware failure), or a combination of the two.

   Overload can occur for many reasons, including:

   Inadequate capacity:  When designing Diameter networks, that is,
      application-layer multi-node Diameter deployments, it can be very
      difficult to predict all scenarios that may cause elevated
      traffic.  It may also be more costly to implement support for some
      scenarios than a network operator may deem worthwhile.  This
      results in the likelihood that a Diameter network will not have
      adequate capacity to handle all situations.

   Dependency failures:  A Diameter node can become overloaded because a
      resource on which it depends has failed or become overloaded,
      greatly reducing the logical capacity of the node.  In these
      cases, even minimal traffic might cause the node to go into
      overload.  Examples of such dependency overloads include DNS
      servers, databases, disks, and network interfaces that have failed
      or become overloaded.

   Component failures:  A Diameter node can become overloaded when it is
      a member of a cluster of servers that each share the load of
      traffic and one or more of the other members in the cluster fail.
      In this case, the remaining nodes take over the work of the failed
      nodes.  Normally, capacity planning takes such failures into
      account, and servers are typically run with enough spare capacity
      to handle failure of another node.  However, unusual failure
      conditions can cause many nodes to fail at once.  This is often
      the case with software failures, where a bad packet or bad
      database entry hits the same bug in a set of nodes in a cluster.




McMurry & Campbell            Informational                     [Page 5]

RFC 7068         Diameter Overload Control Requirements    November 2013


   Network-initiated traffic flood:  Certain access network events can
      precipitate floods of Diameter signaling traffic.  For example,
      operational changes can trigger avalanche restarts, or frequent
      radio overlay handovers can generate excessive authorization
      requests.  Failure of a Diameter proxy may also result in a large
      amount of signaling as connections and sessions are reestablished.

   Subscriber-initiated traffic flood:  Large gatherings of subscribers
      or events that result in many subscribers interacting with the
      network in close time proximity can result in Diameter signaling
      traffic floods.  For example, the finale of a large fireworks show
      could be immediately followed by many subscribers posting
      messages, pictures, and videos concentrated on one portion of a
      network.  Subscriber devices such as smartphones may use
      aggressive registration strategies that generate unusually high
      Diameter traffic loads.

   DoS attacks:  An attacker wishing to disrupt service in the network
      can cause a large amount of traffic to be launched at a target
      element.  This can be done from a central source of traffic or
      through a distributed DoS attack.  In all cases, the volume of
      traffic well exceeds the capacity of the element, sending the
      system into overload.

1.3.  Effects of Overload

   Modern Diameter networks, composed of application-layer multi-node
   deployments of Diameter elements, may operate at very large
   transaction volumes.  If a Diameter node becomes overloaded or, even
   worse, fails completely, a large number of messages may be lost very
   quickly.  Even with redundant servers, many messages can be lost in
   the time it takes for failover to complete.  While a Diameter client
   or agent should be able to retry such requests, an overloaded peer
   may cause a sudden large increase in the number of transactions
   needing to be retried, rapidly filling local queues or otherwise
   contributing to local overload.  Therefore, Diameter devices need to
   be able to shed load before critical failures can occur.

1.4.  Overload vs. Network Congestion

   This document uses the term "overload" to refer to application-layer
   overload at Diameter nodes.  This is distinct from "network
   congestion", that is, congestion that occurs at the lower networking
   layers that may impact the delivery of Diameter messages between
   nodes.  This document recognizes that element overload and network
   congestion are interrelated, and that overload can contribute to
   network congestion and vice versa.




McMurry & Campbell            Informational                     [Page 6]

RFC 7068         Diameter Overload Control Requirements    November 2013


   Network congestion issues are better handled by the transport
   protocols.  Diameter uses TCP and the Stream Control Transmission
   Protocol (SCTP), both of which include congestion management
   features.  Analysis of whether those features are sufficient for
   transport-level congestion between Diameter nodes and of any work to
   further mitigate network congestion is out of scope for both this
   document and the work proposed by it.

1.5.  Diameter Applications in a Broader Network

   Most elements using Diameter applications do not use Diameter
   exclusively.  It is important to realize that overload of an element
   can be caused by a number of factors that may be unrelated to the
   processing of Diameter or Diameter applications.

   An element that doesn't use Diameter exclusively needs to be able to
   signal to Diameter peers that it is experiencing overload regardless
   of the cause of the overload, since the overload will affect that
   element's ability to process Diameter transactions.  If the element
   communicates with protocols other than Diameter, it may also need to
   signal the overload situation on these protocols, depending on its
   function and the architecture of the network and application for
   which it is providing services.  Whether that is necessary can only
   be decided within the context of that architecture and use cases.
   This specification details the requirements for a mechanism for
   signaling overload with Diameter; this mechanism provides Diameter
   nodes the ability to inform their Diameter peers of overload,
   mitigating that part of the issue.  Diameter nodes may need to use
   this, as well as other mechanisms, to solve their broader overload
   issues.  Indicating overload on protocols other than Diameter is out
   of scope for this document and for the work proposed by it.

2.  Overload Control Scenarios

   Several Diameter deployment scenarios exist that may impact overload
   management.  The following scenarios help motivate the requirements
   for an overload management mechanism.

   These scenarios are by no means exhaustive and are in general
   simplified for the sake of clarity.  In particular, this document
   assumes for the sake of clarity that the client sends Diameter
   requests to the server, and the server sends responses to the client,
   even though Diameter supports bidirectional applications.  Each
   direction in such an application can be modeled separately.

   In a large-scale deployment, many of the nodes represented in these
   scenarios would be deployed as clusters of servers.  This document
   assumes that such a cluster is responsible for managing its own



McMurry & Campbell            Informational                     [Page 7]

RFC 7068         Diameter Overload Control Requirements    November 2013


   internal load-balancing and overload management so that it appears as
   a single Diameter node.  That is, other Diameter nodes can treat it
   as a single, monolithic node for the purposes of overload management.

   These scenarios do not illustrate the client application.  As
   mentioned in Section 1, Diameter is not typically an end-user
   protocol; rather, it is generally used in support of some other
   client application.  These scenarios do not consider the impact of
   Diameter overload on the client application.

2.1.  Peer-to-Peer Scenarios

   This section describes Diameter peer-to-peer scenarios, that is,
   scenarios where a Diameter client talks directly with a Diameter
   server, without the use of a Diameter agent.

   Figure 1 illustrates the simplest possible Diameter relationship.
   The client and server share a one-to-one peer-to-peer relationship.
   If the server becomes overloaded, either because the client exceeds
   the server's capacity or because the server's capacity is reduced due
   to some resource dependency, the client needs to reduce the amount of
   Diameter traffic it sends to the server.  Since the client cannot
   forward requests to another server, it must either queue requests
   until the server recovers or itself become overloaded in the context
   of the client application and other protocols it may also use.

                            +------------------+
                            |                  |
                            |                  |
                            |     Server       |
                            |                  |
                            +--------+---------+
                                     |
                                     |
                            +--------+---------+
                            |                  |
                            |                  |
                            |     Client       |
                            |                  |
                            +------------------+

                   Figure 1: Basic Peer-to-Peer Scenario









McMurry & Campbell            Informational                     [Page 8]

RFC 7068         Diameter Overload Control Requirements    November 2013


   Figure 2 shows a similar scenario, except in this case the client has
   multiple servers that can handle work for a specific realm and
   application.  If Server 1 becomes overloaded, the client can forward
   traffic to Server 2.  Assuming that Server 2 has sufficient reserve
   capacity to handle the forwarded traffic, the client should be able
   to continue serving client application protocol users.  If Server 1
   is approaching overload, but can still handle some number of new
   requests, it needs to be able to instruct the client to forward a
   subset of its traffic to Server 2.

               +------------------+     +------------------+
               |                  |     |                  |
               |                  |     |                  |
               |     Server 1     |     |     Server 2     |
               |                  |     |                  |
               +--------+-`.------+     +------.'+---------+
                            `.               .'
                              `.           .'
                                `.       .'
                                  `.   .'
                            +-------`.'--------+
                            |                  |
                            |                  |
                            |     Client       |
                            |                  |
                            +------------------+

              Figure 2: Multiple-Server Peer-to-Peer Scenario

   Figure 3 illustrates a peer-to-peer scenario with multiple Diameter
   realm and application combinations.  In this example, Server 2 can
   handle work for both applications.  Each application might have
   different resource dependencies.  For example, a server might need to
   access one database for Application A and another for Application B.
   This creates a possibility that Server 2 could become overloaded for
   Application A but not for Application B, in which case the client
   would need to divert some part of its Application A requests to
   Server 1, but the client should not divert any Application B
   requests.  This requires that Server 2 be able to distinguish between
   applications when it indicates an overload condition to the client.

   On the other hand, it's possible that the servers host many
   applications.  If Server 2 becomes overloaded for all applications,
   it would be undesirable for it to have to notify the client
   separately for each application.  Therefore, it also needs a way to
   indicate that it is overloaded for all possible applications.





McMurry & Campbell            Informational                     [Page 9]

RFC 7068         Diameter Overload Control Requirements    November 2013


   +---------------------------------------------+
   | Application A       +----------------------+----------------------+
   |+------------------+ |  +----------------+  |  +------------------+|
   ||                  | |  |                |  |  |                  ||
   ||                  | |  |                |  |  |                  ||
   ||     Server 1     | |  |    Server 2    |  |  |     Server 3     ||
   ||                  | |  |                |  |  |                  ||
   |+--------+---------+ |  +-------+--------+  |  +-+----------------+|
   |         |           |          |           |    |                 |
   +---------+-----------+----------+-----------+    |                 |
             |           |          |                |                 |
             |           |          |                |  Application B  |
             |           +----------+----------------+-----------------+
             ``-.._                 |                |
                   `-..__           |            _.-''
                        `--._       |        _.-''
                             ``-._  |   _.-''
                            +-----`-.-''-----+
                            |                |
                            |                |
                            |     Client     |
                            |                |
                            +----------------+

           Figure 3: Multiple-Application Peer-to-Peer Scenario

2.2.  Agent Scenarios

   This section describes scenarios that include a Diameter agent, in
   the form of either a Diameter relay or Diameter proxy.  These
   scenarios do not consider Diameter redirect agents, since they are
   more readily modeled as end servers.  The examples have been kept
   simple deliberately, to illustrate basic concepts.  Significantly
   more complicated topologies are possible with Diameter, including
   multiple intermediate agents in a path connected in a variety
   of ways.















McMurry & Campbell            Informational                    [Page 10]

RFC 7068         Diameter Overload Control Requirements    November 2013


   Figure 4 illustrates a simple Diameter agent scenario with a single
   client, agent, and server.  In this case, overload can occur at the
   server, at the agent, or both.  But in most cases, client behavior is
   the same whether overload occurs at the server or at the agent.  From
   the client's perspective, server overload and agent overload are the
   same thing.

                           +------------------+
                           |                  |
                           |                  |
                           |     Server       |
                           |                  |
                           +--------+---------+
                                    |
                                    |
                           +--------+---------+
                           |                  |
                           |                  |
                           |      Agent       |
                           |                  |
                           +--------+---------+
                                    |
                                    |
                           +--------+---------+
                           |                  |
                           |                  |
                           |     Client       |
                           |                  |
                           +------------------+

                      Figure 4: Basic Agent Scenario

   Figure 5 shows an agent scenario with multiple servers.  If Server 1
   becomes overloaded but Server 2 has sufficient reserve capacity, the
   agent may be able to transparently divert some or all Diameter
   requests originally bound for Server 1 to Server 2.

   In most cases, the client does not have detailed knowledge of the
   Diameter topology upstream of the agent.  If the agent uses dynamic
   discovery to find eligible servers, the set of eligible servers may
   not be enumerable from the perspective of the client.  Therefore, in
   most cases the agent needs to deal with any upstream overload issues
   in a way that is transparent to the client.  If one server notifies
   the agent that it has become overloaded, the notification should not
   be passed back to the client in a way that the client could
   mistakenly perceive the agent itself as being overloaded.  If the set





McMurry & Campbell            Informational                    [Page 11]

RFC 7068         Diameter Overload Control Requirements    November 2013


   of all possible destinations upstream of the agent no longer has
   sufficient capacity for incoming load, the agent itself becomes
   effectively overloaded.

   On the other hand, there are cases where the client needs to be able
   to select a particular server from behind an agent.  For example, if
   a Diameter request is part of a multiple-round-trip authentication,
   or is otherwise part of a Diameter "session", it may have a
   Destination-Host Attribute-Value Pair (AVP) that requires that the
   request be served by Server 1.  Therefore, the agent may need to
   inform a client that a particular upstream server is overloaded or
   otherwise unavailable.  Note that there can be many ways a server can
   be specified, which may have different implications (e.g., by IP
   address, by host name, etc).

              +------------------+     +------------------+
              |                  |     |                  |
              |                  |     |                  |
              |     Server 1     |     |     Server 2     |
              |                  |     |                  |
              +--------+-`.------+     +------.'+---------+
                           `.               .'
                             `.           .'
                               `.       .'
                                 `.   .'
                           +-------`.'--------+
                           |                  |
                           |                  |
                           |     Agent        |
                           |                  |
                           +--------+---------+
                                    |
                                    |
                                    |
                           +--------+---------+
                           |                  |
                           |                  |
                           |     Client       |
                           |                  |
                           +------------------+

                 Figure 5: Multiple-Server Agent Scenario









McMurry & Campbell            Informational                    [Page 12]

RFC 7068         Diameter Overload Control Requirements    November 2013


   Figure 6 shows a scenario where an agent routes requests to a set of
   servers for more than one Diameter realm and application.  In this
   scenario, if Server 1 becomes overloaded or unavailable while
   Server 2 still has available capacity, the agent may effectively
   operate at reduced capacity for Application A but at full capacity
   for Application B.  Therefore, the agent needs to be able to report
   that it is overloaded for one application but not for another.

   +--------------------------------------------+
   | Application A       +----------------------+----------------------+
   |+------------------+ |  +----------------+  |  +------------------+|
   ||                  | |  |                |  |  |                  ||
   ||                  | |  |                |  |  |                  ||
   ||     Server 1     | |  |    Server 2    |  |  |     Server 3     ||
   ||                  | |  |                |  |  |                  ||
   |+---------+--------+ |  +-------+--------+  |  +--+---------------+|
   |          |          |          |           |     |                |
   +----------+----------+----------+-----------+     |                |
              |          |          |                 |                |
              |          |          |                 | Application B  |
              |          +----------+-----------------+----------------+
              |                     |                 |
               ``--.__              |                _.
                      ``-.__        |          __.--''
                            `--.._  |    _..--'
                            +----``-+.''-----+
                            |                |
                            |                |
                            |    Agent       |
                            |                |
                            +-------+--------+
                                    |
                                    |
                            +-------+--------+
                            |                |
                            |                |
                            |    Client      |
                            |                |
                            +----------------+

               Figure 6: Multiple-Application Agent Scenario










McMurry & Campbell            Informational                    [Page 13]

RFC 7068         Diameter Overload Control Requirements    November 2013


2.3.  Interconnect Scenario

   Another scenario to consider when looking at Diameter overload is
   that of multiple network operators using Diameter components
   connected through an interconnect service, e.g., using IPX (IP Packet
   eXchange).  IPX [IR.34] is an Inter-Operator IP Backbone that
   provides a roaming interconnection network between mobile operators
   and service providers.  IPX is also used to transport Diameter
   signaling between operators [IR.88].  Figure 7 shows two network
   operators with an interconnect network between them.  There could be
   any number of these networks between any two network operators'
   networks.

               +-------------------------------------------+
               |               Interconnect                |
               |                                           |
               |   +--------------+      +--------------+  |
               |   |   Server 3   |------|   Server 4   |  |
               |   +--------------+      +--------------+  |
               |         .'                      `.        |
               +------.-'--------------------------`.------+
                    .'                               `.
                 .-'                                   `.
   ------------.'-----+                             +----`.-------------
         +----------+ |                             | +----------+
         | Server 1 | |                             | | Server 2 |
         +----------+ |                             | +----------+
                      |                             |
   Network Operator 1 |                             | Network Operator 2
   -------------------+                             +-------------------

                Figure 7: Two-Network Interconnect Scenario

   The characteristics of the information that an operator would want to
   share over such a connection are different from the information
   shared between components within a network operator's network.  For
   example, network operators may not want to convey topology or
   operational information; this would in turn limit how much overload
   and loading information can be sent.  For the interconnect scenario
   shown in Figure 7, Server 2 may want to signal overload to Server 1,
   to affect traffic coming from Network Operator 1.

   This case is distinct from those internal to a network operator's
   network, where there may be many more elements in a more complicated
   topology.  Also, the elements in the interconnect network may not
   support Diameter overload control, and the network operators may not
   want the interconnect network to use overload or loading information.
   They may only want the information to pass through the interconnect



McMurry & Campbell            Informational                    [Page 14]

RFC 7068         Diameter Overload Control Requirements    November 2013


   network without further processing or action by the interconnect
   network, even if the elements in the interconnect network do support
   Diameter overload control.

3.  Diameter Overload Case Studies

3.1.  Overload in Mobile Data Networks

   As the number of smartphone devices that are Third Generation (3G)
   and Long Term Evolution (LTE) enabled continues to expand in mobile
   networks, there have been situations where high signaling traffic
   load led to overload events at the Diameter-based Home Location
   Registers (HLRs) and/or Home Subscriber Servers (HSS) [TR23.843].
   The root causes of the HLR overload events were manifold but included
   hardware failure and procedural errors.  The result was high
   signaling traffic load on the HLR and HSS.

   The 3GPP architecture [TS23.002] makes extensive use of Diameter.  It
   is used for mobility management [TS29.272], the IP Multimedia
   Subsystem (IMS) [TS29.228], and policy and charging control
   [TS29.212], as well as other functions.  The details of the
   architecture are out of scope for this document, but it is worth
   noting that there are quite a few Diameter applications, some with
   quite large amounts of Diameter signaling in deployed networks.

   The 3GPP specifications do not currently address overload for
   Diameter applications or provide a load control mechanism equivalent
   to those provided in the more traditional SS7 elements in the Global
   System for Mobile Communications (GSM); see [TS29.002].  The
   capabilities specified in the 3GPP standards do not adequately
   address the abnormal condition where excessively high signaling
   traffic load situations are experienced.

   Smartphones, which comprise an increasingly large percentage of
   mobile devices, contribute much more heavily, relative to
   non-smartphones, to the continuation of a registration surge, due to
   their very aggressive registration algorithms.  Smartphone behavior
   contributes to network loading and can contribute to overload
   conditions.  The aggressive smartphone logic is designed to:

   a.  always have voice and data registration, and

   b.  constantly try to be on 3G or LTE data (and thus on 3G voice or
       Voice over LTE (VoLTE) [IR.92]) for their added benefits.

   Non-smartphones typically have logic to wait for a time period after
   registering successfully on voice and data.




McMurry & Campbell            Informational                    [Page 15]

RFC 7068         Diameter Overload Control Requirements    November 2013


   The aggressive smartphone registration is problematic in two ways:

   o  first, by generating excessive signaling load towards the HSS that
      is ten times the load from a non-smartphone, and

   o  second, by causing continual registration attempts when a network
      failure affects registrations through the 3G data network.

3.2.  3GPP Study on Core Network Overload

   A study in the 3GPP System Aspects working group 2 (SA2) on core
   network overload has produced the technical report [TR23.843].  This
   enumerates several causes of overload in mobile core networks,
   including portions that are signaled using Diameter.  [TR23.843] is a
   work in progress and is not complete.  However, it is useful for
   pointing out scenarios and the general need for an overload control
   mechanism for Diameter.

   It is common for mobile networks to employ more than one radio
   technology and to do so in an overlay fashion with multiple
   technologies present in the same location (such as 2nd or 3rd
   generation mobile technologies, along with LTE).  This presents
   opportunities for traffic storms when issues occur on one overlay and
   not another as all devices that had been on the overlay with issues
   switch.  This causes a large amount of Diameter traffic as locations
   and policies are updated.

   Another scenario called out by this study is a flood of registration
   and mobility management events caused by some element in the core
   network failing.  This flood of traffic from end nodes falls under
   the network-initiated traffic flood category.  There is likely to
   also be traffic resulting directly from the component failure in this
   case.  A similar flood can occur when elements or components recover
   as well.

   Subscriber-initiated traffic floods are also indicated in this study
   as an overload mechanism where a large number of mobile devices are
   attempting to access services at the same time, such as in response
   to an entertainment event or a catastrophic event.

   While this 3GPP study is concerned with the broader effects of these
   scenarios on wireless networks and their elements, they have
   implications specifically for Diameter signaling.  One of the goals
   of this document is to provide guidance for a core mechanism that can
   be used to mitigate the scenarios called out by this study.






McMurry & Campbell            Informational                    [Page 16]

RFC 7068         Diameter Overload Control Requirements    November 2013


4.  Existing Mechanisms

   Diameter offers both implicit and explicit mechanisms for a Diameter
   node to learn that a peer is overloaded or unreachable.  The implicit
   mechanism is simply the lack of responses to requests.  If a client
   fails to receive a response in a certain time period, it assumes that
   the upstream peer is unavailable or is overloaded to the point of
   effective unavailability.  The watchdog mechanism [RFC3539] ensures
   that transaction responses occur at a certain rate even when there is
   otherwise little or no other Diameter traffic.

   The explicit mechanism can involve specific protocol error responses,
   where an agent or server tells a downstream peer that it is either
   too busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a
   request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER)
   perhaps because that destination itself is overloaded to the point of
   unavailability.

   Another explicit mechanism, a DPR (Disconnect-Peer-Request) message,
   can be sent with a Disconnect-Cause of BUSY.  This signals the
   sender's intent to close the transport connection and requests that
   the client not reconnect.

   Once a Diameter node learns via one of these mechanisms that an
   upstream peer has become overloaded, it can then attempt to take
   action to reduce the load.  This usually means forwarding traffic to
   an alternate destination, if available.  If no alternate destination
   is available, the node must either reduce the number of messages it
   originates (in the case of a client) or inform the client to reduce
   traffic (in the case of an agent).

   Diameter requires the use of a congestion-managed transport layer,
   currently TCP or SCTP, to mitigate network congestion.  It is
   expected that these transports manage network congestion and that
   issues with transport (e.g., congestion propagation and window
   management) are managed at that level.  But even with a congestion-
   managed transport, a Diameter node can become overloaded at the
   Diameter protocol or application layers due to the causes described
   in Section 1.2, and congestion-managed transports do not provide
   facilities (and are at the wrong level) to handle server overload.
   Transport-level congestion management is also not sufficient to
   address overload in cases of multi-hop and multi-destination
   signaling.








McMurry & Campbell            Informational                    [Page 17]

RFC 7068         Diameter Overload Control Requirements    November 2013


5.  Issues with the Current Mechanisms

   The currently available Diameter mechanisms for indicating an
   overload condition are not adequate to avoid service outages due to
   overload.  This inadequacy may, in turn, contribute to broader
   impacts resulting from overload due to unresponsive Diameter nodes
   causing application-layer or transport-layer retransmissions.  In
   particular, they do not allow a Diameter agent or server to shed load
   as it approaches overload.  At best, a node can only indicate that it
   needs to entirely stop receiving requests, i.e., that it has
   effectively failed.  Even that is problematic due to the inability to
   indicate durational validity on the transient errors available in the
   base Diameter protocol.  Diameter offers no mechanism to allow a node
   to indicate different overload states for different categories of
   messages, for example, if it is overloaded for one Diameter
   application but not another.

5.1.  Problems with Implicit Mechanism

   The implicit mechanism doesn't allow an agent or server to inform the
   client of a problem until it is effectively too late to do anything
   about it.  The client does not know that it needs to take action
   until the upstream node has effectively failed.  A Diameter node has
   no opportunity to shed load early to avoid collapse in the first
   place.

   Additionally, the implicit mechanism cannot distinguish between
   overload of a Diameter node and network congestion.  Diameter treats
   the failure to receive an answer as a transport failure.

5.2.  Problems with Explicit Mechanisms

   The Diameter specification is ambiguous on how a client should handle
   receipt of a DIAMETER_TOO_BUSY response.  The base specification
   [RFC6733] indicates that the sending client should attempt to send
   the request to a different peer.  It makes no suggestion that the
   receipt of a DIAMETER_TOO_BUSY response should affect future Diameter
   messages in any way.

   The Authentication, Authorization, and Accounting (AAA) Transport
   Profile [RFC3539] recommends that a AAA node that receives a "Busy"
   response failover all remaining requests to a different agent or
   server.  But while the Diameter base specification explicitly depends
   on [RFC3539] to define transport behavior, it does not refer to
   [RFC3539] in the description of behavior on receipt of a
   DIAMETER_TOO_BUSY error.  There's a strong likelihood that at least
   some implementations will continue to send Diameter requests to an
   upstream peer even after receiving a DIAMETER_TOO_BUSY error.



McMurry & Campbell            Informational                    [Page 18]

RFC 7068         Diameter Overload Control Requirements    November 2013


   BCP 41 [RFC2914] describes, among other things, how end-to-end
   application behavior can help avoid congestion collapse.  In
   particular, an application should avoid sending messages that will
   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior as
   described in the Diameter base specification fails at this, since if
   an upstream node becomes overloaded, a client attempts each request
   and does not discover the need to failover the request until the
   initial attempt fails.

   The situation is improved if implementations follow the [RFC3539]
   recommendation to keep state about upstream peer overload.  But even
   then, the Diameter specification offers no guidance on how long a
   client should wait before retrying the overloaded destination.  If an
   agent or server supports multiple realms and/or applications,
   DIAMETER_TOO_BUSY offers no way to indicate that it is overloaded for
   one application but not another.  A DIAMETER_TOO_BUSY error can only
   indicate overload at a "whole server" scope.

   Agent processing of a DIAMETER_TOO_BUSY response is also problematic
   as described in the base specification.  DIAMETER_TOO_BUSY is defined
   as a protocol error.  If an agent receives a protocol error, it may
   either handle it locally or forward the response back towards the
   downstream peer.  If a downstream peer receives the DIAMETER_TOO_BUSY
   response, it may stop sending all requests to the agent for some
   period of time, even though the agent may still be able to deliver
   requests to other upstream peers.

   DIAMETER_UNABLE_TO_DELIVER errors, or using DPR with cause code BUSY,
   also have no mechanisms for specifying the scope or cause of the
   failure, or the durational validity.

   The issues with error responses described in [RFC6733] extend beyond
   the particular issues for overload control and have been addressed in
   an ad hoc fashion by various implementations.  Addressing these in a
   standard way would be a useful exercise, but it is beyond the scope
   of this document.

6.  Extensibility and Application Independence

   Given the variety of scenarios in which Diameter elements can be
   deployed and the variety of roles they can fulfill with Diameter and
   other technologies, a single algorithm for handling overload may not
   be sufficient.  For purposes of this discussion, an algorithm is
   inclusive of behavior for control of overload but does not encompass
   the general mechanism for transporting control information.  This
   effort cannot anticipate all possible future scenarios and roles.
   Extensibility, particularly of algorithms used to deal with overload,
   will be important to cover these cases.



McMurry & Campbell            Informational                    [Page 19]

RFC 7068         Diameter Overload Control Requirements    November 2013


   Similarly, the scopes to which overload information may apply may
   include cases that have not yet been considered.  Extensibility in
   this area will also be important.

   The basic mechanism is intended to be application independent, that
   is, a Diameter node can use it across any existing and future
   Diameter applications and expect reasonable results.  Certain
   Diameter applications might, however, benefit from application-
   specific behavior over and above the mechanism's defaults.  For
   example, an application specification might specify relative
   priorities of messages or selection of a specific overload control
   algorithm.

7.  Solution Requirements

   This section proposes requirements for an improved mechanism to
   control Diameter overload, with the goals of addressing the issues
   described in Section 5 and supporting the scenarios described in
   Section 2.  These requirements are stated primarily in terms of
   individual node behavior to inform the design of the improved
   mechanism; solution designers should keep in mind that the overall
   goal is improved overall system behavior across all the nodes
   involved, not just improved behavior from specific individual nodes.

7.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

   REQ 4:  Diameter allows requests to be sent from either side of a
           connection, and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.




McMurry & Campbell            Informational                    [Page 20]

RFC 7068         Diameter Overload Control Requirements    November 2013


   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           be configured at each node.

7.2.  Performance

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.

   REQ 8:  Supporting nodes MUST be able to distinguish current overload
           information from stale information.

   REQ 9:  The solution MUST function across fully loaded as well as
           quiescent transport connections.  This is partially derived
           from the requirement for stability in REQ 7.

   REQ 10: Consumers of overload information MUST be able to determine
           when the overload condition improves or ends.

   REQ 11: The solution MUST be able to operate in networks of different
           sizes.

   REQ 12: When a single network node fails, goes into overload, or
           suffers from reduced processing capacity, the solution MUST
           make it possible to limit the impact of the affected node on
           other nodes in the network.  This helps to prevent a small-
           scale failure from becoming a widespread outage.

   REQ 13: The solution MUST NOT introduce substantial additional work
           for a node in an overloaded state.  For example, a
           requirement for an overloaded node to send overload
           information every time it received a new request would
           introduce substantial work.






McMurry & Campbell            Informational                    [Page 21]

RFC 7068         Diameter Overload Control Requirements    November 2013


   REQ 14: Some scenarios that result in overload involve a rapid
           increase of traffic with little time between normal levels
           and levels that induce overload.  The solution SHOULD provide
           for rapid feedback when traffic levels increase.

   REQ 15: The solution MUST NOT interfere with the congestion control
           mechanisms of underlying transport protocols.  For example, a
           solution that opened additional TCP connections when the
           network is congested would reduce the effectiveness of the
           underlying congestion control mechanisms.

7.3.  Heterogeneous Support for Solution

   REQ 16: The solution is likely to be deployed incrementally.  The
           solution MUST support a mixed environment where some, but not
           all, nodes implement it.

   REQ 17: In a mixed environment with nodes that support the solution
           and nodes that do not, the solution MUST NOT result in
           materially less useful throughput during overload as would
           have resulted if the solution were not present.  It SHOULD
           result in less severe overload in this environment.

   REQ 18: In a mixed environment of nodes that support the solution and
           nodes that do not, the solution MUST NOT preclude elements
           that support overload control from treating elements that do
           not support overload control in an equitable fashion relative
           to those that do.  Users and operators of nodes that do not
           support the solution MUST NOT unfairly benefit from the
           solution.  The solution specification SHOULD provide guidance
           to implementors for dealing with elements not supporting
           overload control.

   REQ 19: It MUST be possible to use the solution between nodes in
           different realms and in different administrative domains.

   REQ 20: Any explicit overload indication MUST be clearly
           distinguishable from other errors reported via Diameter.

   REQ 21: In cases where a network node fails, is so overloaded that it
           cannot process messages, or cannot communicate due to a
           network failure, it may not be able to provide explicit
           indications of the nature of the failure or its levels of
           overload.  The solution MUST result in at least as much
           useful throughput as would have resulted if the solution were
           not in place.





McMurry & Campbell            Informational                    [Page 22]

RFC 7068         Diameter Overload Control Requirements    November 2013


7.4.  Granular Control

   REQ 22: The solution MUST provide a way for a node to throttle the
           amount of traffic it receives from a peer node.  This
           throttling SHOULD be graded so that it can be applied
           gradually as offered load increases.  Overload is not a
           binary state; there may be degrees of overload.

   REQ 23: The solution MUST provide sufficient information to enable a
           load-balancing node to divert messages that are rejected or
           otherwise throttled by an overloaded upstream node to other
           upstream nodes that are the most likely to have sufficient
           capacity to process them.

   REQ 24: The solution MUST provide a mechanism for indicating load
           levels, even when not in an overload condition, to assist
           nodes in making decisions to prevent overload conditions from
           occurring.

7.5.  Priority and Policy

   REQ 25: The base specification for the solution SHOULD offer general
           guidance on which message types might be desirable to send or
           process over others during times of overload, based on
           application-specific considerations.  For example, it may be
           more beneficial to process messages for existing sessions
           ahead of new sessions.  Some networks may have a requirement
           to give priority to requests associated with emergency
           sessions.  Any normative or otherwise detailed definition of
           the relative priorities of message types during an overload
           condition will be the responsibility of the application
           specification.

   REQ 26: The solution MUST NOT prevent a node from prioritizing
           requests based on any local policy, so that certain requests
           are given preferential treatment, given additional
           retransmission, not throttled, or processed ahead of others.

7.6.  Security

   REQ 27: The solution MUST NOT provide new vulnerabilities to
           malicious attack or increase the severity of any existing
           vulnerabilities.  This includes vulnerabilities to DoS and
           DDoS attacks as well as replay and man-in-the-middle attacks.
           Note that the Diameter base specification [RFC6733] lacks
           end-to-end security, and this must be considered (see
           Security Considerations in this document (Section 8)).  Note




McMurry & Campbell            Informational                    [Page 23]

RFC 7068         Diameter Overload Control Requirements    November 2013


           that this requirement was expressed at a high level so as to
           not preclude any particular solution.  Is is expected that
           the solution will address this in more detail.

   REQ 28: The solution MUST NOT depend on being deployed in
           environments where all Diameter nodes are completely trusted.
           It SHOULD operate as effectively as possible in environments
           where other nodes are malicious; this includes preventing
           malicious nodes from obtaining more than a fair share of
           service.  Note that this does not imply any responsibility on
           the solution to detect, or take countermeasures against,
           malicious nodes.

   REQ 29: It MUST be possible for a supporting node to make
           authorization decisions about what information will be sent
           to peer nodes based on the identity of those nodes.  This
           allows a domain administrator who considers the load of their
           nodes to be sensitive information to restrict access to that
           information.  Of course, in such cases, there is no
           expectation that the solution itself will help prevent
           overload from that peer node.

   REQ 30: The solution MUST NOT interfere with any Diameter-compliant
           method that a node may use to protect itself from overload
           from non-supporting nodes or from denial-of-service attacks.

7.7.  Flexibility and Extensibility

   REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.

   REQ 32: The solution MUST provide a method for extending the
           information communicated and the algorithms used for overload
           control.






McMurry & Campbell            Informational                    [Page 24]

RFC 7068         Diameter Overload Control Requirements    November 2013


   REQ 33: The solution MUST provide a default algorithm that is
           mandatory to implement.

   REQ 34: The solution SHOULD provide a method for exchanging overload
           and load information between elements that are connected by
           intermediaries that do not support the solution.

8.  Security Considerations

   A Diameter overload control mechanism is primarily concerned with the
   load-related and overload-related behavior of nodes in a Diameter
   network, and the information used to affect that behavior.  Load and
   overload information is shared between nodes and directly affects the
   behavior, and thus the information is potentially vulnerable to a
   number of methods of attack.

   Load and overload information may also be sensitive from both
   business and network protection viewpoints.  Operators of Diameter
   equipment want to control the visibility of load and overload
   information to keep it from being used for competitive intelligence
   or for targeting attacks.  It is also important that the Diameter
   overload control mechanism not introduce any way in which any other
   information carried by Diameter is sent inappropriately.

   Note that the Diameter base specification [RFC6733] lacks end-to-end
   security, making it difficult for non-adjacent nodes to verify the
   authenticity and ownership of load and overload information.
   Authentication of load and overload information helps to alleviate
   several of the security issues listed in this section.

   This document includes requirements intended to mitigate the effects
   of attacks and to protect the information used by the mechanism.
   This section discusses potential security considerations for overload
   control solutions.  This discussion provides the motivation for
   several normative requirements described in Section 7.  The
   discussion includes specific references to the normative requirements
   that apply for each issue.

8.1.  Access Control

   To control the visibility of load and overload information, sending
   should be subject to some form of authentication and authorization of
   the receiver.  It is also important to the receivers that they are
   confident the load and overload information they receive is from a
   legitimate source.  REQ 28 requires that the solution work without
   assuming that all Diameter nodes in a network are trusted for the
   purposes of exchanging overload and load information.  REQ 29
   requires that the solution let nodes restrict unauthorized parties



McMurry & Campbell            Informational                    [Page 25]

RFC 7068         Diameter Overload Control Requirements    November 2013


   from seeing overload information.  Note that this implies a certain
   amount of configurability on the nodes supporting the Diameter
   overload control mechanism.

8.2.  Denial-of-Service Attacks

   An overload control mechanism provides a very attractive target for
   denial-of-service attacks.  A small number of messages may effect a
   large service disruption by falsely reporting overload conditions.
   Alternately, attacking servers nearing, or in, overload may also be
   facilitated by disrupting their overload indications, potentially
   preventing them from mitigating their overload condition.

   A design goal for the Diameter overload control mechanism is to
   minimize or eliminate the possibility of using the mechanism for this
   type of attack.  More strongly, REQ 27 forbids the solution from
   introducing new vulnerabilities to malicious attack.  Additionally,
   REQ 30 stipulates that the solution not interfere with other
   mechanisms used for protection against denial-of-service attacks.

   As the intent of some denial-of-service attacks is to induce overload
   conditions, an effective overload control mechanism should help to
   mitigate the effects of such an attack.

8.3.  Replay Attacks

   An attacker that has managed to obtain some messages from the
   overload control mechanism may attempt to affect the behavior of
   nodes supporting the mechanism by sending those messages at
   potentially inopportune times.  In addition to time shifting, replay
   attacks may send messages to other nodes as well (target shifting).

   A design goal for the Diameter overload control solution is to
   minimize or eliminate the possibility of causing disruption by using
   a replay attack on the Diameter overload control mechanism.
   (Allowing a replay attack using the overload control solution would
   violate REQ 27.)

8.4.  Man-in-the-Middle Attacks

   By inserting themselves between two nodes supporting the Diameter
   overload control mechanism, an attacker may potentially both access
   and alter the information sent between those nodes.  This can be used
   for information gathering for business intelligence and attack
   targeting, as well as direct attacks.






McMurry & Campbell            Informational                    [Page 26]

RFC 7068         Diameter Overload Control Requirements    November 2013


   REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks
   on the overload control solution.  A transport using Transport Layer
   Security (TLS) and/or IPsec may be desirable for this purpose.

8.5.  Compromised Hosts

   A compromised host that supports the Diameter overload control
   mechanism could be used for information gathering as well as for
   sending malicious information to any Diameter node that would
   normally accept information from it.  While it is beyond the scope of
   the Diameter overload control mechanism to mitigate any operational
   interruption to the compromised host, REQs 28 and 29 imply a need to
   minimize the impact that a compromised host can have on other nodes
   through the use of the Diameter overload control mechanism.  Of
   course, a compromised host could be used to cause damage in a number
   of other ways.  This is out of scope for a Diameter overload control
   mechanism.

9.  References

9.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6733]   Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
               "Diameter Base Protocol", RFC 6733, October 2012.

   [RFC2914]   Floyd, S., "Congestion Control Principles", BCP 41,
               RFC 2914, September 2000.

   [RFC3539]   Aboba, B. and J. Wood, "Authentication, Authorization and
               Accounting (AAA) Transport Profile", RFC 3539, June 2003.

9.2.  Informative References

   [RFC5390]   Rosenberg, J., "Requirements for Management of Overload
               in the Session Initiation Protocol", RFC 5390,
               December 2008.

   [RFC6357]   Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
               Considerations for Session Initiation Protocol (SIP)
               Overload Control", RFC 6357, August 2011.

   [TR23.843]  3GPP, "Study on Core Network (CN) overload solutions",
               TR 23.843 1.2.0, Work in Progress, October 2013.





McMurry & Campbell            Informational                    [Page 27]

RFC 7068         Diameter Overload Control Requirements    November 2013


   [IR.34]     GSMA, "Inter-Service Provider IP Backbone Guidelines",
               IR 34 9.1, May 2013.

   [IR.88]     GSMA, "LTE Roaming Guidelines", IR 88 9.0, January 2013.

   [IR.92]     GSMA, "IMS Profile for Voice and SMS", IR 92 7.0,
               March 2013.

   [TS23.002]  3GPP, "Network Architecture", TS 23.002 12.2.0,
               June 2013.

   [TS29.272]  3GPP, "Evolved Packet System (EPS); Mobility Management
               Entity (MME) and Serving GPRS Support Node (SGSN) related
               interfaces based on Diameter protocol", TS 29.272 12.2.0,
               September 2013.

   [TS29.212]  3GPP, "Policy and Charging Control (PCC) over Gx/Sd
               reference point", TS 29.212 12.2.0, September 2013.

   [TS29.228]  3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
               Signalling flows and message contents", TS 29.228 12.0.0,
               September 2013.

   [TS29.002]  3GPP, "Mobile Application Part (MAP) specification",
               TS 29.002 12.2.0, September 2013.


























McMurry & Campbell            Informational                    [Page 28]

RFC 7068         Diameter Overload Control Requirements    November 2013


Appendix A.  Contributors

   Significant contributions to this document were made by Adam Roach
   and Eric Noel.

Appendix B.  Acknowledgements

   Review of, and contributions to, this specification by Martin Dolly,
   Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
   Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent
   Thiebaut, Andrew Booth, and Lionel Morand were most appreciated.  We
   would like to thank them for their time and expertise.

Authors' Addresses

   Eric McMurry
   Oracle
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   EMail: emcmurry@computer.org


   Ben Campbell
   Oracle
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   EMail: ben@nostrum.com


















McMurry & Campbell            Informational                    [Page 29]