BGP UPDATE for SD-WAN Edge Discovery

2.2.1. SD-WAN Secure L3VPN Example Topology

This section summarizes the BGP requirements from the following three scenarios from [SD-WAN-BGP-USAGE] can be handled by a BGP control plane using BGP Tunnel-Encapsulation attribute [RFC9012]:¶

• Homogeneous Encripted SD-WAN,¶

• Differential Encrypted SD-WAN, and¶

• Private VPN PE based SD-WAN.¶

Based on [SD-WAN-BGP-USAGE], it is easy to see how Figure 1 matches scenario 1 (Homogeneneous Encrypted SD-WAN) and scenario 2 (Differential Encrypted SD-WAN). Recasting Figure 1 as a logical BGP peering topology results in a BGP topology between PEs and CN (CE at customer site) results in Figure 2. Scenario 3 (Private VPNs based on SD-WAN) from [SD-WAN-BGP-USAGE] aligns with the Figure 2.¶

Hybrid SD-WAN tunnel infrastructure requires that the PEs (C-PE1, C-PE2, C-PE3, and C-PE4) have an existing topology that the Hybrid SD-WAN tunnel overlays. These PEs use local policy to sending the approprite traffic across the appropriate network based on local policy.¶

Hybrid SD-WAN Secure L3VPN:

Sample Topology¶

     BGP over secure link       +---+  BGP over secure link
                   +------------|RR |---------+
                  / BGP Peer    +-+-+ BGP Peer \
                 /                              \
                /                                \
        +---------+                              +-------+
 +---+  | C-PE1   |--P1--( MPLS L3VPN Net1 )--P1-| C-PE2 | +---+
 |CN3|--|         |--P2--( MPLS L2VPN Net2 )--P2-|       |-|CN3|
 +---+  |         |                              |       |
 +---+  |         |                              |       | +---+
 |CN2|--| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CN1|
 +---+  |         |--P4---(L2 direct link)----P4-|       | +---+
    |   +---------+                              +-------+    |
    \                                                         /
     \  +---------+                              +-------+  /
      +-|         |                              |       |-+
 +---+  | C-PE3   |--P1---( MPLS L3VPN Net1 )--P1| C-PE4 | +---+
 |CN2|--|         |--P2---( MPLS L2VPN Net2 )--P2|       |-|CN1|
 +---+  |         |                              |       | +---+
 +---+  |         |                              |       | +---+
 |CN1|--| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CN2|
 +---+  |         |--P4---(L2 direct link)----P4-|       | +---+
        +---------+                              +-------+
               \                                 /
                \                               /
                 \ BGP Peer    +-+-+ BGP Peer  /
                  +------------|RR |----------+
     BGP over secure link      +---+  BGP over secure link

         Please note that RR may be one RR, but for clarity of diagram
         the RR has been displayed as two parts.

Hybrid SD-WAN BGP Mesh :

Logical BGP Topology for SD-WAN¶

                 Logical topology for BGP peers

                             +----+
                   +---------| RR |---------+
                  /          +--+-+          \
                 /                            \
              +------+                         +------+
   +---+  |      |------SDWAN hybrid-------|      |  +---+
   |CN3|--|CE-PE1|                         |CE-PE2|--|CN3|
   +---+  |      |           /-------------|      |  +---+
   +---+  |      |---\      /              |      |  +---+
   |CN2|--|      |    \    SDWAN Hybrid    |      |--|CN1|
   +---+  |      |     \ /                 |      |  +---+
          +------+     /                   +------+
                      /  \
              +------+   /    \                +------+
   +---+  |      |--/    SDWAN Hybrid      |      |  +---+
   |CN2|--|CE-PE |          \------------- |CE-PE4|--|CN1|
   +---+  |      |                         |      |  +---+
   +---+  |      |                         |      |  +---+
   |CN1|--|      |                             |      |--|CN2|
   +---+  |      |------SDWAN hybrid-------|      |  +---+
          +------+                         +------+
               \                                /
                \                              /
                 \ BGP Peer  +-+--+ BGP Peer  /
                  +----------| RR |----------+
                             +----+

     Please note that RR may be one RR, but for clarity of diagram
         the RR has been displayed as two parts.
         The BGP connections to the RR are over secure links or
         secure transports.

Note that the Figure 1 SD-WAN node BGP peers (C-PE) are connected in the underlay by both trusted VPNs and untrusted public networks. For trusted VPNs, IPsec Security associations may not be set-up. In some circumstances, some SD-WAN node peers may be connected only by untrusted public networks. For the traffic over untrusted networks, IPsec Security Associations (IPsec SA) must be established and maintained. If an edge node has network ports behind a NAT, the NAT properties need to be discovered by the authorized SD-WAN peers.¶

2.2.2. SD-WAN Secure Links Example Topology

