ipsec

Pre-Alpha. This page describes behavior that may change.

Ze implements native IKEv2 in Go for route-based IPsec VPN tunnels. No strongSwan, no libreswan, no external IKE daemon. The IKE engine, the cryptographic primitives, the wire codec, and the XFRM dataplane integration are all in-tree. The result is a single binary that negotiates IKE SAs, installs XFRM policies and states, and programs routes through XFRM interfaces, all driven from the same YANG config tree as every other Ze subsystem.

Architecture

The IPsec stack is split across several packages:

Package	Role
`internal/component/ike/wire`	IKEv2 wire format codec (RFC 7296). Encodes and decodes all payload types.
`internal/component/ike/crypto`	Cryptographic primitives: DH groups, PRF, integrity, encryption, key derivation.
`internal/component/ike/transport`	UDP transport with NAT-T (RFC 3948) keepalives, port 4500 encapsulation.
`internal/component/ike/eap`	EAP authentication: EAP-MSCHAPv2, EAP-TLS.
`internal/component/ike/engine`	IKE FSM: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, INFORMATIONAL. Initiator and responder roles, rekeying, DPD.
`internal/component/ike/ipsec`	Config, YANG schema, validation.
`internal/component/ike/dataplane`	XFRM policy and state programming via netlink.
`internal/component/pki`	PKI certificate store for X.509 certificates and private keys.

Configuration

IPsec is configured under vpn { ipsec { } }. Named ike-group and esp-group blocks hold the IKE and ESP proposals and lifetimes; each site-to-site peer references a group pair, sets its authentication, and binds to a VTI (XFRM) interface for route-based forwarding.

pki {
    certificate my-cert {
        certificate-file /etc/ze/certs/router.pem;
        private-key-file /etc/ze/certs/router-key.pem;
    }
    ca-certificate my-ca {
        certificate-file /etc/ze/certs/ca.pem;
    }
}

vpn {
    ipsec {
        interface eth0;

        ike-group site-b-ike {
            key-exchange ikev2;
            lifetime     28800;
            proposal 1 {
                encryption aes256gcm;
                hash       sha256;
                dh-group   14;
            }
            dead-peer-detection { interval 30; timeout 120; }
        }

        esp-group site-b-esp {
            lifetime 3600;
            pfs      enable;
            proposal 1 { encryption aes256gcm; }
        }

        site-to-site {
            peer site-b {
                ike-group       site-b-ike;
                esp-group       site-b-esp;
                connection-type initiate;
                local-address   198.51.100.2;
                remote-address  198.51.100.1;
                authentication {
                    mode           x509;
                    certificate    my-cert;
                    ca-certificate my-ca;
                }
                vti { bind vti0; }
            }
        }
    }
}

Traffic selectors are not listed per tunnel: route-based IPsec sends whatever the routing table forwards through the bound VTI (see Interfaces: XFRM).

IKE features

Feature	Detail
IKEv2 (RFC 7296)	Full IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, INFORMATIONAL exchange support.
Role	Initiator or responder, per peer (`connection-type initiate` / `respond`). See IKEv2 responder role below.
Proposals	AES-CBC, AES-GCM (128/256), ChaCha20-Poly1305. DH groups: MODP 2048/3072/4096/8192, ECP 256/384/521. PRF: SHA-256/384/512.
Authentication	Pre-shared key, X.509 certificates, EAP-MSCHAPv2, EAP-TLS. As responder, Ze is the EAP authenticator (EAP-MSCHAPv2 / EAP-TLS server).
NAT-T (RFC 3948)	Automatic NAT detection, UDP encapsulation on port 4500, keepalive.
DPD	Dead Peer Detection via INFORMATIONAL exchange. Configurable interval and timeout.
Rekeying	Real CREATE_CHILD_SA rekeying of both the IKE SA and the Child SAs, make-before-break. Collision handling. See Rekeying below.
Identity checks	`remote-id` is enforced against the asserted identity and against the peer certificate. `remote-id-type` pins one identity type. See Remote identity below.
Certificates	Chain bounded by `certificate-count` (default 4), intermediates sent in order, and an optional bounded Hash-and-URL fetch.
Traffic selectors	A `traffic-selector` list per peer, narrowed per RFC 7296 Section 2.9. See Traffic selectors below.
Transport mode	`mode transport` negotiates USE_TRANSPORT_MODE. Tunnel mode is the default.
Denial of service	COOKIE challenge before a half-open slot is committed, and the INVALID_KE_PAYLOAD group retry. See Denial-of-service protection below.
Dataplane read-back	`show vpn ipsec dataplane` reads the kernel SAD and SPD, and a drift check compares them against what the engine believes.
MOBIKE (RFC 4555)	Not implemented; an endpoint address change requires the SA to be re-established.
Virtual IP pool	Not wired. The `remote-access` container parses, and no session reads it, so a `pool` assigns no address and an `eap-user` list authenticates nobody.

