RFC 5660
IPsec Channels: Connection Latching
RFC 5660: IPsec Channels: Connection Latching 🎀
Part 1 of 7 🦋
📜 Title block tea: This is RFC 5660, called IPsec Channels: Connection Latching. It was written by N. Williams from Sun and sits in the Standards Track category. The date is October 2009. The header doesn't list any RFCs that it obsoletes or updates. 💅
Abstract ✨
okay so this doc describes, at a high level, how apps and transport protocols can talk to IPsec to make "channels" 🦋. You do this by latching "connections" (aka packet flows) onto certain IPsec Security Association (SA) parameters, and the latch stays put for as long as the connection lives. The big plot twist is that connection latching sits on top of IPsec. It doesn't change the IPsec architecture underneath 🫶.
Why would you even want this? Connection latching helps protect apps from accidentally sending live packet flows to the wrong peer. That can happen when IPsec gets reconfigured, or when you're relying on a weak link between a peer's identity and its address. That weak link is basically the heart of Better Than Nothing Security (BTNS), so connection latching can add a seriously big layer of protection to BTNS IPsec nodes 🔥.
Last but not least, IPsec channels will make it possible to use channel binding with them 👑.
Status of This Memo 📝
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. To find out where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). The memo can be distributed freely, with no limits 🌸.
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is covered by BCP 78 and by the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the BSD License 🙈.
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Connection Latching .............................................4
2.1. Latching of Quality-of-Protection Parameters ...............8
2.2. Connection Latch State Machine .............................9
2.3. Normative Model: ULP Interfaces to the Key Manager ........12
2.3.1. Race Conditions and Corner Cases ...................17
2.3.2. Example ............................................18
2.4. Informative Model: Local Packet Tagging ...................19
2.5. Non-Native Mode IPsec .....................................21
2.6. Implementation Note Regarding Peer IDs ....................22
3. Optional Features ..............................................22
3.1. Optional Protection .......................................22
4. Simultaneous Latch Establishment ...............................23
5. Connection Latching to IPsec for Various ULPs ..................23
5.1. Connection Latching to IPsec for TCP ......................24
5.2. Connection Latching to IPsec for UDP with
Simulated Connections .....................................24
5.3. Connection Latching to IPsec for UDP with
Datagram-Tagging APIs .....................................25
5.4. Connection Latching to IPsec for SCTP .....................25
5.5. Handling of BROKEN State for TCP and SCTP .................26
6. Security Considerations ........................................27
6.1. Impact on IPsec ...........................................27
6.2. Impact on IPsec of Optional Features ......................28
6.3. Security Considerations for Applications ..................28
6.4. Channel Binding and IPsec APIs ............................29
6.5. Denial-of-Service Attacks .................................29
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................301. Introduction ✨
okay bestie, let's get into it 🧚. IPsec protects packets without really caring about the stateful packet flows that upper-layer protocols (ULPs) rely on. That's a problem 😭, because apps that depend on IPsec for session protection are exposed to some real risks. Those risks include IPsec configurations that change out from under them, configurations where multiple peers can reach the same addresses, and weak links between peer IDs and their addresses. The last one can happen through "wildcard" matching in the IPsec Peer Authorization Database (PAD), and it shows up a lot when Better Than Nothing Security (BTNS) [RFC5387] is in use.
Apps that want to use IPsec might need to make sure local policy is set up correctly on all the endpoints [RFC5406] [USING-IPSEC]. Here's the tea: there are no standard Application Programming Interfaces (APIs) for this. There are non-standard ones, like [IP_SEC_OPT.man], but that's the catch. Apps still have to use hostnames (think the Domain Name System [RFC1034]) and IP addresses through the existing APIs, and they have to rely on an IPsec configuration they might not be able to verify 🙈. On top of that, application specs need to cover PAD/SPD configuration too, so that individual addresses are tightly bound to individual IPsec identities and credentials (certificates, public keys, and so on). That's a lot of work, periodt 💀.
So yeah, IPsec is pretty cumbersome for apps. The fix is APIs for IPsec. That means not just APIs for configuring IPsec, but APIs that look like the existing IP APIs (like "BSD Sockets"). That way, typical apps using UDP [RFC0768], TCP [RFC0793], and Stream Control Transmission Protocol (SCTP) [RFC4960] can use IPsec with minimal changes 🌈.
This document lays the groundwork for IPsec APIs that UDP and TCP apps can use. It's a way to bind traffic flows, like TCP connections, to the security properties the app wants. We call these "connection latches" (and "IPsec channels" in some contexts) 💖. The methods below make that happen by connecting ULPs and apps to IPsec.
If connection latching gets widely adopted, using IPsec could become way simpler for apps, at least for certain classes of them ⭐.
As specified here, connection latching is mainly about watching updates to the SPD and the Security Association Database (SAD). The goal is to spot changes that go against an app's requirements for a given packet flow, and then react. That reaction could be synchronously alerting the ULP and app before any packets get sent or received under the new policy 🔥.
Under no circumstance are IPsec policy databases to be modified by connection latching in any way that can persist beyond the lifetime of the related packet flows, nor reboots. Under no circumstance is the PAD to be modified at all by connection latching.
If you leave out all the optional features, connection latching can be implemented as a monitor of SPD and SAD changes. It only interferes with their workings as much as it needs to, just enough to give synchronous alerts to ULPs and apps 🫶.
We assume you already know the IPsec architecture [RFC4301] and Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] 🎀.
Note: "connection latch" and "IPsec channel" mean the same thing from here on. The second term is related to "channel binding" [RFC5056]. Connection latching is suitable for channel binding applications, or it will be once the channel bindings for IPsec channels get defined. (Defining those IPsec channel bindings is out of scope for this document 🙈.)
Note: when this document says IPsec peer "ID", it means the Internet Key Exchange (IKE) peer ID (for example, the ID derived from a peer's cert, as well as the cert itself). It does not mean the peer's IP address 💜.
1.1. Conventions Used in This Document 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Abstract function names are all capitalized and written with a pair of parentheses. Their arguments go inside the parentheses, and optional arguments go in square brackets. If there's a return value, it comes after the argument list, introduced by ->, with a description of what it is. For example, FOO(3-tuple, [message]) is a function called "FOO" with two arguments, one of them optional, that returns nothing. By contrast, FOOBAR(handle) -> state is a function with a single required argument that returns a value. The types of the values are described in the surrounding text ✨.
2. Connection Latching ✨
okay so bestie, an IPsec channel is basically a packet flow tied to a ULP control block (like a TCP connection) where every single packet is protected by IPsec SAs, and two things stay locked for the whole life of the flow 🔒:
- the peer's identity is the same the entire time 🫶
- the quality of IPsec protection is the same for every packet in that flow 💅
an IPsec channel gets created when the flow gets created 🦋 that could happen because of something you do locally (like a connect() that makes the first outgoing packet go out), or because you receive the first/initiating packet for the flow (like a TCP SYN) 🌸
it gets destroyed when the flow ends 💀 and it can also get "broken" if the connection latch can't be kept up for some reason (more on that below). when that happens, the ULP and the application get told about it 🚨
so channels are made by "latching" a bunch of parameters onto a ULP connection when the connection is made 🎀 the REQUIRED set of parameters that get bound into IPsec channels is:
- Type of protection: confidentiality and/or integrity protection 🛡️
- Transport mode versus tunnel mode 🚇
- Quality of protection (QoP): cryptographic algorithm suites, key lengths, and replay protection (see Section 2.1) 🔐
- Local identity: the local ID asserted to the peer, as per the IPsec processing model [RFC4301] and BTNS [RFC5386] 🪪
- Peer identity: the peer's asserted and authorized IDs, as per the IPsec processing model [RFC4301] and BTNS [RFC5386] 👑
the SAs protecting a given channel's packets are allowed to change over time 🔄 they might expire and get swapped for equivalent SAs, or they might get re-keyed. the set of SAs protecting a channel doesn't need to be related by anything except this: they must be congruent to the channel, meaning the SAs' parameters have to match what's latched into the channel ✨ and honestly it's super desirable that IPsec channels survive the expiration of IKE_SAs and child SAs, because then the operational stuff in the various key exchange protocols can't mess with the design and features of connection latching 🙌
now, if the SPD gets modified, or an SA gets added to the SAD, and the new policy and/or SA isn't congruent to an established channel (see the previous paragraph), then we call that a conflict 😤 conflict resolution is covered below 👇
Requirements and recommendations:
- If an IPsec channel is desired, then packets for a given connection MUST NOT be sent until the channel is established. 🚫📤
- If an IPsec channel is desired, then inbound packets for a given connection MUST NOT be accepted until the channel is established. That is, inbound packets for a given connection arriving prior to the establishment of the corresponding IPsec channel must be dropped or the channel establishment must fail. 🙅♀️📥
- Once an IPsec channel is established, packets for the latched connection MUST NOT be sent unprotected nor protected by an SA that does not match the latched parameters. 🔒
- Once an IPsec channel is established, packets for the latched connection MUST NOT be accepted unprotected nor protected by an SA that does not match the latched parameters. That is, such packets must either be dropped or cause the channel to be terminated and the application to be informed before data from such a packet can be delivered to the application. 🛑
- Implementations SHOULD provide programming interfaces for inquiring the values of the parameters latched in a connection. 🔍
- Implementations that provide such programming interfaces MUST make available to applications all relevant and available information about a peer's ID, including authentication information. This includes the peer certificate, when one is used, and the trust anchor to which it was validated (but not necessarily the whole certificate validation chain). 🪪🏅
- Implementations that provide such programming interfaces SHOULD make available to applications any information about local and/or remote public and private IP addresses, in the case of NAT-traversal. 🌐
- Implementations that provide such programming interfaces SHOULD make available to applications the inner and outer local and peer addresses whenever the latched connection uses tunnel-mode SAs. 🎁
- Implementations SHOULD provide programming interfaces for setting the values of the parameters to be latched in a connection that will be initiated or accepted, but these interfaces MUST limit what values applications may request according to system policy (i.e., the IPsec PAD and SPD) and the application's local privileges.
(Typical system policy may not allow applications any choices here. Policy extensions allowing for optional protection are described in Section 3.1.) 📜
- Implementations SHOULD create IPsec channels automatically by default when the application does not explicitly request an IPsec channel. Implementations MAY provide a way to disable automatic creation of connection latches. ⚙️
- The parameters latched in an IPsec channel MUST remain unchanged once the channel is established. 🧊
- Timeouts while establishing child SAs with parameters that match those latched into an IPsec channel MUST be treated as packet loss (as happens, for example, when a network partitions); normal ULP and/or application timeout handling and retransmission considerations apply. ⏳
- Implementations that have a restartable key management process (or "daemon") MUST arrange for existing latched connections to either be broken and disconnected, or for them to survive the restart of key exchange processes. (This is implied by the above requirements.) For example, if such an implementation relies on keeping some aspects of connection latch state in the restartable key management process (e.g., values that potentially have large representations, such as BTNS peer IDs), then either such state must be restored on restart of such a process, or outstanding connection latches must be transitioned to the
CLOSEDstate. 🔄💫 - Dynamic IPsec policy (see Section 3.1) related to connection latches, if any, MUST be torn down when latched connections are torn down, and MUST NOT survive reboots. 🧹
- When IKE dead-peer detection (DPD) concludes that the remote peer is dead or has rebooted, then the system SHOULD consider all connection latches with that peer to be irremediably broken. 💔
we describe two models of IPsec channels for native IPsec implementations, and only one of them is normative 📚 the normative model is based on abstract programming interfaces in the form of function calls between ULPs and the key management component of IPsec (basically the SAD, augmented with a Latch Database (LD)) 🗄️ the second model is based on abstract programming interfaces between ULPs and the IPsec (Encapsulating Security Payload / Authentication Header (ESP/AH)) layer, using meta-data tagging of packets within the IP stack 🏷️
the two models aren't fully equivalent though 👀 one model can't be built with NICs that offload ESP/AH but don't tag incoming packets passed to the host processor with SA information, or let the host processor tag outgoing packets. that same model can be easily extended to support connection latching with unconnected datagram "sockets", while the other model is rigidly tied to a notion of "connections" and can't be extended that way. there may be other minor differences between the two as well. instead of trying to prove they're equivalent for some set of security guarantees, we just pick one model to be the normative one 💅
we also provide a model for non-native implementations, like bump-in-the-stack (BITS) and Security Gateway (SG) implementations 🧩 the connection latching model for non-native implementations isn't full-featured, because it depends on estimating packet flow state, which may not always be possible. non-native IPsec implementations also can't be expected to provide connection latching APIs (the ones that do could be called native) 🙃 so this third model is not suitable for channel binding applications [RFC5056] 🚫
2.1. Latching of Quality-of-Protection Parameters 💜
okay so in IPsec, the assumption about who's the IKE initiator and who's the responder is non-deterministic 🎲 sometimes an IKE SA and child SAs get initiated by the "client" (like whoever calls the connect() BSD sockets function), and sometimes by the "server" (like whoever calls accept()) 🖥️ which means the negotiation of quality of protection is non-deterministic too, unless one of the peers offers a single cryptographic suite in the IKE negotiation 🤷♀️
when you create narrow child SAs with traffic selectors matching the connection latch's 5-tuple, you can constrain the IKE Quality-of-Protection negotiation down to a single cryptographic suite ✨ so implementations SHOULD provide an API for requesting the use of such child SAs 🙌 and implementors SHOULD consider an application request for a specific QoP to imply a request for narrow child SAs 🎯
but when you use SAs with traffic selectors covering more than just one flow, the system may only be able to latch a set of cryptographic suites instead of a single one 😬 in that case, an implementation MUST report the QoP being used as indeterminate 🌫️
2.2. Connection Latch State Machine ✨
okay so connection latches can be in one of five states, bestie 💅
- LISTENER
- ESTABLISHED
- BROKEN (there exist SAs that conflict with the given connection latch, conflicting SPD changes have been made, or DPD has been triggered and the peer is considered dead or restarted)
- CLOSED (by the ULP, the application or administratively)
and every latch always has an owner, or holder, like a ULP transmission control block (TCB). no latch is ever homeless 🏠
A latch can be born in the LISTENER state, and that's where its story starts 🌸 LISTENER can only transition to CLOSED. It matches up with the LISTEN state of TCP (and other ULPs), it's tied to IP 3-tuples, and it can spawn brand new latches in the ESTABLISHED state. main character energy, fr 👑
A latch can also be born straight into ESTABLISHED or BROKEN. that happens either because a ULP asked for it directly, or because something happened that made a LISTENER latch create a new latch (in either ESTABLISHED or BROKEN). these two states are the active latches for a traffic flow's 5-tuple 🦋 and they can switch between each other, or go to CLOSED.
latches stay in CLOSED until their owners have been told, unless the owner was the one who caused the transition. in that case CLOSED is super fleeting ⚡ going from ESTABLISHED or BROKEN to CLOSED should usually be started by the latch owners, but implementations SHOULD provide administrative interfaces for closing active latches. it's the responsible move 🫶
so when does a latch get BROKEN? 💔 it happens when there are SAs in the SAD whose traffic selectors cover the 5-tuple bound by the latch, and whose peer and/or parameters clash with the ones the latch is bound to. it also happens when SPD changes would make the latched connection's packets get sent or received with different protection parameters than the ones that were latched. and it's allowed when IKEv2 DPD concludes the remote peer is dead or has rebooted 😭 whenever a latch goes to BROKEN, the owner always gets told. then, once every SA and/or SPD conflict is cleared, a BROKEN latch goes back to ESTABLISHED 🥹✨
most transitions come from the latch owners (the ULPs) doing stuff locally. the only exceptions are: being born into ESTABLISHED from a LISTENER latch, going to BROKEN, going from BROKEN back to ESTABLISHED, and administrative moves to CLOSED. (also, check out the implementation note about restartable key management processes in Section 2 🔁)
the state diagram below uses the conventions from Section 1.1 and the state transition events from Section 2.3 🎀
<CREATE_LISTENER_LATCH(3-tuple, ...)>
:
v <CREATE_CONNECTION_LATCH(5-tuple, ...)>
/--------\ : :
+------|LISTENER|...... : :
| \--------/ : : : +--------------------+
| : : : : |Legend: |
| : : : : | dotted lines denote|
| <conn. trigger event> : : | latch creation |
| (e.g., TCP SYN : : : | |
| received, : : : | solid lines denote |
| connect() : : : | state transition|
| called, ...) v v : | |
| : /-----------\ : | semi-solid lines |
| : |ESTABLISHED| : | denote async |
| <conflict> \-----------/ : | notification |
| : ^ | : +--------------------+
| : | <conflict
| : <conflict or DPD>
| : cleared> | :
| : | | :
| : | v v
| : /----------------\
| :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
| \----------------/
| |
<RELEASE_LATCH()> <RELEASE_LATCH()>
| |
| v
| /------\
+------------------->|CLOSED|
\------/
Figure 1: Connection Latching State Machinethe exact transition details depend on which connection latching model an implementation follows, so peek at the sections below 🔍
2.3. Normative Model: ULP Interfaces to the Key Manager 🔐
this section is the NORMATIVE model of connection latching, so it's the official rulebook 📜
here we talk about connection latching as a function-call interface between the ULPs and the "key manager" part of a native IPsec implementation. we describe abstract interfaces for creating, asking about, and releasing IPsec channels 🧚
this model adds a service to the IPsec key manager (the bit that manages the SAD and works with the separate key exchange protocol implementations, or implements them itself): managing connection latches. there's also a brand new IPsec database, the Latch Database (LD), which holds every connection latch object. the LD does not persist across system reboots, so it resets on reboot 🔄
the traditional IPsec processing model lets SAs with different peers but overlapping traffic selectors exist at the same time. in this model, that directly breaks the requirements for connection latching (see Section 2) 😤 so we fix it by requiring that connection latches get broken (and holders informed) whenever those conflicts show up 💅
the INFORMATIVE figure below shows this model and API using terms lots of implementors will recognise, though it doesn't fit every implementation 🌈
+--------------------------------------------+
| +--------------+ |
| |Administrator | |
| |apps | |
| +--------------+ |
| ^ ^ |
| | | | user mode
| v v |
| +--------------+ +-------++--------+ |
| |App | |IKEv2 || | |
| | | | +---+ || +----+ | |
| | | | |PAD| || |SPD | | |
| | | | +---+ || +--^-+ | |
| +--------------+ +-+-----++----+---+ |
| ^ | | |
+---|---------------------|-----------|------+ user/kernel mode
| |syscalls | PF_KEY | | interface
| | | [RFC2367] | |
+---|---------------------|-----------|------+
| v | | |
|+-------+ +------------|-----------|-----+|
||ULP | | IPsec key|manager | ||
|+-------+ | | +--------v----+||
| ^ ^ | | | Logical SPD |||
| | | | | +-----------^-+||
| | | | +-------+ | || kernel mode
| | | | | | ||
| | | | +----------+ +--v--+ | ||
| | +-------->| Latch DB |<-->| SAD | | ||
| | | +----------+ +--^--+ | ||
| | +--------------------|------|--+|
+-|-------------------------------v------v---+
| | IPsec Layer (ESP/AH) |
| | |
+-v------------------------------------------+
| IP Layer |
+--------------------------------------------+Figure 2: Informative Implementation Architecture Diagram
the ULP interfaces to the IPsec LD look like this 🎀
CREATE_LISTENER_LATCH(3-tuple, [type and quality-of-protection parameters])->latch handle | error
if there's no conflicting connection latch object in the LISTENER state for the given 3-tuple (local address, protocol, and local port number), AND local policy allows it, then this operation atomically creates a connection latch object in the LISTENER state for that 3-tuple ✨
when a child SA shows up that matches a listener latch's 3-tuple, but doesn't match any ESTABLISHED connection latch's 5-tuple (local address, remote address, protocol, local port number, and remote port number), the key manager creates a new connection latch object in the ESTABLISHED state 🦋 the key manager MUST inform the holder of the listener latch about any connection latches created because of that listener latch. see the "ALERT()" interface below 🚨
CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection parameters], [peer ID], [local ID])->latch handle | error
if a) the requested latch doesn't exist (or does exist but is CLOSED), b) all the latch parameters are provided, or suitable SAs already exist in the SAD to derive them from, AND c) there are no conflicts with the SPD and SAD, then this creates a connection latch in the ESTABLISHED state 💖 if the latch parameters aren't provided and there are no suitable SAs in the SAD to derive them from, then the key manager MUST start child SAs (and, if needed, IKE_SA) to derive those parameters from 🛠️
the key manager MAY delay the child SA setup and return right after the policy check. it can do this because the ULP that asked for the latch will send a packet later on, and that packet will kick off the SA establishment 🧦 an implementation like this might need an extra, fleeting state in the connection latch state machine, a "LARVAL" state, so to speak, which isn't described here 🐣
if the connection latch ultimately can't be established, either because of conflicts or because no SAs can be set up with the peer at the destination address, then an error is returned to the ULP 😬 (if the key manager delayed SA establishment and the SA setup ultimately fails, the key manager has to tell the ULP, possibly asynchronously. this is one of several details that implementors who use a LARVAL state must take care of 🧠)
RELEASE_LATCH(latch object handle)
changes the state of the given connection latch to CLOSED, and then the connection latch gets deleted 👋
the key manager MAY delete any existing child SAs that match the given latch if the latch had been in the ESTABLISHED state. if the key manager does delete those SAs, it SHOULD inform the peer with an informational Delete payload (see IKEv2 [RFC4306]) 🗑️
FIND_LATCH(5-tuple)->latch handle | error
given a 5-tuple, returns a latch handle (or an error) 🔎
INQUIRE_LATCH(latch object handle)->{latch state, latched parameters} | error
returns all the available information about the given latch, including its current state (or an error) 📋
the IPsec LD interface to the ULP looks like this 📣
ALERT(latch object handle, 5-tuple, new state, [reason])
Alerts a ULP as to an asynchronous state change for the given
connection latch and, optionally, provides a reason for the
change.
This interface is to be provided by each ULP to the key manager.
The specific details of how this interface is provided are
implementation details, thus not specified here (for example, this
could be a "callback" function or "closure" registered as part of
the CREATE_LISTENER_LATCH() interface, or it could be provided
when the ULP is loaded onto the running system via a registration
interface provided by the key manager).Obviously the LD gets updated whenever a connection latch object is created, deleted, or broken 💖
Okay so this whole API is a brand-new service of the IPsec key manager 🎀 and it comes with serious responsibilities. The IPsec key manager MUST prevent conflicts amongst latches, and it MUST prevent conflicts between any latch and existing or proposed child SAs, like this:
- Non-listener connection latches MUST NOT be created if there are conflicting SAs in the SAD when the connection latch is requested or would be created (from a listener latch). A child SA conflicts with another one, in view of a latch, if and only if: a) its traffic selectors and the conflicting SA's match the given latch's, and b) its peer, type-of-protection, or quality-of-protection parameters differ from the conflicting SA. 🙈
- Child SA proposals that would conflict with an extant connection latch, and whose traffic selectors can be narrowed to avoid the conflict, SHOULD be narrowed (see Section 2.9 of [RFC4306]). Otherwise, the latch MUST be transitioned to the BROKEN state. 💅
- Where child SA proposals that would conflict with an extant connection latch cannot be narrowed to avoid the conflict, the key manager MUST break the connection latch and inform the holder (i.e., the ULP) prior to accepting the conflicting SAs. 💀
Finally, the key manager MUST protect latched connections against SPD changes that would change the quality of protection afforded to a latched connection's traffic, or that would bypass it. 🔥 When a configuration change like that happens, the key manager MUST respond in either of the following ways. The REQUIRED to implement behavior is to transition into the BROKEN state all connection latches that conflict with the given SPD change. An OPTIONAL behavior is to logically update the SPD as if a PROTECT entry had been added at the head of the SPD-S, with traffic selectors matching only the latched connection's 5-tuple, and with processing information taken from the connection latch. Such updates of the SPD MUST NOT survive system crashes or reboots. Not surviving a crash is giving very safe, very protective energy 🧚
ULPs create latched connections by interfacing with IPsec in these ways:
- For listening end-points, the ULP will request a connection latch listener object for the ULP listener's 3-tuple. Any latching parameters requested by the application MUST be passed along. 🎀
- When the ULP receives a packet initiating a connection for a 5-tuple matching a 3-tuple listener latch, then the ULP will ask the key manager whether a 5-tuple connection latch was created. If not, then the ULP will either reject the new connection or accept it and inform the application that the new connection is not latched. 👀
- When initiating a connection, the ULP will request a connection latch object for the connection's 5-tuple. Any latching parameters requested by the application MUST be passed along. If no latch can be created, then the ULP MUST either return an error to the application or continue with the new connection and inform the application that the new connection is not latched. 🦋
- When a connection is torn down and no further packets are expected for it, then the ULP MUST request that the connection latch object be destroyed. 🧹
- When tearing down a listener, the ULP MUST request that the connection latch listener object be destroyed. 🌸
- When a ULP listener rejects connections, the ULP will request the destruction of any connection latch objects that may have been created as a result of the peer's attempt to open the connection. 🫶
- When the key manager informs a ULP that a connection latch has transitioned to the BROKEN state, then the ULP MUST stop sending packets and MUST drop all subsequent incoming packets for the affected connection until it transitions back to ESTABLISHED. Connection-oriented ULPs SHOULD act as though the connection is experiencing packet loss. 📉
- When the key manager informs a ULP that a connection latch has been administratively transitioned to the CLOSED state, then connection-oriented ULPs MUST act as though the connection has been reset by the peer. Implementations of ULPs that are not connection-oriented, and that have no API by which to simulate a reset, MUST drop all inbound packets for that connection and MUST NOT send any further packets. The application is expected to detect timeouts and act accordingly. ⏰
The main benefit of this model of connection latching is that it accommodates IPsec implementations where ESP/AH handling is implemented in hardware (for all or a subset of the host's SAD), even where the hardware does not support tagging inbound packets with the indexes of SAD entries corresponding to the SAs that protected them. Hardware that can't tag packets? No problem, bestie 🌈
2.3.1. Race Conditions and Corner Cases 💥
ULPs MUST drop inbound packets and stop sending packets immediately upon receipt of a connection latch break message. Otherwise, the ULP will not be able to tell apart inbound packets that were protected consistently with the connection's latch from inbound packets that were not. This may include dropping inbound packets that were protected by a suitable SA. From the ULP's point of view, dropping such packets is no different from packet loss elsewhere on the network at the IP layer or below. It's harmless from a security point of view because the connection fails safe, but it can result in retransmits. 🙃
Another race condition goes like this. A PROTECTed TCP SYN packet may be received and decapsulated, but the SA that protected it could have expired before the key manager creates the connection latch that would be created by that packet. In this case, the key manager will have to initiate new child SAs so it can determine the sender's peer ID and include it in the connection latch. There is no guarantee that the peer ID for the new SAs will be the same as that of the peer that sent the TCP SYN packet. This race condition is harmless: TCP will send a SYN+ACK to the wrong peer, which will then respond with a RST. The connection latch will reflect the new peer, however, so if the new peer is malicious, it will not be able to appear to be the old peer. Therefore, this race condition is harmless. 🫣
2.3.2. Example 🧚
Consider several systems with a very simple PAD containing a single entry like so:
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <any valid to trust anchor X> 192.0.2/24 by-IPFigure 3: Example PAD
And a simple SPD like so:
Rule Local Remote Next Action
TS TS Proto
---- ----- ------ ----- ----------------
1 192.0.2/24:ANY 192.0.2/24:1-5000 TCP PROTECT(ESP,...)
1 192.0.2/24:1-5000 192.0.2/24:ANY TCP PROTECT(ESP,...)
1 ANY ANY ANY BYPASSFigure 4: [SG-A] SPD Table
Effectively this says: for TCP ports 1-5000 in our network, allow only peers that have credentials issued by CA X, and PROTECT that traffic with ESP. Otherwise, bypass all other traffic. 🌟
Now let's look at two hosts, A and B, in this network that want to communicate using port 4000, plus a third host, C, that is also in the same network and wants to attack A and/or B. 😈 All three hosts have credentials and certificates issued by CA X. Let's also imagine that A is connected to its network via a wireless link and is dynamically addressed. 📱
B is listening on port 4000. A initiates a connection from port 32800 to B on port 4000.
We'll assume there are no IPsec APIs, but that TCP creates latches where possible.
We'll consider three cases: a) A and B both support connection latching, b) only A does, c) only B does. For the purposes of this example, the SAD is empty on all three hosts when A initiates its TCP connection to B on port 4000.
When an application running on A initiates a TCP connection to B on port 4000, A will begin by creating a connection latch. Since the SAD is empty, A will initiate an IKEv2 exchange to create an IKE_SA with B and a pair of child SAs for the 5-tuple {TCP, A, 32800, B, 4000}. Then a new latch will be created in ESTABLISHED state. Sometime later, TCP will send a SYN packet protected by the A-to-B child SA, per the SPD. 🦋
When an application running on B creates a TCP listener "socket" on port 4000, B will create a LISTENER connection latch for the 3-tuple {TCP, B, 4000}. When B receives A's TCP SYN packet, it will then create a connection latch for {TCP, B, 4000, A, 32800}. Since, by this point, child SAs have been created whose traffic selectors encompass this 5-tuple, and there are no other conflicting SAs in the SAD, this connection latch will be created in the ESTABLISHED state. ✅
If C attempts to mount a man-in-the-middle attack on A (i.e., pretends to have B's address(es)) any time after A created its connection latch, then C's SAs with A will cause the connection latch to break, and the TCP connection to be reset. (That's because we assume there are no APIs by which TCP could notify the application of the connection latch break.) If C attempts to impersonate A to B, then the same thing will happen on B. 🚨
If A does not support connection latching, then C will be able to impersonate B to A at any time. Without having seen the cleartext of traffic between A and B, C will be limited by the TCP sequence numbers to attacks such as RST attacks. Similarly, if B does not support connection latching, then C will be able to impersonate A to B. 😭
2.4. Informative Model: Local Packet Tagging
okay so this section looks at connection latching from the ULP side (TCP, UDP, SCTP, the protocols sitting right on top of IP 💅) and shows how IPsec and the ULPs can pass tags back and forth as packets go up and down the IP stack 🦋
This section is INFORMATIVE.
In this model the ULPs keep the connection latch objects and state themselves, instead of the IPsec key manager doing it. They also basically cache a subset of the decorrelated SPD inside their TCBs ✨ Tagging packets with SA identifiers as they move up and down the stack lets the ULPs enforce connection latching semantics. And these tags are local only. They never show up on the wire 🫶
The interface between the ULPs and IPsec works like this:
- The IPsec layer tags all inbound protected packets addressed to the host with the index of the SAD entry corresponding to the SA that protected the packet.
- The IPsec layer understands two types of tags on outbound packets:
- a tag specifying a set of latched parameters (peer ID, quality of protection, etc.) that the IPsec layer will use to find or acquire an appropriate SA for protecting the outbound packet (else IPsec will inform the ULP and drop the packet);
- a tag requesting feedback about the SA used to protect the outgoing packet, if any.
ULPs create latched connections by talking to IPsec like this:
- When the ULP passes a connection's initiating packet to IP, the ULP requests feedback about the SA used to protect the outgoing packet, if any, and may specify latching parameters requested by the application. If the packet is protected by IPsec, then the ULP records certain parameters of the SA used to protect it in the connection's TCB.
- When a ULP receives a connection's initiating packet, it processes the IPsec tag of the packet, and it records in the connection's TCB the parameters of the SA that should be latched.
Once SA parameters are recorded in a connection's TCB, the ULP enforces the connection's latch (aka binding) to those parameters like so:
- The ULP processes the IPsec tag of all inbound packets for a given connection and checks that the SAs used to protect input packets match the connection latches recorded in the TCBs. Packets that are not so protected are dropped (this corresponds to transitioning the connection latch to the BROKEN state until the next acceptable packet arrives, but in this model, this transition is imaginary) or cause the ULP to break the connection latch and inform the application. 😬
- The ULP always requests that outgoing packets be protected by SAs that match the latched connection by appropriately tagging outbound packets.
By caching a subset of the decorrelated SPD in ULP TCBs and relying on this packet tagging, this method of connection latching can also optimize SPD processing. It skips the need to search the SPD, both on input and on output, for packets intended for the host or originated by the host. That means the OPTIONAL "logical SPD" updates described in Sections 2.3 and 3.1 end up being an incidental side effect of this approach. ✨
This model of connection latching may not be workable with ESP/AH offload hardware that does not support the packet tagging scheme described above.
Note that this model has no explicit BROKEN connection latch state. 🙈
Extending the ULP/IPsec packet-tagging interface to the application, for use with connection-less datagram transports, should let applications use those transports and implement connection latching at the application layer. 🧚
2.5. Non-Native Mode IPsec
This section is INFORMATIVE.
Non-native IPsec implementations, mainly BITS and SG, can implement connection latching too 💜 The big difference between native IPsec and BITS, bump-in-the-wire (BITW), or SG IPsec is that the latter have no APIs for applications at the end-points. So there can be no uses of the latch management interfaces described in Section 2.3, not even at the ULP end-points. That means BITS/BITW/SG implementations have to figure out ULP connection state by inspecting packets (which lots of firewalls can do) and then emulate calls to the key manager accordingly.
When a connection latch is broken, a BITS/BITW/SG implementation may have to fake a connection reset by sending appropriate packets (e.g., TCP RST packets) for the affected connections. 💀
Like all stateful middleboxes, this scheme suffers from the middlebox's inability to interact with applications. For example, connection death may be hard to figure out. And channel binding applications can't work with channels maintained by a proxy without being able to communicate, securely, with the middlebox about it. 🥺
2.6. Implementation Note Regarding Peer IDs
One of the recommendations for connection latching implementors is to make peer CERT payloads (certificates) available to applications. 🎀
Also, raw public keys are likely to be used when building channel bindings for IPsec channels (see [IPSEC-CB]). They also have to be available in any case, so that leap-of-faith can be implemented at the application layer (see [RFC5386] and [RFC5387]). 🔑
Certificates and raw public keys are big bit strings, too big to be reasonably kept in kernel-mode implementations of connection latching (which will likely be the typical case). Those implementations should intern peer IDs in a user-mode database and use small integers to refer to them from the kernel-mode SAD and LD. Corruption of that database is akin to corruption of the SAD/LD. If it does get corrupted, the implementation MUST act as though all ESTABLISHED and BROKEN connection latches are administratively transitioned to the CLOSED state. 🚨 Implementations without IPsec APIs MAY hash peer IDs and use the hash to refer to them, preferably using a strong hash algorithm. 🌈
3. Optional Features
At its bare minimum, connection latching is a passive layer on top of IPsec that warns ULPs about SPD and SAD changes that are incompatible with the SPD/SAD state that applied to a connection when it was established. 👀
There are some optional features, such as (abstract) APIs. Some of these make connection latching a bit more active. Specifically, the optional logical SPD updates described in Section 2.3 and the optional protection/bypass feature described in the following sub-section. ⭐
3.1. Optional Protection
With IPsec APIs, an application could request that a connection's packets be protected where they'd otherwise be bypassed. In other words, applications could override BYPASS policy. Locally privileged applications could request that their connections' packets be bypassed rather than protected, so privileged applications could override PROTECT policy. We call this "optional protection". 🦋
Both native IPsec models of connection latching can be extended to support optional protection. With the model described in Section 2.4, optional protection comes naturally: the IPsec layer only needs to check that the protection requested for outbound packets meets or exceeds (as determined by local or system policy) the quality of protection, if any, required by the SPD. For the model described in Section 2.3, enforcing minimum protection requirements would be done by the IPsec key manager via the connection latch state machine. 💅
When an application requests, and local policy permits, either additional protection or bypassing protection, then the SPD MUST be logically updated so that there's a suitable SPD entry protecting or bypassing the exact 5-tuple recorded by the corresponding connection latch. 🔥 Such logical SPD updates MUST be made at connection latch creation time, and MUST be made atomically (see the note about race conditions in Section 2.3). And such updates of the SPD MUST NOT survive system crashes or reboots. 💀
Those SPD updates are temporary by design. If the system crashes or reboots, they're gone. Don't count on them sticking around! 🙈
4. Simultaneous Latch Establishment
Some connection-oriented ULPs, specifically TCP, support simultaneous connections (where two clients connect to each other, using the same 5-tuple, at the same time). Connection latching supports simultaneous latching too, as long as the key exchange protocol doesn't make it impossible. 👯♀️
Picture two applications doing a simultaneous TCP connect to each other and requesting an IPsec channel. If they request the same connection latching parameters, then the connection and channel should be established as usual. Even if the key exchange protocol in use doesn't support simultaneous IKE_SA and/or child SA establishment, once one peer's attempt to create the necessary child SAs succeeds, the other peer should be able to notice the new SAs right away when its own attempts to create the same ones fail. ✨
If, however, the two peer applications request different connection latching parameters, then the connection latch must fail on one end or on both ends. 😭
5. Connection Latching to IPsec for Various ULPs
The following sub-sections describe connection latching for each of three transport protocols. Note that for TCP and UDP, there's nothing in the following sections that shouldn't already be obvious from the rest of this document. The section on SCTP, however, covers details about SCTP multi-homing that may not be as obvious. 🌸
5.1. Connection Latching to IPsec for TCP
IPsec connection latch creation/release for TCP [RFC0793] connections is triggered when:
- a TCP listener end-point is created (e.g., when the BSD Sockets
listen()function is called on a socket). This should cause the creation of a LISTENER connection latch. - a TCP
SYNpacket is received on an IP address and port number for which there is a listener. This should cause the creation of an ESTABLISHED or BROKEN connection latch. - a TCP
SYNpacket is sent (e.g., as the result of a call to the BSD Socketsconnect()function). This should cause the creation of an ESTABLISHED or BROKEN connection latch. - any state transition of a TCP connection to the CLOSED state will cause a corresponding transition for any associated connection latch to the CLOSED state as well. 🍓
See Section 5.5 for how to handle latch transitions to the BROKEN state. 👑
5.2. Connection Latching to IPsec for UDP with Simulated Connections 🦋
okay so UDP [RFC0768] is a connection-less transport protocol, which is literally the whole vibe of UDP 🫶. BUT some networking APIs (like the BSD Sockets API) let you fake UDP connections anyway 💅. When that happens, you can support connection latching using either model from above. In this section we're ignoring the fact that the connection latching model in Section 2.4 can support per-datagram latching by extending its packet tagging interfaces to the application. That's a whole other glow-up for later 💖.
IPsec connection latch creation and release for UDP connections gets triggered when:
- an application creates a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch. ✨
- an application destroys a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch. 🌸
So when a connection latch goes to the BROKEN state AND the application asked for the connection to be broken (or system policy says so), UDP should tell the application, if there's a way to do that. If there isn't, it should just wait and let the application-layer keepalive/timeout strategy (if there is one) time the connection out 🙈.
What counts as the right move when a latch gets administratively moved to the CLOSED state depends on whether the implementation's "connected" UDP sockets API has a way for the socket to return an error saying it's been closed. Vibes depend on the API, babe 💀.
5.3. Connection Latching to IPsec for UDP with Datagram-Tagging APIs 🎀
Implementations based on either model of connection latching can give applications datagram-tagging APIs based on the ones in Section 2.4. Implementations UDP with of the normative model of IPsec connection latching have to confirm, on output, that the application-provided 5-tuple matches the application-provided connection latch. On input, UDP can derive the tag by searching for a connection latch that matches the incoming datagram's 5-tuple. Main character energy for the lookup 🧚✨.
5.4. Connection Latching to IPsec for SCTP 🌈
SCTP [RFC4960] is a connection-oriented protocol, so it's kind of giving TCP. ngl the big difference for connection latching is that SCTP lets each end-point be identified by a set of IP addresses. But just like TCP, each end-point of an SCTP connection (or, technically, an SCTP association) can only have ONE port number 💅.
We can represent the multiple SCTP association end-point addresses as multiple 5-tuples, each with its own connection latch. OR we can extend the connection latch object so it supports multiple addresses for each end-point. The first approach is the one this document uses throughout, so that's the representation we'll assume 💜.
Heads up though: this approach ends up with N x M connection latches for any SCTP association (where one end-point has N addresses and the other has M). The alternative needs just one connection latch per SCTP association (with N + M addresses). Implementors may choose either approach. It's your call, bestie 🫶.
IPsec connection latch creation and release for SCTP connections gets triggered when:
- an SCTP listener end-point is created (for example, when the SCTP sockets listen() function is called on a socket). This should cause the creation of a LISTENER connection latch for each address of the listener. 🍓
- an SCTP INIT chunk is received on an IP address and port number that has a listener. This should cause the creation of one or more ESTABLISHED or BROKEN connection latches, one for each distinct 5-tuple given the client and server's addresses. 👑
- an SCTP INIT chunk is sent (for example, as the result of a call to the SCTP sockets connect() function). This should cause the creation of one or more ESTABLISHED or BROKEN connection latches. ✨
- an SCTP Address Configuration Change Chunk (ASCONF) [RFC5061] adding an end-point IP address is sent or received. This should cause the creation of one or more ESTABLISHED or BROKEN connection latches. 🦋
- any state transition of an SCTP association to the CLOSED state will cause a matching transition of any associated connection latches to the CLOSED state as well. Bye bye, latches 😭.
- an SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is sent or received. This should cause one or more associated connection latches to be CLOSED. 💀
For how to handle latch transitions to the BROKEN state, check out Section 5.5 🌸.
5.5. Handling of BROKEN State for TCP and SCTP 💖
There are a few ways to handle connection latch transitions to the BROKEN state when you're dealing with connection-oriented ULPs like TCP or SCTP:
- a. Wait for a possible future transition back to the ESTABLISHED state. Until that happens, the ULP won't move data between the two end-points of the connection. ULP and application timeout mechanisms will, of course, kick in if you stay in the BROKEN state for too long. SCTP can detect these timeouts and start failover, in the case of multi-homed associations. ⏳
- b. Act as though the connection has been reset (an RST message received, in TCP, or an ABORT message received, in SCTP). 🔥
- c. Act as though an ICMP destination unreachable message had been received. (In SCTP, messages like this can trigger path failover in the case of multi-homed associations.) 🌈
Implementations SHOULD provide APIs that let applications either 1) get told about latch breaks (asynchronously or otherwise) so they can pick a disposition, and/or 2) select a specific disposition a priori (before a latch break happens). The disposition options are wait, close, or proceed with path failover. Choices, choices 🎀.
Implementations MUST provide a default disposition for when a connection latch breaks. Option (a) is clearly the purist default, but we RECOMMEND (b) for TCP and SCTP associations where only a single path remains (one 5-tuple), and (c) for multi-homed SCTP associations. The reasoning is this: a conflicting SA most likely means the original peer is gone and has been replaced by another, and the original peer probably isn't coming back. So failing faster just makes sense 🧚.
Okay, this part is SO important 🚨. Our recommended default behavior does NOT create off-path reset denial-of-service (DoS) attacks. To break a connection latch, an attacker would first have to successfully establish an SA with one of the connection's end-points, one that conflicts with the connection latch and that needs multiple messages exchanged between that end-point and the attacker. Unless the attacker's chosen victim end-point lets the attacker claim IP address ranges for its SAs, the attacker would have to actually take over the other end-point's addresses, and that rules out off-path attacks. Locked down 🔒💅.
6. Security Considerations 🛡️
6.1. Impact on IPsec 🌸
Connection latching adds a mechanism for dealing with the situation where the SAD has multiple non-equivalent child SAs with overlapping traffic selectors. At minimum, this mechanism is a local notification to transport protocols (and, through them, applications) that a conflict exists and affects a transport layer's connections. Affected transports also get notified when the conflict is cleared. The transports MUST NOT... wait, sorry, lowercase in the original, so: the transports must drop inbound packets, and must not send outbound packets, for connections affected by a conflict. In this minimal form, connection latching is a passive, local feature layered on top of IPsec. Chill and low-key 🫶.
We do this by adding a brand new type of IPsec database, the Latch Database (LD). It holds objects that represent a transport protocol's interest in protecting a given packet flow from these conflicts. The LD is managed alongside updates to the SAD and the SPD, so any updates to either that conflict with established connection latches can be detected. For some IPsec implementations this might mean big changes to their internals 😭. But two different models of connection latching are given, and we hope most native IPsec implementors will find at least one model simple enough to implement in their stack 🙏.
This whole idea of conflicting SAs (and how to deal with them) does NOT change the basic IPsec architecture. The IPsec feature that lets those conflicts happen is still there, and it's up to the transport protocols and applications to decide whether and how to respond 💅.
There are, however, interesting corner cases in the normative model of connection latching that implementors absolutely need to know about. The notes in Section 2.3.1 are especially relevant 👀.
6.2. Impact on IPsec of Optional Features 🎀
Section 3 describes optional features of connection latching where the key manager takes on a somewhat more active role. It's still local, though 🧚. There are two of these features: optional protect/bypass, and preservation of "logical" SPD entries so latched connections can stay in the ESTABLISHED state even when administrative SPD (but not SAD) changes are not so friendly. These two features interact with administrative interfaces to IPsec, so administrators have to be made aware of them, and they SHOULD be given a way to break ESTABLISHED connection latches. Also, since there's a recent trend toward centralizing parts of IPsec policy, these two features can be said to have non-local effects, because they can stop distributed policy changes from fully taking effect 🌈.
6.3. Security Considerations for Applications 💜
Connection latching is not negotiated. That means one end of a connection can be using connection latching while the other end isn't. In that case, policy changes local to the non-latched end could cause packets to be sent unprotected 😱. The latched end will reject unprotected packets, but if they carry sensitive data, the damage may already be done 💀. So applications SHOULD check that both ends of a connection are latched. (That check is implicit for applications that use channel binding to IPsec, so those are covered ✨.)
Connection latching protects individual connections from weak peer ID<->address binding, from IPsec configuration changes, and from configurations that let multiple peers assert the same addresses. BUT connection latching does NOT ensure that any two connections with the same end-point addresses will have the same latched peer IDs. In other words, applications that use multiple concurrent connections between two nodes might not be protected any more or less by connection latching than by IPsec alone 🙈. Multi-connection apps can, however, examine the latched SA parameters of each connection to make sure all concurrent connections with the same end-point addresses also have the same end-point IPsec IDs. Double-check your work, bestie 🫶.
Connection latching protects against TCP RST attacks. It does not help, though, if the original peer of a TCP connection is no longer available (for example, if an attacker has managed to interrupt the network connection between the two peers). That's a real limit, so don't get it twisted 😭🔥.
6.4. Channel Binding and IPsec APIs ✨
okay so IPsec channels are literally a prerequisite for channel binding [RFC5056] to IPsec 💅 connection latching gives you those channels, BUT the channel bindings for IPsec channels (aka latched connections) are not specified in this doc 🫶 that's a work in progress over at [IPSEC-CB] 🚧
Without IPsec APIs, connection latching only gives you marginal security benefits over traditional IPsec 😭 and those APIs aren't described here either, so go check out [ABSTRACT-API] 🧚
6.5. Denial-of-Service Attacks 💀
bestie, this one is serious 😭 a connection latch state can flip to the BROKEN state if an on-path attacker triggers it, or if an off-path attacker can attack routers or make an end-point accept an ICMP Redirect message. Connection latching protects apps against on- and off-path attackers in general, but not against on-path denial of service specifically 🙈
attackers can break latches if they can trigger DPD on one or both end-points and if they cause packets to stop moving between the two end-points 🥺 those attacks generally need the attacker to be on-path, so we consider it acceptable to break latches when DPD concludes that a peer is dead or rebooted 🌸
attackers can also break latches if IPsec policy on a node lets them use the IP address of a peer of that node 👀 those configurations are expected to be used together with BTNS in general, and those attacks generally need the attacker to be on-path too 🦋
7. Acknowledgements 🫶
the author thanks Michael Richardson for all his help 💖 and also Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, Daniel Migault, and many others who've joined the BTNS WG or answered questions about IPsec, connection latching implementations, etc. ✨ the squad is iconic 👑
8. References 📚
8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6,
RFC 768, August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4960] Stewart, R., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and
M. Kozuka, "Stream Control Transmission Protocol
(SCTP) Dynamic Address Reconfiguration", RFC 5061,
September 2007.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-
Nothing Security: An Unauthenticated Mode of
IPsec", RFC 5386, November 2008.8.2. Informative References
[ABSTRACT-API] Richardson, M., "An abstract interface between
applications and IPsec", Work in Progress,
November 2008.
[IPSEC-CB] Williams, N., "End-Point Channel Bindings for IPsec
Using IKEv2 and Public Keys", Work in Progress,
April 2008.
[IP_SEC_OPT.man] Sun Microsystems, Inc., "ipsec(7P) man page,
Solaris 10 Reference Manual Collection".
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC5056] Williams, N., "On the Use of Channel Bindings to
Secure Channels", RFC 5056, November 2007.
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and
Applicability Statement for Better-Than-Nothing
Security (BTNS)", RFC 5387, November 2008.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of
IPsec Version 2", BCP 146, RFC 5406, February 2009.
[USING-IPSEC] Dondeti, L. and V. Narayanan, "Guidelines for using
IPsec and IKEv2", Work in Progress, October 2006.Author's Address 🖊️
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com📦 where this page comes from
- ietf: rfc5660 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms