BGP UPDATE for SD-WAN Edge Discovery

3.2.1. SD-WAN Secure L3VPN Example Topology

This section summarizes how a BGP-based control plane, using the BGP Tunnel Encapsulation Attribute [RFC9012], can support three deployment scenarios described in [SD-WAN-BGP-USAGE]. These scenarios focus on different ways encrypted tunnels are used in SD-WAN service delivery. While Section 1.1 lists five BGP-specific control-plane requirements, the following list highlights service-level SD-WAN deployment models that BGP can support through tunnel advertisement and associated metadata.¶

• Homogeneous Encrypted 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 aligns with 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 C-PEs (customer premises equipment), as shown in Figure 2. Scenario 3 (Private VPNs based on SD-WAN) from [SD-WAN-BGP-USAGE] also corresponds to 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 appropriate traffic across the appropriate network based on local policy.¶

Hybrid SD-WAN Secure L3VPN:

Sample Topology¶

     BGP over Secure Transport  +---+  BGP over Secure Transport
                   +------------|RR |---------+
                  / BGP Peer    +-+-+ BGP Peer \
                 /                              \
                /                                \
        +---------+                              +-------+
 +---+  | C-PE1   |--P1--( MPLS L3VPN Net1 )--P1-| C-PE2 | +----+
 |CPN3|-|         |--P2--( MPLS L2VPN Net2 )--P2-|       |-|CPN3|
 +---+  |         |                              |       |
 +---+  |         |                              |       | +----+
 |CPN2|-| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CPN1|
 +---+  |         |--P4---(L2 direct path)----P4-|       | +----+
    |   +---------+                              +-------+    |
    \                                                         /
     \  +---------+                              +-------+  /
      +-|         |                              |       |-+
 +---+  | C-PE3   |--P1---( MPLS L3VPN Net1 )--P1| C-PE4 | +----+
 |CPN2|-|         |--P2---( MPLS L2VPN Net2 )--P2|       |-|CPN1|
 +---+  |         |                              |       | +----+
 +---+  |         |                              |       | +----+
 |CPN1|-| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CPN2|
 +---+  |         |--P4---(L2 direct path)----P4-|       | +----+
        +---------+                              +-------+
               \                                 /
                \                               /
                 \ BGP Peer    +-+-+ BGP Peer  /
                  +------------|RR |----------+
     BGP over Secure Transport +---+  BGP over Secure Transport

         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 |---------+
                  /          +--+-+          \
                 /                            \
          +------+                         +------+
   +----+ |      |-----SD-WAN hybrid-------|      | +----+
   |CPN3|-| C-PE1|                         | C-PE2|-|CPN3|
   +----+ |      |           /-------------|      | +----+
   +----+ |      |---\      /              |      | +----+
   |CPN2|-|      |    \   SD-WAN Hybrid    |      |-|CPN1|
   +----+ |      |     \ /                 |      | +----+
          +------+     /\                  +------+
                      /  \
          +------+   /    \                +------+
   +----+ |      |--/   SD-WAN Hybrid      |      | +----+
   |CPN2|-| C-PE3|          \------------- | C-PE4|-|CPN1|
   +---+  |      |                         |      | +---+
   +----+ |      |                         |      | +----+
   |CPN1|-|      |                         |      |-|CPN2|
   +----+ |      |-----SD-WAN hybrid-------|      | +----+
          +------+                         +------+
               \                                /
                \                              /
                 \ BGP Peer  +-+--+ BGP Peer  /
                  +----------| RR |----------+
                             +----+

        Note:
        - SD-WAN Hybrid: SD-WAN Hybrid Tunnel

        - For diagram clarity, the RR is shown as two separate nodes to illustrate its connectivity to all C-PEs. In practice, there may be only one RR. All BGP sessions to the RR are established over secure transport connections.

        - The same CN depicted as connected to multiple C-PEs is to illustrate a multihoming scenario, where a single customer network maintains multiple connections to the SD-WAN fabric via different C-PEs.

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