IKEv2 responder role

Ze can act as the IKEv2 responder as well as the initiator. A peer with connection-type respond waits for an unsolicited inbound IKE_SA_INIT from its configured remote-address, answers IKE_AUTH, and installs the first Child SA. (connection-type initiate, the default, is the original behavior.) The UDP transport always listens, so there is no separate listen switch: responder behavior is selected by connection-type respond plus a matching remote address.

As responder Ze authenticates with pre-shared key, X.509 certificate, or EAP. For EAP it is the EAP authenticator (the EAP-MSCHAPv2 or EAP-TLS server) for a road-warrior client: it presents its own certificate or PSK first, then runs the EAP method and derives the session keys from the EAP MSK.

vpn {
    ipsec {
        interface eth0;
        ike-group IKE-PSK {
            key-exchange ikev2;
            proposal 1 { encryption aes256gcm; hash sha256; dh-group 14; }
        }
        esp-group ESP-PSK {
            pfs enable;
            proposal 1 { encryption aes256gcm; }
        }
        site-to-site {
            peer swan {
                ike-group       IKE-PSK;
                esp-group       ESP-PSK;
                connection-type respond;
                local-address   172.28.0.2;
                remote-address  172.28.0.3;
                authentication {
                    mode              pre-shared-secret;
                    local-id          "172.28.0.2";
                    remote-id         "172.28.0.3";
                    pre-shared-secret "$9$encoded";
                }
            }
        }
    }
}

For a road-warrior EAP server, set authentication { mode eap-mschapv2 } (or eap-tls) and reference a device certificate and ca-certificate from the PKI store. Configure the client as a site-to-site peer.

The remote-access container is not wired. It parses, and no session reads it, so a pool assigns no address and an eap-user list authenticates nobody.

Replacing a stale SA

A new inbound IKE_SA_INIT is allowed to proceed while an older established SA for the same peer is still being maintained. Once the replacement authenticates, its INITIAL_CONTACT notification tells the remote endpoint to discard the stale SA. A responder therefore recovers straight after an operator clear or a peer restart instead of waiting out Dead Peer Detection.

clear vpn ipsec sa sends a best-effort encrypted IKE Delete before dropping local state, so initiator peers re-establish immediately. If that UDP Delete is lost, the ordinary DPD path still removes the stale remote SA.

Authentication

Every EAP mode and X.509 needs a trust anchor

ca-certificate is mandatory for x509 and for every EAP mode, and the daemon refuses a remote certificate it cannot chain to that anchor. A certificate with no trust anchor authenticates nobody: any self-signed certificate carrying a valid signature would pass. RFC 7296 Section 2.16 requires EAP to run with a public-key authentication of the responder, and the anchor is what makes that signature attributable. An EAP mode also needs a certificate, because the responder signs its AUTH with it.

ca-certificate holds one anchor, not a path. A two-level authority therefore needs the peer to send its intermediates. RFC 7296 Section 3.6 puts the peer certificate first, and Ze reads every later CERT payload as a link toward the anchor. Ze sends its own chain the same way: the certificate entry first, then the intermediates that PKI entry carries, in order.

Ze refuses a config that names no ca-certificate at commit and at reload. It does NOT refuse it under ze config validate, which reads the schema and does not run a plugin's config verifier.

The EAP peer path-validates the authenticator's chain against that trust anchor, as RFC 5216 Section 5.3 requires. EAP-TLS carries no server hostname, so the chain is validated without DNS-name matching.

EAP-TLS with TLS 1.3

RFC 9190 Section 2.5 requires an EAP-TLS 1.3 server to send an encrypted TLS record carrying application data 0x00 once it has processed the client Finished and sent its last handshake message. That record is the protected success result indication, and Ze sends it in the flight that round already carries. Without it strongSwan derives no MSK, the AUTH payload of RFC 7296 Section 2.16 cannot be computed, and the SA never establishes. A TLS 1.2 exchange concludes with the bare EAP-Success it used before.

Ze issues no TLS session ticket, so EAP-TLS session resumption is not available. Each EAP session builds its own TLS configuration, and a ticket minted under one could never be redeemed under another.

Remote identity

remote-id is the identity Ze expects the remote endpoint to assert. When it is set, Ze enforces it twice: once against the IDi or IDr payload the peer sent, and once against the remote certificate in the certificate modes. The second check is what matters when one authority issues to several clients. The chain proves the authority issued the certificate. It does not prove the certificate speaks for this peer.

A subject alternative name binds. The subject common name binds only when the certificate carries no alternative name extension at all. An address remote-id binds against the address alternative names alone, never against a domain name that spells the same address.

Ze compares six identity types: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_KEY_ID, and ID_DER_ASN1_DN. remote-id-type pins ONE of them for the peer. Without it a text remote-id accepts ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID alike, because all three compare as text. Set remote-id-type key-id to accept an opaque key id, which matches no certificate field and is denied by default.

An unset remote-id runs neither check. Every certificate the configured authority issued then authenticates as this peer. Ze logs a warning naming the peer and the identity it accepted. Set remote-id whenever the authority issues to more than one client.

Certificate chains and Hash-and-URL

certificate-count bounds the X.509 chain in both directions: the most certificates Ze sends, and the most it accepts. RFC 7296 Section 3.6 sets that figure at four, and so does the default. A peer that sends more is REFUSED rather than truncated, because a silent trim hides that the limit was reached.

hash-and-url replaces the certificate on the wire with a 20-octet SHA-1 hash and a URL that resolves to it, which keeps IKE messages short. certificate-url is where you publish this device's certificate.

The leaf defaults to false, and that default is a security property. Resolving a URL a peer sends makes an outbound request on behalf of a peer that is not yet authenticated. With the leaf false Ze advertises nothing, a conforming peer sends no such payload, and Ze drops one from a peer that sends it anyway.

Control	Bound
Scheme	`http` only; every other scheme is refused before any name resolution
Response size	64 KiB
Total timeout	5 seconds
Redirects	None. A redirect is refused
Destination	Loopback, private, link-local, multicast, and metadata addresses are denied
Hash	The SHA-1 is verified BEFORE any parser reads the fetched bytes
Cache	Keyed by the hash, never by the URL

Use certificate-url-allow to permit a destination the deny list refuses. Run ze doctor to check a configured certificate-url.

Pre-shared secret encoding

pre-shared-secret-encoding reads the secret as ascii, the default, or as hex. RFC 7296 Section 2.15 requires the management interface to accept both. Use hex for a secret that holds non-printable octets.

The encoding is stated and never guessed from the value. A secret such as abcdef0123456789 is valid ASCII and valid hex, so a daemon that read the value to decide would silently reinterpret a deployed secret. A hex value with an odd length or a non-hexadecimal character is refused at commit. The at-rest $9$ obfuscation is unwrapped first, so a hex secret can also be stored obfuscated.

Denial-of-service protection

RFC 7296 Section 2.6 names two attacks on an IKE responder: state exhaustion and CPU exhaustion from initiation requests with forged source addresses. The answer is a COOKIE. Ze answers an inbound IKE_SA_INIT with a COOKIE notification and commits no state, and the initiator must repeat its request with that cookie as the first payload before Ze creates an SA or takes the peer's half-open handshake slot.

vpn {
    ipsec {
        cookie-threshold 0;
    }
}

cookie-threshold sets how many half-open IKE SAs Ze tolerates before it challenges. It defaults to 0, which challenges every inbound initiation. That default costs a genuine peer one extra round trip and closes a real availability hole: a responder peer has one half-open slot, held for 30 seconds, so a single spoofed datagram bearing that peer's source address would otherwise deny it service.

The cookie is an HMAC-SHA256 over the initiator's nonce, its source address, and its SPI, under a secret Ze rotates every 60 seconds. A cookie minted under the previous secret stays valid for one further interval, so a rotation never breaks an in-flight handshake. A cookie that does not match is ignored rather than rejected, as the RFC requires.

Diffie-Hellman group correction

An initiator has to guess which Diffie-Hellman group the responder will pick. When the guess is wrong the responder answers INVALID_KE_PAYLOAD naming the group it accepts, and Ze retries the IKE_SA_INIT under that group.

The retry re-offers the whole configured proposal set rather than narrowing it to the suite carrying the responder's group. RFC 7296 Section 1.2 requires that, because the rejection is unauthenticated and a narrowed re-offer would let an attacker who forges one notify choose the cipher. Ze also refuses a group it never proposed. Both the COOKIE and the INVALID_KE_PAYLOAD retry share one budget of three per connection attempt, so two peers can never oscillate between them.

Rekeying

Both the Child SAs and the IKE SA are rekeyed with a real on-the-wire CREATE_CHILD_SA exchange (RFC 7296), replacing an earlier local-only key roll that could silently desync a live tunnel. A Child SA rekey carries N(REKEY_SA) with fresh nonces and traffic selectors; an IKE SA rekey performs a fresh Diffie-Hellman exchange (the peer supplies its key-exchange payload) and resets the message-ID counters.

Rekeying is make-before-break: the replacement SA is installed before the old one is deleted, so forwarding never pauses. Simultaneous rekeys are resolved by the RFC 7296 nonce rule (the lower nonce wins) so both ends converge on one SA. Ze rekeys on the ESP or IKE soft-lifetime and retransmits a lost CREATE_CHILD_SA before tearing the tunnel down. Rekeys are counted by ze_ipsec_rekey_total{peer} (both Child SA and IKE SA rekeys) and streamed as child-rekey on monitor vpn ipsec.

Child SA and dataplane

Child SAs define the traffic selectors and the ESP proposal. Ze programs XFRM policies and states via netlink. Route-based IPsec uses XFRM interfaces (see Interfaces: XFRM).

Feature	Detail
ESP proposals	AES-GCM-16 (128/256), AES-CBC + HMAC-SHA-256/384/512.
Traffic selectors	IPv4 and IPv6 CIDR prefixes, an optional IP protocol, and an optional single port.
Encapsulation	Tunnel mode by default; `mode transport` negotiates transport mode (RFC 7296 Section 1.3.1).
Connection	Per peer: `connection-type initiate` starts the exchange, `connection-type respond` waits for the peer (see IKEv2 responder role).
Replay protection	Anti-replay window (default 32).
Lifetime	Time-based and byte-based rekeying thresholds.

Traffic selectors and narrowing

A peer's traffic-selector list states which traffic its Child SAs carry. It is also the policy RFC 7296 Section 2.9 narrows a peer's proposal against.

vpn { ipsec { site-to-site { peer branch-1 {
    traffic-selector 1 {
        local  { prefix 10.1.0.0/16; }
        remote { prefix 10.2.0.0/16; }
    }
    traffic-selector 2 {
        protocol 6
        local  { prefix 10.3.0.0/24; port 179; }
        remote { prefix 10.4.0.0/24; }
    }
} } } }

When the list is absent the peer accepts whatever the remote endpoint proposes. That is the behavior of every configuration written before the list existed, so adding the list is what restricts a peer, never omitting it.

As responder, Ze narrows the initiator's proposed TSi and TSr to a subset the list allows, and leads the answer with the initiator's first choices. A proposal it cannot narrow to a non-empty subset draws TS_UNACCEPTABLE. As initiator, Ze proposes the list in order, because RFC 7296 reads the order as the preference order.

The selectors Ze puts on the wire are the selectors it programs. A proposal it cannot program exactly is narrowed FURTHER, never rounded outward: an address range that is not a prefix becomes the largest prefix inside it, and a port range that is neither all ports nor one port becomes its first port. A rekey is never narrowed below the scope in use.

Port value	Meaning	RFC 7296 Section 3.13.1 encoding
`any` (the default)	every port	start 0, end 65535
`1`..`65535`	one port	start N, end N

A port other than any needs protocol to name a protocol that defines ports, such as 6 for TCP or 17 for UDP. Section 3.13.1 requires the port fields to be 0 and 65535 whenever the protocol is 0, so the combination is refused at commit rather than widened silently. Opaque ports are refused for the same reason: no dataplane backend can express an exact match on port 0.

Transport mode

mode transport asks the peer for transport mode with the USE_TRANSPORT_MODE notification of RFC 7296 Section 1.3.1. Tunnel mode is the default, and it is the RFC's own default.

vpn { ipsec { site-to-site { peer host-1 {
    mode transport
    transport-required true
    traffic-selector 1 {
        local  { prefix 10.0.0.3/32; }
        remote { prefix 10.0.0.4/32; }
    }
} } } }

Transport mode constrains the selectors. RFC 7296 Section 2.23.1 requires exactly one IP address in TSi and in TSr, so every prefix must be a single host, and a vti binding is refused because an XFRM interface carries tunnel encapsulation. Several selectors are still allowed when they share that one address, for example to negotiate several ports.