Suppose the SD-WAN network topology from Figure 1 removes the L3VPN links. Instead the links are simply a combination of L3 WAN Networks (unsecured) and physically secure direct L2 and L3 links. The topology in Figure 1 becomes the underlay physical topology in Figure 3. The unsecured links need IPSec encryptions so the IPsec links must be configured. An SD-WAN Hybrid tunnel allows connections between the C-PEs (C-PE1, C-PE2, C-PE3, and C-PE) to be a single logical link.¶

Therefore, the logical topology in Figure 3, reduces to the SD-WAN logical topology shown in Figure 2.¶

Hybrid SD-WAN Secure Links:

Sample Topology¶

     BGP over secure link       +---+  BGP over secure link
                   +------------|RR |---------+
                  / BGP Peer    +-+-+ BGP Peer \
                 /                              \
                /                                \
        +---------+                              +-------+
 +---+  | C-PE1   |--P1--( WAN L3 Net1)-------P1-| C-PE2 | +---+
 |CN3|--|         |--P2--( L3 Direct Link)----P2-|       |-|CN3|
 +---+  |         |                              |       |
 +---+  |         |                              |       | +---+
 |CN2|--| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CN1|
 +---+  |         |--P4---(L2 direct link)----P4-|       | +---+
    |   +---------+                              +-------+    |
    \                                                         /
     \  +---------+                              +-------+  /
      +-|         |                              |       |-+
 +---+  | C-PE3   |--P1--( WAN L3 Net1 )------P1-| C-PE4 | +---+
 |CN2|--|         |--P2--( L3 Direct Link )---P2-|       |-|CN1|
 +---+  |         |                              |       | +---+
 +---+  |         |                              |       | +---+
 |CN1|--| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CN2|
 +---+  |         |--P4---(L2 direct link)----P4-|       | +---+
        +---------+                              +-------+
               \                                 /
                \                               /
                 \ BGP Peer    +-+-+ BGP Peer  /
                  +------------|RR |----------+
     BGP over secure link      +---+  BGP over secure link

         Please note that RR may be one RR, but for clarity of diagram
         the RR has been displayed as two parts.

2.2.3. RR connections to BGP Peers in SD-WAN

For both the SD-WAN Secure L3VPN network and the SD-WAN Secure Links, the BGP Peers are assumed to be connected to a Route Reflector via secure link. For an SD-WAN deployment with multiple RRs, it is assumed that there are secure connections among those RRs.¶

How secure connections are established between the BGP Peer and the RR, or between the multiple RRs is out of the scope of this document. The existing BGP UPDATE propagation mechanisms control the edge properties propagation among the RRs.¶

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.¶

3.2.1. NLRI for SD-WAN Underlay Tunnel Update

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:¶

+------------------+
|    Route Type    | 2 octet
+------------------+
|     Length       | 2 Octet
+------------------+
|   Type Specific  |
~ Value (Variable) ~
|                  |
+------------------+

where:¶

Route (NLRI) Type:

2 octet value to define the encoding of the rest of the SD-WAN the NLRI. The SD-WAN Secure Links use case may have many different formats, the route type was assigned two octets.¶

Length:

2 octets of length expressed in bits as defined in [RFC4760].¶

This document defines the following SD-WAN Route type:¶

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:¶

     +------------------+
     |  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
     +------------------+

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.¶

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.¶

SD-WAN Node ID:

The node's IPv4 or IPv6 address. For IPv4 SD-WAN NLRI (1/74) the length is 4. For IPv6 SD-WAN NLRI (1/76), the length is 16.¶

Route Type values outside of 1 are out of scope for this document.¶

3.2.2. Validation of SD-WAN NLRI

(editor) Need some input on whether Egress End Point should match SD-WAN node-ID or if these can be different. If they can be different, how are we validating the tunnel Egress end point.¶

3.3.1. IPsec-SA-ID Sub-TLV

SubTLV Name:

IPsec-SA-ID - Send IPsec SA-IDs¶

SubTLV Code:

64 (IANA assigned)¶

SubTLV Description:

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. 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.¶

SubTLV Encoding:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPSec-SA-ID Sub|   Length  |  Reserved                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #2                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #n                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

• IPSec-SA-ID Sub-Type (8 bits): 64(IANA Assigned).¶

• length (8 bits): Specifies the total length in octets of the value field (not including the Type and Length fields). For the IPSec-SA-ID Sub-Type, the length should be the 2 + 4 *(number of IPsec SA IDs) .¶

• Reserved: Reserved for future use. In this version of the document, the Reserved field MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change.¶

• Value field: The value field consists of a sequence of IPsec SA Identifiers, each 4 octets long. As shown in figure above, n IPsec SAs are attached in the IPsec-SA-ID Sub-TLV:¶

  • IPSec SA Identifier #1: A 4 octet identifier for a pre-established IP security association.¶

  • IPSec SA Identifier #2: A 4 octet identifier for a pre-established IP security association.¶

  • IPSec SA Identifier #n: A 4 octet identifier for a pre-established IP security association.¶

