idnits 2.17.1 draft-dunbar-idr-sdwan-edge-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 22 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 18, 2020) is 1254 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDWAN-BGP-USAGE' is mentioned on line 168, but not defined == Missing Reference: 'Tunnel-encap' is mentioned on line 181, but not defined == Missing Reference: 'SDN-IPsec' is mentioned on line 870, but not defined == Missing Reference: 'ID' is mentioned on line 457, but not defined == Missing Reference: 'Section 7' is mentioned on line 482, but not defined == Missing Reference: 'RFC4760' is mentioned on line 689, but not defined == Missing Reference: 'Controller-IKE' is mentioned on line 915, but not defined == Missing Reference: 'SECURE-VPN' is mentioned on line 1000, but not defined == Unused Reference: 'RFC2119' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: 'LISP-GEOLOC' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'SDN-IPSEC' is defined on line 1194, but no explicit reference was found in the text == Unused Reference: 'VPN-over-Internet' is defined on line 1203, but no explicit reference was found in the text == Unused Reference: 'DMVPN' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'DSVPN' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 1215, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-Problem' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'Net2Cloud-gap' is defined on line 1223, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-geo-09 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 == Outdated reference: A later version (-06) exists of draft-sajassi-bess-secure-evpn-02 == Outdated reference: A later version (-01) exists of draft-rosen-bess-secure-l3vpn-00 == Outdated reference: A later version (-07) exists of draft-dm-net2cloud-problem-statement-02 == Outdated reference: A later version (-04) exists of draft-dm-net2cloud-gap-analysis-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-10 Summary: 1 error (**), 0 flaws (~~), 29 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft Futurewei 3 Intended status: Standard S. Hares 4 Expires: May 18, 2021 Hickory Hill Consulting 5 R. Raszuk 6 Bloomberg LP 7 K. Majumdar 8 CommScope 9 November 18, 2020 11 BGP UPDATE for SDWAN Edge Discovery 12 draft-dunbar-idr-sdwan-edge-discovery-01 14 Abstract 16 The document describes encoding of BGP UPDATE messages for the SDWAN 17 edge node discovery. 19 In the context of this document, BGP Route Reflectors (RR) is the 20 component of the SDWAN Controller that receives the BGP UPDATE from 21 SDWAN edges and in turns propagates the information to the intended 22 peers that are authorized to communicate via the SDWAN overlay 23 network. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on Dec 18, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Conventions used in this document..............................3 66 3. Framework of SDWAN Edge Discovery..............................4 67 3.1. The Objectives of SDWAN Edge Discovery....................4 68 3.2. Basic Schemes.............................................5 69 3.3. Edge Node Discovery.......................................7 70 4. BGP UPDATE to Support SDWAN Segmentation.......................8 71 4.1. Constrained Propagation of Edge Capability................9 72 4.2. SDWAN Segmentation for Control Plane.....................10 73 4.3. SDWAN Segment Identifier in Data Plane...................11 74 5. Hybrid Underlay...............................................11 75 5.1. SDWAN-Hybrid Tunnel Encoding.............................11 76 5.2. Encoding Example.........................................14 77 5.2.1. Multiple IPsec SAs Sharing One Tunnel End Point.....14 78 5.2.2. Multiple IPsec SAs with different Tunnel End Points.15 79 6. Hybrid Underlay Detailed Attributes...........................16 80 6.1. SDWAN NLRI for Underlay Network Properties...............16 81 6.2. Extended Port Sub-TLV....................................18 82 6.3. ISP of the Underlay network Sub-TLV......................20 83 7. IPsec Security Association Property Sub-TLVs..................22 84 7.1. Controller Facilitated IPsec Tunnels for SDWAN Networks..22 85 7.2. IPsec SA Nonce Sub-TLV...................................24 86 7.3. IPsec Public Key Sub-TLV.................................25 87 7.4. IPsec SA Proposal Sub-TLV................................26 88 7.5. Simplified IPsec Security Association sub-TLV............26 89 7.6. IPsec SA Encoding Examples...............................27 90 8. Error & Mismatch Handling.....................................28 91 9. Manageability Considerations..................................29 92 10. Security Considerations......................................30 93 11. IANA Considerations..........................................30 94 12. References...................................................30 95 12.1. Normative References....................................30 96 12.2. Informative References..................................30 97 13. Acknowledgments..............................................32 99 1. Introduction 101 [SDWAN-BGP-USAGE] illustrates how BGP is used as control plane for a 102 SDWAN network. SDWAN network is an overlay network with some special 103 properties. 105 The document describes a BGP UPDATE for SDWAN edge nodes to announce 106 its properties to its RR which then propagates to the authorized 107 peers. 109 2. Conventions used in this document 111 Cloud DC: Off-Premise Data Centers that usually host applications 112 and workload owned by different organizations or 113 tenants. 115 Controller: Used interchangeably with SDWAN controller to manage 116 SDWAN overlay path creation/deletion and monitor the 117 path conditions between sites. 119 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 120 This is to differentiate from most commonly used PE- 121 based VPNs a la RFC 4364. 123 MP-NLRI: The MP_REACH_NLRI Path Attribute defined in RFC4760. 125 SDWAN End-point: can be the SDWAN edge node address, a WAN port 126 address (logical or physical) of a SDWAN edge node, or a 127 client port address. 129 OnPrem: On Premises data centers and branch offices 131 SDWAN: Software Defined Wide Area Network. In this document, 132 "SDWAN" refers to the solutions of policy-driven 133 transporting IP packets over multiple different underlay 134 networks to get better WAN bandwidth management, 135 visibility.and control. 137 SDWAN Instance: Same as SDWAN Segment 139 SDWAN Segmentation: Segmentation is the process of dividing the 140 network into logical sub-networks. One SDWAN Segment is 141 very much like a VPN except that SDWAN segment is over 142 hybrid of underlay networks. 144 3. Framework of SDWAN Edge Discovery 146 3.1. The Objectives of SDWAN Edge Discovery 148 The objectives of SDWAN edge discovery is for a SDWAN edge node to 149 discover its authorized peers to which its attached clients traffic 150 need to communicate. The attributes to be propagated includes the 151 SDWAN segmentations supported, the attached routes under specific 152 SDWAN segmentations, and the properties of the underlay networks 153 over which the client routes can be carried. 155 Some SDWAN peers are connected by both trusted VPNs and untrusted 156 public networks. Some SDWAN peers are connected only by untrusted 157 public networks. For the portion over untrusted networks, IPsec 158 Security Associations (IPsec SA) have to be established and 159 maintained. If an edge node has network ports behind the NAT, the 160 NAT properties needs to be discovered by authorized SDWAN peers. 162 Just like any VPN networks, the attached client's routes belonging 163 to specific SDWAN segmentations can only be exchanged to the SDWAN 164 peer nodes that are authorized to communicate. 166 3.2. Basic Schemes 168 As described in [SDWAN-BGP-USAGE], two separate BGP UPDATE messages 169 are used for SDWAN Edge Discovery: 171 - UPDATE U1 for the attached client routes, 172 This UPDATEs is for a SDWAN node to advertise the attached 173 client routes to remote peers. This UPDATE will continue using 174 the existing BGP AFI/SAFI for IP or VPN. Detailed underlay 175 tunnel specification can be recursively resolved by using the 176 Recursive Next Hop Resolution as specified by the section 8 of 177 [Tunnel-Encap]. 179 A new Tunnel Type (SDWAN-Hybrid) needs to be added, to be used 180 by Encapsulation Extended Community or the Tunnel-Encap Path 181 Attribute [Tunnel-encap] to indicate mixed underlay networks. 183 - UPDATE U2, advertised by the Next hop address of the UPDATE U1 184 to propagate the properties tunnels terminated at the edge 185 node. 186 This UPDATE is for an edge node to advertise the properties of 187 directly attached underlay networks, including the underlay 188 network ISP information, NAT information, pre-configured IPsec 189 SA identifiers. Also can include the detailed IPsec SA 190 attributes, such as keys, nonce, encryption algorithms, etc. 192 This UPDATE U2 is for peers to discover remote node's underlay 193 network properties. 195 In the following figure: there are four types underlay paths between 196 C-PE1 and C-PE2: 198 a) MPLS-in-GRE path; 200 b) node-based IPsec tunnel [2.2.2.2<->1.1.1.1]. 202 c) port-based IPsec tunnel [192.0.0.1 <-> 192.10.0.10]; and 204 d) port-based IPsec tunnel [172.0.0.1 <-> 160.0.0.1]; 205 +---+ 206 +--------------|RR |----------+ 207 / Untrusted +-+-+ \ 208 / \ 209 / \ 210 +---------+ MPLS Path +-------+ 211 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 212 | | | | 213 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 214 | | | | 215 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 216 | 1.1.1.1 | |2.2.2.2| 217 +---------+ +-------+ 219 Figure 1: Hybrid SDWAN 221 C-PE2 uses UPDATE U1 to advertise the attached client routes: 223 UDPATE U1: 225 Extended community: RT for SDWAN Segmentation 1 226 NLRI: AFI=? & SAFI = 1/1 227 Prefix: 10.1.1.x; 20.1.1.x 228 NextHop: 2.2.2.2 (C-PE2) 229 Encapsulation Extended Community: tunnel-type=SDWAN-hybrid 230 Color Extended Community: RED 232 The UPDATE U1 is recursively resolved to the UPDATE U2 which 233 specifies the detailed hybrid WAN underlay Tunnels terminated at the 234 C-PE2: 236 UPDATE U2: 238 NLRI: SAFI = SDWAN 239 (With Color RED encoded in the NLRI Site-Property field) 240 Prefix: 2.2.2.2 241 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 242 IPSec SA for 192.0.0.1 243 Tunnel-End-Point Sub-TLV [Section 3.1 of Tunnel-encap] 244 IPsec SA sub-TLV [See the Section 5] 246 Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] 247 IPSec SA for 170.0.0.1 248 Tunnel-End-Point Sub-TLV /*the address*/ 249 IPsec SA sub-TLV 251 Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid] 252 Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap] 254 Note: [Tunnel-Encap] Section 11 specifies that each Tunnel Encap 255 Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two 256 separate Tunnel Encap Attributes are needed to indicate that the 257 client routes can be carried by either one. 259 3.3. Edge Node Discovery 261 The basic scheme of SDWAN Edge node discovery using BGP consists of: 263 - Upon powering up, a SDWAN edge node establish a secure tunnel 264 (such as TLS, SSL) with the SDWAN central controller whose 265 address is preconfigured on the edge node. The central 266 controller will inform the edge node of its local RR. The edge 267 node will establish a transport layer secure session with the 268 RR (such as TLS, SSL). 270 - The Edge node will advertise its own properties to its 271 designated RR via the secure transport layer tunnel. This is 272 different from traditional BGP, where each node sends its 273 properties (BGP UPDATE) to its neighbors, which in turn 274 propagate to all the nodes in the network. 276 - The RR propagates the received information to the authorized 277 peers. 279 - The authorized peers can establish the secure data channels 280 (IPsec) and exchange more information among each other. 281 For a SDWAN deployment with multiple RRs, it is assumed that there 282 are secure connections among those RRs. How secure connections being 283 established among those RRs is the out of the scope of the current 284 draft. The existing BGP UPDATE propagation mechanisms control the 285 edge properties propagation among the RRs. 287 For some special environment where the communication to RR are 288 highly secured, [SDN-IPsec] IKE-less can be deployed to simplify 289 IPsec SA establishment among edge nodes. 291 4. BGP UPDATE to Support SDWAN Segmentation 293 One SDWAN network can be divided to multiple segmentations. Each 294 SDWAN edge node may need to support multiple SDWAN segments. One 295 client's traffic may need to be mapped to different SDWAN 296 segmentations based on client's policy. Therefore, we need encoding 297 to differentiate SDWAN segments. For example, in the picture below, 298 the "Payment-Flow" (payment applications) can only be propagated to 299 "Payment-GW". Other flows can be propagated to all other nodes. This 300 is very similar to VPNs. But need to differentiate from traditional 301 MPLS VPNs because a SDWAN edge may also support traditional MPLS 302 VPNs. 303 [Note: SDWAN Segment ID is configured the same way as VRF, or EVI as 304 in EVPN. For node with both MPLS and IPsec ports, the label for MPLS 305 can be used for SDWAN Segment ID] 307 +---+ 308 +--------------|RR |----------+ 309 / Untrusted +-+-+ \ 310 / \ 311 / \ 312 +---------+ MPLS Path +-------+ 313 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 314 | | | | 315 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 316 | | | | 317 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr |11.2.2.x 318 | 1.1.1.1 | / |2.2.2.2| 319 +---------+ / +-------+ 320 / 321 /PaymentFlow 322 / 323 +----+----+ 324 | payment | 325 | Gateway | 326 +---------+ 328 Figure 2: SDWAN Segmentation 330 4.1. Constrained Propagation of Edge Capability 332 BGP has built-in mechanism to dynamically achieve the constrained 333 distribution of edge information. RFC4684 describes the BGP RT 334 constrained distribution. In a nutshell, a SDWAN edge sends RT 335 Constraint (RTC) NLRI to the RR for the RR to install an outbound 336 route filter, as shown in the figure below: 338 RT Constraint RT constraint 339 NLRI={SDWAN#1, SDWAN#2} NLRI={SDWAN#1, SDWAN#3} 340 -----> +---+ <----------- 341 +--------------------|RR1|------------------+ 342 | Outbound Filter +---+ Outbound Filter | 343 | Permit SDWAN#1,#2 Permit SDWAN#1,#3| 344 | Deny all Deny all | 345 | <------- ---------> | 346 | | 347 +-----+---+ MPLS Path +-----+-+ 348 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 349 | | | | 350 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 351 | | | | 352 | Addr A3(160.0.0.1) --------(170.0.0.1)B3 Addr | 353 | 1.1.1.1 | |2.2.2.2| 354 +---------+ +-------+ 355 SDWAN Instance #1 SDWAN Instance #1 356 SDWAN Instance #2 SDWAN Instance #3 357 Figure 3: Constraint propagation of Edge Property 359 However, as SDWAN overlay network span across untrusted networks, 360 RR can't trust the RT Constraint (RTC) NLRI BGP UPDATE from any 361 nodes. Polices must be configured on RR to filter out unauthorized 362 nodes to be registered as interested in certain SDWAN segments. RR 363 can only process the RTC NLRI from authorized peers for a SDWAN 364 segment. 366 It is out of the scope of this document on how RR is configured 367 with the policies to filter out unauthorized nodes for specific 368 SDWAN segments. 370 When the RR receives BGP UPDATE from an edge node, it propagates 371 the received UPDATE message to the nodes that are in the Outbound 372 Route filter for the specific SDWAN segment. 374 4.2. SDWAN Segmentation for Control Plane 376 SDWAN Instances is represented by the SDWAN Target ID in the BGP 377 Extended Community. 379 Same as Route Target for VPN, a different Type is used to 380 differentiate SDWAN segments from MPLS VPN instances. This is 381 especially useful when a CPE supports both MPLS VPN and SDWAN 382 Segmentation (instances). 384 Encoding: 386 RFC4360: Extended Community for SDWAN Route Target 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type high | Type low(*) | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 0 1 2 3 4 5 6 7 395 +-+-+-+-+-+-+-+-+ 396 |I|T| 6-bit val | 397 +-+-+-+-+-+-+-+-+ 399 The high-order octet of the Type Field 400 T bit =0 (transitive) when SDWAN edge sends to its RR which then 401 propagates to remote peers based on outbound filters. 403 RFC4760 states that Route Target community is transitive 404 For SDWAN, an edge receiving the SDWAN Update shouldn't forward it 405 to other nodes. 406 T bit =1 (non-transitive) when RR propagates the UPDATE to SDWAN 407 EDGE 409 [IANA Consideration: 411 Following the encoding scheme specified by RFC7153, need IANA to 412 assign the following values for the "Type High" Octet: 413 - Transitive (when edge announce the advertisement to its RR): 414 Ox0A, which is the number after 0x08 for Flow Spec Redirect. 415 - Non Transitive (when RR send to remote edges): Ox4A 417 Request a new value of the low- order octet of the Type field for 418 this community (different from the VPN Route Target 0x02)? 419 ] 421 4.3. SDWAN Segment Identifier in Data Plane 423 From data plane perspective, packets from different SDWAN network 424 instances (or segmentations) need to have their corresponding SDWAN 425 instance identifier encoded in the header. 427 For a SDWAN edge node which can be reached by both MPLS and IPsec 428 path, the client packets reached by MPLS network will be encoded 429 with the MPLS Labels based on the scheme specified by RFC8277. 431 For GRE Encapsulation within IPsec tunnel, the GRE key field can be 432 used to carry the SDWAN Instance ID. For NVO (VxLAN, GENEVE, etc.) 433 encapsulation within the IPsec tunnel, Virtual Network Identifier 434 (VNI) field is used to carry the SDWAN Instance ID. 436 [Note: the SDWAN Instance ID is same as EVI in EVPN, or VNI if VxLAN 437 is used]. 439 5. Hybrid Underlay 441 5.1. SDWAN-Hybrid Tunnel Encoding 443 A new Tunnel-Type=SDWAN-Hybrid (code point to be assigned by IANA)is 444 introduced to indicate hybrid underlay networks. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Tunnel-Type(=SDWAN-Hybrid ) | Length (2 Octets) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Value | 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 SDWAN Hybrid Underlay network Sub-TLV Value Field 456 Since IPsec SA has a lot of attributes, such as public keys, nonce, 457 encryption algorithms etc., the IPsec Tunnel Identifier [ID] can be 458 used in the SDWAN-Hybrid Value field instead of listing all IPsec SA 459 attributes. Using IPsec Tunnel ID can greatly reduce the size of BGP 460 UPDATE messages. Another added benefit of using IPsec Tunnel ID is 461 that the IPsec SA attributes, or rekeying process can be advertised 462 independently. 464 There are two Sub-TLVs to represent the IPsec IDs under the SDWAN- 465 Hybrid tunnel type: IPsec-SA-ID and IPsec-SA-Group. 467 Editor's note: The IPSEC-SA-Group was designed to provide better 468 scaling for multiple IPsec SA terminated at one endpoint. One end 469 point can have multiple IPsec SAs, one SA can encrypt client data to 470 CPE1 and another one for CPE2. 472 IPsec-SA-ID Sub-TLV 474 0 1 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IPsec SA Identifier | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 The IPsec SA identifier (2 Octet) is for cross reference the IPsec 481 SA attributes being pre-configured or advertised by another UPDATE 482 [Section 7]. 484 If the client traffic needs to be encapsulated in a specific type 485 within the IPsec ESP Tunnel, such as GRE or VxLAN, etc., the 486 corresponding Tunnel-Encap Sub-TLV needs to be appended right after 487 the IPsec-SA-ID Sub-TLV. 489 Editor Note: 4 octets can be considered as well for IPsec-SA-ID. 491 IPsec-SA-Group Sub-TLV: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | InnerEncapType | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | IPsec SA Identifier #1 | IPsec SA Identifier #2 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 ~ |IPsec SA Identifier #n | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 IPsec-SA-Group Sub-TLV 504 IPsec-SA-Group Sub-TLV is for the scenario that multiple IPsec SAs 505 have the same inner encapsulation. Multiple IPsec SA IDs are 506 included in the IPsec-ID-Group Sub-TLV. If different inner 507 encapsulation is desired within IPsec tunnels, then multiple IPsec- 508 SA-Group Sub-TLVs can be included within one Tunnel Encap Path 509 Attribute. 511 InnerEncapType (2 octet) indicates the encapsulation type for the 512 payload within the IPsec ESP Tunnel. The Inner Encap Type value will 513 take the value specified by the IANA Consideration Section (12.5) of 514 [Tunnel-Encap]: 516 - types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN- 517 GPE) in the "BGP Tunnel Encapsulation Tunnel Types" registry. 518 - types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel 519 Encapsulation Tunnel Types" registry. 521 For each of the Tunnel Types specified, the detailed encapsulation 522 value field as specified by Section 3.2 of [Tunnel-Encap] is 523 appended right after the IPsec Sub-TLV. 525 The Tunnel Ending Point Sub-TLV specified by the Section 3.1 of 526 [Tunnel-Encap] has to be attached to identify the IPsec Tunnel 527 terminating address. 528 There can be multiple IPsec tunnels terminating at one WAN port or 529 at one node, e.g. one tunnel for going to destination "A", another 530 one for going to destination "B". Use SDWAN for retail industry as 531 an example, it is necessary for all shops at any location to only 532 exchange Payment System traffic with the Payment Gateway, while 533 other traffic can be exchanged with any nodes. 534 Therefore, there could be multiple IPsec Sub-TLVs bound with one 535 Tunnel Ending Point Sub-TLV. 537 However, it is quite common in SDWAN deployment that all IPsec 538 attributes from one node or one port are the same for all 539 destinations. In that case, IPsec SA ID is set to 0 and the 540 terminating address can be used to cross reference the IPsec SA 541 attributes which are advertised by the Underlay Network Property 542 advertisement UPDATE. 544 5.2. Encoding Example 546 5.2.1. Multiple IPsec SAs Sharing One Tunnel End Point 548 The encoding example is for the following scenario: 550 - there are three IPsec SAs terminating at the same WAN Port 551 address (or the same node address) 552 - Two of the IPsec SAs use GRE (value =2) as Inner Encapsulation 553 within the IPsec Tunnel 554 - One of the IPsec SA uses VxLAN (value = 8) as the Inner 555 Encapsulation within its IPsec Tunnel. 557 Here is the encoding for the scenario: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Tunnel-Type =SDWAN-Hybrid | Length = | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Tunnel-end-Point Sub-TLV | 565 ~ ~ 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 |IPsec-SA-group:InnerEncapType=2| Length = 4 | 568 +-------------------------------+-------------------------------+ 569 | IPsec SA Identifier = 1 | IPsec SA Identifier = 2 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | GRE-KEY (4 Octets) | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |IPsec-SA-ID: =3 | Reserved | 574 +-------------------------------+-------------------------------+ 575 ~ VxLAN Sub-TLV ~ 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 The Length of the Tunnel-Type = SDDWAN-Hybrid is the sum of the 579 following: 580 - Tunnel-end-point sub-TLV total length 581 - the IPsec-SA-Group Sub-TLV length + 4 (the two octets for 582 InnerEncapType + the two octets for the Length field) 583 - GRE-Key Length (4) 584 - The IPsec-SA-ID Sub-TLV length: 4 585 - The VxLAN sub-TLV total length 587 5.2.2. Multiple IPsec SAs with different Tunnel End Points 589 If IPsec SAs are terminating at different addresses, then multiple Tunnel 590 Encap Attributes have to be included. 592 The encoding example for the Figure 1: 594 - there is one IPsec SA terminating at the WAN Port address 595 192.0.0.1; and another IPsec SA terminating at WAN Port 596 170.0.0.1; 597 - Both IPsec SAs use GRE (value =2) as Inner Encapsulation within 598 the IPsec Tunnel 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Tunnel-Type =SDWAN-Hybrid | Length = | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Tunnel-end-Point Sub-TLV | 606 ~ for 192.0.0.1 ~ 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | IPsec SA Identifier = 1 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 ~ GRE Sub-TLV ~ 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Tunnel-Type =SDWAN-Hybrid | Length = | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Tunnel-end-Point Sub-TLV | 615 ~ for 170.0.0.1 ~ 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | IPsec SA Identifier = 1 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 ~ GRE sub-TLV ~ 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 6. Hybrid Underlay Detailed Attributes 624 6.1. SDWAN NLRI for Underlay Network Properties 626 For the MPLS VPN, the underlay network is controlled by the VPN 627 service provider, therefore, there is no need for nodes to advertise 628 any underlay properties to remote peers. 630 For the untrusted underlay network to which a SDWAN edge is 631 connected, many attributes need to be advertised to remote nodes, 632 such as: 634 - ISP information of the underlay network, 635 - NAT property 636 - the geolocation of the SDWAN edge 637 - IPsec SA attributes, such as public keys, nonce, supported 638 encryption algorithms, etc. 639 - the IPsec tunnel termination address 641 A new SDWAN NLRI is specified within the MP_REACH_NLRI Path 642 Attribute of RFC4760, with SAFI=SDWAN (code = 74): 644 +------------------+ 645 | NLRI Length | 1 octet 646 +------------------+ 647 | Site-Type | 1 Octet 648 +------------------+ 649 | Port-Local-ID | 4 octets 650 +------------------+ 651 | SDWAN-Color | 4 octets 652 +------------------+ 653 | SDWAN-Node-ID | 4 or 16 octets 654 +------------------+ 656 where: 658 - NLRI Length: 1 octet of length expressed in bits as defined in 659 [RFC4760]. 660 - Site Type: 1 octet value. The SDWAN Site Type defines the 661 different types of Site IDs to be used in the deployment. The 662 draft defines the following types: 663 Site-Type = 1: For simple deployment, such as all edge nodes 664 under one SDWAN management system, a simple identifier is 665 enough for the SDWAN management to map the site to its 666 precise geolocation. 667 Site-Type = 2: to indicate that the value in the site-ID is 668 locally significant, therefore, need a Geo-Loc Sub-TLV to 669 fully describe the accurate location of the node. This is for 670 large SDWAN heterogeneous deployment where Site IDs has to be 671 described by proper Geo-location of the Edge Nodes [LISP- 672 GEOLoc]. 673 - Port local ID: SDWAN edge node Port identifier, which can be 674 locally significant. The detailed properties about the network 675 connected to the port are further encoded in the Tunnel Path 676 Attribute. If the SDWAN NLRI applies to multiple ports, this 677 field is NULL. 678 - SDWAN-Color: is used to correlate with the Color-Extended- 679 community included in the client routes UPDATE. It can also 680 represent some common properties shared by a set of SDWAN edge 681 nodes, such as the property of a specific geographic location 682 shared by a group of SDWAN edge nodes. 683 - SDWAN Edge Node ID: a routable address (IPv4 or IPv6) within the 684 WAN to reach this node or port. 686 [Editor's note on using SDWAN SAFI for the underlay network 687 property advertisement: 688 SDWAN SAFI [IANA assigned =74] is used instead of IP SAFI in 689 the MP-NLRI [RFC4760] Path Attribute to advertise the 690 underlay network properties to emphasize that the address in 691 the NLRI is NOT client addresses. 692 If the same IP SAFI used, receiver needs to add extra logic 693 to differentiate regular BGP MP-NLRI client routes 694 advertisement from the SDWAN underlay network properties 695 advertisement. The benefit of using the same IP SAFI is that 696 the UPDATE can traverse existing routers without being 697 dropped. Since the SDWAN underlay network UPDATE is only 698 between SDWAN edge and its corresponding RR, there won't be 699 any intermediated routers. Therefore, this benefit becomes 700 not applicable. 701 ] 703 6.2. Extended Port Sub-TLV 705 When a SDWAN edge node is connected to an underlay network via a 706 port behind NAT devices, traditional IPsec uses IKE for NAT 707 negotiation. The location of a NAT device can be such that: 708 - Only the initiator is behind a NAT device. Multiple initiators 709 can be behind separate NAT devices. Initiators can also connect 710 to the responder through multiple NAT devices. 711 - Only the responder is behind a NAT device. 712 - Both the initiator and the responder are behind a NAT device. 714 The initiator's address and/or responder's address can be 715 dynamically assigned by an ISP or when their connection crosses a 716 dynamic NAT device that allocates addresses from a dynamic address 717 pool. 719 Because one SDWAN edge can connect to multiple peers via one 720 underlay network, the pair-wise NAT exchange as IPsec's IKE is not 721 efficient. In BGP Controlled SDWAN, NAT information of a WAN port is 722 advertised to its RR in the BGP UPDATE message. It is encoded as an 723 Extended sub-TLV that describes the NAT property if the port is 724 behind a NAT device. 726 A SDWAN edge node can inquire STUN (Session Traversal of UDP Through 727 Network Address Translation RFC 3489) Server to get the NAT 728 property, the public IP address and the Public Port number to pass 729 to peers. 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | NAT Type | Encap-Type |Trans networkID| RD ID | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Local IP Address | 738 32-bits for IPv4, 128-bits for Ipv6 739 ~~~~~~~~~~~~ 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Local Port | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Public IP | 744 32-bits for IPv4, 128-bits for Ipv6 745 ~~~~~~~~~~~~ 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Public Port | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | ISP-Sub-TLV | 750 ~ ~ 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Where: 755 o Port Ext Type: indicate it is the Port Ext SubTLV. 756 o PortExt subTLV Length: the length of the subTLV. 757 o Flags: 758 - I bit (CPE port address or Inner address scheme) 759 If set to 0, indicate the inner (private) address is IPv4. 760 If set to 1, it indicates the inner address is IPv6. 762 - O bit (Outer address scheme): 763 If set to 0, indicate the public (outer) address is IPv4. 764 If set to 1, it indicates the public (outer) address is 765 IPv6. 767 - R bits: reserved for future use. Must be set to 0 now. 769 o NAT Type.without NAT; 1:1 static NAT; Full Cone; Restricted 770 Cone; Port Restricted Cone; Symmetric; or Unknown (i.e. no 771 response from the STUN server). 772 o Encap Type.the supported encapsulation types for the port 773 facing public network, such as IPsec+GRE, IPsec+VxLAN, IPsec 774 without GRE, GRE (when packets don't need encryption) 775 o Transport Network ID.Central Controller assign a global unique 776 ID to each transport network. 777 o RD ID.Routing Domain ID.need to be global unique. 778 o Local IP.The local (or private) IP address of the port. 779 o Local Port.used by Remote SDWAN edge node for establishing 780 IPsec to this specific port. 781 o Public IP.The IP address after the NAT. If NAT is not used, 782 this field is set to NULL. 783 o Public Port.The Port after the NAT. If NAT is not used, this 784 field is set to NULL. 786 6.3. ISP of the Underlay network Sub-TLV 788 The purpose of the Underlay network Sub-TLV is to carry the ISP WAN 789 port properties with SDWAN SAFI NLRI. It would be treated as 790 optional Sub-TLV. The BGP originator decides whether to include this 791 Sub-TLV along with the SDWAN NLRI. If this Sub-TLV is present, it 792 would be processed by the BGP receiver and to determine what local 793 policies to apply for the remote end point of the Underlay tunnel. 795 The format of this Sub-TLV is as follows: 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Type | Length | Flag | Reserved | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 |Connection Type| Port Type | Port Speed | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Where: 806 Type: To be assigned by IANA 808 Length: 6 bytes. 810 Flag: a 1 octet value. 812 Reserved: 1 octet of reserved bits. It SHOULD be set to zero on 813 transmission and MUST be ignored on receipt. 815 Connection Type: There are two different types of WAN 816 Connectivity. They are listed below as: 818 Wired - 1 819 WIFI - 2 820 LTE - 3 821 5G - 4 823 Port Type: There are different types of ports. They are listed 824 Below as: 826 Ethernet - 1 827 Fiber Cable - 2 828 Coax Cable - 3 829 Cellular - 4 831 Port Speed: The port seed is defined as 2 octet value. The values 832 are defined as Gigabit speed. 834 7. IPsec Security Association Property Sub-TLVs 836 7.1. Controller Facilitated IPsec Tunnels for SDWAN Networks 838 IPsec is a common technique used to encrypt traffic traversing 839 untrusted networks. IPSec operation between two peer nodes need to 840 perform Internet Key Exchange (IKEv2), which can be broken down into 841 the following steps: 843 - IKE_SA_INIT exchanges: This pair of messages negotiate 844 cryptographic algorithms, exchange nonces, and do a Diffie- 845 Hellman exchange. 847 - IKE_AUTH: this pair of messages authenticate the previous 848 messages, exchange identities and certificates, and establish 849 the first Child SA. Based on the authentication used: Pre- 850 Shared Key, RSA certificates or EAP the number of messages 851 exchanged in IKE_AUTH can grow. 853 - CREATE_CHILD_SA - This is simply used to create additional 854 CHILD-SAs as needed 856 - INFORMATIONAL- During an IKEv2 SA lifetime, peers may desire to 857 exchange some control messages related to errors or have 858 notifications of certain events. This function is accomplished 859 by INFORMATIONAL exchange. 861 In SDWAN environment, each SDWAN edge node might need to establish 862 IPsec tunnels to multiple peers, and there can be multiple IPsec 863 tunnels for different client traffic between any two peers. In 864 addition, SDWAN edge nodes can be far apart. Upon powering up, a 865 SDWAN edge might not know their authorized communication peers and 866 might not have the policies configured for aligning traffic with 867 their specific IPsec Tunnels. Therefore, the IPsec operation in 868 SDWAN environment are usually facilitated by its SDWAN Controller. 870 [SDN-IPsec] describes two different mechanisms to achieve controller 871 facilitated IPsec configuration: IKE case vs. IKE-less case. Under 872 the IKE case, the Controller is in charge of provisioning the 873 required information to IKE, the Security Policy Database (SPD) and 874 the Security Association Database (PAD). The SDWAN peers exchange 875 the Internet Key Exchange (IKE) protocol and manage SPD and SAD. 876 Under the IKE-less case, the Controller will provide the required 877 parameters to create valid entries in the SPD and the SAD into the 878 edge nodes. Therefore, the edge node will only need to 879 implementation IPsec encryption while automated key management 880 functionality is moved to the Controller. 882 For BGP controlled SDWAN networks, since there is already a secure 883 management tunnel established between RR and the edge nodes, all the 884 negotiations exchanged in IKEv2 can be carried by BGP UPDATE 885 messages to/from the Route Reflector (RR). RR will propagate the 886 information to the intended destinations. More importantly, when an 887 edge node needs to establish multiple IPsec tunnels to many 888 different SDWAN edge nodes, all the management information can be 889 multiplexed into the secure management tunnel between RR and the 890 edge node. Therefore, there is reduced amount of work on 891 authentication in processing in BGP Controlled SDWAN networks. 893 Editor's Note: 895 RFC7296 specifies the IPsec SA attributes exchange among two 896 peers to establish peer-wise IPsec SA. [Controller-IKE] 897 specifies the structure for a controller to facilitate the 898 exchange of the RFC7296 specified IPsec SA attributes among 899 many nodes. 901 [CONTROLLER-IKE] specifies the Device Information Message 902 (DIM) for the edge node to advertise to its controller, which 903 includes DH public number, nonce, peer identity, an indication 904 whether this is the initial distributed policy, and rekey 905 counter. The originating edge node distributes the DH public 906 value along with the other values in the DIM (using IPsec 907 Tunnel TLV in Tunnel Encapsulation Attribute) to other remote 908 C-PEs via the RR. Each receiving C-PE uses this DH public 909 number and the corresponding nonce in creation of IPsec SA 910 pair to the originating C-PE - i.e., an outbound SA and an 911 inbound SA. The detail procedures are described in section 5.2 912 of [CONTROLLER-IKE]. 914 [SECURE-VPN] proposes the BGP UPDATE Sub-TLV structure to 915 carry the information specified by [Controller-IKE] to be 916 propagated among peers via BGP. 918 To expedite the standardization process, this draft aligns 919 with the IPsec Sub-TLVs described in the Section 6.1, 6.2 and 920 6.3 of [SECURE-EVPN], with some optimization. 922 For scalability reason, this draft advertises the IPSec SA 923 related attributes at a different pace than client routes 924 UPDATEs. Client Routes UPDATE only references the identifier 925 for the prior established IPsec SAs. 927 The optimized IPsec SA attributes are represented by a set of Sub- 928 TLVs: 930 - IPsec SA Nonce Sub-TLV 931 - IPsec SA Public Key Sub- TLV 932 - IPsec SA Proposal Sub-TLV: to indicate the number of 933 Transform Sub-TLVs 934 o Transforms Substructure Sub-TLV 936 For BGP controlled SDWAN network, very often an edge node doesn't 937 know its peer identity. Then the peer identity field can be null. 939 7.2. IPsec SA Nonce Sub-TLV 941 The Nonce Sub-TLV is based on the Base DIM sub-TLV as described the 942 Section 6.1 of [SECURE-EVPN]. IPsec SA ID is added to the sub-TLV, 943 which is to be referenced by the client route NLRI Tunnel Encap Path 944 Attribute for the IPsec SA. The following fields are removed 945 because: 947 - the Originator ID is carried by the NLRI, 948 - the Tenant ID is represented by the Route Target Extended 949 Community, and 950 - the Subnet ID are carried by the BGP route UPDATE. 952 The format of this Sub-TLV is as follows: 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | ID Length | Nonce Length |I| Flags | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Rekey | 960 | Counter | 961 +---------------------------------------------------------------+ 962 | IPsec SA ID | Reserved | 963 +---------------------------------------------------------------+ 964 | | 965 ~ Nonce Data ~ 966 | | 967 +---------------------------------------------------------------+ 969 IPsec SA ID - The 2 bytes IPSec SA ID could 0 or non-zero values. It 970 is cross referenced by client route's IPSec Tunnel Encap IPSec-SA-ID 971 or IPSec-SA-Group Sub-TLV in Section 5. When there are multiple 972 IPsec SAs terminated at one address, such as WAN port address or the 973 node address, they are differentiated by the different IPsec SA IDs. 975 7.3. IPsec Public Key Sub-TLV 977 The IPsec Public Key Sub-TLV is derived from the Key Exchange Sub- 978 TLV described in [SECURE-EVPN] with an addition of Duration filed to 979 define the IPSec SA life span. The edge nodes would pick the 980 shortest duration value between the SDWAN SAFI pairs. 982 The format of this Sub-TLV is as follows: 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Diffie-Hellman Group Num | Reserved | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | | 990 ~ Key Exchange Data ~ 991 | | 992 +---------------------------------------------------------------+ 993 | Duration | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 7.4. IPsec SA Proposal Sub-TLV 998 The IPsec SA Proposal Sub-TLV is to indicate the number of Transform 999 Sub-TLVs. This Sub-TLV aligns with the sub-TLV structure from 1000 [SECURE-VPN] 1002 The Transform Sub-sub-TLV will following the section 3.3.2 of 1003 RFC7296. 1005 7.5. Simplified IPsec Security Association sub-TLV 1007 For a simple SDWAN network with edge nodes supporting only a few 1008 pre-defined encryption algorithms, a simple IPsec sub-TLV can be 1009 used to encode the pre-defined algorithms, as below: 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 |IPsec-simType |IPsecSA Length | Flag | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Transform | Mode | AH algorithms |ESP algorithms | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | ReKey Counter (SPI) | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | key1 length | Public Key ~ 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | key2 length | Nonce ~ 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Duration | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Where: 1028 o IPsec-SimType: The type value has to be between 128~255 because 1029 IPsec-SA subTLV needs 2 bytes for length to carry the needed 1030 information. 1031 o IPsec-SA subTLV Length (2 Byte): 25 (or more) 1032 o Flags: 1 octet of flags. None are defined at this stage. Flags 1033 SHOULD be set to zero on transmission and MUST be ignored on 1034 receipt. 1035 o Transform (1 Byte): the value can be AH, ESP, or AH+ESP. 1037 o IPsec Mode (1 byte): the value can be Tunnel Mode or Transport 1038 mode 1039 o AH algorithms (1 byte): AH authentication algorithms supported, 1040 which can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. 1041 Each SDWAN edge node can have multiple authentication. 1042 algorithms; send to its peers to negotiate the strongest one. 1043 o ESP (1 byte): ESP authentication algorithms supported, which 1044 can be md5 | sha1 | sha2-256 | sha2-384 | sha2-512 | sm3. Each 1045 SDWAN edge node can have multiple authentication algorithms; 1046 send to its peers to negotiate the strongest one. Default 1047 algorithm is AES-256. 1048 o When node supports multiple authentication algorithms, the 1049 initial UPDATE needs to include the "Transform Sub-TLV" 1050 described by [SECURE-EVPN] to describe all of the 1051 algorithms supported by the node. 1053 o Rekey Counter (Security Parameter Index)): 4 bytes 1054 o Public Key: IPsec public key 1055 o Nonce.IPsec Nonce 1056 o Duration: SA life span. 1058 7.6. IPsec SA Encoding Examples 1060 For the Figure 1 in Section 3, C-PE2 needs to advertise its IPsec SA 1061 associated attributes, such as the public keys, the nonce, the 1062 supported encryption algorithms for the IPsec tunnels terminated at 1063 192.0.0.1, 170.1.1.1 and 2.2.2.2 respectively. 1065 Using the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1] as an 1066 example: C-PE1 needs to advertise the following attributes for 1067 establishing the IPsec SA: 1068 SDWAN Node ID 1069 SDWAN Color 1070 Tunnel Encap Attr (Type=SDWAN-Hybrid) 1071 Extended Port Sub-TLV for information about the Port 1072 (including ISP Sub-TLV for information about the ISP2) 1073 IPsec SA Nonce Sub-TLV, 1074 IPsec SA Public Key Sub-TLV, 1075 IPsec SA Sub-TLV for the supported transforms 1076 {Transforms Sub-TLV - Trans 2, 1077 Transforms Sub-TLV - Trans 3} 1079 C-PE2 needs to advertise the following attributes for establishing 1080 IPsec SA: 1081 SDWAN Node ID 1082 SDWAN Color 1083 Tunnel Encap Attr (Type=SDWAN-Hybrid) 1084 Extended Port Sub-TLV (including ISP Sub-TLV for information 1085 about the ISP2) 1086 IPsec SA Nonce Sub-TLV, 1087 IPsec SA Public Key Sub-TLV, 1088 IPsec SA Sub-TLV for the supported transforms 1089 {Transforms Sub-TLV - Trans 2, 1090 Transforms Sub-TLV - Trans 4} 1092 As both end points support Transform #2, the Transform #2 will be 1093 used for the IPsec Tunnel [ISP4: 160.0.0.1 <-> ISP2:170.0.0.1]. 1095 8. Error & Mismatch Handling 1097 Each C-PE device advertises SDWAN SAFI Underlay NLRI to the other C- 1098 PE devices via BGP Route Reflector to establish pairwise SAs between 1099 itself and every other remote C-PEs. During the SAFI NLRI 1100 advertisement, the BGP originator would include either simple IPSec 1101 Security Association properties defined in IPSec SA Sub-TLV based on 1102 IPSec-SA-Type = 1 or full-set of IPSec Sub-TLVs including Nonce, 1103 Public Key, Proposal and number of Transform Sub-TLVs based on 1104 IPSec-SA-Type = 2. 1106 The C-PE devices would compare the IPSec SA attributes between the 1107 local and remote WAN ports. If there is a match on the SA Attributes 1108 between the two ports, the IPSec Tunnel would be established. 1110 The C-PE devices would not try to negotiate the base IPSec-SA 1111 parameters between the local and the remote ports in the case of 1112 simple IPSec SA exchange or the Transform sets between local and 1113 remote ports if there is a mismatch on the Transform sets in the 1114 case of full-set of IPSec SA Sub-TLVs. 1116 As an example, using the Figure 1 in Section 3, to establish IPsec 1117 Tunnel between C-PE1 and C-PE2 WAN Ports A2 and B2 [A2: 192.10.0.10 1118 <-> B2:192.0.0.1]: 1120 C-PE1 needs to advertise the following attributes for establishing 1121 the IPsec SA: 1122 NH: 192.10.0.10 1123 SDWAN Node ID 1124 SDWAN-Site-ID 1125 Tunnel Encap Attr (Type=SDWAN) 1126 ISP Sub-TLV for information about the ISP3 1127 IPsec SA Nonce Sub-TLV, 1128 IPsec SA Public Key Sub-TLV, 1129 Proposal Sub-TLV with Num Transforms = 1 1130 {Transforms Sub-TLV - Trans 1} 1132 C-PE2 needs to advertise the following attributes for establishing 1133 IPsec SA: 1134 NH: 192.0.0.1 1135 SDWAN Node ID 1136 SDWAN-Site-ID 1137 Tunnel Encap Attr (Type=SDWAN) 1138 ISP Sub-TLV for information about the ISP1 1139 IPsec SA Nonce Sub-TLV, 1140 IPsec SA Public Key Sub-TLV, 1141 Proposal Sub-TLV with Num Transforms = 1 1142 {Transforms Sub-TLV - Trans 2} 1144 As there is no matching transform between the WAN ports A2 and B2 in 1145 C-PE1 and C-PE2 respectively, there will be no IPsec Tunnel be 1146 established. 1148 9. Manageability Considerations 1150 TBD - this needs to be filled out before publishing 1152 10. Security Considerations 1154 The document describes the encoding for SDWAN edge nodes to 1155 advertise its properties to their peers to its RR, which 1156 propagates to the intended peers via untrusted networks. 1158 The secure propagation is achieved by secure channels, such as 1159 TLS, SSL, or IPsec, between the SDWAN edge nodes and the local 1160 controller RR. 1162 [More details need to be filled in here] 1164 11. IANA Considerations 1166 This document requires the following IANA actions. 1168 o SDWAN Overlay SAFI = 74 assigned by IANA 1169 o SDWAN Route Type 1171 12. References 1173 12.1. Normative References 1175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1176 Requirement Levels", BCP 14, RFC 2119, March 1997. 1178 12.2. Informative References 1180 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 1181 (I2NSF) Problem Statement and Use Cases", July 2017 1183 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 1184 Address Family Identifier (SAFI) and the BGP Tunnel 1185 Encapsulation Attribute", April 2009. 1187 [CONTROLLER-IKE] D. Carrel, et al, "IPsec Key Exchange using a 1188 Controller", draft-carrel-ipsecme-controller-ike-01, work- 1189 in-progress. 1191 [LISP-GEOLOC] D. Farinacci, "LISP Geo-Coordinate Use-Case", draft- 1192 farinacci-lisp-geo-09, April 2020. 1194 [SDN-IPSEC] R. Lopez, G. Millan, "SDN-based IPsec Flow Protection", 1195 draft-ietf-i2nsf-sdn-ipsec-flow-protection-07, Aug 2019. 1197 [SECURE-EVPN] A. Sajassi, et al, "Secure EVPN", draft-sajassi-bess- 1198 secure-evpn-02, July 2019. 1200 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 1201 Attribute", draft-ietf-idr-tunnel-encaps-09, Feb 2018. 1203 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 1204 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 1205 work-in-progress, July 2018 1207 [DMVPN] Dynamic Multi-point VPN: 1208 https://www.cisco.com/c/en/us/products/security/dynamic- 1209 multipoint-vpn-dmvpn/index.html 1211 [DSVPN] Dynamic Smart VPN: 1212 http://forum.huawei.com/enterprise/en/thread-390771-1- 1213 1.html 1215 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 1216 storage, distribution and enforcement of policies for 1217 network security", Nov 2007. 1219 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 1220 Underlay to Cloud Overlay Problem Statement", draft-dm- 1221 net2cloud-problem-statement-02, June 2018 1223 [Net2Cloud-gap] L. Dunbar, A. Malis, and C. Jacquenet, "Gap Analysis 1224 of Interconnecting Underlay with Cloud Overlay", draft-dm- 1225 net2cloud-gap-analysis-02, work-in-progress, Aug 2018. 1227 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 1228 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 1230 13. Acknowledgments 1232 Acknowledgements to Wang Haibo, Hao Weiguo, and ShengCheng for 1233 implementation contribution; Many thanks to Jim Guichard, John 1234 Scudder, and Donald Eastlake for their review and contributions. 1236 This document was prepared using 2-Word-v2.0.template.dot. 1238 Authors' Addresses 1240 Linda Dunbar 1241 Futurewei 1242 Email: ldunbar@futurewei.com 1244 Sue Hares 1245 Hickory Hill Consulting 1246 Email: shares@ndzh.com 1248 Robert Raszuk 1249 Email: robert@raszuk.net 1251 Kausik Majumdar 1252 CommScope 1253 Email: Kausik.Majumdar@commscope.com