-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-idr-sdwan-edge-discovery-13.xml
1598 lines (1548 loc) · 73.4 KB
/
draft-ietf-idr-sdwan-edge-discovery-13.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?Pub Inc?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-sdwan-edge-discovery-13"
ipr="trust200902">
<front>
<title abbrev="SDWAN Edge Discovery">BGP UPDATE for SD-WAN Edge Discovery</title>
<author fullname="Linda Dunbar" initials="L. " surname="Dunbar">
<organization>Futurewei</organization>
<address>
<postal>
<city>Dallas, TX</city>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
<organization>Microsoft Azure</organization>
<address>
<postal>
<street/>
<city>California</city>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Susan Hares" initials="S. " surname="Hares">
<organization>Hickory Hill Consulting</organization>
<address>
<postal>
<street></street>
<city> </city>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Robert Raszuk" initials="R. " surname="Raszuk">
<organization>Arrcus</organization>
<address>
<postal>
<street></street>
<code></code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Venkit Kasiviswanathan" initials="V" surname="Kasiviswanathan">
<organization>Arista</organization>
<address>
<postal>
<street/>
<city></city>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2024"/>
<abstract>
<t>The document describes the encoding of BGP UPDATE messages for the
SD-WAN edge node property discovery.</t>
<t>In the context of this document, BGP Route Reflector (RR) is the component of the
SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges
and in turns propagates the information to the intended peers
that are authorized to communicate via the SD-WAN overlay network.</t>
</abstract>
<note title="Requirements 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 <xref
target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all
capitals, as shown here.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>BGP [RFC4271] can be used as a control plane
for a SD-WAN network. SD-WAN network refers to a policy-driven network
over multiple heterogeneous underlay networks to get better
WAN bandwidth management, visibility, and control. </t>
<t>The document describes BGP UPDATE messages for an SD-WAN edge
node to advertise its properties to its RR which then propagates
that information to the authorized peers.
</t>
</section>
<section title="Conventions used in this document">
<t>The following acronyms and terms are used in this document: </t>
<list
style="hanging">
<t hangText="Cloud DC:">Off-Premises Data Centers that usually host applications and workload owned by different organizations or tenants.</t>
<t hangText="Color-EC:">Color Extended Community defined in [RFC9012].</t>
<t hangText="Controller:">Used interchangeably with SD-WAN controller to manage SD-WAN overlay path creation/deletion
and monitor the path conditions between sites.</t>
<t hangText="CPE:">Customer (Edge) Premises Equipment</t>
<t hangText="CPE-Based VPN:">Virtual Private Secure network formed among CPEs. This is to differentiate such VPNs from most commonly used PE-based VPNs discussed in [RFC4364].</t>
<t hangText="Encaps-EC:">Encapsulation Extended Community defined in [RFC9012].</t>
<t hangText="MP-NLRI:">Multi-Protocol Network Layer Reachability Information [MP_REACH_NLRI] Path Attribute defined in [RFC4760].</t>
<t hangText="RR:">Route Reflector</t>
<t hangText="SD-WAN:">An overlay connectivity service that optimizes transport of IP Packets over one or more Underlay Connectivity Services by recognizing applications (Application Flows) and determining forwarding behavior by applying Policies to them. [MEF-70.1]</t>
<t hangText="SD-WAN Endpoint:">can be the SD-WAN edge node address, a WAN port address (logical or physical) of a
SD-WAN edge node, or a client port address.</t>
<t hangText="SD-WAN Hybrid tunnel:">A single logical tunnel that combines several links of different
encapsulation iinto a single tunnel.</t>
<t hangText="RT-EC:"> Route Target Extended Community [RFC4360] </t>
<t hangText="TEA:"> Tunnel Encapsulation Path Attribute [RFC9012] </t>
<t hangText="VPN:">Virtual Private Network</t>
<t hangText="VRF:">VPN Routing and Forwarding instance</t>
<t hangText="WAN:">Wide Area Network</t>
</list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC8174] when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Framework of SD-WAN Edge Discovery">
<section title="The Objectives of SD-WAN Edge Discovery">
<t>
The objectives of SD-WAN edge discovery for an SD-WAN edge node
are to discover its authorized BGP peers and each peer's associated properities
in order to establish secure overlay tunnels [Net2Cloud]. The attributes to be propagated include: </t>
<list style="symbol">
<t>the SD-WAN (client) VPNs information, </t>
<t>the attached routes under the SD-WAN VPNs, and </t>
<t>the properties of the underlay networks over
which the client routes can be carried.</t>
</list>
<t>Some SD-WAN peers are connected by both trusted VPNs and untrusted public networks.
Some SD-WAN peers are connected only by untrusted public networks.
For the traffic over untrusted networks, IPsec Security Associations (IPsec SA)
must be established and maintained. For the trusted VPNs, IPsec Security
associations may not be set-up. If an edge node has network ports behind a NAT,
the NAT properties need to be discovered by the authorized SD-WAN peers.
</t>
<t>Like any VPN networks, the attached client routes belonging
to specific SD-WAN VPNs can only be exchanged with the SD-WAN
peer nodes authorized to communicate.</t>
</section>
<section title="Comparing with Pure IPsec VPN">
<t> A pure IPsec VPN has IPsec tunnels connecting all edge nodes over public networks.
Therefore, it requires stringent authentication and authorization (i.e., IKE Phase 1)
before other properties of IPsec SA can be exchanged. The IPsec Security Association (SA)
between two untrusted nodes typically requires the following configurations and message exchanges:
</t>
<t>
<list>
<t>
<list style="hanging">
<t hangText="IPsec IKEV2:">messages sent to authenticate with each other. </t>
<t hangText="Establish IPsec SA">: requires the following set-up
<list style="symbol">
<t>Local key configuration, </t>
<t>Setting the Remote Peer address, </t>
<t>Information from IKEv2 Proposal directly sent to peer (Encryption method, Integrity sha512, etc.), and</t>
<t>Transform set. </t>
</list>
</t>
<t hangText="Attached client prefixes discovery acchieved by:">
<list style="symbol">
<t>Running routing protocol within each IPsec SA. </t>
<t>If multiple IPsec SAs between two peer nodes are established to achieve load sharing,
each IPsec tunnel needs to run its own routing protocol to exchange client routes attached to the edges.</t>
</list>
</t>
<t hangText="Set-up Access List or Traffic Selector:">such as Permit Local-IP1, Remote-IP2, and other parameters.</t>
</list>
</t>
</list>
</t>
<t>In a BGP-controlled SD-WAN network over hybrid MPLS VPN and public internet underlay networks,
all edge nodes and RRs are already connected by private secure paths. The RRs have the policies
to manage the authentication of all peer nodes. More importantly, when an edge node needs to
establish multiple IPsec tunnels to many edge nodes, all the management information can
be multiplexed into the secure management tunnel between RR and the edge node operating as a BGP peer.
Therefore, the amount of authentication in a BGP-Controlled SD-WAN network can be significantly reduced.
</t>
<t>Client VPNs are configured via VRFs, just like the configuration of the existing MPLS VPN.
The IPsec equivalent traffic selectors for local and remote routes are achieved by
importing/exporting VPN Route Targets. The binding of client routes to IPsec SA is dictated by policies.
As a result, the IPsec configuration for a BGP controlled SD-WAN (with mixed MPLS VPN) can be simplified
in the following manner:</t>
<t>
<list style="symbol">
<t>The SD-WAN controller has the authority to authenticate edges and peers
so the Remote Peer association is controlled by the SD-WAN Controller (RR). </t>
<t>The IKEv2 proposals (including the IPsec Transform set)
can be sent directly to peers, or incorporated in a BGP UPDATE. </t>
<t>The BGP UPDATE announces the client route reachability through
the SDWAN hybrid tunnels. A SDWAN hybrid tunnnel combines several
other tunnels into a single logical tunnel. The SD-WAN Hybrid
tunnel implementations insure that all tunnels within are
either running over secure network links or secured by IPsec.
</t>
<t>Importing/exporting Route Targets under each client VPN (VRF) achieves the traffic selection
(or permission) among clients' routes attached to multiple edge nodes.</t>
</list>
</t>
<t>Note that with this method there is no need to run multiple routing protocols in each IPsec tunnel.
</t>
</section>
<section title="Client Routes and SDWAN UPDATE">
<t>There are two different sequences of BGP UPDATE messages are used for
SD-WAN Edge Discovery. The first associates Client routes BGP Updates with the SD-WAN Hybrid Tunnel.
The second passes information regarding the SD-WAN Underlay between
Egress routers and Ingress routers.
</t>
<section title="Client Routes">
<t>This section describes how client routes in BGP Updates are associated with the SD-WAN Hybrid Tunnel.
</t>
<t>
<list style="hanging">
<t hangText="Client routes BGP UPDATE:">
<list>
<t></t>
<t>This BGP UPDATE message contains the client routes (NLRI), Next Hop, and the attributes which
identify the Hybrid SD-WAN tunnel toward the Next Hop. The SD-WAN-Hybrid Tunnel BGP attributes
are either passed as either:
<list style="symbols">
<t>Encapsulation Extended Community [Encap-EC] which identifies the SD-WAN-hybrid tunnel with
a Tunnel Egress End Point as NextHop in BGP Update [per RFC9012], </t>
<t>Tunnel Encapsulation Attribute (TEA) which identifies the SD-WAN-Hybrid tunnel and
uses the Tunnel Egress Endpoint SubTLV to identify the egress endpoint (see [RFC9012] section 3.1) </t>
</list>
</t>
<t>Ordering: If both the TEA and the Extended Community for tunnel information exists, the
Extended Community is preferred (i.e. takes precedence.)
</t>
</list>
</t>
<t hangText="Sample Topology:">For a Hybrid SD-WAN Tunnel
<figure
anchor="Hybrid SD-WAN"
title="Hybrid SD-WAN">
<artwork><![CDATA[
Site 15.0.0.2
+---+
+--------------|RR |----------+
/ Untrusted +-+-+ \
/ \
/ \
+---------+ MPLS Path +-------+
11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x
| | | |
21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x
| | | |
| Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |
| 1.1.1.1 | |2.2.2.2|
+---------+ +-------+
]]></artwork>
</figure>
</t>
<t hangText="Example Client Routes:">
In figure 1, four overlay paths between C-PE1 and C-PE2 are established
for illustration purpose. More overlay paths are possible. One physical port on C-PE2 can
terminate multiple overlay paths from different ports on C-PE1.
<list style="hanging">
<t hangText="a)">MPLS-in-GRE path;</t>
<t hangText="b)">node-based IPsec tunnel [2.2.2.2 - 1.1.1.1].
As C-PE2 has two public internet facing WAN ports, either of those two WAN port IP addresses
can be the outer destination address of the IPsec encapsulated data packets; </t>
<t hangText="c)">port-based IPsec tunnel [192.0.0.1 - 192.10.0.10]; and</t>
<t hangText="d)">port-based IPsec tunnel [172.0.0.1 - 160.0.0.1]. </t>
</list>
</t>
<t hangText="C-PE2 advertises the attached client routes"> in one of two forms below:
<list>
<t>Client Route UPDATE - [RFC9012] "Barebones" (option 1)
<figure
anchor="Client-Routes-1"
title="Client Routes Update Message ">
<artwork><![CDATA[
NLRIs: AFI=IPv4 (1) and SAFI = VPN (128)
Prefix: 10.1.1.x; 20.1.1.x
NextHop: 2.2.2.2 (C-PE2)
Attributes:
Extended community RT: (RT-EC) for SD-WAN VPN 1
Encapsulation Extended Community (Encaps-EC)
tunnel-type=SD-WAN-Hybrid
]]></artwork>
</figure>
</t>
<t>Client Route UPDATE [RFC9012] Tunnel Encaps Attribute (TEA) (option 2)
<figure
anchor="Client-Routes-2"
title="Client Routes Update Message ">
<artwork><![CDATA[
NLRIs: AFI=IPv4 (1) and SAFI = VPN (128)
Prefix: 10.1.1.x; 20.1.1.x
NextHop: 2.2.2.2 (C-PE2)
Attributes:
Extended community RT: (RT-EC) for SD-WAN VPN 1
Tunnel Encapsulation Attribute (TEA)
Tunnel Egress Endpoint SubTLV: 2.2.2.2 (C-PE2)
]]></artwork>
</figure>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="SD-WAN Underlay UPDATE">
<t>Edges nodes use this BGP UPDATE to advertise the properties of directly
attached underlay networks and IPsec SA attributes associated with an SD-WAN-Hybrid tunnel.
The properties of underlay networks include encapsulation, NAT and underlay physical properties.
The IPsec SA attributes passed include keys, nonce, and encryption algorithms, and other IP SEC attributes.
</t>
<t>The security attributes are likely to change more rapidly than the physical
attributes of links within the Hybrid SD-Wan Tunnel. Typically the attributes of the
links are passed during initial set-up of Hybrid SD-WAN tunnels in the network.
</t>
<t> Given the topology in figure 1, C-PE2 can send the SD-WAN NLRI in a BGP Update messages
to advertise the properties of Internet facing ports 192.0.0.1 and 170.0.0.1,
and their associated IPsec SA related parameters.
</t>
<t> Example 1 below provides sample BGP Updates per port. This type of UPDATE packing
provides poor packing of UPDATES, but it may occur.
Example 2 provides a single BGP Update which passes the initial
information in one update. In the update, Color-EC is Color Extended Community
[RFC4360].
</t>
<section title="Example #1 SD-WAN Underlay Update Messages Used in Set-Up">
<t>Example #1 - BGP Updates per Port
<figure
anchor="SDWAN-RT-1"
title="SDWAN NLRI Update per Port">
<artwork><![CDATA[
# Update #1 for Port B2 on C-PE2
SD-WAN NLRI (AFI=1/SAFI=SD-WAN)
Port-id = Local port ID for WAN Port 192.0.0.1
SD-WAN Color = Match to Color-EC of Client routes
SD-WAN Node ID = 2.2.2.2 (C-PE2)
Tunnel Encaps Attribute (TEA)
Tunnel TLV: (type: Hybrid-SD-WAN)
Tunnel Egress Endpoint SubTLV: 2.2.2.2
Extended-Port Attribute SubTLV: Port B2 (192.0.0.1)
IPsec SA Identifier SubTLV: SA-1, SA-2
# Update #2 for Port B3 (IPsec) in Hybrid tunnel on PE2
SD-WAN NLRI (AFI=1/SAFI=SD-WAN)
Port-id = Local port ID for WAN Port 170.0.0.1
SD-WAN Color = Match to Color-EC of Client Routes
SD-WAN Node ID = 2.2.2.2 (C-PE2)
Tunnel Encaps Attribute (TEA)
Tunnel TLV: (type: SD-Wan-Hybrid)
Tunnel Egress Endpoint SubTLV (SubTLV=6) = 2.2.2.2
Extended Port Attribute SubTLV: Port B3 (170.0.0.1)
Simplified IPSec SD-WAN SubTLV: SA-3, SA-4
See section 7.1 for Extended Port Attribute SubTLV definition.
See section 8.1 for IPsec SA Identifier SubTLV.
See section 8.5 for Simplified IPsec SD-WAN SubTlv.
]]></artwork>
</figure>
</t>
</section>
<section title="Example #2 IPsec terminated at Node with Hybrid Tunnel">
<t>Example #2 - IP Sec Terminated at Node C-PE2
<figure
anchor="SDWAN-RT-2"
title="SDWAN NLRI Update 3 ports">
<artwork><![CDATA[
# Ports B1 (MPLS), B2 (IPsec), B3 (IPsec)
# Update for C-PE2 (IPSec)
SD-WAN NLRI (AFI=1 / SAFI = SD-WAN)
SD-WAN Color = Match to Color-EC of Client routes
Port ID = 0
SD-WAN Node ID = 2.2.2.2
Tunnel Encaps Attribute (TEA)
Tunnel TLV (type: SD-Wan-Hybrid)
Egress Endpoint = 2.2.2.2
IPsec-SA-ID: SA-1, SA-2, SA-3, SA-4
]]></artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Edge Node Discovery ">
<t>The basic scheme of SD-WAN edge node discovery using BGP consists of the following:
<list style="symbol">
<t>Secure connection to a SD-WAN controller (BGP RR in this context):
<list>
<t>For an SD-WAN edge with both MPLS and IPsec paths, the edge node should already have a secure connection to
its controller (RR in this context). For an SD-WAN edge that is only accessible via Internet,
the SD-WAN edge upon power-up establishes a secure tunnel (such as TLS or SSL)
with the SD-WAN central controller whose address is preconfigured on the edge node.
The central controller informs the edge node of its local RR. The edge node then establishes a
transport layer secure session with the RR (such as TLS or SSL).</t>
</list>
</t>
<t>The BGP Peer Edge node will advertise the properties of its Hybrid SD-WAN Tunnel
to its designated RR via the secure connection.</t>
<t>The RR propagates the received information to the authorized BGP peers. </t>
<t>The authorized BGP peers can establish the secure data channels via Hybrid SD-WAN tunnel
and exchange more information among each other. </t>
</list>
</t>
<t>For an SD-WAN deployment with multiple RRs, it is assumed that there are secure connections among those RRs.
How secure connections are established among those RRs is out of the scope of this document.
The existing BGP UPDATE propagation mechanisms control the edge properties propagation among the RRs.</t>
<t>For some environments where the communication to RR is highly secured, [RFC9016]
IKE-less can be deployed to simplify IPsec SA establishment among edge nodes.</t>
</section>
</section>
<section title="Constrained propagation of BGP UPDATE ">
<section title="SD-WAN Segmentation, Virtual Topology and Client VPN">
<t>In SD-WAN deployment, SD-WAN Segmentation is a frequently used term which refers to partitioning a
network into multiple subnetworks, just like MPLS VPNs. SD-WAN Segmentation is achieved by creating
SD-WAN virtual topologies and SD-WAN VPNs. An SD-WAN virtual topology consists of a set of edge nodes
and the tunnels (a.k.a. underlay paths) interconnecting those edge nodes. These tunnels forming the
underlay paths can be IPsec tunnels, or MPLS VPN tunnels, or other tunnels.
</t>
<t>An SD-WAN VPN is configured in the same way as the VRFs of an MPLS VPN. One SD-WAN client VPN
can be mapped to multiple SD-WAN virtual topologies. SD-WAN Controller governs the policies of mapping
a client VPN to SD-WAN virtual topologies.</t>
<t>Each SD-WAN edge node may need to support multiple VPNs. Route Target is used to differentiate the
SD-WAN VPNs. For example, in the picture below, the Payment-Flow on C-PE2 is only mapped to the virtual
topology of C-PEs to/from Payment Gateway, whereas other flows can be mapped to a multipoint-to-multipoint
virtual topology.</t>
<t>
<figure
anchor="SD-WAN Virtual Topology and VPN"
title="SD-WAN Virtual Topology and VPN">
<artwork><![CDATA[
+---+
+--------------|RR |----------+
/ Untrusted +-+-+ \
/ \
/ \
+---------+ MPLS Path +-------+
11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x
| | | |
21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x
| | | |
| Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |11.2.2.x
| 1.1.1.1 | / |2.2.2.2|
+---------+ / +-------+
\ /
\ /PaymentFlow
\ /
\ +----+----+
+---------------| payment |
| Gateway |
+---------+
]]></artwork>
</figure>
</t>
</section>
<section title="Constrained Propagation of Edge Capability">
<t> BGP Route Reflectors [RFC4456] may be configured to constrain the
distribution of BGP informtion to specific BGP clients.
</t>
<t>
<figure
anchor="Constraint propagation of Edge Property"
title="Constraint propagation of Edge Property">
<artwork><![CDATA[
NLRI={SD-WAN#1, SD-WAN#2} NLRI={SD-WAN#1, SD-WAN#3}
-----> +---+ <-----------
+--------------------|RR1|------------------+
| Outbound Filter +---+ Outbound Filter |
| Permit SD-WAN#1,#2 Permit SD-WAN#1,#3|
| <------- ---------> |
| |
+-----+---+ MPLS Path +-----+-+
11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x
| | | |
21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x
| | | |
| Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |
| 1.1.1.1 | |2.2.2.2|
+---------+ +-------+
SD-WAN VPN #1 SD-WAN VPN #1
SD-WAN VPN #2 SD-WAN VPN #3
]]></artwork>
</figure>
</t>
<t>The RR is configured to speak to the BGP clients (CE-PE1 and CE-PE2)
over secure virtual links (IPsec), and send only certain routes.
The configuration on the RR and the BGP Peers sending SD-WAN routes forms
a "walled garden" for the SD-WAN information. </t>
<t>It is out of the scope of this document on how RR is configured with the policies to
filter out unauthorized nodes for specific SD-WAN VPNs.</t>
</section>
</section>
<section title="Client Route UPDATE Procedures">
<t>The Tunnel Encapsulation Attribute for the SD-WAN Hybrid Tunnel Type
may be associated with BGP UPDATE messages with NLRI with AFI/SAFI
IPv4 Unicast (1/1), IPv4 with MPLS labels (1/4), IPVPN-IPv4 Label Unicast (1/128),
IPv6 Unicast (2/1), IPv6 with MPLS labels (2/4), VPN-IPv6 Label Unicast (2/128),
and EVPN (25/70).
</t>
<t>
When associated with any NLRI in this set, these routes
are described as "Client Routes" in this document.
Based on [RFC9012], there are two forms a Tunnel Encapsulation
Attribute (TEA) can take: "Barebones" using the Encapsulation
Extended Community (Encaps-EC) and a normal Tunnel Encapsulation form.
</t>
<section title="Tunnel Form 1: Encapsulation Extended Community (Encaps-EC) ">
<t>
The SD-WAN Client Route UPDATE message uses the Encapsulation
Extended Community (Encap-EC) to identify
the Hybrid SD-WAN tunnel and the Tunnel Egress Endpoint.
Per [RFC9012], the Encapsulation Extended
Community uses the NextHop Field in the BGP UPDATE as
the Tunnel Egress EndPoint. The validation for
the Tunnel Egress Endpoint uses the validation
in section 6, 8, and 13 applied to the NextHop.
</t>
<t>
A Color Extended Community (Color-EC) or local policy applied to the
client route directs the traffic for the client route
to across appropriate interface within the Hybrid SD-WAN Tunnel
to the Tunnel Egress Endpoint.
</t>
</section>
<section title="Tunnel Form 2: Tunnel Encapsulation Path Attribute (TEA) ">
<t> The Client route with the Tunnel Encapsulation Path
Attribute (TEA) with the Hybrid SD-WAN route TLV
must have the Tunnel Egress Endpoint
(SubTLV=6) and any of the SubTLVs found in [RFC9012].
The validation for the Tunnel Egress Endpoint uses the validation
in section 6, 8, and 13 from [RFC9012].
</t>
</section>
<section title=" Multiple tunnels attached to One Route">
<t>A single SD-WAN client route may be attached to multiple SD-WAN Hybrid tunnels.
An Update with an SD-WAN client route may express these tunnels as
an Encap-EC or a TEA. Each of these tunnel descriptions is treated as a
unique Hybrid SD-WAN tunnel with a unique Egress Endpoint.
Local Policy on the BGP Peer determines which tunnel the client data traffic will use.
</t>
</section>
<section title="SD-WAN VPN ID in Client Route Update">
<t>An SD-WAN VPN ID is same as a client VPN in a BGP controlled SD-WAN network.
The Route Target Extended Community should be included in a Client Route UPDATE message to
differentiate the client routes from routes belonging to other VPNs.
Route Target value is taken as the VPN ID (for 1/1 and 2/1).
For 1/128 and 2/128, the RD from the NLRI identifies the VPN ID.
For EVPN, picking up the VPN-ID from EVPN SAFI.
</t>
</section>
<section title="SD-WAN VPN ID in Data Plane">
<t>SD-WAN edge node which can be reached by either
an MPLS path or an IPsec path within the hybrid SD-WAN tunnel.
If client packets are sent via a secure MPLS network
within the Hybrid SD-WAN tunnel, then the data packets
will have MPLS headers with the MPLS Labels based on the scheme specified
by [RFC8277]. It is assumed the secure MPLS network assures
the security outer MPLS Label header.
</t>
<t>If the packets are sent via a link with IPsec outer encryption
across a public network, the payload is still encrypted with
GRE or VXLAN encryption. For GRE Encapsulation within an IPsec tunnel,
the GRE key field can be used to carry the SD-WAN VPN ID.
For network virtual overlay (VxLAN, GENEVE, etc.) encapsulation
within the IPsec tunnel, the Virtual Network Identifier (VNI) field is
used to carry the SD-WAN VPN ID.
</t>
</section>
</section>
<section title="SD-WAN Underlay UPDATE">
<t>The hybrid SD-WAN underlay tunnel UPDATE is to advertise the detailed properties associated with the
public facing WAN ports and IPsec tunnels. The Edge BGP Peer will advertise the SD-WAN properties to
its designated RR via the secure connection. The BGP Update message will contain
the SD-WAN Underlay NLRI and a Tunnel Encapsulation Attribute (TEA) with SubTLVs for Extended Port attribute
(see section 7) or IP Sec information (see section 8). The IPsec information subTLVs include:
IPsec-SA-ID, IPsec SA Nonce, IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.
IP</t>
<section title="NLRI for SD-WAN Underlay Tunnel Update">
<t>A new NLRI SAFI (SD-WAN SAFI=74) is introduced within the MP_REACH_NLRI Path
Attribute of [RFC4760] for advertising the detailed properties of the SD-WAN tunnels
terminated at the edge node:</t>
<t>
<figure anchor="SD-WAN NLRI" title="SD-WAN NLRI">
<artwork><![CDATA[
+------------------+
| Route Type | 2 octet
+------------------+
| Length | 2 Octet
+------------------+
| Type Specific |
~ Value (Variable) ~
| |
+------------------+
]]></artwork>
</figure>
</t>
<t>Where</t>
<t>
<list style="hanging">
<t hangText="Route (NLRI) Type:"> 2 octet value to define the encoding of the rest of the SD-WAN the NLRI.
</t>
<t hangText="Length:">2 octets of length expressed in bits as defined in [RFC4760].</t>
</list>
</t>
<t></t>
<t>This document defines the following SD-WAN Route type:</t>
<t>
<list style="hanging">
<t hangText="NLRI Route-Type = 1:"> For advertising the detailed properties of the SD-WAN
tunnels terminated at the edge, where the transport network port can be uniquely identified by a
tuple of three values (Port-Local-ID, SD-WAN-Color, SD-WAN-Node-ID).
The SD-WAN NLRI Route-Type =1 has the following encoding:
<figure anchor="SD-WAN NLRI Route Type 1" title="SD-WAN NLRI Route Type 1">
<artwork><![CDATA[
+------------------+
| Route Type = 1 | 2 octet
+------------------+
| Length | 2 Octet
+------------------+
| Port-Local-ID | 4 octets
+------------------+
| SD-WAN-Color | 4 octets
+------------------+
| SD-WAN-Node-ID | 4 or 16 octets
+------------------+
]]></artwork>
</figure>
</t>
<t hangText="Port-local-ID:"> SD-WAN edge node Port identifier, which is locally significant.
If the SD-WAN NLRI applies to multiple WAN ports, this field is zero.</t>
<t hangText="SD-WAN-Color:"> represents a group of tunnels, which correlate
with the Color-Extended-community included in the client routes UPDATE.
When a client route can be reached by multiple SD-WAN edges co-located at one site,
the SD-WAN-Color can represent a group of tunnels terminated at those SD-WAN edges co-located at the site.
If an SD-WAN-Color represents all the tunnels at a site, then the SD-WAN-Color effectively represents the site.</t>
<t hangText="SD-WAN Node ID:"> The node's IPv4 or IPv6 address.</t>
</list>
</t>
<t> Route Type values outside of 1 are out of scope for this document.
</t>
</section>
<section title="SD-WAN-Hybrid Tunnel Encoding">
<t> A new BGP Tunnel-Type SD-WAN-Hybrid (code point 25) indicates hybrid underlay tunnels.</t>
<t>
<figure
anchor="SD-WAN Hybrid Value Field"
title="SD-WAN Hybrid Value Field">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type=25(SD-WAN-Hybrid )| Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>The valid SubTLVs for the Hybrid Tunnel type include subTLVs
specified in [RFC9012] and the following SubTLVs specified in
this document:
<list style="symbols">
<t> Extended Port Attributes SubTLV
</t>
<t>IPsec SA-ID SubTLV
</t>
<t> IPSec SA Rekey SubTLV
</t>
<t> IPsec Public Key SubTLV
</t>
<t>IPsec SA Proposal SubTLV
</t>
<t>Simplified IPsec SA SubTLV
</t>
</list>
</t>
<t>The Extended Port Attributes are described in section 7, and
the IPsec related SubTLVs are described in section 8.
</t>
</section>
</section>
<section title="Extended Port Attribute Sub-TLV">
<t> The SD-WAN Underlay NLRI is sent with a Tunnel Encapsulation Attribute with the
Extended Port Attribute Sub-TLV advertises the properties associated with a public Internet-facing WAN
port that might be behind NAT. An SD-WAN edge node can query a STUN Server (Session Traversal of UDP
through Network address translation [RFC8489]) to get the NAT properties, including the public IP address and the
Public Port number, to pass to its peers.</t>
<t>The location of a NAT device can be:
<list style="symbol">
<t>Only the initiator is behind a NAT device. Multiple initiators can be behind separate NAT devices.
Initiators can also connect to the responder through multiple NAT devices.</t>
<t>Only the responder is behind a NAT device.</t>
<t>Both the initiator and the responder are behind a NAT device.</t>
</list>
</t>
<t>The initiator's address and/or responder's address can be dynamically assigned
by an ISP or when their connection crosses a dynamic NAT device that allocates
addresses from a dynamic address pool.</t>
<t>As one SD-WAN edge can connect to multiple peers, the pair-wise NAT exchange as IPsec's
IKE[RFC7296] is not efficient. In the BGP Controlled SD-WAN, NAT properties for a WAN port are
encoded in the Extended Port Attribute sub-TLV, which the following format:</t>
<t>
<figure
anchor="Extended Port Attribute Sub-TLV"
title="Extended Port Attribute Sub-TLV">
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=65(extPort| ExtPort Length| Reserved |I|O|R|R|R|R|R|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT Type | Encap-Type |Trans networkID| RD ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
32-bits for IPv4, 128-bits for Ipv6
~~~~~~~~~~~~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public IP |
32-bits for IPv4, 128-bits for Ipv6
~~~~~~~~~~~~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended SubSub-TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>Where:
<list style="symbol">
<t>Extended Port Attribute Type (=65): indicating it is the Extended Port Attribute SubTLV</t>
<t>ExtPort Length: the length of the subTLV in octets (variable). </t>
<t>Flags:
<list style="symbol">
<t>I bit (CPE port address or Inner address scheme):
<list>
<t>If set to 0, indicate the inner (private) address is IPv4.</t>
<t>If set to 1, indicates the inner address is IPv6. </t>
</list>
</t>
<t>O bit (Outer address scheme):
<list>
<t>If set to 0, indicate the inner (private) address is IPv4.</t>
<t>If set to 1, indicates the inner address is IPv6. </t>
</list>
</t>
<t>R bits: reserved for future use. Must be set to 0, and ignored upon reception.</t>
</list>
</t>
<t>NAT Type: the NAT type can be one of the following values:
<list style="symbols">
<t>1: without NAT ; </t>
<t>2: 1-to-1 static NAT; </t>
<t>3: Full Cone; </t>
<t>4: Restricted Cone; </t>
<t>5: Port Restricted Cone; </t>
<t>6: Symmetric; or </t>
<t>7: Unknown (i.e. no response from the STUN server).</t>
</list>
NAT type values outside of 1-7 are invalid for this SubTLV.
</t>
<t>Encap-Type: the supported encapsulation types for the port.
<list>
<t>Encap-Type=1: GRE;</t>
<t>Encap-Type=2: VxLAN;</t>
</list>
Notes:
<list>
<t>The Encap-Type inside the Extended Port Attribute Sub-TLV is different from the RFC9012's
BGP-Tunnel-Encapsulation type. The port can indicate the specific encapsulations, such as:
<list style="symbols">
<t>If the IPsec-SA-ID subTLV or the IPsec SA detailed subTLVs (Nonce/publicKey/Proposal)
are included in the SD-WAN-Hybrid tunnel, the Encap-Type indicates the
encapsulation type within the IPsec payload.</t>
<t>If the IPsec SA subTLVs are not included in the SD-WAN-Hybrid Tunnel,
the Encap-Type indicates the encapsulation of the payload without IPsec encryption.</t>
</list>
</t>
<t>Encapsulation types outside of GRE and VxLAN are outside of the scope of this specification.
</t>
</list>
</t>
<t>Transport Network ID: Central Controller assigns a global unique ID to each transport network.
Any value in this octet is valid </t>
<t>RD ID: Routing Domain ID, need to be globally unique. Any value in this octet is valid.
<list>
<t>Some SD-WAN deployment might have multiple levels, zones, or regions that are represented as logical
domains. Policies can govern if tunnels can be established across domains. For example, a hub node
can establish tunnels with different logical domains but the spoke nodes cannot establish
tunnels with nodes in different domains.</t>
</list>
</t>
<t>Local IP: The local (or private) IP address of the WAN port.</t>
<t>Local Port: used by Remote SD-WAN edge node for establishing IPsec to this specific port.</t>
<t>Public IP: The IP address after the NAT. If NAT is not used, this field is set to all-zeros</t>
<t>Public Port: The Port after the NAT. If NAT is not used, this field is set to all-zeros.</t>
<t>Extended SubSub-TLV: for carrying additional information about the underlay networks.</t>
</list>
</t>
<section title="Extended SubSub-TLV">
<t>One Extended SubSub-TLVs is specified in this document: Underlay Network Transport SubSub-TLV
</t>
<section title="Underlay Network Transport SubSub-TLV">
<t>The Underlay Network Transport SubSub-TLV is an optional Sub-TLV to
carry the WAN port connection types and bandwidth, such as LTE, DSL, Ethernet, etc.</t>
<t>The format of this Sub-TLV is as follows:
<figure
anchor="Underlay Network SubSub-TLV"
title="Underlay Network SubSub-TLV">
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnderlayType | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Connection Type| Port Type | Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>Where:
<list style="hanging">
<t hangText="Underlay Network Properties:"> sub Type=66 </t>
<t hangText="Length:"> always 6 bytes</t>
<t hangText="Reserved:"> 2 octet of reserved bits. It SHOULD be set to zero on
transmission and MUST be ignored on receipt.</t>
<t hangText="Connection Type:"> are listed below as:
<list style="symbol">
<t>1 = Wired</t>
<t>2 = WIFI</t>
<t>3 = LTE </t>
<t>4 = 5G </t>
<t>Any value outside of 1-4 is outside the scope of this specification. </t>
</list>
</t>
<t hangText="Port Type:">Port type define as follows:
<list style="symbol">
<t>1 = Ethernet </t>
<t>2 = Fiber Cable </t>
<t>3 = Coax Cable </t>
<t>4 = Cellular </t>
<t>Any value outside of values 1-4 are outside the scope of this specification.</t>
</list>
</t>
<t hangText="Port Speed:">The port seed is defined as 2 octet value. The values are defined as Gigabit speed.
For example, a value of 1 would mean 1 gigabit. The port speed of "0" is not valid.</t>
</list>
The connection types of equipment and port types will continue to grow with technology change.
Future specifications may specify additional connection types or port types.
</t>
</section>
</section>
</section>
<section title="IPsec SA Property Sub-TLVs">
<t> This section describes the SubTLVs that pass data regarding IPsec parameters for
the Hybrid SD-WAN tunnel. During set-up of the Hybrid SD-WAN tunnels, the IPsec
parameters need to be securely passed to set-up secure association. For hybrid SD-WAN tunnels,
the IPsec security association for IPsec links may change to different
security associations over time.
</t>
<t>The IPSec subTLVs supported by the Hybrid Tunnel type are: IPSec-SA-ID, IPsec SA Nounce,
IPsec Public Key, IPsec Proposal, and Simplified IPSec SA. The IPSec-SA-ID SubTLV provides
a way to indicate the IPsec SA Identifiers (section 8.1) for pre-configured security association.
The other four SubTLVs provide different ways to pass details regarding IPsec security associations.
The IPsec SA Nounce passes Nounce and rekey counters for a Secure Association identified by IPsec SA Identifier
(see section 8.2). The IPSec Public Key SubTLV passes IPsec Public Key data with a time duration
(see section 8.3). The IPsec Proposal SubTLV provides Transform attributes and Transform IDs (see section 8.4).
The Simplified IP SEC SA passes the information that identifies configuration for 2 keys (see section 8.5).
</t>
<t>For a quick rotation between security associations, the SDWAN NLRI (port-id, color, node)
can quickly distribute a switch to a set of new security association using the BGP Update message.
In this case, the BGP UPDATE message would like figure 10</t>
<t>
<figure
anchor="SD-WAN-NLRI-IPsec1"
title="SD-WAN NLRI IPsec rotation in attack">
<artwork><![CDATA[
SDWAN NLRI
Route-type: 1
length: 12
port-id - 0.0.0.0
SD-WAN-Color - 0.0.0.1
node-id - 2.2.2.2
TEA:
Tunnel TLV: (type: SD-WAN Hybrid)
Tunnel Egress Endpoint SubTLV: 2.2.2.2
IPsec-SA-ID SubTLV: 20, 30
]]></artwork>
</figure>
</t>
<section title="IPsec-SA-ID Sub-TLV">
<t>IPsec-SA-ID Sub-TLV within the Hybrid Underlay Tunnel UPDATE indicates one or more
pre-established IPsec SAs by using their identifiers, instead of listing all the
detailed attributes of the IPsec SAs.</t>
<t>Using an IPsec-SA-ID Sub-TLV not only greatly reduces the size of BGP UPDATE messages, but also allows the
pairwise IPsec rekeying process to be performed independently.</t>
<t>The following is the structure of the IPsec-SA-ID sub-TLV
<figure
anchor="IPsec-SA-ID Sub-TLV"
title="IPsec-SA-ID Sub-TLV">
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=64 (IPsec-SA-ID subTLV) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec SA Identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec SA Identifier #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec SA Identifier #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>where:
<list>
<t> length is the length of the subTLV in octets (must be on 4 octet boundary)
</t>
<t> The length is followed by a sequence of IPsec SA Identifiers of length 4 octets.
<list style="symbols">
<t>IPSec SA Identifier #1 - is a 4 octet identifier for a IP Security association.
</t>
<t>IPSec SA Identifier #2 - is a 4 octet identifier for a IP Security association.
</t>
<t>IPSec SA Identifier #n - is a 4 octet identifier for a IP Security association.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="IPsec SA Rekey Counter Sub-TLV">
<t> The IPsec SA Rekey Counter Sub-TLv provides the rekey counter
for a security association (identified by IPsec SA Identifier).
</t>
<t>The format of this Sub-TLV is as follows:</t>
<figure
anchor="IPsec SA Rekey Counter Sub-TLV"
title="IPsec SA Rekey Counter Sub-TLV">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Length | Nonce Length |I| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rekey |
| Counter |
+---------------------------------------------------------------+
| IPsec SA Identifier |
+---------------------------------------------------------------+
| |
~ Nonce Data ~