SubTLV Error Handling:

A IPsec-SA-ID Sub-TLV is a MALFORMED if the fields do not fit the limits specified above. Per [RFC9012] a MALFORMED Sub-TLV is ignored. The procedures for content check for the IPsec-SA-ID Sub-TLV is specified in section 3.4 for client routes, and section 3.5 for underlay routes.¶

Tunnel End Point Validation:

The IPsec-SA-ID Sub-TLV does not help validate the Tunnel Egress EndPoint. However, the IPSec-SA provide the security information associated with set of routes sent from a peer which must be correctly handled upon reception of the data.¶

3.3.2. IPsec SA Rekey Counter Sub-TLV

SubTLV Name:

IPsec SA ReKey Counter - Rekey Counter for a IPsec SA¶

SubTLV Code:

67 (IANA assigned)¶

SubTLV Description:

The IPsec SA Rekey Counter Sub-TLV provides the rekey counter for a security association (identified by IPsec SA Identifier).¶

SubTLV Encoding:

The encoding iss shown in the figure below:¶

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |IPSec-SA-ID Sub|   Length  |  Reserved                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   ID Length   |       Nonce Length            |I|   Flags     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Rekey                             |
       |                            Counter                            |
       +---------------------------------------------------------------+
       |                IPsec SA Identifier                            |
       +---------------------------------------------------------------+
       |                                                               |
       ~                          Nonce Data                           ~
       |                                                               |
       +---------------------------------------------------------------+

where:¶

IPSec-SA-ID Sub-Type (8 bits): 67 (IANA assigned)¶

length (8 bits): Specifies the total length in octets of the value field (not including the Type and Length fields). The total length is variable with the value equal to 16 plus Nonce length.¶

Reserved: Reserved for future use. In this version of the document, the Reserved field MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change.¶

ID Length (8 bits): indicates the length in octets of SA-Identifer. This length should be 4 octets.¶

Nonce Length (16 bits): indicates the length in octets of the Nonce Data.¶

I Flag: when set to 1, the I-flag indicates that the communication being established is new. when set to 0, it signals that the communication is a continuation of an existing session.¶

Flags (7 bits): Reserved for future use. In this version of the document, the Reserved field MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change.¶

Rekey Counter (64 bits): the number of key updates or rekeys that have occurred. Each time a key is rotated or replaced, the ReKey Counter is incremented.¶

IPsec SA Identifier (IPSec-SA-ID): a specific IPsec SAs terminated at the edge.¶

Nonce Data: a random or pseudo-random number for preventing replay attacks. Its length is a multiple of 32 bits[RFC7296].¶

SubTLV Error Handling:

A IPsec SA Rekey Counter Sub-TLV s a MALFORMED if the fields do not fit the limits specified above. Per [RFC9012] a MALFORMED SubTLV is ignored. The procedures for content checks for this Sub-tLV are specified in section 3.4 for client routes, and section 3.5 for underlay routes. Please note that:¶

The IPsec-SA-ID may also refer to the values carried in the same TEA in the same Tunnel TLV (type SD-WAN Hybrid) as the IPsec SA Rekey Counter Sub-TLV in either the IPsec Public Key Sub-TLV or the IPsec SA Proposal Sub-TLV. The IPsec SA Rekey Counter, IPsec Public Key, and IPsec SA Proposal Sub-TLVs work together to create security associations.¶

The IPsec-SA-ID may refer to an IPsec SA-ID in another SD-WAN Hybrid Tunnel TLV in the same TEA as the IPsec SA Rekey Counter sub-TLV,¶

The IPsec SA-ID may refer to a preconfigured IPsec SA-ID preconfigured associated with this SD-WAN Hybrid Tunnel Endpoint.¶

Tunnel End Point Validation:

The IPsec SA Rekey SubTLV does not help validate the Tunnel Egress EndPoint.¶

3.3.3. IPsec Public Key Sub-TLV

SubTLV Name:

IPsec Public Key - IPsec Public Key information¶

SubTLV Code:

68 (IANA assigned)¶

SubTLV Description:

The IPsec Public Key Sub-TLV provides the Public Key exchange information and the life span for the Diffie-Hellman Key.¶

SubTLV Encoding:

The encoding iss shown in the figure below:¶

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |IPSec-SA-ID Sub|   Length  |  Reserved                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Diffie-Hellman Group Num    |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                       Key Exchange Data                       ~
       |                                                               |
       +---------------------------------------------------------------+
       |                            Duration                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

IPSec-SA-ID Sub-Type (8 bits): 68 (IANA assigned)¶

length (8 bits): Specifies the total length in octets of the value field (not including the Type and Length fields). The total length is variable with the length being 14 + the Key Exchange Data length.¶

