-
Notifications
You must be signed in to change notification settings - Fork 10
/
oc2slpf-v1.0-cs01.html
1792 lines (1792 loc) · 140 KB
/
oc2slpf-v1.0-cs01.html
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
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
<head>
<meta name="description" content="This profile defines the actions, targets, specifiers and options that are consistent with the OpenC2 Language Specification in the context of stateless packet filtering.">
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0</title>
<link rel="stylesheet" href="styles/markdown-styles-v1.7.3.css" />
</head>
<body>
<p><img src="https://docs.oasis-open.org/templates/OASISLogo-v2.0.jpg" alt="OASIS Logo" /></p>
<hr style="page-break-before: avoid" />
<h1big id="open-command-and-control-openc2-profile-for-stateless-packet-filtering-version-10">Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0</h1big>
<h2 id="committee-specification-01">Committee Specification 01</h2>
<h2 id="11-july-2019">11 July 2019</h2>
<br />
<h4 id="this-version">This version:</h4>
<p><a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.md">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.html">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.pdf">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.pdf</a></p>
<h4 id="previous-version">Previous version:</h4>
<p><a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/csprd02/oc2slpf-v1.0-csprd02.md">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/csprd02/oc2slpf-v1.0-csprd02.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/csprd02/oc2slpf-v1.0-csprd02.html">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/csprd02/oc2slpf-v1.0-csprd02.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/csprd02/oc2slpf-v1.0-csprd02.pdf">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/csprd02/oc2slpf-v1.0-csprd02.pdf</a></p>
<h4 id="latest-version">Latest version:</h4>
<p><a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.md">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.pdf">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.pdf</a></p>
<h4 id="technical-committee">Technical Committee:</h4>
<p><a href="https://www.oasis-open.org/committees/openc2/">OASIS Open Command and Control (OpenC2) TC</a></p>
<h4 id="chairs">Chairs:</h4>
<p>Joe Brule (<a href="mailto:jmbrule@nsa.gov">jmbrule@nsa.gov</a>), <a href="https://www.nsa.gov/">National Security Agency</a> <br />
Duncan Sparrell (<a href="mailto:duncan@sfractal.com">duncan@sfractal.com</a>), <a href="http://www.sfractal.com/">sFractal Consulting LLC</a></p>
<h4 id="editors">Editors:</h4>
<p>Joe Brule (<a href="mailto:jmbrule@nsa.gov">jmbrule@nsa.gov</a>), <a href="https://www.nsa.gov/">National Security Agency</a> <br />
Duncan Sparrell (<a href="mailto:duncan@sfractal.com">duncan@sfractal.com</a>), <a href="http://www.sfractal.com/">sFractal Consulting</a> <br />
Alex Everett (<a href="mailto:alex.everett@unc.edu">alex.everett@unc.edu</a>), <a href="http://www.unc.edu/">University of North Carolina, Chapel Hill</a></p>
<h4 id="abstract">Abstract:</h4>
<p>Open Command and Control (OpenC2) is a concise and extensible language to enable the command and control of cyber defense components, subsystems and/or systems in a manner that is agnostic of the underlying products, technologies, transport mechanisms or other aspects of the implementation. Stateless packet filtering is a cyber defense mechanism that denies or allows traffic based on static properties of the traffic, such as address, port, protocol, etc. This profile defines the Actions, Targets, Specifiers and Options that are consistent with the version 1.0 of the OpenC2 Language Specification (<a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a>) in the context of stateless packet filtering (SLPF).</p>
<h4 id="status">Status:</h4>
<p>This document was last revised or approved by the OASIS Open Command and Control (OpenC2) TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at <a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical">https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical</a>.</p>
<p>TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at <a href="https://www.oasis-open.org/committees/openc2/">https://www.oasis-open.org/committees/openc2/</a>.</p>
<p>This specification is provided under the <a href="https://www.oasis-open.org/policies-guidelines/ipr#Non-Assertion-Mode">Non-Assertion</a> Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (<a href="https://www.oasis-open.org/committees/openc2/ipr.php">https://www.oasis-open.org/committees/openc2/ipr.php</a>).</p>
<p>Note that any machine-readable content (<a href="https://www.oasis-open.org/policies-guidelines/tc-process#wpComponentsCompLang">Computer Language Definitions</a>) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.</p>
<h4 id="citation-format">Citation format:</h4>
<p>When referencing this specification the following citation format should be used:</p>
<p><strong>[OpenC2-SLPF-v1.0]</strong> <em>Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0</em>. Edited by Joe Brule, Duncan Sparrell and Alex Everett. 11 July 2019. Committee Specification 01. <a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.html">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/cs01/oc2slpf-v1.0-cs01.html</a>. Latest version: <a href="https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html">https://docs.oasis-open.org/openc2/oc2slpf/v1.0/oc2slpf-v1.0.html</a>.</p>
<hr />
<h2 id="notices">Notices</h2>
<p>Copyright © OASIS Open 2019. All Rights Reserved.</p>
<p>All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full <a href="https://www.oasis-open.org/policies-guidelines/ipr">Policy</a> may be found at the OASIS website.</p>
<p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.</p>
<p>The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.</p>
<p>This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<p>OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.</p>
<p>OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.</p>
<p>OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.</p>
<p>The name "OASIS" is a trademark of <a href="https://www.oasis-open.org/">OASIS</a>, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see <a href="https://www.oasis-open.org/policies-guidelines/trademark">https://www.oasis-open.org/policies-guidelines/trademark</a> for above guidance.</p>
<hr />
<h1 id="table-of-contents">Table of Contents</h1>
<ul type="none">
<li><a href="#1-introduction">1 Introduction</a>
<ul type="none">
<li><a href="#11-ipr-policy">1.1 IPR Policy</a></li>
<li><a href="#12-terminology">1.2 Terminology</a></li>
<li><a href="#13-normative-references">1.3 Normative References</a></li>
<li><a href="#14-non-normative-references">1.4 Non-Normative References</a></li>
<li><a href="#15-document-conventions">1.5 Document Conventions</a>
<ul type="none">
<li><a href="#151-naming-conventions">1.5.1 Naming Conventions</a></li>
<li><a href="#152-font-colors-and-style">1.5.2 Font Colors and Style</a></li>
</ul></li>
<li><a href="#16-overview">1.6 Overview</a></li>
<li><a href="#17-goal">1.7 Goal</a></li>
<li><a href="#18-purpose-and-scope">1.8 Purpose and Scope</a></li>
</ul></li>
<li><a href="#2-openc2-language-binding">2 OpenC2 Language Binding</a>
<ul type="none">
<li><a href="#21-openc2-command-components">2.1 OpenC2 Command Components</a>
<ul type="none">
<li><a href="#211-actions">2.1.1 Actions</a></li>
<li><a href="#212-targets">2.1.2 Targets</a></li>
<li><a href="#213-command-arguments">2.1.3 Command Arguments</a></li>
<li><a href="#214-actuator-specifiers">2.1.4 Actuator Specifiers</a></li>
</ul></li>
<li><a href="#22-openc2-response-components">2.2 OpenC2 Response Components</a>
<ul type="none">
<li><a href="#221-common-results">2.2.1 Common Results</a></li>
<li><a href="#222-slpf-results">2.2.2 SLPF Results</a></li>
<li><a href="#223-response-status-codes">2.2.3 Response Status Codes</a></li>
</ul></li>
<li><a href="#23-openc2-commands">2.3 OpenC2 Commands</a>
<ul type="none">
<li><a href="#231-allow">2.3.1 Allow</a></li>
<li><a href="#232-deny">2.3.2 Deny</a></li>
<li><a href="#233-query">2.3.3 Query</a></li>
<li><a href="#234-delete">2.3.4 Delete</a></li>
<li><a href="#235-update">2.3.5 Update</a></li>
</ul></li>
</ul></li>
<li><a href="#3-conformance-statements">3 Conformance statements</a>
<ul type="none">
<li><a href="#31-clauses-pertaining-to-the-openc2-producer-conformance-target">3.1 Clauses Pertaining to the OpenC2 Producer Conformance Target</a>
<ul type="none">
<li><a href="#311-conformance-clause-1-baseline-openc2-producer">3.1.1 Conformance Clause 1: Baseline OpenC2 Producer</a></li>
<li><a href="#312-conformance-clause-2-ip-version-4-connection-producer">3.1.2 Conformance Clause 2: IP Version 4 Connection Producer</a></li>
<li><a href="#313-conformance-clause-3-ip-version-6-connection-producer">3.1.3 Conformance Clause 3: IP Version 6 Connection Producer</a></li>
<li><a href="#314-conformance-clause-4-ip-version-4-net-producer">3.1.4 Conformance Clause 4: IP Version 4 Net Producer</a></li>
<li><a href="#315-conformance-clause-5-ip-version-6-net-producer">3.1.5 Conformance Clause 5: IP Version 6 Net Producer</a></li>
<li><a href="#316-conformance-clause-6-update-file-producer">3.1.6 Conformance Clause 6: Update File Producer</a></li>
<li><a href="#317-conformance-clause-7-delete-rule-number-producer">3.1.7 Conformance Clause 7: delete rule number Producer</a></li>
<li><a href="#318-conformance-clause-8-persistent-producer">3.1.8 Conformance Clause 8: Persistent Producer</a></li>
<li><a href="#319-conformance-clause-9-direction-producer">3.1.9 Conformance Clause 9: Direction Producer</a></li>
<li><a href="#3110-conformance-clause-10-drop-process-producer">3.1.10 Conformance Clause 10: drop-process Producer</a></li>
<li><a href="#3111-conformance-clause-11-temporal-producer">3.1.11 Conformance Clause 11: Temporal Producer</a></li>
</ul></li>
<li><a href="#32-clauses-pertaining-to-the-openc2-consumer-conformance-target">3.2 Clauses Pertaining to the OpenC2 Consumer Conformance Target</a>
<ul type="none">
<li><a href="#321-conformance-clause-12-baseline-openc2-consumer">3.2.1 Conformance Clause 12: Baseline OpenC2 Consumer</a></li>
<li><a href="#322-conformance-clause-13-ip-version-4-connection-consumer">3.2.2 Conformance Clause 13: IP Version 4 Connection Consumer</a></li>
<li><a href="#323-conformance-clause-14-ip-version-6-connection-consumer">3.2.3 Conformance Clause 14: IP Version 6 Connection Consumer</a></li>
<li><a href="#324-conformance-clause-15-ip-version-4-net-consumer">3.2.4 Conformance Clause 15: IP Version 4 Net Consumer</a></li>
<li><a href="#325-conformance-clause-16-ip-version-6-net-consumer">3.2.5 Conformance Clause 16: IP Version 6 Net Consumer</a></li>
<li><a href="#326-conformance-clause-17-update-file-consumer">3.2.6 Conformance Clause 17: Update File Consumer</a></li>
<li><a href="#327-conformance-clause-18-delete-rule-number-consumer">3.2.7 Conformance Clause 18: delete rule number Consumer</a></li>
<li><a href="#328-conformance-clause-19-persistent-consumer">3.2.8 Conformance Clause 19: Persistent Consumer</a></li>
<li><a href="#329-conformance-clause-20-direction-consumer">3.2.9 Conformance Clause 20: Direction Consumer</a></li>
<li><a href="#3210-conformance-clause-21-drop-process-consumer">3.2.10 Conformance Clause 21: drop-process Consumer</a></li>
<li><a href="#3211-conformance-clause-22-temporal-consumer">3.2.11 Conformance Clause 22: Temporal Consumer</a></li>
</ul></li>
</ul></li>
<li><a href="#annex-a-sample-commands">Annex A: Sample Commands</a>
<ul type="none">
<li><a href="#a1-deny-and-allow">A.1 Deny and Allow</a>
<ul type="none">
<li><a href="#a11-deny-a-particular-connection">A.1.1 Deny a particular connection</a></li>
<li><a href="#a12-deny-all-outbound-ftp-transfers">A.1.2 Deny all outbound ftp transfers</a></li>
<li><a href="#a13-block-all-inbound-traffic-from-a-particular-source">A.1.3 Block all inbound traffic from a particular source.</a></li>
<li><a href="#a14-permit-ftp-transfers-to-a-particular-destination">A.1.4 Permit ftp transfers to a particular destination.</a></li>
</ul></li>
<li><a href="#a2-delete-rule">A.2 Delete Rule</a></li>
<li><a href="#a3-update-file">A.3 Update file</a></li>
<li><a href="#a4-query-features">A.4 Query features</a>
<ul type="none">
<li><a href="#a41-no-query-items-set">A.4.1 No query items set</a></li>
<li><a href="#a42-version-of-language-specification-supported">A.4.2 Version of Language specification supported</a></li>
<li><a href="#a43-actuator-profiles-supported">A.4.3 Actuator profiles supported</a></li>
<li><a href="#a44-specific-commands-supported">A.4.4 Specific Commands Supported</a></li>
</ul></li>
</ul></li>
<li><a href="#annex-b-acronyms">Annex B: Acronyms</a></li>
<li><a href="#annex-c-acknowledgments">Annex C: Acknowledgments</a></li>
<li><a href="#annex-d-revision-history">Annex D: Revision History</a></li>
</ul>
<hr />
<h1 id="1-introduction">1 Introduction</h1>
<p><em>The content in this section is non-normative, except where it is marked normative.</em></p>
<p>OpenC2 is a suite of specifications that enables command and control of cyber defense systems and components. OpenC2 typically uses a request-response paradigm where a <em>Command</em> is encoded by a <em>Producer</em> (managing application) and transferred to a <em>Consumer</em> (managed device or virtualized function) using a secure transfer protocol, and the Consumer can respond with status and any requested information.</p>
<p>OpenC2 allows the application producing the commands to discover the set of capabilities supported by the managed devices. These capabilities permit the managing application to adjust its behavior to take advantage of the features exposed by the managed device. The capability definitions can be easily extended in a noncentralized manner, allowing standard and non-standard capabilities to be defined with semantic and syntactic rigor.</p>
<h2 id="11-ipr-policy">1.1 IPR Policy</h2>
<p>This specification is provided under the <a href="https://www.oasis-open.org/policies-guidelines/ipr#Non-Assertion-Mode">Non-Assertion</a> Mode of the <a href="https://www.oasis-open.org/policies-guidelines/ipr">OASIS IPR Policy</a>, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (<a href="https://www.oasis-open.org/committees/openc2/ipr.php">https://www.oasis-open.org/committees/openc2/ipr.php</a>).</p>
<h2 id="12-terminology">1.2 Terminology</h2>
<p><em>This section is normative.</em></p>
<ul type="none">
<li><strong>Action</strong>: The task or activity to be performed (e.g., 'deny').</li>
<li><strong>Actuator</strong>: The function performed by the Consumer that executes the Command (e.g., 'Stateless Packet Filtering').</li>
<li><strong>Argument</strong>: A property of a Command that provides additional information on how to perform the Command, such as date/time, periodicity, duration, etc.</li>
<li><strong>Command</strong>: A Message defined by an Action-Target pair that is sent from a Producer and received by a Consumer.</li>
<li><strong>Consumer</strong>: A managed device / application that receives Commands. Note that a single device / application can have both Consumer and Producer capabilities.</li>
<li><strong>Message</strong>: A content- and transport-independent set of elements conveyed between Consumers and Producers.</li>
<li><strong>Producer</strong>: A manager application that sends Commands.</li>
<li><strong>Response</strong>: A Message from a Consumer to a Producer acknowledging a Command or returning the requested resources or status to a previously received Command.</li>
<li><strong>Specifier</strong>: A property or field that identifies a Target or Actuator to some level of precision.</li>
<li><strong>Target</strong>: The object of the Action, i.e., the Action is performed on the Target (e.g., IP Address).</li>
</ul>
<p>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 <a href="#rfc2119">[RFC2119]</a> and <a href="#rfc8174">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here.</p>
<h2 id="13-normative-references">1.3 Normative References</h2>
<h6 id="rfc1123">[RFC1123]</h6>
<p>Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <a href="https://www.rfc-editor.org/info/rfc1123">https://www.rfc-editor.org/info/rfc1123</a>.</p>
<h6 id="rfc2119">[RFC2119]</h6>
<p>Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>.</p>
<h6 id="rfc2780">[RFC2780]</h6>
<p>Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <a href="https://www.rfc-editor.org/info/rfc2780">https://www.rfc-editor.org/info/rfc2780</a>.</p>
<h6 id="rfc4443">[RFC4443]</h6>
<p>Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <a href="https://www.rfc-editor.org/info/rfc4443">https://www.rfc-editor.org/info/rfc4443</a>.</p>
<h6 id="rfc8174">[RFC8174]</h6>
<p>Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>.</p>
<h6 id="rfc8259">[RFC8259]</h6>
<p>Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>.</p>
<h6 id="openc2-lang-v10">[OpenC2-Lang-v1.0]</h6>
<p><em>Open Command and Control (OpenC2) Language Specification Version 1.0</em>. Edited by Jason Romano and Duncan Sparrell. November 2018, <a href="http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html">http://docs.oasis-open.org/openc2/oc2ls/v1.0/oc2ls-v1.0.html</a>.</p>
<h2 id="14-non-normative-references">1.4 Non-Normative References</h2>
<h6 id="rfc3339">[RFC3339]</h6>
<p>Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <a href="https://www.rfc-editor.org/info/rfc3339">https://www.rfc-editor.org/info/rfc3339</a>.</p>
<h6 id="rfc4291">[RFC4291]</h6>
<p>Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <a href="https://www.rfc-editor.org/info/rfc4291">https://www.rfc-editor.org/info/rfc4291</a>.</p>
<h6 id="rfc6891">[RFC6891]</h6>
<p>Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <a href="https://www.rfc-editor.org/info/rfc6891">https://www.rfc-editor.org/info/rfc6891</a>..</p>
<h6 id="rfc5237">[RFC5237]</h6>
<p>Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, DOI 10.17487/RFC5237, February 2008, <a href="https://www.rfc-editor.org/info/rfc5237">https://www.rfc-editor.org/info/rfc5237</a>.</p>
<h6 id="openc2-https-v10">[OpenC2-HTTPS-v1.0]</h6>
<p>Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0. Edited by David Lemire. November, 2018, <a href="http://docs.oasis-open.org/openc2/open-impl-https/v1.0/open-impl-https-v1.0.html">http://docs.oasis-open.org/openc2/open-impl-https/v1.0/open-impl-https-v1.0.html</a>.</p>
<h6 id="acd">[ACD]</h6>
<p>Herring, M.J. and Willett, K.D. "Active Cyber Defense: A Vision for Real-Time Cyber Defense," Journal of Information Warfare, vol. 13, Issue 2, p. 80, April 2014, <a href="https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8">https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8</a>.</p>
<h6 id="iacd">[IACD]</h6>
<p>Willett, Keith D., "Integrated Adaptive Cyberspace Defense: Secure Orchestration", International Command and Control Research and Technology Symposium, June 2015 <a href="https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762">https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762</a>.</p>
<h2 id="15-document-conventions">1.5 Document Conventions</h2>
<h3 id="151-naming-conventions">1.5.1 Naming Conventions</h3>
<ul>
<li><a href="#rfc2119">[RFC2119]</a>/<a href="#rfc8174">[RFC8174]</a> key words (see <a href="#12-terminology">Section 1.2</a>) are in all uppercase.</li>
<li>All property names and literals are in lowercase, except when referencing canonical names defined in another standard (e.g., literal values from an IANA registry).</li>
<li>Words in property names are separated with an underscore (_), while words in string enumerations and type names are separated with a hyphen (-).</li>
<li>The term "hyphen" used here refers to the ASCII hyphen or minus character, which in Unicode is "hyphen-minus", U+002D.</li>
</ul>
<h3 id="152-font-colors-and-style">1.5.2 Font Colors and Style</h3>
<p>The following color, font and font style conventions are used in this document:</p>
<ul>
<li>A fixed width font is used for all type names, property names, and literals.</li>
<li>Property names are in bold style – <strong>'created_at'</strong>.</li>
<li>All examples in this document are expressed in JSON. They are in fixed width font, with straight quotes, black text and a light shaded background, and 4-space indentation. JSON examples in this document are representations of JSON Objects. They should not be interpreted as string literals. The ordering of object keys is insignificant. Whitespace before or after JSON structural characters in the examples are insignificant <a href="#rfc8259">[RFC8259]</a>.</li>
<li>Parts of the example may be omitted for conciseness and clarity. These omitted parts are denoted with ellipses (...).</li>
</ul>
<p>Example:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode json"><code class="sourceCode json"><a class="sourceLine" id="cb1-1" title="1"><span class="fu">{</span></a>
<a class="sourceLine" id="cb1-2" title="2"> <span class="dt">"action"</span><span class="fu">:</span> <span class="st">"deny"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb1-3" title="3"> <span class="dt">"target"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb1-4" title="4"> <span class="dt">"file"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb1-5" title="5"> <span class="dt">"hashes"</span><span class="fu">:</span> <span class="fu">{</span></a>
<a class="sourceLine" id="cb1-6" title="6"> <span class="dt">"sha256"</span><span class="fu">:</span> <span class="st">"22fe72a34f006ea67d26bb7004e2b6941b5c3953d43ae7ec24d41b1a928a6973"</span></a>
<a class="sourceLine" id="cb1-7" title="7"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb1-8" title="8"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb1-9" title="9"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb1-10" title="10"><span class="fu">}</span></a></code></pre></div>
<h2 id="16-overview">1.6 Overview</h2>
<p>In general, there are two types of participants involved in the exchange of OpenC2 Messages, as depicted in Figure 1-1:</p>
<ol>
<li><strong>Producers</strong>: A Producer is an entity that creates Commands to provide instruction to one or more systems to act in accordance with the content of the Command. A Producer may receive and process Responses in conjunction with a Command.</li>
<li><strong>Consumers</strong>: A Consumer is an entity that receives and may act upon a Command. A Consumer may create Responses that provide any information captured or necessary to send back to the Producer.</li>
</ol>
<p><img src="images/image_1.png" alt="OpenC2 Message Exchange" width="650" /></p>
<p><strong>Figure 1-1. OpenC2 Message Exchange</strong></p>
<p>OpenC2 is a suite of specifications for Producers and Consumers to command and execute cyber defense functions. These specifications include the OpenC2 Language Specification, Actuator Profiles, and Transfer Specifications. The OpenC2 Language Specification and Actuator Profile specifications focus on the language content and meaning at the Producer and Consumer of the Command and Response while the transfer specifications focus on the protocols for their exchange.</p>
<ul>
<li>The <strong>OpenC2 Language Specification (<a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a>)</strong> provides the semantics for the essential elements of the language, the structure for Commands and Responses, and the schema that defines the proper syntax for the language elements that represents the Command or Response.</li>
<li><strong>OpenC2 Actuator Profiles</strong> specify the subset of the OpenC2 language relevant in the context of specific Actuator functions. Cyber defense components, devices, systems and/or instances may (in fact are likely to) implement multiple Actuator profiles. Actuator profiles extend the language by defining Specifiers that identify the Actuator to the required level of precision. Actuator Profiles may define Command Arguments and Targets that are relevant and/or unique to those Actuator functions.</li>
<li><strong>OpenC2 Transfer Specifications</strong> utilize existing protocols and standards to implement OpenC2 in specific environments. These standards are used for communications and security functions beyond the scope of the language, such as message transfer encoding, authentication, and end-to-end transport of OpenC2 Messages.</li>
</ul>
<p>The OpenC2 Language Specification defines a language used to compose Messages for command and control of cyber defense systems and components. A Message consists of a header and a payload (<em>defined</em> as a Message body in the OpenC2 Language Specification Version 1.0 and <em>specified</em> in one or more Actuator profiles).</p>
<p>The language defines two payload structures:</p>
<ol>
<li><strong>Command</strong>: An instruction from one system known as the Producer, to one or more systems, the Consumer(s), to act on the content of the Command.</li>
<li><strong>Response</strong>: Any information sent back to the Producer as a result of the Command.</li>
</ol>
<p>OpenC2 implementations integrate the related OpenC2 specifications described above with related industry specifications, protocols, and standards. Figure 1-2 depicts the relationships among OpenC2 specifications, and their relationships to other industry standards and environment-specific implementations of OpenC2. Note that the layering of implementation aspects in the diagram is notional, and not intended to preclude any particular approach to implementing the needed functionality (for example, the use of an application-layer message signature function to provide message source authentication and integrity).</p>
<p><img src="images/image_2.png" alt="OpenC2 Documentation and Layering Model" width="650" /></p>
<p><strong>Figure 1-2. OpenC2 Documentation and Layering Model</strong></p>
<p>OpenC2 is conceptually partitioned into four layers as shown in Table 1-1.</p>
<p><strong>Table 1-1. OpenC2 Protocol Layers</strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Layer</th>
<th style="text-align: left;">Examples</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">Function-Specific Content</td>
<td style="text-align: left;">Actuator Profiles<br>(standard and extensions)</td>
</tr>
<tr class="even">
<td style="text-align: left;">Common Content</td>
<td style="text-align: left;">Language Specification<br><a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a></td>
</tr>
<tr class="odd">
<td style="text-align: left;">Message</td>
<td style="text-align: left;">Transfer Specifications<br>(<a href="#openc2-https-v10">[OpenC2-HTTPS-v1.0]</a>, OpenC2-over-CoAP, ...)</td>
</tr>
<tr class="even">
<td style="text-align: left;">Secure Transport</td>
<td style="text-align: left;">HTTPS, CoAP, MQTT, OpenDXL, ...</td>
</tr>
</tbody>
</table>
<ul>
<li>The <strong>Secure Transport</strong> layer provides a communication path between the Producer and the Consumer. OpenC2 can be layered over any standard transport protocol.</li>
<li>The <strong>Message</strong> layer provides a transfer- and content-independent mechanism for conveying Messages. A transfer specification maps transfer-specific protocol elements to a transfer-independent set of message elements consisting of content and associated metadata.</li>
<li>The <strong>Common Content</strong> layer defines the structure of Commands and Responses and a set of common language elements used to construct them.</li>
<li>The <strong>Function-specific Content</strong> layer defines the language elements used to support a particular cyber defense function. An Actuator profile defines the implementation conformance requirements for that function. Producers and Consumers will support one or more profiles.</li>
</ul>
<p>The components of a Command are an Action (what is to be done), a Target (what is being acted upon), an optional Actuator (what is performing the command), and Command Arguments, which influence how the Command is to be performed. An Action coupled with a Target is sufficient to describe a complete Command. Though optional, the inclusion of an Actuator and/or Command Arguments provides additional precision to a Command.</p>
<p>The components of a Response are a numerical status code, an optional status text string, and optional results. The format of the results, if included, depend on the type of Response being transferred.</p>
<h2 id="17-goal">1.7 Goal</h2>
<p>The goal of the OpenC2 Language Specification is to provide a language for interoperating between functional elements of cyber defense systems. This language used in conjunction with OpenC2 Actuator Profiles and OpenC2 Transfer Specifications allows for vendor-agnostic cybertime response to attacks.</p>
<p>The Integrated Adaptive Cyber Defense (IACD) framework defines a collection of activities, based on the traditional OODA (Observe–Orient–Decide–Act) Loop <a href="#iacd">[IACD]</a>:</p>
<ul>
<li>Sensing: gathering of data regarding system activities</li>
<li>Sense Making: evaluating data using analytics to understand what's happening</li>
<li>Decision Making: determining a course-of-action to respond to system events</li>
<li>Acting: Executing the course-of-action</li>
</ul>
<p>The goal of OpenC2 is to enable coordinated defense in cyber-relevant time between decoupled blocks that perform cyber defense functions. OpenC2 focuses on the Acting portion of the IACD framework; the assumption that underlies the design of OpenC2 is that the sensing/analytics have been provisioned and the decision to act has been made. This goal and these assumptions guide the design of OpenC2:</p>
<ul>
<li><strong>Technology Agnostic:</strong> The OpenC2 language defines a set of abstract atomic cyber defense actions in a platform and implementation agnostic manner</li>
<li><strong>Concise:</strong> A Command is intended to convey only the essential information required to describe the action required and can be represented in a very compact form for communications-constrained environments</li>
<li><strong>Abstract:</strong> Commands and Responses are defined abstractly and can be encoded and transferred via multiple schemes as dictated by the needs of different implementation environments</li>
<li><strong>Extensible:</strong> While OpenC2 defines a core set of Actions and Targets for cyber defense, the language is expected to evolve with cyber defense technologies, and permits extensions to accommodate new cyber defense technologies.</li>
</ul>
<h2 id="18-purpose-and-scope">1.8 Purpose and Scope</h2>
<p>A 'Stateless Packet Filter' (SLPF) is a policy enforcement mechanism that restricts or permits traffic based on static values such as source address, destination address, and/or port numbers. A Stateless Packet Filter does not consider traffic patterns, connection state, data flows, applications, or payload information. The scope of this profile is limited to Stateless Packet Filtering herein referred to as SLPF.</p>
<p>This Actuator profile specifies the set of Actions, Targets, Specifiers, and Command Arguments that integrates SLPF functionality with the Open Command and Control (OpenC2) Command set. Through this Command set, cyber security orchestrators may gain visibility into and provide control over the SLPF functionality in a manner that is independent of the instance of the SLPF function.</p>
<p>All components, devices and systems that provide SLPF functionality will implement the OpenC2 Actions, Targets, Specifiers and Arguments identified as required in this document. Actions that are applicable, but not necessarily required, for SLPF will be identified as optional.</p>
<p>The purpose of this document is to:</p>
<ul>
<li>Identify the required and optional OpenC2 Actions for Actuators with SLPF functionality</li>
<li>Identify the required and optional Target types for each Action in the SLPF class of Actuators</li>
<li>Identify Actuator-Specifiers and Arguments for each Action/Target pair that are applicable and/or unique to the SLPF class of Actuators</li>
<li>Annotate each Action/Target pair with a justification and example, and provide sample OpenC2 Commands to a SLPF with corresponding Responses</li>
</ul>
<p>This SLPF profile:</p>
<ul>
<li>Does not define or implement Actions beyond those defined in Version 1.0 of the <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a></li>
<li>Is consistent with Version 1.0 of the OpenC2 Language Specification</li>
</ul>
<p>Cyber defense systems that are utilizing OpenC2 may require the following components to implement the SLPF profile:</p>
<ul>
<li>OpenC2 Producers: Devices that send Commands, receive Responses, and manage the execution of Commands involving one or more SLPF or other Actuators with SLPF capability. The OpenC2 Producer needs <em>a priori</em> knowledge of which Commands the Actuator can process and execute, therefore must understand the profiles for any device that it intends to command</li>
<li>OpenC2 Consumers: Devices or instances that provide stateless packet filtering functions. Typically these are Actuators that execute the cyber defense function, but could be orchestrators (i.e., a device or instance that forwards Commands to the Actuator)</li>
</ul>
<p>Though cyber defense components, devices, systems and/or instances may implement multiple Actuator profiles, a particular OpenC2 Message may reference at most a single Actuator profile. The scope of this document is limited to SLPF.</p>
<p>This specification is organized into three major sections.</p>
<p>Section One (this section) provides a non-normative overview of the suite of specifications that realize OpenC2. This section provides references as well as defines the scope and purpose of this specification.</p>
<p><a href="#2-openc2-language-binding">Section Two</a> (normative) binds this particular profile to the OpenC2 Language Specification. Section Two enumerates the components of the language specification that are meaningful in the context of SLPF and defines components that are applicable to this distinct profile. Section Two also defines the Commands (i.e., the Action/Target pairs) that are permitted in the context of SLPF.</p>
<p><a href="#3-conformance-statements">Section Three</a> (normative) presents definitive criteria for conformance so that cyber security stakeholders can be assured that their products, instances and/or integrations are compatible with OpenC2.</p>
<p><a href="#annex-a-sample-commands">Annex A</a> (non-normative) provides multiple examples of Commands and associated Responses (JSON serialization) to facilitate development.</p>
<hr />
<h1 id="2-openc2-language-binding">2 OpenC2 Language Binding</h1>
<p><em>This section is normative</em></p>
<p>This section defines the set of Actions, Targets, Specifiers, and Arguments that are meaningful in the context of an SLPF. This section also describes the appropriate format for the status and properties of a Response frame. This section is organized into three major subsections; Command Components, Response Components and Commands.</p>
<p>Extensions to the Language Specification are defined in accordance with <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a>, Section 3.1.5, where:</p>
<ol>
<li>The unique name of the SLPF schema is <code>oasis-open.org/openc2/v1.0/ap-slpf</code></li>
<li>The namespace identifier (nsid) referring to the SLPF schema is: <code>slpf</code></li>
<li>The definitions of and conformance requirements for these types are contained in this document</li>
</ol>
<h2 id="21-openc2-command-components">2.1 OpenC2 Command Components</h2>
<p>The components of an OpenC2 Command include Actions, Targets, Actuators and associated Arguments and Specifiers. Appropriate aggregation of the components will define a Command-body that is meaningful in the context of an SLPF.</p>
<p>This specification identifies the applicable components of an OpenC2 Command. The components of an OpenC2 Command include:</p>
<ul>
<li>Action: A subset of the Actions defined in the OpenC2 Language Specification that are meaningful in the context of a SLPF.
<ul>
<li>This profile SHALL NOT define Actions that are external to Version 1.0 of the <a href="#openc2-lang-v10">OpenC2 Language Specification</a></li>
<li>This profile MAY augment the definition of the Actions in the context of a SLPF</li>
<li>This profile SHALL NOT define Actions in a manner that is inconsistent with version 1.0 of the OpenC2 Language Specification</li>
</ul></li>
<li>Target: A subset of the Targets and Target-Specifiers defined in Version 1.0 of the OpenC2 Language Specification that are meaningful in the context of SLPF and one Target (and its associated Specifier) that is defined in this specification</li>
<li>Arguments: A subset of the Arguments defined in the Language Specification and a set of Arguments defined in this specification</li>
<li>Actuator: A set of specifiers defined in this specification that are meaningful in the context of SLPF</li>
</ul>
<h3 id="211-actions">2.1.1 Actions</h3>
<p>Table 2.1.1-1 presents the OpenC2 Actions defined in version 1.0 of the Language Specification which are meaningful in the context of an SLPF. The particular Action/Target pairs that are required or are optional are presented in <a href="#23-openc2-commands">Section 2.3</a>.</p>
<p><strong>Table 2.1.1-1. Actions Applicable to SLPF</strong></p>
<p><strong><em>Type: Action (Enumerated)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>query</strong></td>
<td style="text-align: left;">Initiate a request for information. Used to communicate the supported options and determine the state or settings</td>
</tr>
<tr class="even">
<td style="text-align: left;">6</td>
<td style="text-align: left;"><strong>deny</strong></td>
<td style="text-align: left;">Prevent traffic or access</td>
</tr>
<tr class="odd">
<td style="text-align: left;">8</td>
<td style="text-align: left;"><strong>allow</strong></td>
<td style="text-align: left;">Permit traffic or access</td>
</tr>
<tr class="even">
<td style="text-align: left;">16</td>
<td style="text-align: left;"><strong>update</strong></td>
<td style="text-align: left;">Instructs the Actuator to update its configuration by retrieving and processing a configuration file and update</td>
</tr>
<tr class="odd">
<td style="text-align: left;">20</td>
<td style="text-align: left;"><strong>delete</strong></td>
<td style="text-align: left;">Remove an access rule</td>
</tr>
</tbody>
</table>
<h3 id="212-targets">2.1.2 Targets</h3>
<p>Table 2.1.2-1 summarizes the Targets defined in Version 1.0 of the <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a> as they relate to SLPF functionality. Table 2.1.2-2 summarizes the Targets that are defined in this specification.</p>
<h4 id="2121-common-targets">2.1.2.1 Common Targets</h4>
<p>Table 2.1.2-1 lists the Targets defined in the OpenC2 Language Specification that are applicable to SLPF. The particular Action/Target pairs that are required or are optional are presented in <a href="#23-openc2-commands">Section 2.3</a>.</p>
<p><strong>Table 2.1.2-1. Targets Applicable to SLPF</strong></p>
<p><strong><em>Type: Target (Choice)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">9</td>
<td style="text-align: left;"><strong>features</strong></td>
<td style="text-align: left;">Features</td>
<td style="text-align: left;">A set of items such as Action/Target pairs, profiles versions, options that are supported by the Actuator. The Target is used with the query Action to determine an Actuator's capabilities</td>
</tr>
<tr class="even">
<td style="text-align: left;">10</td>
<td style="text-align: left;"><strong>file</strong></td>
<td style="text-align: left;">File</td>
<td style="text-align: left;">Properties of a file</td>
</tr>
<tr class="odd">
<td style="text-align: left;">13</td>
<td style="text-align: left;"><strong>ipv4_net</strong></td>
<td style="text-align: left;">IPv4-Net</td>
<td style="text-align: left;">The representation of one or more IPv4 addresses expressed using CIDR notation</td>
</tr>
<tr class="even">
<td style="text-align: left;">14</td>
<td style="text-align: left;"><strong>ipv6_net</strong></td>
<td style="text-align: left;">IPv6-Net</td>
<td style="text-align: left;">The representation of one or more IPv6 addresses expressed using CIDR notation</td>
</tr>
<tr class="odd">
<td style="text-align: left;">15</td>
<td style="text-align: left;"><strong>ipv4_connection</strong></td>
<td style="text-align: left;">IPv4-Connection</td>
<td style="text-align: left;">A network connection as specified by a five-tuple (IPv4)</td>
</tr>
<tr class="even">
<td style="text-align: left;">16</td>
<td style="text-align: left;"><strong>ipv6_connection</strong></td>
<td style="text-align: left;">IPv6-Connection</td>
<td style="text-align: left;">A network connection as specified by a five-tuple (IPv6)</td>
</tr>
</tbody>
</table>
<p>The semantics/ requirements as they pertain to common targets:</p>
<ul>
<li>ipv4_connection
<ul>
<li>If the protocol = ICMP, the five-tuple is: src_addr, dst_addr, icmp_type, icmp_code, protocol where the ICMP types and codes are defined in <a href="#rfc2780">[RFC2780]</a></li>
<li>If the protocol = TCP, UDP or SCTP, the five-tuple is: src_addr, src_port, dst_addr, dst_port, protocol</li>
<li>For any other protocol, the five-tuple is: src_addr, unused, dst_addr, unused, protocol</li>
</ul></li>
<li>ipv6_connection
<ul>
<li>If the protocol = ICMP, the five-tuple is: src_addr, dst_addr, icmp_type, icmp_code, protocol where the ICMP types and codes are defined in <a href="#rfc4443">[RFC4443]</a></li>
<li>If the protocol = TCP, UDP or SCTP, the five-tuple is: src_addr, src_port, dst_addr, dst_port, protocol</li>
<li>For any other protocol, the five-tuple is: src_addr, unused, dst_addr, unused, protocol</li>
</ul></li>
</ul>
<h4 id="2122-slpf-targets">2.1.2.2 SLPF Targets</h4>
<p>The list of common Targets is extended to include the additional Targets defined in this section and referenced with the slpf namespace.</p>
<p><strong>Table 2.1.2-2. Targets Unique to SLPF</strong></p>
<p><strong><em>Type: Target (Choice)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1024</td>
<td style="text-align: left;"><strong>rule_number</strong></td>
<td style="text-align: left;">Rule-ID</td>
<td style="text-align: left;">Immutable identifier assigned when a rule is created. Identifies a rule to be deleted</td>
</tr>
</tbody>
</table>
<h3 id="213-command-arguments">2.1.3 Command Arguments</h3>
<p>Arguments provide additional precision to a Command by including information such as how, when, or where a Command is to be executed. Table 2.1.3-1 summarizes the Command Arguments defined in Version 1.0 of the <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a> as they relate to SLPF functionality. Table 2.1.3-2 summarizes the Command Arguments that are defined in this specification.</p>
<h4 id="2131-common-arguments">2.1.3.1 Common Arguments</h4>
<p>Table 2.1.3-1 lists the Command Arguments defined in the <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a> that are applicable to SLPF.</p>
<p><strong>Table 2.1.3-1. Command Arguments applicable to SLPF</strong></p>
<p><strong><em>Type: Args (Map)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>start_time</strong></td>
<td style="text-align: left;">Date-Time</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">The specific date/time to initiate the Action</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>stop_time</strong></td>
<td style="text-align: left;">Date-Time</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">The specific date/time to terminate the Action</td>
</tr>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>duration</strong></td>
<td style="text-align: left;">Duration</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">The length of time for an Action to be in effect</td>
</tr>
<tr class="even">
<td style="text-align: left;">4</td>
<td style="text-align: left;"><strong>response_requested</strong></td>
<td style="text-align: left;">Response-Type</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">The type of Response required for the Action: <code>none</code>, <code>ack</code>, <code>status</code>, <code>complete</code></td>
</tr>
</tbody>
</table>
<h4 id="2132-slpf-arguments">2.1.3.2 SLPF Arguments</h4>
<p>The list of common Command Arguments is extended to include the additional Command Arguments defined in this section and referenced with the slpf namespace.</p>
<p><strong>Table 2.1.3-2. Command Arguments Unique to SLPF</strong></p>
<p><strong><em>Type: Args (Map)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1024</td>
<td style="text-align: left;"><strong>drop_process</strong></td>
<td style="text-align: left;">Drop-Process</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">Specifies how to handle denied packets</td>
</tr>
<tr class="even">
<td style="text-align: left;">1025</td>
<td style="text-align: left;"><strong>persistent</strong></td>
<td style="text-align: left;">Boolean</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">Normal operations assume any changes to a device are to be implemented persistently. Setting the persistent modifier to FALSE results in a change that is not persistent in the event of a reboot or restart</td>
</tr>
<tr class="odd">
<td style="text-align: left;">1026</td>
<td style="text-align: left;"><strong>direction</strong></td>
<td style="text-align: left;">Direction</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">Specifies whether to apply rules to incoming or outgoing traffic. If omitted, rules are applied to both</td>
</tr>
<tr class="even">
<td style="text-align: left;">1027</td>
<td style="text-align: left;"><strong>insert_rule</strong></td>
<td style="text-align: left;">Rule-ID</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">Specifies the identifier of the rule within a list, typically used in a top-down rule list</td>
</tr>
</tbody>
</table>
<p><strong><em>Type: Drop-Process (Enumerated)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>none</strong></td>
<td style="text-align: left;">Drop the packet and do not send a notification to the source of the packet</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>reject</strong></td>
<td style="text-align: left;">Drop the packet and send an ICMP host unreachable (or equivalent) to the source of the packet</td>
</tr>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>false_ack</strong></td>
<td style="text-align: left;">Drop the traffic and send a false acknowledgment</td>
</tr>
</tbody>
</table>
<p><strong><em>Type: Direction (Enumerated)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>both</strong></td>
<td style="text-align: left;">Apply rules to all traffic</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>ingress</strong></td>
<td style="text-align: left;">Apply rules to incoming traffic only</td>
</tr>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>egress</strong></td>
<td style="text-align: left;">Apply rules to outgoing traffic only</td>
</tr>
</tbody>
</table>
<p><strong><em>Type: Rule-ID</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Type Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>Rule-ID</strong></td>
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">Access rule identifier</td>
</tr>
</tbody>
</table>
<p>The semantics/requirements as they relate to SLPF arguments:</p>
<ul>
<li><p>insert_rule:</p>
<ul>
<li><p>The value MUST be immutable - i.e., the identifier assigned to an access rule at creation must not change over the lifetime of that rule</p></li>
<li><p>The value MUST be unique within the scope of an Openc2 Producer and an Openc2 Consumer- i.e., the value MUST map to exactly one deny <target> or allow <target> for a given instance of an SLPF</p></li>
</ul></li>
<li><p>directionality:</p>
<ul>
<li>Entities that receive but do not support directionality MUST NOT reply with 200 OK and SHOULD return a 501 error code</li>
<li>If absent or not explicitly set, then the Command MUST apply to both</li>
</ul></li>
<li><p>drop_process: If absent or not explicitly set, then the Actuator MUST NOT send any notification to the source of the packet</p></li>
<li><p>persistent: If absent or not explicitly set, then the value is TRUE and any changes are persistent</p></li>
</ul>
<h3 id="214-actuator-specifiers">2.1.4 Actuator Specifiers</h3>
<p>An Actuator is the entity that provides the functionality and performs the Action. The Actuator executes the Action on the Target. In the context of this profile, the Actuator is the SLPF and the presence of one or more Specifiers further refine which Actuator(s) shall execute the Action.</p>
<p>Table 2.1.4-1 lists the Specifiers that are applicable to the SPLF Actuator. <a href="#annex-a-sample-commands">Annex A</a> provides sample Commands with the use of Specifiers.</p>
<p>The Actuator Specifiers defined in this document are referenced under the slpf namespace.</p>
<p><strong>Table 2.1.4-1. SLPF Specifiers</strong></p>
<p><strong><em>Type: Specifiers (Map)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1</td>
<td style="text-align: left;"><strong>hostname</strong></td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;"><a href="#rfc1123">[RFC1123]</a> hostname (can be a domain name or IP address) for a particular device with SLPF functionality</td>
</tr>
<tr class="even">
<td style="text-align: left;">2</td>
<td style="text-align: left;"><strong>named_group</strong></td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">User defined collection of devices with SLPF functionality</td>
</tr>
<tr class="odd">
<td style="text-align: left;">3</td>
<td style="text-align: left;"><strong>asset_id</strong></td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">0..1</td>
<td style="text-align: left;">Unique identifier for a particular SLPF</td>
</tr>
<tr class="even">
<td style="text-align: left;">4</td>
<td style="text-align: left;"><strong>asset_tuple</strong></td>
<td style="text-align: left;">String</td>
<td style="text-align: left;">0..10</td>
<td style="text-align: left;">Unique tuple identifier for a particular SLPF consisting of a list of up to 10 strings</td>
</tr>
</tbody>
</table>
<h2 id="22-openc2-response-components">2.2 OpenC2 Response Components</h2>
<p>Response messages originate from the Actuator as a result of a Command.</p>
<p>Responses associated with required Actions MUST be implemented. Implementations that include optional Actions MUST implement the RESPONSE associated with the implemented Action. Additional details regarding the Command and associated Response are captured in <a href="#23-openc2-commands">Section 2.3</a>. Examples are provided in <a href="#annex-a-sample-commands">Annex A</a>.</p>
<h3 id="221-common-results">2.2.1 Common Results</h3>
<p>Table 2.2.1-1 lists the Response Results properties defined in the <a href="#openc2-lang-v10">[OpenC2-Lang-v1.0]</a> that are applicable to SLPF.</p>
<p><strong>Table 2.2.1-1. Response Results Applicable to SLPF</strong></p>
<p><strong><em>Type: Results (Map [1..*])</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: right;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: right;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: right;">1</td>
<td style="text-align: left;"><strong>versions</strong></td>
<td style="text-align: left;">Version</td>
<td style="text-align: right;">0..*</td>
<td style="text-align: left;">List of OpenC2 language versions supported by this Actuator</td>
</tr>
<tr class="even">
<td style="text-align: right;">2</td>
<td style="text-align: left;"><strong>profiles</strong></td>
<td style="text-align: left;">ArrayOf(Nsid)</td>
<td style="text-align: right;">0..1</td>
<td style="text-align: left;">List of profiles supported by this Actuator</td>
</tr>
<tr class="odd">
<td style="text-align: right;">3</td>
<td style="text-align: left;"><strong>pairs</strong></td>
<td style="text-align: left;">Action-Targets</td>
<td style="text-align: right;">0..*</td>
<td style="text-align: left;">List of targets applicable to each supported Action</td>
</tr>
<tr class="even">
<td style="text-align: right;">4</td>
<td style="text-align: left;"><strong>rate_limit</strong></td>
<td style="text-align: left;">Number</td>
<td style="text-align: right;">0..1</td>
<td style="text-align: left;">Maximum number of requests per minute supported by design or policy</td>
</tr>
</tbody>
</table>
<h3 id="222-slpf-results">2.2.2 SLPF Results</h3>
<p>The list of common Response properties is extended to include the additional Response properties defined in this section and referenced with the slpf namespace.</p>
<p><strong>Table 2.2.2-1. SLPF Results</strong></p>
<p><strong><em>Type: OpenC2-Response (Map)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">1024</td>
<td style="text-align: left;"><strong>rule_number</strong></td>
<td style="text-align: left;">Rule-ID</td>
<td style="text-align: left;">Rule identifier returned from allow or deny Command</td>
</tr>
</tbody>
</table>
<h3 id="223-response-status-codes">2.2.3 Response Status Codes</h3>
<p>Table 2.2.1-2 lists the Response Status Codes defined in the OpenC2 Language Specification that are applicable to SLPF.</p>
<p><strong>Table 2.2.1-2. Response Status Codes</strong></p>
<p><strong><em>Type: Status-Code (Enumerated.ID)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Value</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">102</td>
<td style="text-align: left;">Processing. Command received but action not necessarily complete.</td>
</tr>
<tr class="even">
<td style="text-align: left;">200</td>
<td style="text-align: left;">OK.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">400</td>
<td style="text-align: left;">Bad Request. Unable to process Command, parsing error.</td>
</tr>
<tr class="even">
<td style="text-align: left;">500</td>
<td style="text-align: left;">Internal Error. For "response_requested" value "complete", one of the following MAY apply:<br> * Cannot access file or path<br> * Rule number currently in use<br> * Rule not updated</td>
</tr>
<tr class="odd">
<td style="text-align: left;">501</td>
<td style="text-align: left;">Not implemented. For "response_requested" value "complete", one of the following MAY apply:<br> * Target not supported<br> * Option not supported<br> * Command not supported</td>
</tr>
</tbody>
</table>
<h2 id="23-openc2-commands">2.3 OpenC2 Commands</h2>
<p>An OpenC2 Command consists of an Action/Target pair and associated Specifiers and Arguments. This section enumerates the allowed Commands and presents the associated Responses.</p>
<p>Table 2.3-1 defines the Commands that are valid in the context of the SLPF profile. An Action (the top row in Table 2.3-1) paired with a Target (the first column in Table 2.3-1) defines a valid Command. The subsequent subsections provide the property tables applicable to each OpenC2 Command.</p>
<p><strong>Table 2.3-1. Command Matrix</strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;"></th>
<th style="text-align: center;">Allow</th>
<th style="text-align: center;">Deny</th>
<th style="text-align: center;">Query</th>
<th style="text-align: center;">Delete</th>
<th style="text-align: center;">Update</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>ipv4_connection</strong></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>ipv6_connection</strong></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>ipv4_net</strong></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>ipv6_net</strong></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>features</strong></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>slpf:rule_number</strong></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;">valid</td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>file</strong></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;">valid</td>
</tr>
</tbody>
</table>
<p>Table 2.3-2 defines the Command Arguments that are allowed for a particular Command by the SLPF profile. A Command (the top row in Table 2.3-2) paired with an Argument (the first column in Table 2.3-2) defines an allowable combination. The subsection identified at the intersection of the Command/Argument provides details applicable to each Command as influenced by the Argument.</p>
<p><strong>Table 2.3-2. Command Arguments Matrix</strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: left;"></th>
<th style="text-align: center;">Allow <em>target</em></th>
<th style="text-align: center;">Deny <em>target</em></th>
<th style="text-align: center;">Query features</th>
<th style="text-align: center;">Delete slpf:rule_number</th>
<th style="text-align: center;">Update file</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>response_requested</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"><a href="#2331-query-features">2.3.3.1</a></td>
<td style="text-align: center;"><a href="#2341-delete-slpfrule_number">2.3.4.1</a></td>
<td style="text-align: center;"><a href="#2351-update-file">2.3.5.1</a></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>start_time</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"><a href="#2341-delete-slpfrule_number">2.3.4.1</a></td>
<td style="text-align: center;"><a href="#2351-update-file">2.3.5.1</a></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>stop_time</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>duration</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>persistent</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>direction</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>insert_rule</strong></td>
<td style="text-align: center;"><a href="#231-allow">2.3.1</a></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
<tr class="even">
<td style="text-align: left;"><strong>drop_process</strong></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"><a href="#232-deny">2.3.2</a></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
<td style="text-align: center;"></td>
</tr>
</tbody>
</table>
<h3 id="231-allow">2.3.1 Allow</h3>
<p>Table 2.3.1-1 summarizes the Command Arguments that apply to all of the Commands consisting of the 'allow' Action and a valid Target type.</p>
<p>Upon receipt of an unsupported Command Argument, SLPF Consumers</p>
<ul>
<li>MUST NOT respond with a OK/200</li>
<li>SHOULD respond with the 501 status code.</li>
<li>SHOULD respond with "Option not supported" in the status text</li>
<li>MAY respond with the 500 status code</li>
</ul>
<p>OpenC2 Producers that send 'allow target' Commands and support the 'delete slpf:rule_number' Command:</p>
<ul>
<li>MUST support the slpf:rule_number Target type as defined in <a href="#2122-slpf-targets">Section 2.1.2.2</a></li>
<li>SHOULD populate the Command Arguments field with "response_requested" : "complete"</li>
<li>MAY populate the Command Arguments field with the "insert_rule" : <integer> option</li>
<li>MUST populate the Command Arguments field with "response_requested" : "complete" if the insert_rule Argument is populated</li>
</ul>
<p>OpenC2 Consumers that receive and successfully parse 'allow <target>' Commands but cannot implement the 'allow <target>' :</p>
<ul>
<li>MUST NOT respond with a OK/200</li>
<li>SHOULD respond with the 501 status code</li>
<li>SHOULD respond with 'Rule not updated' in the status text</li>
<li>MAY respond with the 500 status code</li>
</ul>
<p>OpenC2 Consumers that receive 'allow <target>' Commands and support the 'delete slpf:rule_number' Command:</p>
<ul>
<li>MUST support the slpf:rule_number Target type as defined in <a href="#2122-slpf-targets">Section 2.1.2.2</a></li>