<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-xu-idr-bgp-sec-sync-00" ipr="trust200902">
  <front>
    <title abbrev="BGP Sec Sync">BGP Extension for Secure Session State
    Synchronization</title>

    <author fullname="Haijun Xu" initials="H." surname="Xu">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>xuhaijun@huawei.com</email>
      </address>
    </author>

    <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhuangshunwan@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Haibo Wang" initials="H." surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>

    <date day="5" month="July" year="2026"/>

    <abstract>
      <t>This document defines a new BGP Address Family, termed the Secure
      Session Synchronization Address Family, allowing BGP speakers to
      exchange stateful firewall, NAT, and IPSec session information across
      distributed nodes. This architecture facilitates zero-packet-loss
      failover and seamless path protection for Secure SD-WAN, SASE, and SSE
      multi-POP deployments, entirely bypassing the scalability limits of
      traditional layer-2 synchronization protocols. </t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Modern Secure SD-WAN and Secure Access Service Edge (SASE/SSE)
      architectures rely heavily on dynamic, stateful packet inspection
      deployed on edge Customer Premises Equipment (CPE) and distributed Cloud
      Points of Presence (POPs). When link failures or node outages trigger a
      data-plane switchover, traffic is rerouted to an alternate gateway node.
      </t>

      <t>However, traditional routing protocols only synchronize Layer 3
      reachability. The underlying stateful security contexts&mdash;such as
      TCP sequence numbers, NAT translation bindings, and IPSec anti-replay
      windows&mdash;are lost during the transition. This mismatch forces edge
      clients to re-establish hundreds of thousands of concurrent active
      sessions, leading to substantial packet drops, broken flows, and severe
      application degradation. </t>

      <t>Existing state synchronization mechanisms (e.g., dedicated single-hop
      sync links) are bounded by proprietary protocols and cannot scale across
      multi-hop wide area networks (WANs) or mesh topologies. </t>

      <t>This document leverages BGP's proven database scalability by
      introducing a novel Address Family dedicated to carrying session states
      as control-plane attributes. Using BGP Route Reflectors (RRs) and Route
      Target (RT) filtering constraints, session states can be selectively and
      efficiently broadcasted to eligible backup peers, enabling hitless
      stateful cross-POP/site failovers. </t>

      <t/>
    </section>

    <section title="Protocol Extensions: AFI and SAFI Definitions">
      <t> To transport secure session states without interfering with existing
      unicast routing structures, this document requests a new Address Family
      Identifier (AFI) and Subsequent Address Family Identifier (SAFI) from
      IANA: </t>

      <t><list style="symbols">
          <t>AFI: Secure Session Space (TBD1) </t>

          <t>SAFI: Session State Synchronization (TBD2) </t>
        </list></t>

      <t>BGP speakers MUST negotiate Capability Advertisements <xref
      target="RFC5492"/> for AFI=TBD1 / SAFI=TBD2 during the BGP session
      initialization phase.</t>
    </section>

    <section title="The Secure Session NLRI Format">
      <t>The Secure Session Network Layer Reachability Information (NLRI) is
      carried inside BGP UPDATE messages using MP_REACH_NLRI and
      MP_UNREACH_NLRI attributes [RFC4760]. The unique "key" that identifies a
      discrete network session is structured within the NLRI as follows: </t>

      <t><figure>
          <artwork align="left"><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Length (2 octets)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Route Distinguisher                       |
   |                          (8 octets)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   IP Version  |   Protocol    |           Reserved            |
   | (1=IPv4,2=IPv6|  (TCP, UDP)   |            0x00               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Port        |        Destination Port       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source IP Address                       |
   |                    (4 octets or 16 octets)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination IP Address                     |
   |                    (4 octets or 16 octets)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure></t>

      <t/>

      <t><list style="symbols">
          <t>Route Distinguisher (RD): An 8-octet identifier used to isolate
          overlapping IP spaces belonging to distinct VRFs or enterprise
          tenants sharing the same multi-tenant SASE fabric. </t>

          <t>Protocol: Matches the IP packet header protocol field (e.g., 6
          for TCP, 17 for UDP). </t>

          <t>Source / Destination IPs and Ports: Defines the strict 5-tuple
          identifying the communication flow. </t>
        </list></t>

      <t/>

      <t/>
    </section>

    <section title="Session State Path Attributes (TLV Structure)">
      <t>Dynamic session parameters that fluctuate over time MUST NOT be
      encoded inside the static NLRI key. Instead, they MUST be advertised via
      a new optional, non-transitive BGP attribute named the **Secure Session
      Attribute**. This attribute is composed of individual TLVs: </t>

      <t/>

      <section title="TCP State TLV (Type 1)">
        <t/>

        <t><list style="symbols">
            <t>Type: 1 </t>

            <t>Length: 8 octets </t>

            <t>Value: Contains the localized TCP state engine classification
            (e.g., 0x03 for ESTABLISHED) along with synchronized forward and
            reverse TCP Sequence and Acknowledgment Numbers. </t>
          </list></t>

        <t/>
      </section>

      <section title=" NAT Binding TLV (Type 2)">
        <t/>

        <t><list style="symbols">
            <t>Type: 2 </t>

            <t>Length: Variable (Depends on IPv4/IPv6) </t>

            <t>Value: Carries the Post-NAT translated Source IP and translated
            Source Port. This ensures that a backup CPE or POP can maintain
            identical NAT bindings for the tenant upon hot-standby takeover.
            </t>
          </list></t>

        <t/>
      </section>

      <section title="Session Expiry TLV (Type 3)">
        <t/>

        <t><list style="symbols">
            <t>Type: 3 </t>

            <t>Length: 4 octets </t>

            <t>Value: A 32-bit integer indicating the remaining lifetime of
            the session in seconds. </t>
          </list></t>

        <t/>
      </section>
    </section>

    <section title="Operational Procedures &amp; Flood Dampening Mechanics">
      <t> Because data-plane session allocations happen at scales multiple
      orders of magnitude higher than standard infrastructure routing updates,
      implementations MUST strictly comply with the following control-plane
      dampening rules to maintain BGP process stability: </t>

      <section title=" State-Driven Triggering Window">
        <t/>

        <t><list style="symbols">
            <t>A BGP speaker MUST NOT generate a BGP UPDATE message for every
            individual TCP packet or state transition (e.g., handshaking
            phase). </t>

            <t>The generation of an MP_REACH_NLRI for a TCP session MUST be
            deferred until the local security engine verifies the session has
            successfully entered the `ESTABLISHED` state. </t>
          </list></t>
      </section>

      <section title="Batching and Coalescing Regimes">
        <t/>

        <t><list style="symbols">
            <t>BGP speakers running this address family MUST implement a
            mandatory coalescing timer (suggested default: 200 milliseconds).
            </t>

            <t>Newly established sessions captured within this window MUST be
            aggregated and transmitted in bulk within a single BGP UPDATE
            message, effectively dampening packet processing stress on the BGP
            peer. </t>
          </list></t>

        <t/>
      </section>

      <section title="Session Teardown and Graceful Withdrawal">
        <t/>

        <t><list style="symbols">
            <t>When an active session naturally times out or intercepts an
            explicit teardown sequence (TCP FIN or RST), the originating node
            MUST queue an MP_UNREACH_NLRI to withdraw the session key from the
            network. </t>

            <t>Backup nodes receiving this withdrawal MUST purge the matching
            entry from their shadow forwarding tables. </t>
          </list></t>

        <t/>
      </section>
    </section>

    <section title="Security Considerations">
      <t>Transporting exact firewall session tables over BGP means that if an
      unauthorized entity eavesdrops on the control-plane data, they gain
      access to the entire active topology and session matrix of the network.
      Therefore, sessions utilizing this address family MUST enforce
      transport-layer encryption mechanisms such as TLS <xref
      target="RFC8205"/> or IPsec protection for the BGP peering sessions.
      </t>

      <t/>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests IANA to allocate an AFI value of TBD1 for the
      "Secure Session Space" and a SAFI value of TBD2 for "Session State
      Synchronization". </t>

      <t/>
    </section>

    <section title="Contributors ">
      <t>The following people made significant contributions to this
      document:</t>

      <t><figure>
          <artwork align="left"><![CDATA[To be added.

]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge the review and inputs from
      xxx.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.4271'?>

      <?rfc include='reference.RFC.4456'?>

      <?rfc include='reference.RFC.4760'?>

      <?rfc include='reference.RFC.5492'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8205'?>
    </references>

    <references title="Informative References"/>
  </back>
</rfc>
