forked from henrikau/DetNet_Sec
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdetnet-security.xml
More file actions
2126 lines (2079 loc) · 149 KB
/
detnet-security.xml
File metadata and controls
2126 lines (2079 loc) · 149 KB
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" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC7384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7384.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-detnet-security-13" ipr="trust200902">
<front>
<title abbrev="DetNet Security"> Deterministic Networking (DetNet) Security Considerations </title>
<author fullname="Ethan Grossman" initials="E.A." role="editor" surname="Grossman">
<organization abbrev="DOLBY">Dolby Laboratories, Inc.</organization>
<address>
<postal>
<street>1275 Market Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94103</code>
<country>USA</country>
</postal>
<phone>+1 415 465 4339</phone>
<email>[email protected]</email>
<uri>http://www.dolby.com</uri>
</address>
</author>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
<organization abbrev="HUAWEI">Huawei Network.IO Innovation Lab</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Andrew J. Hacker" initials="A.J." surname="Hacker">
<organization abbrev="MISTIQ">MistIQ Technologies, Inc</organization>
<address>
<postal>
<street/>
<city>Harrisburg</city>
<region>PA</region>
<code/>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2021"/>
<area>Routing</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>DetNet, security</keyword>
<abstract>
<t>A DetNet (deterministic network) provides specific performance guarantees to its data
flows, such as extremely low data loss rates and bounded latency (including bounded latency
variation, i.e. "jitter"). As a result, securing a DetNet requires that in addition to the
best practice security measures taken for any mission-critical network, additional security
measures may be needed to secure the intended operation of these novel service
properties.</t>
<t> This document addresses DetNet-specific security considerations from the perspectives of
both the DetNet system-level designer and component designer. System considerations include
a taxonomy of relevant threats and attacks, and associations of threats versus use cases and
service properties. Component-level considerations include ingress filtering and packet
arrival time violation detection.</t>
<t>This document also addresses security considerations specific to the IP and MPLS data plane
technologies, thereby complementing the Security Considerations sections of those
documents.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>A deterministic IP network (IETF DetNet, <xref target="RFC8655"/>) can carry data flows for
real-time applications with extremely low data loss rates and bounded latency. The bounds on
latency defined by DetNet (as described in <xref
target="I-D.ietf-detnet-flow-information-model"/>) include both worst case latency
(Maximum Latency, Section 5.9.2) and worst case jitter (Maximum Latency Variation, Section
5.9.3). Data flows with deterministic properties are well-established for Ethernet networks
(see TSN, <xref target="IEEE802.1BA"/>); DetNet brings these capabilities to the IP
network.</t>
<t>Deterministic IP networks have been successfully deployed in real-time Operational
Technology (OT) applications for some years, however such networks are typically isolated
from external access, and thus the security threat from external attackers is low. An
example of such an isolated network is a network deployed within an aircraft, which is "air
gapped" from the outside world. DetNet specifies a set of technologies that enable creation
of deterministic flows on IP-based networks of potentially wide area (on the scale of a
corporate network), potentially merging OT traffic with best-effort (Information Technology,
IT) traffic, and placing OT network components into contact with IT network components,
thereby exposing the OT traffic and components to security threats that were not present in
an isolated OT network. </t>
<t>These DetNet (OT-type) technologies may not have previously been deployed on a wide area
IP-based network that also carries IT traffic, and thus can present security considerations
that may be new to IP-based wide area network designers; this document provides insight into
such system-level security considerations. In addition, designers of DetNet components (such
as routers) face new security-related challenges in providing DetNet services, for example
maintaining reliable isolation between traffic flows in an environment where IT traffic
co-mingles with critical reserved-bandwidth OT traffic; this document also examines security
implications internal to DetNet components. </t>
<t>Security is of particularly high importance in DetNet because many of the use cases which
are enabled by DetNet <xref target="RFC8578"/> include control of physical devices (power
grid devices, industrial controls, building controls) which can have high operational costs
for failure, and present potentially attractive targets for cyber-attackers. </t>
<t>This situation is even more acute given that one of the goals of DetNet is to provide a
"converged network", i.e. one that includes both IT traffic and OT traffic, thus exposing
potentially sensitive OT devices to attack in ways that were not previously common (usually
because they were under a separate control system or otherwise isolated from the IT network,
for example <xref target="ARINC664P7"/>). Security considerations for OT networks are not a
new area, and there are many OT networks today that are connected to wide area networks or
the Internet; this document focuses on the issues that are specific to the DetNet
technologies and use cases. </t>
<t>Given the above considerations, securing a DetNet starts with a scrupulously well-designed
and well-managed engineered network following industry best practices for security at both
the data plane and controller plane, as well as for any OAM implementation; this is the
assumed starting point for the considerations discussed herein. Such assumptions also depend
on the network components themselves upholding the security-related properties that are to
be assumed by DetNet system-level designers; for example, the assumption that network
traffic associated with a given flow can never affect traffic associated with a different
flow is only true if the underlying components make it so. Such properties, which may
represent new challenges to component designers, are also considered herein. </t>
<t>Starting with a "well-managed network" as noted above enables us to exclude some of the
more powerful adversary capabilities from the Internet Threat Model of BCP 72 (<xref
target="RFC3552"/>), such as the ability to arbitrarily drop or delay any or all traffic.
Given this reduced attacker capability, we can present security considerations based on
attacker capabilities that are more directly relevant to a DetNet.</t>
<t>In this context we view the "traditional" (i.e. non-time-sensitive) network design and
management aspects of network security as being primarily concerned with denial-of service
prevention, i.e. they must ensure that DetNet traffic goes where it's supposed to and that
an external attacker can't inject traffic that disrupts the delivery timing assurance of the
DetNet. The time-specific aspects of DetNet security presented here take up where those
"traditional" design and management aspects leave off. </t>
<t>However note that "traditional" methods for mitigating (among all the others) denial-of
service attack (such as throttling) can only be effectively used in a DetNet when their use
does not compromise the required time-sensitive or behavioral properties required for the OT
flows on the network. For example, a "retry" protocol is typically not going to be
compatible with a low-latency (worst-case maximum latency) requirement, however if in a
specific use case and implementation such a retry protocol is able to meet the timing
constraints, then it may well be used in that context. Similarly if common security
protocols such as TLS/DTLS or IPsec are to be used, it must be verified that their
implementations are able to meet the timing and behavioral requirements of the
time-sensitive network as implemented for the given use case. An example of "behavioral
properties" might be that dropping of more than a specific number of packets in a row is not
acceptable according to the service level agreement.</t>
<t>The exact security requirements for any given DetNet are necessarily specific to the use
cases handled by that network. Thus the reader is assumed to be familiar with the specific
security requirements of their use cases, for example those outlined in the DetNet Use Cases
<xref target="RFC8578"/> and the Security Considerations sections of the DetNet documents
applicable to the network technologies in use, for example <xref target="RFC8939"/>).
Readers can find a general introduction to the DetNet Architecture in <xref target="RFC8655"
/>, the DetNet Data Plane in <xref target="RFC8938"/>, and the Flow Information Model in
<xref target="I-D.ietf-detnet-flow-information-model"/>.</t>
<t>The DetNet technologies include ways to: <list style="symbols">
<t> Assign data plane resources for DetNet flows in some or all of the intermediate nodes
(routers) along the path of the flow</t>
<t> Provide explicit routes for DetNet flows that do not dynamically change with the
network topology in ways that affect the quality of service received by the affected
flow(s) </t>
<t> Distribute data from DetNet flow packets over time and/or space to ensure delivery of
the data in each packet in spite of the loss of a path.</t>
</list>
</t>
<t>This document includes sections considering DetNet component design as well as system
design. The latter includes a taxonomy and analysis of threats, threat impacts and
mitigations, and an association of attacks with use cases (based on the Use Case Common
Themes section of the DetNet Use Cases <xref target="RFC8578"/>). </t>
<t>This document is based on the premise that there will be a very broad range of DetNet
applications and use cases, ranging in size scope from individual industrial machines to
networks that span an entire country (<xref target="RFC8578"/>). Thus no single set of
prescriptions (such as exactly which mitigation should be applied to which segment of a
DetNet) can be applicable to all of them, and indeed any single one that we might prescribe
would inevitably prove impractical for some use case, perhaps one that does not even exist
at the time of this writing. Thus we are not prescriptive here - we are stating the desired
end result, with the understanding that most DetNet use cases will necessarily differ from
each other, and there is no "one size fits all". </t>
</section>
<section title="Abbreviations and Terminology">
<t>IT: Information Technology (the application of computers to store, study, retrieve,
transmit, and manipulate data or information, often in the context of a business or other
enterprise - <xref target="IT_DEF"/>). </t>
<t>OT: Operational Technology (the hardware and software dedicated to detecting or causing
changes in physical processes through direct monitoring and/or control of physical devices
such as valves, pumps, etc. - <xref target="OT_DEF"/>) </t>
<t>Component: A component of a DetNet system - used here to refer to any hardware or software
element of a DetNet which implements DetNet-specific functionality, for example all or part
of a router, switch, or end system.</t>
<t>Device: Used here to refer to a physical entity controlled by the DetNet, for example a
motor.</t>
<t>Resource Segmentation: Used as a more general form for Network Segmentation (the act or
practice of splitting a computer network into subnetworks, each being a network segment -
<xref target="RS_DEF"/>) </t>
<t>Controller Plane: In DetNet the Controller Plane corresponds to the aggregation of the
Control and Management Planes (see <xref target="RFC8655"/> section 4.4.2). </t>
</section>
<section title="Security Considerations for DetNet Component Design">
<t>This section provides guidance for implementers of components to be used in a DetNet. </t>
<t>As noted above, DetNet provides resource allocation, explicit routes and redundant path
support. Each of these has associated security implications, which are discussed in this
section, in the context of component design. Detection, reporting and appropriate action in
the case of packet arrival time violations are also discussed.</t>
<section title="Resource Allocation">
<section title="Inviolable Flows">
<t>A DetNet system security designer relies on the premise that any resources allocated to
a resource-reserved (OT-type) flow are inviolable; in other words there is no physical
possibility within a DetNet component that resources allocated to a given DetNet flow
can be compromised by any type of traffic in the network; this includes malicious
traffic as well as inadvertent traffic such as might be produced by a malfunctioning
component, or due to interactions between components that were not sufficiently tested
for interoperability. From a security standpoint this is a critical assumption, for
example when designing against DOS attacks. In other words, with correctly designed
components and security mechanisms, one can prevent malicious activities from impacting
other resources.</t>
<t>However, achieving the goal of absolutely inviolable flows may not be technically or
economically feasible for any given use case, given the broad range of possible use
cases (e.g. [reference to DetNet Use Cases RFC8578]) and their associated security
considerations as outlined in this document. It can be viewed as a continuum of security
requirements, from isolated ultra-low latency systems that may have little security
vulnerability (such as an industrial machine) to broadly distributed systems with many
possible attack vectors and OT security concerns (such as a utility network). Given this
continuum, the design principle employed in this document is to specify the desired end
results, without being overly prescriptive in how the results are achieved, reflecting
the understanding that no individual implementation is likely to be appropriate for
every DetNet use case. </t>
</section>
<section title="Design Trade-Off Considerations in the Use Cases Continuum">
<t>It is important for the DetNet system designer to understand, for any given DetNet use
case and its associated security requirements, the interaction and design trade-offs
that inevitably need to be reconciled between the desired end results and the DetNet
protocols, as well as the DetNet system and component design. </t>
<t>For any given component, as designed for any given use case (or scope of use cases), it
is the responsibility of the component designer to ensure that the premise of inviolable
flows is supported, to the extent that they deem necessary to support their target use
cases. </t>
<t>For example, the component may include traffic shaping and policing at the ingress, to
prevent corrupted or malicious or excessive packets from entering the network, thereby
decreasing the likelihood that any traffic will interfere with any DetNet OT flow. The
component may include integrity protection for some or all of the header fields such as
those used for flow ID, thereby decreasing the likelihood that a packet whose flow ID
has been compromised might be directed into a different flow path. The component may
verify every single packet header at every forwarding location, or only at certain
points. In any of these cases the component may use dynamic performance analytics (<xref
target="DpaMitigation"/>) to cause action to be initiated to address the situation in
an appropriate and timely manner, either at the data plane or controller plane, or both
in concert. The component's software and hardware may include measures to ensure the
integrity of the resource allocation/deallocation process. Other design aspects of the
component may help ensure that the adverse effects of malicious traffic are more
limited, for example by protecting network control interfaces, or minimizing cascade
failures. The component may include features specific to a given use case, such as
configuration of the response to a given sequential packet loss count. </t>
<t>Ultimately, due to cost and complexity factors, the security properties of a component
designed for low-cost systems may be (by design) far inferior to a component with
similar intended functionality, but designed for highly secure or otherwise critical
applications, perhaps at substantially higher cost. Any given component is designed for
some set of use cases and accordingly will have certain limitations on its security
properties and vulnerabilities. It is thus the responsibility of the system designer to
assure themselves that the components they use in their design are capable of satisfying
their overall system security requirements. </t>
</section>
<section title="Documenting the Security Properties of a Component">
<t>In order for the system designer to adequately understand the security related behavior
of a given component, the designer of any component intended for use with DetNet needs
to clearly document the security properties of that component. For example, to address
the case where a corrupted packet in which the flow identification information is
compromised and thus may incidentally match the flow ID of another ("victim") DetNet
flow, resulting in additional unauthorized traffic on the victim, the documentation
might state that the component employs integrity protection on the flow identification
fields. </t>
</section>
<section title="Fail-Safe Component Behavior">
<t>Even when the security properties of a component are understood and well specified, if
the component malfunctions, for example due to physical circumstances unpredicted by the
component designer, it may be difficult or impossible to fully prevent malfunction of
the network. The degree to which a component is hardened against various types of
failures is a distinguishing feature of the component and its design, and the overall
system design can only be as strong as its weakest link. </t>
<t>However, all networks are subject to this level of uncertainty; it is not unique to
DetNet. Having said that, DetNet raises the bar by changing many added latency scenarios
from tolerable annoyances to unacceptable service violations. That in turn underscores
the importance of system integrity, as well as correct and stable configuration of the
network and its nodes, as discussed in <xref target="Introduction"/>. </t>
</section>
<section title="Flow Aggregation Example">
<t>As another example regarding resource allocation implementation, consider the
implementation of Flow Aggregation for DetNet flows (as discussed in <xref
target="RFC8938"/>). In this example say there are N flows that are to be aggregated,
thus the bandwidth resources of the aggregate flow must be sufficient to contain the sum
of the bandwidth reservation for the N flows. However if one of those flows were to
consume more than its individually allocated bandwidth, this could cause starvation of
the other flows. Thus simply providing and enforcing the calculated aggregate bandwidth
may not be a complete solution - the bandwidth for each individual flow must still be
guaranteed, for example via ingress policing of each flow (i.e. before it is
aggregated). Alternatively, if by some other means each flow to be aggregated can be
trusted not to exceed its allocated bandwidth, the same goal can be achieved. </t>
</section>
</section>
<section title="Explicit Routes">
<t>The DetNet-specific purpose for constraining the ability of the DetNet to re-route OT
traffic is to maintain the specified service parameters (such as upper and lower latency
boundaries) for a given flow. For example if the network were to re-route a flow (or some
part of a flow) based exclusively on statistical path usage metrics, or due to malicious
activity, it is possible that the new path would have a latency that is outside the
required latency bounds which were designed into the original TE-designed path, thereby
violating the quality of service for the affected flow (or part of that flow). </t>
<t>However, it is acceptable for the network to re-route OT traffic in such a way as to
maintain the specified latency bounds (and any other specified service properties) for any
reason, for example in response to a runtime component or path failure. </t>
<t>So from a DetNet security standpoint, the DetNet system designer can expect that any
component designed for use in a DetNet will deliver the packets within the agreed-upon
service parameters. For the component designer, this means that in order for a component
to achieve that expectation, any component that is involved in controlling or implementing
any change of the initially TE-configured flow routes must prevent re-routing of OT flows
(whether malicious or accidental) which might adversely affect delivering the traffic
within the specified service parameters.</t>
</section>
<section title="Redundant Path Support">
<t>The DetNet provision for redundant paths (PREOF) (as defined in the DetNet Architecture
<xref target="RFC8655"/>) provides the foundation for high reliability of a DetNet, by
virtually eliminating packet loss (i.e. to a degree which is implementation-dependent)
through hitless redundant packet delivery. Note: At the time of this writing, PREOF is not
defined for the IP data plane. </t>
<t>It is the responsibility of the system designer to determine the level of reliability
required by their use case, and to specify redundant paths sufficient to provide the
desired level of reliability (in as much as that reliability can be provided through the
use of redundant paths). It is the responsibility of the component designer to ensure that
the relevant PREOF operations are executed reliably and securely, to avoid potentially
catastrophic situations for the operational technology relying on them. </t>
<t>However, note that not all PREOF operations are necessarily implemented in every network;
for example a packet re-ordering function may not be necessary if the packets are either
not required to be in order, or if the ordering is performed in some other part of the
network.</t>
<t>Ideally a redundant path for a flow could be specified from end to end, however given
that this is not always possible (as described in <xref target="RFC8655"/>) the system
designer will need to consider the resulting end-to-end reliability and security resulting
from any given arrangement of network segments along the path, each of which provides its
individual PREOF implementation and thus its individual level of reliability and security. </t>
<t>At the data plane the implementation of PREOF depends on the correct assignment and
interpretation of packet sequence numbers, as well as the actions taken based on them,
such as elimination (including elimination of packets with spurious sequence numbers).
Thus the integrity of these values must be maintained by the component as they are
assigned by the DetNet Data Plane Service sub-layer, and transported by the Forwarding
sub-layer. This is no different than the integrity of the values in any header used by the
DetNet (or any other) data plane, and is not unique to redundant paths. The integrity
protection of header values is technology-dependent; for example, in Layer 2 networks the
integrity of the header fields can be protected by using MACsec <xref
target="IEEE802.1AE-2018"/>. Similarly, from the sequence number injection perspective,
it is no different from any other protocols that use sequence numbers. In particular IPSec
Authentication Header (<xref target="RFC4302"/>, Sec. 3 Authentication Header (AH)
Processing) provides useful insights.</t>
</section>
<section title="Timing (or other) Violation Reporting">
<t>A task of the DetNet system designer is to create a network such that for any incoming
packet which arrives with any timing or bandwidth violation, an appropriate action can be
taken in order to prevent damage to the system. The reporting step may be accomplished
through dynamic performance analysis (see <xref target="DpaMitigation"/>) or by any other
means as implemented in one or more components. The action to be taken for any given
circumstance within any given application will depend on the use case. The action may
involve intervention from the controller plane, or it may be taken "immediately" by an
individual component, for example if very fast response is required. </t>
<t>The definitions and selections of the actions that can be taken are properties of the
components. The component designer implements these options according to their expected
use cases, which may vary widely from component to component. Clearly selecting an
inappropriate response to a given condition may cause more problems than it is intending
to mitigate; for example, a naive approach might be to have the component shut down the
link if a packet arrives outside of its prescribed time window; however such a simplistic
action may serve the attacker better than it serves the network. Similarly, simple logging
of such issues may not be adequate, since a delay in response could result in material
damage, for example to mechanical devices controlled by the network. Thus a breadth of
possible and effective security-related actions and their configuration is a positive
attribute for a DetNet component.</t>
<t>Some possible violations that warrant detection include cases where a packet arrives: </t>
<t>
<list style="symbols">
<t>Outside of its prescribed time window</t>
<t>Within its time window but with a compromised time stamp that makes it appear that it
is not within its window</t>
<t>Exceeding the reserved flow bandwidth</t>
</list>
</t>
<t>Some possible direct actions that may be taken at the data plane include traffic policing
and shaping functions (e.g., those described in <xref target="RFC2475"/>), separating
flows into per-flow rate-limited queues, and potentially applying active queue management
<xref target="RFC7567"/>. However if those (or any other) actions are to be taken, the
system designer must ensure that the results of such actions do not compromise the
continued safe operation of the system. For example, the network (i.e. the controller
plane and data plane working together) must mitigate in a timely fashion any potential
adverse effect on mechanical devices controlled by the network. </t>
</section>
</section>
<section title="DetNet Security Considerations Compared With DiffServ Security Considerations">
<t>DetNet is designed to be compatible with DiffServ <xref target="RFC2474"/> as applied to IT
traffic in the DetNet. DetNet also incorporates the use of the 6-bit value of the DSCP field
of the Type of Service (ToS) byte of the IPv4 header (or the Traffic Class byte in IPv6) for
flow identification for OT traffic. However, the DetNet interpretation of the DSCP value for
OT traffic is not equivalent to the PHB selection behavior as defined by DiffServ. </t>
<t>Thus security consideration for DetNet have some aspects in common with DiffServ, in fact
overlapping 100% with respect to IP IT traffic. Security considerations for these aspects
are part of the existing literature on IP network security, specifically the Security
Considerations sections of <xref target="RFC2474"/> and <xref target="RFC2475"/>. However,
DetNet also introduces timing and other considerations which are not present in DiffServ, so
the DiffServ security considerations are a subset of the DetNet security considerations. </t>
<t>In the case of DetNet OT traffic, the DSCP value is interpreted differently than in
DiffServ and contribute to determination of the service provided to the packet. In DetNet,
there are similar consequences to DiffServ for lack of detection of, or incorrect handling
of, packets with mismarked DSCP values, and many of the points made in the DiffServ Security
discussions (<xref target="RFC2475"/> Sec. 6.1 , <xref target="RFC2474"/> Sec. 7 and <xref
target="RFC6274"/> Sec 3.3.2.1) are also relevant to DetNet OT traffic, though perhaps in
modified form. For example, in DetNet the effect of an undetected or incorrectly handled
maliciously mismarked DSCP field in an OT packet is not identical to affecting the PHB of
that packet, since DetNet does not use the PHB concept for OT traffic; but nonetheless the
service provided to the packet could be affected, so mitigation measures analogous to those
prescribed by DiffServ would be appropriate for DetNet. For example, mismarked DSCP values
should not cause failure of network nodes. The remarks in <xref target="RFC2474"/> regarding
IPsec and Tunnelling Interactions are also relevant (though this is not to say that other
sections are less relevant). </t>
<t>In this discussion, interpretation (and any possible intentional re-marking) of the DSCP
values of packets destined for DetNet OT flows is expected to occur at the ingress to the
DetNet domain; once inside the domain, maintaining the integrity of the DSCP values is
subject to the same handling considerations as any other field in the packet.</t>
</section>
<section anchor="ThreatSection" title="Security Threats">
<t>This section presents a taxonomy of threats, and analyzes the possible threats in a
DetNet-enabled network. The threats considered in this section are independent of any
specific technologies used to implement the DetNet; <xref target="TechnologySpecificThreats"
/> considers attacks that are associated with the DetNet technologies encompassed by <xref
target="RFC8938"/>. </t>
<t> We distinguish controller plane threats from data plane threats. The attack surface may be
the same, but the types of attacks as well as the motivation behind them, are different. For
example, a delay attack is more relevant to data plane than to controller plane. There is
also a difference in terms of security solutions: the way you secure the data plane is often
different than the way you secure the controller plane. </t>
<section title="Threat Taxonomy">
<t>This document employs organizational elements of the threat models of <xref
target="RFC7384"/> and <xref target="RFC7835"/>. This model classifies attackers based
on two criteria: </t>
<t>
<list style="symbols">
<t>Internal vs. external: internal attackers either have access to a trusted segment of
the network or possess the encryption or authentication keys. External attackers, on
the other hand, do not have the keys and have access only to the encrypted or
authenticated traffic.</t>
<t>On-path vs. off-path: on-path attackers are located in a position that allows
interception, modification, or dropping of in-flight protocol packets, whereas
off-path attackers can only attack by generating protocol packets.</t>
</list>
</t>
<t>Regarding the boundary between internal vs. external attackers as defined above, please
note that in this document we do not make concrete recommendations regarding which
specific segments of the network are to be protected in any specific way, for example via
encryption or authentication. As a result, the boundary as defined above is not
unequivocally specified here. Given that constraint, the reader can view an internal
attacker as one who can operate within the perimeter defined by the DetNet Edge Nodes (as
defined in the DetNet Architecture <xref target="RFC8655"/>), allowing that the specifics
of what is encrypted or authenticated within this perimeter will vary depending on the
implementation. </t>
<t>Care has also been taken to adhere to Section 5 of <xref target="RFC3552"/>, both with
respect to which attacks are considered out-of-scope for this document, but also which are
considered to be the most common threats (explored further in <xref
target="ThreatAnalysis"/>, Threat Analysis). Most of the direct threats to DetNet are
active attacks (i.e. attacks that modify DetNet traffic), but it is highly suggested that
DetNet application developers take appropriate measures to protect the content of the
DetNet flows from passive attacks (i.e. attacks that observe but do not modify DetNet
traffic) for example through the use of TLS or DTLS. </t>
<t>DetNet-Service, one of the service scenarios described in <xref
target="I-D.varga-detnet-service-model"/>, is the case where a service connects DetNet
islands, i.e. two or more otherwise independent DetNets are connected via a link that is
not intrinsically part of either network. This implies that there could be DetNet traffic
flowing over a non-DetNet link, which may provide an attacker with an advantageous
opportunity to tamper with DetNet traffic. The security properties of non-DetNet links are
outside of the scope of DetNet Security, but it should be noted that use of non-DetNet
services to interconnect DetNets merits security analysis to ensure the integrity of the
networks involved. </t>
</section>
<section anchor="ThreatAnalysis" title="Threat Analysis">
<section anchor="DelayThreat" title="Delay">
<t>An attacker can maliciously delay DetNet data flow traffic. By delaying the traffic,
the attacker can compromise the service of applications that are sensitive to high
delays or to high delay variation. The delay may be constant or modulated.</t>
</section>
<section anchor="ModificationThreat" title="DetNet Flow Modification or Spoofing">
<t>An attacker can modify some header fields of en route packets in a way that causes the
DetNet flow identification mechanisms to misclassify the flow. Alternatively, the
attacker can inject traffic that is tailored to appear as if it belongs to a legitimate
DetNet flow. The potential consequence is that the DetNet flow resource allocation
cannot guarantee the performance that is expected when the flow identification works
correctly.</t>
</section>
<section anchor="SegmentThreat"
title="Resource Segmentation (Inter-segment Attack) Vulnerability">
<t>DetNet nodes are expected to split their resources between DetNet flows in a way that
prevents traffic from one DetNet flow from affecting the performance of other DetNet
flows, and prevents non-DetNet traffic from affecting DetNet traffic. However, due to
implementation constraints ,in some DetNet nodes some of the resources may be partially
shared. An attacker can try to exploit this property. For example, an attacker can
inject traffic that will consume network resources such that it affects DetNet flows.
This can be performed using non-DetNet traffic that indirectly affects DetNet traffic
(hardware resource exhaustion), or by using DetNet traffic from one DetNet flow that
directly affects traffic from different DetNet flows.</t>
</section>
<section anchor="ReplicationThreat" title="Packet Replication and Elimination">
<section title="Replication: Increased Attack Surface">
<t>Redundancy is intended to increase the robustness and survivability of DetNet flows,
and replication over multiple paths can potentially mitigate an attack that is limited
to a single path. However, the fact that packets are replicated over multiple paths
increases the attack surface of the network, i.e., there are more points in the
network that may be subject to attacks.</t>
</section>
<section title="Replication-related Header Manipulation">
<t>An attacker can manipulate the replication-related header fields. This capability
opens the door for various types of attacks. For example:</t>
<t>
<list style="symbols">
<t>Forward both replicas - malicious change of a packet SN (Sequence Number) can
cause both replicas of the packet to be forwarded. Note that this attack has a
similar outcome to a replay attack.</t>
<t>Eliminate both replicas - SN manipulation can be used to cause both replicas to
be eliminated. In this case an attacker that has access to a single path can cause
packets from other paths to be dropped, thus compromising some of the advantage of
path redundancy.</t>
<t>Flow hijacking - an attacker can hijack a DetNet flow with access to a single
path by systematically replacing the SNs on the given path with higher SN values.
For example, an attacker can replace every SN value S with a higher value S+C,
where C is a constant integer. Thus, the attacker creates a false illusion that
the attacked path has the lowest delay, causing all packets from other paths to be
eliminated in favor of the attacked path. Once the flow from the compromised path
is favored by the eliminating bridge, the flow has effectively been hijacked by
the attacker. It is now possible for the attacker to either replace en route
packets with malicious packets, or to simply inject errors into the packets,
causing the packets to be dropped at their destination.</t>
<t>Amplification - an attacker who injects packets into a flow that is to be
replicated will have their attack amplified through the replication process. This
is no different than any attacker who injects packets that are delivered through
multicast, broadcast, or other point-to-multi-point mechanisms. </t>
</list>
</t>
</section>
</section>
<section anchor="ControllerThreat" title="Controller Plane">
<section anchor="PathThreat" title="Path Choice Manipulation">
<section title="Control or Signaling Packet Modification">
<t>An attacker can maliciously modify en route control packets in order to disrupt or
manipulate the DetNet path/resource allocation.</t>
</section>
<section title="Control or Signaling Packet Injection">
<t>An attacker can maliciously inject control packets in order to disrupt or
manipulate the DetNet path/resource allocation.</t>
</section>
<section title="Increased Attack Surface">
<t>One of the possible consequences of a path manipulation attack is an increased
attack surface. Thus, when the attack described in the previous subsection is
implemented, it may increase the potential of other attacks to be performed.</t>
</section>
</section>
<section title="Compromised Controller">
<t>An attacker can subvert a legitimate controller (or subvert another component such
that it represents itself as a legitimate controller) with the result that the network
nodes incorrectly believe it is authorized to instruct them. </t>
<t>The presence of a compromised node or controller in a DetNet is not a threat that
arises as a result of determinism or time sensitivity; the same techniques used to
prevent or mitigate against compromised nodes in any network are equally applicable in
the DetNet case. The act of compromising a controller may not even be within the
capabilities of our defined attacker types - in other words it may not be achievable
via packet traffic at all, whether internal or external, on-path or off-path. It might
be accomplished for example by a human with physical access to the component, who
could upload bogus firmware to it via a USB stick. All of this underscores the
requirement for careful overall system security design in a DetNet, given that the
effects of even one bad actor on the network can be potentially catastrophic. </t>
<t>Security concerns specific to any given controller plane technology used in DetNet
will be addressed by the DetNet documents associated with that technology. </t>
</section>
</section>
<section anchor="ReconnaissanceThreat" title="Reconnaissance">
<t>A passive eavesdropper can identify DetNet flows and then gather information about en
route DetNet flows, e.g., the number of DetNet flows, their bandwidths, their schedules,
or other temporal or statistical properties. The gathered information can later be used
to invoke other attacks on some or all of the flows.</t>
<t>DetNet flows are typically uniquely identified by their 6-tuple, i.e. fields within the
L3 or L4 header, however in some implementations the flow ID may also be augmented by
additional per-flow attributes known to the system, e.g. above L4. For the purpose of
this document we assume any such additional fields used for flow ID are encrypted and/or
integrity-protected from external attackers. Note however that existing OT protocols
designed for use on dedicated secure networks may not intrinsically provide such
protection, in which case IPsec or transport layer security mechanisms may be
needed.</t>
</section>
<section anchor="SyncThreat" title="Time Synchronization Mechanisms">
<t>An attacker can use any of the attacks described in <xref target="RFC7384"/> to attack
the synchronization protocol, thus affecting the DetNet service. </t>
</section>
</section>
<section title="Threat Summary">
<t>A summary of the attacks that were discussed in this section is presented in <xref
target="ThreatSummary"/>. For each attack, the table specifies the type of attackers
that may invoke the attack. In the context of this summary, the distinction between
internal and external attacks is under the assumption that a corresponding security
mechanism is being used, and that the corresponding network equipment takes part in this
mechanism. </t>
<figure align="center" anchor="ThreatSummary" title="Threat Analysis Summary">
<artwork align="left">
<![CDATA[
+-------------------------------------------+----+-----+----+-----+
| Attack | Attacker Type |
| +----------+----------+
| | Internal | External |
| |On-P|Off-P|On-P|Off-P|
+-------------------------------------------+----+-----+----+-----+
|Delay attack | + | | + | |
+-------------------------------------------+----+-----+----+-----+
|DetNet Flow Modification or Spoofing | + | + | | |
+-------------------------------------------+----+-----+----+-----+
|Inter-segment Attack | + | + | + | + |
+-------------------------------------------+----+-----+----+-----+
|Replication: Increased Attack Surface | + | + | + | + |
+-------------------------------------------+----+-----+----+-----+
|Replication-related Header Manipulation | + | | | |
+-------------------------------------------+----+-----+----+-----+
|Path Manipulation | + | + | | |
+-------------------------------------------+----+-----+----+-----+
|Path Choice: Increased Attack Surface | + | + | + | + |
+-------------------------------------------+----+-----+----+-----+
|Control or Signaling Packet Modification | + | | | |
+-------------------------------------------+----+-----+----+-----+
|Control or Signaling Packet Injection | + | + | | |
+-------------------------------------------+----+-----+----+-----+
|Reconnaissance | + | | + | |
+-------------------------------------------+----+-----+----+-----+
|Attacks on Time Synchronization Mechanisms | + | + | + | + |
+-------------------------------------------+----+-----+----+-----+
]]></artwork>
</figure>
</section>
</section>
<!-- Section: Security Threats -->
<section anchor="ThreatImpact" title="Security Threat Impacts">
<t>When designing security for a DetNet, as with any network, it may be prohibitively
expensive or technically infeasible to thoroughly protect against every possible threat.
Thus the security designer must be informed (for example by an application domain expert
such as a product manager) regarding the relative significance of the various threats and
their impact if a successful attack is carried out. In this section we present an example of
a possible template for such a communication, culminating in a table (<xref
target="ThreatIndustryMapping"/>) which lists a set of threats under consideration, and
some values characterizing their relative impact in the context of a given industry. The
specific threats, industries, and impact values in the table are provided only as an example
of this kind of assessment and its communication; they are not intended to be taken
literally.</t>
<t>This section considers assessment of the relative impacts of the attacks described in <xref
target="ThreatSection"/>, Security Threats. In this section, the impacts as described
assume that the associated mitigation is not present or has failed. Mitigations are
discussed in <xref target="ThreatMitigation"/>, Security Threat Mitigation. </t>
<t> In computer security, the impact (or consequence) of an incident can be measured in loss
of confidentiality, integrity or availability of information. In the case of time sensitive
or OT networks (though not to the exclusion of IT or non-time-sensitive networks) the impact
of an exploit can also include failure or malfunction of mechanical and/or other physical
systems. </t>
<t>DetNet raises these stakes significantly for OT applications, particularly those which may
have been designed to run in an OT-only environment and thus may not have been designed for
security in an IT environment with its associated components, services and protocols. </t>
<t>The extent of impact of a successful vulnerability exploit varies considerably by use case
and by industry; additional insights regarding the individual use cases is available from
<xref target="RFC8578"/>, DetNet Use Cases. Each of those use cases is represented in
<xref target="ThreatIndustryMapping"/>, including Pro Audio, Electrical Utilities,
Industrial M2M (split into two areas, M2M Data Gathering and M2M Control Loop), and others. </t>
<t>Aspects of Impact (left column) include Criticality of Failure, Effects of Failure,
Recovery, and DetNet Functional Dependence. Criticality of failure summarizes the
seriousness of the impact. The impact of a resulting failure can affect many different
metrics that vary greatly in scope and severity. In order to reduce the number of variables,
only the following were included: Financial, Health and Safety, Effect on a Single
Organization, and Effect on Multiple Organizations. Recovery outlines how long it would take
for an affected use case to get back to its pre-failure state (Recovery time objective,
RTO), and how much of the original service would be lost in between the time of service
failure and recovery to original state (Recovery Point Objective, RPO). DetNet dependence
maps how much the following DetNet service objectives contribute to impact of failure: Time
dependency, data integrity, source node integrity, availability, latency/jitter.</t>
<t>The scale of the Impact mappings is low, medium, and high. In some use cases there may be a
multitude of specific applications in which DetNet is used. For simplicity this section
attempts to average the varied impacts of different applications. This section does not
address the overall risk of a certain impact which would require the likelihood of a failure
happening. </t>
<t>In practice any such ratings will vary from case to case; the ratings shown here are given
as examples.</t>
<figure align="center" anchor="ThreatIndustryMapping"
title="Impact of Attacks by Use Case Industry">
<artwork align="left">
<![CDATA[
Table
+------------------+-----------------------------------------+-----+
| | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M |
| | | | | less | |Data |Ctrl |
+------------------+-----------------------------------------+-----+
| Criticality | Med | Hi | Low | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Effects
+------------------+-----------------------------------------+-----+
| Financial | Med | Hi | Med | Med | Low | Med | Med |
+------------------+-----------------------------------------+-----+
| Health/Safety | Med | Hi | Hi | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Affects 1 org | Hi | Hi | Med | Hi | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Affects >1 org | Med | Hi | Low | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
|Recovery
+------------------+-----------------------------------------+-----+
| Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
|DetNet Dependence
+------------------+-----------------------------------------+-----+
| Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi |
+------------------+-----------------------------------------+-----+
| Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi |
+------------------+-----------------------------------------+-----+
| Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Availability | Hi | Hi | Med | Hi | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
]]></artwork>
</figure>
<t>The rest of this section will cover impact of the different groups in more detail.</t>
<section anchor="DelayImpact" title="Delay-Attacks">
<!-- <xref target="DelayThreat"/> -->
<section title="Data Plane Delay Attacks">
<t>Note that 'delay attack' also includes the possibility of a 'negative delay' or early
arrival of a packet, or possibly adversely changing the timestamp value. </t>
<t> Delayed messages in a DetNet link can result in the same behavior as dropped messages
in ordinary networks, since the services attached to the DetNet flow are likely to have
strict delivery time requirements.</t>
<t>For a single path scenario, disruption within the single flow is a real possibility. In
a multipath scenario, large delays or instabilities in one DetNet flow can also lead to
increased buffer and processor resource consumption at the eliminating router.</t>
<t>A data-plane delay attack on a system controlling substantial moving devices, for
example in industrial automation, can cause physical damage. For example, if the network
promises a bounded latency of 2ms for a flow, yet the machine receives it with 5ms
latency, control loop of the machine can become unstable. </t>
</section>
<section title="Controller Plane Delay Attacks">
<t>In and of itself, this is not directly a threat to the DetNet service, but the effects
of delaying control messages can have quite adverse effects later.</t>
<t>
<list style="symbols">
<t>Delayed tear-down can lead to resource leakage, which in turn can result in failure
to allocate new DetNet flows, finally giving rise to a denial of service attack.</t>
<t>Failure to deliver, or severely delaying, controller plane messages adding an
endpoint to a multicast-group will prevent the new endpoint from receiving expected
frames thus disrupting expected behavior.</t>
<t>Delaying messages removing an endpoint from a group can lead to loss of privacy as
the endpoint will continue to receive messages even after it is supposedly
removed.</t>
</list>
</t>
</section>
</section>
<section anchor="SpoofingImpact" title="Flow Modification and Spoofing">
<section title="Flow Modification">
<t>If the contents of a packet header or body can be modified by the attacker, this can
cause the packet to be routed incorrectly or dropped, or the payload to be corrupted or
subtly modified. Thus, the potential impact of a modification attack includes disrupting
the application as well as the network equipment.</t>
</section>
<section title="Spoofing">
<section title="Dataplane Spoofing">
<t>Spoofing dataplane messages can result in increased resource consumptions on the
routers throughout the network as it will increase buffer usage and processor
utilization. This can lead to resource exhaustion and/or increased delay.</t>
<t>If the attacker manages to create valid headers, the false messages can be forwarded
through the network, using part of the allocated bandwidth. This in turn can cause
legitimate messages to be dropped when the resource budget has been exhausted.</t>
<t>Finally, the endpoint will have to deal with invalid messages being delivered to the
endpoint instead of (or in addition to) a valid message.</t>
</section>
<section title="Controller Plane Spoofing">
<t>A successful controller plane spoofing-attack will potentially have adverse effects.
It can do virtually anything from:</t>
<t>
<list style="symbols">
<t>modifying existing DetNet flows by changing the available bandwidth</t>
<t>add or remove endpoints from a DetNet flow</t>
<t>drop DetNet flows completely</t>
<t>falsely create new DetNet flows (exhaust the systems resources, or to enable
DetNet flows that are outside the control of the Network Engineer)</t>
</list>
</t>
</section>
<!-- Controller Plane Spoofing -->
</section>
<!-- spoofing-->
</section>
<!-- Flow Modification and Spoofing impact -->
<section anchor="SegmentationImpact" title="Segmentation Attacks (injection)">
<section title="Data Plane Segmentation">
<t>Injection of false messages in a DetNet flow could lead to exhaustion of the available
bandwidth for that flow if the routers attribute these false messages to the resource
budget of that flow. </t>
<t>In a multipath scenario, injected messages will cause increased processor utilization
in elimination routers. If enough paths are subject to malicious injection, the
legitimate messages can be dropped. Likewise it can cause an increase in buffer usage.
In total, it will consume more resources in the routers than normal, giving rise to a
resource exhaustion attack on the routers.</t>
<t>If a DetNet flow is interrupted, the end application will be affected by what is now a
non-deterministic flow. Note that there are many possible sources of flow interruptions,
for example, but not limited to, such physical layer conditions as a broken wire or a
radio link which is compromised by interference. </t>
</section>
<section title="Controller Plane Segmentation">
<t> In a successful controller plane segmentation attack, control messages are acted on by
nodes in the network, unbeknownst to the central controller or the network engineer.
This has the potential to: </t>
<t>
<list style="symbols">
<t>create new DetNet flows (exhausting resources)</t>
<t>drop existing DetNet flows (denial of service)</t>
<t>add end-stations to a multicast group (loss of privacy)</t>
<t>remove end-stations from a multicast group (reduction of service)</t>
<t>modify the DetNet flow attributes (affecting available bandwidth)</t>
</list>
</t>
<t>If an attacker can inject control messages without the central controller knowing, then
one or more components in the network may get into a state that is not expected by the
controller. At that point, if the controller initiates a command, the effect of that
command may not be as expected, since the target of the command may have started from a
different initial state. </t>
</section>
<!-- cp segment impact -->
</section>
<!-- SegmentationImpact -->
<section anchor="ReplicationImpact" title="Replication and Elimination">
<t> The Replication and Elimination is relevant only to data plane messages as controller
plane messages are not subject to multipath routing. </t>
<section title="Increased Attack Surface">
<t>The impact of an increased attack surface is that it increases the probability that the
network can be exposed to an attacker. This can facilitate a wide range of specific
attacks, and their respective impacts are discussed in other subsections of this
section.</t>
</section>
<section title="Header Manipulation at Elimination Routers">
<t>This attack can potentially cause DoS to the application that uses the attacked DetNet
flows or to the network equipment that forwards them. Furthermore, it can allow an
attacker to manipulate the network paths and the behavior of the network layer.</t>
</section>
</section>
<section title="Control or Signaling Packet Modification">
<t>If control packets are subject to manipulation undetected, the network can be severely
compromised.</t>
</section>
<section title="Control or Signaling Packet Injection">
<t>If an attacker can inject control packets undetected, the network can be severely
compromised.</t>
</section>
<section title="Reconnaissance" anchor="Reconnaissance">
<t> Of all the attacks, this is one of the most difficult to detect and counter. </t>
<t> An attacker can, at their leisure, observe over time various aspects of the messaging
and signalling, learning the intent and purpose of the traffic flows. Then at some later
date, possibly at an important time in the operational context, they might launch an
attack based on that knowledge. </t>
<t> The flow-id in the header of the data plane messages gives an attacker a very reliable
identifier for DetNet traffic, and this traffic has a high probability of going to
lucrative targets. </t>
<t>Applications which are ported from a private OT network to the higher visibility DetNet
environment may need to be adapted to limit distinctive flow properties that could make
them susceptible to reconnaissance. </t>
</section>
<section title="Attacks on Time Synchronization Mechanisms">
<t>DetNet relies on an underlying time synchronization mechanism, and therefore a
compromised synchronization mechanism may cause DetNet nodes to malfunction. Specifically,
DetNet flows may fail to meet their latency requirements and deterministic behavior, thus
causing DoS to DetNet applications. </t>
</section>
<section title="Attacks on Path Choice" anchor="PathChoiceImpact">
<t>This is covered in part in <xref target="SegmentationImpact"/>, Segmentation Attacks, and
as with Replication and Elimination ( <xref target="ReplicationImpact"/>), this is
relevant for DataPlane messages. </t>
</section>
</section>
<!-- Section: Security Threat Impacts-->
<section anchor="ThreatMitigation" title="Security Threat Mitigation">
<t>This section describes a set of measures that can be taken to mitigate the attacks
described in <xref target="ThreatSection"/>, Security Threats. These mitigations should be
viewed as a set of tools, any of which can be used individually or in concert. The DetNet
component and/or system and/or application designer can apply these tools, as necessary
based on a system-specific threat analysis. </t>
<t>Some of the technology-specific security considerations and mitigation approaches are
further discussed in the DetNet data plane solution documents, such as <xref
target="RFC8939"/>, <xref target="RFC8938"/>, <xref
target="I-D.ietf-detnet-mpls-over-udp-ip"/>, and <xref
target="I-D.ietf-detnet-ip-over-mpls"/>. </t>
<section title="Path Redundancy">
<t>Description <list hangIndent="10" style="empty">
<t>A DetNet flow that can be forwarded simultaneously over multiple paths. Packet
replication and elimination <xref target="RFC8655"/> provides resiliency to dropped or
delayed packets. This redundancy improves the robustness to failures and to on-path
attacks. Note: At the time of this writing, PREOF is not defined for the IP data
plane. </t>
</list>
</t>
<t>Related attacks <list hangIndent="10" style="empty">
<t>Path redundancy can be used to mitigate various on-path attacks, including attacks
described in <xref target="DelayThreat"/>, <xref target="ModificationThreat"/>, <xref
target="SegmentThreat"/>, and <xref target="SyncThreat"/>. However it is also
possible that multiple paths may make it more difficult to locate the source of an
on-path attacker. </t>
<t>A delay modulation attack could result in extensively exercising parts of the code
that wouldn't normally be extensively exercised and thus might expose flaws in the
system that might otherwise not be exposed. </t>
</list>
</t>
</section>
<section anchor="IntegritySection" title="Integrity Protection">
<t>Description <list hangIndent="10" style="empty">
<t>Integrity Protection in the scope of DetNet is the ability to detect if a packet
header has been modified (maliciously or otherwise) and if so, take some appropriate
action (as discussed in <xref target="DpaMitigation"/>). The decision on where in the
network to apply integrity protection is part of the DetNet system design, and the
implementation of the protection method itself is a part of a DetNet component
design.</t>
<t>The most common technique for detecting header modification is the use of a Message
Authentication Code (MAC) (for examples see <xref target="TechnologySpecificThreats"
/>). The MAC can be distributed either in-line (included in the same packet) or via a
side channel. Of these, the in-line method is generally preferred due to the low
latency that may be required on DetNet flows and the relative complexity and
computational overhead of a sideband approach. </t>
<t> There are different levels of security available for integrity protection, ranging
from the basic ability to detect if a header has been corrupted in transit (no
malicious attack) to stopping a skilled and determined attacker capable of both subtly
modifying fields in the headers as well as updating an unsigned MAC. Common for all
are the 2 steps that need to be performed in both ends. The first is computing the
checksum or MAC. The corresponding verification step must perform the same steps
before comparing the provided with the computed value. Only then can the receiver be
reasonably sure that the header is authentic. </t>
<t> The most basic protection mechanism consists of computing a simple checksum of the
header fields and provide it to the next entity in the packets path for verification.
Using a MAC combined with a secret key provides the best protection against
modification and replication attacks (see <xref target="ModificationThreat"/> and
<xref target="ReplicationThreat"/>). This MAC usage needs to be part of a security
association that is established and managed by a security association protocol (such
as IKEv2 for IPsec security associations). Integrity protection in the controller
plane is discussed in <xref target="ControllerProtectSection"/>. The secret key,
regardless of MAC used, must be protected from falling into the hands of unauthorized
users. Once key management becomes a topic, it is important to understand that this is
a delicate process and should not be undertaken lightly. BCP 107 <xref
target="RFC4107"/> provides best practices in this regard.</t>
<t> DetNet system and/or component designers need to be aware of these distinctions and
enforce appropriate integrity protection mechanisms as needed based on a threat
analysis. Note that adding integrity protection mechanisms may introduce latency, thus
many of the same considerations in <xref target="EncryptionConsiderations"/> also
apply here. </t>
</list>
</t>
<t>Packet Sequence Number Integrity Considerations <list hangIndent="10" style="empty">
<t>The use of PREOF in a DetNet implementation implies the use of a sequence number for
each packet. There is a trust relationship between the component that adds the
sequence number and the component that removes the sequence number. The sequence
number may be end-to-end source to destination, or may be added/deleted by network
edge components. The adder and remover(s) have the trust relationship because they are
the ones that ensure that the sequence numbers are not modifiable. Thus, sequence
numbers can be protected by using authenticated encryption, or by a MAC without using
encryption. Between the adder and remover there may or may not be replication and
elimination functions. The elimination functions must be able to see the sequence
numbers. Therefore, if encryption is done between adders and removers it must not
obscure the sequence number. If the sequence removers and the eliminators are in the
same physical component, it may be possible to obscure the sequence number, however
that is a layer violation, and is not recommended practice. Note: At the time of this
writing, PREOF is not defined for the IP data plane.</t>
</list>
</t>
<t>Related attacks <list hangIndent="10" style="empty">
<t>Integrity protection mitigates attacks related to modification and tampering,
including the attacks described in <xref target="ModificationThreat"/> and <xref
target="ReplicationThreat"/>. </t>