RFC 4303 - IP Encapsulating Security Payload (ESP)

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

Negative

what Ze owes

The 8 shares marked as a part above are the whole of the 23 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: IP Encapsulating Security Payload (RFC 4303): 1 MET (SPI 0/reserved never on the wire) + 1 single-polarity positive (32-packet anti-replay window projected) + 14 not-applicable (per-packet ESP datapath -- sequence, padding, TFC, SAD lookup, ICV, anti-replay check -- kernel XFRM)

What the public ledger says

Status: Partial

What the ledger says is covered:

Coverage

Positive and negative tests (7): RFC4303-1-1, RFC4303-2-1, RFC4303-2.1-1, RFC4303-2.1-2, RFC4303-3.2-1, RFC4303-3.4.3-2, RFC4303-2.2.1-2

Annotated (including scoped evidence) (16): RFC4303-1-2, RFC4303-2.2-1, RFC4303-2.2-2, RFC4303-2.2-3, RFC4303-2.4-1, RFC4303-2.6-1, RFC4303-2.6-2, RFC4303-3.3.3-1, RFC4303-3.3.4-1, RFC4303-3.3.4-2, RFC4303-3.4.3-1, RFC4303-3.4.3-3, RFC4303-3.4.2-1, RFC4303-3.4.2-2, RFC4303-3.4.4.1-1, RFC4303-3.4.4.2-1

Requirements

Gaps and untested MUSTs

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC4303-1-1