Diffie-Hellman Group Num (16-bits): identifies the Diffie-Hellman group used to compute the Key Exchange Data. Details on Diffie-Hellman group numbers can be found in Appendix B of IKEv2 [RFC7296] and [RFC5114].¶

The Key Exchange data: This refers to a copy of the sender's Diffie-Hellman public value. The length of the Diffie-Hellman public value is defined for MODP groups in [RFC 7296] and for ECP groups in [RFC 5903].¶

Duration (32 bits): a 4-octet value specifying the life span of the Diffie-Hellman key in seconds.¶

SubTLV Error Handling:

A IPsec Public Key SubTLV is a MALFORMED SubTLV if the fields do not fit the limits specified above. Per [RFC9012] a MALFORMED SubTLV is ignored. The procedures for content checks for the IPsec Public is specified in section 3.4 for client routes, and section 3.5 for underlay routes.¶

Tunnel End Point Validation:

The IPsec SA Rekey SubTLV not help validate the Tunnel Egress EndPoint.¶

3.3.4. IPsec SA Proposal Sub-TLV

SubTLV Name:

IPsec SA Proposal - Indicates number of IPsec Transforms¶

SubTLV Code:

69 (IANA assigned)¶

SubTLV Description:

The IPsec SA Proposal Sub-TLV is to indicate the number of Transform Sub-TLVs.¶

SubTLV Encoding:

The encoding iss shown in the figure below:¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPSec-SA-ID Sub|   Length      |  Reserved                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Transform Attr Length      |Transform Type |    Reserved.  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Transform ID              |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Transform Attributes                   ~
|                                                               |
+---------------------------------------------------------------+

where:¶

IPSec-SA-ID Sub-Type (8 bits): 69 (IANA assigned)¶

length (8 bits): Specifies the total length in octets of the value field (not including the Type and Length fields). The total length is variable with the length being 10 + the Transform attribute length.¶

Transform Attr Length (16 bits): indicates the length of the Transform Attributes field.¶

Transform Type (8 bits): The Transform Type values are defined in Section 3.3.2 of [RFC7296] and [IKEV2IANA]. Only ENCR, INTEG, and ESN values are permitted.¶

Reserved (8 bits): reserved for future use. These bits are ignored upon receipt and set to zero when transmitted.¶

Transform ID (16 bits): An identifer for the transform defined by the associated transform attributes.¶

Transform Attributes: These Sub-SubTLV are defined in section 3.3.5 of [RFC7296].¶

SubTLV Error Handling:

A IPsec SA Proposal Sub-TLV is a MALFORMED Sub-TLV if the fields do not fit the limits specified above. Per [RFC9012] a MALFORMED Sub-TLV is ignored. The procedures for content checks for the IPsec SA Proposal SubTLV is specified in section 3.4 for client routes, and section 3.5 for underlay routes.¶

Tunnel End Point Validation:

The IPsec SA Rekey SubTLV not help validate the Tunnel Egress EndPoint.¶

3.3.5. Simplified IPsec SA Sub-TLV

SubTLV Name:

Simplified IPsec SA - Provides simple key for 2 keys¶

SubTLV Code:

69 (IANA assigned)¶

SubTLV Description:

For a simple SD-WAN network with edge nodes supporting only a few pre-defined encryption algorithms, a simple IPsec sub-TLV can be used to encode the pre-defined algorithms.¶

SubTLV Encoding:

The encoding is shown in the figure below:¶

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |IPSec-SA-ID Sub|   Length      |  Reserved                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |IPsec-simType  |IPsecSA Length |             Reserved          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Transform     | Mode          | AH algorithms |ESP algorithms |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ReKey Counter (SPI)                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | key1 length   |         Key 1                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | key2 length   |         Key 2                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | nonce length  |         Nonce                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Duration                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

IPSec-SA-ID Sub-Type (8 bits): 70¶

Length (8 bits):

variable (based on key length)¶

Reserved (16 bits):

Reserved for future use. These bits SHOULD be set to zero on transmission and MUST be ignored on receipt.¶

Transform (8 bits):

• Transform = 1 means AH,¶

• Transform = 2 means ESP, or¶

• Transform = 3 means AH+ESP.¶

All other transform values are outside the scope of this document.¶

IPsec Mode (8 bits):

• Mode = 1 indicates that the Tunnel Mode is used.¶

• Mode = 2 indicates that the Transport mode is used.¶

All mode values besides 1 and 2 are outside the scope of this document.¶

AH algorithms (8 bits):

AH authentication algorithms supported. The values are specified by [IANA-AH]. Each SD-WAN edge node can support multiple authentication algorithms; send to its peers to negotiate the strongest one.¶

ESP algorithms (8 bits):

the ESP algorithms supported. Its values are specified by [IANA-ESP]. One SD-WAN edge node can support multiple ESP algorithms and send them to its peers to negotiate the strongest one. The default algorithm is AES-256.¶