A peer that declines the request establishes the Child SA in tunnel mode. Set transport-required true when that downgrade is unacceptable: Ze then deletes the SA instead, which is what Section 1.3.1 asks of an initiator. It defaults to false, so a peer without transport mode keeps a working tunnel.

Both ESP wire forms

RFC 7296 Section 2.23 requires a device that supports NAT traversal to receive UDP-encapsulated ESP and bare ESP at any time. One Linux XFRM state serves one form: a state that carries the encapsulation template refuses bare ESP, and a state without one refuses encapsulated ESP.

Ze serves the second form beside the kernel. A raw IPPROTO_ESP reader takes the datagram XFRM refused and re-presents it through port 4500, which carries UDP_ENCAP, so the kernel hands XFRM the form its template wants. One established Child SA therefore keeps carrying traffic when its peer changes ESP form mid-session, with no rekey and no delete. The reader carries a per-socket inbound policy exemption, because Linux applies the inbound IPsec policy check before it queues a packet to a raw socket. XFRM still decrypts, still owns the replay window, and still applies the policy to the re-presented datagram.

The second-form reader serves IPv4. The form Ze SENDS is a separate decision and follows the NAT verdict alone.

Reading the kernel dataplane

Every other IPsec command reports what the IKE engine believes it installed. The show vpn ipsec dataplane commands read the kernel instead, so a state the kernel refused, a state it expired, and a policy that outlived its owner all become visible.

Command	What it reads
`show vpn ipsec dataplane sa [spi <spi>]`	The Security Association Database: SPI, addresses, if-id, mode, algorithms, replay window, byte and packet counters, and timestamps. SPI 0 is refused, because RFC 4303 Section 2.1 reserves it.
`show vpn ipsec dataplane policy`	The Security Policy Database: selector prefixes and ports, direction, priority, upper-layer protocol, if-id, tunnel endpoints, and the peer that installed each policy. A policy Ze did not install reports its owner as unknown.
`show vpn ipsec dataplane drift`	Each Child SA the engine counts as installed whose SPI the kernel does not hold. The command exits non-zero on drift, so a script can test it.

A read that cannot happen is an error, never an empty table. No backend loaded, a backend that cannot enumerate, and a process without CAP_NET_ADMIN each get their own message. An empty table answers "is my tunnel programmed?" with "no", and that is wrong when the truth is that nobody asked the kernel.

Drift is compared in ONE direction. An SPI the kernel holds that the engine does not name is not drift: RFC 7296 Section 2.8 keeps the old and the new Child SA alive together until the old one is deleted, so a rekey window holds two SPIs.

show vpn ipsec sa and show vpn ipsec peer name <name> carry the kernel counters in each child SA object: bytes-in, packets-in, bytes-out, and packets-out. They come from the kernel because the IKE engine never sees ESP payload. Each is null rather than zero when the SAD could not be read, and counters-known says which answer you hold.

The health registry folds the same comparison in: a peer whose Child SA the kernel does not hold reports degraded and names the peer. ze doctor adds doctor-ipsec-xfrm-unavailable, a warning raised when vpn ipsec is configured and the kernel XFRM dataplane does not answer, which is a kernel without CONFIG_XFRM_USER or a process without CAP_NET_ADMIN.

Dataplane backends

XFRM is the default backend and the production path. A VPP backend exists behind the ze_vpp build tag and programs a real VPP through the generated binapi, but it cannot be driven by IKE and no configuration selects it. It installs security associations and refuses every security policy the IKE engine produces for them, because a VPP policy lives in a security policy database bound to interfaces and nothing tells the backend which interface to use. It also implements no transport mode, and refuses such an install rather than programming a tunnel-mode entry and reporting success.

PKI certificate store

The pki { } block stores X.509 certificates, private keys, and CA certificates. Certificates are loaded from PEM files and validated at commit time. The PKI store also serves TLS certificates for the web UI and the gRPC API.

Health monitoring reports certificate expiry as warnings (30 days) and errors (expired). Prometheus metrics: ze_pki_certificate_expiry_seconds, ze_pki_certificate_valid.

XFRM interfaces

XFRM interfaces provide route-based IPsec. Traffic routed through the XFRM interface is encrypted; traffic arriving on it is decrypted. See Interfaces: XFRM for the config surface.

CLI

