IPsec Channels: Connection Latching
Extracted elements (30)
Certificates and raw public keys are too large to store in kernel-mode implementations. Peer IDs should be interned in a user-mode database using small integer references from the kernel SAD/LD; corruption of this database MUST cause all ESTABLISHED and BROKEN latches to be administratively closed.
Connection latching is layered atop IPsec and does not modify the underlying IPsec architecture; the feature that allows concurrent SAs with overlapping traffic selectors remains, and it is up to transport protocols and applications to decide whether and how to respond to conflicts.
SAs protecting an IPsec channel may change over time through expiration and re-keying, as long as replacement SAs remain congruent to the latched parameters. This design allows IPsec channels to survive SA expiration so that key exchange operational considerations do not affect the connection latching feature.
The RECOMMENDED default disposition for a BROKEN latch is connection reset (rather than waiting), because a conflicting SA most likely indicates that the original peer is gone and replaced by another; waiting for recovery that is unlikely to occur would unnecessarily delay application failure detection.
Two models of connection latching are defined: a normative ULP-to-key-manager interface model and an informative local packet-tagging model. The normative model was chosen because it accommodates hardware ESP/AH offload NICs that do not support packet tagging, while the packet-tagging model more naturally supports connectionless datagram transports.
Connection latching is not negotiated between peers, so one end may use it while the other does not. If the non-latched end sends data unprotected due to a local policy change, the latched end will reject the packets but sensitive data may already have been exposed.
For SCTP multi-homed associations, connection latching may be represented as N×M connection latches (one per 5-tuple of end-point address combinations) or as a single latch object with multiple addresses per end-point. Implementors may choose either approach.
Non-native IPsec implementations (BITS, BITW, SG) can implement connection latching by inferring ULP connection state from packet inspection, but they cannot provide APIs and thus are not suitable for channel binding applications. When a latch is broken, a BITS/SG implementation may need to send fake TCP RST packets.
Child SA proposals conflicting with an extant latch whose traffic selectors can be narrowed SHOULD be narrowed; where narrowing is impossible, the key manager MUST break the connection latch and inform the ULP prior to accepting the conflicting SAs.
If an IPsec channel is desired, packets for a given connection MUST NOT be sent and inbound packets MUST NOT be accepted until the channel is established; inbound packets arriving before channel establishment must be dropped or channel establishment must fail.
Implementations MUST provide a default disposition for latch breaks. The document RECOMMENDs acting as connection reset (option b) for TCP and single-path SCTP, and ICMP destination unreachable (option c) for multi-homed SCTP; implementations SHOULD also provide APIs for applications to choose or be notified of dispositions.
Implementations with a restartable key management process MUST arrange for existing latched connections to either be broken and disconnected or to survive the restart. If latch state is kept in a restartable process, it must be restored on restart or outstanding latches transitioned to CLOSED.
Once an IPsec channel is established, packets for the latched connection MUST NOT be sent unprotected or protected by a non-matching SA, and such inbound packets must be dropped or cause channel termination before data can be delivered to the application.
The key manager MUST prevent conflicts amongst latches and between any latch and existing or proposed child SAs. Non-listener connection latches MUST NOT be created if conflicting SAs exist in the SAD at the time of creation.
The key manager MUST protect latched connections against SPD changes that would alter the quality of protection or bypass a latched connection's traffic. The REQUIRED behavior is to transition conflicting latches to BROKEN; an OPTIONAL behavior is to insert a logical PROTECT SPD entry for the latch's exact 5-tuple (which MUST NOT survive reboots).
The parameters latched in an IPsec channel MUST remain unchanged once the channel is established. Timeouts while establishing child SAs matching latched parameters MUST be treated as packet loss.
ULPs MUST drop inbound packets and stop sending immediately upon receipt of a latch break message; failure to do so prevents distinguishing packets protected consistently with the latch from those that were not.
Under no circumstance is the PAD to be modified at all by connection latching, and IPsec policy databases MUST NOT be modified in any way that persists beyond the lifetime of the related packet flows or survives reboots.
When a connection latch is administratively transitioned to CLOSED, connection-oriented ULPs MUST act as though the connection was reset by the peer; non-connection-oriented ULPs MUST drop inbound and MUST NOT send further packets.
When optional protection is used and local policy permits, the SPD MUST be logically updated to add a suitable PROTECT or BYPASS entry for the exact 5-tuple at latch creation time, atomically, and such updates MUST NOT survive system crashes or reboots.
When the key manager notifies a ULP of a BROKEN latch, the ULP MUST stop sending and MUST drop all subsequent inbound packets for the affected connection until the latch transitions back to ESTABLISHED; connection-oriented ULPs SHOULD treat this as packet loss.
When using SAs with traffic selectors encompassing more than a single flow, an implementation MUST report the QoP as indeterminate rather than selecting one cryptographic suite; implementations SHOULD provide an API for requesting narrow child SAs when a specific QoP is needed.
A Latch Database (LD) is a new IPsec database added to the key manager containing connection latch objects. The LD does not persist across system reboots and is managed in conjunction with updates to the SAD and SPD to detect conflicts.
An 'IPsec channel' (synonymous with 'connection latch') is a packet flow associated with a ULP control block where the peer's identity and the quality of IPsec protection remain constant for the lifetime of the flow. A channel is created when its associated flow is created and destroyed when the flow ends, or 'broken' when the latch cannot be maintained.
The REQUIRED parameters bound in an IPsec channel are: type of protection (confidentiality and/or integrity), transport vs. tunnel mode, quality of protection (QoP: algorithm suites, key lengths, replay protection), local identity, and peer identity as per the IPsec processing model and BTNS.
ULP interfaces to the IPsec LD comprise: CREATE_LISTENER_LATCH(3-tuple, ...) -> handle, CREATE_CONNECTION_LATCH(5-tuple, ...) -> handle, RELEASE_LATCH(handle), FIND_LATCH(5-tuple) -> handle, INQUIRE_LATCH(handle) -> {state, params}, and an ALERT(handle, 5-tuple, new-state, reason) callback from the key manager to the ULP.
Applications SHOULD check that both ends of a connection are latched (implicit when using channel binding to IPsec). Applications using multiple concurrent connections between two nodes must individually verify that each connection's latched peer IPsec ID is consistent.
Connection latch BROKEN state transitions can be triggered by on-path attackers and off-path attackers able to manipulate routers or ICMP Redirect messages. Breaking a latch requires successfully establishing a conflicting SA, which for off-path attackers requires taking over the peer's IP addresses, ruling out purely off-path attacks.
IPsec channels are a prerequisite for channel binding (RFC 5056) to IPsec, but the channel bindings specification for IPsec channels is explicitly out of scope for this document. Without IPsec APIs, connection latching provides only marginal security benefits over traditional IPsec.
Connection latches have four states: LISTENER (3-tuple scope, gives rise to new latches), ESTABLISHED (active 5-tuple latch), BROKEN (SA/SPD conflict or IKEv2 DPD dead-peer detected), and CLOSED (released by ULP, application, or administratively). ESTABLISHED and BROKEN can transition to each other; all active states can transition to CLOSED; BROKEN transitions always notify the holder.