[Idr] Is there any issue of using the ID of a pre-established IPsec SA in the BGP UDPATE for SDWAN Edge nodes instead of detailed IPsec SA attributes ?

[Linda Dunbar <[e-mail]>]

IDR experts:

https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/ proposes using two separate BGP UPDATE messages for SDWAN Edge Discovery:


  *   UPDATE U1 for advertising the attached client routes,
This UPDATE is exactly the same as the BGP edge client route UDPDATE. It  uses the Encapsulation Extended Community and the Color Extended Community to link with the Underlay Tunnels UPDATE Message.


  *   UPDATE U2 advertises the properties of the various tunnels, including IPsec, terminated at the edge node.

Since there are many parameters associated with an IPsec SA, IPsec SA identifiers are used in the Tunnel Encap Path Attribute, instead  of listing all the detailed attributes of the IPsec SA.

The following is the structure of the IPsec-SA-ID sub-TLV:
 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= IPsec-SA-ID subTLV      |  Length (2 Octets)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #2                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If the client traffic needs to be encapsulated in a specific type within the IPsec ESP Tunnel, such as GRE or VxLAN, etc., the corresponding Tunnel-Encap Sub-TLV needs to be prepend right before the IPsec-SA-ID Sub-TLV.

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

Do people see any issues of this proposed encoding?

Thank you very much.
Linda Dunbar