MUST be configurable via management interfaces. (§1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged after the R3 split: the row is now only the Section 1 clause 'MUST be configurable via management interfaces' (the IKE negotiation clause is the gap row RFC4303-1-2). Forbidden behaviour: the management interface refusing, or silently altering, an integrity-only ESP configuration. Positive: TestIPsecESPRequiresIntegrity drives esp + null cipher + sha256 through parseOSPFConfig/validateConfig and t.Fatalf on any refusal. Negative (R1(b), inputs pushed toward a refusal): TestRFC4303IntegrityOnlyESPIsConfigurable, for every integrity algorithm in ipsecAuthKeyLen x {cipher leaf omitted, explicit null}, validates and installs and asserts proto 50 (not AH), cipher null with no key, and the configured integrity algorithm and key length, so a validator requiring a cipher for ESP or accepting integrity-only for one algorithm only goes red. The old negative (null cipher with no integrity refused) proved RFC4303-3.2-1 and was removed from this row. Revert records on validateESPConfidentiality for both units observed red (positive recorded by this judge). Only the OSPFv3 manual-SA surface offers integrity-only ESP; IKE's absence is RFC4303-1-2.

RFC4303-1-2

Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols (§1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. First judgement. The Section 1 clause 'Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols' is unmet in Ze's IKEv2: the ESP encryption vocabulary (ike/ipsec/types.go encryptionNames, ParseEncryptionAlgo) has no null entry, so no configuration can propose ENCR_NULL, and resolveESPTransforms (engine/initiator.go) resolves only registered ciphers; TestRFC7296NegotiationRefusesNullIntegrityAndNullCipher shows the matcher refuses a peer's null proposal. Integrity-only ESP is offered only by manual OSPFv3 SA configuration (RFC4303-1-1). The {gap} annotation and the Support remaining text disclose it; the row quote is a verbatim span of Section 1, split from RFC4303-1-1 under R3 with a correction paragraph and an extraction unsourced-ids entry.

No test carries RFC4303-1-2, so no unit is bound to it.

RFC4303-2-1

The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). (§2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged (was weak: the IKE Child SA producer was untagged). Both producers Ze fills are now covered. OSPFv3 manual SAs: TestRFC4303ESPPacketOnTheWireCarriesProtocol50 (netns, IPv6 Next Header 50 captured on the wire), negative TestRFC4303IntegrityOnlyESPOnTheWireIsNotAH (null cipher + sha256, the AH-shaped input, still 50 on the wire), TestIPsecSAProtocolNumber; ipsecProtoNumber revert records observed red. IKE Child SA: TestRFC4301ChildSAIsInstalledAsESP (tag only, body unchanged, D-15) asserts Proto 50 on the inbound and the outbound SA createFirstChildSA installs; installChildSA is the one SAParams builder of the engine (callers: first Child SA and CREATE_CHILD_SA), revert record observed red. The IKE side is single-polarity by construction: protoESP is a constant and IKEv2 offers no input that selects another protocol, so the row's negative stays the OSPF one. The SAParams-to-kernel step (dataplane xfrmStateFromParams) is shared by both producers and proven on the wire by the OSPF probe; the VPP backend is asserted only at the SAParams boundary Ze owns.

RFC4303-2.1-1

The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (§2.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-10 against RFC 4303 S2.1 "The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire." after e2e724cf57 changed TestResponderRefusesPeerSPIZero: it now asserts no first Child SA, an IKE_AUTH response with no SA payload and a NO_PROPOSAL_CHOSEN refusal, and no longer the IKE SA state, which RFC 7296 S2.21.2 governs and this row does not. The SPI is still isolated (same re-encrypted request as TestResponderUsesPeerSPI, which pins outbound 0x0a0b0c0d), and removing both refusals (selectAuthChildSA, createFirstChildSA) builds a Child SA on SPI 0 and reddens it. Every other producer unchanged and proven both ways: own SPI TestGenerateESPSPISkipsTheReservedZero (three zero draws, spi != 0 mutant recorded); peer SPI initiator SAr2, rekey request and rekey response refuse 0 with no Child SA and no ESP state and install exactly 0x0a0b0c0d; OSPF TestIPsecSPIZeroRefused refuses spi 0 and accepts 4294967295 (mutant recorded). Caveats, not gaps: TestGenerateESPSPI cannot fail on its own, and TestIPsecSPIBoundary's 255/256 pair tests the IANA 1..255 reservation, a neighbouring rule.

RFC4303-2.1-2

The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. (§2.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged (was weak: the negotiation branch, the IKE Child SA, had no test). Manual-configuration branch unchanged: OSPFv3 TestRFC4303InboundESPSAKeyedOnConfiguredDestination plus the netns pair TestRFC4303InboundESPMapsByConfiguredDestination / TestRFC4303InboundESPToUnconfiguredDestinationMapsToNoSA, buildIPsecSA revert records observed red. Negotiation branch: positive TestRFC4303InboundChildSAKeyedOnNegotiatedSPIAndLocalAddress (the single inbound SA carries the negotiated ChildInboundSPI, proto 50 and Dst = the negotiated local address, so a Src/Dst swap goes red); negative TestRFC4303InboundESPToAnotherLocalAddressMapsToNoSA on real XFRM in a rootless netns (control to negotiated 10.250.0.1: delivered, XfrmInNoStates +0; same SPI and packet to 10.250.0.3: not delivered, XfrmInNoStates +1). Judge re-ran it once under -race: body ran in the child namespace and passed; judge mutation (negative packet aimed at the negotiated address) went red on the not-delivered assertion, so the negative is not vacuous. installChildSA revert records observed red for both. The indication itself (destination matched, source not) is XFRM's (daddr, spi, proto) state lookup keyed on what Ze negotiated, so both branches are proven for every role Ze fills; VPP backend inbound lookup is asserted only at the SAParams boundary.

RFC4303-2.2-1

For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. (§2.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-2.2-1, so no unit is bound to it.

RFC4303-2.2-2

In other words, the sender MUST NOT send a packet on an SA if doing so would cause the sequence number to cycle. (§3.3.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-2.2-2, so no unit is bound to it.

RFC4303-2.2-3

Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. (§2.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-2.2-3, so no unit is bound to it.

RFC4303-2.4-1

If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the size required by the algorithm. o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figures above, to ensure that the ICV field (if present) is aligned on a 4-byte boundary. Padding beyond that required for the algorithm or alignment reasons cited above could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the separate mechanism described below (see Section 2.7) should be used when TFC is required. The sender MAY add 0 to 255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, subject to the requirements noted above, but all implementations MUST support generation and consumption of padding. (§2.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-2.4-1, so no unit is bound to it.

RFC4303-2.6-1

the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet. A transmitter MUST be capable of generating dummy packets marked with this value in the next protocol field (§2.6)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-2.6-1, so no unit is bound to it.

RFC4303-2.6-2

a receiver MUST be prepared to discard such packets, without indicating an error. (§2.6)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-2.6-2, so no unit is bound to it.

RFC4303-3.2-1

Note that although both confidentiality and integrity are optional, at least one of these services MUST be selected, hence both algorithms MUST NOT be simultaneously NULL. (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged: TestIPsecESPRequiresIntegrity changed only by removing the RFC4303-1-1 negative comment; its assertions are unchanged. Forbidden behaviour: an ESP SA with both encryption and integrity NULL. Negative: validateConfig(esp, encryption-algorithm null, no integrity) must return ErrIPsecAuthAlgo, t.Fatalf otherwise. Positive: null cipher + sha256 accepted (exactly one service). The only producer that admits a NULL cipher is the OSPFv3 manual path; the IKE ESP vocabulary has no ENCR_NULL (ike/ipsec/types.go encryptionNames), so every IKE Child SA carries encryption. Both clauses are the same obligation and both are covered.

RFC4303-3.3.3-1

The sender's counter is initialized to 0 when an SA is established. The sender increments the sequence number (or ESN) counter for this SA and inserts the low-order 32 bits of the value into the Sequence Number field. Thus, the first packet sent using a given SA will contain a sequence number of 1. (§3.3.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.3.3-1, so no unit is bound to it.

RFC4303-3.3.4-1

Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). (§3.3.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.3.4-1, so no unit is bound to it.

RFC4303-3.3.4-2

In any case, an ESP implementation MUST support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. (§3.3.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.3.4-2, so no unit is bound to it.

RFC4303-3.4.3-1

A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed (§3.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour: Ze unable to run a receive window of at least 32 on a 32-bit-sequence SA (e.g. installing a smaller window). TestChildSAReplayWindowDefault (engine/child_test.go) asserts ReplayWin == 64 on both installed SAs; a window below 32 fails it. Ze never negotiates ESN, so every SA uses 32-bit sequence numbers. Single-polarity marker present. The assertion is at SAParams; xfrmStateFromParams projects it to the kernel (xfrm_linux.go:132).

RFC4303-3.4.3-2

This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. (§3.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged. {single-polarity} rightly dropped: the OSPFv3 producer has a refusal path. Positive: TestRFC4303ESPReplayWindowCarriesIntegrity installs replay-window 64 with null and aes128 ciphers and asserts every SA has ReplayWin 64, AuthAlgo sha256 and a 32-octet key; IKE: TestChildSAReplayRequiresIntegrity asserts every installed Child SA with ReplayWin > 0 is AEAD or carries AuthAlgo+AuthKey (non-AEAD proposals always resolve an integrity transform, resolveESPTransforms). Negative: TestRFC4303ESPReplayWindowWithoutIntegrityIsRefused, replay-window 64 with no integrity under no cipher, null and aes128, each refused ErrIPsecAuthAlgo by validateConfig, so anti-replay without integrity never reaches the installer. The refusal comes from the integrity-always-required check, which is exactly how Ze meets this MUST NOT; the input enables anti-replay without integrity, so it violates this requirement. Records: buildIPsecSA (positive) and validateIPsecInterface (negative) reverts observed red. Supplementary gap: the IKE negative (a non-AEAD proposal with no INTEG never installed) is structural, not tested.

RFC4303-3.4.3-3

The receive window is updated only if the integrity verification succeeds. (§3.4.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.4.3-3, so no unit is bound to it.

RFC4303-3.4.2-1

For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked, whether 32- or 64-bit sequence numbers are employed for the SA, and whether the (explicit) ICV field should be present (and if so, its size). Also, the SAD entry will specify the algorithms and keys to be employed for decryption and ICV computation (if applicable). If no valid Security Association exists for this packet, the receiver MUST discard the packet; this is an auditable event. (§3.4.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.4.2-1, so no unit is bound to it.

RFC4303-3.4.2-2

If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (§3.4.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.4.2-2, so no unit is bound to it.

RFC4303-3.4.4.1-1

If separate confidentiality and integrity algorithms are employed processing proceeds as follows: 1. If integrity has been selected, the receiver computes the ICV over the ESP packet minus the ICV, using the specified integrity algorithm and verifies that it is the same as the ICV carried in the packet. Details of the computation are provided below. If the computed and received ICVs match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the cleartext Flow ID. Implementation Note: Implementations can use any set of steps that results in the same result as the following set of steps. Begin by removing and saving the ICV field. Next check the overall length of the ESP packet minus the ICV field. If implicit padding is required, based on the block size of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field, or after the high-order 32 bits of the sequence number if ESN is selected. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. 2. The receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. As in Section 3.3.2, we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm (RFC 2410). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 3. The receiver processes any Padding as specified in the encryption algorithm specification. (§3.4.4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.4.4.1-1, so no unit is bound to it.

RFC4303-3.4.4.1-2

If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer. (§3.4.4.1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-11 by an independent judge after 3c3792805f rewrote the {gap}. RFC 4303 3.4.4.1: "If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer." Ze's Go performs no ESP decryption on either backend. Linux XFRM: xfrmStateFromParams builds the netlink XfrmState and carries no attribute asking for the Padding bytes to be checked. VPP: vppBackend.InstallSA writes an ipsec_sad_entry_v3 whose flags come from vppSAFlags (IS_INBOUND, IS_TUNNEL, IS_TUNNEL_V6, USE_ANTI_REPLAY, USE_ESN, UDP_ENCAP), and the vendored govpp ipsec_types vocabulary (NONE, USE_ESN, USE_ANTI_REPLAY, IS_TUNNEL, IS_TUNNEL_V6, UDP_ENCAP, IS_INBOUND, ASYNC) has no padding check to ask for. Nothing in the repository shows either layer inspecting the padding values, so the SHOULD is unmet. The annotation now names both backends and their producers, resolving the earlier defect. No test tags the row, which is correct for a {gap}.

No test carries RFC4303-3.4.4.1-2, so no unit is bound to it.

RFC4303-3.4.4.2-1

Decrypts and integrity checks the ESP Payload Data, Padding, Pad Length, and Next Header, using the key, algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. (§3.4.4.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC4303-3.4.4.2-1, so no unit is bound to it.

RFC4303-2.2.1-2

Use of an ESN MUST be negotiated by an SA management protocol. (§2.2.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour: keying an SA with ESN that the SA management protocol did not negotiate. Negative: TestEsnInitiatorRefusesAnESNValueItNeverOffered requires verifyAcceptedOffer to return errAcceptedOfferESN for an answer selecting ESN (and for two ESN values), t.Fatalf otherwise. Positive: the offered non-ESN value is accepted and the offer is pinned to the single value. Ze never offers ESN and manual OSPFv3 SAs set none, so no un-negotiated ESN path exists.

RFC4303-3.4.3-4

a window size of 64 is preferred and SHOULD be employed as the default (§3.4.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour (SHOULD): a default window other than 64. TestChildSAReplayWindowDefault asserts ReplayWin == 64 on both IKE Child SAs with no window configured; any other default goes red. Single-polarity marker present. The OSPFv3 manual path defaults to no anti-replay, which RFC 4303 Section 3.3.3 advises for manually keyed SAs, so the default-window sentence binds the IKE path.

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes RFC 4303, so its obligations are stated where they were written.