When a node supports multiple authentication algorithms, the initial UPDATE needs to include the "Transform Sub-TLV"¶

Rekey Counter (Security Parameter Index) (4 octet):

indicates the count for rekeying.¶

key1 length (8 bits):

indicates the IPsec public key 1 length¶

Public Key 1:

IPsec public key 1¶

key2 length (8 bits):

indicates the IPsec public key 2 length¶

Public Key 2:

IPsec public key 2¶

none-length (8 bits):

indicates the Nonce key length¶

Nonce:

IPsec Nonce¶

Duration (32 bits):

specifying the security association (SA) life span in seconds.¶

SubTLV Error Handling:

A Simplified IPsec SA Sub-TLVis a MALFORMED Sub-TLV if the fields do not fit the limits specified above. Per [RFC9012] a MALFORMED Sub-TLV is ignored. The procedures for content checks for the IPsec SA Proposal SubTLV is specified in section 3.4 for client routes, and section 3.5 for underlay routes.¶

Tunnel End Point Validation:

Simplified IPsec SA does not participate in Tunnel End Point Validation.¶

3.3.6. Extended Port Attribute Sub-TLV

SubTLV Name:

Extended Port Attribute - Provides information related IPsec and NATs¶

SubTLV Code:

65 (IANA assigned)¶

SubTLV Description:

The Extended Port Attribute Sub-TLV advertises the properties associated with a public Internet-facing WAN port that might be behind NAT. A 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.¶

The location of a NAT device can be:¶

• 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.¶

• Only the responder is behind a NAT device.¶

• Both the initiator and the responder are behind a NAT device.¶

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.¶

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.¶

SubTLV Encoding:

The encoding is shown in the figure below:¶

     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                             |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

• Extended Port Attribute Type (=65): indicating it is the Extended Port Attribute SubTLV¶

• ExtPort Length: the length of the subTLV in octets (variable).¶

• Flags:¶

  • I bit (CPE port address or Inner address scheme):¶

    • If set to 0, indicate the inner (private) address is IPv4.¶

    • If set to 1, indicates the inner address is IPv6.¶

  • O bit (Outer address scheme):¶

    • If set to 0, indicate the inner (private) address is IPv4.¶

    • If set to 1, indicates the inner address is IPv6.¶

  • R bits: reserved for future use. Must be set to 0, and ignored upon reception.¶

• NAT Type: the NAT type can be one of the following values:¶

  • 1: without NAT ;¶

  • 2: 1-to-1 static NAT;¶

  • 3: Full Cone;¶

  • 4: Restricted Cone;¶

  • 5: Port Restricted Cone;¶

  • 6: Symmetric; or¶

  • 7: Unknown (i.e. no response from the STUN server).¶

  NAT type values outside of 1-7 are invalid for this SubTLV.¶

• Encap-Type: the supported encapsulation types for the port.¶

  • Encap-Type=1: GRE;¶

  • Encap-Type=2: VxLAN;¶

  Notes:¶

  • 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:¶

    • 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.¶

    • 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.¶

  • Encapsulation types outside of GRE and VxLAN are outside of the scope of this specification.¶

• Transport Network ID: Central Controller assigns a global unique ID to each transport network. Any value in this octet is valid¶

• RD ID: Routing Domain ID, need to be globally unique. Any value in this octet is valid.¶

  • 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.¶

• Local IP: The local (or private) IP address of the WAN port.¶

• Local Port: used by Remote SD-WAN edge node for establishing IPsec to this specific port.¶

• Public IP: The IP address after the NAT. If NAT is not used, this field is set to all-zeros¶

• Public Port: The Port after the NAT. If NAT is not used, this field is set to all-zeros.¶

• Extended SubSub-TLV: for carrying additional information about the underlay networks.¶

SubTLV Error Handling:

A IPsec SA Proposal Sub-TLV is a MALFORMED Sub-TLV if the fields do not fit the limits specified above. Per [RFC9012] a MALFORMED Sub-TLV is ignored. The procedures for content checks for the IPsec SA Proposal SubTLV is specified in section 3.4 for client routes, and section 3.5 for underlay routes.¶

Tunnel End Point Validation:

Simplified IPsec SA does not participate in Tunnel End Point Validation.¶

3.4.1. SD-WAN Tunnel in Encapsulation Extended Community (Encaps-EC)

The SD-WAN Client routes are sent with a the Encapsulation Extended Community (Encap-EC) BGP attribute that identifies the the Hybrid SD-WAN tunnel type. 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.¶

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.¶

3.4.2. SD-WAN Tunnel in Tunnel Encapsulation Path Attribute (TEA)

The procedures for validating a client route with a TEA does the following:¶

1. Check for Well-formed SD-WAN Hybrid Tunnel TLV:

A well-formed Hybrid SD-WAN Tunnel TLV MUST have a Tunnel Engress Endpoint SubTLV. The validation for the Tunnel Egress Endpoint uses the [RFC9012] validation in section 6, 8, and 13. An invalid Tunnel Egress Endpoint, cause the Hybrid SD-WAN Tunnel TLV to be invalid, and the TLV is ignored.¶

It MAY also have any of the following SubTLVs:¶

• the Color SubTLV defined in [RFC9012],¶

• IPsec-SA-ID,¶

• IPsec SA Nonce,¶

• IPsec Public Key,¶

• IPSec SA Proposal, or¶

• Simplified IPsec SA)¶

A MALFORMED SubTLV is ignored in the Tunnel TLV is ignored.¶

SubTLV with an unknown type is ignored.¶

2. Check for multiple instances of SubTLVs:

Multiple instances of the Tunnel Endpoint SubTLV causes the first one to be used, and the subsequent instances to be ignored.¶

Multiple instances of the IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA cause the first instance to be used, and subsequent instances to be ignored.¶

A Hybrid SD-WAN tunnel TLV may have multiple instances of the IPsec-SA-ID if the IPsec SA Identifiers are unique. If all the IPsec SA Identifies are not unique, the second SubTLV is ignored and not propagated.¶

3. Validate Tunnel Egress Endpoint:

The Tunnel Egress Endpoint MUST link to the remote end of one of the underlay links to be used. This validation adheres to the [RFC9012] Tunnel Egress Endpoint validation. The tunnel link may be active or inactive.¶

4. Validate each NLRI:

Local policy is run to validate routes.¶

5. Validate Hext Hop:

The next hop must be be reachable via the tunnel."¶

3.4.3. Multiple tunnels attached to One Client Route

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.¶

3.4.4. SD-WAN VPN ID in Client Route Update

An SD-WAN VPN ID is the 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.¶

3.4.5. SD-WAN VPN ID in Data Plane

SD-WAN edge node 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.¶

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.¶

3.5.1. Hybrid SD-WAN NLRI with a Encapsulation Extended Community

The Hybrid SD-WAN NLRI MUST be accompanied with the TEA, and MUST NOT be accompanied by an Encapsulation Extended Community.¶

3.5.2. Underlay Route with a TEA

An underlay routes contains Hybrid SD-WAN NLRIs with TEA attached. The procedures for processing underlay routes follows the following steps:¶

1. Check for Well-Formed SD-WAN Hybrid Tunnel TLV:

An Hybrid SD-WAN Tunnel TLV is well-formed using only SubTLVs valid for association with the underlay Route.¶

A well-formed SD-WAN Hybrid Tunnel TLV MUST contain a valid Tunnel Egress Endpoint subTLV to be a valid SD-WAN Hybrid TLV. [RFC9012] provides validation guidelines for the Tunnel Egress Endpoint in sections 13.¶

The SD-WAN Hybrid Tunnel TLV MAY contain the following subTLVs: Tunnel Egress, IPsec-SA-ID, Extended Port SubTLV, IPsec Nonce, IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.¶

Following [RFC9012] intent, a MALFORMED SubTLV is ignored, and a SubTLV with an unknown type is ignored.¶

2. Multiple instances of SubTLVs within a SD-WAN Tunnel TLV

Multiple instances of the Tunnel Endpoint, IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA cause only the first one to be used. Subsequent subTLV ware ignored and not propagated. The IPsec-SA-ID subTLVs may have multiple instances of the subTLV if the IPsec SA Identifiers are unique, but if the IPsec SA Identifiers are not unique the second subTLV is ignored and not propagated. If multiple Extended Port SubTLVs exist, the TLVs must be validated in step 4.¶

3. Validate Tunnel Egress Endpoint

The Tunnel Egress Endpoint MUST link to remote end point of one of the underlay links from the router receiving the link.¶

4. Validate Extended Port SubTLV(s)

If a single Extended Port SubTLV exist, then validate that the port information provides needed information to establish a connection to the remote port. A SD-WAN edge node MAY utilize local policy, local configuration, and the information from the SubTLV. The exact mechanism of local port validation is outside the scope of this document. If the Extended Port SubTLV is invalid, the SD-WAN tunnel TLV must be considered to be invalid.¶

5. Validate each NLRI

The typed NLRI in the SD-WAN Underlay MUST be Well-Formed having the format specified in section 3.2.1. A MALFORMED NLRI must cause the NLRI to be discarded. An implementation MAY log an error for a MALFORMED NLRI. The local policy configuration in the BGP peer receiving this NLRI MUST determine the validity of the route based on policy.¶

6. Validate Next Hop

The IP address specified in the Next Hop field must be reachable by the Tunnels.¶

3.5.3. Underlay Routes with Port-Local-ID of zero

