-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-idr-flowspec-v2-03.xml
3356 lines (3232 loc) · 125 KB
/
draft-ietf-idr-flowspec-v2-03.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC5065 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
<!ENTITY RFC5701 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5701.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6482 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6482.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7153.xml">
<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
<!ENTITY RFC8040 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8205.xml">
<!ENTITY RFC8206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8206.xml">
<!ENTITY RFC8955 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8955.xml">
<!ENTITY RFC8956 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8956.xml">
<!ENTITY RFC9015 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9015.xml">
<!ENTITY RFC9117 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9117.xml">
<!ENTITY RFC9184 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9184.xml">
<!ENTITY I-D.ietf-idr-wide-bgp-communities SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-wide-bgp-communities.xml">
<!ENTITY I-D.ietf-idr-flowspec-l2vpn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-l2vpn.xml">
<!ENTITY I-D.ietf-idr-flowspec-nvo3 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-nvo3.xml">
<!ENTITY I-D.ietf-idr-flowspec-srv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-srv6.xml">
<!ENTITY I-D.ietf-idr-flowspec-mpls-match SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-mpls-match.xml">
<!ENTITY I-D.ietf-idr-bgp-flowspec-label SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-flowspec-label.xml">
<!ENTITY I-D.ietf-idr-flowspec-interfaceset SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-interfaceset.xml">
<!ENTITY I-D.ietf-idr-flowspec-path-redirect SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-path-redirect.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-idr-flowspec-v2-03" ipr="trust200902">
<front>
<title abbrev="BGP FlowSpec v2">BGP Flow Specification Version 2 </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Hickory Hill Consulting</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<phone>+1-734-604-0332</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Donald Eastlake" initials="D" surname="Eastlake">
<organization>Futurewei Technologies</organization>
<address>
<postal>
<street>2386 Panoramic Circle</street>
<city>Apopka</city>
<region>FL</region>
<code>32703</code>
<country>USA</country>
</postal>
<phone>+1-508-333-2270</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Chaitanya Yadlapalli" initials="C" surname="Yadlapalli">
<organization>ATT</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Sven Maduschke" initials="S" surname="Maduscke" >
<organization> Verizon</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>DE</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2023" />
<area>Routing Area</area>
<workgroup>IDR Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>BGP Flow Specification</keyword>
<abstract>
<t>BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and
RFC 9117 describes the distribution of traffic filter policy (traffic
filters and actions) distributed via BGP. Multiple applications have used
BGP FSv1 to distribute traffic filter policy. These applications include
the following: mitigation of denial of service (DoS), enabling traffic
filtering in BGP/MPLS VPNs, centralized traffic control of router firewall
functions, and SFC traffic insertion.
</t>
<t> During the deployment of BGP FSv1 a number of issues were detected due to
lack of consistent TLV encoding for rules for flow specifications, lack of
user ordering of filter rules and/or actions, and lack of clear definition
of interaction with BGP peers not supporting FSv1. Version 2 of the BGP
flow specification (FSv2) protocol addresses these features. In order to
provide a clear demarcation between FSv1 and FSv2, a different NLRI
encapsulates FSv2.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Modern IP routers have the capability to forward traffic and to classify,
shape, rate limit, filter, or redirect packets based on administratively
defined policies. These traffic policy mechanisms allow the operator
to define match rules that operate on multiple fields within header
of an IP data packet. The traffic policy allows actions
to be taken upon a match to be associated with each match rule.
These rules can be more widely defined as “event-condition-action”
(ECA) rules where the event is always the reception of a packet.
</t>
<t>BGP (<xref target="RFC4271"></xref>) flow specification as defined by
<xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>,
<xref target="RFC9117"></xref> specifies the distribution of traffic filter policy (traffic
filters and actions) via BGP to a mesh of BGP peers (IBGP and EBGP peers).
The traffic filter policy is applied when packets are received on a router
with the flow specification function turned on. The flow specification
protocol defined in <xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>, and
<xref target="RFC9117"></xref> will be called BGP
flow specification version 1 (BGP FSv1) in this draft.
</t>
<t> Some modern IP routers also include the abilities of firewalls which can
match on a sequence of packet events based on administrative policy. These
firewall capabilities allow for user ordering of match rules and user
ordering of actions per match.
</t>
<t>
Multiple deployed applications currently use BGP FSv1 to distribute traffic
filter policy. These applications include: 1) mitigation of Denial of
Service (DoS), 2) traffic filtering in BGP/MPLS VPNS, and 3) centralized
traffic control for networks utilizing SDN control of router firewall
functions, 4) classifiers for insertion in an SFC, and 5) filters for SRv6 (segment routing v6).
</t>
<t>During the deployment of BGP flow specification
v1, the following issues were detected:
<list style="symbols">
<t>lack of consistent TLV encoding prevented extension of encodings, </t>
<t>inability to allow user defined order for filtering rules,</t>
<t>inability to order actions to provide deterministic interactions
or to allow users to define order for actions, and</t>
<t>no clearly defined mechanisms for BGP peers which do
not support flow specification v1.</t>
</list>
</t>
<t>
Networks currently cope with some of these issues by limiting the type of
traffic filter policy sent in BGP. Current Networks do not have a good
workaround/solution for applications that receive but do not understand FSv1
policies.
</t>
<t>
This document defines version 2 of the BGP flow specification protocol to
address these shortcomings in BGP FSv1. Version 2 of BGP flow specification
will be denoted as BGP FSv2.
</t>
<t>BGP FSv1 as defined in <xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>, and
<xref target="RFC9117"></xref> specified 2 SAFIs (133, 134)
to be used with IPv4 AFI (AFI = 1) and IPv6 AFI (AFI=2).
</t>
<t>
This document specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs
(1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered
traffic match actions encoded in Communities (Wide or Extended).
</t>
<t>
FSv1 and FSv2 use different AFI/SAFIs to send flow specification filters. Since BGP
route selection is performed per AFI/SAFI, this approach can be termed “ships in the night” based on AFI/SAFI.
</t>
<t>
FSv1 is a critical component of deployed applications. Therefore, this
specification defines how FSv2 will interact with BGP peers that support
either FSv2, FSv1, FSv2 and FSv1,or neither of them.
It is expected that a transition to FSv2 will occur over time as new
applications require FSv2 extensibility and user-defined ordering for rules
and actions or network operators tire of the restrictions of FSv1 such as error
handling issues and restricted topologies.
</t>
<t>
Section 2 contains the definition of Flow specification, a short review of FSv1 and an overview of FSv2.
Section 3 contains the encoding rules for FSv2 and user-based encoding sent via BGP. Section 4 describes how to
validate FSv2 NLRI. Section 5 discusses how to order FSV2 rules. Section 6 covers combining
FSv2 user-ordered match rules and FSv1 rules. Section 6 also discusses how to combine
user-ordered actions, FSv1 actions, and default actions. Sections 7-10 address an
alternate security mechanism, considerations for IANA, security in deployments, and scalability aspirations.
</t>
<section title="Definitions and Acronyms">
<t><list>
<t>AFI - Address Family Identifier</t>
<t>AS - Autonomous System </t>
<t>BGPSEC - secure BGP <xref target="RFC8205"></xref> updated by <xref target="RFC8206"></xref> </t>
<t>BGP Session ephemeral state - state which does not survive the loss of BGP peer session.</t>
<t>Configuration state - state which persist across a reboot of software module within
a routing system or a reboot of a hardware routing device.</t>
<t>DDOs - Distributed Denial of Service.</t>
<t>Ephemeral state - state which does not survive the reboot of a software module,
or a hardware reboot. Ephemeral state can be ephemeral configuration state or
operational state.</t>
<t>FSv1 - Flow Specification version 1 [RFC8955] [RFC8956] </t>
<t>FSv2 - Flow Specification version 2 (this document) </t>
<t>NETCONF - The Network Configuration Protocol <xref target="RFC6241"></xref>.</t>
<t>RESTCONF - The RESTCONF configuration Protocol <xref target="RFC8040"></xref> </t>
<t>RIB - Routing Information Base.</t>
<t> ROA - Route Origin Authentication <xref target="RFC6482"></xref></t>
<t>RR - Route Reflector.</t>
<t> SAFI – Subsequent Address Family Identifier </t>
</list>
</t>
</section>
<section title="RFC 2119 language">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref>
<xref target="RFC8174"></xref> when, and only when, they appear in all capitals as shown here.
</t>
</section>
</section>
<section title="Flow Specification ">
<t>
A BGP Flow Specification is an n-tuple containing one or more match criteria
that can be applied to IP traffic, traffic encapsulated in IP traffic or
traffic associated with IP traffic. The following are
examples of such traffic: IP packet or an IP packet
inside a L2 packet (Ethernet), an MPLS packet, and SFC flow.
</t>
<t>
A given Flow Specification NLRI may be associated with a set of path
attributes depending on the particular application, and attributes within
that set may or may not include reachability information (e.g., NEXT_HOP).
Extended Community or Wide Community attributes (well-known or AS-specific)
MAY be used to encode a set of pre-determined actions.
</t>
<t>
A particular application is identified by a specific AFI/SAFI (Address
Family Identifier/Subsequent Address Family Identifier) and corresponds to a
distinct set of RIBs. Those RIBs should be treated independently of each
other in order to assure noninterference between distinct applications.
</t>
<t>
BGP processing treats the NLRI as a key to entries in AFI/SAFI BGP
databases. Entries that are placed in the Loc-RIB are then associated with
a given set of semantics which are application dependent. Standard BGP
mechanisms such as update filtering by NLRI or by attributes such as AS_PATH or
large communities apply to the BGP Flow Specification defined NLRI-types.
</t>
<t>
Network operators can control the propagation of BGP routes by enabling or
disabling the exchange of routes for a particular AFI/SAFI pair on a
particular peering session. As such, the Flow Specification may be
distributed to only a portion of the BGP infrastructure.
</t>
<section title="Flow Specification v1 (FSv1) Overview">
<t>
The FSv1 NLRI defined in <xref target="RFC8955"></xref> and <xref target="RFC8956"></xref>
include 13 match conditions encoded for the following AFI/SAFIs:
<list style="symbol">
<t>IPv4 traffic: AFI:1, SAFI:133 </t>
<t>IPv6 Traffic: AFI:2, SAFI:133 </t>
<t>BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134
</t>
<t> BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134</t>
</list>
</t>
<t>If one considers the reception of the packet as an event,
then BGP FSv1 describes a set of
Event-MatchCondition-Action (ECA) policies where:
<list style="symbol">
<t>event is the reception of a packet, </t>
<t>condition stands for “match conditions” defined in the BGP NLRI as an n-tuple of component filters, and </t>
<t>the action is either: the default condition (accept traffic), or a set of actions (1 or more)
defined in Extended BGP Community values <xref target="RFC4360"></xref>.
</t>
</list>
</t>
<t>
The flow specification conditions and actions combine to make up FSv1 specification rules. Each FSv1 NLRI must
have a type 1 component (destination prefix). Extended Communities with FSv1 actions can be attached
to a single NLRI or multiple NLRIs in a BGP message
</t>
<t>
Within an AFI/SAFI pair, FSv1 rules are ordered based on the components in
the packet (types 1-13) ordered from left-most to right-most and within the
component types by value of the component. Rules are inserted in the rule
list by component-based order where an FSv1 rule with existing component type has
higher precedence than one missing a specific component type,
</t>
<t>
Since FSv1 specifications (<xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>, and
<xref target="RFC9117"></xref>) specify that the FSv1 NLRI MUST have a destination prefix
(as component type 1) embedded in the flow specification, the FSv1 rules with destination
components are ordered by IP Prefix comparison rules for IPv4 (<xref target="RFC8955"></xref>)
and IPv6 (<xref target="RFC8956"></xref>). <xref target="RFC8955"></xref>
specifies that more specific prefixes (aka longest match) have higher precedence than
that of less specific prefixes and that for prefixes of the same length the lower IP number
is selected (lowest IP value). <xref target="RFC8955"></xref> specifies that if the
offsets within component 1 are the same, then the longest match and lowest IP comparison rules from
<xref target="RFC8955"></xref> apply. If the offsets are different, then the lower offset has precedence.
</t>
<t>
These rules provide a set of FSv1 rules ordered by IP Destination Prefix
by longest match and lowest IP address. <xref target="RFC8955"></xref>
also states that the requirement for a destination prefix component “MAY be relaxed by explicit configuration”
Since the rule insertions are based on comparing component types between two rules in order,
this means the rules without destination prefixes are inserted after all rules which
contain destination prefix component.
</t>
<t>
The actions specified in FSv1 are:
<list style="symbols">
<t>accept packet (default),</t>
<t>traffic flow limitation by bytes (0x6), </t>
<t>traffic-action (0x7),</t>
<t>redirect traffic (0x8),</t>
<t>mark traffic (0x9), and </t>
<t>traffic flow limitation by packets (12, 0xC)</t>
</list>
</t>
<t> Figure 1 shows a diagram of the FSv1 logical data structures
with 5 rules. If FSv1 rules have destination prefix components
(type=1) and FSv1 rule 5 does not have a destination prefix,
then FSv1 rule 5 will be inserted in the policy after rules 1-4.
<figure>
<artwork>
+--------------------------------------+
| Flow Specification (FS) |
| Policy |
+--------------------------------------+
^ ^ ^
| | |
| | |
+--------^----+ +-------^-------+ +-------------+
| FS Rule 1 | | FS Rule 2 | ... | FS rule 5 |
+-------------+ +---------------+ +-------------+
: :
: :
...: :........
: :
+---------V---------+ +----V-------------+
| Rule Condition | | Rule Action |
| in BGP NLRIs | | in BGP extended |
| AFIs: 1 and 2 | | Communities |
| SAFI 133, 134 | | |
+-------------------+ +------------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+
| Match | | match | |match | | Action | | action ||action|
|Operator| |Variable| |Value | |Operator| |variable|| Value|
|*1 | | | | | |(subtype| | || |
+--------+ +--------+ +------+ +--------+ +--------++------+
*1 match operator may be complex.
Figure 2-1: BGP Flow Specification v1 Policy
</artwork>
</figure>
</t>
</section>
<section title="Flow Specification v2 (FSv2) Overview">
<t>
Flow Specification v2 allows the user to order the flow specification rules and the actions
associated with a rule. Each FSv2 rule may have one or more match conditions
and one or more associated actions.
</t>
<t>
This FSv2 specification supports the components and actions for the following:
<list style="symbols">
<t>IPv4 (AFI=1, SAFI=TBD1),
</t>
<t>IPv6 (AFI=2, SAFI=TBD2),
</t>
<t>L2 (AFI=6, SAFI=TDB1),
</t>
<t>BGP/MPLS IPv4 VPN: (AFI=1, SAFI=TBD2),
</t>
<t> BGP/MPLS IPv6 VPN: (AFI=2, SAFI=TBD2),
</t>
<t> BGP/MPLS L2VPN (AFI=25, SAFI=TDB2),
</t>
<t> SFC: (AFI=31, SAFI=TBD1), and
</t>
<t> SFC VPN (AFI=31, SAFI=TBD2).
</t>
</list>
</t>
<t>The FSv2 specification for tunnel traffic is outside the
scope of this specification. The FSv1 specification for tunneled
traffic is in <xref target="I-D.ietf-idr-flowspec-nvo3"></xref>.
</t>
<t>FSv2 operates in the ships-in-the night model with FSv1 so network
operators can manipulate which the distribution of FSv2
and FSv1 using configuration parameters.
Since the lack of deterministic ordering was an FSv1 problem,
this specification provides rules and protocol features to keep
filters in a deterministic order between FSv1 and FSv2.
</t>
<t>
The basic principles regarding ordering of flow specification filter rules are:
<list>
<t>1) Rule-0 (zero) is defined to be 0/0 with the “permit-all” action. </t>
<t>2) FSv2 rules are ordered based on user-specified order.
<list>
<t>The user-specified order is carried in the FSv2 NLRI and a
numerical lower value takes precedence over a numerically higher value.
For rules received with the same order value, the FSv1 rules apply
(order by component type and then by value of the components).
</t>
</list>
</t>
<t>3) FSv2 rules are added starting with Rule 1 and FSv1 rules are added after FSv2 rules
<list>
<t>For example, BGP Peer A has FSv2 data base with 10 FSv2 rules (1-10). FSv1 user number
is configured to start at 301 so 10 FSv1 rules are added at 301-310.
</t>
</list>
</t>
<t>4) An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a BGP peer that does not support FSv1 or FSv2.
The capabilities sent by a BGP peer indicate whether the AFI/SAFI can be received (FSv1 NLRI or FSv2 NLRI).
</t>
<t>5) Associate a chain of actions to rules based on user-defined action number (1-n). (optional)
<list>
<t>If no actions are associated with a filter rule, the default is to drop traffic the filter rules match</t>
<t>An action chain of 1-n actions can be associated with a set of filter rules can
via Extended Communities or Wide Communities. Only Wide Communities can associate a user-defined
order for the actions. Extended Community actions occur after actions with a
user specified order (see section 5.2 for details).
</t>
</list>
</t>
</list>
</t>
<t>
Figure 2-2 provides a logical diagram of the FSv2 structure
<figure>
<artwork>
+--------------------------------+
| Rule Group |
+--------------------------------+
^ ^ ^
| |--------- |
| | ------
| | |
+--------^-------+ +-------^-----+ +---^-----+
| Rule1 | | Rule2 | ... | Rule-n |
+----------------+ +-------------+ +---------+
: : : :
:.................: : : :
: |.........: : :
+--V--+ +--V--+ : :
| name| |order| .........: :.....
+-----+ +-----+ : :
: :
+----------------V----+ +-----V----------------+
|Rule Match condition | | Rule Action |
+---------------------+ +----------------------+
: : : : : : : : |
+--V--+ : : : +--V---+ : : : V
| Rule| : : : |action| : : : +-----------+
| name| : : : |order | : : : |action name|
+-----+ : : : +------+ : : : +-----------+
: : : : : :.............
: : : : : :
.....: . :..... ..: :...... :
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------+ +--V-----+ +--V---+
| Match | | match | |match | | Action | | action | |action|
|Operator| |variable| |Value | |Operator| |Variable| | Value|
+--------+ +--------+ +------+ +--------+ +--------+ +------+
Figure 2-2: BGP FSv2 Data storage
</artwork>
</figure>
</t>
</section>
</section>
<section title="FSv2 Filters and Actions">
<t>
The BGP FSv2 uses an NRLI with the format for
AFIs for IPv4 (AFI = 1), IPv6 (AFI = 2), L2 (AFI = 6), L2VPN (AFI=25), and
SFC (AFI=31) with two following SAFIs to support transmission of the flow specification
which supports user ordering of traffic filters and actions for IP traffic and
IP VPN traffic.
</t>
<t>
This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined in
<xref target="RFC4760"></xref>. When advertising FSv2 NLRI, the length of the
Next-Hop Network Address MUST be set to 0. Upon reception,
the Network Address in the Next-Hop field MUST be ignored.
</t>
<t>Implementations wishing to exchange flow specification rules MUST use
BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code
(Code 1) as defined in <xref target="RFC4760"></xref>, and
indicate a capability for FSv1, FSv2 (Code TBD3), or both.
</t>
<t>The AFI/SAFI NLRI for BGP Flow Specification version 2 (FSv2) has the format:
<figure>
<artwork>
+-------------------------------+
|length (2 octets) |
+-------------------------------+
| Sub-TLVs (variable) |
| +===========================+ |
| | order (4 octets) | |
| +---------------------------+ |
| | identifier (4 octets) | |
| +---------------------------+ |
| | type (2 octets) | |
| +---------------------------+ |
| | length-Subtlv (2 octets) | |
| +---------------------------+ |
| | value (variable) | |
| +===========================+ |
+-------------------------------+
Figure 3-1: FSv2 format
</artwork>
</figure>
</t>
<t>
where:
<list style="symbols">
<t> length: length of field including all SubTLVs in octets.
<list>
<t> The combined lengths of any FSv2 NLRI in the
MP_REACH_NLRI or MP_UNREACH_NLRI. The BGP NLRI length
must be less than the packet size minus the other fields
(BGP header, BGP Path Attributes, and NLRI).
</t>
</list>
</t>
<t> order: flow-specification global rule order number (4 octets). </t>
<t>identifier: identifier for the rule (used for NM/Logging) (4 octets) </t>
<t> type: contains a type for FSv2 TLV format of the NRLI (2 octets) which can be:
<list>
<t>0 - reserved, </t>
<t>1 - IP Traffic Rules </t>
<t>2- L2 traffic rules</t>
<t>3- SFC Traffic rules </t>
<t>4- SFC VPN Traffic rules </t>
<t>5 - BGP/MPLS VPN IP Traffic Rules </t>
<t>6 - BGP/MPLS VPN L2 Traffic Rules </t>
</list>
</t>
<t> length-Subtlv: is the length of the value part of the Sub-TLV,
</t>
<t>value: value depends on the subTLV (see sections below).</t>
</list>
</t>
<section title="Filters">
<section title="IP header SubTLV (type=1)">
<t>
The format of the IP header TLV value field is shown in figure 3-2.
The IP header for the VPN case is specified in section 3.5.
</t>
<t>
<figure>
<artwork>
+-------------------------------+
| +--------------------------+ |
| | (subTLVs)+ | |
| +==========================+ |
+-------------------------------+
Figure 3-2 - IP Header TLV
</artwork>
</figure>
</t>
<t>Where: Each SubTLV has the format:
<figure>
<artwork>
+-------------------------------+
| SubTLV type (1 octet) |
+-------------------------------+
| length (1 octet) |
+ ------------------------------+
| value (variable) |
+-------------------------------+
Figure 3-3 – IP header SubTLV format
</artwork>
</figure>
</t>
<t>
Where:
<list>
<t>SubTLV type: component values are defined in
the “Flow Specification Component types” registry for IPv4 and IPv6 by
<xref target="RFC8955"></xref>,
<xref target="RFC8956"></xref>, and <xref target="I-D.ietf-idr-flowspec-srv6"></xref>
</t>
<t>length: length of SubTLV (varies depending on SubTLV type).
</t>
<t>value: dependent on the subTLV
<list>
<t> For descriptions of value portions for components 1-13 see
<xref target="RFC8955"></xref> and <xref target="RFC8956"></xref>.
For component 14 see <xref target="I-D.ietf-idr-flowspec-srv6"></xref>.
</t>
</list>
</t>
</list>
</t>
<t>Many of the components use the operators [numeric_op] and [bitmask_op]
defined in <xref target="RFC8955"></xref>
</t>
<t>The list of valid SubTLV types appears in Table 2.
</t>
<t>
<figure>
<artwork>
Table 2 IP SubTLV Types for IP Filters
SubTLV
-type Definition
====== ============
1 - IP Destination prefix
2 - IP Source prefix
3 – IPv4 Protocol / IPv6 Upper Layer Protocol
4 – Port
5 – Destination Port
6 – Source Port
7 – ICMPv4 type / ICMPv6 type
8 – ICMPv4 code / ICPv6 code
9 – TCP Flags
10 – Packet length
11 – DSCP (Differentiated Services Code Point)
12 – Fragment
13 – Flow Label
14 - TTL
15-63 unassigned (IP flow)
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
Table 3 Non-IP Types for IP Filters
SubTLV
-type Definition
====== ============
64 – Parts of SID
65 - MPLS Match 1: Label in Label stack
66 - MPLS Match 2: EXP bits in top Label
67-249 unassigned (reserved for now)
250- Filter Error handling
251-255 Reserved
</artwork>
</figure>
</t>
<t>
Ordering within the TLV in FSv2: The transmission of SubTLVs within a
flow specification rule MUST be sent ascending order by SubTLV type.
If the SubTLV types are the same, then the value fields are compared
using mechanisms defined in <xref target="RFC8955"></xref>
and <xref target="RFC8956"></xref> and MUST be in ascending order.
NLRIs having TLVs which do not follow the above ordering rules MUST be considered as
malformed by a BGP FSv2 propagator. This rule prevents any ambiguities that arise
from the multiple copies of the same NLRI from multiple BGP FSv2 propagators.
A BGP implementation SHOULD treat such malformed NLRIs as "Treat-as-withdraw"
<xref target="RFC7606"></xref>.
</t>
<t>See <xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>, and
<xref target="I-D.ietf-idr-flowspec-srv6"></xref>. for specific details.
</t>
<section title="IP Destination Prefix (type = 1)">
<t> IPv4 Name: IP Destination Prefix (reference: <xref target="RFC8955"></xref>) </t>
<t> IPv6 Name: IPv6 Destination Prefix (reference: <xref target="RFC8956"></xref>) </t>
<t></t>
<t>IPv4 length: Prefix length in bits
</t>
<t>IPv4 value: IPv4 Prefix (variable length)
</t>
<t>IPv6 length: length of value
</t>
<t>IPv6 value: [offset (1 octet)] [pattern (variable)] [padding(variable)]
</t>
<t>If IPv6 length = 0 and offset = 0, then component matches every address.
Otherwise, length must be offset "less than" length "less than" 129 or component is malformed.
</t>
</section>
<section title="IP Source Prefix (type = 2) ">
<t> IPv4 Name: IP Source Prefix (reference: <xref target="RFC8955"></xref>) </t>
<t> IPv6 Name: IPv6 Source Prefix (reference: <xref target="RFC8956"></xref>) </t>
<t></t>
<t>IPv4 length: Prefix length in bits </t>
<t>IPv4 value: Source IPv4 Prefix (variable length)</t>
<t>IPv6 length: length of value </t>
<t>IPv6 value: [offset (1 octet)] [pattern (variable)][padding(variable)]
</t>
<t></t>
<t>
If IPv6 length = 0 and offset = 0, then component matches every address. Otherwise, length must be offset < length < 129
or component is malformed.
</t>
</section>
<section title="IP Protocol (type = 3) ">
<t> IPv4 Name: IP Protocol IP Source Prefix (reference: <xref target="RFC8955"></xref>) </t>
<t> IPv6 Name: IPv6 Upper-Layer Protocol: (reference: <xref target="RFC8956"></xref>) </t>
<t></t>
<t>IPv4 length: variable </t>
<t>IPv4 value: [numeric_op, value]+</t>
<t></t>
<t>IPv6 length: variable </t>
<t>IPv6 value: [numeric_op, value}+ </t>
<t>where the value following each numeric_op is a single octet. </t>
</section>
<section title="Port (type = 4)">
<t> IPv4/IPv6 Name: Port (reference: <xref target="RFC8955"></xref>), <xref target="RFC8956"></xref>) </t>
<t>Filter defines: a set of port values to match either destination port or source port.
</t>
<t></t>
<t>IPv4 length: variable </t>
<t>IPv4 value: [numeric_op, value]+</t>
<t></t>
<t>IPv6 length: variable </t>
<t>IPv6 value: [numeric_op, value]+</t>
<t></t>
<t>where the value following each numeric_op is a single octet. </t>
<t>Note-1: (from FSV1) In the presence of the port component (destination or source port),
only a TCP (port 6) or UDP (port 17) packet can match the entire flow specification.
If the packet is fragmented and this is not the first fragment, then the system
may not be able to find the header. At this point, the FSv2 filter may fail to
detect the correct flow. Similarly, if other IP options or the encapsulating
security payload (ESP) is present, then the node may not be able to describe the transport header
and the FSv2 filter may fail to detect the flow.
</t>
<t>The restriction in note-1 comes from the inheritance of the FSv1 filter component for port.
If better resolution is desired, a new FSv2 filter should be defined.
</t>
<t>Note-2: FSv2 component only matches the first upper layer protocol value.
</t>
</section>
<section title="Destination Port (type = 5) ">
<t> IPv4/IPv6 Name: Destination Port (reference: <xref target="RFC8955"></xref>), <xref target="RFC8956"></xref>) </t>
<t>Filter defines: a list of match filters for destination port for TCP or UDP within a received packet
</t>
<t>Length: variable </t>
<t> Component Value format: [numeric_op, value]+
</t>
</section>
<section title="Source Port (type = 6) ">
<t> IPv4/IPv6 Name: Source Port (reference: <xref target="RFC8955"></xref>), <xref target="RFC8956"></xref>)
</t>
<t>Filter defines: a list of match filters for source port for TCP or UDP within a received packet
</t>
<t>IPv4/IPv6 length: variable </t>
<t>IPv4/Ipv6 value: [numeric_op, value]+
</t>
</section>
<section title="ICMP Type (type = 7) ">
<t> IPv4: ICMP Type (reference: <xref target="RFC8955"></xref>)
</t>
<t> Filter defines: Defines: a list of match criteria for ICMPv4 type
</t>
<t>IPv6: ICMPv6 Type (reference: <xref target="RFC8956"></xref>)
</t>
<t>Filter defines: a list of match criteria for ICMPv6 type.
</t>
<t> </t>
<t>IPv4/IPv6 length: variable</t>
<t>IPv4/IPv6 value: [numeric_op, value]+ </t>
</section>
<section title="ICMP Code (type = 8) ">
<t> IPv4: ICMP Type (reference: <xref target="RFC8955"></xref>) </t>
<t> Filter defines: a list of match criteria for ICMPv4 code.
</t>
<t>IPv6: ICMPv6 Type (reference: <xref target="RFC8956"></xref>) </t>
<t>Filter defines: a list of match criteria for ICMPv6 code. </t>
<t> </t>
<t>IPv4/IPv6 length: variable</t>
<t>IPv4/IPv6 value: [numeric_op, value]+ </t>
</section>
<section title="TCP Flags (type = 9) " >
<t> IPv4/IPv6: TCP Flags Code (reference: <xref target="RFC8955"></xref>)
</t>
<t>Filter defines: a list of match criteria for TCP Control bits
</t>
<t> </t>
<t>IPv4/IPv6 length: variable</t>
<t>IPv4/IPv6 value: [bitmask_op, value]+ </t>
<t></t>
<t>Note: a 2 octets bitmask match is always used for TCP-Flags </t>
</section>
<section title="Packet length (type = 10 (0x0A)) ">
<t> IPv4/IPv6: Packet Length (reference: <xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>)
</t>
<t> Filter defines: a list of match criteria for length of packet
(excluding L2 header but including IP header).
</t>
<t>IPv4/IPv6 length: variable</t>
<t>IPv4/IPv6 value: [numeric_op, value]+ </t>
<t></t>
<t>Note:<xref target="RFC8955"></xref> uses either 1 or 2 octet values.
</t>
</section>
<section title="DSCP (Differentiaed Services Code Point)(type = 11 (0x0B)) ">
<t> IPv4/IPv6: DSCP Code (reference: <xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>)
</t>
<t> Filter defines: a list of match criteria for DSCP code values to match the
6-bit DSCP field.
</t>
<t> </t>
<t>IPv4/IPv6 length: variable</t>
<t>IPv4/IPv6 value: [numeric_op, value]+ </t>
<t></t>
<t>Note: This component uses the Numeric Operator (numeric_op) described in
<xref target="RFC8955"></xref> in section 4.2.1.1.
Type 11 component values MUST be encoded as single
octet (numeric_op len=00).
</t>
<t>The six least significant bits contain the DSCP value. All other
bits SHOULD be treated as 0.
</t>
</section>
<section title="Fragment (type = 12 (0x0C)) ">
<t> IPv4/IPv6: Fragment (reference: <xref target="RFC8955"></xref>, <xref target="RFC8956"></xref>)
</t>
<t> Filter defines: a list of match criteria for specific IP fragments.
</t>
<t> </t>
<t>Length: variable</t>
<t>Component Value format: [bitmask_op, value]+</t>
<t>Bitmask values are:</t>
<t>
<figure>
<artwork>
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 |LF |FF |IsF| DF|
+---+---+---+---+---+---+---+---+
Figure 3-4
</artwork>
</figure>
</t>
<t> Where:
<list>
<t> DF (don’t fragment): match If IP header flags bit 1 (DF) is 1.
</t>
<t>IsF(is a fragment other than first: match if IP header fragment offset is not 0.
</t>
<t> FF (First Fragment): Match if <xref target="RFC0791"></xref> IP Header Fragment offset is zero and Flags Bit-2 (MF) is 1.
</t>
<t>LF (last Fragment): Match if [RFC7091] IP header Fragment is not 0 And Flags bit-2 (MF) is 0
</t>
<t>0: MUST be sent in NLRI encoding as 0, and MUST be ignored during reception.
</t>
</list>
</t>
</section>
<section title="Flow Label(type = 13 (0xOD)) ">
<t> IPv4/IPv6: Fragment (reference: <xref target="RFC8956"></xref>)
</t>
<t> Filter defines: a list of match criteria for 20-bit Flow Label in the IPv6 header field.
</t>
<t> </t>
<t>Length: variable</t>
<t>Component Value format: [numeric_op, value]+
</t>
</section>
<section title="TTL (type=14 (0x0E))">
<t>TTL: Defines matches for 8-bit TTL field in IP header
</t>
<t>Encoding: <[numeric_op, value]+>
</t>
<t>where: value is a 1 octet value for TTL.
</t>
<t>ordering: by full value of number_op concatenated with value </t>
<t>conflict: none</t>
<t>reference: draft-bergeon-flowspec-ttl-match-00.txt </t>
</section>
<section title="Parts of SID (type = 64 (0x40))">
<t> IPv6: Service Identifier Matches (reference: <xref target="I-D.ietf-idr-flowspec-srv6"></xref>
</t>
<t> Filter defines: a list of match bit match criteria for some combinations of the
LOC (location), FUNCT (function) and ARG (arguments) fields in the SID or or whole SID.
</t>
<t> </t>
<t>Length: variable</t>
<t>Component Value format: [type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+]
</t>
<t>where:
<list style="symbols">
<t>type (1 octet): This indicates the new component type (TBD1, which is to be assigned by IANA).
</t>
<t>LOC-Len (1 octet): This indicates the length in bits of LOC in SID.
</t>
<t>FUNCT-Len (1 octet): This indicates the length in bits of FUNCT in SID.
</t>
<t>ARG-Len (1 octet): This indicates the length in bits of ARG in SID.
</t>
<t>[op, value]+: This contains a list of {operator, value} pairs that are used to match some parts of SID.
</t>
</list>
</t>
<t>The total of three lengths (i.e., LOC length + FUNCT length + ARG
length) MUST NOT be greater than 128. If it is greater than 128, an
error occurs and it is treated as a withdrawal [RFC7606] and
[RFC4760].
</t>
<t>The operator (op) byte is encoded as:
<figure>
<artwork>
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | field type|lt |gt |eq |
+---+---+---+---+---+---+---+---+
Figure 3-5
</artwork>
</figure>
</t>
<t>where:
<list>
<t>where the behavior of each operator bit has clear similarity with that
of [RFC8955]'s Numeric Operator field.
</t>
<t>e (end-of-list bit): Set in the last {op, value} pair in the sequence.
</t>
<t>a - AND bit: If unset, the previous term is logically ORed with the
current one. If set, the operation is a logical AND. It should be
unset in the first operator byte of a sequence. The AND operator has
higher priority than OR for the purposes of evaluating logical
expressions.
</t>
<t>field type:
<list>
<t>000: SID's LOC
</t>
<t>001: SID's FUNCT
</t>
<t>010: SID's ARG
</t>
<t>011: SID's LOC:FUNCT (the concatenation of the LOC and FUNCTION fields)
</t>
<t>100: SID's FUNCT:ARG (the concatenation of the FUNCTION and ARG fields)
</t>
<t>101: SID's LOC:FUNCT:ARG (the concatenation of the FUNCTION and ARG fields)
</t>
</list>
</t>
<t>Note: For an unknown field type, Error Handling is to "treat as withdrawal" [RFC7606]
and [RFC4760].
</t>
<t>lt: less than comparison between data' and value'.
</t>
<t>gt: greater than comparison between data' and value'.
</t>
<t>eq: equality between data' and value'.
</t>
</list>
</t>
<t>The data' and value' used in lt, gt and eq are indicated by the field
type in an operator and the value field following the operator.
</t>
<t>The length of the value field depends on the field type and is
the length of the SID parts being matched (see Table 3, Figure 3-6)
in bytes, rounded up if that length is not a multiple of 8.
</t>
<t>
<figure>
<artwork>
Table 3 - SID Parts fields
+-----------------------+------------------------------+
| Field Type | Value |
+=======================+==============================+
| SID's LOC | value of LOC bits |
+-----------------------+------------------------------+
| SID's FUNCT | value of FUNCT bits |