3.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 Transport  +---+  BGP over Secure Transport
                   +------------|RR |---------+
                  / BGP Peer    +-+-+ BGP Peer \
                 /                              \
                /                                \
        +--------+                              +-------+
 +---+  | C-PE1  |--P1--( WAN L3 Net1)-------P1-| C-PE2 | +----+
 |CPN3|-|        |--P2--( L3 Direct Path)----P2-|       |-|CPN3|
 +---+  |        |                              |       |
 +---+  |        |                              |       | +----+
 |CPN2|-| Addr   |--P3 --( WAN L3 Net3)------P3-|       |-|CPN1|
 +---+  |        |--P4---(L2 direct Path)----P4-|       | +----+
    |   +--------+                              +-------+    |
    \                                                        /
     \  +---------+                              +-------+  /
      +-|         |                              |       |-+
 +---+  | C-PE3   |--P1--( WAN L3 Net1 )------P1-| C-PE4 | +----+
 |CPN2|-|         |--P2--( L3 Direct Path )---P2-|       |-|CPN1|
 +---+  |         |                              |       | +----+
 +---+  |         |                              |       | +----+
 |CPN1|-| Addr    |--P3 --( WAN L3 Net3)------P3-|       |-|CPN2|
 +---+  |         |--P4---(L2 direct Path)----P4-|       | +----+
        +---------+                              +-------+
               \                                 /
                \                               /
                 \ BGP Peer    +-+-+ BGP Peer  /
                  +------------|RR |----------+
     BGP over Secure Transport +---+  BGP over Secure Transport

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

3.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 RR via Secure Transport Connection. For an SD-WAN deployment with multiple RRs, it is assumed that there are Secure Transport Connection among those RRs.¶

How Secure Transport 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.¶

In some environments where the control plane communication to the RR is already secured using mechanisms such as those discussed in [RFC7018], IKE-less IPsec can be deployed to simplify data-plane IPsec-SA establishment among edge nodes..¶

4.2.1. The 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 octets
+------------------+
|     Length       | 2 octets
+------------------+
|   Type Specific  |
~ Value (Variable) ~
|                  |
+------------------+

where:¶

Route (NLRI) Type:

2 octet value to define the encoding of the rest of the SD-WAN the NLRI.¶

Length:

2 octets indicating the length of the Value field, expressed in bits, following the NLRI encoding convention defined in [RFC4760], Section 3.¶

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

NLRI Route Type = 1 (SD-WAN Tunnel Endpoint NLRI):

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 octets
     +------------------+
     |     Length       | 2 octets
     +------------------+
     |   Port-Local-ID  | 4 octets
     +------------------+
     |   SD-WAN-Color   | 4 octets
     +------------------+
     |  SD-WAN-Node-ID  | 4 or 16 octets
     +------------------+

Length:

The value of the Length field for Route-Type 1 MUST be either 12 octets (when the SD-WAN-Node-ID is an IPv4 address) or 24 octets (when the SD-WAN-Node-ID is an IPv6 address). Any other value is invalid, and the NLRI MUST be treated as malformed and discarded.¶

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:

identifies a group of SD-WAN tunnels that may span multiple SD-WAN edges co-located at the same site. This value correlates with the Color Extended Community attached to client routes. The receiving BGP speaker selects SD-WAN tunnels whose SD-WAN-Color matches the Color Extended Community in the client route when determining which underlay tunnel(s) to use. If the SD-WAN-Color represents all tunnels at a site, it effectively serves as a site-level identifier. If no matching SD-WAN-Color is found, the client route may not be forwarded over any SD-WAN tunnels.¶

SD-WAN Node ID:

This field carries the IPv4 or IPv6 address of the SD-WAN edge node (C-PE). For IPv4 SD-WAN NLRI (AFI/SAFI 1/74), this field contains a 4-octet IPv4 address representing a /32 host address. For IPv6 SD-WAN NLRI (AFI/SAFI 2/74), this field contains a 16-octet IPv6 address representing a /128 host address. The SD-WAN Node ID identifies the loopback address used by the SD-WAN edge node to advertise its tunnel attributes.¶

4.2.2. Validation of SD-WAN NLRI

Upon receiving an SD-WAN NLRI Route-Type 1, the following validation steps MUST be performed:¶

The Length field MUST contain a value of either 12 or 24 octets, as defined in Section 4.2.1. Any other value renders the NLRI malformed and it MUST be discarded.¶

If Length = 12, the SD-WAN Node-ID field MUST contain exactly 4 octets, representing an IPv4 address. If Length = 24, the SD-WAN Node-ID field MUST contain exactly 16 octets, representing an IPv6 address.¶

The SD-WAN Node-ID MUST be a valid unicast address.¶

Implementations MAY apply additional local policy checks (e.g., verifying whether the advertising BGP speaker is authorized to advertise SD-WAN NLRIs), but these are outside the scope of NLRI field validation itself.¶

