-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-dots-signal-channel-04.xml
2497 lines (2086 loc) · 107 KB
/
draft-ietf-dots-signal-channel-04.xml
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
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dots-signal-channel-04"
ipr="trust200902">
<front>
<title abbrev="DOTS Signal Channel">Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal Channel</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="McAfee">McAfee, Inc.</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<street></street>
<city></city>
<country></country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Andrew Mortensen" initials="A." surname="Mortensen">
<organization>Arbor Networks, Inc.</organization>
<address>
<postal>
<street>2727 S. State St</street>
<city>Ann Arbor, MI</city>
<region></region>
<code>48104</code>
<country>United States</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Nik Teague" initials="N." surname="Teague">
<organization>Verisign, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>United States</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date />
<workgroup>DOTS</workgroup>
<abstract>
<t>This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of-Service
(DDoS) attacks to a server capable of enabling network traffic
mitigation on behalf of the requesting client. A companion document
defines the DOTS data channel, a separate reliable communication layer
for DOTS management and configuration.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. In
most cases, sufficient scale can be achieved by compromising enough
end-hosts and using those infected hosts to perpetrate and amplify the
attack. The victim in this attack can be an application server, a host,
a router, a firewall, or an entire network.</t>
<t>In many cases, it may not be possible for an network administrators
to determine the causes of an attack, but instead just realize that
certain resources seem to be under attack. This document defines a
lightweight protocol permitting a DOTS client to request mitigation from
one or more DOTS servers for protection against detected, suspected, or
anticipated attacks . This protocol enables cooperation between DOTS
agents to permit a highly-automated network defense that is robust,
reliable and secure.</t>
<t>The requirements for DOTS signal channel protocol are obtained from
<xref target="I-D.ietf-dots-requirements"></xref>.</t>
<t>This document satisfies all the use cases discussed in <xref
target="I-D.ietf-dots-use-cases"></xref> except the Third-party DOTS
notifications use case in Section 3.2.3 of <xref
target="I-D.ietf-dots-use-cases"></xref> which is an optional feature
and not a core use case. Third-party DOTS notifications are not part of
the DOTS requirements document. Moreover, the DOTS architecture does not
assess whether that use case may have an impact on the architecture
itself and/or the DOTS trust model.</t>
<t>This is a companion document to the DOTS data channel specification
<xref target="I-D.ietf-dots-data-channel"></xref> that defines a
configuration and bulk data exchange mechanism supporting the DOTS
signal channel.</t>
</section>
<section anchor="notation" title="Notational Conventions and Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>(D)TLS: For brevity this term is used for statements that apply to
both Transport Layer Security <xref target="RFC5246"></xref> and
Datagram Transport Layer Security <xref target="RFC6347"></xref>.
Specific terms will be used for any statement that applies to either
protocol alone.</t>
<t>The reader should be familiar with the terms defined in <xref
target="I-D.ietf-dots-architecture"></xref>.</t>
</section>
<section title="Solution Overview">
<t>Network applications have finite resources like CPU cycles, number of
processes or threads they can create and use, maximum number of
simultaneous connections it can handle, limited resources of the control
plane, etc. When processing network traffic, such applications are
supposed to use these resources to offer the intended task in the most
efficient fashion. However, an attacker may be able to prevent an
application from performing its intended task by causing the application
to exhaust the finite supply of a specific resource.</t>
<t>TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the
victim and ACK-flood is a CPU exhaustion attack on the victim (<xref
target="RFC4987"></xref>). Attacks on the link are carried out by
sending enough traffic such that the link becomes excessively congested,
and legitimate traffic suffers high packet loss. Stateful firewalls can
also be attacked by sending traffic that causes the firewall to hold
excessive state. The firewall then runs out of memory, and can no longer
instantiate the state required to pass legitimate flows. Other possible
DDoS attacks are discussed in <xref target="RFC4732"></xref>.</t>
<t>In each of the cases described above, the possible arrangements
between the DOTS client and DOTS server to mitigate the attack are
discussed in <xref target="I-D.ietf-dots-use-cases"></xref>. An example
of network diagram showing a deployment of these elements is shown in
<xref target="fig1"></xref>. Architectural relationships between
involved DOTS agents is explained in <xref
target="I-D.ietf-dots-architecture"></xref>. In this example, the DOTS
server is operating on the access network.</t>
<t><figure anchor="fig1" title="Sample DOTS Deployment (1)">
<artwork align="center"><![CDATA[
Network
Resource CPE router Access network __________
+-----------+ +--------------+ +-------------+ / \
| |____| |_______| |___ | Internet |
|DOTS client| | DOTS gateway | | DOTS server | | |
| | | | | | | |
+-----------+ +--------------+ +-------------+ \__________/
]]></artwork>
</figure></t>
<t>The DOTS server can also be running on the Internet, as depicted in
<xref target="fig_blah"></xref>.</t>
<figure anchor="fig_blah" title="Sample DOTS Deployment (2)">
<artwork align="center"><![CDATA[
Network DDoS mitigation
Resource CPE router __________ service
+-----------+ +-------------+ / \ +-------------+
| |____| |_______| |___ | |
|DOTS client| |DOTS gateway | | Internet | | DOTS server |
| | | | | | | |
+-----------+ +-------------+ \__________/ +-------------+
]]></artwork>
</figure>
<t></t>
<t>In typical deployments, the DOTS client belongs to a different
administrative domain than the DOTS server. For example, the DOTS client
is a firewall protecting services owned and operated by an domain, while
the DOTS server is owned and operated by a different domain providing
DDoS mitigation services. That domain providing DDoS mitigation service
might, or might not, also provide Internet access service to the website
operator.</t>
<t>The DOTS server may (not) be co-located with the DOTS mitigator. In
typical deployments, the DOTS server belongs to the same administrative
domain as the mitigator.</t>
<t>The DOTS client can communicate directly with the DOTS server or
indirectly via a DOTS gateway.</t>
<t>This document focuses on the DOTS signal channel.</t>
</section>
<section title="Happy Eyeballs for DOTS Signal Channel">
<t>DOTS signaling can happen with DTLS <xref target="RFC6347"></xref>
over UDP and TLS <xref target="RFC5246"></xref> over TCP. A DOTS client
can use DNS to determine the IP address(es) of a DOTS server or a DOTS
client may be provided with the list of DOTS server IP addresses. The
DOTS client MUST know a DOTS server's domain name; hard-coding the
domain name of the DOTS server into software is NOT RECOMMENDED in case
the domain name is not valid or needs to change for legal or other
reasons. The DOTS client performs A and/or AAAA record lookup of the
domain name and the result will be a list of IP addresses, each of which
can be used to contact the DOTS server using UDP and TCP.</t>
<t>If an IPv4 path to reach a DOTS server is found, but the DOTS
server's IPv6 path is not working, a dual-stack DOTS client can
experience a significant connection delay compared to an IPv4-only DOTS
client. The other problem is that if a middlebox between the DOTS client
and DOTS server is configured to block UDP, the DOTS client will fail to
establish a DTLS session with the DOTS server and will, then, have to
fall back to TLS over TCP incurring significant connection delays. <xref
target="I-D.ietf-dots-requirements"></xref> discusses that DOTS client
and server will have to support both connectionless and
connection-oriented protocols.</t>
<t>To overcome these connection setup problems, the DOTS client can try
connecting to the DOTS server using both IPv6 and IPv4, and try both
DTLS over UDP and TLS over TCP in a fashion similar to the Happy
Eyeballs mechanism <xref target="RFC6555"></xref>. These connection
attempts are performed by the DOTS client when its initializes, and the
client uses that information for its subsequent alert to the DOTS
server. In order of preference (most preferred first), it is UDP over
IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which
adheres to <xref target="RFC6724">address preference order</xref> and
the DOTS preference that UDP be used over TCP (to avoid TCP's head of
line blocking).</t>
<t><figure anchor="fig_happy_eyeballs" title="Happy Eyeballs">
<artwork align="center"><![CDATA[
DOTS client DOTS server
| |
|--DTLS ClientHello, IPv6 ---->X |
|--TCP SYN, IPv6-------------->X |
|--DTLS ClientHello, IPv4 ---->X |
|--TCP SYN, IPv4----------------------------------------->|
|--DTLS ClientHello, IPv6 ---->X |
|--TCP SYN, IPv6-------------->X |
|<-TCP SYNACK---------------------------------------------|
|--DTLS ClientHello, IPv4 ---->X |
|--TCP ACK----------------------------------------------->|
|<------------Establish TLS Session---------------------->|
|----------------DOTS signal----------------------------->|
| |
]]></artwork>
</figure></t>
<t>In reference to <xref target="fig_happy_eyeballs"></xref>, the DOTS
client sends two TCP SYNs and two DTLS ClientHello messages at the same
time over IPv6 and IPv4. In this example, it is assumed that the IPv6
path is broken and UDP is dropped by a middle box but has little impact
to the DOTS client because there is no long delay before using IPv4 and
TCP. The DOTS client repeats the mechanism to discover if DOTS signaling
with DTLS over UDP becomes available from the DOTS server, so the DOTS
client can migrate the DOTS signal channel from TCP to UDP, but such
probing SHOULD NOT be done more frequently than every 24 hours and MUST
NOT be done more frequently than every 5 minutes.</t>
</section>
<section title="DOTS Signal Channel">
<section title="Overview">
<t>The DOTS signal channel is built on top of the Constrained
Application Protocol (CoAP) <xref target="RFC7252"></xref>, a
lightweight protocol originally designed for constrained devices and
networks. CoAP’s expectation of packet loss, support for
asynchronous non-confirmable messaging, congestion control, small
message overhead limiting the need for fragmentation, use of minimal
resources, and support for (D)TLS make it a good foundation on which
to build the DOTS signaling mechanism.</t>
<t>The DOTS signal channel is layered on existing standards (<xref
target="fig_dots"></xref>). </t>
<t>TBD: The default port number for DOTS signal channel is 5684
(Section 12.7 of <xref target="RFC7252"></xref> and Section 10.4 of
<xref target="I-D.ietf-core-coap-tcp-tls"></xref>), for both UDP and
TCP.</t>
<t><figure anchor="fig_dots"
title="Abstract Layering of DOTS signal channel over CoAP over (D)TLS">
<artwork align="center"><![CDATA[ +--------------+
| DOTS |
+--------------+
| CoAP |
+--------------+
| TLS | DTLS |
+--------------+
| TCP | UDP |
+--------------+
| IP |
+--------------+
]]></artwork>
</figure></t>
<t>The signal channel is initiated by the DOTS client. Once the signal
channel is established, the DOTS agents periodically send heartbeats
to keep the channel active. At any time, the DOTS client may send a
mitigation request message to the DOTS server over the active channel.
While mitigation is active, the DOTS server periodically sends status
messages to the client, including basic mitigation feedback details.
Mitigation remains active until the DOTS client explicitly terminates
mitigation, or the mitigation lifetime expires.</t>
<t>Messages exchanged between DOTS client and server are serialized
using Concise Binary Object Representation (CBOR) <xref
target="RFC7049"></xref>, CBOR is a binary encoding designed for small
code and message size. CBOR encoded payloads are used to convey signal
channel specific payload messages that convey request parameters and
response information such as errors. This specification uses the
encoding rules defined in <xref
target="I-D.ietf-core-yang-cbor"></xref> for representing mitigation
scope and DOTS signal channel session configuration data defined using
YANG (<xref target="YANG"></xref>) as CBOR data.</t>
<t>DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The
payload included in CoAP responses with 2.xx and 3.xx Response Codes
MUST be of content type "application/cbor" (Section 5.5.1 of <xref
target="RFC7252"></xref>). CoAP responses with 4.xx and 5.xx error
Response Codes MUST include a diagnostic payload (Section 5.5.2 of
<xref target="RFC7252"></xref>). The Diagnostic Payload may contain
additional information to aid troubleshooting.</t>
</section>
<section anchor="YANG" title="DOTS Signal YANG Module">
<t>This document defines a YANG <xref target="RFC6020"></xref> module
for mitigation scope and DOTS signal channel session configuration
data.</t>
<section title="Mitigation Request YANG Module Tree Structure">
<t>This document defines the YANG module "ietf-dots-signal", which
has the following tree structure:<figure>
<artwork><![CDATA[
module: ietf-dots-signal
+--rw mitigation-scope
+--rw scope* [mitigation-id]
+--rw mitigation-id int32
+--rw target-ip* inet:ip-address
+--rw target-prefix* inet:ip-prefix
+--rw target-port-range* [lower-port upper-port]
| +--rw lower-port inet:port-number
| +--rw upper-port inet:port-number
+--rw target-protocol* uint8
+--rw fqdn* inet:domain-name
+--rw uri* inet:uri
+--rw alias-name* string
+--rw lifetime? int32
]]></artwork>
</figure></t>
</section>
<section title="Mitigation Request YANG Module ">
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "[email protected]"
module ietf-dots-signal {
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal";
prefix "signal";
import ietf-inet-types {
prefix "inet";
}
organization "McAfee, Inc.";
contact "Konda, Tirumaleswar Reddy <[email protected]>";
description
"This module contains YANG definition for DOTS
signal sent by the DOTS client to the DOTS server.";
revision 2017-08-03 {
reference
"https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
}
container mitigation-scope {
description
"Top level container for a mitigation request.";
list scope {
key mitigation-id;
description "Identifier for the mitigation request.";
leaf mitigation-id {
type int32;
description "Mitigation request identifier.";
}
leaf-list target-ip {
type inet:ip-address;
description
"IPv4 or IPv6 address identifyting the target.";
}
leaf-list target-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifyting the target.";
}
list target-port-range {
key "lower-port upper-port";
description "Port range. When only lower-port is present,
it represents a single port.";
leaf lower-port {
type inet:port-number;
mandatory true;
description "Lower port number.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
error-message
"The upper port number must be greater than or
equal to lower port number.";
}
description "Upper port number.";
}
}
leaf-list target-protocol {
type uint8;
description "Identifies the target protocol number.";
}
leaf-list fqdn {
type inet:domain-name;
description "FQDN";
}
leaf-list uri {
type inet:uri;
description "URI";
}
leaf-list alias-name {
type string;
description "alias name";
}
leaf lifetime {
type int32;
description
"Indicates the lifetime of the mitigation request.";
}
}
}
}
<CODE ENDS>]]></artwork>
</figure></t>
</section>
<section title="Session Configuration YANG Module Tree Structure">
<t>This document defines the YANG module "ietf-dots-signal-config",
which has the following structure:<figure>
<artwork><![CDATA[
module: ietf-dots-signal-config
+--rw signal-config
+--rw session-id? int32
+--rw heartbeat-interval? int16
+--rw missing-hb-allowed? int16
+--rw max-retransmit? int16
+--rw ack-timeout? int16
+--rw ack-random-factor? decimal64
+--rw trigger-mitigation? boolean]]></artwork>
</figure></t>
</section>
<section title="Session Configuration YANG Module ">
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "[email protected]"
module ietf-dots-signal-config {
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config";
prefix "config";
organization "McAfee, Inc.";
contact "Konda, Tirumaleswar Reddy <[email protected]>";
description
"This module contains YANG definition for DOTS
signal channel session configuration.";
revision 2016-11-28 {
reference
"https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
}
container signal-config {
description "Top level container for DOTS signal channel session
configuration.";
leaf session-id {
type int32;
description "An identifier for the DOTS signal channel
session configuration data.";
}
leaf heartbeat-interval {
type int16;
description
"DOTS agents regularly send heartbeats to each other
after mutual authentication in order to keep
the DOTS signal channel open.";
}
leaf missing-hb-allowed {
type int16;
description
"Maximum number of missing heartbeats allowed";
}
leaf max-retransmit {
type int16;
description
"Maximum number of retransmissions of a
Confirmable message.";
}
leaf ack-timeout {
type int16;
description
"Initial retransmission timeout value.";
}
leaf ack-random-factor {
type decimal64 {
fraction-digits 2;
}
description
"Random factor used to influence the timing of
retransmissions";
}
leaf trigger-mitigation {
type boolean;
default true;
description
"If false, then mitigation is triggered
only when the DOTS server channel session is lost";
}
}
}
<CODE ENDS>]]></artwork>
</figure></t>
</section>
</section>
<section anchor="m_req" title="Mitigation Request">
<t>The following methods are used to request or withdraw mitigation
requests:<list style="hanging">
<t hangText="PUT:">DOTS clients use the PUT method to request
mitigation (<xref target="post"></xref>). During active
mitigation, DOTS clients may use PUT requests to convey mitigation
efficacy updates to the DOTS server (<xref
target="put"></xref>).</t>
<t hangText="DELETE:">DOTS clients use the DELETE method to
withdraw a request for mitigation from the DOTS server (<xref
target="del"></xref>).</t>
<t hangText="GET:">DOTS clients may use the GET method to
subscribe to DOTS server status messages, or to retrieve the list
of existing mitigations (<xref target="get"></xref>).</t>
</list></t>
<t>Mitigation request and response messages are marked as
Non-confirmable messages. DOTS agents should follow the data
transmission guidelines discussed in Section 3.1.3 of <xref
target="RFC8085"></xref> and control transmission behavior by not
sending on average more than one UDP datagram per RTT to the peer DOTS
agent. Requests marked by the DOTS client as Non-confirmable messages
are sent at regular intervals until a response is received from the
DOTS server and if the DOTS client cannot maintain a RTT estimate then
it SHOULD NOT send more than one Non-confirmable request every 3
seconds, and SHOULD use an even less aggressive rate when possible
(case 2 in Section 3.1.3 of <xref target="RFC8085"></xref>).</t>
<section anchor="post" title="Requesting mitigation">
<t>When a DOTS client requires mitigation for any reason, the DOTS
client uses CoAP PUT method to send a mitigation request to the DOTS
server (<xref target="Figure1"></xref>, illustrated in JSON
diagnostic notation). The DOTS server can enable mitigation on
behalf of the DOTS client by communicating the DOTS client's request
to the mitigator and relaying selected mitigator feedback to the
requesting DOTS client.</t>
<t><figure anchor="Figure1" title="PUT to convey DOTS signals">
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03)
Uri-Host: "host"
Uri-Path: "version"
Uri-Path: "dots-signal"
Uri-Path: "signal"
Content-Type: "application/cbor"
{
"mitigation-scope": {
"scope": [
{
"mitigation-id": integer,
"target-ip": [
"string"
],
"target-prefix": [
"string"
],
"target-port-range": [
{
"lower-port": integer,
"upper-port": integer
}
],
"target-protocol": [
integer
],
"fqdn": [
"string"
],
"uri": [
"string"
],
"alias-name": [
"string"
],
"lifetime": integer
}
]
}
}
]]></artwork>
</figure></t>
<t>The parameters are described below.</t>
<t><list style="hanging">
<t hangText="mitigation-id:">Identifier for the mitigation
request represented using an integer. This identifier MUST be
unique for each mitigation request bound to the DOTS client,
i.e., the mitigation-id parameter value in the mitigation
request needs to be unique relative to the mitigation-id
parameter values of active mitigation requests conveyed from the
DOTS client to the DOTS server. This identifier MUST be
generated by the DOTS client. This document does not make any
assumption about how this identifier is generated. This is a
mandatory attribute.</t>
<t hangText="target-ip:">A list of IP addresses under attack.
This is an optional attribute.</t>
<t hangText="target-prefix:">A list of prefixes under attack.
Prefixes are represented using CIDR notation <xref
target="RFC4632"></xref>. This is an optional attribute.</t>
<t hangText="target-port-range:">A list of ports under attack.
The port range, lower-port for lower port number and upper-port
for upper port number. When only lower-port is present, it
represents a single port. For TCP, UDP, SCTP, or DCCP: the range
of ports (e.g., 1024-65535). This is an optional attribute.</t>
<t hangText="target-protocol:">A list of protocols under attack.
Values are taken from the IANA protocol registry <xref
target="proto_numbers"></xref>. The value 0 has a special
meaning for 'all protocols'. This is an optional attribute.</t>
<t hangText="fqdn: ">A list of Fully Qualified Domain Names.
Fully Qualified Domain Name (FQDN) is the full name of a system,
rather than just its hostname. For example, "venera" is a
hostname, and "venera.isi.edu" is an FQDN. This is an optional
attribute.</t>
<t hangText="uri: ">A list of Uniform Resource Identifiers
(URI). This is an optional attribute.</t>
<t hangText="alias-name:">A list of aliases. Aliases can be
created using the DOTS data channel (Section 3.1.1 of <xref
target="I-D.ietf-dots-data-channel"></xref>) or direct
configuration, or other means and then used in subsequent signal
channel exchanges to refer more efficiently to the resources
under attack. This is an optional attribute.</t>
<t hangText="lifetime: ">Lifetime of the mitigation request in
seconds. Upon the expiry of this lifetime, and if the request is
not refreshed, the mitigation request is removed. The request
can be refreshed by sending the same request again. The default
lifetime of the mitigation request is 3600 seconds (60 minutes)
-- this value was chosen to be long enough so that refreshing is
not typically a burden on the DOTS client, while expiring the
request where the client has unexpectedly quit in a timely
manner. A lifetime of negative one (-1) indicates indefinite
lifetime for the mitigation request. The server MUST always
indicate the actual lifetime in the response and the remaining
lifetime in status messages sent to the client. This is an
optional attribute in the request.</t>
</list></t>
<t>The CBOR key values for the parameters are defined in <xref
target="mapping"></xref>. The IANA Considerations section defines
how the CBOR key values can be allocated to standards bodies and
vendors. FQDN and URI mitigation scopes may be thought of as a form
of scope alias, in which the addresses to which the domain name or
URI resolve represent the full scope of the mitigation. In the PUT
request at least one of the attributes target-ip or target-prefix or
fqdn or uri or alias-name MUST be present. DOTS agents can safely
ignore Vendor-Specific parameters they don't understand. The
relative order of two mitigation requests from a DOTS client is
determined by comparing their respective mitigation-id values. If
two mitigation requests have overlapping mitigation scopes the
mitigation request with higher numeric mitigation-id value will
override the mitigation request with a lower numeric mitigation-id
value. Two mitigation-ids are overlapping if there is a common IP,
IP Prefix, FQDN, URI or alias-name. The overlapped lower numeric
mitigation-id is automatically deleted and no longer available at
the DOTS server. The Uri-Path option carries a major and minor
version nomenclature to manage versioning and DOTS signal channel in
this specification uses v1 major version.</t>
<t>In both DOTS signal and data channel sessions, the DOTS client
MUST authenticate itself to the DOTS server (<xref
target="mutauth"></xref>). The DOTS server can use the algorithm
discussed in Section 7 of <xref target="RFC7589"></xref> to derive
the DOTS client identity or username from the client certificate.
The DOTS server couples the DOTS signal and data channel sessions
using the DOTS client identity, so the DOTS server can validate
whether the aliases conveyed in the mitigation request were indeed
created by the same DOTS client using the DOTS data channel session.
If the aliases were not created by the DOTS client then the DOTS
server returns 4.00 (Bad Request) in the response. The DOTS server
couples the DOTS signal channel sessions using the DOTS client
identity, and the DOTS server uses mitigation-id parameter value to
detect duplicate mitigation requests. If the mitigation request
contains both alias-name and other parameters identifying the target
resources (such as, target-ip, target-prefix, target-port-range,
fqdn, or uri) then the DOTS server appends the parameter values in
alias-name with the corresponding parameter values in target-ip,
target-prefix, target-port-range, fqdn, or uri.</t>
<t><xref target="Figure2"></xref> shows an PUT request example to
signal that ports 80, 8080, and 443 on the servers 2001:db8:6401::1
and 2001:db8:6401::2 are being attacked (illustrated in JSON
diagnostic notation).</t>
<t><figure anchor="Figure2" title="PUT for DOTS signal">
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03)
Uri-Host: "www.example.com"
Uri-Path: "v1"
Uri-Path: "dots-signal"
Uri-Path: "signal"
Content-Format: "application/cbor"
{
"mitigation-scope": {
"scope": [
{
"mitigation-id": 12332,
"target-ip": [
"2001:db8:6401::1",
"2001:db8:6401::2"
],
"target-port-range": [
{
"lower-port": 80
},
{
"lower-port": 443
},
{
"lower-port": 8080
}
],
"target-protocol": [
6
]
}
]
}
}
The CBOR encoding format is shown below:
a1 # map(1)
01 # unsigned(1)
a1 # map(1)
02 # unsigned(2)
81 # array(1)
a4 # map(4)
03 # unsigned(3)
19 302c # unsigned(12332)
04 # unsigned(4)
82 # array(2)
70 # text(16)
323030313A6462383A363430313A3A31 # "2001:db8:6401::1"
70 # text(16)
323030313A6462383A363430313A3A32 # "2001:db8:6401::2"
05 # unsigned(5)
83 # array(3)
a1 # map(1)
06 # unsigned(6)
18 50 # unsigned(80)
a1 # map(1)
06 # unsigned(6)
19 01bb # unsigned(443)
a1 # map(1)
06 # unsigned(6)
19 1f90 # unsigned(8080)
08 # unsigned(8)
81 # array(1)
06 # unsigned(6)
]]></artwork>
</figure>The DOTS server indicates the result of processing the
PUT request using CoAP response codes. CoAP 2.xx codes are success.
CoAP 4.xx codes are some sort of invalid requests. <xref
target="put_response"></xref> shows an PUT response for CoAP 2.xx
response codes.</t>
<t><figure anchor="put_response" title="2.xx response body">
<artwork align="left"><![CDATA[{
"mitigation-scope": {
"scope": [
{
"mitigation-id": integer,
"lifetime": integer
}
]
}
}
]]></artwork>
</figure></t>
<t>COAP 5.xx codes are returned if the DOTS server has erred or is
currently unavailable to provide mitigation in response to the
mitigation request from the DOTS client. If the DOTS server does not
find the mitigation-id parameter value conveyed in the PUT request
in its configuration data then the server MAY accept the mitigation
request, and a 2.01 (Created) response is returned to the DOTS
client, and the DOTS server will try to mitigate the attack. If the
DOTS server finds the mitigation-id parameter value conveyed in the
PUT request in its configuration data then the server MAY update the
mitigation request, and a 2.04 (Changed) response is returned to
indicate a successful update of the mitigation request. If the
request is missing one or more mandatory attributes, then 4.00 (Bad
Request) will be returned in the response or if the request contains
invalid or unknown parameters then 4.02 (Invalid query) will be
returned in the response. </t>
<t>For the mitigation request to continue beyond the initial
negotiated lifetime, the DOTS client will need to refresh the
current mitigation request by sending a new PUT request. The PUT
request MUST use the same mitigation-id value, and MUST repeat all
the other parameters as sent in the original mitigation request
apart from a possible change to the lifetime parameter value.</t>
</section>
<section anchor="del" title="Withdraw a DOTS Signal">
<t>A DELETE request is used to withdraw a DOTS signal from a DOTS
server (<xref target="Figure3"></xref>).</t>
<figure anchor="Figure3" title="Withdraw DOTS signal">
<artwork align="left"><![CDATA[ Header: DELETE (Code=0.04)
Uri-Host: "host"
Uri-Path: "version"
Uri-Path: "dots-signal"
Uri-Path: "signal"
Content-Format: "application/cbor"
{
"mitigation-scope": {
"scope": [
{
"mitigation-id": integer
}
]
}
}
]]></artwork>
</figure>
<t></t>
<t>The DOTS server immediately acknowledges a DOTS client's request
to withdraw the DOTS signal using 2.02 (Deleted) response code with
no response payload. A 2.02 (Deleted) Response Code is returned even
if the mitigation-id parameter value conveyed in the DELETE request
does not exist in its configuration data before the request. If the
DOTS server finds the mitigation-id parameter value conveyed in the
DELETE request in its configuration data, then to protect against
route or DNS flapping caused by a client rapidly toggling
mitigation, and to dampen the effect of oscillating attacks, DOTS
servers MAY allow mitigation to continue for a limited period after
acknowledging a DOTS client's withdrawal of a mitigation request.
During this period, DOTS server status messages SHOULD indicate that
mitigation is active but terminating. The active-but-terminating
period is initially 30 seconds. If the client requests mitigation
again before that 30 second window elapses, the DOTS server MAY
exponentially increase the active- but-terminating period up to a
maximum of 240 seconds (4 minutes). After the active-but-terminating
period elapses, the DOTS server MUST treat the mitigation as
terminated, as the DOTS client is no longer responsible for the
mitigation. For example, if there is a financial relationship
between the DOTS client and server domains, the DOTS client ceases
incurring cost at this point.</t>
</section>
<section anchor="get" title="Retrieving a DOTS Signal">
<t>A GET request is used to retrieve information and status of a
DOTS signal from a DOTS server (<xref target="Figure4"></xref>). If
the DOTS server does not find the mitigation-id parameter value
conveyed in the GET request in its configuration data, then it
responds with a 4.04 (Not Found) error response code. The 'c'
(content) parameter and its permitted values defined in <xref
target="I-D.ietf-core-comi"></xref> can be used to retrieve
non-configuration data or configuration data or both.</t>
<figure anchor="Figure4" title="GET to retrieve the rules">
<artwork align="left"><![CDATA[1) To retrieve all DOTS signals signaled by the DOTS client.
Header: GET (Code=0.01)
Uri-Host: "host"
Uri-Path: "version"
Uri-Path: "dots-signal"
Uri-Path: "signal"
Observe : 0
2) To retrieve a specific DOTS signal signaled by the DOTS client.
The configuration data in the response will be formatted in the
same order it was processed at the DOTS server.
Header: GET (Code=0.01)
Uri-Host: "host"
Uri-Path: "version"
Uri-Path: "dots-signal"
Uri-Path: "signal"
Observe : 0
Content-Format: "application/cbor"
{
"mitigation-scope": {
"scope": [
{
"mitigation-id": integer
}