Command	Description
`show vpn ipsec status`	Tunnel and peer status summary.
`show vpn ipsec sa`	Active IKE and Child SAs: algorithms, kernel byte and packet counters, rekey timers, SPIs, NAT detection, `is-initiator` (initiator vs responder role), and `peer-window-size`.
`show vpn ipsec peer name <name>`	Detail for one configured peer.
`show vpn ipsec dataplane sa [spi <spi>]`	The SAs the kernel holds. See Reading the kernel dataplane.
`show vpn ipsec dataplane policy`	The policies the kernel holds.
`show vpn ipsec dataplane drift`	Child SAs the engine expects that the kernel does not hold. Exits non-zero on drift.
`clear vpn ipsec sa [peer <name>]`	Tear down and re-establish SAs, optionally for one peer.
`monitor vpn ipsec`	Stream SA and child lifecycle events (`sa-up`, `sa-down`, `child-up`, `child-down`, `child-rekey`).
`show pki certificates`	List loaded certificates with expiry.

peer-window-size is the number of outstanding requests the peer promised in its SET_WINDOW_SIZE notification. Zero means the peer sent none, which RFC 7296 Section 2.3 reads as a window of one. Ze holds one request outstanding and accepts exactly one request id.

Health and metrics

The IPsec component registers with the health registry. It reports healthy when all configured tunnels are established, degraded when some are down or when the kernel does not hold a Child SA the engine expects, and down when critical tunnels fail.

Metric	What it reports
`ze_ipsec_sa_count`	Active IKE SAs.
`ze_ipsec_tunnel_up{peer}`	1 only when the IKE SA is established AND the Child SA is installed in the dataplane.
`ze_ipsec_tunnel_degraded{peer}`	1 for a tunnel with a live control plane whose ESP install the kernel refused. Alert on this one: with `tunnel_up` it separates a lost session from a session with no ESP.
`ze_ipsec_rekey_total{peer}`	Child SA and IKE SA rekeys.
`ze_ipsec_cookie_challenges_total{peer}`	COOKIE challenges Ze issued.
`ze_ipsec_cookie_verify_failures_total{peer}`	Inbound cookies that did not verify. A rising count is an attacker probing the half-open slot, or a secret rotation catching an in-flight challenge.
`ze_ipsec_sa_init_retries_total{peer,cause}`	IKE_SA_INIT retries Ze sent, labeled `cookie` or `invalid-ke-payload`.
`ze_ipsec_error_notify_sent_total{type,protected}`	Error notifications sent, by notify type and by whether the carrying message was encrypted.
`ze_ipsec_error_notify_suppressed_total{reason}`	Error notifications a guard stopped, by the name of the guard.

Interop testing

The IKE implementation includes interop tests against strongSwan, from the Alpine 3.21 test image. The infrastructure lives in test/ipsec-interop/ and drives Docker containers running strongSwan as the remote IKE peer. Sixteen scenarios run today:

Area	Scenarios
Authentication	PSK, EAP-MSCHAPv2, EAP-TLS, and EAP-TLS over TLS 1.3.
Ze as responder	PSK, EAP-MSCHAPv2, EAP-TLS over TLS 1.3, IKE SA rekey started by strongSwan, and a fresh IKE_SA_INIT accepted beside an established SA.
Rekey and teardown	Child SA rekey with make-before-break, `clear vpn ipsec sa` and re-establishment, and a Delete sent while the one request window is held.
Negotiation	The INVALID_KE_PAYLOAD retry and the COOKIE challenge.
Dataplane	A live Child SA whose peer changes ESP form mid-session, and BGP routes exchanged with FRR over the tunnel.

There is no certificate-only (mode x509) scenario. The certificate paths are proven by unit tests and by the EAP-TLS scenarios, which authenticate both ends with certificates.

RFC 7296 conformance

Ze holds every gated MUST-level requirement extracted from RFC 7296 in rfc/short/rfc7296.md: 222 of the summary's 227 rows, each implemented and proven in both directions by RFC requirement: tagged tests. The remaining five rows are SHOULD-level and ungated. See RFC Implementation for what that proof means and what it does not.

Uh oh!

ipsec

Architecture

Configuration

IKE features

IKEv2 responder role

Replacing a stale SA

Authentication

Every EAP mode and X.509 needs a trust anchor

EAP-TLS with TLS 1.3

Remote identity

Certificate chains and Hash-and-URL

Pre-shared secret encoding

Denial-of-service protection

Diffie-Hellman group correction

Rekeying

Child SA and dataplane

Traffic selectors and narrowing

Transport mode

Both ESP wire forms

Reading the kernel dataplane

Dataplane backends

PKI certificate store

XFRM interfaces

CLI

Health and metrics

Interop testing

RFC 7296 conformance

See also

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!