If the local policy check fails, the NLRI SHOULD be discarded without affecting the BGP session.¶

4.2.3. BGP Path Attributes attached to SD-WAN NLRI

The Path Attributes attached to the SD-WAN NLRIs apply to the WAN-facing tunnel endpoints being advertised, not to client routes. These attributes describe properties of the WAN ports (e.g., encapsulation, transport role, or color) that may be used in establishing SD-WAN overlay tunnels between edge nodes. Client routes, which represent customer prefixes, are propagated using separate BGP NLRIs (e.g., IPv4/IPv6 unicast or L3VPN), with their own associated Path Attributes. The SD-WAN NLRI and client route NLRI are independent but may be correlated by the receiving BGP speaker for tunnel selection and service mapping.¶

4.3.1. IPsec-SA-ID Sub-TLV

The IPsec-SA-ID Sub-TLV is used to reference one or more previously established IPsec-SAs between SD-WAN nodes. This Sub-TLV carries one or more 32-bit Security Parameter Index (SPI) values assigned at the receiving node (i.e., the inbound SPI). When combined with the SD-WAN Node-ID (which identifies the tunnel endpoint address), each SPI uniquely identifies an existing IPsec-SA, consistent with the SA identification described in [RFC4301], Section 4.1.¶

Multiple SPIs MAY be included within the Sub-TLV to reference multiple pre-established IPsec-SAs available for the SD-WAN overlay. This enables advertisement of SA updates, key rotations, or operational state changes without resending full SA parameter sets, thereby significantly reducing the size of BGP UPDATE messages and allowing pairwise IPsec rekeying to proceed independently for each SA.¶

Sub-TLV Name:

IPsec-SA-ID¶

Sub-TLV Code:

64 (IANA assigned)¶

Sub-TLV 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 SPIs, each 4 octets long. As shown in the figure above, n IPsec-SAs are attached in the IPsec-SA-ID sub-TLV:¶

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

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

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

Sub-TLV Error Handling:

The Length field of the IPsec-SA-ID Sub-TLV MUST be a non-zero multiple of 4 octets. Any other value is considered a malformed Sub-TLV. Error handling for malformed Sub-TLVs follows [RFC9012]¶

4.3.2. IPsec-SA Rekey Counter Sub-TLV

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

Sub-TLV Name:

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

Sub-TLV Code:

67 (IANA assigned)¶

Sub-TLV Encoding:

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

where:¶

• SA-ReKeyCounter (IPsec-SA Rekey Counter) 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 18 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 (SA-SPI). This length SHOULD be 4 octets.¶

• Nonce Length (16 bits): indicates the length, in octets, of the Nonce Data. The value MUST be a non-zero multiple of 4 (i.e., the Nonce Data length MUST be a multiple of 32 bits)[RFC7296].¶

• 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): dentifies the SPI assigned to a specific IPsec-SA terminated at the SD-WAN edge node. The length of this field is specified in ID Length. For this specification, the length MUST be 4 octets. Other lengths are outside the scope of this document.¶

• Nonce Data: a random or pseudo-random number for preventing replay attacks.¶

Sub-TLV Error Handling:

The IPsec-SA Rekey Counter Sub-TLV is considered malformed under any of the following conditions:¶

The total Sub-TLV Length is less than the sum of ID Length, Nonce Length, and 4 octets for the Rekey Counter.¶

The ID Length field does not match the actual length of the ID field.¶

The Nonce Length field is zero or not a multiple of 4.¶

Malformed Sub-TLVs are handled according to [RFC9012]; they MUST be ignored and skipped during parsing.¶

4.3.3. IPsec Public Key Sub-TLV

The IPsec Public Key Sub-TLV provides the Public Key exchange information and the life span for the Diffie-Hellman Key. The encoding is 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-PublicKey|   Length      |  Reserved                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Diffie-Hellman Group Num    |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                       Key Exchange Data                       ~
       |                                                               |
       +---------------------------------------------------------------+
       |                            Duration                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

• IPSec-PublicKey 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 10 + 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.¶

An IPsec Public Key Sub-TLV is considered malformed if any of its fields do not conform to the encoding rules specified above. Malformed Sub-TLVs are handled according to [RFC9012] and MUST be ignored.¶

4.3.4. IPsec-SA Proposal Sub-TLV