Section 3.2.1 specifies that Route Type 1 has a tuple of (Port-Local-ID, SD-WAN-Color, SD-WAN-Node-ID). Port-Local-ID may be zero if the NLRI applies to multiple ports. The BGP Peer receiving the NLRI must have pre-configured inbound filters to set the preference for the SD-WAN NLRI tuple.¶

Since a Port-Local-ID value of zero indicates the NLRI applies to multiple ports, it is possible to have the following NLRI within a packet (or received in multiple packets):¶

• Port-Local-ID (0), SD-WAN-Color (10), SD-WAN-Node-ID (2.2.2.2),¶

• Port-Local-ID (0), SD-WAN-Color (20), SD-WAN-Node-ID (2.2.2.2), and¶

• Port-Local-ID (0), SD-WAN-Color (30), SD-WAN-Node-ID (2.2.2.2).¶

These NLRI may simply indicate that there are three groups of tunnels for SD-WAN-Node-ID (2.2.2.2) assigned three colors. For example, these tunnels could represent three types of gold, silver and bronze network service.¶

3.5.4. Multiple Tunnels attached to One Underlay Route

An underlay route (SD-WAN NLRI) may only attach to one Hybrid SD-WAN Tunnel. If there are more than one Hybrid SD-WAN Tunnel TLV within a single TEA, the first is processed and the subsequent Hybrid SD-WAN Tunnel TLVs are ignored.¶

3.6.1. Error handling for the Tunnel Encapsulation Signaling

The error handling for the tunnel encapsulation signaling (Encaps-EC and TEA) adheres to the error handling and validation specified by [RFC9012].¶

The Tunnel encapsulation signaled with the client routes indicates the Egress endpoint via Next Hop in the Encaps-EC or the TEA SubTLV for Tunnel Egress Endpoints. As indicated in the procedure in sections 3.4.2 and 3.5.2, the SD-WAN Hybrid tunnel follows the validation section 6, 8, and 13 from [RFC9012].¶

The SD-WAN client routes associates some of the NLRIs that [RFC9012] associates with the Encaps-EC and the TEA using the validation specified in [RFC9012] in sections 6, 8, and 13. When the SD-WAN Hybrid Tunnel is associated with the SD-WAN NLRI, and all RFC9012 validation rules in section 6, 8, and 13 are extended to apply to the SD-WAN NLRI.¶

[RFC9012] contains the necessary detail to specify validation for the new SubTLVs present for the SD-WAN Tunnel type. However, to aid users of this document the following recap of validation of [RFC9012] is provided below. The validation from section 13 of [RFC9012] includes:¶

• Invalid tunnel type must be treat if the TLV was not present.¶

• A malformed subTLVs must be treated as an unrecognized subTLV except for Tunnel Egress Endpoint. If Tunnel Egress Endpoint is malformed, the entire TLV must be ignored.¶

• Multiple incidents of Tunnel Egress Endpoint SubTLV cause the first incident of these subTLVs to be utilized. Subsequent TLVs after the first one per type are ignored (per RFC9012), but propogated.¶

• If a subTLV is meaningless for a tunnel type, the subTLV is ignored, but the subTLV is not considered malformed or removed from the Tunnel Attribute propagated with the NLRI.¶

For SD-WAN client routes with a TEA with a SD-WAN Hybrid Tunnel type TLV, the IPSec SubTLVs (IPsec SA-ID, IPSec nonce, IPSec Public Key, IPsec Proposal, and Simplified IPsec SA) are meaningful, but may be rarely sent. Incorrect fields within any of these 5 TLVs. Per [RFC9012], a malformed subTLV is treated as an unrecognized subTLV.¶

For SD-WAN NLRI underlay routes, the the Extended Port subTLV and the IPSec SubTLVs (IPsec SA-ID, IPSec nonce, IPSec Public Key, IPsec Proposal, and Simplified IPsec SA) are valid and meaningful. Incorrect fields within any of these 6 TLVs or subSubTLVs within the TLVs should cause the subTLV to be treated as malformed SubTLV. Per [RFC9012], a malformed subTLV is treated as an unrecognized subTLV.¶

If multiple instancs of the IPsec nonce, IPsec Public Key, IPsec Proposal, and Simplified IPsec are received within a SD-WAN Tunnel TLV , only the first is processed. The second instance is ignored and not propagated. The IPsec SA-ID may have multiple copies, but the IPsec SA Identifiers sent in the second SubTLV must be different than any in the first IPsec-SA ID SubTLV.¶

If multiple instances of the Extended Port subTLV are received, the local policy must determine which is to be used.¶

3.6.2. Error Handling for NLRI

The SD-WAN NLRI [AFI 1/SAFI = 74] utilizes a route type field to describe the format of the NLRI. This specification only allows an NLRI with a type value of 1. An NLRI with a type of field of another value is ignored and not processed. The implementation MAY log an error upon a reception of an type value outside of Route Type 1. Error handling for the SD-WAN NLRI also adheres to the BGP Update error handling specified in [RFC7606].¶