The IPsec-SA Proposal Sub-TLV is used to advertise a set of cryptographic parameters that define the proposal for establishing an IPsec-SA. A proposal consists of one or more transform types, where each transform specifies a particular cryptographic function (such as encryption or integrity) and the corresponding algorithm to be used. This structure follows the same model as IKEv2 Proposals defined in [RFC7296] Section 3.3.¶

Sub-TLV Name:

IPsec-SA Proposal - Indicates IPsec Transform Attributes¶

Sub-TLV Code:

69 (IANA assigned)¶

Each transform includes:¶

-

A Transform Type, which identifies the function being specified (e.g., encryption, integrity).¶

-

A Transform ID, which specifies the algorithm for that function.¶

-

Optional Transform Attributes, which provide additional algorithm-specific parameters when necessary.¶

The encoding is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SA-Proposal  |   Length      |       Reserved (16 bits)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Transform Attr Length      |Transform Type |    Reserved.  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Transform ID              |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Transform Attributes                   ~
|                                                               |
+---------------------------------------------------------------+

where:¶

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

length (8 bits): Total length of the value field in octets (not including Type and Length fields). This equals 10 + the Transform attribute length.¶

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

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

Transform Type (8 bits): The function being specified. Transform Type values are defined in [RFC7296] Section 3.3.2 and IANA IKEv2 Transform Type registry. Valid types include ENCR (1), PRF (2), INTEG (3), DH (4), and ESN (5).¶

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

Transform ID (16 bits): Identifies the algorithm for the corresponding Transform Type, as defined in [RFC7296] Section 3.3.2.¶

Transform Attributes: Optional algorithm-specific parameters, encoded as defined in [RFC7296] Section 3.3.5.¶

The Transform Attributes field may be omitted if no additional parameters are required for the selected algorithm.¶

Multiple IPsec-SA Proposal Sub-TLVs MAY be included to describe multiple transform types for the same SA proposal. Collectively, these Sub-TLVs define the full proposal for an IPsec-SA between SD-WAN edge nodes.¶

Sub-TLV Error Handling:

An IPsec-SA Proposal Sub-TLV is considered malformed if:¶

-

The Length field does not match the actual length of the Value field.¶

-

The Transform Attribute Length field is inconsistent with the total Sub-TLV Length.¶

-

Any field value falls outside its valid range as specified in [RFC7296].¶

Malformed Sub-TLVs MUST be handled according to [RFC9012] and ignored during parsing. Additional content checks for the IPsec-SA Proposal Sub-TLV are described in Section 4.4 (for client routes) and Section 4.5 (for underlay routes).¶

4.3.5. Simplified IPsec-SA Sub-TLV

The Simplified IPsec-SA Sub-TLV provides a compact way to signal pre-configured IPsec-SA parameters for deployments where full transform negotiation (e.g., via IKEv2) is not supported or not necessary. In such deployments, SD-WAN edge nodes are provisioned (e.g., via SD-WAN controller or management system) with a common set of agreed security profiles, including allowed transforms and algorithms. This Sub-TLV signals which profile entry is to be used for a given SA instance.¶

Sub-TLV Name:

Simplified IPsec-SA¶

Sub-TLV Code:

70 (IANA assigned)¶

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

where:¶

Length (8 bits):

variable in octets (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 invalid unless specified by future specifications.¶

IPsec Mode (8 bits):

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

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

Only Mode values 1 and 2 are valid in this document. All other Mode values are considered invalid unless specified by future specifications.¶

AH algorithms (8 bits):

Specifies the AH authentication algorithm to be used. The values are defined in [RFC4305] and its updates (e.g., [RFC8221]). While an SD-WAN edge node may be capable of supporting multiple AH algorithms, this field carries only a single algorithm value for the specific SA instance. The selection of which algorithms are supported across peers is determined via SD-WAN controller provisioning or management policy. No in-band negotiation of multiple algorithms is performed using this field.¶

ESP algorithms (8 bits):

Specifies the ESP encryption algorithm, as defined in [RFC4305], [RFC8221], and their updates. Like AH Algorithm, only a single algorithm value is carried per SA instance, with acceptable algorithms coordinated by provisioning or policy.¶

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¶

nonce-length (8 bits):

indicates the Nonce key length¶

Nonce:

IPsec Nonce¶

Duration (32 bits):

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

A Simplified IPsec-SA Sub-TLV is considered MALFORMED if any of its fields are not properly encoded, do not conform to the specified value ranges above, or contain invalid field lengths. Per [RFC9012], any MALFORMED Sub-TLV MUST be ignored, and processing continues with the remaining Sub-TLVs in the TEA.¶

4.3.6. Extended Port Attribute Sub-TLV

The Extended Port Attribute Sub-TLV advertises NAT-related properties associated with a public Internet-facing WAN port on an SD-WAN edge node. This information enables peer SD-WAN nodes to establish secure tunnels even when one or both peers are behind NAT devices. An SD-WAN edge node may query a STUN server (Session Traversal Utilities for NAT [RFC8489]) to determine its NAT properties, including its public IP address and public port number. These properties are then advertised to peer nodes using the Extended Port Attribute Sub-TLV.¶

In SD-WAN deployments, NAT devices may exist at one or both ends of the tunnel path. The possible deployment scenarios include:¶

• Only one SD-WAN edge node is located behind a NAT device, while its peer is directly reachable.¶

• Both SD-WAN edge nodes are behind NAT devices (symmetric or independent NATs).¶

• The external address and port assigned to an edge node may change dynamically, either due to ISP address allocation or when traversing NAT devices that use dynamic address pools.¶

Because an SD-WAN edge node may have multiple WAN ports with independent NAT characteristics, the NAT properties are associated with individual WAN ports and are advertised independently for each port using this Sub-TLV. This per-port advertisement allows remote peers to construct appropriate NAT traversal parameters for each potential tunnel endpoint.¶

Unlike pairwise NAT traversal mechanisms such as IKEv2 [RFC7296], which require peers to dynamically discover NAT properties during tunnel setup, the BGP-controlled SD-WAN architecture enables each SD-WAN edge node to proactively advertise its NAT properties to all peers through BGP signaling. This approach simplifies NAT traversal in large-scale SD-WAN deployments where each edge node may need to establish tunnels with many peers.¶

Sub-TLV Name:

Extended Port Attribute¶

Sub-TLV Code:

65 (IANA assigned)¶

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

• ExtPort Length: the length of the value field in octets excluding the Type and the Length fields. If IPv4, the length is 32 (8 header, 32 address, 8 for 1 SubSub-TLV). If IPv6, the length is 64 (8 header, 48 addresses, 8 for 1 subSubTLV).¶

• Flags (16 bits):¶

  • I bit (C-PE 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 (8 bites): an unsigned integer indicating the NAT behavior observed for this WAN port. The values are derived from the legacy NAT classification model described in RFC 3489 Section 5. The assigned values are:¶

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

  The NAT Type value is determined by the sender using NAT discovery procedures (e.g., STUN [RFC8489] with legacy tests [RFC3489]) or local administrative configuration. The receiver is not required to verify NAT behavior but MUST validate that the received NAT Type field is within the range 1-7. Values outside this range are considered invalid and result in the Sub-TLV being treated as malformed.¶

• Encap-Type(8 bits): An unsigned integer indicating the encapsulation type supported for this WAN port. This field is distinct from the Tunnel Type field in the BGP Tunnel Encapsulation Attribute [RFC9012]. The encapsulation types defined by this document are:¶

  • Encap-Type=1: GRE;¶

  • Encap-Type=2: VxLAN;¶

  Notes:¶

  • Other values are reserved for future specifications. The Encap-Type identifies the encapsulation protocol used within the IPsec payload when IPsec-SA Sub-TLVs (IPsec-SA-ID, IPsec-SA Nonce, IPsec Public Key, IPsec-SA Proposal, or Simplified IPsec-SA) are present in the SD-WAN Hybrid Tunnel.¶

  • The Extended Port Attribute Sub-TLV does not support NAT traversal scenarios involving IPv4/IPv6 translation (e.g., NAT64 or 6to4).¶

• Trans NetworkID (Transport Network ID) (8 bits): An identifier assigned by the SD-WAN Controller to indicate the transport network that this WAN port belongs to. All values from 0 to 255 are valid.¶

• RD ID: The Routing Domain ID is a globally unique identifier assigned to the routing domain associated with this WAN port. All values from 0 to 255 are valid.¶

  • Some SD-WAN deployments may define multiple levels, zones, or regions that are represented as logical domains. Operational policies may govern whether tunnels are allowed between nodes in different logical domains. For example, a hub node may be permitted to establish tunnels across domains, while spoke nodes may be restricted to communicating only within their own domain. The definition, distribution, and enforcement of such policies are outside the scope of this document.¶

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

• If NAT is not used for the WAN port, both the Public IP and Public Port fields MUST be set to zero. If one field is set to zero and the other is non-zero, the Sub-TLV is considered malformed.¶

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

If the Extended Port Attribute Sub-TLV is malformed (e.g., incorrect length, invalid address format, or unrecognized NAT type), it MUST be ignored per the procedures described in [RFC9012]. Other Sub-TLVs in the same Tunnel Encapsulation Attribute, if valid, MUST still be processed.¶

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | UnderlayType  |      Length   |      Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Connection Type|   Port Type   |        Port Speed             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.1. SD-WAN Hybrid Tunnel Type in Encapsulation Extended Community

When client routes are advertised using the Encapsulation Extended Community (Encap-EC) with the SD-WAN Hybrid Tunnel Type, as specified in [RFC9012], the Encap-EC identifies the tunnel type, and the NextHop field in the BGP UPDATE serves as the Tunnel Egress Endpoint. Validation of the Tunnel Egress Endpoint follows the procedures defined in Sections 6, 8, and 13 of [RFC9012], as applied to the NextHop.¶

The Color Extended Community (Color-EC) is used to associate a client route with its eligible underlay tunnels. The Color value in the client route identifies the set of underlay tunnels, previously advertised with the same Color via SD-WAN SAFI, that may be used to transport the traffic. This enables SD-WAN ingress nodes or controllers to apply path selection policies based on performance, cost, or service requirements.¶

In this approach, if a required underlay tunnel is unavailable, the associated route MUST NOT be installed in the forwarding table or used to forward traffic. The route MAY still exist in the BGP control plane but MUST be marked as unusable for forwarding until a valid secure tunnel is established.¶

4.4.2. SD-WAN Hybrid Type in Tunnel Attributes via TEA

When client routes are advertised using the Tunnel Encapsulation Attribute (TEA) with the SD-WAN Hybrid Tunnel Type, the following procedures apply for validating the BGP UPDATE message:¶

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

A well-formed SD-WAN Hybrid Tunnel TLV MUST include a Tunnel Egress Endpoint Sub-TLV if the hybrid tunnel terminates at a specific WAN port. If the tunnel is intended to terminate at the SD-WAN node level, the Tunnel Egress Endpoint Sub-TLV MAY be omitted. 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 Sub-TLVs:¶

• the Color Sub-TLV defined in [RFC9012],¶

• IPsec-SA-ID,¶

• IPsec-SA Rekey Counter,¶

• IPsec Public Key,¶

• IPSec SA Proposal, or¶

• Simplified IPsec-SA¶

A MALFORMED Sub-TLV is ignored in the Tunnel TLV is ignored.¶

Sub-TLV with an unknown type is ignored.¶

2. Check for multiple instances of Sub-TLVs:

As specified in [RFC9012], only the first instance of a Sub-TLV is processed; subsequent ones are ignored.¶

A SD-WAN Hybrid 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 Sub-TLV 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 Next Hop:

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

4.4.3. Client Routes Carried Over Multiple Hybrid SD-WAN Tunnels

When a client route is advertised with the Encapsulation Extended Community (Encap-EC) that identifies the Hybrid SD-WAN Tunnel Type, the route may also include a Color Extended Community (Color-EC). This combination allows the route to be carried over multiple underlay tunnels that were previously advertised, each with the same Color value.¶

The Color-EC serves as a correlation mechanism: all underlay tunnels that have been advertised (via SD-WAN SAFI) with the same Color value are considered eligible to carry the traffic for the client route. This approach supports flexible path selection and tunnel diversity while avoiding the need to enumerate each tunnel per route.¶

This model is especially useful when:¶

• A site has multiple available IPsec tunnels or WAN links.¶

• A centralized controller or ingress SD-WAN edge node must select the optimal tunnel for forwarding based on performance, policy, or service constraints.¶

The tunnel attributes, including IPsec parameters, NAT traversal info, and WAN port properties, are conveyed separately via SD-WAN SAFI updates. This keeps client route updates minimal, allowing multiple routes to reference the same tunnel attributes by using the Color-EC.¶

4.4.4. SD-WAN VPN ID in Control Plane

In a BGP-controlled SD-WAN network, the VPN ID distinguishes client VPNs and ensures route separation. It is conveyed in client route UPDATEs as follows:¶

• For IPv4/IPv6 Unicast (AFI/SAFI = 1/1 or 2/1), the Route Target Extended Community SHOULD be included. The Route Target value is interpreted as the VPN ID. The Route Target is especially necessary when the SD-WAN edge node serves multiple VPNs on its client-facing interfaces. If all client routes belong to a single VPN and the association is unambiguous, the Route Target MAY be omitted.¶

• For VPN-IPv4/VPN-IPv6 (AFI/SAFI = 1/128 or 2/128), the RD in the NLRI serves as the VPN ID.¶

4.4.5. SD-WAN VPN ID in Data Plane

In the data plane, SD-WAN traffic can traverse either an MPLS or IPsec segment within a Hybrid SD-WAN tunnel. The method for conveying the VPN ID depends on the encapsulation:¶

• MPLS Segments: When the Hybrid tunnel uses MPLS transport, the MPLS label stack is used to identify the VPN per [RFC8277]. Security is assumed to be provided by the MPLS transport.¶

• IPsec Segments: When traversing a public network with IPsec encryption: For GRE encapsulation within IPsec, the GRE Key field can carry the SD-WAN VPN ID; For VXLAN network virtualization overlays within IPsec, the VNI (Virtual Network Identifier) field is used to carry the VPN ID.¶

4.5.1. Underlay Route with a TEA

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 Sub-TLVs valid for association with the underlay Route.¶

A well-formed SD-WAN Hybrid Tunnel TLV includes tunnel attributes associated with a specific SD-WAN edge node, identified by the SD-WAN Node ID. The presence of the Tunnel Egress Endpoint sub-TLV indicates that the tunnel terminates at a specific WAN port on the SD-WAN node. If this sub-TLV is absent, the tunnel is considered to terminate at the node level, allowing any of the node's WAN ports to be used.¶

The Hybrid SD-WAN NLRI MUST NOT be accompanied by an Encapsulation Extended Community.¶

The SD-WAN Hybrid Tunnel TLV may contain the following sub-TLVs: Tunnel Egress Endpoint, IPsec-SA-ID, IPsec-SA Rekey Counter, IPsec Public Key, IPsec-SA Proposal, Simplified IPsec-SA, and Extended Port Attribute.¶

Following [RFC9012] intent, a MALFORMED Sub-TLV is ignored, and a sub-TLV with an unknown type is ignored.¶

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

As specified in [RFC9012], only the first instance of a Sub-TLV is processed; subsequent ones are ignored. The IPsec-SA-ID sub-TLVs MAY have multiple instances of the sub-TLV if the IPsec-SA Identifiers are unique, but if the IPsec-SA Identifiers are not unique the second sub-TLV is ignored and not propagated. If multiple Extended Port Sub-TLVs 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 Attribute Sub-TLV(s)

As described in Section 4.3.6, each Extended Port Attribute sub-TLV describes the properties of a single WAN port. Therefore, multiple Extended Port sub-TLVs may be present when the SD-WAN edge node has multiple WAN ports. Each sub-TLV MUST be validated to ensure that the port information it contains is sufficient to support the establishment of a tunnel to the remote peer. If any Extended Port Attribute Sub-TLV is determined to be invalid, the entire SD-WAN Hybrid Tunnel TLV MUST be considered invalid.¶

5. Validate each NLRI

Each typed NLRI in the SD-WAN Underlay MUST be well-formed, meaning it conforms to the structure defined in Section 4.2.1, including correct field lengths and ordering. A MALFORMED NLRI MUST be discarded; implementations MAY log an error. For well-formed NLRIs, the route's acceptance MUST be determined by local policy, based on the contents (e.g., Node ID, Color).¶

6. Validate Next Hop

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

4.5.2. Underlay Routes with Port-Local-ID of Zero

As specified in Section 4.2.1, a Route Type 1 NLRI includes the tuple (Port-Local-ID, SD-WAN-Color, SD-WAN-Node-ID). The Port-Local-ID field MAY be set to zero to indicate that the NLRI applies to all WAN ports on the identified SD-WAN node, effectively representing tunnel attributes at the node level rather than a specific port.¶

When Port-Local-ID = 0, the receiving BGP speaker SHOULD apply local policy to determine how to associate client routes with underlay tunnels. This local policy may prefer tunnels from specific SD-WAN nodes, or choose among SD-WAN Colors based on administrative preference, link type, path performance, or service-level objectives. The exact selection logic is implementation-specific.¶

It is valid for multiple such node-level NLRIs to be received, each advertising different SD-WAN Colors for the same node. For example, the following three NLRIs may be received (within one or more UPDATE messages):¶

• 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 indicate that node 2.2.2.2 supports multiple tunnel groups, each classified by a different SD-WAN Color. For example, these Colors may correspond to service tiers such as gold, silver, and bronze. The SD-WAN-Color field is used to correlate underlay tunnels with client routes that carry a matching Color Extended Community. If no match is found, the client route may not be forwarded over any SD-WAN tunnel.¶

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

4.6.1. Error handling for the Tunnel Encapsulation Signaling

The error handling for the tunnel encapsulation signaling (Encapsulation Extended Community and TEA) in this document follows the procedures specified in [RFC9012], Sections 6, 8, and 13. Unless otherwise stated, malformed or unrecognized Sub-TLVs MUST be handled as specified in [RFC9012]. This document defines new Sub-TLVs for Tunnel Type 25 (SD-WAN-Hybrid), but does not alter the validation behavior established in RFC 9012.¶

The Tunnel encapsulation signaled with the client routes indicates the Egress endpoint via Next Hop in the Encapsulation Extended Community or the TEA Sub-TLV 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 associate some of the NLRIs that [RFC9012] associates with the Encapsulation Extended Community 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 Sub-TLVs 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 treated if the TLV was not present.¶

• A malformed sub-TLVs MUST be handled per [RFC9012] Section 13. If Tunnel Egress Endpoint is malformed, the entire TLV MUST be ignored. For security-sensitive attributes, such as those related to IPsec-SA setup, malformed or invalid values MUST be discarded and MUST NOT be used in security association processing. The BGP UPDATE containing such attributes SHOULD still be processed if other attributes remain valid. Implementations SHOULD log the error for operational awareness and MAY trigger a session reset or rekeying if required by local policy. Unlike general BGP attributes, failure to process security-related information correctly could lead to misconfigurations or weakened security.¶

• Multiple incidents of Tunnel Egress Endpoint Sub-TLV cause the first incident of these sub-TLVs to be utilized. Subsequent TLVs after the first one per type are ignored (per RFC9012), but propagated.¶

• If a sub-TLV is meaningless for a tunnel type, the sub-TLV is ignored, but the sub-TLV 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 Sub-TLVs (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 sub-TLV is treated as an unrecognized sub-TLV.¶

For SD-WAN NLRI underlay routes, the Extended Port sub-TLV and the IPSec sub-TLVs (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 SubSub-TLVs within the TLVs SHOULD cause the sub-TLV to be treated as malformed sub-TLV. Per [RFC9012], a malformed sub-TLV is treated as an unrecognized sub-TLV.¶

If multiple instances 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 sub-TLV MUST be different than any in the first IPsec-SA ID sub-TLV.¶

If multiple instances of the Extended Port sub-TLV are received, the local policy MUST determine which is to be used.¶

4.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 the reception of a 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 carefully constrain the SD-WAN-NLRI, tunnels, and IPsec security associations 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.¶

4.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 an Encapsulation Extended Community. If an SD-WAN NLRI is paried with an Encapsulation Extended Community rather than a Tunnel Encapsulation Attribute, the SD-WAN NLRI is considered malformed and the Treat-as-withdraw approach (per [RFC7606]) SHOULD be used.¶

5.2.1. Example creation of IPsec-SA over SD-WAN Hybrid tunnel

This section provides an example of how IPsec-SA is established over an SD-WAN Hybrid tunnel. Figure 1 in Section 4 illustrates an IPsec tunnel being created between port P2 (192.168.1.10) on C-PE1 and port P2 (192.168.2.1) on C-PE2.¶

To establish this tunnel, C-PE1 must advertise the following attributes required for setting up the IPsec-SA:¶

• NextHop: 192.168.1.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 SubSub-TLV - with information on ISP.¶

  • IPSec information for detailed information about the ISP¶

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

SD-WAN Node ID:

2.2.2.2¶

SD-WAN-Site-ID:

1500¶

Tunnel Encap Attr (Type=SD-WAN)

• Extended Port Attribute Sub-TLV¶

  • Transport SubSub-TLV - with information on ISP.¶

• 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 P2 and P2 in C-PE1 and C-PE2, respectively, no IPsec Tunnel will be established.¶