The local policy configuration in the BGP peer receiving this NLRI must determine the validity of the route based on policy. Local configuration and policy must be carefully constrain the SD-WAN-NLRI, tunnels, and IPsec security associations in to create a "walled garden".¶

In the future, other proposals for a SD-WAN NLRI may specify a different route type. Those proposals must specify the following:¶

• validation for new Route Type in the SD-WAN-NLRI, and¶

• how the new Route Type interacts with the Route Type 1.¶

3.6.3. SDWAN NLRI and Tunnel Encapsulation Attribute

The SD-WAN NLRI (AFI=1/SAFI=74) must be paired with Tunnel Encapsulation attribute with a tunnel TLV for tunnel type SD-WAN-Hybrid. If the SD-WAN NLRI exist in an BGP UPDATE without a Tunnel Encapsulation Attribute (TEA) with a tunnel TLV for tunnel type SD-WAN-Hybrid, the NLRI is considered malformed and Treat-as-withdraw approach (per RFC7606).¶

The SD-WAN NLRI should not be paired with Encapsulation Extended Community. If an SD-WAN NLRI is paried Encapsulation Extended Community rather than a Tunnel Encapsulation Attribute, the SD-WAN NLRI is considered malformed and Treat-as-withdraw approach (per [RFC7606]) should be used.¶

4.2.1. SD-WAN Hybrid Tunnel Mechanisms for Passing IPSec Security Association Info

The TEA passes in the Tunnel TLV for the SD-WAN Hybrid Tunnel these three sets of information in the following subTLVs:¶

IPsec-SA-ID:

passes the previous configured (pre-configured or generated) IPsec SA identifiers.¶

Simplified IPsec SA SubTLV:

specifies a simplified set of information upon which to set-up the IPsec security associations for the tunnel.¶

A sequence of the following SubTLVs:

IPsec SA Rekey Counter SubTLV, IPsec Public Key SubTLV, and a IPSec Proposal SubTLV. Configuration on the local node uses this information and any information in the underlay to create security associations.¶

The BGP Peer's need to send the IPSec SA attributes received on the SD-WAN NLRI in the TEA between the local and remote WAN ports. If there is a match on the SA Attributes between the two ports, the IPSec Tunnel is established. If there is a mismtach on the SA Attributes, no IPsec Tunnel is established.¶

The C-PE devices do not try to negotiate the base IPSec-SA parameters between the local and the remote ports in the case of simple IPSec SA exchange or the Transform sets between local and remote ports. If there is a mismatch in the IPsec SA, then no IPsec Tunnel is created. If there is a mismatch on the Transform sets in the case of full-set of IPSec SA Sub-TLVs, no tunnel is created.¶

4.2.2. Example creation of IPsec Security Association over SD-WAN Hybrid tunnel

This section provides one example of how IPsec Security associations are created over the SD-WAN Hybrid tunnel. Figure 1 in Section 3 shows an establish an IPsec Tunnel being created between C-PE1 and C-PE2 WAN Ports A2 and B2 (A2: 192.10.0.10 - B2:192.0.0.1).¶

To create this tunnel C-PE1 needs to advertise the following attributes for establishing the IPsec SA:¶

• NextHop: 192.10.0.10¶

• SD-WAN Node ID: 1.1.1.1¶

• SD-WAN-Site-ID: 15.0.0.2¶

• Tunnel Encap Attr (Type=SD-WAN) -¶

  • Extended Port Attribute Sub-TLV containing¶

    • Transport SubSubTLV - with information on ISP3.¶

  • IPSec information for detailed information about the ISP3¶

  • IPsec SA Rekey Counter Sub-TLV,¶

  • IPsec SA Public Key Sub-TLV,¶

  • Proposal Sub-TLV (type = ENCR, transform ID = 1)¶

    • type: ENCR¶

    • Transform ID: 1¶

    • Tranform attributes = trans 1 [from RFC7296]¶

C-PE2 needs to advertise the following attributes for establishing IPsec SA:¶

Next Hop:

192.0.0.1¶

SD-WAN Node ID:

2.2.2.2¶

SD-WAN-Site-ID:

1500¶

Tunnel Encap Attr (Type=SD-WAN)

• Extended Port Attribute SubTLV¶

  • Transport SubSubTLV - with information on ISP3.¶

• IPsec SA Rekey Counter Sub-TLV,¶

• IPsec SA Public Key Sub-TLV,¶

• IPSec Proposal Sub-TLV with¶

  • transform type: ENCR¶

  • Transform ID = 1¶

  • Transform attributes = trans 2¶

As there is no matching transform between the WAN ports A2 and B2 in C-PE1 and C-PE2, respectively, no IPsec Tunnel will be established.¶